그래서 모두가 같은 곳으로 몰리고, 역 앞에서 몇 시간을 서 있게 된다. 문제는 정보 부족이 아니라 "오늘만의 규칙"을 아는 지도가 없다는 것이다.
출구 7개의 혼잡을 시간대별로 미리 예측해서, 신호등 색으로 보여주는 웹페이지를 만들었다.
쇼 직후 21시의 예측 화면 축소판. 핵심은 상태("혼잡함")가 아니라 행동("신길로 가라")을 알려준다는 점이다.
사람들의 귀가 습관은 해마다 거의 같았다. 여의도(5)역으로 29%, 샛강으로 17%… 이 비율이 2년 연속 그대로다. 그래서 "작년처럼 움직인다"를 뼈대로 쓰고, 올해 다른 부분만 고치면 된다.
케이크에 비유하면 — 오늘 케이크의 크기(α)를 재고, 작년과 같은 비율로 자르고(몫), 걷는 시간만큼 늦게 내놓는다(도착).
머신러닝을 안 쓴 이유: 배울 데이터가 축제일 이틀뿐이다. 이틀로 학습시키면 "외우기"가 된다. 대신 사람이 부품 하나하나 검증할 수 있는 곱셈식을 골랐다.
2025년 답안지를 가리고, 2024년 공부만으로 2025년 문제를 풀어 봤다. 그리고 실제 2025년 기록과 채점했다.
출구 혼잡 "등급"(여유/주의/경계/혼잡) 기준. 남은 불확실성은 숨기지 않고 "0.65~1.41" 같은 범위로 함께 보여준다 — 모르는 것을 아는 척하지 않는 게 이 서비스의 원칙이다.
여의도로 오는 사람들은 그날 어딘가의 역에서 지하철을 탔다. 멀리서 오는 사람일수록 먼저 탄다. 그래서 출발역들의 승차를 지켜보면, 여의도가 붐비기 전에 미리 안다.
| 출발역 | 여의도까지 | 신호가 오는 때 | 일치도 r |
|---|---|---|---|
| 성수 | 35분 | 1시간 먼저 | 0.95 |
| 영등포시장 | 3분 | 같은 시각 | 0.86 |
| 김포공항 | 25분 | 제외 (공항 유동 혼입) | −0.19 |
12곳 전체 표와 판정 기준은 자세한 보고서 §3.6에 있다. 이 신호는 축제 당일 예측에 바로 넣지 않고 관측만 한다 — 분 단위 정확도를 아직 검증하지 못했기 때문이다.
쇼 직후 가장 위험한 곳은 제일 큰 여의도(5)역이 아니라 샛강역이다. 9호선 역이라 처리 용량이 작다.
통제가 풀리면 기다리던 사람들이 한꺼번에 몰린다. 부하 1.00 — 그날 밤 최고치이자 용량 한계다. 이 값은 두 해 평균이고, 2년 중 1년은 용량을 28% 넘겼다.
이 둘은 지도앱이 절대 알려주지 못한다. 우리 서비스가 존재하는 이유다.
설계 원칙: 아래층이 죽어도 위층이 산다. 축제날 밤 통신은 반드시 느려지기 때문에, 처음부터 그걸 전제로 만들었다.
9/1, 실전 나흘 전에 "이 시스템을 깨라"는 주문을 AI(Claude Code)에 주고, 지적마다 어느 파일 몇 번째 줄인지 근거를 요구했다. 시험 전날 친구에게 답안지를 주고 틀린 데를 찾아 달라는 것과 같다.
일곱 차례. 치명 6 · 높음 10 · 중간 16 · 낮음 7. 예컨대 "발행이 실패해도 아무도 모른다", "관람객 화면 지도가 처음부터 안 그려졌다".
고치기 전에 실패하는 테스트부터 썼다. 자동 테스트가 22개에서 122개가 됐다. 한 번은 다른 AI(Codex)에게 우리 것을 공격시켰다.
코드로 못 고치는 약점 — 이를테면 "9호선 3개 역은 검증 데이터가 없다". 남이 찾기 전에 보고서에 적었다.
예측 범위는 그대로 두되 "실제 오차는 이보다 못하지 않다"는 하한(42~44%)을 보고서에 못 박았다. 좁은 범위를 믿지 말라는 뜻이다.
전체 목록과 처리 근거는 자세한 보고서 §5와 저장소의 redteam-20260901.md에 있다.
9/4 오후 5시에 켠 시스템을 끄지 않고 9/6 새벽 1시까지 32시간 돌렸다. 본번 12시간 동안 5분마다 예측을 발행했다 — 287번.
가장 붐비는 시각 22시. 유출 곡선의 모양이 실측과 0.66 상관.
같은 데이터로 12시간 전에 낸 공식 예측이 저녁 피크를 9배 낮게 봤다. 5분마다 다시 재야 하는 이유다.
23시 꼬리. 하루치 실측으로 고치면 외우기가 되니 고치지 않고 적어 두었다.