"팀을 늘리는 게 답이 아니었다" — 조직을 더한다고 일이 빨라지지 않는 이유

더 많은 사람을 투입했는데 왜 더 느려질까

소프트웨어 엔지니어링 매니저로 일해본 사람이라면 누구나 한 번쯤 마주치는 장면이 있어요. 일이 밀린다, 로드맵이 안 굴러간다, 그래서 "팀을 하나 더 만들자"는 결정을 내립니다. 사람을 뽑고, 매니저를 세우고, 백로그를 나눠 갖고, 슬랙 채널을 새로 파고. 그런데 6개월 뒤에 돌아보니 속도가 빨라지긴커녕, 회의는 두 배가 되고 의사결정은 더 느려져 있어요. 이번에 공유된 한 엔지니어링 리더의 회고는 바로 이 흔한 함정에 대한 솔직한 이야기예요. 자기가 내렸던 "팀을 추가하자"는 결정이 사실은 전략적으로 틀렸다고 인정하는, 꽤 흔치 않은 자기 비판 글이거든요.

글의 핵심 주장이 뭐냐면

저자는 자기 조직이 처리해야 할 일이 늘어나자, 자연스럽게 "팀을 하나 더 추가하면 처리량(throughput)이 늘어나겠지"라고 생각했어요. 그런데 그 결정이 가져온 건 처리량 증가가 아니라 조직 간 조율 비용의 폭증이었다고 합니다. 이게 무슨 말이냐면요. 새 팀이 생기면 그 팀이 다루는 영역과 기존 팀의 영역 사이에 "경계선"이 생겨요. 두 팀이 같이 만져야 하는 코드, 같이 결정해야 하는 API, 같이 합의해야 하는 우선순위가 생기죠. 이걸 인터페이스(interface)라고 부르는데, 팀이 늘면 이 인터페이스의 개수가 기하급수적으로 늘어나요. 팀이 N개면 인터페이스는 대략 N(N-1)/2개거든요.

저자가 짚은 또 다른 포인트는, 새 팀을 만든다는 건 단순히 인원 배치가 아니라 새로운 조직적 정체성을 만드는 일이라는 점이에요. 팀이 생기면 그 팀은 자기 OKR을 갖고 싶어 하고, 자기 로드맵을 갖고 싶어 하고, 자기 코드 영역을 갖고 싶어 해요. 이게 자연스러운 본능인데, 회사 전체로 보면 이 본능이 모이면 사일로(silo)가 됩니다.

콘웨이의 법칙과 역콘웨이 전략

이 이야기는 사실 새로운 게 아니에요. 1968년에 멜빈 콘웨이라는 사람이 내놓은 콘웨이의 법칙(Conway's Law)이 있는데, 이게 뭐냐면 "시스템을 설계하는 조직은, 그 조직의 커뮤니케이션 구조를 그대로 닮은 시스템을 만들게 된다"는 관찰이에요. 팀 두 개가 있으면 시스템도 두 덩어리로 나뉘게 되고, 팀 사이에 회의가 많으면 시스템 사이에 인터페이스도 많아진다는 거죠.

그래서 요즘 마이크로서비스나 플랫폼 엔지니어링 쪽에서는 역콘웨이 전략(Inverse Conway Maneuver)이라는 표현을 써요. 우리가 만들고 싶은 아키텍처가 있다면, 그 아키텍처에 맞게 조직을 먼저 설계하라는 거예요. 매튜 스켈튼과 마누엘 페이스가 쓴 "Team Topologies"라는 책이 이 주제를 본격적으로 다루는데요. 거기서는 팀의 종류를 스트림 정렬 팀, 플랫폼 팀, 컴플리케이티드 서브시스템 팀, 인에이블링 팀의 네 가지로 나누고, 팀 사이의 상호작용 모드도 협업/X-as-a-Service/촉진의 세 가지로 정리해요. 즉, 팀을 추가할 때는 "이 팀이 어떤 역할의 팀이고, 다른 팀과 어떤 모드로 상호작용할 것인가"를 먼저 정의해야 한다는 뜻이에요.

그럼 뭘 먼저 했어야 했을까

저자가 회고하면서 짚은 대안은 팀을 추가하기 전에, 기존 팀의 일감 구조부터 바꾸는 것이었어요. 같은 사람 수라도 일을 어떻게 묶어서 누구에게 맡기느냐에 따라 처리량이 달라지거든요. 또 하나는 자율성을 높여주는 것. 결정을 매니저에게 올리지 않고도 엔지니어가 스스로 내릴 수 있게 권한을 내리고 가드레일을 세우는 일이, 팀 추가보다 훨씬 효과가 빠른 경우가 많다는 거예요. 마지막으로는 "안 하기로 결정하기". 모든 백로그를 처리할 수는 없으니, 줄을 세우고 후순위는 과감히 "안 한다"고 못 박는 것이 사람을 더 뽑는 것보다 효과적일 때가 많다고 합니다.

한국 개발자와 매니저에게 주는 시사점

한국에서도 "인원 추가 = 속도 증가"라는 직관이 의사결정 회의에서 자주 등장합니다. 특히 분기 OKR이 안 굴러간다 싶을 때 가장 먼저 나오는 카드가 "TF 만들자", "본부 신설하자"예요. 그런데 신설된 조직이 자리잡고 처리량을 내기까지는 보통 두 분기, 길면 세 분기가 걸려요. 그동안 조율 비용은 즉시 발생하고요. 그래서 매니저 트랙에 있는 분이라면 이번 글을 계기로, 팀 추가를 제안하기 전에 "우리가 풀려는 문제는 처리량 부족인가, 우선순위 부재인가, 자율성 부족인가"를 먼저 자문해보면 좋겠습니다.