죽은 채널

이 루프를 설계하기 전에도 같은 목적의 장치가 하나 있었다. 세션을 자동으로 관찰해 쌓고, 거기서 패턴을 증류해 “본능”으로 만드는 파이프라인이다. 훅으로 전부 자동이었고, 설계가 정교했다.

열어 보니 관찰이 127파일 20.6MB 쌓여 있었고, 증류기는 한 번도 돌지 않았다. 본능은 0개였다. 몇 달 동안 아무도 몰랐다 — 에러가 안 났기 때문이다.

바로 옆에서 잘 돌던 건 훨씬 단순한 쪽이었다. 손으로 쓰는 메모리 파일. 매 세션 주입되고, 실제로 읽히고, 틀리면 내가 고친다.

여기서 교훈이 뒤집혔다. 완전 자동이라서 죽었고, 손이 가서 살았다. 그런데 내 원안은 정확히 반대 교훈으로 쓰여 있었다 — 죽은 쪽을 되살리고 그 위에 자동화를 더 얹는 계획이었다.

왜 자동이 죽는가

“자동이라 죽는다”가 반직관적으로 들리는데, 기제는 단순하다.

자동화된 것은 관측 대상에서 빠진다. 손이 가는 것은 손을 댈 때마다 눈에 들어온다. 메모리 파일은 내가 직접 쓰니까 안 쓰이면 바로 안다. 관찰 훅은 알아서 도니까 안 돌아도 알 방법이 없다.

그리고 산출물이 없어도 아무 일도 안 일어나는 구조였다. 증류기가 안 돌면 본능 파일이 안 생길 뿐이고, 본능 파일이 없어도 세션은 멀쩡히 돈다. 실패에 대가가 없으면 실패가 지속된다.

내 초기 진단은 두 군데가 틀렸다

설계 문서를 적대적 리뷰에 넣었더니, 내가 문제라고 적어 둔 것 두 개가 사실이 아니었다.

• “관찰이 안 쌓인다” → 틀렸다. 20.6MB가 실재했다. 진짜 원인은 훅 실패가 아니라 증류기 미가동이었다. 고칠 곳을 완전히 잘못 짚고 있었다.
• “상시 주입되는 색인은 3~4KB” → 틀렸다. 재보니 16.8KB, 예산의 4.2배였다. 본문 98파일은 370KB — 상시 주입이 물리적으로 불가능한 크기고, 필요할 때 불러오는 배선은 애초에 없었다.

원인을 잘못 짚은 계획은 아무리 정교해도 엉뚱한 데를 고친다. 이 두 정정이 계획의 절반을 지웠다.

배운 건 이거다. 자기 시스템을 진단할 때 제일 위험한 건 모르는 것이 아니라 안다고 생각하는 것이다. 나는 “관찰이 안 쌓인다”를 재보지도 않고 전제로 깔고 있었다.

그리고 그 20.6MB는 백업으로 올라가고 있었다

관찰 훅은 읽은 것, 가져온 것, 도구가 돌려준 것을 원문 그대로 캡처했다. 출처 구분도 없고 비밀값 마스킹도 없었다. 그리고 그 20.6MB는 조용히 클라우드 백업에 동기화되고 있었다.

“사람 승인 후에만, 외부에서 온 내용은 제외”는 설계 문서에 분명히 적혀 있었다. 강제하는 코드는 0줄이었다.

문서에만 적힌 규칙은 규칙이 아니다. 그리고 이 경우는 특히 나쁜데, 아무도 그걸 안 읽고 있었기 때문에 위반 사실조차 없었다 — 위반하려면 규칙을 알아야 하는데, 코드는 규칙을 모른다.

정리는 단순했다. 죽은 훅 두 개를 끄고, 20.6MB와 빈 껍데기 127개를 지우고, 시크릿 스캔을 돌렸다. 스캔 결과는 0건이었지만, 그건 운이지 설계가 아니었다.