서론

Claude Code에 코드 리뷰를 맡기게 된 이후로, 줄곧 철저히 지키고 있는 것이 있습니다. 리뷰는 구현을 진행한 것과 동일한 세션(대화창)에서 시키지 않고, 반드시 별도의 세션을 새로 열어서 실행한다는 규칙입니다.

구현 직후의 세션은 「동작하는 것을 확인했다」라는 문맥을 그대로 끌고 가기 때문에, 그 전제를 스스로 무너뜨리려는 지적이 나오기 어려워집니다. 인간의 셀프 리뷰(Self-review)가 제대로 작동하기 어려운 것과 같은 구조입니다. 세션을 분리하여 구현 경위를 전혀 모르는 상태에서 검토하게 하니, 구현 측면에서는 나오지 않았던 각도의 지적이 돌아오는 빈도가 확실히 높아졌습니다.

이 운용을 철저히 하고 있다면 충분하다고 생각했습니다. 그런데 어떤 실례를 통해 그 인식이 깨졌습니다.

실례: 1만 행 CSV 사건

어느 PR(Pull Request)에서 CSV 업로드 처리에 대한 리뷰 결과는 「사양대로 동작하고 있으며, 버그도 없다」는 것이었습니다. 별도 세션에서의 리뷰로서는 판정에 문제가 없습니다.

하지만 실제 코드를 살펴보니, 1만 행이 있는 CSV를 청크 분할(Chunking)도 하지 않고 통째로 하나의 변수에 읽어들이는 구현이 되어 있었습니다.

# 리뷰는 「사양대로·버그 없음」이라고 판정했던 코드
rows = [row for row in csv.reader(f)] # 1만 행을 1개의 리스트에 전부 담음
# 실제 운용 시에는 청크 단위로 처리하여 메모리에 다 올라가지 않도록 해야 함
...

개발 시의 테스트 데이터는 건수가 적기 때문에, 이 상태에서도 테스트는 정상적으로 통과합니다. 리뷰 또한 사양과의 정합성 및 기지의 버그 패턴이라는 축에서는 아무런 문제를 검출할 수 없습니다.

AI 리뷰가 보고 있는 축, 보고 있지 않은 축

여기서 깨달은 점은, 「사양을 충족하고 버그가 없다」는 것과 「실제 운용 데이터량에서 메모리나 퍼포먼스 측면에서 파탄 나지 않는가」는 애초에 검증하고 있는 축이 다르다는 것입니다.

정리하자면, AI 리뷰가 강한 영역과 약한 영역은 다음과 같이 나뉩니다.

세션을 분리하여 「진단의 독립성」을 확보하더라도, 이 표의 오른쪽 관점은 애초에 리뷰의 스코프(Scope)에 들어오지 않습니다. 건수가 적은 테스트 데이터에서는 문제가 표면화되지 않기 때문에, 리뷰도 테스트도 그냥 지나치게 됩니다.

그래서 마지막은 사람의 눈을 거친다

AI 리뷰의 「지적 없음」은 「운영 환경에서 안전함」의 증명이 아니다. 이 전제에 입각하여, 별도 세션에서의 리뷰를 거친 후에도 최종 확인만큼은 반드시 자신의 눈으로 직접 수행하고 있습니다.

살펴보는 포인트는 리뷰가 검출하기 어려운 오른쪽의 관점, 특히 「이 코드는 운영 환경에 준하는 데이터량에서도 같은 방식 그대로 괜찮은가」입니다. CSV 사건 이후로는 데이터를 읽어들이는 처리, 루프(Loop) 처리, 외부 API를 호출하는 처리에 대해서는 건수나 요청 수가 늘어났을 때 어떻게 될지를 의식하며 확인하고 있습니다.

요약

• 리뷰를 구현과 별도의 세션으로 분리하는 것은 판정의 독립성을 확보하기 위한 최소한의 기준
• 다만 AI 리뷰는 「사양과의 정합성」, 「기지의 버그 패턴」에는 강한 반면, 「스케일 시의 설계 판단」, 「비기능 요구사항」은 검증 스코프에 포함되지 않는 경우가 많음
• 테스트 데이터의 건수가 적으면 이러한 종류의 결함은 표면화되지 않아 리뷰와 테스트를 모두 통과해 버림
• 「지적 없음」을 그대로 믿지 말고, 운영 환경에 준하는 데이터량과 실제 운용 조건을 의식한 최종 확인은 사람의 몫으로 남겨둘 것

Discussion