공식 제공 페이지 기준으로 API는 4종인데, 프로젝트에서는 실패 범위와 정리 책임에 따라 5개 소스로 나눴다.
| 내부 소스 | 공식 공공데이터 | 확인하는 정보 |
|---|---|---|
| shortest_route | 최단경로이동정보 | 이동 시간, 환승, 구간별 경로 후보 |
| facility_info | 편의시설위치정보 | 엘리베이터·에스컬레이터 위치와 운행 구간 |
| elevator_status | 교통약자 이용시설 승강기 가동현황 | 시설별 가동 상태 |
| elevator_info | 교통약자이용정보 | 역·호선별 엘리베이터 상세 위치 |
| restroom | 교통약자이용정보 | 역·호선별 장애인화장실 위치 |
교통약자이용정보 API가 엘리베이터와 장애인화장실을 같이 주지만 내부 소스는 나눴다. 한쪽이 실패했을 때 다른 쪽의 조회 상태까지 같이 숨어버리면 안 되니까.
역명과 호선은 별칭과 운영기관까지 목록으로 관리한다. 모호하면 비슷한 역으로 확정하지 않고 한 번에 하나씩 되묻는다.
최단경로 API의 역 코드는 일반 역 번호와 값이 달라서 따로 관리하고, 실제 응답으로 확인한 코드만 쓴다. 이걸 같은 값으로 가정했다가 실제로 사고가 났다.
시설 상태는 소스마다 표현이 달라서 네 가지로 정리했다. 엘리베이터 위치와 가동 상태는 시설 번호가 같거나 이름이 정확히 하나만 일치할 때만 같은 시설로 묶고, 애매하면 상태를 붙이지 않고 미확인으로 둔다.
같은 빈 응답이라도 원인은 제각각이다. 조회는 성공했는데 해당이 없을 수도, 일부 소스만 실패했을 수도, 지원 범위 밖일 수도, 최신 조회가 실패해 이전 응답을 쓴 것일 수도 있다.
사용자에게 해야 하는 말이 전부 다르니까 서버도 다른 상태로 돌려준다.
공공데이터에 없다는 것과 현실에 없다는 것은 전혀 다른 말이다.
역 코드 문제로 생긴 실제 장애는 트러블슈팅과 운영 시나리오의 사례 1에 있다. 이 상태 구분을 실제로 쓰는 쪽은 근거 기반 판단과 MCP 계약의 판단 규칙이다.