협업은 헛소리다 — 소수가 만들고, 다수가 회의한다
Brooks의 법칙, Ringelmann 효과, 그리고 협업 도구가 감추는 책임 확산의 구조
Joan Westenberg의 글을 기반으로, 협업 문화의 구조적 문제를 정리한다.
실제로 방아쇠를 당기는 사람은 소수다
2차 대전 당시 S.L.A. Marshall의 연구에 따르면, 전투 중 실제로 총을 쏜 병사는 15~20%에 불과했다. IBM이 1960년대에 발견한 "80%의 사용량이 20%의 기능에서 나온다"는 패턴과 같은 구조다. 조직에서도 소수의 구성원이 대부분의 결과를 만든다.
나머지는 "구조적 지원"만 제공한다. 그 자체로 나쁜 건 아니지만, 문제는 이 불균형을 직시하지 않는다는 점이다.
협업 도구가 해결한 건 뭔가
Notion, ClickUp, Slack, Jira, Monday, Teams — 이 도구들이 쏟아졌다. 결과물(output)이 늘었나? 아니다. 활동(activity)만 늘었다.
투명성이 진척과 혼동된다. 가시성이 책임감과 혼동된다. "스레드에 포함되는 것"이 "결과를 소유하는 것"과 동일시된다. 협업은 참여의 시뮬레이션으로 변질됐다.
Ringelmann 효과와 Brooks의 법칙
1913년 Ringelmann 효과: 집단 규모가 커질수록 개인의 노력 비율이 감소한다. 줄다리기를 혼자 하면 100%의 힘을 쓰지만, 8명이면 1인당 49%만 쓴다.
Frederick Brooks는 1975년 『맨먼스 미신(The Mythical Man-Month)』에서 IBM System/360 사례를 통해 말했다 — 늦은 프로젝트에 인원을 추가하면 더 늦어진다. 인원이 n명일 때 의사소통 경로는 n(n-1)/2로 폭증한다. 10명이면 45개, 20명이면 190개다.
회의가 회의를 낳는다. 킥오프, 싱크, 리뷰, 회고 — 이 사이클이 끝없이 반복되지만 실제 실행과 연결되지 않는 '조정의 과잉'만 남는다.
고품질 작업은 어디서 나오나
Dostoevsky는 『카라마조프가의 형제들』을 혼자 썼다. Apollo Guidance Computer는 MIT의 소규모 팀이 명확한 책임 체계 아래 만들었다.
복잡하고 질 높은 작업은 대부분 명확한 권한과 책임을 가진 개인 또는 소규모 그룹이 수행한다. 협업은 그 결과를 포장하는 언어로만 기능한다.
협업이 ownership을 죽인다
협업이 문화적 규범이 된 환경에서는 단독 결정이 "비협조적 행위"로 간주된다. 스스로 결정을 내리고 결과를 감수하는 ownership이 반사회적 행위처럼 느껴지게 됐다.
대부분의 프로젝트가 조정 시간 > 실행 시간이 된 구조에서, 실패의 해법은 항상 "더 많은 협업"으로 귀결된다. 근데 진짜 질문은 이거다 — "우리가 실제로 무엇을 만들고 있으며, 누가 그것에 책임을 지는가?"
개인 책임으로의 회귀
어떤 일이든 최종 책임자는 한 명이어야 한다. 협업 구조가 그 존재를 가리더라도.
모든 책임을 조직 전체가 감시할 필요는 없다. 과도한 관리와 메트릭 중심 문화 대신, 개인이 자기 작업을 스스로 관리하고 결과로 평가받는 구조가 필요하다.
"협업"이라는 따뜻하지만 비싼 허구를 내려놓으면, 누가 실제로 방아쇠를 당기고 있는지 보인다.
동작 흐름
실질적 성과의 대부분은 소수(15~20%)가 만든다 — Marshall/IBM 연구
협업 도구는 산출물이 아닌 활동(activity)만 늘렸다
Ringelmann 효과: 집단이 커지면 개인 노력 비율이 감소
Brooks의 법칙: 늦은 프로젝트에 인원 추가 → 더 늦어진다
고품질 작업은 명확한 ownership을 가진 개인·소그룹에서 나온다
최종 책임자는 항상 한 명이어야 한다