오픈소스를 망치는 가장 확실한 방법: 2차 세계대전 사보타주 매뉴얼이 대기업 회의실 풍경이 된 이야기

80년 전 첩보 문서가 지금 우리 회사 회의실에서 벌어지는 일이라면?

1944년, 미국 정보기관의 전신인 OSS(전략사무국)는 적국 내부에 잠입한 시민들이 조직을 "안에서부터" 무너뜨릴 수 있도록 Simple Sabotage Field Manual이라는 매뉴얼을 만들었어요. 폭탄을 던지거나 무기를 들고 싸우는 게 아니라, 평범한 직원이 회사나 공장에서 일을 하면서 슬쩍슬쩍 비효율을 만들어내는 방법을 정리한 문서거든요. 그런데 최근 alephic.com의 한 글에서 이 매뉴얼을 다시 꺼내 읽어봤더니, "어라, 이거 우리 회사 일하는 방식이랑 똑같은데?" 하는 항목들이 너무 많다는 거예요. 농담이 아니라, 80년 전 적국을 파괴하라고 쓴 지침이 오늘날 "잘 굴러간다는 대기업"의 표준 운영 방식이 되어 있다는 게 이 글의 핵심 주장입니다.

오픈소스(OSS) 진영에서도 비슷한 현상이 보입니다. 자유롭게 코드를 공유하고 빠르게 의사결정 하던 프로젝트들이 점점 무거워지면서, "보안 검토", "행동 강령 위원회", "기여자 라이선스 동의서(CLA)" 같은 절차들로 둘러싸이고 있죠. 물론 이게 다 나쁘다는 건 아니에요. 다만 이게 진짜로 프로젝트를 보호하기 위한 건지, 아니면 결과적으로 새로운 기여자를 차단하고 의사결정을 마비시키는 사보타주가 되어버렸는지 한 번쯤 돌아봐야 한다는 거예요.

매뉴얼이 알려준 "합법적 태업" 11가지

원문 매뉴얼에서 가장 유명한 항목들을 한국식으로 살짝 옮겨볼게요. "모든 결정은 위원회를 통해서 내려라", "가능한 한 큰 위원회를 만들어라(최소 5명 이상)", "이전 회의에서 결정된 것을 다시 끄집어내서 재논의하라", "세부 단어 하나하나의 정확한 표현을 두고 토론하라", "중요한 안건일수록 무관한 이슈를 끌어와 흐름을 끊어라", "위원회나 부서 간 책임소재를 끝없이 핑퐁시켜라", "회의에서 길고 두서없는 일화로 시간을 잡아먹어라".

읽으면서 어디서 많이 본 풍경이죠? 스프린트 플래닝에서 "이거 저번 분기에 정리한 것 같은데 다시 한 번 얼라인 맞춰볼까요?"로 30분이 사라지고, PR 리뷰에서 변수명 하나로 댓글이 40개 달리고, 보안팀과 인프라팀이 서로 "이건 너네 영역인데"라며 티켓을 미루는 일들 말이에요. 매뉴얼은 분명히 "이렇게 하면 적국의 생산성이 떨어진다"라고 적어놨는데, 우리는 그걸 "성숙한 조직의 표준 프로세스"라고 부르고 있는 셈이에요.

왜 이렇게 됐을까: 의도가 아니라 구조의 문제

글에서 가장 흥미로운 부분은 "누가 일부러 그러는 게 아니다"라는 지적이에요. 회사가 일정 규모를 넘으면 한 번의 실수가 큰 비용으로 돌아오기 때문에, 그걸 막기 위한 안전장치를 계속 쌓게 되거든요. 그런데 안전장치 하나하나는 합리적이어도, 다 합쳐 놓으면 매뉴얼이 의도한 그 "마비 상태"와 똑같아진다는 거죠. 책임 회피, 위험 회피, 합의 추구가 결합하면 결과적으로 사보타주와 구분이 안 되는 행동 패턴이 만들어집니다.

오픈소스 쪽에서 이게 더 도드라지는 이유는, 원래 OSS의 강점이 "의사결정 속도"와 "낮은 진입 장벽"이었기 때문이에요. 리누스 토르발스가 메일링 리스트에서 패치 하나 보고 그날 머지하던 시절의 리눅스가 지금처럼 거대 기업의 후원과 거버넌스 체계 위에 올라타면서, 작은 변경 하나에도 여러 위원회의 승인을 거쳐야 하는 구조로 바뀌었거든요. 쿠버네티스 KEP 프로세스, 파이썬 PEP, 러스트 RFC 같은 것들이 다 좋은 의도지만, 신규 기여자가 첫 패치를 머지하기까지 6개월씩 걸리는 사례가 흔해진 것도 사실이에요.

다른 시각: "느린 게 꼭 나쁜 건 아니다"

이 주장에 대한 반론도 만만치 않습니다. 의료, 금융, 항공처럼 한 번의 실수가 사람 목숨이나 수십억 손실로 이어지는 분야에서는 "빠른 결정"이 오히려 사보타주거든요. 리눅스 커널도 옛날처럼 즉흥적으로 머지했다면, 지금 전 세계 서버의 안정성을 책임지지 못했을 거예요. 즉 핵심은 "프로세스가 있다/없다"가 아니라, 그 프로세스가 만들어내는 비용과 보호 가치의 비율이 맞느냐입니다. 변수명 토론에 30분을 쓰는 건 사보타주에 가깝지만, 보안 취약점이 있는 PR을 4명이 리뷰하는 건 정당한 비용이라는 거죠.

한국 개발자가 가져갈 만한 것

한국 IT 조직, 특히 어느 정도 규모가 있는 회사에서 일해 본 분이라면 이 매뉴얼 항목들이 거의 "우리 팀 회의록" 수준으로 들어맞을 거예요. 그래서 더 의미가 있는 게, 이걸 "누구 탓"으로 돌리지 않고 "구조 점검 체크리스트"로 써볼 수 있다는 점이에요. 다음 회의에 들어가기 전에 한 번만 자문해보세요. "이 안건은 정말로 위원회 결정이 필요한가, 아니면 한 사람이 책임지고 결정할 수 있는가?", "이미 결정된 걸 다시 꺼내고 있는 건 아닌가?", "세부 표현 토론에 들어가는 시간이 결과물의 가치보다 큰가?" 같은 질문들이요.

사이드 프로젝트나 작은 오픈소스를 운영하시는 분이라면 더 직접적인 교훈이 있어요. 프로젝트가 성장할수록 "규칙을 추가하고 싶은 유혹"이 커지는데, 규칙 하나를 추가할 때마다 그게 진짜로 보호하는 게 뭔지, 대신 잃는 속도와 기여자가 뭔지 같이 적어두는 습관을 들이면 좋아요. 결국 좋은 거버넌스는 "많은 규칙"이 아니라 "꼭 필요한 규칙만 남기는 것"이거든요.

마무리

결국 이 글이 묻는 건 단순합니다. "우리가 매일 합리적이라고 부르는 그 절차들이, 사실은 80년 전 적국을 무너뜨리려고 만든 매뉴얼과 얼마나 다른가?" 한 번쯤 자기 회사의 회의와 PR 프로세스를 매뉴얼 항목과 나란히 놓고 비교해 보면, 농담이 아니라 진짜 등골이 서늘해질지도 몰라요.

여러분 조직에서 가장 "사보타주처럼 보이는" 프로세스는 뭔가요? 그리고 그게 정말 보호 가치가 있는 비용인지, 아니면 그냥 책임 회피용 안전장치인지 한 번 토론해 보면 재미있을 것 같아요.