{"title":"AI가 줄여야 할 것은 인원수가 아니라 팀 크기다","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/ai-small-teams-not-headcount/","section":"posts","date":"2026-07-02T12:03:10+09:00","lastmod":"2026-07-02T12:03:10+09:00","description":"Miguel Carranza의 글을 바탕으로, AI 시대에 회사가 사람을 덜 뽑는 대신 더 작은 팀을 더 많이 만들어야 하는 이유를 정리한다.","summary":"AI가 조직을 바꾼다는 말은 자주 인원 감축 이야기로 흘러갑니다. Miguel Carranza의 글은 방향을 다르게 잡습니다. 핵심은 사람을 덜 뽑자는 것이 아니라, 팀을 작게 쪼개 새로 합류한 사람이 더 많은 회의가 아니라 더 많은 병렬성을 만들게 하자는 주장입니다.\n원문: AI shouldn\u0026rsquo;t shrink headcount. It should shrink teams\nSmall Teams 핵심 정리 핵심 주장: AI의 조직 효과는 인원 감축보다 팀 크기 축소에 있다. 작은 팀은 결정권과 책임 소재가 뚜렷하다. 병목 이동: AI가 첫 구현과 낯선 코드 검토 비용을 낮추면, 중요한 일은 \u0026ldquo;코드를 누가 쓰는가\u0026quot;보다 \u0026ldquo;무엇을 만들고 언제 멈출지 판단하는가\u0026quot;가 된다. RevenueCat 사례: OCTO는 신뢰 높은 시니어 IC들이 새 베팅과 중요 프로젝트를 빠르게 검증하는 작은 조직 실험이었다. 제품팀 적용: 1~3명 엔지니어, 공유 PM·디자인, 명확한 Tech Lead 구조로 팀 수를 늘리고 회의 규모를 줄였다. 주의점: 작은 팀은 중복과 용량 리스크가 크다. 그래서 매니저는 모든 팀에 같은 시간을 쓰기보다 막힌 곳에 깊게 들어가야 한다. 1) AI는 채용 논리를 없애지 않고 팀 토폴로지를 바꾼다 Carranza가 먼저 선을 긋는 지점은 중요합니다. 작은 팀은 \u0026ldquo;AI가 있으니 사람을 덜 뽑자\u0026quot;는 말이 아닙니다. 오히려 채용이 늘어날 때 그 사람이 더 큰 회의에 흡수되지 않고, 새로운 실행 단위를 만들게 하자는 말입니다.\n","content":"AI가 조직을 바꾼다는 말은 자주 인원 감축 이야기로 흘러갑니다. Miguel Carranza의 글은 방향을 다르게 잡습니다. 핵심은 사람을 덜 뽑자는 것이 아니라, 팀을 작게 쪼개 새로 합류한 사람이 더 많은 회의가 아니라 더 많은 병렬성을 만들게 하자는 주장입니다.\n원문: AI shouldn\u0026rsquo;t shrink headcount. It should shrink teams\nSmall Teams 핵심 정리 핵심 주장: AI의 조직 효과는 인원 감축보다 팀 크기 축소에 있다. 작은 팀은 결정권과 책임 소재가 뚜렷하다. 병목 이동: AI가 첫 구현과 낯선 코드 검토 비용을 낮추면, 중요한 일은 \u0026ldquo;코드를 누가 쓰는가\u0026quot;보다 \u0026ldquo;무엇을 만들고 언제 멈출지 판단하는가\u0026quot;가 된다. RevenueCat 사례: OCTO는 신뢰 높은 시니어 IC들이 새 베팅과 중요 프로젝트를 빠르게 검증하는 작은 조직 실험이었다. 제품팀 적용: 1~3명 엔지니어, 공유 PM·디자인, 명확한 Tech Lead 구조로 팀 수를 늘리고 회의 규모를 줄였다. 주의점: 작은 팀은 중복과 용량 리스크가 크다. 그래서 매니저는 모든 팀에 같은 시간을 쓰기보다 막힌 곳에 깊게 들어가야 한다. 1) AI는 채용 논리를 없애지 않고 팀 토폴로지를 바꾼다 Carranza가 먼저 선을 긋는 지점은 중요합니다. 작은 팀은 \u0026ldquo;AI가 있으니 사람을 덜 뽑자\u0026quot;는 말이 아닙니다. 오히려 채용이 늘어날 때 그 사람이 더 큰 회의에 흡수되지 않고, 새로운 실행 단위를 만들게 하자는 말입니다.\n초기 스타트업은 자연스럽게 이렇게 움직입니다. 한 사람이 전체 기능을 잡고, 버그는 하루 만에 고치고, 기능은 일주일 안에 나갑니다. 회사가 커지면 속도가 느려지는 일은 어느 정도 당연합니다. 고객이 늘고, 표면적이 넓어지고, 리스크도 커지기 때문입니다.\n하지만 모든 느림이 성숙의 증거는 아닙니다. 어떤 느림은 단지 조직 무게가 일상이 된 결과입니다. AI는 이 무게를 다시 의심하게 만듭니다.\n2) 코드 작성이 싸지면 동의 비용이 더 비싸진다 예전에는 큰 제품 영역을 맡기려면 백엔드 몇 명, 프론트엔드 몇 명, PM, EM, 디자이너가 붙는 구조가 자연스러웠습니다. 코드 작성이 병목이고, 낯선 영역을 리뷰하는 비용도 컸기 때문입니다.\nAI는 이 균형을 흔듭니다. 첫 버전 작성 비용이 낮아지고, 익숙하지 않은 코드베이스를 파악하는 일도 쉬워집니다. 그러면 병목은 구현 자체에서 다음 질문들로 이동합니다.\n이 일을 만들 가치가 있는가? 지금 충분히 검증했는가? 이 결정의 책임자는 누구인가? 언제 멈추거나 버릴 수 있는가? 그래서 모든 의미 있는 작업마다 각 전문 분야의 여러 명이 동의할 필요는 줄어듭니다. 여전히 AI가 만든 그럴듯한 헛소리를 걸러낼 사람은 필요합니다. 다만 그 사람이 반드시 큰 회의실 안에 여럿일 필요는 없습니다.\n3) OCTO가 보여준 작은 팀의 조건 RevenueCat에서 먼저 검증된 모델은 OCTO, 즉 Office of the CTO였습니다. 신뢰 높은 시니어 IC 몇 명에게 새 베팅과 중요 프로젝트를 맡기고, 큰 조직을 만들기 전에 빠르게 학습하게 한 구조입니다.\n새로운 베팅의 초반에는 코드보다 판단이 더 중요합니다. 기술 선택을 빠르게 해야 하고, MVP에 애착을 갖지 않아야 하며, 사업적으로 틀렸다면 만든 코드도 버릴 수 있어야 합니다. Carranza는 여기서 어려운 일이 코드를 쓰는 것이 아니라, 버려야 할 때 버리는 성숙함이라고 봅니다.\nOCTO가 잘 작동한 이유는 작고, 시니어하고, 신뢰가 높았기 때문입니다. 숨을 곳이 없고, 정렬을 연기처럼 보여줄 필요도 없습니다. 일이 막히면 바로 드러나고, 베팅이 틀리면 더 빨리 알게 됩니다.\n4) 제품팀으로 확장한 방식 RevenueCat은 이 방식을 새 베팅에만 쓰지 않고 제품팀에도 적용했습니다. 여러 미션을 한 조직과 한 회의 구조 안에 묶어두던 팀을 쪼갰고, 결과적으로 제품팀 수를 두 배 이상으로 늘렸습니다.\n기본 모델은 단순합니다.\n엔지니어 1~3명 필요하면 공유 PM 또는 디자이너 명확한 엔지니어링 DRI인 Tech Lead 사람 관리, 채용, 코칭, 성과, 팀 건강을 맡는 매니저 Tech Lead는 일을 앞으로 밀고, 리스크를 빨리 올리고, 다른 팀과의 인터페이스가 됩니다. 두 작은 팀이 조율해야 할 때는 16명이 모이는 회의 대신 Tech Lead 몇 명이 이야기하면 됩니다.\n이 구조는 미래 리더를 찾는 낮은 리스크의 방법이기도 합니다. 사람 관리 책임 없이도 의사결정, 결과 소유, 조율 경험을 줄 수 있기 때문입니다.\n5) 작은 팀의 비용도 작지 않다 작은 팀은 만능 해법이 아닙니다. 가장 큰 비용은 중복과 용량 리스크입니다. 두 명짜리 팀에서 한 명이 육아휴직, 휴가, 장애 대응으로 빠지면 팀 용량의 절반이 사라집니다.\n또한 작은 팀은 IC에게 더 많은 리더십을 요구합니다. 누군가는 결정을 내리고, 명확히 커뮤니케이션하고, 허락을 기다리지 않고 일을 움직여야 합니다. 모든 사람이 바로 그 역할에 맞는 것은 아닙니다.\n팀이 많아지면 파편화도 생깁니다. 같은 일을 중복하거나 제품 일관성이 흔들릴 수 있습니다. 그래서 Tech Lead의 역할이 중요합니다. 해법은 큰 회의로 돌아가는 것이 아니라, 올바른 사람들끼리 더 좋은 조율 구조를 만드는 것입니다.\n6) 매니저의 일은 균등 배분이 아니라 주의력 배분이다 작은 팀을 여러 개 맡는 EM은 모든 팀에 같은 시간을 쓸 수 없고, 그래야 할 필요도 없습니다. 매주 잘 출시하는 건강한 팀과 막힌 팀은 같은 관리 밀도를 요구하지 않습니다.\n매니저의 일은 주의력을 가장 수익이 높은 곳에 배분하는 쪽으로 바뀝니다.\n막힌 팀에는 깊게 들어간다. 준비가 덜 된 Tech Lead를 코칭한다. 휴가나 육아휴직으로 계획이 깨지면 재배치한다. 잘 굴러가는 팀은 사실이 바뀔 때까지 자율성을 준다. 1:1도 고정 주기만이 정답은 아닙니다. 어떤 사람은 매주 필요하고, 어떤 사람은 격주로 충분하며, 신뢰 높은 팀은 Tech Lead를 통해 상태를 확인해도 됩니다.\n결론 및 시사점 Carranza의 주장은 AI 시대 조직 설계의 좋은 기준선을 줍니다. AI가 코드 작성 비용을 낮춘다면, 회사는 사람을 줄이는 상상보다 조율 비용을 줄이는 구조를 먼저 봐야 합니다.\n작은 팀은 빠른 결정, 명확한 소유권, 눈에 보이는 성과를 만듭니다. 대신 작은 팀이 작동하려면 강한 IC, 선명한 Tech Lead, 막힌 곳을 알아보는 매니저, 그리고 팀 간 조율을 위한 얇지만 단단한 연결이 필요합니다.\n한 줄 결론: AI 시대의 좋은 조직은 사람을 덜 쓰는 조직이 아니라, 더 작은 책임 단위로 더 많은 일을 동시에 배울 수 있는 조직이다.\n관련 포스트 에이전틱 엔지니어링 매니지먼트 — EM 역할에 에이전트를 적용하면 무엇이 보이는가 Modern Engineering Values — AI 시대, 코딩이 병목이 아닐 때 엔지니어에게 남은 것 Software is becoming marketing - 소프트웨어 풍요 시대의 제품과 일자리 ","wordCount":843,"tags":["AI","조직설계","엔지니어링매니지먼트","스타트업","RevenueCat"],"categories":["AI","Engineering"],"frameworks":["Small Teams","Organizational Design","Strong Ownership"],"mental_models":["Coordination Cost","DRI","Span of Attention"],"philosophy_type":"engineering-management","schema_type":"Article","actionable":true,"priority":"medium","key_points":["AI 시대의 목표는 인원 감축이 아니라, 같은 사람으로 더 많은 병렬 작업을 가능하게 하는 작은 팀 구조다.","코드 작성 비용이 낮아질수록 병목은 구현에서 판단, 검토, 소유권, 조율로 이동한다.","RevenueCat은 OCTO라는 작고 신뢰 높은 시니어 IC 그룹에서 배운 방식을 제품팀으로 확장했다.","1~3명 엔지니어와 Tech Lead 중심 구조는 속도와 책임 소재를 선명하게 만들지만, 휴가·육아휴직·장애 대응 때 용량 손실이 크다."],"related":["posts/agentic-engineering-management","posts/modern-engineering-values","posts/software-is-becoming-marketing"]}