Vibe Coding과 Spec-Driven Development의 만남: 두 세계의 장점 결합하기

속도와 구조 사이에서 고민하지 마세요, 둘 다 가질 수 있습니다.

모든 개발자가 느끼는 갈등

최근 AI 어시스턴트(AI assistants)와 함께 코딩을 해왔다면, 아마 양극단의 경험을 모두 해보셨을 것입니다.

한쪽에는 **Vibe Coding (바이브 코딩)**이 있습니다. 채팅창을 열고 원하는 것을 평이한 영어로 설명한 뒤, 모델이 실행되도록 내버려 둡니다. 마치 마법처럼 느껴집니다. 빠르게 결과물을 내놓고, 몰입 상태(flow)를 유지하며, 도파민이 솟구치는 것을 느낍니다.

다른 한쪽에는 찝찝한 기분이 자리 잡고 있습니다. 코드베이스(codebase)가 표류하기 시작합니다. 어떤 컴포넌트가 하지 말아야 할 세 가지 일을 수행합니다. 분명히 내가 만들지 않았다고 맹세할 수 있는 버그가 나타납니다. AI에게 수정을 요청하면, 다른 무언가가 망가집니다. '바이브(vibes)'가 혼돈으로 변합니다.

이때 등장하는 것이 **Spec-Driven Development (SDD, 명세 기반 개발)**입니다. 코드 한 줄을 작성(또는 생성)하기 전에 명세(specification)를 작성한다는 개념입니다. 즉, 무엇을 만드는지, 왜 만드는지, 그리고 어떻게 동작해야 하는지를 정의하는 명확하고 구조화된 문서를 작성하는 것입니다. 새로운 개념은 아니지만, AI 코딩 시대에 다시 부활하고 있습니다.

좋은 소식은 무엇일까요? 둘 중 하나를 선택할 필요가 없다는 것입니다. 사실, 이 둘을 결합하는 것이 오늘날 소프트웨어를 구축하는 가장 생산적인 방법이라고 할 수 있습니다.

Vibe Coding이란 정확히 무엇인가?

이 용어는 2025년 초 Andrej Karpathy에 의해 대중화되었습니다: "내가 Vibe Coding이라고 부르는 새로운 종류의 코딩이 있습니다. 여기서는 완전히 바이브에 몸을 맡기고, 지수적 성장을 수용하며, 코드가 존재한다는 사실조차 잊어버립니다."

이 방식의 특징은 다음과 같습니다:

프롬프트 우선, 코드 후순위 사고 (Prompt-first, code-second thinking)
높은 반복 속도 (High iteration speed)
최소한의 사전 계획 (Minimal upfront planning)
빈칸을 채우는 모델에 대한 신뢰

Vibe coding은 유지보수성보다 속도가 더 중요한 프로토타이핑 (prototyping), 탐색 (exploration), 그리고 **개인 프로젝트 (solo projects)**에서 빛을 발합니다. 이는 정당하고 강력한 워크플로우(workflow)이지만, 한계가 존재합니다.

Spec-Driven Development란 무엇인가?

SDD는 구현이 시작되기 _전_에 기계가 읽을 수 있고(동시에 인간도 읽을 수 있는) 명세(specification)를 작성하는 관행입니다. 명세에는 일반적으로 다음 내용이 포함됩니다:

목표 (Goal): 우리가 해결하려는 문제는 무엇인가?
범위 (Scope): 무엇이 포함되고, 무엇이 명시적으로 제외되는가?
기능적 요구사항 (Functional requirements): 시스템이 무엇을 수행해야 하는가?
비기능적 요구사항 (Non-functional requirements): 성능, 보안, 확장성 제약 조건
데이터 모델 / API 계약 (Data models / API contracts): 데이터의 형태
수락 기준 (Acceptance criteria): 완료되었음을 어떻게 알 수 있는가?

AI 보조 워크플로우 (AI-assisted workflow)에서 명세는 모든 프롬프트 (prompt)에 입력하는 **단일 진실 공급원 (single source of truth)**이 됩니다. 매번 컨텍스트 (context)를 다시 설명하는 대신, 모델이 참조할 수 있는 문서에 고정(anchor)시키는 것입니다.

각 접근 방식이 단독으로 부족한 이유

명세 없는 Vibe Coding

사용자: "사용자 인증 시스템을 만들어줘"
AI: *300줄의 코드를 생성함*
사용자: "사실 역할 기반 액세스 제어 (RBAC)를 추가해줘"
...

명세가 없으면 AI는 당신의 실제 목표가 아니라 _당신의 마지막 메시지_에 최적화됩니다. 모든 새로운 프롬프트는 모델과의 새로운 협상이며, 컨텍스트 드리프트 (context drift)는 피할 수 없습니다.

Vibe 없는 Spec-Driven

과도한 명세 프로세스는 추진력을 죽일 수 있습니다. 아이디어가 작동할지조차 알기 전에 10페이지짜리 제품 요구 사항 문서 (PRD)를 작성하는 것은 함정입니다. 검증되지 않은 문제에 대해 요구사항을 과잉 설계 (over-engineer)하게 됩니다. 명세는 아무도 읽지 않는 관료적인 유물이 되어버립니다.

하이브리드 워크플로우: 명세 우선, Vibe는 빠르게

가장 이상적인 지점은 빠른 AI 보조 구현을 안내하는 가벼운 명세입니다. 실제 작동 방식은 다음과 같습니다:

1단계: 최소 기능 명세 (Minimal Viable Spec, MVS) 작성

어떤 AI 코딩 도구를 사용하기 전에, 15~30분 정도 짧은 명세를 작성하는 데 시간을 할애하세요. 격식을 갖출 필요는 없으며, 마크다운 (markdown) 파일이면 충분합니다.

# 기능: 사용자 인증

## 목표
...

그게 전부입니다. 몇 백 단어의 글이 몇 시간의 혼란을 방지해 줍니다.

2단계: 명세를 프롬프트의 기반으로 사용

이제 모든 AI 프롬프트는 명세의 컨텍스트로 시작합니다:

다음 명세를 바탕으로: [관련 섹션 붙여넣기]

POST /auth/register 엔드포인트를 구현하세요. bcrypt를 사용하여
...

모델은 더 이상 당신의 의도를 추측하는 것이 아니라, 계약 (contract)에 따라 실행합니다.

3단계: 명세(Spec)의 경계 안에서 Vibe를 발산하기

구조가 갖춰졌다면, 이제 Vibe를 흘려보내세요. 에러 핸들링 (Error handling)을 추가해야 하나요? 쿼리 (Query)를 최적화해야 하나요? 컴포넌트 (Component)의 스타일을 입혀야 하나요? 기반이 탄탄하기 때문에 빠르게 움직일 수 있습니다. 명세 (Spec)가 벽을 세운다면, Vibe 코딩 (Vibe coding)은 방을 꾸미는 것입니다.

4단계: 요구사항 변경 시 명세 업데이트하기

이것이 훌륭한 하이브리드 워크플로우 (Hybrid workflow)와 나쁜 워크플로우를 가르는 규율입니다. 범위 (Scope)가 변경될 때(반드시 변경될 것입니다), 먼저 명세를 업데이트한 다음, 코드를 다시 생성하거나 리팩터링 (Refactor)하세요. 명세가 오래된 문서가 되게 두지 마세요. 그것은 살아있는 계약 (Contract)입니다.

1단계: spec.md 편집 → OAuth 섹션 추가
2단계: 업데이트된 명세 섹션으로 AI에게 프롬프트 (Prompt) 전달
3단계: 구현하도록 맡기기

실전 예시: 작업 관리자 (Task Manager) 구축하기

간단한 작업 관리자를 만든다고 가정해 봅시다. 하이브리드 접근 방식이 어떻게 전개되는지 살펴보겠습니다.

순수 Vibe 접근 방식:

"React와 Node로 작업 관리자를 만들어줘"

무언가 만들어지긴 하겠지만, 어떤 데이터베이스 (Database)를 쓸까요? 인증 (Auth)은 어떻게 할까요? 데이터 모델 (Data model)은 무엇인가요? 당신은 다음 한 시간 동안 AI의 추측을 수정하는 데 시간을 허비하게 될 것입니다.

하이브리드 접근 방식:

10분 동안 명세를 작성합니다:

# Task Manager MVP

## 스택: React + Express + SQLite (단순함, Docker 불필요)
...

이제 당신의 AI 프롬프트는 레이저처럼 정밀하게 집중됩니다:

"이 명세를 사용하여 SQLite 기반의 Express API를 생성해줘. 작업(Task)의 CRUD에 필요한 엔드포인트 (Endpoint)만 구현해줘."

결과는 어떨까요? 당신이 실제로 원하는 것과 일치하는, 깔끔하고 예측 가능한 코드가 나옵니다.

이 워크플로우를 빛나게 하는 도구들

명세 작성 후 Vibe를 발산하는 방식은 긴 컨텍스트 (Long context)나 파일 기반 프롬프팅 (File-based prompting)을 지원하는 AI 도구들과 아름답게 조화를 이룹니다:

Claude: 긴 명세에 대한 추론 (Reasoning)과 일관성 유지에 탁월함
Cursor / Windsurf: 명세를 프로젝트 규칙 (Project rule)이나 컨텍스트 파일 (Context file)로 로드함
GitHub Copilot Workspace: 명세에서 코드로(Spec-to-code) 이어지는 과정이 말 그대로 핵심 기능임
Claude Code: CLI를 통해 명세를 입력하고 세션 전반에 걸쳐 컨텍스트를 유지하는 데 이상적임

핵심은 명세를 첫 번째 프롬프트에서뿐만 아니라, 항상 AI가 접근할 수 있도록 만드는 것입니다.

각 모드를 사용해야 하는 시점

상황	권장 모드
새로운 아이디어를 탐색할 때	순수 바이브 코딩 (Pure vibe), 빠르게 검증
...

사고방식의 전환 (The Mindset Shift)

가장 큰 변화는 기술적인 것이 아니라 철학적인 것입니다. 바이브 코딩 (Vibe coding)은 AI를 마치 신탁(Oracle)처럼 대하고 싶은 유혹을 줍니다. 그저 묻기만 하면 결과가 나오는 것처럼 말이죠. 하지만 명세 기반 개발 (Spec-driven development)은 **당신이 여전히 설계자 (Architect)**임을 상기시켜 줍니다. AI는 놀라운 실행자 (Executor)이지만, 방향성이 필요합니다.

두 가지를 결합하면 강력한 결과물을 얻을 수 있습니다. 혼란 없는 바이브 코딩의 속도와, 관료주의적 절차 없는 명세의 구조를 동시에 가질 수 있습니다.

이렇게 생각해보세요: 명세 (Specs)는 지도이고, 바이브 코딩 (Vibe coding)은 엔진입니다. 빠르게 달릴 수는 있지만, 여전히 어디로 가고 있는지는 알고 있어야 합니다.

오늘 바로 시작하기

다음에 새로운 기능을 시작할 때, 마크다운 (Markdown) 형식으로 15분 동안 명세를 작성하세요.
목표 (Goal), 범위 경계 (Scope boundaries), 데이터 모델 (Data model), 그리고 수락 기준 (Acceptance criteria)을 포함하세요.
관련 섹션을 모든 AI 프롬프트 (Prompt)에 붙여넣으세요.
상황이 변하면 코드를 수정하기 전에 명세를 먼저 업데이트하세요.
설정된 범위 내에서 빠르게 결과물을 출시(Ship)하세요.

AI의 환각 (Hallucinations)을 수정하는 데 쓰는 시간은 얼마나 줄어드는지, 그리고 실제로 작동하는 결과물을 출시하는 데 얼마나 더 많은 시간을 쓸 수 있는지 직접 경험하면 놀라게 될 것입니다.

바이브 코딩과 명세를 결합해 보셨나요? 여러분의 워크플로우 (Workflow)는 어떠한가요? 아래에 댓글을 남겨주세요. 다른 분들은 이 과정을 어떻게 헤쳐나가고 있는지 정말 궁금합니다.