Spec Kit vs OpenSpec 비교: 내 AI 코딩 워크플로에 맞는 것은?

Spec Kit과 OpenSpec은 둘 다 MIT 라이선스의 오픈 소스 도구이며 같은 문제를 풉니다. 요구 사항이 채팅 기록에만 있으면 AI 코딩 어시스턴트의 결과를 예측하기 어려우므로, 스펙을 먼저 글로 남기고 코드를 쓰기 전에 사람과 AI가 합의하게 하는 것입니다. 둘의 차이는 프로세스의 무게, 스펙을 조직하는 방식, 도구 체인에 있습니다.

먼저 우리의 입장부터

HagiCode 자체의 워크플로는 OpenSpec을 기반으로 하므로 우리에게는 선호가 있습니다. 아래 사실은 두 프로젝트의 공식 문서를 2026-10-26에 확인한 내용이고, 우리의 의견인 부분은 그렇게 표시했습니다. 두 프로젝트 모두 빠르게 바뀌므로 선택하기 전에 각각의 최신 문서를 다시 확인하세요.

무엇을 비교하나

Spec Kit: GitHub에서 만들었습니다. 명령줄 도구는 specify(Python 패키지 specify-cli)이며, 설치와 사용법은 Spec Kit 설치 방법에 있습니다.
OpenSpec: Fission AI에서 만들었습니다. 명령줄 도구는 openspec(npm 패키지 @fission-ai/openspec)이며, 소개는 OpenSpec 소개에 있습니다.

주요 차이

항목	Spec Kit	OpenSpec
실행 환경	Python 3.11+, uv 또는 pipx로 설치	Node.js 20.19.0+, npm 또는 Homebrew로 설치
설치 명령	`uv tool install specify-cli`	`npm install -g @fission-ai/openspec@latest`
초기화	`specify init my-project --integration claude`	프로젝트 안에서 `openspec init`
명령 접두사	`/speckit-*`	`/opsx:`(일부 어시스턴트는 `/opsx-`, Codex는 `$openspec-*`)
주요 흐름	constitution → specify → clarify → plan → checklist → tasks → analyze → implement → converge. 가장 짧은 경로는 specify → plan → tasks → implement → converge	기본 프로필은 propose, explore, apply, update, sync, archive. 확장 프로필에는 new, continue, ff, verify 등이 추가됨
기능별 산출물	`spec.md`, `plan.md`, `tasks.md`와 체크리스트, 분석 결과	`proposal.md`, `specs/`, `design.md`, `tasks.md`가 들어 있는 변경 폴더 하나
스펙 조직 방식	기능 하나를 중심으로 완전한 스펙을 작성	델타 스펙이 중심. `ADDED`와 `MODIFIED`로 변경을 기술하고 아카이브할 때 장기 스펙에 병합
확장성	확장(extension)과 프리셋(preset). 공식으로 bug, assess 등이 있음	사용자 정의 스키마와 커뮤니티 스키마
여러 저장소	공식 문서의 핵심 흐름에서는 전용 멀티 저장소 지원을 찾지 못했습니다	Stores(베타)가 기획을 별도 저장소에 두고 여러 코드 저장소와 공유
지원 어시스턴트	공식 문서에 수십 개의 통합이 나열됨	공식 문서에 30개 이상의 도구를 지원한다고 나와 있음
라이선스	MIT	MIT

프로세스의 무게: 가장 자주 나오는 차이

OpenSpec의 README는 Spec Kit을 철저하지만 무겁다고 요약합니다. 단계 게이트가 엄격하고, Markdown이 많고, Python 환경이 필요하다는 것입니다. 그리고 자신은 더 가볍고 어떤 산출물이든 언제든 고칠 수 있다고 소개합니다. 이것은 OpenSpec 쪽의 설명입니다.

공정하게 보면, Spec Kit의 빠른 시작도 constitution, clarify, checklist, analyze가 모두 선택 사항인 5단계 최단 경로를 제시하고, OpenSpec도 확장 프로필에서는 명령이 꽤 많습니다. 진짜 차이는 명령 개수가 아니라 기본 자세입니다. Spec Kit은 스펙에서 구현까지 이어지고 마지막에 수렴시키는 파이프라인에 가깝고, OpenSpec은 각 변경이 언제든 수정할 수 있는 독립된 폴더라는 점을 강조합니다.

상황별 선택

아래 조언은 우리의 판단이며 두 프로젝트의 공식 결론이 아닙니다.

내 상황	더 맞는 선택	이유
새 프로젝트이고 스펙부터 구현까지 완결된 흐름을 원함	Spec Kit	흐름이 완전하고, constitution이 프로젝트 전체를 제약하며, `converge`가 스펙과 대조해 마무리함
기존 코드가 많고 매번 작은 부분만 바꿈	OpenSpec	델타 스펙은 바뀌는 부분만 기술하므로 기존 기능의 전체 스펙을 다시 쓸 필요가 없음
팀이 주로 Python이고 uv에 익숙함	Spec Kit	설치 방식이 기술 스택과 맞음
팀이 주로 Node.js를 씀	OpenSpec	npm 명령 하나로 설치됨
기능 하나가 여러 저장소를 건드림	OpenSpec	Stores로 기획을 공유 저장소에 둘 수 있음. 아직 베타라는 점은 유의
이미 만들어진 확장이 많았으면 함(버그 수정, 아이디어 평가)	Spec Kit	공식 사이트에 나열된 확장과 프리셋이 더 많음
요구 사항이 자주 바뀌어 스펙과 계획을 언제든 고치고 싶음	OpenSpec	산출물에 엄격한 단계가 없어 돌아가서 수정할 수 있음

결정 가이드

기능보다 먼저 기술 스택과 습관을 보세요. 두 도구는 기능이 많이 겹치므로, 환경이 맞지 않아서 생기는 마찰이 더 큰 경우가 많습니다.
같은 작은 기능으로 각각 한 번씩 돌려 보세요. 반나절이면 끝날 요구 사항을 골라 각각 전체 흐름을 밟아 보는 편이 비교 글 열 편을 읽는 것보다 믿을 만합니다.
한 프로젝트에 둘 다 설치하지 마세요. 두 도구 모두 프로젝트에 명령과 디렉터리를 생성하므로 섞으면 어시스턴트의 명령 목록이 어지러워집니다.
세 가지로 평가하세요. 스펙을 쓴 뒤 재작업이 실제로 줄었는지, 내가 쓰는 AI 어시스턴트가 공식 지원되는지, 팀이 이 Markdown 파일들을 기꺼이 관리하는지입니다.

HagiCode의 방식

우리는 오랫동안 OpenSpec을 써 왔고, 그 위에 여러 저장소의 스펙 관리와 단계별 Agent 선택을 구축했습니다. 이 내용은 두 글에 정리되어 있습니다: 다양한 Agent로 OpenSpec 각 단계 효율 최적화: HagiCode 실전 정리, MonoSpecs는 무엇인가: 왜 OpenSpec의 추가 업그레이드와 확장이라고 하는가. 이것은 우리의 선택일 뿐 모든 팀에 더 낫다는 뜻은 아닙니다. 팀에 Spec Kit이 더 맞는다면 HagiCode가 지원하는 Claude Code, Codex 같은 Agent CLI와도 똑같이 쓸 수 있습니다. 준비 방법은 AI Agent CLI 설치를 보세요.