Content is user-generated and unverified.

Claude Code 워크플로우: 효율적인 개발을 위한 실전 가이드

들어가며

도구는 훌륭하지만, 진정한 마법은 그것을 어떻게 사용하느냐에 있다. 이 문서는 Claude Code를 실제 개발 워크플로우에 통합하는 방법과, 수많은 시행착오를 통해 얻은 실용적인 인사이트를 공유한다.

기본 설정 (Setup)

도구 스택 구성

꽤 단순하고 작업 기반의 워크플로우를 가지고 있다:

  • Claude Code: 메인 드라이버
  • Codex: 검토 및 어려운 작업용
  • Cursor: 코드 읽기 및 수동 편집용

플랜 모드는 거의 사용하지 않는다. 대신 요구사항이 충분히 명확해지면 관련 파일을 직접 찾기 위해 코드베이스를 탐색한다.

커스텀 도구 활용

몇 가지 커스텀 명령을 유지하고, CLAUDE.md와 스크래치패드를 광범위하게 사용한다. 커스텀 서브에이전트는 없다. 필요할 때 가끔 MCP를 사용한다(예: 문서용. 지금까지 Playwright와 Figma MCP를 시도해봤다) 하지만 일반적으로는 팬이 아니다. 과거에 간단한 것들에 훅을 사용했고 필요에 따라 사용한다. 스킬/플러그인은 아직 정기적으로 사용해야 할 것이다. 관찰성(로그/오류 모니터링) 목적으로 백그라운드 에이전트를 자주 사용한다. Git worktrees는 거의 사용하지 않는다.

하네스가 너무나 철저하게 엔지니어링되어 있어서 Claude는 어떤 서브에이전트를 생성할지, 어떤 명령/도구 호출/스킬을 실행할지, 무엇을 비동기 방식으로 실행할지 안다. 에이전트 루프를 크게 운반할 수 있어서 주요 작업은 판단력을 사용하고 올바른 방향으로 프롬프트하는 것이다. 다음 세대 모델은 더 나아질 것이고, 관련 스캐폴딩은 기존 기능에 대해서는 줄어들고 새로운 기능에 대해서는 증가할 것이다.

기능을 깊이 알 필요는 전혀 없다. 하지만 작동 방식을 아는 것은 Explore 에이전트에게 Sonnet을 사용하라고 말하는 것처럼 모델을 더 잘 조종하는 데 도움이 될 수 있다.

탐색 및 실행 (Exploration and Execution)

탐색 단계: 대화를 통한 이해

Opus 4.5는 설명에 놀랍고 뛰어난 ASCII 다이어그램을 만든다. 5월 지식 컷오프도 여기서 도움이 된다. 따라서 탐색은 많은 질문을 하는 것을 포함한다 - 요구사항 명확화, 어디서/어떻게/왜 변경해야 하는지 이해하기. 플랜 모드보다 효율적이지 않을 수 있지만 이 접근 방식을 좋아한다.

충분한 컨텍스트를 가지면 /ultrathink를 많이 사용하고 어떤 변경이 필요한지 묻는다. 그런 다음 괜찮아 보이면 변경 사항을 밀접하게 모니터링하면서 실행을 시작한다 - 기본적으로 마이크로 매니징한다. 때때로 여기서 Codex의 두 번째 의견을 묻기도 한다.

"일회용 초안" 접근법

어려운 새로운 기능의 경우, 때때로 "일회용 초안" 접근법을 사용한다. 어떤 변경이 필요한지 이해하면, 새 브랜치를 만들고 Claude가 관찰하는 동안 처음부터 끝까지 기능을 작성하게 한다. 그런 다음 출력을 요구사항에 얼마나 가까웠는지에 대한 정신적 모델과 비교한다. 어디서 벗어났는가?

이 프로세스는 Claude의 오류와 가지고 있던 컨텍스트를 기반으로 내린 결정/편향을 드러낸다. 이러한 사후 지식의 이점으로 또 다른 반복을 실행하는데, 이번에는 첫 번째 패스에서 배운 것으로 알게 된 더 날카로운 프롬프트로 진행한다. 영화 테넷(Tenet)과 비슷한 개념이다.

백엔드 중심 또는 복잡한 기능의 경우 특히, 때때로 Codex xhigh에게 대신 계획을 생성하도록 요청한다.

무엇을 사용하고 사용하지 않는가 (What I Use and Don't)

사용하는 것

  • 몇 가지 커스텀 명령
  • CLAUDE.md와 스크래치패드를 광범위하게 사용
  • 관찰성(로그/오류 모니터링) 목적의 백그라운드 에이전트
  • 필요 시 MCP (문서, Playwright, Figma MCP)
  • 간단한 작업을 위한 훅

사용하지 않는 것

  • 커스텀 서브에이전트 (아직)
  • Git worktrees (거의)
  • 스킬/플러그인 (정기적으로는 아직)
  • MCP (일반적으로는 팬이 아님, 필요 시에만)

판단의 중요성

하네스가 너무 철저하게 엔지니어링되어 있어서 Claude가 대부분의 작업을 자동으로 처리한다. 주요 작업은 판단력을 사용하고 올바른 방향으로 프롬프트하는 것이다. 기능을 깊이 알 필요는 없지만, 작동 방식을 이해하면 모델을 더 잘 조종할 수 있다.

검토 단계 (Review)

Codex를 활용한 코드 리뷰

코드를 검토하고 버그를 찾는 데는 GPT-5.2-Codex가 우수하다고 생각한다. 그냥 /review를 사용하면 된다. 코드 리뷰 제품보다 낫다.

버그를 찾고 P1, P2와 같은 심각도를 언급할 수 있다. Claude에 비해 위양성을 보고할 가능성이 적고 혼란스러운 변경사항에 대해 더 신뢰할 수 있다. 실행은 Claude로, 검토/버그는 GPT/o-시리즈 모델로 하는 이 역학은 아마도 1년 동안 꽤 일정했다.

검토 프로세스

  1. Opus 4.5로 변경 사항 구현
  2. GPT-5.2-Codex로 코드 검토 수행
  3. 발견된 버그와 개선 사항 확인
  4. 필요한 경우 수정 반복

컨텍스트 관리

컨텍스트 모니터링

/context를 사용하여 현재 컨텍스트 사용량을 자주 확인한다. 복잡한 것을 구축할 때 총 60%에 도달하면 핸드오프나 컴팩트를 수행한다.

컨텍스트 최적화 전략

  • 컨텍스트가 50-60%에 도달하면: 새로운 대화를 시작하거나 /compact 실행
  • 복잡한 작업 시작 전: 항상 컨텍스트 상태 확인
  • 핸드오프 명령 사용: 현재 세션의 중요한 정보를 요약하고 새 세션으로 전환

실용적인 팁

울트라싱크 활용

어려운 작업이나 Opus 4.5가 더 엄격하기를 원할 때 울트라싱크를 많이 사용한다. 예를 들어:

  • 복잡한 개념 설명이 필요할 때
  • 변경 사항을 자체 검토할 때
  • 아키텍처 결정이 필요한 경우

질문 주도 개발

Claude와 대화하면서 개발하는 접근법:

  1. 요구사항에 대해 질문
  2. 코드베이스 구조 이해
  3. 변경이 필요한 위치와 방법 파악
  4. 구현 전략 검증
  5. 단계별 실행

이 방법은 플랜 모드보다 덜 효율적일 수 있지만, 더 깊은 이해와 더 나은 결과를 제공한다.

다른 도구와의 통합

Claude Code + Codex + Cursor

세 가지 도구를 조합하여 사용하는 이유:

  • Claude Code: 빠른 반복, 우수한 커뮤니케이션, 메인 개발
  • Codex: 깊은 검토, 버그 발견, 복잡한 작업 계획
  • Cursor: 코드 읽기, 빠른 수동 편집

각 도구의 강점을 활용하여 최상의 결과를 얻는다.

워크플로우 진화

지속적인 학습

도구와 모델은 계속 진화한다. 다음 세대 모델은 더 나아질 것이고:

  • 기존 기능에 대한 스캐폴딩은 줄어들 것
  • 새로운 기능에 대한 스캐폴딩은 증가할 것
  • 판단력과 프롬프팅의 중요성은 계속될 것

실험 정신

새로운 기능이나 접근법을 시도하는 것을 두려워하지 마라. Claude Code는 안전하게 실험할 수 있는 환경을 제공한다:

  • 체크포인팅으로 쉽게 되돌릴 수 있음
  • 서브에이전트로 병렬 탐색 가능
  • 백그라운드 에이전트로 장시간 작업 모니터링

마치며

효율적인 워크플로우는 도구의 기능을 이해하고, 각 도구의 강점을 활용하며, 지속적으로 배우고 실험하는 것에서 나온다. Claude Code는 강력한 하네스와 프롬프트로 대부분의 무거운 작업을 수행하므로, 개발자는 판단력과 전략에 집중할 수 있다.

가장 중요한 것은 완벽한 워크플로우를 찾으려고 하지 말고, 자신의 작업 스타일과 프로젝트 요구사항에 맞는 워크플로우를 만들어가는 것이다. 도구는 계속 진화하고, 우리의 워크플로우도 함께 진화해야 한다.


작성 일자: 2025-12-29

Content is user-generated and unverified.
    Claude Code Workflow: Practical Development Guide | Claude