소규모 B2B SaaS 팀을 위한 듀얼트랙 애자일 — 2주 사이클 실전 운영기
스크럼? 칸반? 어느 쪽도 우리 상황에 딱 맞지 않아서 직접 프로세스를 설계했다. 소규모 팀에서 기획과 개발이 서로를 기다리지 않는 구조를 만든 경험을 공유한다.
왜 직접 만들었나
일반적인 스크럼은 "기획 → 개발 → 배포"가 한 스프린트 안에 순차적으로 일어난다. 문제는 개발팀이 기획을 기다리는 유휴 시간이 생긴다는 것이다. 소규모 팀에서 이 유휴 시간은 치명적이다.
듀얼트랙 애자일의 핵심은 단순하다: 다음 사이클의 기획(Discovery)과 현재 사이클의 개발(Delivery)을 동시에 돌린다. 개발팀이 이번 차수를 만드는 동안, 기획/디자인팀은 다음 차수를 준비한다.
2주 사이클 전체 그림
두 트랙이 2주 주기로 맞물려 돌아간다. Discovery가 끝나면 그 결과물이 다음 Delivery의 입력이 된다. 파이프라인처럼.
Phase 1. Discovery — 다음에 뭘 만들지
백로그 정제
고객 피드백, 내부 아이디어를 유저 스토리 단위로 정리한다. 이 단계에서 중요한 건 "무엇을"이지 "어떻게"가 아니다. 기술 부채도 별도 섹션으로 관리하면서 매 사이클 리소스를 강제 할당한다. 이걸 안 하면 기능 개발에 밀려서 영원히 처리 안 된다.
Blueprint & PRD
우선순위가 높은 항목은 아키텍처 영향도를 검토하는 Blueprint를 먼저 만든다. 이 기능이 기존 시스템에 어떻게 붙는지, 어떤 서비스에 변경이 필요한지를 미리 파악하는 것이다. 그 위에 기능 목적과 제약사항을 담은 PRD를 작성한다.
디자인 및 프로토타이핑
개발 착수 전에 시각적 결과물을 확정한다. "개발 중 스펙 변경"이 가장 큰 낭비라는 걸 몇 번 겪고 나서 이 단계를 반드시 거치게 만들었다.
경영진 컨펌
2주치 작업 계획이 비즈니스 방향과 맞는지 검증하는 게이트. 스타트업 규모라면 이 단계가 빠르게 돌아간다.
Phase 2. Delivery — 실제로 만들기
킥오프 + 회고
사이클 시작일에 두 가지를 동시에 한다:
- 이전 사이클 회고: Keep/Problem 공유 (길게 안 한다, 15분)
- 이번 사이클 킥오프: 확정된 스토리 브리핑, 세부 일정 확인
개발 → QA → 배포
확정된 스펙에 따라 개발하고, 배포 전 기능 명세 기반 QA를 거쳐 정기 배포한다. 2주마다 예측 가능한 릴리즈가 나간다는 게 핵심이다.
Hot-track — 현실은 계획대로 안 된다
정기 사이클만으로는 부족하다. 운영 중인 서비스에서 크리티컬 버그가 터지거나, 고객사에서 긴급 요청이 들어온다.
운영 원칙:
- 전체 리소스의 ~20%를 버퍼로 확보해둔다
- 정기 사이클 배포를 기다릴 수 없는 건만 Hot-track으로 처리
- Hot-track 배포 건은 다음 킥오프에서 함께 리뷰
- 발생한 기술 부채는 즉시 백로그에 등록
20% 버퍼가 없으면 Hot-track이 정기 사이클을 잡아먹는다. 이건 협상 불가능한 원칙이다.
전체 워크플로우
티켓 관리 — 보드 상태 설계
프로세스가 있어도 티켓 상태가 이를 반영하지 않으면 무용지물이다. 듀얼트랙에 맞춰 보드 상태를 설계했다.
| Phase | Status | 진입 조건 |
|---|---|---|
| Discovery | BACKLOG |
티켓 생성 |
GROOMED |
Background/Overview 작성 완료 | |
PRIORITIZED |
P0~P3 우선순위 라벨 부여 | |
SPEC_READY |
PRD + 디자인 완료 (P0/P1 대상) | |
| Commitment | COMMITTED |
차수 계획 + 경영진 컨펌 |
| Delivery | IN_PROGRESS |
개발자 착수 |
IN_REVIEW |
PR 생성 | |
QA |
리뷰 승인 완료 | |
DONE |
QA 통과 + 배포 |
핵심은 SPEC_READY와 COMMITTED 사이의 게이트다. Discovery에서 스펙이 완성되지 않은 티켓은 Delivery에 넘어갈 수 없다. 이 경계가 "개발 중 스펙 변경"을 막아준다.
우선순위 기준
| 우선순위 | 의미 | 기획 요구사항 |
|---|---|---|
| P0 | 다음 사이클 필수 | PRD, 디자인 필수 |
| P1 | 다음 사이클 선택 | PRD, 디자인 가능한 만큼 (70% 이상 완료 지향) |
| P2 | 추후 재검토 | 기획 보류 |
| P3 | 장기 백로그 | 기획 보류 |
P0/P1은 Commitment 단계에서 실제 포함 여부가 결정된다. P2/P3는 주기적으로 재검토해서 승격하거나 폐기한다.
핵심 관리 지표
모니터링하는 지표는 3개뿐이다:
- 계획 준수율: 이번 사이클에 계획한 스토리가 다 배포됐는가?
- 기술 부채 해결 비율: 안정화 작업에 리소스가 적절히 할당되고 있는가?
- Hot-track 빈도: 긴급 배포가 정기 사이클의 예측 가능성을 해치고 있지 않은가?
지표가 많으면 아무도 안 본다. 3개만 추적하되 매 사이클 회고에서 반드시 리뷰한다.
운영하면서 느낀 점
잘 되는 것:
- 개발팀이 기획을 기다리는 유휴 시간이 거의 없다
- 2주마다 예측 가능한 배포가 나간다는 안정감
- Hot-track 20% 버퍼 덕분에 긴급 대응에도 정기 사이클이 안 무너진다
아직 고민인 것:
- Discovery와 Delivery 간 핸드오프 품질이 들쑥날쑥하다. PRD의 완성도 차이가 크다
- 기술 부채 리소스 "강제 할당"이 바쁜 시기에 지켜지기 어렵다
- 소규모 팀이라 한 명이 빠져도 사이클 전체가 흔들린다
완벽한 프로세스는 없다. 중요한 건 2주마다 회고하면서 프로세스 자체를 개선한다는 점이다. 프로세스도 제품처럼 반복 개선의 대상이다.
AI 활용 포인트
이 프로세스 문서 자체를 Claude Code로 구조화했다. "우리 팀이 실제로 하고 있는 일"을 설명하면 Mermaid 다이어그램과 테이블로 시각화해주고, 빠진 단계나 모호한 기준을 지적해줘서 프로세스를 더 명확하게 다듬을 수 있었다.
Top comments (0)