AI 시대, Spec Driven Development: LLM과 협업하는 새로운 개발 방식

게시 2026/05/28

By woolam

조회 23 분읽는 시간

들어가며: AI 시대, 개발 방식은 어떻게 변해야 하는가?

최근 AI, 특히 LLM(Large Language Model)의 발전은 소프트웨어 개발 방식도 바꾸고 있습니다. 코드를 생성하고 테스트 케이스를 만들고 아키텍처까지 제안하는 AI의 능력은 개발자에게 새로운 가능성을 열어주었습니다. 하지만 동시에 우리는 한 가지 질문에 부딪힙니다. “AI와 함께 개발할 때, 우리는 무엇에 집중해야 하는가?”

단순히 Chat 기반으로 AI에게 “이런 기능 만들어줘”라고 요청하는 방식은 금세 한계에 부딪힙니다. AI는 우리가 기대하는 만큼 모든 컨텍스트를 이해하지 못하고, 모호한 요구사항은 모호한 결과로 이어지기 마련입니다. 주니어 개발자에게 대략적인 아이디어만 던져주고 완벽한 결과물을 기대할 수 없는 것과 같습니다. 저는 여기서 명세(Specification)의 중요성을 다시 깨달았습니다. AI 시대에 개발의 효율과 품질을 높이려면 SDD(Spec Driven Development)라는 개발 방법론에 주목할 필요가 있습니다.

기존 개발 방법론 흐름: SDD는 왜 등장했는가?

소프트웨어 개발 방법론은 시대의 요구와 기술 발전에 따라 꾸준히 진화해왔습니다. SDD가 왜 등장했는지 이해하려면 그 이전의 주요 방법론을 짚어볼 필요가 있습니다.

1. Waterfall (폭포수 모델)

등장 배경: 초기 소프트웨어 개발은 건축이나 제조업처럼 계획-설계-구현-테스트-배포의 순차적인 단계를 따르는 것이 효율적이라고 여겨졌습니다.
핵심 철학: 각 단계가 명확히 구분되며, 이전 단계가 완료되어야 다음 단계로 넘어갈 수 있습니다. 문서화와 계획을 중시합니다.
장점: 프로젝트의 구조가 명확하고, 진행 상황 파악이 용이하며, 대규모 프로젝트에 적합합니다.
한계: 요구사항 변경에 취약하고 피드백 반영이 어려워 시장 변화에 민첩하게 대응하기 어렵습니다. 개발 후반에 문제점이 발견될 경우 비용이 크게 증가합니다.

2. Agile (애자일)

등장 배경: Waterfall 모델의 경직성과 변화 대응의 어려움을 극복하기 위해 등장했습니다. 고객과의 소통, 변화에 대한 유연한 대응을 강조합니다.
핵심 철학: “개인과 상호작용 > 프로세스와 도구”, “작동하는 소프트웨어 > 포괄적인 문서”, “고객과의 협력 > 계약 협상”, “변화에 대한 대응 > 계획을 따르기”를 가치로 삼습니다.
장점: 변화에 유연하게 대응하고, 고객 만족도를 높이며, 빠른 피드백을 통해 품질을 개선합니다.
한계: 명확한 문서화 부족으로 인한 오해 발생 가능성, 대규모 프로젝트 관리의 어려움, 팀원 간의 높은 숙련도와 소통 능력이 요구됩니다.

3. TDD (Test Driven Development)

등장 배경: 애자일 방법론의 한 축으로, 코드의 품질과 신뢰성을 높이기 위해 제안되었습니다.
핵심 철학: “실패하는 테스트 코드 작성 → 테스트 통과를 위한 최소한의 코드 작성 → 코드 리팩토링”의 반복적인 사이클을 통해 개발을 진행합니다.
장점: 견고하고 유지보수하기 쉬운 코드, 높은 코드 커버리지, 빠른 피드백을 통한 버그 감소.
한계: 테스트 코드 작성에 드는 초기 비용, 테스트하기 어려운 코드 구조로 이어질 수 있음, 비즈니스 요구사항과의 직접적인 연결성 부족.

4. BDD (Behavior Driven Development)

등장 배경: TDD의 한계를 보완하고, 비즈니스 요구사항과 개발 코드 간의 간극을 줄이기 위해 등장했습니다.
핵심 철학: “Given-When-Then”과 같은 자연어 기반의 시나리오를 사용하여 시스템의 행동(Behavior)을 정의하고 이를 기반으로 테스트 및 개발을 진행합니다. 개발자, 테스터, 비즈니스 담당자 간의 협업을 강조합니다.
장점: 비즈니스 요구사항을 명확히 이해하고 공유, 높은 가독성의 테스트 코드, 고객과의 소통 증진.
한계: 시나리오 작성에 많은 시간 소요, 복잡한 시스템의 모든 행동을 시나리오로 표현하기 어려움, 도구 의존성.

5. SDD (Spec Driven Development)

등장 배경: BDD의 철학을 확장하여, 실행 가능한 명세(Executable Specification)를 개발의 중심에 두는 방법론입니다. 특히 API 중심의 개발이 많아지고 자동화된 코드 생성 및 검증의 중요성이 커지면서 주목받기 시작했습니다. 그리고 AI/LLM 시대에 들어서면서 그 중요성이 더욱 부각되고 있습니다.
핵심 철학: 시스템의 모든 기능과 행동을 명확하고 형식적인 Spec으로 정의하고 이 Spec을 기반으로 코드 생성, 테스트, 문서화를 자동화합니다. Spec 자체가 Single Source of Truth가 됩니다.
장점: 명확한 요구사항 정의, 자동화된 코드 생성 및 테스트, 문서와 코드의 일관성 유지, AI와의 효율적인 협업.
한계: 초기 Spec 작성에 높은 전문성 요구, Spec 변경 시 파급 효과 관리의 어려움, 적절한 도구와 프레임워크의 필요성.

SDD란 무엇인가: Spec이 개발의 중심이 되다

SDD는 말 그대로 명세(Specification)가 개발의 모든 것을 주도하는 방식입니다. 여기서 Spec은 단순한 문서가 아닙니다. 시스템의 기능과 인터페이스, 데이터 구조, 행동을 정확하고 모호함 없이 정의한 형식적인 계약입니다.

Spec: Single Source of Truth

SDD에서 Spec은 Single Source of Truth (단일 진실 공급원) 역할을 합니다. 시스템에 관한 모든 정보의 최종 출처이자 기준인 셈입니다. 개발자와 테스터, 기획자, AI까지 이 Spec으로 시스템을 이해하고 상호작용합니다.

Spec: 시스템의 “무엇을(What)” 할 것인가를 정의합니다. (예: API 엔드포인트, 요청/응답 스키마, 데이터 모델)
Tasks: Spec을 기반으로 “어떻게(How)” 구현할 것인가에 대한 세부 작업들을 정의합니다.
Implementation: Tasks에 따라 실제 코드를 작성하는 단계입니다.

기존 방식에서는 요구사항 문서와 설계 문서, 코드, 테스트 코드가 따로 관리되면서 불일치가 생기기 쉬웠습니다. SDD는 Spec을 중심으로 이 모두를 연결하고 자동화해 문서와 코드의 일관성을 보장합니다.

특히 LLM은 명확한 Spec이 있을 때 제 성능을 냅니다. 모호한 지시보다 잘 정의된 Spec이 AI에게 더 정확하고 유용한 컨텍스트를 주기 때문입니다. 잘 작성된 API 문서가 개발자에게 도움이 되듯, 잘 정의된 Spec은 AI에게 든든한 길잡이가 됩니다.

왜 AI 시대에 중요해졌는가: 컨텍스트 문제의 해결사

AI, 특히 LLM과 협업하다 보면 “컨텍스트(Context)”가 얼마나 중요한지 절감하게 됩니다. LLM은 방대한 지식을 갖췄지만, 특정 프로젝트나 기능의 암묵적인 지식이나 배경 정보는 알지 못합니다. 여기서 SDD가 해결책이 됩니다.

컨텍스트 윈도우 문제: LLM은 한 번에 처리할 수 있는 정보의 양(컨텍스트 윈도우)에 제한이 있습니다. 모든 프로젝트의 상세 내용을 AI에게 한 번에 전달하기는 어렵습니다. Spec은 필요한 정보만을 응축하여 효율적인 컨텍스트를 제공합니다.
암묵적 지식 전달 실패: 개발팀 내부에서 공유되는 암묵적인 지식이나 관례는 AI에게 전달되기 어렵습니다. Spec은 이러한 암묵적인 부분을 명시적으로 정의하여 AI가 오해 없이 작업을 수행하도록 돕습니다.
문서와 코드 불일치: 기존 개발에서는 문서와 코드가 따로 놀아 불일치가 자주 발생했습니다. AI가 코드를 생성할 때 잘못된 문서나 오래된 정보를 참조하면 문제가 커집니다. Spec을 Single Source of Truth로 삼으면 이러한 불일치를 원천적으로 방지할 수 있습니다.
반복적인 설명 비용: AI에게 매번 동일한 배경 정보나 제약 사항을 설명하는 것은 비효율적입니다. Spec은 한 번 정의되면 재사용 가능하며, AI는 이를 바탕으로 일관된 결과물을 생성할 수 있습니다.

Spec은 AI와 협업할 때 컨텍스트 역할을 합니다. 명확한 Spec은 AI에게 “이 프로젝트는 이런 규칙을 따르고, 이런 기능을 만들어야 하며, 이런 제약사항이 있다”고 알려주는 가장 효율적인 방법입니다.

실제 개발 흐름: Spec → Tasks → Implementation

SDD를 실제 개발에 적용하는 흐름은 다음과 같습니다.

Spec 작성: 개발의 첫 단계는 시스템의 기능과 행동을 명확하게 정의하는 Spec을 작성하는 것입니다. OpenAPI Specification(OAS)과 같은 표준화된 형식을 사용하여 API의 엔드포인트, 요청/응답 스키마, 인증 방식 등을 상세하게 기술합니다. 이는 사람과 AI 모두가 이해할 수 있는 언어로 작성되어야 합니다.
- 예시: 사용자 인증 API의 Spec을 OAS로 작성. “/auth/login 엔드포인트는 username과 password를 받아 JWT 토큰을 반환한다.” 와 같이 명확히 정의합니다.
Tasks 분해: 작성된 Spec을 기반으로 실제 구현에 필요한 세부 작업(Tasks)들을 분해합니다. 이 단계에서 AI의 도움을 받을 수 있습니다. AI에게 Spec을 제공하고 “이 Spec을 구현하기 위한 백엔드 API, 프론트엔드 컴포넌트, 데이터베이스 스키마 변경 등의 Tasks를 생성해줘”라고 요청할 수 있습니다.
- 예시: “로그인 API Spec을 기반으로, 백엔드에서는 AuthController와 AuthService 구현, 프론트엔드에서는 LoginForm 컴포넌트 구현, 데이터베이스에는 users 테이블에 password 필드 암호화 로직 추가”와 같은 Tasks를 도출합니다.
LLM에게 컨텍스트 전달: 이제 각 Task를 수행하기 위해 LLM에게 Spec과 Task를 컨텍스트로 전달합니다. 이때, 전체 Spec을 한 번에 전달하기보다는, 해당 Task에 필요한 부분만 선별하여 전달하는 것이 효율적입니다. LLM은 이 컨텍스트를 바탕으로 코드 스니펫, 테스트 코드, 문서 초안 등을 생성합니다.
- 예시: “다음 로그인 API Spec과 Task를 기반으로, Python Flask로 로그인 API 핸들러 코드를 작성해줘. JWT 토큰 발행 로직 포함.” (Spec과 Task 코드 블록을 함께 전달)
구현 (AI Assisted Implementation): LLM이 생성한 코드를 검토하고, 필요한 경우 수정 및 보완하여 실제 구현에 반영합니다. AI는 초안을 빠르게 생성하여 개발 속도를 높이는 역할을 하며 개발자는 AI가 놓칠 수 있는 엣지 케이스나 성능 최적화, 보안 등을 담당합니다.
검증: 구현된 코드가 Spec을 정확히 따르는지 검증합니다. SDD에서는 Spec을 기반으로 자동화된 테스트 코드를 생성하거나 Spec 자체를 테스트 도구로 활용하여 검증 과정을 효율화할 수 있습니다. 이는 문서와 코드의 일관성을 유지하는 데 핵심적인 역할을 합니다.

이 흐름은 AI에게 코드를 무작정 맡기는 것이 아니라 명확한 설계와 계획 아래 AI를 협업 도구로 활용하는 방식입니다. Spec이 개발의 “나침반” 역할을 해서 AI가 길을 잃지 않고 올바른 방향으로 나아가도록 돕습니다.

느낀점 / 정리

이번에 SDD를 깊이 살펴보면서 몇 가지를 새로 배웠습니다.

첫째, SDD는 문서화 자체가 목적이 아닙니다. 문서를 잘 만들기 위한 방법론이 아니라 AI와 협업하기 위한 컨텍스트 설계라는 점을 분명히 이해했습니다. 잘 정의된 Spec은 AI에게 명확히 지시하고 오해를 줄이며 일관된 결과물을 얻는 데 꼭 필요한 기반입니다.

둘째, “느리게 가는 것이 빠르게 가는 것”이라는 말을 다시 실감했습니다. 초기 Spec 작성에 시간과 노력이 들지만, 그만큼 이후 개발과 테스트, 유지보수 단계의 시행착오와 비용을 크게 줄여줍니다. 특히 AI가 개입할 때 잘못된 컨텍스트로 인한 반복 수정을 막아줍니다.

셋째, AI에게 코드 생성을 무작정 요청하기보다 명세 설계가 훨씬 중요하다는 점입니다. AI는 우리가 주는 컨텍스트의 품질에 비례해 결과물을 내놓습니다. 따라서 AI의 잠재력을 제대로 끌어내려면 개발자가 먼저 명확하고 실행 가능한 Spec을 설계하는 능력을 길러야 합니다.

마지막으로, 최근 AI 에이전트의 Runtime과 Orchestration 개념을 공부하면서 에이전트가 복잡한 작업을 수행하려면 안정적이고 예측 가능한 실행 환경(Harness)이 반드시 필요하다는 것을 배웠습니다. AI와 협업하는 소프트웨어 개발도 마찬가지여서, 명확한 Spec은 AI가 안정적이고 예측 가능하게 작동할 “실행 환경”을 제공한다는 점에서 두 개념이 자연스레 이어졌습니다. SDD는 AI 시대에 개발자가 AI를 단순한 도구가 아니라 진짜 협업 파트너로 만드는 중요한 전략이라고 생각합니다.

References

AI, Development Methodology, SDD

SDD SpecDrivenDevelopment LLM AI RAG Agile TDD BDD ContextWindow