OpenSpec vs Spec Kit: AI 에이전트 개발을 위한 스펙 주도 프레임워크 선택

AI 코딩 에이전트는 어떤 인간보다도 빠르게 코드를 작성합니다. 병목은 이동했습니다: 이제 스펙이 제품입니다. 에이전트에 명확하고 구조화된 사양(specification)이 없으면, 아키텍처를 환각하고 요구사항을 날조하며 아무도 요청하지 않은 테스트를 통과하는 코드를 생산합니다.

이를 해결하기 위해 두 프레임워크가 등장했습니다: OpenSpec(GitHub 스타 약 28k)과 GitHub의 Spec Kit(약 75k 스타)입니다. 둘 다 MIT 라이선스입니다. 둘 다 AI 에이전트가 직접 사용하는 슬래시 명령을 생성합니다. 하지만 속도와 거버넌스 사이에서 근본적으로 다른 트레이드오프를 만들며 — 잘못된 것을 고르면 팀에 몇 주의 재작업 비용이 발생합니다.

선택 방법은 다음과 같습니다.

핵심 분할: 유연한 반복 vs 구조화된 거버넌스

OpenSpec은 Node.js CLI(@fission-ai/openspec)로 스펙을 가볍고 저장소에 네이티브인 산물로 취급합니다. 작업을 제안, 사양, 디자인, 작업 파일을 포함하는 변경 폴더로 구성합니다. 철학은 최소한의 의식 — 에이전트에게 스펙을 빠르게 전달하고, 반복하고, 완료되면 보관하는 것입니다.

Spec Kit(GitHub의 프레임워크, specify CLI와 /speckit.* 명령 중심)은 모든 것을 **constitution(헌장)**에 기반합니다. 제약, 코딩 표준, TDD 요구사항, 컴플라이언스 규칙을 인코딩하는 프로젝트 수준 문서입니다. 모든 기능은 각 게이트에서 템플릿과 체크리스트를 갖춘 구조화된 단계 파이프라인을 통해 흐릅니다.

차이는 표면적이지 않습니다. 팀이 기능별로 흡수하는 오버헤드 양, 프롬프트당 에이전트가 소비하는 컨텍스트 양, 감사 추적이 컴플라이언스 검토자를 만족시키는지 여부를 결정합니다.

워크플로 비교

OpenSpec: 네 명령, 최소 마찰

OpenSpec의 워크플로는 의도적으로 짧습니다:

graph LR
    A["/opsx:propose"] --> B["/opsx:explore"]
    B --> C["/opsx:apply"]
    C --> D["/opsx:archive"]

1. /opsx:propose — 제안 문서와 함께 변경 폴더 생성
2. /opsx:explore — 해당 폴더 내에서 스펙과 디자인 반복
3. /opsx:apply — 확정된 스펙을 기반으로 구현 실행
4. /opsx:archive — 완료된 작업을 아카이브로 이동

그게 전부입니다. constitution 없음. 필수 명확화 단계 없음. 작업 분해 게이트 없음. 제안하고, 탐색하고, 적용하고, 보관합니다. apply에서 explore로 다시 돌아가야 한다면 그냥 하면 됩니다 — 당신을 막는 단계 게이트 강제가 없습니다.

OpenSpec은 프롬프트 부풀림을 방지하기 위해 50KB 컨텍스트 한계를 강제합니다. 이는 의도적인 설계 선택입니다: OpenSpec 스펙으로 작업하는 에이전트는 과도하게 큰 컨텍스트 창으로 인해 멈추지 않으며, 모노레포 전반에 여러 에이전트를 실행할 때 중요합니다.

Spec Kit: 6단계, Constitution 기반

Spec Kit의 파이프라인은 더 광범위합니다:

graph LR
    A["/speckit.constitution"] --> B["/speckit.specify"]
    B --> C["/speckit.clarify"]
    C --> D["/speckit.plan"]
    D --> E["/speckit.tasks"]
    E --> F["/speckit.implement"]
    G["/speckit.analyze"] -.-> B

1. /speckit.constitution — 프로젝트 전체 규칙, 제약, 표준 정의
2. /speckit.specify — 상세 기능 사양 생성
3. /speckit.clarify — 모호성과 미해결 질문 해결
4. /speckit.plan — 구현 계획 생성
5. /speckit.tasks — 계획을 개별 할당 가능한 작업으로 분해
6. /speckit.implement — TDD 게이트와 체크리스트 검증으로 작업 실행
7. /speckit.analyze(선택) — 변경 사항을 명세하기 전에 기존 코드 분석

constitution이 핵심 차별화 요소입니다. 이후의 모든 명령이 존중하는 살아 있는 문서입니다. constitution에 “모든 데이터베이스 변경은 마이그레이션 스크립트가 필요” 또는 “재시도 로직 없는 직접 API 호출 금지"라고 쓰여 있다면, 에이전트는 모든 단계에서 그 규칙을 강제합니다. 규제 산업 — 의료, 금융, 정부 — 의 경우, 이것이 개발 워크플로 자체에 컴플라이언스 요구사항을 인코딩하기 위해 정확히 필요한 메커니즘입니다.

직접 비교

컨텍스트 세금 문제

Spec Kit의 강력함은 비용을 수반합니다. 설치된 모든 슬래시 명령, 모든 템플릿, 모든 constitution 규칙이 에이전트의 컨텍스트 창에 토큰을 추가합니다. 여러 확장과 함께 Spec Kit을 실행하는 팀은 상당한 컨텍스트 세금을 보고합니다 — 에이전트가 코드에 대해 추론하는 대신 프레임워크 지침을 파싱하는 데 토큰을 소비합니다.

이는 규모가 커질수록 중요합니다. 큰 코드베이스에 Spec Kit의 전체 명령 세트를 로드한 상태로 Claude Code나 Codex를 실행 중이라면, 프레임워크 오버헤드에 컨텍스트를 소비하고 있는 것입니다. 일부 팀은 실용적인 토큰 예산 내에 머물기 위해 확장을 가지치기하거나 constitution을 분할해야 했다고 보고했습니다.

OpenSpec은 50KB 컨텍스트 한계로 이를 우회합니다. 무식한 도구이지만 — 같은 수준의 거버넌스 깊이를 인코딩할 수는 없습니다 — 하지만 에이전트가 프레임워크 메타데이터가 아닌 실제 사양에 집중하게 유지합니다.

엔터프라이즈 결론: 에이전트가 이미 컨텍스트가 제한된 상태라면(큰 코드베이스, 복잡한 시스템 프롬프트, 다중 파일 변경), 커밋하기 전에 Spec Kit 명령 세트의 토큰 비용을 측정하세요. OpenSpec의 상한은 더 낮지만 예측 가능합니다.

OpenSpec을 사용해야 할 때

OpenSpec을 선택할 때:

• 속도가 프로세스보다 중요한 빠른 프로토타이핑 또는 개념 증명 작업을 수행 중일 때
• 팀이 여러 AI 에이전트 도구를 사용하며 모두에 작동하는 단일 가벼운 스펙 계층을 원할 때
• 단계 게이트와 싸우지 않고 구현이 시작된 후 스펙을 변경하는 등 중간에 반복해야 할 때
• 코드베이스가 충분히 커서 컨텍스트 예산이 실질적 제약인 경우
• 전체 거버넌스 프레임워크를 채택하지 않고 스펙 주도 개발을 원할 때

OpenSpec의 “core” 프로파일은 스펙 주도 AI 개발에 대한 가장 낮은 마찰 진입점입니다. CLI를 설치하고, 변경 폴더를 만들면, 에이전트가 작업할 구조화된 스펙을 갖게 됩니다. 작성할 constitution도, 큐레이션할 확장 카탈로그도 없습니다.

Spec Kit을 사용해야 할 때

Spec Kit을 선택할 때:

• 거버넌스와 반복 가능성이 오버헤드를 정당화하는 프로덕션 시스템을 구축 중일 때
• 조직이 규제 도메인(의료, 금융, 정부)에서 운영되며 개발 워크플로에 컴플라이언스 규칙을 인코딩해야 할 때
• TDD 강제를 나중에 덧붙이는 것이 아니라 프레임워크에 내장하길 원할 때
• 팀이 구조화된 단계 게이트의 이익을 볼 때 — 구현 전 계획, 계획 전 명확화
• 조직 특정 워크플로를 위해 훅과 큐레이션된 확장 카탈로그를 통한 확장성이 필요할 때

Spec Kit의 constitution 모델은 엔터프라이즈 환경에서 진정으로 강력합니다. “모든 API 엔드포인트는 OpenAPI 문서가 필요” 또는 “모든 상태 변경은 이벤트 소싱이 필요"를 constitution 규칙으로 인코딩하면, 에이전트가 매번 자동으로 강제합니다. 그것은 거버넌스 쇼가 아닙니다 — 실제로 실행되는 거버넌스입니다.

하이브리드 접근: 가볍게 시작, 구조 추가

이 두 프레임워크는 철학적으로 상호 배타적이지 않습니다. 많은 엔터프라이즈 팀을 위한 실용적 경로:

1. 초기 탐색과 프로토타이핑에는 OpenSpec으로 시작하세요. 오버헤드 없이 스펙 습관을 확립합니다.
2. 프로젝트가 프로덕션으로 넘어가 거버넌스, 컴플라이언스 인코딩, 반복 가능한 단계 워크플로가 필요해지면 Spec Kit으로 이동하세요.
3. Spec Kit의 의식이 속도를 늦추는 사이드 프로젝트, 내부 도구, 빠른 실험은 OpenSpec 유지하세요.

가장 나쁜 결과는 스펙 프레임워크가 아예 없는 것입니다 — 모호한 프롬프트로 작업하며 아무도 작성하지 않은 요구사항에 대해 검토하지 않은 코드를 생산하는 에이전트.

실행 가능한 결론

1. 스펙 주도 개발은 더 이상 선택이 아닙니다. AI 에이전트에 구조화된 스펙이 없다면, 환각된 요구사항을 디버깅하고 있는 것입니다. 프레임워크를 선택하세요.

2. 컨텍스트 예산을 먼저 측정하세요. Spec Kit의 전체 명령 세트를 로드한 상태로 에이전트를 실행하고 얼마나 많은 토큰이 프레임워크 오버헤드로 가는지 확인하세요. 컨텍스트 창의 15-20%를 초과한다면, OpenSpec 또는 다듬어진 Spec Kit 구성을 고려하세요.

3. 규제 산업의 경우, Spec Kit의 constitution은 스스로 비용을 지불합니다. 에이전트가 자동으로 강제하는 컴플라이언스 규칙을 인코딩하는 것은 추가 산물 오버헤드를 감수할 가치가 있습니다. 대안은 규제 컴플라이언스를 위해 에이전트 생성 변경 사항을 수동 검토하는 것입니다.

4. 빠른 프로토타이핑에는 OpenSpec이 속도에서 이깁니다. 네 명령, 50KB 컨텍스트 한계, 유지할 constitution 없음. 에이전트에게 빠르게 스펙을 전달합니다.

5. 아카이브/정리 단계를 건너뛰지 마세요. 두 프레임워크 모두 완료된 작업을 아카이브를 지원합니다. 저장소에 있는 오래된 스펙은 향후 실행에서 에이전트를 혼란스럽게 합니다. 적극적으로 보관하세요.

6. 실제 스택에 대해 둘 다 평가하세요. 각 프레임워크의 예제 저장소를 복제하고, 선호하는 AI 에이전트로 코드베이스에 대해 실행하고, 출력 품질과 토큰 비용을 비교하세요. 올바른 선택은 팀의 거버넌스 요구에 따라 결정되며, GitHub 스타 수가 아닙니다.