SDD란 무엇일까?

김재연·2026년 1월 25일
post-thumbnail

SDD(Spec-driven Development), 내가 요즘 정리하고 있는 개발 방식

요즘 들어 개발하면서
“코드를 잘 짜는 것”보다
“무엇을 왜 짜고 있는지 잃지 않는 것”이 더 중요하다는 생각을 자주 하게 된다.

특히 AI를 적극적으로 활용하면서
이 감각은 더 강해졌다.

코드는 점점 더 빨리 만들어지는데,
그만큼 사고의 맥락은 더 쉽게 사라진다는 느낌을 받았기 때문이다.

그러다 자연스럽게 SDD라는 개념을 접하게 됐다.


SDD란 무엇인가

SDD(Spec-driven Development)는
아직 완전히 정립된 정의가 있는 개념은 아니다.

다만 공통적으로 이야기되는 핵심은 비교적 명확하다.

코드를 작성하기 전에, 먼저 Spec을 작성한다

Spec-driven Development,
혹은 Documentation First 방식이라고 불러도 크게 어색하지 않다.

최근에는 kiro, spec-kit 같은 도구들이 등장하면서
SDD가 조금 더 구체적인 형태로 논의되고 있다.

이 도구들이 제시하는 기본 흐름은 다음과 같다.

요구사항(Requirements)을 정리하고,
그 위에 설계(Design)를 얹고,
그 다음에 실제 작업(Task, Implementation)을 진행한다.

굉장히 당연해 보이는 이야기지만,
막상 현실에서는 자주 생략되는 단계이기도 하다.


spec-kit과 Memory Bank 개념이 흥미로웠던 이유

spec-kit을 보면서 가장 인상 깊었던 개념은
Memory Bank였다.

Memory Bank는
작업 흐름 중간중간 참고하는 선택 사항이 아니라,
프로젝트 전반에 걸쳐 무조건 지켜져야 하는 규칙 묶음에 가깝다.

예를 들면 이런 것들이다.

  • 코딩 컨벤션
  • 설계 철학
  • AI가 반드시 따라야 할 전제 조건들

spec-kit에서는
이 Memory Bank를
SDD 접근 방식의 전제 조건처럼 다룬다.

작업 흐름 전체를 관통하는
일종의 헌법 같은 파일인 셈이다.

이 지점이 꽤 마음에 들었다.


하지만, 도구를 그대로 쓰고 싶지는 않았다

다만 kiro나 spec-kit을 그대로 도입할지는
조금 고민이 됐다.

툴이 제공하는 구조 자체는 매력적이었지만,
한편으로는 이런 생각도 들었다.

  • 형식을 맞추는 데 에너지를 쓰게 되지는 않을까
  • 작은 변경에도 문서 구조부터 신경 써야 하지는 않을까
  • 결국 도구를 유지하는 비용이 커지지 않을까

그래서 결론적으로는
도구는 가져오지 않고, 개념만 가져오자는 쪽으로 정리했다.


내가 시도하고 있는 SDD 방식

지금 내가 시도하고 있는 방식은
꽤 단순하다.

먼저, 프로젝트 전반에 걸쳐
절대적으로 지켜야 할 규칙들을
Memory Bank 형태의 md 파일로 고정해둔다.

여기에는 코딩 컨벤션,
설계 방향,
AI가 따라야 할 기본 원칙들이 들어간다.

그리고 각 기능이나 모듈을 구현할 때마다
“왜 이렇게 구현했는지”를
별도의 md 파일로 남긴다.

중요한 점은
형식을 강제하지 않는 대신, 질문을 고정한다는 것이다.

예를 들면,

  • 이 변경은 어떤 문제를 해결하려고 했는가
  • 어떤 선택지들을 고민했는가
  • 왜 이 선택을 했는가
  • 나중에 바뀔 가능성이 높은 지점은 어디인가

이 정도만 남겨도,
나중에 코드를 다시 볼 때
맥락을 복원하는 데 큰 도움이 된다.


아직은 AI 자율주행이 아니라, 보조 운전 단계라고 생각한다

SDD 이야기를 하다 보면
AI가 모든 걸 알아서 해주는 미래를 떠올리기 쉽다.

하지만 적어도 지금 시점에서는
완전한 AI 자율주행 개발은 지양하는 게 맞다고 생각한다.

spec-kit을 사용하더라도,
결국 중간중간 검증하는 과정은 필요하고,
단계마다 되돌아보며 수정해야 한다.

SDD는 자동화를 위한 방법론이라기보다는,
사고를 멈추지 않게 만드는 장치에 가깝다고 느낀다.


왜 지금 SDD가 더 중요해졌을까

최근 바이브 코딩을 접하고,
AI를 적극적으로 활용하면서
한 가지 확실해진 게 있다.

구현은 AI에게 맡길 수 있다면,
나는 다른 곳에 더 집중하는 게 맞다

그 다른 곳이란 결국,

  • 요구사항을 정확히 이해하는 것
  • 설계의 방향을 잡는 것
  • 왜 이 선택을 하는지 스스로 설명할 수 있는 것

이런 영역들이다.

그래서 더더욱
Spec을 먼저 쓰고,
생각을 문서로 남기는 방식이
나에게는 잘 맞는다고 느끼고 있다.


마무리하며

지금 내가 하고 있는 SDD는
교과서적인 방법론도 아니고,
특정 도구에 종속된 방식도 아니다.

다만 분명한 목적은 있다.

  • 코드를 빨리 만드는 것보다
  • 생각을 잃지 않는 개발을 하고 싶다

SDD는 그걸 도와주는 하나의 프레임이고,
Memory Bank와 md 로그는
그 프레임을 유지하기 위한 최소한의 장치다.

아마 이 방식도
프로젝트를 거듭하면서 계속 바뀔 것이다.

하지만 적어도 지금 시점에서는,
내가 개발하면서 느끼는 고민들에
가장 솔직하게 답하고 있는 방식이라고 생각한다.

다음 글에서는
이 SDD 방식을 실제 프로젝트에서 어떻게 쓰고 있는지,
그리고 AI와의 협업이 어떤 식으로 달라졌는지를
조금 더 구체적으로 정리해볼 생각이다.

천천히, 계속 다듬어보려고 한다.

profile
끊임없이 '성장'하는 개발자 김재연입니다.

2개의 댓글

comment-user-thumbnail
2026년 1월 30일

이런 배경이..!

1개의 답글