라우팅 점검 스크립트를 하나 만들고, 그 뒤 사흘을 그 스크립트 자체를 두들기는 데 썼다.
뮤테이션 테스트를 59종까지 늘려 살아남은 뮤턴트 7건을 닫는 작업이었고, 그날 손에 쥔 결과는 없었다.
값은 8월 중순, 상류가 설정을 옮겨서 그 스크립트가 먼저 깨진 날에 나왔다.
문제
모델 라우팅 설정은 어긋나도 소리를 내지 않는다.
호출은 성공하고 응답도 돌아오는데 내가 지정한 모델이 아닌 쪽이 답한다.
이 스택은 그런 무효화를 여러 번 겪었고, 2026년 7월 29일에 그걸 잡는 점검 스크립트를 하나 만들었다.
그 뒤 한 달간 라우팅 사건 대부분을 사람이 아니라 이 스크립트가 먼저 알아챘다.
그런데 점검 스크립트도 코드다.
잘못 짜여도 통과를 뱉으면 아무도 모른다.
감시 장치가 조용히 고장 나면 감시받던 대상이 고장 난 것보다 나쁘다.
없는 안전을 있다고 믿게 되기 때문이다.
점검 스크립트를 점검했다
만든 직후 사흘 동안 강화 커밋 12건이 연달아 붙었다.
아무 소리 없이 통과하던 경로를 막았고, 오버라이드로 열려 있던 자리를 줄였고, 추론 설정을 하나의 스키마로 합쳤다.
그리고 뮤테이션 테스트를 59종까지 늘렸다.
뮤테이션 테스트는 검사 대상이 아닌 검사기 쪽을 과녁으로 잡는다.
코드 한 곳을 일부러 틀리게 바꿔 놓고 점검을 돌린다.
그래도 통과가 나오면 그 뮤턴트는 살아남은 것이고, 살아남았다면 그 자리에 검사가 없다.
59종 중 7건이 처음에 살아남았고 그 7건을 하나씩 닫았다.
만든 날의 장부로만 보면 이 사흘은 지출뿐이다.
라우팅은 그동안 멀쩡했고 잡힌 사건도 없다.
검사기를 일부러 망가뜨려 보는 일은 그날 아무것도 증명하지 않는다.
회수는 상류가 움직인 날 일어났다
2026년 8월 18일, 업스트림이 에이전트 체인 설정 테이블을 한 모듈에서 다른 모듈로 분리했다.
그 변경이 라우팅을 조용히 틀어 놓기 전에 점검 스크립트가 먼저 실패했다.
사고로 드러날 것이 검사 실패로 먼저 드러났다.
가장 값싼 형태로 상류 변경을 통보받은 셈이다.
같은 시각에 감시 대상을 하나 늘렸다.
8월 초에 제거해 둔 모델 핀이 하나 있었는데, 그 제거의 전제가 이번 상류 변경으로 깨질 수 있다고 봤다.
전제를 다시 세우는 대신 그 항목에 상시 감시를 붙였다.
8월 30일에는 라우팅 골든 기준선을 다시 잡았다.
그 작업에서 상류 표류 12건을 감사했고, 감사 결과 핀은 전원 유지로 결정됐다.
표류를 12건으로 셀 수 있었던 것은 그 전에 기준선과 검사가 서 있었기 때문이다.
| 장치 | 만든 날 | 값이 나온 날 | 그날 일어난 일 |
|---|---|---|---|
| 라우팅 점검 스크립트 | 2026-07-29 | 2026-08-18 | 상류가 설정 테이블을 옮기자 검사가 먼저 실패했다 |
| 뮤테이션 테스트 59종 | 2026-07-29~31 | 2026-08-30 | 기준선을 다시 잡으며 상류 표류 12건을 감사했다 |
| 캐시 패치 재적용 자동화 | 2026-08-09 | 2026-08-10 | 업데이트가 설치본을 갈아치웠고 재적용이 자동으로 돌았다 |
같은 형태가 로컬 패치에도 있었다
표의 마지막 줄이 세 번째 사례다.
런타임 업데이트는 설치본 배포 트리를 통째로 갈아치운다.
그 위에 얹어 둔 캐시 패치는 업데이트 한 번이면 같이 사라진다.
8월 9일에 이걸 규칙으로 못 박았다. 캐시 패치에는 재적용 자동화가 붙어야 한다.
그 패치가 얹혀 있던 런타임이 omo이고, 8월에 senpi에서 이 이름으로 바뀌었다.
자동화의 첫 실전은 다음 날 왔다.
8월 10일 새벽 업데이트에서 영향은 없음으로 나왔고 재적용이 자동으로 돌았다.
테스트 9건이 적용 경로와 멱등성과 실패 경로까지 덮고 있었다.
자동화가 처음 쓸모를 보인 날은 만든 다음 날, 상류가 설치본을 갈아치운 순간이었다.
감시 장치도 은퇴시킨다
8월 22일, 패치를 지켜보던 백그라운드 작업이 오탐 알림을 계속 띄웠다.
정체를 규명해 보니 그날 나온 업스트림 릴리스가 같은 결론에 도달해 로컬 패치를 흡수한 뒤였다.
패치의 수명이 정상적으로 끝난 자리였고, 그 사실을 알린 계기가 오탐 알림 스팸이었다.
8월 30일에는 감시 장치 3건을 걷었다.
업데이트 훅 안에서 캐시 패치를 15회 다시 확인하던 루프를 지웠다.
같은 대상을 세 겹으로 감시하고 있었고 그 훅에 주어진 시간 예산이 15초였다.
확인을 반복하는 일과 예산 안에 끝나는 일이 충돌하면 감시가 훅을 잡아먹는다.
같은 날 캐시 패치 하나와 그 환경변수 배선도 은퇴시켰다.
빈자리에는 금지한 프로바이더로 설정이 표류하면 알리는 장치 하나만 남겼다.
그날 마지막 네 커밋 중 셋이 축소 방향이었다.
결론
테스트를 더 짜자는 이야기와는 다르다.
검사기의 값은 검사 대상이 바뀌는 날에만 계산되고, 그래서 점검 장치를 만든 직후에 그 장치를 평가하려 들면 항상 손해로 보인다.
평가는 상류가 처음 움직일 때까지 미뤄 두는 편이 맞는다.
짓는 손과 걷는 손이 같은 강도여야 이 일이 유지되므로 정산이 끝난 장치는 걷어낸다.
빈자리에는 설정이 금지한 프로바이더로 표류하면 알리는 장치 하나만 남겼다.
한계·재검토 트리거
2026-09 기준 / 재검토 트리거: 상류 변경이 점검 스크립트를 깨뜨리지 않고 라우팅만 조용히 틀어 놓은 사례가 한 건이라도 관측되면 이 글의 판정을 다시 연다.