🌦️ 날씨 안내 콘텐츠 | 김병익

📌 프로젝트 개요

로봇이 설치된 건물 위치를 기준으로 오늘, 내일, 주간 예보와 대기질 정보를 안내하는 콘텐츠입니다.
기상청 예보 데이터를 화면에 표시하고, 같은 데이터로 음성 안내 문구를 조립해 함께 제공합니다.
고객사 건물마다 예보 격자와 대기질 측정소가 다르므로, 현장 기준 날씨가 나오도록 위치 정보를 설정합니다.
대기 화면, 메인 화면, 날씨 전용 화면 등 여러 위치에서 노출되므로, 배치별로 표시 범위를 달리하면서도 데이터 처리는 하나로 유지되도록 구성했습니다.
기획 단계부터 참여해 프론트엔드를 단독으로 담당했으며, UI/UX 설계부터 기능 개발과 성능 최적화까지 수행했습니다.
텍스트와 음성 안내는 국제화(i18n)를 위해 다국어를 지원하여, 다양한 언어 환경에서도 유연하게 대응합니다.

건물별 예보 격자와 대기질 측정소를 지정해, 로봇이 설치된 현장 기준의 날씨를 제공하도록 구성했습니다.
기상청 API 데이터를 오늘, 내일, 주간 세 영역으로 구분해 렌더링했습니다.
UI 컴포넌트를 기능 단위로 분리하고 상위 페이지에서 조합하도록 설계해, 여러 화면에 배치하면서도 재사용성과 확장성을 확보했습니다.
화면 진입마다 발생하던 API 호출을 미들웨어 캐싱으로 전환하고 갱신 주기를 12시간으로 설정해,
로봇 1대당 하루 30회에서 2회로 줄였습니다.
응답이 비정상일 때 마지막 정상 데이터를 localStorage에서 불러와 대체 표시하도록 처리했습니다.
가공이 끝난 데이터를 재사용하도록 바꿔 평균 로딩 시간을 1,600ms에서 700ms로 줄였습니다.
날씨 데이터를 조합해 TTS 음성 안내 문구를 생성하고, 입주사 명칭을 포함한 맞춤 안내를 제공했습니다.
i18n 다국어: ko-KR, en-US, zh-CN UI 텍스트와 음성 안내를 제공했습니다.
기상청 API 응답 규격과 필드 의미를 내부 문서로 정리해, 이후 다른 개발자가 응답 구조를 다시 파악하지 않아도 되도록 했습니다.

날씨 콘텐츠는 대기 화면, 메인 화면, 날씨 전용 화면 등 여러 위치에서 노출됐습니다.
같은 데이터를 쓰지만 배치마다 표시 범위와 동작이 달랐고, 화면별로 따로 만들면 중복이 계속 늘어나는 구조였습니다.
아토믹 디자인 패턴을 참고해 UI 컴포넌트를 기능 단위로 나누고 상위 페이지에서 조합하도록 설계했습니다.
이렇게 나눠두니 배치 위치가 늘어나도 데이터를 가져오고 가공하는 로직은 하나로 유지됐고,
화면마다 다른 부분만 조합을 바꿔 대응할 수 있었습니다.
기상청 API 응답 규격과 필드 의미는 내부 문서로 정리했습니다.
응답 필드명이 직관적이지 않아, 나중에 수정할 사람이 규격을 다시 해석하지 않도록 하기 위함이었습니다.

초기에는 날씨 화면에 진입할 때마다 API를 호출했습니다.
로봇 1대 기준 하루 평균 30회 정도가 발생했고, 화면 진입 때마다 응답을 기다려야 해서 첫 화면이 늦게 보여졌습니다.
더 큰 문제는 기상청 API 응답 오류였습니다. 주 1회 이상 비정상 응답이 발생했고,
값이 비면서 화면이 아예 뜨지 않는 런타임 오류로 이어졌습니다.
현장에서는 로봇 화면이 비어 있는 상태로 방치되므로 운영 문제로 이어졌습니다.

예보 데이터는 그렇게 자주 바뀌지 않는다는 점에서 출발했습니다.
기상청 동네예보는 3시간 간격으로 발표되지만, 로봇 안내 화면에서 오늘, 내일, 주간을 보여주는 용도라면
그 안에서 의미 있게 달라지지 않습니다.
매 진입마다 호출하는 대신 미들웨어의 캐싱 기능을 사용하고 갱신 주기를 12시간으로 잡았습니다.
TanStack Query에서 staleTime을 두는 것과 같은 개념으로, 오전과 오후 한 번씩이면 충분하다고 판단했습니다.
응답 오류에 대해서는 마지막으로 정상 수신한 데이터를 'localStorage'에 보관해두고,
새 데이터가 비정상이면 그 값으로 화면을 채우도록 했습니다.
사용자 입장에서는 조금 오래된 예보를 보게 되지만, 빈 화면을 보는 것보다 낫다고 판단했습니다.
결과적으로 API 호출은 하루 2회로 줄었고, 응답 이상으로 화면이 비는 오류는 발생하지 않았습니다.

기존 흐름은 화면 진입 -> API 호출 -> 미들웨어가 응답 수신 및 정제 -> 프론트 전달 ->
프론트에서 화면에 맞게 가공 -> 렌더링 순서였습니다.
모든 단계를 화면 진입 시점에 처음부터 다시 거쳤습니다.
캐싱을 적용하면서 가공까지 끝난 데이터를 저장해 재사용하도록 바꿔,
진입 시점에는 렌더링만 하면 되도록 했습니다.
개발자도구 네트워크 탭과 콘솔 타이머, 미들웨어가 렌더 완료 신호를 받는 시점 간격으로 확인한 결과
평균 1,600ms에서 700ms로 줄었습니다.