---
task_id: task-2163
type: context
scope: task
created: 2026-04-25
updated: 2026-04-25
status: in-progress
---

# 맥락 노트: task-2163

**task**: task-2163 (MediScan Phase 1-B: 분석 엔진 개발)

---

## 3 Step Why 자문

### 1st Why: "왜 이 설계가 필요한가?"
**A**: Phase 1-A에서 5종 PDF를 구조화된 JSON으로 파싱하는 기반이 완성되었으나, 파싱 데이터만으로는 비즈니스 가치가 없다. 고지의무 판별이라는 핵심 비즈니스 로직이 있어야 보험 언더라이팅 자동화가 가능하다. 분석 엔진은 파싱 데이터를 입력으로 받아 3개월/1년/5년 기준의 고지의무 항목을 자동 분류하는 것이 목표다.

### 2nd Why: "왜 6개 서브모듈 분리 구조가 최선인가?"
**B**: 단일 모듈로 모든 로직을 구현하면 (1) 테스트가 어려워지고 (2) 각 규칙(투약일수, 수술분류, 7일합산 등)이 독립적으로 변경될 수 있는데 결합도가 높아진다. 6개 서브모듈(disease_normalizer, obligation_classifier, medication_calculator, treatment_validator, surgery_classifier, seven_day_rule) + 오케스트레이터(engine.py) 구조는 각 모듈을 독립적으로 테스트/수정할 수 있고, 단일 책임 원칙을 따른다.

### 3rd Why: "왜 B가 다른 대안보다 나은가?"
**C**: 대안 1(단일 모듈): 코드가 1000줄 이상으로 비대해지고 테스트 격리 불가. 대안 2(클래스 상속 체계): 분석 규칙들은 상속 관계가 아닌 조합 관계이므로 상속은 부적절. 대안 3(플러그인 패턴): 현재 규모에서는 오버엔지니어링. 함수/클래스 기반 모듈 분리가 가장 적절한 복잡도 수준이다.

**결론**: A→B→C 논리적으로 일관. 설계 유지.

## 결정 근거

### 1. KCD 상병코드 데이터 접근
- 전체 KCD-8 코드베이스를 JSON으로 관리하는 대신, 6대질병 관련 핵심 코드만 하드코딩하여 초기 구현
- 이유: 전체 KCD 코드 수집은 별도 작업 필요. Phase 1-B에서는 분류 로직 검증에 집중
- 추후 외부 데이터 소스 연동 시 disease_normalizer만 교체하면 됨

### 2. 고지의무 기준
- 업계 표준 기준을 참고하되, 정확한 보험사별 기준표 미확보
- 일반적 기준 적용 + TODO 주석으로 기준 확정 시 교체 가능하도록 설계

### 3. 테스트 전략
- 단위 테스트: 각 서브모듈별 독립 테스트
- 통합 테스트: engine.py의 전체 파이프라인 테스트
- 테스트 데이터: AccidentBasicResult, DetailTreatmentResult 등 Pydantic 모델 인스턴스 직접 생성

## 참조 자료

- Phase 1-A 파서: `/home/jay/projects/MediScan/src/parsers/`
- 스키마 모델: `/home/jay/projects/MediScan/src/models/schemas.py`
- MHS V9.7 릴리즈 노트: `/home/jay/projects/MediScan/docs/MHS V9.7 Update Log 2026-03-20.txt`

## 주의사항

- Phase 1-A 코드 수정 금지 — analysis/ 모듈만 신규 추가
- docs/samples/ PDF 파일 git 커밋 금지 (.gitignore 확인)
- 기본진료내역 파서가 없으므로 자동차사고기본진료정보 데이터로 테스트