흐름을 막지 않는 협업 — 리뷰와 핸드오프

내 일이 끝나면 왜 다른 사람의 일이 막힐까?

당신은 금요일 오후 5시에 코드 리뷰 요청을 보낸 적 있습니까?

주말 동안 리뷰어는 그 요청을 보지 못합니다. 월요일 아침에 출근해서야 리뷰를 시작합니다. 피드백이 오면 화요일. 수정하고 다시 요청하면 수요일. 다시 리뷰, 목요일. 금요일 오후가 되어서야 겨우 머지됩니다.

코드는 30분 만에 작성했는데, 완료되기까지 일주일이 걸렸습니다.

그림 1. 실제 코딩 30분, 리뷰 대기 5일—전체 리드 타임의 대부분은 기다리는 시간이다.

이것이 흐름을 막는 협업입니다.

혼자서는 아무리 빨리 해도, 협업 과정에서 병목이 생기면 전체 속도가 느려집니다.

엘리야후 골드랫(Eliyahu Goldratt)은 The Goal에서 제약 이론(Theory of Constraints)을 제시하며 이렇게 선언합니다. "어떤 시스템이든 목표 달성을 저해하는 제약 요인(Bottleneck)이 적어도 하나는 존재한다. 전체 시스템의 생산성은 오직 이 병목 자원의 처리 능력에 의해 결정된다."

개인의 생산성이 아무리 높아도, 협업 지점에서 막히면 전체 흐름이 정체됩니다. 병목이 아닌 곳에서의 최적화는 전체 생산성을 높이지 못하며, 오히려 병목 앞의 재고만 쌓이게 만듭니다. 흐름을 지키는 협업의 기술이 필요합니다.

---

내 완료가 다른 사람의 시작

일의 흐름에서 우리는 혼자가 아닙니다. 나의 '완료'는 누군가의 '시작'이 됩니다.

내가 디자인을 완료하면 → 개발자가 구현을 시작합니다

내가 코드를 완료하면 → 리뷰어가 검토를 시작합니다

내가 기획 문서를 완료하면 → 팀이 실행을 시작합니다

이 연결고리를 의식해야 합니다. 내가 느리면 다른 사람도 느려집니다. 내가 핸드오프를 불명확하게 하면 다른 사람이 혼란에 빠집니다.

그림 2. 연결고리 중 하나만 끊어져도 하위 작업 전체가 멈춘다.

스탠리 맥크리스털(Stanley McChrystal) 장군은 Team of Teams 에서 현대 조직의 핵심 과제로 '공유된 의식(Shared Consciousness)'을 제시합니다. 이는 팀원 전체가 시스템의 전체상과 현재 상황을 실시간으로 동일하게 이해하는 상태를 의미합니다. 개별 팀이 아무리 뛰어나도, 팀과 팀 사이의 연결이 끊어지면 조직 전체가 마비됩니다.

그는 이라크전에서 적의 네트워크가 미군보다 빠르게 움직이는 것을 보고 깨달았습니다. 정보가 계층을 따라 올라갔다 내려오는 동안, 적은 이미 다음 행동을 끝냈습니다. 중앙집권적 통제가 아니라, 모든 구성원이 동일한 정보를 공유하는 '공유된 의식'이 필요했습니다.

심리학에서 이를 공유 멘탈 모델(Shared Mental Models)이라고 부릅니다. 연구에 따르면, 공유 멘탈 모델의 정확도와 유사성이 높은 팀일수록 커뮤니케이션 효율성이 높고, 돌발 상황에서의 대처 능력이 뛰어납니다. A는 이슈가 해결되었다고 생각하고, B는 A가 처리 중이라 생각하며, C는 그 이슈의 존재조차 모르는 상황—이런 인지적 불일치가 협업의 비용을 증가시킵니다.

흐름 중심의 사고는 "내 일만 하면 돼"에서 "내 일이 다음 사람에게 어떤 영향을 미칠까?"로 관점을 바꾸는 것입니다. 이것은 개인의 효율성이 아닌, 시스템 전체의 효율성을 보는 눈입니다.

그림 3. 사일로(좌)와 공유된 의식(우)—연결이 없으면 속도도 없다.

---

24시간 리뷰 원칙

코드 리뷰, 문서 리뷰, 기획 리뷰. 리뷰는 협업의 핵심이지만, 동시에 가장 큰 병목 지점입니다.

24시간 리뷰 원칙을 제안합니다. 리뷰 요청을 받으면 24시간(영업일 기준) 안에 응답하는 것입니다.

"24시간 안에 완료하라"는 게 아닙니다. 최소한 응답은 하라는 것입니다.

- 바로 리뷰할 수 있으면 리뷰

- 바로 어려우면 "내일 오전까지 볼게요"라고 알려주기

- 다른 사람에게 위임해야 하면 그것도 알려주기

응답 없음이 가장 나쁩니다. 요청자는 기다리는지, 다른 방법을 찾아야 하는지조차 모릅니다. 불확실성이 가장 큰 비용입니다.

하버드 비즈니스 스쿨의 데이비드 마이스터(David Maister)는 "대기열의 심리학(The Psychology of Waiting Lines)"에서 대기의 핵심 법칙을 제시합니다:

"불확실한 대기는 확실한 대기보다 길게 느껴진다."

병원에서 "30분 대기"라고 안내받는 것보다, 언제 부를지 모르는 상태로 20분을 기다리는 것이 훨씬 더 큰 불안과 스트레스를 유발합니다. 개발자가 PR(Pull Request)을 올리고 언제 리뷰될지 모르는 상태로 기다릴 때, 이 불확실성은 인지적 배경에서 지속적인 알람을 울리며 다른 업무의 집중을 방해합니다.

마이스터의 또 다른 법칙도 중요합니다: "설명되지 않은 대기는 설명된 대기보다 길게 느껴진다." 이유를 모른 채 기다리는 것은 통제력 상실감을 줍니다. "긴급 서버 점검으로 배포가 지연됩니다"라는 공지는 대기의 고통을 줄여줍니다. 그러나 아무런 피드백 없이 방치된 요청은 무시당한다는 느낌과 함께 시스템에 대한 불신을 심어줍니다.

그림 4. 불확실한 대기는 시간이 지날수록 스트레스가 지수적으로 증가하고, 확실한 대기("내일까지 볼게요")는 완만하게 유지된다.

Google의 DORA(DevOps Research and Assessment) 연구에서도 리드 타임(Lead Time)—코드 변경이 프로덕션에 배포되기까지 걸리는 시간—이 팀 성과의 핵심 지표로 제시됩니다.

2024년 DORA 리포트에 따르면, 엘리트 그룹은 저성과 그룹에 비해 127배 빠른 리드 타임과 2,293배 빠른 복구 속도를 보입니다. 그 차이의 상당 부분은 리뷰와 승인 과정에서 발생합니다. 엘리트 그룹은 '좀비 이슈'를 거의 허용하지 않으며, 문제가 발생했을 때 즉각적인 집단 지성을 발휘합니다.

그림 5. 엘리트 팀과 저성과 팀의 DORA 핵심 지표 비교—127배의 리드 타임 차이.

---