DevCraft 진행 방식
기능을 많이 만드는 것이 아니라,
검증 가능한 구조를 정의합니다.
일정과 예산이 흔들리는 이유
- ·일정이 늘어나는 이유 — 범위가 정해지기 전에 개발이 시작되고, 기능이 계속 추가됩니다.
- ·예산이 흔들리는 이유 — 범위 변경마다 비용이 달라지고, 중간에 요구가 늘어납니다.
- ·기능이 계속 추가되는 이유 — "이것도 있으면 좋겠다"가 검증 기준 없이 반영됩니다.
대부분은 구조 정의 없이 시작하기 때문입니다. 그래서 우리는 범위를 먼저 정하고, 6주 단위로 고정해 진행합니다.
6주 MVP 스프린트 상세 구조
주차별 산출물을 정해 두고, 그 범위 안에서만 진행합니다.
Week 1
구조 정의
요구사항 정리, 핵심 기능 3~5개 범위 확정, 데이터·플로우 구조 정의. 무엇을 만들지·무엇을 만들지 않을지 문서로 합의.
산출물
- 핵심 기능 범위 문서
- 데이터·플로우 초안
- 일정·범위 합의
Week 2
UX 및 시스템 설계
화면·플로우 설계, API·DB 설계, 관리자 구조 정의. 개발 착수에 필요한 설계까지 완료.
산출물
- 와이어프레임·유저 플로우
- API·DB 설계서
- 관리자 구조 정의
Week 3
개발 1차
정의된 범위 내 핵심 플로우 구현. 중간 산출물로 검토·피드백 반영.
산출물
- 핵심 플로우 1차 구현
- 중간 검토 결과 반영
Week 4~5
개발 2~3차
나머지 핵심 기능 구현 및 연동. 단계별 검수·수정.
산출물
- 전체 핵심 기능 구현
- 내부 테스트·버그 수정
Week 6
안정화 및 배포
QA, 배포, 기본 모니터링·문서 전달. 검증 가능한 상태로 1차 마무리.
산출물
- QA·버그 수정
- 배포·환경 설정
- 문서·모니터링 기본 전달
일반적인 개발 방식과 무엇이 다른가
차이를 단순히 나열합니다. 어떤 접근이 프로젝트에 맞는지는 목표와 제약에 따라 다릅니다.
흔히 있는 방식
- ·기능 중심으로 시작 — 무엇을 만들지 목록부터 나열하고 진행
- ·일정이 유동적 — 범위 변경에 따라 기간이 늘어남
- ·범위가 확장됨 — 진행 중 요구가 추가될수록 기능이 늘어남
- ·출시 시점이 불확실 — 마무리 기준이 명확하지 않을 수 있음
DevCraft 진행 방식
- ·구조 정의 후 시작 — 범위·데이터·플로우를 먼저 정한 뒤 개발 착수
- ·6주 고정 스프린트 — 주차별 산출물로 범위를 고정해 일정 예측 가능
- ·범위 고정 — 합의된 범위 안에서만 진행, 추가는 다음 단계로
- ·검증 가능한 상태로 종료 — 1차 목표(검증 가능)를 기준으로 마무리
우리가 기능을 결정하는 기준
넣을지 말지 판단할 때 아래 세 가지를 봅니다.
- 1.검증에 필요한가?
출시 후 사용자 반응을 보기 위해 꼭 있어야 하는지 기준으로 냅니다.
- 2.사용자 행동과 연결되는가?
전환·재방문·목표 행동과 직접 연결되는 기능을 우선합니다.
- 3.출시 지연을 만드는가?
복잡도나 공수가 크면 2차 스프린트로 미루고, 1차에는 제외합니다.
MVP 이후 확장
6주 스프린트는 검증 가능한 1차를 만드는 단계입니다. 이후는 같은 구조를 유지한 채 단계적으로 이어갑니다.
- ·프로젝트 단위 고도화 — 기능 확장, 관리자 강화, 성능 개선을 별도 스프린트로 진행.
- ·구조 유지 확장 — 데이터·API 구조를 바꾸지 않고 기능만 추가·개선.
- ·단계형 진행 — 검증 → 고도화 → 운영을 단계별로 나누어 제안.
이 방식이 맞는지 먼저 확인해보세요.
6주 안에 가능한 범위인지, 상담 단계에서 함께 정리합니다.