IR 자료: 마이그레이션 난이도 브리핑 (3축 전량 실측)

"Forge가 얼마나 복잡한 레거시를 다룰 수 있는가"를 증명하는 Before 자산.
지표는 전부 소스에서 자동 집계(추정·과장 없음).

- tools/gen_metrics.py: 소스 실측 → app/ui/metrics.js + index.html 인라인
  · 축A 규모: 파일 4,626 / 33만 LOC / EXEC SQL 23,742 / tpcall 989 /
    tpbegin 1,234 / UBF 46,904 / 테이블 75 / 카피북 2,207
  · 축B 자동변환 실패지점: ATMI·XA2PC(6단)·ECPG·UBF·카피북팬아웃·매크로
    각각 실측 카운트 + Java/Spring 이전이 어려운 이유
  · 축B 거래추적: ACQUIRE 6프로그램·6XA브랜치, PAY_APPROVE 5·5, CL_DAILY 6·6
    (프로그램→테이블쓰기→XA브랜치 트리)
  · 축C 레거시 인벤토리: acq_common.h 139프로그램 공유, 매크로 2,247,
    sqlca 수동분기 18,719, EXEC밀도 9.8/파일
- 포털 신규 화면 "마이그레이션 난이도"(AR0002, #mig): 위 3축을 한 화면에
- docs/MIGRATION_COMPLEXITY.md: 피치덱용 브리프 (실동작 증거 + 발견된 실결함 4건)
- README: IR 자료 안내 추가

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

README.md

@@ -8,6 +8,12 @@
 > 이 C/ATMI 시스템(2,000+본)을 Java Spring Boot로 전환하는 시나리오를 검증한다.
 > 컴파일만 되는 스텁이 아니라 **상용급 TP 미들웨어에서 실제로 도는** 시스템이라는 점이 핵심이다.
 
+> **IR·데모용 자료** — [`docs/MIGRATION_COMPLEXITY.md`](docs/MIGRATION_COMPLEXITY.md):
+> "Forge가 얼마나 복잡한 레거시를 다룰 수 있는가"를 3축(양적 규모·자동변환 실패지점·
+> 실전 레거시성)으로 **전량 실측**해 정리. 포털에서도 실시간 확인:
+> `#arch`(호출그래프 552노드·41 모듈간 경로), `#mig`(마이그레이션 난이도 브리핑).
+> 지표는 전부 소스에서 자동 집계된다(`tools/gen_callgraph.py`, `tools/gen_metrics.py`).
+
 ---
 
 ## 1. 스택