diff --git a/journey/plans/251218_langgraph_1.0_upgrade_plan.md b/journey/plans/251218_langgraph_1.0_upgrade_plan.md
index fa7d9b0..6a855e3 100644
--- a/journey/plans/251218_langgraph_1.0_upgrade_plan.md
+++ b/journey/plans/251218_langgraph_1.0_upgrade_plan.md
@@ -36,6 +36,36 @@
 - **개선**: 1.0의 자동 상태 관리 활용
 - **효과**: 서버 재시작 시 콜드메일 처리 중단 지점부터 자동 재개
 
+## 워크플로우 통합 설계
+
+### 설계 고려사항
+
+**문제**: 콜드메일과 프론트엔드 IR Deck 분석이 서로 다른 진입점을 가짐
+- 콜드메일: 스케줄러 → `coldmail_workflow.py`
+- 프론트엔드: REST API → `ir_deck.py` (직접 `IRDeckAnalyzer().analyze()` 호출)
+
+**고려한 방법**:
+1. **라우터 노드 통합**: 단일 워크플로우에서 라우터 노드로 분기
+2. **서브그래프 통합**: 공통 분석 부분을 서브그래프로 만들어 재사용
+3. **별도 워크플로우 + 공통 함수**: 각각 독립 워크플로우, 공통 로직은 함수로 재사용
+
+### 최종 결정
+
+**2개 워크플로우 + 공통 함수 재사용** 방식 채택
+
+| 방식 | 장점 | 단점 | 결정 |
+|------|------|------|------|
+| 라우터 통합 | 단일 워크플로우 관리 | 진입점이 달라 복잡도 증가 | ❌ |
+| 서브그래프 | 공통 부분 재사용 | 여전히 2개 워크플로우 필요 | ⚠️ |
+| 별도 워크플로우 | 단순, 유지보수 용이 | 공통 로직 중복 가능 | ✅ |
+
+**구조**:
+- **워크플로우 1**: 콜드메일 처리 (기존 + HITL 패턴)
+- **워크플로우 2**: 프론트엔드 IR Deck 분석 (신규, HITL 없음)
+- **공통 함수**: `extract_ir_metrics()`, `evaluate_ir_deck()`, `save_evaluation()`
+
+**이유**: 진입점이 다르면 별도 워크플로우로 관리하는 것이 단순하고 유지보수에 유리함
+
 ## 마이그레이션 전략
 
 1. **의존성 업데이트**: `requirements.txt`에서 `langgraph==0.6.10` → `langgraph>=1.0.0`