---
id: dual-track-agile
title: "Dual-Track Agile"
category: "10_Wiki/Topics"
status: "draft"
verification_status: "conceptual"
canonical_id: ""
aliases: ["Dual-Track Development", "Discovery and Delivery"]
duplicate_of: ""
source_trust_level: "B"
confidence_score: 0.85
created_at: 2026-06-12
updated_at: 2026-06-12
review_reason: ""
merge_history: []
tags: ["research", "Assumption Validation Loop", "Agile", "Product Discovery"]
raw_sources: ["NotebookLM Synthesis"]
applied_in: ["Rise8 Core Practices/Balanced Teams"]
github_commit: ""
---

# [[Dual-Track Agile]]

## 🎯 한 줄 통찰 (One-line insight)
지속적인 제품 탐색(Discovery)과 신속한 실행(Delivery)을 병행함으로써, '무엇을 만들 것인가'의 불확실성을 해소함과 동시에 '어떻게 만들 것인가'의 효율성을 극대화하는 애자일 운영 체계 [1-3].

## 🧠 핵심 개념 (Core concepts)
- **Continuous Discovery (지속적 탐색)**: 사용자 연구와 가설 검증을 프로젝트 초기에만 수행하는 것이 아니라, 매주 실행 트랙과 나란히 수행하여 로드맵을 실제 문제에 고정시킴 [1, 4].
- **Rapid Delivery (신속한 실행)**: 탐색 트랙에서 검증된 가설과 아이템을 실제 작동하는 제품으로 빠르게 구현하여 사용자에게 전달함 [2, 3].
- **Parallel Execution (병렬 실행)**: 탐색과 실행이 분리된 단계가 아닌 동시 병행되는 프로세스로 작동하며, 상호 피드백을 주고받음 [1, 5].
- **Cross-functional Involvement (교차 기능적 참여)**: 엔지니어와 디자이너가 고객 인터뷰에 참여하고, PM이 코드 리뷰에 참여하여 팀 전체가 공유된 맥락(Shared Context)을 가짐 [3, 5].

## 🧩 추출된 패턴 (Extracted patterns)
- **Validated Transition Pattern**: 탐색 트랙에서 고위험 가설을 검증(RAT 등)한 후에만 실행 트랙의 전체 개발 리소스를 투입함 [6, 7].
- **Unified Roadmap Alignment**: 고객 인용구, 실험 결과와 같은 탐색 결과물(Discovery Artifacts)을 개발 티켓(Delivery Tickets)에 직접 연결하여 개발자가 '왜' 이 기능을 만드는지 이해하게 함 [5].
- **Bi-Weekly Discovery Cadence**: 2주마다 정기적으로 가설을 맵핑하고 실험 데이터를 검토하는 리듬을 유지하여 탐색의 연속성을 보장함 [8].

## 📖 세부 내용 (Details)
Dual-Track Agile은 전통적인 제품 개발의 '벽'을 허무는 방식이다. 기존 방식에서는 PM이 요구사항을 정의하고 개발자가 이를 구현하는 순차적 구조였으나, 이 모델에서는 **탐색 트랙**과 **실행 트랙**이 동시에 회전한다 [3, 5].

1.  **탐색 트랙(Discovery Track)**:
    - 핵심 질문: "우리가 올바른 문제를 해결하고 있는가?", "이 솔루션이 가치를 제공하는가?" [9, 10].
    - 도구: 가설 맵핑([[Assumption Mapping]]), [[Riskiest Assumption Testing]], 가벼운 프로토타입 테스팅, 매주 수행되는 사용자 인터뷰 [1, 7, 8].
    - 결과물: 검증된 가설, 우선순위가 정의된 백로그, 실제 사용자 피드백 [11, 12].

2.  **실행 트랙(Delivery Track)**:
    - 핵심 질문: "어떻게 이를 안정적이고 확장 가능하게 만들 것인가?" [13, 14].
    - 도구: 스프린트 기반의 QA, CI/CD 자동화 배포 파이프라인, 기능 계측(Instrumentation) [15].
    - 결과물: 실제 제품 업데이트, 안정적인 서비스 운영, 사용 지표 데이터 [16, 17].

엔터프라이즈 환경에서는 기회 해결 트리(Opportunity Solution Tree)를 사용하여 여러 팀이 공유된 결과(Outcomes)를 중심으로 정렬되도록 하며, 경량 거버넌스를 통해 실험의 흐름을 유지한다 [2]. 특히 엔지니어가 분기당 최소 2회 이상의 고객 탐색 세션에 참여하도록 권장되는데, 이는 기술적 결정의 질을 높이는 결과를 낳는다 [14].

## ⚖️ 모순 및 업데이트 (Contradictions & updates)
- **'MVP'의 오용**: 단순히 '작은 제품'을 만드는 것을 MVP라고 오해하여 탐색 없이 실행 트랙에만 집중하는 경우가 많으나, 소스에서는 MVP를 '학습을 위한 가장 작은 실험'으로 재정의하고 탐색 트랙의 핵심 도구로 사용할 것을 강조함 [18-20].
- **속도와 구조의 균형**: "빠르게 배포하는 것(shipping fast)"이 "거칠게 배포하는 것(shipping rough)"을 의미하지 않으며, 훈련된 프로세스 없는 속도는 소음에 불과하다는 점이 지적됨 [21].

## 🛠️ 적용 사례 (Applied in summary)
- **Rise8 Core Practices**: 'Balanced Teams' 연습의 일환으로 'Dual-Track Development'가 명시되어 있으며, 지속적 개선 사이클과 병행하여 운영됨 [22].
- **14단계 검증 플로우**: 문제 인지(Stage 1)부터 출시 후 최적화(Stage 14)까지 탐색(Discovery)과 실험적 검증(Experimental Verification)이 순차적/반복적으로 연결되는 구체적 경로가 제시됨 [23].

## ✅ 검증 상태 및 신뢰도
- **상태:** draft
- **검증 단계:** conceptual (실제 기업 운영 가이드 및 방법론 소스에서 반복 확인됨)
- **출처 신뢰도:** B (전문 애자일 컨설팅 조직 Rise8 및 제품 관리 전문 교육 자료 기반)
- **중복 검사 결과:** 신규 생성 (New discovery)


## 🔗 관련 문서 링크 (Related document links)

### 상위/유사 개념

#### [제품 발견 엔진 (Discovery Engine)]
- [[Continuous Discovery]]
  - 연결 이유: Dual-Track의 한 축을 담당하는 핵심 활동임.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 매주 사용자와 소통하며 로드맵을 조정하는 구체적 방법론.
- [[Assumption Mapping]]
  - 연결 이유: 탐색 트랙에서 어떤 실험을 먼저 할지 결정하는 우선순위 도구임.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 리스크와 불확실성에 기반한 실험 설계.

#### [실행 및 검증 프레임워크]
- [[Build-Measure-Learn]]
  - 연결 이유: 두 트랙 사이를 흐르는 정보의 순환 구조를 설명함.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 실험 결과(Learn)가 어떻게 실제 개발(Build)로 이어지는지에 대한 피드백 루프.
- [[Riskiest Assumption Testing]]
  - 연결 이유: 실행 트랙에 과도한 코딩 비용을 쓰기 전 탐색 트랙에서 수행해야 할 '수술적' 실험 방식.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: MVP보다 더 가벼운 검증 기법의 적용.

### 심층 후속 질문 (Deeper Research Questions)
- 탐색 트랙의 결과가 실행 트랙의 스프린트 백로그로 전환되는 구체적인 'Hand-over' 기준은 무엇인가? [5]
- 엔지니어가 탐색 단계에 참여할 때 발생하는 실행 트랙의 일시적 속도 저하를 어떻게 조직적으로 정당화할 것인가? [14]
- 리소스가 극도로 제한된 1인 창업가나 소규모 팀에서도 두 트랙을 물리적으로 분리하여 운영하는 것이 효율적인가? [24, 25]
- Dual-Track Agile 환경에서 '성공'을 측정하기 위한 KPI는 탐색과 실행 각각에서 어떻게 달라져야 하는가? [17]
- 엔터프라이즈 환경에서 기존의 무거운 거버넌스(Stage-gate)를 어떻게 Dual-Track에 맞는 경량 구조로 변환할 것인가? [2, 26]

### 실무 적용 맥락 (Practical Application Contexts)
- **Implementation:** 탐색 트랙에서 클릭 가능한 모형(mockups)이나 Fake Door 테스트를 통해 기능을 선검증한 후 개발에 착수함 [1, 27].
- **System Design:** 로드맵 도구와 Jira 등 개발 티켓 도구를 통합하여, 모든 개발 작업이 어떤 탐색 가설(Discovery Goal)에서 기인했는지 추적 가능하게 설계함 [5, 28].
- **Operation / Maintenance:** 출시 후에는 실행 트랙에서 분석 도구(Mixpanel 등)를 통해 사용 지표를 모니터링하고, 이를 다시 탐색 트랙의 새로운 입력값으로 활용함 [23, 29].
- **Learning Path:** 엔지니어링 팀은 정기적으로 사용자의 목소리를 직접 듣는 'User Interview Participation' 과정을 학습 경로에 포함함 [14].

### 인접 주변 주제
- [[Kano Model]]
  - 확장 방향: 탐색 트랙에서 도출된 수많은 기능 아이디어 중 어떤 것이 '기본'이고 어떤 것이 '매력' 요소인지 분류할 때 활용 [30].
- [[Pivot or Persevere]]
  - 확장 방향: 두 트랙의 순환 결과, 현재의 방향성을 유지할지 아니면 근본적으로 수정할지 결정하는 전략적 의사결정 시점 정의 [31, 32].

## 📝 변경 이력 (Change history)
- 2026-06-12: Initial draft generated via Datacollector_MAC P-Reinforce engine.