협업은 헛소리다
(joanwestenberg.com)- 2차 대전 당시 실제로 총을 쏜 병사는 15~20%에 불과했다는 연구처럼, 조직 내 대부분의 실질적 성과는 소수가 만들어냄
- 테크 업계는 이 문제의 해법으로 "협업"을 내세웠지만, 실제로는 업무 조율 도구만 늘어나고 산출물은 거의 나오지 않는 구조가 고착화
- 집단이 커질수록 의사소통 비용과 조정 비용이 폭증하며, 회의가 회의를 낳는 책임 확산 현상이 반복됨
- 투명성이 진척과 혼동되고, 가시성이 책임감과 혼동되면서, 협업 문화가 개인 책임을 희석하는 메커니즘으로 작동 중
- 실제 복잡하고 질 높은 작업은 대부분 명확한 권한과 책임을 가진 개인 또는 소규모 그룹이 수행하며, 협업은 이를 포장하는 언어로만 기능함
- 진짜 필요한 것은 협업 인프라가 아니라 개인의 주체적 판단과 책임(ownership) 이며, 조직은 이를 신뢰하는 방향으로 전환 필요
협업이라는 허상
-
협업(collaboration) 은 현대 조직에서 생산성의 상징처럼 여겨지지만, 실제로는 책임 회피와 비효율의 구조로 작동함
- 제2차 세계대전 중 S.L.A. Marshall의 연구에 따르면, 전투 중 실제로 총을 쏜 병사는 15~20%에 불과했음
- IBM이 1960년대에 발견한 “80%의 사용량이 20%의 기능에서 나온다”는 패턴과 유사하게, 소수의 구성원이 대부분의 결과를 만들어냄
- 나머지는 “구조적 지원(structural support)”만 제공하며, 조직 내 노력의 불균형이 반복적으로 나타남
- 기술 산업은 이 문제를 해결하기 위해 ‘협업’이라는 개념을 신앙처럼 추종하게 되었음
- Notion, ClickUp, Slack, Jira, Monday, Teams 등 수많은 협업 도구가 등장했지만, 생산물(output) 보다 활동(activity) 이 늘어남
- 투명성과 가시성이 곧 진전이나 책임으로 오인되며, “스레드에 포함되는 것”이 “결과를 소유하는 것”과 동일시됨
- 이로 인해 협업은 실제 결과보다 참여의 시뮬레이션으로 변질됨
-
책임의 확산(diffusion of responsibility) 은 오래전부터 관찰된 현상임
- 1913년 Ringelmann 효과는 집단 규모가 커질수록 개인의 노력 비율이 감소함을 보여줌
- Frederick Brooks는 1975년 IBM System/360 사례를 통해, 늦은 프로젝트에 인원을 추가하면 더 늦어진다는 법칙을 제시
- 인원이 늘수록 의사소통 비용과 조정 비용이 기하급수적으로 증가하며, 회의가 회의를 낳는 악순환이 발생
- 협업 산업은 이 구조적 문제를 감추기 위해 막대한 자원을 투입했지만, 실제 고품질 작업은 소수의 개인 또는 작은 팀이 수행함
- Dostoevsky는 『카라마조프가의 형제들』을 혼자 썼고, Apollo Guidance Computer는 MIT의 소규모 팀이 명확한 책임 체계 아래 개발
- 진정한 성과는 명확한 권한과 개인적 책임에서 비롯되며, 협업은 그 결과를 포장하는 언어로만 작동함
- 반면 현대 조직은 소셜 관리(social management) 를 위한 복잡한 협업 인프라를 구축했을 뿐, 실제 작업은 뒷전으로 밀려남
-
진짜 소유(ownership) 는 개인이 스스로 결정을 내리고 결과를 감수하는 형태로 존재함
- 그러나 협업이 문화적 규범이 된 환경에서는 단독 결정이 비협조적 행위로 간주됨
- 협업 이데올로기는 책임과 주도성을 반사회적 행위처럼 느끼게 만들었으며, 이는 생산의 핵심 메커니즘을 약화시킴
- 회의, 문서, 회고, 킥오프 등은 끝없이 반복되지만, 실제 실행과 연결되지 않은 ‘조정의 과잉’ 만 남음
개인 책임으로의 회귀 필요성
- 대부분의 프로젝트가 조정 시간 > 실행 시간의 구조로 변했고, 실패 시 해법은 “더 많은 협업”으로 귀결됨
- 그러나 진짜 질문은 “우리가 실제로 무엇을 만들고 있으며, 누가 그것에 책임을 지는가”임
- 어떤 일에 대해서든 최종 책임자는 한 명이어야 함, 협업 구조가 그 존재를 가리더라도
-
개인의 신뢰 회복이 필요함
- 모든 책임을 조직 전체가 감시할 필요는 없음
- 과도한 관리와 메트릭 중심 문화 대신, 개인이 자신의 작업을 스스로 관리하고 결과로 평가받아야 함
- 실패 시 그 책임을 명확히 개인에게 귀속시키는 구조가 필요함
-
집단적 노력의 허상을 버리고, 실제 행동하는 사람을 식별할 수 있는 환경으로 돌아가야 함
- 각자가 자신의 할 일을 스스로 관리하고, 그 결과로 평가받는 단순한 구조로 복귀
- “협업”이라는 따뜻하지만 비싼 허구를 내려놓을 때, 누가 실제로 방아쇠를 당기고 있는지 명확히 볼 수 있음
1 + 1 = 1.1 이기만 하더라도, 아무리 생산성이 높은 1인일지라도 비효율적인 1,000명보다 더 큰 산출물을 만들어낼 수는 없습니다.
소프트웨어 개발은 수공예적인 장인 정신 측면도 있지만 공장에서 생산하는 생산품 측면도 있으니까요.
똑똑한 소수가 잘 정리해서 멍청한놈들도 이해할 수 있게, 잘 움직일 수 있게 해주죠. 멍청한놈들은 그게 자기들이 협업하고 있다고 착각하고 ㅋㅋ
공감 많이 됩니다.
특히 생산물보다 협업 도구에서 일어나는 가시성과 투명성을 위한 활동만 주장창 늘어진다는...
자기 책임 덜어내겠다고 이것저것 다 노트 남기는 기획자들 보면, 개발자로썬 현타만 옵니다.
"2차 대전 당시 실제로 총을 쏜 병사는 15~20%에 불과했다"
마셜의 "15~20% 사격률" 주장을 정면으로 반박하고 분석한 후속 연구와 논문들은 군사 역사학계에서 꽤 비중 있게 다루어졌습니다. 1980년대 이후 여러 역사학자들과 군사 전문가들이 마셜의 연구 기록을 추적한 결과, 해당 수치가 사실상 조작되었거나 심각하게 과장되었다는 결론에 도달했습니다.
로버트 엔겐(2010년)은 미군과 비슷한 환경에서 싸웠던 제2차 세계대전 당시 캐나다군 보병 장교들의 설문조사 및 전투 기록을 분석했습니다. 캐나다군의 실제 사격률은 마셜이 주장한 15~20%보다 압도적으로 높았음을 증명하며, 마셜의 주장이 서방 연합군 전체에 적용될 수 없는 심각한 일반화의 오류라고 반박했습니다.
첫 내용부터 뭔가 이상한거 같아서 찾아보니, 잘못 알려진 사실 같네요. 밑에 해커뉴스 댓글에서 말하는 것도 그렇고요.
진짜 초특급 천재가 아닌 이상, 아무리 잘해도 혼자서 일 못한다. 나머지 80%가 설령 치어리더 역할만 하더라도 옆에서 어화둥둥 해주기만 해도 0.5인분은 되고 에이스들이 2~3인분 일을 하면서 회사가 돌아가는거야. 혼자 일하면 인정받는 느낌도 못받고, 외로워서 못버텨.
큰 규모 조직이 될수록 이 화자가 말하는게 맞는 것 같고
작은 규모 조직이 될수록 이 화자가 말하는 방향성이 이미 되어있는 것 같내요 ㅋㅋ
Hacker News 의견들
-
내가 30년 넘게 이 일을 하면서 본 건, “마감일(date)”이 항상 결과물보다 중요하게 여겨진다는 점임
실제로는 그 날짜를 맞추는 게 거의 불가능하지만, 조직은 여전히 그걸 유일한 지표로 삼음
소프트웨어 개발이 본질적으로 예측 불가능한 활동이라는 점은 거의 고려되지 않음
애자일 선언문이 처음 나왔을 때는 희망이 있었지만, 곧 “각 단계가 얼마나 걸릴지 정확히 말하라”는 관리 방식으로 변질되었음- 내 경험상 진짜 핵심은 날짜보다 예산임
조금 늦는 건 용서받지만, 돈을 더 달라고 하면 영원히 미움받음
애자일은 좋은 Product Owner가 적절한 예산과 의사결정 권한을 확보했을 때만 잘 작동함 - “날짜가 항상 더 중요하다”는 말에서 착안해 Date-bound delivery라는 새 방법론을 생각해봤음
팀은 기간 내에 가능한 만큼만 납품하고, 마감이 다가올수록 기능을 줄여감
결과물의 내용보다 납품 자체를 보장하는 방식임
만약 날짜가 그렇게 중요하다면, 이런 접근도 시도해볼 만하지 않겠음? - Spolsky의 인용을 확장하자면 “누군가 대신 청바지 값을 내준다면 얘기가 달라짐”임
작은 조직일수록 진짜 이해관계자가 존재하지만, 큰 조직에서는 성과와 커리어가 분리되어 있음
나는 하드웨어 쪽에서 일하며, 내 연말 목표를 “내가 직접 작성한 코드로 시연 가능한 상태”로 정의함 - 요즘 LLM들도 인간처럼 견적을 부풀려 말함
“몇 주 걸린다”고 하더니 실제로는 30초 만에 구현함
- 내 경험상 진짜 핵심은 날짜보다 예산임
-
글쓴이가 너무 강하게 말한 것 같음
아마 협업이 엉망인 팀에서 일한 트라우마가 있을지도 모르겠음
하지만 잘 운영되는 팀은 분명 존재하고, 집단이 개인보다 더 큰 성과를 낼 수 있음
피라미드나 Linux 커널, AWS도 혼자 만든 게 아님- 나도 예전엔 고성능 팀에서 일했지만 지금은 혼자 일함
팀이 커질수록 커뮤니케이션 오버헤드가 커지고, 그중 상당수는 관리층의 가시성 욕구 때문임
좋은 팀은 내부적으로 잘 소통하지만, 관리층도 일정 수준의 가시성이 필요함
결국 좋은 팀 + 좋은 관리자 조합이 필수임 - 글의 핵심은 “협업이 이데올로기가 되어 책임감이 사라졌다”는 부분이라고 봄
대부분의 조직은 협업을 잘하지 못하면서, 그 실패를 협업이라는 말로 덮음
다만 “작은 팀만이 일한다”는 주장엔 과도한 면이 있음
피라미드 건설 같은 사례는 현대적 의미의 협업이라기보단 엄격한 지시 체계에 가까움 - 글쓴이의 시각이 너무 냉소적임
아폴로 컴퓨터 프로그램은 작은 팀이 만들었지만, 달에 가기 위해선 훨씬 더 많은 협력이 필요했음
협업이 실제로 효과적이라는 증거는 너무 많음 -
집단성과 개인성과는 선형적이지 않음
혼자서는 Assassin’s Creed 같은 대작을 못 만들고, 위원회로는 Stardew Valley 같은 게임을 못 만듦
서로 다른 종류의 역량임 - Linux 커널은 실제로 개인별 책임 구분이 명확함
- 나도 예전엔 고성능 팀에서 일했지만 지금은 혼자 일함
-
나도 글쓴이의 경험에 공감함
스타트업에서 해고된 뒤 대기업으로 옮겼는데, 처음엔 팀워크가 잘 맞아 성과가 좋았음
그런데 Agile 코치가 등장해 “협업”을 명분으로 자신의 의제를 밀어붙이기 시작함
8개월 동안 쓸모없는 워크숍과 권한 다툼이 이어졌고, 결국 유능한 팀이 무기력한 팀에 끌려다님
무능한 사람을 해고하지 않는 문화가 문제임
진짜 협업은 서로의 자존심을 내려놓고 경청하며 일할 때 가능함 -
혼자 일하면 더 많은 일을 할 수 있지만, 문제를 잘못 정의할 위험이 큼
협업은 다양한 관점을 통해 그걸 방지함- 하지만 큰 조직에서는 협업이 곧 아무 문제도 해결하지 않는 상태가 되기도 함
일하지 않는 사람들이 오히려 일하는 사람을 방해함
- 하지만 큰 조직에서는 협업이 곧 아무 문제도 해결하지 않는 상태가 되기도 함
-
최근 읽은 McEntire의 논문 “The Organizational Physics of Multi-Agent AI” 가 흥미로웠음
AI 에이전트조차 인간 조직의 정치적 비효율을 그대로 재현함
결국 조직이 나쁘면 “일에 대한 일(work about work)”만 하게 됨
작고 책임감 있는 팀이 훨씬 즐겁지만, 재현 가능성이 낮음
내 블로그 글 Where to Cut에서도 이 주제를 다룸- 나도 최근 Team Topologies를 다시 읽고 있음
역할과 구조가 명확할 때만 오케스트레이션이 제대로 작동함을 느낌 - 좋은 팀은 대체 불가능(fungible) 하지 않음
사람을 바꾸거나 팀을 이동시키면 맥락 전환 비용이 생겨 팀의 응집력이 깨짐 - 네 글이 원문보다 훨씬 명확함
원문은 무슨 말을 하려는지 잘 모르겠었음 - “신이 인간을 자기 형상대로 만들었다”는 구절이 훈련 데이터에 들어간 건 의도였을까, 아니면 무분별한 데이터 수집의 부산물일까 궁금함
- 나도 최근 Team Topologies를 다시 읽고 있음
-
성과를 내는 사람에게 인정이 주어지지 않는 문화가 조직을 좀먹음
무게를 더 짊어지는 20%는 단지 인정받고 싶을 뿐임
그걸 주지 않으면 회사는 빠르게 텅 비게 됨- 나는 인정보다 팀의 동료애와 보상이 더 중요함
내가 뭘 하는지도 모르는 사람의 칭찬엔 관심 없음 - 대부분의 사무직은 원래 공로가 제대로 인정되지 않는 구조로 운영됨
- 나는 인정보다 팀의 동료애와 보상이 더 중요함
-
이 글은 조직을 넘어 ‘저작권과 주체성’의 사회적 의미로 확장될 수 있음
복잡하고 고품질의 일은 결국 작은 팀이나 개인의 명확한 책임감에서 나옴
도스토옙스키나 아폴로 컴퓨터 팀처럼 말임
반면 “모두가 기여하지만 아무도 보상받지 않는” 협업 유토피아는 현실과 거리가 멂
인간은 자신의 이름이 걸린 창작물에 더 강한 동기를 느낌- 하지만 우리는 모두 이전 세대의 성과 위에 쌓아 올리는 협업 구조 속에 있음
복잡한 공급망 자체가 또 다른 형태의 협업임
- 하지만 우리는 모두 이전 세대의 성과 위에 쌓아 올리는 협업 구조 속에 있음
-
“80%의 병사가 총을 쏘지 않았다”는 주장이 의심스러워 찾아보니, 이미 오래전부터 반박된 자료였음
2011년 논문에서도 그 근거가 약하다고 함- 병참병까지 포함했는지 혼동이 있었을 가능성이 있음
미군의 tooth-to-tail 비율을 보면 실제 전투 인원은 4~10% 수준임
따라서 수치 혼동이 원인일 수 있음 - 책 On Killing은 훈련 개선으로 사격률이 90% 이상으로 올라갔다고 분석함
하지만 그만큼 PTSD 비율도 상승했다고 함
- 병참병까지 포함했는지 혼동이 있었을 가능성이 있음
-
글 전체가 군인 사례를 사무직 모델로 억지로 끌어온 incoherent한 시도처럼 느껴짐
하지만 글쓴이에게 좋은 소식이 있음 — 당신도 개인 창작자가 될 수 있음
Notch나 Stardew Valley 개발자처럼 말임
불평 대신 직접 무언가를 만들면 됨- 그래도 “죽기 싫으면 적을 쏴야 하지 않나?”라는 점에서
80%가 총을 안 쐈다는 건 여전히 흥미로운 사실임 - 집단이 커질수록 책임감이 희석되는 현상은 이미 잘 알려진 사실임
- 그래도 “죽기 싫으면 적을 쏴야 하지 않나?”라는 점에서
-
글쓴이는 성과에 대한 인센티브 설계를 전혀 고려하지 않았음
Munger의 말처럼 “인센티브를 보면 결과를 알 수 있음”
협업의 어려움보다 중요한 건, 성과자에게 보상하고 무임승차자를 제재하는 구조를 만드는 일임- 하지만 현실의 기술 조직에서 가능한 인센티브는 연봉 인상이나 보너스 정도임
그것도 많지 않음 - 인센티브를 대규모로 정렬시키는 게 가능한가 의문임
가능했다면 이미 우리는 유토피아에 살고 있을 것임
- 하지만 현실의 기술 조직에서 가능한 인센티브는 연봉 인상이나 보너스 정도임
AI TOOLs 가 현실인 지금시점에선 개인의 man power를 극대화 할수 있는 꽤 현실적이고 일가견 있는 글이라 생각됩니다.
앞으로 모든것은 점점 더 경량화 와 빠른 속도를 요구할텐데 지금 까지 해온 낡은 관념의 협업은 리셋되겠죠. 그러나 엔터프라이즈급 솔루션 개발을 위해서는 협업은 필수.