Claude Code를 사용할 때 적대적 리뷰(adversarial reviews)를 하지 않으면 버그를 배포하는 꼴입니다

에이전트한테 진짜 일을 맡기기 시작하면, 넌 더 이상 코드를 짜는 사람이 아니라 그 코드에 책임을 지는 사람이 되는 거야. 나쁘지 않은 거래지만, 네 직업의 성격 자체가 바뀌는 거지. 운영 환경에서 뭐가 터지면 아무도 그 코드가 어떻게 만들어졌는지는 안 물어봐. 그냥 너만 쳐다볼 거니까.

내버려 두면 에이전트는 쓰레기 같은 결과물만 내놔. 멍청해서가 아니라, 검사하는 사람이 없으면 뭐든 다 그렇게 되거든. 주니어 개발자도 똑같고, 너도 컨디션 안 좋은 날엔 그럴 수 있어.

에이전트를 굴리는 방법은 크게 두 가지야. 하나는 에이전트 위에 딱 붙어서 모든 단계를 일일이 지시하는 건데, 이건 직접 타이핑하는 것보단 빠를지 몰라도 결국 애 보는 꼴이 돼. 에이전트가 멈췄다 다시 시작할 때마다 문제 상황을 머릿속에 다시 집어넣어야 하고, 한눈팔다 딴짓이라도 하면 그냥 직접 하는 것보다 더 느려져.

다른 방법은 에이전트를 부하 직원처럼 대하는 거야. 뭘 원하는지, 대충 어떻게 하라고 던져주고 결과물 나올 때쯤 확인하는 거지. 시니어 엔지니어들은 에이전트 도구를 다 이렇게 써. 결과에 책임을 지기 위해 모든 키스트로크를 다 지켜볼 필요는 없어. 관리자들도 다 그렇게 안 하잖아. 대신 검토는 네 몫이야. 그걸 건너뛰면 쓰레기 같은 코드가 그대로 나가는 거지.

그러니까 두 번째 모델을 붙여서 문제점을 찾으라고 시켜

그게 바로 적대적 검토(adversarial review)야. 한 모델이 코드를 짜면, 다른 모델(혹은 적어도 앞선 맥락을 전혀 모르는 모델)이 diff를 읽고 뭐가 잘못됐는지 찾아내는 거지. 이 모델은 코드를 직접 수정할 권한은 없고, 문제점만 지적할 수 있어. 그럼 작성자 모델이 그걸 보고 수정할지 말지 결정하고, 다시 결과를 확인하는 식이야. 대부분의 경우 뭔가 찾아내더라고.

덕분에 더 좋은 코드가 나오긴 하지만, 사실 그게 진짜 목적은 아니야. 네가 직접 지켜보지 않은 결과물을 믿을 수 있게 만드는 게 핵심이지. 에이전트가 너한테 시간을 벌어줬잖아. 그 남는 시간, 추가적인 검토, 토큰 몇 푼이면 되는 공짜 눈깔 하나를 여기에 쓰는 거야.

데이터

내가 최근에 Codex 검토를 거쳐 완료한 티켓 83개를 살펴봤는데, 최소 67개는 코드에 실질적인 수정이 들어갔어. 첫 번째 시도에서 잘못됐거나 놓쳤던 부분들을 배포 전에 잡아낸 거지. 검토 5번 중 4번은 고칠 만한 게 나왔다는 소리야.

이 검토들이 유도한 122개의 커밋을 문제 유형별로 분류해 보면 이래:

What got caught	Share of commits
Correctness / logic	34%
Concurrency / races	22%
Durability / data	19%
Security / injection	9%
Test integrity	9%