월요일 아침입니다. 당신은 '훌륭한' 기술 리더답게 대기 중인 PR(Pull Request)들을 살펴봅니다. 브랜치 이름: codex/something. 변경된 파일 수: 200개 이상. 새로 추가된 코드 라인 수: 40,000줄. 설명: "bugfix". 당신은 아직 diff(차이점)를 들여다보지도 않았지만, 무엇을 보고 있는지 이미 정확히 알고 있습니다. 브랜치 이름이 말해주고 있습니다. 작성자가 말해주고 있습니다(기술적 지식이 없는 공동 창업자입니다). 당신이 지켜보는 동안 이미 댓글을 남기고 있는 버그 봇(bug bot)이 말해주고 있습니다. 당신은 이 패턴을 전에 본 적이 있기 때문에 알고 있습니다. 모두가 이 패턴을 본 적이 있습니다. 다만 보통은 월요일의 공동 창업자가 아니라,

이 부채는 조직이 그것이 쌓이고 있다는 사실을 인지하는 속도보다 더 빠르게 생성될 수 있습니다. 왜 이 특정 PR (Pull Request)이 실제로 세 가지 문제를 안고 있는지 구체적으로 말씀드리겠습니다. 단순히 "이것은 나쁜 PR입니다"라고 말하는 것은 누구에게도 도움이 되지 않기 때문입니다. 첫째, 유지보수가 불가능합니다. 문서화가 되어 있지 않습니다. 결정 사항에 대한 인라인 설명 (inline explanation)이 없습니다. 함수가 왜 그런 방식으로 작성되었는지에 대한 맥락 (context)도 없습니다. 무언가 고장 날 때 — 그리고 반드시 고장 나게 되어 있습니다 — 새벽 2시에 이를 디버깅하는 엔지니어에게는 추적할 수 있는 흔적이 없습니다. 그들은 더 이상 스스로를 설명할 수 없는 모델이 작성한 코드를 읽고 있으며, 그 코드는 내용을 완전히 이해하지 못하는 누군가에 의해 열렸고, 시스템은 이제 근본적으로 변해버린 상태입니다. 둘째, 리뷰가 불가능합니다. 좋은 PR은 하나의 이야기를 들려줍니다. 읽으면서 무엇이 왜 바뀌었는지 이해할 수 있습니다. 하지만 200개의 파일과 4만 줄에 달하는 PR은 이야기가 아닙니다. 그것은 고고학적 발굴 작업입니다. 어떤 리뷰어도 이것을 의미 있게 승인할 수 없습니다. 아무도 의미 있게 리뷰할 수 없는 PR은 테스트 통과 여부와 상관없이 머지 (merge)할 준비가 되지 않은 것입니다. 이는 실제 작업을 건너뛰는 행위입니다. 올바른 방법은 어떤 문제가 존재하는지 이해하고, 티켓 (ticket)을 작성한 뒤, 이 시스템을 유지보수하는 엔지니어들이 충분한 맥락을 가지고 문제를 해결하게 하는 것입니다. 그것이 더 느립니다. 하지만 그것이 누구나 실제로 지원할 수 있는 시스템을 만드는 유일한 방법이기도 합니다.

조절 장치 (governor)가 사라졌습니다. 한 사람이 실수로 코드베이스 (codebase)에 유입할 수 있는 양을 제한하던 것이 있었습니다. 바로 인간의 타이핑 속도입니다. 엔진에서의 조절 장치 (governor)는 물리적인 제한 장치입니다. 운전자에게 속도를 줄이라고 요구하지 않습니다. 그저 엔진이 특정 지점보다 더 빠르게 돌아가지 못하게 할 뿐입니다. 그것이 인프라로서의 제약 (constraint as infrastructure)입니다. 타이핑 속도가 소프트웨어에서의 그 역할을 했습니다. 주말에 혼자 일하는 사람은 자신이 만들 수 있는 문제의 규모에 자연스러운 천장이 있었습니다. 누군가 멈추라고 말해서가 아니라, 그들의 손이 움직일 수 있는 시간이 한정되어 있었기 때문입니다. 그것은 의도치 않은 조절 장치였습니다. 아무도 그것을 설계하지 않았지만, 그냥 존재했습니다. 이제 그것은 사라졌습니다. AI 도구를 가진 누군가가 여유로운 주말을 보낸다면, 과거에 전체 팀이 한 스프린트 (sprint) 동안 배포하던 것보다 더 많은 코드를 생성할 수 있습니다.

그리고 한 개인의 결정 범위(scope)를 제한하던 요소가 더 이상 존재하지 않습니다. 그렇다면 질문은 이것이 됩니다. 무엇이 그 자리를 대신할 것인가? 그 답은 판단력(judgment)이어야 합니다. 그리고 안타깝게도, 판단력은 물리 법칙(physics)보다 훨씬 더 의지하기 어렵습니다. 우리가 솔직하게 말해야 할 어려운 부분은 바로 여기입니다. 여기서부터 어려워집니다. 4만 줄짜리 PR (Pull Request)을 들고 있는 사람이 바로 급여를 지급하는 결정권자라면 어떻게 해야 할까요?

먼저 효과가 없는 방법부터 시작하겠습니다. "이것은 우리의 프로세스(process)를 따르지 않습니다." 맞습니다. 하지만 당신이 지적하는 그 사람이 프로세스의 소유자라면, 그 말은 아무런 힘이 없습니다. "이것은 더 많은 문서화(documentation)가 필요합니다." 이는 완벽주의라는 이유로 묵살됩니다. "이것은 더 작은 단위의 PR로 나누어야 합니다." 작동하는 기능을 보며 엔지니어들이 왜 모든 것을 복잡하게 만드는지 의아해하는 사람에게는 관료주의처럼 들립니다.

더 효과적인 방법은 리스크(risk)를 엔지니어링 용어가 아닌 비즈니스 용어로 재구성하는 것입니다. 질문은 "이 코드가 우리의 표준을 충족하는가"가 되어서는 안 됩니다. 질문은 다음과 같아야 합니다. "이 코드가 머지(merge)된 후, 이 시스템의 책임은 누구에게 있는가?" 이것은 지원 비용(support cost)에 관한 질문입니다. 온콜(on-call) 부담에 관한 질문입니다. 또한 "이 코드를 생성한 사람이 그 기능이 무엇을 하는지 설명하지 못할 때, 인시던트 대응(incident response)은 어떤 모습일 것인가"에 대한 질문입니다. 만약 당신이 PR을 올린 사람에게, 이 코드가 본인이 아닌 엔지니어링 팀에 부채(liability)를 떠넘기게 된다는 점을 인식시킬 수 있다면, 이는 프로세스에 호소하는 것보다 훨씬 더 생산적인 대화가 될 것입니다.

두 번째로 더 효과적인 방법은 구체적인 대안을 제시하는 것입니다. "이것은 틀렸습니다"가 아니라, "올바른 방식은 이렇습니다"라고 말하는 것입니다. 티켓 흐름(ticket flow)을 안내해 주고, 검토 가능한(reviewable) PR이 실제로 어떤 모습인지 보여주세요. 그들이 단순히 벽에 부딪히는 것이 아니라, 나아갈 수 있는 방향을 제시해야 합니다.

효율성 측면의 이점과 생산성 해제(productivity unlock)는 분명히 실재합니다. 목표는 사람들이 AI 도구를 사용하는 것을 막는 것이 아닙니다. 목표는 성과를 가져가는 사람과 비용을 감당하는 사람이 무언가 고장 난 후가 아니라, PR이 열리기 전에 서로 대화할 수 있는 조직을 구축하는 것입니다. 이것은 구조적인 문제입니다. 그렇다면 구조적인 문제를 어떻게 해결할 수 있을까요?

코드 리뷰 시 개인의 용기 있는 행동이 아닌, 구조를 통해 해결해야 합니다. 책임 부채 (Accountability Debt)의 실제 비용은 매우 명확하게 측정 가능한 방식으로 나타납니다:

• 장애 해결 시간 (Incident resolution times)의 증가: 아무도 빠르게 디버깅할 수 있는 문맥 (Context)을 가지고 있지 않기 때문입니다.
• 코드를 생성하지 않았고 그 과정에서 자문을 구하지도 않은 엔지니어들의 온콜 (On-call) 부담 가중
• 향후 개발 속도 저하: 코드베이스 (Codebase)를 이해하고 추론하기가 더 어려워지기 때문입니다.
• 인력 이탈 (Attrition): 유능한 엔지니어들이 이해할 수 없는 시스템을 넘겨받고 그것을 책임지라는 요구를 받는 환경을 떠나기 때문입니다.

하지만 이 중 그 어떤 것도 "주말 동안 기능을 출시함" 옆에 있는 대시보드에는 나타나지 않습니다. 그리고 이것이 바로 문제의 핵심입니다.

이것이 나아갈 방향에 대한 노트
이것은 일시적인 문제가 아닙니다. AI 도구들의 성능이 낮아지거나 접근성이 떨어지지는 않을 것입니다. 효율성이라는 승리를 챙기면서도, 그 비용을 반대 의견을 내기 가장 어려운 사람들에게 소리 없이 전가하지 않는 방법을 찾아내는 조직이 인재 유지, 시스템 신뢰성, 그리고 실제로 성장을 지속할 수 있는 엔지니어링 "문화" 측면에서 우위를 점하게 될 것입니다. 그렇지 못한 조직은 무언가 눈에 띌 정도로 심각하게 망가지기 전까지는 그 어떤 재무제표에도 나타나지 않는 부채를 쌓아가고 있는 것입니다. 그때가 되면, 승리를 거두었던 사람은 대개 이미 다음 단계로 넘어가 있을 것입니다.

듣는 것을 선호하시나요? 저는 Chaotic Commits의 에피소드 5인 'merge conflict: when the diff is 40k lines and the author is the owner'에서 이 내용을 심도 있게 다룹니다. 해당 에피소드에는 PR(Pull Request)에서 실제로 어떤 일이 일어났는지, 그리고 그 권한을 가진 사람이 급여를 지급하는 사람일 때 그 대화를 나누는 기분이 어떤지에 대한 내용이 포함되어 있습니다. 사용하시는 팟캐스트 플랫폼에서 찾아보세요.