AI PR 피드백 루프

AI가 pull request를 빠르게 만들면 코드 리뷰의 의미도 바뀝니다. 예전에는 사람이 직접 고친 코드를 리뷰어가 확인했다면, VIBE 코딩에서는 사람이 목표와 제약을 주고 AI가 만든 diff를 리뷰어와 함께 검증합니다. 이때 가장 위험한 패턴은 리뷰 코멘트를 “AI에게 전부 반영해 줘”라고 한 번에 넘기는 것입니다. 코멘트의 의도, 위험도, 재현 방법, 테스트 필요성, 반박 가능성을 나누지 않으면 작은 지적이 큰 리팩터링으로 번지고, 좋은 코멘트가 엉뚱한 수정으로 바뀌며, 이미 통과한 기능이 깨집니다.

AI PR 피드백 루프는 리뷰 코멘트를 작업 단위로 분해하고, 각 코멘트를 acceptance criteria, 회귀 테스트, 작은 커밋, 리뷰 응답으로 연결하는 방식입니다. 초보자는 “리뷰를 받은 뒤 AI에게 다시 시키는 안전한 순서”로 이해하면 됩니다. 실무자는 더 엄격하게 봐야 합니다. 어떤 코멘트가 결함인지, 어떤 코멘트가 취향인지, 어떤 코멘트가 설계 논쟁인지, 어떤 코멘트가 배포 위험과 연결되는지 분류하고, 수정 전후 diff와 재현 명령을 남겨 리뷰어가 빠르게 판단하도록 만들어야 합니다.

이 글은 AI가 만든 PR에 코드 리뷰가 달렸을 때 한 번에 뭉개지 않고, 코멘트별로 검증 가능한 수정 루프를 만드는 방법을 다룹니다. 목표는 리뷰어를 설득하는 말재주가 아니라, 리뷰어 의도를 정확히 반영하거나 합리적으로 반박할 수 있는 증거를 만드는 것입니다.

핵심 결론

AI PR 피드백 루프의 핵심은 리뷰 코멘트를 “수정 요청 목록”이 아니라 “검증 가능한 결정 목록”으로 바꾸는 것입니다. 리뷰 코멘트 하나마다 먼저 분류합니다. 실제 버그인지, 누락된 테스트인지, 보안·성능·접근성 위험인지, 명명·구조 개선인지, 제품 요구사항 해석 차이인지 나눕니다. 그다음 각 코멘트에 대해 acceptance criteria를 한 줄로 씁니다. “빈 상태에서 버튼이 사라지지 않는다”, “권한 없는 사용자는 저장 요청 전에 차단된다”, “동일 입력에서 이전 스냅샷과 같은 결과를 낸다”처럼 관찰 가능한 문장이어야 합니다.

수정은 작은 커밋으로 나눕니다. 한 커밋은 한 코멘트 또는 강하게 연결된 코멘트 묶음만 다룹니다. AI에게는 “이 코멘트만 해결하고, 관련 없는 리팩터링을 하지 말고, 회귀 테스트를 먼저 추가하고, diff를 작게 유지하라”고 지시합니다. 수정 후에는 리뷰 응답에 무엇을 바꿨는지, 어떤 테스트와 재현 명령으로 확인했는지, 남은 배포 위험이 무엇인지 적습니다. 코멘트가 부정확하거나 제품 방향과 맞지 않으면 바로 무시하지 않고 반박 기준을 적용합니다. 재현되지 않는 이유, 기존 acceptance criteria와 충돌하는 이유, 대안이 더 안전한 이유를 diff와 테스트 근거로 설명합니다.

이 루프를 쓰면 PR은 “AI가 만든 큰 덩어리”에서 “리뷰 코멘트가 하나씩 닫히는 검증 단위”로 바뀝니다. 리뷰어는 다시 전체 코드를 처음부터 읽지 않고도 각 결정의 근거를 볼 수 있고, 작성자는 AI가 만든 수정이 원래 의도를 벗어나지 않았는지 추적할 수 있습니다. 특히 배포 직전의 PR에서는 이 방식이 rollback 판단에도 도움이 됩니다. 어떤 리뷰 코멘트가 배포 위험을 줄였고, 어떤 코멘트는 후속 작업으로 넘겼는지 기록되어야 배포 후 문제가 생겼을 때 되돌릴 범위를 작게 잡을 수 있습니다.

왜 중요한가

AI는 코멘트의 사회적 맥락을 모른다

리뷰 코멘트에는 코드 문장 이상의 맥락이 들어 있습니다. “이 함수가 너무 많은 일을 합니다”라는 말은 단순히 함수를 쪼개라는 뜻일 수도 있고, 테스트 가능성을 높이라는 뜻일 수도 있고, 책임 경계를 다시 보자는 설계 신호일 수도 있습니다. AI는 코멘트 문장만 보고 가장 그럴듯한 수정을 만들 수 있지만, 팀이 실제로 걱정한 배포 위험이나 유지보수 비용을 자동으로 이해하지 못합니다. 그래서 리뷰어 의도를 먼저 해석해야 합니다.

리뷰어 의도 해석은 어렵게 들리지만 실무에서는 간단한 질문으로 시작할 수 있습니다. 이 코멘트는 사용자에게 보이는 버그를 막으려는가, 개발자가 다음 변경을 안전하게 하도록 돕는가, 운영 중 장애 가능성을 줄이는가, 아니면 단지 코드 스타일을 맞추려는가. 이 질문에 답하면 AI에게 줄 작업 지시가 달라집니다. 버그 코멘트라면 재현 명령과 회귀 테스트가 먼저이고, 구조 코멘트라면 공개 동작이 바뀌지 않는다는 테스트가 먼저이며, 스타일 코멘트라면 자동 포맷과 lint 확인이 충분할 수 있습니다.

리뷰 코멘트를 한꺼번에 넘기면 diff가 폭발한다

AI에게 여러 코멘트를 한 번에 맡기면 수정 범위가 넓어집니다. 리뷰어가 요청하지 않은 이름 변경, 파일 이동, 추상화 추가, 테스트 재작성까지 섞일 수 있습니다. 그러면 PR은 더 좋아진 것처럼 보이지만 실제로는 리뷰 비용이 다시 커집니다. 리뷰어는 처음 코멘트가 해결됐는지 확인하기 위해 새 diff 전체를 다시 읽어야 하고, 새로운 변경에서 또 다른 위험을 찾아야 합니다.

작은 커밋은 이 문제를 줄입니다. 코멘트 A를 해결한 커밋, 코멘트 B를 해결한 커밋, 테스트 보강 커밋을 나누면 리뷰어는 의도와 diff를 연결해서 볼 수 있습니다. 나중에 문제가 생겨도 어느 코멘트 대응이 원인인지 좁힐 수 있습니다. VIBE 코딩에서 작은 커밋은 단순한 Git 취향이 아니라 AI 작업 범위를 통제하는 안전장치입니다.

좋은 리뷰 응답은 배포 문서의 일부다

리뷰 응답은 “수정했습니다”로 끝나면 안 됩니다. 특히 AI가 수정한 경우에는 무엇을 수정했는지보다 어떻게 검증했는지가 중요합니다. “빈 목록 상태를 재현하는 테스트를 추가했고, 기존 카드 렌더링 테스트와 빌드를 통과했습니다”처럼 재현 명령과 검증 범위를 포함해야 합니다. 이 기록은 나중에 배포 승인, 장애 분석, rollback 판단에 그대로 쓰입니다.

실제 작업 순서

1단계: 코멘트 인벤토리를 만든다

PR에 달린 코멘트를 그대로 AI에게 넘기지 말고 먼저 인벤토리를 만듭니다. 각 코멘트에 번호를 붙이고 유형을 나눕니다. 예를 들어 C1은 버그, C2는 테스트 누락, C3은 접근성, C4는 명명 개선, C5는 제품 요구사항 확인처럼 적습니다. 각 항목에는 원문 요지를 짧게 붙이되, 리뷰어를 공격하거나 방어하는 표현은 빼고 관찰 가능한 문제로 바꿉니다.

좋은 인벤토리 문장은 “리스트가 비었을 때 빈 상태 안내가 사라질 수 있음”입니다. 나쁜 문장은 “리뷰어가 빈 상태를 걱정함”입니다. 전자는 테스트로 확인할 수 있고, 후자는 감정과 추측이 섞입니다. AI에게는 전자 같은 문장을 줘야 합니다.

2단계: acceptance criteria를 코멘트별로 쓴다

각 코멘트에는 통과 기준이 있어야 합니다. acceptance criteria는 리뷰어의 요구를 실행 가능한 문장으로 바꾼 것입니다. “빈 상태 안내가 보인다”보다 “결과 배열이 0개이고 필터가 적용된 상태에서도 빈 상태 제목, 설명, 다음 행동 버튼이 렌더링된다”가 더 좋습니다. “에러 처리가 좋아진다”보다 “외부 호출이 500을 반환하면 사용자에게 재시도 가능한 안내를 보여 주고 내부적으로 실패 카운터가 증가한다”가 더 좋습니다.

이 기준은 AI의 작업 지시서가 됩니다. 기준이 흐리면 AI는 넓게 고치고, 기준이 선명하면 작게 고칩니다. 기준에는 사용자가 보는 결과, 시스템 상태, 테스트가 관찰할 신호를 함께 넣는 것이 좋습니다.

3단계: 먼저 회귀 테스트를 추가한다

버그나 누락을 다루는 코멘트라면 회귀 테스트를 먼저 씁니다. 이미 동작하는 코드에 대한 리뷰라도 마찬가지입니다. 테스트가 먼저 실패해야 AI가 정말 해당 문제를 해결했는지 알 수 있습니다. UI라면 렌더링 조건, 접근성 이름, 클릭 후 상태를 테스트하고, API라면 요청 입력, 권한, 실패 응답, 재시도 조건을 테스트합니다.

테스트를 쓸 수 없는 코멘트도 있습니다. 예를 들어 변수 이름이나 파일 구조처럼 정성적인 리뷰는 테스트보다 diff 제한과 lint가 더 적합할 수 있습니다. 그래도 공개 동작이 바뀌지 않는다는 기존 테스트, 스냅샷 범위, 타입 검사, 빌드 검증은 유지해야 합니다. “테스트 없음”은 허용될 수 있지만 “검증 없음”은 허용하면 안 됩니다.

4단계: AI에게 한 코멘트만 맡긴다

AI 작업 지시는 작아야 합니다. “C1만 해결하라. C2와 C3은 건드리지 마라. 먼저 실패하는 회귀 테스트를 만들고, 최소 수정으로 통과시켜라. 관련 없는 리팩터링, 이름 변경, 파일 이동을 하지 마라. 마지막에 변경 파일과 테스트 명령을 요약하라.” 이런 식으로 제한합니다. 이 제한이 있어야 AI가 코드베이스 전체를 다시 설계하려는 유혹을 줄일 수 있습니다.

실무에서는 한 코멘트가 여러 파일을 건드릴 수 있습니다. 그래도 작업의 이유는 하나여야 합니다. “권한 없는 저장 차단”이라는 이유로 미들웨어, 버튼 비활성화, API 검증, 테스트를 함께 고칠 수는 있습니다. 하지만 같은 커밋에서 디자인 색상, 함수 이름, 불필요한 추상화까지 바꾸면 리뷰 응답이 흐려집니다.

5단계: diff를 읽고 리뷰어 의도와 맞는지 확인한다

AI가 수정한 뒤에는 테스트 결과만 보지 말고 diff를 읽습니다. 확인할 질문은 네 가지입니다. 첫째, 코멘트의 acceptance criteria를 정확히 만족하는가. 둘째, 관련 없는 파일이 바뀌지 않았는가. 셋째, 새 조건이 기존 사용자 흐름을 막지 않는가. 넷째, 배포 위험이 더 커지지 않았는가. 특히 조건문과 권한 로직은 AI가 지나치게 넓게 차단하는 경우가 있으므로 입력별 예시를 직접 확인해야 합니다.

이 단계에서 마음에 들지 않으면 바로 추가 수정하지 말고 코멘트 인벤토리로 돌아갑니다. 기준이 잘못됐는지, AI 지시가 넓었는지, 리뷰어 의도가 다른지 다시 정리합니다. 무작정 “더 깔끔하게”라고 요청하면 diff가 다시 커집니다.

6단계: 리뷰 응답을 증거 중심으로 쓴다

리뷰 응답은 짧지만 근거가 있어야 합니다. “C1 반영했습니다. 빈 상태에서도 안내와 다음 행동 버튼이 보이도록 조건을 분리했고, 빈 결과 회귀 테스트를 추가했습니다. 확인: focused test, lint, build.”처럼 씁니다. 반박이 필요한 경우에는 “현재 요구사항에서는 관리자와 일반 사용자의 빈 상태 메시지가 달라야 해서 제안한 공통 컴포넌트 추출은 이번 PR에서 보류합니다. 대신 중복 위험을 줄이기 위해 테스트를 추가했습니다.”처럼 대안과 검증을 같이 적습니다.

리뷰 응답은 사람에게 쓰는 문장입니다. 내부 경로나 민감한 설정 이름을 그대로 붙이지 말고, 공개되어도 안전한 명령 범위와 결과만 적습니다. 실패한 실험이 있었다면 원인을 간단히 적되, 비밀 값이나 내부 연결 정보는 남기지 않습니다.

7단계: 남은 코멘트와 배포 위험을 닫는다

모든 코멘트를 닫기 전에 “이번 PR에서 처리하지 않는 것”을 분리합니다. 제품 결정이 필요한 코멘트, 범위가 큰 리팩터링, 별도 마이그레이션이 필요한 작업은 후속 이슈로 넘길 수 있습니다. 단, 그냥 넘기지 말고 배포 위험을 평가해야 합니다. 지금 배포해도 사용자 피해가 없는가, rollback 기준이 있는가, 모니터링에서 확인할 신호가 있는가, 다음 PR이 없으면 기술 부채가 커지는가를 적습니다.

상황별 예시

예시 1: UI 빈 상태 코멘트

리뷰어가 “필터 결과가 0개일 때 화면이 비어 보일 수 있습니다”라고 남겼다고 가정합니다. 이 코멘트는 사용자 경험 버그이며 회귀 테스트가 필요합니다. acceptance criteria는 “필터 결과가 0개여도 빈 상태 제목, 설명, 필터 초기화 버튼이 보인다”입니다. AI에게는 빈 배열과 활성 필터를 가진 렌더링 테스트를 먼저 추가하라고 지시합니다. 수정은 조건문 하나일 수도 있고, 빈 상태 컴포넌트 분리일 수도 있습니다. 중요한 것은 전체 목록 구조를 갈아엎지 않는 것입니다.

리뷰 응답은 이렇게 씁니다. “필터 적용 후 결과가 0개인 상태를 회귀 테스트로 고정했고, 빈 상태 안내와 초기화 버튼을 렌더링하도록 조건을 분리했습니다. 기존 일반 목록 렌더링 테스트도 통과했습니다.” 이 응답은 리뷰어가 무엇을 다시 확인해야 하는지 바로 알려 줍니다.

예시 2: API 권한 코멘트

리뷰어가 “클라이언트에서 버튼을 숨겨도 직접 요청하면 저장될 수 있습니다”라고 남겼다면 보안·권한 코멘트입니다. acceptance criteria는 “권한 없는 사용자의 저장 요청은 서버에서 403으로 거절되고 저장 부작용이 없다”입니다. AI에게는 서버 검증 테스트를 먼저 쓰게 합니다. UI 버튼 비활성화만 고치면 코멘트를 해결한 것이 아닙니다. diff에서는 서버 경계에서 권한을 확인하는지, 실패 응답이 과도한 내부 정보를 주지 않는지, 성공 경로가 깨지지 않는지 봅니다.

이 경우 리뷰 응답은 “서버 저장 경계에서 권한 검사를 추가했고, 권한 없는 요청이 부작용 없이 거절되는 테스트를 추가했습니다”처럼 써야 합니다. “버튼을 숨겼습니다”라고 답하면 리뷰어 의도를 놓친 것입니다.

예시 3: 설계 분리 코멘트

리뷰어가 “이 훅이 데이터 로딩과 화면 상태를 모두 다룹니다”라고 남겼다면 설계 코멘트입니다. 바로 큰 리팩터링을 하지 말고 배포 위험을 봅니다. 해당 훅이 이번 PR의 핵심 위험인지, 아니면 후속 정리인지 판단합니다. acceptance criteria는 “공개 동작은 유지하면서 데이터 로딩 책임과 화면 표시 상태 책임을 분리한다”가 될 수 있습니다. 테스트는 기존 사용자 흐름이 그대로 유지되는지 확인하는 쪽이 중요합니다.

설계 코멘트는 반박 기준도 필요합니다. PR 범위를 넘는다면 “이번 PR에서는 버그 수정 범위를 유지하기 위해 책임 분리는 후속 작업으로 분리하고, 대신 현재 변경이 깨지지 않도록 회귀 테스트를 추가했습니다”라고 답할 수 있습니다. 반박은 무시가 아니라 범위 관리입니다.

예시 4: 성능 코멘트

리뷰어가 “이 계산이 렌더마다 반복됩니다”라고 남겼다면 성능 코멘트입니다. 먼저 실제 영향이 있는지 확인합니다. acceptance criteria는 “동일 입력에서 비싼 계산은 한 번만 수행되고, 목록 100개 기준 렌더 시간이 기준선을 넘지 않는다”처럼 숫자나 관찰 지표를 포함할 수 있습니다. AI에게 무조건 메모이제이션을 넣으라고 하면 의존성 배열 실수로 오래된 값을 보여 줄 수 있습니다. 성능 수정은 정확성 회귀 테스트와 함께 가야 합니다.

리뷰 응답에는 “계산 범위를 입력 변경 시점으로 제한했고, 동일 입력 재렌더에서 결과가 유지되는 테스트를 추가했습니다. 과도한 최적화를 피하기 위해 데이터 구조 변경은 하지 않았습니다”처럼 실무 판단을 적습니다.

실수와 주의점

“모두 반영” 프롬프트는 금물이다

리뷰 코멘트를 복사해 “모두 반영해 줘”라고 요청하면 AI는 코멘트 사이의 우선순위와 범위를 구분하지 못합니다. 특히 서로 충돌하는 코멘트가 있을 때 위험합니다. 한 리뷰어는 추상화를 줄이라고 하고, 다른 리뷰어는 공통 컴포넌트를 만들라고 할 수 있습니다. 이때 AI가 둘을 동시에 만족시키려 하면 이상한 중간 구조가 나옵니다. 먼저 사람 또는 운영자가 분류하고 결정해야 합니다.

테스트 없이 스타일만 고치다 기능을 깨뜨릴 수 있다

명명, 폴더 이동, 컴포넌트 분리처럼 안전해 보이는 수정도 공개 동작을 바꿀 수 있습니다. import 순서가 바뀌거나 초기화 타이밍이 달라지거나 상태 보존이 깨질 수 있습니다. 그래서 “스타일 코멘트”라도 최소한 기존 테스트, 타입 검사, 빌드는 돌려야 합니다. 사용자 흐름과 연결된 구조 변경이면 회귀 테스트를 추가해야 합니다.

리뷰어와 싸우는 응답은 문제 해결을 늦춘다

AI가 만든 코드를 사람이 방어하려다 보면 리뷰 응답이 감정적으로 변할 수 있습니다. 좋은 응답은 방어가 아니라 증거입니다. 리뷰어가 틀렸다고 생각해도 “재현 조건을 확인했지만 현재 입력 조합에서는 실패하지 않았습니다. 다만 혼동을 줄이기 위해 경계값 테스트를 추가했습니다”처럼 사실과 대안을 제시합니다. 반박 기준은 리뷰어를 이기기 위한 규칙이 아니라 PR을 안전하게 닫기 위한 규칙입니다.

배포 위험을 코멘트 완료와 혼동하지 않는다

모든 코멘트가 resolved가 되어도 배포가 안전하다는 뜻은 아닙니다. 리뷰 과정에서 큰 구조가 바뀌었거나 권한 경계가 수정됐거나 성능 최적화가 들어갔다면 배포 위험은 오히려 커질 수 있습니다. 마지막에는 코멘트 완료 여부와 별개로 smoke test, 주요 경로 확인, 오류 로그, rollback 기준을 다시 봐야 합니다.

AI가 만든 리뷰 응답을 그대로 붙이지 않는다

AI는 그럴듯한 리뷰 응답을 잘 씁니다. 하지만 실제로 돌리지 않은 테스트를 “통과했다”고 쓰거나, 수정하지 않은 범위를 수정했다고 말할 수 있습니다. 리뷰 응답은 반드시 실제 명령과 diff를 확인한 뒤 사람이 승인해야 합니다. 확인하지 않은 내용은 쓰지 않습니다.

검증 체크리스트

코멘트 분류 확인

• 모든 리뷰 코멘트가 버그, 테스트, 보안·권한, 성능, 접근성, 설계, 스타일, 제품 결정, 후속 작업 중 하나로 분류되었는가.
• 각 코멘트에 acceptance criteria가 있는가.
• 코멘트 간 충돌이나 우선순위 문제가 먼저 해결되었는가.
• 처리하지 않는 코멘트는 후속 작업과 배포 위험으로 분리되었는가.

테스트와 diff 확인

• 버그성 코멘트에는 실패하는 회귀 테스트가 먼저 있었는가.
• AI 수정 diff가 해당 코멘트 범위를 넘지 않는가.
• 작은 커밋 단위로 리뷰어가 의도와 변경을 연결해 볼 수 있는가.
• 테스트, 타입 검사, lint, build 결과가 실제로 확인되었는가.
• 공개 동작, 권한 경계, 오류 메시지, 접근성 이름, 성능 지표가 필요한 범위에서 유지되는가.

리뷰 응답 확인

• 리뷰 응답이 “수정했습니다”가 아니라 변경 내용과 검증 근거를 포함하는가.
• 반박이 필요한 코멘트는 재현 결과, 기존 기준과의 충돌, 대안, 후속 작업을 설명하는가.
• 민감한 설정 이름, 내부 연결 정보, 로컬 파일 경로, 토큰성 문자열이 응답에 포함되지 않았는가.
• 배포 위험과 rollback 조건이 필요한 PR에서는 마지막 요약에 남아 있는가.

다음 단계

첫 번째로 팀에서 쓰는 리뷰 코멘트 분류표를 만드세요. 복잡한 도구가 필요하지 않습니다. 버그, 테스트, 권한, 성능, 접근성, 설계, 스타일, 제품 결정, 후속 작업 정도면 충분합니다. 다음 PR부터 리뷰 코멘트가 달리면 이 분류표에 맞춰 번호를 붙이고 acceptance criteria를 한 줄씩 작성합니다. 그다음 AI에게 한 번에 하나의 코멘트만 맡깁니다.

두 번째로 리뷰 응답 템플릿을 짧게 고정하세요. “무엇을 바꿨는가”, “어떤 테스트 또는 재현 명령으로 확인했는가”, “남은 위험이나 후속 작업은 무엇인가” 세 줄이면 충분합니다. 이 템플릿은 AI에게 초안을 만들게 할 수 있지만, 실제 검증 결과와 diff를 본 뒤에만 붙입니다.

세 번째로 PR 병합 전 마지막 smoke loop를 추가하세요. 리뷰 코멘트를 모두 닫은 뒤에도 대표 사용자 경로, 권한 실패 경로, 변경된 화면의 빈 상태, 오류 응답, 성능에 민감한 목록, 배포 후 관측 신호를 다시 확인합니다. 문제가 생기면 어느 작은 커밋을 되돌릴지 rollback 후보를 정합니다.

마지막으로 이 루프를 팀의 기본 VIBE coding 작업 지시서에 넣으세요. “리뷰 코멘트는 분류하고, acceptance criteria를 만들고, 회귀 테스트를 먼저 추가하고, 작은 커밋으로 수정하고, 증거 중심으로 리뷰 응답한다.” 이 한 문장이 들어가면 AI가 만든 PR도 사람 팀의 리뷰 품질과 운영 기준 안에서 움직이기 시작합니다.