SpecScore vs OpenSpec
둘 다 사양을 코드 옆에 Markdown으로 작성하며, AI 에이전트가 읽을 수 있습니다. 하지만 다른 질문에 답합니다. OpenSpec은 스펙을 구성하고 에이전트 명령을 생성합니다. SpecScore는 스펙 콘텐츠를 lint하고, 라이프사이클을 강제하며, 코드를 요구사항까지 추적합니다.
공통점.
OpenSpec이 잘하는 것.
가장 넓은 에이전트 지원
OpenSpec은 생성된 스킬 파일을 통해 29개의 AI 코딩 에이전트를 지원합니다 — Claude, Cursor, Copilot, Gemini, Windsurf, Cline 등. 사용 중인 에이전트가 목록에 있다면, OpenSpec은 설정 없이 바로 통합됩니다.
낮은 진입 장벽
npm install -g @fission-ai/openspec && openspec init 만으로 바로 스펙을 작성할 수 있습니다. 배울 스키마도, 필수 frontmatter도 없습니다. 특히 기존 코드베이스에서 부담 없이 시작할 수 있도록 설계되었습니다.
깔끔한 변경 델타 모델
OpenSpec의 ADDED / MODIFIED / REMOVED 형식은 스펙 변경에 잘 설계되어 있습니다. 각 변경은 제안서, 델타 스펙, 작업이 포함된 폴더로 구성됩니다 — 수정 사항을 제안하는 구조화된 방식입니다.
기능 비교.
| 기능 | OpenSpec | SpecScore |
|---|---|---|
| 스펙 형식 | Markdown (frontmatter 없음) | Markdown + YAML frontmatter |
| 스펙 linting | 파일 구조만 | 콘텐츠 품질 — 모호한 동사, 누락된 인수 기준, 끊어진 참조 |
| 요구사항 ID | 없음 (제목으로 참조) | Slug 기반 (REQ: slug-format) |
| 인수 기준 ID | 없음 | 기계 주소 지정 가능 ID |
| 라이프사이클 상태 | 암시적 (파일 위치) | 강제 적용 — Draft → Under Review → Approved → Implementing → Stable → Deprecated |
| 코드-스펙 추적성 | 없음 | specscore: 어노테이션 + Verifies: 커밋 트레일러 |
| 하위 기능 | 아니오 | 예 (중첩 디렉토리) |
| 상호 참조 | 공식 메커니즘 없음 | 의존성, 소스 아이디어, 플랜 참조 |
| CI 통합 | 기본 (openspec validate) | specscore lint 구성 가능한 심각도, pre-commit 훅 |
| 에이전트 지원 | 29개 에이전트 | Claude Code 우선 + 모든 에이전트를 위한 CLI |
| 스키마 커스터마이징 | 예 (schema.yaml, fork/init) | 고정 스키마 (설계에 의한 일관성) |
| 변경 제안 | 델타 모델 (ADDED/MODIFIED/REMOVED) | 변경 요청 아이디어 + 제안 |
| 런타임 의존성 | Node.js 20.19+ | 없음 — 단일 Go 바이너리 |
| 라이선스 | MIT | MIT |
SpecScore가 더 나아가는 부분.
검증은 파일 구조를 넘어섭니다
OpenSpec의 validate는 파일 구조를 검사합니다. SpecScore는 두 레이어로 더 많은 것을 검사합니다: lint는 콘텐츠 관계를 결정적으로 검증하고 — 모든 요구사항에 인수 기준이 있는지, 상호 참조가 해석되는지, 상태 전환이 유효한지 — AI 리뷰어(/review, /score)는 어떤 린터도 잡을 수 없는 것을 잡아냅니다: 모호한 기준과 막연한 동사.
$ specscore lint checkout/apply-discount.md ✗ R3 no acceptance criteria ✗ link "Related Feature: discount-tiers" not found
모든 요구사항에 기계 판독 가능한 ID가 있습니다
OpenSpec은 요구사항을 제목으로 참조합니다 — 이름 변경에 취약합니다. SpecScore는 slug 기반 ID(REQ: slug-format)와 이름 변경, 리팩토링, 에이전트 핸드오프에도 유지되는 인수 기준 ID를 할당합니다.
라이프사이클은 암시가 아닌 강제입니다
OpenSpec에서 스펙의 라이프사이클은 파일 위치입니다: specs/ (현재), changes/ (제안), archive/ (완료). SpecScore에서 라이프사이클은 강제되는 상태 필드입니다 — Draft → Under Review → Approved → Implementing → Stable → Deprecated — lint로 검증되고, git 훅이나 CI에서 specscore change-status로 전환됩니다.
코드가 스펙으로 추적됩니다
OpenSpec에는 추적성 메커니즘이 없습니다. SpecScore는 코드 주석에 specscore: 소스 어노테이션과 Verifies: 커밋 트레일러를 제공합니다. specscore code refs를 실행하면 "어떤 코드가 이 요구사항을 구현하는가?"에 대한 결정적인 답을 얻을 수 있습니다.
런타임 의존성 없음
OpenSpec은 Node.js 20.19+가 필요합니다. SpecScore는 단일 Go 바이너리입니다 — 런타임도, node_modules도 없습니다. Go, Rust, Python, Java 프로젝트에서 Node를 툴체인에 추가하지 않고 사용할 수 있습니다.
조합 가능한 아티팩트 계층 구조
OpenSpec 스펙은 도메인별로 평면적입니다. SpecScore는 타입이 지정된 계층 구조를 가집니다: 아이디어가 기능으로 승격되고, 기능은 요구사항과 인수 기준을 포함하며, 플랜은 인수 기준을 참조하고, 태스크는 플랜을 참조합니다. 모든 관계는 CLI를 통해 기계적으로 탐색할 수 있습니다.
언제 어떤 것을 사용할까.
OpenSpec으로 시작하세요...
- Cursor, Copilot 또는 Claude 이외의 에이전트를 사용하고 즉시 사용 가능한 통합이 필요한 경우.
- 기존 코드베이스에 처음으로 스펙을 추가하고 마찰 없이 시작하고 싶은 경우.
- 팀이 강제 적용보다 스키마 유연성을 중시하는 경우.
SpecScore를 사용하세요...
- 스펙 품질 강제가 필요한 경우 — lint가 에이전트가 토큰을 낭비하기 전에 모호함을 잡아냅니다.
- 코드-스펙 추적성이 필요한 경우 — "어떤 코드가 이 요구사항을 구현하는가?"에 결정적인 답을 제공합니다.
- 다수의 기능, 하위 기능, 라이프사이클 전환이 있는 대규모 시스템을 구축하는 경우.
- 런타임 의존성이 전혀 없기를 원하는 경우 — 바이너리 하나, Node.js 불필요.
- CI에서 스펙 품질 게이트가 필요한 경우 —
specscore lint는 실패 시 ESLint나go vet과 마찬가지로 0이 아닌 코드로 종료합니다.
상호 배타적이지 않습니다.
SpecScore는 OpenSpec의 spec.md 파일을 lint할 수 있습니다. OpenSpec으로 시작한 팀은 마이그레이션 없이 SpecScore의 품질 레이어를 추가할 수 있습니다 — 이미 가지고 있는 스펙을 lint하고, 필요할 때 추적성을 추가하고, 팀이 성장할 때 라이프사이클을 강제하세요.
OpenSpec은 확실한 진입로입니다. SpecScore는 가드레일입니다.
피드백
이 비교는 공개적으로 이용 가능한 문서와 소스 코드를 기반으로 합니다. 잘못되었거나 오래된 정보가 있나요? 수정 issue를 열어주세요. SpecScore를 다른 도구와 비교해 주길 원하시나요? 요청해 주세요.