AI 에이전트 1년에 PR 11배, 병목은 사라지지 않고 사람에게로 왔다

닐 카카(Neil Kakkar)는 런던에서 일하는 9년 차 소프트웨어 엔지니어입니다. 블룸버그에서 3년, 포스트호그에서 4년을 일했고 지금은 AI 스타트업 타노에서 첫 엔지니어로 8개월째 일합니다. 그가 한 달에 병합한 PR 수는 포스트호그 마지막 해까지 8~20개였고, 타노로 옮긴 뒤 200개 이상이 됐습니다. 포스트호그 대비 11배입니다.

원문 에세이는 더 프래그매틱 엔지니어(The Pragmatic Engineer)가 창간 5주년을 맞아 연 에세이 공모의 우승작입니다. 응모작 125편 중 1등, 상금은 1만 달러였습니다. 숫자만 보면 AI를 켜자 11배가 됐다는 이야기로 읽히지만, 글의 결론은 반대에 가깝습니다. 빨라진 코드가 만든 새 병목이 사람에게 그대로 남았다는 기록입니다.

포스트호그 8~20개에서 타노 200개로

비교 대상은 규모가 다른 세 조직입니다. 블룸버그는 2만 명 규모의 금융 회사, 포스트호그는 그가 합류할 때 10명에서 지금 200명으로 커진 스타트업, 타노는 그가 첫 엔지니어로 들어간 열 명짜리 회사입니다. 월 병합 PR은 블룸버그에서 포스트호그로 옮기며 2.4배, 포스트호그에서 타노로 옮기며 다시 11배가 됐습니다.

포스트호그 시절의 작업량은 AI가 만든 것이 아닙니다. 2024년 말까지 회사에서 쓴 AI는 탭 자동완성 수준이었고, 반복적인 테스트 작성 정도에 썼습니다. 기능을 통째로 만드는 지금의 에이전트와는 거리가 있습니다. 그래서 이 수치는 AI 이전의 좋은 엔지니어링을 기준선으로 삼은 값입니다.

저자 스스로 단서를 붙입니다. 경력 수준과 회사 규모, 문화가 함께 달라졌으니 AI만의 효과를 분리한 비교는 아니라는 것입니다. 그가 다른 분석에서 인용한 업계 평균 PR 증가 폭은 약 2배입니다. 11배는 평균이 아니라 조건이 전부 맞아떨어진 한 사례입니다.

사라진 병목, 사람 리뷰와 소통 비용

타노에서 사람 코드 리뷰는 선택 사항입니다. 정확히는 코드베이스를 파악한 뒤부터입니다. 그는 합류 3주 뒤에 사람 리뷰 없이도 괜찮다는 판단에 이르렀고, 경험에 따라 최대 8주까지 걸릴 수 있다고 적습니다.

대신 CI에 리뷰 에이전트를 붙였습니다. Claude Code GitHub Actions로 만든 에이전트가 모든 PR에서 돌고, 위험한 변경에는 더 깊게 검사하는 에이전트를 필요할 때 따로 실행합니다. 대부분의 PR에는 자동 리뷰만 있고 동료 리뷰가 없습니다. 덕분에 병합까지 걸리는 시간의 중앙값은 1시간 미만이고, 되돌리기 비율은 이전보다 6분의 1로 줄었습니다.

소통 비용도 줄었습니다. 포스트호그에서 설문 기능 1차 버전은 엔지니어 2명과 디자이너 1명이 한 달 동안 만들었습니다. 백엔드를 고치면 프런트엔드도 같이 고쳐야 해서 대화가 계속 필요했습니다. 지금 같은 기능은 한 사람이 설계부터 프런트엔드와 백엔드까지 맡는 편이 더 빠르다고 그는 적습니다.

새로 생긴 병목, 승인 대기열과 주의력

문제는 다른 팀에 같은 도구를 들였을 때입니다. 사람 리뷰가 의무인 조직에서 코드 생성만 빨라지면, 작성 속도가 아니라 승인 대기열이 처리량을 정합니다. 그는 그런 환경이라면 생산성 향상이 1~2배에 그칠 것으로 봅니다. 옆 동료의 리뷰 시간은 그대로인데 내 PR만 빨리 쌓이기 때문입니다.

리뷰를 걷어낸 뒤에도 병목은 남았습니다. 그는 동시에 3~5개 작업을 굴리고, 타노는 하루에 약 30개 PR을 병합합니다. 에이전트가 만들어 낸 PR을 따라가는 일 자체가 부담이라, 동시 작업 수를 제한해도 하루가 끝날 때 정신적으로 더 지친다고 씁니다.

쉽게 끝낼 수 있다는 이유만으로 새 일을 집어 드는 습관도 생겼습니다. 버그 하나가 들어오면 한 시간이면 끝날 것 같아 바로 세션을 여는 식입니다. 그는 이걸 컴퓨터가 실행보다 작업 전환에 시간을 쓰는 것에 비유합니다. 공유 맥락도 줄어, 한 사람이 넓은 영역을 맡는 구조에서 버스 팩터가 1에 가까워지는 문제를 지적합니다.

실제로 터진 사고 두 건

자동 리뷰만 통과한 코드는 값을 치렀습니다. 통화 보고 기능에서 에이전트는 최소 단위를 부동소수점으로 읽고 모든 통화에 100을 곱하는 코드를 썼습니다. 바레인 디나르는 1디나르가 1,000 fulūs라 100을 곱하면 틀립니다. 회사에는 통화 계산용 유틸리티가 이미 있었고, 사람 리뷰라면 그걸 쓰지 않은 점을 바로 잡았을 겁니다. 배포 직후 숫자가 안 맞는 걸 발견해 한 시간 안에 고쳤습니다.

데이터베이스 쪽은 더 컸습니다. 포스트그레스의 posts 테이블이 약 25GB, 600만 행까지 커졌는데 부분 인덱스를 추가하는 마이그레이션이 쓰기를 막았습니다. 수집 파이프라인이 새 글을 저장하지 못했고 배포도 타임아웃으로 실패했습니다. 이후 이런 작업은 동시 인덱스 생성으로만 하고, 리뷰 에이전트 지침에 큰 테이블 목록과 차단형 마이그레이션 금지 규칙을 넣었습니다.

아키텍처를 옮기는 과정에서는 보호 장치를 빠뜨려 같은 작업에 크리에이터에게 두 번 지급하는 사고도 났습니다. 그는 이걸 감수한 교환이라고 적습니다. 새 구조를 빨리 깔아야 확장이 됐기 때문입니다. 사고 유형은 리뷰 에이전트의 검사 항목에 추가했습니다.

따라 하려면 도구보다 순서

그가 강조하는 건 모델 선택이 아닙니다. 업무 방식이 그대로면 도구 효과도 제한된다는 것입니다. 사람 리뷰 의무, 승인 단계, 제품 결정 권한 같은 것부터 손봐야 PR이 늘어난 만큼 결과가 나옵니다.

경계도 필요합니다. 타노의 핵심 근무 시간은 오전 9시부터 오후 6시까지이고, 그는 노트북을 회사에 두고 퇴근해 로컬 에이전트를 1~2시간 더 돌립니다. 결과는 다음 날 오전에 봅니다. 오전 9~11시에 여는 PR 비중은 포스트호그 9%에서 타노 18%로 올랐습니다. 밤새 쌓인 결과를 아침에 처리하는 흐름입니다.

비용도 무제한이 아닙니다. 팀원 각자 20x Claude Max 구독 1개를 쓰고, 이 사용량을 API 요금으로 환산하면 월 8,000달러 이상입니다. 그는 토큰을 최대한 쓰는 것을 목표로 삼지 않는다고 밝힙니다. 구독 한도가 오히려 중요한 작업을 고르는 제약으로 작동합니다.

마지막으로 그가 남기는 단서는 PR 수와 사업 성과를 구분하라는 것입니다. 제품 시장 적합성, 매출, 단위 경제성은 PR 빈도로 대체되지 않습니다. 이미 잘 돌아가는 사업이라면 프로세스를 바꾸는 데 더 신중해야 한다고 적습니다.

에이전트가 코드를 쓰는 속도는 계속 빨라질 겁니다. 원문에서 바뀌지 않은 건 사람이 확인할 수 있는 양입니다. 도구를 들이기 전에 리뷰와 승인 단계를 먼저 세어보는 편이 순서에 맞습니다.

원문: How software engineering is changing: a tale of two eras (The Pragmatic Engineer, 2026년 11월)