현재 우리 팀의 개발 방식은 표면적으로는 스프린트 기반의 애자일 프로세스를 따르고 있지만 실제로는 애자일을 빙자한 워터폴형태로 운영되고 있습니다. 스프린트가 일정 단위로만 기능하며 각 기간 내에서 디자인 → 프론트엔드 → 백엔드 → QA가 순차적으로 진행되는 구조이기 때문입니다. 이러한 흐름은 초기 계획에 따라 움직이는 전통적 워터폴 모델과 다를 바 없으며 실질적인 병렬 협업이나 피드백 루프가 존재하지 않습니다.
스프린트는얼마나 많이가 아니라 무엇을 끝내고 어떤 가치를 전달했는가를 중심으로 돌아가야 합니다.
그러나 현재 구조에서는 기능이 명확히 정의되지 않아 스프린트마다 무엇이 완료된 상태인가에 대한 공통 기준이 없습니다. 이로 인해 리뷰, 회고 또한 양적 진행 보고에 그치고 있습니다.
본 프로젝트는 아직 MVP 단계이지만 소프트웨어 품질은 초기 시장 반응과 고객 신뢰 형성에 직접적인 영향을 미치는 핵심 요인입니다. 스프린트 단위로 기능이 빠르게 추가되더라도 안정성과 일관성이 확보되지 않으면 사용자 경험이 부정적으로 고착되고 이후 개선 속도보다 신뢰 회복 비용이 더 커질 수 있습니다.
이에 따라 이번 문서에서는 마일스톤 중심의 기능 기반 병렬 협업 구조로 전환하여 프로젝트의 효율성과 개발 사이클의 유연성뿐 아니라 MVP 단계에서도 확보 가능한 품질 기준을 강화하는 방안을 제안합니다.
이번 제안은 특정 방법론으로의 전환이 아니라 현재의 워터폴형 스프린트를 진짜 애자일로 복원하는 것에 있습니다. 마일스톤으로 방향을 정하고 스프린트로 리듬을 유지하며 FDD로 기능 단위의 정의와 품질 기준을 확보하는 구조를 통해 속도 중심의 개발에서 가치 중심의 개발로 전환하는 것을 목표로 합니다.
graph LR
subgraph Sprint_기반["스프린트 중심 (기간 중심)"]
A1["Sprint 1<br>디자인 → FE → BE → QA"]
A2["Sprint 2<br>디자인 → FE → BE → QA"]
A3["Sprint 3<br>디자인 → FE → BE → QA"]
A4["배포"]
A1 --> A2 --> A3 --> A4
end
subgraph Milestone_FDD["마일스톤 + FDD 중심 (기능 중심)"]
M1["MS1<br>마일스톤 (목표 중심)"]
F01["F01 로그인/회원가입<br>디자인 · FE · BE · QA 병렬"]
F02["F02 스터디룸 생성<br>디자인 · FE/BE 병렬 · QA"]
F03["F03 초대 기능<br>디자인 · FE/BE/QA 병렬"]
Deploy["배포 (MS1 완료)"]
M1 --> F01
M1 --> F02
M1 --> F03
F01 --> Deploy
F02 --> Deploy
F03 --> Deploy
end
style Sprint_기반 fill:#333,stroke:#f59e0b,stroke-width:1px
style Milestone_FDD fill:#333,stroke:#0284c7,stroke-width:1px
style Deploy fill:#333,stroke:#16a34a,stroke-width:1px
| 구분 | 현재 방식 (스프린트 기반) | 개선 방안 (마일스톤 + FDD기반) |
|---|---|---|
| 운영 단위 | 스프린트 (1 ~ 2주 주기, 일정 중심) | 마일스톤 (3 ~ 4주 단위, 목표 중심) |
| FDD(기능 중심) | ||
| 관리 초점 | 이번 기간 안에 얼마나 많은 작업을 처리했는가 | 이번 마일스톤 안에 어떤 기능을 완성했는가 |
| 작업 기준 | 역할별 분리 (디자인 + BE → FE → QA 순서) | 기능별 병렬 진행 (한 기능 내에서 디자인, FE, BE, QA 동시 진행) |
| 작업 흐름 | 순차적 단계로 진행 (워터폴과 유사함) | 병렬적 + 유기적 (애자일 + FDD 하이브리드) |
| 협업 구조 | 역할간 의존성이 높음(대기 발생 가능성 높음) | 의존성이 낮아지며 기능단위로 자율적으로 협업 가능 |
| 리소스 활용 | 한 역할 완료 후 다른 역할 진행 | 모든 포지션이 동시에 작업 진행 |
| 배포 기준 | 스프린트 종료 시점 | 마일스톤 완성(종료) 시점 |
| 문서 관리 | 개별 이슈 중심 | 기능 단위 |
| 차이점 | 속도 중심 | 품질 + 완성도 있는 결과물 |
마일스톤 + FDD구조는 품질과 병렬성을 확보하는 데 강점을 가지지만 팀 규모와 커뮤니케이션 빈도에 따라 리스크가 커질 수 있습니다. 각 기능 단위가 병렬로 진행되기 때문에 문서화가 충분하지 않거나 팀 간 정보 공유가 늦을 경우 작업 간 불일치, 중복 개발, 통합 지연이 발생할 수 있습니다.
특히 우리 팀은 주 단위 미팅 체계로 운영되고 있기 때문에 실시간 피드백이 어렵고, 진행 중 이슈를 즉시 감지하기 어렵다는 구조적 한계가 존재합니다. 이러한 커뮤니케이션 간극은 기능 간 의존 관계를 늦게 파악하게 만들고 결과적으로 일정 예측의 정확도를 떨어뜨릴 수 있습니다.
이러한 리스크는 비동기적 커뮤니케이션 체계를 도입함으로써 보완할 수 있습니다.