2026년 소규모 팀을 위한 스펙 기반 개발(SDD) — 언제 빛나고, 언제 과한가

핵심 요약

• 스펙 기반 개발(SDD)은 챗 프롬프트가 아니라 버전 관리되는 스펙을 진실의 원천으로 두고, 그 스펙을 AI 에이전트가 실행하도록 만드는 워크플로입니다.
• 2026년 도구 생태계는 실재합니다. GitHub Spec Kit이 2026년 5월 15일 v0.8.11을 출시하며 30개 이상의 AI 에이전트를 지원하고, 그 옆에 AWS Kiro, Google Antigravity, 오픈소스 BMAD가 있습니다.
• 공개된 효과는 크지만 경계가 분명합니다. Airbnb는 3,500개 테스트 파일을 6주 만에 마이그레이션(추정 1.5년 → 6주), AWS는 “2주짜리” 알림 기능을 2일에 끝낸 Kiro 데모를 공개했습니다.
• SDD는 모든 팀에 맞지 않습니다. 솔로 개발, 단순 CRUD, 빠르게 변하는 프로토타입에는 스펙 작성 비용이 더 큽니다.
• 2~20명 팀에서는 하이브리드가 정답입니다. 핵심 20%만 스펙으로 끌고, 나머지는 가벼운 CLAUDE.md / AGENTS.md로 충분합니다.

2026년 초에 무엇이 바뀌었나

두 가지가 동시에 일어났습니다. 첫째, 모든 주요 AI 코딩 벤더가 자기 색깔의 SDD를 2025년 말부터 2026년 봄 사이에 출시했습니다 — GitHub은 Spec Kit, AWS는 spec / steering / hooks 모델 중심의 Kiro IDE, 그리고 Google은 Antigravity. 둘째, 대규모 엔지니어링 조직의 공개 사례가 진지하게 받아들일 만큼 구체적이 됐습니다. Airbnb의 3,500개 테스트 파일 6주 마이그레이션(수동 추정 1.5년), AWS가 공개한 Kiro 데모에서 “2주짜리” 알림 기능이 2일에 끝났다는 사례.

작은 팀도 최소한 입장을 가져야 할 정도의 움직임입니다. 다만 2026년의 더 유용한 질문은 “도입할까”가 아니라, “우리 업무 중 어디에서 스펙이 그 비용을 갚을 만큼 일하는가 — 어디서는 그저 우리를 느리게 하는가”입니다.

마케팅을 걷어낸 SDD의 정의

SDD는 세 가지 성질을 갖춘 워크플로입니다.

• 스펙이 유일한 진실의 원천입니다. 코드 옆 리포에 버전 관리됩니다. 스펙과 코드가 어긋나면 스펙이 이기고, 코드가 다시 생성됩니다.
• 스펙은 AI 의미에서 실행 가능합니다. 에이전트가 추가 챗 없이도 스펙을 읽고 계획·태스크·디프를 생성할 수 있어야 합니다.
• 사람은 이산적 게이트에서 사인오프합니다 — 보통 스펙 후, 계획 후, 그리고 태스크별로. 마지막에 거대한 PR 한 개를 리뷰하는 방식이 아닙니다.

GitHub Spec Kit의 워크플로가 좋은 구체적 레퍼런스입니다. 다섯 개의 슬래시 명령 — /speckit.constitution, /speckit.specify, /speckit.plan, /speckit.tasks, /speckit.implement — 가 자연어 기능 설명을 계획, 태스크 그래프, 마지막으로 PR 크기의 변경으로 바꿉니다. 핵심은 그 명령들이 아니라, 그것들이 강제하는 구조입니다.

2026년 스펙 기반 도구 비교

• 도구 — 형태 — 이럴 때 소규모 팀에 좋다 — 트레이드오프
• GitHub Spec Kit — 오픈소스 CLI, 리포 안에서 동작. 30개 이상 AI 에이전트 지원 — 이미 Copilot/Claude Code를 쓰고, 얇고 이식 가능한 스펙 레이어가 필요할 때 — 워크플로를 직접 조립해야 함
• AWS Kiro — spec / steering / hooks가 기본인 전용 IDE — 새 IDE를 받아들일 수 있고, SDD를 기본 경로로 두고 싶을 때 — IDE 전환 비용; 한 벤더 의견에 묶임
• Google Antigravity — 구글의 에이전트 우선 환경 — 이미 구글 AI 스택에 투자한 팀 — 비교적 신규 — 생태계 아직 형성 중
• BMAD / OpenSpec — 어떤 에이전트에서도 돌릴 수 있는 오픈 방법론/포맷 — 벤더에 묶이지 않고 SDD 디시플린을 원할 때 — DIY 비중이 크고 다듬어짐은 덜함
• CLAUDE.md / AGENTS.md — 리포 수준 컨텍스트 파일 한 개 — 오버헤드는 거의 없이 가치의 대부분을 얻고 싶을 때 — 완전한 스펙 워크플로는 아니며 팀 디시플린에 의존

언제 SDD가 보상하고, 언제 그렇지 않은가

업계 글들이 일관되게 말하는 결론은 단순합니다. SDD는 서비스를 가로지르는 기능, 마이그레이션, 규제 업무에 잘 맞고, 솔로 개발·단순 CRUD·주말 프로토타입에는 과합니다. 이유는 철학이 아니라 메커니즘입니다.

• 스펙이 곧 자산입니다. 같은 스펙이 여러 PR·서비스·엔지니어를 떠받친다면 비용을 갚습니다. 한 번 읽히고 다시 안 읽힌다면 안 갚습니다.
• 에이전트의 가드레일은 폭발 반경에 비례해야 합니다. 한 파일짜리 버그 수정에는 헌법과 태스크 그래프가 필요 없습니다. 열 개 서비스에 걸친 스키마 마이그레이션에는 필요합니다.
• 스펙 드리프트는 실재합니다. 빠르게 진화하는 프로토타입은 코드보다 스펙을 더 빨리 낡게 만듭니다. 제품 표면이 매주 바뀌면, 스펙도 매주 썩습니다.

2~20명 팀이 쓰기 좋은 기준 하나: 평소 그 일에 짧은 디자인 닥을 쓸 것 같다면 스펙으로, 안 쓸 것 같다면 그대로.

2주짜리 파일럿 플랜

팀 전체에 SDD를 약속할 필요는 없습니다. 아래 플랜은 일부러 작게 잡았습니다.

• 주차 — 액션 — 금요일까지 보여야 하는 결과
• 1주 · 월~수 — 활동 중인 리포 한 곳에 GitHub Spec Kit 설치. 테스트·에러 처리·네이밍·의존성 정책 같은 팀의 실제 컨벤션을 1쪽짜리 헌법으로 작성. — 새 엔지니어가 10분 안에 읽을 수 있는 헌법 파일 한 개.
• 1주 · 목~금 — 평소라면 짧은 디자인 닥을 썼을 다음 기능 하나 선택. /speckit.specify, /speckit.plan 실행. 코드 한 줄 작성 전에 사람이 두 결과를 리뷰. — 그 자체로 디자인 닥으로 사인오프해도 좋을 스펙·계획.
• 2주 · 월~수 — /speckit.tasks와 /speckit.implement 실행. 태스크당 PR 1개. 첫 PR까지의 시간, 리뷰 왕복, 리뷰에서 잡힌 결함 vs 테스트에서 잡힌 결함을 기록. — SDD 루프로 출시된 기능 1개 + 평소 워크플로와 비교 가능한 숫자.
• 2주 · 목~금 — 회고. 향후 어떤 카테고리의 일을 스펙으로 끌고, 어떤 일은 기존 방식으로 두는지 명시적으로 결정. — 팀이 실제로 따를 1쪽짜리 기준.

솔직한 실패 모드

소규모 팀 SDD 파일럿에서 잘 깨지는 지점들은 예측 가능합니다.

• 스펙이 그냥 마크다운으로 옮긴 “바이브”가 됩니다. 스펙이 모호하면 계획도 모호하고 구현은 더 정교하게 나쁩니다. SDD는 흐릿한 사고를 구해주지 않습니다 — 더 일찍 드러낼 뿐입니다.
• 리뷰가 엉뚱한 게이트로 몰립니다. 팀들은 보통 마지막 PR에서 리뷰를 다 합니다. SDD의 핵심은 스펙·계획 리뷰가 코드 작성 전에 결함 대부분을 잡는다는 데 있습니다. 그걸 건너뛰면 오버헤드만 더한 셈입니다.
• 벤더 락인이 슬그머니 들어옵니다. 벤더 IDE는 편하지만 나중에 에이전트를 갈아타기 어렵게 만듭니다. Spec Kit·BMAD·CLAUDE.md 계열 파일은 리포와 함께 이동하며, 보통 작은 팀이 원하는 형태입니다.

이 중 어느 것도 SDD를 건너뛸 이유는 아닙니다. 다만 팀 전체에 내놓기 전에 관찰 가능한 작은 파일럿을 먼저 돌리라는 이유들입니다.

출처

• GitHub — Spec Kit 리포지터리 — 2026년 5월 15일 v0.8.11 출시, 30개 이상 AI 에이전트 지원, 다섯 명령 워크플로(constitution / specify / plan / tasks / implement)의 근거.
• byteiota — 스펙 기반 개발이 ‘바이브 코딩’을 끝낸다 (2026년 3월) — AWS Kiro의 “2주 → 2일” 데모, Airbnb의 3,500개 테스트 파일 마이그레이션 수치, 그리고 언제 쓰고 언제 건너뛰어야 하는지 가이드의 근거.
• Augment Code — 2026 AI 코딩용 SDD 도구 베스트 6 — Spec Kit·Kiro·Antigravity·BMAD·OpenSpec 등 2026년 도구 지형의 근거.
• BCMS — 스펙 기반 개발: 결정판 2026 가이드 — SDD의 구조적 정의와 게이트형 리뷰 모델의 근거.

관련 글

• 2026년 소규모 팀을 위한 AI 코딩 도우미 선택 가이드 — Copilot · Cursor · Claude Code
• 2026년 소상공인 사이트를 위한 AI 검색 가시성