스펙 주도 개발은 소프트웨어를 구현하기 전에 상세한 명세(스펙)를 먼저 작성하고 합의한 뒤, 이 명세를 개발 전 과정에서 참조하는 단일 진실 공급원으로 삼는 소프트웨어 개발 방법론이다. 전통적인 코드 중심 개발에서는 명세가 있더라도 구현이 시작되면 문서와 코드가 점차 어긋나는 경우가 많았던 반면, 스펙 주도 개발에서는 요구사항, 제약조건, 인수 기준을 담은 명세 자체가 구현을 이끌어 내거나 구현의 타당성을 검증하는 근거로 계속 기능한다. 이 용어는 오래전부터 OpenAPI 명세를 이용한 API 계약 우선 설계 등 특정 영역에서 쓰여 왔으나, 2025년을 전후해 대규모 언어 모델 기반 코딩 에이전트가 확산되면서 사람이 작성한 자연어 명세로부터 AI가 코드를 생성하고 그 결과를 명세에 대조해 검증하는 절차 전반을 가리키는 말로 폭넓게 쓰이게 되었다.
Living Spec의 4단계 양방향 loop
| 단계 | 방향 | 내용 |
|---|---|---|
| 1. 초기 의도 | 개발자 → 명세 | 개발자가 상위 요구사항을 쓰고 AI가 구조화된 spec으로 확장 |
| 2. 구현 | 명세 → 에이전트 → 코드 | 에이전트가 확정된 spec을 읽고 코드·테스트·문서 생성 |
| 3. 양방향 갱신 | 구현 → 명세 | 실제로 무엇이 구현됐는지를 에이전트/사람이 spec에 다시 기록 |
| 4. 지속적 정제 | 운영 → 명세 | 지표·인시던트·운영 경험이 spec에 피드백됨 |
과잉 명세 문제
사전에 지나치게 상세한 명세를 작성하는 것은 구현 과정에서 아무것도 배우지 못할 것이라는 가정에 기반하는데, 이는 현실에서 거의 성립하지 않는다.
선언적 결과가 명령적 지시보다 우월하다
선언적 요구사항은 모든 구현 단계를 규정하는 대신 원하는 결과와 제약 조건을 설명하기 때문에 에이전트의 동작을 개선합니다. 이를 통해 에이전트는 기존 패턴을 적용하면서도 검토 가능한 성공 기준을 유지할 수 있습니다.
사양 검토
구현을 시작하기 전에 사양 자체를 검증하십시오.
아키텍처 일관성, 보안 영역, 의사결정이 팀의 의도와 일치하는지 검토하세요.
안티패턴
사양 누락: 에이전트는 부족한 부분을 추측으로 채우게 된다. -> 테스트 가능한 요구사항을 포함하는 구조화된 승인 기준을 사용해야 한다
과잉 명세: 에이전트가 무시하거나 지나치게 문자적으로 따르게 만들어 오히려 품질을 떨어트릴 수 있다. -> 명령형 지시가 아닌 결과와 제약 조건을 선언적으로 명시
모호한 성공 기준: 명확한 종류 규칙이 없으면 에이전트는 언제 멈춰야 할지를 모릅니다. -> 정량화 가능하고 테스트 가능한 기준을 채택
참고자료
https://www.augmentcode.com/guides/living-specs-for-ai-agent-development