CLAB 인사이트 분석: AI 코드 리뷰는 정답 판정기가 아니라 하방을 막는 안전망이다

NAVER D2의 **「시간은 금이다: LLM을 이용한 AI 코드 리뷰 도입기」**를 CLAB 하네스 관점에서 보면, 중요한 질문은 “AI가 리뷰를 얼마나 잘하나”가 아니다. 더 현실적인 질문은 이것이다.

팀의 코드 리뷰 하방을 어떻게 일정 수준 이상으로 막을 것인가?

사람 리뷰는 중요하지만 항상 충분하지 않다. 바쁘면 놓친다. 익숙한 코드라서 넘긴다. 기능이 급하면 구조보다 동작만 본다. AI 코드 리뷰는 사람을 대체하기보다, 이런 빈틈을 먼저 훑어주는 안전망으로 쓰는 편이 맞다.

자동 리뷰는 팀 규칙을 먹고 자란다

이 자료에서 특히 눈에 들어온 부분은 AI 코드 리뷰어가 단순히 “코드 보고 의견 내는 모델”이 아니라는 점이다. 모델 선정, 실행 인프라, 리뷰 대상 수집, 결과 전달, 다음 개선까지 하나의 시스템으로 묶여 있다.

CLAB 하네스에서도 AI 리뷰를 붙인다면, 모델에게 이런 식으로 말하는 것은 부족하다.

이 PR 리뷰해줘.

이렇게 해야 한다.

이번 변경의 책임 영역은 무엇인가?
CLAB frontend convention 중 어떤 항목을 봐야 하는가?
변경 파일이 member / land / design-system 경계를 넘었는가?
API 계약을 임의로 바꾸지 않았는가?
UI 변경이라면 실제 화면 증거가 있는가?

AI 리뷰의 품질은 모델만으로 결정되지 않는다. 어떤 규칙을 주고, 어떤 evidence를 함께 주고, 어떤 형식으로 결과를 제한하느냐가 훨씬 크다.

CLAB 하네스에서 리뷰는 마지막이 아니라 흐름이다

코드 리뷰를 PR 마지막 단계에만 붙이면 늦다. 이미 범위가 커졌고, 파일이 많이 바뀌었고, 작성자는 “끝났다”고 생각한다. 그때 AI가 잔뜩 코멘트를 달면 귀찮은 봇이 된다.

CLAB 하네스에서는 리뷰가 더 앞에 있어야 한다.

요청 → task card → convention lookup → 작업 → diff hygiene → test/evidence → PR draft

여기서 AI 리뷰는 마지막 코멘트가 아니라 각 단계의 하방 체크다. 작업 전에는 범위가 과한지 보고, 작업 중에는 컨벤션을 다시 확인하고, 작업 후에는 diff와 evidence가 맞는지 본다.

이렇게 두면 AI 리뷰는 사람의 리뷰 시간을 빼앗는 도구가 아니라, 사람이 볼 만한 PR로 정리해주는 도구가 된다.

리뷰 결과는 사람에게 설명 가능해야 한다

AI 리뷰 도구를 붙일 때 흔한 실패는 코멘트가 많아지는 것이다. 코멘트가 많아지면 좋아 보이지만, 실제 팀에서는 읽히지 않는다. 특히 근거가 약한 코멘트, 취향에 가까운 코멘트, repo 컨벤션과 무관한 코멘트가 섞이면 신뢰가 빠르게 떨어진다.

그래서 CLAB 하네스에서는 리뷰 결과를 이렇게 나눠야 한다.

blocker: merge 전에 반드시 고쳐야 하는 것
warning: 사람 판단이 필요한 것
suggestion: 다음 리팩토링 후보
note: 이번 작업에서 배운 팀 규칙 후보

이 분류는 단순한 출력 형식이 아니다. AI가 팀의 의사결정에 끼어들 때 필요한 예의에 가깝다. 모든 것을 단정하지 않고, 근거가 있는 것과 제안에 가까운 것을 나눠야 한다.

CLAB에서는 이렇게 읽었다

이 자료를 보고 CLAB 하네스의 AI 리뷰 방향을 “똑똑한 리뷰어 만들기”로 잡으면 안 된다고 판단했다. 더 나은 방향은 팀이 놓치기 쉬운 하방을 자동으로 막는 리뷰 흐름이다.

CLAB 하네스가 해야 할 일은 PR마다 멋진 코멘트를 많이 다는 것이 아니다. 작업 범위를 좁히고, 컨벤션을 붙이고, 검증 결과를 남기고, 사람 리뷰어가 봐야 할 위험 지점을 줄여주는 것이다.