메인 콘텐츠로 건너뛰기

Claude Code 개발을 자동화하는 스펙 워크플로우 완전 정리

요약

AI 클립으로 정리됨

출처 및 참고 : https://github.com/Pimzino/claude-code-spec-workflow

“요구사항 → 설계 → 태스크 → 구현”이 머릿속이 아니라 시스템 안에서 자동으로 돌아간다면 어떨까요? Claude Code용 오픈소스 패키지인 claude-code-spec-workflow는 바로 그 부분을 대신 해주는 도구입니다. 새로운 기능은 스펙 기반으로, 버그는 보고부터 검증까지 한 흐름으로 처리하게 만들어 개발 프로세스를 정리해 줍니다.

이 글에서는 이 워크플로우가 무엇을 해주는지, 어떻게 설치하고 쓰는지, 언제 쓰면 좋은지까지 한 번에 살펴보겠습니다.

Claude Code Spec Workflow란? 한 문장으로 요약하면

claude-code-spec-workflow는 Claude Code를 위한 “개발 비서 겸 PM” 같은 도구입니다.

새 기능을 만들 때는 요구사항을 정리하고, 설계를 만들고, 태스크를 쪼개고, 구현까지 이어지는 전 과정을 하나의 구조화된 스펙으로 묶어 줍니다.

버그가 발생하면 “보고 → 원인 분석 → 수정 → 검증”까지를 일정한 형식으로 관리해 줘서, 내가 혼자 개발하든 팀으로 개발하든 흐름이 엉키지 않게 도와줍니다.

특징적으로 다음 두 가지를 중심에 둡니다.

  • 새 기능: 스펙 워크플로우

  • 버그 수정: 버그 워크플로우

여기에 실시간 대시보드, AI 에이전트, 문맥 최적화, 타입스크립트 기반 프론트엔드까지 붙어서 꽤 본격적인 “개발 워크플로우 플랫폼”의 느낌을 줍니다.

왜 이런 워크플로우 도구가 필요한가?

실제 개발을 해보면 이런 상황이 반복됩니다.

기능을 급하게 만들다가 요구사항이 뒤늦게 바뀌고, 설계 없이 바로 코딩했다가 기술 부채가 쌓이고, 버그가 생겼는데 “이거 왜 이렇게 고쳤는지” 나중에 기억이 안 나는 경우 말이죠.

문제의 핵심은 대부분 “흐름이 없다”는 겁니다. 누군가는 머릿속에, 누군가는 메모에, 누군가는 이슈 트래커에 흩어져 있어서 나중에 전체 그림을 보기 어렵습니다.

Claude Code Spec Workflow는 이 흐름을 강제로 구조화합니다.

  • 기능은 반드시 “요구사항 → 설계 → 태스크 → 구현”의 흐름을 따르게 하고

  • 버그는 “보고 → 분석 → 수정 → 검증”을 거치게 합니다.

게다가 각 단계가 명시적인 파일과 명령으로 관리되기 때문에, AI를 쓸 때도 “맥락이 정리된 상태”에서 도움을 받게 됩니다. 결과적으로:

  • 문서화가 자연스럽게 따라오고

  • 작업 단위가 명확해지고

  • 협업과 리뷰가 쉬워집니다.

설치 방법과 기본 세팅: 시작은 의외로 간단하다

이 도구는 Node.js 16 이상과 Claude Code가 설치되어 있으면 바로 사용할 수 있습니다.

전형적인 시작 흐름은 대략 이렇게 흘러갑니다.

  • 글로벌 설치로 명령을 어디서나 쓰게 만들고

  • 프로젝트 디렉터리에서 한 번만 초기 설정을 돌립니다.

설정 과정에서는 다음과 같은 선택을 하게 됩니다.

  • AI 에이전트를 쓸지 말지 (더 자동화 vs 조금 더 단순한 설정)

  • 프로젝트 분석을 허용할지 (프레임워크, 패턴 자동 탐지)

한 번 세팅을 끝내면, 프로젝트 안에 .claude/라는 디렉터리가 생기고 그 안에 명령, 템플릿, 스펙, 버그 문서, 에이전트 설정이 모두 들어가게 됩니다. 이후에는 Claude에 슬래시 명령을 치거나, 제공된 CLI를 호출하는 방식으로 워크플로우를 사용하게 됩니다.

스펙 워크플로우: 새로운 기능을 위한 자동화된 흐름

이 도구의 핵심은 새 기능 개발을 위한 “스펙 워크플로우”입니다.

가장 인상적인 점은 “한 줄 명령으로 전체 스펙을 만들어 준다”는 것인데, 예를 들어 로그인 기능을 만든다고 하면 이런 식입니다.

  • 기능 이름과 짧은 설명만 넘기면

  • 도구가 요구사항, 유저 스토리, 수용 기준, 기술 설계, 태스크 분해까지 자동으로 만들어 줍니다.

생성되는 단계는 대략 다음과 같이 구성됩니다.

  • Requirements: 유저 스토리, 시나리오, acceptance criteria

  • Design: 기술 아키텍처, 주요 컴포넌트, 다이어그램 등

  • Tasks: 에이전트가 처리하기 좋은 작은 단위의 태스크 목록

  • Commands: 각 태스크를 실행할 수 있는 명령들 (자동 생성 가능)

그다음에는 두 가지 스타일 중 하나로 실행을 이어갈 수 있습니다.

  • 수동 제어: 특정 태스크만 골라서 실행하면서 천천히 진행

  • 자동 실행: 순서대로 쭉 실행해서 구현까지 밀어붙이기

즉, “생각 → 문서 → 태스크 → 코드”까지 이어지는 흐름을 시스템 차원에서 잡아주는 셈입니다. 특히 큰 기능이나 복잡한 리팩터링을 할 때 머릿속만 믿지 않아도 된다는 것이 큰 장점입니다.

버그 워크플로우: Report → Analyze → Fix → Verify

버그가 생겼을 때도 이 도구는 일정한 흐름을 강제합니다.

버그 이름과 설명을 입력하면 버그 문서가 만들어지고, 이후에 정해진 단계가 순서대로 이어집니다.

  • Report: 어떤 상황에서 문제가 발생하는지, 증상을 정리

  • Analyze: 재현, 로그 분석, 원인 후보 정리

  • Fix: 실제 코드 수정과 관련 커밋 내용 설명

  • Verify: 수정 후 재현 테스트, 회귀 여부 확인

각 단계는 슬래시 명령으로 되어 있어서, “지금 내가 무엇을 하고 있는지”를 분명하게 의식하게 합니다.

이 덕분에 나중에 “이 버그 왜 이렇게 고쳤더라?” 싶을 때, .claude/bugs 아래 문서만 보면 당시의 생각과 결정 과정을 그대로 따라갈 수 있습니다. 팀 개발에서는 특히, 버그 하나하나가 작은 히스토리 문서처럼 쌓이는 효과가 큽니다.

Steering 문서: 프로젝트의 ‘세계관’을 정의한다

이 워크플로우의 재미있는 부분이 바로 ‘Steering 문서’입니다.

보통 프로젝트를 하다 보면 이런 정보들이 여기저기 흩어져 있습니다.

  • 이 제품은 어떤 사람들을 위한 것인지

  • 어떤 기술 스택과 패턴을 쓰는지

  • 디렉터리 구조와 네이밍 컨벤션은 무엇인지

spec-steering-setup 명령을 한 번 실행하면, 프로젝트 안에 세 가지 핵심 문서가 만들어집니다.

  • product.md: 제품 비전, 타깃 유저, 핵심 기능, 성공 지표

  • tech.md: 기술 스택, 프레임워크, 개발 도구, 제약 사항

  • structure.md: 폴더 구조, 네이밍 규칙, import 패턴, 코드 구조 원칙

이 문서들은 단순한 설명 문서를 넘어, 이후 모든 스펙 작업과 코드 생성의 기준점이 됩니다.

Claude는 이 문서를 분석해서 “이 프로젝트에서는 이런 식으로 코드를 짜야 한다”라는 암묵적 규칙을 익히고, 그 기준을 따라 스펙과 구현 제안을 해 줍니다. 즉, AI에게 ‘프로젝트의 세계관’을 한 번에 주입하는 장치라고 보면 이해하기 쉽습니다.

실시간 대시보드와 터널: 진행 상황을 눈으로 보는 맛

CLI와 문서만으로도 충분히 쓸 수 있지만, 이 패키지에는 꽤 괜찮은 대시보드도 들어 있습니다.

별도의 명령으로 대시보드를 띄우면 브라우저에서 다음과 같은 정보를 한눈에 볼 수 있습니다.

  • 프로젝트별 스펙과 버그 현황

  • 각 스펙의 진행 단계와 태스크 상태

  • 현재 실행 중인 워크플로우

WebSocket 기반으로 실시간 업데이트가 되고, Tailwind CSS로 꾸며진 현대적인 UI라서 “지금 이 프로젝트가 어디까지 왔는지”를 직관적으로 파악하기 좋습니다.

여기에 ‘대시보드 터널’ 기능이 붙어 있어서, 임시 HTTPS 주소를 만들어 외부 사람에게도 공유할 수 있습니다.

  • 매니저나 클라이언트에게 진행 상황을 보여주고 싶을 때

  • 원격 팀과 실시간으로 상황을 맞춰야 할 때

터널은 다음과 같은 안전장치도 갖추고 있습니다.

  • HTTPS로 접속

  • 읽기 전용 접근 (외부에서 프로젝트 데이터 수정 불가)

  • 비밀번호 옵션으로 접근 제어

  • Cloudflare, ngrok 등 여러 제공자 지원 및 자동 폴백

  • 대시보드를 끄면 터널도 자동 종료

즉, 별도 배포 없이도 “간단한 PM용 진행 상황 대시보드”를 무료로 가진 느낌입니다.

컨텍스트 최적화: 토큰을 아껴주는 똑똑한 문서 로딩

Claude와 같은 LLM을 개발 워크플로우에 쓰다 보면, 항상 부딪히는 문제가 하나 있습니다. 바로 “맥락을 얼마나 많이, 얼마나 자주 보내야 하는가”입니다.

이 패키지는 이 부분에 꽤 신경을 썼습니다.

  • 스티어링 문서, 스펙, 템플릿처럼 자주 쓰이는 문서는 한 번에 묶어서 불러옵니다.

  • 버그 문서처럼 개별성이 강한 문서는 필요할 때 직접 읽습니다.

  • 메인 에이전트가 전체 컨텍스트를 한 번 로딩하면, 서브 에이전트에게는 필요한 부분만 전달해 “다시 불러오지 말라”고 명시합니다.

이 전략 덕분에:

  • 전체 문서 로딩에 쓰이는 토큰을 60~80%까지 줄일 수 있고

  • 동일한 정보를 중복해서 보내지 않기 때문에 응답 속도도 빨라집니다.

또한 세션 단위 캐싱과 파일 변경 감지를 통해, 파일이 바뀐 경우에만 새로 읽는 식으로 동작합니다. 결과적으로 “큰 프로젝트에서도 LLM 호출 비용과 속도를 둘 다 잡는” 구조를 만들어 둡니다.

TypeScript 기반 대시보드: 프론트엔드 개발자에게도 반가운 구성

대시보드 쪽은 TypeScript로 아주 꼼꼼하게 구현되어 있습니다.

  • 프론트엔드 타입 정의가 잘 되어 있고

  • WebSocket 메시지는 구분된 유니온 타입으로 관리되고

  • 상태 관리, 에러 핸들링, 런타임 타입 가드까지 갖춰져 있습니다.

개발 편의성을 위해 다음과 같은 스크립트도 준비되어 있습니다.

  • 개발용/프로덕션용 프론트엔드 빌드

  • 프론트엔드 전용 타입 체크

  • 백엔드+프론트엔드 전체 빌드

  • 린트, 포맷 자동화

간단히 말하면 “대충 돌아가게 만든 데모 대시보드”가 아니라, 실제 프로젝트에서도 참고할 수 있을 정도의 타입 안정성과 구성 품질을 가진 프론트엔드입니다.

TypeScript를 좋아하는 개발자라면, 이 프로젝트 구조 자체가 좋은 학습 소재가 되기도 합니다.

언제, 어떻게 쓰면 가장 유용할까?

이 도구를 언제 쓰면 좋을지 기준을 잡아보면 대략 이렇습니다.

  • 새로운 기능을 추가할 때

    • 스펙이 어느 정도 명확하다면 스펙 워크플로우로 전체 과정을 자동화

    • 복잡하거나 실험적인 기능이라면 태스크 실행을 수동으로 조정하면서 진행

  • 기존 코드에서 버그가 터졌을 때

    • 버그 워크플로우로 원인 분석부터 검증까지 기록을 남기면서 처리

  • 코드베이스를 익히고 싶을 때

    • 개별 명령으로 천천히 실행해 보며 “이 프로젝트가 어떻게 돌아가는지” 파악

  • 실제 배포용 기능을 만들 때

    • 스펙 워크플로우를 처음부터 끝까지 사용하고, 완성 후 스펙과 코드 리뷰까지 함께 진행

또 문서에서는 “스펙 생성에는 Claude Opus 4, 구현에는 Claude Sonnet 4” 조합을 추천합니다. 무거운 사고가 필요한 설계 단계와, 빠른 반복이 필요한 구현 단계를 분리해서 다른 모델을 쓰라는 전략입니다.

본인의 작업 스타일에 맞게:

  • 초반에는 완전 자동화에 의존해보고

  • 익숙해지면 일부 단계는 수동으로 조정하면서

  • 궁극적으로 “팀의 개발 문화”에 맞게 커스터마이징하는 방식이 가장 자연스럽습니다.

마무리: 혼자 개발해도 “팀처럼” 일하고 싶다면

Claude Code Spec Workflow는 결국 이런 질문에 대한 답입니다.

“혼자 혹은 소수 인원으로 개발하면서도, 요구사항 관리, 설계, 구현, 버그 처리까지 팀처럼 체계적으로 굴릴 수 없을까?”

이 도구는:

  • 스펙 기반 개발을 강제해 주고

  • 버그 플로우를 문서로 남겨 주고

  • 프로젝트의 세계관(steering 문서)을 한 번 정의하면

  • AI가 그 기준 안에서 일하도록 만들어 줍니다.

거기에 실시간 대시보드와 안전한 터널 공유, 컨텍스트 최적화까지 붙어서 “생각보다 꽤 본격적인 개발 운영 도구”로 완성됩니다.

개인적으로는 다음과 같은 사람들에게 특히 추천하고 싶습니다.

  • “이제는 좀 제대로 문서화하고 싶다”는 1인 개발자

  • AI를 실무 개발에 깊게 통합해 보고 싶은 팀

  • 스펙과 버그 히스토리를 자산으로 남기고 싶은 CTO/리드 개발자

이미 Claude Code를 쓰고 있다면, 이 워크플로우를 한 번 프로젝트에 붙여보세요. 처음에는 명령이 많아 보여도, 몇 번 돌려 보면 “아, 개발 흐름이 이렇게 유도되는구나” 하는 감각이 생깁니다.

그 이후부터는, 예전처럼 “감으로” 개발하던 때로 돌아가기 꽤 어려워질지도 모릅니다.

출처 및 참고 : GitHub - Pimzino/claude-code-spec-workflow: Automated workflows for Claude Code. Features spec-driven development for new features (Requirements → Design → Tasks → Implementation) and streamlined bug fix workflow for quick issue resolution (Report → Analyze → Fix → Verify).

이 노트는 요약·비평·학습 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.