저자는 자신이 작업하는 Rails 애플리케이션들이 대부분 표준 Rails 아키텍처(모델, 뷰, 컨트롤러)를 따르며, 서비스 객체나 이벤트 기반 시스템이 없음을 언급합니다. 이러한 환경에서 Claude Code는 모델 변경 후 뷰 업데이트, 모델 및 유효성 검사 대규모 수정, 번역 추가 등과 같이 반복적이고 지루한 작업을 자동화하는 데 매우 효과적입니다. Claude Code가 이러한 ‘지루한’ 작업을 처리하는 동안, 개발자는 커피를 마시거나, 자녀와 시간을 보내거나, Claude Code가 처리하기 어려운 더 복잡하고 창의적인 문제 해결에 집중할 수 있습니다. 또한, 여러 Claude Code 인스턴스를 병렬로 실행하여 동시에 더 많은 작업을 처리할 수 있는 잠재력도 제시됩니다.
그러나 Claude Code와 동시에 같은 코드베이스에서 작업하는 것은 충돌을 야기할 수 있으므로, 저자는 ‘git-worktrees’를 활용한 코드 격리 방법을 제안합니다. Git worktrees를 사용하면 특정 폴더 내에 새로운 브랜치를 생성하고, 해당 폴더에서 Claude Code 인스턴스를 실행함으로써 완벽한 격리 환경을 구축할 수 있습니다. 저자는 프로젝트 폴더 내에 /worktrees 디렉토리를 유지하고, 스크립트와 Tmux를 활용하여 새로운 Claude Code 인스턴스를 새로운 프롬프트, 새로운 브랜치, 그리고 자체 worktree에서 시작하는 과정을 자동화합니다. 이 스크립트는 기능 설명을 기반으로 브랜치 이름과 worktree 경로를 생성하고, Tmux를 통해 해당 worktree 경로에서 Claude Code를 실행합니다.
저자의 일반적인 작업 흐름은 Rails 프로젝트를 위한 Tmux 세션을 실행하는 것입니다. Claude Code에 작업을 위임하고 싶을 때, 작은 헬퍼 스크립트를 사용하여 새로운 Tmux 창/페인을 시작하고 Claude가 작업을 수행하도록 합니다. 이 동안 저자는 메인 창에서 다른 브랜치 작업을 계속하며 주기적으로 Claude의 진행 상황을 확인하거나, Claude가 완료되었을 때 훅(hook)을 통해 알림을 받습니다.
Claude Code가 생성한 코드에 대한 검토는 중요한 단계입니다. 저자는 Rails 개발에서 자동화된 검사만으로는 충분하지 않다고 판단하며, 특히 뷰 변경이 포함된 경우 직접 테스트하는 것을 선호합니다. Claude가 PR을 열고 이를 검토하는 방식보다는, 직접 해당 브랜치로 전환하여 변경 사항을 비교(diff)하고 Rails 서버를 실행하여 결과를 수동으로 검증하는 방식을 선호합니다. 이를 위해 Tmux와 Tmuxinator를 활용합니다. 각 프로젝트에 로컬 .tmuxinator 파일을 생성하여 유연성을 확보하고, 이미 실행 중인 Rails 서버와의 포트 충돌을 피하기 위해 다음 사용 가능한 포트를 동적으로 할당하는 간단한 스크립트를 사용합니다. 이를 통해 새로운 편집기 인스턴스를 사용하여 필요한 경우 수동으로 변경하거나 Claude에게 PR을 열도록 지시할 수 있습니다.
현재 저자는 최대 3개의 Claude Code 인스턴스를 병렬로 실행하고 있으며, 이는 초보적인 수준이지만 더 많은 병렬화를 시도하고 있습니다. 코드베이스에서 병렬화할 수 있는 양에는 한계가 있지만, 이 방법은 현재 Rails 앱에서 놀랍도록 잘 작동하고 있다고 평가합니다.