스펙 주도 개발이란? AWS가 설명하는 AI 코딩 생산성 높이는 법

핵심 메시지

• 스펙 주도 개발(Spec-Driven Development)은 코드를 작성하기 전에 요구사항·설계 문서를 마크다운으로 먼저 작성하는 구조적 방식이다.
• LLM 코딩 도구를 '신입 인턴'처럼 다뤄야 하며, 방향을 명확히 잡아주지 않으면 엉뚱한 길로 샌다.
• AWS는 이 방식을 제품화한 Kiro(IDE·CLI)를 내놓았지만, 동일한 흐름은 어떤 코딩 도구로도 수동으로 구현할 수 있다.
• 흐름은 요구사항 → 설계 문서 → 구현 작업 목록 순이며, 사람이 각 단계를 검토하는 'human in the loop'이 핵심이다.
• 컨텍스트는 너무 많지도 적지도 않은 '골디락스 영역'으로 관리하고, 최종 코드 리뷰 책임은 사람에게 있다.

쉽게 이해하기

AWS의 시니어 개발자 애드보킷 Eric Hanchett는 '스펙 주도 개발'을 소개한다. 핵심 정의는 단순하다. 코드를 한 줄 쓰기 전에 요구사항과 설계 문서를 먼저 만든다는 것이다. 그는 이 마크다운 문서들이 LLM 코딩 어시스턴트와 특히 잘 맞물린다고 말한다.

왜 필요할까. 발표자는 요즘의 LLM을 'AI 인턴'에 비유한다. 조금만 자유를 주면 궤도를 벗어나기 때문에 방향을 잘 잡아줘야 한다는 것이다. 프런티어 모델이 계속 좋아지더라도 완벽하지 않고, 요구사항과 패러다임이 끊임없이 바뀌므로 맥락을 명시적으로 주는 일이 중요하다고 강조한다.

주의할 점도 짚는다. agents.md나 claude.md 같은 파일에 규칙을 담되 너무 많지도 적지도 않게 두는 '골디락스 영역'을 지키고, 필요할 때만 실행되는 skills(지시 파일)를 활용하라고 권한다. 무엇보다 모든 단계에서 사람이 코드 리뷰어로 남아야 하며, 문제가 생기면 책임은 에이전트가 아니라 사람에게 있다.

AWS는 고객들이 이미 직접 만들어 쓰던 패턴을 제품화해 AI IDE 겸 CLI인 Kiro(kiro.dev)를 내놓았고, 거기엔 'vibe' 모드와 'spec' 모드가 있다. 다만 발표자는 Kiro 없이도 어떤 어시스턴트로든 같은 과정을 수동으로 할 수 있고, GitHub의 오픈소스 Spec Kit도 있다고 소개한다.

실제 흐름은 요구사항(EARS 형식, 사용자 스토리, 명확화 질문) → 설계 문서(머메이드 다이어그램) → 구현 작업 목록 순이다. 작업 목록이 나오면 '상위 4개로 먼저 동작하는 MVP를 만들라'고 지시하는 것이 그의 팁이며, property-based test와 MCP(예: Jira·Asana 티켓을 스펙에 끌어오기)도 함께 활용한다. 그린필드뿐 아니라 오래된 레거시 프로젝트에도 잘 맞는다고 말한다.

주요 인사이트

• 모델 성능이 좋아져도 '맥락 제공'이 결과 품질을 좌우한다 — 명세는 그 맥락을 명시적으로 남기는 장치다.
• 그린필드뿐 아니라 수년 된 레거시 프로젝트에도 수십 개의 스펙 파일을 둘 수 있다.
• 작업 목록이 나오면 '상위 4개로 먼저 동작하는 MVP를 만들라'고 지시하면 빠르게 결과를 확인할 수 있다.
• property-based test는 요구사항·설계 문서를 기준으로 수십~수백 회 검증해 구현이 명세를 충족하는지 확인한다.
• MCP를 쓰면 Jira·Asana의 티켓과 요구사항 문서를 스펙 생성 단계에 직접 끌어올 수 있다.

자주 묻는 질문

관련 AI 소식