[백엔드] 외부 API 선택 이론적 정확도보다 실사용 제약

부제: 이론상 더 정확한 국내 API 대신 글로벌 API를 고른 이유

챗봇에 날씨 기능을 붙이며 어떤 날씨 API를 쓸지 골라야 했다.
후보는 둘이었다. 국내 기상청과 글로벌 날씨 API.

이론상 더 정확한 쪽

한국의 단기 강수 정확도만 놓고 보면, 이론상 국내 기상청이 우위일 수 있다.
"가장 정확한 걸 쓰면 되지 않나" 하는 게 첫 생각이었다.

그런데 종합해 보니 글로벌 API를 골랐다.
정확도 하나가 아니라 세 가지를 같이 봤기 때문이다.

• 요청 한도(quota): 실사용에서 얼마나 부를 수 있느냐. 정확해도 한도에 막히면 못 쓴다.
• 코드 복잡도: 붙이고 유지하는 비용.
• 확장성: 한국만이 아니라 해외 사용자까지 커버.

"가장 정확한 것"이 아니라 "실제로 감당 가능하고 넓게 쓰이는 것"을 택한 것이다.
국내 초단기실황을 선택적 보조로 얹는 건 나중 과제로 남겼다.

문서와 실측은 다르다

API를 붙이며 또 하나 배운 게 있다.
문서에 적힌 한계값을 그대로 믿으면 안 된다는 것.

예보 API 문서엔 "14~300일 범위 지원"이라고 적혀 있었다.
그런데 실제로 찔러 보니 달랐다.
D+13은 거부되고, D+14부터 D+365까지만 됐다.
경계값은 문서가 아니라 실측으로 잡아야 했다.

무료 티어로 시작하고, 되살릴 길을 남긴다

또 하나, 처음엔 무료 티어로 시작했다.
그러다 보니 무료 티어에 막힌 기능이 있었다.

장기 예보 조회는 무료 티어에 아예 권한이 없었다(요청하면 거부 코드가 떨어졌다).
그래서 그 도구를 목록에서 일시적으로 뺐다.
단기 예보도 유료 티어면 14일까지인데 무료 티어는 3일까지라, 상한을 3일로 낮췄다.

여기서 중요한 건 "그냥 지운" 게 아니라는 점이다.
빼면서 주석에 되살릴 지점을 정확히 남겼다.
"유료로 올리면 여기 한 줄, 저기 한 줄만 복구하면 된다"고.
지금은 무료로 감당 가능한 만큼만 쓰되, 업그레이드할 때 헤매지 않도록 길을 표시해 둔 것이다.

정리

• 외부 API를 이론적 정확도만 보고 고르면 실사용에서 막힌다
• quota(요청 한도)·코드 복잡도·확장성을 종합해 글로벌 API 채택 — "정확한 것"보다 "감당 가능하고 넓게 쓰이는 것"
• API 문서의 한계값(14~300일)과 실측(D+13 거부/D+14~365)이 달라, 경계는 실측으로 확정
• 무료 티어로 시작하되, 막힌 기능(장기예보·예보 일수)은 끄고 "유료 전환 시 복구 지점"을 주석에 명시

외부 API 선택은 이론적 정확도 경쟁이 아니다.
quota·복잡도·확장성 같은 실사용 제약이 실제 값어치를 가른다.
그리고 문서에 적힌 한계는 반드시 실측으로 확인해야 한다.