Claude Code /verify·/code-review 수동 호출: 자동 리뷰 착각을 줄이는 법 | DAKER 커뮤니티
Claude Code 검증 운영의 핵심은 완료 전에 /verify와 /code-review를 사람이 명시적으로 호출하는 것입니다. Claude Code /verify·/code-review란 작업 결과를 별도 검증·리뷰 루틴으로 확인하는 수동 호출형 스킬입니다. 2026년 7월 20일 KST 기준 최신 공식 릴리스는 검증과 코드 리뷰가 자동으로 실행된다고 기대하지 말고, 필요한 순간 직접 호출하라고 정리합니다.
문제 상황: Claude가 알아서 리뷰까지 끝냈다고 봐도 될까?
긴 수정 작업이 끝나면 대화 마지막에 “완료”라는 말이 보입니다. 하지만 당신이 실제 배포나 PR 머지를 앞두고 있다면 그 말만으로는 부족합니다. 검증 명령, 코드 리뷰 관점, 남은 위험이 따로 확인되어야 팀이 같은 기준으로 완료를 판단할 수 있습니다.
핵심 개념: 왜 /verify와 /code-review를 직접 호출해야 할까?
한 줄 요약: 최신 릴리스 기준으로 Claude Code는 검증과 코드 리뷰 스킬을 스스로 실행하지 않으므로, 사용자가 완료 전에 명시적으로 호출해야 합니다. 이 변화는 실무에서 오히려 기준을 분명하게 만듭니다. 구현 대화, 검증 대화, 리뷰 대화를 나누면 자동화가 무엇을 했고 무엇을 하지 않았는지 보고서에 남기기 쉽습니다.
단계별 사용법: 완료 직전 검증 루틴은 어떻게 잡을까?
- 작업 요청의 마지막 줄에 완료 기준과 실행할 테스트 이름을 적습니다.
- 구현이 끝나면 먼저 일반 테스트, 타입 검사, 린트처럼 프로젝트가 요구하는 검증을 실행합니다.
- 결과가 통과한 뒤 /verify를 호출해 작업 요구사항과 증거가 맞는지 다시 확인합니다.
- PR이나 공유 변경이라면 /code-review를 별도로 호출해 버그, 회귀, 누락 테스트를 먼저 봅니다.
- 최종 보고에는 구현 결과, 검증 결과, 리뷰 결과, 아직 확인하지 못한 항목을 분리해 씁니다.
짧은 예시: 리뷰 착각을 줄이는 한 문장 요청
“수정 후 테스트를 실행하고, 마지막에 /verify와 /code-review 기준으로 남은 위험을 분리해 보고해 주세요”처럼 요청하면 좋습니다. 권한이나 자동 실행이 걸린 작업이라면 권한 하드닝 글을 함께 보고, 반복 검증 절차는 Skills 운영 글처럼 팀 명령으로 고정하면 됩니다.
팀 적용 체크리스트: 완료 보고에 무엇을 넣을까?
- 실행한 검증 명령과 결과를 한 줄로 남깁니다.
- /verify가 확인한 요구사항과 확인하지 못한 요구사항을 나눕니다.
- /code-review 결과에서 실제 수정한 항목과 남긴 항목을 구분합니다.
- 테스트를 못 돌린 경우에는 이유와 대체 확인 방법을 적습니다.
- 자동 리뷰가 실행됐다는 표현을 쓰지 말고 수동 호출 여부를 명시합니다.
공식 출처 기준으로 무엇을 조심해야 할까?
작성 기준일은 2026년 7월 20일 KST입니다. 기능 사실은 공식 릴리스와 공식 changelog에서 비공개로 확인했고, 공개 본문에는 DAKER 내부 링크만 남겼습니다. 이 글은 특정 프로젝트의 테스트 성공을 보장하지 않으며, 팀의 CI와 리뷰 정책을 대체하지 않습니다.
자주 묻는 질문
/verify를 호출하면 테스트가 자동으로 모두 실행되나요?
프로젝트와 스킬 정의에 따라 다릅니다. 핵심은 검증을 명시적으로 요청하고 실제 실행 증거를 확인하는 것입니다.
/code-review는 PR 리뷰를 대체하나요?
대체라기보다 사전 점검에 가깝습니다. 사람 리뷰 전에 명백한 버그와 누락 테스트를 먼저 줄이는 용도로 쓰는 편이 안전합니다.
작은 수정에도 두 스킬을 모두 써야 하나요?
문서 오타처럼 위험이 낮은 작업은 가볍게 확인해도 됩니다. 공유 코드, 권한, 배포, 데이터 처리 변경에는 명시 호출을 권장합니다.
팀 문서에는 어떻게 적으면 좋나요?
“완료 전 검증 명령 실행, 필요 시 /verify, PR 전 /code-review”처럼 실행 조건과 보고 형식을 짧게 고정하면 됩니다.
오늘은 최근 완료 보고 하나를 골라, 검증과 리뷰가 실제로 호출됐는지부터 다시 확인해 보세요.