SpecScore vs Spec Kit

둘은 서로 다른 레이어에서 작동합니다. Spec Kit은 워크플로우입니다 — 에이전트를 아이디어에서 구현까지 안내하는 가이드 프로세스죠. SpecScore는 스펙이 작성되는 형식이며, 그것을 lint하고, 쿼리하고, 추적하는 CLI를 더한 것입니다. Spec Kit은 SpecScore 파일을 생성할 수 있습니다.

공통점.

같은 북극성 — 코드보다 먼저 사양을, AI 에이전트를 일급 독자로.
스펙은 Markdown으로 저장소에 존재합니다 — 버전 관리 가능하고, PR 리뷰가 가능합니다.
둘 다 MIT 라이선스의 오픈 소스입니다.
둘 다 Claude Code, Cursor, Copilot 및 기타 AI 코딩 에이전트를 대상으로 합니다.

Spec Kit이 잘하는 것.

Spec Kit은 GitHub Next의 스펙 기반 개발 워크플로우입니다.

완결적이고 의견이 분명한 프로세스

Spec Kit은 전체 흐름을 제공합니다:constitution → specify → plan → tasks → implement. 각 단계에는 슬래시 명령과 에이전트를 궤도에 유지하도록 설계된 프롬프트가 있습니다. 프로세스를 원한다면, Spec Kit이 하나를 건네줍니다.

강한 배포력과 인지도

GitHub Next의 지원을 받으며, 큰 커뮤니티와 늘어나는 확장 라이브러리를 갖추고 있습니다. 많은 개발자에게 Spec Kit은 처음 접하는 스펙 기반 워크플로우입니다.

에이전트 비종속 명령

Spec Kit의 명령은 Claude Code, Cursor, Copilot 등에서 동작합니다 — 어떤 것을 실행하든 워크플로우가 에이전트를 이끕니다.

기능 비교.

이 도구들은 서로 다른 질문에 답하므로, 표는 승자가 아니라 역할을 비교합니다.

기능	Spec Kit	SpecScore
주요 역할	워크플로우 / 방법론	저장 형식 + CLI
스펙 출력	자유 형식 Markdown	Markdown + YAML frontmatter (구조화)
스펙 linting	없음	콘텐츠 품질 — 모호한 동사, 누락된 인수 기준, 끊어진 참조
요구사항 / 인수 기준 ID	없음	기계 주소 지정 가능 ID (`REQ: slug`)
라이프사이클 상태	암시적 (워크플로우 단계)	강제 적용 — Draft → Approved → Implementing → Stable → Deprecated
코드-스펙 추적성	없음	`specscore:` 어노테이션 + `Verifies:` 커밋 트레일러
CLI에서 스펙 쿼리	스캐폴딩 (`specify`, `plan`, `tasks`)	쿼리 API — `feature list / show / deps`, `lint`, `code refs`
런타임 의존성	Python	없음 — 단일 Go 바이너리
CI 통합	워크플로우 실행	`specscore lint` 0이 아닌 코드로 종료, pre-commit 훅
관계	둘은 조합됩니다 — Spec Kit은 SpecScore 파일을 생성할 수 있습니다
라이선스	MIT	MIT

SpecScore가 더하는 것.

출력이 lint 가능합니다

Spec Kit은 자유 형식 Markdown을 생성합니다 — 좋든 나쁘든, 그대로 출시됩니다. SpecScore는 결과를 두 레이어로 검사합니다: lint는 모든 요구사항에 인수 기준이 있는지, 상호 참조가 해석되는지, 상태 전환이 유효한지 결정적으로 검증하고 — AI 리뷰어(/review,/score)는 모호한 기준과 막연한 동사를 잡아냅니다.

$ specscore lint checkout/apply-discount.md
  ✗ R3  no acceptance criteria
  ✗ link  "Related Feature: discount-tiers" not found

출력이 쿼리 가능합니다

Spec Kit은 파일을 작성합니다; 다시 읽으려면 열어야 합니다. SpecScore 스펙은 CLI에서 질문에 답합니다: specscore feature list,feature deps, code refs — 그래서 에이전트가 저장소의 모든 파일을 읽지 않고 스펙 그래프를 탐색합니다.

모든 요구사항에 ID가 있습니다

Spec Kit은 요구사항을 산문으로 참조합니다. SpecScore는 slug 기반 ID(REQ: slug-format)와 이름 변경, 리팩토링, 에이전트 핸드오프에도 유지되는 인수 기준 ID를 할당합니다.

라이프사이클이 강제됩니다

Spec Kit에서 스펙의 단계는 워크플로우 어디에 있느냐입니다. SpecScore에서 라이프사이클은 강제되는 상태 필드입니다 — Draft → Approved → Implementing → Stable → Deprecated — lint로 검증되고, git 훅이나 CI에서 specscore change-status로 전환됩니다.

코드가 스펙으로 추적됩니다

Spec Kit에는 추적성 메커니즘이 없습니다. SpecScore는specscore: 소스 어노테이션과 Verifies:커밋 트레일러를 제공합니다 — specscore code refs를 실행하면 "어떤 코드가 이 요구사항을 구현하는가?"에 대한 결정적인 답을 얻습니다.

런타임 의존성 없음

SpecScore는 단일 Go 바이너리입니다 — 설치할 런타임이 없습니다. Go, Rust, Python, Java, 또는 JavaScript 프로젝트에서 툴체인에 무언가를 추가하지 않고 동작합니다.

언제 어떤 것을 사용할까.

Spec Kit을 선택하세요…

아이디어에서 구현까지 가이드되고 의견이 분명한 프로세스를 원하는 경우.
팀에 명시적인 specify / plan / tasks 단계의 규율이 필요한 경우.
팀 전반에서 에이전트를 이끄는 방식을 표준화하는 경우.

SpecScore를 사용하세요…

모든 파일을 읽지 않고 에이전트가 lint, 쿼리, 변경할 수 있는 스펙이 필요한 경우.
결정적인 답을 주는 코드-스펙 추적성이 필요한 경우.
다수의 기능과 라이프사이클 전환이 있는 대규모 시스템을 구축하는 경우.
런타임 의존성이 전혀 없기를 원하는 경우 — 바이너리 하나, 언어 툴체인 불필요.
ESLint나 go vet처럼 0이 아닌 코드로 종료하는 CI의 스펙 품질 게이트가 필요한 경우.

SpecScore는 Spec Kit을 확장합니다 — 대체하지 않습니다.

Spec Kit은 스펙을 생산하는 프로세스이고, SpecScore는 그 스펙이 작성될 수 있는 형식입니다. SpecScore 형식을 내보내는 Spec Kit 확장이 진행 중입니다 — Spec Kit 워크플로우를 실행하면, 그 끝에서 lint하고, 쿼리하고, 추적하는 스펙을 얻습니다.

프로세스를 위해서는 Spec Kit을 선택하세요. 아티팩트를 위해서는 SpecScore를 선택하세요. 둘 다 원할 때는 둘 다 실행하세요.

이 비교는 공개적으로 이용 가능한 문서와 소스 코드를 기반으로 합니다. 잘못되었거나 오래된 정보가 있나요? 수정 issue를 열어주세요. SpecScore를 다른 도구와 비교해 주길 원하시나요? 요청해 주세요.