2026년 Frankfurter API 대안: 개발자를 위한 솔직한 비교

Frankfurter API 대안을 찾고 있다면, 이미 그것으로 무언가를 출시해 본 경우가 대부분일 것입니다. Frankfurter는 한 세대의 사이드 프로젝트에게 사실상 기본값이 된 무료 환율 API입니다. API 키도, 가입도, 할당량도 없고, REST 인터페이스는 깔끔하며, 오픈소스 코드는 하루 오후면 다 읽을 수 있습니다. 그러다 무언가가 바뀝니다 — 컴플라이언스 질문, 주말에만 터지는 버그, 장중 환율이 필요한 고객 — 그리고 다른 선택지가 뭐가 있는지 궁금해지기 시작합니다.

이 가이드는 그 결정을 솔직하게 들여다봅니다. 2026년의 Frankfurter가 실제로 무엇을 하는지(대부분의 비교 글은 낡은 정보를 쓰고 있습니다), 팀을 떠나게 만드는 다섯 가지 구체적인 한계, 그리고 현실적인 세 갈래 길 — 직접 호스팅하기, 키 기반 상용 API로 옮기기, 하이브리드로 운영하기 — 을 다룹니다. 마지막에 마이그레이션 예제가 있습니다.

2026년의 Frankfurter는 실제로 어떤 서비스인가

"최고의 무료 통화 API" 모음 글은 거의 전부가 여전히 Frankfurter를 "ECB 환율, 약 30개 통화, 주말 데이터 없음"으로 설명합니다. 수년간 사실이었지만 더 이상은 정확하지 않습니다.

frankfurter.dev의 v2 API는 84개 중앙은행의 일일 환율을 추적하며 201개 통화를 다루고, 이력은 1948년까지 거슬러 올라갑니다. 상업적 이용도 실제로 무료이고, 인증이 필요 없으며, 월간·일간 할당량을 공표하지 않고, JSON 외에 CSV와 NDJSON 출력도 제공합니다. OpenAPI 명세와 llms.txt, 에이전트 워크플로용 MCP 서버도 있습니다. Docker로 직접 호스팅할 수도 있습니다.

이는 모음 글들이 인정하는 것보다 훨씬 탄탄한 제품이며, 분명히 말해 둘 가치가 있습니다. 상당수의 프로젝트에서 Frankfurter가 정답이며, 굳이 옮길 필요가 없습니다. 개인 재무 트래커, 통화 참고 페이지, 하루 한 번 환율을 확정하는 청구 도구, 10년치 월평균을 끌어오는 데이터 분석 노트북을 만든다면 Frankfurter는 그 일을 잘 해내고, 비용도 들지 않습니다.

이 글의 나머지는 그렇지 않은 경우에 관한 것입니다.

팀이 Frankfurter API 대안을 찾게 만드는 다섯 가지 한계

1. 일일 기준환율은 실시간 환율이 아니다

이것은 구조적인 한계이며 결함이 아닙니다. 데이터 출처가 원래 그런 것입니다. 중앙은행 기준환율은 영업일마다 한 번 공표됩니다. 예컨대 ECB는 매 영업일 중앙유럽시간 16:00경에 유로 기준환율을 발표합니다. Frankfurter는 그 숫자를 충실히 노출할 뿐입니다.

즉 09:00에 가져온 환율과 15:00에 가져온 환율은 같은 값입니다. 그 사이 시장이 1.2% 움직였더라도 말이죠. 단순 표시용 변환기라면 아무도 눈치채지 못합니다. 하지만 결제 페이지, 정산 금액 계산, 또는 고객이 당신의 숫자를 구글과 비교하는 자리에서는 그 지연이 곧 고객 문의가 됩니다.

하루 중에 움직이는 환율이 필요하다면 기준환율 소스가 아니라 시장 데이터 소스가 필요합니다. Finexly API는 시장 시간 동안 170개 이상의 통화를 매분 갱신합니다. 같은 것의 더 나은 버전이 아니라 다른 데이터 모델입니다. 이 구분은 환율 API는 데이터를 어디서 가져오는가에서 더 자세히 다룹니다.

2. 주말과 공휴일 행이 없다

중앙은행은 토요일, 일요일, 국경일에 공표하지 않습니다. 그래서 2026-08-23을 조회하면 쓸 만한 값이 나오지 않고, 한 달치 시계열은 31행이 아니라 약 21행입니다.

모든 팀이 똑같은 방식으로 걸려 넘어집니다. 야간 작업이 일요일에 돌고, 비어 있거나 어긋난 결과를 받아, 죽거나 — 훨씬 나쁘게는 — 원장에 조용히 null을 씁니다. 어떤 중앙은행 소스든 일일 환율 위에 시스템을 올린다면 명시적인 전진 채움 정책이 필요하고, 그것을 문서로 남겨야 합니다. "마지막 공표 환율 사용"과 "해당 행 건너뛰기"는 서로 다른 재무제표를 만들어 내기 때문입니다.

3. 혼합 환율은 공표 이후에도 바뀔 수 있다

기본적으로 Frankfurter는 기여하는 모든 제공처의 환율을 혼합합니다. 그 결과에 대해 자체 FAQ는 상쾌할 만큼 솔직합니다. 새 데이터가 들어오면서 마지막 소수 자리가 달라질 수 있고, 컴플라이언스 목적이라면 특정 제공처로 필터링해야 한다고 말이죠.

일반적인 용도로는 전혀 합리적인 설계입니다. 문제가 되는 것은 환율을 저장해 사용자에게 보여 준 뒤, 나중에 재조회 값과 대사할 때입니다. 감사인에게 설명하기 매우 어려운 미세한 차이를 발견하게 됩니다. Frankfurter 쪽 해법은 혼합값을 받아들이는 대신 providers=ECB(또는 당신을 규제하는 기관)를 전달하는 것입니다. 당신 시스템 쪽 해법은 거래 시점에 실제로 사용한 환율을 영속화하고 절대 다시 도출하지 않는 것입니다. 이 규칙은 어떤 제공처에도 적용되며, 환율과 세무 신고 가이드에서 다룹니다.

4. API 키가 없다는 것은 할당량도, 가시성도 없다는 뜻

"API 키 불필요"는 Frankfurter의 최고 장점이자 가장 과소평가된 위험입니다. 키가 없기 때문에:

• 애플리케이션별 할당량이 없습니다. 지금 이 순간 엉성한 루프로 두들기고 있는 누군가를 포함해, 인터넷 전체와 공용 속도 제한기를 공유합니다.
• 사용량 텔레메트리가 없습니다. 지난 화요일 호출량이 세 배가 됐다고 알려 줄 대시보드가 없습니다.
• 지원 관계가 없습니다. 상태 페이지와 GitHub 이슈 트래커는 있고, 이는 많은 무료 서비스보다 나은 편이지만, SLA도 없고 호출할 담당자도 없습니다.

프로젝트 자체의 안내도 명확합니다. 대용량 사용이라면 응답을 캐시하거나, 직접 호스팅하거나, 데이터셋을 직접 조회하라는 것입니다. 정직한 조언이고, 동시에 많은 팀이 Frankfurter API 대안을 검토하기 시작하는 지점이기도 합니다. 데이터가 틀려서가 아니라, 뒷받침하는 계약이 전혀 없는 프로덕션 의존성을 떠안았기 때문입니다.

5. 환산 엔드포인트가 없다

Frankfurter는 이를 의도적으로 문서화합니다. 환율을 가져와서 곱하라는 것이죠. 코드 세 줄입니다.

그런데 그 세 줄은 코드베이스 여섯 군데에서 조금씩 다르게 작성되고, 그중 한 곳에서는 곱해야 할 자리에서 나눕니다. 전용 convert 엔드포인트는 기술적 필수품이 아닙니다. 반올림과 방향 규칙의 구현을 정확히 하나로 유지하는 방법입니다. EUR→USD와 USD→EUR가 0.3% 어긋나는 버그를 내본 적이 있다면 왜 중요한지 아실 겁니다. 이 지뢰밭의 나머지는 통화 반올림과 소수 자릿수 가이드에서 다룹니다.

Frankfurter API 대안 비교

아래 무료 요금제 정보는 작성 시점에 각 제공사가 공개한 내용입니다. 확정하기 전에 직접 확인하세요. 무료 요금제는 문서보다 자주 바뀝니다.

두 가지가 눈에 띕니다. 첫째, 할당량에서 Frankfurter를 이길 곳은 없습니다. 애초에 할당량이 없기 때문입니다. 일일 환율에 대한 순수 호출량이 제약이라면, 답은 다른 곳에서 더 작은 할당량을 사는 것이 아니라 Frankfurter를 직접 호스팅하는 것입니다. 둘째, 유료 옵션은 같은 데이터를 예쁜 포장으로 파는 것이 아닙니다. 다른 갱신 주기와 지원 관계를 파는 것입니다. 둘 다 당신의 문제가 아니라면 이전은 다운그레이드입니다.

몇몇은 통화 API 비교와 실시간 환율 API 비교에서 나란히 분석해 두었습니다.

방법 1: Frankfurter를 직접 호스팅하기

가장 활용되지 않는 답입니다. Frankfurter는 Docker 이미지를 제공하며, 직접 돌리면 프로덕션 팀이 진짜로 걱정하는 두 가지 — 공용 속도 제한기와 통제권 부재 — 가 사라집니다.

docker run -d -p 8080:8080 --name frankfurter \
  lineofflight/frankfurter

얻는 것: 무제한 내부 호출, 스스로 책임지는 가용성, 제공처를 고정할 수 있는 능력. 떠안는 것: 컨테이너, 데이터베이스, 모니터링, 그리고 은행 휴일에 상류 수집이 깨진 것을 알아챌 사람. 이는 실제 비용입니다 — 다른 누군가가 이미 작성한 코드에 적용한, 우리의 자체 구축 대 구매 분석과 사실상 같은 논지입니다.

셀프 호스팅은 볼륨이 크고, 지연 요구가 엄격하며, 일일 기준환율로 정말 충분할 때 옳은 선택입니다. 장중 환율이 필요한 문제에는 전혀 도움이 되지 않습니다. 같은 일일 데이터의 자체 사본을 돌리는 것뿐이니까요.

방법 2: 장중 환율을 제공하는 키 기반 API로 옮기기

여기까지 온 이유가 환율의 신선도, 이색 통화쌍 커버리지, 또는 이메일에 답해 줄 사람의 필요라면, 정직한 답은 키 기반 상용 API입니다.

같은 작업을 양쪽에서 보면 이렇습니다. 먼저 Frankfurter:

curl "https://api.frankfurter.dev/v2/rate/USD/EUR"

그리고 Finexly의 대응:

curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://api.finexly.com/v1/rate?from=USD&to=EUR"

{ "pair": "USD_EUR", "rate": 0.9215 }

엔드포인트 매핑

형태가 가장 크게 달라지는 것은 다중 통화쌍 호출입니다. Frankfurter는 기준 통화 하나에 상대 통화 목록을 쓰지만, Finexly는 명시적인 BASE_QUOTE 쌍의 목록을 받습니다. 덕분에 교차 계산 없이 USD_EUR와 GBP_JPY를 한 요청에서 가져올 수 있습니다.

마이그레이션 래퍼

새 클라이언트를 코드베이스 곳곳에 흩뿌리지 마세요. 둘을 하나의 인터페이스 뒤에 두면, 되돌리는 일이 설정 변경으로 끝납니다:

import os
import requests

FINEXLY_KEY = os.environ["FINEXLY_API_KEY"]

def get_rate(base: str, quote: str, provider: str = "finexly") -> float:
    """Return the mid-market rate for base->quote."""
    if provider == "frankfurter":
        r = requests.get(
            f"https://api.frankfurter.dev/v2/rate/{base}/{quote}",
            timeout=5,
        )
        r.raise_for_status()
        return float(r.json()["rate"])

    r = requests.get(
        "https://api.finexly.com/v1/rate",
        params={"from": base, "to": quote},
        headers={"Authorization": f"Bearer {FINEXLY_KEY}"},
        timeout=5,
    )
    r.raise_for_status()
    return float(r.json()["rate"])

print(get_rate("USD", "EUR"))

따라 할 만한 두 가지 세부 사항. API 키는 환경 변수에서 가져오고 소스에는 절대 넣지 않습니다 — Finexly 문서는 쿼리 파라미터로 전달한 키가 서버 접근 로그와 HTTP Referrer 헤더를 통해 유출될 수 있다고 지적하므로, 프로덕션 경로는 Authorization 헤더입니다. 그리고 모든 호출에 타임아웃을 둡니다. 대다수 HTTP 클라이언트의 기본값이 "영원히 기다리기"이기 때문입니다.

응답 헤더의 X-RateLimit-Limit, X-RateLimit-Used, X-RateLimit-Units를 지켜보면 할당량 소비를 실시간으로 확인할 수 있습니다. 이 텔레메트리야말로 인증 없는 API에서는 얻을 수 없는 것이며, 종종 팀이 옮기는 진짜 이유가 됩니다.

방법 3: 하이브리드 — 하나는 캐시하고, 다른 하나로 폴백

대부분의 프로덕션 시스템이 수렴하는 패턴입니다. 주 제공처를 쓰고, 공격적으로 캐시하며, 무료 무인증 API를 최후의 보루로 남겨 둡니다:

const CACHE = new Map();
const TTL_MS = 60_000;

async function getRate(base, quote) {
  const key = `${base}_${quote}`;
  const hit = CACHE.get(key);
  if (hit && Date.now() - hit.at < TTL_MS) return hit.rate;

  let rate;
  try {
    const res = await fetch(
      `https://api.finexly.com/v1/rate?from=${base}&to=${quote}`,
      { headers: { Authorization: `Bearer ${process.env.FINEXLY_API_KEY}` } }
    );
    if (!res.ok) throw new Error(`HTTP ${res.status}`);
    rate = (await res.json()).rate;
  } catch (err) {
    // Degrade to daily reference rates rather than failing the request
    const res = await fetch(`https://api.frankfurter.dev/v2/rate/${base}/${quote}`);
    rate = (await res.json()).rate;
  }

  CACHE.set(key, { rate, at: Date.now() });
  return rate;
}

월 1,000회 무료 요금제에 60초 캐시를 얹으면 소규모 앱은 넉넉히 감당됩니다. 호출량이 트래픽이 아니라 시간의 함수가 되기 때문입니다. 폴백 응답에는 로그로 표시를 남기세요. 어제 환율로 조용히 저하된 상태가 일주일간 발견되지 않는 일을 막아 줍니다. TTL 선택과 재시도 동작은 캐싱 및 오류 처리 가이드에 더 자세히 있습니다.

결정 체크리스트

위에서부터 훑어 내려가며 첫 "예"에서 멈추세요:

1. 거래일 중에 환율이 바뀌어야 하는가? → 기준환율이 아니라 시장 데이터 API가 필요합니다.
2. 규제 대상이거나 감사 대상 흐름인가? → 특정 제공처를 고정하고, 사용한 환율을 저장하고, 절대 다시 도출하지 마세요.
3. 호출량은 많지만 일일 환율로 충분한가? → Frankfurter를 직접 호스팅하세요.
4. 장애가 났을 때 응답해 줄 사람이 필요한가? → 키와 지원 등급이 있는 요금제가 필요합니다.
5. 위 어느 것도 아닌가? → Frankfurter에 머무르세요. 캐시하고, 주말 공백을 처리하고, 시간은 다른 데 쓰세요.

Frankfurter API 대안을 찾아 나선 팀 대부분은 5단계에서, 진짜 문제가 빠진 캐시와 처리되지 않은 일요일이었음을 알게 됩니다.

자주 묻는 질문

Frankfurter API는 정말 상업적으로 무료인가요? 네. 프로젝트는 상업적 이용도 무료이며 월간·일간 할당량이 없다고 밝히고 있습니다. 요청 제한은 남용 방지 목적일 뿐입니다. 대신 SLA와 지원 계약이 없으므로 위험은 이용자 몫입니다.

Frankfurter는 ECB 환율만 제공하나요? 더 이상 아닙니다. v2 API는 84개 중앙은행, 201개 통화의 데이터를 혼합하며, providers 파라미터로 단일 출처로 좁힐 수 있습니다. 널리 퍼진 "ECB만, 30개 통화"라는 설명은 구버전 이야기입니다.

왜 Frankfurter는 주말에 데이터를 반환하지 않나요? 중앙은행이 비영업일에 기준환율을 공표하지 않기 때문입니다. 중앙은행 데이터 위에 만든 API는 모두 같은 공백을 갖습니다. 마지막 공표 환율로 전진 채움을 하거나, 연속적으로 호가되는 시장 데이터 소스를 쓰면 됩니다.

Frankfurter의 가장 좋은 무료 대안은 무엇인가요? "무료"가 무엇을 사 줘야 하는지에 달렸습니다. 무제한 일일 환율이라면 Frankfurter를 이길 것이 없으니 직접 호스팅하세요. 장중 갱신과 진짜 API 키가 있는 무료 요금제를 원한다면, Finexly 무료 플랜이 170개 이상 통화에 대해 월 1,000회를 제공합니다. 더 넓은 지형은 무료 통화 API 가이드를 참고하세요.

Frankfurter와 유료 API를 함께 쓸 수 있나요? 가능하고, 합리적인 아키텍처입니다. 평상시 트래픽은 주 제공처로 보내고 오류 시 Frankfurter로 폴백하면 됩니다. 위 하이브리드 예제와 같습니다. 다만 폴백 응답은 반드시 로깅하세요. 신선도 보장이 다르기 때문입니다.

시작하기

만들고 있는 것에 일일 기준환율로 충분하다면 Frankfurter에 머무르세요. 좋은 프로젝트이고 비용도 들지 않습니다. 하루 중에 움직이는 환율, 중앙은행 기준 집합을 넘어서는 커버리지, 또는 실제로 모니터링할 수 있는 사용량 헤더가 필요하다면 무료 Finexly API 키를 받으세요 — 신용카드는 필요 없습니다. 170개 이상 통화에 대해 월 1,000회로 시작해 성장에 맞춰 업그레이드하거나, 먼저 요금 페이지에서 등급을 비교해 보세요.