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

2026년 현재 스펙 기반 개발(Spec-Driven Development, SDD) 환경을 비교하는 개발자들은 보통 가장 지능적인 모델이 무엇인지 묻지 않습니다. 그들은 어떤 워크플로우가 AI 에이전트를 의식적인 예식(ceremony) 속에 빠뜨리지 않으면서도 정렬(alignment) 상태를 유지할 수 있는지 묻습니다.

GitHub Spec Kit, AWS Kiro, 그리고 Claude Code 커스텀 워크플로우는 모두 동일한 폭넓은 아이디어 – 요구사항, 설계, 태스크, 구현, 검증 – 를 구현하지만, 이식성, 통합 깊이, 그리고 강제하는 프로세스의 양에서 트레이드오프를 가집니다.

개념부터 먼저 파악해야 한다면 스펙 기반 개발이란 무엇인가?과 도구 중립적인 스펙 기반 개발 워크플로우 가이드를 앱 아키텍처 문서 클러스터에서 읽어보세요. 본 비교는 AI 개발자 도구 허브 내 어시스턴트 리뷰와 워크플로우 가이드와 함께 배치됩니다.

SDD는 도구 카테고리가 되고 있다

스펙 기반 개발은 2025년 후반쯤 종이상의 연습이 아닌 것이 되었습니다. 모든 주요 AI 코딩 벤더가 이제 specify-plan-implement(요구사항-계획-구현)의 어떤 버전은 제공하며, 스탠드얼론 도구들의 목록도 그 루프 주위에 얼마나 많은 구조를 추가하는지를 두고 경쟁하고 있습니다.

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

SDD 설정 비교하기

도구를 선택하기 전에, 무엇에 최적화를 원하는지 이름을 붙여야 합니다. 팀 규모, 코드베이스의 나이, 그리고 필요한 리뷰 양에 따라 동일한 기능이 한 설정에서는 노력이 없이 느껴지고 다른 설정에서는 관료적으로 느껴질 수 있습니다.

이식성 – 스펙이 당신의 리포지토리에 일반 마크다운으로 존재하고 다음 분기에 선호하는 에이전트와 함께 작동할 수 있습니까? 아니면 하나의 IDE, 하나의 클라우드, 또는 하나의 프로프리etary 포맷에 묶여 있습니까?

설립 마찰 – “SDD를 사용해 보고 싶다"에서 작동하는 specify-plan-tasks 루프까지 얼마나 걸립니까? CLI 스캐폴딩, IDE 설치, 또는 자기만의 슬래시 커맨드를 만드는 것은 모두 다른 활성화 에너지를 가집니다.

스펙 품질 – 도구가 정확한 요구사항과 수용 기준을 작성하는 데 도움을 주나요, 아니면 단순히 긴 문서를 생성하나요? 구조는 유용합니다. 볼륨은 그렇지 않습니다.

태스크 실행 – 도구가 일을 리뷰 가능한 슬라이스로 어떻게 나누습니까? 태스크가 병렬로 실행될 수 있습니까? 50개 항목의 태스크 폭발을 억제합니까?

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

리포지토리 기반화 – 워크플로우는 계획하기 전에 프로젝트 컨벤션, 결정 기록, ADR, AGENTS.md, 기존 코드를 읽습니까? 기반화 없이 에이전트는 이전에 검토된 의도를 보지 못했기 때문에 아키텍처를 재발명합니다.

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

락인 – 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 환경을 xứng하다고 가정합니다. 프롬프트가 에이전트가 프로덕션 코드를 작성하기 전에 구조화된 아티팩트 – 일반적으로 EARS 스타일 표기법의 requirements.md, design.md, 의존성 순서화된 tasks.md – 를 생성합니다.

가이드된 경험은 Kiro의 주요 판매 포인트입니다. 요구사항, 설계, 태스크는 별도의 CLI를 통해 관리하는 파일이 아니라 코드 옆에 있는 1급 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(또는 동등물)입니다.

이 접근법은 가장 가볍고 해킹하기 가장 쉽습니다. Kiro 스타일 3파일 레이아웃을 이식하거나, 슬래ش 커맨드로 Spec Kit 단계를 복제하거나, 하나의 리포지토리에 맞는 최소 워크플로울 발명할 수 있습니다. Claude Code는 항상 켜진 프로젝트 컨텍트를 위해 CLAUDE.md를 읽고 태스크가 일치할 때 스킬을 가져옵니다. 그 점진적 공개는 모든 프롬프트마다 전체 constitution을 로드하지 않고 세션을 초점에 맞추어 둡니다.

단점은 규율입니다. 당신이 그 게이트를 스스로 만들지 않는 한, clarify나 리뷰 게이트를 강제하는 것이 없습니다. “Claude Code 내부의 스펙 기반 개발"에 대한 Reddit과 Hacker News 스레드는 다른 사람의 스킬을 복사해서 한 번 실행하고 스킬이 느리게 느껴졌을 때 구조 없는 프롬프팅으로 돌아간 개발자들로 가득 차 있습니다. Claude Code SDD는 스킬을 코드처럼 – 버전 관리, 리뷰, 유지보수 – 일회성 프롬프트 다운로드가 아닌 것으로 다룰 때 작동합니다.

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

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

그 스킬 스택을 손으로 만드는 것이 위에서 표가 경고하는 규율 문제처럼 들린다면, Superpowers를 살펴볼 가치가 있습니다. 이는 오픈 소스 스킬 패키지 – 브레인스토밍, 계획 작성, 서브에이전트 기반 개발, 테스트 주도 개발, 코드 리뷰 요청, 및 몇 개의 지원 스킬 – 입니다. 이것은 당신이 처음부터 작성하는 것이 아니라 설치 가능한 플러그인으로서 배포됩니다. 이는 “품질은 전적으로 작성자 규율에 의존"이라는 한계를 직접적으로 표적으로 삼습니다: 스킬은 자동으로 트리거되며, 에이전트가 건너뛸 수 있는 선택적 제안이 아닌 필수 워크플로우로 의도됩니다.

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

스스로 작성하는 레포지토리 로컬 스킬과 달리, Superpowers는 Claude Code 전용이 아닙니다. 그것은 Claude Code, Cursor, Codex, Gemini CLI, GitHub Copilot CLI, Devin, Factory Droid 및 몇몇 다른 에이전트를 위한 플러그인 매니페스트를 출시하므로, 하나의 .claude/skills/ 폴더에 살기보다 같은 방법론이 하드웨어를 가로질러 당신을 따라갑니다. 이것은 Kiro와 같은 더 무겁고 IDE 특화 도구를 채택하는 것보다 당신 자신의 Claude Code 스킬을 만드는 것과 사이의 중간 지점입니다: 당신은 에디터를 포기하거나 단일 벤더의 스펙 포맷에 커밋하지 않고도 의견이 확고하고 강제된 루프를 얻습니다.

Superpowers는 원칙적으로는 Claude Code 스킬 접근법을 좋아하지만, 리뷰 게이트를 강제하는 것이 없기 때문에 구조 없는 프롬프팅으로 계속해서 미끄러져 돌아오는 개발자에게 적합합니다. 이미 자신의 스택에 조준된 프로젝트 특화 SDD 스킬을 가지고 있다면 더 약한 적합성입니다 – 그 경우 당신은 강제된 예식의 더 큰 양을 위해 커스터마이징의 작은 양을 거래하고 있습니다.

BMAD, OpenSpec 및 기타 워크플로우

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

OpenSpec (Fission AI)는 Spec Kit보다 적은 생성 파일로 변경 중심 접근법을 취합니다. 커뮤니티 벤치마크는 상당한 토큰 사용량 절감을 보고하지만, 비용은 사전 구조의 감소입니다. OpenSpec는 기존 코드베이스를 수정하고 800줄 계획 단계 없이 리뷰 가능한 스펙을 원할 때 이기게 경향이 있습니다. 그것은 IDE 통합에 있어 Kiro와보다 이식성에 있어 Spec Kit와 더 경쟁합니다. 설치 단계, explore-propose-apply-archive 루프, 그리고 Reddit에서 가장 자주 나타나는 함정에 대해서는 OpenSpec 퀵스타트를 참조하세요.

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

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

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

**gstack**는 스펙 레이어를 한 단계 넘어갑니다: 그것은 코딩 에이전트를 전체 가상 엔지니어링 팀 – 프로덕트 리뷰, 아키텍처 및 설계 리뷰, 브라우저 QA, 보안 감사, 그리고 ship-deploy 릴리스 체인 – 으로 감싸므로, 스펙은 골격이 아니라 몇몇 강제 단계 중 하나가 됩니다. 그것은 Claude Code와 다른 9개의 에이전트에서 실행되며, 가이드는 Spec Kit(또는 OpenSpec)가 계획 골격을 소유하면서 gstack이 스펙 도구가 강제하지 않는 레이어를 공급하는 방법을 다룹니다.

그들 모두를 관통하는 패턴은 동일합니다. 모호성이 비쌈할 때 더 많은 프로세스가 도움이 됩니다. 피드백 속도가 정렬보다 더 중요할 때 더 많은 프로세스는 해가 됩니다. 도구 무게를 하이프가 아니라 태스크 크기에 맞추세요.

어떤 SDD 설정을 사용해야 합니까?

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

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

Claude Code 스킬 접근법을 원하지만 자신의 리뷰 게이트를 계속 건너뛰고 있음. 커스텀 스킬을 처음부터 쓰기보다 Superpowers를 설치하세요. 당신은 당일 자신의 규일에 의존하지 않는 강제된 브레인스토밍-계획-구현-리뷰 루프를 얻기 위해 프로젝트 특화 튜닝의 일부를 포기합니다.

솔로 개발자, 그린필드 기능, 여러 세션. Spec Kit 또는 잘 유지보수된 Claude Code SDD 스킬. 당신은 IDE의 손 잡기보다 내구성 있는 아티팩트를 더 필요로 합니다.

작은 팀, 혼합 에디터. Spec Kit. Git 내 일반 마크다운 스펙, 풀 리퀘스트에서 리뷰, 각 개발자가 선호하는 에이전트에 의해 실행.

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

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

기존 코드베이스, 브라운필드 변경. OpenSpec 또는 가벼운 Claude Code 워크플로우. 모든 버그 수정에 대한 전체 Spec Kit 예식은 워터폴처럼 느껴질 것입니다. 더 무거운 구조는 횡단형 기능에 dành으세요.

그린필드 프로덕트, 많은 에이전트. Spec Kit. Copilot, Claude Code, Cursor가 모두 동일한 리포지토리에 닿을 수 있을 때 IDE 광택보다 이식성이 더 중요합니다.

멀티 에이전트 오케스트레이션 실험 중인 팀은 또한 에이전트 간 역할 분할에 대한 패턴을 위해 Oh My OpenCode 에이전트를 살펴봐야 합니다 – SDD 아티팩트와 보완적이지 그 대체재가 아닙니다.如果你的 팀이 IDE 통합 대신 터미널 퍼스트 에이전트를 실행한다면, OpenCode CLI 실무 가이드는 계획-부터-구현 규율의 더 가볍고, 프롬프트 레벨 버전을 보여줍니다 – 전체 Spec Kit 트리가 태스크가 WARRANT하는 예식보다 더 많을 때 유용합니다.

실질적 결정 테이블

실제로 성공을 결정하는 것은 무엇인가

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

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

특정 기능에 대해 SDD와 구조 없는 프롬프팅 사이에서 여전히 선택 중이라면, 스펙 기반 개발 vs 바이브 코딩를 읽어보세요. 이 기사의 도구 비교는 기능이 아예 스펙이 가치가 있는지 결정한 후에만 중요합니다.

나쁜 스펙은 모든 에이전트를 더 나쁘게 만듭니다. 좋은 스펙은 도구 간에 이동합니다.

결론

GitHub Spec Kit, Kiro, 그리고 Claude Code 워크플로우는 세 가지 답변입니다 – 세션을 가로질러 AI 에이전트를 어떻게 정렬 상태로 유지할 것인가 – 이식성 대 통합에 대한 다른 베팅을 가진. Spec Kit는 리포지토리 내 에이전트 독립적 마크다운을 최적화합니다. Kiro는 AWS 기반 에이전트를 가진 가이드된 스펙 네이티브 IDE를 최적화합니다. Claude Code 스킬은 당신이 그것들을 유지보수할 때만 성공하는 해킹 가능하고 가벼운 워크플로울 최적화합니다.

현재 기능에 대한 모호성을 제거하는 가장 얕은 설정을 선택하세요. 블로그 게시물이 말한다고 해서가 아니라 조정 고통이 나타날 때 구조를 추가하세요. 2026년 SDD에서 가치를 얻는 개발자는 가장 화려한 툴체인을 가진 사람들이 아닙니다. 그들은 구현할 가치가 있는 스펙을 작성하는 – 그리고 그것이 선택한 도구가 그것에 대해 실행하도록 허용하는 – 사람들입니다.

유용한 링크

• GitHub Spec Kit 문서 – 공식 Spec Kit 워크플로우 참조
• Superpowers 퀵스타트: 설치, 워크플로우, 그리고 시험 – Claude Code, Cursor, Codex 및 기타 에이전트 간 브레인스토밍-부터-TDD 방법론을 강제하는 오픈 소스 스킬 패키지
• gstack: 의견이 확고한 AI 소프트웨어 엔지니어링 스택 – 전체 가상-엔지니어링-팀 옵션, 그리고 Spec Kit, OpenSpec, Superpowers와 어떻게 결합하는지
• Martin Fowler의 SDD 도구에 대하여 – Kiro, Spec Kit, Tessl 분석