2nd/10_Wiki/Topics/Thinking & Reasoning/Data-Driven Hypothesis Development (DDHD).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
data-driven-hypothesis-development-(ddhd)	Data-Driven Hypothesis Development (DDHD)	10_Wiki/Topics	draft	conceptual				B	0.85	2026-05-24	2026-05-24			research hypothesis-driven thinking	NotebookLM Synthesis	Thoughtworks Legacy Modernization Project

Data-Driven Hypothesis Development (DDHD)

🎯 한 줄 통찰 (One-line insight)

불확실성이 높은 '알려지지 않은 미지(Unknown Unknowns)'의 문제를 해결하기 위해, 데이터를 기반으로 가설을 설정하고 소규모 실험을 통해 점진적으로 학습하며 가치를 전달하는 체계적인 접근 방식이다 [1-3].

🧠 핵심 개념 (Core concepts)

1. 데이터 기반 목표 정의 (Define the Goal Using Data): 문제를 데이터로 정의하여 명확성을 확보하고, 목표와 정렬된 메트릭을 사전에 설정한다 [3-5].
2. 실험으로서의 가설 (Hypothesize as Experiments): 제안된 해결책을 일련의 반복적인 실험으로 간주하며, 각 실험은 독립적이고 측정 가능한 결과와 기준을 가져야 한다 [3, 5, 6].
3. 빠른 피드백 루프 (Fast Feedback): 며칠 단위의 빠른 피드백을 위해 소규모의 구체적인 실험을 설계하며, 지속적 인도(CD)와 자동화된 테스트를 활용한다 [3, 7, 8].
4. 점진적 가치 전달 (Incremental Delivery of Value): 성공적인 실험뿐만 아니라 실패한 실험을 통해서도 시스템에 대한 이해를 높이고 의사결정의 명확성을 얻는 것을 가치로 간주한다 [2, 3, 9].

🧩 추출된 패턴 (Extracted patterns)

• Fail Fast 전략: 정확한 경로를 모를 때 다양한 경로를 빠르게 테스트하여 '정답'이 아닌 솔루션을 조기에 제거하고 최단 경로를 찾는다 [1, 6].
• 도메인 지식 재구축 (Knowledge Rebuilding): 도메인 지식 손실이 심각한 레거시 시스템에서 데이터를 통해 저비용, 저리스크 방식으로 지식을 다시 쌓는 패턴을 보인다 [2, 10].
• 중단 시점의 정의 (Stopping Criteria): 각 가설은 "언제 중단해야 하는가?" 즉, 정보가 충분하여 의사결정을 내릴 수 있는 시점이 언제인지를 명시해야 한다 [6].

📖 세부 내용 (Details)

• 문제 분류 및 적용: DDHD는 주로 '알려진 미지(Known Unknowns)'와 '알려지지 않은 미지(Unknown Unknowns)' 카테고리의 문제를 해결하는 데 효과적이다 [1, 11].
• 단계별 프로세스:
  • 1단계 (목표 정의): 핵심 메트릭을 추적하고 시각화할 수 있는 대시보드를 구축한다 [3, 5].
  • 2단계 (가설 수립): 한 가설은 하나 이상의 실험으로 구성되며, 성공 시 운영 환경(Production)에 반영하고 실패 시 교훈을 기록하고 공유한다 [3, 6].
  • 3단계 (피드백 루프): 격리된 테스트 환경에서 메트릭을 기준선(Baseline)과 비교하고, 검증된 경우 운영 환경에서 추가 테스트(A/B 테스트 등)를 수행한다 [3, 7, 8].
  • 4단계 (가치 전달): 유형의 시스템 개선, 문제에 대한 이해도 증진, 문서화 및 모니터링 강화를 통해 가치를 축적한다 [9].
• 주요 엔지니어링 실천법: 레거시 시스템의 경우 자동화된 회귀 테스트(Regression Testing) 수트 구축, 모니터링 및 관측성(Observability) 확보, 자동화된 성능 테스트 등이 빠른 피드백을 위해 필수적이다 [3, 8].
• 팀 역량 강화: 특정인만이 아닌 전체 팀원이 가설을 작성하고 실험을 정의하도록 권한을 부여하며, 쌍(Pairing) 프로그래밍을 통해 가설을 수립하는 것을 권장한다 [12].

⚖️ 모순 및 업데이트 (Contradictions & updates)

• 전면 재구축 vs. 점진적 실험: 고객은 흔히 전면적인 시스템 재구축(Complete Rebuild)을 해결책으로 제시하지만, DDHD는 시스템의 핵심 아키텍처가 견고하다면 점진적인 실험과 개선이 리스크를 줄이고 더 빠른 가치를 제공한다고 주장한다 [10, 13].
• 실패의 정의: DDHD에서는 가설이 기각되는 것을 실패로 보지 않고, 의사결정에 필요한 정보를 제공하는 성공적인 학습 과정으로 본다. 진짜 실패는 아무런 결론을 내릴 수 없는 실험이다 [9, 14].

🛠️ 적용 사례 (Applied in summary)

• Thoughtworks 레거시 시스템 현대화 프로젝트: 시스템 가시성이 낮고 도메인 지식이 부족하며 오랜 기간 방치된 레거시 시스템 프로젝트에 적용되었다 [13].
  • 수행 내용: 전면 재구축 대신 짧은 실험을 반복하며 점진적인 가치를 전달하고 도메인 지식을 재구축함 [10, 15].
  • 결과: 12~24개월이 소요될 수 있는 대규모 작업의 리스크를 제거하고 매주 가치를 전달함 [16].
• 실제 적용 패턴: 매주 진행 상황을 공유하는 쇼케이스(Showcase), 스토리 카드에 목표 포함, 실험 대시보드를 통한 시각화 등을 통해 비즈니스 이해관계자와 팀을 정렬시킴 [17, 18].

✅ 검증 상태 및 신뢰도

• 상태: draft
• 검증 단계: conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
• 출처 신뢰도: B (Official Documentation / Primary Source via NotebookLM)
• 중복 검사 결과: 신규 생성 (New discovery)

📝 변경 이력 (Change history)

• 2026-05-24: Initial draft generated via Datacollector_MAC P-Reinforce engine. [19]