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

2026년에 스펙 기반 개발(Spec-Driven Development, SDD) 환경을 비교하는 개발자들은 보통 어떤 모델이 가장 똑똑한지 묻지 않습니다. 그들은 어떤 워크플로우가 AI 에이전트를 정렬 상태로 유지하면서도 과도한 절차(Ceremony)에 빠뜨리지 않을지 묻습니다.

GitHub Spec Kit, AWS Kiro, Claude Code 커스텀 워크플로우는 모두 동일한 광범위한 아이디어인 요구사항, 설계, 태스크, 구현, 검증을 구현하지만, 이식성(Portability), 통합 깊이, 그리고 강제하는 절차의 양에서 트레이드오프가 존재합니다.

먼저 개념이 필요하시다면 스펙 기반 개발이란 무엇인가?와 도구 중립적인 스펙 기반 개발 워크플로우 가이드를 앱 아키텍처 문서 클러스터에서 읽어보시기 바랍니다. 이 비교 아티클은 어시스턴트 리뷰와 워크플로우 가이드와 함께 AI 개발 도구 허브에 위치합니다.

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

스펙 기반 개발은 2025년 후반쯤부터 종이 위의 연습이 아닌 실제 도구로 정착되기 시작했습니다. 모든 주요 AI 코딩 벤더가 ‘지정-계획-구현(specify-plan-implement)’ 루프의 어떤 버전이든 제공하고 있으며, 이 루프 주위에 얼마나 많은 구조를 추가하는지를 두고 경쟁하는 독립형 도구들의 목록도 점점 늘어나고 있습니다.

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

SDD 환경 비교 방법

도구를 선택하기 전에 무엇을 최적화하려 하는지 명명하십시오. 팀 규모, 코드베이스의 연대, 필요한 리뷰의 양에 따라 동일한 기능이 한 환경에서는 무척 자연스러울 수도 있고, 다른 환경에서는 관료적으로 느껴질 수 있습니다.

이식성 – 스펙이 저장소 내 일반 마크다운 파일로 존재하면서 다음 분기에 선호하는 에이전트와 함께 작동할 수 있습니까? 아니면 특정 IDE, 클라우드, 또는 독점 형식에 묶여 있습니까?

설정 마찰 – “SDD를 시도하고 싶다"는 생각부터 작동하는 지정-계획-태스크 루프까지 얼마나 걸립니까? CLI 스캐폴딩, IDE 설치, 또는 슬래시 커맨드를 직접 만드는 것 모두 다른 활성화 에너지를 요구합니다.

스펙 품질 – 도구가 정확한 요구사항과 수용 기준을 작성하는 데 도움이 됩니까, 아니면 단순히 긴 문서만 생성할 뿐입니까? 구조는 유용합니다. 분량은 그렇지 않습니다.

태스크 실행 – 도구는 작업을 리뷰 가능한 조각으로 어떻게 나누습니까? 태스크를 병렬로 실행할 수 있습니까? 50개 이상의 태스크 폭발을 거부합니까?

리뷰 체크포인트 – 지정, 계획, 태스크, 구현 사이에 자연스러운 인간 게이트가 존재합니까? 리뷰 없는 SDD는 더 느린 바이브 코딩(Vibe Coding)일 뿐입니다.

저장소 기반(Grounding) – 워크플로우는 계획 단계 전에 프로젝트 컨벤션, 의사결정 기록, ADR, AGENTS.md, 그리고 기존 코드를 읽습니까? 기반이 없는 에이전트는 이전 선택 뒤에 있는 검토된 의도를 볼 수 없으므로 아키텍처를 다시 발명하는 경향이 있습니다.

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

락인(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은 헌법, 스펙, 계획, 태스크, 컨트랙트 등 큰 아티팩트 트리를 생성할 수 있으며, 이는 다중 세션 기능에서는 이점이 되지만 작은 CLI 조정에는 무겁게 느껴질 수 있습니다. Hacker News 스레드에서는 정기적으로 그 오버헤드를 워터폴 절차와 비교합니다. 또한 스펙, 태스크, 구현이 하나의 가이드된 표면에서 이루어지는 완전히 통합된 IDE를 원한다면 Spec Kit은 약합니다. 기존 에디터를 대체하는 것이 아니라 그 위에 프로세스를 얹어줍니다.

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

AWS Kiro

Kiro는 VS Code / Code OSS 포크 위에 구축된 AWS의 스펙 기반 IDE입니다. Spec Kit이 SDD를 기존 스택으로 가져온다면, Kiro는 SDD가 목적에 맞게 구축된 환경을 당연시합니다. 프롬프트가 에이전트가 프로덕션 코드를 작성하기 전에 구조화된 아티팩트 – 일반적으로 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 파일을 Skills 메커니즘으로 통합했으므로, 지속 가능한 패턴은 지정-계획-구현 체크리스트를 정의하고 필요 시 로드되는 SKILL.md(또는 동등한 것)입니다.

이 접근 방식은 가장 가볍고 해킹하기 쉽습니다. Kiro 스타일 3파일 레이아웃을 이식하거나, 슬래시 커맨드로 Spec Kit 단계를 모방하거나, 또는 한 저장소에 맞는 최소한의 워크플로우를 발명할 수 있습니다. Claude Code는 항상 켜져 있는 프로젝트 컨텍스트를 위해 CLAUDE.md를 읽고, 태스크가 일치할 때 스킬을 가져옵니다. 이러한 점진적 공개(Progressive Disclosure)는 모든 프롬프트마다 전체 헌법을 로드하지 않으면서도 세션을 집중되게 합니다.

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

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

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

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

그가 강제하는 워크플로우는 요구사항부터 코드로의 스펙 기반 개발 워크플로우에서 다루는 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/ 폴더에 머무르지 않고 동일한 방법론이 하네스(Harness) 사이를 따라 이동합니다. 이는 자체 Claude Code 스킬을 만드는 것과 Kiro와 같은 더 무겁고 IDE 특화 도구를 채택하는 것 사이의 중간 지점이 됩니다. 에디터를 포기하거나 단일 벤더의 스펙 형식에 구속되지 않으면서도 의견이 분분한 강제 루프를 얻습니다.

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

BMAD, OpenSpec 및 기타 워크플로우

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

OpenSpec (Fission AI)는 Spec Kit보다 적은 생성 파일로 변경 중심의 접근 방식을 취합니다. 커뮤니티 벤치마크는 동일한 태스크에 대해 실질적으로 더 낮은 토큰 사용량을 보고하지만, 사전 구조가 적다는 대가가 있습니다. OpenSpec는 기존 코드베이스를 수정하면서 800줄짜리 계획 단계 없이 리뷰 가능한 스펙을 원할 때 이기는 경향이 있습니다. 이는 Kiro의 IDE 통합보다는 Spec Kit의 이식성과 더 많이 경쟁합니다.

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

Tessl은 스펙을 생성된 코드의 문자 그대로 소스로 취급하며, 출력을 파생된 것으로 표시하고 수동 편집을 desenc려합니다. 이는 주류 도구 중 가장 강력한 “스펙을 소스로"라는 입장이지만, Tessl은 여전히 베타 단계이며 그룹 내 가장 높은 제품 락인을 가지고 있습니다.

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

이 모든 것에서 공통적인 패턴은 동일합니다. 모호성이 비쌀 때 더 많은 프로세스가 도움이 됩니다. 정렬보다 피드백 속도가 더 중요할 때 더 많은 프로세스가 해가 됩니다. 도구 무게를 하이프가 아닌 태스크 크기에 맞게 조정하십시오.

어떤 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 스킬만으로는 안 됩니다. 툴링은 감사 추적(Audit Trails)을 대체하지 않습니다. 단지 생성하기 쉽게 할 뿐입니다.

기존 코드베이스, 브라운필드 변경. OpenSpec 또는 경량 Claude Code 워크플로우. 모든 버그 수정마다 전체 Spec Kit 절차는 워터폴처럼 느껴질 것입니다. 더 무거운 구조는 횡단 기능에 예약하십시오.

그린필드 제품, 많은 에이전트. Spec Kit. Copilot, Claude Code, Cursor가 모두 같은 저장소에 접근할 수 있다면 IDE의 정제보다 이식성이 더 중요합니다.

멀티 에이전트 오케스트레이션을 실험하는 팀은 에이전트 간 역할 분할 패턴을 위해 Oh My OpenCode Agents도 살펴봐야 합니다 – 이는 SDD 아티팩트의 대체재가 아니라 보완재입니다.

실용적 의사결정 표

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

도구 선택보다 아티팩트 품질이 더 중요합니다. 모호한 수용 기준을 가진 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까지의 방법론을 강제하는 오픈소스 스킬 패키지
• Martin Fowler의 SDD 도구 분석 – Kiro, Spec Kit, Tessl 분석