탈 수 있을까?

양주에서 서울로 출근하는 광역버스 승객에게 버스가 내 정류장에 도착할 때 자리가 있을지 예보하는 서비스. 5인 팀에서 데이터 수집과 예보 API, 모바일 웹 조회 흐름을 맡고 기획 논의에 참여함.

FILE 02양주 만차예보 · 2026.09–10

문제: 지금 보이는 잔여석으로는 내 정류장에서 탈 수 있을지 알기 어려움. 공공 API의 빈 좌석 슬롯이 기본값 0으로 들어와 '정보 없음'이 '만석'으로 보임
본인 판단: 실제 차량이 보고한 0만 만석으로 처리하고 정보 없음과 빈 슬롯은 따로 구분. 근거가 부족한 예측 확률은 null로 둠
역할·기간: 5인 팀 '타고가조', 데이터 수집과 예보 API, 모바일 웹 조회 흐름 담당, 기획 논의 참여 · 2026.09.23–10.17
인정: 2026 양주시 미래인재 AI 공모전 최우수상 (팀 수상, 제2026-126호, 2026.10.17) · 로컬 API 코드와 테스트는 AI 협업, 응답 기준과 검수는 본인

01 · 배경

'언제 올까'에서 '탈 수 있을까'로

옥정에서 좌석이 소진돼 고읍과 삼숭에서 타기 어렵다는 시민 건의가 있었고, 양주시는 2026년 2월 G1300과 1306을 증회함. 기획안에 쓴 STCIS 자료(2026.9.8–21 평일)에서 G1300 덕현초교 06시대 혼잡도는 97%, 관측일 10일 중 9일 혼잡.

기존 안내는 도착 예정 시간과 현재 잔여석까지만 보여 줌. 팀은 질문을 '내 정류장에 오면 탈 수 있을까'로 바꾸고 도착 시 만차 확률, 유사 운행 사례, 다음 버스 비교를 함께 주는 방향으로 정리함. 팀 설문 기준으로 '만차로 다음 버스를 기다렸다'는 응답은 42.8%.

AS IS '버스는 언제 올까?'와 TO BE '내 정류장에 오면 탈 수 있을까?'를 나란히 비교한 슬라이드 — **질문 전환**도착 예정 시간과 현재 잔여석에서 도착 시 만차 확률과 유사 운행 비교로 · 팀 발표자료 p.4

시범 범위는 덕현초교 출발 G1300과 1306 두 노선, 평일 05:45–09:00 만차 예측.

02 · 문제 정의

빈칸이 0석으로 들어오는 데이터

2026.10.03 덕정역 도착 API를 한 번 조회해 좌석 값을 확인. 정규화한 슬롯 56개 중 쓸 수 있는 좌석 값은 2행뿐임.

빈 슬롯 37, 좌석 공란이나 숫자 해석 불가 28, 음수나 미제공 8 (한 행에 여러 표시가 겹쳐 합계는 56을 넘음)
빈 슬롯이 기본값 0으로 들어와, 그대로 쓰면 '정보 없음'이 '만석'으로 보임

단일 조회 결과 · 본인 로컬 검증 문서 기준

03 · 판단 기준과 결정

모르는 값은 모른다고 응답

근거가 없으면 숫자 대신 이유를 보냄.

이 기준으로 수집과 예보 API의 응답 규칙을 아래처럼 정함.

피함

API 기본값 0을 그대로 사용

빈 슬롯과 정보 없음이 실제 만석 관측과 섞임

채택

0석, 정보 없음, 빈 슬롯 분리

실제 차량이 보고한 0만 만석으로 판단. -1이나 공란, 음수는 0으로 바꾸지 않고 빈 슬롯은 후보에서 제외

피함

요청 시각에 도착 예정 시간을 다시 더함

예전에 받은 도착 예정 시간이 조회할 때마다 뒤로 밀려 방금 본 값처럼 보임

채택

수신 시각 고정과 stale 표시

도착 예정 시각은 수신 시각 기준으로 고정. 오래된 관측은 stale로 표시하고 계산에서 제외

채택

근거가 부족하면 확률은 null

유사 사례 19건 이하면 확률을 내지 않고 20건부터 계산. 20건을 채워도 공개 승인은 따로 둠

채택

덕현초교 직접 관측을 기준으로

덕정역 관측은 같은 차량, 같은 운행, 같은 방향이 확인될 때만 보조로 사용. 차량번호 일치만으로 같은 운행으로 보지 않음

예보 갱신 시점을 '도착 15·10·5분 전'에서 '3·2·1정거장 전'으로 바꾼 것은 팀 결정으로, 2026.10.15 최종 발표자료에 반영됨.

04 · 결과물

예보 화면과 예측 보류 구조

팀 최종 발표자료(2026.10.15)의 서비스 화면. 예보 카드에 무좌석 위험과 함께 근거가 된 유사 운행 횟수를 같이 표시함.

'탈 수 있을까?' 모바일 웹 첫 화면, '오늘은, 앉아서 가볼까요?' 문구와 출발지 입력 영역 — **1. 첫 화면**출발지와 목적지를 정하고 버스별 예보로 이동 · 팀 발표자료 p.1

덕현초교에서 신림역까지 경로 카드, G1300 4분 후 잔여 5석, 무좌석 위험 4% 위험 낮음 13회 중 0회 — **2. 버스별 예보**'무좌석 위험 4% · 13회 중 0회'처럼 확률과 근거 사례 수를 함께 표시 · 팀 발표자료 p.9

하네스가 관리하는 AI 구조도, 실시간 운행과 JSON 사례, Markdown 규칙에서 유사 운행 검색, 확률 추정과 사례 기반 계산, 검증을 거쳐 통과하면 경로 카드, 미통과하면 예측 보류 — **3. AI 구조**보정, 최신성, 근거, 일관성 검증을 통과하지 못하면 예측 보류 · 팀 공동 설계, 팀 발표자료 p.12

본인 산출물. 로컬 FastAPI 예보 API 0.1.0(경로 10개)과 GBIS 좌석 수집기, 검증 문서. 첫 공식 조회 3회 모두 정상 응답, 차량 슬롯 72행 중 유효 좌석 17행 확인. 팀 저장소와 통합 전 로컬 구현이며, Azure 서버는 생성과 관리까지 담당.

최우수상. 2026 양주시 미래인재 AI 공모전 최우수상, 양주시장 명의, 팀 수상.

AI 협업 범위. API 명세 초안, 코드, 테스트는 AI 협업. 좌석 상태 구분과 확률 공개 조건, 결과 검수는 본인.

05 · 정리

본인 작업과 팀 작업의 범위

실제 조회에서 빈칸이 0으로 들어오는 것을 먼저 확인한 뒤 0석과 정보 없음을 나누는 기준을 문서로 작성.

근거가 부족할 때 숫자를 내지 않는 원칙은 팀 구조의 '검증 미통과 시 예측 보류'와 같은 방향. 본인 산출물은 로컬 구현, 화면과 발표자료는 팀 공동 작업.