같은 화면을 세 번째 갈아엎고 있다면, 먼저 질문을 바꿔야 합니다.
"내가 왜 이렇게 느리지?"가 아니라 "이 요구사항은 왜 이렇게 자주 바뀌지?"입니다.
전자는 당신을 갈아 넣는 질문이고, 후자는 원인을 정확한 자리에 놓는 질문입니다. 둘은 같은 상황을 보지만, 하나는 당신을 소진시키고 하나는 당신을 살립니다.
병목은 사람이 아니라 구조에 있다
의사결정이 소수에게 몰려 있는 조직에서는, 승인 대기 줄이 길어집니다. PM이 둘 이상이면 우선순위가 서로 부딪히고, 어제 A안이던 것이 오늘 B안으로 내려옵니다. 그 사이에서 코드를 짜는 사람은, 결정이 흔들릴 때마다 자기 결과물을 지웁니다.
이걸 개인의 생산성 문제로 읽으면 답이 안 나옵니다. 아무리 빨리 짜도, 결정이 흔들리면 결과물은 다시 폐기되니까요. 이건 실행의 문제가 아니라 결정의 구조 문제입니다.
1968년 멜빈 콘웨이는 한 문장으로 이걸 정리했습니다 — 시스템의 구조는 그것을 만든 조직의 소통 구조를 닮는다. 소통이 엉켜 있으면 산출물도 엉킵니다. 당신이 만든 코드가 자꾸 뒤집히는 건, 당신의 실력이 아니라 그 위의 소통이 뒤집히고 있다는 신호입니다.
원인을 이렇게 옮겨 놓는 것만으로도 절반은 해결됩니다. 바꿀 수 없는 걸 붙잡고 자책하는 대신, 바꿀 수 있는 걸 보게 되니까요.
그래서 바꿀 것은 사람이 아니라 당신의 리스크
구조를 혼자 바꿀 수는 없습니다. 소수에게 몰린 결정권을 재분배하는 건 당신 권한 밖의 일입니다. 그러니 목표를 바꿉니다 — 구조를 고치려 들지 말고, 그 구조가 당신에게 남기는 리스크를 줄입니다.
기록으로 남깁니다. 구두로 내려온 요구사항, 바뀐 우선순위, 결정 사항을 메신저와 문서에 남깁니다. "A안으로 진행하는 것으로 이해했습니다. 변경되면 알려주세요." 이 한 줄이, 나중에 "누가 그렇게 하랬어"가 오갈 때 당신을 지킵니다. 기록은 정치가 아니라 위생입니다.
의사결정자를 명확히 못 박습니다. "이 안의 최종 승인자는 누구인가요?"를 묻는 걸 두려워하지 마세요. 승인권자가 흐릿한 채로 착수하면, 방향이 뒤집혔을 때 그 책임이 당신에게 굴러옵니다. 시작 전에 "누구 결정입니까"를 확인하는 30초가, 며칠의 재작업을 막습니다.
작게 쪼갭니다. 요구사항이 자주 바뀌는 환경에서 크게 한 번에 만드는 건, 폐기될 결과물을 크게 만드는 것과 같습니다. 뒤집혀도 손실이 작도록, 되돌리기 쉬운 단위로 자릅니다. 잦은 변경은 작은 단위 앞에서만 감당할 만해집니다.
PM 간 다툼에 편들지 않습니다. 어느 쪽 PM의 편을 드는 순간, 당신은 실행자에서 정치의 당사자로 강등됩니다. "최종 결정이 내려오면 그에 맞춰 구현하겠습니다." 이 태도는 회피가 아니라, 당신의 자리를 실행의 자리로 지키는 방어선입니다.
감정은 아껴라, 그게 가장 오래 남는다
반복되는 비효율에 매번 반응하면, 지치는 건 결국 당신뿐입니다. 바꿀 수 없는 구조에 감정을 쏟는 건, 새는 통에 물을 붓는 일입니다.
의견은 근거와 함께 한 번 제시하고, 받아들여지지 않으면 결정을 따릅니다. 설득에 매달리기보다, 맡은 범위를 정확히 해내고 그 결과를 숫자로 남깁니다. "이 구조로 하면 이런 수치가 나옵니다"는, 열 번의 회의보다 조용하고 강합니다.
튀지 않는데 빠지면 티가 나는 사람. 소란 없이 결과로 증명하는 사람. 결정이 흔들리는 조직일수록, 흔들리지 않고 자기 일을 해내는 사람의 값어치는 오히려 또렷해집니다.
그래서, 오늘의 질문
일이 안 될 때 당신이 던진 질문은 무엇이었나요.
"내가 느린가"였다면, 당신은 바꿀 수 없는 걸 붙잡고 자신을 갈고 있었던 겁니다. "구조가 막혔나"였다면, 당신은 이미 바꿀 수 있는 자리를 보고 있는 겁니다.
병목은 대개 당신이 아닙니다. 그걸 정확히 알아보는 것부터가, 살아남는 사람의 첫 수입니다.