GitHub Spec Kit과 Kiro, Claude Code의 SDD 워크플로 비교

2026년에 스펙 기반 개발(Spec-Driven Development) 방식을 비교하는 개발자들은 통상 가장 똑똑한 모델이 무엇인지 묻지 않습니다. 그들은 AI 에이전트를 세리머니(중요하지 않은 절차)에 매몰시키지 않으면서도 정렬 상태(Aligned)를 유지하는 워크플로우가 무엇인지 묻고 있습니다.

GitHub Spec Kit, AWS Kiro, Claude Code 커스텀 워크플로우는 모두 동일한 광범위한 아이디어–요구사항, 설계, 태스크, 구현, 검증–를 구현하지만, 이식성, 통합 깊이, 강제하는 프로세스의 양에 대해 상이한 트레이드오프를 제공합니다.

먼저 개념이 필요하시다면 스펙 기반 개발이란 무엇인가?와 툴에 의존하지 않는 스펙 기반 개발 워크플로우 가이드를 애플리케이션 아키텍처 문서 클러스터에서 읽어보시기 바랍니다. 이 비교 분석은 어시스턴트 리뷰와 워크플로우 가이드와 함께 AI 개발 도구 허브에 위치해 있습니다.

SDD가 툴 카테고리가 되고 있다

스펙 기반 개발은 2025년 후반쯤에 서론적 연습(paper exercise)이 아니게 되었습니다. 모든 주요 AI 코딩 벤더는 이제 specify-plan-implement(요구사항 정의-계획 수립-구현)의 어떤 버전을 제공하고 있으며, 이 루프 주위에 얼마나 많은 구조를 추가하는지 경쟁하는 독립형 툴 목록이 점점 더 늘어나고 있습니다.

중요한 비교는 “어떤 툴이 승리하는가"가 아닙니다. 그것은 프로세스 깊이와 이식성입니다. Kiro는 통합되어 있습니다. Spec Kit은 이식 가능합니다. Claude Code 워크플로우는 해킹(수정)이 가능합니다. 나쁜 스펙은 어떤 래퍼를 선택하든 모든 에이전트를 더 나쁘게 만듭니다. 좋은 스펙은 툴을 가로지릅니다.

SDD 세업 비교 방법

도구를 선택하기 전에, 무엇을 최적화하고 싶은지 명확히 하세요. 팀 크기, 코드베이스의 연령, 필요한 리뷰 양에 따라 동일한 기능이 한 세업에서는 effortless(수월하게) 느껴지고 다른 세업에서는 관료적(bureaucratic)으로 느껴질 수 있습니다.

이식성(Portability) – 스펙이 저장소에서 평범한 마크다운으로 존재하여 다음 분기에 선호하는 에이전트와 함께 작동할 수 있는가? 아니면 하나의 IDE, 하나의 클라우드, 또는 하나의 독점적 형식에 묶여 있는가?

세업 마찰(Setup friction) – “SDD를 시도하고 싶다"에서 작동하는 specify-plan-tasks 루프까지 얼마나 시간이 걸리는가? CLI 스캐폴딩, IDE 설치, 또는 나만의 슬래시 커맨드를 만드는 것 모두 다른 활성화 에너지를 가집니다.

스펙 품질(Spec quality) – 그 도구가 정확한 요구사항과 수용 기준 작성에 도움이 되는가, 아니면 대부분 긴 문서를 생성하는가? 구조는 유용합니다. 양(Volume)은 아닙니다.

태스크 실행(Task execution) – 도구가 작업을 리뷰 가능한 조각으로 어떻게 나눕는가? 태스크가 병렬로 실행될 수 있는가? 50개 항목의 태스크 폭발을 억제하는가?

리뷰 체킹포인트(Review checkpoints) – specify, plan, tasks, implement 사이에 자연스러운 인간 게이트가 있는가? 리뷰 없는 SDD는 더 느린 바이브 코딩(vibe coding)일 뿐입니다.

저장소 근거(Repository grounding) – 워크플로우는 계획 전에 프로젝트 관습, 의사결정 기록, ADR, AGENTS.md, 기존 코드를 읽는가? 근거 없는 에이전트는 이전 선택 뒤에 있는 검토된 의도를 결코 보지 않기 때문에 아키텍처를 재발명합니다.

팀 협업(Team collaboration) – 여러 사람이 풀 리퀘스트에서 동일한 스펙 아티팩트를 리뷰할 수 있는가? 프로세스를 다시 작성하지 않고도 에이전트를 섞을 수 있는가?

락인(Lock-in) – 6개월 후 에디터, 모델, 또는 클라우드 벤더를 변경하면 무엇을 잃게 되는가?

GitHub Spec Kit

GitHub Spec Kit은 스펙 기반 루프를 저장소에 스캐폴딩하고 실행을 이미 사용 중인 코딩 에이전트로 이관하는 오픈소스 CLI 툴킷입니다. specify CLI는 템플릿, 슬래시 커맨드, 관용 폴더 레이아웃을 배치합니다. 일반적인 커맨드는 constitution-specify-clarify-plan-tasks-implement 시퀀스를 따르며, 아키텍처 작업이 시작되기 전에 모호성을 해결하기 위한 명시적인 clarify 단계가 있습니다.

Spec Kit의 결정적 이점은 에이전트 독립성입니다. 공식 문서에서는 Claude Code, GitHub Copilot, Cursor, Gemini CLI, Codex 및 수십 개 이상의 다른 에이전트와 함께 작동하는 도구로 포지셔닝합니다. 스펙을 한 번 마크다운으로 작성하고 코드를 커밋하듯 커밋한 후, 프로세스를 다시 작성하지 않고 실행자를 교체합니다. 이것은 단일 벤더에 베팅하지 않고 SDD를 원하는 팀에게 Spec Kit을 기본 추천 사항으로 만듭니다.

트레이드오프는 현실적입니다. Spec Kit은 constitution, spec, plan, tasks, contracts라는 큰 아티팩트 트리를 생성할 수 있으며, 이는 멀티 세션 기능에는 효과가 있지만 작은 CLI 수정에는 무겁게 느껴질 수 있습니다. Hacker News 스레드는 정기적으로 그 오버헤드를 워터폴 세리머니와 비교합니다. 또한, 스펙, 태스크, 구현이 하나의 가이드된 표면에서 존재하는 완전 통합된 IDE를 원하는 경우 Spec Kit은 약합니다. 그것은 기존 에디터를 대체하는 대신 위에 프로세스를 레이어링합니다.

Spec Kit은 이미 선호하는 AI 코딩 어시스턴트가 있고 그 위에 표준화된 SDD 스캐폴드를 원하는 팀에게 적합합니다. 이는 그린필드 기능, 멀티 에이전트 쇼(팀), 그리고 에디터 락인을 거부하는 사람들에게 특히 강력합니다.

AWS Kiro

Kiro는 VS Code / Code OSS 포크 기반의 AWS 스펙 기반 IDE입니다. Spec Kit이 SDD를 기존 스택으로 가져오는 반면, Kiro는 SDD가 목적-built 환경을 당연시합니다. 프롬프트가 에이전트가 프로덕션 코드를 작성하기 전에 구조화된 아티팩트–통상 EARS 스타일 표기법의 requirements.md, design.md, 그리고 의존성 순서화된 tasks.md–를 생성합니다.

가이드된 경험은 Kiro의 주요 판매 포인트입니다. 요구사항, 설계, 태스크는 코드를 통한 별도의 CLI로 관리되는 파일이 아니라 코드 옆에 있는 일급 UI 객체입니다. Kiro는 또한 구현이 변경될 때 테스트, 문서 또는 관련 아티팩트를 업데이트할 수 있는 이벤트 기반 자동화인 Agent Hooks를 제공합니다. 이 양방향 루프는 Spec Kit이 기본적으로 제공하지 않는 것입니다 – Spec Kit 스펙은 인간이 업데이트할 때까지 정적인 상태로 남아 있습니다.

비용은 이식성 대신 통합 깊이를 거래하는 것입니다. Kiro는 자신의 에디터 내에서 실행되며, AWS Bedrock 기반 모델을 사용하고, 등급 기반 요금제와 크레딧 기반 가격 모델을 통해 청구합니다. 이미 AWS 인프라에 있는 엔터프라이즈 팀은 종종 이를 용인합니다. 솔로 개발자와 멀티 에디터 팀은 그렇지 않을 수 있습니다. Kiro는 또한 더 새로운 IDE의 전형적인 거친 모서리를 가지고 있습니다 – 확장성 호환성, 워크플로우 놀라움, 그리고 “정말 또 다른 에디터가 필요한가?“라는 질문.

Kiro는 가장 가이드된 SDD 경험을 원하고 스펙 네이티브 IDE 채택에 익숙한 개발자에게 적합합니다. 엔터프라이즈 팀, AWS 중심 환경, 그리고 Amazon Q Developer에서 이주하여 수동으로 툴체인을 조립하지 않고 스펙 규율을 원하는 사람들에게 강력한 옵션입니다. 오늘 표준 VS Code에서 생활하며 현재 세업을 사랑하는 경우, Kiro는 Spec Kit보다 더 큰 전환을 요구합니다.

Claude Code 커스텀 커맨드와 스킬

Claude Code는 Spec Kit이나 Kiro처럼 단일 공식 SDD 제품을 제공하지 않습니다. 이 도구 자체가 처음이라면, 세업, 권한, 로컬 백엔드를 위해 Claude Code 설치 및 구성 가이드를 시작점으로 하세요. SDD 패턴 자체는 개발자가 유지보수하는 커스텀 커맨드, 스킬, 그리고 저장소 로컬 마크다운 템플릿 안에 존재합니다. Anthropic은 오래된 .claude/commands/*.md 파일들을 스킬 메커니즘으로 흡수했으므로, 지속 가능한 패턴은 필요 시 로드되는 specify-plan-implement 체크리스트를 정의하는 SKILL.md(또는 equivalents)입니다.

이 접근법은 가장 가볍고 해킹(수정)이 쉽습니다. Kiro 스타일 3파일 레이아웃을 이식하거나, 슬래시 커맨드로 Spec Kit 단계를 미러링하거나, 하나의 저장소에 맞는 최소 워크플로우를 발명할 수 있습니다. Claude Code는 항상 켜진 프로젝트 컨텍트를 위해 CLAUDE.md를 읽고, 태스크가 일치할 때 스킬을 가져옵니다. 이 점진적 정보 노출은 모든 프롬프트에 완전한 constitution을 로드하지 않고도 세션을 집중시켜 줍니다.

단점은 규율입니다. clarify 또는 리뷰 게이트를 통해 강제하는 것은 그 게이트를 스스로 구축할 때만 존재합니다. “Claude Code 내 스펙 기반 개발"에 대한 Reddit과 Hacker News 스레드는 누군가의 스킬을 복사하고 한 번 실행한 후, 스킬이 느리게 느껴지면 비구조화된 프롬프팅으로 돌아가는 개발자로 가득 차 있습니다. Claude Code SDD는 스킬을 코드처럼–버전 관리, 리뷰, 유지보수–일회성 프롬프트 다운로드가 아닌 것으로 대할 때 작동합니다.

진지한 구현을 위해 Claude Skills and SKILL.md for Developers를 읽고, 명시적인 리뷰 체킹포인트를 가진 스킬로 단계를 인코딩하세요. Claude Code SDD는 이미 Claude Code에 거주하고, 최대 유연성을 원하며, 워크플로우를 스스로 유지보수할 경우 올바른 선택입니다. 특히 리뷰 게이트 단계의 경우, Claude Code 서브에이전트가 태스크를 병합하기 전에 생성된 코드에 독립적이고 격리된 컨텍스트의 리뷰 패스를 실행할 수 있습니다 – 이는 Kiro의 Agent Hooks가 네이티브로 제공하는 검증 역할의 경량 대체재입니다.

Superpowers: DIY 스킬 스택의 패키지화된 버전

그 스킬 스택을 손으로 만드는 것이 위 표가 경고하는 바로 그 규율 문제처럼 들린다면, Superpowers를 눈여겨볼 가치가 있습니다. 이는 오픈소스 스킬 패키지–브레인스토밍, writing-plans, subagent-driven-development, test-driven-development, requesting-code-review, 그리고 몇몇 지원 스킬–이며, 처음부터 작성하는 것이 아니라 설치 가능한 플러그인으로 배포됩니다. 이는 “품질이 완전히 저자 규일에 의존한다"는 한계를 직접적으로 표적으로 삼습니다: 스킬은 자동으로 트리거되고, 에이전트가 건너뛸 수 있는 옵션적 제안이 아니라 필수 워크플로우로 의도됩니다.

그가 강제하는 워크플로우는 요구사항에서 코드로의 스펙 기반 개발 워크플로우에서 다루는 5단계 루프와 밀접하게 매핑됩니다: 브레인스토밍은 거친 아이디어를 리뷰된 설계 문서로 정제하고, writing-plans는 이를 작은 검증 가능한 태스크로 나누고, subagent-driven-development는 태스크마다 새로운 서브에이전트를 2단계 리뷰와 함께 디스패치하며, test-driven-development은 아무것도 완료로 간주되기 전에 엄격한 red-green-refactor를 강제합니다. 그 마지막 부분은 대부분의 Claude Code SDD 스킬이 신경 쓸 것보다 더 엄격합니다 – Superpowers는 실패하는 테스트가 존재하기 전에 작성된 코드를 명시적으로 삭제합니다.

스스로 작성하는 저장소 로컬 스킬과 달리, Superpowers는 Claude Code 전용이 아닙니다. 이는 Claude Code, Cursor, Codex, Gemini CLI, GitHub Copilot CLI, Devin, Factory Droid 및 기타 몇몇 에이전트를 위한 플러그인 매니페스트를 제공하므로, 하나의 .claude/skills/ 폴더에 머무는 대신 같은 방법론이 하네스를 가로지릅니다. 이는 자신의 Claude Code 스킬을 작성하는 것과 Kiro와 같은 더 무겁고 IDE 특정적인 도구를 채택하는 것 사이의 중간 지점입니다: 에디터를 포기하거나 단일 벤더의 스펙 형식에 전념하지 않으면서도 의견 주도적이고 강제된 루프를 얻게 됩니다.

Superpowers는 원칙적으로 Claude Code 스킬 접근법을 좋아하지만, 리뷰 게이트를 강제하는 것이 없어 비구조화된 프롬프팅으로 계속 회귀하는 개발자에게 적합합니다. 이미 스택에 맞게 튜닝된 프로젝트 특정 SDD 스킬이 있다면 더 약한 적합성을 보입니다 – 그 경우 작은 양의 커스터마이징을 더 큰 양의 강제된 세리머니와 교환하게 됩니다.

BMAD, OpenSpec, 그리고 다른 워크플로우

모든 팀이 Spec Kit 아티팩트 트리나 Kiro IDE를 원하지는 않습니다. 2026년 비교에서 지속적으로 등장하는 두 가지 대안이 있습니다.

OpenSpec(Fission AI)는 Spec Kit보다 적은 생성 파일로 변경 사항 중심의 접근법을 취합니다. 커뮤니티 벤치마크는 유사한 태스크에 대해 실질적으로 더 낮은 토큰 사용량을 보고하지만, upfront 구조가 적다는 대가로 그렇습니다. OpenSpec는 기존 코드베이스를 수정하고 800라인의 계획 단계 없이 리뷰 가능한 스펙을 원할 때 이기는 경향이 있습니다. 이는 IDE 통합에서 Kiro와 경쟁하기보다 이식성에서 Spec Kit과 경쟁합니다. 설치 단계, explore-propose-apply-archive 루프, 그리고 Reddit에서 가장 많이 나타나는 함정에 대해 OpenSpec quickstart를 참조하세요.

BMAD-METHOD(커뮤니티)는 반대 방향으로 밀어냅니다 – 제품 오너, 아키텍트, 개발자, 리뷰어 페르소나를 시뮬레이션하는 멀티 에이전트, 역할 기반 워크플로우. BMAD는 명시적 역할 분리가 도움이 되는 대형 그린필드 노력에서 강력할 수 있습니다. 또한 무겁습니다. 팀은 일반적으로 세리머니가 이미 급격한 조정 고통이 있을 때만 효과가 있다고 보고합니다.

Tessl은 스펙을 생성된 코드의 문자적 소스로 취급하며, 출력을 유도된 것으로 표시하고 수동 편집을 억제합니다. 이는 주류 툴 중 가장 강한 “스펙-즉-소스” 입장입니다, 하지만 Tessl은 여전히 베타이며 그룹에서 가장 높은 제품 락인을 가지고 있습니다.

Spec Kitty 및 기타 커뮤니티 스캐폴드는 OpenSpec와 Spec Kit 사이에서 무게면에서 위치합니다. 완전한 GitHub 툴체인을 채택하지 않고 템플릿을 원한다면 주목할 가치가 있습니다.

그들 모두의 패턴은 동일합니다. 모호성이 비쌀 때 더 많은 프로세스가 도움이 됩니다. 피드백 속도가 정렬보다 중요할 때 더 많은 프로세스가 해를 끼칩니다. 툴의 무게를 하이프가 아닌 태스크 크기에 맞춰야 합니다.

어떤 SDD 세업을 사용해야 할까?

보편적인 승자는 없습니다. 올바른 세업은你是谁인, 무엇을 구축하는지, 그리고 실제로 얼마나 많은 구조를 유지할 것인지를 결정합니다.

솔로 개발자, 기존 코드베이스, 작은 기능. Claude Code 스킬 또는 OpenSpec로 시작하세요. 짧은 요구사항 블록, 최소 태스크 목록, 그리고 하나의 리뷰 체킹포인트를 작성하세요. 50라인의 변경을 위해 완전한 Spec Kit 트리를 설치하지 마세요.

Claude Code 스킬 접근법을 원하지만 자신의 리뷰 게이트를 계속 건너뛰는 경우. 커스텀 스킬을 처음부터 작성하는 대신 Superpowers를 설치하세요. 프로젝트 특정 튜닝을 포기하는 대가로, 그날 당신의 규일에 의존하지 않는 강제된 brainstorm-plan-implement-review 루프를 얻게 됩니다.

솔로 개발자, 그린필드 기능, 여러 세션. Spec Kit 또는 잘 유지보수된 Claude Code SDD 스킬. IDE의 손을 잡아주는 것보다 지속 가능한 아티팩트가 더 필요합니다.

소형 팀, 혼합 에디터. Spec Kit. Git에 있는 평범한 마크다운 스펙, 풀 리퀘스트에서 리뷰되고, 각 개발자가 선호하는 에이전트에 의해 실행됩니다.

엔터프라이즈 팀, AWS 네이티브, 컴플라이언스 압력. Kiro. 가이드된 아티팩트, 요구사항 추적 가능성, 그리고 문서와 테스트가 구현에 더 가까이 있도록 하는 훅.

규제 환경. Kiro 또는 Spec Kit 및 자체 검증 체크리스트 – 명시적으로 컴플라이언스 게이트를 인코딩하지 않는 한 Claude Code 스킬만으로는 안 됩니다. 툴링은 감사 추적(Audit trails)을 대체하지 않습니다. 이를 생성하기 더 쉽게 할 뿐입니다.

기존 코드베이스, 브라운필드 변경. OpenSpec 또는 경량 Claude Code 워크플로우. 모든 버그 픽스에 대한 완전한 Spec Kit 세리머니는 워터폴처럼 느껴질 것입니다. 더 무거운 구조를 가로질러 기능을 위해 예약하세요.

그린필드 제품, 여러 에이전트. Spec Kit. Copilot, Claude Code, Cursor가 모두 동일한 저장소에 접할 수 있을 때, IDE의 광택보다 이식성이 더 중요합니다.

멀티 에이전트 오케스트레이션을 실험하는 팀은 에이전트 간 역할 분할 패턴을 위해 Oh My OpenCode Agents를 살펴보아야 합니다 – 이는 SDD 아티팩트의 대체재가 아닌 보완재입니다. 팀이 IDE 통합 에이전트 대신 터미널 우선 에이전트를 실행한다면, OpenCode CLI 실무 가이드는 구현 전 계획 규율의 더 가벼운, 프롬프트 수준의 버전을 보여줍니다 – 이는 완전한 Spec Kit 트리가 태스크가 정당화하는 것보다 더 많은 세리머니일 때 유용합니다.

실용적 결정 테이블

실제로 성공을 결정하는 것

도구 선택은 아티팩트 품질보다 덜 중요합니다. 모호한 수용 기준이 있는 Kiro 요구사항 파일은 느슨한 Claude Code 프롬프트와 동일한 드리프트(drift)를 생성합니다. 50개의 중복된 태스크를 나열하는 Spec Kit 계획은 어떤 에이전트가 구현하든 워터폴처럼 느껴질 것입니다.

모든 세업에서 이동하는 실무는 지루하지만 효과적입니다. 스펙을 한 번에 리뷰할 수 있을 정도로 작게 유지하세요. 비목표(Non-goals)를 명시적으로 작성하세요. 인간이 읽을 수 있는 디프로 태스크를 분할하세요. 병합 전에 수용 기준에 대해 검증하세요. 구현이 더 나은 경로를 발견하면 스펙을 업데이트하세요.

특정 기능에 대해 SDD와 비구조화된 프롬프팅 사이에서 여전히 선택 중이라면, Spec-Driven Development vs Vibe Coding을 읽어보세요. 이 글의 도구 비교는 기능이 스펙을 받을 가치가 있다고 결정된 후에만 의미가 있습니다.

나쁜 스펙은 모든 에이전트를 나쁘게 만듭니다. 좋은 스펙은 툴을 가로지릅니다.

결론

GitHub Spec Kit, Kiro, 그리고 Claude Code 워크플로우는 세션에 걸쳐 AI 에이전트를 어떻게 정렬 상태로 유지할 것인가라는 동일한 질문에 대한 세 가지 답이며, 이식성과 통합에 대한 다른 베팅을 하고 있습니다. Spec Kit은 저장소에서 에이전트 비공식적(markdown)에 최적화됩니다. Kiro는 AWS 기반 에이전트를 가진 가이드된 스펙 네이티브 IDE에 최적화됩니다. Claude Code 스킬은 해킹 가능하고 경량인 워크플로우에 최적화되며, 이는 당신이 유지보수할 때만 성공합니다.

해당 기능에 대한 모호성을 제거하는 가장 얕은 세업을 선택하세요. 블로그 포스트가叫你 하니까가 아니라, 조정 고통이 나타날 때 구조를 추가하세요. 2026년에 SDD에서 가치를 얻는 개발자들은 가장 정교한 툴체인을 가진 사람들이 아닙니다. 그들은 구현할 가치가 있는 스펙을 작성한 후, 선택한 도구가 그것에 대해 실행하도록 두는 사람들입니다.

유용한 링크

• GitHub Spec Kit 문서 – 공식 Spec Kit 워크플로우 참조
• Superpowers Quickstart: Install, Workflow, and Tryout – Claude Code, Cursor, Codex 및 다른 에이전트에서 브레인스토밍부터 TDD까지 방법론을 강제하는 오픈소스 스킬 패키지
• Martin Fowler on SDD tools – Kiro, Spec Kit, Tessl 분석