acquire-core-x

forge-bot/acquire-core-x

Fork 0

Commit graph

Author	SHA1	Message	Date
hyeongwoo	438ae8992d	Wave G: 실제 매입사 경제모델 고도화 (딥리서치 갭분석 기반) 딥리서치(95 에이전트, OCC/Fed/Berlin Group 등 1차 출처, 검증된 9 finding)로 실제 카드 매입사 아키텍처를 조사(docs/GAP_ANALYSIS.md)하고, 최우선 갭 3개를 스키마+시드+런타임서비스+화면으로 메웠다. 메운 갭 (실제 매입사 핵심 메커니즘) 1. 수수료 3층 분해: 기존 flat MDR → interchange(발급사)+scheme fee(카드망)+ markup(매입사 수익). 실측 결과 interchange=MDR의 86% (리서치 "70~90%"와 일치). 2. 클리어링 ≠ 정산 분리: 승인·정산과 별도인 프레젠트먼트(클리어링) 단계 추가. 3. 발급사↔매입사 순액정산: BIN/ICA 기준 다자 순액(한국 BC카드 컨소시엄형). 4. 펀딩 항등식: 총매출−환불−채그백−수수료−리저브=입금 (2,924건 전부 항등 성립). 5. 채그백/분쟁 라이프사이클: FIRST_CB→REPRESENT→PRE_ARB→ARBITRATION 상태기계. 스키마 (db/schema.d/70-econ.sql, 96-econ-seed.sql) - 신규 9테이블: st_interchange_rate, st_scheme_fee, st_fee_component, cl_presentment, st_member_bank, st_net_settlement, st_reserve, st_merchant_funding, ac_dispute. - 기존 정산건 소급 분해(요율표 카드종류×채널 차등) + 순액정산 배치 + 펀딩 계산. - 시드 계산검증: 3층 항등식·펀딩 항등식 100% 성립(내가 채그백 일수중복 버그 1건 수정). 런타임 서비스 (전부 게이트웨이로 실호출 검증) - st: ST_FEEDECOMP(ic+sf+markup=mdr), ST_NETSETTLE(BIN별 순액), ST_FUNDING(항등식) - ac: ACQ_DISPUTE_OPEN, ACQ_DISPUTE_ADVANCE(상태기계-부적법 전이 거부), ACQ_PRESENT(클리어링). 각 120줄+, ECPG/XA 격리 규율 준수. 화면 (포털 AR0003 "정산 경제", #econ) - 수수료 3층 색상바 + 펀딩 항등식 워터폴 + 발급사별 순액정산 + 분쟁 라이프사이클 + 클리어링. 전부 실측 데이터 조회. 검증 - 통합 빌드 error 0, 도메인 재기동 5,879 서비스 AVAIL - 6개 신규 서비스 실호출 정상(수수료 3층 84=74+6+4, 상태기계 부적법 전이 거부) - 기존 6단 매입 체인 COMMIT OK 유지, 미결 2PC 0 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-22 14:03:35 +09:00
hyeongwoo	46ff41b633	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>	2026-07-22 13:18:40 +09:00

Author

SHA1

Message

Date

hyeongwoo

438ae8992d

Wave G: 실제 매입사 경제모델 고도화 (딥리서치 갭분석 기반)

딥리서치(95 에이전트, OCC/Fed/Berlin Group 등 1차 출처, 검증된 9 finding)로
실제 카드 매입사 아키텍처를 조사(docs/GAP_ANALYSIS.md)하고, 최우선 갭 3개를
스키마+시드+런타임서비스+화면으로 메웠다.

메운 갭 (실제 매입사 핵심 메커니즘)
1. 수수료 3층 분해: 기존 flat MDR → interchange(발급사)+scheme fee(카드망)+
   markup(매입사 수익). 실측 결과 interchange=MDR의 86% (리서치 "70~90%"와 일치).
2. 클리어링 ≠ 정산 분리: 승인·정산과 별도인 프레젠트먼트(클리어링) 단계 추가.
3. 발급사↔매입사 순액정산: BIN/ICA 기준 다자 순액(한국 BC카드 컨소시엄형).
4. 펀딩 항등식: 총매출−환불−채그백−수수료−리저브=입금 (2,924건 전부 항등 성립).
5. 채그백/분쟁 라이프사이클: FIRST_CB→REPRESENT→PRE_ARB→ARBITRATION 상태기계.

스키마 (db/schema.d/70-econ.sql, 96-econ-seed.sql)
- 신규 9테이블: st_interchange_rate, st_scheme_fee, st_fee_component, cl_presentment,
  st_member_bank, st_net_settlement, st_reserve, st_merchant_funding, ac_dispute.
- 기존 정산건 소급 분해(요율표 카드종류×채널 차등) + 순액정산 배치 + 펀딩 계산.
- 시드 계산검증: 3층 항등식·펀딩 항등식 100% 성립(내가 채그백 일수중복 버그 1건 수정).

런타임 서비스 (전부 게이트웨이로 실호출 검증)
- st: ST_FEEDECOMP(ic+sf+markup=mdr), ST_NETSETTLE(BIN별 순액), ST_FUNDING(항등식)
- ac: ACQ_DISPUTE_OPEN, ACQ_DISPUTE_ADVANCE(상태기계-부적법 전이 거부),
  ACQ_PRESENT(클리어링). 각 120줄+, ECPG/XA 격리 규율 준수.

화면 (포털 AR0003 "정산 경제", #econ)
- 수수료 3층 색상바 + 펀딩 항등식 워터폴 + 발급사별 순액정산 + 분쟁 라이프사이클
  + 클리어링. 전부 실측 데이터 조회.

검증
- 통합 빌드 error 0, 도메인 재기동 5,879 서비스 AVAIL
- 6개 신규 서비스 실호출 정상(수수료 3층 84=74+6+4, 상태기계 부적법 전이 거부)
- 기존 6단 매입 체인 COMMIT OK 유지, 미결 2PC 0

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

2026-07-22 14:03:35 +09:00

hyeongwoo

46ff41b633

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>

2026-07-22 13:18:40 +09:00

2 commits