생성형 AI를 개발에 도입하면 코드를 작성하는 부분은 눈에 띄게 빨라집니다. 반면, 리뷰하는 인원수나 CI의 실행 속도는 변하지 않습니다. 생성량만 늘리면 PR(Pull Request)이 리뷰 대기 상태가 되고, 수정 후 재확인하는 횟수도 늘어납니다.

이러한 병목 현상을 보면, AI에게 맡기는 순서가 반드시 코드 생성이 먼저일 필요는 없습니다. 저는 기존의 CI나 인간 리뷰의 전 단계에서 '제출 전 확인 역할'로 만드는 것이 더 통합하기 쉽다고 생각합니다.

AI에게 맡기는 것은 변경 내용의 정리, 누락 후보의 나열, 확인 사항의 언어화입니다. 빌드나 테스트의 성패, 머지(Merge) 가능 여부까지는 맡기지 않습니다.

경계는 다음과 같습니다.

AI가 "문제없습니다"라고 답하더라도, 그것이 테스트가 성공했다는 것을 의미하지는 않습니다. 반대로, Lint나 SAST(정적 분석 보안 테스트)의 실패 이유를 사람이 읽을 수 있는 형태로 정리하는 용도라면, 판정의 책임을 옮기지 않고도 사용할 수 있습니다.

구현
|
v
...

AI의 코멘트를 그대로 PR에 게시하면, 오탐(False Positive) 확인 작업을 리뷰어에게 떠넘기게 됩니다. 개발자가 한 번 읽고 채택, 기각, 확인 대기로 분류한 뒤에 내보내는 것이 다루기 쉽습니다.

리포지토리 전체를 매번 전달할 필요는 없습니다. 최소한 다음 정보를 조합합니다.

- 변경 목적
- 대상 파일
- git diff
...

관점도 고정합니다. 자유롭게 리뷰하게 하는 것보다, 이번에 확인해주길 바라는 항목을 5개 정도 지정하는 것이 코멘트의 입도가 일정해집니다.

다음 차이점(diff)을 리뷰해 주세요.
확인 관점:
- 수락 조건과의 불일치
...

근거가 되는 차이점과 확인 방법을 필수 항목으로 넣은 이유는, 그럴싸해 보이는 일반론을 배제하기 쉽게 하기 위해서입니다. 해당 행을 제시하지 못하는 지적은 일단 보류해도 괜찮습니다.

처음부터 AI의 결과로 CI를 실패하게 만드는 것은 피합니다. 도입 초기에는 AI의 출력을 아티팩트(Artifact)나 PR 코멘트로 남기기만 합니다.

jobs:
verify:
steps:
...

이 예시에는 인증이나 데이터 보호에 관한 내용은 적지 않았습니다. 실운용에서는 외부로 보낼 수 있는 차이점의 범위, 로그 보관 기간, 시크릿(Secret) 제거를 먼저 결정해야 합니다. 이것이 결정되지 않은 동안에는 공개 리포지토리나 더미 코드(Dummy Code)로만 테스트하는 것이 무난합니다.

AI 리뷰를 개선하려면 지적 수가 아니라 채택 여부를 기록합니다.

지적 수만 보면, 세세한 코멘트를 대량으로 내보내는 설정일수록 고평가됩니다. 우리가 남기고 싶은 것은 채택되었는지, 어떻게 확인했는지, 인간 리뷰 전에 발견할 의미가 있었는지입니다.

• AI가 생성한 코드에도 통상적인 테스트와 리뷰를 적용한다
• SAST 경고는 AI의 설명만으로 종결하지 않고, 수정 후 재스캔한다
• 불명확한 점을 추측으로 채우지 않고, 확인 대기로 남긴다
• 프롬프트(Prompt)나 에이전트(Agent) 설정도 Git으로 변경 관리한다
• AI 리뷰가 중단되더라도 통상적인 CI는 멈추지 않는 구성부터 시작한다

PR 전의 셀프 리뷰를 한 종류만 골라, 당분간 채택 여부를 기록해 보는 것이 작은 시작입니다. 거기서 노이즈가 많다면 관점을 좁힙니다. 도움이 된다면 테스트 관점이나 CI 실패 로그의 정리로 범위를 넓힙니다. 코드 생성과는 별개로, 이 순서로 시도해 볼 가치가 있습니다.