30장. AI 코드 리뷰 자동화

앞 장에서는 AI 코딩을 안전하게 쓰는 방법을 살펴보았다.

AI가 만든 코드는 그럴듯해 보일 수 있지만, 항상 안전한 것은 아니라고 했다.
컴파일되는 코드와 실제로 맞는 코드는 다르고, 보안, 권한, 트랜잭션, 테스트, 라이선스, 기존 아키텍처까지 함께 봐야 한다고 했다.

이번 장에서는 그 흐름을 코드 리뷰로 확장해본다.

개발팀에서 코드 품질을 지키는 가장 중요한 과정 중 하나가 PR 리뷰다.

PR은 Pull Request의 줄임말이다.
개발자가 작성한 코드를 바로 메인 브랜치에 반영하지 않고, 변경 내용을 다른 사람이 검토한 뒤 병합하기 위한 절차다.

AI는 이 PR 리뷰 과정에서도 도움을 줄 수 있다.

예를 들어 AI는 다음과 같은 일을 할 수 있다.

- PR 변경 내용 요약
- 변경 영향도 분석
- 보안 취약점 후보 검토
- 테스트 누락 확인
- 리뷰 코멘트 초안 생성
- 릴리즈 노트 초안 작성
- 팀 규칙 위반 여부 점검

하지만 AI 코드 리뷰 자동화는 조심해서 설계해야 한다.

AI가 리뷰 코멘트를 달 수 있다고 해서 사람이 리뷰하지 않아도 되는 것은 아니다.
AI는 변경 내용을 빠르게 훑고, 놓칠 수 있는 항목을 알려주는 보조 도구로 보는 것이 안전하다.

이번 장에서는 AI를 활용해 코드 리뷰를 자동화하는 방법과, 그 한계를 함께 살펴본다.
이 장은 네가 준 전체 목차와 30장 작성 기준에 맞춰 이어서 작성한다.

1. 코드 리뷰 자동화가 필요한 이유

코드 리뷰는 중요하다.

하지만 실무에서는 코드 리뷰가 항상 충분히 이루어지기 어렵다.

개발 일정이 바쁘면 리뷰가 형식적으로 끝날 수 있다.
리뷰어가 변경 내용을 모두 이해하지 못한 상태에서 승인할 수도 있다.
작은 PR은 대충 보고, 큰 PR은 너무 커서 자세히 보기 어려울 수도 있다.

특히 다음과 같은 문제가 자주 생긴다.

- PR 설명이 부족하다
- 변경 파일이 너무 많다
- 리뷰어가 어디를 봐야 할지 모른다
- 테스트가 충분한지 판단하기 어렵다
- 보안 영향이 있는지 놓친다
- 권한 체크 누락을 발견하지 못한다
- 변경 영향 범위가 정리되지 않는다
- 리뷰 코멘트가 스타일 지적에만 치우친다

AI 코드 리뷰 자동화는 이런 문제를 줄이는 데 도움을 줄 수 있다.

AI는 PR diff를 읽고 변경 내용을 요약할 수 있다.
위험해 보이는 부분을 후보로 정리할 수 있다.
테스트가 부족해 보이는 영역을 알려줄 수 있다.
리뷰어가 집중해서 봐야 할 파일을 추천할 수도 있다.

여기서 중요한 표현은 “후보”다.

AI가 지적한 내용이 항상 맞는 것은 아니다.
하지만 리뷰어가 확인해야 할 목록을 만들어주는 것만으로도 도움이 된다.

코드 리뷰 자동화의 목적은 사람 리뷰를 없애는 것이 아니다.

사람 리뷰가 더 중요한 부분에 집중할 수 있게 돕는 것이다.

2. AI 코드 리뷰 자동화의 기본 구조

AI 코드 리뷰 자동화는 보통 PR이 생성되거나 업데이트될 때 실행된다.

흐름은 대략 다음과 같다.

개발자가 PR 생성
→ GitHub Actions 또는 CI 실행
→ 변경 파일과 diff 수집
→ AI에게 리뷰 요청
→ AI가 요약과 검토 의견 생성
→ PR 댓글로 결과 등록
→ 사람이 최종 리뷰

이 구조에서 AI는 PR의 변경 내용을 입력으로 받는다.

입력에는 다음 정보가 포함될 수 있다.

- PR 제목
- PR 설명
- 변경 파일 목록
- Git diff
- 커밋 메시지
- 테스트 실행 결과
- 관련 이슈 번호
- 팀 리뷰 규칙

AI는 이 정보를 바탕으로 리뷰 결과를 만든다.

예를 들어 다음과 같은 결과를 생성할 수 있다.

PR 요약:
사용자 메모 저장 API가 추가되었고,
Controller, Service, Repository 파일이 변경되었습니다.

주요 변경:
- 관리자 요청 파라미터 검증 추가
- 사용자 메모 저장 Service 추가
- Repository에 insertUserMemo 메서드 추가

검토 필요:
- 관리자 권한 검증이 Middleware에서 처리되는지 확인 필요
- 메모 내용에 개인정보가 포함될 수 있으므로 로그 출력 여부 확인 필요
- 500자 초과 입력 테스트가 필요함

이런 결과가 PR에 자동으로 달리면 리뷰어는 변경 내용을 빠르게 파악할 수 있다.

하지만 이 자동화에는 주의할 점이 있다.

PR diff에는 회사 소스코드가 포함된다.
따라서 AI 서비스로 코드를 보내도 되는지 먼저 확인해야 한다.

팀 또는 회사 정책상 외부 AI로 소스코드를 전송할 수 없다면, 사내 AI 환경이나 로컬 모델을 사용해야 할 수도 있다.

3. PR 요약 자동화

AI 코드 리뷰 자동화에서 가장 먼저 적용하기 좋은 기능은 PR 요약이다.

PR 요약은 비교적 위험이 낮고 효과가 크다.

개발자가 PR 설명을 자세히 작성하지 않았더라도, AI가 변경된 파일과 diff를 보고 요약을 만들 수 있다.

예를 들어 다음과 같은 PR이 있다고 해보자.

변경 파일:
- AdminUserMemoController.php
- UserMemoService.php
- UserMemoRepository.php
- UserMemoServiceTest.php

AI는 이를 보고 다음처럼 요약할 수 있다.

이 PR은 관리자 페이지에서 사용자 메모를 저장하는 기능을 추가합니다.

주요 변경 사항:
- 관리자 메모 저장 API Controller 추가
- 사용자 존재 여부 확인 후 메모 저장
- Repository에 메모 저장 메서드 추가
- 사용자 없음, 메모 길이 초과 케이스 테스트 추가

이 요약은 리뷰어에게 도움이 된다.

리뷰어는 먼저 전체 변경 의도를 파악한 뒤 파일을 볼 수 있다.

PR 요약에는 다음 내용이 들어가면 좋다.

- 변경 목적
- 주요 변경 파일
- 추가된 기능
- 수정된 동작
- 삭제된 코드
- 테스트 추가 여부
- 리뷰어가 집중해서 봐야 할 부분

PR 요약 자동화는 개발자에게도 도움이 된다.

개발자가 PR 설명을 대충 작성했더라도 AI 요약을 보고 빠진 내용을 보완할 수 있다.
반대로 AI 요약이 개발자의 의도와 다르면 PR 설명이나 코드가 명확하지 않다는 신호일 수 있다.

다만 AI 요약이 항상 정확한 것은 아니다.

AI가 변경 의도를 잘못 해석할 수도 있다.
따라서 요약은 참고 자료로 보고, 최종 PR 설명은 개발자가 확인해야 한다.

4. 변경 영향도 분석

PR 리뷰에서 중요한 것은 “무엇이 바뀌었는가”뿐만 아니라 “어디에 영향을 주는가”다.

작은 코드 변경처럼 보여도 영향 범위가 클 수 있다.

예를 들어 공통 인증 미들웨어를 수정하면 여러 API에 영향을 줄 수 있다.
공통 응답 포맷을 바꾸면 프론트엔드와 외부 연동 API까지 영향을 받을 수 있다.
DB 조회 조건 하나가 바뀌면 관리자 페이지의 통계 수치가 달라질 수 있다.

AI는 변경 영향도 분석을 보조할 수 있다.

예를 들어 다음과 같이 요청할 수 있다.

아래 PR diff를 보고 변경 영향도를 분석해줘.

다음 기준으로 나눠줘.

- 직접 변경된 기능
- 영향을 받을 수 있는 API
- DB 변경 여부
- 캐시 영향
- 외부 API 영향
- 프론트엔드 영향
- 운영 중 주의할 점

AI는 diff를 읽고 영향 후보를 정리할 수 있다.

예를 들어 사용자 상태값 처리 코드가 바뀌었다면 다음처럼 말할 수 있다.

영향 가능성:
- 사용자 로그인 가능 여부 판단에 영향
- 관리자 사용자 목록 필터에 영향
- 차단 사용자 세션 만료 처리에 영향
- 통계에서 활성 사용자 수 계산에 영향 가능성
- 기존 BLOCK 상태 외에 SUSPENDED 상태가 추가되었으므로 관련 분기 확인 필요

이런 분석은 리뷰어가 놓칠 수 있는 부분을 알려준다.

하지만 AI의 영향도 분석은 완벽하지 않다.

AI가 전체 시스템 구조를 알지 못하면 일부 영향 범위를 놓칠 수 있다.
특히 레거시 시스템처럼 암묵적인 의존성이 많은 구조에서는 더 그렇다.

따라서 영향도 분석 자동화는 다음과 같이 사용하는 것이 좋다.

- AI가 영향 후보를 정리한다
- 개발자가 실제 영향 범위를 확인한다
- 리뷰어가 빠진 부분을 추가한다
- 필요한 경우 테스트 범위를 넓힌다

AI는 영향도 분석의 시작점을 제공한다.
영향도를 확정하는 것은 개발자와 리뷰어의 역할이다.

5. 보안 취약점 검토

AI 코드 리뷰 자동화에서 가장 조심하면서도 유용한 영역이 보안 검토다.

AI는 코드 diff를 보고 보안상 위험해 보이는 부분을 지적할 수 있다.

예를 들어 다음과 같은 코드를 발견할 수 있다.

$sql = "SELECT * FROM users WHERE email = '" . $email . "'";

AI는 이 코드에 대해 SQL Injection 위험을 지적할 수 있다.

또는 다음과 같은 로그 코드를 보고 민감 정보 노출 가능성을 말할 수 있다.

logger.info("login failed", [
    "email" => $email,
    "password" => $password
]);

이 경우 비밀번호가 로그에 남는 문제가 있다.

AI에게 보안 검토를 요청할 때는 기준을 명확히 주는 것이 좋다.

아래 diff를 보안 리뷰 관점에서 검토해줘.

특히 다음 항목을 봐줘.

- SQL Injection
- XSS
- 인증 누락
- 권한 검증 누락
- 민감 정보 로그 출력
- 파일 업로드 검증
- SSRF
- 경로 조작
- 토큰 만료 검증
- 관리자 기능 접근 제어

이렇게 요청하면 AI가 보안 항목을 기준으로 diff를 볼 수 있다.

하지만 AI 보안 리뷰에는 한계가 있다.

AI는 정적 분석 도구가 아니다.
모든 취약점을 정확히 탐지하지 못한다.
반대로 실제로는 문제가 아닌데 문제라고 말할 수도 있다.

따라서 보안 검토는 AI만으로 끝내면 안 된다.

가능하면 다음을 함께 사용해야 한다.

- 정적 분석 도구
- 의존성 취약점 검사
- 시크릿 탐지 도구
- 코드 리뷰
- 보안 체크리스트
- 수동 검증

AI 보안 리뷰는 “자동 보안 승인”이 아니라 “보안 의심 지점 탐지”로 보는 것이 안전하다.

6. 테스트 누락 확인

PR 리뷰에서 자주 놓치는 부분 중 하나가 테스트다.

기능 코드는 변경되었는데 테스트가 없을 수 있다.
테스트가 있더라도 정상 케이스만 있고 실패 케이스가 빠질 수 있다.

AI는 변경 내용을 보고 테스트 누락 후보를 알려줄 수 있다.

예를 들어 다음과 같이 요청할 수 있다.

아래 PR diff를 보고 테스트가 부족해 보이는 부분을 찾아줘.

정상 케이스, 실패 케이스, 권한 오류, 입력값 오류, 외부 API 실패, DB 실패, 중복 요청 관점으로 봐줘.

AI는 다음처럼 응답할 수 있다.

테스트 누락 가능성:
- 메모 길이 500자 초과 케이스 테스트 필요
- 대상 사용자가 존재하지 않는 경우 테스트 필요
- 관리자 권한이 없는 사용자의 요청 테스트 필요
- Repository 저장 실패 시 예외 처리 테스트 필요
- 메모 내용이 빈 문자열일 때 처리 기준 확인 필요

이런 결과는 리뷰어에게 유용하다.

리뷰어는 “테스트가 있나?”만 보는 것이 아니라 “어떤 케이스가 빠졌나?”를 볼 수 있다.

AI는 테스트 코드 자체를 생성할 수도 있다.

위에서 누락된 테스트 케이스를 기준으로 PHPUnit 테스트 코드 초안을 만들어줘.

Repository는 Mock으로 처리하고,
Service 레벨 테스트로 작성해줘.

하지만 테스트 생성 역시 그대로 믿으면 안 된다.

AI가 만든 테스트는 다음 문제가 있을 수 있다.

- 실제 프로젝트 테스트 구조와 다르다
- Mock 설정이 틀렸다
- 검증이 약하다
- 테스트 이름과 내용이 맞지 않는다
- 중요한 경계값이 빠졌다
- 테스트가 구현 세부사항에 너무 의존한다

테스트 누락 확인 자동화의 목적은 리뷰어가 테스트 관점을 놓치지 않도록 돕는 것이다.

테스트 품질까지 최종 판단하는 것은 개발자와 리뷰어가 해야 한다.

7. 리뷰 코멘트 자동 생성

AI는 PR에 리뷰 코멘트를 자동으로 생성할 수도 있다.

예를 들어 diff에서 특정 코드 부분을 보고 다음과 같은 코멘트를 달 수 있다.

이 메서드는 사용자 상태를 변경하지만 감사 로그가 없습니다.
관리자 기능이라면 누가 어떤 사용자의 상태를 변경했는지 기록하는 것이 좋습니다.

또는 다음처럼 달 수 있다.

amount 값이 0 이하인 경우에 대한 검증이 보이지 않습니다.
포인트 차감 로직이라면 음수 입력으로 포인트가 증가하지 않도록 방어가 필요합니다.

이런 코멘트는 리뷰어가 놓칠 수 있는 부분을 보완해준다.

하지만 자동 리뷰 코멘트에는 단점도 있다.

AI가 너무 많은 코멘트를 달면 오히려 방해가 된다.
중요하지 않은 스타일 지적이 많아지면 개발자는 AI 코멘트를 무시하게 된다.
잘못된 코멘트가 반복되면 신뢰도가 떨어진다.

따라서 AI 리뷰 코멘트는 기준을 정해야 한다.

처음부터 모든 스타일과 모든 코드를 리뷰하게 하기보다는, 위험도가 높은 항목 위주로 제한하는 것이 좋다.

예를 들어 다음 항목만 코멘트하도록 할 수 있다.

- 권한 검증 누락 가능성
- 민감 정보 로그 출력 가능성
- SQL Injection 위험
- 트랜잭션 누락 가능성
- 중복 요청 방어 필요
- 테스트 누락 가능성
- 기존 아키텍처 위반 가능성

AI 리뷰 코멘트는 적고 정확할수록 좋다.

많은 코멘트를 다는 것보다, 리뷰어가 실제로 확인해야 할 중요한 항목을 알려주는 것이 더 중요하다.

8. AI 리뷰의 한계

AI 리뷰는 유용하지만 한계가 분명하다.

첫째, AI는 전체 비즈니스 맥락을 모를 수 있다.

예를 들어 어떤 코드는 겉으로 보면 권한 검증이 없는 것처럼 보인다.
하지만 실제로는 상위 Middleware에서 권한을 이미 검증하고 있을 수 있다.

AI는 이 맥락을 모르면 잘못된 코멘트를 달 수 있다.

둘째, AI는 레거시 의존성을 놓칠 수 있다.

오래된 시스템에서는 명시적이지 않은 의존성이 많다.

- 특정 상태값을 다른 배치가 참조한다
- 관리자 화면에서 같은 컬럼을 직접 조회한다
- 외부 업체가 특정 응답 필드에 의존한다
- 로그 포맷을 모니터링 시스템이 파싱한다

AI는 diff만 보고 이런 의존성을 모두 알기 어렵다.

셋째, AI는 실행 결과를 완전히 검증하지 못한다.

코드를 읽고 위험 후보를 말할 수는 있지만, 실제로 동작하는지는 테스트와 실행으로 확인해야 한다.

넷째, AI는 중요도를 잘못 판단할 수 있다.

사소한 스타일 문제를 크게 말하고, 실제로 중요한 데이터 정합성 문제를 놓칠 수 있다.

다섯째, AI도 환각할 수 있다.

코드에 없는 함수를 있다고 말하거나, 실제로 변경되지 않은 부분을 변경되었다고 설명할 수 있다.

그래서 AI 리뷰는 사람 리뷰를 대체하면 안 된다.

AI 리뷰는 다음 역할에 적합하다.

- 변경 요약
- 검토 후보 정리
- 테스트 누락 후보 제안
- 보안 의심 지점 표시
- 리뷰어가 볼 포인트 정리

반대로 다음 역할에는 적합하지 않다.

- 최종 승인
- 보안 승인
- 배포 승인
- 비즈니스 규칙 확정
- 장애 영향 확정
- 데이터 정합성 보장

AI 리뷰는 보조 도구다.
최종 책임은 여전히 사람에게 있다.

9. 사람이 반드시 검토해야 하는 부분

AI가 리뷰를 도와주더라도 사람이 반드시 봐야 하는 부분이 있다.

특히 다음 영역은 사람 리뷰가 필수다.

- 결제
- 정산
- 포인트
- 후원
- 인증
- 권한
- 개인정보
- 관리자 기능
- 데이터 삭제
- 외부 API 연동
- 운영 자동화
- 배치 작업
- 인프라 설정 변경

이런 영역은 단순 코드 품질 문제가 아니다.

비즈니스 손실, 개인정보 사고, 보안 사고, 장애로 이어질 수 있다.

사람 리뷰어는 다음을 확인해야 한다.

- 요구사항이 정확히 반영되었는가
- 도메인 정책과 맞는가
- 권한 검증 위치가 적절한가
- 실패 시 데이터가 일관되게 유지되는가
- 중복 실행되어도 안전한가
- 운영 로그가 충분한가
- 개인정보가 노출되지 않는가
- 장애 시 복구 가능한가
- 배포 순서에 문제가 없는가
- 다른 팀과 협의가 필요한가

예를 들어 정산 로직 변경 PR이 있다고 해보자.

AI는 코드상 위험 후보를 지적할 수 있다.
하지만 실제 정산 정책, 회계 기준, 운영 예외 처리까지 모두 알 수는 없다.

따라서 이런 PR은 담당자가 직접 봐야 한다.

AI가 “문제없음”이라고 했더라도 사람 리뷰가 생략되면 안 된다.

AI 리뷰 결과는 참고 자료다.
승인 권한은 사람에게 있어야 한다.

10. 팀 규칙 기반 리뷰 프롬프트 만들기

AI 코드 리뷰 자동화의 품질은 프롬프트에 크게 영향을 받는다.

단순히 “이 코드를 리뷰해줘”라고 하면 일반적인 리뷰가 나온다.

팀에서 원하는 리뷰를 받으려면 팀 규칙을 프롬프트에 포함해야 한다.

예를 들어 다음과 같은 팀 규칙이 있다고 해보자.

- Controller에서는 비즈니스 로직을 작성하지 않는다.
- DB 접근은 Repository에서만 한다.
- 외부 API 호출은 Client 클래스를 통해서만 한다.
- 관리자 기능은 감사 로그를 남긴다.
- 개인정보는 로그에 남기지 않는다.
- 응답 형식은 { result, message, data } 구조를 사용한다.
- 결제, 정산, 포인트 관련 코드는 트랜잭션을 검토한다.

이 규칙을 AI 리뷰 프롬프트에 포함할 수 있다.

너는 우리 팀의 PR 리뷰 보조자다.

아래 팀 규칙을 기준으로 PR diff를 검토해라.

팀 규칙:
- Controller에서는 비즈니스 로직을 작성하지 않는다.
- DB 접근은 Repository에서만 한다.
- 외부 API 호출은 Client 클래스를 통해서만 한다.
- 관리자 기능은 감사 로그를 남긴다.
- 개인정보는 로그에 남기지 않는다.
- 응답 형식은 { result, message, data } 구조를 사용한다.
- 결제, 정산, 포인트 관련 코드는 트랜잭션을 검토한다.

리뷰 기준:
- 중요한 문제만 지적한다.
- 스타일 지적은 하지 않는다.
- 확실하지 않은 내용은 “확인 필요”라고 표시한다.
- 코드에 근거가 없는 추측은 하지 않는다.
- 최종 승인은 사람이 해야 한다는 전제로 작성한다.

출력 형식:
1. PR 요약
2. 주요 변경 사항
3. 위험 가능성
4. 테스트 누락 후보
5. 사람이 꼭 확인해야 할 부분

이렇게 프롬프트를 만들면 AI 리뷰 결과가 팀 기준에 더 가까워진다.

중요한 것은 AI에게 리뷰 기준을 명확히 주는 것이다.

팀의 코드 스타일, 아키텍처 규칙, 보안 기준, 운영 원칙을 알려주지 않으면 AI는 일반적인 기준으로 리뷰한다.

일반적인 리뷰도 도움이 될 수 있지만, 실무에서는 팀의 맥락이 더 중요하다.

11. GitHub Actions와 연동하는 구조

AI 코드 리뷰 자동화는 GitHub Actions 같은 CI 도구와 연동할 수 있다.

GitHub Actions는 GitHub 저장소에서 특정 이벤트가 발생했을 때 자동으로 작업을 실행하는 기능이다.

예를 들어 다음 이벤트가 발생했을 때 실행할 수 있다.

- PR 생성
- PR 업데이트
- 특정 브랜치에 push
- 리뷰 요청
- 라벨 추가
- 수동 실행

AI 리뷰 자동화의 기본 흐름은 다음과 같다.

1. PR이 생성된다.
2. GitHub Actions가 실행된다.
3. 변경된 파일 목록과 diff를 가져온다.
4. 너무 큰 diff는 제외하거나 요약한다.
5. 팀 리뷰 프롬프트와 diff를 AI API에 전달한다.
6. AI가 리뷰 결과를 생성한다.
7. GitHub PR 댓글로 결과를 등록한다.
8. 사람 리뷰어가 결과를 참고해 최종 리뷰한다.

간단히 표현하면 다음 구조다.

GitHub PR
    ↓
GitHub Actions
    ↓
Diff 수집
    ↓
AI 리뷰 요청
    ↓
리뷰 결과 생성
    ↓
PR 댓글 등록
    ↓
사람 리뷰

실무에서는 몇 가지 제한이 필요하다.

첫째, 너무 큰 diff는 한 번에 보내지 않는 것이 좋다.

AI 모델에는 입력 길이 제한이 있고, 너무 많은 변경을 한 번에 보내면 요약 품질이 떨어진다.

둘째, 민감한 파일은 제외해야 한다.

예를 들어 다음 파일은 AI 리뷰 입력에서 제외할 수 있다.

- .env
- 인증키 파일
- 비밀 설정 파일
- 인증서 파일
- 운영 설정 파일
- 개인정보 샘플 데이터
- 대용량 자동 생성 파일

셋째, 리뷰 결과를 실패 조건으로 사용할지 신중해야 한다.

처음부터 AI가 지적하면 CI를 실패시키는 방식은 위험할 수 있다.
AI가 잘못된 지적을 할 수 있기 때문이다.

초기에는 PR 댓글로만 남기는 것이 좋다.
이후 팀에서 신뢰도가 확인되면 특정 규칙에 대해서만 실패 조건을 걸 수 있다.

예를 들어 시크릿 탐지나 테스트 실패는 CI 실패로 처리할 수 있다.
하지만 AI의 일반 리뷰 코멘트는 참고 자료로 남기는 것이 안전하다.

12. AI 리뷰 자동화에서 제외해야 할 파일

AI 리뷰 자동화에서는 모든 파일을 AI에게 보내면 안 된다.

보안상 제외해야 할 파일이 있고, 리뷰 효율상 제외해야 할 파일도 있다.

보안상 제외해야 할 파일은 다음과 같다.

- .env
- .pem
- .key
- 인증서 파일
- 비밀번호 설정 파일
- 운영 서버 접속 정보
- 외부 업체 연동 비밀키
- 개인정보가 포함된 샘플 데이터
- DB 덤프 파일

리뷰 효율상 제외해도 되는 파일은 다음과 같다.

- 빌드 결과물
- 자동 생성 파일
- lock 파일
- 이미지 파일
- 압축 파일
- 대용량 JSON
- 라이브러리 vendor 파일
- minify된 JS/CSS 파일

물론 lock 파일은 의존성 변경을 확인하는 데 필요할 수 있다.
하지만 AI에게 전체 내용을 보내는 것은 효율적이지 않을 수 있다.

이 경우에는 “의존성이 변경되었다”는 사실만 요약해서 전달하는 방식이 좋다.

예를 들어 다음처럼 전달할 수 있다.

package-lock.json 변경 있음.
신규 의존성:
- example-lib 1.2.0

제거된 의존성:
- old-lib 0.9.1

AI 리뷰 자동화에서 중요한 것은 필요한 정보만 보내는 것이다.

모든 데이터를 많이 보낸다고 좋은 리뷰가 나오는 것은 아니다.
오히려 민감 정보 노출 위험과 비용만 증가할 수 있다.

13. 리뷰 결과의 출력 형식 정하기

AI 리뷰 자동화를 운영하려면 출력 형식을 정해야 한다.

출력 형식이 매번 다르면 사람이 읽기 어렵다.
PR마다 리뷰 결과 구조가 다르면 팀원들이 활용하기도 어렵다.

추천하는 출력 형식은 다음과 같다.

1. PR 요약
2. 주요 변경 파일
3. 위험 가능성
4. 테스트 누락 후보
5. 보안 확인 항목
6. 사람이 꼭 확인해야 할 부분
7. AI 리뷰 한계 안내

예를 들어 PR 댓글은 다음처럼 만들 수 있다.

AI 리뷰 요약

1. PR 요약
관리자 사용자 메모 저장 기능이 추가되었습니다.
Controller, Service, Repository, 테스트 파일이 변경되었습니다.

2. 주요 변경
- AdminUserMemoController 추가
- UserMemoService에 saveMemo 추가
- UserMemoRepository에 insertMemo 추가
- UserMemoServiceTest 추가

3. 위험 가능성
- 관리자 권한 검증이 Middleware에서 수행되는지 확인 필요
- 메모 내용이 로그에 남지 않는지 확인 필요

4. 테스트 누락 후보
- 메모 500자 초과
- 대상 사용자 없음
- Repository 저장 실패

5. 사람이 꼭 확인해야 할 부분
- 감사 로그 항목이 충분한지
- 메모에 개인정보가 들어갈 수 있는지
- 운영 화면에서 마스킹이 필요한지

6. 참고
이 리뷰는 AI가 생성한 검토 후보이며, 최종 승인은 사람이 해야 합니다.

이런 형식은 리뷰어가 빠르게 읽을 수 있다.

AI 리뷰 결과는 길다고 좋은 것이 아니다.

리뷰어가 실제로 행동할 수 있는 형태여야 한다.

14. AI 리뷰 코멘트의 품질 관리

AI 리뷰 자동화를 도입하면 처음에는 신기하고 유용해 보일 수 있다.

하지만 시간이 지나면 문제가 생길 수 있다.

- 코멘트가 너무 많다
- 틀린 지적이 반복된다
- 중요하지 않은 내용을 계속 말한다
- 팀 규칙과 맞지 않는 리뷰를 한다
- 리뷰어가 AI 코멘트를 읽지 않는다
- 개발자가 AI 코멘트를 무시한다

그래서 AI 리뷰도 품질 관리가 필요하다.

다음 항목을 주기적으로 확인하면 좋다.

- AI 코멘트 중 실제로 반영된 비율
- 잘못된 지적의 비율
- 너무 자주 반복되는 코멘트
- 팀 규칙에 맞지 않는 코멘트
- 사람이 놓친 문제를 AI가 잡은 사례
- AI가 놓친 중요한 문제
- 리뷰어 만족도

AI 리뷰 프롬프트도 개선해야 한다.

예를 들어 AI가 스타일 지적을 너무 많이 한다면 프롬프트에 추가할 수 있다.

스타일, 네이밍, 줄바꿈 지적은 하지 마라.
보안, 권한, 데이터 정합성, 테스트 누락 중심으로만 리뷰해라.

AI가 확실하지 않은 내용을 단정한다면 다음을 추가할 수 있다.

코드만 보고 확정할 수 없는 내용은 “확인 필요”라고 표현해라.
근거가 없는 추측은 하지 마라.

AI 리뷰 자동화는 한 번 만들고 끝나는 기능이 아니다.

팀의 코드 구조와 리뷰 문화에 맞게 계속 조정해야 한다.

15. AI 리뷰 자동화를 도입하는 순서

AI 코드 리뷰 자동화는 처음부터 크게 도입하지 않는 것이 좋다.

작게 시작하고, 효과를 확인한 뒤 확장하는 것이 안전하다.

추천하는 도입 순서는 다음과 같다.

1단계: PR 요약 자동화
2단계: 테스트 누락 후보 정리
3단계: 보안 의심 지점 표시
4단계: 팀 규칙 기반 리뷰
5단계: 특정 영역 필수 체크리스트 자동화
6단계: GitHub Actions 연동 고도화
7단계: 리뷰 결과 품질 관리

처음에는 PR 요약만 해도 충분히 효과가 있다.

PR 요약은 개발자와 리뷰어 모두에게 부담이 적다.
AI가 틀려도 큰 문제가 생기지 않는다.
팀원들이 AI 리뷰 결과를 읽는 습관을 만들기에도 좋다.

그다음 테스트 누락 후보를 추가할 수 있다.

이 기능은 코드 품질에 직접 도움이 된다.
리뷰어가 테스트 관점을 놓치지 않게 해준다.

보안 검토는 유용하지만 조심스럽게 도입해야 한다.

AI가 보안 문제를 잘못 판단할 수 있기 때문이다.
처음에는 “보안 의심 지점”으로만 표시하고, 최종 판단은 사람에게 맡겨야 한다.

팀 규칙 기반 리뷰는 프롬프트가 어느 정도 정리된 뒤 도입하는 것이 좋다.

무작정 일반 리뷰를 자동화하면 팀 코드 스타일과 맞지 않는 코멘트가 많아질 수 있다.

AI 리뷰 자동화는 빠르게 크게 만드는 것보다, 작게 시작해서 신뢰를 쌓는 것이 중요하다.

16. AI 코드 리뷰 자동화 예시 프롬프트

실무에서 사용할 수 있는 AI 코드 리뷰 프롬프트 예시는 다음과 같다.

너는 백엔드 개발팀의 PR 리뷰 보조자다.

목표:
- PR 변경 내용을 요약한다.
- 리뷰어가 확인해야 할 위험 후보를 정리한다.
- 테스트 누락 가능성을 찾는다.
- 보안과 권한 관점의 의심 지점을 표시한다.
- 최종 승인 판단은 하지 않는다.

팀 규칙:
- Controller는 요청 검증과 Service 호출만 담당한다.
- 비즈니스 로직은 Service에 둔다.
- DB 접근은 Repository에서만 한다.
- 외부 API 호출은 Client 클래스를 통해 수행한다.
- 관리자 기능은 감사 로그를 남긴다.
- 개인정보는 로그에 남기지 않는다.
- 응답 형식은 { result, message, data } 구조를 따른다.
- 결제, 정산, 포인트, 후원 관련 코드는 트랜잭션을 반드시 검토한다.

리뷰 기준:
- 스타일 지적은 하지 않는다.
- 중요한 위험 가능성만 정리한다.
- 코드만 보고 확정할 수 없는 내용은 “확인 필요”라고 표시한다.
- 근거 없는 추측은 하지 않는다.
- 같은 내용을 반복하지 않는다.
- 사람이 실제로 확인할 수 있는 형태로 작성한다.

출력 형식:
1. PR 요약
2. 주요 변경 사항
3. 위험 가능성
4. 테스트 누락 후보
5. 보안/권한 확인 항목
6. 사람이 꼭 확인해야 할 부분
7. AI 리뷰 한계 안내

입력:
- PR 제목
- PR 설명
- 변경 파일 목록
- diff
- 테스트 결과

이 프롬프트는 그대로 완성본은 아니다.

팀의 구조에 맞게 바꿔야 한다.

예를 들어 프론트엔드 팀이라면 다음 항목이 더 중요할 수 있다.

- XSS
- 상태 관리
- API 응답 처리
- 접근성
- 렌더링 성능
- 브라우저 호환성

인프라 팀이라면 다음 항목이 중요할 수 있다.

- 권한 정책
- 네트워크 노출
- 시크릿 관리
- 롤백 가능성
- 장애 영향
- 비용 영향

AI 리뷰 프롬프트는 팀의 리뷰 철학을 문장으로 정리한 것에 가깝다.

좋은 프롬프트를 만들려면 먼저 팀의 리뷰 기준이 명확해야 한다.

17. AI 리뷰 자동화의 운영 주의사항

AI 리뷰 자동화도 운영 대상이다.

한 번 만들어놓고 방치하면 안 된다.

다음 항목을 관리해야 한다.

- API 비용
- 호출 빈도
- 입력 토큰 크기
- 실패 시 처리 방식
- 리뷰 결과 저장 여부
- 민감 정보 필터링
- 모델 변경 이력
- 프롬프트 변경 이력
- 리뷰 결과 품질
- 개발자 피드백

예를 들어 PR이 업데이트될 때마다 AI 리뷰를 실행하면 비용이 커질 수 있다.

개발자가 커밋을 여러 번 push하면 AI 호출도 여러 번 발생한다.
따라서 다음과 같은 제한을 둘 수 있다.

- PR 생성 시 1회 실행
- 라벨을 붙였을 때만 실행
- 수동 명령어 댓글을 달았을 때 실행
- 특정 브랜치에 대해서만 실행
- diff 크기가 일정 이하일 때만 실행
- 문서 변경만 있는 PR은 제외

실패 처리도 필요하다.

AI API 호출이 실패했다고 PR 전체를 막으면 개발 흐름이 불편해질 수 있다.
초기에는 AI 리뷰 실패를 CI 실패로 처리하지 않는 것이 좋다.

또 AI 리뷰 결과를 어디까지 저장할지도 정해야 한다.

리뷰 결과에는 코드 요약과 위험 분석이 포함된다.
이 정보도 회사 내부 정보일 수 있다.

따라서 로그 저장 기간과 접근 권한을 정해야 한다.

AI 리뷰 자동화도 결국 하나의 개발 도구다.

도구 자체의 보안, 비용, 운영 정책이 필요하다.

18. 정리

AI 코드 리뷰 자동화는 개발팀의 리뷰 품질을 높이는 데 도움을 줄 수 있다.

AI는 PR 변경 내용을 요약하고, 변경 영향도를 정리하고, 보안 취약점 후보를 찾고, 테스트 누락 가능성을 알려줄 수 있다.
리뷰어가 어디를 집중해서 봐야 하는지도 정리해줄 수 있다.

하지만 AI 리뷰는 사람 리뷰를 대체하지 않는다.

AI는 전체 비즈니스 맥락을 모를 수 있다.
레거시 의존성을 놓칠 수 있다.
실제로는 문제가 아닌 부분을 문제라고 할 수도 있다.
중요한 문제를 놓칠 수도 있다.

따라서 AI 리뷰는 최종 승인자가 아니라 리뷰 보조자로 사용해야 한다.

AI 코드 리뷰 자동화를 안전하게 사용하려면 다음 원칙이 필요하다.

- PR 요약부터 작게 시작한다
- 팀 리뷰 규칙을 프롬프트에 포함한다
- 민감한 파일은 AI 입력에서 제외한다
- 너무 큰 diff는 나누거나 요약한다
- AI 리뷰 결과를 참고 자료로 다룬다
- 고위험 영역은 사람이 반드시 검토한다
- AI 코멘트 품질을 주기적으로 개선한다
- 비용과 호출 빈도를 관리한다
- 프롬프트 변경 이력을 관리한다

AI 리뷰 자동화의 목표는 리뷰를 없애는 것이 아니다.

리뷰어가 더 중요한 문제에 집중하도록 돕는 것이다.

좋은 코드 리뷰 문화가 없는 팀에 AI를 붙인다고 갑자기 좋은 리뷰가 생기지는 않는다.
먼저 팀의 리뷰 기준이 있어야 하고, AI는 그 기준을 반복적으로 적용하도록 도와주는 역할을 해야 한다.

AI 리뷰 자동화는 개발 프로세스의 보조 장치다.

잘 설계하면 PR 리뷰의 품질과 속도를 함께 높일 수 있다.
하지만 최종 판단은 언제나 사람이 해야 한다.

30장 핵심 요약