오늘은 아래와 같은 내용을 여러분과 나누려고 합니다:

오늘 글의 핵심 내용을 작성하는데 AWS의 VP이자 Agentic AI 담당 Distinguished Engineer인 Marc Brooker의 도움을 받았습니다. 감사드립니다.

AI 기술이 ‘소프트웨어 개발’ 영역에 본격적으로 활용되기 시작하면서, 한 가지 중요한 질문을 피하기 어려워졌죠 - 이게 정말 안전한 걸까? 하는 질문이 바로 그겁니다.

‘바이브 코딩’가 프로그래밍의 세계에 편의성과 속도, 그리고 재미를 가져다 줬다는 것은 뭐 너무나 분명합니다. 개발의 문턱을 엄청나게 낮춘 것도 사실이구요. 그런데 동시에, 품질이 별로 좋지 않고 구조도 없는 코드—흔히 서구권에서는 ‘AI 코딩 슬롭(AI coding slop)’이라 불리는—도 엄청나게 쏟아졌죠.

그렇다고 바이브 코딩을 완전히 포기하는 건 너무 성급한, 그리고 현명하지 못한 선택일 겁니다. 그렇다면, ‘바이브 코딩’을 좀 더 안전하게, 그리고 효과적으로 할 수 있는 방법은 없을까요? AI가 만들어낸 코드가, 프롬프트마냥 흔들리지 않을 진실의 원천(Source of Truth; 기준)을 어떻게 찾을 수 있을까요?

바로 여기에서, 스펙 기반 개발(Spec-Driven Development, SDD)이 등장합니다.

SSD의 아이디어는 간단합니다. 유저 스토리, 요구사항, 시스템 동작 방식, 제약 조건, 인수 기준, 기능—이 모든 것을 명세서(Specification)라는 한 곳에 담고, 코딩 프로세스를 거기서부터 시작하는 것이죠. 명세서는 명확한 목표가 설정된 규칙의 토대가 됩니다. 코딩 에이전트가 프롬프트의 바다에서 길을 잃지 않도록 하는 지도 역할을 한다고나 할까요?

그럼, 오늘은 SDD가 왜 바이브 코딩 대비 좀 더 신뢰할 수 있는 대안인지 알아보고, 지금 당장 쓸 수 있는 몇 가지 주요 SDD 도구들을 살펴보겠습니다.

오늘 다룰 내용은 다음과 같습니다:

지난 수십 년간, 프로그래밍이라는 작업은 컴퓨터에게 어떻게 할지를 일일이 하나하나 알려주는 일이었습니다. C나 포트란 같은 초기 언어들은 특히 완전히 절차적이었구요. 반복문, 메모리, 제어 흐름—모든 단계를 개발자가 직접 손으로 써야 했습니다.

그러다 1970년대에 SQL이 완전히 다른 아이디어를 들고 나타났습니다. 절차를 묘사하는 대신 원하는 결과를 묘사하는 것이었거든요.

인덱스를 어떻게 쓸지, 조인을 어떻게 처리할지 등을 직접 지정할 필요가 없었습니다. 데이터베이스가 알아서 실행 방법을 찾아냈으니까요. 어떤 면에서 보면, SQL이야말로 ‘스펙 기반 프로그래밍의 첫 번째 주류 사례’라고 해도 될지 모르겠네요. 원하는 것의 명세를 제공하면, 시스템이 실행을 담당하는 것 그 자체였으니까요.

2000년대에 업계는 이 아이디어를 한 단계 더 밀어붙이려고 했고, 그게 바로 모델 주도 개발(MDD, Model-Driven Development)이었습니다. 엔지니어들이 UML 다이어그램이나 도메인 모델 같은 형식 모델로 시스템을 설계하면, 도구가 코드를 자동으로 만들어내는 방식이었죠 - 아 정말 기억이 새록새록 떠오르네요.

모델이 핵심 산출물의 자리를 차지하고, 코드는 그 부산물에 불과한 세상—이론상 완벽했습니다. 하지만 현실에서 이 MDD를 위한 도구들은 너무 경직되어 있었고, 개발자들은 이 도구들이 만들어낸 코드와 씨름하는 데 더 많은 시간을 쏟았던 게 현실이었습니다.

또 다른 갈래로는 행동 주도 개발(BDD)이 있었습니다. 비즈니스 관점에서 사용자의 행동에 집중하고 시스템이 제대로 된, 올바른 일을 하고 있는지 확인하는 방식인데요.

그리고 지금 이 시대, 생성형 AI가 새로운 코딩의 시대를 열었습니다. 코딩 어시스턴트와 자율 에이전트 덕분에 예전에 프로그래머들이 꿈만 꾸던 일들이 현실이 됐죠. 자연어를 그대로 작동하는 코드로 변환하고, 대규모의 코드베이스를 수정하고, 테스트 스크립트를 손쉽게 생성하고, 시스템을 리팩터링하는 것들 모두가 AI의 일이 되었습니다.

바이브 코딩은 AI 코딩 어시스턴트 활용의 정점이죠. 프롬프트를 하나씩 보내면서 진행하는 방식이 주된 형태고, 구체적인 흐름은 이렇습니다: 개발자가 프롬프트 작성 → AI가 코드 생성 → 개발자가 더 많은 프롬프트로 수정하고 버그를 잡음 → 반복. 놀라우리만큼 잘 작동하고, 코딩 과정을 단순하게 만들어 줘서, 훨씬 더 많은 사람들이 개발에 접근할 수 있게 해줬습니다.

그런데 동시에, 바이브 코딩은 굉장히 취약하기도 합니다:

왜 그럴까요? 바로, 바이브 코딩에는 구조가 없기 때문입니다. 규칙과 제약의 토대, 검증 시스템, '제대로 하는 것'이 무엇인지 정의하고 반복해 가는 그 과정 중에 에이전트가 길을 잃지 않도록 잡아주는 나침반 같은 것이 없습니다.

그리고, 스펙 기반 개발이 바로 이 문제를 해결하려는 시도이구요.

스펙 기반 개발은, ‘AI가 지원해주는 소프트웨어 개발’의 흐름에 형식적 구조, 확장성, 그리고 검증 가능한 정확성을 다시 도입하려는 시도라고 설명할 수 있겠습니다. MDD와 BDD, 그리고 바이브 코딩의 중간 어딘가에 놓으면 될 것 같아요.

SDD에서는, 규칙과 제약이 훨씬 명시적입니다. 그리고 이 SDD의 핵심 기반이 바로 ‘명세서(Specification)입니다.

SDD 방법론에서, 모든 것은 명세서에서 시작되고, 명세서가 중심을 잡는 객체가 됩니다. 코딩 에이전트의 나침반 이야기 연장선상에서, 명세서는 기계가 읽을 수 있는 북극성(North Star)같은 거라고 비유할께요. 생성된 코드에 지속적인 전역 목표를 부여하는 역할을 합니다.

좀 더 구체적으로 들여다보면, 명세서는 아래와 같은 내용을 구조화해서 담은 문서입니다:

Marc Brooker는 SDD에서 크게 보면 명세서가 두 번 쓰인다고 강조했습니다:

명세서는 소프트웨어가 무엇을 해야 하는지를 정의하고, UI·단위·통합 테스트를 비롯한 다양한 테스트, 형식 검증 등 ’실제로 작동하는’ 소프트웨어를 만드는 데 필요한 것들을 구축하는 기준이 됩니다.

자, 실제로 어떻게 생겼는지 궁금하시죠? 거창할 것도 없고, 가장 간단한 형태로는 이런 식입니다:

이 명세서를 에이전트에게 주면, 에이전트는 "무엇을 만들어야 하는가"와 "올바르게 만들었는지 어떻게 아는가"를 동시에 알게 되는 겁니다. 채팅창의 프롬프트가 아니라, 검토하고 수정하고 버전 관리도 할 수 있는 문서가 기준이 되는 거죠.

스펙 기반 개발은 바이브 코딩보다 훨씬 반복적인 프로세스입니다. 내부 루프(Inner Loop)와 외부 루프(Outer Loop)로 생각하면 이해하기 쉬울까 싶은데, 내부 루프는 현재 명세서에 맞는 소프트웨어를 만드는 목표 지향적인 실행 과정이고, 외부 루프는 그 소프트웨어가 실제 세계를 만나는 과정입니다.

내부 루프는 에이전트가 완전 자율로 실행할 수 있는 단계들로 구성됩니다:

외부 루프는, 소프트웨어를 사용자, 팀, 고객 앞에 내보이고, 새로운 기능과 변경·수정에 대한 피드백을 수집하고, 명세를 업데이트하고, 내부 루프를 다시 실행해서 변경 사항을 구현합니다. 소프트웨어와 명세를 실제 세계에 맞게 계속 발전시켜 나가는 순환인 거죠. 그리고 무엇보다 중요한 것은, 정확성이 지속적으로 강제된다는 점이구요.

여기서 핵심은, 명세서라는 것이 개발이 시작되고 나면 서랍 속으로 들어가야 하는 ‘기획 문서’가 아니라는 겁니다. Git 같은 버전 관리 시스템 안에서 코드와 동시에 함께 살아 숨쉬고, 소프트웨어 개발의 전체 사이클에 직접 연결되는, 개발 프로세스 안에서 살아 숨쉬는 무언가입니다.

엔지니어들이 멱등성(Idempotence), 단조성(Monotonicity), 교환법칙(Commutativity), 상태 일관성 같은 불변 조건들을 정의하면, AI 시스템이 대용량 입력 공간을 자동으로 생성해서 그 속성들을 스트레스 테스트합니다. 검증은 CI/CD 파이프라인의 일부가 됩니다. AI 에이전트가 명세를 읽고 업데이트하고, 명세에서 작업을 계획하고, 변경 사항을 명세에 맞게 검증합니다. 오류는 즉시 잡히고, 검증된 변경 내용만이 지속해서 유지됩니다.

명세서를 통해서, 자율 에이전트는 비로소 정확한 목표를 향해 올바르게 나아가는 방법의 지도를 얻게 됩니다. 명세서가 1차 산출물이 되고, 코드는 파생 산출물이 되는 셈이예요.

바이브 코딩의 한계를 넘어서, SDD가 실질적으로 AI 기반 코딩의 세계에 더해주는 건 뭘까요?

여기서 흥미로운 점이 하나 더 있습니다. SDD의 구조를 들여다보면, AI 연구에서 오랫동안 추구해온 '뉴로심볼릭 AI(Neurosymbolic AI)'의 방향과 자연스럽게 맞닿아 있다는 점인데요.

뉴로심볼릭 AI란 간단히 말해서 두 가지를 결합하는 접근입니다. 하나는 ChatGPT나 Claude처럼 자연어를 이해하고 창의적으로 생성하는 신경망 기반 AI, 다른 하나는 수학적 규칙과 논리로 옳고 그름을 판단하는 기호 기반 시스템입니다. AI가 글을 잘 쓰는 건 신경망 덕분이고, 체스 프로그램이 절대로 불법 수를 두지 않는 건 기호 시스템 덕분입니다.

SDD 워크플로우를 보면, 이 둘이 자연스럽게 역할을 나눕니다. LLM은 명세를 읽고 코드를 만들고 리팩토링을 제안합니다—창의적이고 유연한 부분이죠. 그리고 명세 자체가 '이 코드가 규칙을 지키고 있는가'를 판단하는 기준이 됩니다—논리적이고 엄격한 부분이죠. AI가 제안하고, 명세가 심판하는 구조입니다.

AI가 아무리 그럴듯한 코드를 만들어도, 명세의 조건을 통과하지 못하면 앞으로 나아가지 않습니다. 이것이 SSD가 바이브 코딩과 근본적으로 다른 지점입니다.

SDD가 중요한 트렌드가 되고 있다는 저희의 직감을 확인시켜준 게 바로 AWS의 Kiro입니다. Kiro는 스펙 기반 개발을 중심으로 명시적으로 설계된 AI IDE로, 바이브 코딩의 불안정성을 해결하기 위해서 만들어졌습니다.

Kiro는 앞서 설명한 워크플로우대로 작동합니다. 소프트웨어가 무엇을 해야 하는지 설명하는 구조화된 마크다운 문서 디렉토리로, 명세 작성에서부터 시작합니다. 작은 CLI 도구라면 파일 하나로 충분하고, 규모가 큰 프로젝트라면 UI, 백엔드, 의존성 등을 다루는 여러 파일이 될 수 있겠죠. 그런 다음에 SDD의 일반적인 루프를 거칩니다.

Kiro 내부에서 유저 스토리와 인수 기준은 자동으로 EARS 형식(Easy Approach to Requirements Syntax)으로 재작성됩니다. EARS는 자연어 패턴을 사용해서 요구사항을 작성하는 구조화된 방식으로, 다음과 같은 형태를 취합니다:

즉, EARS는 requirements.md 같은 파일 내부에서 사용되는 문법입니다. 이 구조는 각 요구사항을 직접 검증 가능하게끔 만들고, AI 시스템이 프롬프트를 오해하는 원인이 되는 ‘모호한 가정들’을 제거합니다.

AWS는 기존 코드에서 명세를 추출한 다음, 이를 활용해서 기능을 추가하거나 코드베이스를 유지보수하는 작업도 진행하고 있다고 합니다. 또, 개발자들에게 더 많은 제어권을 주기 위해서 명세 유형을 계속 추가하고 있습니다.

Kiro의 가장 중요한 확장 기능 중 하나는 속성 기반 테스팅(Property-based Testing)입니다. "입력 X → 기대 Y" 같은 개별 테스트 케이스를 직접 작성할 필요가 없습니다. 대신 출력이 만족해야 하는 일반적인 속성(Property)을 정의하면, 시스템이 자동으로 다양한 입력을 생성하고 그 속성이 유지되는지 확인합니다. 예를 들어서, 제곱근 함수를 몇 가지 숫자로 직접 테스트하는 대신, "결과를 제곱하면 원래 입력값에 가까워야 한다"는 속성을 정의하는 겁니다. 속성 기반 테스팅은 UI 같은 다른 영역에서도 작동해서, 일반적인 테스팅 방식보다 훨씬 넓은 커버리지를 제공합니다.

아직 출시되지 않았지만 곧 나올 흥미로운 Kiro 기능 하나가 더 있습니다. 뉴로심볼릭 기술을 활용한 명세 모호성 탐지입니다. Kiro가 명세를 형식적으로 추론해서 모호성과 내부적인 불일치 사항을 찾아내고, 이걸 개발자에게 명확히 해달라고 강조 표시할 수 있게 될 예정이라고 합니다.

AWS는 Kiro의 스펙 기반 접근법으로 인상적인 성과를 내고 있다고 보고하고 있습니다. 예를 들어서, 18개월 정도, 약 30명의 엔지니어가 투입될 거라고 예상하고 계획했던 아키텍처 재구축 프로젝트가 단 6명의 인력으로 76일 만에 완료되었습니다. 디지털 신원 확인 및 사기 방지 회사인 Socure는 3주 예상의 Scala → Go 마이그레이션을 2일 만에 완료했습니다. 엄청나죠?

GitHub의 Spec Kit도 주목할 만한 SDD 도구입니다. Kiro와 목표는 같지만, 작동 방식이 꽤 달라요.

Spec Kit의 핵심 철학은 "순서를 강제한다"는 겁니다. 개발자가 CLI에서 명령어를 직접 입력해서 단계를 하나씩 밟아가야 합니다:

중요한 건 앞 단계의 결과물이 없으면 다음 단계로 넘어갈 수 없다는 점입니다. AI가 명세도 없이 바로 코드부터 짜는 일이 구조적으로 불가능합니다.

한 가지 독특한 기능이 더 있어요. 프로젝트 컨스티튜션(Constitution)이라는 파일인데, 쉽게 말해서 "이 프로젝트에서 AI가 항상 지켜야 할 규칙 모음"입니다. 테스트 기준, 성능 목표, 코딩 스타일 같은 것들을 여기 한 번 정해두면 이후 모든 명세와 구현에 자동으로 적용됩니다.

Kiro와 비교하면 차이가 명확합니다. Kiro는 에이전트가 알아서 계획을 세우고 실행하는 자율 주행에 가깝다면, Spec Kit은 개발자가 핸들을 쥐고 단계마다 직접 명령을 내리는 수동 변속기에 가깝습니다. 어느 쪽이 낫다기보다, 얼마나 많은 제어권을 개발자가 갖고 싶은지에 따라 선택을 달리 하면 되겠죠?

Tessl은 조금 다른 각도에서 문제에 접근합니다. 핵심 아이디어는 이거예요: “AI 에이전트가 코드를 잘 짜려면 맥락(Context)이 필요한데, 그 맥락을 npm 패키지처럼 설치해서 쓸 수 있게 하자.”는 거예요.

에이전트에게 주입하는 맥락은 세 종류입니다:

이 세 가지를 묶은 걸 타일(Tile)이라고 부르고, Tessl의 패키지 매니저로 프로젝트에 설치합니다 - npm install처럼요.

코드를 건드리기 전에 반드시 세 가지 산출물을 먼저 만들어야 합니다: 계획 → 명세 → 테스트. 이 문서들은 저장소에 남아서 다음번 에이전트 실행 때도 그대로 재활용됩니다.

가장 독특한 기능은 Tessl Spec Registry입니다. 쉽게 말해 "명세 패키지 앱스토어"입니다. 에이전트가 모르는 라이브러리나 사내 기술 스택을 맞닥뜨렸을 때, 웹 검색이나 학습 데이터에 의존하는 대신 여기서 해당 Spec Pack을 설치하면 됩니다. 현재 10,000개 이상의 Spec이 등록되어 있고, 각각 특정 라이브러리 버전에 맞춰서 정리되어 있습니다.

Spec Kit과 비교하면 역할이 다릅니다. Spec Kit이 개발 순서를 강제하는 워크플로우 도구라면, Tessl은 에이전트가 필요한 지식을 설치해서 쓰는 지식 관리 플랫폼입니다. 두 가지는 경쟁 관계라기보다 보완 관계에 가깝다고 생각해요.

그렇다면 우리 모두에게 친숙한 GitHub Copilot, Claude Code, Cursor 같은 것들도 SDD 도구일까요?

결론부터 말하면, 아닙니다. 하지만 아닌 이유를 알면 SDD가 뭔지 더 선명하게 이해할 수 있어요.

이 도구들은 기본적으로 프롬프트 → 추론 → 코드 방식으로 작동합니다. 개발자가 무언가를 요청하면, AI가 대화 흐름을 보고 알아서 판단해서 코드를 만들어냅니다. 요구사항이나 아키텍처 결정은 채팅 히스토리 안에 녹아있을 뿐이지, 독립적인 문서로 존재하지 않습니다.

SDD는 다릅니다. 명세, 계획, 테스트, 작업 목록이 AI와 별개로 파일로 존재하고, AI는 그 파일을 기준으로 움직입니다. 이 차이가 핵심입니다.

그렇다고 Copilot이나 Claude Code가 SDD와 전혀 무관한 건 아닙니다. 이 도구들은 SDD 워크플로우 안에서 ‘실행’의 역할을 당연히 맡을 수 있습니다. Kiro나 Spec Kit이 명세를 만들고 계획을 세우면, Claude Code가 그걸 받아서 실제 코드를 짜는 식으로요.

지금 당장 시작해볼 수 있는 방법도 있습니다. Claude Code의 CLAUDE.md나 Cursor의 .cursorrules 파일에 프로젝트 규칙과 제약 조건을 정리해두는 겁니다. 완전한 SDD는 아니지만, 도구를 바꾸지 않고도 SDD의 핵심이라고 할 수 있는 습관—코드보다 명세를 먼저 쓰는 것—을 시작할 수 있는 가장 쉬운 첫걸음입니다.

SDD의 접근법을 좋아하는 사람들이 있습니다 - 주로, 믿을 수 없는 바이브 코딩에 지친 사람들이죠. 반면에, SDD의 방법론으로 개발을 하면 너무 시간이 많이 든다고 생각하는 사람들도 있습니다. 인터페이스를 정의하고, 동작의 제약 조건을 작성하고, 유저 스토리를 묘사하고, 불변 조건을 명세하는 데 실제 코딩보다 더 많은 시간을 쓸 수 있으니까요.

SDD가 여러분의 워크플로우에 맞는지 판단하는 데 도움이 될 정보들이 없을까 해서 한 번 정리해 봤습니다.

SDD가 특히 빛을 발하는 경우:

반대로 SDD가 잘 맞지 않는 경우:

그렇다고 SDD가 맞지 않는 상황이라고 해서 명세가 완전히 쓸모없는 건 아닙니다. 완벽한 명세가 아니더라도, 방향을 잡아주는 지도가 있는 것과 없는 것은 다릅니다. 지도가 있어야 더 크고 정교한 무언가를 만들 수 있으니까요.

AWS는 SDD가 앞으로 소프트웨어가 만들어지는 방식이 될 것이라고 본다고 합니다. 소프트웨어가 무엇을 해야 하는지, 어떻게 작동해야 하는지를 명시적으로 정의하고, 그 코딩 프로세스가 어떻게 점검되고 업데이트되는지까지 정의하기 때문입니다. 테스트와 검증이 개발의 중심에 놓이고, 그 결과 사용자가 실제로 원하는 것에 더 가까운, 더 일관된 결과물이 나옵니다.

SDD가 모든 팀의 표준 개발 방식이 될지는 물론 아직 모르지만, 지금 이 시점에서 두 가지는 분명합니다.

바이브 코딩에는 중심을 잡을 닻이 필요합니다. 속도와 자유는 좋지만, 그것만으로는 흔들립니다.

그리고 어떤 작업이든 명세화하고 표준화할 수 있게 된 순간, 그건 이미 최고의 품질을 요구해도 될 만큼 성숙한 워크플로우라는 뜻입니다.

읽어주셔서 감사합니다. 친구와 동료 분들에게도 뉴스레터 추천해 주세요!