Spec-Driven AI 개발 입문 가이드

개요

이 문서는 입문자가 BMAD, GitHub Spec Kit, OpenSpec 세 가지 방법론을 쉽게 이해할 수 있도록 만든 교육 자료입니다.

세 방법론은 모두 AI 코딩 에이전트 + 명세(spec) 기반 워크플로우를 강조하지만, 실제로는 강조점이 꽤 다릅니다.

이 문서의 목표는 세 가지입니다.

  1. 입문자가 세 방법론의 공통분모를 이해한다.
  2. 각 방법론이 어디서 다른지 감을 잡는다.
  3. 자신의 상황에 맞는 출발점을 고를 수 있게 돕는다.

---

1. 먼저, Spec-Driven 개발이 뭐예요?

기존 AI 코딩은 종종 이런 식으로 흘러갑니다.

Spec-Driven 개발은 이 문제를 줄이기 위한 접근입니다.

핵심 아이디어는 간단합니다.

즉, 채팅창 안에만 요구사항을 두지 않고, 명세 문서와 계획 문서, 작업 문서로 바깥에 꺼내는 것이 핵심입니다.

이렇게 하면 좋은 점이 있습니다.

---

2. 세 방법론의 공통점

BMAD, Spec Kit, OpenSpec은 모두 다음 생각을 공유합니다.

1) 바로 코딩부터 들어가지 않는다

먼저 의도와 범위를 정리합니다.

2) 명세를 문서로 남긴다

대화가 아니라 파일로 남기기 때문에, 다음 단계에서 재사용이 가능합니다.

3) 구현 전에 계획을 세운다

기술 선택, 제약 조건, 구조를 적어두고 구현합니다.

4) 큰 일을 작은 일로 나눈다

작업을 잘게 쪼개야 AI도 덜 흔들리고 검증도 쉬워집니다.

5) 사람은 steering, AI는 generation 역할을 맡는다

AI가 초안을 만들고, 사람은 방향과 기준을 잡아줍니다.

---

3. 세 방법론을 아주 쉽게 비유하면

BMAD

작은 회사 조직도를 AI 안에 옮겨놓은 방식입니다.

PM, Architect, Developer, QA, Scrum Master 같은 역할이 분리되어 있고, 각 역할이 순서대로 문서를 만들고 일을 넘깁니다.

GitHub Spec Kit

교과서적인 설계-계획-작업-구현 파이프라인입니다.

무엇을 만들지, 어떤 기술과 제약으로 만들지, 어떤 작업 순서로 구현할지 차근차근 진행합니다.

OpenSpec

기존 프로젝트에서도 부담 없이 붙일 수 있는 가벼운 spec 폴더 체계입니다.

아이디어가 생기면 proposal/spec/design/tasks를 만들고, 구현하고, 끝나면 archive하는 흐름이 핵심입니다.

---

4. BMAD 쉽게 이해하기

BMAD가 지향하는 것

BMAD는 단순한 spec 템플릿 모음이 아닙니다.

이 방법론은 AI 에이전트를 역할별로 분리해서, 마치 팀처럼 협업하게 만드는 데 초점이 있습니다.

대표적으로 이런 흐름을 가집니다.

즉 BMAD는 명세 기반 개발 + 애자일 프로세스 + 역할 기반 에이전트 운영이 합쳐진 형태라고 볼 수 있습니다.

BMAD의 장점

BMAD의 단점

BMAD가 잘 맞는 경우

---

5. GitHub Spec Kit 쉽게 이해하기

Spec Kit이 지향하는 것

Spec Kit은 세 방법론 중 가장 교과서적입니다.

핵심 흐름은 아주 명확합니다.

  1. **Constitution** — 이 프로젝트의 원칙과 기준을 정함
  2. **Specify** — 무엇을 왜 만들지 정의함
  3. **Plan** — 어떤 기술과 구조로 만들지 정함
  4. **Tasks** — 구현 작업으로 쪼갬
  5. **Implement** — 작업을 실행함

여기서 중요한 포인트는, 각 단계가 끝날 때 검토하고 다음 단계로 넘어간다는 점입니다.

즉 Spec Kit은 “생각-설계-작업 분해-구현”의 교과서 버전입니다.

Spec Kit의 장점

Spec Kit의 단점

Spec Kit이 잘 맞는 경우

---

6. OpenSpec 쉽게 이해하기

OpenSpec이 지향하는 것

OpenSpec은 “명세는 필요하지만 너무 무거우면 안 쓴다”는 철학이 강합니다.

핵심 흐름은 꽤 단순합니다.

OpenSpec은 이 change 단위를 중심으로 프로젝트를 관리합니다.

즉, 거대한 방법론이라기보다 AI 코딩 프로젝트에 붙이는 가벼운 명세 레이어에 가깝습니다.

OpenSpec의 장점

OpenSpec의 단점

OpenSpec이 잘 맞는 경우

---

7. 세 가지를 한눈에 비교하면

| 항목 | BMAD | GitHub Spec Kit | OpenSpec |

|---|---|---|---|

| 핵심 정체성 | 역할 기반 AI 팀 운영 | 정석적인 spec-driven 프로세스 | 가볍고 유연한 spec layer |

| 문서량 | 많음 | 중간~많음 | 중간 |

| 단계성 | 강함 | 강함 | 중간 |

| brownfield 적합성 | 중간~높음 | 높음 | 매우 높음 |

| greenfield 적합성 | 매우 높음 | 매우 높음 | 높음 |

| 초보자 진입성 | 낮음~중간 | 중간 | 높음 |

| 팀 운영 프레임 | 매우 강함 | 중간 | 약함 |

| 작은 수정 작업 적합성 | 낮음 | 중간 | 높음 |

---

8. 입문자는 무엇부터 시작하면 좋을까요

입문자에게는 보통 이렇게 추천할 수 있습니다.

A. 기존 프로젝트에서 작게 시작하고 싶다

OpenSpec이 가장 무난합니다.

이유는 change 단위가 직관적이고, brownfield에서도 부담이 적기 때문입니다.

B. 구조를 제대로 배우고 싶다

GitHub Spec Kit이 좋습니다.

이유는 phase가 명확해서 spec-driven development의 기본기를 익히기 좋기 때문입니다.

C. AI를 역할별 팀처럼 굴려보고 싶다

BMAD가 좋습니다.

이유는 단순 명세 도구가 아니라, 역할 기반 에이전트 운영을 강하게 경험할 수 있기 때문입니다.

---

9. 실전에서는 셋 중 하나만 써야 할까요?

꼭 그렇지는 않습니다.

실전에서는 섞어서 쓰는 그림도 가능합니다.

즉 앞으로 중요한 건 특정 도구 하나의 승패보다,

이 세 가지를 어떻게 조합하느냐에 더 가깝습니다.

---

10. 초보자가 실수하기 쉬운 포인트

1) 문서만 많이 만들고 구현 검증을 안 하는 경우

명세는 구현을 돕기 위한 것이지, 문서 자체가 목표는 아닙니다.

2) 작은 작업에도 너무 큰 프로세스를 쓰는 경우

복잡도에 맞게 방법론 강도를 조절해야 합니다.

3) AI가 만든 spec을 그대로 믿는 경우

spec도 AI가 만든 초안일 뿐이므로, 사람의 검토가 필요합니다.

4) 계획 없이 바로 implement부터 가는 경우

명세 기반 개발의 핵심은 “코딩 전에 정리하기”입니다.

5) 팀 규칙을 문서에 안 녹여 넣는 경우

기술 스택, 테스트 기준, UX 규칙, 보안 원칙이 빠지면 AI는 결국 추측하게 됩니다.

---

11. 추천 학습 순서

  1. OpenSpec 개념으로 change 단위를 이해한다
  2. Spec Kit 구조로 specify → plan → tasks → implement 흐름을 익힌다
  3. BMAD로 역할 분화된 AI 팀 운영을 경험한다

이 순서가 보통 가장 덜 어렵습니다.

---

12. 마무리

세 방법론은 모두 “AI에게 더 정확히 일시키기 위한 구조”라는 공통 목적을 가집니다.

하지만 접근은 다릅니다.

입문자라면 가장 먼저 외워야 할 문장은 이것 하나면 충분합니다.

좋은 AI 코딩은 프롬프트를 잘 쓰는 것에서 끝나지 않고, 의도와 제약을 구조화해 전달하는 데서 시작합니다.