최근 r/SpecDrivenDevelopment의 한 빌더가 SuperPowers, OpenSpec, 그리고 Spec Kit의 차이점을 신중하고 정직하게 설명했습니다. 그는 분명히 사전 조사를 철저히 한 상태였습니다. 그는 SuperPowers는 타임스탬프가 찍힌 스펙(specs)을 누적하여 보관하고, OpenSpec은 모든 것을 단일 스펙 아티팩트(spec artifact)로 병합하며, Spec Kit은 전체 흐름을 스캐폴딩(scaffolding)한다는 점을 말해줄 수 있었습니다. 그리고 그는 해당 스레드에서 가장 정직한 문장으로 마무리했습니다.

"우리 모두 여전히 이 기능들을 파악해 나가는 과정에 있다고 생각합니다. 때로는 그냥 뛰어들어 시도해 보는 것이 최선입니다."

그 문장이 바로 현재 스펙 주도 개발 (Spec-Driven Development, SDD)의 실상입니다. 어떤 도구가 승리하느냐가 아닙니다. 사려 깊고 의욕적인 빌더들이 기능을 출시하는 대신 저녁 시간을 할애하여 CLI를 비교하고 있다는 사실, 즉 툴링 레이어 (tooling layer)가 누구도 따라잡을 수 없을 만큼 빠르게 움직이고 있다는 사실입니다. 도구를 쇼핑하는 것 자체가 업무가 되어버렸습니다.

테스트해 볼 가치가 있는 가설은 다음과 같습니다: 스펙 주도 개발을 위해 선택하는 도구는 당신이 생각하는 것보다 훨씬 덜 중요하며, 도구를 선택하는 데 소비하는 시간은 대부분 낭비라는 것입니다. 왜냐하면 이 모든 도구의 밑바탕에 깔린 관행은 동일하며, 그 관행만이 유일하게 지속 가능한 부분이기 때문입니다.

도구들은 실제로 다르지만 (대부분 중요하지 않습니다)

먼저 도구들에 대해 공정하게 말해봅시다. 왜냐하면 그것들은 실재하며 훌륭하기 때문입니다.

OpenSpec은 6개월도 채 되지 않아 GitHub 스타 27,000개를 돌파한 가벼운 오픈 소스 프레임워크입니다. 이 도구의 핵심 제안은 제안(propose), 적용(apply), 아카이브(archive)라는 최소한의 3단계 루프입니다. 스펙은 저장소(repo) 내에 마크다운(markdown) 형태로 존재하며, API 키나 MCP가 필요하지 않습니다. Thoughtworks의 Technology Radar는 바로 그 미니멀리즘을 정확히 찬양했습니다: "유연하고 미니멀한 워크플로우(fluid, minimal workflow)."

GitHub Spec Kit은 스캐폴딩(scaffolding) 중심의 옵션입니다. 이는 스펙에서 계획을 거쳐 작업(tasks)으로 이어지는 구조화된 명령 세트와 템플릿을 제공하며, 종종 EARS 구문으로 수락 기준(acceptance criteria)을 생성합니다. 이 도구는 단계(phases)에 대해 확고한 견해(opinionated)를 가지고 있습니다.

SuperPowers는 또 다른 입장을 취합니다. 바로 명세(specs)가 타임스탬프를 가지며 시간이 지남에 따라 누적된다는 것입니다. 따라서 하나의 통합된 문서 대신 의도(intent)의 실행 기록을 얻게 됩니다.

이것들은 실제로 차이가 있습니다. 만약 이런 비교하는 것을 즐기는 분이라면, 기분 좋은 주말을 보내며 이들을 비교할 수 있을 겁니다. 하지만 여러분이 실제로 무엇을 비교하고 있는지 주목하세요. 여러분은 각 도구가 동일한 네 가지 항목—원하는 것의 설명, 그것을 구축하기 위한 계획, 완료되었음을 알기 위한 기준(criteria), 그리고 결정 기록(record of decisions)—을 어떻게 저장하고 순서화하는지를 비교하고 있는 것입니다. 저장 형식(storage format)이 변수입니다. 이 네 가지 항목은 상수입니다.

이것이 재정의(reframe)입니다. 명세 기반 도구들은 여러분이 명세를 작성해야 하는지에 대해 경쟁하는 것이 아닙니다. 그들은 이 점에 대해서는 완전히 동의합니다. 그들이 경쟁하는 것은 파일 레이아웃(file layout)입니다.

실제로 살아남는 것

여기서 도구 비교에 깊이 빠진 사람들에게는 불편한 지점이 있습니다.

이 계층이 얼마나 빠르게 변화하고 있는지 보세요. Latent.Space는 최근 'meta-harness summer'라고 불리는 것을 목록화했습니다: Conductor, Zed의 ACP, Vercel의 Eve, HarnessAgent, Databricks의 Omnigent 등, 매주 새로운 오케스트레이션 레이어가 등장합니다. SDD 도구들도 한 계층 아래에 자리하고 있으며, 이들 역시 똑같이 빠르게 변화하고 있습니다. 여러분이 이번 달에 신중하게 선택한 도구가 봄이 되기 전에 유지보수되지 않거나, 비교 스레드를 읽기 시작했을 때 존재하지 않았던 무언가에 의해 대체될 수 있습니다.

그렇다면 무엇이 이 변화 속에서 살아남을까요?

도구가 아닙니다. 명세(spec)입니다.

무엇을 구축하는지, 그리고 왜 구축하는지를 설명하는 요구사항. 완료되었음을 정의하는 승인 기준(acceptance criteria). 6개월 후에도 코드가 현재와 같은 이유를 설명해 주는 결정 기록. 이 아티팩트들은 일반 텍스트 파일입니다. 이들을 생성한 어떤 CLI보다도 오래갑니다. 여러분은 이것들을 OpenSpec에서 Spec Kit으로, 다시 텍스트 파일로, 혹은 완전히 다른 도구로 옮길 수 있으며, 아무것도 잃지 않을 것입니다. 왜냐하면 애초에 그것들은 도구 자체에 관한 것이 아니었기 때문입니다.

자신의 Claude Code 기여분 100%를 Claude Code로 작성한다고 보고한 Boris Cherny는 현재 자신의 업무를 루프 (loops)를 작성하고 그것들이 스스로를 검증할 수 있도록 보장하는 일이라고 설명합니다. 루프는 그가 소유하는 것이고, 모델은 빌려 쓰는 것입니다. 이와 동일한 논리가 한 단계 위에도 적용됩니다. 스펙 (spec)은 당신이 소유하는 것이고, 도구는 빌려 쓰는 것입니다.

이런 관점으로 바라보게 되면, 비교 쇼핑의 양상이 달라 보입니다. 당신은 방법론을 선택하고 있었던 것이 아닙니다. 실제로 중요한 것을 담기 위한 일시적인 컨테이너를 선택하고 있었던 것입니다.

세 가지 방식 모두에 깔린 실천법

OpenSpec, Spec Kit, SuperPowers를 완전히 걷어내고 나면, 이들 모두가 인코딩(encode)하려고 시도하는 실천법이 드러납니다. 이는 세 가지 습관으로 요약됩니다.

기능(feature)당 하나의 스펙. 제품 전체를 위한 40페이지짜리 문서도 아니고, 한 줄짜리 프롬프트(prompt)도 아닙니다. 에이전트 (agent)가 구축할 수 있고 당신이 확인할 수 있을 만큼 범위를 좁게 설정하여, 단일 구축 가능한 대상에 대해 집중적으로 기술한 것입니다.

에이전트가 코드를 작성하기 전에 검토할 수 있는 계획. 먼저 계획을 세우는 목적은 관료주의를 위한 것이 아닙니다. 문단 하나에서 잘못된 가정을 잡아내는 데는 몇 분이 걸리지만, 생성된 코드베이스 (codebase)에서 이를 잡아내는 데는 오후 전체가 걸리기 때문입니다. 계획은 당신이 미처 생각하지 못했던 질문들을 발견하는 곳입니다.

축적되는 기준. 각 기능의 수락 기준 (acceptance criteria)은 당신의 제품이 무엇을 해야 하는지에 대한 성장하는 기록의 일부가 됩니다. 그 기록은 나중에 이미 작동하던 것을 망가뜨리지 않고도 변경할 수 있게 해주며, 특정 기능이 완료되었는지 아니면 완료된 것처럼 보일 뿐인지를 명확하게 알려줍니다.

그게 전부입니다. 그것이 스펙 기반 개발 (spec-driven development)의 전부이며, 정의상 도구에 구애받지 않습니다 (tool-agnostic). r/SpecDrivenDevelopment 게시자는 사실 거의 토씨 하나 틀리지 않고 이미 이 점을 파악하고 있었습니다. 그는 공유 모델을 "기능당 하나의 스펙, 스펙당 하나의 계획"이라고 설명했습니다. 그는 단지 도구 비교에 계속 신경을 쓰고 있었기 때문에, 자신이 정답을 찾아냈다는 사실을 알지 못했을 뿐입니다.

그 차이를 구체적으로 생각해 봅시다.

도구 중심 사고 (Tool-first thinking): "OpenSpec을 써야 할까, 아니면 Spec Kit을 써야 할까? OpenSpec은 더 가볍지만 Spec Kit은 더 나은 작업 템플릿 (task templates)을 가지고 있어. 하지만 SuperPowers의 누적 모델 (accumulation model)이 내 작업 방식에는 더 잘 맞는데, 지금 당장은 OpenSpec 주변의 커뮤니티가 더 크네."

실행 중심 사고 (Practice-first thinking): "이 기능은 '사용자가 이메일로 비밀번호를 재설정할 수 있게 한다'야. 완료된 상태의 모습은 이래: 로그아웃된 사용자가 재설정을 요청하고, 한 시간 동안 유효한 일회용 링크를 받으며, 새 비밀번호를 설정하면 기존 비밀번호는 더 이상 작동하지 않아야 해. 자, 이제 어떤 도구가 이러한 기준에 맞춰 이를 구축하는 데 도움이 될까?"

두 번째 빌더는 제품을 출시할 것입니다. 첫 번째 빌더는 계속해서 비교 스레드(comparison threads)만 읽고 있을 것입니다.

BrainGrid의 위치

이것이 바로 BrainGrid가 메우기 위해 만들어진 간극이며, 어떻게 메우는지에 대해 정확히 짚고 넘어갈 가치가 있습니다.

SDD 도구들은 프레임워크 (framework)를 건네주고 당신이 그것을 실행하도록 내버려 둡니다. CLI를 설치하고, 명령어를 배우고, 에이전트 (agent)에 연결하고, 매번 단계를 따르는 것을 기억해야 합니다. 그 방식은 타당하지만, 당신이 직접 조립하고 유지 관리해야 하며, 이는 바로 r/SpecDrivenDevelopment 스레드가 가득 차 있는 바로 그 노동입니다. (만약 특정 도구의 트레이드오프 (tradeoffs)를 더 깊이 살펴보고 싶다면, 우리는 Kiro와 BrainGrid의 스펙 주도 개발 (spec-driven development)에 대한 견해 비교와 각각이 어디에 적합한지를 비교했습니다.)

BrainGrid는 이 관행을 프레임워크 (framework)가 아닌 제품 (product)으로서 제공합니다. 사용자가 기능을 설명하면, Planning Agent (기획 에이전트)가 이를 수락 기준 (acceptance criteria), 데이터 모델 (data models), 그리고 디자인 (designs)을 포함한 요구사항 (requirement)으로 변환하며, 코드가 작성되기 전에 모호한 부분을 지적하고 미처 생각하지 못했던 질문을 던집니다. 이것이 바로 "기능당 하나의 명세 (one spec per feature), 명세당 하나의 계획 (one plan per spec)"이며, 사용자가 직접 설정하는 것이 아니라 시스템이 대신 수행해 주는 방식입니다. 그 후 Builder Agent (빌더 에이전트)가 두 가지 방식으로 이를 구축합니다. 하나는 실시간 미리보기가 가능하고 풀 리퀘스트 (pull request)를 생성하는 샌드박스인 BrainGrid Cloud 방식이며, 다른 하나는 MCP를 통해 Claude Code, Cursor, 또는 Codex를 사용하여 사용자의 GitHub 리포지토리 (repo) 내 로컬 컴퓨터에서 구축하는 방식입니다. 어떤 에이전트를 지정하더라도 계획과 기준은 동일합니다. 모든 기능은 기획에서 빌드, 그리고 배포에 이르기까지 보드 위에서 흐르며, 명세 (specs), 결정 사항, 그리고 검증 (verifications) 결과는 제품의 기록으로 축적됩니다. 에이전트를 바꾸거나 모델 (model)을 바꾸더라도 워크플로우 (workflow)는 유지됩니다.

이 구조적인 핵심은 도구들이 전달하고자 하는 바와 동일하지만, 조립 과정이 생략되어 있다는 점이 다릅니다. 즉, 명세 (spec)가 지속 가능한 자산 (durable asset)이며, 증거가 의도한 바와 일치한다고 말하기 전까지는 기능이 완료된 것이 아닙니다. 사용자가 파일 형식을 선택하고 규율을 지키기를 바라는 것이 아닙니다. 규율 그 자체가 바로 제품입니다.

솔직한 트레이드오프 (Trade-Off)

여기에는 실제적인 비용이 따르며, 이는 BrainGrid에 유리한 점만큼이나 불리한 점이기도 합니다.

만약 사용자가 자신의 도구를 직접 제어하는 것을 선호한다면, OpenSpec과 같은 오픈 소스 프레임워크 (open-source framework)는 모든 파일과 모든 단계에 대한 완전한 통제권을 제공합니다. 사용자가 전체 스택 (stack)을 소유하게 됩니다. 일부 빌더들은 진심으로 그것을 원하며, 그들에게 비교 쇼핑은 낭비가 아니라 장인 정신 (craft)의 영역입니다. 반면 관리형 제품 (managed product)은 그러한 통제권을 대신하여 '모든 것이 대신 수행되는 편리함'을 맞바꿉니다. 이것은 실질적인 선택의 문제이며, 모든 사람에게 정답인 것은 아닙니다.

하지만 대부분의 빌더들, 특히 "우리는 여전히 이 모든 것들을 파악해 나가는 중입니다"라고 말하는 이들에게 통제권은 핵심이 아닙니다. 핵심은 출시(Shipping)입니다. (만약 당신이 구체적으로 오픈 소스 프레임워크들을 비교하고 있다면, 저희의 BrainGrid vs Spec Kit 비교를 통해 그 트레이드오프(tradeoff)를 자세히 살펴볼 수 있습니다.) 그리고 도구 비교 스레드들이 가리고 있는 진실은, 당신이 다음에 구축할 기능에 대해 실제 수락 기준(acceptance criteria)이 포함된 정교한 명세(spec)를 하나 작성하는 순간, 어떤 도구를 사용하든 오늘 바로 명세 기반 개발(spec-driven development)을 실천할 수 있다는 점입니다. 연구를 먼저 끝낼 필요는 없습니다.

FAQ

OpenSpec이란 무엇인가요?

OpenSpec은 AI 코딩 에이전트를 위한 가볍고 오픈 소스인 명세 기반 개발 (spec-driven development) 프레임워크입니다. 이 프레임워크는 명세(specifications)를 저장소(repo) 내에 마크다운(markdown) 형식으로 저장하며, API 키나 MCP가 필요 없이 제안(propose), 적용(apply), 보관(archive)이라는 최소한의 3단계 루프를 실행합니다. 이는 코딩 에이전트가 코드를 작성하기 전에 명세를 작성하도록 돕는 여러 도구 중 하나입니다 (GitHub Spec Kit 및 SuperPowers와 함께). 이 프레임워크는 근본적인 실천 방식이 아닌, 주로 명세를 저장하고 순서를 정하는 방식에서 다른 도구들과 차이가 있습니다.

OpenSpec과 Spec Kit의 차이점은 무엇인가요?

OpenSpec은 최소한의 기능을 갖추고 있으며, 제안-적용-보관(propose-apply-archive) 루프를 통해 작업 내용을 하나의 진화하는 명세 아티팩트(spec artifact)로 병합합니다. GitHub Spec Kit은 스캐폴딩(scaffolding) 비중이 더 높으며, 명세에서 계획(plan)을 거쳐 작업(tasks)으로 이어지는 구조화된 명령과 템플릿을 제공하며, 종종 EARS 구문을 사용합니다. 실질적인 차이점은 파일 레이아웃과 각 도구가 단계별 과정에 대해 얼마나 독자적인 견해(opinionated)를 가지고 있는지에 있습니다. 두 도구 모두 동일한 핵심 실천 방식을 인코딩합니다: 기능당 하나의 명세, 검토 가능한 계획, 그리고 완료를 정의하는 수락 기준(acceptance criteria)입니다.

어떤 명세 기반 개발 도구가 가장 좋은가요?

단 하나의 최고의 도구는 없으며, 선택의 중요성은 대부분의 비교 스레드에서 시사하는 것보다 덜 중요합니다. OpenSpec, Spec Kit, SuperPowers는 모두 동일한 관행을 인코딩하며, 주로 명세(spec)를 저장하고 순서를 정하는 방식에서 차이가 납니다. 더 나은 질문은 당신이 실제로 명세 기반 개발 (spec-driven development)을 실천하고 있는지입니다. 즉, 기능당 하나의 집중된 명세를 작성하고, 에이전트가 코드를 작성하기 전에 계획을 검토하며, 누적되는 수락 기준 (acceptance criteria)을 유지하고 있는가 하는 점입니다. 어떤 도구든 이를 지원할 수 있습니다. 직접 조립하는 프레임워크 대신 해당 관행을 제공하는 BrainGrid와 같은 관리형 제품도 마찬가지입니다.

명세 기반 개발을 하기 위해 도구가 필요한가요?

아니요. 명세 기반 개발 (spec-driven development)은 도구가 아니라 관행입니다. 당신은 오늘이라도 바로 시작할 수 있습니다. 다음 기능에 대해 무엇이 "완료"되었는지를 정의하는 구체적인 수락 기준 (acceptance criteria)을 포함하여 하나의 긴밀한 명세를 작성한 다음, 이를 바탕으로 빌드하고 결과를 확인하면 됩니다. 도구들 (OpenSpec, Spec Kit, SuperPowers)은 그러한 습관을 자동화하고 구조화하며, BrainGrid와 같은 제품은 전체 루프를 대신 실행해 주지만, 관행 그 자체는 일반 마크다운 (markdown) 파일에서도 작동합니다. 지속 가능한 자산은 명세 (spec)이지, 그것을 생성한 소프트웨어가 아닙니다.

AI 코딩 에이전트에게 명세 기반 개발이 왜 중요한가요?

모호한 프롬프트는 확신에 찬 실수를 저지르는 기계이기 때문입니다. 에이전트가 코드의 대부분을 작성할 때, 병목 현상은 타이핑 속도가 아니라 명확성, 즉 당신이 원하는 바를 얼마나 정확하게 설명하는지와 완료가 어떻게 정의되는지로 옮겨갑니다. 명세 (spec)는 에이전트에게 목표를 제공하며, 당신에게는 모든 줄을 읽는 대신 수락 기준 (acceptance criteria)에 따라 결과를 검증할 수 있는 방법을 제공합니다. 에이전트가 더 자율적으로 변할수록 이는 덜 중요한 것이 아니라 더 중요해집니다. 더 많은 자율성은 명세 (spec)가 포착하지 않는 한, 아무도 기록하지 않은 더 많은 결정이 내려짐을 의미하기 때문입니다.