AI시대: SDLC는 끝났는가 — SDD, Spec 기반 개발

SDLC(Software Development Life Cycle)는 소프트웨어를 체계적으로 개발하기 위한 구조화된 프레임워크입니다.
1956년 Herbert Benington이 대규모 군사 소프트웨어 개발 과정을 단계적으로 기술하면서 그 개념이 처음 등장했고, 1970년 Winston Royce가 Waterfall 모델을 통해 요구사항 → 설계 → 구현 → 검증 → 유지보수의 프로세스로 정형화했습니다. 이후 소프트웨어의 복잡도와 형태가 다양해 지면서 소프트웨어 개발 방법론은 지속적으로 진화해 왔습니다.

그렇지만, SDLC의 본질적 구조는 유지됐습니다. 어떤 방법론이든 요구사항을 분석하고, 구조를 설계한 후에 구현에 들어가고 검증 과정을 통해 구현물을 점검하는 단계는 존재했고, 각 단계는 여러 산출물들을 만들어냅니다. 요구사항 정의서, 설계서, 테스트 계획서 — 이 문서들은 고객이나 과제 PL, 다음 단계 담당자 등 다양한 이해관계자들 사이의 의사소통 수단이었습니다.

산출물의 독자는 항상 인간이었습니다.

그런데 AI가 개발을 주도하기 시작하면서, 이 구조가 본질적으로 흔들리고 있습니다.
산출물의 독자가 인간에서 AI로 바뀌고 있기 때문입니다.

SDD(Spec-Driven Development)는 이 변화를 가장 선명하게 포착한 개념입니다.
최근 등장한 이 접근법은, AI 시대의 개발 프로세스를 근본적으로 재정의하려는 시도입니다.

이 문서들이 존재하는 이유는 단순합니다. 이해관계자들 간의 의사소통 때문입니다. 특히 각 단계 담당자들 간에 진행한 결과를 전달하기 위한 수단인 것입니다. 요구사항 분석가가 작성한 내용을 설계자가 읽고, 설계자의 산출물을 개발자가 읽고, 개발자의 코드를 테스터가 읽습니다.

각 단계 사이의 의사소통을 명확하게 하여 에러를 최소화 하는 것이 문서의 역할이었습니다.

AI가 등장하면서 초기에는 이 과정이 더 편해질 것으로 예상했습니다.
AI를 이용해서 고객과의 회의록을 요구사항 정의서로 정리하고, 다시 이를 바탕으로 설계서 초안을 만들고, 테스트 케이스를 자동으로 생성했습니다.

즉 인간용 산출물을 더 빠르게 만드는 도구로서의 AI였습니다.

그런데 AI의 성능이 좋아지고, AI의 역할이 확대되면서, 이제 상황이 달라집니다.
AI가 단순히 코딩을 도와주는 도구에서 코딩 에이전트로 진화하면서, 코딩, 즉 구현 단계의 담당자가 된 것입니다.
즉 중간 산출물의 중요 독자 중 하나가 인간이 아닌 AI가 되었음을 의미합니다.

여기서 근본적인 질문이 생깁니다.

요구사항 정의서를 읽고 코드를 짜는 것이 AI라면, 그 문서는 어떻게 달라져야 하는가?

인간 친화적인 문서와 AI 친화적인 문서는 분명히 다릅니다.
인간은 기본적으로 문맥을 추론합니다. 작성된 글의 행간을 읽고, 불명확한 부분을 경험으로 채웁니다. 하지만 AI는 그렇지 않습니다. 무엇을 만들지, 무엇을 만들면 안 되는지, 어떻게 검증할 지가 명확하게 기술되어야 합니다.

AI는 분량보다 구조화된 형식에 더 민감합니다.
인간은 수백 페이지의 문서를 이해하기 위해 클래스 다이어그램, 시퀀스 다이어그램, 디플로이먼트 다이어그램 등 다양한 추상화 기법을 활용합니다. 하지만 AI에게는 추상화된 이미지보다 구조적으로 기술된 마크다운이 더 효과적입니다. 불필요한 추상화는 AI가 스스로 채워야 할 공간을 늘려, 결과적으로 할루시네이션 같은 부작용을 일으킬 수 있습니다.

산출물의 독자가 바뀌면, 산출물의 형식도 바뀌어야 합니다. 이것이 SDD의 출발점입니다.

SDD란 무엇인가

SDD(Spec-Driven Development) 는 코드가 아닌 Spec을 개발의 가장 중요한 핵심 산출물로 삼는 개발 방식입니다.

전통적인 SDLC에서 문서는 코드를 만들기 위한 준비물이고, 각 단계는 좋은 코드를 만들기 위한 과정이었습니다.
하지만, SDD에서는 관계가 역전됩니다. 코드는 Spec의 구현체 일 뿐이고, Spec만이 개발의 유일한 진실 공급원(Single source of truth)입니다.

Spec의 형식은 마크다운 파일입니다. 자연어로 작성되지만, 구조화된 형식을 따르고, 아래 내용들이 핵심 요소입니다.

Outcomes: 완료 기준
Scope boundaries: 포함 범위와 제외 범위
Constraints: 기술적 제약, 보안 요건, 규정 준수 사항
Prior decisions: 이미 결정된 아키텍처나 패턴
Task breakdown: 구현 단위로 분해된 작업 목록
Verification criteria: 검증 방법

중요한 것은 Spec이 살아있는 문서 라는 점입니다. 한번 작성하고 서랍에 넣는 관행적인 기존의 설계서와 다릅니다.
코드가 바뀌면 Spec도 바뀌고, Spec이 바뀌면 코드가 재생성됩니다.
GitHub의 표현을 빌리자면, “버전 관리되는 사고(version control for your thinking)” 입니다.

다만 SDD를 어느 수준까지 적용하느냐에 따라 구현 방식은 달라집니다.
Spec을 코드 작성 전에 한번 작성하는 것(Spec-first)부터, 작업 완료 후에도 Spec을 계속 유지하며 진화시키는 것(Spec-anchored), 나아가 개발자는 Spec만 편집하고 코드는 AI가 전적으로 재생성하는 것(Spec-as-source)까지 다양한 스펙트럼이 존재합니다. 현재 대부분의 SDD 툴은 Spec-first 수준이며, Spec-as-source는 아직 실험적 단계로 봐야할 듯 합니다.

SDD의 흐름은 아래와 같습니다. 각 단계는 순차적이되, 단방향이 아니라 계속 순환하면서 Spec을 업데이트 합니다.

엔지니어의 질문들

SDD를 접하면서 자연스럽게 떠오르는 실질적인 질문들이 있습니다.

버그가 생기면, 코드를 고치나? Spec을 고치나?

SDD의 답은 명확합니다. Spec을 고치고, 코드를 재생성합니다.

코드를 직접 수정하면 Spec과 코드 사이의 일관성이 깨지게 됩니다. Spec은 “A를 구현하라”고 되어 있는데, 실제 코드는 “B로 패치된 상태”가 됩니다. 여기서 AI에게 다시 작업을 맡기면, AI는 A를 가정하고 작업을 하므로 B가 날아갈 수 있습니다.

코드 리뷰의 의미도 달라집니다. AI가 생성한 코드를 라인 단위로 리뷰하는 것보다, Spec이 올바른지를 검토하는 것이 더 중요한 리뷰가 됩니다. 인간의 검증 대상이 코드에서 Spec으로 이동했다는 것을 의미합니다.

AI-friendly Repository란 따로 있는가?

있습니다. 기존 Repository 구조와는 다른 원칙이 적용됩니다.

Spec 파일들(.md)이 코드와 함께 Repository 안에서 버전 관리됩니다. 계층 구조는 대략 이렇습니다.

/
├── .spec/
│   ├── constitution.md       # 전체 프로젝트 컨텍스트, 기술 스택, 아키텍처 원칙
│   ├── requirements/         # 기능별 요구사항 Spec
│   ├── design/               # 설계 결정 기록
│   └── tasks/                # 구현 단위 작업 명세
├── src/
│   └── ...                   # AI가 생성한 코드
└── tests/
    └── ...                   # Spec에서 파생된 테스트

이 구조에서 AI는 매 작업마다 constitution.md를 context로 읽고, 해당 기능의 Spec을 참조하여 코드를 생성합니다.
AI가 일관된 판단을 하려면, context가 구조화되어 있어야 합니다. 무엇이 전체 프로젝트의 제약인지, 무엇이 이번 태스크의 범위인지가 명확히 분리되어야 합니다.

대규모 프로젝트에서는 Monorepo vs. Poly-repo의 선택도 달라집니다.
AI 에이전트가 여러 서비스를 넘나들며 작업할 때, Spec의 범위와 Repository의 경계를 어떻게 맞출지가 새로운 아키텍처 질문이 됩니다.

인간의 역할은 어떻게 바뀌는가?

코드 작성자에서 Spec Architect 로 바뀝니다.

무엇을 만들지 정의하고, Spec의 품질을 책임지고, AI가 생성한 결과물을 검증하는 것이 핵심 역할이 됩니다.
필요시 단계 사이의 승인 게이트(phase gate) 를 인간이 담당합니다. Spec이 올바른지 확인하고, Plan이 의도에 맞는지 검토하고, 생성된 코드가 Spec을 충족했는지 최종 확인합니다.

얼핏 생각해보면, 인간의 역할이 낮아진 걸로 볼 수도 있지만, 그렇지 않습니다. 오히려 더 높은 수준의 판단을 요구합니다.
AI가 “어떻게 만드는가”를 담당한다면, 인간은 “무엇을 만드는가”와 “왜 만드는가”를 담당해야 합니다.

변곡점으로서의 SDD

수백 페이지짜리 설계서가 사라지는 것은, 문서 작성의 어려움 때문이 아닙니다. 산출물의 독자가 바뀌었기 때문입니다.

SDLC의 각 단계 자체가 없어지는 것도 아닙니다.
요구사항 분석은 여전히 필요하고, 설계도 필요하고, 검증도 필요합니다. 달라지는 것은 그 산출물의 형식입니다.
인간 간 의사소통 도구였던 문서가, AI의 작업 지시서인 Spec으로 바뀝니다.

SDD는 아직 best practice가 정립 중인 영역입니다. 작은 태스크에는 오버킬이 될 수 있고, 툴마다 구현 방식도 다릅니다. GitHub Spec Kit, Kiro 등 경쟁하는 접근법들이 아직 정리되지 않은 걸로 보입니다.

그럼에도 방향은 분명합니다. 소프트웨어 개발 패러다임이 크게 바뀌고 있습니다.
코드는 더 이상 개발의 시작점이 아닙니다. Spec이 시작점이고, 코드는 그 결과물입니다.
AI시대에, 가장 중요한 개발 역량은 좋은 코드를 짜는 능력이 아니라 좋은 Spec을 정의하는 능력이 될 것입니다.

AI시대에도 여전히 인간이 주도합니다.

ChulJoo Kim (김철주).

※ 참고 문헌