KRX 수집 코드 위치 선택 (BE vs ML)
상태
승인
후보군
| 방안 | 설명 |
|---|
| BE(Kotlin) 수집 | backend/marketflow에 KRX Gateway·Repository, MySQL 영속화. ml은 read API 소비 |
| ML(Python) 수집 | ml/에서 스크래핑+스코어링 일체, 자체 저장 |
결정
BE(Kotlin)에서 수집·영속화하고, ml 추천 스코어링은 BE read API로 소비한다.
결정 이유
- 토스 외부 호출 게이트웨이가 모두
backend/.../infrastructure/toss에 있다. KRX도 동일하게 infrastructure/krx 어댑터로 배치하면 외부 연동 책임이 BE에 일관된다.
- 신호 영속화가 BE signal_snapshots로, ml TtlCache 제거로 ml은 stateless 방향이다. KRX 영속화를 ml에 두면 이 방향과 충돌한다.
- 영속화·트랜잭션·멱등 upsert는 JPA+MySQL 기반 BE가 강점이다.
검토 대안
| 방안 | 기각 이유 |
|---|
| ML 수집+자체 저장 | ml stateless 방향 위배, 영속화 이원화로 운영 복잡 |
트레이드 오프
| 구분 | 내용 |
|---|
| 득 | 외부 연동·영속화 책임 BE 집중, ml stateless 유지, 기존 ADR 일관 |
| 실 | ml이 팩터를 쓰려면 BE read API 1-hop 추가 (네트워크 비용) |