# Claude Code로 생산성을 높이는 방법 > Clean Markdown view of GeekNews topic #27817. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=27817](https://news.hada.io/topic?id=27817) - GeekNews Markdown: [https://news.hada.io/topic/27817.md](https://news.hada.io/topic/27817.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-03-25T05:33:26+09:00 - Updated: 2026-03-25T05:33:26+09:00 - Original source: [neilkakkar.com](https://neilkakkar.com/productive-with-claude-code.html) - Points: 42 - Comments: 2 ## Summary 개발 효율을 높이려면 AI보다 **에이전트가 일하는 인프라**를 다듬는 일이 핵심임을 보여줍니다. `/git-pr` 자동화, **SWC 기반 초고속 빌드**, 프리뷰 검증, 병렬 워크트리 등으로 반복 작업과 대기 시간을 없애며 루프 속도를 극단적으로 끌어올린 사례인데요. 각 마찰을 제거할 때마다 새로운 병목이 드러나는 **제약 이론 패턴**이 그대로 적용되어, 이제 개발의 초점은 기능 구현이 아니라 루프를 얼마나 빠르게 돌릴 수 있느냐로 이동합니다. 이번 위클리 전체에 조금씩 이런 것들이 스며들어 있네요. 다들 비슷한 곳을 보고 있다고 생각이 됩니다. ## Topic Body - 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 생성 후 포트 충돌 발생 - 앱이 프론트엔드와 백엔드 각각 별도 포트를 필요로 하며, 모든 워크트리가 **동일한 환경 변수를 공유**하여 같은 포트에 바인딩 시도 - 이를 해결하기 위해 워크트리 생성 시 각 서버에 **고유 포트 범위를 자동 할당**하는 시스템 구축 - 동시에 10개의 프리뷰도 실행 가능 - 2개의 병렬 브랜치에도 압도되던 상태에서 **5개의 워크트리를 동시에 운영**하는 수준으로 전환 - 여러 에이전트를 별도 워크트리에서 각각 다른 기능을 빌드하도록 실행하고, **UI 자체 검증이 완료될 때까지 자율 실행** - 계획 단계에 깊이 관여한 후 **코드 리뷰 시점까지 개입하지 않는** 방식 - 리뷰도 훨씬 매끄러워짐: 설정 작업, 리빌드, 포트 충돌 없이 **읽고, 확인하고, 머지**하는 흐름 ### 핵심은 AI가 아니라 인프라 - 역할이 변화: 복잡한 문제를 직접 풀고 완벽한 UI를 만드는 데 시간을 쓰는 대신, **에이전트를 효과적으로 만드는 인프라를 구축**하는 것이 더 재미있어짐 - 솔로 개발자가 아닌 **10명 규모 팀의 매니저**가 된 것과 유사 - 화려하지 않은 배관(plumbing) 작업이지만, 이것이 **플로 상태에 머무르는지 환경과 싸우는지**를 결정 - Tano에서 가장 높은 레버리지를 가진 작업은 기능 개발이 아니라, **커밋의 흐름을 급류로 바꾼 인프라 구축** ### 루프: 제약 이론의 적용 - 각 단계가 서로 다른 종류의 마찰을 제거: - `/git-pr`: 코드 변경을 PR로 만드는 **포맷팅 마찰** 제거 - SWC: 변경 후 결과를 보기까지의 **대기 마찰** 제거 - 프리뷰 기능: 변경 사항을 확인하는 **검증 마찰** 제거 - 워크트리 시스템: 여러 작업 흐름 간 **컨텍스트 스위칭 마찰** 제거 - 하나를 제거할 때마다 다음 병목이 즉시 드러나는, **제약 이론(Theory of Constraints)** 의 전형적 패턴 - 작업의 본질이 변화: "코드를 쓰는 도구를 사용하는 것"이 아니라, 작업 시작 → 에이전트 코드 작성 → 프리뷰 확인 → diff 읽기 → 피드백 또는 머지 → 다음 작업의 **타이트한 피드백 루프** - 루프가 충분히 빠르면 주의력이 빠져나갈 틈이 없고, **속도 향상 자체가 게임**이 됨 - 최종적으로 개발의 목표는 기능 구현이 아니라, **루프 속도를 얼마나 더 높일 수 있는가**로 이동 - **속도 자체가 엔지니어링의 즐거움이 되는 단계**에 도달 ## Comments ### Comment 53772 - Author: t7vonn - Created: 2026-03-25T10:40:05+09:00 - Points: 1 리뷰어로서는 기계가 쓴 PR Description을 봤을 때 경험이 썩 좋지 않더라고요. 프롬프트 튜닝만 잘 하면 되려나 싶기도 합니다만.. ### Comment 53749 - Author: neo - Created: 2026-03-25T05:33:26+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47494890) - 90년대의 **‘주간 코드 라인 수’** 지표가 다시 돌아온 느낌임 “PR을 더 많이 한다”는 건 AI가 잘 작동한다는 증거가 아니라 단지 더 많이 머지하고 있다는 뜻임 코드 품질, 버그, 유지보수 부담을 고려하지 않은 채 생산량만으로 성과를 판단하는 건 예전 관리자가 밀어붙이던 나쁜 지표와 다를 바 없음 결국 우리는 나쁜 지표에 반대한 게 아니라, **측정당하는 것 자체**를 싫어했던 것 같음 - 나도 AI를 매일 쓰지만, ‘라인 수’보다는 **PR 코멘트·반복·버그 최소화**를 목표로 함 코드가 단순하고 영향력 있는 결과를 내는 게 진짜 목표임 여러 에이전트를 동시에 돌려서 서로 다른 구현을 시도하게 하고, 그중 좋은 아이디어를 합치는 식으로 실험 중임 또, 문서와 요구사항을 모아 에이전트에게 질문을 던지고, 코드 리뷰 피드백을 일반화해 **체크리스트**로 만들어 다음 리뷰에 반영함 - 글쓴이가 **번아웃과 불안**에 대한 블로그 글도 썼던데, 이런 생산성 집착이 그와 연결된 것 같음 아플 정도로 일하는 건 자랑이 아니라 시스템이 잘못된 신호임 - 글의 첫 문장에서도 “커밋은 나쁜 지표지만, 내가 가진 가장 눈에 띄는 신호”라고 인정하고 있음 - 코드 라인 수는 개인 단위에서는 무의미하지만, 시스템 전체 규모를 추정할 때는 의미가 있음 예를 들어 [COCOMO 모델](https://en.wikipedia.org/wiki/COCOMO)은 법정에서도 시스템 가치 추정에 사용될 정도로 신뢰받음 - “나쁜 지표에 반대한 게 아니라 측정 자체를 싫어했다”는 말은 결국 **좋은 지표란 존재하느냐**의 문제임 대부분의 개발자는 자기 자신을 수치화하고 싶지 않음 다만 AI 옹호자들은 개선을 증명하려면 측정이 필요하다고 생각함 - LLM을 이용해 **인지 부하를 줄이는 방향**으로 써야 한다고 생각함 사람은 멀티태스킹에 약하고, LLM이 그걸 보완해주지는 않음 나는 Claude에게 구현을 대신 맡기기보다, **직접 구현 과정을 안내받는 방식**으로 씀 이렇게 하면 전체 과정을 이해하면서 세부와 큰 그림을 동시에 볼 수 있음 반복적이고 기계적인 부분만 Claude에게 맡기면 됨 - 나도 **POC 중심 워크플로우**를 씀 LLM에게 문제를 이해하도록 질문을 던지고, 핵심 코드를 직접 작성한 뒤 나머지 구현 계획을 세우게 함 LLM은 코드 읽기·설명·단순 작업에 강하고, 나는 문제 해결 방향을 선택하는 데 집중함 - 이 아이디어가 너무 마음에 들어서 바로 시도해볼 예정임 LLM이 내 대신 결정한 부분을 추적하기 위해 “가정 목록 작성”이나 “계획에 없던 결정 나열” 같은 프롬프트를 실험 중임 - 어떤 사람은 이런 강도 높은 협업이 **재미있고 몰입감 있다**고 함 Claude의 특성을 이해하면 검증 효율도 높아지고, 경험이 쌓일수록 품질 관리도 쉬워짐 - 여러 에이전트를 돌려 큰 기능을 만들면, 결국 **리뷰 시간이 엄청나게 늘어나는 문제**가 생김 다른 사람(혹은 AI)의 코드를 읽는 게 직접 작성하는 것보다 어렵기 때문임 테스트 자동화로 커버할 수도 있겠지만, 완전한 신뢰는 어려움 - 그래서 나는 **계획 단계의 엄격함**을 강조함 범위·테스트·문서 계획을 명확히 하고, 코드 리뷰 봇(Sourcery, CodeRabbit, Codescene)과 **강력한 린팅 규칙**을 적용함 BDD, property testing, e2e 테스트, 코드 감사, **mutation/fuzzing 테스트**까지 활용함 에이전트 코딩의 장점은 이런 품질 관리에 쓸 시간을 확보해준다는 점임 - LLM이 불필요하게 **장황하고 불필요한 수정**을 많이 해서 리뷰 범위가 넓어지는 게 병목임 - 하지만 단순 수정이나 UI 개선처럼 위험이 낮은 변경은 **자동 배포**도 가능함 [100 PRs a day](https://jonathannen.com/building-towards-100-prs-a-day/) 같은 접근으로 점진적 배포를 시도 중임 - 나는 에이전트가 만든 코드를 그대로 배포하지 않고, 그 **출력 결과만 활용**함 - 코드 리뷰는 연습으로 충분히 빨라질 수 있음 작업을 세분화하고 테스트를 신뢰하면 AI 코드 리뷰도 가벼워짐 테스트 케이스를 더 꼼꼼히 보고, 코드 리뷰는 빠르게 끝냄 여러 에이전트를 병렬로 돌리진 않지만, AI 덕분에 생산성은 확실히 높아졌음 - PR 작성 과정이 단순 자동화되면 **자기 검증의 기회**가 사라짐 나는 PR 설명을 쓰는 과정에서 내 코드의 이상함을 자주 발견했음 영어로 설명하는 그 순간이 마지막 sanity check였음 - **worktree 시스템** 덕분에 문맥 전환이 쉬워졌지만, 동시에 **정신적 피로**가 커짐 - 여러 에이전트를 병렬로 돌리는 게 실제로 속도나 정확도에 어떤 영향을 주는지 **연구가 필요**하다고 느낌 - 나는 한 번에 1~2개의 작업에 집중하는 편임 작은 단위로 나눠서 리뷰 주기를 짧게 가져가면 품질 관리가 쉬움 - 에이전트에게 PR 생성을 맡기고, 나중에 몰아서 리뷰하는 식으로 **큐를 쌓아두는 전략**을 씀 - 여러 worktree를 병렬로 돌리지만, 항상 지켜보진 않음 그냥 내 흐름을 깨지 않고 다음 날 돌아와도 **진행이 되어 있는 상태**가 좋음 - Claude가 코드를 완성도 높게 작성한다는 전제에는 회의적임 실제로는 **여러 번의 피드백과 수정**이 필요하고, 동시에 여러 작업을 병렬로 관리하면 오히려 비효율적임 - Claude Code는 **학습용 도구로는 혁신적**이지만, 코드 생성 품질은 들쭉날쭉함 Flutter/Dart를 배우면서 Claude에게 개념을 묻는 식으로 공부했는데, 책 없이 일주일 만에 앱을 만들 수 있었음 마치 **대화형 백과사전**처럼 느껴짐 - 나도 이 용도에는 전적으로 동의함. 진짜 혁신적임 - 많은 사람들이 이렇게 사용함 “이 언어에서 X를 하는 관용적 방법은?” 같은 질문에 즉시 유용한 답을 줌 다만 세상을 바꾸는 존재라기보단 **아주 좋은 도구**일 뿐임 - AI는 사람을 대체하기보다 **학습과 숙련을 가속화하는 방향**으로 써야 함 하지만 과도한 마케팅이 경제 전반에 부정적 영향을 주고 있음 AI가 일자리를 대체한다는 허상 때문에 젊은 세대가 직업을 포기하는 현상도 우려됨 - “SWC로 빌드 전환 후 서버 재시작이 1초 미만으로 줄었다”는 말이 있었는데, [SWC](https://swc.rs/)는 **Speedy Web Compiler**로, 타입 체크 없이 빠르게 트랜스파일하는 도구임 [NestJS 문서](https://docs.nestjs.com/recipes/swc)에서도 같은 것을 설명함 - LLM을 쓴다고 해서 **생산성이 폭발적으로 늘었다고 자랑할 일은 아님** 모두가 같은 도구를 쓰면 기준선이 올라갈 뿐임 게다가 AI가 생성한 대규모 코드가 제대로 리뷰되지 않으면 장기적 품질은 불확실함 - 성과는 단순 비교가 아니라 **자신의 결과물과 가치**로 판단해야 함 - 현대 컴파일러(GHC 등)를 써서 생산성이 높아졌다고 말하는 것도 같은 맥락임 - LLM이 생산성을 높여주긴 하지만, **커밋 수 그래프**로 측정하는 건 무의미함 LOC로 품질을 판단하는 것만큼 어리석음 - 나도 Claude 덕분에 몇 달 미뤘던 기능을 며칠 만에 구현했음 직접 코드를 작성하면서 이해하고, Claude는 **작업 분해와 리뷰 파트너**로서 큰 도움이 됨 - 코드베이스 개선의 최고의 지표는 **음수 LOC**, 즉 불필요한 코드 삭제임 - 경험상 가장 뛰어난 엔지니어는 **코드를 줄이는 사람**이었음 복잡한 코드를 단순한 추상화로 대체하는 능력이 진짜 생산성임