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