코드 작성 속도가 문제라고 생각했다면 - 더 큰 문제가 있습니다.txt

source https://andrewmurphy.io/blog/if-you-thought-the-speed-of-writing-code-was-your-problem-you-have-bigger-problems

화요일 아침. 엔지니어링 부사장이 슬라이드 덱 앞에 서서 2017년에 암호화폐를 발견한 사람들처럼 흥분 상태에 있습니다. 그들은 방금 컨퍼런스에서 돌아왔거나, 아마도 공급업체 저녁 모임에서 돌아왔을 것입니다. 피노 누아 세 잔에 데모 한 번, 그랬더니 마침내 새로운 소식이 생겼다네요.

"우리는 모든 팀에 AI 코딩 어시스턴트를 도입할 것입니다. 초기 수치에 따르면 코드 출력이 40% 증가했습니다. 이는 우리의 속도를 혁신적으로 변화시킬 것입니다."

방 안에서는 반은 고개를 끄덕이고 나머지 반은 갑자기 노트북에 관심을 가지기 시작합니다. 당신의 직원 엔지니어가 그런 표정을 짓고 있습니다. 그 표정, 아마 알고 있을 것입니다. 무언가를 말할지 아니면 나중에 LinkedIn을 업데이트할지를 계산하는 표정입니다.

중요한 질문은 아무도 하지 않습니다.

“무엇을 향한 속도인가요?”

이제 무슨 일이 일어났는지 살펴보겠습니다. 부사장님이 소프트웨어 배포 조직 전체를 쭉 훑어보더니, 이미 충분히 빠른 딱 한 가지를 골라내서 그걸 더 빠르게 만들겠다고 결정한 겁니다. 조립 라인으로 치면 병목 구간도 아닌 곳을 찾아내 거기다 돈을 쏟아부은 꼴이죠.

시스템이 어떻게 작동하는지 아는 사람이라면, 이것이 단순히 도움이 되지 않는다는 것을 알고 있습니다. 오히려 모든 것을 적극적으로 악화시킵니다.

골드랫과의 대화

1984년, 엘리 골드랫은 The Goal 라는 소설을 썼습니다. 이 소설은 제조업에 관한 것으로, 소프트웨어와 관련성이 이토록 높은 것은 비즈니스 소설로서는 그다지 적절하지 않습니다. 이 책은 기술적으로 소설인 가장 유용한 비즈니스 책이기도 한데, 이는 대부분의 KPI 프레임워크와는 거의 정반대입니다.

핵심 아이디어는 제약 이론입니다. 이론은 다음과 같습니다:

모든 시스템에는 정확히 하나의 제약 조건이 존재합니다. 하나의 병목 현상이죠. 시스템 전체의 처리량은 바로 그 병목 현상의 처리량에 의해 결정됩니다. 병목 현상을 해결하기 전까지는 다른 어떤 것도 중요하지 않습니다.

대부분의 사람들은 그 부분은 이해합니다. 하지만 사람들이 이해하지 못하는 부분은 바로 이것이며, 바로 이 부분이 여러분을 두려움에 떨게 할 것입니다:

보틀넥이 아닌 단계를 최적화하면, 더 빠른 시스템을 얻는 것이 아니라 더 고장 나는 시스템을 얻게 됩니다.

이 문제를 기계적인 관점에서 생각해 봅시다. A 작업대에서 위젯을 더 빨리 생산하더라도, 병목 지점인 B 작업대가 여전히 동일한 속도로만 처리할 수 있다면, 결국 A와 B 사이에 미완성 위젯이 산더미처럼 쌓이게 될 뿐입니다. 재고는 늘어나고, 리드 타임은 길어집니다. B 작업대의 직원들은 이제 업무에 허덕이게 됩니다. 쌓인 작업물 때문에 다음에 무엇을 처리해야 할지 혼란스러워집니다. 모두가 깊이 생각하기보다는 급한 순서대로 처리하느라 바쁘다 보니 품질은 급격히 떨어집니다.

아무것도 빨라지지 않았습니다. 교통 체증을 만들고 이를 생산성이라고 부른 것입니다.

끔찍한 상황: "코드 출력을 3배로 늘리면 실제로 일어나는 일"

이미 이 상황을 경험하고 있는 분들이 있을 것입니다. 저도 경험해봤습니다. 정말 힘들었습니다.

개발자들이 그 어느 때보다도 빠르게 PR을 생성하고 있습니다. 훌륭합니다. 멋집니다. 금별을 줘야 합니다. 누군가 축하 폭죽을 준비해 주세요. 이제 그 PR이 리뷰 큐에 들어갑니다. 그런데 리뷰어는 세 배로 늘지 않았습니다. 리뷰어를 세 배로 늘리겠다는 생각조차 하지 않았습니다. 왜냐하면 리뷰어는 공급업체의 슬라이드 덱에 없었기 때문입니다.

그래서 PR은 그대로 쌓입니다. 하루, 이틀, 일주일. 작성자는 AI 지원 기능으로 전환했으며, 리뷰 코멘트가 도착했을 때 첫 번째 기능이 무엇을 했는지 거의 기억하지 못합니다. "이 함수가 무엇을 하는지 설명해 주실 수 있나요?"라고 묻습니다. 이 질문은 그들이 8일 전에 작성한 코드를 바라보며 한 것입니다. 개발자의 기억으로는 대략 공룡 시대와 같습니다.

리뷰는 단순히 너무 많아서 제대로 검토되지 않고 스탬프를 찍기 시작합니다. 누군가 진짜로 읽지 않은 PR을 승인합니다. 우리 모두 그렇게 해왔습니다(저를 그렇게 쳐다보지 마세요). PR이 병합됩니다. CI는 45분이 걸리고, 불안정한 테스트에서 실패합니다. 재실행되면 두 번째 시도에서 통과합니다(불안정한 테스트는 괜찮습니다. 항상 괜찮습니다. 하지만 그렇지 않을 때가 오고, 당신은 토요일 새벽 2시에 속옷을 입고 프로덕션에서 디버깅을 하며 인생에서 무엇이 잘못되었는지 궁금해하게 됩니다. 제가 어떻게 아는지 물어보세요... 사실 물어보지 마세요). 배포 파이프라인은 회의 중인 사람의 수동 승인을 요구합니다. 기능은 "프로덕션으로 가져가는 것" 단계에 긴급성을 가지고 있는 사람이 없어서 3일 동안 스테이징에 남아 있습니다.

한편, 개발자는 이미 두 개의 PR을 더 발송했습니다. 큐는 계속 증가합니다. WIP(작업 중인 항목 수)는 폭발적으로 증가합니다. 모두 여섯 가지 작업을 동시에 진행하고 있지만 실제로 완료된 것은 없습니다. 사이클 타임(사용자에게 가치를 전달하는 속도를 실제로 측정하는 지표)은 악화됩니다.

코드는 더 많이 작성하고 있는데, 출시하는 소프트웨어는 줄어들고 있습니다. 상황을 명백하고도 측정 가능하게 악화시켰으면서도, 생산성이 40% 상승했다는 대시보드가 표시되고 있습니다.

축하합니다. 재고를 생성하는 데 세계적 수준의 공장을 세웠습니다. 그 재고는 바닥에 쌓여 썩고 있습니다. 누군가 이번에 승진할 것입니다.

저는 이 정확한 상황을 세 개의 다른 회사에서 목격했습니다. 대시보드는 상승하고, 배포는 감소합니다. 그리고 아무도 이 둘을 연결짓지 않습니다. 대시보드는 이사회에 보고하는 것이고, 이사회는 사이클 타임이 무엇인지 모르며, 아무도 이를 설명하는 사람이 되고 싶어하지 않습니다.

그리고 제가 밤에 잠을 이루지 못하게 하는 부분은, 많은 AI 생성 코드가 있습니다. 아무도 이를 완전히 이해하지 못합니다. "작성한" 사람은 실제로 작성하지 않았습니다. 그들은 이를 요청했고, 대충 훑어보고, 아마 한 번 실행했을 것입니다. 프로덕션에서 새벽 2시에 무언가가 고장 나면, 대기 중인 사람은 이를 작성하지 않았고, 요청한 사람은 이를 설명할 수 없습니다. 당신은 사고의 범위를 늘리는 동시에 시스템에 대해 추론할 수 있는 인간의 수를 줄였습니다.

더 많은 코드, 적은 이해. 이는 생산성 향상이 아닙니다. 이는 더 멋진 대시보드를 가진 시한폭탄입니다.

실제 병목은 어디인가요?

코드 작성이 병목이 아니라면(거의 항상 그렇습니다), 어디를 봐야 할까요? 가치 흐름을 따라가세요.

"누군가 아이디어를 갖기"에서 "사용자가 그것으로부터 가치를 얻기"까지 따라가세요. 병목이 튀어나와서 손을 흔들며 인사할 것입니다. 어쩌면 당신을 향해 손가락을 흔들 수도 있습니다. 왜냐하면 당신이 그것을 무시해왔기 때문입니다.

1. 무엇을 만들어야 할지 모른다

이 부분은 누구도 이야기하고 싶어하지 않는 부분입니다. 왜냐하면 부끄럽기 때문입니다. 당신의 PM은 두 달 동안 실제 사용자와 대화하지 않았습니다. 요구사항은 세 문장과 디자인에 대한 Figma 링크가 포함된 Jira 티켓으로 도착합니다. 그 디자인은 제품을 사용해본 적이 없는 누군가에 의해 승인된 것입니다. 당신의 엔지니어들은 아무도 지정하지 않은 행동, 엣지 케이스, 오류 처리를 두고 하루에 50개의 마이크로 결정을 내리고 있습니다. 왜냐하면 아무도 그에 대해 생각하지 않았기 때문입니다.

그리고 그들은 추측하고 있습니다.

한 번은 영업 담당자가 잠재 고객이 통화 중에 했을 법한 말을 요약해 보낸 슬랙 메시지를 바탕으로, 한 팀이 6주나 걸려 기능을 개발하는 걸 본 적이 있습니다. 무려 6주나요. 결국 그 잠재 고객은 구매조차 하지 않았습니다. 그 기능을 사용한 사람은 11명에 불과했고, 그중 9명은 사내 QA 담당자였습니다. 이건 단순히 출시 과정의 문제가 아닙니다. 이건 “젠장, 도대체 우린 뭘 하고 있는 거지?”라고 탄식하게 만드는 문제입니다.

그리고 코드를 더 빨리 작성하는 것은 "아, 도대체"라는 상황에 더 빨리 도착하게 할 뿐입니다.

이 환경에서 코드 출력을 가속화하면 잘못된 것을 만드는 속도가 빨라집니다. 당신은 추측의 자동화를 이루었습니다. 잘못된 기능을 더 빨리 만들고, 배포하고, 실패를 지켜보며, 누군가가 "사용자와 더 많이 대화해야 한다"고 말하는 회고를 하게 됩니다. 그때 모두는 진지하게 고개를 끄덕이지만, 실제로는 아무것도 변화하지 않습니다.

병목은 문제를 이해하는 것입니다. 아무리 빨리 타이핑해도 이를 해결할 수 없습니다.

2. 코드가 "완료"된 후 모든 것

"완료"라는 단어를 따옴표로 묶은 이유는 대부분의 조직에서 코드 작성은 여정의 20%에 불과하기 때문입니다. 나머지 80%는 당신의 코드가 다양한 큐에 앉아 천천히 나이를 먹는 것입니다. 마치 사무실 냉장고에 잊혀진 샌드위치처럼요.

코드를 작성하는 데 오후가 걸린 기능이 프로덕션에 도착하는 데 두 달이 걸리는 것을 목격했습니다. 두 달. 코드가 느려진 것은 아닙니다. 그 주위의 모든 사람이 방해했습니다.

PR 리뷰, CI, 스테이징, QA, 보안 리뷰, 제품 승인, 배포 창, 카나리 롤아웃. 개발자의 브랜치에서 사용자의 화면으로 코드를 가져가는 실제 파이프라인은 일련의 핸드오프, 대기 및 큐로 이루어져 있습니다. 대부분의 시간 동안 당신의 코드는 정지해 있습니다. 누군가가 그것을 바라볼 때까지 기다립니다. 파이프라인이 실행되기를 기다립니다. 존재할 수 있는 권한을 부여받기를 기다립니다.

금요일 오후 4시 55분에 PR 승인이 들어오고 "음, 월요일에 배포되겠군"이라고 생각한 적이 있다면 제가 말하는 것이 무엇인지 정확히 알고 있습니다.

"빠른 수정"이 프로덕션에 도달하는 데 9일이 걸리는 것을 보고, 여섯째 날에 살고 싶지 않다고 느낀 적이 있다면... 맞습니다. 코드는 이미 오래전에 완료되었습니다. 그 이후의 모든 것이 병목이었습니다.

배포 속도를 높이고 싶다면, 어디서 대기 중인지 확인해 보세요. 실제 작업 시간과 대기열에 묶여 있는 시간을 비교해 보세요. 그 비율을 보면 머리를 벽에 박고 싶을 정도로 화가 날 거라고 장담합니다.

3. 배포 신뢰의 악순환

배포를 두려워하는 팀들과 함께 일한 횟수를 셀 수 없을 정도입니다. 테스트는 불안정하고, 관측 가능성은 엉망진창이며, 아무도 카나리아 프로세스를 신뢰하지 않습니다. 게다가 지난번 목요일에 누군가 배포를 진행했다가 모두의 주말을 망쳐버리기도 했죠. 그래서 그들은 어떻게 할까요? 변경 사항을 묶어서 더 큰 규모의 릴리스로 배포합니다. 그러다 보니 위험성은 더 커지고, 배포는 더 두려워지며, 결국 모두가 변경 사항을 더 많이 묶어서 배포하게 됩니다.

축하합니다. 두려움의 악순환을 만들었습니다.

이제 이 환경에 더 빠른 코드 배포 속도를 더해 보세요. 코드는 더 많아지고, 배포에 대한 두려움은 여전합니다. 배치 규모는 커지고, 위험은 커지며, 릴리스 빈도는 줄어듭니다. 이미 배포를 두려워하던 팀에게 배포를 하지 않을 더 많은 이유를 제공한 셈입니다. 정말 대단하네요.

4. 제품을 배포했습니다. 잘 작동했을까요? 누가 알까요?

이 문제는 "무엇을 만들어야 할지 모른다"는 주제와 연결됩니다. 파이프라인의 반대편에 있는 동일한 문제입니다. 당신은 무언가를 만들었습니다. 그것을 배포했습니다. 그런데... 아무것도 없습니다. 주목할 만한 분석 데이터도 없고, 출시 후 사용자 인터뷰도 없습니다. 기능이 실제로 해결해야 할 문제를 해결했는지 확인하기 위해 다시 돌아오는 사람도 없습니다.

그러니 다음 기능도 추측하게 되고, 그 다음 기능도 마찬가지죠. 제품 로드맵 전체가 서로 피드백이 전혀 없는 일련의 추측에 불과한 셈입니다.

이 환경에서 더 빠른 코드 출력은 "만들고, 배포하고, 어깨를 으쓱하는" 사이클을 더 빠르게 돌리는 것일 뿐입니다.

"이게 효과가 있었는지 전혀 모르겠다"는 상황이 더 자주 발생하고, 매번 아무것도 배우지 못한 채 그것을 속도라고 부릅니다.

5. 당신의 일정은 하중 지탱 벽입니다

때로는 병목 현상이 전혀 기술적인 문제가 아닐 때가 있습니다. 바로 결정을 내리기 위해 필요한 회의 때문이죠. API 계약에 합의해야 하는데 한 달 동안 서로 대화조차 나누지 않은 세 팀이 바로 그 예입니다. 모든 중요한 설계 결정에 대한 최종 승인 권한을 가진 아키텍트가 있는데, 한 사람의 일정이 시스템의 핵심 기둥이나 다름없는 구조라 2주 분량의 업무가 밀려 있는 경우. 아니면 제가 개인적으로 가장 좋아하는 사례: 6주가 걸리고 분기별로 진행되는 계획 수립 과정 때문에, "계획에 없었기" 때문에 긴급한 작업을 시작하려면 5주를 더 기다려야 하는 경우.

나는 기능이 아직 배포되지 않은 이유에 대한 논의만 하는 방에 앉아본 적이 있습니다. 그 대답은 문자 그대로 "우리는 휴가 중인 사람과의 회의를 기다리고 있습니다"였습니다.

기술적인 문제가 아닙니다. 코드 문제도 아닙니다. 일정 문제입니다. 우리는 기능을 만드는 것보다 기능에 대해 더 많은 시간을 토론하는 데 보냈습니다. 어느 순간 누군가 회의에 대해 논의하기 위한 회의를 하자고 제안했습니다. 농담이 아니길 바랍니다. 이제 샤워가 필요하고, 위스키가 필요합니다.

이것들은 조정 문제입니다. 인간의 문제입니다. 복잡하고 정치적이며, 아무도 책임을 지고 싶어하지 않는 문제입니다.

코드를 더 빨리 작성하는 것은 이 모든 것에 대해 전혀 도움이 되지 않습니다. 제로입니다. 병목 현상은 조직도에 있으며, 어떤 Copilot도 그것을 리팩터링할 수 없습니다.

대신 할 일 (매력적이지 않은 부분)

여러분도 이 부분이 나올 줄 알았겠죠. 지루한 부분 말이죠. 이걸 화려한 일인 척할 생각은 없습니다. 왜냐하면 전혀 그렇지 않으니까요. 아무도 이 주제로 링크드인 게시물을 올리지 않을 겁니다. 벤더 컨퍼런스에서 이 주제로 기조 연설을 하는 사람도 없을 테고요. 기념품 같은 건 더더욱 없습니다.

시작하겠습니다:

가치 흐름을 매핑하세요. 기능이 아이디어에서 프로덕션까지 가는 과정을 실제로 따라가세요. 각 단계를 기록하세요. 각 단계가 얼마나 걸리는지 기록하세요. 단계 간의 대기 시간이 얼마나 되는지도 기록하세요. 이 단계 간의 간격이 당신의 사이클 타임이 존재하는 곳입니다. 이는 우울할 수 있습니다. 그럼에도 불구하고 하세요. 간식도 가져가세요.

산출량이 아니라 사이클 타임을 측정하세요. 코드 줄 수, 병합된 PR, 혹은 “전달된 스토리 포인트”만 측정하고, 커밋부터 프로덕션 배포, 그리고 사용자가 실제로 이를 이용할 때까지 걸리는 시간은 측정하지 않는다면, 잘못된 부분을 최적화하고 있는 것입니다. 마치 A 작업대에서 위젯 개수만 세고 바닥에 쌓인 더미는 외면하는 것과 같습니다. 그만두세요. 진심입니다.

대기 상태를 찾아 제거하세요. PR이 리뷰를 위해 이틀 동안 기다린다면, 리뷰를 개선하세요. 페어 프로그래밍, 더 작은 PR, 전용 리뷰 시간, 비동기 리뷰 규범 등 팀에 맞는 방법을 찾으세요. 배포가 수동 승인을 기다린다면, 자동화하거나 적어도 일정 초대 대신 Slack 버튼으로 만드세요. 결정이 회의를 기다린다면, 회의가 필요 없는 작은 결정을 내리세요.

시작만 하지 말고 끝내도록 하세요. 진행 중인 작업(WIP)에 제한이 있는 데는 다 이유가 있습니다. 진행 중인 일이 열 개 있는 것보다 끝낸 일이 세 개 있는 편이 낫습니다. 진행 중인 모든 작업은 맥락 전환의 부담을 안겨주며, 바로 이 맥락 전환 때문에 훌륭한 엔지니어들도 서서히 정신을 잃어가며, 아무도 읽지 않는 내부 위키에 선언문을 쓰기 시작하게 됩니다.

실제로 일을 하는 사람들과 이야기를 나눠보세요. 개발자들은 이미 병목 현상이 어디에 있는지 잘 알고 있습니다. 스탠드업 미팅에서 그 문제를 불평해 왔고, 몇 달 동안 슬랙에서 그 주제를 소재로 밈을 만들어 왔죠. 그저 아무도 귀를 기울이지 않는다고 생각했을 뿐인데, 솔직히 말해서? 아마 그들이 맞았을 겁니다.

요점

그 화요일 아침으로 돌아가 봅시다. 부사장이 무대에 올라 코드 생산량이 40% 증가했다는 슬라이드를 보여주고 있습니다. 하지만 그분이 말했어야 했고, 실제로 도움이 되었을 말은 다음과 같았을 것입니다. “가치 흐름 분석을 실시한 결과, 기능 개발 단계 간 대기 시간이 평균 9일인 것으로 나타났습니다. 우리는 이 시간을 절반으로 단축할 것입니다.”

그건 매력적이지 않아요. 벤더의 프레젠테이션 자료에 담기에도 어울리지 않고, 제품으로 팔 수도 없죠. 컨퍼런스 발표 주제로도 적합하지 않을 테고요(사실, 이걸 보니 아이디어가 떠오르네요...). 하지만 바로 그 점이 실제로 여러분의 출시 속도를 높여줄 거예요.

코딩 속도는 결코 여러분의 문제가 아니었습니다. 만약 그게 문제라고 생각했다면, 그 믿음과 현실 사이의 간극이 바로 여러분의 진짜 문제가 있는 곳입니다. 경쟁 우위는 코드를 가장 빨리 작성하는 팀에게 돌아가지 않습니다. 그 우위는 무엇을 만들어야 할지 파악하고, 그것을 구축하여, 다른 모두가 아무도 읽을 시간이나 에너지가 없는 AI 생성 PR로 가득 찬 리뷰 대기열에 빠져 허우적거리고 있을 때 이미 사용자에게 전달해 놓은 팀에게 돌아갑니다.

Fix the bottleneck. It's not the keyboard.