AI 코딩 에이전트의 병목은 더 이상 코드 생성 속도가 아니다. 의도(intent)가 얼마나 명확하게 보존되느냐가 진짜 병목이다. dev.to에 게재된 Tisha Chawla(Microsoft)의 분석은 이 지점을 정확히 짚는다. 에이전트는 사람처럼 슬랙 메시지 한 줄로 맥락을 채우지 못한다. 모호한 요구사항을 받으면 그럴듯한 가정을 채워 넣고, 그 가정 위에 기계 속도로 코드를 쌓는다. 리뷰 타임에 diff를 열었을 때 이미 오해가 구조 깊숙이 박혀 있다. 이것이 Ambiguity Tax—불명확한 요구사항이 자동화 루프를 만나 복리로 불어나는 재작업 비용이다.
Spec-Driven Development(SDD)는 이 비용을 리뷰 타임이 아닌 설계 타임에 지불하는 전략이다. 핵심 아이디어는 단순하다. 채팅 히스토리처럼 휘발되는 대화 대신, 리포지토리에 버전 관리되고 리뷰 가능한 명세 아티팩트를 먼저 만드는 것이다. 스펙은 Word 문서가 아니다. diff할 수 있고, 코멘트 달 수 있고, 롤백할 수 있어야 한다. 그래야 에이전트의 실행 컨텍스트로 기능한다. 프롬프트는 대화이고 휘발된다. 스펙은 계약이고 지속된다.
그런데 SDD 방법론 전도사들이 자주 빠뜨리는 두 번째 세금이 있다. Surplus Structure Tax—구조가 너무 많아지면 에이전트의 유한한 추론 예산을 형식 처리에 소모하게 된다는 문제다. Chawla는 이것을 U자 곡선으로 설명한다. 구조가 없으면 Ambiguity Tax가 치솟고, 구조가 과하면 Surplus Tax가 올라간다. 총비용은 그 합이며, 바닥은 '최대 구조' 훨씬 이전에 온다. SDD의 실제 기술은 이 곡선의 바닥을 찾는 것이다. 불확실성을 제거할 만큼만 구조를 추가하고, 그 이상은 에이전트를 오히려 둔하게 만든다.
팀 리드 관점에서 실용적인 판단 기준은 이렇다. Chawla가 정리한 Decision Filter를 그대로 써도 된다. 변경의 Blast Radius가 넓은가(여러 모듈, 공개 API), 되돌리기 어려운가(DB 마이그레이션, 스키마 변경), 요구사항이 진짜 불명확한가, 여러 사람이 리뷰하고 유지해야 하는가—이 신호들이 왼쪽에 쌓이면 스펙이 비용을 회수한다. 반대로 파일 하나, 즉시 되돌릴 수 있고, 혼자 처리하는 원-타임 작업이라면 스펙은 그냥 페이퍼워크다. 모든 변경에 같은 양의 SDD를 적용하는 실수를 피해야 한다.
SDD를 도구 생태계 관점에서 보면 레이어가 세 개로 나뉜다. Intent Layer(무엇을 만들지 명확히 하는 도구)—Spec Kit, OpenSpec, Kiro, BMAD-METHOD. Execution Layer(에이전트가 어떻게 실행할지 통제하는 도구)—Superpowers, GSD, HVE Core. Orchestration Layer(여러 에이전트를 조율하는 도구)—Squad, BMAD-METHOD. 이 세 레이어는 경쟁이 아니라 조합이다. '가장 좋은 SDD 도구'를 고르는 게 아니라 레이어별로 하나씩 골라야 한다. Intent 레이어에서 OpenSpec(가벼운 명세)을 쓰고, Execution 레이어에서 Superpowers(검증 게이트)를 붙이는 식으로.
이 설계 원칙이 비용 거버넌스와 직결되는 시점이 바로 지금이다. GitHub Copilot이 2026년 6월 1일부터 AI Credits(토큰 기반 청구)로 전환한다. 기존의 'premium request' 단위—다소 추상적이었던—가 사라지고, 입력 토큰·출력 토큰·캐시 토큰을 모델별 단가로 환산한 크레딧이 과금 단위가 된다. 1 AI Credit = 0.01 USD. 짧은 질문과 멀티파일 에이전트 세션이 더 이상 같은 가격이 아니다.
팀 운영 관점에서 이 변화가 의미하는 바는 명확하다. 코드 자동완성과 짧은 채팅은 AI Credits를 소비하지 않는다. 문제는 Copilot Chat 긴 세션, cloud agent, Copilot Code Review, 서드파티 에이전트다. 특히 Copilot Code Review는 AI Credits와 GitHub Actions 분을 동시에 소모할 수 있다—두 개의 과금 카운터가 동시에 돌아간다. 엔터프라이즈 플랜에서는 크레딧이 org 전체 풀로 합산되는데, 소수의 파워 유저나 자동화 워크플로우가 사이클 초반에 풀을 과소비하는 리스크가 생긴다.
SDD와 토큰 비용 거버넌스는 사실 같은 문제의 두 얼굴이다. 모호한 요구사항을 에이전트에게 던지면 Ambiguity Tax(재작업 비용)와 토큰 낭비(비용)가 동시에 발생한다. 에이전트가 '이게 뭔지 파악'하는 과정 자체가 토큰 소모다. 반대로 명확한 스펙—모듈, 증상, 기대 테스트, 허용 파일 범위를 명시한—을 주면 에이전트는 열 번 왕복할 것을 두 번에 끝낸다. 좋은 스펙은 품질 도구인 동시에 비용 최적화 도구다.
실행 가이드로 압축하면 이렇다. 첫째, 변경 신호를 먼저 분류하라. Blast Radius가 크고 되돌리기 어렵고 요구사항이 불명확한 작업에만 스펙을 작성하라. 나머지는 코드로 직진해도 된다. 둘째, 스펙 작성 수준을 레벨로 구분하라. Spec-first(일회성 출발점), Spec-anchored(기능 수명 동안 유지), Spec-as-source(코드가 빌드 아웃풋) 중 기본값은 Spec-first다. Spec-anchored는 오너가 없으면 문서 부채가 된다. 셋째, 에이전트 도구를 레이어별로 골라라. Intent Layer 하나, Execution Layer 하나면 대부분의 팀에 충분하다. 넷째, GitHub Copilot 전환 전에 사용 패턴을 점검하라. 롱 에이전트 세션, 프론티어 모델, 자동화 PR 리뷰가 크레딧을 주로 소모한다. 모델 선택을 태스크 복잡도에 맞게 분리하고, user-level budget을 설정해 개인이 풀을 독점하는 상황을 막아라.
AI-First 팀의 운영 성숙도는 결국 두 가지 질문으로 수렴한다. 에이전트에게 얼마나 명확하게 일을 시키고 있는가, 그리고 그 일의 비용을 얼마나 측정하고 있는가. 명세 설계와 비용 거버넌스—이 두 축을 동시에 잡지 않으면 AI-First 워크플로우는 속도가 아니라 불확실성을 증폭시키는 장치가 된다.