기상청 API의 최대 문제점은 수시로 서버가 맛이 가거나 응답이 느리다는 것이지만 (이 글을 쓰기 며칠 전에도 3일간 예보, 실황 API가 응답을 안했다. 주말 내내 안되다가 월요일 출근시간 되니까 고치더라.) 일단 제외하고, API의 구조 자체가 얼마나 개발하기 불편하고 지들 편하게만 만들어졌는지 적어 보겠다.

기상청 API 허브 (https://apihub.kma.go.kr/) 2024년 08월 예특보API 기준.

API가 쓸데없이 많다

내가 3일 후 부터 10일이내 예보 데이터가 필요하면? 중기예보 API를 써야 한다. 오늘부터 3일 이내 예보 데이터가 필요하면? 동네 단기예보 API를 써야 한다. 오늘 특정시간대 예보가 필요하면 초단기예보 API를 써야한다. 지금 현황을 알고 싶으면 초단기실황 API. 거기에 단기개황, 단기육상예보, 단기혜상예보, 기상개황, 예보버전조회, 동네예보분포 등등 단기 예보만 이 정도이고, 중기예보와 특보까지 치면 목적과 지역에 맞춰 써야 하는 예보가 20개 가까이 된다. (중기예보도 강우예보를 확인하는 육상/해상 예보와 기온예보로 분리되어 있다)

그냥 내 위치랑 뭐 필요한지 요청하면 해당하는 자료 주면 안되냐?

저 많은 API가 쓰는 좌표계가 달라

일단 API가 많아도, 여러번 필요한 것들 여러번 호출하면 되잖아? 좀 느리겠지만. 글쎄.

일단 동네예보는 “동네예보 격자 번호”라는 것을 사용한다. 이건 다행히 위경도를 변환하는 API를 제공하고, 인터넷 검색하면 변환하는 함수도 있다. 육상예보와 중기예보는 예보구역코드라는걸 쓴다. 그런데 API별로 예보구역코드가 다르다. 육상예보에서 서울은 11B00000이지만, 기온예보에서는 서울이 11B10101인 식이다. 동네예보 통보문는 발표관서코드를 알아야 한다. 기상특보는 특보구역코드를 계산해서 써야한다. 다른 자료들도 대부분 위치가 아니라 그 자료를 만든 측정소 코드로 요청하는 식이다.

일부 구역코드는 위경도에서 변환이 안되고 서울이면 서울식으로 텍스트 매칭해서 써야 한다.

그냥 위경도로 요청하면 니들이 변환해서 자료 주면 안되니?

자료 만든 시간도 알아야 해

그걸로 끝이 아니다. 일부 자료는 매시간 자료를 만드는게 아니라서 조회할 때 몇시에 만든 자료를 줄지도 설정해야 한다. 예를 들어 가장 자주 쓰게되는 동네 단기 예보는 02시, 05시, 08시, 11시, 14시, 17시, 20시, 23시 이렇게 8번 갱신되는데, 예를 들어 19시에는 17시것을 조회해야 한다. 값을 안넣거나 다른것을 넣으면 에러난다. 물론 이런건 매뉴얼이 있지만.

시간 안넣으면 최신값을 주는 API도 있는데 아닌 것도 많다.

그 외에도 많아

API마다 엑셀과 워드로 매뉴얼이 있기는 한데, 매뉴얼과 다른 사양을 가진 경우도 있고 (갱신 안한 듯), 비슷비슷한 API의 목적이 매뉴얼에도 적혀 있지 않아서 하나하나 API 사용신청하고 써봐야 알 수가 있다.

매뉴얼에 기상 용어도 정리가 안되어 있다. 특보API에 명령 변경이라는 값이 나오는데 이게 특보 등급이나 시간이 변경된 것이라는 걸 한참 돌려봐야 알 수 있다. 기상청 API를 쓰면 용어 정도는 아는 기상전문가라고 생각해서인가.

API의 응답도 딱히 자료가 쓰기 좋기 정리되어 있지 않다. 기온, 풍속, 습도 등등 값이 하나하나 나열만 되어 있다. 하루치 데이터만 해도 24시간 x 측정값들 수로 수백줄이 된다. 이틀 후 13시의 습도를 찾으려면 원하는 값이 나올 때까지 루프 돌리는 수밖에 없다.

날씨 앱 만들려면

날씨 앱 하나 만든다고 가정하자.

일단 현재 날씨를 확인해야겠지? 위경도를 동네예보 격자 번호로 변환한다음 초단기실황 API를 사용한다.

폭염특보가 있는지 표시해야겠지? AWS가 속한 특보구역 코드API를 사용해 현재 위경도가 속한 특보구역 코드를 알아낸 후, 특보현황 조회 API를 사용해야 한다.

날씨앱에 있는 오늘 시간별 날씨를 표시해야 한다. 현재 날씨에서 사용한 동네예보 격자 번호로 초단기예보API나 단기예보API를 사용한다.

내일부터 일주일이나 10일 이내의 날씨도 나와야 한다. 요즘 날씨앱에는 기본이니까. 중기예보 API를 사용해야 하는데, 중기예보 예보구역을 확인한 후(이거 위경도에서 바로 변환이 안된다. 다른건 행정구역에서 대충 변환하면 되는데 강원영서와 영동 구별이 어렵다), 중기예보 육상예보 API에서 강우를 확인하고, 중기기온 예보구역을 확인하고(앞에서 말했듯 육상예보용과 코드가 다르다) 중기예보 기온예보API에서 온도를 확인해야 한다.

날씨앱 첫화면을 띄우기 위해 쓸 기상청 API가 이렇게 6번이 넘는다. 여기에 지오코딩이나 미세먼지 API같은 기상청 외의 API까지 쓰려면 최적화가 얼마나 힘들려나.

비교를 해보자면 Open-Meteo 같은 해외 서비스 API는 저걸 1번의 쿼리로 모든 정보를 가져온다. 위치 확인에 필요한 값도 위경도 뿐이다.

아마도

아마도 API를 개발한 개발자도, 워낙 데이터 소스가 ㅈ같고, 그거 편하게 만든다고 보상이 있는 것도 아니니 그냥 주는 데이터 형식 그대로 조회만 하게 API를 만들었을 것이다. 하지만 정말…그게 최선일까?

저런 API가지고도 기상청 예보 조회를 잘하는 날씨 앱들은 개발자들이 존경스럽다.