신뢰하기: 감독 없는 실행 검증하기
Claude에게 작업을 맡기고 모든 단계를 지켜보지 않은 채 실행하도록 두었습니다. 이제 Claude가 작업을 완료했다고 말합니다. 그 작업을 배포하기 전에, 직접 감독하지 않은 작업을 확인할 방법이 필요합니다. 그 확인 과정이 바로 사람이 지켜보지 않는 Claude Code를 안심하고 신뢰할 수 있게 만드는 요소입니다.
여기서의 핵심 아이디어는 간단합니다. 실행에 부여한 자율성만큼 비례해서 검증하라는 것입니다. 짧은 세션에서 메시지가 스크롤되는 것을 지켜봤다면 간단히 훑어보는 것으로 충분합니다. 하지만 아무도 지켜보지 않는 실행, 또는 아무도 관여하지 않은 채 지속적 통합(continuous integration)에서 실행된 작업이라면 실질적인 확인이 필요합니다. 아무도 무슨 일이 일어났는지 보지 못했으므로, 사후에 그 과정을 재구성해야 합니다.
이렇게 생각해 보세요. 덜 지켜볼수록, 더 많이 검증해야 합니다.
감독 없는 실행은 자동 모드로 유지하기
업무 중 실행이 감독 없이 진행될 때는 권한 우회 모드가 아니라 자동 모드로 유지하세요. 자동 모드에서는 분류기가 여전히 대부분의 작업에서 위험 여부를 검토합니다. 이는 유지할 가치가 있는 안전망입니다.
하지만 그 안전망이 무엇을 하고 무엇을 하지 않는지는 분명히 해야 합니다. 분류기는 코드가 실제로 올바른지는 절대 판단하지 않습니다. 오직 위험한 작업만 표시할 뿐입니다. 따라서 검증 기준은 이전과 정확히 동일하게 유지되어야 합니다. 그 기준은 해당 실행이 얼마나 감독 없이 진행되었는지에 따라 설정하세요.
요약이 아니라 diff부터 시작하기
Claude가 작업한 내용을 요약한 것부터 시작하지 마세요. diff 자체부터 시작하세요.
/code-review를 실행해 변경 사항을 살펴보고 문제를 표시하게 하세요.- 그런 다음 직접
git diff를 눈으로 확인하세요.
함정은 완벽하게 읽히는 깔끔한 요약이지만, 실제 diff는 여러분이 전혀 예상하지 못한 파일을 건드렸을 수 있다는 점입니다. 요약은 그 사실을 알려주지 않습니다. diff는 알려줍니다.
그러니 변경된 내용을 직접 읽으세요. 계획에 포함된 파일을 먼저 읽고, 그다음 계획 밖의 것이 있는지 살펴보세요. 깔끔한 설명이 깨끗한 코드를 증명하지는 않습니다.
테스트를 약속이 아니라 관문으로 만들기
감독 없는 실행에서 진짜 관문은 테스트가 통과했는지, 그리고 Claude가 실제로 테스트를 실행했는지 아니면 실행했다고 주장만 했는지입니다. 이를 신뢰에만 맡기지 마세요. Claude가 건너뛸 수 없도록 훅(hook)으로 연결하세요.
다음 두 가지 훅이 그 역할을 합니다:
- 테스트를 실행하고 실패 시 턴 종료를 거부하는 stop 훅.
- 모든 편집 후 린트와 타입 검사를 수행하는 post-tool-use 훅.
핵심은 종료 코드(exit code)입니다. exit 2로 종료되는 훅은 실패를 Claude에게 곧바로 다시 전달합니다. Claude는 그 실패를 읽고 여러분이 요청하지 않아도 스스로 수정합니다. 무엇보다 좋은 점은, 요청을 기억하든 안 하든 이 검사가 매 실행마다 작동한다는 것입니다.
냉정한 두 번째 의견 구하기
풀 리퀘스트 전에 실행하던 서브 에이전트 코드 리뷰는 여기서도 유효합니다. 이를 감독 없는 실행에 적용하세요.
새 세션이나 서브 에이전트를 열고, 코드가 어떻게 만들어졌는지에 대한 기억이 전혀 없는 상태에서 변경된 코드를 검토하게 하세요. 그 방식에 아무런 이해관계가 없기 때문에, 원래 실행이 스스로를 설득해 넘어간 부분을 잡아냅니다. 새로운 시각을 가진 두 번째 검토자는 작성자가 합리화해 넘긴 부분을 찾아냅니다.
종합하기
실행이 감독 없이 진행된 정도만큼 검사도 진지하게 만드세요:
- diff는 직접 읽으세요.
- 테스트를 턴을 막는 훅으로 만드세요.
- 헤드리스 실행은 JSON 결과와 종료 코드로 검증하세요.
- 중요한 사안에는 냉정한 두 번째 의견을 구하세요.
이렇게 하면 "내가 보지 않는 동안 Claude가 해냈다"는 말이 더 이상 믿음에만 의존하지 않게 됩니다.