교통약자 대상 경로 안내 — 개인화 ETA · 접근성 데이터 통합

배리어프리 길찾기 (My ETA)

기간: 2026 · 해커톤
역할: 백엔드 · 프론트엔드 — 커밋 기준 최다 기여 (전체 코드의 91%)
참여 인력: 7명 — 개발 4명 / 기획·리서치 3명 (24시간 해커톤)

Python 3.12FastAPIPydanticHTTPXTMAP API서울 공공데이터Kakao LocalpytestOpenAPI 3.1

GitHub에서 코드 보기 ↗

서비스

노약자·휠체어 이용자·임산부처럼 이동에 조건이 붙는 사람을 위한 길찾기 서비스입니다.

일반 지도의 예상 도착시간은 표준 보행속도를 씁니다. 그래서 교통약자에게는 늘 틀리고, 그 오차가 대중교통을 놓치게 만듭니다.

이동 유형과 보조기구를 프로필로 받고 안내 중 실제 속도를 모아 ETA를 보정하며, 이탈하거나 놓치면 현재 위치에서 다시 계산합니다.

로그인
이동 프로필
목적지 검색
경로 · ETA
안내
재탐색
도착

모바일 경로 화면. 일반 안내 기준 11분과 '내 속도로는 18분'이 나란히 놓이고, 턱낮춤 없는 횡단 경고가 붉은 상자로 맨 위에, 그 아래 경사·노면·보도 폭 근거가 줄지어 있다 — 경로 — 일반 안내와 내 속도로 다시 계산한 시간을 나란히 두고, 왜 더 걸리는지 구간마다 말한다 (경로 값은 저장소의 목 프로바이더가 만든 합성 데이터)

모바일 지도 화면. 상단에 학습된 보행속도 0.8m/s가 표시되고 지도에 현위치가 찍혀 있다 — 현위치 — 상단의 보행속도는 안내를 마칠 때마다 갱신된다. 표준 속도가 아니라 이 사람의 속도다

데모 UI: React 19 · TypeScript · Vite · Tailwind · 카카오 지도 SDK
직접 띄워보기: backend: ROUTE_PROVIDER=mock uvicorn · frontend: vite→ localhost:5180

e2e가 화면에서 재현하는 것

카카오 지도·장소 검색은 실제 SDK를 호출한다 — 화면의 서울역 검색 결과는 실제 응답이다
경로·ETA 값은 저장소가 제공하는 목 프로바이더(ROUTE_PROVIDER=mock)의 합성 데이터다. mocks/README.md가 실제 정보처럼 표시하지 말라고 명시하고 있어 그대로 밝힌다

위 화면은 로컬 데모 실행 결과입니다. 운영 중인 서비스가 아닙니다.

요약

경로에 접근성 정보를 붙일 때 구간마다 외부를 차례로 묻던 것을 같이 물어 대기 3,097ms → 52ms, 외부 호출 60회 → 20회
표준 보행속도로 낸 ETA가 교통약자에게 항상 틀리던 것을 이동 유형·보조기구 프로필과 안내 중 모은 실제 속도로 보정
확인 못 한 시설 정보를 '있음'으로 채우던 것을 '확인 안 됨'으로 그대로 응답하도록 상태를 정의
경로 이탈과 대중교통 놓침을 감지해 현재 위치를 새 출발점으로 경로와 ETA를 다시 계산

01교통약자 경로 안내 · 외부 API 통합

구간마다 외부를 차례로 묻던 것을 같이 물어 3,097ms → 52ms

변경 전에는 경로 후보마다 구간마다 외부 호출을 하나씩 끝내고 다음으로 넘어가 대기가 일렬로 쌓였고, 변경 후에는 모든 구간의 호출을 한꺼번에 띄워 가장 느린 하나로 끝나는 구조를 비교한 타임라인 — 접근성 정보 붙이기 — 차례로 기다리기 vs 같이 묻기

문제 원인

경로 하나에 접근성 정보를 붙이려면 구간마다 엘리베이터·저상버스·실시간 도착을 외부에 물어야 함
구간끼리 서로 필요로 하는 게 없는데도 차례로 기다려, 응답 시간이 호출들의 합이 됨 — 저장소 전체에 asyncio.gather가 0건
경로 후보가 여러 개면 같은 역을 후보마다 다시 물어 호출이 후보 수만큼 배로 늘어남

해결 과정

구간별 호출과 구간 안의 독립 호출(승·하차역 엘리베이터·승강기 목록·실시간 도착)을 asyncio.gather로 묶음
같은 역·같은 정류장이 여러 후보에 겹치면 한 번만 묻고 결과를 나눠 씀 — 버스 provider가 쓰는 것과 같은 기준으로 동일 정류장을 판정
provider마다 시간 한도를 두고 넘기면 그 항목만 '확인 안 됨'으로 내림 — 이 서비스가 원래 하던 처리의 연장으로, 늦은 것과 못 받은 것을 같게 다룸

결과

대기가 구간 수에 비례해 늘던 것이 구간 수와 무관해짐 — 구간 1개 258ms, 4개 1,031ms이던 것이 둘 다 52ms
경로 후보 3개 기준 외부 호출 60회 → 20회, 대기 3,097ms → 52ms
영영 답하지 않는 외부를 넣어도 응답이 붙들리지 않고 '확인 안 됨'으로 내려가는 것을 테스트로 고정

측정대기 (지하철 구간 4 · 경로 후보 3)3,097ms→52ms외부 호출 1건당 50ms를 주입한 값 · 실제 API 응답 분포가 아니라 호출 구조를 본 것 측정외부 호출 수 (경로 후보 3)60회→20회같은 역·정류장을 후보마다 다시 묻지 않게 한 결과 검증동시 실행 수단0건→구간·역 단위로 묶어 1단계

구현 기능

위 문제 해결 외에, 서비스가 돌아가기 위해 구현한 것들입니다.

TMAP 경로·서울 버스·지하철 실시간 도착·엘리베이터·장소 검색 등 외부 API 5종을 provider 어댑터 계층으로 통합
이동 프로필 조회·수정과 목적지 장소 검색, 대중교통·도보·택시 유형별 경로 검색과 상세 조회
안내 세션 시작·위치 갱신·재탐색·완료 — 완료 시 실제 속도를 프로필에 반영하고, 원본 좌표는 안내 중 계산에만 쓰고 영구 저장하지 않는다

주장하지 않는 것

하나금융그룹 × SK텔레콤 Tech4Good 2026 해커톤의 24시간 팀 프로젝트입니다. 기획은 팀원들이 맡았고, 코드는 저장소 커밋 기준 91%를 제가 썼습니다(프론트 91% · 백엔드 82% · 테스트 82%). 팀원이 만든 하이브리드 대중교통·호출택시 추천과 보도 데이터 provider는 제 성과에서 뺐고, 개인화 보정 엔진도 팀원과 함께 쓴 것이라 단독으로 적지 않았습니다.

위 접근성 조회 수치는 2026-08-08에 제가 고친 부분을 같은 스크립트로 전후 측정한 값입니다. 외부 응답 시간은 호출 1건당 50ms를 주입한 값이라 실제 TMAP·서울 공공데이터의 응답 분포가 아닙니다 — 여기서 확인한 것은 기다림이 쌓이는지 아닌지, 즉 호출 구조입니다. 처리량이나 동시 사용자 지표로 쓰지 않습니다.

그 밖의 성능은 측정하지 않았으므로 수치를 싣지 않습니다. 서비스 품질 보장 범위는 서울시입니다.

← Projects