AI 코드 리뷰가 개발의 중심이 된 이유 (에이전틱 코드 리뷰)

6월 18, 2026

코드를 짜는 일은 싸졌다. 클로드 코드나 코덱스 같은 에이전트에게 시키면 몇 분 만에 수백, 수천 줄이 쏟아진다. 그런데 그 코드를 읽고 "이게 맞나"를 판단하는 속도는 1년 전이나 지금이나 똑같다. 구글 크롬 팀의 Addy Osmani가 쓴 글 Agentic Code Review는 이 비대칭을 정면으로 짚는다. 결론부터 말하면, 이제 개발에서 가장 레버리지가 큰 일은 코드 작성이 아니라 코드 리뷰다.

에이전트가 짠 PR을 병합하기 전 3단계: 빠르게 거르고, 위험도로 나눠 보고, 마지막 병합은 사람이 한다.

예전에는 리뷰가 저절로 굴러갔다. 사람이 코드를 쓰는 속도가 느렸기 때문에, 읽는 일은 상대적으로 싸고 빨랐다. 저자의 표현을 빌리면 "코드를 쓰는 게 느리고 비싼 부분이었고, 읽는 건 싸고 빨랐다. 그 전제가 이제 무너졌다." 에이전트는 1,000줄을 몇 분에 뽑지만 사람의 읽기 속도는 그대로다. 그래서 검증이 새로운 병목이 됐고, 병목이야말로 가장 영향력 있는 지점이다.

코드는 4배 늘었는데 가치는 10%만 늘었다

저자가 인용한 2026년 데이터는 이 흐름을 숫자로 보여준다. 보기 편하게 정리하면 이렇다.

지표	변화	의미
코드 산출량	4배 증가	에이전트가 쏟아내는 양 자체는 폭증
실제 전달 가치	약 10% 증가	양이 가치로 이어지지 않음
리뷰 소요 시간	441% 증가	검증 부담이 폭발
리뷰 없이 병합된 PR	31% 증가	아무도 안 본 코드가 늘어남

양은 4배인데 가치는 10%다. 나머지는 어디로 갔나. 리뷰 시간으로, 그리고 아무도 읽지 않은 채 병합된 코드로 갔다. 산출량을 자랑하는 동안 "이해되지 않은 코드"가 쌓이고 있다는 뜻이다.

AI가 짠 코드가 유독 리뷰하기 어려운 이유

사람이 코드를 쓸 때는 의도가 자연스럽게 따라온다. 왜 이렇게 짰는지, 어떤 대안을 버렸는지가 머릿속과 커밋 메시지에 남는다. 에이전트는 추론은 하지만 그 추론을 버린다. 그래서 PR을 리뷰하는 사람이 "이 코드를 처음으로 들여다보는 첫 인간"이 된다.

문제는 여기서 생긴다. 리뷰어가 "왜 이 변경인가"를 거꾸로 재구성해야 하므로 훨씬 느려진다. 작성자는 0초 만에 아는 맥락을, 리뷰어는 코드만 보고 추측해야 한다. 저자의 처방은 명확하다. 에이전트가 의사결정 로그를 PR에 함께 남기게 하면 이 비용이 급격히 떨어진다. 무엇을 바꿨는지가 아니라 왜 바꿨는지, 어떤 대안을 왜 버렸는지를 기록하게 만드는 것이다.

위험도로 나눠서 리뷰하라

모든 PR을 똑같은 깊이로 보면 리뷰어가 먼저 지친다. 저자는 위험도로 나누는 방식을 권한다.

위험도	예시	리뷰 강도
낮음	설정 변경, 문구 수정	린터 + 훑어보기
높음	핵심 비즈니스 로직, 결제, 인증	타입 검사 + 테스트 + 이중 AI 리뷰 + 전담 엔지니어 + 보안 검사

핵심은 "전부 깊게"가 아니라 "위험한 곳에 사람의 집중을 몰아주기"다. 설정 파일 한 줄을 비즈니스 로직과 똑같이 보면, 정작 위험한 코드를 볼 에너지가 남지 않는다.

에이전트 PR을 받을 때 챙길 체크리스트

저자가 제시한 실천법을 내 언어로 정리하면 다섯 가지다.

첫째, 빠르게 걸러낸다. 거대한 에이전트 PR은 사전에 차단한다. 흥미롭게도 에이전트는 피드백을 받으면 작업 자체를 포기하는 경향이 있어서, 거절율이 38%에 이른다. 즉 초반에 "이건 아니다"라고 신호를 주는 게 효율적이다.

둘째, 리뷰 전에 증거를 요구한다. 변경 목적 서술, 관리 가능한 크기의 diff(에이전트 PR은 평균 51% 더 크다), 테스트 실행 결과, 실제로 돌려본 증명을 PR에 붙이게 한다. 증거 없는 PR은 리뷰 큐에 올리지 않는다.

셋째, 테스트 변경을 코드보다 더 신중히 본다. 가장 위험한 패턴은 에이전트가 테스트의 assertion을 잘못된 새 동작에 맞춰 고쳐버리는 것이다. 커버리지 숫자는 높은데 실제로는 틀린 동작을 통과시킨다. 뮤테이션 테스트로 한 번 더 검증할 필요가 있다.

넷째, CI를 움직이지 않는 벽으로 둔다. 모니터할 신호는 분명하다. 제거된 테스트, 건너뛴 린트, 낮춰진 커버리지 임계값, 중복 생성된 헬퍼 함수, 신뢰할 수 없는 입력을 그대로 LLM에 넘기는 프롬프트 주입 위험. 이 신호가 뜨면 통과시키지 않는다.

다섯째, 병합은 항상 사람이 한다. 저자의 문장이 인상적이다. "모델은 호출당할 수 없고, 자기가 내보낸 것에 책임질 수 없다." AI 리뷰는 신호를 주는 센서로 쓰되, 최종 결정과 책임은 사람이 진다.

솔로냐 회사냐에 따라 기준이 다르다

저자는 상황을 둘로 나눈다. 사용자가 없는 개인 프로젝트라면 AI 리뷰에 거의 다 맡겨도 된다. 테스트가 실제로 작동하면 충분하고 나머지는 오버헤드다. 반대로 크고 오래된 엔터프라이즈 시스템이라면 위의 전략 전부가 기본선이다. 위험도 티어링과 입력 기준이 생존을 가른다. 같은 도구라도 책임의 무게가 다르면 기준이 달라야 한다는 뜻이다.

내가 실제로 쓰는 방식

이 글이 특히 와닿은 이유는, 저자의 개인 운영법이 내가 쓰는 방식과 거의 같기 때문이다. 저자는 클로드 코드와 코덱스를 병렬로 돌리고, 위험도로 분류한 뒤, 자신은 고위험 부분만 직접 검토한다고 한다.

나도 백엔드 작업에서 코덱스를 시니어 리뷰어로 세워 둔다. 최근에 외부 인증 API를 다른 업체로 전면 교체하는 작업을 했는데, 코드 자체는 에이전트로 빠르게 만들었지만 그걸 그대로 믿지 않았다. 코덱스에게 "시니어 백엔드 리뷰어 관점에서 이 변경을 검증하라"고 시켜 별도 리뷰를 한 번 더 받았다. 결국 사람인 내가 본 건 가장 위험한 지점, 즉 응답 구조가 어떻게 중첩되는지와 환경 설정값이 빠지지 않았는지였다. 작성은 싸게, 검증은 사람이 몰아서. Addy Osmani가 말한 구조 그대로다.

그래서 내 결론은 분명하다. 에이전트를 더 많이 쓸수록 리뷰 역량이 곧 실력이다. "테스트 통과"가 "누군가 이걸 이해하고 책임질 수 있음"과 같지 않다는 걸 잊지 않는 것. 작성이 싸진 시대에 진짜 희소한 능력은 빠르게 짜는 게 아니라 빠르게 신뢰 여부를 판단하는 일이다.

자주 묻는 질문 (FAQ)

AI가 짠 코드도 결국 사람이 다 봐야 하나요?

전부 같은 깊이로 볼 필요는 없다. 위험도로 나눠서 설정 변경 같은 저위험은 린터와 훑어보기로, 핵심 로직 같은 고위험은 사람이 집중해서 본다. 다만 병합 결정만큼은 사람이 책임진다.

에이전트한테 리뷰까지 시키면 안 되나요?

AI 리뷰는 유용한 센서다. 다만 모델은 장애가 났을 때 호출당하지도, 책임지지도 못한다. AI 리뷰를 신호로 받아들이되 최종 판단은 사람이 한다.

리뷰 시간을 줄이는 가장 빠른 방법은 무엇인가요?

에이전트가 의사결정 로그를 PR에 남기게 하는 것이다. 무엇을 바꿨는지가 아니라 왜 바꿨는지, 어떤 대안을 버렸는지를 적게 하면 리뷰어가 의도를 역추적하는 비용이 크게 준다.

테스트가 다 통과하면 믿어도 되나요?

테스트 통과는 필요조건이지 충분조건이 아니다. 에이전트가 assertion을 잘못된 동작에 맞춰 고쳐놓으면 커버리지는 높아도 틀린 코드가 통과한다. 테스트 변경 자체를 코드보다 더 신중히 봐야 한다.

개인 프로젝트에도 이 모든 게 필요한가요?

아니다. 사용자가 없는 개인 프로젝트라면 테스트만 실제로 작동해도 충분하고, 나머지 절차는 오버헤드다. 위험도 티어링은 책임의 무게가 큰 팀 환경에서 빛난다.

이 블로그 검색

잘난코 블로그