AI 코드 리뷰, 어디까지 믿을까

AI 도구를 팀에 들여오면서, 기대와 불안이 같이 왔다. 빠르다. 그런데 책임은 누구에게 남는가.

기대했던 것

• 반복적인 스타일 지적 자동화
• 리뷰 전 초안 품질 향상
• 아키텍처 설명 문서 초안 생성
• 신규 인원 온보딩 보조

불안했던 것

• 그럴듯하지만 틀린 제안
• 보안/성능 이슈 누락
• 팀원마다 프롬프트 편차
• “AI가 봤으니 괜찮겠지” 분위기

팀에 맞춰 정한 선

• AI 제안은 참고 의견으로만 남긴다.
• AI 의 간섭범위는 프롬프트를 통해 제한하여 제어한다.
• 배치/결제/인증은 사람 리뷰를 필수로 뒀다.
• Prettier/ESLint는 도구가 막고, 설계는 사람이 본다.
• “왜 이 구조인가”는 PR 본문에 직접 적게 했다.

비슷한 경험 — 새 도구를 들일 때마다 반복된 질문

돌아보면 AI 도구도 결국 “새로운 것 vs 안정성”이라는 같은 갈림길의 최신 버전이었다. Jira·Slack을 도입할 때도, 클린코드 자동화를 걸 때도 똑같은 질문을 했다. 이게 일을 줄여주는가, 아니면 새로운 책임을 늘리는가.

• 이유: 신기술은 늘 매력적이지만, 검증 없이 받아들이면 “AI가 봤으니 괜찮겠지” 같은 책임 공백이 생겼다. 빠르게 도입하고 싶은 마음이 가장 위험해지는 지점이었다.
• 당시 결론: 도입을 막지 않되, 신뢰 범위를 명시적으로 선을 그었다. AI는 참고 의견, 결제·인증·배치는 사람 필수 리뷰. 도구를 믿는 게 아니라 도구의 자리를 정한 것이다.
• 새 도구를 대하는 내 기준은 일관됐다. 쓸까 말까가 아니라 어디까지 맡길까를 먼저 정한다.

느낀 점과 개선점

AI는 속도를 올려줬다. 하지만 최종 판단은 여전히 사람에게 있어야 했다.

다만 운영하며 드러난 부족함도 있다.

• 프롬프트로 간섭 범위를 제한했지만, 팀원마다 프롬프트 편차가 여전히 크다. 같은 도구가 사람마다 다른 품질을 냈다.
• “AI가 봤다”는 안도감이 사람 리뷰를 느슨하게 만드는 부작용을 완전히 막지 못했다.
• AI가 놓치기 쉬운 영역(보안·성능·도메인 규칙)을 체크리스트로 고정하지 못해, 사람의 기억에 의존한다.

앞으로 나가야 할 방향

1. 팀 공용 프롬프트/룰셋을 표준화(.cursor/rules 등)해, AI 리뷰 품질이 사람에 따라 흔들리지 않게 한다.
2. PR 템플릿에 “AI가 본 것 / 사람이 반드시 볼 것”을 분리해, 책임 공백이 생기지 않게 한다.
3. 보안·결제·인증 같은 민감 영역은 결제/정산 체크리스트와 묶어, 사람 리뷰 필수 항목을 명시적으로 남긴다.
4. AI를 클린코드 자동화(클린코드 플레이북)의 ‘1차 정리 단계’로 끼워, 사람은 설계 판단에만 집중하게 한다.

지금은 AI를 대체재가 아니라, 리뷰 전 정리 도구로 쓰는 쪽이 더 편했다. 다음 목표는 그 “편함”을 개인기에서 팀 공통의 기준으로 끌어올리는 것이다.