한화 신입사원 AI 솔루션 챌린지 · 과제 03 고객 페인포인트 해결

불꽃배웅 — 서울세계불꽃축제 귀가 출구 내비 · 최종 보고

눈부신 밤의 끝, 집으로 가는 길까지. · 2026-09-08 기준 (9/5 실전 결과 반영) · 작성: 박재형 · 쉬운 버전(5분) · 피치 덱(12장) · 완성된 대시보드 보기 · 코드 저장소 · 행사일 2026-09-05(토) 실전 운전 완료

읽는 법 — 배경지식 없이 처음 읽는다면 그림 중심의 쉬운 버전(5분)부터 보면 좋다. 바쁘면 위 다섯 줄과 §1~2만 읽어도 흐름이 잡힌다. §3은 예측을 만들고 검증한 방법, §4는 시스템이 돌아가는 구조, §5는 우리 스스로 찾은 결함과 그 처리, §6은 9/5 실전 결과와 채점이다. 낯선 용어는 모두 §7 용어 사전에 풀어 두었고, 차트는 점에 마우스를 올리면 값이 나온다.

1문제 제기 — 귀가가 무너진다

서울세계불꽃축제는 매년 여의도 한강공원 일대에 약 100만 명이 모이는, 한화가 주최하는 국내 최대 규모 불꽃 행사다. 문제는 축제가 아니라 축제가 끝난 직후 1~2시간이다.

21시가 넘어 마지막 불꽃이 터지면, 공원에 있던 사람들이 한꺼번에 지하철역으로 걷기 시작한다. 이때 벌어지는 일:

1.1 지도앱이 막힌 길로 안내한다

공원에서 가장 가까운 역은 여의나루역(5호선)이다. 네이버지도·카카오맵에 "집 가는 길"을 검색하면 당연히 여의나루역으로 안내한다. 그런데 축제일 저녁 여의나루역은 안전상 무정차 통제된다. 걸어가 봐야 닫혀 있다.

이것은 추측이 아니라 실측이다. 서울교통공사 승하차 데이터(OA-12921)를 보면:

1.2 서울시 데이터는 "상태"만 준다

서울시 실시간 도시데이터라는 훌륭한 공공 API가 있고, 여의도 인구·혼잡도를 5분마다 알려준다. 하지만 알려주는 것은 "지금 붐빔"이라는 상태까지다. 관람객이 정작 알고 싶은 "그래서 어디로, 언제 나가야 하나"라는 행동을 알려주는 서비스는 없다.

1.3 누가 겪는 문제인가

KT 통신 데이터 기준 관람객 최다 집단은 20·30대 여성이다. 대부분 대중교통으로 귀가하고, 쇼가 끝난 뒤 어두운 공원에서 통신까지 폭주하는 상황에서 판단해야 한다. 그 순간에 복잡한 앱은 못 쓴다 — 한눈에 읽히는 한 장이 필요하다.

2해결 방안 — 상태가 아니라 행동을 알려준다

출구(지하철역 6개 + 도보 경로 1개)마다 시간대별로 "얼마나 막힐지"를 미리 예측해서, 순위·등급·예상 대기시간으로 보여주는 웹페이지다. 열면 3초 안에 답이 나온다.

2.1 사용 장면

1. 21:15, 마지막 불꽃 직후. 관람객이 QR로 페이지를 연다 (통신 폭주 대비 — 한 번 열었던 페이지는 저장돼 있어 다시 열린다).
2. 화면 맨 위: "지금 나가면: 신길 여유 · 마포대교 도보 여유 / 샛강 주의 · 여의도(5) 주의 / 여의나루 통제 중(21:40 해제)"
3. 자기 집 방향 탭을 누르면 그 방향 추천 출구와 도보 소요, 시간대별 전망(지금 갈까, 30분 놀다 갈까)이 보인다.

2.2 화면이 주는 정보

• 출구 7개: 여의도(5) · 여의나루(5) · 신길(1·5) · 여의도(9) · 샛강(9) · 국회의사당(9) · 마포역 도보(마포대교)
• 등급 4단계: 여유 <0.5 주의 0.5~0.8 경계 0.8~1.0 심각 ≥1.0 — 숫자는 "부하율", 즉 수요를 그 역의 처리용량으로 나눈 값이다(계산은 §3.3, 사전은 §7)
• 통제 안내: 여의나루 임시 통제 20:40~21:40 (2026 공식 공지) — 지도앱이 모르는 바로 그 정보
• 예측 범위(밴드): "0.62 (0.55~0.70)"처럼 폭으로 표시 — 예측의 불확실성을 숨기지 않는다
• 혼잡장 지도와 회피 경로(2026-09-01 추가): CCTV 23대와 서울시 구역 등급을 한 장의 면으로 합친 지도 위에, 현재 위치에서 고른 역까지 혼잡을 피해 걷는 경로와 소요 시간을 그린다(§3.9·§3.10)

2.3 왜 앱이 아니라 정적 웹페이지인가

• 설치 없는 링크 한 개 — 당일 QR로 배포 가능
• 서버가 없어서 죽지 않는다 (GitHub Pages 정적 호스팅). 라이브 데이터 갱신이 끊겨도 사전 예측표로 자동 전환
• 통신 폭주 대비: 마지막으로 본 데이터를 기기에 저장(localStorage), 오프라인이어도 마지막 값 표시

3설계 방법 — 과거 실측을 기준점 삼은 예측 모델

3.1 왜 머신러닝을 안 썼나

ML로 풀려면 학습 데이터가 필요한데, 이 축제의 데이터는 2024·2025년 단 2일뿐이다. 표본 2개로 모델을 학습시키면 외우기(과적합)가 될 뿐이다. 그래서 학습 대신, 실측값을 뼈대로 쓰고 물리 법칙(걷는 속도, 역 처리량)으로 살을 붙이는 구조 모델을 택했다. 구조 모델은 규칙을 데이터에서 통째로 배우게 하는 대신, 규모(E_st)·분배(비중)·시간 형태(도착 곡선)처럼 사람이 검증할 수 있는 부품으로 식을 조립하는 방식이다. 부품마다 따로 근거를 대고 따로 고칠 수 있어, 표본이 적어도 어디가 틀렸는지 짚을 수 있다. 미국 애틀랜타 지하철(MARTA)의 경기장 이벤트 수요 예측 논문도 같은 접근으로 오차 11.7%를 달성했다 — 데이터가 적을 땐 이 방식이 정석이다.

3.2 수요 식 — 세 요소의 곱

정식 표기 — 세 요소를 수식으로

위 곱셈식을 기호로 적으면 다음과 같다. 역 \(st\), 시각 \(h\)의 출구 수요는

\[ D_{st}(h) \;=\; \alpha \cdot E_{st} \cdot \varphi_{st}(h), \qquad \textstyle\sum_h \varphi_{st}(h) = 1 \]

이고, 도착 형태 \(\varphi_{st}\)는 KT 유출 곡선을 쇼 종료 이동분만큼 옮긴 뒤 도달 지연으로 시간대에 배분한다:

\[ \varphi_{st}(h) \;=\; \sum_{k\in\{0,1,2\}} w_{st}(k)\,\hat g(h-k), \qquad \hat g(h) = g_{\mathrm{KT}}(h - \Delta_{2026}),\ \ \Delta_{2026} = +40\text{분} \]

배분 비율 \(w_{st}\)는 도달 지연 \(\tau_{st}\)에서 나온다 — 시간대 안 균등 출발을 가정하면 \(\tau_{st}\)분 걸리는 이동은 같은/다음 시간대로 \((60-\tau)/60,\ \tau/60\)씩 갈린다. 지연 자체는 거리 나누기 밀도별 보행속도다:

\[ \tau_{st} = \frac{1}{60}\!\left[\frac{\ell_1}{v(\rho_{\mathrm{zone}})} + \frac{L_{st}-\ell_1}{v(\rho_{\mathrm{street}})}\right]\!, \qquad v(\rho) = \max\!\Big(0.15,\ 1.34\big[1-e^{-1.913(1/\rho-1/5.4)}\big]\Big)\ \mathrm{m/s} \]

\(v(\rho)\)는 Weidmann(1993)의 Kladek 식(§8.2 [2]). \(L_{st}\) = 관람 구역→출구 직선거리 × 우회계수 1.3(추정 — 9/1 구축한 보행망으로 재현하면 이벤트광장→여의도역 1.31배로 이 값에 가깝다, §3.10), \(\ell_1 = \min(300\,\mathrm{m}, L_{st})\)은 관람 구역 밀도 \(\rho_{\mathrm{zone}}\)로 걷는 초반 구간(추정), 이후는 가로 밀도 \(\rho_{\mathrm{street}}=1.5\)명/m²(추정). \(\rho_{\mathrm{zone}}\)은 당일 CCTV 등급에서 읽고(여유 1.5 · 주의 3.0 · 경계 4.0 · 심각 5.0명/m², §3.7), 관측이 없으면 3.0. 구현: src/nowcast.py kladek()·lag_table().

표 3-1 — 기호·파라미터 일람

표 3-2 — \(E_{st}\)·\(C_{st}\) 실측값 (명)

E = 축제일 승차 − 평시 토요일 중앙값(그 해 전체), 19~23시 합. † = 용량 추정(9호선·1호선 합산·보행로 — OA-12921 밖). 역별 E는 해마다 흔들리지만(여의도(5) 3.8만 ↔ 2.5만) 합계는 0.6% 차로 안정적이다 — 규모 예측이 성립하는 근거이자, 단일값 대신 2년 범위 밴드를 쓰는 이유다(§3.5 히스토리 표). 산출: data/derived/exit_shares.json.

3.3 부하율과 통제 규칙

• 부하율 = 수요 ÷ 처리용량. 처리용량은 그 역이 한 시간에 실제로 태워 보낸 최대 인원(관측값). 1.0을 넘으면 그 시간 안에 다 못 타서 줄이 다음 시간으로 쌓인다 → 예상 대기시간으로 환산.
• 통제 규칙: 여의나루는 20~21시 수요 0(무정차). 그 시간에 여의나루로 걸어온 사람들은 사라지는 게 아니라 해제(21:40)를 기다렸다가 바로 탄다 → 그 몫을 22시로 이월. 실측 근거: 해제 직후 시간대 승차가 2024년 2.3천 · 2025년 5.8천 명.
• 이 이월 규칙 덕분에 모델이 "22시 여의나루가 가장 위험하다"는, 직관과 다른 결론을 낸다 (§4.3).

기호로 적으면 — 부하율, 시간대를 넘는 대기열, 대기시간은

\[ L_{st}(h) = \frac{D_{st}(h)}{C_{st}}, \qquad Q_{st}(h) = \max\big(0,\ Q_{st}(h\!-\!1) + D_{st}(h) - C_{st}\big), \qquad W_{st}(h) = 60\,\frac{Q_{st}(h)}{C_{st}}\ \text{분} \]

\(Q\)는 유량 보존식이고 \(W\)는 Little 법칙(대기열 ÷ 처리율)이다 — 자유 파라미터가 없어, 수요와 용량이 맞으면 자동으로 맞는다. 통제 이월은 여의나루 \(h\in\{20,21\}\)에서 \(D=0\)으로 두고 그 도착분을 해제 후 첫 시간대(22시)에 가산하는 규칙이다. 이것은 안전측 근사다 — 공지상 통제는 20:40~21:40(60분)이라 20:00~20:40과 21:40~22:00은 열려 있지만, 2024·2025 실적은 두 해 다 19시부터 하차가 0이어서 현장이 공지보다 일찍 무정차로 전환했다. 열려 있다고 가정했다가 조기 무정차가 나면 승객이 탈 수 없는 역에서 대기하게 되므로, 모델은 두 시간을 통째로 닫고 화면 문구만 "공지 기준 20:40부터 · 예년엔 조기 무정차"로 조건부로 안내한다(2026-09-01 자체 검증 H2). 보존 검증은 상시 테스트(tests/test_model.py), 대기 분의 실측 대조는 9/5 현장 스톱워치로 하려 했으나 실측이 없어 미검증으로 남는다(§6.2).

3.4 당일 보정 α — 오늘 규모를 실시간으로 갱신

• 관측 ① 도착측: 여의나루역 30분 단위 하차 인원 (낮 12시~19시, 사람들이 공원에 들어오는 규모)
• 관측 ② 귀가측: 여의도 일대 9개 역 30분 단위 승차 인원 (19시 이후, 사람들이 실제로 빠져나가는 규모)
• 관측이 하나도 없으면? 사전 예측표를 그대로 쓴다. 즉 라이브가 죽어도 서비스는 성립한다.

α 추정은 격자 베이즈 갱신이다. 로그 등간격 61점 \(\alpha \in [1/3, 3]\) 위에서

\[ w(\alpha) \;\propto\; p_0(\alpha) \prod_{i=1}^{n} \mathcal{N}\big(y_i;\ A_i\,\alpha + B_i,\ \sigma_i\big), \qquad p_0 = \mathrm{LogNormal}(0,\ 0.25) \]

를 계산하고 \(\hat\alpha = p50\), 예측 밴드는 \([p10, p90]\)을 쓴다. 사전분포 폭 0.25는 p10/p90이 0.73/1.38로 2년 관측 밴드와 맞도록 정했다. 관측 \(y_i\)는 두 채널이다:

표 3-3 — \(\alpha\) 관측 채널 (O1·O2)

구현: src/nowcast.py assimilate(). 사후분포가 격자 끝에 붙으면(edge_hit) 관측과 사전이 크게 어긋난다는 경고로 기록한다.
커버리지 \(c\)(핫스팟 9역 ÷ 우리 6출구)는 당일 14~17시 30분 창의 중앙값으로 추정한다. \(\alpha\)는 \(c\)에 반비례하므로 이 값 하나가 규모 전체를 흔든다 — 창이 3개 미만이거나 창끼리 (최대−최소)÷중앙값이 0.3을 넘으면 추정을 버리고 고정값 1.3을 쓴다. 실제 사용값·산포는 assimilation.coverage_basis·coverage_spread로 발행 데이터에 남긴다(2026-09-01 자체 검증 H5).

3.5 검증 — 타임머신 시험 (백테스트)

예측 모델은 "맞는지"를 반드시 숫자로 확인해야 한다. 방법: 한 해의 데이터를 가리고, 다른 해의 데이터만으로 그 해를 예측한 뒤 실측과 비교한다. B 모드가 2026년 예측이 실제로 놓이는 조건과 같다(과거 데이터만 있음).

오차 = |예측−실측| 합 ÷ 실측 합 (시간대 승차가 있는 4개 역 기준). B 오차의 주범은 해마다 총 인파가 다르다는 것(여의도(5) 21시: 2024년 17.8천 ↔ 2025년 12.5천) — 이 폭을 예측 밴드로 정직하게 표시한다. 등급 적중률이 더 중요하다: 관람객이 실제로 보는 것은 숫자가 아니라 여유~심각 등급이고, 이건 B에서도 76~88% 맞는다. 이 밖에 코드가 바뀔 때마다 자동으로 도는 회귀 테스트 122건(2026-09-08 기준 — 수요 총량 보존·통제 이월·쇼 종료 입력 방어·발행 스키마·혼잡장 수치 등)이 상시 통과 상태다. 8/31에는 22건이었고, 9/1 자체 검증(§5)의 조치를 실패하는 테스트부터 쓰는 방식으로 넣으면서 45건이 됐다.

오차 지표는 시간대 절대오차 합 대 실측 합의 비다:

\[ \mathrm{err} = \frac{\sum_h \big|\hat D(h) - D_{\mathrm{obs}}(h)\big|}{\sum_h D_{\mathrm{obs}}(h)} \]

표 3-4 — 역별 오차·등급 적중 (오차 err, 괄호 = 등급 적중/시간대 수)

읽는 법 — "2025→2024"는 2025년 데이터만으로 2024년을 예측한 교차 검증. 신길의 B 오차 0.69는 절대 규모가 작아(시간당 수백 명) 비율이 과장된 것으로, 등급은 5/5 전부 맞다. 여의나루 등급 분모가 2인 것은 통제로 열린 시간대가 두 개뿐이기 때문이다. 시간대별 원자료: data/derived/backtest.json.

표 3-4b — (2026-09-04 추가) 4년 교차 검증: 2022·2023 을 더한 9쌍

축제는 2000년부터 열렸는데 우리는 두 해만 썼다. 지하철 승하차(OA-12921)는 2008년부터 연도별 파일이 있고, KT 생활이동 일별 OD 는 2023-01-01 부터 있다. 그래서 2023 은 소스와 목표 양쪽에, 2022 는 유출 곡선이 없어 목표(실측)에만 더했다(2020·2021 은 코로나로 열리지 않았다). 소스 3해 × 목표 4해에서 같은 해를 뺀 9쌍이다. 여의나루 통제 시간대는 축제일 승차 실측에서 읽었다 — 2022 는 20시 한 시간대(부분 통제), 2023 은 19·20시.

승차 오차 = Σ|예측 승차−실측 승차| / Σ실측 승차, 초과 오차는 평시를 뺀 초과분 기준. 4역(여의도·여의나루·신길·마포) 19~23시. 원자료 data/derived/backtest_4y.json, 계산 tools/backtest_4y.py.

결론은 둘이다. 첫째, 표본을 2쌍에서 9쌍으로 늘려도 오차는 줄지 않았다 — 위 표 3-4 의 42~44% 는 두 해의 우연이 아니라 연도 간 이전 오차의 실제 크기다. 둘째, 이 값이 C1 이 요구하는 밴드의 바닥이다. α 사후 밴드가 관측을 먹고 ±5% 로 좁아져도 화면 밴드가 이 아래로 내려갈 근거가 없다. 이 검증은 보고서용이고, 9/5 에 도는 모델과 사전 예측표는 손대지 않았다.

표 3-4a — 백테스트가 검증한 수요 비중 (출구별 실측 비중 share_mean 기준)

약점을 먼저 말한다 (2026-09-01 자체 검증 H1·H3 · 부하율은 2026-09-03 정정본). 백테스트는 수요의 55.4%만 검증했고, 미검증 44.6%에 최악 후보가 몰려 있다. 사전 예측표 22시 부하율 상위는 여의나루 1.00 · 샛강 0.82 · 여의도(5) 0.66 · 국회의사당 0.65인데 2위와 4위가 검증 밖이고, 그 용량은 전부 추정값(estimated_capacity: true)이다. "샛강이 두 번째로 위험하다"는 결론의 근거는 9호선 실측이 아니라 교통카드 일별 비례 추정이라는 뜻이다. 9/5에도 9호선 역 단위 승차 관측은 없다(서울시 실시간 도시데이터의 승차는 핫스팟 합산이다) — 이 구간의 검증 재료는 CCTV 밀도와 현장 관찰뿐이다. 또 하나, 19시 여의나루는 2024·2025 두 해 모두 통제(하차 0)였는데 2026 모델은 공지(20:40~)를 따라 19시를 개방으로 둔다(부하율 0.18). 20·21시는 실제보다 보수적으로 닫으면서 19시는 이력보다 낙관적으로 여는 비대칭이다. 백테스트가 한 번도 검증하지 못한 시간대이므로 화면 문구는 "공지 기준"임을 같이 적는다.

그림 4 — 백테스트: 모델 곡선이 실측을 따라가는가. 대표로 여의도(5)역 저녁. 21시 정점의 높이·위치가 맞는다.

히스토리(2024·2025 실측)가 가르쳐준 사실

3.6 피더 분석 — 사람들은 어디서 타고 오나

그림 1 — 상위 피더 12곳 점·선 도식. 가운데가 여의도. 선 방향은 실제 방위, 중심에서 떨어진 거리는 지하철 소요시간(점선 링 = 10·20·30분, 추정), 원 크기는 2년간 여의도행으로 집계(귀속)된 인원. ▶ 재생을 누르면 낮 12시부터 인파 유입이 흐른다 — 유입 속도는 그 시각의 실측 승차 강도를 역별 비중으로 배분한 값(추정).

어떻게 찾았나 — 4단계

1. 초과 승차 계산: 서울 1~8호선 전 역(253역)에서 축제일 시간대별 승차 − 평시 토요일 중앙값을 구한다. "평소에도 타는 사람"을 걷어낸 나머지.
2. 2년 필터: 2024·2025 두 해 연속 초과가 난 역만 인정. 한 해만 튄 역은 다른 행사·우연일 수 있어 제외.
3. KT 데이터로 제약: KT 생활이동(휴대전화 기반)이 "여의도 유입이 어느 구(區)에서 출발했는지" 총량을 준다. 역별 초과분은 그 구 총량을 넘지 않게 배분 — 역 데이터 혼자 결론 내지 않고 독립된 두 소스를 맞물린다.
4. 교차 검증: 배분한 합계가 여의도 도착과 규모(자릿수)·시간 모양에서 일치하는지 확인.

그림 2 — 핵심 근거: 시간이 맞물린다. 피더역들의 초과 승차(주황 실선)가 먼저 움직이고, 여의도 도착(파랑 점선)이 약 1시간 뒤를 그대로 따라간다. 상관계수 0.99. 차트 아래 슬라이더로 시각을 옮기면 같은 무리가 한 시간 뒤 도착하는 짝이 커서로 보인다.

그림 3 — 개별 역에서 보면. 영등포시장역(5호선, 여의도 3분)의 축제일 승차는 입장 시간대(12~17시)에만 평시보다 많고, 저녁이 되면 격차가 사라진다. "축제 가려고 탄 사람들"이라는 해석과 정확히 맞는 모양.

"이 사람들이 여의도로 갔다"고 판단한 근거 5가지

역별로 뜯어본 상관 — 거리가 위상을 결정한다

2년 합동 Pearson, 표본 n=20 (2년 × 10시간대). 굵은 값이 그 역의 우세 위상. 근거리 4곳은 같은 시각(0.80~0.86), 원거리 3곳은 1시간 선행(0.71~0.95)이 우세하다 — 소요시간이 길수록 선행이 커지는 순서가 그대로 재현된다(근거 ①의 역별 분해). 다만 개별 역은 표본이 작아 잡음이 크므로, 본 판단은 12곳 합산 상관(lag1 0.99)으로 하고 이 표는 위상 확인과 당일 감시 우선순위(강한 역 위주)에 쓴다. 산출: data/derived/feeder_leadlag.json.

한계도 정직하게. 초과 승차가 전부 축제 인파는 아니다 — 서울 전 역의 초과 합은 여의도 유입 규모의 1.7~3.3배로, 다른 나들이·행사가 섞여 있다. 그래서 2년 연속 필터·구 총량 상한으로 보수적으로 배분(귀속)했고, 개별 역 중엔 잡음이 큰 곳도 있다(위 표: 사당 0.04 · 목동 0.13 · 김포공항 −0.19). 분 단위 정밀 검증은 9/5 라이브 수집으로 한다.

이걸로 뭘 하나

• 사전: 출발지 구성 → 귀가 방향 비중 → 출구 배분의 근거 (방향 대칭 ⑤)
• 당일: 피더 12곳을 5분마다 감시(전용 API 키 2개) — 여의도가 붐비기 30~40분 전에 미리 아는 조기 신호. 단 9/5 예측 모델엔 안 넣고 관측만 한다. 분 단위 정확도가 검증 안 된 신호로 실전을 흔들 수 없기 때문. 9/5 실측으로 역별 시차를 검증한 뒤에야 「도착 30분 예측」 기능이 될 수 있다 — 이번 판에는 관측 근거로만 싣는다.

3.7 CCTV — 걷는 속도를 실측으로

• 서울시 교통 CCTV(TOPIS) 23대의 공개 영상에 사람 수를 세는 AI(DM-Count)를 붙였다. 영상 프레임은 저장하지 않고 집계 숫자만 남긴다 (사생활 보호). 23대 중 9대는 720p 고화질 스트림(hls_hd)을 우선 읽고 실패하면 표준화질로 내려간다(2026-09-01 추가).
• 출구로 가는 길목 5대에는 "관심 영역(ROI)"과 면적을 지정했다 — 축제일에 차량이 통제되고 보행로로 바뀌는 차도 부분만 계산에 넣는다. 면적(추정, OSM 차로 수·연장과 교량 제원): 63빌딩 10,000m² · 마포대교 남단 10,000m² · 마포대교 북단 9,000m² · 여의공원 20,000m² · 원효대교 남단 9,000m². 사람 수 ÷ 면적 = 밀도(명/m²)이고, 밀도가 높을수록 보행속도를 늦춰 도착 지연을 보정한다(§3.2).
• 판독마다 신뢰도(confidence)와 플래그(저조도·배경차분 실패·밀도 포화)를 같이 남긴다. 발행 데이터에도 density·calibrated·confidence·flags가 실리고, 화면의 혼잡장이 이 값으로 관측 노이즈를 정한다(§3.9). 즉 미심쩍은 판독은 버리지 않고 "덜 믿는다".
• 야간 작동 테스트 완료(8/29 밤 1시간, 23대 전부 정상 수신·야간 화질 문제 없음). 720p 전환 후 야간 안정성은 9/4~5 의 32시간 연속 운전에서 확인했다 — 자정 전후 TOPIS 스트림 재시작으로 14대가 수 분간 빈 프레임을 낸 것(L7) 외에 문제가 없었다.

3.8 규모의 외부 검증 — 생활인구·전야제

모델의 뼈대인 "규모"가 지하철 데이터 안에서만 맞는 것일 수 있다. 그래서 지하철과 독립인 제3의 소스(서울 생활인구, OA-14991 — 통신 기반 추계)로 같은 그림이 나오는지 확인했다.

표 3-5 — 여의동 생활인구: 평시 vs 축제 당일 (19시, 명)

당일 피크(19시)가 2년 연속 같은 배수로 재현되고, 시간 곡선의 모양도 모델의 유출 곡선과 맞물린다. 지하철 승하차(교통공사) · 이동 OD(KT) · 생활인구(추계)라는 서로 독립인 세 소스가 규모에서 합의한다 — §3.6 근거 ③과 같은 삼각측량이다.

표 3-6 — 전야제(축제 전일 금) 여의나루 하차: 17~23시 합 (명)

전야제 인파는 여의나루 하차 기준 평시 금요일의 1.9배 수준에서 2년 연속 재현되고, 여의도역은 평시 수준에 머문다. 이 수치를 9/4 전야 관측의 정상 신호 기준으로 삼았다 — 그날 관측이 이 규모면 파이프라인이 맞게 돌고 있는 것이다. (2026-09-06 정정) 9/4 전야 관측으로는 이 기준을 판정하지 못했다 — 판정 불가로 기록한다. 파이프라인 정상 여부는 대신 발행 주기·재기동 0·α 갱신으로 확인했다(§6.3). 한편 생활인구는 전야제를 동 단위에서 1.00~1.09배로만 본다 — 여의동의 평일 직장 인구에 희석되기 때문이다. 작은 행사는 역 단위 관측이 동 단위 추계보다 민감하다는, 우리 관측 설계(§3.4 O1·O2)의 방증이다.

산출: data/derived/lifepop_yeouido.json · data/derived/eve_rehearsal.json.

3.9 혼잡장 — 관측 30여 점을 한 장의 면으로 (2026-09-01 추가)

지점 \(x\)의 혼잡 지수 \(C(x)\in[0,1]\)를 관측 \(y_i = C(x_i) + \varepsilon_i,\ \varepsilon_i\sim\mathcal N(0,\sigma_i^2)\)에서 복원한다. 사후 평균과 분산은 표준 식이다:

\[ \mu(x) = m_0 + \mathbf{k}(x)^{\!\top}(\mathbf K + \boldsymbol\Sigma)^{-1}(\mathbf y - m_0), \qquad s^2(x) = k(x,x) - \mathbf{k}(x)^{\!\top}(\mathbf K + \boldsymbol\Sigma)^{-1}\mathbf{k}(x) \]

커널은 두 길이척도의 Matérn 3/2 합이다 — 카메라 시야 규모(150m)와 구역 규모(1,200m)를 따로 잡는다:

\[ k(r) = \sum_{\ell\in\{150,\,1200\}} v_\ell\,(1+a_\ell)\,e^{-a_\ell}, \qquad a_\ell = \frac{\sqrt3\, r}{\ell}, \qquad v_{150}=v_{1200}=0.125 \]

RBF(가우시안) 커널은 무한 번 미분 가능해 인파의 장으로는 지나치게 매끄럽다. Matérn 3/2는 한 번 미분 가능한 거친 면을 허용한다(Rasmussen & Williams 2006, §8.2 [6]). 길이척도 150m의 근거 후보: 관측 주기 5분 동안 밀도 3명/m²의 보행 이동 ≈ 99m(§3.2 속도식). 구현 docs/app/field.js · 커널 상수 docs/index.html APF_KERNEL.

표 3-7 — 관측 노이즈 \(\sigma_i\): 신뢰도를 배제가 아니라 폭으로

2026-09-02 정정 — 밀도 보정 5대를 등급 판독으로 되돌렸다. ROI 면적(roi_m2 9,000~20,000m²)이 도로·교량 전체 면적이라 720×480 원거리 고각에서 군중 계수 모델이 셀 수 있는 규모와 두 자릿수 어긋났다. 「주의」(3명/m²)에 닿으려면 판독 인원 27,000~60,000 이 필요한데 8/29 야간 실측 최대는 8.4~29.3 이었다. 그대로 두면 이 5대가 언제나 「여유」를 가장 낮은 \(\sigma\) 로 주장해 혼잡장을 끌어내린다. 자체 점검에서 발견해 되돌렸고, 면적 산출 근거는 남겨 두어 근경 부분 ROI 로 재측정하면 복원된다.

사전 평균 \(m_0\)은 고정값이 아니라 관측 수준에서 잡는다(경험적 베이즈) — 관측마다 정보 가중치 \(w_i = k(0)/(k(0)+\sigma_i^2)\)를 주고, 기본값 0.3을 가짜 관측 3건만큼 섞어 가중평균한다. 고정 0.3이면 주변이 다 붐벼도 사후가 "여유"로 끌려간다 — 예컨대 미보정 카메라(σ 0.30)가 0.70을 봐도 사후는 0.59로 여유 밴드에 주저앉아 마커와 면이 어긋난다. \(w_i<0.10\)인 관측은 장에 사실상 반영되지 않고, 화면의 마커·배지도 같은 기준으로 "거의 반영 안 됨"을 표시한다. 격자는 200×156, 색은 \(\mu\), 불투명도는 확신도 \(1 - s/s_{\max}\)(\(s_{\max}=0.5\), 0.15에서 포화)다. 관측이 없는 곳은 색이 옅어질 뿐 회색으로 바뀌지 않는다 — 9/1 회색 혼합을 걷어낸 것은 화면 가독성을 위한 선택이고, "모르는 곳"이 색에서 사라져 낙관 쪽으로 읽힐 수 있다는 점은 인정한다(§3.11).

혼잡 지수는 밀도 5명/m²를 1로 두는 선형 사상 \(C = \min(1,\rho/5)\)이고, 서울시 4단계 등급은 여유 0 · 보통 ⅓ · 약간 붐빔 ⅔ · 붐빔 1로 놓았다. 이 사상과 길이척도·σ·가짜 관측 3건은 전부 가정이다. (2026-09-05 정정) 서울시 구역 등급 관측의 나이에서 API 발행 시차 28분(9/4~9/5 전 틱 실측, 28.8분 일정)을 뺀다 — 전엔 시차를 낡음으로 깎아 σ 가 1.1 로 불어 「붐빔」이 장에서 사실상 무시됐다. 같은 층을 관람객 화면에도 넣어 두 화면의 장이 같은 관측으로 만들어진다. 카메라가 있는 자리는 카메라(σ 0.3)가 이긴다. 9/5 관측이 쌓이면 관측 하나를 빼고 나머지로 그 자리를 맞히는 교차검증(LOO)으로 교체한다(다음 단계, §6.4). 거리가 유클리드라 한강 건너로 번지는 문제가 있고, 보행망 거리 커널이 답이지만 다음 단계 과제다. 검증은 tests/field_spec.mjs가 배포 중인 field.js를 node로 그대로 읽어 22개 단언(커널 단조성·Cholesky 재구성·σ 순서·경험적 베이즈 사전)을 확인한다 — 그래서 field.js는 DOM을 만지지 않는 순수 함수로 유지한다. \(\mathbf K+\boldsymbol\Sigma\)가 양의 정부호가 아니면 지터를 키워 6회 재시도하고, 그래도 안 되면 사전으로 폴백하며 ok:false를 남긴다.

3.10 혼잡 회피 보행 경로 — 혼잡장 위에서 길을 찾는다 (2026-09-01 추가)

보행망은 OpenStreetMap에서 여의도 일대(카메라 23대를 감싸는 범위)의 도로 기하를 내려받아 만든 그래프다 — 노드 9,219 · 간선 26,042 · 총 연장 1,486km(방향별) · 파일 5.95MB(gzip 전송 775KB). 경로를 처음 누를 때만 내려받는다(지연 로드). 간선 비용은 길이에 혼잡 위험을 곱한 값이고, 위험은 간선 중점에서 읽은 혼잡장 평균 \(\mu\)다:

\[ c(e) = \frac{\max(0.1,\ m_e)}{v(\rho_{\mathrm{eff}})},\qquad \rho_{\mathrm{eff}} = \kappa\,\rho(\mu(x_e)) + (1-\kappa)\,\rho_{\mathrm{street}},\quad \kappa = \min\!\Big(1,\ \tfrac{1-\sigma(x_e)/\sigma_{\max}}{0.15}\Big) \]

(2026-09-04 변경) 전에는 \( c(e) = \max(0.1, m_e)\,(1 + 1.25\,\mu) \) 였다. 가중치 1.25는 출처가 없었고, 최소화 대상이 사람이 신경 쓰는 값도 아니었다. 더 나쁜 것은 경로는 벌점으로 고르면서 화면의 소요 시간은 67m/분 고정으로 따로 계산해 둘이 따로 놀았다는 점이다. 지금 비용은 그 간선을 걷는 데 걸리는 시간이다 — \(v\)는 §3.2와 같은 Kladek 속도식이고 \(\rho\)는 혼잡장 값을 등급 사다리(여유 1.5 · 주의 3.0 · 경계 4.0 · 심각 5.0명/m²)로 되돌린 밀도다. (같은 날 낮 정정) 밀도를 혼잡장 값 그대로 쓰지 않고 장의 확신도 \(\kappa\)(σ에서, §3.9)로 관측 밀도와 가로 기본 \(\rho_{\mathrm{street}}=1.5\)명/m²를 섞는다 — 본 곳은 본 대로, 못 본 곳은 보통 가로. 그대로 쓰면 GP 사전(0.3)과 σ 0.3 수축이 카메라 없는 이면도로까지 2.25명/m²로 읽어 어느 경로든 위험이 같아지고, 균일 배율은 최소경로를 바꾸지 않아 우회가 사라졌다. 경로를 고르는 비용과 화면의 소요 시간이 같은 식이다 — 잠깐 둘을 나눴더니(비용은 장 전체, 표시는 처음 300m) "더 돌게 하고 더 느리다고 말하는" 모순이 났다. 실측 확인(2026-09-04): 실제 관측(15대)에서 6개 목적지 중 2곳이 60여 m 돌고, 교량·광장 심각 배치에서는 4곳이 돈다 — 신길역 +1,278m에 22분 단축, 국회의사당역 +312m에 12분 단축. (2026-09-06 정정) 이 가정 배치의 분 수는 9/5 의 ÷1.4 정정(아래) 뒤 다시 계산해 이벤트광장→여의도역 최단거리 45분 vs 혼잡 회피 21분이 됐다(docs/deck/route_demo.json). 9/5 실측 — M14 부분 닫힘. 9/4 실데이터에서는 장이 매끈해 경로가 바뀌지 않았지만(대장 M14), 9/5 발행 스냅샷 6개로 같은 계산을 다시 돌리면(tools/route_real.mjs) 6시각 × 목적지 6곳 = 36건 중 11건에서 최단시간 경로가 최단거리 경로와 달랐다. 쇼 종료 직후 21:31·21:36 에 4/6(여의도역 +196m·4분 단축 · 샛강 +239m·4분 · 신길 +69m·12분), 22:06 신길 +360m·12분, 23:02 신길 +87m·6분. 20:05 는 0/6 — 공원 전체가 붐빔이라 어느 길이나 같이 느렸다. 오늘 코드로 그날 관측을 다시 돌린 값이라 22:31 이전 화면이 실제로 그린 분 수와는 배율이 다르다(경로 선택은 배율에 거의 무관). 구현 docs/app/field.js blendSeconds(), 두 화면이 같이 쓴다. 속도식이 src/nowcast.py kladek()와 같은 값인지는 테스트가 대조한다(tests/test_routing.py).

탐색은 A*(이진 힙, 직선거리 휴리스틱)를 두 단계로 돈다. 1단계는 보행로·횡단보도·보행자 도로만 허용한 부분 그래프(출발·도착 180m 안에 같은 연결 성분이 있을 때), 2단계는 자동차전용·진입금지를 뺀 OSM 전체다. 화면에는 어느 단계로 찾았는지 표시한다. 브라우저 비용(맥 데스크톱, Node/V8): JSON 파싱 22ms · 그래프 구성 17ms · A* 5ms. 모바일은 몇 배로 본다.

도보 소요 시간은 §3.2와 같은 Kladek 속도식이다 — 처음 300m는 관람구역 밀도 3.0명/m², 이후 가로 1.5명/m². 경로탐색 모듈의 초기 구현은 상수 75m/분(1.25m/s)이어서 같은 1.47km 경로가 20분으로 나왔고, §3.2 기준으로는 39분이다(2026-09-03 정정 — 경로 길이를 1.82km 로 잡아 24분·47분으로 적었던 것을 재현값 1.47km 기준으로 고친다. 2배 차이라는 결론은 그대로다). 2배 차이는 원본이 축제 밤의 밀도를 넣지 않아서 생긴다. 관람객 화면(docs/go.html)은 그때 두 값 중 어느 쪽도 아닌 67m/분을 썼다 — 같은 경로가 22분으로 나왔다. (2026-09-04 결정) 두 화면 모두 위 \(c(e)\)의 구간별 시간을 그대로 표시한다. 같은 경로가 실제 관측(한산한 아침)에서 49분, 관측이 없으면 가로 기본(1.5명/m²)으로 30분이다. 세 값 사이의 선택은 이것으로 닫혔다. (2026-09-05 정정) 화면이 쓰는 밀도 사다리에서 여유 1.5 → 0.5명/m²(4.7km/h), 못 본 길의 가로 기본 1.5 → 0.8명/m²(4.2km/h)로 낮췄다. 1.5명/m² 는 Kladek 식으로 2.9km/h 라 한산한 새벽에도 같은 1.47km 가 32분으로 읽혔다 — 지금은 관측이 없으면 21분, 여유 관측이면 19분이다. 주의 이상은 그대로라 붐비면 여전히 느려진다. 모델의 도달 지연(§3.2, 첫 300m 3.0·이후 1.5)은 바꾸지 않았다 — 화면 시간과 모델 지연의 가로 밀도가 이제 다르다. 두 값 모두 가정이고 9/5 실측 뒤 다시 본다. (2026-09-05 22:30 정정, 당일) 걷는 시간 = Weidmann 시간 ÷ 1.4(속도 ×1.4, 자유보행 1.34 m/s 상한). Weidmann 식은 3.5명/m² 에서 0.8 km/h 까지 떨어지는데, 서울시 「붐빔」 배경 관측이 깔린 광장 일대(u≈0.8)에서 여의도역 1.4 km 가 72분으로 읽혔다 → 51분. 22:20 에 먼저 넣은 속도 바닥 2.2 km/h 는 주의·경계·심각의 시간 차를 지워 10분 만에 철회했다. 1.4 는 가정값이고 속도식 자체(§3.2, 모델 지연)는 그대로다. (2026-09-04 정정) 같은 날 관람객 화면을 v2 로 바꿨다. 경로는 두 화면이 같은 보행망 A* 와 같은 비용 \(c(e)\) 를 쓴다 — 관람객 화면은 첫 답을 늦추지 않으려고 보행망(5.9MB, 전송 0.8MB)을 첫 화면 뒤에 받고, 받기 전에는 역별 근사 경유점(직선합 ×1.15) 위에서 같은 속도식으로 시간만 세며 화면에 「근사」라고 적는다(같은 날 오전 한때 근사만 쓰기로 했다가, 근사 직선은 붐비는 곳을 돌아가지 못해 되돌렸다). 관람객 화면의 추천 1위는 부하율이 아니라 도보 + 대기 시간 오름차순이다(운영 화면·이 보고서의 순위는 부하율 그대로). 혼잡 가중 1.25는 출처 없는 추정치였다. (2026-09-03 정정) 이 보행망의 우회비는 이벤트광장→여의도역 직선 1,120m 대 경로 1,471m = 1.31배이고, 모델의 우회계수 1.3(§3.2)과 거의 같다. 초기 구현 문서(routing/README.md)가 적은 1,820m·1.64배는 지금 보행망에서 재현되지 않는다 — 마포대교 보완 간선과 태그 필터를 넣고 빼 본 네 조합이 모두 1,471m 였고, 같은 계산이 이벤트광장→마포역 1,907m(9/2 실측)는 정확히 재현한다. 따라서 "실측이 모델보다 크므로 보정이 필요하다"는 앞선 서술은 철회한다. 우회계수 1.3은 이 한 구간에서 잘 맞지만 표본이 하나뿐이라, 9/5 이후 여러 구간으로 다시 볼 항목으로 남긴다. 지도 데이터는 © OpenStreetMap contributors, ODbL. 구축·편입 기록: 저장소 routing/README.md.

3.11 버린 결정 — 과정의 기록

맞는 답만큼 중요한 게 "왜 그 길로 안 갔나"다. 심사 항목("만든 과정")이기도 하다.

4아키텍처 — 전체가 어떻게 맞물리나

4.1 3층 구조

핵심 설계 원칙: 아래층이 죽어도 위층이 산다. 라이브 수집이 전부 실패해도 사전 예측표가 있고, 인터넷이 끊겨도 기기에 저장된 마지막 화면이 있다.

도식 읽는 법: [사전층]의 산출물을 [당일층]이 보정하고, 그 결과를 [화면층]이 보여준다. 당일층이 멈추면 화면층은 사전층의 예측표를 그대로 쓴다.

[사전층]  행사 전에 완성 — 라이브 없이도 서비스 성립
  data/raw (KT 이동·승하차·교통카드 원본)
    ├─ baseline.py ──────▶ 유출 곡선·역별 처리용량
    ├─ exit_shares.py ───▶ 출구별 실측 인파 E_st  ← 모델의 뼈대
    ├─ line9_capacity.py ▶ 9호선 용량 추정
    └─ backtrack.py ─────▶ 출발역 역추적 + 2026 사전 예측표
         └─ backtest.py ─▶ 타임머신 검증 (§3.5 표)

[당일층]  9/4·9/5 — run_all.sh 가 프로세스 3개를 띄우고 워치독이 지킨다
  ① collector_api.py ── 도시데이터 5분 (여의도 3곳 상시 · 피더 12곳 12~19시)
                        + 실시간 지하철 도착 17~23시 ──────────────┐
  ② collector_cctv.py ─ TOPIS 23대, 60초 (프레임 미저장 · 집계만) ─┼─▶ ③ nowcast.py ─▶ publish.py
  쇼 종료 실시각 (현장 기입 · 형식·범위 검사) ─────────────────────┘   5분 루프 · α 갱신·통제 이월·보행 지연
     워치독  30초마다 생존 확인·재기동 · 수집 로그 10분 정체 경고 · 10분에 5회 넘게 죽으면 300초 간격
     발행    내용이 같으면 커밋 안 함 · push 실패 시 pull --rebase 후 재시도, 충돌이면 abort + 경보
             연속 실패 횟수는 data/live/publish_fail_streak ──▶ GitHub Pages

[화면층]  정적 웹페이지 (서버 없음) — 출구 랭킹 · 지도(혼잡장 + 회피 경로, MapLibre) · CCTV 카드
  라이브 최신이면 "LIVE" · 15분 넘게 안 오면 "오래됨" · 아예 없으면 사전 예측표
  + 기기 저장(localStorage)으로 오프라인 폴백 · 지도 라이브러리·WebGL 실패 시 안내 문구로 폴백

당일층의 워치독·발행 방어·입력 검사는 9/1 자체 검증(§5, C2~C5)의 조치다. 9/2 저녁 30분 시험 운전이 이 조치들이 실제 수집기와 함께 도는 첫 실행이었고(고장 주입으로 워치독 재기동 1초 확인), 9/4 17:08 → 9/6 01:01 의 32시간 본번 운전에서 재기동 1회(계획된 간격 전환) · 크래시 0 · 슬립 공백 0 으로 지났다(§6.1).

4.2 데이터 소스 — 전부 공개·합법 데이터

원칙: 모든 숫자에 출처·기준일을 남기고, 추정치는 "추정"으로 표기한다. 빈칸을 지어내지 않는다. 데이터셋 ID·링크·사용 범위는 §8에 상세히 정리했다.

4.3 2026 예측 미리보기 (사전 예측표, 2년 평균 [예측 범위])

표의 숫자가 뜻하는 것 (2026-09-01 자체 검증 H4·M1 · 2026-09-03 수치 정정). 헤드라인 부하율은 2024·2025를 각각 계산해 평균한 값이다. 여의나루 22시 1.00은 2024년 0.72와 2025년 1.28의 평균이고, 화면의 대기 8분은 0분과 17분의 평균이다 — 부하율 1.00이면 대기가 사실상 0(0.2분)이어야 하므로 두 숫자는 어느 한 해의 상태가 아니다. 사실 그대로 말하면 "2년 중 1년은 용량을 28% 넘겼다"이고, 범위 [0.65~1.41]이 그 정보를 담는다. (2026-09-03 정정) 이 문단은 9/2까지 같은 자리를 0.91 [0.57~1.30]·대기 6분·"19% 초과"로 적었다. 부하율의 분자에 평시 토요일 승차가 빠져 있었기 때문이다(결함 H9) — 분모인 처리용량은 축제일 총 승차의 시간당 최댓값이라 분자도 평시 + 초과여야 단위가 맞는다. 고친 뒤 여의나루 22시는 경계에서 심각으로 올라갔고, 21시 여의도(9)·국회의사당은 0.50 동률이 됐다. 결론의 방향(여의나루 22시가 최악, 2년 중 1년은 용량 초과)은 그대로다. 또 하나의 한계: 순위는 선택한 시각의 부하율로만 매긴다. 21시 1·2위인 신길(도보 58분)·마포역 도보(43분)는 21시에 출발하면 22시에 닿는데 보여 주는 값은 21시 것이다. 도달 지연 \(\tau_{st}\)를 수요 배분에는 쓰면서 랭킹에는 아직 쓰지 않는다. "지금 출발 → 도착 시각 기준" 정렬은 다음 단계 개선안이다(§6.4).

(2026-09-06 실측 대조) 9/5 화면의 하루 최대 부하는 여의나루 22시 0.93(재개통 직후) · 샛강 0.85 였고 등급은 「경계」까지, 「심각」은 없었다. 사전표의 여의나루 22시 1.00 [0.65~1.41] 안에 들어온다. 실제 통제는 공지(20:40~21:40)가 아니라 18:10~22:05 였다 — 19시 통제를 당일 19:13 에 규칙에 추가했다(H3 확인, §6.1).

5자체 적대적 검증 — 우리 것을 먼저 깨 봤다

9/1, 실전 나흘 전에 공격자 관점으로 모델·파이프라인·대시보드를 깬 것을 시작으로, 실전 뒤까지 7회차 39건(치명 6 · 높음 10 · 중간 16 · 낮음 7, 철회 1)을 등재했다. 1~2회차는 코드를 읽었고, 4회차는 다른 모델(Codex)에게 전체 diff 를 주고 설계를 공격시켰으며, 3·5·6·7회차는 실행(시험 운전·야간 연속 운전·본번)에서 찾았다. 치명·높음은 전부 조치했고(C1 은 서술로 닫음), 중간·낮음의 보류 판단은 결함 대장에 근거와 함께 남겼다. 방법은 Claude Code에 "이 저장소를 깨라"는 공격 프롬프트를 주고, 모든 지적에 파일:줄 또는 데이터 파일로 재현 가능한 근거를 요구한 것이다.

5.1 먼저, 깨지지 않은 것

공격이 통하지 않은 곳도 기록한다 — 같은 곳을 다시 파지 않기 위한 기록이다. API 키 유출(추적 파일·라이브 데이터·로그 전수 검색, 히트 0) · 오류 로그로 키가 새는지(가짜 키로 실제 호출, 예외 문자열에 키 없음) · HTML 이스케이프(API 유래 문자열 17곳 전부 적용) · 표 3-2·3-4·3-5·3-6 수치(원본 JSON에서 역산, 전부 일치) · KaTeX 렌더(3개 폭에서 DOM 계측, 에러 0·넘침 0) · 스테일·오프라인 폴백(3일 지난 데이터로 렌더, 사전 예측표로 정상 강등) · 지도 실패(라이브러리·WebGL 차단, 안내 문구 폴백).

5.2 결함 39건 — 7회차

표 5-1 — 회차별 발견과 처리 (2026-09-08 기준)

결함 대장은 저장소 redteam-20260901.md 하나이며 상태가 바뀌면 그 문서가 먼저다. 덱·보고서의 건수는 tools/deck_data.py 가 대장에서 세고 테스트가 대조한다.

표 5-1b — 1회차(9/1) 결함 18건과 처리

5.3 조치는 실패하는 테스트부터

즉시 5건과 H2·H5는 결함을 재현하는 테스트를 먼저 써서 실패를 확인한 뒤 고쳤다. 신규 테스트 15건 중 13건이 그렇게 빨강→초록을 거쳤고, 2건은 기존 동작을 굳히는 회귀 가드라 처음부터 통과했다. 테스트는 26 → 41 → 45건이 됐고(§3.5), 이후 회차와 기능을 거쳐 9/8 기준 122건이다. 조치 자체가 만든 새 실패 모드 3건도 같이 닫았다 — 고치기 전에는 없던 위험이라 남겨 두면 순손실이다.

표 5-2 — 조치가 스스로 만든 실패 모드

5.4 범위와 한계

전수 감사가 아니다. 1회차가 읽은 것은 nowcast.py · collector_api.py · publish.py · backtrack.py(출구 계산부) · run_all.sh · index.html · report.html과 data/derived/ 산출물이다. 읽지 않은 것은 collector_cctv.py · evaluate.py · exit_shares.py · feeder_leadlag.py, 쉬운 버전·피치 덱, 그리고 9/1에 새로 들어온 field.js(혼잡장) · routing/(경로탐색) · tools/demo.sh다. collector_cctv.py는 구역 밀도를 도달 지연 계산에 직접 먹이는 미감사 입력 중 가장 큰 것이고, 혼잡장은 공개 화면에서 가장 눈에 띄는 요소라 2회차의 1순위다. 결함 대장은 저장소 redteam-20260901.md 하나이며 이 절은 그 요약이다 — 상태가 바뀌면 그 문서가 먼저다. (2026-09-08 추기) 위에 적은 미감사 파일은 2회차가 읽었고(collector_cctv.py·field.js·routing/), 4회차는 다른 모델이 전체 diff 를 공격했다. 5~7회차는 코드가 아니라 실행에서 찾은 것이라 코드 감사 범위와는 별개다.

6실전 결과 — 2026-09-05 당일

9/4 17:08 에 켠 파이프라인을 끄지 않고 9/6 01:01 까지 32시간 돌렸다. 전야제와 본번을 한 번의 운전으로 지났고, 본번 12시간 동안 5분마다 예측을 발행했다. 채점 숫자는 전부 src/evaluate.py --date 20260905(data/derived/eval_20260905.json)에서 가져왔다. 그 시각 화면은 운영·관람객 재생으로 그대로 열린다 — 배너 칩으로 20:05 → 23:02 여섯 시점을 오간다.

6.1 운전 기록

표 6-1 — 당일 수정 4건 (회귀 테스트 통과 후 배포)

6.2 채점 — 맞힌 것과 놓친 것

세 가지를 쟀다. ① 오늘 배율 α 가 어떻게 움직였나 ② 유출 곡선의 형태가 실측 승차와 맞나 ③ 같은 도시데이터를 쓰는 서울시 12시간 선행 예측은 얼마나 맞았나(기준선). 규모의 절대값은 실측(핫스팟 9역 30분 승차 합)과 우리 예측(출구 7곳)의 범위가 달라 비교하지 않는다 — 피크 대비 비율만 비교한다.

표 6-2 — α 궤적 (사후 p50 · 관측 수 하차·승차)

표 6-3 — 유출 곡선의 형태: 22시 피크 대비 비율 (실측 = 핫스팟 9역 30분 승차 합 · 예측 = 출구 7곳 유출)

맞힌 것 — 피크 시각 22시가 일치했고 형태 상관은 r 0.66 이다. 놓친 것 — 23시 꼬리. 실측은 피크의 92% 가 23시에도 이어졌는데 예측은 41% 로 꺼졌다. 원인 후보는 둘이다. ① 감쇠 형태 \(f_s(h)\) 가 2024·2025 실적에서 왔는데 2026 은 여의나루 조기 무정차(18:10~22:05)로 승차가 22시 뒤로 밀렸다. ② 쇼 종료 +17분을 반영해도 꼬리의 폭은 늘지 않는다. 조치는 보류했다 — 2026 실측 하루로 꼬리 파라미터를 다시 맞추면 과적합이다. 결함 대장 M15.

표 6-4 — 기준선: 서울시 12시간 선행 예측 vs 실측 (여의도한강공원 실시간 인구, 명)

하루 MAPE 0.56, 예측 범위 적중 4%. 같은 도시데이터를 쓰는 공식 선행 예측이 저녁 피크를 9배 낮게 봤다. 우리 α 를 5분마다 관측으로 갱신해야 하는 이유의 실측 근거다. 이 표는 우리 모델과의 직접 비교가 아니라 "선행 예측만으로는 안 된다"는 기준선이다.

이 밖에 실측이 확인해 준 것 — 조기 무정차의 방향(H2 의 "공지 시각 + 예년 이력" 병기가 맞았다) · 쇼 종료 기입 경로(C4)가 본번에서 한 번 작동했다 · 실측 장에서 최단시간 경로가 실제로 바뀌었다(36건 중 11건, §3.10 · M14 부분 닫힘) · 서울시 API 발행 시차 28.8분(2회차 가설 확정, M16). 미검증으로 남은 것 — 대기 분 문구(스톱워치 실측 없음).

6.3 실측이 닫은 열린 질문

1. C1 α 밴드 — 밴드는 그대로 두고 실제 오차 하한(교차연도 0.42~0.44)을 §3.4 에 못 박았다(9/6). 본번 마감 밴드 ±6% 와 나란히 읽는다.
2. 전야제 합격선 — 9/4 전야 관측으로는 "평시 금요일의 1.9배" 기준을 판정하지 못했다. 판정 불가로 기록하고, 파이프라인 정상 여부는 발행 주기·재기동 0·α 갱신으로 확인했다(§3.8).
3. 쇼 종료 실시각 기입 — 21:27 에 한 줄 기입, 예측이 즉시 밀렸다(§6.1).
4. 현장 관찰 — 여의나루 실제 무정차 18:10~22:05, 공지와 달랐다. 19시 통제를 당일 규칙에 넣었다.
5. 경로 소요 기준 — §3.10 에서 닫았다(구간별 Kladek 시간, 9/5 ÷1.4 정정 포함).

6.4 다음 단계

• 꼬리 형태 — 감쇠 \(f_s(h)\) 를 2026 을 포함한 3년으로 다시 맞추되, 조기 무정차가 있는 해와 없는 해를 나눠 본다(M15)
• 혼잡장 — 길이척도·σ 를 9/5 관측으로 LOO 교차검증(§3.9) · 유클리드 대신 보행망 거리 커널
• 순위 — 부하율이 아니라 "지금 출발 → 도착 시각" 기준 정렬(M1)
• 사전 예측표 — 2022·2023 을 더한 4년 기준(표 3-4b)
• 운전 — 자정을 넘기지 않는다(L3·L7). CCTV 근경 ROI 재측정으로 보정 카메라를 되살린다(H6)

7용어 사전

부하율

수요 ÷ 처리용량. 1.0이면 그 시간에 온 사람을 그 시간에 딱 다 태우는 상태. 넘으면 줄이 쌓인다.

초과 승차

축제일 승차 − 평시 토요일 중앙값. "평소에도 그 역을 쓰는 사람"을 빼고 남는 순수 축제 인파.

중앙값

여러 토요일 값을 줄 세웠을 때 한가운데 값. 평균과 달리 명절 같은 특이한 날에 안 끌려간다.

백테스트

과거의 한 시점으로 돌아가 "그때 알 수 있던 것만으로" 예측해 보고 실측과 비교하는 검증.

사전 예측표 / 나우캐스트

사전 예측표 = 행사 전에 과거 데이터만으로 만든 예측. 나우캐스트 = 당일 관측을 반영해 5분마다 갱신하는 예측.

α (알파)

오늘 인파가 예년 평균의 몇 배인지 나타내는 배율. 당일 관측으로 계속 갱신.

예측 밴드

"0.62가 아니라 0.55~0.70 사이" — 예측의 불확실성 폭. 관측이 쌓이면 좁아진다.

피더(feeder)역

축제 관람객이 여의도로 오려고 지하철을 탄 출발역. 여의도로 사람을 "공급"하는 역.

ROI (관심 영역)

CCTV 화면에서 계산에 넣을 부분만 오려낸 다각형. 우리는 "축제일에 보행로가 되는 차도"를 지정.

이월 규칙

역이 통제된 시간에 도착한 사람들을 "해제 후 첫 시간대"의 수요로 옮겨 세는 규칙.

혼잡장

지도 위 점 관측(CCTV·구역 등급)을 메워 만든 "어디가 얼마나 붐비나"의 면. 색은 혼잡, 진하기는 확신.

가우시안 과정 회귀

가까운 관측일수록, 믿을 만한 관측일수록 더 믿어 점 사이를 메우고, 관측 없는 곳은 "모른다"(분산 큼)로 남기는 통계 기법.

커널 · 길이척도

커널 = 두 지점이 얼마나 닮았을지를 거리로 정하는 규칙. 길이척도 = 그 닮음이 사라지는 거리 규모(150m·1,200m).

관측 노이즈 σ

관측 하나를 얼마나 못 믿는지의 폭. 클수록 그 관측이 장을 덜 끈다. 배제 대신 쓰는 손잡이.

LOO 교차검증

관측 하나를 빼고 나머지로 그 자리를 맞혀 보는 검사. 혼잡장의 길이척도·σ 가정을 9/5 이후 이것으로 고른다.

A* 탐색

목적지까지 남은 거리를 힌트로 삼아 최소 비용 경로를 찾는 알고리즘. 여기서 비용은 그 구간을 걷는 데 걸리는 시간이다(거리 ÷ 혼잡도별 보행속도). 붐비는 길은 느려지므로, 충분히 국소적인 혼잡이면 돌아가는 쪽이 더 빠르다. (2026-09-04 변경 — 전에는 거리 × (1 + 1.25 × 혼잡)이었다.)

워치독

프로세스가 살아 있는지 주기적으로 보고, 죽었으면 다시 띄우는 감시 루프.

적대적 검증(레드팀)

만든 사람이 공격자 입장으로 바꿔 자기 시스템을 깨 보는 검증. 지적마다 재현 근거를 붙인다.

8참고문헌·데이터 출처

8.1 데이터 출처 (상세)

원본 대용량 파일은 저장소 밖 보관(공개 Release 예정). 전 데이터셋 재다운로드 명령은 저장소 data/README.md.

8.2 참고문헌

1. Santanam, Trasatti, Van Hentenryck, Zhang (2021). Public Transit for Special Events: Ridership Prediction and Train Optimization. arXiv:2106.05359 — 애틀랜타 MARTA 경기장 이벤트 수요 예측. 소표본에서 "관측 패턴 + 곡선 맞춤" 접근(선형회귀 MAPE 11.7%)의 근거. 우리 모델 구조의 직접 참고.
2. Weidmann, U. (1993). Transporttechnik der Fussgänger. ETH Zürich, IVT Schriftenreihe Nr. 90 — 보행 속도–밀도 관계(Kladek 식: 자유속도 1.34 m/s, 정체밀도 5.4명/m²). 출구 도달 지연 계산의 근거. 보행 기본도 개관: Seyfried et al.
3. Wang, Liu, Samaras, Hoai (2020). Distribution Matching for Crowd Counting (DM-Count). NeurIPS 2020 — CCTV 군중 카운팅 모델. lwcc 라이브러리로 사용. 자체 검증: 밀집 군중 사진에서 밀도맵 계열 3종 합의 ±12%, 객체 검출(YOLO)은 12배 과소 → 밀도맵 채택.
4. 특별행사 지하철 수요 문헌: Beijing 다변량 교란 DNN (ESWA 2021) · 역간 상호작용 실시간 예측 (Transp. Res. Part C 2018) — ML 계열 접근의 데이터 요구량 확인(수년치 필요), 구조 모델 선택의 방증.
5. 서울시 지하철 혼잡도 기준 (서울시) · 국토부 도시철도 정거장 설계지침 (고시) — 용량·혼잡 등급 기준. 정거장 시설별 처리량(pph) 확보 시 9호선 추정 용량 대체 예정.
6. Rasmussen, C. E. & Williams, C. K. I. (2006). Gaussian Processes for Machine Learning. MIT Press. gaussianprocess.org/gpml — 혼잡장(§3.9)의 사후 평균·분산 식과 Matérn 커널의 근거.

8.3 벤치마크한 기존 시스템 (11건 중 대표)

• TfL(런던) Wi-Fi 기반 역 혼잡 안내 · Google 지도 Popular Times — "평소 대비 %" 표현 방식 차용
• Paris 2024 올림픽 anticiperlesjeux — 시간×역 격자 사전 안내 (UI 참고)
• Amsterdam CMSA/Public Eye — 카메라 군중 계수의 공공 운영 사례 (프라이버시 설계 참고)
• Yahoo! Japan 混雑レーダー — 불꽃축제 혼잡 히트맵의 원조 사례
• 서울교통공사×SKT 칸별 혼잡도 (OA-12928) — 열차 내 혼잡, 우리와 보완 관계
• 상세 대조표·채택/기각 근거: 저장소 benchmark-crowd-systems.md

8.4 도구

• Claude Code — 데이터 수집·모델 구현·테스트·문서 작성 보조, 그리고 §5의 자체 적대적 검증(공격 프롬프트 → 파일:줄 근거 → 실패하는 테스트 → 수정). AI 활용 기록은 커밋 로그와 저장소 문서에 단계별로 남김
• Python (pytest 122건 상시 검증, OpenCV 프레임 처리) · node (혼잡장 field.js 단언 22개) · MapLibre GL + OpenFreeMap (지도) · OpenStreetMap (보행망, ODbL) · 서체 (마루부리·Pretendard·IBM Plex Mono) · GitHub Pages (호스팅)