외부 API 가정에 맞춰 설계하기: 무료 환율 API에서 배운 교훈

Source: Dev.to

프로젝트 개요

저는 YenUp이라는 애플리케이션을 개발하고 배포했습니다. 이 앱은 오늘의 환율을 어제와 비교하고 결과에 따라 알림을 전송합니다. 프로젝트를 간단하고 무료로 유지하기 위해 Frankfurter API를 데이터 소스로 사용했습니다.

완료했다는 사실에 기뻤습니다. 하지만 곧 받은 알림에 문제가 있음을 발견했습니다.

알림은 오늘의 환율이 어제보다 좋을 때만 전송되어야 했습니다. 엔드‑투‑엔드 전달 파이프라인을 디버깅하기 위해, 환율이 변하지 않아도 Slack 메시지를 강제로 보내는 notification=true 플래그를 추가했습니다.

실제로 받은 알림은 다음과 같았습니다:

Test Notification (forced). CAD/JPY: Yesterday 114.4300 -> Today 114.4300

처음에는 내 구현에 버그가 있다고 의심했습니다. 로직을 검토하고 비교 코드를 다시 확인했습니다. 결국 문제는 내 코드가 아니라 API에 대한 내 가정에 있음을 깨달았습니다.

이 현상은 내 자체 폴백 로직에 의해 더욱 확대되었습니다. 특정 날짜에 데이터가 없을 경우(예: 주말이나 일일 업데이트 이전) 구현이 latest 엔드포인트로 폴백하도록 했습니다. 그 결과 영업일이 아닌 날에도 동일한 기본 환율이 사용될 수 있었습니다.

배운 점

실제 문제는 API 자체의 동작이 아니라 그에 대한 내 가정이었습니다. 저는 “오늘”과 “어제”를 달력 날짜라고 가정하고 로직을 설계했지만, 외부 API는 자체 비즈니스 규칙에 따라 이러한 용어를 정의합니다. 이는 제품이 데이터를 사용하는 방식과 일치하지 않을 수 있습니다.

앞으로 할 일

이를 바탕으로 비교 로직을 달력일이 아닌 영업일을 기준으로 변경하는 방안을 고려하고 있습니다. 아직 완전히 구현하지는 않았는데, 통화마다 영업일을 일관되게 정의하는 것이 추가적인 복잡성을 초래하기 때문입니다.

이 작은 버그는 제 가정을 재검토하게 만들었고, 외부 API와 비즈니스 규칙에 대한 사고 방식을 바꾸게 했습니다. 앞으로도 프로젝트를 통해 계속 배우고 싶습니다.