명세 도구에서 오래 남는 것은 명세가 아니라 아카이브다

명세 도구를 쓸지 말지는 "명세가 코드와 동기화될까"로 판단할 일이 아니다. 그 질문의 답은 20년 전에 나왔다 — 안 된다. 그런데 OpenSpec이 실제로 만드는 산출물을 보면, 오래 남는 건 specs/가 아니라 날짜가 붙어 아카이브로 들어간 변경 폴더다. 그건 명세가 아니라 결정 기록이고, 낡아도 값이 떨어지지 않는 문서다.

도입 판단의 기준을 거기로 옮기면 답이 달라진다.

출처: openspec.dev · github.com/Fission-AI/OpenSpec (MIT)

확인된 것

저장소와 npm 레지스트리에서 직접 확인한 것만 적는다.

2025-08-05 생성, 마지막 푸시 2026-09-17. 별 69,042, 포크 4,736, 열린 이슈 230. MIT. npm @fission-ai/openspec 최신 1.13.1, 누적 49개 버전. Node 20.19.0 이상 필요.
워크플로는 슬래시 명령 다섯 개다. /opsx:explore → /opsx:propose → /opsx:apply → /opsx:verify → /opsx:archive. 기본 프로파일에는 explore와 propose만 들어 있고, 나머지 확장 명령은 openspec config profile로 골라 openspec update를 돌려야 활성화된다.
/opsx:propose가 만드는 건 openspec/changes/<이름>/ 아래 네 파일이다 — proposal.md(왜·무엇), specs/(요구사항과 시나리오), design.md(기술 접근), tasks.md(체크리스트). 끝나면 openspec/changes/archive/<날짜>-<이름>/으로 옮겨진다.
명세 형식은 특수 문법 없는 마크다운이다. ### Requirement: 아래 SHALL 문장, #### Scenario: 아래 WHEN/THEN.
이 저장소는 자기 도구로 자기를 만든다. openspec/ 디렉터리가 실제로 있고, 그 안에 아카이브된 변경 83건과 스펙 디렉터리 36개가 들어 있다. 가장 오래된 아카이브는 프로젝트 초기 것이다.
README의 사용 주석 두 줄이 제품 소개보다 정보량이 많다.

Model selection: OpenSpec works best with high-reasoning models. We recommend Codex 5.5 and Opus 4.7 for both planning and implementation.

Context hygiene: OpenSpec benefits from a clean context window. Clear your context before starting implementation.
홈페이지와 README의 숫자가 다르다. 홈페이지는 지원 에이전트를 50개 이상이라 하고 README는 30개 이상이라고 두 번 쓴다. 홈페이지의 "2초마다 새 명세", "월 26만 5천 명 사용" 같은 수치는 저장소 어디에도 근거가 없다.

판단

1. 값어치는 `specs/`가 아니라 `archive/`에 있다

이런 도구에 늘 따라붙는 반론이 있다. 명세는 결국 코드와 어긋나고, 그러면 코드가 유일한 진실이 된다는 것. 1990년대 UML 코드 생성이 그렇게 끝났다는 지적도 함께 나온다. 절반은 맞다. 살아있는 명세를 유지하는 비용은 실제로 크고, 대부분의 팀은 그걸 감당하지 못한다.

그런데 이 도구가 만드는 건 영구 명세만이 아니다. 변경 하나마다 "왜 이걸 하는가 / 무엇이 바뀌는가 / 어떻게 만들 것인가 / 무엇을 할 것인가" 네 문서가 묶인 폴더가 생기고, 끝나면 날짜가 붙어 봉인된다. 이건 명세보다 ADR(결정 기록)에 가깝다.

차이가 중요하다. 명세는 낡으면 해롭다. 결정 기록은 낡아도 된다. "2026년 9월에 왜 이렇게 했는지"는 시간이 지나도 값이 떨어지지 않고, 오히려 6개월 뒤의 내가 가장 아쉬워하는 정보다. 에이전트에게 맡긴 작업일수록 더 그렇다. 내가 직접 짜지 않은 코드일수록 "왜 이렇게 됐는지"가 머릿속에 없기 때문이다.

그래서 채택한다면 기준은 이것이다. specs/를 살아있는 진실로 유지하려 애쓰지 말고, archive/를 얻기 위해 쓴다. 앞쪽이 낡는 건 예상된 일이고, 그걸로 이 도구의 실패를 말할 수는 없다.

2. 공짜 도구인데 청구서는 늘어난다

README가 스스로 밝힌 조건 두 개를 오늘 아침 하네스 비용 글의 계산법과 붙이면 도입 비용이 보인다.

고추론 모델을 권장한다는 건 싼 모델로 돌리면 효과가 떨어진다는 뜻이다. 구현 전에 컨텍스트를 비우라는 건 작업 하나가 여러 세션으로 쪼개진다는 뜻이다. 합치면 기능 하나에 명세 호출 + 구현 호출 + 검증 호출이 붙고, 각 세션은 새 컨텍스트에서 시작하니 앞 단계의 산출물을 다시 읽어 들인다.

MIT에 로컬 CLI라서 도구값은 0원이다. 늘어나는 건 모델 호출이다. → 도입 전에 계산할 것: 지금 기능 하나에 쓰는 호출 수 × 이 워크플로의 단계 수. 그 곱이 감당되는 작업에만 쓰면 된다. 모든 변경에 다 씌우는 건 비싼 선택이다.

3. "구현 전에 사람이 검토한다"를 강제하는 장치는 이 도구에 없다

제품이 내건 문제 진단은 정확하다. 요구사항이 채팅 기록에만 남으면 다음 세션에서 사라진다. 그건 실제로 겪는 문제다.

그런데 proposal.md를 AI가 쓰고 내가 안 읽으면, 채팅 기록이 파일로 옮겨간 것 이상이 아니다. 오히려 더 나쁠 수 있다 — 파일로 있으면 검토했다는 착각이 생기고, 그 문서가 다음 단계에서 근거로 쓰인다. 읽지 않은 명세가 근거가 되는 구조다.

이 도구는 그 지점을 강제하지 않는다. 그래서 검토를 붙이는 건 내 몫이다. 가장 싼 방법을 하나 제안한다 — proposal.md와 tasks.md를 구현과 별도 커밋으로 올려라. 그러면 계획이 diff로 남고, diff는 사람이 읽게 되어 있다. 같은 커밋에 구현과 섞이면 아무도 계획을 읽지 않는다. (저장소에 없는 내 제안이다.)

4. 도입 판단에 쓸 숫자는 홈페이지가 아니라 `openspec/` 디렉터리다

홈페이지의 "2초마다 새 명세"나 "월 26만 5천 명"은 검증 경로가 없다. 지원 도구 개수는 홈페이지와 README가 아예 다르다.

대신 확인 가능한 게 있다. 저장소가 자기 도구로 자기를 13개월 동안 운영했고, 그 결과로 아카이브된 변경 83건과 스펙 36개가 저장소에 그대로 있다. 이건 마케팅 문구보다 훨씬 강한 증거다 — 실제로 굴러가지 않는 워크플로였다면 83건이 쌓이기 전에 저자들이 먼저 포기했을 것이다.

도구를 살펴볼 때 볼 것도 여기다. 파는 사람이 자기 제품을 쓰고 있는가, 그 흔적이 저장소에 남아 있는가. 별 개수보다 이쪽이 읽을 게 많다.

모르는 것

직접 설치해 돌려보지 않았다. 위 판단은 저장소·README·npm 레지스트리 독해에서 나온 것이다.
83건의 아카이브가 실제로 유용하게 참조되는지는 확인할 수 없다. 쌓였다는 것과 읽힌다는 것은 다르다.
/opsx:verify가 구현과 명세의 불일치를 실제로 어느 정도 잡아내는지 모른다. 검증의 정확도에 대한 수치가 저장소에 없다.
고추론 모델 권장이 얼마나 차이를 내는지 비교 데이터가 없다. 싼 모델로 돌리면 못 쓸 정도인지, 조금 나쁜 정도인지 모른다.
브라운필드 적용을 표방하지만, 기존 코드베이스에서 초기 명세를 뽑는 비용이 어느 정도인지에 대한 수치를 찾지 못했다.
Stores(저장소 분리 계획 공유)는 베타라고 명시돼 있다. 팀 단위 기능은 평가 범위 밖에 뒀다.