엔지니어링 조직을 키우려고 할 때, 많은 리더는 반사적으로 "채용을 늘린다"라고 생각한다. 하지만 사람을 추가하면 추가할수록, 조정 (Coordination) 비용이 불어나며, 늘어난 인원만큼의 성과가 나오지 않는 경우가 있다. Ido Green의 기사 「Ownership over hiring」은 스케일의 본질은 머릿수가 아니라 **오너십 (Ownership, 누가 무엇에 책임을 지는가)**을 넓히는 것이다, 라고 논하고 있다.

테크 리드 (Tech Lead)나 매니저라면 한 번쯤 당사자가 될 만한 이야기이며, 게다가 생성형 AI (Generative AI)로 코드를 저렴하게 만들 수 있게 된 지금이야말로 유효한 관점이기도 하다. 이하, 원문 기사의 주장을 나름대로 정리하여 소개한다. 원문은 여기: https://greenido.dev/2026/06/11/what-changes-at-20-50-and-200-engineers/

기사의 핵심에 있는 것은, 성장 각 단계에서 "새로운 조정세 (Coordination tax)"가 발생한다는 관점이다. 사람이 늘어날수록 누군가와 누군가가 이야기를 맞춰야 할 필요가 늘어나고, 그 수고가 조직의 성장 속도를 앞지르기 시작하면 스케일은 오히려 감속한다.

Green이 강조하는 것은 프로세스나 툴, 조직도 그 자체보다, 오너십의 명확성이 결정적인 요인이 된다는 점이다. 엔지니어가 "나는 무엇을 소유하고 있는가, 왜 그것을 소유하는가, 그것이 고장 났을 때 어떤 일이 일어나는가"를 이해하고 있는 상태. 이것이 있느냐 없느냐에 따라 같은 인원이라도 조직의 강함이 달라진다.

여기서 흥미로운 점은, 규모가 작을 때는 "다소의 중복 (Overlap)을 허용하는 것이, 새로운 조직의 경계선과 그에 따른 조정 비용을 만드는 것보다 저렴하다"라는 지적이다. 깔끔하게 분업하는 것이 항상 정답은 아니다. 경계를 긋는 것 자체에 비용이 들기 때문이다.

또 다른 축은 생성형 AI와의 관계다. Green의 입장은 명확하다. AI에 의해 코드 생성은 거의 공짜가 되었지만, 그것은 오히려 오너십의 중요성을 높인다.

코드가 저렴하게 대량으로 나올수록, 리뷰하고, 유지보수하며, 아키텍처 (Architecture)의 일관성을 유지하는 업무의 비중이 늘어나기 때문이다. "코드를 생성하는 것은 이제 저렴하다. 명확한 오너십을 만드는 것은 여전히 비싸다"라는 문장이 기사 전체를 관통하고 있다.

기사는 조직 규모를 3가지 분기점으로 나누어, 각각 무엇이 병목 (Bottleneck)이 되는지를 묘사한다.

20명 규모
프로세스는 최소한이면 된다. 엔지니어는 고객과 직접 소통하고, 팀은 서비스를 엔드 투 엔드 (End-to-End)로 소유하며, 온콜 (On-call, 장애 대응 당번)까지 맡는다. 이 단계에서는 공통 기반을 만드는 "플랫폼 팀 (Platform Team)"은 시기상조인 경우가 많다고 Green은 말한다. 아직 추상화해야 할 공통 항목이 굳어지지 않았는데 기반을 만들면, 오히려 발목을 잡게 된다.

50명 규모
지금까지 암묵적으로 성립되었던 커뮤니케이션이 의도적인 노력 없이는 돌아가지 않게 된다. 프로세스가 필요해지지만, 여기서 "성숙한 회사처럼 보이고 싶다"라는 동기로 프로세스를 도입하면 형식적인 (Performative) 것이 되기 쉽다.

이 규모에서 새로운 병목이 되는 것은 코드를 쓰는 것이 아니라 **코드 리뷰 (Code Review)**다. 논점은 "얼마나 많이 만들 수 있는가"에서 "그 변경 사항을 얼마나 자신 있게 내보낼 수 있는가"로 옮겨간다.

200명 규모
리더의 업무가 "개발을 관리하는 것"에서 "팀의 집합체라는 계 (System)를 관리하는 것"으로 바뀐다. 거점이나 타임존 (Timezone)을 가로질러 조정 비용이 복리로 불어난다.

이 규모가 되어서야 비로소 플랫폼 팀이 경제적 의미를 갖는다. 기사는 대략 80~100명을 넘어가는 시점을 기준으로 제시하고 있다. 그리고 상장 후에는 외부를 향한 설명 책임이 더해져, 속도와 예측 가능성을 동시에 최적화하는 것이 요구된다. 스타트업적인 기동력과 구조의 양립이라는 난제다.

기사에서 추출할 수 있는, 현장에서 사용할 수 있는 지침을 정리해 둔다.

프로세스는 "증상"으로 취급하라. 새로운 절차를 제안할 때는 반드시 "이것은 어떤 문제를 해결하는가"라고 물어야 한다. 프로세스는 현실의 문제로부터 태어나야 하며, 성숙해 보이고 싶다는 열망에서 태어나서는 안 된다.

플랫폼 팀은 게이트키퍼 (Gatekeeper)가 아니라 가속 장치로 만들어라. 엔지니어를 "고객"으로 간주하는 프로덕트 팀 (Product Team)처럼 행동하며, 성공은 고객(=타 팀)의 개발 속도나 장애 대응이 얼마나 개선되었는가로 측정한다.

온콜은 조직의 본심을 비추는 탐지기로 읽어라. 알람은 실제로 행동으로 이어지는가, 장애는 팀에 정말로 "소유"되어 있는가, 포스트모템 (Post-mortem)은 실제 개선을 낳고 있는가. 여기에 명목상의 오너십인지 진짜인지 나타난다.

상장 후에는 속도와 예측 가능성을 동시에 추구한다. 어느 한쪽이 아니라, 구조와 스타트업 문화의 균형을 의식하여 설계한다.

나 자신이 이 기사에서 깊이 공감한 부분은 "중복을 너무 두려워하지 마라"는 대목이다. 경계를 그어 깔끔하게 나누는 것이 종종 조정 비용(Coordination Cost)이라는 보이지 않는 세금을 발생시킨다. 너무 이른 분업이나 너무 이른 플랫폼화는 엔지니어라면 무의식적으로 정의롭다고 생각하기 쉽지만, 규모에 비해 너무 앞서 나가면 역효과가 날 수 있다는 경계로 읽힌다.

생성형 AI (Generative AI)의 맥락도 체감하는 바와 유사하다. 코드가 저렴해질수록 가치의 중심은 "누가 이것을 보증하고 관리할 것인가"라는 인간 측의 책임으로 옮겨간다. 도구가 똑똑해질수록 오너십 (Ownership) 설계가 효과를 발휘한다는 주장은, 앞으로의 팀 운영을 고민할 때 가져두어야 할 보조선이라고 생각한다 🧭

덧붙여, 본 글은 기사의 주장을 요약 및 재구성한 것이며, 규모의 숫자(20/50/80~100/200)는 원문 기사에서 제시하는 기준일 뿐, 모든 조직에 적용되는 절대값은 아니라는 점을 보충해 둔다.

출처: Ido Green 「Ownership over hiring」. 뉴스레터 『Leadership in Tech』에서 소개. 원문: https://greenido.dev/2026/06/11/what-changes-at-20-50-and-200-engineers/