Claude Code로 개발 생산성을 폭발적으로 높인 방법 - 반복 작업 제거부터 병렬 워크트리까지, 6주간의 실전 경험 정리

“왜 이렇게 커밋이 빨라졌을까?”

AI 에이전트를 도입했는데도 개발 속도가 기대만큼 나오지 않는다면, 문제는 AI 자체가 아니라 개발 인프라일 수 있습니다.
이 글은 Claude Code를 활용해 단순 반복 작업 자동화, 빌드 대기 시간 제거, 에이전트의 UI 자체 검증, 병렬 워크트리 시스템 구축까지 단계적으로 개선하며, 6주 만에 커밋 수와 개발 몰입도를 급격히 끌어올린 경험을 정리한 내용입니다.

핵심은 기능을 더 빨리 “작성”하는 것이 아니라,
에이전트가 효율적으로 일할 수 있는 환경을 만드는 것, 그리고 피드백 루프 속도를 극단적으로 줄이는 것입니다.

반응형

---

개발 생산성을 가로막던 진짜 문제

초기 개발 환경에서는 다음과 같은 작업을 모두 사람이 직접 수행했습니다.

• 변경 사항 스테이징
• 커밋 메시지 작성
• PR 설명 작성
• 푸시
• GitHub PR 생성

각각은 어렵지 않지만, 문제는 매번 사고의 흐름이 끊긴다는 점입니다.
코드를 쓰다가 → 코드를 설명하는 사고로 전환해야 하는 소규모 컨텍스트 스위칭이 계속 발생했습니다.

이 지점에서 중요한 인식 전환이 일어납니다.

“이건 구현 작업이 아니라, 단순 반복 작업(grunt work)이다.”

이때부터 역할은 구현자에서 에이전트를 관리하는 매니저로 바뀌기 시작합니다.

---

/git-pr 스킬로 PR 생성 자동화

첫 번째 개선은 Claude Code의 첫 번째 커스텀 스킬인 /git-pr 작성이었습니다.

무엇이 달라졌나?

• PR 생성 전 과정을 한 번의 명령으로 자동화
• 에이전트가 전체 diff를 읽고 변경 사항을 요약
• 사람이 직접 쓰는 것보다 더 상세한 PR 설명 생성

진짜 효과

시간 절약보다 더 컸던 효과는 정신적 오버헤드 제거입니다.
PR을 작성할 때마다 발생하던
“코드 사고 → 코드 설명 사고” 전환이 완전히 사라졌습니다.

---

빌드 대기 시간 제거: SWC 도입

다음 병목은 대기 시간이었습니다.

• 로컬 프리뷰를 위해 dev 서버 종료
• 새 브랜치에서 재시작
• 서버 빌드에 약 1분 소요

1분은 애매한 시간입니다.
집중을 유지하기엔 길고, 다른 일을 하기엔 짧습니다.

해결 방법

• 빌드 도구를 SWC로 전환
• 서버 재시작 시간 1초 미만으로 단축

체감 변화

파일을 저장하면 서버는 이미 실행 중입니다.
집중이 흐트러질 틈이 사라졌습니다.

이 차이는
“어색한 침묵이 있는 대화”와 “자연스럽게 이어지는 대화”의 차이와 같습니다.

---

에이전트에게 UI 검증을 맡기다

기존에는 모든 UI 변경을 개발자가 직접 확인해야 했습니다.
이 구조에서는 개발자가 모든 기능의 병목이 됩니다.

전환 계기

• Chrome 확장 프로그램이 잦은 크래시 발생
• Claude Code의 프리뷰 기능으로 전환

변화된 워크플로

• 에이전트가 직접 프리뷰 설정
• 세션 데이터를 유지한 상태로 UI 확인
• UI 검증이 완료되어야만 “완료” 처리

결과

• 검증을 에이전트에게 위임
• 개발자는 최종 리뷰에만 개입
• 에이전트가 더 오랜 시간 자율적으로 실행 가능
• 에이전트가 스스로 실수를 잡아내는 효과가 예상보다 큼

---

병렬 워크트리 시스템 구축

앞선 개선이 끝나자, 새로운 마찰이 드러났습니다.

“한 번에 하나의 작업만 편하게 할 수 있다.”

기존 문제

• 다른 PR을 리뷰하려면 브랜치 체크아웃 필요
• 커밋되지 않은 변경과 충돌
• stash → checkout → rebuild → test → switch back → pop stash
• 수동 worktree 생성 시 포트 충돌

구조적 문제

• 프론트엔드/백엔드가 각각 별도 포트 필요
• 모든 워크트리가 동일한 환경 변수 공유
• 동일 포트 바인딩 시도

해결

• 워크트리 생성 시 고유 포트 범위를 자동 할당
• 동시에 10개의 프리뷰 실행 가능

결과

• 2개의 병렬 브랜치에도 버거웠던 환경 → 5개 워크트리 동시 운영
• 여러 에이전트를 각기 다른 워크트리에서 실행
• UI 자체 검증 완료 시점까지 자율 실행
• 리뷰 과정도 훨씬 매끄러워짐

---

제약 이론(Theory of Constraints)의 그대로인 패턴

각 단계는 서로 다른 종류의 **마찰(friction)**을 제거했습니다.

• /git-pr: PR 포맷팅 마찰 제거
• SWC: 결과를 보기까지의 대기 마찰 제거
• 프리뷰 기능: 변경 사항 검증 마찰 제거
• 워크트리 시스템: 컨텍스트 스위칭 마찰 제거

하나를 제거하면, 다음 병목이 즉시 드러납니다.
이는 **제약 이론(Theory of Constraints)**의 전형적인 패턴입니다.

---

개발의 목표가 바뀌다

작업의 본질은 더 이상
“코드를 쓰는 도구를 사용하는 것”이 아닙니다.

이제는 다음과 같은 타이트한 루프가 핵심입니다.

1. 작업 시작
2. 에이전트 코드 작성
3. 프리뷰 확인
4. diff 읽기
5. 피드백 또는 머지
6. 다음 작업

이 루프가 충분히 빠르면,
주의력이 빠져나갈 틈이 없습니다.

속도 향상 자체가 게임이 됩니다.

---

728x90

핵심은 AI가 아니라 인프라

이 경험의 결론은 명확합니다.

• 가장 높은 레버리지를 가진 작업은 기능 개발이 아니다
• 커밋의 흐름을 급류로 바꾸는 인프라 구축이 핵심이다
• 화려하지 않은 배관(plumbing) 작업이 몰입을 결정한다

결국 개발의 목표는
**“무엇을 만들 것인가”에서 “루프 속도를 얼마나 더 높일 수 있는가”**로 이동합니다.

이 단계에 도달하면,
속도 자체가 엔지니어링의 즐거움이 됩니다.

300x250

https://neilkakkar.com/productive-with-claude-code.html

How I’m Productive with Claude Code