FX 는 선을 안 넘어

"둘 다 '인터넷에서 온다' 는 이유로 backup 계획까지 같이 쓰는 건 아니잖아."

통화는 다른 도메인이야

Keep 는 미국 자산과 한국 자산이 섞인 두 포트폴리오를 추적해. 그래서 USD/KRW 환율은 곁다리가 아니라 일급 숫자야. 그리고 equity 와는 일부러 분리된 자기만의 provider 경계를 가져. USD/KRW 의 primary 는 Massive 의 일일 REST aggregate 고, 확인된 유일한 fallback 은 FRED 의 DEXKOUS 시리즈야. 미 연준이 내는 공식 일일 환율이지. 그리고 제일 중요한 규칙 하나. FX 는 Yahoo 로 절대 안 넘어가. Yahoo 가 equity 쪽 fallback 인데도 말이야. equity 의 fallback 목록과 FX 의 fallback 목록은 서로 다른 우주야.

왜 전역 fallback 체인 하나로 안 묶었을까

fallback 은 대체재가 진짜로 비교 가능한 도메인 안에서만 성립하거든. Yahoo 의 equity quote 는 Massive 의 equity quote 를 대신할 만해. 같은 종류의 데이터고 관례도 비슷하니까. 근데 환율은 종류가 다른 측정이야. equity fallback 로직이 슬쩍 건너와서, FX 용으로 검증된 적 없는 source 에서 통화 숫자를 집어 오게 두면 그게 바로 도메인 섞기야. FRED 의 DEXKOUS 는 FX source 로서 따로 검증을 거쳤어. 공식이고 권위 있는 일일 환율이니까. 경계가 말하는 건 하나야. FX 값은 FX 승인을 받은 source 에서만 온다. 끝.

fallback 의 범위는 네트워크가 아니라 도메인이야. '둘 다 온라인에 있다' 는 두 source 를 바꿔 써도 되는 이유가 못 돼. 유효한 fallback 은 바로 그 종류의 데이터에 대해 비교 가능하다고 검증받은 것뿐이야. 코드 경로가 우연히 닿는다는 이유로 주식 source 에서 환율을 집어 오는 도메인 월경이, 조용히 틀린 숫자가 스며드는 경로야.

이 규칙이 만들어 내는 모양

실패가 겹치면 아무거나 아무 걸로나 대체되는 엉킨 fallback 나무 대신, Keep 에는 도메인별로 깔끔한 경계 몇 개만 있어. equity 는 자기 primary 와 확인된 equity fallback 들을 갖고, FX 는 자기 primary 와 확인된 FX fallback 하나를 갖고, 몇몇 종목은 정책으로 정한 source 를 가져. 경계 하나하나가 머릿속에 담고 따져 볼 수 있을 만큼 작아. "이 USD/KRW 숫자, 어디서 왔을 수 있지?" 라는 질문의 답이 어깨 으쓱이 아니라 딱 두 항목짜리 목록인 거야.

기준이 되는 측정엔 편리함보다 권위가 우선이야. FRED DEXKOUS 가 FX fallback 으로 뽑힌 데는 공식 중앙은행 시리즈라는 이유가 커. 가족 자산의 반쪽을 다른 반쪽 통화로 환산하는 환율만큼 기초적인 값이라면, 마침 통화 숫자도 주는 제일 편한 API 가 아니라 구할 수 있는 가장 권위 있는 출처를 써야지.

Code

도메인별 fallback 테이블. 전역 체인 하나가 아니라·python

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

# FX 는 별도 테이블이야. 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

정말 종류가 다른 두 데이터를 가져오는 시스템을 상상해 봐. 온도와 주가라든지. 그리고 '다음 provider 시도' 식의 범용 fallback 이 걸려 있다고 치자. 한 도메인의 실패가, 다른 도메인용으로만 검증된 source 의 값을 내놓게 만드는 버그를 묘사해 봐. 그다음 도메인별 fallback 테이블로 다시 설계하고, 도메인 월경을 막는 invariant 을 한 문장으로 적어 봐.

Hint

전역 fallback 목록 하나가 끌리는 건 DRY 해 보여서야. 근데 여기선 '반복하지 마' 가 틀린 잣대야. 핵심이 바로 이 도메인들은 fallback 을 공유하면 안 된다는 거니까. 테이블을 따로 두는 건 중복이 아니라, 환율이 주식 API 에서 나오는 일을 막는 경계선이야.

통화는 다른 도메인이야

왜 전역 fallback 체인 하나로 안 묶었을까

이 규칙이 만들어 내는 모양

Code

External links

Exercise

Progress

댓글 0