#Spec #Driven #Development 란? ( #명세기반개발 )

I. 들어가며: '바이브 코딩'의 시대와 그 한계

 

1. AI 코딩 시대의 도래

AI 코딩 도구의 등장으로 소프트웨어 개발의 문턱이 극적으로 낮아졌습니다. 이제 누구나 간단한 아이디어만으로도 빠르게 애플리케이션을 만들 수 있는 시대가 열렸습니다. 이러한 현상 속에서 '바이브 코딩(vibe-coding)'이라는 새로운 용어가 등장했습니다. 이는 단순한 아이디어 에 의존해 코드를 짜는 것처럼, 명확한 계획 없이 즉흥적으로 AI와 상호작용하며 개발하는 방식을 의미합니다.

 

https://youtu.be/Ilyc4Ss0tsc

 

 

2. '바이브 코딩'의 정의 및 문제점 분석

바이브 코딩이란 "트윗 길이의 짧은 문장으로 아이디어를 설명하고, AI가 코드를 작성하게 한 뒤, 문제가 생기면 또 다른 지시를 내려 고치는 방식"으로 정의할 수 있습니다. 실무에서 우리 모두는, 저를 포함해서, 명확한 계획 없이 일단 시작하고 보자는 유혹에 빠지곤 합니다. 바로 이 지점에서 프로젝트가 길을 잃기 시작합니다. 이 방식은 초기 프로토타입을 빠르게 만드는 데에는 효과적이지만, 두 가지 핵심적인 문제점을 안고 있습니다.

• 방향성 상실: 긴 슬랙(Slack) 스레드에서 대화가 길어질수록 원래 논점에서 벗어나는 경험을 해본 적이 있을 겁니다. 바이브 코딩도 이와 비슷합니다. 명확한 목표 없이 계속해서 AI에게 프롬프트를 수정하며 지시하다 보면, 처음 의도했던 것과 전혀 다른 결과물이 만들어지기 쉽습니다. 개발 과정이 중심을 잃고 표류하게 되는 것입니다.

• 품질 저하: 바이브 코딩은 코드 품질, 아키텍처, API 패턴, 보안 표준, 장기적인 유지보수성 등 프로덕션급 소프트웨어의 핵심 요소들을 간과하기 쉽습니다. AI는 주어진 프롬프트에만 의존하기 때문에, 전체적인 구조나 장기적인 유지보수를 고려한 코드를 생성하기 어렵습니다. 결국 초기에는 빠르게 결과물을 얻는 것처럼 보이지만, 숨겨진 버그와 기술 부채가 쌓여 나중에 더 많은 수정 작업을 초래하게 됩니다.

 

3. 스펙 주도 개발(SDD) 소개

이러한 문제들에 대한 해결책으로 **스펙 주도 개발(Spec-Driven Development, SDD)**이 주목받고 있습니다. SDD는 "나중에 시간을 절약해주는 잠시 멈춤"이라는 개념으로 설명할 수 있습니다. 무작정 코딩을 시작하는 대신, 먼저 만들고자 하는 소프트웨어의 기능, 요구사항, 제약 조건 등을 명확하게 정의한 '명세서(specification)' 즉, 설계도를 만드는 체계적인 접근법입니다.

이 설계도는 개발 과정에서 인간과 AI 모두가 따라야 할 명확한 '북극성'이 되어, 방향을 잃지 않고 품질 높은 소프트웨어를 만들 수 있도록 돕습니다.

그렇다면 바이브 코딩과 스펙 주도 개발은 구체적으로 어떤 차이가 있을까요? 다음 섹션에서 두 가지 접근법을 한눈에 비교해 보겠습니다.

 

 

II. 한눈에 비교하기: 스펙 주도 개발(SDD) vs. 바이브 코딩

 

스펙 주도 개발(SDD)과 바이브 코딩의 핵심적인 차이점을 아래 표를 통해 명확히 비교할 수 있습니다.

기준	바이브 코딩	스펙 주도 개발(SDD)
시작점	모호한 프롬프트	명확하고 구조화된 명세서
프로세스	반복적인 프롬프트 수정과 코드 생성의 순환	명세 → 계획 → 작업 → 구현의 체계적 단계
개발자의 역할	AI에게 지시하는 프롬프트 엔지니어	AI와 협력하는 시스템 설계자 및 검토자
결과물	빠른 프로토타입, 숨겨진 버그와 기술 부채 발생 가능성	신뢰성 높은 고품질 코드, 유지보수의 용이성
핵심 비유	끝없는 슬랙 스레드	모두가 공유하는 청사진(Source of Truth)

이처럼 명확한 차이를 보이는 스펙 주도 개발이 왜 더 신뢰할 수 있는 접근 방식인지, 그 구체적인 장점들을 자세히 살펴보겠습니다.

 

 

III. 왜 스펙 주도 개발(SDD)을 사용해야 할까?

소프트웨어 개발을 처음 배우는 학생의 입장에서 스펙 주도 개발(SDD)은 복잡한 프로젝트를 성공적으로 이끌어갈 수 있는 강력한 무기가 됩니다. SDD가 제공하는 핵심 이점은 다음과 같습니다.

1. 명확한 목표 설정 이는 앞서 언급한 '방향성 상실' 문제를 정면으로 해결합니다. 잘 정의된 명세서는 끝없는 슬랙 스레드처럼 표류하는 대신, 프로젝트의 모든 참여자가 따라야 할 명확한 등대가 되어줍니다. 이를 통해 "우리가 무엇을 만들고 있었지?"라는 개발 과정의 혼란을 방지하고, 프로젝트에 참여하는 인간과 AI 모두가 처음부터 끝까지 같은 목표를 향해 나아가게 합니다.

 

2. 품질 높은 결과물 이는 AI가 추측에 의존해 코드를 생성하며 발생하는 '품질 저하' 문제를 근본적으로 해결합니다. 명확한 명세서가 있으면 AI는 주어진 설계도에 따라 코드를 생성하기 때문에 버그가 적고, 구조적으로 더 안정적이며 일관성 있는 코드를 만들 수 있습니다. 이는 단순히 '작동하는' 코드를 넘어, 장기적으로 유지보수하기 좋은 '잘 만들어진' 코드를 얻게 됨을 의미합니다.

 

3. 진정한 AI 협업 파트너 이는 개발자의 역할을 단순한 '프롬프트 엔지니어'에서 벗어나게 합니다. SDD를 통해 AI는 단순히 명령을 수행하는 코드 생성 도구를 넘어, 개발자의 의도를 깊이 이해하고 협력하는 진정한 '파트너'가 될 수 있습니다. 명세서는 개발자의 생각을 AI에게 전달하는 가장 정확한 언어이며, 이 명확한 소통을 바탕으로 AI는 잠재력을 최대한 발휘하여 개발자를 도울 수 있습니다.

이러한 개념적 장점들이 실제 개발 과정에서는 어떻게 구체화되는지, 구인구직 앱 개발 예시를 통해 알아보겠습니다.

 

 

IV. 실전 예제: 구인구직 앱 개발로 배우는 SDD 4단계

예제 소개

여기서는 간단한 '구인구직 앱(job seekers app)' 개발 사례를 통해 SDD의 4단계 프로세스를 살펴보겠습니다. 이 앱은 사용자가 면접 질문에 음성으로 답변하면, 이를 녹음하고 분석하여 구직자에게 피드백을 제공하는 인터뷰 준비용 애플리케이션입니다. 개발자의 재치있는 '엘리베이터 피치'에 따르면, 이 앱은 구직자들이 실제 면접처럼 질문에 답하고, 그 결과를 분석하여 정량화된 점수와 피드백을 제공함으로써 면접 기술을 향상시키는 것을 목표로 합니다.

 

SDD 4단계 설명

1단계: 명세(Specification) - '무엇을' 만들지 정의하기

첫 단계로, 우리는 앱의 Figma 디자인을 AI에게 전달했습니다. AI는 즉시 로그인, 프로필 관리를 포함한 방대한 요구사항 목록을 생성해냈죠. 하지만 숙련된 개발자로서 우리는 MVP(최소 기능 제품)에 이 모든 것이 필요하지 않다는 것을 압니다. 그래서 우리는 직접 개입하여 핵심 기능인 '인터뷰 연습'에만 집중하도록 불필요한 기능들을 덜어내는 '범위 조율' 역할을 수행했습니다. 이것이 바로 인간 개발자의 전략적 판단이 빛을 발하는 순간입니다. 이 단계는 기술적 구현이 아닌, 앱의 기능과 목표, 즉 '무엇(WHAT)' 을 정의하는 데 집중합니다.

 

2단계: 계획(Plan) - '어떻게' 만들지 설계하기

명세서가 확정되자, 우리는 AI에게 '어떻게(HOW)' 이 기능을 구현할지에 대한 기술 설계 문서를 요청했습니다. AI는 전체적인 아키텍처와 StartScreen, QuestionScreen 같은 필요한 화면 컴포넌트 목록을 제안했습니다. 하지만 여기서도 인간의 통찰력이 필요했습니다. AI가 만든 초기 설계에는 '사용자 음성을 텍스트로 변환하는 기능'이나 '분석을 위해 Claude AI SDK를 사용'하는 것과 같은 핵심 기술 계획이 빠져 있었습니다. 우리는 이 구체적인 기술 계획을 직접 추가하여 설계를 보완하고 완성했습니다.

 

3단계: 작업(Task) - 실행 계획을 잘게 쪼개기

잘 만들어진 기술 설계도를 바탕으로, AI는 코딩에 필요한 모든 단계를 체크리스트 형태의 '작업 목록'으로 만들었습니다. 하지만 AI가 제안한 작업 순서는 최적이 아니었습니다. 그래서 우리는 사용자가 즉시 눈으로 확인할 수 있는 UI 관련 작업을 초기 단계에 배치하도록 순서를 전략적으로 재조정했습니다. 이 작은 변화를 통해 우리는 더 빠르게 테스트 가능한 MVP를 만들어 피드백을 받을 수 있게 되었고, 프로젝트의 방향성을 조기에 검증할 수 있었습니다.

 

4단계: 구현(Implementation) - AI가 실제로 코드를 작성하기

마지막으로, 우리는 AI에게 잘 정리된 작업 목록에 따라 코드를 작성하도록 지시했습니다. AI가 파일 생성, 라이브러리 설치, 코드 작성을 자동으로 수행하는 동안, 우리는 감독관의 역할을 수행했습니다. 단순히 지켜보는 것을 넘어, 각 단계의 결과물이 우리가 처음 정의했던 명세서와 계획에 정확히 부합하는지 전체 과정을 감독하고 검토하며 최종 결과물의 품질을 보장했습니다.

이처럼 SDD는 아이디어를 체계적인 단계를 거쳐 신뢰할 수 있는 소프트웨어로 만드는 전 과정을 안내합니다. 그렇다면 이러한 변화가 개발자에게는 궁극적으로 어떤 의미를 가질까요?

 

 

V. 결론: AI 시대의 개발자, 코더에서 설계자로

SDD의 핵심 가치 요약

SDD는 단순히 코딩 전에 문서를 하나 더 작성하는 관료적인 절차가 아닙니다. 수많은 프로젝트를 거치며 깨달은 것은, 이것이 AI라는 강력한 도구를 길들이고 그 잠재력을 극대화하기 위한 필수적인 **'생각의 틀(framework)'**이라는 사실입니다. 모호한 지시 대신 명확한 설계도를 제공함으로써, 우리는 AI의 예측 불가능성을 통제하고 그 잠재력을 극대화할 수 있습니다.

 

개발자의 역할 변화 강조

'바이브 코딩'의 즉각적인 속도가 매력적인 유혹일지라도, 견고하고 신뢰성 높은 소프트웨어로 가는 길은 결국 설계자의 규율과 명확한 청사진으로 포장됩니다. SDD가 보편화되면서 개발자의 역할은 근본적으로 변화하고 있습니다. 더 이상 키보드 앞에서 한 줄 한 줄 코드를 입력하는 '코더(Coder)'에 머무르지 않습니다.

 

이제 개발자는 시스템 전체의 청사진을 그리는 '설계자(Architect)', AI의 작업을 지휘하는 '지휘자(Orchestrator)', 명확한 의도를 정의하는 '명세서 저자(Spec Author)', 그리고 AI의 결과물을 검증하는 **'최종 수문장(Guardian)'**으로 진화하고 있습니다. AI 시대의 개발자는 코드를 '만드는' 사람에서, 훌륭한 코드가 '만들어지도록' 설계하고 이끄는 사람으로 거듭나게 될 것입니다.