← 이야기 목록
생산성·AI

📉 API가 죽었을 때 보여줄 값 — 제 백업 환율은 10% 어긋나 있었습니다

외부 API가 실패할 때를 대비해 코드에 환율을 박아뒀습니다. 오늘 실제 값과 대조해보니 어떤 통화는 10% 가까이 벌어져 있었어요. 낡지 않는 백업을 만드는 방법을 정리했습니다.

2026년 8월 25일

환율 계산기를 만들면서 외부 API를 씁니다. 무료로 열려 있는 곳이라 고맙게 쓰고 있는데, 언젠가 안 될 때를 대비해야 했어요. 그래서 코드에 환율을 몇 개 적어뒀습니다. API가 실패하면 이 값으로 계산하도록요. 몇 달 뒤 실제 값과 대조해봤습니다. 어떤 통화는 10% 가까이 벌어져 있었습니다.

백업값은 만드는 순간부터 낡기 시작합니다

코드에 박아둔 값은 이런 식이었습니다.

const FALLBACK_USD_RATES = {
  KRW: 1380.0,
  EUR: 0.92,
  CHF: 0.89,
  // ...
};

만들 때는 맞는 값이었어요. 문제는 환율이 매일 움직인다는 겁니다. 코드는 안 움직이고요. 오늘 API 응답과 나란히 놓아봤습니다.

통화코드의 백업값실제 값차이
CHF0.890.81254+9.5%
CNY7.256.7423+7.5%
EUR0.920.86386+6.5%
KRW13801410.07−2.1%
JPY158159.7−1.1%

원화는 2% 정도라 봐줄 만한데 스위스 프랑은 10%에 가깝습니다. 환율 계산기에서 10%면 작은 오차가 아니에요. 100만 원을 환전한다면 10만 원 차이니까요.

더 나쁜 건 이게 언제 기준인지 아무도 모른다는 점입니다. 주석에도 화면에도 날짜가 없었어요. 사용자는 물론이고 만든 저조차 대조해보기 전까지 몰랐습니다.

낡지 않는 백업은 코드 밖에 있습니다

해결책이 “값을 최신으로 고치기”라면 같은 일이 반복됩니다. 몇 달 뒤에 또 어긋나 있을 거고, 그때 또 고쳐야 하죠. 주기적으로 손봐야 유지되는 구조는 결국 안 하게 됩니다.

방향을 바꿔야 했습니다. 코드에 값을 적어두는 대신, 마지막으로 성공했던 응답을 재활용하는 겁니다.

원래 구조는 이랬어요.

API 호출 → 성공하면 45분간 캐시
        → 실패하면 코드에 박은 값

캐시가 45분 지나면 버립니다. 그런데 버릴 이유가 없어요. 만료된 캐시는 “지금 쓰기엔 오래됐다”는 뜻이지 “틀렸다”는 뜻이 아니거든요. 어제 받은 실제 환율이 몇 달 전에 박아둔 값보다 훨씬 낫습니다.

API 호출 → 성공하면 캐시 갱신
        → 실패하면 만료된 캐시라도 사용 (날짜 표시)
        → 캐시조차 없으면 그때만 코드의 값

이렇게 하면 쓸수록 백업이 좋아집니다. 한 번이라도 성공한 적이 있으면 그 값이 남아 있으니까요. 코드에 박은 값은 첫 방문에 API까지 실패하는 드문 경우에만 쓰입니다.

오래된 값을 쓴다면 반드시 말해줘야 합니다

여기서 중요한 게 하나 더 있습니다. 낡은 값을 쓰는 것 자체는 괜찮아요. 아무것도 못 보여주는 것보다 나으니까요. 문제는 낡았다는 사실을 숨길 때 생깁니다.

다행히 쓰던 API 응답에 날짜가 들어 있었습니다.

{
  "base": "USD",
  "date": "2026-08-18",
  "rates": { "KRW": 1410.07, ... }
}

date를 값과 함께 저장해두면 화면에 “8월 18일 기준”이라고 보여줄 수 있습니다. 사용자가 판단할 수 있게 되는 거죠. 오늘 환율이 급하면 다른 데서 확인하면 되고, 대략만 알면 되는 상황이면 그냥 쓰면 됩니다.

정보를 주는 것과 판단을 대신하는 것은 다릅니다. 낡은 값을 최신인 척 보여주면 판단할 기회를 뺏는 겁니다.

없는 값을 0으로 만들지 마세요

백업을 손보다가 옆에서 더 위험한 걸 발견했습니다.

return { rate: rates[to] || 0, isFallback };

응답에 해당 통화가 없으면 환율을 0으로 놓는 코드입니다. 언뜻 안전해 보이는데, 이러면 계산 결과가 0원이 됩니다. 그리고 “백업값을 쓰는 중”이라는 표시도 안 뜹니다. API가 정상 응답했으니까요.

사용자 눈에는 그냥 0원이 정답처럼 보입니다. 오류 화면이 뜨는 것보다 훨씬 나쁜 상황이에요. 틀렸다는 걸 알 수 없는 답이 가장 위험합니다.

값이 없으면 0으로 때우지 말고 실패로 처리해야 합니다. 그래야 백업 경로로 넘어가고, 사용자에게도 표시가 됩니다.

정리

외부 서비스에 기대는 기능을 만들 때 백업은 필요합니다. 다만 백업을 어떻게 만드느냐가 문제였어요.

세 줄로 남습니다. 코드에 값을 박아두면 그 순간부터 낡기 시작하니, 마지막 성공값을 재활용하는 쪽이 낫습니다. 낡은 값을 쓸 때는 언제 기준인지 함께 보여줘야 합니다. 그리고 없는 값을 0 같은 그럴듯한 숫자로 채우면, 틀렸다는 사실 자체가 숨겨집니다.

만들 때는 다 맞는 값이었습니다. 코드는 그대로인데 세상이 움직인 거죠. AI에게 코딩을 맡기며 배운 것에서도 비슷한 얘기를 했는데, 확인하지 않으면 모르는 건 여기서도 같았습니다.

다른 이야기 보기 홀로라도 도구 →