Claude Code에서 /verify·/code-review를 수동 호출해야 하는 이유 | DAKER 커뮤니티

긴 수정 작업이 끝나고 대화 마지막에 완료라고 적혀 있으면, 검증과 리뷰까지 모두 끝난 것처럼 받아들이기 쉽습니다. 하지만 배포나 PR 머지를 앞둔 상황이라면 구현 완료와 검증 완료, 리뷰 완료를 같은 의미로 보면 곤란합니다.

2026년 7월 20일 KST 기준 최신 공식 릴리스 정리를 보면, Claude Code의 검증과 코드 리뷰는 자동으로 실행된다고 기대하기보다 필요한 시점에 사람이 직접 호출하는 방식으로 이해하는 것이 맞습니다. 이 차이를 분명히 해두면 완료 보고의 기준도 훨씬 선명해집니다.

Claude Code 검증 운영의 핵심은 완료 전에 /verify와 /code-review를 사람이 명시적으로 호출하는 것입니다.

Claude Code /verify·/code-review란 작업 결과를 별도 검증·리뷰 루틴으로 확인하는 수동 호출형 스킬입니다.

왜 자동 리뷰로 착각하기 쉬울까

긴 작업이 끝난 뒤 완료라는 표현이 보이면, 구현뿐 아니라 검토까지 마무리됐다고 받아들이기 쉽습니다. 그러나 실제 운영에서는 검증 명령을 실행했는지, 코드 리뷰 관점에서 어떤 위험을 다시 봤는지, 아직 남은 불확실성이 무엇인지가 따로 정리되어야 합니다.

이 구분이 없으면 팀마다 완료의 의미를 다르게 해석하게 됩니다. 특히 배포 직전이나 PR 머지 직전에는 구현 결과만이 아니라 검증 증거와 리뷰 결과까지 같은 기준으로 확인하는 것이 좋습니다.

핵심 개념: /verify와 /code-review는 왜 직접 호출해야 할까

한 줄로 정리하면, 최신 릴리스 기준으로 Claude Code는 검증과 코드 리뷰 스킬을 스스로 실행하지 않으므로 사용자가 완료 전에 명시적으로 호출해야 합니다.

구현 대화, 검증 대화, 리뷰 대화를 나누면 자동화가 무엇을 했고 무엇을 하지 않았는지 더 분명하게 남길 수 있습니다.

이 방식은 번거로워 보일 수 있지만 실무에서는 오히려 장점이 있습니다. 구현 단계와 검증 단계, 리뷰 단계를 나눠 기록하면 보고서나 작업 이력에서 어떤 확인이 실제로 이뤄졌는지 추적하기 쉬워집니다. 자동으로 다 해줬다고 가정하는 것보다, 수동 호출 여부를 명시하는 편이 팀 기준을 맞추는 데 유리합니다.

완료 직전 검증 루틴은 어떻게 잡으면 좋을까

작업을 요청할 때부터 완료 기준과 실행할 테스트 이름을 마지막 줄에 적어두면 이후 확인이 수월합니다. 구현이 끝난 뒤에는 먼저 일반 테스트, 타입 검사, 린트처럼 프로젝트가 요구하는 기본 검증을 실행하면 됩니다.

그다음 결과가 통과했다면 /verify를 호출해 작업 요구사항과 실행 증거가 맞는지 다시 확인하는 흐름이 자연스럽습니다. PR을 올리거나 다른 사람과 공유할 변경이라면 /code-review를 별도로 호출해 버그 가능성, 회귀 위험, 누락된 테스트를 먼저 살펴보는 것이 좋습니다.

마지막 보고에서는 구현 결과, 검증 결과, 리뷰 결과, 아직 확인하지 못한 항목을 분리해 적는 편이 안전합니다. 이렇게 나눠 쓰면 완료라는 말이 무엇을 포함하는지 모호하지 않게 전달할 수 있습니다.

짧은 요청 문장만 바꿔도 착각을 줄일 수 있습니다

예를 들어 수정 요청 끝에 수정 후 테스트를 실행하고, 마지막에 /verify와 /code-review 기준으로 남은 위험을 분리해 보고해 주세요라고 적어두면 흐름이 분명해집니다.

권한이나 자동 실행이 걸린 작업이라면 권한 하드닝 글을 함께 보는 것이 좋고, 반복 검증 절차는 Skills 운영 글처럼 팀 명령으로 정리해두면 일관성을 유지하기 쉽습니다.

완료 보고에는 무엇을 남기면 좋을까

완료 보고에서는 실행한 검증 명령과 그 결과를 한 줄로 남기고, /verify가 확인한 요구사항과 아직 확인하지 못한 요구사항을 구분해 적는 것이 좋습니다. /code-review 결과도 실제로 수정한 항목과 남겨둔 항목을 나눠 써야 이후 판단이 쉬워집니다.

테스트를 돌리지 못했다면 그 이유와 대체 확인 방법을 함께 적어두는 편이 낫습니다. 무엇보다 자동 리뷰가 실행됐다는 표현보다는, /verify와 /code-review를 수동으로 호출했는지 여부를 명시하는 것이 중요합니다.

공식 출처 기준으로 조심할 점

작성 기준일은 2026년 7월 20일 KST입니다. 기능 사실은 공식 릴리스와 공식 changelog에서 비공개로 확인했습니다. 공개로 확인할 수 있는 관련 자료는 본문에 연결한 DAKER 링크를 참고하면 됩니다.

이 글은 특정 프로젝트의 테스트 성공을 보장하지 않으며, 팀의 CI와 리뷰 정책을 대체하지 않습니다.

/verify가 모든 테스트를 자동으로 실행하는지 여부는 프로젝트와 스킬 정의에 따라 달라질 수 있습니다. 또한 /code-review는 사람의 PR 리뷰를 대체한다기보다, 그 전에 명백한 버그와 누락 테스트를 줄이는 사전 점검에 가깝습니다. 문서 오타처럼 위험이 낮은 수정은 가볍게 확인해도 되지만, 공유 코드나 권한, 배포, 데이터 처리 변경처럼 영향이 큰 작업은 명시 호출 기준을 두는 것이 좋습니다.

참고 자료

https://daker.ai/community/post-mrqt8da2-753e5881
https://daker.ai/community/claude-code-skills-routine-tasks-team-commands

최근 완료 보고를 다시 볼 때, 구현 완료와 검증·리뷰 완료를 어떻게 구분하고 계신가요?