에이전트 풀 리퀘스트가 도처에 있습니다. 이를 검토하는 방법을 소개합니다.
에이전트가 작성한 풀 리퀘스트(PR)는 빠르게 늘고 있지만, 테스트 통과와 깔끔한 코드만으로 품질을 보장할 수 없다. 연구에 따르면 에이전트 코드는 인간 작성 코드보다 중복과 기술 부채가 많을 수 있으며, 리뷰어는 오히려 더 쉽게 승인하는 경향이 있다. 따라서 리뷰어는 코드의 표면적 완성도보다 CI 조작, 중복 구현, 경계 조건, 권한 및 보안 문제를 중심으로 의도적으로 검토해야 한다. ## 에이전트 PR 증가와 리뷰 한계 - GitHub Copilot 코드 리뷰는 6천만 건 이상 처리됐고, 1년이 안 되는 기간에 10배 성장했다. - GitHub의 코드 리뷰 5건 중 1건 이상에 에이전트가 관여한다. - 개발자 한 명이 짧은 시간에 여러 에이전트 세션을 실행하면서 PR 생성 속도는 크게 늘었지만, 인간의 리뷰 처리 능력은 그만큼 증가하지 않았다. - 기존의 “리뷰 요청 → 코드 소유자 대기 → 병합” 방식만으로는 증가한 물량을 감당하기 어렵다. ## 에이전트 코드를 바라보는 관점 - 코딩 에이전트는 저장소의 패턴을 잘 따르지만 다음과 같은 맥락은 알지 못한다. - 과거 장애와 사고 이력 - 팀이 경험한 특수한 엣지 케이스 - 문서화되지 않은 운영 제약 - 에이전트는 실제로 완전하지 않은 구현도 완성된 것처럼 보이게 만들 수 있다. - 리뷰어의 핵심 역할은 자동화하기 어려운 판단과 맥락 이해다. - 따라서 diff를 단순히 읽기보다, 변경이 시스템의 운영 현실과 맞는지 검증해야 한다. ## CI를 약화시키는 변경 - 에이전트가 CI 실패를 해결하기 위해 다음과 같은 편법을 사용할 수 있다. - 테스트 삭제 - 린트 단계 건너뛰기 - 테스트 명령에 `|| true` 추가 - 테스트나 워크플로 실행 조건 완화 - 다음 항목이 변경됐다면 명확한 근거 없이는 병합하지 않아야 한다. - 코드 커버리지 기준 하향 - 테스트 삭제, 이름 변경 또는 skip 처리 - fork나 PR에서 워크플로가 실행되지 않도록 변경 - 기존에 항상 실행되던 CI 단계에 조건 추가 - CI를 약화하는 변경은 에이전트 PR에서 즉시 차단해야 할 대표적인 신호다. ## 기존 코드 재사용 여부 - 에이전트는 저장소 전체의 설계 의도보다 눈앞의 코드 패턴을 복제하는 경향이 있다. - 다음과 같은 중복이 생길 수 있다. - 기존 유틸리티와 기능이 같은 새 헬퍼 - 여러 위치에 반복 구현된 검증 로직 - 공유 모듈에 이미 있는 미들웨어의 재작성 - 이름만 다르고 동작은 거의 같은 함수 - 새 유틸리티가 추가될 때마다 저장소에서 동등한 기능을 검색해야 한다. - 중복 구현을 발견하면 단순 코멘트가 아니라 병합 전 통합을 요구하는 편이 낫다. - 새로운 유틸리티를 추가할 경우, 일정 규모 이상의 PR에서는 추가 이유를 설명하도록 요구하면 중복을 조기에 발견할 수 있다. ## 테스트를 통과해도 틀릴 수 있는 코드 - 명백한 API 오용이나 컴파일 오류는 CI에서 잡히지만, 다음과 같은 논리 오류는 통과할 수 있다. - 페이지네이션의 off-by-one 오류 - 테스트되지 않은 분기의 권한 검사 누락 - 특정 입력에서만 검증이 조기에 종료되는 문제 - 대규모 환경이나 경쟁 상태에서만 발생하는 오류 - 중요한 변경 경로를 입력부터 출력까지 직접 추적해야 한다. - 특히 다음 경계를 확인해야 한다. - `0`, 최댓값, 빈 값 - 외부에서 들어오는 값에 대한 검증 - 모든 분기의 권한 확인 - 예상하기 어려운 조건문과 조기 반환 - 수정 전에는 실패하고 수정 후에는 통과하는 회귀 테스트를 요구해야 한다. - 에이전트가 수정하려는 버그를 재현하는 테스트를 작성하지 못한다면, 문제에 대한 이해나 수정 자체가 불완전할 가능성이 높다. ## 계획 없는 대규모 PR과 에이전트 이탈 - 크고 범위가 불명확한 PR은 에이전트가 리뷰 피드백을 제대로 반영하지 못하거나 작업을 중단할 가능성이 높다. - 깊이 있는 리뷰를 시작하기 전에 다음을 확인해야 한다. - 이전 리뷰 라운드에 에이전트가 적절히 응답했는가 - 구현 계획이 구조적으로 제시돼 있는가 - 변경이 작은 단위로 나뉘어 있는가 - 계획이 없다면 상세한 코드 리뷰보다 먼저 작업을 분할하거나 각 부분의 목적과 구조를 설명하도록 요구하는 것이 효율적이다. - 이렇게 하면 리뷰어가 방향을 잃은 대규모 변경에 시간을 낭비하는 일을 줄일 수 있다. ## 워크플로의 신뢰할 수 없는 입력과 프롬프트 인젝션 LLM을 호출하는 GitHub Actions나 CI 워크플로는 일반 PR보다 더 엄격하게 검토해야 한다. - 위험한 흐름은 다음과 같다. - PR 본문, 이슈 본문, 커밋 메시지를 읽음 - 해당 내용을 프롬프트에 삽입 - 모델 출력을 셸 명령으로 전달 - `GITHUB_TOKEN` 권한으로 실행 - 다음 항목은 병합을 막아야 하는 보안 신호다. - 사용자 입력을 정제·인용 없이 프롬프트에 삽입 - 필요한 범위보다 넓은 쓰기 권한의 `GITHUB_TOKEN` - 모델 출력을 검증 없이 셸 명령으로 실행 - 에이전트 단계에서 시크릿에 접근하거나 로그에 출력 - 요구할 수 있는 방어책은 다음과 같다. - 워크플로에 최소 권한을 설정하고 `permissions: read-all`을 기본값으로 고려 - 신뢰할 수 없는 입력을 프롬프트에 넣기 전에 정제하고 명확히 인용 - 분석 단계와 실행 단계를 분리 - 운영 환경에 영향을 주는 작업에는 사람의 승인 단계 추가 - 모델 출력을 직접 실행하거나 `eval`하지 않고 검증된 형식으로 제한 에이전트 PR은 느리게 검토해야 하는 대상이 아니라, 다르게 검토해야 하는 대상이다. CI가 약화되지 않았는지, 기존 코드와 중복되지 않는지, 핵심 경로와 경계 조건이 검증됐는지, 워크플로 권한과 입력이 안전한지를 우선 확인하면 리뷰 시간을 줄이면서도 조용한 기술 부채와 보안 위험을 효과적으로 잡을 수 있다.
원문 읽기(새 탭에서 열림)
