PR 리뷰 역설

프로그래머들은 이 시대에 가장 혼란을 느끼는 집단일 수 있으며, 프로그래머가 매일 하는 가장 혼란스러운 일은 PR(Pull Request)을 리뷰하는 것입니다.

• Agent들이 너무 빨리 코드를 작성하고 너무 많은 라인을 생성합니다. 인간은 따라잡기 어려워 대부분의 리뷰는 '승인(Approve)' 버튼을 기계적으로 클릭하며 끝납니다.
• Agent들은 더 이상 낮은 수준의 실수를 거의 하지 않기 때문에, 그들의 코드를 읽는 것은 시간 낭비처럼 느껴집니다.

그래서 어떤 사람들은 하나의 Agent가 다른 Agent의 PR을 리뷰하도록 하는 아이디어를 내놓았습니다. 하지만 이것은 잘 작동하지 않습니다. Agent는 종종 실제 구조적 문제를 놓치고, 지적하는 문제들 역시 사소한 트집(nitpicks)에 불과하며, 그중 일부는 아예 문제가 아닙니다.

다른 사람들은 Agent가 코드를 더 잘 리뷰하도록 돕는 스킬을 구축했습니다. 하지만 다른 관점에서 생각해 봅시다: 만약 우리가 그러한 규칙들을 프로젝트의 ABS(Agent Behavior Specification) 파일에 직접 넣고, Agent가 처음부터 규정을 준수하는 코드를 작성하도록 한다면, 이것이 근본적인 문제를 해결하지 않을까요?

문제가 존재하는 곳

PR 코드 리뷰는 수작업으로 작성된 코드 시대에는 매우 가치 있었습니다. 왜냐하면 인간은 항상 실수를 하기 때문입니다. 다른 프로그래머가 당신의 코드를 읽으면 다음과 같은 일을 할 수 있었기 때문입니다:

• 당신의 코드에서 버그를 잡아낼 수 있다.
• 당신의 코드를 읽음으로써 프로젝트에 익숙해질 수 있다.
• 코드 냄새(code smells)를 발견할 수 있다.
• 당신의 코드가 프로젝트 컨벤션을 위반하는 곳을 지적할 수 있다.

하지만 Agent의 경우:

• Agent들이 오늘날 얼마나 잘 코드를 작성하는지 고려하면, 낮은 수준의 실수를 거의 찾을 수 없습니다.
• Agent는 프로젝트에 익숙해지기 위해 특정 PR을 읽을 필요가 없습니다.
• Agent들은 서로의 작업에서 코드 냄새를 발견하는 데 능숙하지 않습니다.
• 만약 적절하게 설정한다면, Agent는 코드를 작성하기 전에 프로젝트 컨벤션을 로드하므로, 규정 준수 문제는 아예 발생하지 않습니다.

저는 에이전트가 작성한 코드에는 작은 문제란 없으며, 오직 큰 문제만 있을 뿐이라고 자주 말합니다.

또한 저는 두 가지 트렌드를 관찰했습니다.

• 프로젝트가 다수 인원의 유지보수 방식에서 프로젝트당 1인 유지보수 방식으로 전환되고 있습니다. 이는 다른 사람의 코드를 리뷰하는 것을 어렵게 만듭니다. 의미 있는 리뷰에 필요한 프로젝트 간의 맥락 (cross-project context)을 갖지 못하기 때문입니다.
• 에이전트가 작성한 PR (Pull Request)의 규모가 계속해서 커지고 있습니다. 일정 규모를 넘어서면 PR을 리뷰하는 것은 불가능한 미션 (mission impossible)이 됩니다.

새로운 종류의 리뷰

따라서 저는 AI 시대에는 코드 리뷰 방식에 혁명적인 변화가 필요하다고 믿습니다. 구체적으로는 다음과 같은 변화들입니다.

새로운 시점

기존 PR 리뷰의 장점 중 하나는 사람들이 동일한 정보를 공유하지 않거나 동일하게 생각하지 않기 때문에, 한 사람이 놓친 문제를 다른 사람이 잡아낼 수 있다는 점이었습니다. 에이전트 코딩에서는 이러한 비대칭성 (asymmetry)이 거의 존재하지 않습니다. 즉, 다른 사람의 PR을 리뷰하는 것이 더 이상 큰 이득을 주지 못한다는 의미입니다.

그렇다고 리뷰가 불필요하다는 뜻은 아닙니다. 코드가 커밋 (commit) 되기 전에 리뷰해야 한다는 뜻입니다. 타이밍이 변한 것입니다. 에이전트의 스파게티 코드 (spaghetti code)가 레포지토리 (repo)에 푸시 (push) 되기 전에 중단시켜야 하며, 이를 통해 쓸모없는 코드 더미가 서버에 쌓여 다른 엔지니어들의 주의력을 낭비하는 것을 방지해야 합니다.

이것은 당연한 소리라고 말할 수도 있습니다. 당연히 에이전트가 작업을 마친 후에 코드를 확인해야 하니까요. 하지만 실제로는 그렇지 않습니다. 에이전트가 코드를 마쳤다고 알리면서 이미 당신을 대신해 커밋하고 푸시까지 완료해 버리는 경우를 발견하게 될 것입니다. 에이전트가 자동 커밋 (auto-committing) 및 자동 푸시 (auto-pushing)를 하지 못하도록 명시적으로 막아야 합니다. 이는 커밋 락 (commit lock)과 훅 (hooks)을 통해 강제할 수 있습니다.

저의 설정은 에이전트가 코드를 마친 후, CR (commit request)이라고 불리는 임시 커밋 락 (commit lock) 파일을 생성하는 컨벤션 (convention)을 따릅니다. 그리고 에이전트의 훅 (hooks)이 이 CR 파일을 확인합니다. 만약 락 파일이 존재하면 커밋은 거부됩니다. CR 파일은 저에 의해 수동으로 제거되거나, 합의된 프로토콜 (protocol)을 통해서만 제거될 수 있습니다. 저의 규칙은 이렇습니다. 제가 "승인 (approve)"이라고 말할 때만 에이전트가 CR 파일을 삭제하고 코드를 커밋합니다.

새로운 표준

AI 시대에 코드 리뷰의 초점은 사소한 실수를 잡아내는 것에서 다음과 같은 사항들로 전환되어야 합니다:

• 코드 스멜 (Code smells) 확인
• 오버엔지니어링 (Over-engineering) 확인
• 프로젝트의 스타일과 충돌하는 구현 방식 확인
• 코드가 실제로 요구사항을 충족하는지 확인
• 그리고 새로운 관심사: PR (Pull Request)이 너무 크지는 않은지 확인

마지막 항목은 에이전트 코딩 (Agent coding)과 함께 등장했습니다. 지나치게 큰 PR은 그 자체로 문제입니다. 만약 PR이 수천 줄에 달하고 줄일 수 없다면, 작업 자체가 너무 컸던 것입니다. 이는 여러 개의 작고 독립적으로 검증 가능한 작업으로 나누어 단계별로 구현했어야 했습니다. PR은 리뷰하기에 너무 커서는 안 됩니다. 만약 그렇다면, 그것 자체가 하나의 코드 스멜입니다.

합리적인 PR은 한 가지 사항에 집중해야 하며, 설령 그 사항이 많은 코드를 포함하더라도 핵심 아이디어는 단순하고 파악하기 쉬워야 합니다. 예를 들어, 고정된 패턴을 따르는 코드를 일괄 수정(Batch-modify)하는 경우, 변경된 줄은 많을 수 있지만 반복되는 패턴을 쉽게 알아볼 수 있습니다. 인간의 뇌는 반복되는 부분을 건너뛰며, 이는 사고에 부담을 주거나 주의력을 분산시키지 않습니다.

새로운 액션 (New Actions)

읽는 것이 질문하는 것이 됩니다. 과거에는 리뷰란 우리가 직접 코드를 한 줄씩 훑어보는 것을 의미했습니다. 이제 우리는 에이전트에게 그 의도와 설계에 대해 질문하는 것을 습관화해야 합니다. 빠르게 질문을 던지는 것은 코드를 이해하는 가장 빠른 방법이며, 저는 에이전트가 답변하는 과정에서 스스로 문제를 발견하는 경우가 많다는 것을 확인했습니다.

코드를 수정하는 것이 규칙을 수정하는 것이 됩니다. 리뷰를 통해 에이전트가 작성한 코드에서 문제를 발견했을 때, 우리는 코드를 수동으로 직접 수정해서는 안 됩니다. 이번에 직접 수정하더라도, 에이전트는 다음에 똑같은 실수를 반복할 것입니다. 대신, 에이전트에게 코드를 수정하도록 지시하고, 이어서 에이전트에게 규칙 문서(Rule documents)를 업데이트하도록 지시하십시오. 저는 이러한 문서들을 ABS (Agent Behavior Specification, 에이전트 행동 명세)라고 부릅니다. CLAUDE.md, BEST_PRACTICE.md와 같은 파일들이 이에 해당합니다.

새로운 리듬 (A New Cadence)

과거에는 머지 (Merge) 전 모든 PR (Pull Request)에 대해 사람의 승인을 요구했습니다. 하지만 상황이 변했습니다:

• 1인 프로젝트가 흔해지고 있습니다.
• 에이전트 (Agents)가 사람이 리뷰할 수 있는 속도보다 더 빠르게 코드를 생성합니다.
• 동일한 규칙이 주어지면, 에이전트는 유사한 요구사항에 대해 반복적으로 동일한 품질의 코드를 제공할 수 있습니다.

따라서 프로젝트의 전체 생애 주기 동안 모든 변경 사항을 일일이 리뷰할 필요가 더 이상 없습니다. 대신 다음과 같이 진행합니다:

• 프로젝트 초기 단계에서는 모든 변경 사항을 리뷰하고, 점진적으로 규칙 기반 (Rule base)을 구축합니다.
• 중후반 단계에서는 단순한 변경 사항에 대한 리뷰는 건너뜁니다. 단, 임계값 (Threshold)을 설정합니다. 건너뛴 리뷰 횟수가 임계값에 도달하면, 규칙을 개선할 필요가 있는지 확인하기 위해 사람의 리뷰를 수행합니다.

새로운 명칭: 코드 감사 (Code Audit)

이 새로운 리뷰 방식은 다음과 같은 특징을 가집니다:

• 프로젝트 초기 단계에는 전체 리뷰를 수행하고, 프로젝트가 성숙해지면 점검 (Spot checks)을 수행합니다.
• 중요한 것은 코드가 정확함을 보장하는 것이 아니라, 코드가 작성된 방식이 규정 (Compliant)을 준수하고 있음을 보장하는 것입니다.

이는 금융 감사 (Financial audit)와 매우 유사하게 들립니다. 그래서 저는 프로젝트 코드를 리뷰하는 이 새로운 방식에 더 적합한 이름이 필요하다고 생각합니다. 바로 코드 감사 (Code audit)입니다.

저자 소개

저는 CodePlato입니다.

저는 인간의 창의성이 AI 코딩의 진정한 뿌리라고 믿습니다. 코드와 모델은 동굴 벽에 투영된 그림자일 뿐입니다.

X: @codeplato2026
https://x.com/codeplato2026