2026년 최고의 스펙 주도 개발 도구

이 스펙 주도 개발 도구 비교는 GitHub Spec Kit, OpenSpec, Kiro, Tessl, BMAD Method, Task Master AI, CodeSpeak, Datarim, 일반 Markdown, SpecScore를 다룹니다. 공개된 페이지와 저장소는 2026년 10월 30일에 읽었습니다. 명령, 파일 배치, 제품이 검사하는 내용은 바뀔 수 있습니다. 맨 아래 출처가 각 서술의 페이지를 밝힙니다.

저장소에서 갈리는 지점은, 명세가 그 자체로 CI에서 실패할 수 있는가입니다. SpecScore 웹사이트 저장소에서 dogfood.yml은 SpecScore CLI를 설치하고, 풀 리퀘스트와 main으로의 푸시에서 specscore spec lint를 실행합니다. specstudio-skills의 /score 스킬은 산출물에 대한 수동 AI 채점입니다. 사람이 호출합니다. 그 워크플로는 호출하지 않습니다.

GitHub Spec Kit

GitHub Spec Kit은 코딩 에이전트에 절차를 건네는 열린 도구 모음입니다. Specify, Plan, Tasks, Implement, Converge로 이어집니다. 2026년 9월 28일 날짜의 Spec Kit 문서 홈은, 각 단계가 Markdown 산출물을 만들고 다음 단계가 그것을 읽는다고 말합니다.

그 파일은 specs/ 아래의 기능 디렉터리에 있습니다. 2026년 10월 30일에 읽은 업그레이드 가이드는 specs/001-my-feature/spec.md 같은 경로를 보여 주고, 옆에 plan.md와 tasks.md를 둡니다. 에이전트형 SDD 레퍼런스는 /speckit.analyze를, 파일을 고치지 않은 채 명세와 계획과 작업 사이의 불일치를 보고하는 것으로 설명합니다. /speckit.clarify와 /speckit.checklist는 에이전트 안에서 실행하는 또 다른 명령입니다. 문서 홈은 준수 게이트를 더하는 커뮤니티 확장도 이름 붙이며, 그 중 하나가 CI Guard입니다.

라이선스는 MIT이고, 공개 저장소는 github/spec-kit입니다. Spec Kit은 그 절차를 원하고, 명세를 에이전트가 쓴 Markdown으로 두어도 되는 팀에 맞습니다. SpecScore와 나란히 보는 글은 SpecScore vs Spec Kit에 있습니다.

OpenSpec

Fission-AI의 OpenSpec은 변경마다 폴더를 나누어, 사람과 에이전트가 코드를 쓰기 전에 합의할 수 있게 합니다. 2026년 10월 30일에 읽은 README는 openspec/changes/add-dark-mode/에 proposal.md, specs/ 디렉터리, design.md, tasks.md가 있는 예를 보여 줍니다. 요구사항은 일반 Markdown입니다. SHALL 문장과 WHEN / THEN 시나리오입니다. 같은 README는 30+ AI 어시스턴트를 지원한다고 말합니다.

openspec validate는 변경과 명세의 구조적 문제를 검사합니다. 2026년 10월 30일에 읽은 CLI 레퍼런스는 검사가 실패할 때의 0이 아닌 종료와, CI 작업이 실행할 수 있는 셸 조각을 적습니다. 이 검사가 보는 것은 OpenSpec의 변경과 명세 구조입니다.

라이선스는 MIT이고, 저장소는 Fission-AI/OpenSpec입니다. OpenSpec은 그 변경 폴더와 구조 검사를 원하는 팀에 맞습니다. SpecScore vs OpenSpec를 보세요.

Kiro

Amazon Web Services(AWS)의 Kiro는 에이전트형 개발 환경입니다. 편집기, CLI, 웹 앱으로 이루어집니다. 2026년 8월 4일에 갱신된 기능 명세 페이지는 하나의 기능을 요구사항, 설계, 작업으로 진행합니다. requirements.md는 EARS를 씁니다. design.md와 tasks.md가 그 옆에 있습니다. Quick Spec은 셋 사이에 승인으로 멈추지 않고 셋을 모두 진행할 수 있습니다.

Analyze Requirements는 설계 전에 불일치, 모호함, 서로 충돌하는 제약, 빈틈을 찾습니다. 그 분석은 Kiro 안에서 돕니다. 기능 명세 페이지가 제품 안 검사를 설명합니다.

2026년 10월 30일에 읽은 Kiro 라이선스는, IDE와 CLI가 AWS Content로서 AWS Customer Agreement 또는 다른 서면 합의와 AWS Intellectual Property License 아래에서 라이선스된다고 말합니다. Kiro는 그 세 파일의 초안을 이 제품에 맡기고 싶은 사람에게 맞습니다. SpecScore vs Kiro를 보세요. 문장 패턴은 EARS 요구사항 구문입니다.

Tessl

2026년 10월 30일에 읽은 Tessl 문서는 에이전트 스킬을 다루는 열린 플랫폼을 설명합니다. 레지스트리, 거버넌스, evals, 관련 컨트롤입니다. 스킬, 규칙, 문서는 저장소 안의 파일입니다.

별도의 산출물인 스펙 주도 개발 타일은 tesslio/spec-driven-development-tile에서 공개되고, Tessl 레지스트리에 올라 있습니다. 타일 README는 에이전트가 .spec.md를 specs/ 디렉터리에 쓰며, YAML 프론트매터, targets, [@test] 링크를 붙인다고 말합니다. scripts/validate-specs.sh와 scripts/check-spec-links.sh, 그리고 타일 자체를 검사하는 GitHub Actions도 적습니다.

타일의 라이선스는 MIT이고, 그 저장소에 있습니다. 문서는 레지스트리 플랫폼을 Tessl의 제품으로 설명하고, 플랫폼 전체의 공개 저장소는 가리키지 않습니다. Tessl은 스킬을 맞추는 팀, 또는 타일이 코드보다 명세를 먼저 두도록 이끄는 규칙을 원하는 팀에 맞습니다. SpecScore vs Tessl를 보세요.

BMAD Method

2026년 10월 30일에 읽은 BMAD Method 저장소 README는 AI 주도 개발을 위한 애자일 방법을 설명합니다. 방법을 처음부터 끝까지 쓸 수도 있고, 브리프와 명세와 아키텍처를 이미 있는 워크플로로 가져갈 수도 있다고 말합니다. 거기서 이름 붙인 안정 라인은 v6.12입니다. v7은 main 브랜치의 미리보기로 설명됩니다. 프로젝트는 이름을 BMad로 적고, 저장소는 BMAD-METHOD입니다.

README의 중심은 그 계획 산출물과, 그것을 만드는 에이전트 스킬입니다. 고정된 명세 스키마를 CI에서 검사하는 명령은 적지 않습니다.

라이선스는 MIT이고, 저장소는 bmad-code-org/BMAD-METHOD입니다. 그 라이선스 파일에는 BMad 상표 고지도 있습니다. 이 방법은 애자일 순환을 원하고, 명세를 그 브리프와 명세에 남겨 둘 팀에 맞습니다. SpecScore vs BMAD Method를 보세요.

Task Master AI

Task Master AI는 AI 코딩 에이전트를 위한 작업 목록입니다. 2026년 10월 30일에 읽은 README는 PRD를 권하고, 자리는 흔히 .taskmaster/docs/prd.txt입니다. task-master parse-prd가 그 산문을 작업으로 바꿉니다. 문서는 작업 구조, 의존성, 태그를 다룹니다.

README는 PRD를 입력으로, 작업 목록을 에이전트가 일하는 대상으로 봅니다. PRD의 문장이나 구조를 검사하는 린터는 설명하지 않습니다.

라이선스는 Commons Clause가 붙은 MIT이고, 저장소는 eyaltoledano/claude-task-master입니다. README는 Task Master로 제품을 만들 수 있고, Task Master 자체를 팔거나 호스팅 서비스로 제공하는 일은 그 허락 밖이라고 말합니다. PRD를 작업으로 나누고 싶은 팀에 맞습니다. SpecScore vs Task Master AI를 보세요.

CodeSpeak

2026년 10월 30일에 읽은 CodeSpeak 사이트는 에이전트형 엔지니어링 도구 모음을 설명합니다. 에이전트 채팅에서 의도를 잡고, 그 의도를 코드에 대응시킨 구조화 요구사항으로 바꾸며, 변경마다 그 요구사항을 강제한다고 말합니다. 사이트는 제품 전체가 나오기 전까지 웹 도구가 채팅에서 의도를 거두어 온다고도 말합니다.

2026년 3월 3일 발효인 서비스 약관은 CodeSpeak Ltd가 소프트웨어와 소스 코드를 포함한 Service를 보유한다고 정합니다. 제품 사이트가 그 도구 모음의 소스 저장소를 공개하지 않으므로, 이 페이지는 그 소프트웨어 라이선스를 지목하지 않습니다.

CodeSpeak은 대화에서 요구사항을 잡고, 그 제품 안에서 코드와의 대응을 유지하고 싶은 팀에 맞습니다. SpecScore vs CodeSpeak를 보세요.

Datarim

4.9.0 버전 배지를 달고 2026년 10월 30일에 읽은 Datarim README는 Claude Code, Codex CLI, Cursor, Google Antigravity를 위한 반복 워크플로를 설명합니다. /dr-prd가 PRD를 생성합니다. 진행 중인 작업은 backlog.md에, 완료된 이력은 backlog-archive.md에 있습니다.

/dr-compliance는 그 명령을 실행할 때 구현을 PRD와 맞춥니다. /dr-dream lint는 지식 기반에서 모순, 고아 항목, 깨진 링크, 오래된 내용, 중복을 점검합니다. 이들은 워크플로 안의 명령입니다.

라이선스는 MIT이고, 저장소는 Arcanada-one/datarim입니다. Datarim은 README가 이름 붙인 에이전트에서 그 단계별 명령을 원하는 팀에 맞습니다. SpecScore vs Datarim를 보세요.

일반 Markdown

일반 Markdown은 명세를 평범한 .md 파일로 두는 것입니다. 제목과 글머리표를, 커밋하는 곳에 둡니다. 스키마는 없습니다. 직접 검사기를 더하기 전까지 리뷰는 누군가 파일을 읽는 일입니다.

연결할 제품도 라이선스 파일도 없습니다. 파일의 조건은 저장소에 적용하는 라이선스 그대로입니다. 일반 Markdown은 짧은 메모, 스파이크, 또는 산문을 읽어서 리뷰할 팀에 맞습니다. SpecScore vs plain Markdown를 보세요.

SpecScore

SpecScore는 명세를 위한 형식입니다. 기능, 요구사항, 인수 기준을 YAML이 붙은 Markdown으로 쓰고, CLI가 파일을 검사합니다. 형식은 specscore/specscore에 있습니다. CLI는 specscore/specscore-cli에 있습니다.

에이전트가 검사할 수 있는 기준을 쓰는 방법은 인수 기준 작성법에 있습니다.

요구사항, 인수 기준, 계획, 태스크를 담은 Markdown 기능 명세 템플릿은 Markdown PRD 템플릿에 있습니다.

Claude Code와 Cursor로 하는 명세 주도 개발. 기능 파일, 에이전트 지시 파일, 그리고 루프 안의 specscore spec lint에 대해서는 Claude Code와 Cursor로 하는 명세 주도 개발.

그 린터를 지속적 통합에서 실행하는 방법은 CI에서 명세 린트하기에 있습니다.

이 웹사이트 저장소에서 dogfood.yml은 그 CLI를 설치하고, 풀 리퀘스트와 main으로의 푸시에서 specscore spec lint를 실행합니다. 형식을 깨뜨린 명세는 그 작업을 실패시킵니다. /score 스킬은 수동 AI 채점입니다. 요청할 때 설정된 리뷰어를 다시 실행하며, dogfood 워크플로는 그것을 호출하지 않습니다.

형식 라이선스는 CC BY 4.0이고, 저장소는 specscore/specscore입니다. CLI 라이선스는 Apache-2.0이고, 저장소는 specscore/specscore-cli입니다. SpecScore는 제목, 링크, 상태가 잘못되었을 때 명세가 CI에서 실패해야 하는 팀에 맞습니다. 파일을 쓴 에이전트가 무엇이든 마찬가지입니다. openspec validate는 여기 다른 도구 가운데 구조 검사로 가장 가깝습니다. 검사하는 것은 OpenSpec 자신의 변경 형태입니다. 개별 비교는 /vs/에서 시작합니다.

고르는 법.

안내되는 절차와, 풀 리퀘스트에서 리뷰할 수 있는 Markdown이 필요하면 GitHub Spec Kit, OpenSpec, BMAD Method, Datarim을 고르세요. EARS 요구사항 초안을 그 제품이 쓰게 하려면 Kiro입니다. PRD가 작업 목록이 되어야 하면 Task Master AI입니다. 의도를 그 제품 안의 채팅에서 잡아야 하면 CodeSpeak입니다. 문제가 에이전트 스킬이면 Tessl이고, 명세 타일은 선택적인 유도입니다.

명세 파일 자체가 CI에서 실패해야 하면 SpecScore를 고르세요. 이 저장소의 검사는 dogfood.yml 안의 specscore spec lint입니다. 위 목록의 워크플로는, 명세를 쓰는 방법으로 그대로 쓸 수 있습니다.

출처.

페이지가 자신의 갱신일을 적은 경우를 빼면, 2026년 10월 30일에 읽었습니다. 가격과 요금제 이름은 바뀌므로 적지 않았습니다.

• GitHub Spec Kit 문서 (페이지 날짜 2026년 9월 28일)
• Spec Kit — 에이전트형 SDD 레퍼런스
• Spec Kit — 업그레이드 가이드 (specs/ 경로)
• github/spec-kit — MIT 라이선스
• Fission-AI/OpenSpec — README
• OpenSpec CLI 레퍼런스 — openspec validate
• Fission-AI/OpenSpec — MIT 라이선스
• Kiro 문서 — 기능 명세와 EARS (2026년 8월 4일 갱신)
• Kiro — 라이선스
• Tessl 문서 — Tessl이란
• tesslio/spec-driven-development-tile
• Tessl 스펙 주도 개발 타일 — MIT 라이선스
• bmad-code-org/BMAD-METHOD — README
• BMAD-METHOD — MIT 라이선스
• eyaltoledano/claude-task-master — README
• Task Master — Commons Clause가 붙은 MIT
• CodeSpeak
• CodeSpeak — 서비스 약관 (2026년 3월 3일 발효)
• Arcanada-one/datarim — README (4.9.0 배지)
• Datarim — MIT 라이선스
• specscore/specscore — dogfood.yml (specscore spec lint)
• specstudio-skills — /score 스킬 (수동 AI 채점)
• specscore/specscore — CC BY 4.0
• specscore/specscore-cli — Apache-2.0