/board 를 A18 에 맞추면
백엔드는 무엇이 달라지나

1. 한 장 요약 A18 채택 시 백엔드가 새로 하는 일

DB 쪽 수치의 정본은 파이프라인 계약 v4 에 있다. 실측 열의 근거는 7절 끝의 접힌 목록에 있다.

정원이 A18 에만 걸리는 이유는 레인 A 모델의 입력이 노선·정류장 순번·시간대 셋뿐이어서다. A18 은 현재 잔여석 ÷ 정원을 점유율로, 좌석 감소 ÷ 정원을 순수요로 쓰므로 정원이 틀리면 두 값이 함께 어긋난다. 정원은 차량마다 그 차가 보여 준 최대 잔여석이다. 전수 22,010 스냅샷에서 말뭉치가 일곱 갈래로 갈리고(44석 35,615행 · 45석 5,719 · 40석 5,134 · 68석 4,479 · 49석 1,232 · 36석 17 · 41석 15) 최빈값은 45가 아니라 44다. 종전 47 은 어느 근거에도 없던 수였다. 이것은 모델이 쓰는 정원이고 차량의 형식승인 좌석수와는 다른 양이다 — 저상 신차는 형식승인이 41 로 유력하고, 잔여석이 형식승인 좌석수를 넘는 차량도 49대 중 6대 있다. 사이트 원칙대로 둘을 하나로 합치지 않고 출처별로 남긴다. 정원은 DB 열이 아니라 번들의 특징 계약이 소유한다.

2. 모듈 경계 주기 · 상태 · 지연 예산으로 가른다

A18 은 지금 파이프라인에 없는 네 가지를 요구한다 — 회차 키 판정 · 셀 통계 집계 · 차량별 추론 · 정류장 조립이다. 넷은 도는 주기가 서로 다르고, 같은 자리에 놓으면 빠른 쪽이 느린 쪽에 끌려간다. 여기에 계약이 하나를 더 얹는다 — 방향별 첫차·막차는 A18 이 재료로 쓰지 않는데 응답에는 실린다.

회차 키를 적재 시점에 정하는 이유

A18 은 "j정류장 전 그 버스의 좌석"과 "앞선 정류장들에서 좌석이 줄던 속도"를 쓴다. 둘 다 같은 차량의 같은 운행 안에서만 뜻이 있다. 한 차량이 하루에 노선을 여러 번 돌면 같은 순번을 여러 번 지나므로, 운행을 나누지 않으면 이번 운행의 9번 정류장과 다음 운행의 17번 정류장이 짝지어진다.

조회 때마다 관측을 거슬러 훑는 방법도 있다. 그렇게 하지 않는 이유는 학습 쪽과 서빙 쪽에 같은 분할 로직이 두 벌 생기기 때문이다. 둘이 어긋나는 순간을 아무도 못 잡고, 오프라인 성적이 온라인에서 재현되지 않는다. 적재할 때 한 번 정해 열에 남기면 그 위험이 사라진다. 분할 규칙은 location_poll.normalizationVersion 에 속한다 — 새 규칙은 새 정규화 판이다.

판정 규칙 자체는 새로 정하지 않아도 된다. v3 의 학습 라벨 조건에 "같은 차량 · 회차"가 이미 들어 있다. 다만 그 판정을 연구 export 가 수행했을 뿐 저장하지 않았고, A18 은 서빙 시점에도 같은 판정을 해야 한다. poll 이 끊겨 직전 관측을 잃으면 경계를 놓칠 수 있는데, 그때는 보수적으로 끊는다. 여정을 끊어도 예보는 낸다. 설계행렬이 상류 좌석 기울기와 직전 좌석에 각각 결측 지시자 열을 갖고 있어, 여정의 첫 관측이든 vehicleId 가 없는 관측이든 같은 방식으로 점수화된다. 여정 키가 없으면 라벨 회수만 못 한다.

예보를 못 내는 자리는 따로 있다 — 잔여석이 결측인 관측이다. 설계행렬이 잔여석을 세 열로 그대로 쓰고 앵커도 거기서 출발하는데, 그 자리에는 기울기·직전 좌석과 달리 결측 지시자가 없다. 예보를 내지 않는다는 것은 그 항목을 담지 않는다는 뜻이다. v4-fe 확정본에서 seatAvailableProbability 는 StopArrival 의 필수 필드라 "예보 없는 arrivals 항목"이라는 상태가 계약에 존재하지 않는다. 빈 자리를 표시할 필드가 없으므로 항목째로 빠지고, 그것이 정상 응답이다. 상태 코드도 사유 코드도 새로 만들지 않는다.

회차는 운행의 끝이 아니다

두 노선은 왕복이고 중간의 안양역(208000069)이 회차 지점이다 — 1650 은 순번 44, 3330 은 43 이다. 재어 보면 회차를 이어서 지난 운행이 1650 94.0% · 3330 72.4% 이고 회차 전후 관측 간격은 중앙 0.3분이다. 차고지에 서지 않고 지나간다는 뜻이다. 그래서 회차 키는 회차마다 끊는 키가 아니라 운행마다 끊는 키다. 회차에서 끊으면 재구성한 운행의 순번 폭 중앙 86/89(1650)·81/85(3330) 가 절반으로 잘려 상류 좌석 기울기의 재료가 사라진다.

회차 너머 정류장에도 예보를 내야 한다 — arrivals 항목의 10.0%(1650)·12.8%(3330) 가 여기 해당하고, 그 버스들은 진짜로 오고 있는 버스다. 다만 근거가 바뀐다. 회차를 넘는 순간 차량의 현재 잔여석이 도착 잔여석을 설명하지 못한다 — 지평 8에서 R² 가 0.178 에서 0.011 로 떨어지고 상관이 음수로 뒤집힌다. 그런데도 예보는 맞는다. 회차 넘는 표본의 평균 점유율이 0.105 이고 점유율 0.7 이상이 0건이라, 지평 8에서 실제 만석률 0.000% 에 최대 예측 0.020 이다. 회차 너머 예보를 내는 것은 차량 상태가 아니라 정류장 통계다. 모델은 turnSeq 를 입력으로 받지 않는다 — 셀 층이 그 구간을 이미 학습하고 있다.

백엔드에 주는 뜻은 하나다. 회차 횡단 여부는 서버가 저장하지도 계산하지도 않는다. v4-fe 확정본은 그 판정을 클라이언트에 넘겼다 — sequence − horizonStops 로 차량의 현재 순번을 얻고 route.turnSequence 와 견주면 끝나는 순번 비교 하나이고, 두 재료가 모두 응답 안에 있다. 서버가 필드를 하나 더 두면 같은 판정이 두 곳에 생기고, 그 값이 틀려도 확률은 그대로라 아무도 어긋남을 못 잡는다. 계약에서 지운 것이 아니라 애초에 서버의 일이 아니다. 다만 채점을 회차 횡단 여부로 가를 때는 서버 쪽에서도 같은 식을 쓴다 — 저장이 아니라 조회 시 유도다.

계산 단위는 차량이고 조립 단위는 정류장이다

새 /board 는 정류장 관점의 응답이지만, A18 의 계산 단위는 여전히 차량이다. 순번 v 에 있는 차량 하나가 지평 1~12 의 예보를 내면 그것이 곧 순번 v+1 … v+12 정류장의 arrivals 항목이 된다. 둘은 같은 집합이고 방향만 다르다. 그러므로 저장은 차량 단위로 하고, 조립에서 정류장 단위로 뒤집는다. 행 하나가 지평 축(채점용)과 목표 순번 축(조회용)을 같이 들면 피벗은 인덱스 조회 하나로 끝난다.

실측 규모는 이렇다. 05~24시 poll 기준 동시에 관측되는 차량이 중앙 11대(1650)·13대(3330), 최대 28·36대다. 지평 12를 곱하면 수집 한 번에 계산할 예보가 중앙 132~156개, 최대 336~432개다. 하루로 치면 08-18 실측 기준 노선당 차량 관측 7.4만~8.2만 건이므로 예보 행이 89만~98만이 된다. 레인 A 의 stop_prediction 이 노선당 하루 340~445행인 것과 견주면 약 2,000배다. 보존 기간과 파티션 축을 먼저 정하지 않으면 이 표가 파이프라인에서 가장 먼저 문제를 낸다.

arrivals 의 범위는 계약이 닫았다

이전 안은 "다음 몇 대까지 담을 것인가"를 열린 선택지로 뒀다. 그 선택지는 사라졌다. v4-fe 확정본이 범위를 식으로 못박았기 때문이다 — max(1, sequence − 12) ≤ 차량순번 ≤ sequence − 1, 랩어라운드 제외다. 여기에 대수 상한 2가 얹힌다(maxItems: 2) — 사용자가 궁금한 것은 자기가 탈 버스이고, 세 대째는 먼저 오는 버스가 둘이라 중앙 27분을 기다려야 한다. 담을 수 있는 항목에는 예보가 반드시 붙으므로 "오고 있다만 알리는 항목"도 함께 사라졌다.

그 결과 응답 크기가 이전 추정보다 작다. 05~24시 poll 기준 노선당 arrivals 항목이 중앙 119(1650)·133(3330) 이고 정류장당 최대 2개다. 상한 없이 담았을 때의 중앙 462~554 · 최대 1,223~1,420 과 견주면 4분의 1 아래다. 지평 12 만으로도 중앙 120~150 이었으므로 대수 상한이 더 줄이는 몫은 크지 않다 — 상한 2 를 두는 이유는 크기가 아니라 "먼저 도착할 버스"라는 뜻을 지키기 위해서다. 랩어라운드를 뺀 근거도 실측이다 — 한 바퀴 돌아 오는 차량이 실제 다음 도착 차량인 경우가 5.1%(1650)·15.6%(3330)뿐이고 그 앞에 중앙 4~7대가 먼저 지나간다. 조립에서 지평 창과 랩어라운드 제외를 같은 자리에서 적용하면 규칙이 한 곳에만 산다.

차량 예보를 저장하는 이유

조회 때마다 계산하고 버리는 선택지도 있었다. 그렇게 하지 않는 근거는 팀이 cell_risk 를 버릴 때 쓴 기준 그대로다 — 그 표는 실제 관측률만 있고 모델 예측값이 없어 브라이어·로그손실·보정오차를 계산할 수 없었다. 내놓은 예보를 남기지 않으면 A18 도 같은 자리에 선다. 사이트 평가 규약의 지표는 전부 만석 여부 이진 사건에 대한 것이라 만석 확률 하나만 남겨도 사후 채점이 된다 — 분포 전체를 저장할 필요는 없다. expectedSeats 를 내보내려면 기댓값 하나가 더 필요할 뿐이다.

기존 stop_prediction 을 늘리지 않고 신설하는 이유는 단위가 다르기 때문이다. 저쪽은 (발행본, 정류장 순번)이라 한 정류장에 답이 하나인데, A18 의 답은 차량마다 다르고 같은 정류장에 대해 지평마다도 다르다. PK 에 차량과 지평을 더하면 레인 A 의 봉인 확인 3 (route_stop 대상 건수 = header 예상 = 자식 순번 집합)이 성립하지 않는다. 확장이 아니라 신설이 맞다.

셀 통계는 번들이 아니라 표에 둔다

셀 통계를 계수와 함께 불변 번들에 담는 방법을 먼저 검토했다. 그렇게 되면 표가 하나도 늘지 않고, v3 가 cell_risk 를 없애며 세운 "서버는 통계를 집계하지 않고 승인된 번들 하나만 실행한다"가 그대로 지켜진다. 그런데 셋을 따져 보면 담기지 않는다.

• 갱신 주기가 다르다. 계수는 배포할 때만 바뀌고 셀 통계는 자료가 쌓이면 다시 계산된다. 번들에 넣으면 통계 재계산 한 번마다 배포 episode 가 통째로 한 판씩 돈다. 위 그림에서 자료 시계에 있는 것을 발행 시계로 옮기는 셈이다.
• 마스킹 폴백에 표본 수가 필요하다. 셀이 얇으면 더 거친 셀로 물러나는데, 그 판정 재료인 표본 수가 관측과 함께 계속 늘어난다. 배포 시점에 굳힐 수 있는 값이 아니다.
• 학습값과 서빙값이 애초에 다르다. 학습은 LODO 교차적합이라 폴드마다 값이 다르고, 서빙은 전체 적합값 하나를 쓴다. 폴드별 값은 외부 ML 환경의 것이고 제품 DB 에 들어올 것이 아니다.

그래서 demand_profile 표를 둔다. 다만 이 결정에는 값이 따른다 — v8 도메인 문서의 "서버가 통계를 집계하지 않는다"는 문장이 실제로 움직인다. 그 문장을 세운 이유는 cell_risk 가 관측률만 있고 모델 예측값이 없어 채점이 불가능한 표였기 때문인데, demand_profile 은 채점 대상이 아니라 모델이 읽는 입력이라 성격이 다르다. 그래도 문장이 하나 바뀌는 것은 사실이므로 6절에 그대로 적어 두었다.

추론이 processor 에 있고 조립이 api 에 있는 이유

모델을 실행하는 곳은 processor 다. 그 정체성은 그대로 두는 편이 낫다 — api 가 추론하기 시작하면 요청 수만큼 모델이 돌고, 내놓은 값이 남지 않아 사후 채점이 불가능해진다. 다만 processor 의 트리거가 바뀐다: 시간대 경계(레인 A)가 멈추고 관측 적재(레인 B)가 들어온다. 레인 B 의 쓰기는 관측 INSERT 가 commit 된 뒤 별도 transaction 으로 한다 — 수집 경로의 4단계 차감 사다리는 그대로 두고, 모델 추론 시간이 수집 지연에 섞이지 않게 한다.

api 가 하는 일은 계산이 아니라 조립이다 — 최신 예보 행을 목표 순번으로 읽어 horizonStops 오름차순으로 담고, 승차 불가 정류장은 빈 배열로 두고, 스냅샷 poll 의 storedRows 를 vehiclesInService 로 붙인다. 읽기 전용이라는 경계는 유지된다. 다만 v8 이 적은 "모델이 무엇으로 바뀌어도 api 는 고칠 일이 없다"는 문장은 이번에 시험대에 오른다 — 정확히 말하면 모델이 바뀌어서가 아니라 응답 계약이 바뀌어서 고치는 것이고, 모델 계약(FullnessProbabilityModel)에 대한 의존은 여전히 없다. 그 구분을 흐리면 안 된다.

레인 B 결과에는 봉인·승격을 적용하지 않는다. 발행 원자성은 "한 판의 예보가 전부 유효하거나 전부 무효"를 보장하는 장치인데, 차량 예보에는 판이라는 단위가 없다 — 한 행이 정확히 한 관측에 매달리고 차량마다 독립이다. 차량 하나의 예보를 못 냈다고 나머지 차량의 예보를 막으면 오히려 계약을 어긴다. v3 의 "승차 가능 정류장 하나라도 실패하면 발행 전체 실패"는 레인 A 에만 걸리는 규칙으로 남는다.

vehiclesInService 와 운행 시간은 서로 다른 시계에 있다

확정 계약이 /board 에 값을 둘 더 요구한다. 둘 다 예보가 아니라 예보를 읽는 법에 관한 값이고, 나오는 자리가 서로 멀다.

vehiclesInService 는 관측 시계에 있다. 그 poll 에서 이 노선에 잡힌 서로 다른 차량 수이고, 스냅샷 poll 행의 storedRows 가 이미 그 값이라 새 조회도 새 열도 필요 없다 — 같은 poll 안 차량 중복은 부분 unique index 가 막으므로 저장 행 수가 곧 distinct 차량 수다. 이 값이 필요한 이유는 arrivals 가 빈 이유를 가르기 위해서다 — 0 이면 "운행이 끝났다" 쪽이고 0 보다 크면 "이 구간에 지금 차가 없다" 쪽이다. 다만 단정은 서버가 하지 않는다. 상류가 빈 응답을 주면 운행 중에도 0 이 되고(실측 22,010 스냅샷 중 1건, 0.005%), 심야에 빈 응답이 반복된 뒤 다음 수집에서 차량이 다시 나타난 실측도 있다. 그래서 판별자로 굽지 않고 정수 그대로 내보낸다.

방향별 첫차·막차는 기준정보 시계에 있다. 원천은 노선 기준정보의 upFirstTime·upLastTime·downFirstTime·downLastTime 이고, 받는 길이 둘이다 — 노선당 getBusRouteInfoItemv2 1콜이거나, 같은 값을 담은 노선 마스터 파일 한 벌이다. 사이트의 상류 판정은 마스터 쪽이지만(3,139개 노선을 1회 다운로드로 덮는다), 파이프라인 계약은 두 노선만 다루므로 API 1콜로 잡았다. 차량위치 poll 과는 다른 경로이므로 poll 예산에 얹히지 않는다. 저장 자리는 노선 판본 표다 — 거기 이미 기점·종점 이름과 회차 순번이 있고, contentDigest 대상에서는 빼서 시간표만 바뀌면 판본을 새로 끊지 않고 같은 행을 UPDATE 한다. 갱신은 노선당 하루 1회(KST 03:30)와 판본 신설 시점이다. 판본 신설 때만 부르는 것으로는 모자란다 — 정류장 목록이 그대로인 채 막차만 바뀌면 판본이 생기지 않아 시간표가 조용히 낡는다. 하루 2회는 위치 수집 옆에서 무시할 수 있고 예보 경로에 부하를 더하지 않는다.

방향마다 다르다는 것이 이 필드의 존재 이유다. 1650 은 상행 04:10~22:35 · 하행 05:25~23:55 로 막차가 80분 어긋나고, 3330 은 상행 04:50~23:30 · 하행 05:00~23:30 이다. 노선 하나를 통째로 "운행 종료"라고 말하면 그 사이 80분 동안 틀린다. 상류에는 평일·토·일·공휴일 4종의 요일패턴이 있는데 두 노선은 현재 네 값이 같아 차이가 드러나지 않는다 — 무엇을 내보낼지는 아래 선택지 ①이다.

갈리는 선택지 둘

위의 다섯(회차 키 저장 · arrivals 범위 · 셀 통계 위치 · 차량 예보 저장 · 조립 위치)은 근거가 한쪽으로 기울었거나 계약이 이미 닫아서 결론까지 갔다. 남은 둘은 아직 열려 있고, 어느 쪽을 골라도 A18 은 동작한다.

① 운행 시간의 요일패턴을 무엇으로 내보내나

상류 마스터에서 공휴일(we*) 값은 사실상 일요일(sun*)의 복제다 — 양쪽 다 값이 있는 1,927개 노선 중 실제로 다른 것은 10개뿐이다. 요일패턴을 셋(평일·토·일)으로 줄여도 잃는 것이 거의 없다.

② 셀 통계 재계산을 누가 도나

3. 두 레인의 공존 같은 관측에서 갈라져 스위치 앞에서 만난다

기존 7개 후보는 차량 상태를 쓰지 않고 A18 은 쓴다. 둘은 답하는 질문이 다르지만 같은 엔드포인트를 놓고 경쟁한다 — v3 와 달라진 점이 여기다. 그래서 공존 구조의 요점은 "둘이 나란히 서빙한다"가 아니라 "한쪽만 서빙하고 다른 쪽은 멈춘 채 남는다"이다.

왜 레인 A 를 지우지 않나

되돌릴 수 있는 변경으로 만들기 위해서다. 레인 A 의 발행 계층 — 표 둘, 봉인 확인 5종, CAS 승격, 시간대 경계 재발행 — 은 하나도 지워지지 않는다. 다만 계속 도는 것도 아니다. 표와 열은 그대로 남고 새 행만 만들지 않는다. 동결은 DDL 이 아니라 스케줄러 정지다. A18 이 새 평일 자료에서 무너지거나 운영이 감당되지 않으면 스케줄러를 다시 켜고 /board 가 읽는 자리를 되돌린다.

배포에 서빙 역할 열을 두지 않는다. 앞선 초안은 레인마다 ACTIVE 를 하나씩 두려고 model_deployment.servingRole 을 더하려 했는데, 그 초안은 "레인 둘이 동시에 서빙한다"를 전제했다. /board 가 A18 로 재구성되면서 서빙 레인은 하나가 됐고, 나눌 유일성이 사라졌다. 그래서 ACTIVE 는 부분 unique index 로 전역 1개인 채 그대로다. CAS 승격 로직도 그대로다 — expected_active_deployment_id 를 받아 정확히 한 행이 아니면 전체 rollback 이다. A18 을 철회할 때도 A18 배포를 RETIRE 하고 이전 배포를 다시 ACTIVE 로 올리면 되고, 그동안 유일성은 계속 성립한다.

나머지 6개 후보 모델은 제품 배포와 무관하게 후보 모델 현황판에서 계속 채점된다. 그쪽은 외부 ML 환경의 일이고 이 문서의 경계 밖이다. A18 도 아직 일일 평가 원장에 들어 있지 않다 — 지금 성적은 오프라인 산출이다.

4. 신규 노선 생애주기 중간 단계를 두지 않는다

A18 은 노선별로 학습하고 계수를 공유하지 않는다. 그래서 새 노선은 자기 이력이 쌓이기 전까지 예보를 낼 재료가 없다.

중간 단계를 두지 않는 이유

• 절편만 남은 예측은 예보가 아니다. 노선별 학습이므로 새 노선에는 셀 통계가 없고, 그러면 결측 지시자가 켜진 채로 마스킹 폴백만 돈다. 그때 나오는 값은 "그 노선의 평균"조차 아니다. v3 도 같은 판단을 이미 적었다 — 세 번째 노선은 수집만 시작하고 예보는 내지 않으며, 미지원 노선을 절편만으로 점수화하면 근거 없는 확률이 된다. supportedScopeDigest 가 그 경계를 이미 봉인하고 있다.
• 차량 상태만으로는 못 버틴다. A18 이 차량 상태를 쓴다고 해서 셀 통계 없이 도는 것은 아니다. 정보원이 지평에 따라 옮겨 간다 — 학습에 쓰지 않은 하루(8/18)에서 재면 차량 상태의 설명력이 지평 1에서 R² 0.958 인데 지평 8에서 0.179, 지평 12에서 0.002 까지 무너지고, 정류장 상태는 0.336 에서 0.310 으로 거의 그대로다. 결합하면 지평 8에서 0.442, 지평 12에서 0.337 이다. 먼 지평일수록 새 노선이 갖지 못한 쪽에 의존한다.
• 채점 원장이 오염된다. 배포 ID 가 바뀌면 전후 데이터를 갈라 채점하는 것이 계약이다. 품질 단계를 중간에 끼우면 같은 배포 안에 성격이 다른 구간이 섞여 어느 구간을 잰 것인지 알 수 없게 된다.
• 한 번 잃은 신뢰는 좋은 예보로도 잘 돌아오지 않는다. 이 서비스가 파는 것은 만석 경보 하나이고, 그것이 틀리면 다음 예보도 안 본다.

관문 — 무엇을 통과해야 하나

A18 이 채택될 때 통과한 검증을 노선 단위로 다시 적용하면 새로 정의할 것이 없다. 다만 문턱값은 아직 고정되지 않았다 — 아래 값들은 A18 이 두 노선에서 낸 실측이지 통과 기준이 아니다. 기준으로 쓰려면 결과를 보기 전에 고정해야 한다. 7절에 미결로 남겼다.

마지막 줄이 실질적으로 가장 센 관문이다. 학습 자료가 전부 휴일일 때 평일 아침 판별력은 0.518 에 머물고 휴일을 세 배로 늘려도 그대로인데, 평일 반나절이 들어오면 0.958 로 뛴다. 모자란 것은 모델이 아니라 그 노선의 자료다.

5. 작업량 추정

계약 문서만 보고 낸 추정이다. 코드베이스를 열어 보지 않았으므로 기존 구현의 결합도에 따라 아래 값은 움직인다. 팀이 규모를 가늠하는 용도로만 쓰이길 바란다.

이전 v4-be 안의 추정은 18~29일이었다. 늘어난 몫이 /board 를 늘리는 대신 바꾸기로 한 값이다 — 재조립 3~5일 · 오류 계약 1~2일 · 캐시와 부하 1~2일 · 검증 1일 · 저장 정책 1일 · 노선 기준정보 1일이 더해지고, /vehicles 응답 조립 1~2일이 빠졌다.

6. 하지 않아도 되는 것 팀이 이미 만든 것은 대부분 그대로 산다

/board 를 다시 만든다고 8/17 확정본이 뒤집히지 않는다. 무엇이 그대로이고 무엇이 실제로 움직이는지 나눠 적는다.

그대로 쓰이는 것

실제로 움직이는 것

v2 초안에서 버린 것 — 어디까지 돌아오나

v3 가 v2 초안의 두 표를 버렸다. A18 은 그중 하나만, 그것도 다른 모습으로 필요로 한다.

v3 가 두 표를 버린 근거는 "모델이 상호작용 로지스틱 회귀라서 읽는 코드가 없다"였다. 읽는 코드가 없는 표를 계약에 남기지 않은 것은 맞는 판단이었고, 지금 바뀐 것은 그 판단이 아니라 전제다 — A18 의 L_cell 이 그 값을 직접 읽는다. 레인 A 에는 원래 근거가 여전히 그대로 유효하다.

7. 먼저 재야 할 것 코드보다 앞선다

작업량 추정보다 앞에 놓이는 확인이 있다. 결과에 따라 5절의 표가 흔들린다.

설계에서 아직 안 정한 것

• 운행 시간의 요일패턴. 2절 선택지 ①이다. 상류에 평일·토·일·공휴일 4종이 있는데 계약은 방향당 첫차·막차 하나씩만 받는다. 두 노선은 현재 네 값이 같아 차이가 드러나지 않는다.
• 좌석이 결측인 관측의 서빙 처리. remainSeatCnt = −1 이면 설계행렬을 채울 수 없어 그 차량이 항목째 빠진다. 전수 22,010 스냅샷에서 차량행 314,688 중 237행(0.075%)이고 판의 1.10% 가 그런 차량을 하나 이상 담으며, 한 차량에 연속 18회까지 이어진 사례가 있다. /vehicles 는 같은 차량을 kind: UNKNOWN 으로 계속 보여 주므로 두 화면이 어긋난다. 직전 관측의 좌석으로 대신할지, crowdedCode 로 거친 추정을 할지, 지금처럼 빼 둘지 정해야 한다.
• 차량 예보 보존 기간과 파티션 축. 노선당 하루 89만~98만행이라 이 표가 파이프라인에서 가장 빨리 자란다. 채점에 필요한 창과 저장 비용의 절충이 필요하다.
• demand_profile 재계산 주기와 주체. 2절 선택지 ②다. 배포와 함께 돌지 독립 일배치일지 미결이다.
• 노선 판본 개편 시 상태 전이. 4절 상태 기계의 점선이다. 폴백만으로 며칠을 버틸 수 있는지에 답이 달렸다.
• 노선 관문의 문턱값. 4절 표의 값들은 A18 이 낸 실측이지 통과 기준이 아니다. 채택 규칙은 모델 채택용으로 만든 것이라 노선 관문으로 옮기려면 문턱을 결과 보기 전에 고정해야 한다.
• 여정 분할 문턱. 순번이 줄어드는 것을 새 여정의 신호로 쓰는데, 상류 지터로 순번이 잠깐 되돌아가는 경우와 구별할 문턱값이 정해지지 않았다. 가르는 것은 여정이지 회차가 아니다 — 회차는 여정 안의 한 점이다.
• 회차지 부근에서 밤을 넘기는 차량. 3330 은 재구성한 여정 중 회차 순번 언저리(42~43)에서 끝나고 다시 시작하는 것이 있다. 순번이 차고지로 돌아가지 않은 채 밤 공백이 들어오므로 여정 경계와 운행 시작 판정이 순번만으로는 갈리지 않는다. 밤 공백의 중앙이 1650 487분 · 3330 462분이라 시간 문턱으로 가를 여지는 있는데, 그 값이 아직 없다.
• 회차 대기가 시간대에 따라 변한다. 1650 기준 회차 대기 중앙이 07시 106.7분에서 21시 46.0분까지 내려간다(전체 중앙 75.3분). 여정 경계를 시간 문턱 하나로 고정하면 아침에는 한 여정을 둘로 쪼개고 밤에는 둘을 하나로 붙인다. 문턱을 시간대별로 둘지, 아예 시간이 아닌 다른 신호로 가를지가 열려 있다.

v3 의 미결 셋(계수 번들 부재 · 학습 사건의 노선 판본 부재 · 제품 공개 노선 ID)은 그대로 남아 있다.

관련 문서

이 문서는 검토 요청안이다. 확정 계약은 v3 이고, 여기서 제안한 어느 항목도 팀 합의 전에는 적용되지 않는다.