AI가 드러낸 불편한 진실
애자일이 25년간 외면해온 질문이 2026년에 돌아왔다. "왜 우리는 명세서 쓰기를 그만뒀나?" dev.to에 게재된 Lewis Campbell의 분석이 지적하듯, LLM 기반 코딩 에이전트는 구조화된 명세를 받을 때와 즉흥적 프롬프트를 받을 때 결과물의 품질이 확연히 갈린다. Claude Code, Cursor, GitHub Copilot을 실제로 써본 팀이라면 이미 몸으로 안다—잘 쓴 스펙 하나가 세 번의 디버깅 라운드를 없애준다는 것을.
문제는 애자일 매니페스토가 "작동하는 소프트웨어 > 포괄적 문서"를 선언한 이후, 많은 팀이 이를 "명세는 쓰지 않아도 된다"는 면죄부로 읽었다는 데 있다. 스탠디시 그룹 데이터에 따르면 애자일 방법론 프로젝트의 약 18%가 완료 전 취소된다. 이 수치를 업계가 오랫동안 묵인해온 건, 스프린트와 회고라는 의식(ritual)이 방법론 자체에 대한 의문을 덮어왔기 때문이다. AI 에이전트는 그 덮개를 걷어냈다.
SDD: 세 단계로 보는 명세 주도 개발
arXiv에 2026년 1월 게재된 논문 Spec-Driven Development: From Code to Contract in the Age of AI는 AI 워크플로우에서 명세를 다루는 방식을 세 층위로 정리한다.
- Spec-first: 명세가 구현을 주도하고, 코드는 명세가 바뀌면 재생성 가능한 산출물로 다룬다.
- Spec-anchored: 명세와 코드가 병렬로 진화하며 상호 참조한다.
- Spec-as-source: 명세가 시스템의 유일한 권위 원천이 되고, 코드는 자동 생성·검증된다.
이 논문이 제시한 정량 수치가 핵심이다. 인간이 정제한 명세는 LLM이 생성하는 코드의 오류를 최대 50% 감소시킨다. 점진적 개선이 아니다. 프로덕션 직행 코드와 수차례 수작업 수정이 필요한 코드 사이의 차이다.
Red Hat의 분석은 여기에 세 가지 실무적 이점을 덧붙인다. 첫째, 명세가 모듈화되면 여러 에이전트가 충돌 없이 병렬 작업할 수 있다. 둘째, 에이전트가 코드를 생성한 뒤 명세 요건 목록과 자기 검증(auto-verification)을 수행해 인간 리뷰어 부담을 줄인다. 셋째, '학습한 교훈' 파일을 명세에 누적해 반복 오류를 줄이는 기억 누적 메커니즘이 작동한다. Red Hat이 목표로 제시한 수치는 첫 시도 95% 정확도—유닛 테스트까지 포함해서.
Thoughtworks가 말하는 '고삐 채우기'
Thoughtworks Technology Radar V34는 이 흐름을 현장 검증된 언어로 정리한다. 코딩 에이전트 성능이 올라갈수록 인간이 루프에서 빠지려는 유혹도 커진다는 것, 그리고 그 유혹에 따른 비용이 팀에게 돌아온다는 것을 레이더는 냉정하게 짚는다.
레이더가 Adopt 단계로 분류한 Context Engineering이 주목할 개념이다. 프롬프트 엔지니어링이 '문구'에 집중했다면, 컨텍스트 엔지니어링은 AI의 정보 환경 전체를 설계 표면으로 다룬다. 대형 컨텍스트 윈도우에 원시 데이터를 쏟아붓는 방식은 'context rot'과 추론 저하를 낳는다. SDD의 구조화된 명세는 곧 컨텍스트 엔지니어링의 실천이다—에이전트에게 무엇을, 언제, 얼마만큼 줄 것인가를 설계하는 작업.
레이더가 함께 강조하는 Curated Shared Instructions도 팀 단위 SDD 실천과 직결된다. 개별 개발자가 매번 프롬프트를 처음부터 작성하는 것을 안티패턴으로 보고, CLAUDE.md, AGENTS.md, .cursorrules 같은 지시 파일을 새 서비스 스캐폴딩의 베이스라인으로 배포하는 방식이다. 명세 파일을 공유 엔지니어링 자산으로 관리하면, 팀원이 교체되거나 새 레포지토리가 생겨도 에이전트의 행동 기준선이 흔들리지 않는다.
레이더는 동시에 Feedback Sensors for Coding Agents를 Trial 단계로 제시한다. 컴파일러, 린터, 타입 체커, 테스트 스위트를 에이전트 워크플로우에 직접 연결해 실패 시 자동 수정을 트리거하는 구조다. SDD가 '입력 품질'을 높이는 feedforward 통제라면, 피드백 센서는 '출력 품질'을 잡는 feedback 통제다. 두 레이어가 함께 작동할 때 에이전트는 처음으로 팀의 진짜 동료가 된다.
코빗이 보여준 조직 전환의 실상
이론은 충분하다. 코빗의 사례가 실행 가능성을 검증한다. 코빗은 Claude, Gemini를 전 직원에게 제공하는 것에서 멈추지 않았다. CTO가 직접 개발을 주도한 RAG 기반 사내 플랫폼으로 사내 문서, 데이터베이스, 업무 시스템을 통합 연결했다. 비개발 직군도 자연어로 데이터를 조회하고, 개발자는 내부 지식에 즉시 접근할 수 있는 구조다.
핵심은 조직 지식의 데이터화다. "구성원의 지식을 AI가 활용 가능한 형태로 전환하는 것이 핵심"이라는 이정우 CTO의 언급은 SDD의 철학과 정확히 맞닿아 있다. 개인에게 흩어진 맥락과 노하우를 시스템이 흡수하고, AI가 그 위에서 작동한다. 코빗이 채용 평가에 AI 활용 역량을 반영하기 시작했다는 점도 주목할 신호다—AI-First 팀 리빌딩은 도구 도입이 아니라 평가 기준의 전환에서 완성된다.
팀 리드가 지금 봐야 할 것
세 소스가 수렴하는 지점은 하나다. AI 에이전트의 품질은 모델이 아니라 팀이 제공하는 컨텍스트의 품질로 결정된다. 그리고 그 컨텍스트를 체계적으로 설계하고, 공유하고, 축적하는 실천이 바로 Spec-Driven Development다.
실행 관점에서 당장 따져볼 질문 세 가지.
.cursorrules또는CLAUDE.md가 팀 레포에 있는가? 없다면 개별 개발자가 매번 같은 컨텍스트를 설명하며 토큰을 낭비하고 있는 것이다.- 에이전트 워크플로우에 피드백 센서가 연결되어 있는가? 린터와 테스트가 에이전트 루프 밖에 있다면, 품질 검증은 여전히 인간 리뷰어의 어깨 위에 있다.
- 조직 지식이 AI가 읽을 수 있는 형태로 저장되어 있는가? 슬랙 메시지와 구두 합의 속에 잠긴 맥락은 에이전트에게 투명한 벽이다.
Thoughtworks 레이더가 경고한 'Codebase Cognitive Debt'—AI 생성 코드가 늘수록 작동 원리에 대한 팀의 멘탈 모델이 흐려진다는 위험—은 SDD가 제대로 작동할 때 방어된다. 명세가 살아있는 문서로 유지되면, 코드베이스를 이해하는 부담의 일부가 명세로 이전된다. "규율 없는 속도는 비용을 가중시킨다"는 레이더의 원칙은 AI-First 팀에게 지금 이 시점에 가장 현실적인 경고다.
속도는 AI가 가져다준다. 구조는 팀이 만들어야 한다.