Claude Code로 생산성을 높이는 방법

- AI 에이전트의 단순 반복 작업 자동화, 빌드 대기 시간 제거, 병렬 워크트리 시스템 구축 등 개발 인프라 개선을 통해 커밋 수가 급격히 증가한 6주간의 경험 정리 - /git-pr 스킬로 PR 생성 과정을 자동화하여 컨텍스트 스위칭 비용을 제거하고, 에이전트가 직접 더 상세한 PR 설명을 작성 - 빌드 도구를 SWC로 전환해 서버 재시작을 1초 미만으로 단축, 흐름이 끊기지 않는 개발 환경 확보 - Claude Code의 프리뷰 기능으로 에이전트가 스스로 UI를 검증하게 하여, 개발자가 모든 변경을 직접 확인하는 병목 해소 - 각 마찰 요소를 순차적으로 제거하면 다음 병목이 드러나는 제약 이론(Theory of Constraints) 패턴이 그대로 적용됨 - 이제 기능 구현보다 에이전트가 효율적으로 일하는 인프라 구축과 루프 속도 향상에 집중 단순 반복 작업의 자동화 - 초기에는 변경 사항 스테이징, 커밋 메시지 작성, PR 설명 작성, 푸시, GitHub PR 생성까지 모든 과정을 수동으로 수행 - 이 작업이 단순 반복(grunt work)이라는 사실을 인식한 것이 첫 번째 전환점이며, 역할이 구현자에서 에이전트를 관리하는 매니저로 변화 - 첫 번째 Claude Code 스킬인 /git-pr 을 작성하여 PR 생성 전 과정을 자동화 - 에이전트가 전체 diff를 읽고 변경 사항을 제대로 요약하기 때문에, 직접 작성하던 것보다 PR 설명이 더 상세 - 코드베이스의 CLAUDE.md는 Graphite 사용을 명시하지만, 개인적으로 plain git을 선호하여 /git-pr 로 운영 - 시간 절약 자체보다 더 큰 효과는 정신적 오버헤드 제거: PR 작성 시마다 발생하던 "코드 사고 → 코드 설명 사고"로의 소규모 컨텍스트 스위칭이 사라짐 대기 시간 제거 - 로컬 프리뷰를 위해 작업 중인 내용을 벗어나 dev 서버를 종료하고 새 브랜치에서 재시작하는 과정이 반복적으로 발생 - 서버 빌드에 약 1분 소요되어, 집중을 깨뜨리기에는 충분히 길고 다른 작업을 하기에는 너무 짧은 시간 - 빌드를 SWC로 전환하여 서버 재시작이 1초 미만으로 단축 - 파일 저장 즉시 서버가 이미 올라와 있어, 주의력이 흐트러지는 틈이 사라짐 - "어색한 침묵이 있는 대화"와 "자연스럽게 흐르는 대화"의 차이에 비유 에이전트의 자체 UI 검증 - 기존에는 모든 UI 변경을 직접 로컬 프리뷰로 확인해야 하여 개발자가 모든 기능의 병목이 됨 - Chrome 확장 프로그램이 계속 크래시한 이후 Claude Code의 프리뷰 기능으로 전환 - 에이전트가 프리뷰를 설정하고 세션 데이터를 유지하면서 UI가 실제로 어떻게 보이는지 직접 확인 가능 - 워크플로에 통합하여, 에이전트가 UI를 직접 검증해야만 "완료" 로 처리 - 검증을 위임할 수 있어 최종 리뷰에만 개입하면 되고, 에이전트가 더 오랜 시간 자율적으로 실행 가능 - 에이전트가 스스로 실수를 잡아내는 것이 예상보다 훨씬 중요한 효과 병렬 워크트리 시스템 - 빠른 리빌드와 자동화된 프리뷰가 갖춰진 후 드러난 다음 마찰: 한 번에 하나의 작업만 편하게 수행 가능하다는 점 - 다른 에이전트나 팀원의 PR을 리뷰하려면 메인에서 PR 브랜치로 체크아웃하고 리빌드·테스트해야 하지만, 커밋되지 않은 변경과 충돌 - stash → checkout → rebuild → test → switch back → pop stash, 또는 수동 worktree 생성 후 포트 충돌 발생 - 앱이 프론트엔드와 백엔드 각각 별도 포트를 필요로 하며, 모든 워크트리가 동일한 환경 변수를 공유하여 같은 포트에 바인딩 시도 - 이를 해결하기 위해 워크트리 생성 시 각 서버에 고유 포트 범위를 자동 할당하는 시스템 구축 - 2개의 병렬 브랜치에도 압도되던 상태에서 5개의 워크트리를 동시에 운영하는 수준으로 전환 - 여러 에이전트를 별도 워크트리에서 각각 다른 기능을 빌드하도록 실행하고, UI 자체 검증이 완료될 때까지 자율 실행 - 계획 단계에 깊이 관여한 후 코드 리뷰 시점까지 개입하지 않는 방식 - 리뷰도 훨씬 매끄러워짐: 설정 작업, 리빌드, 포트 충돌 없이 읽고, 확인하고, 머지하는 흐름 핵심은 AI가 아니라 인프라 - 역할이 변화: 복잡한 문제를 직접 풀고 완벽한 UI를 만드는 데 시간을 쓰는 대신, 에이전트를 효과적으로 만드는 인프라를 구축하는 것이 더 재미있어짐 - 솔로 개발자가 아닌 10명 규모 팀의 매니저가 된 것과 유사 - 화려하지 않은 배관(plumbing) 작업이지만, 이것이 플로 상태에 머무르는지 환경과 싸우는지를 결정 - Tano에서 가장 높은 레버리지를 가진 작업은 기능 개발이 아니라, 커밋의 흐름을 급류로 바꾼 인프라 구축 루프: 제약 이론의 적용 - 각 단계가 서로 다른 종류의 마찰을 제거: - /git-pr : 코드 변경을 PR로 만드는 포맷팅 마찰 제거 - SWC: 변경 후 결과를 보기까지의 대기 마찰 제거 - 프리뷰 기능: 변경 사항을 확인하는 검증 마찰 제거 - 워크트리 시스템: 여러 작업 흐름 간 컨텍스트 스위칭 마찰 제거 - 하나를 제거할 때마다 다음 병목이 즉시 드러나는, 제약 이론(Theory of Constraints) 의 전형적 패턴 - 작업의 본질이 변화: "코드를 쓰는 도구를 사용하는 것"이 아니라, 작업 시작 → 에이전트 코드 작성 → 프리뷰 확인 → diff 읽기 → 피드백 또는 머지 → 다음 작업의 타이트한 피드백 루프 - 루프가 충분히 빠르면 주의력이 빠져나갈 틈이 없고, 속도 향상 자체가 게임이 됨 - 최종적으로 개발의 목표는 기능 구현이 아니라, 루프 속도를 얼마나 더 높일 수 있는가로 이동 - 속도 자체가 엔지니어링의 즐거움이 되는 단계에 도달