스펙 주도 개발 (Spec Driven Development, SDD)

Context Engineering이 전부다

AI에게 코드를 작성하게 하려면, 결국 맥락(Context)이 전부다.
같은 AI 모델이라도 주어진 맥락의 품질에 따라 결과물이 천지차이다.

예를 들어, AI에게 "적 AI 만들어줘"라고만 하면 AI는 대충 Update()에서 Transform.LookAt()하고 MoveTowards()하는 코드를 뱉어낸다. 하지만 이런 맥락을 알려주면 어떨까?

우리 프로젝트는 NavMesh 기반 길찾기를 쓴다
적 상태 관리는 FSM으로 하고 있다
감지 범위는 Physics.OverlapSphere로 처리한다
공격 판정은 서버에서 한다

전혀 다른 수준의 코드가 나온다.
이게 바로 Context Engineering이다. AI에게 올바른 맥락을 설계하고 전달하는 것. 프롬프트 엔지니어링이 "어떻게 말하느냐"의 문제라면, 컨텍스트 엔지니어링은 "무엇을 알려주느냐"의 문제다.
그렇다면 기존의 개발 방식들은 이 맥락을 어떻게 다루고 있을까?

전통적 개발 — 사람 머릿속의 Context

전통적인 개발에서 맥락은 대부분 사람의 머릿속에 있다.
시니어 개발자가 아키텍처를 알고 있고, 기획자가 요구사항을 문서로 정리하고, 코드리뷰에서 "이건 이렇게 하는 게 우리 컨벤션이야"라고 말해준다. 즉 맥락이 사람 간 커뮤니케이션을 통해 전달된다.
이 방식의 문제는 명확하다:

문서는 금방 낡는다 (코드는 바뀌는데 문서는 안 바뀜)
맥락이 특정 사람에게 편중된다 (버스 팩터)
새로운 팀원이 올바른 맥락을 갖추기까지 시간이 오래 걸린다

그래도 이 방식이 수십 년간 작동한 이유는, 코드를 쓰는 주체가 사람이었기 때문이다. 사람은 암묵적 맥락을 어느 정도 추론할 수 있다. "아 여기는 이런 패턴으로 했구나" 정도는 코드만 봐도 감을 잡는다.

바이브코딩 — Context 없이 달리기

바이브코딩(Vibe Coding)은 정반대의 접근이다. 맥락을 최소화하고, 프롬프트 하나로 바로 코드를 생성한다.
"인벤토리 만들어줘", "이 버그 고쳐줘", "스킬 시스템 추가해줘" — 이런 식으로 AI에게 즉석에서 지시를 내린다. 맥락 설계? 그런 거 없다. 그냥 바로 코딩한다. 분위기(vibe)로 코딩하는 거다.
솔직히 바이브코딩은 작은 스코프에서는 매우 강력하다. 프로토타입을 빠르게 뽑거나, 독립적인 유틸리티 함수를 만들 때는 이만한 게 없다.
그러나 프로젝트 규모가 조금만 커지면 문제가 터진다:

AI가 기존 코드와 전혀 다른 패턴으로 코드를 생성한다
이전에 내린 결정과 모순되는 코드가 나온다
같은 수정을 몇 번이고 반복해서 요청하게 된다
결국 수동으로 맥락을 반복 입력하는 "컨텍스트 노동"이 생긴다

이걸 Context Rot(맥락 부식)이라고 부를 수 있다. AI는 개별 작업 하나하나는 꽤 잘 해낸다. "데미지 계산 함수 만들어줘"하면 그럴듯한 함수가 나온다. "피격 이펙트 재생하는 코드 짜줘"하면 그것도 잘 만든다. 문제는, 작업을 전환하는 순간 이전 맥락이 증발한다는 것이다.
예를 들어, AI에게 먼저 데미지 계산 시스템을 만들게 했다고 하자. 방어력 공식도 정하고, 크리티컬 배율도 잡았다. 잘 됐다. 그 다음에 "적 AI 만들어줘"라고 하면? AI는 방금 전 데미지 시스템의 존재를 모른다. 자기가 만든 방어력 공식과 맞지 않는 별도의 공격 로직을 만들어낸다. 그 다음 "UI에 데미지 표시해줘"라고 하면? 또 다른 데미지 계산 로직이 튀어나올 수 있다.
각 작업은 멀쩡한데, 전체를 합치면 엉망이 된다. 마치 서로 다른 사람이 소통 없이 각자 코드를 짠 것처럼. AI가 생성한 코드들이 하나의 일관된 프로젝트가 아니라, 독립적인 코드 조각들의 모음이 되어버린다.
바이브코딩의 근본 한계는 이 Context Rot — 작업이 바뀔 때마다 맥락이 부식되고, 일관성이 무너지는 현상 — 에 있다.

SDD — 스펙이 곧 Context다

SDD(Spec Driven Development)는 이 Context Rot를 정면으로 해결한다.
핵심 아이디어는 단순하다: 스펙(Specification)을 1차 산출물로 만들고, 코드는 그 스펙의 표현(expression)으로 취급한다.

Traditional	Code	→	Docs
TDD	Test	→	Code
SDD	Spec	→	Code

전통적 개발에서는 코드를 먼저 짜고, 문서는 나중에 (혹은 안) 쓴다. TDD는 테스트를 먼저 짜고, 그 테스트를 통과하는 코드를 만든다. SDD는 스펙을 먼저 짜고, 그 스펙을 만족하는 코드를 생성한다.
"무엇을 먼저 만드느냐"가 곧 개발 방법론의 정체성이다. SDD에서는 스펙이 왕이다. 코드는 스펙의 표현일 뿐이다.
이게 왜 Context Rot의 해결책이 되는지 보자. SDD에서 스펙은 단순한 기획 문서가 아니다. 스펙 자체가 AI에게 전달할 구조화된 맥락이다. 프로젝트의 원칙, 아키텍처 제약, 요구사항, 테스트 기준 — 이 모든 것이 스펙에 담긴다. AI가 어떤 작업을 하든, 항상 같은 스펙을 참조한다. 데미지 시스템을 만들 때도, 적 AI를 만들 때도, UI를 만들 때도 동일한 맥락 위에서 코드를 생성하는 거다. 작업이 바뀌어도 맥락이 부식되지 않는다.
즉, 스펙을 잘 쓰는 것 = Context Engineering을 잘 하는 것이고, 잘 쓰인 스펙은 Context Rot을 방지하는 방패가 된다.

"그거 CLAUDE.md랑 뭐가 다른데?"

여기서 이런 의문이 들 수 있다. 이미 CLAUDE.md, AGENTS.md, .cursorrules 같은 파일로 AI에게 프로젝트 맥락을 주고 있지 않은가? 맞다. 이것도 일종의 Context Engineering이다. 그리고 실제로 효과가 있다.

그런데 이런 파일들은 본질적으로 정적인 가이드라인이다. "우리 프로젝트는 이런 구조야", "코딩 컨벤션은 이래" 같은 배경 지식을 알려주는 것에 가깝다. 중요한 역할이지만, 한계가 명확하다:

기능 단위의 맥락이 없다. "인벤토리 시스템의 요구사항은 이거고, 제약은 이거다" 같은 내용은 CLAUDE.md에 안 들어간다.
단계가 없다. 명세 → 명확화 → 계획 → 구현의 흐름 없이, 그냥 한 번에 "알아서 해줘"다.
검증 장치가 없다. AI가 가이드라인을 잘 따랐는지 확인하는 게이트가 없다. 위반해도 그냥 넘어간다.

CLAUDE.md가 "우리 팀의 사내 위키"라면, SDD의 스펙은 "이번 기능의 설계 문서 + 체크리스트 + 테스트 기준"까지 포함한 것이다. 위키만 읽고 코드를 짜는 것과, 상세한 설계서를 보고 짜는 것은 결과물이 다를 수밖에 없다.

spec-kit으로 보는 SDD 워크플로우

GitHub에서 공개한 spec-kit은 SDD를 실제로 적용할 수 있는 도구다. 6단계의 워크플로우로 구성되어 있다.

1. Constitution (헌법)

프로젝트의 불변 원칙을 정의한다. 이건 개별 기능이 아니라 프로젝트 전체에 적용되는 규칙이다.
예를 들어:

"모든 기능은 독립적인 라이브러리로 먼저 만든다"
"구현 코드를 쓰기 전에 반드시 테스트를 먼저 작성한다"
"프로젝트 구조는 3개 이하로 유지한다"

이 원칙들은 이후 모든 단계에서 자동으로 참조된다. AI가 코드를 생성할 때 이 원칙을 위반하면 거부되는 식이다. 게임 개발로 치면, "우리는 ECS 패턴만 쓴다", "MonoBehaviour 금지" 같은 아키텍처 결정을 미리 박아두는 것과 비슷하다.

2. Specify (명세)

기능의 요구사항을 "무엇을", "왜"의 관점에서 작성한다. "어떻게"는 여기서 쓰지 않는다.
이게 중요하다. 구현 방법을 너무 일찍 결정하면, 기술 스택이 바뀌거나 더 나은 방법이 나왔을 때 스펙까지 다시 써야 한다. what과 why만 적어두면, how는 나중에 자유롭게 바꿀 수 있다.

3. Clarify (명확화)

스펙에서 애매한 부분을 명시적으로 표시한다.

AI가 흔히 저지르는 실수가 뭔지 아는가? 그럴듯한 추측을 사실인 것처럼 내뱉는 것이다. SDD에서는 불확실한 부분에 [NEEDS CLARIFICATION] 태그를 달도록 강제한다. AI가 "아 이건 아마 이렇겠지"하고 넘어가는 걸 방지하는 거다.

4. Plan (계획)

이제 비로소 "어떻게"를 다룬다.
스펙과 헌법을 기반으로 기술적인 구현 계획을 세운다. 데이터 모델, API 설계, 테스트 시나리오 등이 여기서 나온다.
중요한 건, 이 단계에 게이트(gate)가 존재한다는 것이다. 계획이 헌법의 원칙을 위반하거나, 불필요하게 복잡하거나, 테스트 없이 구현으로 넘어가려 하면 게이트에서 걸린다. AI가 "대충 넘어가는" 걸 구조적으로 막는 장치다.

5. Task (작업 분할)

계획을 실행 가능한 단위의 작업으로 쪼갠다.

각 작업에는 병렬 실행 가능 여부([P] 태그)까지 표시된다. AI 에이전트가 여러 작업을 동시에 처리할 수 있도록 하기 위함이다.

6. Implement (구현)

드디어 코드를 작성한다. 그런데 이 시점에서 AI는 이미 풍부한 맥락을 갖고 있다:

프로젝트 헌법 (불변 원칙)
기능 명세 (무엇을, 왜)
명확화된 제약 조건
기술 계획 (어떻게)
세분화된 작업 목록

바이브코딩처럼 "알아서 해줘"가 아니라, 충분한 맥락 위에서 코드를 생성하는 거다.

SDD가 아니라 Spec이 중요하다

솔직히, 1~2년 뒤에도 모두가 SDD를 하고 있을 거라고는 생각하지 않는다. AI 개발 방법론은 지금도 우후죽순 나오고 있고, SDD는 그중 하나일 뿐이다.
그런데 TDD를 생각해보자.
모든 팀이 TDD를 하는가? 아니다. 엄격한 TDD를 실천하는 팀은 사실 소수다. 그런데 테스트 자체를 안 짜는 팀이 있는가? 거의 없다. TDD라는 방법론은 선택이지만, 테스트라는 산출물은 이제 업계 표준이다.
SDD도 마찬가지일 거다. SDD라는 방법론 자체는 유행이 지날 수 있다. 더 좋은 워크플로우가 나올 수도 있고, AI가 발전하면서 단계가 줄어들 수도 있다. 하지만 Spec이라는 산출물은 살아남을 확률이 높다.
이유는 간단하다. 앞에서 계속 이야기했듯이 Spec은 곧 Context이기 때문이다. AI가 아무리 똑똑해져도, 맥락 없이 좋은 코드를 짤 수는 없다. 오히려 AI가 발전할수록 — 더 복잡한 시스템을 맡길수록 — 구조화된 맥락의 중요성은 커질 수밖에 없다.