요약 (TL;DR): Spec Kit, OpenSpec, BMAD, Kiro — 이 모든 것들은 명세(spec)가 진실의 원천 (source of truth)으로 유지될 수 있다는 가정하에 구축되었습니다. 하지만 디자인 문서(design docs)나 위키(wikis)가 결코 최신 상태를 유지하지 못했던 것과 같은 이유로, 명세 또한 그럴 수 없습니다. 저는 이 분야에서 흥미롭고 아직 해결되지 않은 문제는 "더 엄격한 명세"가 아니라, "사람이 업데이트하는 것을 기억할 필요가 없는 명세"라고 생각합니다. 이를 실제 운영 환경(production)에서 사용 중인 분들도 동의하는지 궁금합니다.

현재 모두가 내세우는 주장

명세 기반 개발 (Spec-driven development)은 "AI 에이전트가 그럴듯해 보이지만 미묘하게 틀린 코드를 작성한다"는 문제에 대한 기본 답변이 되었습니다. 그 아이디어는 이렇습니다: 프롬프팅 (prompting)을 멈추고, 구조화된 명세를 작성한 뒤, 에이전트가 그에 따라 실행하게 하고, 차이점 (diff)을 검토하는 것입니다. GitHub Spec Kit은 9만 개 이상의 스타를 보유하고 있으며, /speckit.specify → /speckit.plan → /speckit.tasks → /speckit.implement 과정은 이제 기본적으로 알려진 워크플로 (workflow)입니다. OpenSpec은 델타 명세 (delta specs)와 openspec validate --strict를 통해 더 가볍게 동일한 작업을 수행합니다. BMAD는 반대 방향으로 움직이며 12명의 에이전트로 구성된 전체 팀을 시뮬레이션합니다. AWS는 이 아이디어를 중심으로 전체 IDE (Kiro)를 구축했습니다. Tessl은 이 기술로 1억 2,500만 달러를 투자받았습니다.

이것은 근거 없는 유행이 아닙니다. 많은 실제 사례에서 단순 프롬프팅보다 더 잘 작동합니다. 하지만 저는 지난 몇 주 동안 단순히 판매자 페이지를 보는 대신, 찾을 수 있는 모든 실무자들의 기록을 읽으며 이 주제를 깊이 파고들었고, 이 도구들 중 그 어느 것도 실제로 해결하지 못하는 한 가지 문제가 계속해서 나타나고 있음을 발견했습니다.

문제점: 명세의 진실성을 유지하는 것은 README 시절부터 겪어온 것과 동일한 문제이다

우리는 20년 넘게 디자인 문서 (design docs), 아키텍처 위키 (architecture wikis), README 등 코드와 문서를 동기화하려고 노력해 왔습니다. 하지만 지루한 이유로 인해 이는 결코 성공하지 못했습니다. 코드를 수정하는 것은 빠르고 결과물을 출시할 수 있게 해주지만, 문서를 수정하는 것은 느리고 눈에 보이는 결과물이 없기 때문입니다. 팀이 빠르게 움직일 때, 문서는 매번 패배합니다.

SDD는 동일한 산출물에 새로운 이름을 붙이고 이를 "진실의 원천 (source of truth)"라고 부를 뿐입니다. 하지만 비대칭성은 동일합니다. 명세 (spec) 작업을 세 단계 정도 진행했을 때, 에이전트가 아무도 문서화하지 않은 제약 조건에 부딪혀 이를 인라인 (inline)으로 수정하고 배포해 버리면, 명세는 여전히 과거의 계획을 설명하고 있게 됩니다. 실제 운영 환경에서 이를 실행하는 여러 사람들은 명세가 몇 달이 아니라 단 며칠 만에 어긋나기 (drifting) 시작한다고 말합니다. 주요 프레임워크 중 그 어떤 것도 "규율 (discipline)" 이외에는 이에 대한 실질적인 해답을 내놓지 못하고 있는데, 이는 우리가 규율을 요구할 때마다 매번 실패했던 바로 그 요소입니다.

전제 자체에 대한 실질적인 비판

Kent Beck의 반론(1월에 Martin Fowler가 인용한 내용)은 깊이 고민해 볼 가치가 있습니다. 대부분의 SDD 관련 글들은 구현이 시작되기 전에 전체 명세를 작성한다고 가정하는데, 이는 구현 과정에서 명세를 변경해야 할 무언가를 배우지 않을 것이라고 은연중에 가정하는 것입니다. 방법론을 구축하기에는 매우 이상한 가정입니다. 이는 XP (Extreme Programming)가 구축된 핵심 원칙인 피드백 루프 (feedback-loop) 원칙과 정반대되는 것입니다. Fowler의 요점은 AI가 피드백 루프를 가속화해야지, 더 많은 사전 문서화를 앞당기기 위한 변명이 되어서는 안 된다는 것이었습니다. ThoughtWorks의 Radar 또한 기본적으로 동일한 위험을 경고했습니다. 즉, 과도한 사전 명세 (upfront specs)가 빅뱅 출시 (big-bang releases)로 이어지는 경향이 있으며, 이는 애자일 (agile)이 방지하기 위해 존재하는 바로 그 실패 모드라는 점입니다.

명세가 모든 검사를 통과하더라도 여전히 틀릴 수 있다

기억에 남는 사례 하나가 있습니다. 한 개발자가 수개월 동안 진행된 실제 프로젝트를 완전히 명세 기반 (spec-driven)으로 진행했습니다. 철저한 명세가 있었고, 에이전트는 명세된 대로 정확히 구축했으며, 모든 수락 기준 (acceptance criterion)을 통과했습니다. 하지만 시스템은 여전히 틀렸습니다. 명세가 실제로 구축을 시작해야만 나타나는 암묵적이고, 런타임 (runtime)적이며, 시스템 간의 지식을 포착할 수 없었기 때문입니다. 그는 프로젝트 중간에 인프라 (infra) 결정 하나를 변경했는데, 그 지점 이후의 모든 것이 더 이상 유효하지 않은 가정을 소리 없이 상속받았기 때문에 전체 다운스트림 (downstream) 명세 그래프가 깨져버렸습니다.

그리고 별개로 — Scott Logic은 실제 프로젝트에 실제 SDD 워크플로우를 적용해 보았고, 그 결과는 다음과 같았습니다: 기존 프로세스보다 약 10배 느려졌고, 절차(ceremony)는 더 많아졌으며, 버그의 수는 동일했습니다. 이것이 SDD가 쓸모없다는 뜻이라고 생각하지는 않습니다. 제 생각에 이는 엄격함(rigor) 그 자체가 사람들이 가정하는 것처럼 병목 현상(bottleneck)은 아니라는 것을 의미합니다.

제가 실제로 충분히 탐구되지 않았다고 생각하는 것

팀들에게 더 많은 문서를 더 주의 깊게 작성하라고 요구하는 또 다른 프레임워크가 아닙니다. 그보다는 다음과 같은 것에 더 가깝습니다: 생성된 문서(generated docs)나 락파일(lockfile)을 다루는 방식과 마찬가지로, 코드와 실행 중인 시스템이 실제로 수행하는 작업으로부터 명세(spec)를 추론하고 업데이트하는 것입니다. 즉, 누군가가 기억해서 유지보수하는 것이 아니라 자동으로 유지보수되는 방식입니다.

저는 이것의 작동하는 버전을 가지고 있지 않으며, 이것이 유용하기 위해 필요한 수준의 세밀함(granularity)에서 실행 가능한지조차 확신할 수 없습니다 (실제 코드베이스로부터 정확한 아키텍처 다이어그램을 자동 생성하려고 시도해 본 사람이라면 그것이 보통 어떻게 흘러가는지 잘 알 것입니다). 제가 이 글을 올리는 이유는, 무언가를 직접 만든 후에가 아니라 실제로 이 벽에 부딪혀 본 사람들을 통해 이것이 막다른 길이라는 것을 미리 알고 싶기 때문입니다.

만약 여러분이 운영 환경(prod)에서 다음 중 하나라도 실행하고 있다면 진심으로 궁금합니다:

• 여러분의 명세는 2~3주를 넘겨 생존하나요, 아니면 조용히 희망 사항(aspirational)으로 변해버리나요?
• 명세가 드리프트(drift)될 때, 실제 트리거는 무엇인가요 — 놓친 엣지 케이스(edge case), 변경된 의존성(dependency), 아니면 아무도 명세에 백포트(backport)하지 않은 범위(scope)의 변경인가요?
• 명세를 미리 작성하는 대신 코드나 텔레메트리(telemetry)로부터 명세를 생성하거나 업데이트하는 것을 시도해 본 사람이 있나요? 그것이 작동했나요, 아니면 그저 노이즈(noise)만 생성했나요?
• 만약 openspec validate --strict나 Spec Kit의 헌법 모델(constitution model)을 실전에서 사용해 보았다면 — 어느 부분에서 실제로 효과가 있었고, 어느 부분에서 그저 절차(ceremony)만 추가했을 뿐인가요?

무언가를 팔려는 것이 아닙니다. 이것이 실제적인 격차(gap)인지, 아니면 제가 이미 이를 처리하고 있는 도구나 패턴을 놓치고 있는 것인지 진심으로 파악해보고 싶을 뿐입니다.