▲

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

 (neilkakkar.com)
2P by GN⁺ 5시간전 | ★ favorite | 댓글 1개
  • 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 읽기 → 피드백 또는 머지 → 다음 작업의 타이트한 피드백 루프
  • 루프가 충분히 빠르면 주의력이 빠져나갈 틈이 없고, 속도 향상 자체가 게임이 됨
  • 최종적으로 개발의 목표는 기능 구현이 아니라, 루프 속도를 얼마나 더 높일 수 있는가로 이동
    • 속도 자체가 엔지니어링의 즐거움이 되는 단계에 도달
▲
GN⁺ 5시간전  [-]
Hacker News 의견들

  • 90년대의 ‘주간 코드 라인 수’ 지표가 다시 돌아온 느낌임
    “PR을 더 많이 한다”는 건 AI가 잘 작동한다는 증거가 아니라 단지 더 많이 머지하고 있다는 뜻임
    코드 품질, 버그, 유지보수 부담을 고려하지 않은 채 생산량만으로 성과를 판단하는 건 예전 관리자가 밀어붙이던 나쁜 지표와 다를 바 없음
    결국 우리는 나쁜 지표에 반대한 게 아니라, 측정당하는 것 자체를 싫어했던 것 같음

    • 나도 AI를 매일 쓰지만, ‘라인 수’보다는 PR 코멘트·반복·버그 최소화를 목표로 함
      코드가 단순하고 영향력 있는 결과를 내는 게 진짜 목표임
      여러 에이전트를 동시에 돌려서 서로 다른 구현을 시도하게 하고, 그중 좋은 아이디어를 합치는 식으로 실험 중임
      또, 문서와 요구사항을 모아 에이전트에게 질문을 던지고, 코드 리뷰 피드백을 일반화해 체크리스트로 만들어 다음 리뷰에 반영함
    • 글쓴이가 번아웃과 불안에 대한 블로그 글도 썼던데, 이런 생산성 집착이 그와 연결된 것 같음
      아플 정도로 일하는 건 자랑이 아니라 시스템이 잘못된 신호임
    • 글의 첫 문장에서도 “커밋은 나쁜 지표지만, 내가 가진 가장 눈에 띄는 신호”라고 인정하고 있음
    • 코드 라인 수는 개인 단위에서는 무의미하지만, 시스템 전체 규모를 추정할 때는 의미가 있음
      예를 들어 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 같은 접근으로 점진적 배포를 시도 중임
    • 나는 에이전트가 만든 코드를 그대로 배포하지 않고, 그 출력 결과만 활용함
    • 코드 리뷰는 연습으로 충분히 빨라질 수 있음
      작업을 세분화하고 테스트를 신뢰하면 AI 코드 리뷰도 가벼워짐
      테스트 케이스를 더 꼼꼼히 보고, 코드 리뷰는 빠르게 끝냄
      여러 에이전트를 병렬로 돌리진 않지만, AI 덕분에 생산성은 확실히 높아졌음

  • PR 작성 과정이 단순 자동화되면 자기 검증의 기회가 사라짐
    나는 PR 설명을 쓰는 과정에서 내 코드의 이상함을 자주 발견했음
    영어로 설명하는 그 순간이 마지막 sanity check였음

  • worktree 시스템 덕분에 문맥 전환이 쉬워졌지만, 동시에 정신적 피로가 커짐

    • 여러 에이전트를 병렬로 돌리는 게 실제로 속도나 정확도에 어떤 영향을 주는지 연구가 필요하다고 느낌
    • 나는 한 번에 1~2개의 작업에 집중하는 편임
      작은 단위로 나눠서 리뷰 주기를 짧게 가져가면 품질 관리가 쉬움
    • 에이전트에게 PR 생성을 맡기고, 나중에 몰아서 리뷰하는 식으로 큐를 쌓아두는 전략을 씀
    • 여러 worktree를 병렬로 돌리지만, 항상 지켜보진 않음
      그냥 내 흐름을 깨지 않고 다음 날 돌아와도 진행이 되어 있는 상태가 좋음

  • Claude가 코드를 완성도 높게 작성한다는 전제에는 회의적임
    실제로는 여러 번의 피드백과 수정이 필요하고, 동시에 여러 작업을 병렬로 관리하면 오히려 비효율적임

  • Claude Code는 학습용 도구로는 혁신적이지만, 코드 생성 품질은 들쭉날쭉함
    Flutter/Dart를 배우면서 Claude에게 개념을 묻는 식으로 공부했는데, 책 없이 일주일 만에 앱을 만들 수 있었음
    마치 대화형 백과사전처럼 느껴짐

    • 나도 이 용도에는 전적으로 동의함. 진짜 혁신적임
    • 많은 사람들이 이렇게 사용함
      “이 언어에서 X를 하는 관용적 방법은?” 같은 질문에 즉시 유용한 답을 줌
      다만 세상을 바꾸는 존재라기보단 아주 좋은 도구일 뿐임
    • AI는 사람을 대체하기보다 학습과 숙련을 가속화하는 방향으로 써야 함
      하지만 과도한 마케팅이 경제 전반에 부정적 영향을 주고 있음
      AI가 일자리를 대체한다는 허상 때문에 젊은 세대가 직업을 포기하는 현상도 우려됨

  • “SWC로 빌드 전환 후 서버 재시작이 1초 미만으로 줄었다”는 말이 있었는데,
    SWC는 Speedy Web Compiler로, 타입 체크 없이 빠르게 트랜스파일하는 도구임
    NestJS 문서에서도 같은 것을 설명함

  • LLM을 쓴다고 해서 생산성이 폭발적으로 늘었다고 자랑할 일은 아님
    모두가 같은 도구를 쓰면 기준선이 올라갈 뿐임
    게다가 AI가 생성한 대규모 코드가 제대로 리뷰되지 않으면 장기적 품질은 불확실함

    • 성과는 단순 비교가 아니라 자신의 결과물과 가치로 판단해야 함
    • 현대 컴파일러(GHC 등)를 써서 생산성이 높아졌다고 말하는 것도 같은 맥락임

  • LLM이 생산성을 높여주긴 하지만, 커밋 수 그래프로 측정하는 건 무의미함
    LOC로 품질을 판단하는 것만큼 어리석음

    • 나도 Claude 덕분에 몇 달 미뤘던 기능을 며칠 만에 구현했음
      직접 코드를 작성하면서 이해하고, Claude는 작업 분해와 리뷰 파트너로서 큰 도움이 됨
    • 코드베이스 개선의 최고의 지표는 음수 LOC, 즉 불필요한 코드 삭제임
    • 경험상 가장 뛰어난 엔지니어는 코드를 줄이는 사람이었음
      복잡한 코드를 단순한 추상화로 대체하는 능력이 진짜 생산성임
답변달기