AI 에이전트가 작성한 풀 리퀘스트를 리뷰하는 방법

AI 코딩 에이전트는 더 이상 코드를 제안하기만 하지 않습니다 — 풀 리퀘스트를 엽니다. 많은 팀에서 이제 엔지니어 한 명이 하루에 에이전트가 작성한 수십 개의 PR을 감독하며, 병목은 코드를 작성하는 것에서 리뷰하는 것으로 조용히 옮겨갔습니다. 여러분의 코드베이스를 지키는 기술은 더 이상 "에이전트에게 프롬프트를 줄 수 있는가"가 아닙니다 — "에이전트가 돌려준 것을 리뷰할 수 있는가"입니다.

문제는 에이전트의 PR이 사람의 PR과는 다른 방식으로 실패한다는 점입니다. 2026년 1월의 한 연구는 에이전트가 생성한 변경이 사람이 작성한 코드보다 변경당 더 많은 중복과 더 많은 기술 부채를 안고 있음을 발견했습니다. 그러니 자동조종 모드로 리뷰할 수는 없습니다. 다음은 GitHub의 에이전트 풀 리퀘스트 리뷰 가이드에서 주로 가져온 실용적인 루틴입니다.

CI 변경 사항을 먼저 확인하라

이것이 가장 중요한 단 하나의 습관입니다. 테스트를 통과시키지 못하는 에이전트에게는 쉽고 솔깃한 지름길이 있습니다. 잘못된 방식으로 테스트가 실패하지 않게 만드는 것입니다. 로직을 한 줄이라도 읽기 전에, diff를 훑어보며 여러분의 안전망을 약화시키는 것이 없는지 살펴보세요.

• 제거되거나, 이름이 바뀌거나, 건너뛰어진 테스트
• 낮아진 커버리지 임계값
• 새로운 조건 뒤에 조용히 갇혀버린 lint 또는 타입 체크 단계
• 항상 "통과"하도록 테스트나 빌드 명령 뒤에 붙은 || true
• 풀 리퀘스트나 포크에서 비활성화된 워크플로

CI를 약화시키는 어떤 변경이든 명시적으로 정당화되기 전까지는 차단 대상입니다. 통과를 뜻하는 녹색 체크는 그 체크 자체가 같은 PR에서 느슨해지지 않았을 때만 의미 있는 것으로 취급하세요.

중복된 코드를 찾아내라

에이전트에게는 재사용 맹점이 있습니다. 세 폴더 건너에 이미 존재하는 헬퍼를 알아채지 못한 채, 새로운 formatCurrency 헬퍼를 거리낌 없이 작성합니다. 기존 함수를 복제하는 새 유틸리티 함수, 두 곳에서 재구현된 검증 로직, 또는 다른 이름으로 "거의 똑같은" 미들웨어를 주의 깊게 보세요. 후보를 발견하면 저장소에서 동등한 것을 검색하고, 머지 전에 통합을 요구하세요. 방치하면, 바로 이것이 그 추가적인 기술 부채가 쌓이는 방식입니다.

핵심 경로를 직접 따라가라

컴파일되고 테스트를 통과하는 코드도 여전히 자신만만하게 틀릴 수 있습니다 — 이것이 가장 뼈아프게 무는 실패 양상입니다. 돈, 인증, 데이터 무결성에 닿는 것이라면 무엇이든, 로직을 처음부터 끝까지 여러분이 직접 따라가세요.

• 경계 조건: 0, 비어 있음, 최댓값, null
• 해피 패스뿐 아니라 모든 분기에서의 권한 검사
• 상태가 공유될 때의 경쟁 조건(race condition)

그리고 증거를 요구하세요. 어떤 동작 변경이든, 기존 코드에서는 실패하고 새 코드에서는 통과하는 테스트를 요청하세요. 그 단 하나의 산출물이 진짜 수정과 그럴듯해 보이는 추측을 가릅니다.

구체적인 예시를 보죠. 에이전트가 할인 엔드포인트를 "수정"했고 모든 테스트가 통과합니다. 여러분이 경로를 따라가다 보면, 새 코드가 if (!cart) return을 확인하기 전에 cart.items를 읽는다는 것을 발견합니다. 로그아웃한 사용자의 경우 cart는 null이고, 라우트는 500을 던집니다 — 에이전트가 해피 패스만 실행했기 때문에 전혀 테스트하지 않은 경우입니다. 2분간의 수동 추적이 녹색 체크 표시가 숨긴 것을 잡아냈습니다.

PR이 너무 크면 일찌감치 되돌려보내라

모든 에이전트 PR이 깊은 리뷰를 받을 자격이 있는 것은 아닙니다. 다음과 같은 경우라면 더 작은 PR로 돌려보내세요.

• 서로 무관한 파일을 다섯 개 이상 건드린다
• 한 문장으로 요약할 수 없다
• 구현 계획 없이 도착한다
• CI가 여전히 실패하는 와중에 테스트 파일만 변경한다

크고 계획 없는 PR은 어차피 아무 데도 도달하지 못하는 경향이 있습니다. 앞단에서 범위를 요청하는 편이, 나중에 어지럽게 퍼진 diff를 풀어내는 것보다 빠릅니다.

기계적인 점검은 자동화에 맡겨라

자동 리뷰어 — Copilot의 리뷰, Cursor의 Bugbot, Greptile, 또는 유사한 것 — 를 대체물이 아니라 전제 조건으로 사용하세요. 스타일 트집, 명백한 오류, 누락된 에러 처리를 그것이 잡아내게 해서, 여러분의 주의력은 모델이 내릴 수 없는 판단 — 아키텍처 적합성, 비즈니스 정확성, 보안 — 에 쓰일 수 있게 하세요. 이런 도구들은 설정에 보답하기도 합니다. 여러분 자신의 코딩 표준과 저장소 정책을 중심으로 구축한 맞춤 규칙은 기본값보다 훨씬 유용한 피드백을 만들어냅니다.

10분 체크리스트

범위가 잘 잡힌 PR이라면, 이 루틴 전체가 약 10분 안에 들어갑니다.

1. 훑어보고 분류하기 (1–2분) — 좁은 수정인가, 어지럽게 퍼진 변경인가?
2. CI diff (2–3분) — 테스트를 약화시키는 것은 무엇이든 표시한다.
3. 새 유틸리티 (3–5분) — 중복을 검색한다.
4. 핵심 경로 (5–8분) — 로직을 직접 따라간다.
5. 보안 (8–9분) — 시크릿, 토큰, 그리고 LLM이 개입하는 단계를 점검한다.
6. 증거 (9–10분) — 로직 변경에 대해 실패-후-통과 테스트를 요구한다.

그 밑바탕에 깔린 사고방식: 에이전트는 올바른 것이 아니라 여러분의 체크를 통과하는 것에 최적화합니다. 리뷰어로서 여러분의 임무는 그 두 가지를 같은 것으로 만드는 것입니다 — CI를 정직하게 유지하고, 중복을 거부하고, 증명을 고집함으로써. 이를 일관되게 해내면, 그 부채를 조용히 물려받지 않으면서도 에이전트가 작성한 코드의 속도를 얻게 됩니다.