자율 주행 모드

대부분의 사용자는 Claude Code를 "명령-확인-수정"의 감독 모드로 쓴다. 코드를 쓰게 하고, 결과를 확인하고, 문제가 있으면 다시 지시하는 방식이다. 이것은 쓸모없는 건 아니지만 생산성의 절반만 활용하는 것이다.

진짜 생산성 폭발은 "자율 모드"에서 일어난다. Claude에게 코드를 쓰게 하고, 테스트를 돌리게 하고, 실패하면 수정하게 하고, 다시 테스트를 돌리게 하는 루프를 구축하면 — 당신이 커피를 마시는 동안 Claude가 일을 끝낸다.

이 루프의 핵심은 03번(자동 검증)이다. 검증 수단이 없으면 Claude는 "이게 맞는 것 같습니다"라고 말할 수밖에 없다. 하지만 테스트가 있으면 "테스트가 통과했습니다" 또는 "3개가 실패해서 수정하겠습니다"라고 구체적으로 행동한다.

마지막 줄이 핵심이다. "중간에 확인 받지 않아도 돼"라고 명시하면 Claude는 매 수정마다 멈추지 않고 연속적으로 작업한다. 물론 이를 위해서는 충분한 테스트 커버리지가 전제되어야 한다.

많은 개발자가 테스트를 "나중에" 쓴다. 기능 구현이 먼저고, 테스트는 시간이 남으면 하는 것. Claude Code를 쓰면 이 순서가 뒤집혀야 한다. 테스트를 먼저 쓰면, Claude의 자율 작업 품질이 비약적으로 올라간다.

이 방식의 부수 효과도 있다. 테스트가 요구사항의 명세 역할을 한다. "정상 결제 성공"이라는 테스트 케이스 이름 자체가 Claude에게 무엇을 구현해야 하는지 알려준다. 별도의 긴 설명이 필요 없다.

Claude Code는 터미널에서 동작하므로 Git과 GitHub CLI(gh)를 네이티브로 사용할 수 있다. 이것을 활용하지 않고 직접 git 명령어를 치는 건 통역관에게 직접 외국어로 말하는 것과 같다.

핵심은 드래프트 PR이다. Claude가 만든 PR을 바로 머지하는 건 위험하다. 드래프트로 만들면 CI가 돌아가고, 코드 리뷰를 할 수 있고, 문제가 있으면 수정할 수 있다. 안전망을 유지하면서 자동화의 이점을 누리는 방법이다.

일반적인 Git 워크플로우에서 브랜치를 전환하면 작업 디렉토리의 파일이 바뀐다. 빌드 캐시가 날아가고, 에디터가 파일을 다시 로드한다. worktree는 이 문제를 해결한다. 하나의 레포에서 여러 브랜치를 각각 다른 디렉토리로 체크아웃한다.

Claude Code 멀티 인스턴스와 worktree의 조합은 강력하다. 하나의 Claude가 메인 기능을 작업하는 동안, 다른 Claude가 별도 브랜치에서 버그를 수정하거나 테스트를 보강할 수 있다. 각 인스턴스의 컨텍스트가 서로 독립적이므로 간섭이 없다.

이 세 단계의 비율은 프로젝트 성격에 따라 달라진다. 새 프로젝트라면 Plan에 더 시간을 쓴다. 기존 코드의 버그 수정이라면 Prototype으로 바로 들어간다. 중요한 건 세 단계를 모두 거치는 것이다. 계획 없이 코딩하면 헤매고, 프로토타입 없이 계획만 하면 진도가 안 나가고, 리뷰 없이 머지하면 품질이 떨어진다.