기획과 구현의 분리
아이디어를 다듬는 대화와 코드를 쓰는 작업은 다른 도구에서 진행됩니다. 기획의 불확실성이 구현 영역으로 흘러들지 않고, 구현의 제약이 기획을 좁히지 않습니다. 각 단계는 자기 자리에서 최선을 다하고, 확정된 산출물만 다음 단계로 전달됩니다.
— 도구가 아닌 흐름의 분리
// 01 — 출발점
시작은 빠르지만, 끝맺기는 어렵다
AI 도구로 누구나 빠르게 프로토타입을 만드는 시대. 그러나 그것을 출시 가능한 결과물로 끌고 가는 일은 여전히 숙제로 남습니다.
PROBLEM
흔한 문제
- 대화로 만든 코드가 어디까지 검토되었는지 추적이 어렵다.
- 기획이 머릿속에만 있어 다음 세션에서 일관성이 무너진다.
- 새 기능을 추가할 때마다 이전 결정과 충돌한다.
- 검증 없이 다음 작업으로 넘어가 결함이 누적된다.
- 결국 절반쯤 만들어진 프로토타입에서 멈춘다.
FSDD
FSDD의 답변
- 모든 결정은 문서로 남는다 — 대화는 휘발되지만 기획서는 남는다.
- 기획과 구현은 분리된다 — 흔들리는 영역과 확정된 영역을 나눈다.
- 변화는 정상이다 — “기획은 언제나 미완성”을 전제로 설계되었다.
- 검증은 단계다 — QA가 별도 Phase로 라이프사이클에 포함된다.
- 흐름은 끝까지 이어진다 — 기획부터 검증 후 종결까지 동일한 체계 안에서 진행된다.
“기획은 언제나 미완성이다.”
FSDD는 이 전제 위에 설계된 워크플로우다.
// 02 — 핵심 가치
세 가지 원칙으로 흔들림을 줄인다
FSDD는 복잡한 규칙이 아닌 세 가지 원칙 위에 서 있습니다. 모든 절차는 이 원칙에서 파생됩니다.
섹터 기반 기획 체계
기능을 무작위로 나열하지 않고, 관심사가 같은 영역(섹터)으로 묶어 기획합니다. 규모가 커져도 관련된 항목이 같은 폴더에 모이므로 탐색이 쉽고, 변경의 영향 범위가 좁아집니다. 하나의 영역을 손볼 때 다른 영역이 흔들리지 않습니다.
— 폴더가 곧 사고의 단위
자동화된 문서 관리
기획서가 작성되면 SPEC, TASK, TEST, QA 시트가 정해진 규칙에 따라 자동으로 생성되고 갱신됩니다. 프로젝트 빌더가 손으로 관리하는 부분은 최소화되고, 변경이 일어나도 추적 가능한 상태가 유지됩니다. 문서가 일이 되지 않습니다.
— 손으로 쓰지 않고 흐르게 한다
// 03 — 작동 원리
사람의 판단력 + AI의 실행력
FSDD는 1인 개발을 위한 방법론입니다. 한 명의 프로젝트 빌더가 기획 파트너 AI, 개발 AI와 각자의 강점을 살려 협업하며, 혼자서는 닿기 어려운 완성도까지 프로젝트를 끌고 갑니다.
PHASE: PLANNING · [기획 단계]
프로젝트 빌더
사람
기획 파트너 AI
AI
함께 아이디어와 기획서를 다듬는다
PHASE: EXECUTION · [구현 단계]
프로젝트 빌더
사람
개발 AI
AI
AI에게 개발을 맡기고 검증한다
코드는 빠르게 만들어집니다. 완성도는 그렇지 않습니다.
사람의 정성과 합리적인 시스템이 함께할 때, 결과물은 비로소 끝맺어집니다.
// 04 — 어떻게 시작하나
아이디어부터 검증까지
FSDD는 추상적 이론이 아닙니다. 머릿속의 막연한 아이디어부터 검증된 결과물까지, 6단계의 흐름으로 작동합니다.
-
01
아이디어 발상
[사람 단독]YOU당신의 머릿속에서 시작합니다. 만들고 싶은 무언가가 떠오릅니다. 아직 막연해도 괜찮습니다.
AI GUIDE—이 단계는 사람만의 시간입니다.
-
02
프로젝트 시작
[사람 ↔ 기획 파트너 AI]YOU대화형 AI에 새 프로젝트를 만들고 FSDD 가이드 문서를 등록합니다.
AI GUIDE가이드를 읽은 AI가 어떤 정보부터 물어봐야 할지 스스로 판단해 첫 질문을 던집니다.
-
03
기획서 작성
[사람 ↔ 기획 파트너 AI]YOUAI의 질문에 답하며 컨셉을 구체화합니다.
AI GUIDE섹터별 기획서 양식을 안내하고, 메타데이터까지 자동으로 채운
.md파일을planning/폴더에 정리합니다. -
04
기획서 인계
[사람]YOU완성된 기획서를 개발 AI에게 넘기고 작업을 시작하라고 합니다.
AI GUIDE개발 AI가 기획서와 FSDD 가이드를 읽고, 무엇부터 작업할지 스스로 판단합니다.
-
05
자동 구현
[개발 AI 단독]YOU개입하지 않고 결과를 기다립니다.
AI GUIDE가이드대로 SPEC 변환, 작업 분해, 코드 작성, 테스트 시트 작성까지 순차 진행합니다.
-
06
검증과 수정
[사람 + 양쪽 AI]YOU직접 사용해보며 문제를 발견합니다.
AI GUIDE문제 분류 기준을 제시하고, 구현 문제는 개발 AI에게, 기획 문제는 기획 파트너 AI에게 자동 분배합니다.
UPCOMING
실전 가이드
각 단계의 구체적 도구 사용법, 폴더 구조, 기획서 작성 규칙, 테스트 시트 운영 방법은 별도 가이드 페이지에서 다룹니다.
— 준비 중
// 05 — 라이프사이클
네 단계로 끝까지 흐른다
시작은 기획에서, 끝은 검증에서. 그리고 검증은 다시 기획으로 돌아옵니다. FSDD는 한 방향의 흐름이 아니라, 닫힌 루프입니다.
01
기획
아이디어를 구체화하고 문서로 남긴다
장르와 컨셉을 정하고, 섹터를 나누고, 참고 사례를 분석합니다. 그 결과를 메타데이터가 포함된 기획서 .md 파일로 정리하여 planning/ 폴더에 둡니다.
02
스펙 + 구현
기획서를 실행 가능한 결과물로 변환한다
기획서를 SPEC으로 변환하고, 작업을 분해한 뒤 순차적으로 구현합니다. 동시에 테스트 시트를 작성하고, 전체 기능 현황을 추적합니다.
03
QA
직접 사용해보며 문제를 찾는다
테스트 시트를 기준으로 한 항목씩 직접 사용해봅니다. 기획 의도와 실제 동작을 비교하고, 문제를 분류하여 기록합니다. 분류는 버그·다듬기·균형 조정으로, 심각도는 P0부터 P3까지 매깁니다.
04
수정 + 검증
발견된 문제를 분기하여 처리한다
발견된 문제를 두 가지로 나눕니다. 단순 구현 결함은 구현 실행자에게, 기획 자체의 문제는 기획 파트너에게 보냅니다. 수정 후 다시 검증하여 종결합니다.
Phase 4의 결과는 종결로 끝나기도 하고, Phase 1로 다시 돌아가기도 합니다.
기획은 언제나 미완성이라는 전제는, 이 루프 안에서 비로소 작동합니다.
// 06 — 운영 구조
흐름은 하나, 대화는 셋
모든 대화를 한 자리에서 하면 맥락이 섞입니다. FSDD는 대화의 주제를 셋으로 나눠, 각 논의가 자기 영역에만 집중하도록 합니다.
TOPIC 01
기획 논의
기획에만 집중하는 논의
- DOES
- 컨셉 정리, 섹터 정의, 기획서 작성, SPEC 검토, QA에서 발견된 기획 이슈 대응
- OUTPUT
- 기획서
.md파일
TOPIC 02
개발 논의
구현 작업 지시와 이슈 검토
- DOES
- 구현 실행자에게 작업 지시, 구현 중 이슈 검토, QA 발견 결함 수정 요청
- OUTPUT
- 작업 지시 결과, 수정된 코드
TOPIC 03
데이터 논의
수치와 구조를 다루는 논의
- DOES
- 데이터 구조 설계, 균형 수치 검토, 테이블 설계
- OUTPUT
- 데이터 정의서, 균형 수치 결정
세 갈래로 나누는 이유는 추적성입니다.
한 자리에 섞인 결정은 시간이 지나면 출처를 잃습니다.
// 07 — 익숙한 고통
그 순간, 모두가 멈춘다
AI 도구로 무언가를 만들어본 사람이라면 마주쳤을 순간들이 있습니다. FSDD는 그 순간들을 출발점으로 설계되었습니다.
SITUATION01
어제 AI와 길게 논의해서 정한 시스템 구조가 있었습니다. 오늘 새 세션을 열고 이어가려는데, AI는 그 결정을 모릅니다. 다시 처음부터 설명해야 합니다.
FSDD→
모든 결정은 .md 파일로 남습니다. 다음 세션은 그 파일을 읽고 시작합니다. 결정은 휘발되지 않습니다.
SITUATION02
처음에는 잘 돌아갔습니다. 기능을 하나씩 추가했고, 매번 AI가 빠르게 만들어줬습니다. 일주일 후, 새 기능을 추가하니 이전 기능이 깨졌습니다. 어디서부터 손대야 할지 모르겠습니다.
FSDD→
기획서가 섹터별로 분리되어 있고, 각 기능은 자기 SPEC을 가집니다. 변경의 영향 범위가 좁아지고, 충돌은 미리 발견됩니다.
SITUATION03
빨리 만들고 싶어서 테스트를 미뤘습니다. 지금 와서 보니 어디가 정상이고 어디가 결함인지 구분이 안 됩니다. 처음부터 다시 만들고 싶은 충동이 듭니다.
FSDD→
QA가 별도 Phase로 라이프사이클에 들어 있습니다. 모든 항목은 테스트 시트에서 추적되며, 결함은 분류되어 처리됩니다.
SITUATION04
시작은 신났습니다. 며칠 만에 동작하는 프로토타입이 나왔습니다. 그러나 거기서 더 나아가지 못합니다. 폴더에는 미완성 파일들이 쌓여 있고, 다른 프로젝트로 시선이 옮겨집니다.
FSDD→
라이프사이클이 4단계로 끝까지 정의되어 있습니다. 각 단계의 완료 조건이 명시되어 있고, 다음 단계로 넘어가는 흐름이 자동으로 생깁니다. 멈출 핑계가 줄어듭니다.
위 시나리오 중 하나라도 익숙하다면, FSDD가 제시하는 흐름을 한 번 살펴볼 가치가 있습니다.
이 방법론은 추상적인 이론이 아니라, 같은 고통을 겪은 사람의 작업 도구입니다.
// 08 — 업데이트
업데이트는 끝나지 않는다
FSDD는 실전에서 부딪힌 문제를 모아 정기적으로 업데이트됩니다. 한 번에 완성되는 방법론이 아니라, 쓰면서 다듬는 방법론입니다.
CURRENT
1.0.1
기획 체계, 자동화된 문서 관리, QA 단계, 도구 분담의 골격이 자리잡힌 단계입니다.
IN PROGRESS
아직 명확하지 않은 부분들
- 검증 → 수정 → 재기획 시작 흐름 — 4단계 라이프사이클은 정의되었지만, QA 결과가 수정과 재기획으로 이어지는 흐름의 세부 절차는 아직 다듬는 중입니다.
- 균형 조정 경량 절차 — 수치 조정처럼 빈번하게 일어나는 변경에 전체 갱신 사이클은 무겁습니다. 균형 조정만의 경량 절차가 필요합니다.
- 다중 프로젝트 운용 — 여러 프로젝트에 동시에 적용했을 때의 일관성 유지 방법은 아직 검증되지 않았습니다.
UPCOMING
실전 가이드, 준비 중
이 페이지는 FSDD가 무엇인지를 소개하는 페이즈 1입니다. FSDD를 자신의 프로젝트에 도입하기 위한 상세 가이드 — 폴더 구조, 파일 세트, 기획서 작성 규칙, 테스트 시트 운영, 인스톨 절차 — 는 페이즈 2에서 별도 페이지로 공개될 예정입니다.
— 실전 가이드의 공개 시점은 첫 적용 프로젝트의 검증 사이클 완료 후입니다.