GitHub Spec Kit 대 Kiro 대 Claude Code SDD 워크플로우

2026년의 개발자들은 Spec-Driven Development(규격 기반 개발) 설정을 비교할 때, 보통 어떤 모델이 가장 똑똑한지를 묻지 않습니다. 그들은 어떤 워크플로우가 AI 에이전트를 의식적인 절차(ceremony)에 빠뜨리지 않으면서도 정렬(aligned) 상태를 유지해 줄 수 있는지를 묻습니다.

GitHub Spec Kit, AWS Kiro, 그리고 Claude Code 커스텀 워크플로우는 모두 동일한 광범위한 아이디어인 요구사항, 설계, 작업, 구현, 검증 단계를 구현하지만, 이동성(portability), 통합 깊이(integration depth), 그리고 강제하는 프로세스의 양이라는 측면에서 서로 다른 trade-off를 보입니다.

개념을 먼저 이해하고 싶다면 규격 기반 개발이란 무엇인가?과 도구 중립적인 규격 기반 개발 워크플로우 가이드를 앱 아키텍처) 문서 클러스터에서 읽어보세요. 이 비교 자료는 어시스턴트 리뷰 및 워크플로우 가이드와 함께 AI 개발 도구 허브에 위치해 있습니다. 여기서는 Hacker News와 Reddit 스타일의 포럼에서 개발자들이 가장 많이 논쟁하는 세 가지 설정과, 그 주변을 도는 가볍거나 무거운 대안들을 다룹니다.

SDD는 도구 범주가 되고 있다

Spec-Driven Development는 2025년 말 무렵 논문 상의 연습이 아닌 실제 도구로 자리 잡기 시작했습니다. 이제 주요 AI 코딩 벤더들은 모두某种 버전의 ‘규격 정의-계획-구현(specify-plan-implement)‘을 제공하며, 독립형 도구들은 이 루프 주위에 얼마나 많은 구조를 더하는지를 놓고 경쟁하고 있습니다.

중요한 비교는 “어떤 도구가 우세한가"가 아닙니다. 프로세스의 깊이 대 이동성입니다. Kiro는 통합되어 있습니다. Spec Kit는 이동성이 뛰어납니다. Claude Code 워크플로우는 해킹이 가능합니다. 나쁜 규격은 어떤 래퍼(wrapper)를 선택하든 모든 에이전트를 더 나쁘게 만듭니다. 좋은 규격은 도구 사이를 자유롭게 이동합니다.

SDD 설정 비교 방법

도구를 선택하기 전에 무엇을 최적화할지 명명해야 합니다. 팀의 규모, 코드베이스의 연수, 필요한 리뷰의 양에 따라 동일한 기능이 하나의 설정에서는 effortless(수월함)로 느껴지고, 다른 설정에서는 관료적(bureaucratic)으로 느껴질 수 있습니다.

이동성 (Portability) – 규격이 리포지토리의 일반 markdown 파일로 존재하며 다음 분기에 선호하는 에이전트와 함께 작동할 수 있는가? 아니면 하나의 IDE, 하나의 클라우드, 또는 하나의 독점 형식에 묶여 있는가?

설정 마찰 (Setup friction) – “SDD를 시도해보고 싶다"는 생각에서 작동하는 specify-plan-tasks 루프로 이어지는 데 얼마나 걸리는가? CLI 스캐폴딩, IDE 설치, 또는 자체 슬래시 커맨드 제작은 모두 다른 활성화 에너지를 필요로 합니다.

규격 품질 (Spec quality) – 도구가 정확한 요구사항과 수용 기준(acceptance criteria)을 작성하는 데 도움을 주는지, 아니면 긴 문서만 생성하는지? 구조는 유용합니다. 양(volume)은 그렇지 않습니다.

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

리뷰 체크포인트 (Review checkpoints) – 규격 정의, 계획, 작업, 구현 사이에 자연스러운 인간의 게이트가 있는가? 리뷰 없는 SDD는 단지 더 느린 vibe coding(분위기 코딩)일 뿐입니다.

리포지토리 기반화 (Repository grounding) – 워크플로우가 프로젝트 관례, 의사결정 기록, ADR, AGENTS.md, 그리고 기존 코드를 계획하기 전에 읽어들이는가? 기반화되지 않은 에이전트는 이전 선택 뒤에 있는 검토된 의도를 전혀 보지 못하기 때문에 아키텍처를 재발명합니다.

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

종속성 (Lock-in) – 6개월 후 에디터, 모델, 또는 클라우드 벤더를 변경할 때 무엇을 잃게 되는가?

GitHub Spec Kit

GitHub Spec Kit은 규격 기반 루프를 리포지토리로 스캐폴딩하고 실행을 이미 사용하는 코딩 에이전트에 맡기는 오픈 소스 CLI 툴킷입니다. specify CLI는 템플릿, 슬래시 커맨드, 그리고 관례적인 폴더 레이아웃을 제공합니다. 일반적인 명령은 헌장-규격 정의-명확화-계획-작업-구현 시퀀스를 따르며, 아키텍처 작업이 시작되기 전에 모호성을 해결하기 위해 명시적인 명확화(clarify) 단계를 포함합니다.

Spec Kit의 정의적인 장점은 에이전트 독립성입니다. 공식 문서는 이를 Claude Code, GitHub Copilot, Cursor, Gemini CLI, Codex, 그리고 수십 가지 다른 에이전트와 함께 작동하는 툴링으로 포지셔닝합니다. 한 번 markdown으로 규격을 작성하고 코드를 커밋하듯 관리하면, 프로세스를 재작성하지 않고 실행자를 교체할 수 있습니다. 이는 단일 벤더에 베팅하지 않고 SDD를 원하는 팀을 위해 Spec Kit이 기본 권장 사항이 되는 이유입니다.

Trade-off는 현실적입니다. Spec Kit은 헌장, 규격, 계획, 작업, 계약 등 큰 아티팩트 트리를 생성할 수 있으며, 이는 다중 세션 기능에서는 효과를 발휘하지만 작은 CLI 변경에는 무겁게 느껴집니다. Hacker News 스레드에서는 정기적으로 그 오버헤드를 워터폴(waterfall) 의식과 비교합니다. Spec Kit은 규격, 작업, 구현이 하나의 가이드된 표면에서 살 수 있는 완전히 통합된 IDE를 원한다면 약합니다. 이는 기존 에디터 위에 프로세스를 레이어링할 뿐, 이를 대체하지는 않습니다.

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

AWS Kiro

Kiro는 AWS의 규격 기반 IDE로, VS Code / Code OSS 포크를 기반으로 구축되었습니다. Spec Kit이 SDD를 기존 스택에 가져오는 반면, Kiro는 SDD가 목적 지향적인 환경을 필요로 한다고 가정합니다. 프롬프트는 구조화된 아티팩트(일반적으로 EARS 스타일 표기법의 requirements.md, design.md, 그리고 의존성 시퀀싱된 tasks.md)를 생성한 후 에이전트가 프로덕션 코드를 작성합니다.

가이드된 경험은 Kiro의 주요 판매 포인트입니다. 요구사항, 설계, 작업은 파일이 아닌 코드 옆의 일급 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 커스텀 커맨드 및 Skills

Claude Code는 Spec Kit이나 Kiro처럼 단일 공식 SDD 제품을 출시하지 않습니다. 도구 자체에 익숙하지 않다면 설정, 권한, 로컬 백엔드를 위해 Claude Code 설치 및 설정 가이드로 시작하세요. SDD 패턴 자체는 개발자가 유지하는 커스텀 커맨드, Skills, 그리고 리포지토리 로컬 markdown 템플릿에 존재합니다. Anthropic은 이전의 .claude/commands/*.md 파일들을 Skills 메커니즘으로 통합했으므로, 내구성 있는 패턴은 SKILL.md(또는 동등물)로 specify-plan-implement 체크리스트를 정의하고按需(on demand) 로드하는 것입니다.

이 접근법은 가장 가볍고 해킹이 가능합니다. Kiro 스타일의 3 파일 레이아웃을 이식하거나, 슬래시 커맨드로 Spec Kit 단계를 거울화하거나, 하나의 리포지토리에 맞는 최소 워크플로우를 발명할 수 있습니다. Claude Code는 항상 켜진 프로젝트 컨텍스트를 위해 CLAUDE.md를 읽으며, 작업이 매칭될 때 skills를 가져옵니다. 이러한 점진적 공개(progressive disclosure)는 모든 프롬프트에서 전체 헌장을 로드하지 않고도 세션을 집중시킵니다.

단점은 규율입니다. 스스로 그 게이트를 구축하지 않는 한, 명확화나 리뷰 게이트를 통해 강제로 통과시키는 것은 아무것도 없습니다. “Claude Code 내의 규격 기반 개발"에 대한 Reddit과 Hacker News 스레드는 남의 skill을 복사하고 한 번 실행한 후, skill이 느리게 느껴지자 구조 없는 프롬프팅으로 돌아간 개발자들로 가득 차 있습니다. Claude Code SDD는 skills를 코드처럼 – 버전 관리되고, 검토되며, 유지되는 – 취급할 때 작동합니다. 일회성 프롬프트 다운로드처럼 취급해서는 안 됩니다.

진지한 구현을 위해 Claude Skills 및 개발자를 위한 SKILL.md)를 읽고, 명시적인 리뷰 체크포인트를 가진 skills로 단계를 인코딩하세요. Claude Code SDD는 이미 Claude Code에서 살고 있으며, 최대 유연성을 원하고 워크플로우를 스스로 유지할 의향이 있을 때 올바른 선택입니다.

BMAD, OpenSpec 및 기타 워크플로우

모든 팀이 Spec Kit 아티팩트 트리가 Kiro IDE를 원하는 것은 아닙니다. 2026년 비교에서 두 가지 대안이 끊임없이 등장합니다.

OpenSpec (Fission AI)은 Spec Kit보다 적은 생성 파일로 변경 중심(change-centric) 접근을 취합니다. 커뮤니티 벤치마크는 비교 가능한 작업에 대해 materially lower(본질적으로 낮은) 토큰 사용량을 보고하며, 그 비용은 사전 구조가 적다는 것입니다. OpenSpec은 기존 코드베이스를 수정하고 800라인 계획 단계 없이 리뷰 가능한 규격을 원할 때 경향이 승리합니다. 이는 Kiro의 IDE 통합보다는 Spec Kit과의 이동성에서 경쟁합니다.

BMAD-METHOD (커뮤니티)는 반대 방향으로 나아가는 – 프로덕트 오너, 아키텍트, 개발자, 리뷰어 페르소나를 시뮬레이션하는 다중 에이전트, 역할 기반 워크플로우입니다. BMAD는 명시적인 역할 분리가 도움이 되는 대규모 그린필드 노력에서 강력할 수 있습니다. 또한 무겁습니다. 팀들은 정기적으로 그 의식(ceremony)이 조정 통증이 이미 급박할 때만 보답한다고 보고합니다.

Tessl은 규격을 생성된 코드의 문자 그대로의 소스로 취급하며, 출력을 파생된 것으로 표시하고 수동 편집을 억제합니다. 이는 주요 도구 중 가장 강한 “규격-즉-소스” 입장이나, Tessl은 여전히 베타이며 그룹 중 가장 높은 제품 종속성을 가지고 있습니다.

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

그들 모두를 가로지르는 패턴은 동일합니다. 모호성이 비쌀 때 더 많은 프로세스가 도움이 됩니다. 정렬보다 피드백 속도가 더 중요할 때 더 많은 프로세스가 해를 끼칩니다. 도구 무게를 과세(hype)가 아닌 작업 크기에 맞추세요.

어떤 SDD 설정을 사용해야 하나요?

보편적인 승자는 없습니다. 올바른 설정은 당신이 누구인지, 무엇을 구축하는지, 그리고 실제로 얼마나 많은 구조를 유지할 것인지에 달려 있습니다.

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

솔로 개발자, 그린필드 기능, 다중 세션. Spec Kit 또는 잘 유지되는 Claude Code SDD skill. 에디터의 손잡이(hand-holding)보다 내구성 있는 아티팩트가 필요합니다.

소규모 팀, 혼합 에디터. Spec Kit. Git 내 plain markdown 규격, 풀 리퀘스트에서 검토, 각 개발자가 선호하는 에이전트에 의해 실행됨.

엔터프라이즈 팀, AWS 네이티브, 규정 준수 압력. Kiro. 가이드된 아티팩트, 요구사항 추적성, 그리고 구현에 문서와 테스트를 더 가깝게 유지하는 hooks.

규제 환경. Kiro 또는 Spec Kit plus 자체 검증 체크리스트 – 명시적으로 규정 준수 게이트를 인코딩하지 않는 한 Claude Code skills 단독으로 নয়. 툴링은 감사 추적(audit trails)을 대체하지 않습니다. 단지 생성을 더 쉽게 만듭니다.

기존 코드베이스, 브라운필드 변경. OpenSpec 또는 경량 Claude Code 워크플로우. 모든 버그픽스에 전체 Spec Kit 의식은 워터폴처럼 느껴질 것입니다. 교차 기능(cross-cutting features)에 더 무거운 구조를 예약하세요.

그린필드 제품, 많은 에이전트. Spec Kit. Copilot, Claude Code, Cursor가 모두 동일한 리포지토리에 접근할 때 IDE 광택보다 이동성이 더 중요합니다.

다중 에이전트 오케스트레이션을 실험하는 팀은 또한 Oh My OpenCode Agents)를 확인해야 합니다. 이는 에이전트 간 역할 분할 패턴을 제공하며, SDD 아티팩트를 대체하는 것이 아니라 보완합니다.

실용적 결정 테이블

실제 성공을 결정하는 것

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

모든 설정을 가로지르는 관행은 지루하지만 효과적입니다. 한 번의 앉은 자리에서 리뷰할 수 있을 만큼 규격을 작게 유지하세요. 비목표(non-goals)를 명시적으로 작성하세요. 작업을 인간이 읽을 수 있는 diff로 나누세요. 병합 전에 수용 기준에 대해 검증하세요. 구현이 더 나은 경로를 발견할 때 규격을 업데이트하세요.

주어진 기능에 대해 SDD와 구조 없는 프롬프팅 사이에서 여전히 선택 중이라면 규격 기반 개발 vs Vibe Coding)을 읽어보세요. 이 기사에서의 도구 비교는 기능이 규격을 받을 가치가 있다고 결정한 후에만 의미가 있습니다.

나쁜 규격은 모든 에이전트를 더 나쁘게 만듭니다. 좋은 규격은 도구 사이를 이동합니다.

결론

GitHub Spec Kit, Kiro, 그리고 Claude Code 워크플로우는 동일한 질문에 대한 세 가지 답변입니다 – 세션 간에 AI 에이전트를 어떻게 정렬된 상태로 유지할 것인가 – 이동성 대 통합에 대한 다른 베팅과 함께. Spec Kit은 리포지토리 내 에이전트 중립적 markdown을 최적화합니다. Kiro는 AWS 기반 에이전트를 갖춘 가이드된 규격 네이티브 IDE를 최적화합니다. Claude Code skills는 유지될 때만 성공하는 해킹 가능한, 경량 워크플로우를 최적화합니다.

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

유용한 링크

• GitHub Spec Kit 문서 – 공식 Spec Kit 워크플로우 참조
• Martin Fowler의 SDD 도구 분석 – Kiro, Spec Kit, Tessl에 대한 분석