FX 는 선을 절대 안 넘어

"둘 다 '인터넷' 에서 온다고 backup 계획을 공유하는 건 아냐."

통화는 다른 도메인이야

Keep 은 미국과 한국 가치가 섞인 두 포트폴리오를 추적하니, USD/KRW 환율은 나중 생각이 아니라 일급 숫자야. 그리고 equity 와 일부러 분리된 자기 provider 경계를 가져. Massive 의 일일 REST aggregate 가 USD/KRW 의 primary. 유일한 confirm 된 fallback 은 FRED 의 DEXKOUS 시리즈 — 미 연준의 공식 일일 환율. 그리고 가장 중요한 규칙: FX 는 Yahoo 로 절대 안 넘어가, Yahoo 가 equity 의 fallback 인데도. equity fallback 목록과 FX fallback 목록은 별개 우주야.

왜 하나의 전역 fallback 체인이 아냐?

fallback 은 대체가 진짜로 비교 가능한 도메인 안에서만 유효하니까. Yahoo 의 equity quote 는 Massive 의 equity quote 의 합리적 대역이야 — 같은 종류 데이터, 비슷한 관례. 근데 FX 환율은 다른 종류의 측정이고, equity fallback 로직이 건너와서 FX 로 검증 안 된 source 에서 통화 숫자를 잡게 두면 도메인을 섞는 거야. FRED 의 DEXKOUS 는 FX source 로 특별히 검증됐어 — 공식, 권위 있는 일일 환율. 경계가 말해: FX 값은 오직 FX-승인 source 에서만 올 수 있어, 끝.

fallback 은 네트워크가 아니라 도메인에 scope 돼. '둘 다 온라인에 있음' 은 두 source 가 교환 가능한 이유가 아냐. 유효한 fallback 은 그 특정 종류 데이터에 비교 가능하다고 검증된 거야. 도메인 넘는 대체 — 코드 경로가 우연히 닿았다고 주식 source 에서 통화 환율을 잡기 — 가 조용히 틀린 숫자가 들어오는 방법이야.

이게 만드는 모양

충분한 실패 하에 아무거나 아무거나 대체할 수 있는 엉킨 fallback 트리 하나 대신, Keep 은 깔끔한 도메인별 경계의 작은 집합을 가져: equity 는 primary 와 confirm 된 equity fallback 을; FX 는 primary 와 confirm 된 FX fallback 하나를; 특정 종목은 정책 source 를. 각 경계는 머릿속에 쥐고 추론할 만큼 작아. '이 USD/KRW 숫자는 어디서 왔을 수 있지?' 는 어깨 으쓱이 아니라 두 항목짜리 답이야.

base 측정엔 편함보다 권위가 이겨. FRED DEXKOUS 가 FX fallback 으로 뽑힌 건 부분적으로 공식 중앙은행 시리즈라서야 — 가족 부의 반쪽을 다른 반쪽으로 변환하는 환율만큼 근본적인 것엔, 우연히 통화 숫자도 반환하는 가장 편한 API 가 아니라 가장 권위 있는 source 를 원해.

Code

도메인별 fallback 테이블, 절대 하나의 전역 체인 아님·python

# equity 는 자기 검증된 fallback 을 가져.
EQUITY_SOURCES = {"primary": "massive", "fallbacks": ["yahoo", "stooq"]}

# FX 는 SEPARATE 테이블. Yahoo 는 여기 일부러 없어.
FX_SOURCES = {"primary": "massive_daily_rest", "fallbacks": ["fred_dexkous"]}

def resolve_fx(pair, *, confirmed_source=None):
    try:
        return fetch(FX_SOURCES["primary"], pair)
    except ProviderError:
        # FX 값은 오직 FX-승인 source 에서만 올 수 있어.
        # equity fallback 이 FX 를 내게 하는 코드 경로가 없어.
        if confirmed_source in FX_SOURCES["fallbacks"]:
            return fetch(confirmed_source, pair)
        raise FallbackConfirmationRequired(candidate="fred_dexkous")

Exercise

진짜로 다른 두 종류 데이터(가령 온도와 주가)를 fetch 하고 일반적 '다음 provider 시도' fallback 을 가진 시스템을 상상해. 한 도메인의 실패가 다른 도메인용으로만 검증된 source 에서 값을 내게 만드는 버그를 묘사해. 그다음 도메인별 fallback 테이블로 다시 설계하고, 도메인 넘는 누수를 막는 invariant 을 서술해.

Hint

하나의 전역 fallback 목록은 DRY 라서 유혹적이야. 근데 '반복하지 마' 는 여기서 틀린 축이야 — 핵심은 이 도메인들이 fallback 을 공유하면 안 된다는 거야. 별개 테이블은 중복이 아니라 통화 환율이 주식 API 에서 나오지 못하게 하는 경계야.

FX 는 선을 절대 안 넘어

통화는 다른 도메인이야

왜 하나의 전역 fallback 체인이 아냐?

이게 만드는 모양

Code

External links

Exercise

Progress

댓글 0