직접적인 답변

명세 기반 개발 (Spec-driven development, SDD)은 코드가 아닌, 작성되고 버전이 관리되는 명세(specification)가 진실의 원천 (source of truth)이 되는 워크플로우입니다. 즉, 팀이 시스템이 무엇을 해야 하는지 기록하고, 계획을 도출하며, 이를 작업 단위로 나누고 나서야 AI 에이전트가 구현을 생성하도록 하는 방식입니다. Scrum에서는 상세 명세가 Product Backlog에 묻혀 있기보다는, 작업이 인출되는 시점에 Sprint 중에 작성되어 실행 단계에 더 가깝게 위치합니다. Kanban에서는 명세가 아무도 추적하지 않는 보이지 않는 산출물이 아니라, "진행 중 (in progress)" 및 "검토 중 (in review)"와 함께 보드 위의 가시적인 단계가 됩니다.

2026년에 애자일 팀들이 명세를 다시 검토하는 이유

지난 10년 동안 대부분의 경우, "명세를 먼저 작성하라"는 말은 애자일이 탈피하기 위해 만들어진 바로 그 습관처럼 들렸습니다. 하지만 상황이 변했습니다. 그 이유는 프로세스의 유행 때문이 아니라, 티켓을 구현하는 주체가 사람이 아니게 되었을 때 발생하는 현상 때문입니다.

모호한 요구사항을 전달받은 개발자는 자신의 판단력과 종종 명확화 질문을 통해 그 간극을 메웁니다. 반면 AI 에이전트는 동일한 간극을 자신의 최선의 추측으로 채우며, 그 추측이 누군가 의도적으로 내린 결정으로 오해하기 쉬울 만큼 유창하게 전달됩니다. Sonar의 2026년 개발자 설문 조사에 따르면, 개발자의 88%가 AI가 기술 부채 (technical debt)에 최소 한 가지 이상의 부정적인 영향을 미친다고 보고했으며, 특히 53%는 겉보기에는 올바르지만 숨겨진 결함을 유발하는 코드를 지목했습니다 (Sonar, 2026). 2026년 Stack Overflow 개발자 설문 조사에 대한 별도의 보고에 따르면, AI 도구를 사용하는 대다수의 개발자가 적어도 어느 정도의 시간에는 자신이 완전히 이해하지 못한 코드를 생성한 적이 있다고 답했습니다. 이러한 패턴은 초보자뿐만 아니라 숙련된 엔지니어들에게서도 나타납니다 (DEV Community, 2026).

명세 기반 개발 (Spec-driven development)은 이에 대한 대응책입니다. 에이전트가 질문하지 않을 것이기 때문에, 에이전트가 시작하기 전에 계약 (contract)을 명시적으로 만드는 것입니다.

Scrum에서 명세(spec)는 어디에 위치하는가?

흔히 하는 실수는 전체 에이전트 실행 가능 명세(agent-executable spec)를 백로그 정제(Backlog Refinement)나 스프린트 계획(Sprint Planning) 단계에 억지로 밀어 넣으려는 것입니다. 그렇게 되면 정제 과정은 독백으로 변질됩니다. 한 사람이 이미 결정된 전체 명세를 들고 나타나면, 나머지 팀원들은 기여할 수 있는 것이 아무것도 남지 않게 됩니다.

이 주제에 관한 최근의 애자일(agile) 글들에서 공통적으로 언급되는, 더 실행 가능한 고도(altitude) 분할 방식은 다음과 같습니다:

Yuval Yeret는 명세가 더 높은 수준의 프로그래밍 언어(higher-level programming language)가 되고 있다고 설명합니다. 즉, 인간은 해당 계층에서 의도, 제약 조건, 수락 기준을 보유하고, 에이전트는 그 지점부터 구현을 처리한다는 것입니다 (Yeret, 2026). 이러한 프레임워크는 왜 상세 명세를 사이클의 너무 이른 단계로 밀어붙이는 것이 역효과를 내는지 설명해 줍니다. 실제 작업이 시작되기 직전까지는 아무도 명세를 잘 작성할 수 있을 만큼 충분한 컨텍스트를 가지고 있지 않기 때문입니다.

Kanban에서 명세(spec)는 어디에 위치하는가?

Kanban은 이를 수용하기 위해 새로운 프레임워크가 필요한 것이 아니라, 새로운 레인(lane)이 필요합니다. 이미 "대기 중(queued)", "진행 중(in progress)", "검토 중(in review)"을 시각화하고 있는 보드에 명세 상태를 위한 단계를 추가할 수 있습니다: 초안 작성(drafted), 승인됨(approved), 에이전트 구축 중(agent building), 인간의 결과물 검토(human reviewing output). 이는 Kanban의 핵심 규율인 "재공품(work in process) 제한", "병목(blockage) 가시화"를, 보드에서 추적되지 않을 경우 누군가의 에디터 안에서 조용히 방치되기 쉬운 산출물(artifact)에 직접적으로 적용한 확장입니다.

현재 툴링(tooling) 환경의 모습

SDD를 중심으로 구축된 도구들은 동일한 기본적인 움직임으로 수렴합니다: 코드를 작성하기 전에 서면 요구사항 산출물(written requirements artifact)을 생성하고, 채팅 기록(chat history)이 아닌 해당 산출물을 무엇을 만들 것인지에 대한 참조(reference)로 취급하는 것입니다.

• GitHub Spec Kit은 2025년 9월에 오픈 소스로 공개되었으며, 여러 AI 코딩 어시스턴트(AI coding assistants)에서 작동하는 슬래시 명령어(/specify, /plan, /tasks, /implement)를 갖춘 모델 불가지론적 (model-agnostic) CLI입니다 (GitHub Spec Kit).
• AWS Kiro는 더 엄격한 접근 방식을 취합니다. EARS 표기법(EARS notation)으로 작성된 요구사항 문서가 생성되고 승인될 때까지는 코드 생성을 허용하지 않습니다 (Kiro documentation).
• 8080.ai를 포함한 **멀티 에이전트 빌드 플랫폼 (Multi-agent build platforms)**은 애플리케이션 레벨에서 동일한 원칙을 적용합니다. 단일 프롬프트가 전체 요구사항 문서와 아키텍처 다이어그램(architecture diagram)을 생성하며, 전문 에이전트들이 프론트엔드, 백엔드, 인프라 코드를 병렬로 작성하기 전에 반드시 인간의 승인을 거쳐야 합니다.

이 중 그 어떤 것도 코드 생성(code-generation) 문제를 해결하려는 것이 아닙니다. 이들은 조정(coordination) 문제를 해결하고 있습니다. 즉, 과거에는 시니어 엔지니어의 머릿속에 비공식적으로 존재했던 의도(intent)에 맞춰, 문자 그대로만 이해하는 빠른 협업자(AI)를 정렬시키는 것입니다.

실제 사례: 하나의 백로그 아이템, 두 가지 워크플로

명세 기반 개발 (Spec-driven development)이 없는 경우: 백로그 아이템은 "보고 대시보드에 CSV 내보내기 기능 추가"라고 적혀 있습니다. 이 아이템은 구체화되고, 추정되며, 스프린트(sprint)에 포함됩니다. 개발자는 코드베이스를 열고 구현을 시작하며, 그 과정에서 어떤 열을 포함할지, 누락된 데이터가 있는 행을 어떻게 처리할지, 500,000행을 내보낼 때 어떤 일이 발생하는지 등 일련의 작은 미기록 결정(unwritten calls)을 내립니다. 이러한 결정 중 어느 것도 어디에도 문서화되지 않습니다. 만약 개발자 대신 AI 에이전트가 구현을 수행한다면, 에이전트 역시 동일한 결정을 내리겠지만, 누락된 데이터 케이스가 운영 환경(production)에서 문제를 일으키기 전까지는 아무도 이를 알아차리지 못합니다.

명세 기반 개발 (Spec-Driven Development)을 사용하면: 백로그 항목 (backlog item)은 동일합니다. 차이점은 항목이 실제 작업으로 인계될 때부터 시작됩니다. 코드가 생성되기 전에 누군가가 짧은 명세 (spec)를 작성합니다. 어떤 컬럼을 내보낼지, 필드가 누락된 행(row)은 어떻게 처리할지, 스트리밍 (streaming) 대 배치 (batch) 내보내기를 결정할 크기 임계값은 무엇인지, 그리고 테스트 가능한 용어로 정의된 "완료 (done)"의 의미는 무엇인지 등을 작성합니다. 이 명세는 빠른 검토를 거친 후 에이전트 (agent)에게 전달됩니다. 결과물로 나온 코드는 명세와 직접 대조하여 확인할 수 있으며, 6개월 후 누군가 내보내기 로직을 수정해야 할 때도 이 명세는 왜 코드가 그렇게 동작하는지를 여전히 설명해 줍니다.

백로그 항목은 변하지 않았습니다. 변한 것은 개발자의 머릿속에만 존재하던 일련의 결정 사항들이 이제 팀 전체와 해당 코드를 작업하는 모든 미래의 에이전트가 읽을 수 있는 문서로 존재하게 되었다는 점입니다.

자주 묻는 질문 (Frequently asked questions)

명세 기반 개발이 스크럼 (Scrum)이나 칸반 (Kanban)을 대체하나요?
아니요. 프레임워크 자체를 바꾸는 것이 아니라, 무엇을 언제 문서화할지를 바꾸는 것입니다. 스프린트 리뷰 (Sprint Review), 회고 (Retrospective), 재공품 (WIP) 제한, 흐름 시각화 (flow visualization)와 같은 스크럼과 칸반의 핵심 메커니즘은 대부분 잘 유지됩니다. 변하는 것은 상세한 기술 명세 (technical specification)가 이루어지는 지점입니다.

이것은 단순히 단계만 더 추가된 폭포수 (waterfall) 모델 아닌가요?
범위 (scope)를 올바르게 설정한다면 그렇지 않습니다. 팀이 주의해야 할 실패 모드는 때때로 "SpecFall"이라 불리는데, 이는 몇 달 전에 전체 명세를 작성한 뒤 이를 변경 불가능한 것으로 취급하여 애자일 (agile)이 피하고자 했던 경직성을 재현할 때 발생합니다 (InfoQ, 2026). "구축하는 시점에 작성하며, 이해도가 높아짐에 따라 수정 가능하다"라는 범위 내에서 이루어진다면 그렇지 않습니다.

스토리 포인트 (story points)와 작업 분할 (task breakdown)은 어떻게 되나요?
점점 더 선택 사항이 되어가고 있습니다. 만약 에이전트가 구현 계획 (implementation plan)을 생성하는 과정의 일부로 명세를 작업으로 분해한다면, 스프린트 계획 (Sprint Planning) 단계에서 수동으로 동일한 분할 작업을 다시 수행하는 것은 종종 불필요한 중복이 됩니다.

왜 수년 전이 아닌 지금 이런 일이 일어나고 있는가?
모호함의 비용이 변했기 때문입니다. 과거에는 인간이 판단력으로 그 간극을 메웠지만, 에이전트(Agent)는 정답만큼이나 확신에 찬 어조로 추측을 내놓으며 그 간극을 메웁니다. 그리고 그 결과로 발생하는 재작업(Rework)은 최근 개발자 설문 조사 전반에 걸쳐 잘 기록되어 있습니다.

명세 기반 개발 (Spec-driven development)이 바이브 코딩 (Vibe coding)과 같은 것인가?
아니요, 그것은 교정책입니다. 바이브 코딩 (Vibe coding)은 에이전트 (Agent)에게 느슨하게 프롬프팅 (Prompting)을 하고 결과물이 무엇이든 그대로 배포하는 것입니다. 반면 명세 기반 개발 (Spec-driven development)은 코드 생성 (Code generation)이 시작되기 전에 명시적이고 검토 가능한 계약 (Contract)을 요구하며, 이것이 바로 바이브 코딩 (Vibe coding)이 건너뛰는 단계입니다.

명세 기반 개발 (Spec-driven development)이 팀의 속도를 늦추는가?
이를 사용하는 팀들에 따르면 전체적으로는 그렇지 않습니다. 짧은 명세 (Spec)를 작성하는 데 소비되는 시간은 일반적으로 모호한 프롬프트 (Prompt)로부터 구축된 코드를 나중에 디버깅 (Debugging)하거나 다시 작성하는 데 드는 시간보다 작습니다. 비용이 나중에 더 크게 발생하는 대신, 더 일찍 더 작게 나타나는 것입니다.