SDD(Spec-Driven Development) 방법론

[k9425mino]

📆 일자: 26년 7월 29일(수)

요즘 개발 트렌드는 AI 에이전트를 활용한 개발이 주를 이루고 있습니다. AI 에이전트는 개발 생산성을 크게 높여주지만, 프로젝트가 고도화될수록 무분별한 코드 생성과 환각 문제가 두드러진다는 한계도 있습니다. 이러한 상황에서 SDD는 명세를 팀의 단일 진실 공급원으로 삼아, 협업 과정에서의 일관성과 체계적이고 효율적인 개발을 가능하게 합니다. SDD는 비교적 최근 등장한 개념이라 아직 논란의 여지가 있을 수 있지만, 개발자의 역할이 '코드를 작성하는 사람'에서 '스펙을 검증하고 테스트를 설계하는 사람'으로 변화하는 흐름에 부합하는 방법론입니다. 이에 따라 이번 스터디에서는 SDD(Spec-Driven Development) 방법론에 대해 알아보고자 합니다.

🤔오늘의 질문

1. SDD의 정의와 등장 배경을 설명해주세요.
2. SDD의 핵심 원칙과 워크플로우를 설명해주세요.
3. SDD의 장점과 한계를 설명해주세요.
4. SDD 프레임워크 2~3개 정도를 간단하게 소개해주세요.

[9ga0]

SDD(Spec-Driven Development) 방법론 #21

1. SDD의 정의와 등장 배경을 설명해주세요.

Spec-Driven Development는 코드를 먼저 작성하기 보다, 명세(spec)를 작성하고 그 명세를 기준으로 설계, 구현, 테스트, 리뷰를 진행하는 개발 방법론입니다. 여기서 명세는 단순 요구사항 목록뿐만 아니라, 무엇을 만들지, 어떤 동작을 할지/하지말지, 예외 상황 어떻게 처리할지, 입출력, 완료 기준, 테스트 방법 등을 포함합니다.
소프트웨어 규모가 커지면서 사람과의 협업이나 ai와의 협업 시 개발 의도를 명확하게 전달하기 위해서 명확한 기준 문서의 필요해지게 되면서 SDD가 주목받게 되었습니다.

2. SDD의 핵심 원칙과 워크플로우를 설명해주세요.

핵심 원칙은 대표적으로 Spec First, Shared Source of Truth, Unambiguous Behavior, Testable Secification, Iterative Refinement, Boundary Clarity 로 6가지가 있습니다.

• Spec First : 구현 전에 명세를 먼저 작성한다.
• Shared Source of Truth : 명세를 기획자, 개발자, QA, AI 에이전트가 함께 보는 기준으로 삼는다.
• Unambiguous Behavior : "잘 동작해야 한다"가 아니라 구체적인 입력, 출력, 상태, 예외를 적는다.
• Testable Secification : 명세는 테스트 가능한 형태여야 한다.
• Iterative Refinement : 명세는 한 번에 완성하는 문서가 아니라 구현과 피드백을 거치며 갱신된다.
• Boundary Clarity : 이번 작업의 범위, 비범위, 의존성, 변경 금지 영역을 명확히 한다.

일반적인 워크플로우는 문제와 목표 정의, 명세 작성, 명세 리뷰, 테스트 기준화, 구현, 검증, 명세 갱신 순서를 따릅니다.

3. SDD의 장점과 한계를 설명해주세요.

장점)

• 요구사항 해석 차이를 줄인다.
• 개발 전에 누락된 조건과 모순을 발견할 수 있다.
• 테스트 기준이 명확해진다.
• 코드 리뷰가 "취향 논쟁"보다 "명세 충족 여부" 중심으로 바뀐다.
• 신규 개발자의 온보딩이 쉬워진다. (안내서 역할까지 가능)

  실제 회사에서는 신규 개발자가 입사하면 보통 이런 순서로 온보딩이 진행됩니다.
  1. 프로젝트 소개
  2. 개발 환경 설정
  3. SDD 또는 기술 문서 읽기
  5. 시스템 아키텍처 이해
  6. 작은 버그 수정
  7. 작은 기능 개발
  8. 큰 기능 개발
  이 과정을 통해 몇 주에서 몇 달에 걸쳐 프로젝트를 이해하게 됩니다.

• AI 코딩 도구에 더 정확한 작업 지시를 줄 수 있다.
• 큰 기능을 작은 명세 단위로 쪼개기 좋다.
• 유지보수 시 "왜 이렇게 만들었는가"를 추적하기 쉽다.

한계)

• 명세 작성 시간이 추가로 필요하다.
• 오래된 명세는 혼란을 만든다.
• 불확실성이 큰 초기 제품에서는 지나친 명세화가 개발 속도를 늦춘다.
• 모든 요구사항을 문서로 완벽하게 표현하기 어렵다.
• 팀이 명세를 읽고 갱신하는 습관이 없으면 형식적인 문서가 된다.
• 창의적 UI, 탐색적 프로토타입, 연구성 작업에는 유연한 접근이 더 적합할 수 있다.
  * 탐색적 프로토타입 : "무엇을 만들지 아직 확실하지 않은 상태"에서 빠르게 시제품을 만들어 아이디어를 검증하는 방식

4. SDD 프레임워크 2~3개 정도를 간단하게 소개해주세요.

SDD 프레임워크는 대표적으로 SpecDD, BDD, Specification by Example이 있습니다.

• SpecDD : Spec-Driven Development를 위해 .sdd 파일을 코드 가까이에 두는 방식의 프레임워크입니다. 각 기능이나 모듈 옆에 명세를 두고, 의도, 책임, 경계, 의존성, 완료 기준 등을 기록합니다. 특히 AI 에이전트와 사람이 같은 명세를 기준으로 작업하는 흐름에 잘 맞습니다. https://specdd.ai/
• BDD / Cucumber : Behavior-Driven Development로, 사용자의 행동과 시스템 반응을 예시 중심으로 명세화합니다. Cucumber는 Gherkin 문법을 사용해 Given, When, Then 형태로 실행 가능한 명세를 작성하게 해줍니다. SDD와 완전히 같은 것은 아니지만, “명세를 먼저 쓰고 구현과 테스트를 연결한다”는 점에서 매우 가까운 실천 방식입니다.
  https://cucumber.io/docs/bdd/
• Specification by Example : 추상적인 요구사항보다 구체적인 예시를 통해 명세를 만드는 방식입니다. 예를 들어 “할인을 적용한다”가 아니라 “VIP 사용자가 10만 원 이상 구매하면 15% 할인을 받는다”처럼 실제 사례를 기준으로 합의합니다. 이후 이 예시는 인수 테스트나 자동화 테스트로 연결될 수 있습니다.
  https://martinfowler.com/bliki/SpecificationByExample.html

AI 시대에는 “프롬프트를 잘 쓰는 것”보다 한 단계 더 나아가, 프로젝트 안에 지속 가능한 명세 체계를 두는 것이 중요해지고 있다.