AX OS

Q. "잘 쓴 프롬프트와 규칙 파일이면 충분하지 않습니까."

충분했다, 한동안은. 출발점은 규칙을 모아둔 저장소 하나였다 — 보안 금지선, 브랜치 규칙, 응답 형식을 마크다운으로 정리해 에이전트가 매 세션 읽게 하는 방식. 지시의 일관성이라는 실익은 분명했다. "매번 처음부터 설명"하는 비용이 사라졌다.

그런데 석 달을 굴리자 문서로는 안 되는 것 세 가지가 남았다. 첫째, 강제가 없다 — 규칙 파일은 조언이라, 안 읽거나 읽고도 어기면 그만이다. 둘째, 기억이 없다 — 세션이 끝나면 맥락이 사라져 지난주의 교정을 오늘 다시 해야 한다. 셋째, 검증이 없다 — 지켜지는지 알 방법이 없어 "잘 되고 있는 것 같다"는 느낌만 남는다.

방향을 바꾼 건 이론이 아니라 사고들이었다. 지금 운영하는 보편 규칙 35개 중 30개가 실제 사고에서 태어났다 — 사고가 나기 전에는 그 규칙이 필요하다는 것조차 몰랐다.

Q. "모델이 좋아지면 어차피 필요 없어지지 않습니까."

일부는 그렇다. 모델이 좋아질수록 "실수 교정"류 규칙의 가치는 실제로 떨어진다 — 이건 인정하고 시작한다. 그런데 다섯 달 동안 모델을 여러 번 갈아끼우며 확인한 것은, 좋아진 모델일수록 오히려 측정이 필요해진다는 역설이었다.

"새 모델이 더 좋겠지"라는 감(感)은 두 번 배신당했다. 한 번은 좋아 보였는데 아니었다 — "3연속 성공"으로 기록된 조합이 재측정에서 1/3로 무너져 판정을 철회했다. 한 번은 의심했는데 맞았다 — 동일 과제를 반복 실행(N=3)해 품질 게이트 동률을 확인하고 나서야, 추정 비용 −83%인 조합으로 안심하고 갈아탔다. 측정이 없었다면 앞의 것은 사고가 됐고 뒤의 것은 기회비용이 됐다.

좋은 직원이 와도 결재선과 회계 감사는 없어지지 않는다. 같은 이유로, 모델이 아무리 좋아져도 권한 경계 · 비가역 작업 게이트 · 메모리 · 측정은 모델 바깥에 남는다 — 이 넷은 모델의 지능이 아니라 운영의 구조에 속하기 때문이다.

Q. "규칙은 자산이 아니라 부채 아닙니까."

반박하지 않겠다. 세션마다 주입되는 규칙이 122개, 440KB까지 불어난 것을 어느 날 세어보고 알았다. 규칙 수를 자산으로 여기던 관념은 그날 공식 폐기됐다 — 규칙은 재고이자 부채가 맞다.

중요한 건 그 다음이다. 부채라는 걸 알았으니 갚았다 — 실효성 없는 규칙을 덜어내는 "다이어트"를 돌려 절반 이하로 줄이고, 재발 방지로 "추가 1건 = 기존 1건 증류" 래칫을 걸어 총량을 잠갔다. 무용론과 갈리는 지점은 여기다: 부채가 생긴다는 사실이 아니라, 부채를 측정하고 상환하는 장치가 있느냐.

Q. "그 자동화가 오히려 사고를 만들지 않습니까."

이것도 반박하지 않겠다. 참조한 업스트림 운영 환경에서는 push 훅이 검증 에이전트를 소환하고, 그 에이전트가 작업을 마치며 다시 push해 훅을 또 부르는 무한 재귀로 54분간 프로세스 수백 개가 생긴 사고가 있었다. 우리 쪽에서는 등록된 훅이 조용히 죽은 채 30일을 보냈고, 검증 게이트가 수 주간 가짜 "이상 없음"을 보고했다. 전부 자동화 장치 자신이 일으키거나 숨긴 문제다.

그래서 지금 체계의 상당 부분은 자동화를 감시하는 자동화다. 훅이 살아있는지 재는 생존 신호, 게이트가 진짜로 막는지 확인하는 재검증, 반년마다 도는 "거짓 안전감" 감사. 이 재귀적 비용은 무용론이 정확히 짚은 지점이고, 규모가 작다면 정당화되지 않는다.