AI 코딩 에이전트와 팀을 한 스펙으로 묶는 OpenSpec, 스타 6만 8천 돌파

OpenSpec은 소프트웨어를 만들 때 "무엇을 만들 것인가"를 먼저 스펙으로 적어 두고, 그 문서를 팀과 AI 코딩 에이전트가 함께 참조하도록 만드는 경량 프레임워크다. 요구사항을 다듬는 일, 그 요구사항이 정말 만들어야 할 대상을 향하고 있는지 검증하는 일, 그리고 실제 구현이 스펙과 어긋나지 않는지 확인하는 일을 하나의 흐름으로 묶는다. 설정 부담을 줄이면서 프로젝트마다 다르게 적용할 수 있다는 점을 전면에 내세운다.

설치는 npm 전역 설치 한 줄이면 된다. `npm install -g @fission-ai/openspec@latest` 형태로 받고, 현재 버전은 v1.13.0이다. 프로젝트가 공개한 수치에 따르면 GitHub 스타는 68.0k를 넘었고, OpenSpec으로 2초마다 새 스펙이 하나씩 생성되고 있다. 개인이 실험하는 단계를 지나 팀 단위 워크플로에 들어가고 있다는 신호로 읽힌다.

특정 벤더에 묶이지 않는다는 점도 눈에 띈다. Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, OpenCode, Amazon Q Developer, Cline, Continue, Devin Desktop, Qwen Code, Trae, Zed Agent 등이 지원 목록에 이름을 올렸고, 여기에 33개 이상이 더 붙는다. 이미 쓰고 있는 에이전트를 바꾸지 않고도 스펙 계층을 얹을 수 있다는 뜻이다.

작업은 슬래시 명령으로 진행된다. `/opsx:explore`는 문제를 지도처럼 정리하고 코드베이스를 파악하는 단계, `/opsx:propose`는 proposal.md와 specs/, design.md, tasks.md 초안을 만드는 단계다. `/opsx:apply`는 스펙에 적힌 태스크를 실제로 구현하고, `/opsx:verify`는 구현이 스펙과 맞는지 확인하며, `/opsx:archive`는 끝난 변경을 보관한다. 탐색에서 제안, 구현, 검증, 아카이빙까지가 하나의 사이클로 이어진다.

배경에는 에이전트 코딩의 구조적 문제가 있다. 대화형으로 코드를 뽑아내는 방식은 세션이 길어지거나 끊기면 의도가 흐려지고, 나중에 합류한 사람이나 다른 에이전트는 왜 그렇게 짰는지 알 방법이 없다. 그래서 요구사항을 저장소 안의 문서로 남기고 그것을 단일 기준으로 삼자는 스펙 주도 개발(spec-driven development) 흐름이 자리를 잡고 있다. OpenSpec은 이 흐름을 도구 수준에서 밀어붙인 사례다.

실무에서 달라지는 지점은 검증 기준이 생긴다는 것이다. 에이전트가 만든 코드를 리뷰할 때 "요청한 대로 동작하는가"를 넘어 "스펙에 적힌 요구사항과 일치하는가"를 따질 수 있고, 스펙 자체도 리뷰와 변경 이력 관리의 대상이 된다. 도입을 검토한다면 기존 저장소에 specs/ 디렉터리를 어떻게 배치할지, PR과 CI 파이프라인에 verify 단계를 어디에 끼워 넣을지, 팀이 쓰는 에이전트가 지원 목록에 있는지를 먼저 확인하는 편이 좋다.

다만 스펙을 잘 쓰는 일과 스펙을 잘 지키는 일은 별개다. 프레임워크가 요구사항의 품질이나 "올바른 것을 만들고 있는가"라는 판단까지 대신해 주지는 않으며, 결국 그 판단은 사람의 몫으로 남는다. 스펙 문서를 별도 산출물로 유지해야 하는 관리 부담도 생기고, 에이전트별로 명령 지원 범위가 다를 수 있으므로 실제 환경에서 먼저 검증하는 절차가 필요하다.