📉 API가 죽었을 때 보여줄 값 — 제 백업 환율은 10% 어긋나 있었습니다
외부 API가 실패할 때를 대비해 코드에 환율을 박아뒀습니다. 오늘 실제 값과 대조해보니 어떤 통화는 10% 가까이 벌어져 있었어요. 낡지 않는 백업을 만드는 방법을 정리했습니다.
2026년 8월 25일환율 계산기를 만들면서 외부 API를 씁니다. 무료로 열려 있는 곳이라 고맙게 쓰고 있는데, 언젠가 안 될 때를 대비해야 했어요. 그래서 코드에 환율을 몇 개 적어뒀습니다. API가 실패하면 이 값으로 계산하도록요. 몇 달 뒤 실제 값과 대조해봤습니다. 어떤 통화는 10% 가까이 벌어져 있었습니다.
백업값은 만드는 순간부터 낡기 시작합니다
코드에 박아둔 값은 이런 식이었습니다.
const FALLBACK_USD_RATES = {
KRW: 1380.0,
EUR: 0.92,
CHF: 0.89,
// ...
};
만들 때는 맞는 값이었어요. 문제는 환율이 매일 움직인다는 겁니다. 코드는 안 움직이고요. 오늘 API 응답과 나란히 놓아봤습니다.
| 통화 | 코드의 백업값 | 실제 값 | 차이 |
|---|---|---|---|
| CHF | 0.89 | 0.81254 | +9.5% |
| CNY | 7.25 | 6.7423 | +7.5% |
| EUR | 0.92 | 0.86386 | +6.5% |
| KRW | 1380 | 1410.07 | −2.1% |
| JPY | 158 | 159.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에게 코딩을 맡기며 배운 것에서도 비슷한 얘기를 했는데, 확인하지 않으면 모르는 건 여기서도 같았습니다.