PHP2Shell 공지를 보고 점검했더니 PHP가 하나도 없었습니다

이미지
10월 21일에 PHP와 Node.js가 같은 날 보안 패치를 냈습니다. PHP 쪽은 사람들이 PHP2Shell이라고 부르고 있고, Node 쪽은 Node2Shell이라는 이름이 붙었습니다. 이름부터가 좀 무섭습니다. 뒤에 Shell이 붙으면 대개 남의 서버에서 명령을 실행할 수 있다는 뜻이니까요. 회사에서도 바로 지시가 내려왔습니다. 전 프로젝트 점검하고, 외부 IP 붙은 서버는 전수조사하라는 내용이었습니다. 회사 쪽 일은 회사 쪽대로 하고, 저는 퇴근하고 개인 프로젝트랑 예전에 알바로 했던 것들을 한번 열어 봤습니다. 그런데 열어 보고 나니 이번 글은 패치 이야기가 아니라 7년 전 이야기가 됐습니다. PHP2Shell과 Node2Shell, 둘이 같은 무게는 아닌 것 같습니다 찾아오신 분들은 아마 이게 뭔지, 내 서버가 해당되는지부터 궁금하실 것 같아서 그것부터 적습니다. PHP2Shell은 CVE 두 건입니다. CVE-2026-109618 과 CVE-2026-109619이고, 둘 다 인증 없이 원격에서 코드를 실행할 수 있는 취약점입니다. CVSS 4.0 기준 9.2점입니다. 하나는 메모리가 부족할 때 PHP가 요청 데이터를 반쯤 만든 상태에서 멈추고, 정리 단계에서 그 망가진 데이터를 멀쩡한 걸로 취급하는 문제입니다. 다른 하나는 요청이 끝난 뒤에도 그 요청이 쓰던 상태가 남아 있다가 같은 워커가 받은 다음 요청에서 다시 쓰이는 문제입니다. PHP 공식 공지 기준으로 고쳐진 버전은 8.5.12, 8.4.27, 8.3.36, 8.2.35입니다. 그보다 낮은 버전은 전부 해당됩니다. 8.1 이하는 PHP 프로젝트가 더 이상 정규 릴리스를 내지 않습니다. 대신 보안팀이 7.4, 8.0, 8.1용으로 최소한의 소스 백포트를 따로 공개해 뒀고, 배포판이나 LTS 벤더 중에도 백포트를 내는 곳이 있다고 합니다. 직접 빌드하거나 벤더 패키지를 쓰는 게 아니면 사실상 버전을 올리는 수밖에 없어 보입니다. 공지에도 설정을 바꾸는 건 부분적인 완화일 뿐이고...

AI 시대, 중간관리자는 정말 사라질까? - Jack Dorsey의 조직 실험

밝은 사무실 복도에 열린 문이 연달아 이어지고 맨 끝 창으로 햇빛이 들어오는 장면

회사에서 이런 얘기가 돌았습니다. 경영진이 외부 업체 몇 군데를 둘러보고 왔는데 거기서 본 게 꽤 인상적이었던 모양입니다. 개발자가 AI랑 직접 기획을 하고, 기획자가 필요한 부분을 직접 만들고, 디자이너가 개발자를 기다리지 않고 고쳐서 빌드까지 올리는 식이었다고 합니다. 우리도 그쪽으로 가야 하지 않겠냐는 얘기가 위에서 나왔고, 그게 한 단계씩 내려와서 결국 각 팀에 어떻게 생각하시냐는 질문으로 도착했습니다.

저는 그 방향에 동의하는 편입니다. 제 사이드 프로젝트가 이미 그렇게 돌아가고 있어서요. 오디오북 앱 하나를 혼자 만들고 있는데, 관리자 화면이랑 앱이랑 백엔드랑 배포 도구가 한 저장소에 같이 들어 있고, 그 사이를 오가는 일은 제가 직접 하지 않습니다. 저는 방향이 맞는지만 봅니다. 기획도 인프라 구성도 디자인도 단위 테스트도 통합 테스트도 그 안에서 같이 돌아갑니다. 이걸 몇 달 겪고 나면 회사 조직도가 좀 이상해 보이기 시작하는데, 그건 어쩔 수 없는 것 같습니다.

이상해 보인다는 게 정확히 뭔지 생각해 보면, 조직도의 선 대부분이 누가 누구한테 일을 넘기는지를 그려놓은 거라서인 것 같습니다. 제 저장소 안에는 그 선이 없습니다. 넘기는 일이 없으니까요. 그러다 보니 회사 조직도를 보면 선마다 저기서 기다리는 시간이 생기겠구나 하는 생각부터 들게 됩니다.

그런데 이 얘기를 전해 듣고 제일 먼저 걸린 건 내용보다 이 질문이 저한테까지 내려온 길이었습니다. 그건 좀 이따 다시 생각해보기로 하고, 먼저 이 얘기가 어디서 왔는지를 봤습니다.

위계는 정보를 나르려고 생겼다는 얘기

잭 도시가 올해 초에 「From Hierarchy to Intelligence」라는 글을 냈습니다. 세쿼이아의 로엘로프 보타랑 같이 썼고요. 2월 말에 블록이 사천 명을 줄였는데, 그게 비용 절감이 아니라 영구적인 구조 변경이라는 데서 글이 시작합니다.

주장은 꽤 깔끔합니다. 회사의 위계는 원래 문제 하나를 풀려고 생겼다는 겁니다. 한 사람이 전부 볼 수 없을 만큼 조직이 커졌을 때 정보를 어떻게 흘려보낼 거냐. 관리자는 아래에서 맥락을 모아서 올리고, 위에서 온 메시지를 아래로 내리고, 팀 사이를 맞춥니다. 로마 군대 때부터 이천 년 동안 그 역할이 필요했던 건 그 일을 사람밖에 못 했기 때문이고, 이제는 AI가 그걸 끊기지 않고 크게 할 수 있으니 중간에서 전달하는 사람이 필요 없어진다는 얘기입니다.

도시 본인은 작년 12월에 Opus 4.6이랑 Codex 5.3을 써보다가 마음을 굳혔다고 했습니다. 큰 코드베이스 안에서 제대로 돌아가는 걸 보고 나서요. 그리고 앞으로 일 년 안에 대부분 회사가 비슷한 구조 변경을 할 거라고 했습니다.

여기까지는 저도 꽤 동의합니다. 제 쪽에서 실제로 없어진 게 딱 그 일이라서요. 예전에 시간을 제일 많이 잡아먹던 건 만드는 일 자체가 아니라 만드는 일과 만드는 일 사이였습니다. 화면 하나 바꾸려면 시안이 나와야 하고, 시안이 나오면 구현이 되는지 봐야 하고, 보다 보면 원래 의도가 뭐였는지 다시 물어봐야 하고, 물어보면 그새 우선순위가 바뀌어 있었습니다. 이 왕복이 길었던 건 각자 남의 영역을 건드릴 수 없어서였습니다. 권한이 없어서가 아니라 할 줄 몰라서요. 그 벽이 낮아지니까 왕복이 줄어드는 건 맞습니다.

AX라는 말이 무슨 뜻인지 뒤져봤을 때도 비슷한 걸 느꼈었습니다. 바뀌는 단위가 회사라고 적혀 있는데 제가 실제로 본 변화는 전부 사람 한 명 단위였습니다. 도시 글은 그 한 명 단위 변화가 충분히 쌓이면 조직도를 아예 다시 그릴 수 있다는 얘기라서, 틀렸다고 하기는 어렵습니다.

그런데 읽으면서 계속 하나가 걸렸습니다.

조율이라는 말 안에 있는 두 가지

도시가 없앴다고 하는 건 조율입니다. 저는 회사에서 조율이라고 부르는 일 안에 성격이 아주 다른 두 가지가 섞여 있다고 봅니다.

하나는 핸드오프 비용이라고 부를 만한 겁니다. 기획자가 화면을 그려서 개발자한테 넘기고, 개발자가 디자인 수정을 요청하고, 디자이너가 다시 받아서 고치는 왕복. 회의록을 쓰고 티켓을 남기고 스펙 문서를 고치는 일. 정보가 사람에서 사람으로 건너갈 때 붙는 비용이고, 각자가 남의 영역을 직접 만질 수 없어서 생긴 겁니다. AI가 지금 실제로 없애고 있는 건 이쪽이 맞습니다.

다른 하나는 이해를 조정하는 비용입니다. 이건 정보가 느리게 가서 생기는 게 아니라 원하는 게 서로 다른 사람이 여럿이라서 생깁니다. 마케팅은 이번 분기에 내보내고 싶고, 개발은 부채를 갚고 싶고, 대표는 둘 다 원합니다. 세 사람이 같은 회의실에서 같은 자료를 실시간으로 보고 있어도 이 충돌은 그대로입니다. 정보가 모자라서 생긴 게 아니니까요.

도시 글은 이 둘을 하나로 묶고, 위계가 하던 일은 정보를 나르는 거였다고 정리한 다음, AI가 나르니까 위계가 필요 없다고 넘어갑니다. 앞의 절반은 맞는데 뒤의 절반이 따라오지 않는다는 느낌이었습니다.

두 팀이 같은 화면을 각자 손보고 있다고 생각해봤습니다. 둘 다 자기 AI랑 같이 작업해서 각자 다 만들었고 배포 요청이 같은 날 올라옵니다. 두 수정은 서로 충돌합니다. AI가 여기서 뭘 할 수 있을까요. 충돌이 있다는 건 알려줄 수 있고, 어느 쪽이 먼저 머지되면 무슨 문제가 생기는지도 알려줄 수 있고, 일정도 다시 짜줄 수 있습니다. 그런데 정작 필요한 건 누가 양보하느냐입니다. 이건 정보 문제가 아니라 권한 문제고, 답을 낸 사람이 나중에 그 답 때문에 욕을 먹어야 끝나는 종류의 일입니다. AI가 양보하라고 말할 수는 있겠지만, 양보한 쪽이 납득하지 않으면 그 결정은 오래 못 갑니다.

기획자가 AI랑 같이 만든 기능이 배포됐는데 새벽 세 시에 터졌다고 해도 비슷합니다. 만든 사람은 자고 있고, 깨워도 고칠 수 있을지 모릅니다. 만들 땐 AI가 옆에 있었으니 됐는데, 장애가 났을 때 로그를 읽고 원인을 좁히는 건 같은 일이 아니니까요. 결국 다른 누군가가 불려 나갑니다.

그 다른 누군가가 누구냐는 질문에 지금 회사들은 대체로 답을 갖고 있습니다. 온콜 순번표가 있고, 그 서비스를 맡은 개발자가 있습니다. 만드는 사람이 기획자까지 넓어져도 이 순번표가 같이 넓어지지는 않을 것 같습니다. 새벽에 깨는 쪽은 여전히 원래 개발자일 거고, 그 개발자 입장에서는 남이 만든 걸 대신 책임지는 일이 하나 늘어난 셈입니다. 이걸 조율이라고 불러야 할지는 잘 모르겠는데, 누군가는 이 순번표를 다시 짜야 하고 그 일은 정보 전달이 아닙니다.

이 차이가 제일 잘 보이는 게 회의인 것 같습니다. AI 도구가 들어오고 회의가 줄었냐고 물으면 대부분 아니라고 할 겁니다. 저도 안 줄었습니다. 생각해보면 이상한 일입니다. 회의가 정보 공유를 하려고 있는 거라면 지금쯤 확실히 줄었어야 합니다. 누가 뭘 하고 있는지, 어디까지 갔는지, 뭐가 막혔는지는 이제 안 물어봐도 볼 수 있으니까요.

그런데 안 줄어듭니다. 회의 시간의 상당 부분이 원래 정보 공유가 아니었던 겁니다. 실제로는 합의를 만드는 데 쓰이고 있었습니다. 다들 이미 아는 얘기를 한 시간 동안 다시 하는 건 몰라서가 아니라, 그 회의에 앉아서 반대 안 했다는 사실이 있어야 나중에 일이 진행되기 때문입니다. 비효율적으로 보이는데 대신할 방법이 마땅치 않습니다.

정보 공유용 회의는 확실히 줄고 있습니다. 주간 현황 공유 같은 건 문서 하나로 바뀌었거나 바뀌는 중이고요. 그런데 합의용 회의는 그대로고 오히려 늘어난 것도 있습니다. 각자 만들 수 있는 게 많아지니까 맞춰야 할 것도 같이 늘었습니다.

합의용 회의가 늘어나는 게 꼭 나쁜 신호인지는 저도 잘 모르겠습니다. 맞출 게 많다는 건 각자 할 수 있는 게 많아졌다는 뜻이기도 하니까요. 다만 그 회의를 누가 열고 누가 끝내느냐는 여전히 정해져 있어야 하는데, 지금은 그걸 원래 하던 사람이 그대로 하고 있는 것 같습니다. 도구가 바뀌어도 회의를 끝내는 사람은 안 바뀌었습니다.

만드는 권한은 빨리 퍼졌는데 고치는 책임은 안 퍼진 겁니다. AI 도입의 부작용이라기보다 둘이 퍼지는 속도가 달라서 생기는 일인데, 조직에서는 이쪽이 더 오래 갈 것 같습니다. 권한을 넓히는 건 도구를 주면 되지만 책임을 넓히는 건 사람이 그걸 받겠다고 해야 됩니다. 대부분은 안 받겠다고 합니다. 저라도 안 받을 것 같습니다.

사람이 없어서 대신 정해지던 것들

여기서 하나 더 들어가면, 저는 이쪽이 더 중요하다고 생각합니다.

지금까지 회사에서 이건 안 만든다는 결정은 대부분 누가 대놓고 내린 적이 없습니다. 그냥 사람이 없어서 못 했습니다. 하고 싶은 건 많은데 개발자가 셋이면 위에서 세 개만 고르게 되고 나머지는 알아서 빠집니다. 누가 이건 가치가 없으니 안 한다고 판단해서 뺀 게 아니라 손이 모자라서 빠진 겁니다. 리소스가 부족한 게 우선순위 결정을 대신 내려주고 있었던 거죠.

그게 좋은 방식이었다는 건 아닙니다. 오히려 나빴습니다. 정말 중요한 게 순서에서 밀리는 일이 늘 있었으니까요. 다만 브레이크 노릇은 했습니다. 아무도 결정하지 않아도 뭔가는 걸러졌습니다.

AI가 그 제약을 풉니다. 셋이서 열 개를 만들 수 있게 되면 지금까지 리소스가 대신 내려주던 결정을 사람이 직접 내려야 합니다. 할 수 있지만 안 한다고 말해야 하는 일이 처음으로 생기는 겁니다. 그래서 저는 결정할 일이 줄어드는 게 아니라 늘어날 거라고 봅니다. 만들 수 있는 게 많아질수록 안 만들기로 하는 판단이 더 자주 필요해지고, 그 판단은 누군가 책임을 지고 내려야 합니다.

만약 AI가 그 판단까지 해준다면 어떨까도 생각해 봤습니다. 열 개 중에 뭘 만들지 모델한테 골라달라고 하는 겁니다. 고르는 것 자체는 할 겁니다. 그런데 고른 다음에 빠진 일곱 개를 원하던 사람들한테 그 결과를 들고 가는 게 누구일지 생각하면 다시 처음으로 돌아옵니다. 손이 모자라서 빠졌을 때는 아무도 탓할 수가 없었는데, 누가 골라서 빠졌으면 탓할 대상이 생깁니다. 모델이 골랐다고 하면 그 탓은 모델을 쓰기로 한 사람한테 갑니다.

중간관리자가 하던 일 중에 일정 조율은 눈에 보이는 절반이고, 나머지 절반이 뭘 안 할지 정하고 그 결정을 지는 일인데 이쪽은 원래도 잘 안 보였습니다. 안 만들어진 건 기록에 안 남으니까요. 그래서 밖에서 보면 관리자가 회의만 하는 것처럼 보이기 쉬운 것 같습니다.

제 프로젝트는 오히려 반대쪽 얘기

여기서 제 얘기를 다시 해야 할 것 같습니다.

제 오디오북 프로젝트에서 조율 비용이 거의 0인 건 사실입니다. 그런데 그게 되는 이유가 AI가 유능해서는 아닌 것 같습니다. 이해관계자가 한 명이라서입니다.

요구사항을 내는 사람, 그걸 검수하는 사람, 우선순위를 정하는 사람, 잘못되면 책임지는 사람이 다 저입니다. 화요일에 정한 방향을 목요일에 바꿔도 아무한테도 설명할 필요가 없습니다. 기능 하나를 접기로 하면 그냥 접힙니다. 반대할 사람이 없으니까요. 조정할 상대가 처음부터 없습니다.

가끔은 이게 좋기만 한 건지 모르겠다는 생각도 듭니다. 반대할 사람이 없다는 건 제가 틀렸을 때 말려줄 사람도 없다는 뜻이라서요. 목요일에 방향을 바꾼 게 잘한 건지 화요일 판단이 맞았던 건지는 저 혼자 정하고 저 혼자 넘어갑니다. 회사에서 조율 비용이라고 부르는 것 중 일부는 이렇게 누가 한 번 더 물어봐 주는 값이었을 수도 있습니다.

그러니까 제 프로젝트가 보여주는 건 AI가 있으면 조율이 필요 없다가 아니라 이해관계자가 한 명이면 조율이 필요 없다는 겁니다. 뒤쪽 문장은 AI가 나오기 전에도 맞는 말이었습니다. 혼자서 사이드 프로젝트를 여러 개 해보면서 느낀 것도 이쪽에 가까웠습니다. 빨라진 건 맞는데 왜 빨라졌는지를 제가 제대로 짚고 있었는지는 좀 다른 문제였습니다.

회사에서 같은 걸 하려면 AI를 들이는 것만으로는 부족하고, 팀마다 여기까지는 혼자 결정한다는 권한 경계를 새로 그어야 합니다. 그런데 보통은 그 권한 쪽은 손대지 않고 직군 경계만 허무는 식으로 갑니다. 기획자가 코드를 짜고 개발자가 디자인을 고치기 시작하는데 승인은 여전히 예전 라인으로 올라갑니다.

그러면 관리자가 사라지는 게 아니라 다들 남의 영역까지 만들어놓고 결재는 그대로 받는 상태가 됩니다. 조율할 건 오히려 늘어납니다. 예전에는 화면 하나를 두고 결정할 사람이 한 명이었는데 이제는 세 명이 각자 만들어서 결재판에 올리니까요. 핸드오프 비용은 줄었는데 이해 조정 비용은 늘어난 겁니다.

블록의 새 조직도

재미있는 건 도시가 실제로 짠 조직에 이 얘기가 벌써 들어 있다는 겁니다.

블록이 남긴 역할은 셋이라고 합니다. 깊은 전문성을 가진 개별 기여자는 관리자가 아니라 모델한테서 맥락을 받아서 지시를 기다리지 않고 결정합니다. DRI라는 역할은 여러 영역에 걸친 특정 문제를 맡고 모델에서 자원을 끌어올 권한을 가집니다. 마지막이 플레이어 코치인데, 기존 관리자를 대신하는 역할이고 현장에서 계속 손을 쓰면서 사람을 키운다고 되어 있습니다. 도시와 보타는 영구적인 중간관리 계층은 필요 없고 옛 위계가 하던 나머지 전부는 시스템이 조율한다고 썼습니다.

저는 나머지 전부라는 말이 걸렸습니다. 그 사람들 스스로도 전부라고는 안 했거든요. 기예와 사람 키우는 일은 빼놨고, 그게 플레이어 코치입니다. 위계가 하던 일 중에 적어도 한 덩어리는 사람한테 남겨야 한다는 걸 이미 인정한 겁니다.

플레이어 코치라는 이름을 한참 들여다봤는데 볼수록 묘했습니다. 현장에서 계속 손을 쓰면서 사람을 키우는 사람. 이거 그냥 좋은 관리자 아닌가 싶었습니다. 제가 만난 괜찮은 팀장들이 대체로 그랬습니다. 코드를 읽을 줄 알았고, 판단이 필요할 때 판단했고, 아래 사람이 자기보다 잘하게 되는 걸 막지 않았습니다.

그렇게 보면 도시가 없앤 건 관리 계층이라기보다 일을 모르면서 전달만 하던 관리자 쪽인 것 같습니다. 그건 없애는 게 맞다고 생각합니다. 그런데 그건 조직 구조 문제라기보다 그 역할에 누굴 앉혔느냐의 문제입니다. 원래 있으면 안 되는 역할이 있었던 거지 관리라는 일 자체가 필요 없어진 건 아닙니다.

전달만 하던 관리자가 왜 생겼는지도 가끔 궁금합니다. 처음부터 그런 사람을 뽑지는 않았을 텐데, 일을 잘하던 사람이 관리자가 되고 나서 일에서 손을 떼다 보면 어느새 전달만 하게 되는 경우가 많지 않을까 싶습니다. 그렇다면 플레이어 코치라는 이름은 손을 떼지 말라는 주문에 가깝고, 그 주문이 지켜질지는 이름만으로는 알 수 없는 일입니다. 몇 년 지나서 플레이어 코치들이 다시 전달만 하고 있으면, 그건 사람 문제가 아니라 그 역할이 원래 그쪽으로 흘러가게 생긴 거라고 봐야 할 것 같습니다.

이 둘을 섞으면 이상한 데로 갑니다. 전달만 하던 사람이 필요 없어진 걸 보고 관리가 필요 없어졌다고 읽으면 판단하고 책임지던 사람까지 같이 정리됩니다. 그 사람들이 하던 일은 없어지지 않고 남은 사람들한테 흩어지고, 흩어지면 누구 일인지 흐려지고, 결국 아무도 안 하게 됩니다.

사람 키우는 일도 따로 떼어놓으면 잘 안 돌아갑니다. 키우는 일과 평가하는 일은 붙어 있습니다. 평가 권한이 없는 육성은 조언이지 육성이 아니라고 봅니다. 제가 옆에서 아무리 잘 봐줘도 그 사람 승진에 제 의견이 안 들어가면, 몇 달 지나서 그 사람은 저 말고 다른 데를 봅니다. 당연한 일입니다.

그리고 평가야말로 이해 조정이 제일 비싸게 드는 일입니다. 성과 데이터를 모으는 건 모델이 사람보다 훨씬 잘할 겁니다. 누가 뭘 했는지, 어떤 결정이 어디로 이어졌는지 다 남아 있으니까요. 그런데 승진 티오가 하나인데 후보가 둘이면, 그 데이터로 한 명을 고르는 건 데이터를 모으는 것과 전혀 다른 일입니다.

모델이 A의 기여가 더 크다고 했다고 해봅시다. B가 그걸 받아들일까요. 안 받아들이면 B는 나갑니다. 사람이 그 말을 했을 때랑 다른 게 하나 있는데, 따질 상대가 있느냐입니다. 사람이 정했으면 B는 적어도 그 사람을 찾아가서 왜 그랬냐고 물어볼 수 있고, 답이 시원찮으면 화라도 낼 수 있습니다. 모델이 정했으면 그럴 상대가 없습니다.

따질 상대가 있다는 게 별것 아닌 것 같아도, 사람이 남느냐 나가느냐는 꽤 이런 데서 정해지는 것 같습니다. 결과에 동의하지 않아도 그 결과를 낸 사람과 얘기를 해봤다는 게 있으면 좀 버틸 수 있습니다. 모델한테 왜 그랬냐고 물으면 설명은 나오겠지만, 그 설명은 B가 듣고 싶은 종류의 대답이 아닐 것 같습니다. B가 원하는 건 이유라기보다 자기 얘기를 누가 들어줬다는 사실일 테니까요.

제가 보기에 진짜로 안 없어지는 건 육성보다 이해 조정이랑 책임 쪽인데, 그건 세 역할 어디에도 안 적혀 있습니다. DRI가 가진 건 모델에서 자원을 끌어올 권한인데, 그건 모델을 상대로 한 권한이지 사람 사이 우선순위 충돌을 정리하는 권한은 아닙니다. 두 DRI가 같은 자원을 원하면 어떻게 되는지는 없었습니다.

카를로 토르니아이라는 사람이 같은 데를 짚은 글이 있어서 반가웠습니다. 질문 두 개가 정확했습니다. 모델의 우선순위가 엉뚱한 데로 흘러갈 때 누가 그걸 들여다보느냐, 그리고 DRI가 정식 에스컬레이션 경로 없이 시스템 권고에 어떻게 이의를 제기하느냐.

에스컬레이션 경로라는 게 결국 위계의 다른 이름이라고 생각합니다. 위로 올릴 데가 있다는 건 결정을 바꿀 수 있는 사람이 위에 있다는 뜻이고요. 그걸 없애면서 다른 걸 안 만들면 시스템 권고가 사실상 최종 결정이 됩니다. AI가 관리자를 대신하는 게 아니라 AI가 반론할 수 없는 관리자가 되는 쪽에 가깝습니다. 감시 장치를 잔뜩 걸어두고도 그게 한 번도 안 울린 걸 나중에 알았을 때랑 비슷하다는 생각이 들었습니다. 장치는 있는데 그 장치를 아무도 검사하지 않는 겁니다.

같은 글에서 문화 쪽 얘기도 했는데 이것도 수긍이 갔습니다. 위계는 정보만 나른 게 아니라 예측 가능성이랑 지위랑 소속감을 같이 만들어왔다는 겁니다. 그걸 없애면서 다른 걸 안 세우면 빈자리가 생기는데, 그 빈자리는 조직도에는 안 보여도 사람들은 확실히 느낍니다.

예측 가능성이라는 말이 특히 와닿았습니다. 위계가 있으면 적어도 내 일을 누가 보고 누가 결정할지는 압니다. 그 사람이 마음에 안 들어도 알기는 합니다. 시스템이 조율한다고 하면, 내 일이 어떤 기준으로 밀리고 당겨지는지를 매번 화면을 열어봐야 알게 될 것 같습니다. 정보는 더 많아지는데 마음은 덜 놓이는 상태요. 제가 그런 조직에 있다면 아마 그쪽이 더 피곤할 것 같습니다.

숫자는 아직 별말이 없습니다

블록 실적은 감원 뒤에 좋아졌습니다. 그걸 보고 봐라, 되지 않느냐고 하는 글도 벌써 많습니다. 그런데 저는 이 숫자로는 아무것도 확인이 안 된다고 봅니다. 같은 기간에 캐시앱이랑 스퀘어 쪽 사업이 원래 잘되고 있었고, 그건 2월 발표 전부터 그랬습니다. 감원도 2분기 말까지 이어지게 잡혀 있어서 언제부터의 효과인지 자르기도 어렵습니다. 블록이 내놓은 건 엔지니어 한 명당 코드 변경이 두 배 넘게 늘었다는 내부 지표 정도인데, 회사가 고른 지표고 비교할 대상이 없습니다.

반대쪽 얘기도 있었습니다. CEO들이 AI 때문이라고 한 감원 중 상당수가 사실은 팬데믹 때 너무 많이 뽑은 걸 되돌린 거라는 분석이 있었고, 이번 감원도 대부분은 AI 때문이 아닐 거라는 애널리스트 말도 있었습니다. 블록 안에서 일하는 사람들 얘기로는 AI가 만든 코드 변경 대부분을 아직 사람이 손봐야 하고, 은행이나 송금처럼 규제가 걸린 일은 AI가 주도할 수 없다고 했습니다. 밖에서는 조직도가 바뀌었다고 읽는데 안에서는 아직 그 단계가 아닌 겁니다.

하나 더 걸리는 게 있습니다. 도시는 일 년 안에 대부분 회사가 비슷하게 바뀔 거라고 했는데, 그가 그 결정을 내릴 수 있었던 조건을 같이 봐야 할 것 같습니다. 블록에서 사천 명을 줄이는 건 도시가 하겠다고 하면 끝나는 결정이었습니다. 창업자고, 지분 구조도 그렇고, 밖에서 뭐라고 해도 밀고 갈 수 있는 위치입니다. 이사회를 설득하고 부문장들 반발을 달래고 노조랑 협의해야 하는 회사였다면 같은 결정이 같은 속도로는 못 나왔을 겁니다. 나왔더라도 모양이 달랐겠고요.

그러니까 이건 이해 조정이 거의 필요 없는 조건에서 이해 조정이 필요 없다는 걸 보여준 실험에 가깝다고 봅니다. 규모만 다르지 결정하는 사람이 한 명이라는 점에서 제 사이드 프로젝트랑 똑같습니다. 그런 데서 나온 결과를 결정권이 여러 갈래로 나뉜 회사에 그대로 가져가면, 가져가지는 건 결론뿐이고 그 결론을 가능하게 했던 조건은 안 따라옵니다.

만약 제 회사로 이 결론만 들어온다면 어떻게 읽힐지도 생각해 봤습니다. 아마 인원을 줄이자는 얘기로 먼저 읽힐 것 같습니다. 결정하는 사람이 한 명이라는 조건까지 같이 가져오려면 지금 결재 구조를 거의 다 바꿔야 하는데, 그건 아무도 먼저 꺼내고 싶어 하지 않는 얘기입니다. 그래서 결론 쪽만 남고 조건 쪽은 조용히 빠질 가능성이 높아 보입니다.

유럽 쪽 얘기를 짚은 분석도 있었는데, 협의 절차랑 기간이 법으로 정해져 있는 곳에서는 이 모델이 처음부터 안 맞는다는 겁니다. 제도가 이해 조정을 억지로 붙여놓은 셈인데, 그걸 비효율로 볼 수도 있지만 거꾸로 보면 그 절차가 원래 무슨 일을 하고 있었는지가 거기서 보입니다.

이런 실험은 원래 결론이 나오려면 몇 년이 걸립니다. 지금 나와 있는 건 시작할 때 한 선언뿐인데 그게 벌써 성공 사례로 인용되고 있습니다. 다른 회사 경영진이 이걸 보고 블록도 했다는데로 말을 시작하면, 검증 안 된 가설이 근거 자료로 한 단계 올라갑니다. 그리고 그런 일이 실제로 일어나고 있는 것 같습니다. 제 회사에도 그 얘기가 왔으니까요.

그 질문이 내려온 길

중간관리 계층을 줄이자는 얘기가 어떻게 저한테까지 왔는지 다시 생각해봤습니다. 경영진이 밖에서 사례를 봤고, 그게 위에서 정리됐고, 한 단계 아래로 내려왔고, 거기서 다시 각 팀에 질문으로 내려왔습니다. 도시가 없애야 한다고 한 바로 그 길입니다. 맥락을 모으고, 메시지를 전달하고, 다들 같은 쪽을 보게 맞추는 그 일이요.

저는 이게 우연은 아니라고 봅니다. 문제가 정말 정보 전달뿐이었다면 이 얘기는 전사 공지 하나로 다 같이 받았어야 합니다. 요즘은 그게 전혀 어렵지 않습니다. 그런데 실제로는 단계를 밟아서 내려왔고, 단계마다 말의 모양이 조금씩 바뀌었습니다. 위에서는 이 방향으로 간다였던 게 아래로 오면서 이렇게 가야 하지 않겠냐는 질문이 됐습니다.

왜 질문으로 바뀌었을까 생각해보면, 그 중간에서 누군가 반발을 예상했던 것 같습니다. 그대로 지시로 내리면 팀들이 어떻게 반응할지 알고 있었던 거죠. 그래서 물어보는 모양으로 바꿔서 팀장들이 스스로 동의한 것처럼 만들려고 한 게 아닐까 싶습니다.

그게 꼭 나쁜 일이라고는 생각하지 않습니다. 물어보는 모양으로 바뀐 덕분에 저도 이렇게 생각을 적어볼 틈이 생겼으니까요. 지시로 왔으면 따르거나 버티거나 둘 중 하나였을 겁니다.

저한테는 그게 바로 이해 조정입니다. 정보를 나르는 게 아니라 같은 정보를 받을 사람들이 지금 어떤 상태인지 알고 거기에 맞게 말의 모양을 바꾸는 일이요. 그리고 그 일을 한 사람은 바로 이 얘기가 없애자고 하는 그 계층에 있었습니다.

모델한테 이걸 시킬 수 있을까요. 문장은 만들 겁니다. 팀마다 사정을 넣어주면 톤도 맞춰줄 거고요. 다른 건 그렇게 나온 말을 팀장들이 어떻게 받아들이느냐입니다. 사람이 하면 그 사람이 나중에 결과를 같이 집니다. 이 방향으로 갔다가 잘못되면 그 말을 전한 사람도 같이 엮입니다. 그래서 받는 쪽도 그 말을 무겁게 듣습니다. 모델이 보낸 메시지에는 그게 없습니다.

만약 모델이 쓴 메시지에 누군가 자기 이름을 걸고 내보낸다면 얘기가 좀 달라질 수는 있습니다. 그런데 그러면 이름을 건 그 사람이 결국 중간관리자가 하던 일을 하고 있는 거라서, 없앤 줄 알았던 역할이 다른 이름으로 돌아오는 셈입니다. 문장을 누가 썼느냐보다 그 문장 뒤에 누가 서 있느냐가 중요한 것 같습니다. 받는 쪽은 문장보다 그 뒤에 선 사람을 보고 무게를 잽니다. 그 사람이 없으면 문장은 그냥 공지가 됩니다. 공지는 읽고 넘기면 그만이라, 동의를 얻으려던 말이 공지가 되면 원래 하려던 일을 못 합니다. 그래서 그 말을 누가 전하느냐가 생각보다 큰 문제 같습니다.

저는 이게 AI가 못 하는 일이라기보다 AI한테 맡기면 안 되는 일에 가깝다고 봅니다. 둘은 같은 말이 아닙니다. 코드는 AI가 충분히 쓸 수 있는데, 그 코드가 나간 다음에 생기는 일은 사람이 집니다. 설계는 내가 했는데 결과물은 AI가 만든 상태를 몇 달 겪으면서 계속 걸렸던 것도 이거였습니다. 결과물만 보면 누가 만들었는지 구분이 안 되는데, 문제가 생기면 불려 나가는 건 여전히 저였습니다.

AX라는 말을 요즘 많이 쓰는데, 저는 그게 사람이 AI가 못 하는 것만 한다는 것보다는 사람이 책임질 수 있는 것만 한다는 쪽에 가깝다고 봅니다. 비슷해 보이는데 조직으로 옮겨보면 꽤 다릅니다. 앞쪽으로 가면 AI가 좋아질 때마다 사람 일자리가 줄어듭니다. 뒤쪽으로 가면 AI가 좋아져도 책임지는 구조는 그대로고, 만들 수 있는 게 많아진 만큼 결정할 게 오히려 늘어납니다. 조직이 AI 대응으로 바뀔 때마다 신입 일자리가 먼저 없어지는 것도 앞쪽으로 읽은 결과가 아닌가 싶습니다.

직군 경계가 흐려지는 건 계속 갈 것 같습니다. 이미 가고 있고 저도 그렇게 일하고 있으니 반대할 이유는 없습니다. 다만 그게 관리 계층이 없어진다는 데로 바로 이어지지는 않는 것 같습니다. 없어지는 건 사람 사이를 오가던 전달 쪽이고, 남는 건 결정하고 그 결정을 지는 쪽인데, 지금 나오는 얘기들은 대체로 앞쪽만 보고 뒤쪽까지 같이 없애려는 것처럼 보입니다.

예전에 회사에서 AI 에이전트가 열렸을 때 같은 도구를 받고도 결과가 달랐던 건 기록이 있느냐 없느냐 때문이었는데, 이번 것도 비슷할 것 같습니다. 도구가 아니라 도구를 받을 쪽이 준비가 돼 있느냐요. 권한 경계를 다시 안 긋고 도구만 넣으면 만들어지는 물건만 늘고 결재 줄은 그대로일 겁니다.

물어보고 싶은 게 하나 있긴 합니다. 이 방향으로 가면 결재 라인도 같이 바뀌는 거냐고요. 각자 만드는 범위는 넓히면서 승인 절차는 그대로 두면 앞에서 쓴 그 상태가 됩니다. 이 질문에 어떤 답이 오는지를 보면 이번 얘기가 일하는 방식을 바꾸자는 건지, 인원 얘기를 꺼내려는 준비인지도 어느 정도 보일 것 같습니다.

팀에서 의견을 물어왔을 때 뭐라고 할지는 아직 못 정했습니다. 방향에 동의한다고 하면 그다음에 나올 얘기가 인원 얘기일 것 같아서요. 이건 조금 더 봐야 할 것 같습니다.

댓글

이 블로그의 인기 게시물

봉제인형 사진 한 장, ChatGPT와 Gemini의 다른 대답

AI 부업으로 3개월에 2달러 벌고 50달러를 썼다는 증언을 봤습니다. 그 위에 광고가 네 겹입니다

구글은 서울에서 모델이 아니라 에이전트를 판다