기계가 코드를 읽고 사람이 승인하는 시대가 온다

주 저장소의 검토 준비가 끝난 모든 풀 리퀘스트를 자체 제작한 검토 에이전트 Hopper가 먼저 읽는다. 이 글은 Hopper를 만들며 얻은 수치와 교훈을 공유하고, 2027년 10월까지 팀의 코드 검토가 어떻게 바뀔지에 관한 여덟 가지 전망을 내놓는다. 핵심은 기계가 모든 변경 사항을 읽고, 회사에 피해를 줄 수 있는 변경은 사람이 승인하며, 컴플라이언스가 이 구분을 의무화한다는 것이다.

사람이 코드를 쓰지 않는다면

지난달 DHH는 Rails World 기조연설에서 37signals가 손으로 코드를 작성하는 일을 중단했다고 말했다. 프로그래머의 행복과 아름다운 Ruby를 20년간 옹호한 그는 에이전트에게 HEY 백엔드를 Rust로 다시 만들게 하고 있다. 그는 Rust를 읽기 고통스러운 언어라고 불렀으며, 이제는 직접 코드를 읽을 필요가 없다고 한다. 기조연설은 “전적인 낙관”으로 끝났다. 여기에 덧붙이고 싶은 문제는 검토다. 사람이 코드를 쓰지 않고 읽지도 않는다면, 잘못된 변경을 찾아낼 다른 수단이 필요하다.

지난주 Anthropic은 Claude가 Claude Code 코드의 약 90%를 작성하는 상황에서 자사의 코드 검토 방식을 공개했다. 애디 오스마니(Addy Osmani), 모건 웨스트리 런트(Morgan Westlee Lunt), 칭 왕(Qing Wang)이 쓴 글에 따르면, Anthropic은 검토 절차를 유지하되 대부분의 읽기를 기계에 맡기고 기계가 잘하지 못하는 부분은 사람에게 남겼다. 분류기가 변경 사항마다 위험 등급을 매기고, 등급에 따라 사람 검토자를 0명, 1명 또는 2명 배정한다. 검토자가 없는 경로는 신뢰 목록에 있는 작성자만 이용할 수 있다. CI 워크플로 파일처럼 항상 사람의 검토가 필요한 변경도 있다. Anthropic은 “에이전트의 승인은 사람의 승인으로 간주되지 않는다”고 명시했다.

변경을 요청한 사람은 테스트 방법과 되돌리는 방법을 확인하고 승인한다. 팀에는 “변경을 반영한 사람이 책임진다”는 원칙이 있으며, 변경으로 문제가 생기면 보통 해당 변경을 올린 사람이 수정한다. 검토 에이전트는 과거에 사고를 일으킨 풀 리퀘스트를 대상으로 매일 테스트한다. 검토가 세 차례 진행된 뒤에도 의견이 모이지 않으면 작성자에게 접근 방식을 다시 생각하라고 요청한다. 풀 리퀘스트 하나가 밤새 50회 넘게 검토된 뒤 도입한 규칙이다.

6월부터 9월까지 Claude Code에 병합된 풀 리퀘스트는 두 배 넘게 늘었지만, 되돌리기가 필요했던 비율은 40% 넘게 떨어졌다. 검토도 더 빨리 수렴했다. 검토를 재설계한 뒤 5회 이상 검토가 필요했던 풀 리퀘스트 비율은 8.9%에서 1.5%로 줄었다.

Anthropic의 모노레포에 반영되는 변경은 5월 하루 약 2,500건에서 9월 하루 30,000건 이상으로 늘었다. 검토 방식을 공개한 주에 Code Review가 Team 및 Enterprise 요금제에서 정식 제공되기 시작했다. Anthropic의 자사 인력 보고서는 에이전트의 작업 시간이 직원 작업 시간의 6배에 이르며, 에이전트의 대화형 세션 시간 중 약 80%가 사람을 기다리는 데 쓰인다고 밝혔다. 코드 작성은 저렴해졌지만 이를 읽고 승인하는 사람은 더 빨라지지 않았다. 기다리는 시간의 상당 부분이 검토 때문이라고 본다.

AI가 작성한 코드의 품질을 둘러싼 연구

순다르 피차이는 4월 구글의 새 코드 중 75%가 AI로 생성되고 엔지니어의 승인을 받는다고 썼다. 이는 전년 가을의 50%, 2024년 말의 4분의 1 이상에서 늘어난 수치다. 회사마다 집계 방식이 다르므로 정확한 수치보다 추세가 중요하다.

코드 품질에 관해서는 연구 결과가 엇갈린다. 구글의 DORA 연구는 AI 도입이 늘수록 처리량이 늘지만 불안정성도 커진다고 밝혔다. 코드 검토 업체 CodeRabbit은 오픈소스 풀 리퀘스트 470건을 분석해 AI가 작성한 변경에서 문제가 약 1.7배 더 많이 발견됐다고 보고했다. 다만 이는 검토 서비스 업체의 데이터다. Anthropic의 인력 보고서는 같은 사람을 같은 달, 같은 디렉터리에서 비교했으며 에이전트가 작성한 코드가 나중에 제거되거나 되돌려지는 빈도에 차이가 없다고 밝혔다.

세 결과는 모두 동시에 참일 수 있다. AI가 쓴 코드의 품질은 이를 검토하는 시스템의 품질에 달려 있다. 하지만 대부분의 팀은 사람이 하루에 몇 건씩 변경하던 때를 기준으로 만든 검토 절차를 여전히 사용한다.

작은 수정에서 나온 열여섯 가지 지적

지난 금요일 AI 플러그인용 오픈소스 스캐너 hol-guard에 작은 수정 사항을 보냈다. 위험한 Codex 샌드박스 설정을 단순히 언급한 문서까지 ‘승인 우회’ 검사에서 걸러내고 있어, 수정 사항은 설정을 언급하는 문장과 실제 지시를 구별하도록 했다.

저장소에는 AI 검토 봇 네 개가 설치돼 있었다. CodeRabbit, Qodo, Gitar 세 봇이 검토했고 Greptile은 실행 조건에 따라 건너뛰었다. 유지관리자 두 명도 검토했다. 한 명은 재현한 거짓 음성 세 건을 들어 수정을 요청했고, 다른 한 명은 내 브랜치에 직접 수정 사항을 반영했다. 변경은 커밋 10개를 거쳐 올린 지 5시간 반 만에 병합됐다.

봇은 빨랐고 대부분 정확했다. 지적 16건 가운데 15건은 세 가지 약점이 반복해서 드러난 것이었다. 블록 인용·목록·중첩 목록 안의 코드와 잘못된 깊이에서 닫힌 코드 펜스를 제대로 다루지 못하는 자체 Markdown 파서, 부정 표현이나 경고 문구와 설명문으로 작성된 설정 절차를 정규식으로 읽는 방식, 그리고 어떤 파일을 지시 사항으로 볼지에 관한 문제였다. 하나씩 수정했다. 한 봇의 요약에는 초록색 ‘Approved’ 배지까지 있었지만, Anthropic의 규칙에 따르면 이는 사람의 승인으로 간주되지 않는다. 작은 수정 하나를 봇 세 개와 유지관리자 두 명이 검토해 모든 사례를 찾아냈지만, 봇과 사람 모두 그 배경에 있는 약점을 직접 지적하지는 못했다.

Hopper를 만들며 배운 점

주 저장소에서 검토 준비가 끝난 모든 풀 리퀘스트를 Hopper가 살펴보지만, 병합은 여전히 사람이 승인한다. Hopper는 Claude Opus 5.5로 작동한다. Hopper가 자체 검토 중에 발견했다가 넘긴 우려 사항은 두 번째 검토자에게 전달한다. 두 검토자는 각각 Opus 5.5와 GPT-6 Astra를 사용한다.

Hopper가 놓친 결함을 살펴보니, 확인한 표본 24건 중 13건은 Hopper가 추론 과정에서 알아차렸지만 사소하거나 이미 처리됐다고 판단해 넘긴 문제였다. 발견한 내용을 끝까지 확인하라는 프롬프트를 추가해도 달라지지 않았다. 효과가 있었던 방법은 넘긴 우려 사항과 이를 제외한 이유, 관련 파일을 새로운 맥락에서 검토하는 두 번째 검토자에게 전달하는 것이었다. 두 번째 검토에서도 살아남은 우려 사항 30건 중 27건은 실제 문제였다.

서로 다른 모델 계열은 서로 다른 버그를 찾는다. 두 번째 검토자에게 같은 프롬프트를 주고 모델만 바꿔 비교했다. 다시 검토한 사례 19건에서 GPT 검토자는 Claude가 놓친 실제 결함 16건을 찾았고, Claude는 GPT가 놓친 결함 4건을 찾았다. 어느 쪽도 실제로는 문제가 아닌 정확성 지적을 내놓지 않았다. GPT는 경쟁 상태와 논리 반전에 강했다. 예를 들어 ‘5보다 작은 값’을 거부하는 필터나, 첫 메시지 두 개가 동시에 들어와 대화가 둘로 나뉘는 문제를 찾았다. Claude는 수정 뒤 오래된 상태로 남는 UI 데이터를 더 잘 찾아냈다.

다만 GPT는 차단 지적 21건 중 6건에서 심각도를 과장했고, Claude는 6건 중 그런 경우가 없었다. 따라서 최종 판정에는 두 검토자의 지적을 합친다. 심각도에 의견 차이가 있으면 Hopper가 높은 심각도를 검증한 경우가 아니라면 낮은 쪽을 적용한다. GPT만 제기한 차단 지적은 Hopper가 해당 경로를 직접 확인한 경우에만 차단으로 남긴다.

검토자를 만드는 것보다 성능을 측정하는 일이 더 어렵다. 처음에는 재현 테스트의 재현율이 지나치게 높게 나왔다. 과거 풀 리퀘스트를 다시 실행할 때 검토자가 나중에 올라온 수정 커밋의 이름이나 검토 뒤에 편집된 설명을 볼 수 있었기 때문이다. 미래 정보를 볼 수 있는 실행은 결함의 68%를 찾았지만, 정보가 새지 않은 실행은 44%를 찾았다. 이제 모든 실행에서 정보 누출 여부를 검사하고 결과를 따로 집계한다.

사람 검토자가 지적한 차단 결함을 기준으로 보면 Hopper의 발견률은 약 45%다. 하지만 이 수치는 Hopper의 성과를 과소평가한다. 추가 지적 30건을 살펴본 한 표본에서는 25건이 실제 문제로 확인됐고, 틀렸다고 입증된 지적은 없었다. 대부분은 사람이 언급하지 않은 버그였다. Hopper가 내놓는 지적 중 96%는 사실에 부합하지만, 실제로 중요한 문제는 약 4분의 1이다. 엔지니어들이 반박하는 경우는 거의 없다.

Hopper의 규칙 대부분은 실수에서 나왔다. Hopper는 풀 리퀘스트를 승인하지 못한다. 프롬프트에 승인하지 말라고 적는 대신 도구 권한에서 승인 권한을 제거했다. 봇의 초록색 배지는 실제보다 승인자가 한 명 더 있는 것처럼 보일 수 있기 때문이다. 첫 주에는 다른 검토자가 하지 않은 말을 지어내 지적한 일이 있었다. 이제 검토자, 버전, CI 결과 또는 라이브러리에 관한 주장은 근거가 된 링크나 명령을 함께 제시해야 한다.

때로는 판정에 포함된 지적이 실제 인라인 댓글에는 실리지 않아 별도의 댓글로 올라가거나 사라졌다. 이제 판정의 지적 수와 인라인 댓글 수가 일치하지 않으면 검토를 거부하는 보호 장치가 작동한다. 이 장치는 검토 181건에서 실제 누락 5건을 잡았다. 초기에 실행 예산이 다 떨어져 생각을 마치지 못한 채 끝나면서 검토 비용의 28%는 아무 결과도 내놓지 못했다. 지금은 예산이 소진된 실행에 마지막 단계를 한 번 더 주고, 부분 결과라고 표시해 지금까지의 내용을 게시하는 것만 허용한다.

Hopper의 맹점은 코드를 실행해야만 알 수 있는 문제다. 세션 중간에 새로고침하거나 사용자가 화면을 벗어날 때 나타나는 수명주기 및 실행 시점 버그는 코드를 읽는 것만으로 거의 찾아내지 못한다. 그래서 두 번째 전망은 코드를 실제로 실행하는 검토에 관한 것이다.

먼저 적용해 볼 다섯 가지

검토 에이전트를 운영하거나 만들 계획이라면 다음 방법을 대체로 효과 대비 비용이 낮은 순서로 적용할 수 있다.

• 프롬프트로 승인을 금지하는 데 그치지 말고 에이전트 자격 증명에서 승인 권한을 제거한다.
• 검토자가 무엇을 발견했고 왜 제외했는지 기록하게 한다. 그 우려 사항을 새로운 맥락과 같은 프롬프트를 사용해 다른 모델 계열의 검토자에게 전달한다.
• 재현율 수치를 신뢰하기 전에 재실행에서 수정 사항을 볼 수 있었는지 확인한다.
• 모든 주장에 근거가 되는 링크나 명령을 붙인다.
• 요약과 인라인 댓글이 일치하지 않는 검토는 거부한다.

2027년 10월을 내다본 여덟 가지 전망

다음은 앞으로 1년 동안의 변화를 예상한 것이다. 각 전망의 확신도와 틀렸다고 판단할 기준도 함께 제시한다.

• 사람은 코드를 직접 입력하지 않아도 책임은 계속 진다. 탄탄한 팀에서는 프로덕션 코드 대부분을 사람이 손으로 쓰지 않게 될 것이다. 그러나 책임이 기계로 넘어가지는 않는다. 변경을 요청한 사람이 검토와 사후 분석에서 책임지는 ‘변경을 반영한 사람이 책임진다’는 원칙이 보편화될 것이다.
• 검토는 코드 차이를 읽는 일에서 동작을 입증하는 일로 옮겨간다. 코딩 에이전트는 환경을 시작하고, 수정한 흐름을 직접 클릭해 확인하고, 화면을 비교하고 로그를 읽는 개발 도구를 갖추게 된다. Anthropic 엔지니어 중 상당수는 풀 리퀘스트를 열기 전에 기능을 처음부터 끝까지 확인하는 기술을 이미 사용한다. 프로덕션에 반영하기 전에는 엄격한 검토 에이전트가 실제 환경에서 모든 핵심 흐름을 확인할 것이다. 코드 차이를 읽는 것은 저렴한 첫 번째 필터가 되고, 검토 결과에는 재현할 수 있는 실패 실행이 담길 것이다.
• 코드는 기계가 검사하기 쉽게 작성된다. 여덟 가지 전망 중 확신이 가장 낮다. DHH는 자신이 읽지 않는 Rust 백엔드로 이 방향을 일부 실현하고 있다. 그는 CPU와 메모리를 아끼기 위해 Rust를 택했다. 지난 수십 년간 프로그래밍 언어에 추가된 요소 중 상당수는 사람이 코드를 편하게 읽고 쓰도록 돕기 위한 것이며, Ruby는 읽기 편한 대신 성능 비용을 치르는 사례다. 사람이 코드를 대부분 읽지 않게 되면 이 절충이 뒤집힐 수 있다. 코드는 기계에 더 가까워지고, 컴파일러나 에이전트가 검사할 수 있는 강한 타입·불변 조건·계약으로 보호될 것이다. 현재로서는 이미 존재하는 엄격한 언어가 이 변화를 이끌 가능성이 커 보인다. 에이전트는 학습 데이터에 많이 포함된 언어에서 여전히 가장 저렴하고 안정적으로 작동하며, 사람과 마찬가지로 의미 있는 이름을 필요로 한다. 이름을 제거하면 모델의 코드 이해력이 크게 떨어진다. 에이전트용 로그를 압축한 한 실험에서는 입력 토큰이 17% 줄었지만 세션 총비용은 67% 늘었다. 절약한 정보를 해독하는 데 모델이 비용을 썼기 때문이다. 따라서 에이전트 우선의 새 언어가 등장할 것이라는 전망에는 절반만 걸겠다. 등장한다면 엄격하지만 사람이 읽기 어려운 언어일 것이다.
• 저렴한 의사결정 모델이 모든 줄을 훑는다. 최첨단 모델은 모든 변경 사항의 모든 줄을 깊이 읽기에는 느리고 비싸다. TypeSafe의 Jev처럼 텍스트 대신 유형이 지정되고 보정된 결정을 내리는 새 모델 계열은 각 코드 변경 부분의 위험을 1초도 안 돼 평가하고, 위험한 부분만 비싼 검토자에게 넘길 수 있다. 검토는 빠른 모델이 선별하고, 최첨단 모델이 조사하며, 사람이 승인하는 절차가 된다. Jev라는 이름은 윌리엄 스탠리 제번스에서 따왔다. 그가 설명한 역설은 이 글의 상황과 맞닿아 있다. 코드 작성 비용이 낮아지면 더 많은 코드를 쓰고, 검토 부담도 함께 커진다.
• 사람의 검토는 피해가 큰 변경에 집중된다. 마이그레이션, 프로덕션에 영향을 주는 인프라 코드, 인증, 권한, 결제에는 사람 검토자가 계속 필요할 것이다. 그 밖의 변경 대부분은 Anthropic의 위험 등급 절차처럼 에이전트 검토와 통과 표시를 거쳐 병합될 것이다. 사람 검토자는 의도와 영향 범위를 판단하게 된다. 지금까지 검토에서 제대로 살피기 어려웠던 부분이다. 다만 이런 검토자를 어디서 길러낼지는 우려스럽다. Anthropic의 기술직 채용에서 주니어 비중은 27%에서 9%로 줄었다. 지금 주니어를 뽑지 않으면 2030년에 누가 마이그레이션을 승인할 시니어가 될지 알 수 없다.
• 컴플라이언스가 사람의 승인 절차를 의무화한다. 감사인은 이미 프로덕션 변경을 누가 승인했는지 묻는다. 금융 서비스에 적용되는 EU의 DORA 규정은 변경 승인 기능이 변경을 요청하고 구현하는 기능과 독립적이어야 한다고 요구한다. 여기서 DORA는 구글의 DORA 연구와 관계가 없는 디지털 운영 복원력법(Digital Operational Resilience Act)을 가리킨다. PCI DSS는 사람이 검토한 코드를 작성자 아닌 사람이 확인하고 경영진이 승인하도록 요구한다. SOC 2는 변경이 승인돼야 한다고 요구하지만 승인자가 누구인지는 정하지 않는다. 그래서 기업들은 어떤 변경에 사람이 필요한지를 위험 등급별 정책으로 명시할 것이고, 그 목록은 앞서 말한 전망과 비슷해질 것이다. 소프트웨어를 제품으로 다루는 EU의 새 제품책임지침은 12월까지 각국 법률에 반영돼야 하며, 위험이 큰 변경에 책임자를 지정할 이유를 더한다. Anthropic은 이미 이런 규칙을 두고 있다. 컴플라이언스 업무를 하는 나는 이 전망에 가장 큰 확신을 갖고 있다.
• 검토 대상은 코드보다 명세와 규칙이 된다. 검토 규칙은 코드와 함께 저장소에 있으며, 그 규칙을 바꾸는 풀 리퀘스트부터 적용된다. 명세는 각 모듈이 무엇을 해야 하는지 설명한다. 에이전트가 코드를 쓰면 사람이 가장 큰 가치를 더할 수 있는 곳은 계약이다. 모듈이 무엇을 약속하고 어떤 문제가 병합을 막아야 하는지 정하는 일이다. 명세는 아키텍처를 결정하는 자리이기도 하다. 개별 풀 리퀘스트가 모두 괜찮아 보여도 아키텍처는 나빠질 수 있으며, 사람이나 에이전트가 변경마다 검토해서는 이를 알아채지 못한다. 시스템 구조를 장기적으로 관리할 책임자가 필요하다. 코드보다 명세와 규칙에 더 많은 검토 시간을 쓸 것으로 예상한다.
• 검토자는 소프트웨어처럼 테스트하고, 더 많이 읽기보다 빠르게 되돌리는 데 집중한다. 진지하게 운영하는 팀은 Anthropic처럼 과거 사고 사례로 만든 평가 자료를 사용해 검토 에이전트를 매일 시험할 것이다. 변경 속도가 어느 수준을 넘으면 병합 전에 더 읽는 것보다 문제를 빠르게 발견하고 되돌리는 편이 저렴한 안전망이 되므로, 팀은 탐지와 되돌리기에 더 투자할 것이다. Anthropic은 아직 자동 회로 차단기를 만들지 않았다. 이 장치는 되돌리기나 사고가 늘면 승인 규칙을 자동으로 강화한다. 이런 장치도 표준이 될 것으로 본다.

검토 에이전트를 운영하거나 이 전망에 동의하지 않는다면 의견을 들려주길 바란다. 컴플라이언스에 관한 전망을 빼면 어느 것이든 반론을 듣고 생각을 바꿀 수 있다.