명세 주도 개발: 카테고리 전체가 수렴한 실천
진지한 AI 코딩 도구들이 모두 서로 1년 안쪽의 간격으로 같은 기능을 출시했다 — 우연히 벌어지는 일이 거의 없는 종류의 일이다.
2025년의 흥미로운 질문은 모델이 얼마나 좋아지고 있는지였다. 2026년의 흥미로운 질문은 그것들에게 무엇을 건네는지다.
GitHub은 Spec Kit을 냈다. AWS는 그 발상을 중심으로 만든 IDE인 Kiro를 냈다. BMAD-METHOD, OpenSpec, Tessl이 각자 시도했다. Cursor는 규칙 파일을 통해 같은 지점에 도달했다. Martin Fowler는 이 구현들에 대한 비교를 발표했다. 여섯 개의 독립된 팀이 열두 달 안에 같은 답으로 수렴할 때, 그들은 서로를 베끼고 있는 것이 아니다. 모두 같은 벽에 부딪히고 있는 것이다.
그 벽에는 이제 이름이 있다. 해결책에도.
명세 주도 개발이 실제로 무엇인가
코드가 생성되기 전에 요구사항과 제약과 성공 기준을 쓴다. 그 문서를 사실의 원천으로 대한다. 에이전트가 그것에 맞춰 만들게 한다.
그것이 전부다. 새로운 발상이 아니다 — 그것은 요구사항 공학이며, 업계가 30년간 형편없이 하다가 대체로 너무 느리다는 이유로 버린 것이다. 바뀐 것은 개념이 아니다. 경제학이다.
명세는 예전에 쓰기도 비싸고 최신으로 유지하기도 비쌌다. 그래서 대부분의 팀은 큰 줄기만 쓰고 나머지 전부를 코드 리뷰에서 발견했다. 개발자가 어차피 그 기능을 만드는 데 3주가 걸릴 때 그것은 합리적인 교환이었다. 생성이 빨라지자 그것은 합리적이기를 그만두었다. 이제 명세가 느린 부분이고 — 그리고 느린 부분이 바로 모든 판단이 사는 곳이기 때문이다.
이것이 대항해 발명된 실패 양상
프롬프트부터 시작하는 도구는 명세를 완전히 건너뛴다. 당신은 결과를 서술하고, 도구는 그것을 닮은 무언가를 만들어 내며, 그 서술이 다루지 않은 모든 결정은 생성기에 의해 조용히 내려진다.
어떤 결정들? 결국 중요해지는 것들이다. 이메일 주소가 유일한지, 그리고 무엇에 걸쳐 유일한지. 취소된 계정이 여전히 무엇을 볼 수 있는지. 두 사람이 같은 레코드를 편집하면 무슨 일이 벌어지는지. 그 목록이 만 개의 행이 쌓이기 전에 페이지네이션이 필요한지.
아무도 그 질문을 하지 않았으니 아무도 답하지 않았다 — 그런데 애플리케이션은 각각에 대한 답을 갖고 있다. 당신의 비즈니스를 결코 포함하지 않은 맥락에서 추론으로 선택된 답을.
같은 동학이 정의 단계를 건너뛰는 모든 도구에서 나타난다. 그것은 70% 문제 뒤의 메커니즘이다. 진전이 멈추는 것은 남은 작업이 어렵기 때문이 아니라, 수백 세대 전에 암묵적으로 내려진 아키텍처 결정에 막혀 있고 시스템을 뜯어내지 않고는 그것을 더 이상 바꿀 수 없기 때문이다.
그것 없이 무슨 일이 벌어지는지에 대한 데이터
DORA의 2025년 《State of AI-assisted Software Development》가 지금 볼 수 있는 가장 명확한 자료다. 기술 전문가의 90%가 이제 업무에서 AI를 쓰고, 80% 이상이 그것이 자신의 생산성을 높였다고 믿는다. 그리고 더 높은 AI 도입은 소프트웨어 배포 처리량의 증가와 소프트웨어 배포 불안정성의 증가와 동시에 연관된다.
배포는 더 빠르다. 계속 돌아가게 하는 것은 더 나쁘다. 둘 다 함께.
GitClear의 2026년 6억 2,300만 건 코드 변경 분석이 그 피해의 모양을 보여 준다. 2023년 기준선 대비, 중복 코드 블록 81% 증가, 커밋 내 복사·붙여넣기가 2022년 9.4%에서 2026년 상반기 15.7%로 상승, 오류를 감추는 구조 47% 증가. 동시에 파일 간 함수 호출 — 코드 재사용의 가장 좋은 대리 지표 — 은 35% 감소했고, 리팩터링 활동은 2022년 변경의 21%에서 2026년 3.8%로 붕괴했다.
개발자는 이제 리팩터링할 가능성보다 복사·붙여넣기할 가능성이 대략 다섯 배 높다. 2022년에는 이 비율이 반대였다.
이 중 어느 것도 모델 품질 문제가 아니다. 생성이 저렴하고 구조가 아무의 명시적인 일도 아닐 때 벌어지는 일이다.
세 가지 투신 수준
모두가 이 말로 같은 것을 뜻하지는 않으며, 그 차이는 실무에서 중요하다. Martin Fowler의 틀이 내가 본 것 중 가장 깔끔하다.
명세 우선(spec-first). 명세를 쓰고, 그것으로부터 생성하고, 그다음 코드를 손으로 유지한다. 명세가 초기 빌드를 구동하고 점차 역사적 기록이 된다. 도입하기 가장 쉽고 보장은 가장 약하다 — 반년이 지나면 그 문서는 더 이상 존재하지 않는 시스템을 서술한다.
명세 정박(spec-anchored). 명세와 코드가 함께 진화한다. 명세를 바꾸고, 영향받은 부분을 다시 생성하고, 둘 다 최신으로 유지한다. 더 많은 규율이 필요하고, 그 대가로 문서가 계속 신뢰할 만하게 남는다.
명세를 원천으로(spec-as-source). 명세가 당신이 편집하는 유일한 산출물이다. 코드는 컴파일된 바이너리가 산출물인 것처럼 산출물이다 — 손으로 패치하지 않는다. 보장이 가장 강하고, 팀의 일하는 방식에서 가장 큰 도약이다.
명세 주도라고 자칭하는 대부분의 팀은 명세 우선을 하고 있다. 그것은 눈감고 프롬프트하는 것에 비하면 진짜 개선이며, 동시에 조용히 부식하는 버전이기도 하다.
명세에 들어가야 하는 것
유용한 시험: 생성기가 추측해야 할 것이라면, 그것은 이 문서에 들어가야 한다.
- 데이터 모델. 엔티티, 관계, 카디널리티, 무엇이 레코드를 유일하게 만드는지, 삭제 시 무슨 일이 벌어지는지. 가치가 가장 높은 절이고 가장 자주 건너뛰어지는 절이다.
- 사용자 유형과 권한. 누가 존재하는지, 각자가 무엇을 보고 할 수 있는지, 경계에서 무슨 일이 벌어지는지.
- 불변식. 결코 위반되어서는 안 되는 규칙을, 담백하게 진술한 것. 「오류를 우아하게 처리한다」가 아니다 — 그것은 소망이고 제약이 아니다.
- 성공 기준. 그것이 작동하는지 어떻게 알 것인가를, 「작동하는가」에 대한 불일치가 해소될 수 있을 만큼 구체적인 용어로.
들어가지 말아야 할 것: 생성기가 당신보다 더 잘 고르는 구현 세부. 변수 이름을 지정하는 명세는 명세가 아니다. 그것은 더 나쁜 도구를 쓴 코드다.
모두가 틀리는 부분
명세는 산문 말고 다른 어딘가에서 강제될 때만 도움이 된다.
제약이 문서에만 산다면 그것은 제안이다. 생성기는 그것을 한 번 읽었고, 자기가 건드린 열네 번째 파일에서 그것을 지켰을 수도 있고 아닐 수도 있다. 제약은 시스템이 확인하는 곳으로 끝나야 한다. 폼 핸들러가 아니라 데이터베이스의 not-null과 unique로, 주석이 아니라 경계의 타입으로, 누군가 쓰기를 기억한 조건이 아니라 시스템이 평가하는 정책으로서의 인가로.
이것이 실천으로서의 명세 주도 개발과 문서 장르로서의 명세 주도 개발의 차이다. 문서는 당신이 결정하는 방법이다. 강제는 당신이 그 결정을 지키는 방법이다.
당신이 실제로 그것을 하고 있는지 판별하는 방법
네 가지 질문이며, 일부러 불편하게 만들었다.
- 무언가 깨지면 코드를 고치는가 명세를 고치는가? 답이 늘 코드라면 당신은 잘해야 명세 우선이고, 그 문서는 이미 낡았다.
- 새로운 사람이 명세를 읽고 시스템이 어떻게 동작할지 예측할 수 있는가? 알기 위해 코드를 읽어야 한다면 그 명세는 원천이 아니라 요약이다.
- 명세 안에 시스템이 위반할 수 없는 것이 있는가? 모든 규칙이 산문이라면 그중 어느 것도 보장되지 않는다.
- 명세를 리뷰하는가 diff를 리뷰하는가? 생성된 코드 수천 줄을 리뷰하는 것은 연극이다. 논쟁이 아직 저렴한 동안 그 문서를 두고 논쟁하라.
이것이 도구를 어디에 남기는가
현재 대부분의 구현은 구체적으로 코드 생성에 대한 명세 주도다. 그들은 명세를 만들고 그것에 맞춰 구현을 생성하며, 그들이 다루는 산출물은 코드베이스다.
더 어려운 버전은 같은 논리를 애플리케이션 전체로 확장한다 — 데이터 모델, API 표면, 인증 경계, 인터페이스 — 그래서 명세는 코드가 무엇을 하는지만이 아니라 시스템이 무엇인지를 다룬다. 그것이 바로 Archie의 청사진 단계이고, 내가 그것을 저장소가 아니라 풀스택에 적용된 명세 주도 개발이라고 서술하는 이유다. 범위는 다르고 원칙은 같다. 생성하기 전에 정의하라.
이것을 얼마나 멀리 가져갈지에 대해서는 합리적인 사람들 사이에 이견이 있다. 뒤로 돌아가자고 주장하는 진지한 사람은 없다.
그것이 드는 비용
판단을 앞으로 당기는 일은 프로젝트의 첫 주에는 더 느리고 그 뒤 모든 주에는 더 빠르다. 그 비용은 실재하며, 추진력이 가장 가치 있게 느껴지고 경쟁사가 눈에 보이는 무언가를 배포하는 바로 그 순간에 지불된다. 이것을 건너뛴 팀이 이기고 있는 것처럼 보이는 스프린트가 있을 것이다.
규율도 부식한다. 제약을 적어 두는 일은 인터페이스가 나타나는 것을 보는 것만큼 즐겁지 않고, 문서를 리뷰하는 일은 코드를 리뷰하는 것만큼 만족스럽지 않다. 이 습관들은 기한 압박 아래 침식되며, 그것이 바로 그것들을 중요하게 만드는 같은 압박이다.
그리고 그것은 정말로 모든 것에 적용되지는 않는다. 이번 주말에 아이디어를 검증하고 그 결과를 버릴 생각이라면, 버려라. 수명이 이틀인 소프트웨어에 이 중 어느 것도 할 가치가 없다.
이것이 자리를 잡은 이유
팀에게 명세를 먼저 쓰게 만들려는 이전의 모든 시도는 실패했고, 그것은 정당한 이유로 실패했다. 명세가 진짜 작업 위에 얹힌 오버헤드였기 때문이다. 문서를 쓰고 나서도 여전히 그 물건을 만들어야 했다.
이제 그 교환이 달라졌다. 이제 문서가 곧 작업의 대부분이고, 빌드가 저렴한 부분이다. 여섯 개의 독립된 팀이 서로 1년 안쪽에서 이것을 알아챈 것은, 모델이 좋아진 데 따른 명백한 결과였기 때문이다.
이 실천은 논쟁에서 이긴 것이 아니다. 그 아래에서 경제학이 움직인 것이다.
더 읽을 거리
최초의 진단: 바이브 코딩은 약속을 깼다. 이 카테고리가 다음으로 간 곳: 바이브 코딩 다음은 무엇인가. 같은 논증을 시스템 전체에 적용한 것: 제1원리에서 출발하는 AI-first 소프트웨어 설계. 그리고 같은 발상의 더 오래된 표현: 소프트웨어를 두 번 쓰지 마라.
자주 묻는 질문
명세 주도 개발이란 무엇인가? 코드가 생성되기 전에 요구사항과 제약과 성공 기준을 쓰고, 그 명세를 AI 에이전트가 맞춰 만드는 사실의 원천으로 대하는 것이다. 그것은 정의 단계를 건너뛰는 프롬프트 우선 워크플로에 대한 직접적인 응답으로 2025년과 2026년에 등장했다.
전통적인 요구사항 문서와 어떻게 다른가? 개념은 같다. 경제학이 다르다. 전통적인 명세는 팀이 큰 줄기만 쓰고 나머지를 구현 중에 발견할 만큼 비쌌다. 초안 잡는 데 몇 달이 아니라 몇 시간이 걸리고 저렴하게 수정할 수 있게 되면, 끝낼 가치와 최신으로 유지할 가치가 생긴다.
어떤 도구가 명세 주도 개발을 지원하는가? GitHub Spec Kit, AWS Kiro, BMAD-METHOD, OpenSpec, Tessl이 이름이 붙은 구현이며, Cursor는 규칙 파일을 통해 더 경량 버전을 지원한다. 주된 차이는 명세가 코드에 얼마나 강하게 결속되는지다 — 생성을 한 번 구동하는지, 그것과 나란히 진화하는지, 아니면 당신이 편집하는 유일한 산출물인지.
명세 주도 개발의 세 가지 수준은 무엇인가? 명세 우선은 명세가 초기 빌드를 구동하고 코드는 손으로 유지하는 것. 명세 정박은 명세와 코드가 함께 진화하는 것. 명세를 원천으로는 명세가 당신이 편집하는 유일한 것이고 코드는 산출물로 취급되는 것. 이것을 실천하는 대부분의 팀은 명세 우선을 하고 있다.
명세 주도 개발은 팀을 느리게 하는가? 그것은 작업을 재배치하고 추가하지 않는다. 명세 안의 결정은 앞단에서 의도적으로 내려지거나, 나중에 생성기가 추측하며 암묵적으로 내려진다. 그리고 두 번째 경로가 바로 재작업이 나오는 곳이다. 첫 주에는 더 느리고 그 뒤에는 더 빠르다.
명세에 무엇이 들어가야 하는가? 생성기가 그러지 않으면 추측해야 할 모든 것. 관계와 유일성 규칙이 있는 데이터 모델, 사용자 유형과 권한, 결코 위반되어서는 안 되는 불변식, 불일치를 해소할 만큼 구체적인 성공 기준. 생성기가 당신보다 더 잘 고르는 구현 세부는 빼 두라.
명세 주도 개발과 AI-first 설계는 같은 것인가? 명세 주도 개발은 생성하기 전에 정의하는 실천이다. AI-first 설계는 더 넓은 아키텍처적 결과의 집합이며, 제약이 어디서 강제되는지, 어떤 순서로 결정을 내리는지, 인간 소비자와 함께 에이전트 소비자를 위해 설계하는 것도 다룬다.
