[한글자막] AI 코드 리뷰 에이전트, 직접 만들 때 놓치기 쉬운 것들

한 줄 핵심

AI 코드 리뷰 에이전트는 샌드박스·프롬프트·과거 PR 평가·모델 분리·코드베이스 맥락·자율 테스트를 함께 설계해야 비로소 실용적인 품질과 비용을 얻을 수 있다.

시간별 요약

1. 0:00
   소개 이 영상은 코드 작성량이 급증한 상황에서 생긴 리뷰 병목을 AI로 풀기 위한 방법을 다룬다. 단순한 리뷰 자동화가 아니라, 실제로 쓸 만한 리뷰 에이전트를 만들 때 놓치기 쉬운 문제들을 짚는다.
2. 0:26
   리뷰 에이전트의 기본 구조와 한계 기본 구조는 샌드박스 안의 에이전트가 GitHub나 GitLab의 PR 내용을 받아 간단한 프롬프트로 검토하고, 결과를 리뷰 API로 돌려주는 방식이다. 하지만 이 방식만으로는 버그를 놓치고, 코드베이스 맥락을 오해하고, 비용이 빠르게 커지며, 사소한 지적이 과도하게 늘어나는 문제가 생긴다.
3. 3:38
   프롬프트를 어떻게 개선할까 프롬프트는 특정 버그 유형을 겨냥하도록 바꾸고, nitpick을 명시적으로 배제하는 방향으로 개선해야 한다. 다만 작은 문구 변경도 댓글 수에 큰 영향을 주기 때문에, 검토기만으로는 버그의 부재를 증명할 수 없고 희귀한 치명적 버그를 놓칠 위험이 남는다.
4. 5:20
   과거 PR로 성능 검증 과거 장애와 인시던트가 발생한 PR 데이터셋을 만들어, 리뷰 에이전트가 그 버그를 얼마나 자주 잡는지 측정해야 한다. 다만 버그의 형태는 시간이 지나며 바뀌고, 새롭게 등장하는 오류도 늘어나므로 내부 데이터만으로는 커버리지에 한계가 있다.
5. 6:36
   모델을 교차해 검토하기 Claude와 Codex 같은 모델은 서로 다른 방식으로 실수하므로, 코드 생성에 쓴 모델과 다른 모델로 리뷰하는 편이 더 잘 잡힌다. 브랜치명, PR 설명, 커밋 메타데이터 같은 흔적을 활용해 생성 모델을 추정하고, 모델을 뒤집는 방식으로 검출률을 높일 수 있다.
6. 8:26
   코드와 문서의 맥락 grep 중심의 탐색은 비효율적이고 부정확하므로, 코드베이스 전체를 분류·색인한 내부 지식베이스나 living wiki가 필요하다. Jira, Linear, Confluence, Notion, 생산 로그까지 함께 연결하면 인증 흐름이나 의도 해석처럼 문맥 의존적인 문제를 더 정확하게 다룰 수 있다.
7. 11:48
   샌드박스에서 자율 테스트 정적 코드만 읽어서는 보이지 않는 UI 문제를 잡기 위해, 의존성이 포함된 샌드박스에서 앱을 실제로 띄우고 end-to-end로 테스트해야 한다. 이를 위해서는 애플리케이션 흐름 문서화와 간단한 빌드 스크립트, 그리고 배포 가능한 dev box 구성이 필요하다.
8. 12:59
   앱 흐름을 직접 테스트 PR 브랜치에서 앱을 실행하고 auth, sign-up 같은 흐름 맵을 따라가며 실제 사용자 경로를 검증해야 한다. 이런 방식이면 버튼이 화면에 존재하더라도 iPhone에서 숨겨지거나 첫 화면에 보이지 않는 문제를 vision 모델로 찾아낼 수 있다.
9. 13:21
   모델을 나눠 비용 줄이기 리뷰 품질을 유지하려면 모든 작업에 frontier model을 쓰기보다, 맥락 수집·파일 읽기·간단한 테스트 같은 긴 꼬리 작업은 더 작은 모델로 분리해야 한다. 다만 모델을 바꿔치기할수록 품질 저하 위험이 있으므로, 대규모 데이터셋으로 각 서브태스크의 성능을 지속적으로 검증해야 한다.

실무 인사이트

• AI 코드 리뷰의 핵심은 '한 번에 모든 걸 잘하는 모델'이 아니라, 버그 탐지·맥락 수집·테스트·최종 판정을 역할별로 분해하는 설계다.
• 실무에서는 프롬프트 개선보다 과거 인시던트 기반 평가와 모델 교차 검토가 더 큰 성능 차이를 만든다.
• 비용 최적화는 곧 품질 저하와 연결되므로, 저비용 모델로 대체할 업무와 frontier model을 유지할 업무를 데이터로 구분해야 한다.