잘 넘기기보다 덜 넘기기

1-4 보론. 잘 넘기기보다 덜 넘기기 — 핸드오프는 줄일 비용이다

원글(리뷰와 핸드오프)은 협업의 거의 모든 것을 다뤘습니다. 24시간 리뷰 원칙, 좀비 이슈, SBAR 핸드오프, 호혜성의 선순환까지요. Part 1의 마무리답게 "내 완료가 남의 시작"이라는 시스템 관점도 잘 깔았죠.

그런데 원글은 한 가지를 묻지 않습니다. 핸드오프를 어떻게 잘할지는 집요하게 가르치지만, 그 핸드오프가 있어야 하는지는 묻지 않는다는 것.

그래서 이 보론은 "잘 넘기는 법"이 아니라 "덜 넘기는 법"에서 시작합니다.

도현을 다시 부릅니다. 그는 원글을 읽고 핸드오프의 모범생이 됐습니다. PR을 올릴 때 SBAR로 상황·배경·판단·권고를 또박또박 적었고, 리뷰어는 24시간 안에 응답했죠. 교과서대로였습니다.

그리고 일주일치 작업이 통째로 되돌아왔습니다.

이 보론은 그 되돌아온 일주일에 관한 이야기입니다. 결론을 먼저 말하면 이렇습니다 — 핸드오프는 다듬어야 할 의례가 아니라 줄여야 할 비용이다.

가장 좋은 핸드오프는 매끄러운 핸드오프가 아니라, 일어나지 않은 핸드오프다.

완벽한 핸드오프가 통째로 되돌아오다

도현은 결제 모듈을 닷새 동안 만들었습니다.

다 끝내고, PR을 올리고, 원글이 시킨 대로 핸드오프를 정성껏 썼습니다.

S: 결제 재시도 로직을 구현했습니다.
B: 기존 단건 결제에 재시도 큐를 붙였습니다.
A: 멱등성 키로 중복 결제를 막았습니다.
R: 리뷰 후 머지 부탁드립니다.

리뷰어는 24시간 안에 봤습니다. 그리고 답이 왔죠.

"도현 님, 이 재시도를 애초에 결제 모듈 안에 넣으면 안 돼요.

우리 이번 분기에 결제를 외부 PG 큐로 빼기로 했거든요. 이거 처음부터 다시 설계해야 해요."

닷새가 날아갔습니다. 핸드오프는 완벽했는데도요. SBAR는 흠잡을 데 없었고, 응답도 빨랐습니다. 그런데 소용이 없었습니다. 문제는 핸드오프의 품질이 아니라, 핸드오프가 일어난 시점이었습니다.

도현은 다 만들고 나서, "done"이 되고 나서 처음 넘겼습니다.

그 순간 리뷰어가 할 수 있는 건 매끄럽게 받는 게 아니라, 닷새짜리 방향 오류를 발견하는 것뿐이었죠.

원글의 모든 처방—SBAR, 24시간, 체크리스트—은 바통을 잘 넘기는 법입니다.

그런데 바통을 너무 늦게, 너무 완성된 채로 넘기면, 받는 사람은 그걸 다시 던질 수밖에 없습니다.

모든 핸드오프는 비용이다

원글은 핸드오프를 중립적인 전달 행위로 봅니다. 잘하면 흐르고 못하면 막히는.

하지만 실무에서 핸드오프는 그 자체로 네 가지 비용을 항상 부과합니다.

큐가 생긴다

넘기는 순간 리뷰 대기열이 만들어집니다.

1-1에서 본 보이지 않는 큐가, 핸드오프마다 하나씩 생깁니다.

맥락이 재로딩된다

받는 사람은 내 머릿속을 0에서 다시 빌드합니다.

SBAR는 이 비용을 줄일 뿐 없애지 못합니다.

수박이 자란다

넘긴 일이 남의 큐에서 멈춰 있으면, 보드는 초록인데 흐름은 멈춥니다(1-3).

암묵지가 샌다

Poppendieck이 린 소프트웨어에서 못박았듯, 지식은 넘길 때마다 샙니다.

머릿속의 절반은 문서로 못 옮겨지니까요.

그래서 핸드오프는 "잘하면 좋은 것"이 아니라 "있을수록 비싼 것"입니다. 원글이 인용한 DORA의 엘리트 팀을 보세요. 그들이 빠른 건 핸드오프가 매끄러워서가 아닙니다. 핸드오프가 적어서입니다.

Accelerate 연구의 결론이 바로 그거였죠 — 느슨하게 결합된 팀, 경계를 적게 넘는 일이 성과를 만든다. 원글은 소가 다니던 길을 정성껏 포장하라고 가르칩니다. 진짜 빠른 팀은 그 길을 없앱니다.