명세 기반 개발(Spec-Driven Development) 완벽 정리—바이브 코딩과 무엇이 다른가

핵심 메시지

• 이제 개발에서 가장 어려운 부분은 코드 작성이 아니라, 만들고 싶은 것을 LLM에 효과적으로 전달하는 일이다.
• 바이브 코딩은 프롬프트로 구현을 바로 요청하고 결과를 주고받으며 고치는 방식이라 결과가 매번 달라지고 SDLC를 건너뛴다.
• 명세 기반 개발은 구현이 아니라 '시스템이 무엇을 해야 하는가'(동작·제약)를 프롬프트로 정의하는 데서 시작한다.
• 명세는 계약처럼 요구사항을 만들고, 승인하면 할 일이 담긴 설계 문서로, 다시 구현으로 이어진다.
• 명세가 모든 후속 작업(구현·테스트·문서화·검증)을 이끄는 핵심 산출물이 되어 코딩 에이전트의 모호성을 줄인다.

쉽게 이해하기

IBM 테크놀로지가 최근 AI 코딩에서 부상한 '명세 기반 개발(Spec-Driven Development, 스펙 코딩)'을 설명한다. 앱을 만드는 방식이 달라지면서, 예전에는 코드를 쓰고 검토하는 일이 가장 어려웠지만 이제는 만들고 싶은 것을 LLM에 효과적으로 전달하는 일이 핵심이 됐다는 진단에서 출발한다.

먼저 흔히 떠올리는 '바이브 코딩'을 짚는다. 개발자는 AI 코딩 에이전트에 초기 프롬프트를 던지고, 모델은 그 프롬프트로 짐작한 코드를 생성한다. 원하는 구현이 아니면 프롬프트를 고쳐 다시 시키기를 반복한다. 빠른 테스트에는 좋지만, 같은 요청을 백 번 시도하면 매번 다른 결과가 나올 수 있고, 전통적 소프트웨어 개발 수명주기(SDLC)를 건너뛴다는 한계가 있다.

SDLC는 요구사항(PRD)을 바탕으로 계획·설계하고, 필요한 기능을 구현하고, 테스트와 품질 보증을 거쳐, 개발→스테이징→프로덕션으로 배포한 뒤 유지보수하는 흐름이다. 명세 기반 개발은 바이브 코딩에 이 SDLC 요소들을 더한 접근이라고 영상은 설명한다.

스펙 코딩은 구현을 직접 지시하지 않는다. 시스템이 무엇을 해야 하는지, 즉 동작과 제약을 프롬프트로 정의한다. 이 명세는 '계약'처럼 쓰여 요구사항을 만들고, 요구사항이 프로젝트 전체의 중심 위계가 된다. 요구사항이 만족스러우면 승인해 설계 문서로 바꾸고, 설계 문서에는 구현별 할 일이 담긴다. 아직 아무것도 구현되지 않은 단계에서 방향을 충분히 잡을 수 있다는 점이 장점이다.

영상은 개발 방식의 변화도 비교한다. 전통적 개발은 코드를 먼저 쓰고 문서를 나중에 만들었고, 테스트 주도 개발(TDD)은 테스트를 먼저 정의한 뒤 코드를 썼다. 명세 기반 개발은 이를 뒤집어 명세→요구사항·설계 문서→구현→코드 순으로 진행하며, 발표자는 이를 'TDD와 행동 주도 개발(BDD)의 강화판'이라고 표현한다. 로그인 기능을 예로 들면, /login 엔드포인트와 user·pass 변수, 사용자명 누락 시 실패 코드, 올바른 자격 증명에 200 응답을 주는 테스트 케이스를 명세 단계에서 정의해 두어, 코딩 에이전트의 모호성을 줄이고 명세를 핵심 산출물로 삼는다.

주요 인사이트

• 바이브 코딩의 비결정성(같은 요청에도 결과가 달라짐)을 명세라는 '계약'으로 묶어 통제하려는 시도라는 점이 핵심이다.
• 명세 기반 개발은 AI 시대에도 SDLC의 계획·설계·테스트 단계를 되살려, 생성형 코드 개발에 공학적 규율을 더한다.
• 구현 전에 동작·제약·테스트 케이스를 먼저 합의하므로, 모델이 추측으로 결정하던 부분이 명시적 지시로 바뀐다.
• 명세가 구현·테스트·문서·검증을 이끄는 1차 산출물이 된다는 점에서, 프롬프트 한 줄보다 재현성과 협업에 유리하다.

자주 묻는 질문

관련 AI 소식