2nd/10_Wiki/Topics/Topic_Agent/Dual-Track Agile.md

id, title, category, status, verification_status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, created_at, updated_at, review_reason, merge_history, tags, raw_sources, applied_in, github_commit

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

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.