AI에게 코드 리뷰 맡길 때 결과가 확 달라지는 프롬프트 템플릿 (복붙용)

안녕하세요, 라운지AI입니다. AI에게 "이 코드 리뷰해 줘"라고만 하면 대부분 변수명 바꾸기, 주석 달기 같은 얕은 이야기만 돌아와요. 반대로 맥락과 기준을 같이 주면 실제로 놓치기 쉬운 버그를 꽤 잘 짚어 줍니다. 제가 써 보고 효과가 좋았던 방식을 정리해 봤어요.

1. 결과가 얕아지는 이유

• 무엇을 하려는 코드인지 모르니 "의도와 다르게 동작하는 부분"을 찾을 수 없어요.
• 기준이 없으니 스타일 지적처럼 쉽게 말할 수 있는 것부터 채웁니다.
• 우선순위를 정해 주지 않으면 사소한 지적 10개 속에 진짜 버그 1개가 묻혀요.

2. 복붙용 리뷰 프롬프트

너는 꼼꼼한 시니어 개발자야. 아래 변경 사항을 리뷰해 줘.

[맥락]
- 이 코드가 하는 일: (예: 주문 취소 시 포인트를 환불하는 API)
- 언어/프레임워크/버전: (예: TypeScript, Node 20, Prisma)
- 특히 걱정되는 부분: (예: 동시에 두 번 취소 요청이 오는 경우)

[리뷰 기준] 아래 순서로, 중요한 것부터 봐 줘.
1. 정확성: 의도와 다르게 동작하는 입력이나 상태가 있는지
2. 경계값·예외: null, 빈 배열, 0, 아주 큰 값, 네트워크 실패
3. 동시성·중복 실행: 같은 요청이 두 번 들어오면?
4. 보안: 권한 확인 누락, 입력값 검증, 민감정보 로그
5. 성능: 반복문 안의 DB 호출(N+1) 등

[출력 형식]
- 문제마다: 심각도(높음/중간/낮음), 위치, 어떤 입력에서 무엇이 잘못되는지, 고친 코드
- 확실하지 않은 건 "추정"이라고 표시
- 스타일 지적은 맨 마지막에 3개 이하로만

[코드]
(여기에 diff 또는 코드)

핵심은 "어떤 입력에서 무엇이 잘못되는지"를 쓰게 하는 것이에요. 구체적인 실패 시나리오를 요구하면 근거 없는 지적이 확 줄어듭니다.

3. 받은 리뷰는 이렇게 검증해요

1. 재현부터: 지적된 시나리오를 테스트 코드로 먼저 만들어 실패하는지 확인해요. 실패하지 않으면 AI가 틀린 거예요.
2. 고친 코드는 그대로 붙이지 않기: 제안 코드가 다른 곳의 동작까지 바꾸는 경우가 있어서, 기존 테스트를 꼭 돌려 봐요.
3. "추정" 표시는 따로 확인: 라이브러리 동작에 대한 설명은 공식 문서로 한 번 더 확인하는 게 안전해요.

4. 주의할 점

• 회사 코드라면 사내 보안 정책부터 확인하세요. API 키, 고객 데이터, 내부 주소가 들어간 부분은 지우고 붙여 넣는 게 기본이에요.
• 파일 전체보다 변경된 부분(diff) + 관련 함수만 주는 편이 정확도가 높았어요. 너무 길면 앞부분 맥락을 놓치기도 해요.
• AI 리뷰는 사람 리뷰를 대신하기보다 사람이 보기 전에 한 번 거르는 용도로 쓸 때 만족도가 제일 높았습니다.

여러분은 코드 리뷰에 AI를 어떻게 쓰고 계신가요? 팀에서 쓰는 리뷰 기준이나 프롬프트가 있다면 댓글로 나눠 주세요.