12개월간의 AI 생성 Pull Request가 우리 엔지니어링 팀에 가르쳐준 것

2025년 초 우리 플랫폼 팀이 모든 저장소(Repository)에 AI 코딩 어시스턴트(AI coding assistants)를 도입했을 때, 나는 생산성 향상을 기대했다. 하지만 내가 예상하지 못했던 점은 가장 가치 있는 교훈이 성공이 아닌 실패로부터 왔다는 사실이다. AI가 코드 작성에 유의미한 역할을 했던 약 4,200개의 병합된 풀 리퀘스트(Pull Requests, PR)를 검토한 결과, 나타난 모습은 내가 읽었던 대부분의 마케팅 자료와 상반되었다. AI 인프라에 대한 6,440억 달러(USD) 규모의 베팅이 실리콘밸리와 그 너머의 자본 흐름을 재편하고 있는 만큼, 이 기술 뒤에 숨겨진 경제적 모멘텀은 부정할 수 없다. 하지만 이러한 도구들로 실제 프로덕션 소프트웨어를 배포하는 일상적인 현실은 그 어떤 키노트(Keynote) 발표가 시사하는 것보다 더 복잡하고, 미묘하며, 궁극적으로 더 흥미롭다. 이것이 우리가 배운 것, 우리가 바꾼 것, 그리고 시작하기 전에 누군가 우리에게 말해줬으면 했던 것들이다.

생산성 수치는 실재하지만 오해의 소지가 있다. 우리의 내부 텔레메트리(Telemetry)에 따르면, AI 지원이 표준 관행이 된 이후 개별 개발자들의 코드 라인 수(Line count) 기준 배포량이 26%에서 55% 사이로 증가했다. 이는 명백한 승리처럼 들리며, 좁은 맥락에서는 실제로 그렇다. 보일러플레이트 생성(Boilerplate generation), 테스트 스캐폴딩(Test scaffolding), API 클라이언트 래퍼(API client wrappers), 그리고 일상적인 리팩터링(Refactoring) 작업은 모두 몇 시간에서 몇 분으로 단축되었다. 우리 팀의 한 주니어 엔지니어는 이전 워크플로(Workflow)였다면 6주가 걸렸을 레거시 ETL 파이프라인을 3일 만에 다시 작성했다. 하지만 코드 양은 잘못된 지표이며, 우리는 이를 거의 즉시 깨달았다. 4개월 차에 접어들자 우리의 장애 발생률(Incident rate)은 전년 대비 31% 상승했다. 되돌리기(Reverts) 작업이 늘어났고, 평균 해결 시간(Mean time to resolution, MTTR)은 더 길어졌다. 사후 분석(Postmortems)을 파헤쳐 보았을 때 한 가지 패턴이 나타났다. 회귀(Regressions) 현상은 AI가 생성한 코드 자체의 치명적인 버그인 경우는 드물었다. 그것들은 미묘한 통합 실패(Integration failures), 모델이 알 수 없었던 엣지 케이스(Edge cases), 그리고 로컬에서는 작동하지만 시스템의 다른 부분에 있는 명시되지 않은 관례를 위반하는 제안들을 수락함으로써 누적된 복잡성 때문이었다.

METR에서 널리 퍼진 연구에 따르면, 익숙한 코드베이스에서 작업하는 숙련된 개발자들은 스스로가 20% 더 빨라졌다고 믿었음에도 불구하고 실제로는 AI 어시스턴트(AI assistants)를 사용할 때 19% 더 느려진 것으로 나타났다. 성숙한 서비스의 유지보수 작업을 신규 개발(greenfield work) 작업과 분리했을 때 우리가 자체 데이터에서 관찰했던 결과는, AI 개발 생산성에 관한 METR의 무작위 대조 시험(randomized controlled trial) 결과와 일치한다. 생산성 이야기는 전적으로 맥락(context)에 달려 있으며, AI가 빛을 발하는 맥락은 대부분의 시니어 엔지니어들이 시간을 보내는 맥락이 아니다.

아무도 경고하지 않았던 리뷰 병목 현상 (The Review Bottleneck Nobody Warned Us About)
AI 도입이 우리에게 강요한 단일 최대의 운영적 변화는 코드 리뷰(code review)의 완전한 재구조화였다. 개발자가 20분 만에 그럴싸해 보이는 800줄의 코드를 생성할 수 있게 되면, 병목 현상은 즉시 그리고 영구적으로 그것을 리뷰해야 하는 사람에게로 이동한다. 우리의 시니어 엔지니어들은 3개월 이내에 번아웃(burnout)을 겪기 시작했다. 리뷰 대기열은 늘어났고, PR(Pull Request)은 며칠 동안 방치되었다. 작업량이 너무 많아 세심한 리뷰가 불가능해지자 사람들은 변경 사항을 형식적으로 승인(rubber-stamping)하기 시작했다.

우리는 결국 워크플로우(workflow)를 뒤집음으로써 이 문제를 해결했다. 이제 작성자는 AI의 도움을 받은 모든 변경 사항에 대해 5분 미만의 녹화된 영상을 통해 리뷰어에게 내용을 설명해야 한다. 영상에는 코드가 무엇을 하는지, 왜 이 접근 방식을 선택했는지, 그리고 무엇을 수동으로 검증했는지가 포함되어야 한다. 영상 요구 사항은 관료적으로 들릴 수 있지만, 두 가지를 달성했다. 첫째, 작성자가 자신이 생성한 코드를 실제로 이해하도록 강제함으로써 위험한 지식 격차(knowledge gap)를 메웠다. 둘째, 리뷰어의 시간을 존중하는 시작점을 제공했다. 리뷰 속도는 6주 이내에 회복되었고, 병합(merged)된 코드의 품질은 측정 가능한 수준으로 향상되었다.

실제로 효과가 있는 것 (What Actually Works)
1년간의 실험 끝에, 몇 가지 관행이 AI 도구로부터 이득을 얻는 팀과 그 결과물에 잠겨버리는 팀을 갈라놓았다. 이 중 혁명적인 것은 없지만, 이를 일관되게 적용하는 데 필요한 규율(discipline)이 차별화 요소임이 드러났다.

생성 전의 엄격한 명세(specification)가 프롬프트 엔지니어링(prompt engineering) 기술보다 더 중요하다. 어시스턴트(assistant)를 호출하기 전에 상세한 수락 기준(acceptance criteria), 타입 시그니처(type signatures), 그리고 예시 입력(example inputs)을 작성한 엔지니어들은 자연어(natural language)로 의도를 설명한 엔지니어들보다 훨씬 더 나은 결과를 얻었다. 모델은 문자 그대로를 따르는 협업자(literal-minded collaborator)다. 모호한 지침을 주면 모델은 종종 확신에 찬 태도로 모호한 코드를 생성한다. 사소하지 않은 모든 변경 사항에 대해 테스트 우선(test-first) 워크플로우는 타협할 수 없는 필수 사항이 되었다. 구현(implementation)을 생성하기 전에 테스트를 작성하는 것은 기존에 타입 시스템(type systems)이 단독으로 수행하던 역할을 완수한다. 즉, 탐색 공간(search space)을 제한하고 출력이 올바른지에 대한 객관적인 신호를 제공한다. 이 단계를 건너뛴 팀들은 프로덕션(production) 환경에서 소리 없이 실패하는, 그럴듯해 보이는 코드를 디버깅하는 상황에 직면했다. 아키텍처 경계(architecture boundaries)에서 의무적인 인간 체크포인트(human checkpoints)를 AI 지원과 결합함으로써, 일관성 없는 시스템 설계로 서서히 흘러가는 것을 방지할 수 있었다. 우리는 서비스 경계를 넘나들거나, 새로운 공개 API(public API)를 정의하거나, 인증(authentication) 또는 인가(authorization) 로직을 수정하는 모든 코드에 대해 인간이 작성할 것을 요구한다. 이러한 영역에서 모델은 제안(suggest)은 할 수 있지만, 직접 작성(author)할 수는 없다. 이 규칙 하나만으로도, 이 규칙이 없었다면 배포되었을 여러 차례의 아찔한 사고(near-misses)를 방지할 수 있었다. 관측 가능성(observability)에 대한 투자는 몇 배의 가치를 증명했다. 저장소(repository) 내 모든 코드 라인의 출처(provenance)를 완전히 신뢰할 수 없을 때는, 프로덕션에서 문제를 빠르게 감지할 수 있어야 한다. 우리는 하반기에 트레이싱(tracing), 구조화된 로깅(structured logging), 그리고 알림(alerting)에 대한 지출을 두 배로 늘렸다. 비용은 상당했다. 하지만 이를 수행하지 않았을 때의 비용은 재앙적이었을 것이다.

갑자기 더 가치 있어진 기술들
12개월 동안 우리 팀이 적응하는 과정을 지켜보며, 어떤 엔지니어링 기술이 AI 지원 환경에서 복리로 쌓이고 어떤 기술이 가치가 하락하는지 드러났다. 이는 무엇이 강력한 개발자를 만드는가에 대한 오래된 가정들을 뒤집어 놓았다. 코드를 주의 깊게 읽는 능력은 팀 내에서 단일 항목으로 가장 가치 있는 기술이 되었다.

300줄의 diff (차이점)를 훑어보고 의심스러운 두 블록을 식별할 수 있는 엔지니어는, 오직 테스트에만 의존하여 문제를 잡아내려는 엔지니어보다 10배 더 생산적이었다. 디버깅 (Debugging) 기술 또한 가치가 상승했는데, 이는 AI가 생성한 버그가 표준적인 문제 해결 휴리스틱 (Heuristics)에 저항하는 생소한 형태로 나타나는 경우가 많기 때문이다. 시스템 설계 (System design)와 아키텍처적 판단 (Architectural judgment)은 중요성이 줄어들기는커녕 더욱 중요해졌다. 모델은 당신이 요청하는 그 어떤 개별 컴포넌트 (Component)도 생성할 수 있지만, 당신의 시스템에 실제로 어떤 컴포넌트가 필요한지, 그것들이 어떻게 상호작용해야 하는지, 혹은 어떤 트레이드오프 (Trade-off)를 감수할 가치가 있는지에 대해서는 말해주지 못한다. 성공적으로 적응한 엔지니어들은 전체 시스템을 머릿속에 담아두고, 일관된 전체 구조에 부합하는 구현을 하도록 AI를 유도할 수 있는 사람들이었다. 반대로, API 구문을 기억하거나, 프레임워크의 관용구 (Idioms)를 암송하거나, 보일러플레이트 (Boilerplate) 코드를 빠르게 타이핑하는 능력은 하룻밤 사이에 거의 무가치해졌다. 이러한 기술을 중심으로 자신의 정체성을 구축했던 엔지니어들이 가장 힘든 적응기를 겪었다. 반면, 이러한 것들을 소프트웨어를 구축하는 실제 업무의 부수적인 것으로 여겨왔던 엔지니어들은 변화를 거의 느끼지 못했다.

과거의 나에게: 만약 내가 2025년 1월에 이 도구들을 도입하고 있던 과거의 나에게 메시지를 하나 보낼 수 있다면, 그것은 바로 이것이다: 기술 자체가 어려운 부분이 아니다. 진짜 어려운 부분은 근본적으로 달라진 생산 함수 (Production function)를 중심으로 팀의 리뷰 프로세스 (Review processes), 품질 기준 (Quality bars), 그리고 기술 개발 경로 (Skill development pathways)를 재구축하는 것이다. 이 전환기에서 승리하는 팀은 가장 뛰어난 모델을 가졌거나 가장 영리한 프롬프트 (Prompt)를 사용하는 팀이 아니다. 그들은 AI 보조를 진지한 조직적 변화로 취급하고 그에 따라 투자하는 팀이다. 그 외의 사람들은 아무도 완전히 이해하지 못하는 코드를 더 많이 배포하고 있으며, 전통적인 리팩터링 (Refactoring)으로는 해결할 수 없는 일종의 부채를 쌓아가고 있고, 가장 최악의 순간에 중요한 무언가가 고장 날 때 비로소 그 비용을 깨닫게 될 것이다.