왜 Spec-Driven Development가 실패하고 있으며, Intent-Driven Software Development (IDSD)가

인공지능 보조 프로그래밍의 부상은 vibe coding (단순한 직관이나 비공식적인 프롬프트로 프로그래밍하는 것)의 실패에 대한 대응책으로 Spec-Driven Development (SDD)를 대중화했습니다. 하지만 기업 실무에서 방대한 사양(specification)을 처음부터 작성하는 것은 실행 불가능한 일입니다. **Intent-Driven Software Development (IDSD)**는 ICE (Intent, Context, Expectations) 프레임워크를 통해 사양을 세 가지 명확한 학문적 영역으로 나눔으로써 이 개념을 발전시키며, 개발자가 수락 기준(acceptance criteria)을 기계에 위임하는 대신 제어 루프(loop) 내에서 존재감을 유지하도록 강제합니다.

목차

• 완전한 사양이라는 환상과 SDD의 실패
• ICE 프레임워크: 분할 정복
• ICE 파일의 해부 (실전 예시)
• IDSD의 실행 루프
• "매우 빠른 속도로 옳게 틀리는" 것의 위험성
• 시도 중에 죽지 않기 위한 방법과 요청하지 않은 조언들
• 최종 성찰

인공지능을 활용한 소프트웨어 개발은 급격한 전환기를 거쳤습니다. 초기에는 vibe coding (Andrej Karpathy가 만든 용어)이 장면을 지배했습니다. 개발자들은 모호한 아이디어를 설명하고 작동하는 코드를 기대했습니다. 이 접근 방식이 실제 프로젝트에서 불안정한 코드와 환각(hallucinations)을 생성하는 것을 보고, 업계는 Spec-Driven Development (SDD)로 피신했습니다. 그러나 임의로 작성된 방대한 사양은 AI 에이전트가 추측할 수밖에 없는 논리적 공백을 만듭니다. IDSD는 인간이 무엇을 해야 하고 기계가 무엇을 실행해야 하는지를 정확하게 정의함으로써 이 프로세스를 전문화하는 방법론적 해답으로 등장했습니다.

완전한 명세의 환상과 SDD의 실패

코드를 작성하기 전에 명세(Specification)를 작성한다는 아이디어는 새로운 것이 아닙니다. 애자일 설계(Agile design) 방법론과 소프트웨어 계약(Software contracts)은 수십 년 동안 이를 시도해 왔습니다. 하지만 인공지능(AI) 시대에 Spec-Driven Development (SDD) 움직임은 방법론적 함정에 빠졌습니다. 바로 우리가 방대하고 초정밀한 명세를 사전에 작성할 수 있으며, 또한 그렇게 해야만 한다는 환상입니다.

오픈 소스 이니셔티브에서 볼 수 있는 광범위하고 복잡한 통합 프로토콜(예: Anthropic의 Model Context Protocol)이나 1,500행 이상의 내부 명세와 같이 거대한 명세를 수동으로 정의하려는 시도는 세 가지 근본적인 이유로 인해 프로덕션 환경에서 실행 불가능합니다:

1. 초기 인지 비용 (Cognitive cost): 코드를 생성하기 전에 Markdown 형식으로 거대한 명세를 작성하고 구조화하는 것은 엄청난 정신적 설계 노력을 요구합니다. 개발자가 함수의 시그니처(Signature), 타입(Type), 흐름(Flow)을 상세히 기술하는 데 수 시간을 보낸다면, AI의 가장 큰 장점인 개발 속도를 잃게 됩니다.
2. LLM의 통계적 특성: 언어 모델은 명세를 컴파일하는 것이 아니라 확률적으로 해석합니다. 온도(Temperature)가 0.0일지라도, 매우 길거나 복잡하게 포맷팅된 텍스트는 모델 간(예: Claude 3.5 Sonnet에서 GPT-4o 또는 Gemini로 전환 시) 해석의 불일치가 발생하며, 이로 인해 개발자는 AI가 동일하게 "이해"할 수 있도록 명세의 문구를 끊임없이 조정해야 합니다.
3. 유지보수 및 명세 드리프트 (Specification Drift): 매일 변경되는 실제 코드베이스와 수천 줄의 명세를 동기화된 상태로 유지하는 것은 패배가 예정된 싸움입니다. 명세에 문서화되지 않은 프로덕션에서의 첫 번째 빠른 변경이 발생하는 순간, 명세 기반의 코드 생성 시스템 전체가 무너집니다.

업계에서는 대규모 프로젝트의 완벽한 명세서(specifications)를 마치 개발 시작 단계에서 작성된 것처럼 보여주곤 하지만, 실제로는 소프트웨어가 이미 작동한 _이후_에 생성된 사후 문서(retrospective documentation)인 경우가 많습니다. 이 정도 수준의 세부 사항을 사전에 작성하는 것은 현대적인 기업용 개발(enterprise development) 방식과는 근본적으로 호환되지 않습니다.

ICE 프레임워크: 분할 정복 (Divide and Conquer)

엔지니어가 AI 에이전트가 해독해야 하는 빈틈투성이의 혼란스러운 명세서를 작성하는 것을 방지하기 위해, IDSD는 문제를 ICE라는 약어로 불리는 세 가지 독립적인 영역으로 세분화할 것을 제안합니다.

1. Intent (의도) - "무엇(What)"

이는 출발점이며, 특정 기술 스택(technology stack)이나 서비스에 결합되지 않은 채 인간이 얻고자 하는 비즈니스 결과물을 나타냅니다. 잘 구조화된 의도는 다섯 가지 필수 요소로 구성됩니다:

• 설명 (Description): 무엇을 원하는가 (예: "사용자가 90달러 미만의 빨간 신발을 구매하고 싶어 함").
• 제약 조건 (Constraints): 비즈니스 제한 사항 (예: 해당 품목은 재고가 있어야 하며 배송이 가능해야 함).
• 실패 시나리오 (Failure scenarios): 의도가 충족되지 않는 경우 (예: 140달러짜리 신발이나 파란색 신발을 반환하는 경우).
• 성공 시나리오 (Success scenarios): 해피 패스 (Happy path) (예: 저렴한 신발을 장바구니에 담고 구매를 완료함).
• 연결 (Connections): 이 변경으로 인해 영향을 받는 다른 의도들과의 연결 (재고, 결제 게이트웨이 등).

2. Expectations (기대치) - 수락 기준 (Acceptance Boundary)

최종 결과물이 완료(done)된 것으로 간주되는 조건들의 집합입니다. 이는 기술적인 언어 대신 사용자 또는 비즈니스 동작 관점에서 작성되어야 합니다. 이 규율을 분리하여 유지함으로써, AI가 작업이 언제 완료되었는지 자율적으로 결정하여 자신의 코드를 스스로 정당화하는 것을 방지할 수 있습니다.

3. Context (컨텍스트) - "어떻게(How)"

현재 시스템의 아키텍처 (Architecture), 코드베이스 (Codebase)의 상태, 그리고 기술적 제약 사항을 나타냅니다. 프롬프트 (Prompt) 시작 시 이 모든 것을 하나의 거대한 문서에 포함하는 대신, 컨텍스트 (Context)는 에이전트 (Agent)가 필요로 할 때마다 실행 하네스 (Execution Harness)에 의해 점진적으로 제공되고 주입되어야 합니다.

Vibe Coding vs. SDD vs. IDSD

특성	Vibe Coding	Spec-Driven Development (SDD)	Intent-Driven Software Development (IDSD)
개발자의 역할	탐색적 프로그래밍 및 비정형 프롬프트 사용.	상세한 설계도 또는 명세서 (Specification) 설계자.	비즈니스 아키텍트 (의도/Intent) 및 품질 검사관 (기대치/Expectations).
...

ICE 파일의 구조 (실제 예시)

실무에서 개발자는 가벼운 구조화된 파일에 **의도 (Intent)**와 **기대치 (Expectations)**를 문서화하고, 하네스 (Harness)가 **컨텍스트 (Context)**를 동적으로 주입하도록 합니다. 다음은 동일한 Rate Limiter 기능에 대한 Markdown 형식의 실제 예시입니다:

# 의도 (Intent): API 엔드포인트 보호

## 1. 설명
...

이 형식을 통해 개발자는 AI가 해결해야 할 정확한 기술적 구현 (Implementation)을 상세히 기술할 필요 없이, 몇 분 만에 비즈니스 로직과 검증 기대치를 정의할 수 있습니다.

IDSD의 실행 루프 (Execution Loop)

IDSD에서 프로그래머는 제어 루프 (Control Loop)를 결코 떠나지 않으며, 개념적 설계 (Conceptual Design)에 대한 소유권을 유지합니다.

그림 1: 책임 분할을 포함한 Intent-Driven Software Development의 흐름.

• 인간: 기능과 관련된 의도(intention)와 기대치만을 정의합니다.
• 아머니 (Harness): 코드베이스에서 적절한 컨텍스트를 추출하고, 코드 에이전트에게 공급하며, 결과가 기대치를 충족하는지 검증합니다. 아머니(spec-kit, BMAD 또는 기타)는 단지 기계적인 도구일 뿐이며, IDSD가 전략적인 방법론입니다.

'빠르게 잘못된 것에 성공하는' 위험성

에이전트들이 명확한 의도와 지속적인 감독 없이 작동할 때, 설계 이탈(deviation from design)이라고 알려진 현상이 발생합니다. 종종 개발자는 에이전트가 명세의 공백을 해결해 줄 것이라고 믿으며 루프에서 벗어납니다.

2025년, METR가 수행한 통제된 연구에 따르면, AI를 사용하여 코딩하는 숙련된 개발자들은 올바른 소프트웨어를 전달하는 속도가 측정 가능하게 느렸지만, 그 활동을 마치 훨씬 더 빨랐다고 확신하며 끝냈습니다. 이는 AI가

에이전트가 잘못 생성한 코드를 수정하는 것은 매우 비용이 많이 들 수 있습니다. 인간이 루프(Human in the loop)에 참여하지 않아 발생하는 3일간의 이탈은 수백 달러의 토큰 비용과 잘못된 작업을 되돌리기 위한 며칠간의 수동 리팩터링 (Refactoring) 비용을 초래할 수 있습니다.

실패하지 않기 위한 방법과 요청하지 않은 조언들

의도 기반 개발 (Intent-Driven Software Development, IDSD)로 전환하려면 기존의 AI 보조 전통 프로그래밍에서 흔히 발생하는 악습을 피해야 합니다.

1. AI가 기대치 (Expectations)를 작성하게 두지 마세요

가장 흔한 실수 중 하나는 AI에게 _"내 의도를 읽고 수락 기준 (Acceptance Criteria)을 대신 작성해줘"_라고 요청하는 것입니다. 이는 책임의 분리를 파괴합니다. 만약 AI가 자신이 평가받을 규칙을 직접 정의하게 되면, AI는 스스로 생성한 코드의 한계에 맞춰 기대치를 조정하게 되며, 이는 운영 환경(Production)에서 심각한 논리적 오류를 허용하는 결과를 낳습니다.

2. 컨텍스트 과부하 (Context Overload)를 피하세요

처음부터 AI 에이전트에게 전체 리포지토리 (Repository)를 모두 제공하지 마세요. 과도한 정보는 컨텍스트 노이즈를 증가시키고, 언어 모델 (Language Model)의 정확도를 저하시키며, 토큰 비용을 급격히 높입니다. 개발 프레임워크 (Harness)가 현재 작업 중인 모듈과 관련된 파일만을 주입하도록 하세요.

3. 제어 루프 내에 머무르세요 (Human in the Loop)

IDSD에서 여러분의 역할은 코드를 작성하는 것이 아니라, 생성된 코드가 여러분의 기대치를 엄격하게 충족하는지 평가하는 것입니다. 단순히 개발 프레임워크의 테스트를 통과했다는 이유만으로 풀 리퀘스트 (Pull Request)를 승인하거나 브랜치 (Branch)를 자동으로 머지 (Merge)하지 마세요. 의미론적 검증 (Semantic Validation)과 통합 검증 (Integrative Validation)에는 여전히 여러분의 기술적 판단이 필요합니다.

마치며

AI와 함께 프로그래밍할 때 성공과 실패를 가르는 차이는 언어 모델 (LLM)의 성능이나 당신이 다운로드한 자동화 도구에 있지 않습니다. 그것은 바로 규율 (Discipline)에 달려 있습니다. 도전 과제는 당신의 에이전트가 코드를 생성할 수 있는지 여부가 아니라 (현재의 에이전트들은 그것을 할 수 있습니다), 당신이 스스로 의도 (Intent)와 기대치 (Expectations)를 명시하는 규율을 갖추었는지, 그리고 하루의 끝에 변경 사항을 맹목적으로 승인하는 데 그치지 않고 실행 과정을 관찰하며 루프 안에 머무르는 (Human-in-the-loop) 인내심을 가지고 있는지입니다.

기억해야 할 핵심 사항:

• ICE는 책임을 분리합니다: 인간은 의도 (Intent)와 목표 (Expectations)를 정의하고, 소프트웨어는 코드베이스의 현실 (Context)을 주입합니다.
• 기계의 자기 평가를 피하십시오: AI는 자신의 작업이 평가될 기준인 기대치 (Expectations)를 결코 스스로 작성하거나 재정의해서는 안 됩니다.
• 방향 없는 속도는 비용이 많이 듭니다: 잘못된 코드를 빠른 속도로 생성하는 것은 결국 수동으로 수정하는 데 수 시간이 걸리는 기술 부채 (Technical Debt)를 생성할 뿐입니다.