[번역] "Collaboration" is bullshit

1944년, 독일 국방군은 제3제국을 구하기 위한 히틀러의 마지막 도박에 나섰습니다. 벌지 전투는 몰락해 가는 정권의 운명이 걸린, 무모하고 파멸이 예정된 도박이었습니다. 하지만 그 잔혹함은 서부 전선의 미군에게 진정한 두 번째 시험대가 되었습니다. 전투가 진행되는 동안 육군 역사학자 S.L.A. 마셜은 실전을 치른 보병 중대원들을 인터뷰하기 시작했습니다. 3년 뒤인 1947년 출간된 그의 저서 《대 포화》에 따르면, 실제 전투 상황에 놓인 소총수의 단 15~20%만이 무기를 발사했을 뿐, 나머지 대부분은 고개를 숙인 채 숨어 있었습니다. 그들은 명령이 내려오면 움직였고, 진지를 지켰으며, 겉보기에는 전투 중인 군인의 흉내를 냈습니다. 하지만 방아쇠를 당기지는 않았습니다. 그 어떤 표준적인 조직 지표로 보더라도 그 인원들은 제자리에 출석한 것으로 계산되었지만, 5명 중 4명은 단 한 번도 방아쇠를 당기지 않은 것입니다.

마셜의 수치나 방법론에 대해서는 논쟁의 여지가 있을 수 있습니다. 하지만 이 비율은 계속해서 반복되어 나타납니다. 1960년대 IBM은 컴퓨터 사용량의 80%가 전체 시스템 기능의 단 20%에서 나온다는 사실을 발견하며 이 법칙을 우연히 마주했습니다. 이 패턴이 반복되는 이유는 집단 내에서 노력이 어떻게 분배되는지에 대한 진실을 설명해 주기 때문입니다. 사람들의 극히 일부만이 대부분의 일을 해내고, 나머지는 그저 관대하게 표현하자면 구조적 지원을 제공할 뿐입니다.

큰 조직에서 일해 본 사람이라면 제가 무슨 말을 하는지 정확히 알 것입니다.

현대 기술 산업은 인간의 조율과 참여라는 이 문제를 바라보며 협업을 해결책으로 내놓았습니다. 만약 우리 중 20%만이 킬러 본능을 가지고 움직인다면, 우리는 나머지 80%의 공유된 본능을 더 잘 관리해야 한다는 것입니다. 그렇게 협업은 우리의 공동된 강박이 되었습니다. 우리는 팀워크를 성배처럼 추구합니다.

그 이른바 팀워크 혁명은 문서 작업을 위한 Notion, 태스크 관리를 위한 ClickUp, 대화를 위한 Slack, 티켓 관리를 위한 Jira, 보드를 위한 Monday, 이메일로 했어야 할 통화를 위한 Teams, 다른 곳에 욱여넣지 못한 것들을 위한 이메일, 그리고 이제는 이 모든 스택을 재발명하려는 AI 에이전트들을 우리에게 안겨주었습니다. 평범한 지식 노동자는 수많은 시스템에 계정을 유지하며 하루에도 수백 번씩 애플리케이션 사이를 전환합니다. 그리고 그들은 종합적으로, 무언가 결과물이라고 부를 만한 것으로는 전혀 이어지지 않는 엄청난 양의 조율되고 협업적인 활동을 만들어냅니다.

제품 마케팅, 데브렐, 블로그 게시물, 투자 유치, 그리고 이 모든 것 위에 쌓인 헛짓거리들을 걷어내고 나면, 우리에게 남는 것은 집단적 참여의 시뮬레이션일 뿐 그 외에는 거의 아무것도 없습니다. 투명성은 진척과 혼동되었고, 가시성은 책임감과 혼동되었으며, 스레드에 포함되는 것은 사회적으로나 조직적으로나 결과물을 소유하는 것과 같은 의미가 되어버렸습니다.

한 번 이런 혼동이 문화적 수준에 자리 잡으면, 그것을 뽑아내는 것은 거의 불가능해집니다. 개인적인 책임감이 결코 줄 수 없는, 협업이라는 감정 특유의 달콤함이 있기 때문입니다. 무언가를 온전히 소유한다는 것은 특정하고 명확하게 당신이 그것에 실패할 수 있음을 의미하며, 그 실패는 당신의 이름표를 달게 됩니다.

반면 협업을 한다는 것은 실패가 프로세스의 몫이 된다는 것을 의미합니다.

그래서 모두가 협업을 선택했고, 우리는 그것을 문화라고 불렀습니다.

마셜이 관찰한 소총수들은 어느 집단에서나 일어나는 책임감의 분산에 반응한 평범한 사람들이었습니다. 막시밀리앙 링겔만은 슬랙 워크스페이스에 이모지 반응을 남길 수 있기도 훨씬 전인 1913년에 밧줄 당기기 실험으로 같은 현상을 측정했습니다. 집단의 크기가 커질수록 개인의 노력은 예측 가능하게 감소합니다. 타인의 존재는 개인의 책임감을 분해하며, 이를 경험하는 모든 사람에게는 그것이 완전히 합리적으로 느껴집니다. 당신은 팀의 일원이고 기여하고 있지만, 동시에 만약 밧줄을 당신 혼자 당겼을 때보다는 측정 가능할 정도로 덜 힘껏 당기고 있습니다. 밧줄을 잡은 모든 사람이 이 짓을 동시에 하고 있기 때문에, 머릿수에 맞게 전체 힘이 더해지지 않는 것입니다.

프레더릭 브룩스는 1975년 소프트웨어 개발에서 동일한 역학을 발견했습니다. 그는 IBM의 System/360 프로젝트를 지켜보며 “지연되고 있는 프로젝트에 인력을 추가하면 프로젝트는 더 지연된다”는 자신의 이론을 입증했습니다. 커뮤니케이션 오버헤드는 인원수보다 빠르게 증가하고 조율 비용은 복리로 불어납니다. 새로운 사람은 자신의 업무 능력뿐만 아니라 다른 모든 사람들과의 관계를 시스템에 가져옵니다. 이러한 관계는 유지보수가 필요하고, 불일치를 만들어내며, 그 회의들이 만들어낸 불일치를 해결하기 위해 더 많은 회의를 필요로 합니다.

브룩스는 여러분 회사의 3분기 로드맵 계획 사이클이나 스타트업의 스프린트 회고를 묘사했을 수도 있습니다. 이 모든 것들은 매년 길어지기만 하고 투자 대비 생산성은 오히려 떨어지고 있으니까요.

협업 산업은 불편한 진실을 감추기 위해 막대한 돈을 쏟아부었습니다. 그 진실이란, 가장 복잡하고 고품질의 일은 명확한 권한과 날카로운 책임감을 가지고 움직이는 개인이나 아주 소규모의 그룹에 의해 수행되며, 나중에 가서야 팀워크라는 언어로 사후 합리화된다는 것입니다. 도스토옙스키는 《카라마조프 가의 형제들》을 혼자 썼습니다. 아폴로 유도 컴퓨터는 진정한 오너십을 가질 수 있을 만큼 충분히 작은 MIT 팀에서 나왔고, 마거릿 해밀턴이 직접 설계한 오류 감지 루틴에 자신의 이름을 올릴 수 있을 만큼 위계적이었습니다.

의사소통은 중요하며 공유된 컨텍스트도 중요합니다. 하지만 개인의 주도적인 오너십을 지원하기 위한 인프라로서의 커뮤니케이션과 협업과, 조직의 주된 활동으로서의 커뮤니케이션과 협업 사이에는 엄청난 차이가 있습니다. 솔직해집시다. 협업을 최우선으로 하는 대부분의 문화가 구축한 것은 후자입니다. 그들은 실제 업무는 하지 않은 채, 그 업무에 대해 사회적으로 떠들기 위한 기가 막히게 정교한 기계를 만들어 냈습니다.

오너십이라는 것이 존재한다면, 그것은 집단의 합의를 기다리지 않고 깊이 개입하고 고민하여 결단을 내리는 개인의 모습일 것입니다. 그 개인은 때로는 맞고 때로는 틀리겠지만, 그 결과를 전적으로 책임질 것입니다. 그들은 카드를 한 열에서 다른 열로 옮길 권한이 누구에게 있는지 알아내려고 기다리거나, #celebrations 채널에 그것을 자랑하느라 시간을 낭비하지 않습니다.

하지만 협업이 지배적인 가치가 된 곳에서 그런 사람이 되는 것은 엿같은 일입니다. 모든 독단적인 결정은 문화적 위반이자 당신이 팀 플레이어가 아니라는 신호로 읽히기 때문입니다. 이념이 되어버린 협업은 오너십과 책임을 지는 행위 자체를 반사회적인 것으로 느껴지게 만들었습니다. 결과물을 결승선 너머로 밀어내는 유일한 메커니즘이 바로 오너십이라는 점을 생각하면, 참으로 기가 막힌 노릇입니다.

우리는 이러한 과잉을 어디서나 볼 수 있습니다. 모두가 같은 페이지에 있는 한 아무도 방향을 바꾸지 않은 채 자신의 바쁜 업무만 보고하는 스탠드업 회의. 결정을 내리기 위함이 아니라 누군가가 고민을 할 수 있도록 내가 고민을 한 척 보여주기 위해 작성되는 문서들. 회고, 킥오프, WIP 회의가 마치 세포 분열처럼 자신들만의 또 다른 회고, 킥오프, WIP 회의를 낳고, 정작 명목상으로 조직해야 할 실제 일과는 아무런 연결 고리도 없는 상황.

이제 모든 프로젝트는 실행 시간보다 조율하는 오버헤드가 더 많이 드는 것 같고, 프로젝트가 실패하면 사후 분석에서는 그저 더 많은 협업을 권장할 뿐입니다…

어느 시점에는 (그리고 제 생각엔 그 시점은 시발 어제였어야 합니다) 우리는 스스로에게 물어야 합니다. 도대체 우리는 무엇을 생산하고 있으며, 그것을 생산할 실제 책임자는 누구인가?

현대 노동 위에 덮어씌워진 이 협업 장치들이 얼마나 정교하게 책임자를 투명인간으로 만들고 책임감을 용해시켰든지 간에, 결국 “X에 대한 책임이 누구에게 있는가”에 대한 답은 단 한 명의 개인이 되어야만 합니다.

우리는 모든 책임이 조직 전체에 보여야만 한다는 강박 없이, 오버페이 받는 관리자들이 그들의 배부른 지표를 들이밀며 후속 조치를 강요하지 않고도, 개인이 알아서 자신의 일을 해낼 것이라고 다시 신뢰할 수 있는 길을 찾아야 합니다.

아마도, 어쩌면, 우리의 삶을 조금은 더 편하게 만들 수 있을지도 모릅니다. 사람들이 자신만의 태스크 목록을 유지하게 놔두고, 그들이 그 목록을 어떻게 관리하는지에 따라 알아서 생존하거나 도태되도록 내버려 둘 수 있을 것입니다. 그리고 그들이 엿같이 실패했을 때 오직 그들에게만 책임을 물을 수도 있을 것입니다. 팀 차원의 칸반 보드, 캘린더, 그리고 모든 태스크 리스트를 들여다볼 필요 없이 말입니다. 그리고 어쩌면, 우리가 그 따뜻하고 값비싼 집단적 노력이라는 허구를 놓아버린다면, 우리 중 누가 진짜로 방아쇠를 당기고 있는지, 그리고 누가 그저 고개를 숙이고 숨어있는지만을 조금 더 쉽게 볼 수 있을지도 모릅니다.

용어 해설 (Glossary) #

• 벌지 전투 (Battle of the Bulge): 제2차 세계대전 후반 독일군이 미군을 상대로 벌인 대규모 반격 작전.
• S.L.A. 마셜 (Samuel Lyman Atwood Marshall): 미 육군 역사학자로, 전투 중 소총수들의 발사율 저하 현상을 연구하여 유명해짐.
• 대 포화 (Men Against Fire): S.L.A. 마셜이 집필한 전투 중 인간의 심리와 소총수들의 발사 행태에 대한 연구서.
• 구조적 지원 (Structural Support): 핵심적인 기여보다는 조직의 외형적 구조를 유지하는 수준의 소극적인 참여를 일컬음.
• 협업 (Collaboration): 공동의 목표를 위해 함께 일하는 행위이나, 여기서는 책임 소재를 불분명하게 만드는 병폐로 묘사됨.
• 데브렐 (Developer Relations): 개발자들을 대상으로 기술적 소통과 생태계 확장을 담당하는 직군.
• 책임감의 분산 (Diffusion of Responsibility): 집단의 인원수가 많아질수록 개인이 느끼는 책임감이 줄어드는 심리적 현상.
• 막시밀리앙 링겔만 (Maximilien Ringelmann): 링겔만 효과(집단 내 개인 기여도 감소)를 발견한 프랑스의 농공학자.
• 프레더릭 브룩스 (Frederick Brooks): 《맨먼스 미신(The Mythical Man-Month)》의 저자로, 인력 투입이 프로젝트 지연을 가속화한다는 브룩스의 법칙으로 유명함.
• 아폴로 유도 컴퓨터 (Apollo Guidance Computer): 아폴로 계획에서 우주선의 항법과 제어를 담당한 선구적인 컴퓨터 시스템.
• 마거릿 해밀턴 (Margaret Hamilton): 아폴로 계획의 소프트웨어 개발을 주도한 선구적인 컴퓨터 과학자이자 엔지니어.
• 깊이 개입하고 고민하여 (Gives a shit): 결과에 대해 깊은 오너십과 열정을 가지고 집요하게 파고드는 태도.