이 책은 두 분의 독자를 모두 환영합니다. 한 분은 개발 경험이 있는 분입니다. 5파일이라는 단어를 처음 듣더라도 "아, 명세를 파일로 관리하는 패턴이구나" 정도는 즉시 떠올리실 겁니다. 다른 한 분은 개발 경험이 적거나 없는 분입니다. 어쩌면 동업자가 같이 보자고 해서, 혹은 AI로 앱을 만들 수 있다는데 어디서 시작해야 할지 몰라서 펼치셨을 수도 있습니다.

먼저 SDD라는 단어부터 풀어봅니다.

SDD = Spec-Driven Development = 명세 기반 개발.

"명세 (Spec, Specification)"는 "무엇을 만들 것인지 적어둔 문서"입니다. 우리가 1장 이후로 만들 SPEC.md 파일이 정확히 그것입니다. SDD는 "명세를 먼저 적고, 명세에 따라 코드를 만드는 방식"을 가리킵니다.

전통 코딩에서도 "설계 먼저"는 항상 강조됐습니다. 그런데 AI 코딩 도구(Claude Code, GitHub Copilot, Cursor 등)가 등장하면서 "설계가 더 중요해졌다"는 변화가 일어났습니다.

이 세 가지가 SDD가 "AI 시대의 핵심 사상"이 된 이유입니다.

이 책을 펼친 시점(2026년 5월)에 시장에는 9개 이상의 SDD 도구가 활발히 경쟁합니다. 이 9개를 한 번에 다 익힐 필요는 없습니다. "풍경이 이렇다"는 것만 알면 됩니다.

이제 9개 중 가장 영향력 있는 5개를 차례로 짧게 풀어보겠습니다. 나머지 4개는 "이런 게 있다" 정도만 알아두시고, 자세한 내용은 부록 H에서 깊게 다룹니다.

0.2.1 GSD (Get Shit Done) — 솔로 자동화의 풀스펙

한 줄: "내가 무엇을 만들고 싶은지 정확히 안다면, 이 도구가 그것을 만들어준다."

누가 만들었나: TÂCHES라는 1인 개발자.

어떤 도구인가: 솔로 개발자(혼자 일하는 개발자)를 위한 자동화 도구. 사용자가 한 명령을 입력하면, AI가 "질문 → 조사 → 요구사항 정리 → 로드맵 작성"을 알아서 진행합니다.

핵심 명령어 흐름:

/gsd-new-project    — 새 프로젝트 시작
/gsd-discuss-phase  — 한 단계의 세부 결정 논의
/gsd-plan-phase     — 그 단계의 작업 계획 수립
/gsd-execute-phase  — 계획대로 코드 실행
/gsd-verify-work    — 결과 검증
/gsd-ship           — 최종 출시

강점: 자동화 깊이가 가장 깊습니다. 솔로 개발자가 "엔터프라이즈 의식(긴 회의·결재 절차·승인 사이클)" 없이 빠르게 진행할 수 있습니다.

약점: 학습 곡선이 가파릅니다. 명령어를 외워야 할 게 많고(전체 30개 이상), 처음 시작 시 "86개의 작은 도구(skills)"가 자동 설치되어 비개발자에게 부담스럽습니다.

0.2.2 GitHub Spec-Kit — GitHub 공식 spec-first

한 줄: "프로젝트 헌법을 한 번 정하면, 모든 명세가 그 헌법을 따른다."

누가 만들었나: GitHub(Microsoft 자회사). 코드 공유 사이트 GitHub의 공식 도구.

핵심 명령어 흐름: /speckit.constitution → /speckit.specify → /speckit.clarify → /speckit.analyze → /speckit.implement

강점: GitHub 공식 백업이라 장기 유지보수가 안정적입니다. "NEEDS CLARIFICATION" 같은 표시로 "여기는 더 명확히 정해야 함"을 자동 알려줍니다.

약점: 명세를 약간만 수정하려고 해도 "전체 명세 재생성" 패턴이 자주 발생합니다. 팀이 검토했던 명세가 통째로 바뀌면 다시 검토해야 합니다.

0.2.3 OpenSpec — 기존 코드 변경 명세

한 줄: "이미 있는 코드에 변경할 부분만 명세하고, 끝나면 본문에 합친다."

어떤 도구인가: 새 프로젝트가 아니라 이미 있는 코드를 고치는 데 특화됩니다. "전체 명세"가 아니라 "변경 제안(delta spec, 차이 명세)"만 적습니다.

비유: 새 집을 짓는다면 → Spec-Kit 같은 도구(전체 설계도). 이미 있는 집을 리모델링한다면 → OpenSpec("이 방을 이렇게 바꾼다"만 적음).

0.2.4 BMAD-METHOD — 멀티 AI 페르소나 풀팀

한 줄: "AI 개발팀 전체를 시뮬레이션 — 분석가·PM·아키텍트·개발자·QA가 페르소나로 협업."

AI에게 7~8개 직무를 맡겨서 한 팀처럼 작동하게 합니다. 각 직무가 명확한 이름을 가집니다: Mary(분석가), Preston(PM), Winston(아키텍트), Sally(제품 오너), Simon(스크럼 마스터), Devon(개발자), Quinn(QA), BMad Master(총괄 조율자).

강점: 산출물의 깊이가 가장 깊습니다. PRD + 아키텍처 문서 + 스토리 분해 + 테스트 전략까지. 복잡한 도메인(의료·금융·법률)에 강합니다.

약점: 가장 무겁습니다. 7~8개 페르소나의 협업을 1인 운영자가 관리하는 부담이 큽니다.

0.2.5 Taskmaster AI — 작업 분해 전문

한 줄: "명세 자체보다 작업을 어떻게 쪼개고 의존성을 잡을지에 집중."

다른 도구들이 "명세를 어떻게 만들 것인가"에 집중한다면, Taskmaster는 "명세에서 작업을 어떻게 쪼갤 것인가"에 집중합니다. "이 작업이 끝나야 저 작업이 시작된다" 같은 의존성을 그래프로 보여줍니다.

강점: Cursor(AI 코드 에디터)와의 통합이 가장 매끄럽습니다. 작업 분해 + 진행 추적이 본질입니다.

약점: 명세 자체의 깊이는 다른 도구들보다 얕습니다. 명세는 다른 도구로 만들고 Taskmaster는 보조로 사용하는 패턴이 일반적입니다.

0.2.6~0.2.9 나머지 4개 — 짧은 소개

이 절이 0장의 가장 중요한 부분입니다.

9개 도구를 차례로 살펴보면, 공통적으로 다루지 못하는 영역 5개가 명확히 보입니다. 이 5개가 우리 "5파일+ 사이클"의 "+(확장)"이 채우는 영역입니다.

미점유 영역 1 — 회색지대 결정 (E1)

법적·윤리적·시장적 "회색지대"에서 "안전하고 솔직한 자기 위치"를 정하는 작업입니다.

미점유 영역 2 — 1인·소수 운영자의 12개월 페이스 (E2)

"이 사람이 6~12개월 동안 무너지지 않을 페이스인가"의 메타 결정입니다.

미점유 영역 3 — 두 검토자 사각지대 (E3)

"검토자 한 명에 의존하지 말라" — 두 다른 AI 모델 또는 두 사람의 사각지대가 다르므로 통합해야 입체적 검증이 됩니다.

미점유 영역 4 — LogOnTable 실황 보존 (E4)

"왜 그 결정을 내렸는가"의 사용자-AI 대화 트레이스를 보존하는 패턴입니다.

왜 중요한가: 6개월 후 동업자가 "이 결정을 왜 이렇게 내렸지" 펼쳤을 때, 결정 결과만 있으면 답이 없습니다. 결정 "과정"의 대화가 보존되어 있어야 합니다.

9개 도구는 모두 "산출물(artifact)" 중심입니다. 결정에 도달하는 "대화"는 휘발됩니다(AI 세션이 끝나면 사라집니다). 우리는 의도적으로 보존합니다.

미점유 영역 5 — 콘텐츠 SSOT (코드 외 다중 페르소나) (E5)

"같은 사실을 여러 페르소나가 다른 톤으로 표현"할 때, 사실 자체는 단일 출처에서 받는 패턴입니다.

객관 비교가 끝났습니다. 이제 따뜻한 톤으로 돌아옵니다.

이 책은 9개 자리에 "5파일+ 사이클"을 골랐습니다. 세 가지 이유가 있습니다.

이유 1 — 학습용으로 "수동의 가치"가 있습니다

GSD의 /gsd-new-project 한 명령이 "질문 → 연구 → 요구사항 → 로드맵"을 자동으로 진행하면, 학습자는 그 안에서 일어나는 "왜 이 질문을 하는가, 왜 이 요구사항이 v1이고 저것이 v2인가"를 체험하지 못합니다. 결과는 빠르지만 학습은 얕습니다.

5파일+ 사이클은 의도적으로 수동입니다. SPEC v1 → 외부 검토 → SPEC v2 → 사용자 직관 → SPEC v3 → 두 검토자 → SPEC v4. 각 단계가 "왜"를 노출합니다.

이유 2 — 5개 미점유 영역이 "본질"입니다

위에서 본 5개 영역(회색지대 · 1인 페이스 · 두 검토자 · LogOnTable · 콘텐츠 SSOT)은 "부록"이 아닙니다. 우리가 12개월 여정에서 가장 자주 부딪히는 영역입니다.

5파일+ 사이클은 이 5개 영역을 자기 본질의 일부로 삼습니다. 표준 도구를 단순화한 것이 아니라, 표준 도구가 다루지 못하는 영역을 다루기 위한 형식입니다.

이유 3 — 표준 도구로 "졸업"할 수 있습니다

5파일+ 를 1~2 프로젝트에 적용한 후, 표준 도구로 옮겨가는 길이 자연스럽게 열려 있습니다. 1탄 부록 H에 매핑표가 있고, 3탄 권7에서 표준 도구 통합 가이드가 다뤄집니다.

이 책은 "5파일+ 만 쓰자"고 주장하지 않습니다. "5파일+ 로 시작하고, 적절한 시점에 표준 도구로 옮기되, 그때도 5개 미점유 영역은 자체 보강해야 함"을 명시적으로 말합니다.

마지막 절은 학습 곡선의 약속입니다.

3탄까지 마치신 분(개발자 동업자, 비개발자 동업자, 직원 모두)은 새 프로젝트를 시작할 때:

• 9개 표준 도구 중 "이 프로젝트에 가장 맞는 것"을 선택할 수 있습니다.
• 5파일+ 의 5확장으로 "표준이 못 다루는 영역"을 보강할 수 있습니다.
• 줍줍(B2C)과 TSV(미디어) 두 도메인 사례를 비교 참조해서 새 도메인에 적용할 수 있습니다.

지금까지 우리는 9개 도구의 풍경을 객관적으로 보고, 그 안에서 5파일+ 의 자리를 한 문장으로 좌표화했습니다.

다음 장에서 한 단계 들어가서:

• 5파일(SPEC · PLAN · REVIEW · BUILD · CLAUDE) 각각이 9개 표준의 무엇과 무엇에 매핑되는가
• 확장 5종(E1~E5)이 각 파일과 어떻게 결합하는가
• "5파일+"라는 이름이 각 영역에서 구체적으로 어떻게 작동하는가

를 정리합니다.