서론

6월에는 Opus 4.8의 「court 무한 루프」로부터의 부활 절차를 썼고, 7월 초에는 한정 기간 동안 사용할 수 있었던 Claude Fable 5에 대해 썼다. 이번에는 그 후속편이다. 한정 기간 동안 제공된 상위 모델이 남긴 자산을 일상 운영 모델로부터 어떻게 보호할 것인가라는 문제를 둘러싸고, 3주 동안 같은 가드(Guard)를 3번이나 다시 만든 기록이다.

모델 소개 기사가 아니라, 실제로는 AI 에이전트 운영에 관한 이야기다. 결론부터 말하자면, 도달한 지점은 "규칙은 읽히는 것이 아니라, 기계로 강제하는 것"이었다.

발단: 1주일뿐이었던 상위 모델

7월 상순, Anthropic의 Claude Fable 5를 한정 기간 동안 사용할 수 있게 되었다. Opus보다 상위에 위치하는 새로운 티어(Tier)의 모델로, 설계·리뷰·언어화의 질이 명확히 한 단계 다르다는 점은 지난 기사에서 썼듯이 분명했다.

사용 가능한 기간은 1주일도 채 되지 않았다. 그래서 그사이에 Claude Code 환경 정비를 단번에 맡기기로 했다. 훅(Hook, 도구 실행 전후에 삽입하는 스크립트)을 통한 자동 백업이나 게이트(Gate), 규칙 문서의 재편, 스킬 정리 등, 말하자면 환경의 OS 계층을 Fable에게 쓰게 했다.

문제는 권한 만료 후다. 다음 주부터는 일상 운영 모델인 Opus 4.8과 Sonnet 5로 돌아갈 것이라고 (당시에는) 생각했다. 상위 모델이 설계한 체계를 그보다 판단력이 낮은 모델이 일상적인 작업에서 건드리게 된다. 그대로 두면, 잘하려고 한 덮어쓰기로 인해 조금씩 망가져 가는 미래가 보였다.

제1형태: "만든 자만이 수정할 수 있다": Fable 5 "7월 7일까지" (제1탄)

처음에 만든 것은 정직한 가드였다. Fable이 작성한 자산은 Fable 이외의 모델이 수정하는 것을 기계적으로 차단한다. 신규 생성과 추가는 허용하되, 기존 내용의 변경만 막는다. Claude Code의 PreToolUse 훅은 exit 2를 반환하면 해당 도구 실행을 중지하고 stderr의 문구를 모델에게 돌려주기 때문에, 그 기능을 활용했다.

현재 어떤 모델이 작동 중인지는 훅으로 들어오는 입력, transcript 말미, 그리고 settings라는 3단계 판정법을 사용했다. 판정 기준은 완전히 모델이다. "상위 모델의 성과물은 상위 모델만이 건드릴 수 있다"는, 글로 쓰면 상당히 오만한 규칙이지만, 당시에는 이것이 자연스러운 해답처럼 보였다.

하위 모델에게 맡겨본 결과

Fable에게는 환경 정비와 병행하여 작업 역할 분담표도 설계하게 했다. 정형적인 실행은 Opus 4.8, 대량의 정형화 작업은 Sonnet 계열의 서브 에이전트(Sub-agent), 판단이 필요한 업무만 상위 모델로. 비용을 고려하면 당연한 설계였고, 실제로 한동안 이 분담 체제로 운영했다.

결과는 가드의 테마가 보여주듯이었다. 규칙 문서에 적혀 있는 내용을 그 상황의 문맥에 따라 "해석"하여 망가뜨린다. 세션(Session)을 넘나드는 기억 파일(메모리)에는 무엇이든 기록하려 하고, 상한선을 정해두었던 인덱스(Index)는 금방 넘쳐버린다. "대화 도중에 멋대로 저장하지 말 것"이라고 명문화해도, 긴 세션의 후반부로 갈수록 지켜질 확률이 낮아진다. 망가진 부분을 수리하는 일은 결국 Fable에게 돌아오므로, 저렴하게 끝내려 했던 작업이 오히려 더 비싸게 먹힌다.

여기서 얻은 교훈이 이 기사에서 가장 쓰고 싶었던 내용이다. 규칙 문서는 모델에게 있어 "지켜질 확률을 높이는 장치"일 뿐이다. 확률로 해결되지 않는 문제는 훅(Hook)으로 물리적으로 막을 수밖에 없다. 저장 지시가 없는 턴의 메모리 쓰기를 막는 게이트, 본업 배포 계열의 조작을 막는 게이트 등, 이 시기에 "읽히는 규칙"이 차례차례 "기계적 게이트"로 교체되어 갔다. 구현 패턴은 내용이 길어지므로 별도의 기사로 정리하겠다.

제2형태: "누가 썼는가"에서 "무엇을 망가뜨려서는 안 되는가"로: Fable 5 "7월 12일까지" (1차 연장)

12일(당시) Fable의 권한 만료가 다가오자 제1형태의 결함이 보이기 시작했다. Fable이 사라진 후, 이 가드는 모든 모델을 영구적으로 차단하기만 하는 벽이 된다. 해제는 인간의 명시적인 지시로 가능하다고 해도, 일상적인 가필과 수정까지 매번 막힌다면 운영이 되지 않는다.

그래서 만료 직전에 가드의 기준을 다시 세웠다. "누가 썼는가"를 버리고 "무엇을 망가뜨려서는 안 되는가"로 보호한다. 보호 대상을 매니페스트(Manifest)에 열거하고, 동결(모든 수정 차단)·불변 조항(파일 내의 마커 구간만 보호하고 구간 외는 자유롭게 허용)·추가 우선(추가는 허용)의 3단계로 나누었다. 파일 내부에 "이 부분만큼은 망가뜨리지 마라"라는 조항을 심어두는 형태이므로, 편집하는 모델은 조항을 읽기만 하면 되고 모델 판정 자체도 불필요해진다.

설계 측면에서는 이쪽이 훨씬 논리적이다. 지금 다시 읽어봐도 이 전환은 옳았다고 생각한다. 다만 한 가지, 예상과 다른 일이 일어났다.

쫓겨난 것은 나 자신이었다: Fable 5 "7월 19일까지" (2차 연장)

19일(당시)의 기한을 목전에 두고 깨달았다. 모델 판정을 버렸다는 것은, Fable 자신도 같은 강도로 멈춘다는 뜻이다. 그리고 보호 대상을 가장 빈번하게 건드리는 것은, 체계를 설계한 본인인 Fable이었다.

에이전트(Agent)에게 정비 작업을 실행시키면, 보호 파일에 부딪혀 멈춘다. 인간이 해제어를 말하면 직후의 1턴만 열리고 다시 멈춘다. "해제는 예외 운용이며, 일상적인 동선에는 넣지 않는다"라는 설계 당시의 성립 조건이, 어느샌가 완전히 무너져 있었다. 가드(Guard)는 예상했던 적(하위 모델의 안이한 덮어쓰기)보다, 예상치 못했던 아군(설계자 본인의 유지보수 작업)을 계속해서 막아섰다.

즉, 무엇을 명령해도 1회 멈춘다는 것...

이래서는 "에이전트"로서의 의미가 없다. 간단한 명령이라도 매번 확인. 심지어는 "여기에 저장할 수 없어서 다른 곳에 저장했습니다"라고 말하기까지 한다.

"저장해야 할 장소에만" 저장해주길 바라는데, "가드가 있으니까 다른 곳에 저장했다"라며 "적절하지 않은 장소"에 저장한다.

이미 엉망진창이 되어 있었다.

게다가 아이러니하게도, 메모리(Memory) 상한만큼은 Fable이라 할지라도 여유롭게 뚫고 들어왔다. 상위 모델이라면 넘치게 하지 않을 것이라 생각했던 인덱스(Index)는, Fable에서도 넘쳤다. 무언가를 배울 때마다 기록하고 싶어 하는 것은, 모델의 상하 관계와 상관없는 습성인 듯하다. 이 부분은 최종적으로 "인덱스가 예산(행 수와 바이트 수)을 초과하는 동안에는, 신규 행의 추가만을 기계적으로 차단한다. 기존 항목으로의 통합과 삭제는 허용한다"라는 형태로 안착했다. 넣고 싶다면 먼저 버려라. one-in-one-out의 기계적 강제로, 이것은 모델을 불문하고 모두에게 적용하고 있다.

전환점: 구독 서비스 도입: Fable 5 「Max라면 구독으로 사용할 수 있다」 (처음부터 그렇게 말해줬어야지!)

7월 20일, Fable 5를 구독 범위 내에서 영구적으로 사용할 수 있게 되었다. "실효에 대비한다"라는 가드 제2 형태의 전제가 이날 사라졌다.

며칠 후, 가드에 모델 판정을 부활시켰다. Fable은 그대로 통과시키고, Opus 4.8과 Sonnet 5에는 기존과 같은 강도로 적용한다. 다만 전부 개방한 것은 아니다. 메모리 예산 가드와 운영 환경(Production) 조작 게이트는 모든 모델을 대상으로 유지하고 있다. "상위 모델이니까 신뢰한다"라는 영역과 "모델을 불문하고 기계적으로 제약한다"라는 영역의 선긋기가, 3주간의 재작업 끝에 남은 답이 되었다.

결과적으로는 이 "상위 모델이라면 무엇이든 믿는다"라는 나 자신의 안일함을 통감하게 해주었으므로, 다행스러운 일로 치기로 했다.

다만, 수십 시간과 수만 토큰(Token)에 대해서는 조금 애틋하다. 하지만 이것이 "엔지니어"의 일상이겠지요. 저는 "전직" 엔지니어입니다만.

마치며

솔직한 실감도 적어둔다. Opus 4.8과 Sonnet 5만으로 이 정도 규모의 자동 운용을 신뢰하며 돌리는 것은, 나의 환경에서는 어려웠다. court 루프와 같은 기지의 버그는 후크(Hook)로 완화할 수 있지만, 규칙을 해석으로 깨뜨리거나 무엇이든 기록하고 싶어 하는 성질은, 규칙 문서를 늘려도 고쳐지지 않았기 때문이다. Fable이 상용화되면서 일상은 편해졌지만, 서브 에이전트(Sub-agent)나 폴백(Fallback) 상황에서 하위 모델이 섞이는 장면은 남아있으므로, 가드의 층을 벗겨낼 예정은 없다.

모델은 몇 달 만에 교체되며, 그때마다 이 질문에서 시작될 것이라 생각한다. 이 모델의 성과물을 누가 지킬 것인가. 방어(Guard)를 기계에 구현한 만큼, 다음 모델에게 안심하고 일을 맡길 수 있다.

...AI로 할 수 있지 않을까 싶어 채용을 중단한 기업이 지난 반년 동안 많았다. 하지만 나 자신도 Fable에 휘둘렸듯이, "상상 이상으로 시간을 잡아먹는 것"이 AI다.

철저히 추적할 필요는 있으며, 확실히 편리해질 것이다. 사용하지 않을 이유가 없다. 하지만 "기존 업무를 수행하면서 AI를 도입"하기 위해서는 단순히 "AI라면 전부 할 수 있다"라고 생각하는 것은 너무 안일하다.

이 "AI 시대의 채용"에 대해서도 다시 글로 써보려 한다.

Discussion