Spec-Driven Development vs Vibe Coding: 직접 시도해 본 솔직한 첫 인상
Source: Dev.to
(번역할 텍스트가 제공되지 않았습니다. 번역이 필요한 본문을 알려주시면 한국어로 번역해 드리겠습니다.)
두 가지 떠오르는 접근법
| 접근법 | 설명 |
|---|---|
| 바이브 코딩 | AI에 직접 프롬프트를 주고 빠르게 반복합니다. |
| 스펙 기반 개발 | 코드를 작성하기 전에 구조화된 사양, 사용자 스토리, 작업을 생성하는 프레임워크를 사용합니다. |
내 의견: 실제 프로젝트에 적용해 본 결과, 현실은 더 복잡합니다. 아래는 OpenSpec을 프레임워크로 사용한 첫 인상입니다.
스펙 기반 개발이란?
“AI 에이전트에게 *‘이 기능을 만들라’*고 지시하는 대신, 애플리케이션을 설명하는 구조화된 문서 집합을 먼저 생성합니다.”
일반적인 산출물:
- 명세서
- 사용자 스토리
- 상세 작업
- 아키텍처 노트
- 기능 정의
AI 에이전트는 단일 프롬프트에 직접 응답하는 대신 이러한 작업을 하나씩 실행합니다. OpenSpec 및 GitHub SpecKit과 같은 프레임워크가 이 분해 과정을 자동화합니다. 이론적으로 이는 특히 대규모 프로젝트에서 더 신뢰할 수 있고 유지 보수가 쉬운 AI‑생성 코드를 만들어, 워크플로우가 전통적인 소프트웨어 엔지니어링 프로세스와 유사해집니다.
Vibe 코딩에 대한 일반적인 비판
- 프롬프트가 너무 모호함
- 컨텍스트가 빨리 사라짐
- AI가 일관성 없는 아키텍처를 생성할 수 있음
- 대규모 프로젝트가 혼란스러워짐
Spec‑Driven Development는 구조화된 요구사항과 제어된 실행을 도입함으로써 이러한 문제들을 해결하려고 시도합니다. 개념적으로는 매우 타당해 보이지만, 프레임워크를 사용하기 시작하면 상황이 달라집니다.
Spec‑Driven 프레임워크 사용 시 트레이드‑오프
1. 문서‑중심 프로세스
OpenSpec 같은 프레임워크는 다음과 같은 많은 마크다운 파일을 생성합니다:
- 사양
- 사용자 스토리
- 작업 목록
- 개발 노트
개발자 비용:
- 생성된 산출물을 검토한다.
- 내용이 타당한지 확인한다.
- 모든 마크다운 파일을 다시 AI에 입력한다.
이는 토큰 사용량, API 호출, 그리고 구독 크레딧을 코드가 실제로 작성되기 전에 소모하게 합니다. 경우에 따라 이 오버헤드가 이점을 능가하기도 합니다.
2. 실제 병목 현상: AI 모델
Spec 프레임워크는 프롬프트를 더 작은 단계로 나눌 뿐이며, 그 단계를 실행하는 모델이 최종 출력 품질을 결정합니다.
- 일부 모델은 느리며, 지속적인 승인 절차가 필요하고 작업 체인 처리에 어려움을 겪습니다.
- 다른 모델은 훨씬 빠르고 더 높은 능력을 보입니다.
문제가 발생했을 때 원인을 파악하기 어렵습니다:
- 프롬프트가 너무 큰가?
- 사양이 부실하게 생성되었는가?
- 모델 자체가 충분히 좋지 않은가?
Spec 프레임워크는 이를 해결해 주지 못합니다—단지 명령 전달 방식을 재구성할 뿐입니다.
인기 있는 Spec‑Driven 프레임워크
| 프레임워크 | 특성 |
|---|---|
| OpenSpec | 가벼우며, 프로세스 부담이 적고, 개인 개발자에게 더 쉽습니다. |
| GitHub SpecKit | 훨씬 더 구조화되어 있으며, 대규모 팀을 위해 설계된 느낌이고, 프로세스에 더 큰 강조를 둡니다. |
현재 SpecKit은 가장 완전한 구현처럼 보이지만, 생태계가 빠르게 변화하고 있습니다.
새로운 아이디어
다중 에이전트 오케스트레이션
- BMAD는 단일 사양에 대해 여러 AI 에이전트가 병렬로 작업하는 실험을 진행하고 있습니다.
- VS Code는 이미 여러 AI 에이전트를 동시에 실행할 수 있는 지원을 추가하고 있습니다.
- 이는 AI 기반 개발의 주요 부분이 될 수 있습니다.
Tessl – “사양이 곧 애플리케이션”
- 개발자는 사양을 편집하고, 그 사양으로부터 코드가 생성됩니다.
- 전체 애플리케이션을 이론적으로 사양만으로 재구성할 수 있습니다.
- 강력하지만, 대부분의 실제 팀에게는 아직 미래지향적입니다.
내가 선호하는 중간 지점: 구조화된 AI 코딩
순수한 바이브 코딩이 아니다. 완전한 사양‑주도 개발도 아니다.
내가 “구조화된 AI 코딩”이라고 부르는 워크플로우다.
핵심 아이디어
- 기능 요청을 폴더로 정리한다
- 마크다운으로 상세한 지시사항을 작성한다
- AI에게 명확한 컨텍스트를 제공한다
- AI가 코드를 작성하기 전에 계획을 생성하도록 한다
이것이 방지하는 것
- 생성된 사용자 스토리, 자동화된 작업 분해, 방대한 사양 트리와 같은 무거운 파이프라인.
실제 적용 방법
- 개발자는 각 기능에 대해 명확하고 구조화된 지시사항을 제공한다.
- 최신 AI 코딩 에이전트(예: Copilot, Claude Code)는 계획 모드를 지원하여, AI가 변경을 수행하기 전에 의도한 단계를 보여준다.
장점
- 더 빠른 반복
- 모델과의 보다 직접적인 커뮤니케이션
- 관료적 부담 감소
- AI에게 구체적인 계획을 제공함으로써 안전성 유지
TL;DR
- Vibe Coding = 빠르고 프롬프트‑기반, 프로토타입에 좋지만 혼란스러워질 수 있음.
- Spec‑Driven Development = 구조화되고 문서‑중심, 대규모 프로젝트에 유리하지만 오버헤드가 늘고 여전히 모델 품질에 의존.
- Structured AI Coding (내 하이브리드) = 가벼운 구조 + 계획 모드 = 빠르고 직접적이며 관료주의 감소.
시도해 보고 어느 균형이 팀에 가장 잘 맞는지 확인해 보세요!
사양 기반 개발: 균형 잡힌 시각
개념적으로, Spec‑Driven Development는 매우 강력한 아이디어입니다.
이는 Vibe Coding의 실제 한계를 해결합니다: 프로젝트가 커질수록 AI는 컨텍스트와 구조가 필요합니다.
하지만 현재 Spec‑Driven 워크플로우에 대한 과대광고는 종종 비용 대비 이점의 트레이드오프를 무시합니다. 이러한 프레임워크는 추가적인 계층을 도입합니다:
- 사양 파일
- 작업 분해 시스템
- 문서화 파이프라인
이 모든 것이 인간과 AI 모두가 처리해야 할 복잡성을 추가합니다. 전체 워크플로우를 거친 후에도 최종 결과물은 여전히 AI 모델의 능력에 제한될 수 있습니다.
따라서 Spec‑Driven Development가 확실히 흥미로운 방향이긴 하지만, AI 지원 개발의 모든 문제를 마법처럼 해결해 주지는 않습니다. 현재 가장 실용적인 접근법은 Vibe Coding과 완전한 Spec‑Driven Development 사이의 경량화된 구조화 워크플로우일 수 있습니다.
그 중간 지점은 아직 공식적으로 정의되지 않았습니다.
YouTube에서 재생목록 보기
Spec‑Driven Development – YouTube
Spec‑Driven Development는 AI 지원 소프트웨어 개발의 새로운 접근 방식으로, AI 에이전트가 구조화된 사양을 기반으로 코드를 생성합니다…