AI가 코드를 다 짜주는데,
왜 코드 리뷰를 더 자주 돌리게 될까
AI 에이전트한테 코드를 맡기면서, 사실 저는 한동안 제가 직접 만든 점검 명령 하나만 돌리고 있었어요.
그러다 Claude Code에 /code-review라는 게 따로 있다는 걸 뒤늦게 알았고, 그냥 한번 써봤죠. 별것 아닌 시작이었는데, 거기서 배운 게 의외로 컸어요 —
아무리 문서에 있어도, 직접 써보고 체감하기 전엔 아무 소용이 없다는 거요. AI한테 코드를 맡기는 분이라면 알아둘 만해요.
01원래 나는, 내가 만든 명령 하나만 돌렸어요
저는 1인 스튜디오로 작은 SaaS를 여러 개 빌드해요. 한동안 제 검증은 단순했어요 — 제가 직접 만들어 둔 점검 명령 하나를 돌리는 것. 그거면 충분하다고 생각했죠.
그러다 우연히 Claude Code에 /code-review라는 빌트인 명령이 따로 있다는 걸 알게 됐어요. 방금 바뀐 부분(git diff)을 버그·정리 관점으로 훑어주는 거였어요. "있는 줄도 몰랐네" 싶어서 그냥 한번 돌려봤어요.
그런데 돌릴 때마다 자꾸 뭔가가 나왔어요. 그러면서 점점 더 자주 돌리게 됐고요. 두 가지가 궁금해졌어요 — 왜 자꾸 뭐가 나오지, 그리고 나는 왜 이걸 여태 몰랐지.
02AI가 준 건 코드지, '이해'가 아니에요
이유는 생각보다 단순했어요. 손으로 코드를 짤 땐, 이해가 공짜로 따라와요. 한 줄씩 직접 치는 과정 자체가 곧 이해니까, 다 짜고 나면 왜 그렇게 동작하는지 이미 머릿속에 있죠.
그런데 에이전트가 짜면, 코드는 받는데 이해는 안 따라와요. 결과물만 뚝 떨어지고 "왜 이렇게 했는지"는 빠져 있어요. 그래서 파일마다 보이지 않는 '이해 빚'이 붙어요 — 지금은 안 보이지만, 버그를 고치거나 기능을 얹을 때 결국 다시 읽어서 갚게 되는 빚이요.
코드 리뷰는 바로 그 빚을 미루지 않고 그 자리에서 갚는 행동이었어요. 그래서 AI한테 더 많이 맡길수록, 리뷰가 더 자주 필요해졌던 거예요. 생성이 싸졌다고 일이 사라진 게 아니라, 이해가 코드에서 떨어져 나와 뒤로 미뤄졌을 뿐이거든요.
03나만 그런 줄 알았어요
처음엔 "내가 코드를 대충 봐서 그런가" 싶었어요. 그래서 찾아봤더니, 데이터가 같은 말을 하고 있었어요.
코드 품질 도구를 만드는 Sonar의 조사에서, 개발자의 96%가 "AI가 짠 코드가 기능적으로 맞는지 완전히 믿지는 않는다"고 답했어요. 그런데 정작 커밋 전에 항상 확인하는 사람은 48%뿐이었고요.
제가 /code-review를 자꾸 돌리게 된 게, 유난스러운 습관이 아니었던 거예요. 다들 빚이 있는 걸 알아요. 다만 절반은 갚고, 절반은 미룰 뿐이고요.
04왜 '한 번 더 보는 것'이 그렇게 통할까
여기서 흥미로운 지점이 있어요. 코드를 짠 그 세션(나든, 에이전트든)은 '이해한 착각'을 갖고 있어요 — 방금 만들었으니 다 안다고 느끼죠. 그 상태로 "맞는지 봐줘"라고 하면, 자기가 만든 걸 자기가 보증하는 셈이에요.
/code-review가 힘을 갖는 건 그래서예요. 그건 전체 대화 맥락이 아니라 바뀐 코드(diff)를 새로 들여다봐요. 맥락이 줄어든 눈으로 보면, "방금 안다고 느꼈던 것"과 "코드에 실제로 적힌 것"의 틈이 드러나거든요. 그 틈이 바로 이해 빚이 숨어 있던 자리예요.
같은 원리를 더 밀어붙이고 싶다면, Claude Code엔 두 가지 길이 더 있어요.
① 맥락이 아예 0인 리뷰어를 따로 두기. 서브에이전트는 자기만의 독립 컨텍스트에서 돌아요. 읽기 전용 리뷰어를 하나 만들어두면, 코드를 짠 적 없는 눈으로 점검하게 할 수 있어요:
# .claude/agents/reviewer.md
---
name: reviewer
description: 코드를 처음 보는 시선으로 변경분을 검토. 검토가 필요할 때 사용.
tools: Read, Grep, Glob, Bash # Edit·Write 없음 = 읽기 전용
model: sonnet
---
당신은 이 코드를 처음 보는 리뷰어입니다.
코드만 보고 "이게 무엇을, 왜 하는지"를 다시 설명해 보세요.
설명이 막히는 지점이 곧 점검해야 할 지점입니다.
tools에서 Edit·Write를 뺀 게 핵심이에요 — 고치진 못하고 검토만 하는 눈이 되는 거죠.
② 검토를 자동으로 돌리기. 매번 기억해서 돌리는 대신, 공식 security-guidance 플러그인을 깔면 편집·커밋마다 자동으로 점검이 돌아요. "의지"를 "기본 동작"으로 바꾸는 거예요.
05결국, 써보기 전엔 아무것도 아니었어요
이 작은 일에서 제가 진짜로 건진 건, '이해 빚'이라는 개념이 아니었어요. 그건 머리로 정리한 거고요.
진짜 깨달음은 이거예요 — 아무리 공식 문서에 있어도, 내가 직접 써보고 체감하기 전까진 그 기능은 나에게 없는 거나 마찬가지더라고요. /code-review는 줄곧 문서에 있었어요. 그런데 제가 안 써본 동안엔, 그게 존재한다는 사실이 저에게 아무 값도 못 했어요. 한 번 돌려보고 뭔가가 나오고 나서야, 비로소 '내 도구'가 됐고요.
그래서 제가 가장 중요하게 여기는 건 — 더 똑똑한 도구를 아는 게 아니라, 이것저것 많이 시도하고 실험해보는 것이에요. 정보로 아는 것과 체감하는 것은 전혀 다르거든요. 그리고 신기하게도, 그렇게 자꾸 찔러보면 거기서 꼭 얻는 게 생겨요. 제가 /code-review를 만난 것도, 별생각 없이 한번 시도해봤기 때문이었으니까요.
그렇게 쌓인 경험이 습관이 될 때, 비로소 필요할 때 꺼내 쓰는 진짜 내 무기가 돼요.
그리고 이건 요령이 아니에요. 빠른 팁 하나로 끝나는 게 아니라, 여러 번 반복해서 직접 해보는 훈련에 가까워요. 그렇게 몸으로 겪다 보면 남이 알려준 방식이 아니라 나한테 맞는 리듬이 생겨요. 결국 중요한 건 그거예요 — 빌려온 요령이 아니라, 반복해서 찾아낸 나만의 리듬.
그러니 거창하게 시작하지 않아도 괜찮아요. 오늘 안 써본 명령 하나를 그냥 한번 돌려보는 것 — 거기서부터예요.
/code-review를 한 번 돌려요. 가장 작고 즉시 가능한 습관이에요. 저도 여기서 시작했어요. 자꾸 뭔가 나오면, 그게 미뤄둔 이해 빚이에요.security-guidance 플러그인 — 의지에 맡기지 않고 구조로 만드는 거예요. (둘 다 공식 기능)아는 것과 체감하는 것은 달라요. 공식 문서에 있어도, 직접 써보고 겪어보기 전엔 내 것이 아니에요. 그러니 오늘 — 안 써본 명령 하나를 그냥 한번 돌려보세요. 거기서부터 시작이에요.
매주 메일로 받아보세요