검토 시키기 — 만든 직원이 검사하지 않는다
AI에게 “네가 만든 것, 괜찮아?”라고 물으면 대체로 괜찮다는 답이 돌아옵니다. 자기 답안을 자기가 채점하기 때문입니다. 클로드 코드는 이 문제를 만드는 직원과 검사하는 직원을 따로 두는 방식으로 풉니다. 왜 이 기능이 필요한지는 「AI는 자기가 한 일을 스스로 판단하지 못합니다」 페이지에서 설명합니다.
원리 — 만든 쪽이 채점하지 않는다
코드 검토(code review)는 새로 만든 코드를 다시 살펴 결함을 짚어 내는 작업입니다. 글을 세상에 내보내기 전에 교정자가 오탈자와 논리 구멍을 잡아 주는 것과 비슷합니다. 코드를 쓴 바로 그 클로드가 자기 코드를 채점하지 않습니다. 검토는 만든 과정을 모르는 채 새로 시작하는 별도의 클로드가 맡고, 오직 문제를 찾는 데만 집중합니다. 만드는 직원과 검사하는 직원을 따로 두는 원칙이며, 책 11장이 꺼내고 13장이 깊이 다룹니다.
검토는 한 번으로 끝나지 않고 여러 길목에서 나눠 이뤄집니다.
| 길목 | 도구 | 언제 실행되나 |
|---|---|---|
| 코드를 쓰는 도중 | 도구보안 가드 플러그인 | 언제 실행되나설치해 두면 자동 |
| 터미널에서 | 도구/code-review | 언제 실행되나내가 원할 때 명령 한 줄 |
| PR(합쳐 달라는 요청서)이 올라올 때 | 도구Code Review(깃허브 연동) | 언제 실행되나팀이 설정하면 자동 |
| 합치기 직전 클라우드에서 | 도구/code-review ultra | 언제 실행되나큰 변경 때 직접 |
앞 단계가 잡지 못한 것을 뒤 단계가 잡는 구조입니다. 일찍 검토하면 뒤로 넘어가는 문제가 줄어들지만, 그렇다고 뒤 단계를 없앨 수는 없습니다.
/code-review와 보안 가드 플러그인입니다. 뒤의 둘은 개발팀 협업용이고 검토마다 비용이 듭니다. 아래에서는 있다는 것만 알아 두면 됩니다.
/code-review — 올리기 전에 한 번
클로드가 다 만든 코드를 세상에 내보내기 전에, 아무 세션에서나 이 한 줄로 검토를 시킵니다.
# 지금까지의 작업분을 별도의 눈이 검토
/code-review이 검토는 바뀐 부분(diff)만 보는 것이 아닙니다. 프로젝트 코드 전체를 함께 살피며, 바뀐 코드가 다른 어떤 코드를 쓰고 또 어디에서 쓰이는지까지 읽습니다. 따로 지정하지 않으면 지금까지 쌓인 변경을 모두 함께 봅니다. 여기에는 두 가지가 다 들어갑니다. 원본에서 갈라져 나온 뒤 지금 브랜치(원본을 건드리지 않고 따로 이어 가는 작업 줄기)에 저장해 둔 변경, 그리고 아직 저장하지 않은 작업입니다. 여기서 말하는 저장은 커밋(바뀐 내용을 한 묶음으로 저장하는 일)입니다.
검토의 깊이는 명령 뒤에 수준을 붙여 조절합니다. 수준을 낮게 주면 확실한 결함만 적게 보고하고, high·max처럼 높게 주면 더 넓게 훑는 대신 불확실한 것까지 딸려 올 수 있습니다. 쓰는 모델과 수준에 따라서는 결함 말고도 정리하면 좋을 곳까지 짚습니다. Opus 5.5·Sonnet 5.5에서는 medium으로 돌려도 중복이나 군더더기처럼 정리할 곳과 운영 헌법(CLAUDE.md)에 적은 규칙을 어긴 곳을 함께 보고합니다. 아무것도 붙이지 않으면 마지막으로 붙였던 수준(low~max)을 다시 씁니다. 예전 세션에서 붙인 수준도 기억하고, 다시 쓸 때는 화면에 그렇다는 안내가 뜹니다. 수준을 한 번도 붙인 적이 없으면 지금 세션에 정해 둔 생각의 깊이(/effort)를 그대로 씁니다.
/code-review high
--fix— 검토가 끝난 뒤 찾은 문제를 작업 중인 파일에 바로 고쳐 반영합니다.--comment— 찾은 문제를 PR의 해당 코드 줄에 댓글로 달아 줍니다.--max-findings— 뒤에 숫자를 붙이면 그 개수까지,all을 붙이면 찾은 것을 모두 보고합니다. 평소 정해진 개수보다 더 받거나 덜 받고 싶을 때 씁니다. 한 번 정한 값은 다음 검토에도 그대로 쓰이니, 원래대로 되돌리려면--max-findings default를 붙입니다.- 뒤에 특정 파일·PR 번호·브랜치 이름을 지정하면 그 부분만 검토합니다.
이름이 비슷한 /simplify는 코드를 더 간결하게 정리하는 데만 쓰는 명령입니다. 버그를 찾고 싶다면 /code-review를 씁니다.
/code-review를 한 번 실행하는 습관을 들이십시오. 지적이 나오면 “지금 찾은 문제를 고쳐 줘”라고 말로 시키거나, 처음부터 --fix를 붙입니다.
/code-review를 돌렸는데 검토할 것이 없다고 나올 때
가장 흔한 원인은 검토할 대상을 찾지 못한 것입니다. 이 명령은 깃(파일이 바뀐 기록을 남기는 도구)으로 관리되는 폴더에서 바뀐 부분을 찾아봅니다. 깃을 쓰지 않는 폴더이거나 아직 바뀐 파일이 없으면 볼 대상 자체가 없습니다. 지금 할 일은 두 가지입니다. 먼저 “이 폴더가 깃 저장소인지, 지금 바뀐 파일이 있는지 알려 줘”라고 그대로 시켜 확인합니다. 깃을 쓰지 않는 폴더라면 아래 “코드가 아니어도” 항목의 방식대로 새 세션에서 파일을 불러와 검토시키십시오. 깃·브랜치·커밋이라는 말부터 낯설다면 용어 사전을 먼저 보십시오.
보안 가드 플러그인 — 코드를 쓰는 동안 곁에서 보는 보안 담당
가장 이른 검토는 클로드가 코드를 쓰는 그 순간에 일어납니다. 보안 가드 플러그인(security-guidance)을 설치하면, 방금 고친 코드에서 흔한 보안 구멍을 찾아 같은 세션 안에서 바로 고칩니다. 요리하는 동안 옆에서 위생을 봐 주는 직원과 비슷합니다. 훅(정해진 순간이 오면 저절로 실행되는 자동 장치)이나 자동화 스크립트를 말로 만들게 하는 사장에게는 기본 안전망입니다.
# 공식 마켓플레이스에서 설치 /plugin install security-guidance@claude-plugins-official # 다시 시작할 필요 없이 지금 세션에 바로 적용 /reload-plugins
설치할 때 적용 범위를 묻는데, 사용자(user) 범위를 고르면 이 컴퓨터의 모든 새 세션에 자동으로 켜집니다. 그다음에는 따로 입력할 명령어가 없습니다. 이 플러그인은 세 시점에 각각 다른 깊이로 검사합니다.
- 파일을 고칠 때마다 — 위험한 코드 패턴을 즉시 걸러냅니다. AI 모델을 쓰지 않아 비용이 들지 않습니다.
- 응답이 끝날 때마다 — 그 응답에서 바뀐 부분 전체를 보안 관점으로 다시 봅니다.
- 커밋하거나 푸시(인터넷 저장소에 올리는 일)할 때마다 — 주변 코드까지 읽는 더 깊은 검토로 진짜 결함인지 확인하고 오탐(문제가 아닌데 문제라고 잡은 것)을 걸러 줍니다.
여기서도 검토는 별도의 클로드가 맡습니다. 검토가 파일 저장이나 커밋을 막지는 않습니다. 대신 찾아낸 문제를 클로드에게 지시로 넘겨, 대화 안에서 이어 고치게 합니다.
나머지 둘은 개발 협업용 — 있다는 것만 알아 두기
Code Review(깃허브 연동) — 팀이 깃허브에서 함께 일하면, 작업 결과를 합쳐 달라는 요청서(PR)가 올라올 때마다 분야를 나눠 맡은 여러 검토 담당 AI가 자동으로 검토합니다. 문제가 있는 줄에는 심각도를 붙여 댓글을 답니다. 아직 정식 출시 전 시험 단계(research preview)입니다. Team·Enterprise 구독에서 쓸 수 있고, 한 번 검토에 평균 20분쯤 걸리며 비용은 대략 15~25달러입니다.
울트라리뷰(ultrareview) — 큰 변경을 합치기 직전에 /code-review ultra 한 줄로 돌리는 깊은 검토입니다. 내 컴퓨터가 아닌 클라우드에서 더 많은 검토 담당 AI가 문제를 하나하나 재현해 확인합니다. 보통 5~10분 걸리고 그동안에도 터미널은 자유롭게 쓸 수 있습니다. 이것도 시험 단계이며, Claude.ai 계정 로그인이 필요합니다. Pro·Max 구독은 처음 3회가 무료입니다. 이 3회는 계정마다 한 번만 주고 다시 채워 주지 않습니다. 그 뒤로는 검토마다 대략 5~25달러가 사용 크레딧에서 빠져나갑니다. Team·Enterprise 구독에는 이 무료 3회가 없습니다.
/code-review와 보안 가드 플러그인으로 충분합니다. 울트라리뷰로 내 브랜치를 검토하면 아직 커밋하지 않은 수정까지 묶어 클라우드로 올립니다. 시작하기 전에 뜨는 확인 창에도 이 안내가 나옵니다. .env처럼 비밀번호나 열쇠(API 키) 같은 비밀 정보가 든 듯한 이름의 파일은 고친 내용을 빼고 올립니다. 맥과 리눅스(윈도우 안의 리눅스 포함)에서 그렇습니다. 윈도우에서 바로 쓸 때는 그대로 올라가니, 시작하기 전에 밖으로 나가면 안 되는 수정이 섞여 있지 않은지 보십시오.
코드가 아니어도 — 다른 세션에 검토시키기
이 원리는 코드 밖에서도 그대로 통합니다. 보고서·기획안·원고도 마찬가지입니다. 만든 세션에게 “괜찮아?”라고 물으면 그 세션은 후하게 점수를 줍니다. 대신 새 터미널 창에서 새 세션을 열어, 만든 과정의 기억이 전혀 없는 눈에게 검토만 시킵니다.
# 새로 연 세션에서 — 고치게 하지 말고 판정만 시키는 것이 요령
보고서.md를 검토해 줘. 고치지 말고,
논리 구멍과 근거 없는 주장만 목록으로 보고해 줘.검토 결과를 들고 원래 세션으로 돌아가 고치게 하면, 만든 직원과 검사한 직원이 나뉜 채로 일이 끝납니다. 여러 세션을 나란히 두고 쓰는 방법은 「여러 세션 동시에」 페이지에서 다룹니다.
내가 모르는 분야일 때 — 무엇을 믿고 받아들일까요
검사하는 쪽도 결국 같은 AI인데, 그 검사 결과는 무엇을 믿고 받아들여야 하느냐는 물음이 남습니다. 게다가 내가 모르는 분야라면 결과물이 맞는지 내 눈으로 확인할 수도 없습니다. 내용의 옳고 그름을 직접 판정하는 능력은 이 방법들로 생기지 않습니다.
다만 무엇을 판단할지는 바꿀 수 있습니다. 내용을 판단할 수 없어도, 일하는 방식은 판단할 수 있습니다. 세무를 모르는 사장이 세무 담당자의 보고를 받는 상황과 같습니다. 사장은 계산식을 검산하지 않습니다. 대신 근거 서류를 요구하고, 확실한 것과 애매한 것을 구분해 달라고 하고, 큰돈이 걸린 일은 외부 전문가에게 한 번 더 물어봅니다. AI 직원에게도 같은 방식을 씁니다.
내용을 몰라도 확인할 수 있는 것이 네 가지 있습니다.
| 무엇을 시키나 | 어떻게 시키나 | 무엇이 드러나나 |
|---|---|---|
| ⓐ 출처를 대게 한다 | 어떻게 시키나주장마다 근거가 어디서 왔는지 함께 내라고 요구하고, 그 출처를 내가 직접 열어 봅니다. | 무엇이 드러나나출처가 없거나 열어 보니 그런 내용이 없는 주장 |
| ⓑ 스스로 반박하게 한다 | 어떻게 시키나같은 결과물을 새 대화에 건네고 “이 결과의 약점과 틀릴 수 있는 지점을 찾아 달라”고 시킵니다. | 무엇이 드러나나만든 쪽이 당연하게 깔고 간 무리한 전제 |
| ⓒ 작게 시험한다 | 어떻게 시키나전부 믿기 전에 확인할 수 있는 작은 조각 하나를 실제로 돌려 보거나 아는 사람에게 물어 맞는지 봅니다. | 무엇이 드러나나전체가 어긋나 있는지(조각 하나가 틀리면 나머지도 의심합니다) |
| ⓓ 확신 정도를 묻는다 | 어떻게 시키나“이 중 확실한 것과 불확실한 것을 구분해 달라”고 시킵니다. | 무엇이 드러나나내가 특별히 조심해야 할 위험 구간 |
ⓑ에서 새 대화여야 하는 이유는 앞 항목과 같습니다. 만든 대화는 자기가 세운 전제를 그대로 안고 있어서 그 위에서 답합니다. 새 대화는 그 결과물에 정이 들지 않은 상태로 봅니다.
# 반박 시키기 — 만든 대화가 아니라 새 대화에서, 결과물만 건넵니다
첨부한 결과물을 검토해 줘. 고치지 말고,
① 틀릴 수 있는 지점 ② 근거가 약한 주장
③ 빠진 반대 의견을 각각 목록으로 보고해 줘.# 확실한 것과 불확실한 것 가르기 — 위험 구간을 드러내는 질문
이 결과물의 주장을 세 무리로 갈라 줘.
① 출처로 확인되는 것 ② 네 판단인 것
③ 확신이 없는 것. ③에는 왜 확신이 없는지 한 줄씩 붙여 줘.위 네 가지를 다 해도 AI 검증만으로는 “이제 확실합니다”라는 지점에 닿지 않습니다. 돈이 오가는 판단, 법과 규정이 걸린 판단, 사람의 안전이 걸린 판단은 AI 검증으로 대신하지 않고 해당 분야의 사람 전문가에게 확인합니다. AI에게는 그 전문가에게 무엇을 물어야 하는지 질문 목록을 정리하게 하는 데까지만 맡깁니다. 이것은 AI가 모자라서 두는 예외가 아니라, 원래 조직이 일하는 정상적인 방식입니다. 사람 직원에게 일을 맡기는 사장도 계약서는 변호사에게, 세금은 세무사에게 따로 확인받습니다.
여기서 말한 방법은 만드는 직원과 검사하는 직원을 따로 두는 원칙(책 11장)과 통제 지점을 정하는 원칙(책 13장)을 사장이 혼자 판단해야 하는 상황에 맞게 옮긴 것입니다. 시키는 문장을 다듬는 방법은 「지시 잘하기」 페이지에 있습니다. 검토용 세션을 따로 여는 방법은 「여러 세션 동시에」 페이지에서 이어집니다.
연습에서 실전으로 — 넘길 때의 기준
연습과 실전을 가르는 기준은 AI가 잘하느냐가 아니라, 내가 확인할 수 있느냐입니다. 잘한다는 느낌은 몇 번 잘된 결과를 보면 금방 생기지만, 그 느낌만으로 실제 업무를 맡기면 틀렸을 때 알아차릴 방법이 없습니다. 확인할 방법이 있는 일부터 AI에게 맡깁니다.
다음 네 가지가 갖춰졌다면 실제 업무를 맡겨도 된다는 신호입니다.
- 결과가 일정합니다 — 같은 일을 여러 번 시켜 봤는데 결과의 수준이 크게 출렁이지 않습니다.
- 맞는지 판단할 수 있습니다 — 내가 직접 판단할 수 있거나, 앞 항목의 방법처럼 확인할 수단이 따로 있습니다.
- 틀려도 되돌릴 수 있습니다 — 파일 하나 고치는 일처럼, 잘못되면 이전 상태로 돌려놓을 수 있습니다.
- 손해를 감당할 수 있습니다 — 틀렸을 때 드는 비용이 다시 하면 되는 정도입니다.
반대로 다음에 하나라도 해당하면 아직 이릅니다.
- 시킬 때마다 결과가 달라집니다.
- 맞는지 틀린지 판단할 방법이 나에게 없습니다.
- 되돌릴 수 없습니다 — 외부로 나가는 발송, 결제, 삭제가 여기에 해당합니다.
그런데 이 셋에 해당한다고 해서 그 일을 AI에게 아예 못 맡기는 것은 아닙니다. 선택지가 전부 맡기거나 전부 직접 하거나 둘뿐이라고 생각하기 쉬운데, 실제로 오래 쓰게 되는 것은 그 사이입니다. AI가 만들고 내가 최종 승인하는 중간 단계를 오래 두는 것이 잘못된 상태가 아니라 정상 운영입니다. 되돌릴 수 없는 일만 사람의 손을 거치게 하면, 되돌릴 수 없다는 이유로 통째로 미뤄 두었던 일도 지금 AI에게 맡길 수 있습니다.
클로드 코드 자체가 이런 방식으로 설계돼 있습니다. 무언가를 바꾸는 일은 반드시 내 허락을 받은 뒤에 합니다. 클로드가 제안한 변경이 안전한지 승인 전에 확인하는 것도 내 몫으로 남아 있습니다. 파일을 건드리기 전에 계획만 먼저 받아 보는 계획 모드도 같은 취지입니다.