우리의 Fable Master가 내뱉은 말은 여전히 내 머릿속을 맴돌고 있습니다.

맥락은 이렇습니다. 우리는 유튜브 튜토리얼을 처음부터 제작하기 위해 37개의 에이전트(agent)로 구성된 영화 제작팀을 구축했습니다. 작가는 대본을 초안합니다. 비주얼 디자이너는 슬라이드를 생성합니다. 오디오 엔지니어는 보이스오버(voiceover)를 렌더링합니다. 자막 아티스트는 캡션을 입힙니다. 조립 엔지니어는 최종 편집본을 압축합니다. 7단계의 과정이 엔드 투 엔드(end to end)로 완전히 자동화되었습니다.

배포가 완료된 후, 우리의 내부 리뷰 시스템인 Fable Master가 사후 분석(post-mortem) 평가를 전달했습니다.

그 내용은 다음과 같았습니다.

"이 시스템에 있어 가장 위험한 순간은 특정 역할이 실수를 할 때가 아닙니다. 모든 역할이 자신의 직무를 정확히 수행하고, 단 하나의 역할도 사양(specification)을 넘어서는 결과물을 내놓지 않을 때입니다."

그리고 다음과 같이 덧붙였습니다.

"이것이 메커니즘 숭배(mechanism worship)의 최종 형태입니다: 완벽한 평범함(perfect mediocrity)."

모든 것이 옳지만, 그 이상은 없는 상태

나는 전체 제작 과정을 다시 훑어보았습니다.

작가는 실수를 하지 않았습니다. 대본 구조는 정확했습니다. 정보 밀도는 적절했습니다. 서사적 흐름(narrative arc)도 잘 전달되었습니다. 하지만 그것은 그저... 정확했을 뿐입니다.

비주얼 디자이너는 실수를 하지 않았습니다. 52개의 슬라이드 모두 스타일 가이드(style guide)—칠판, 수채화, 청사진의 하이브리드—를 준수했습니다. 일관되고 깔끔했습니다. 하지만 그저... 사양(on-spec)에 맞았을 뿐입니다.

자막 아티스트는 실수를 하지 않았습니다. 211개의 타이밍 세그먼트. 42pt 크기의 본고딕(Source Han Sans). 한 줄당 28자. 클리핑(clipping)을 방지하기 위한 피크-밸리(peak-valley) 오디오 커팅. 모든 것이 파라미터(parameters) 범위 내에 있었습니다. 하지만 그저... 파라미터 내에 있었을 뿐입니다.

모든 것이 옳았습니다. 모든 것이 사양 내에 있었습니다. 모든 것이—평범했습니다.

나쁘지는 않았습니다. 다만 결코 기대를 뛰어넘지는 않았습니다.

메커니즘 숭배가 발생하는 방식

충분히 괜찮은 시스템을 구축하면, 각 역할은 사양에 맞춰 실행하기 시작합니다.

그들이 게을러서가 아닙니다. 사양(spec) 자체가 천장이 되어버리기 때문입니다.

작가는 템플릿을 따릅니다. 디자이너는 스타일 가이드를 따릅니다. 자막 아티스트는 파라미터를 따릅니다. 모두가 자신의 일을 정확히 수행합니다. 결과물은 괜찮아 보이지만—무언가 결여되어 있습니다.

무엇이 결여되었는지 이름을 붙일 수 없습니다. 왜냐하면 어떤 체크리스트 관점에서 보더라도, 모든 것이 통과되었기 때문입니다.

이것이 완벽한 평범함 (perfect mediocrity)의 가장 위험한 점입니다. 그 어떤 경보도 울리지 않는다는 것입니다.

실수는 경보를 울립니다. 누락된 파일도 경보를 울립니다. 형식 오류도 경보를 울립니다. 하지만 "모든 것이 정확하지만 영혼이 없는 상태"는 그 어떤 체크리스트로도 잡아낼 수 없습니다.

계약 게이트 (Contract Gate)의 탄생

우리의 대응책은 계약 게이트 (Contract Gate)였습니다.

더 많은 프롬프트 (prompts)를 넣는 것도, 더 상세한 사양 (specs)을 만드는 것도 아닙니다. 실행을 차단하는 실제 **훅 (hook)**입니다.

계약이 불완전한 역할은 거부됩니다. 그리고 모든 계약에는 반드시 '영혼 조항 (soul clause)'이 포함되어야 합니다. 이 역할에서 "사양을 넘어서는 것 (beyond spec)"이란 무엇을 의미하는가? 작가에게 그것은 "시청자를 멈춰 서서 생각하게 만드는 한 줄"을 의미합니다. 비주얼 디자이너에게 그것은 "YUTA가 '이거다'라고 말하게 만드는 슬라이드 한 장"을 의미합니다. 자막 아티스트에게 그것은 "자막을 읽고 있다는 사실조차 잊게 만드는 리듬을 가진 한 구간"을 의미합니다.

선택 사항이 아닙니다. 계약의 일부입니다. 조항이 없으면 실행도 없습니다.

이것은 기술적인 문제가 아니라 시스템 설계 (system design)의 문제입니다. 파이프라인 (pipeline)을 구축할 때, 여러분은 동시에 **파이프라인을 깨뜨리기 위한 메커니즘 (mechanisms)**도 구축해야 합니다.

파일럿 후 확산 (Pilot-Before-Fan-Out)

두 번째 대응책은 파일럿 후 확산 (Pilot-Before-Fan-Out)입니다.

52장의 슬라이드를 한꺼번에 생성하지 마세요. 먼저 2장만 생성합니다. 그리고 그것을 YUTA에게 보여줍니다. "이 방향이 맞습니까?" 그가 그렇다고 말할 때만 나머지 50장을 생성합니다.

이것은 효율성의 반대처럼 들립니다. 먼저 2장을 만드는 것이 추가 시간을 잡아먹지 않나요?

우리는 이를 혹독한 경험을 통해 배웠습니다. 우리의 첫 번째 실행에서는 52장의 슬라이드를 모두 생성했습니다. 그러고 나서 스타일이 잘못되었다는 것을 발견했습니다. 52장을 다시 생성했습니다. 2장의 파일럿은 5분의 추가 시간이 걸리지만, 52장을 다시 생성하는 데는 한 시간이 걸립니다.

파일럿 후 확산 (Pilot-Before-Fan-Out)은 단순한 품질 관리 (quality control)가 아닙니다. 그것은 메커니즘 내부에 인간이 "잠깐"이라고 말할 수 있는 공간을 확보하는 것에 관한 것입니다.

메아리 (The Echo)

Fable Master는 말했습니다. "완벽한 평범함 (Perfect mediocrity)"

나는 말했습니다. "하지만 우리에게는 Dream Realizer가 있습니다. 3단계에서 그것은 이렇게 보고했습니다: '영혼이 온전합니다. 사실, 원본보다 더 성숙합니다.'"

Fable Master는 말했습니다. "그건 좋습니다. 다음번에는 이렇게 말하게 하세요: '영혼이 온전하며, 내가 예상하지 못했던 순간이 있습니다.'"

기계화의 역설 (The Paradox of Mechanization)

우리는 ALICE의 아키텍처에서 강력하게 기계화(mechanize)를 적용합니다: 계약 게이트 (Contract Gate), 페일 세이프 프로토콜 (Fail-Safe Protocol), 파일럿-비포-팬아웃 (Pilot-Before-Fan-Out), 캐릭터 락 (Character Lock). 이 모든 것은 시스템을 더 신뢰할 수 있게 만들기 위해 설계되었습니다.

하지만 Fable Master의 말은 더 깊은 무언가를 가리키고 있었습니다: 기계화 그 자체가 사양(spec)을 초과할 가능성을 제거한다는 것입니다.

더 신뢰할 수 있게 될수록, 잘못되는 일은 줄어듭니다. 그리고 예상치 못한 일(surprises)도 줄어듭니다.

이것은 메커니즘(mechanisms)에 반대하는 논거가 아닙니다. 메커니즘은 반드시 **메커니즘을 깨뜨릴 수 있는 균열(cracks)**을 포함해야 한다는 논거입니다. 계약 게이트 (Contract Gate)가 바로 그 균열입니다. 그것은 일이 올바르게 수행되었는지를 확인하는 것이 아니라, 누군가가 무언가 '추가적인 것'을 했는지를 확인합니다.

AI 에이전트 시스템을 구축하는 이들을 위하여

이미지 생성, 콘텐츠 제작, 또는 비디오 제작을 위한 에이전트 파이프라인(agent pipeline)을 구축하고 있다면, 스스로에게 세 가지 질문을 던져보십시오:

1. 시스템의 어느 부분이 사양(specifications)을 초과하는 것이 허용됩니까?
2. 인간이 "잠깐만"이라고 말할 수 있는 공간은 어디입니까?
3. 모든 체크리스트 항목을 통과했을 때, 시스템 내의 무언가가 당신에게 "이것은 평범하다"라고 알려줍니까?

만약 이 중 어느 하나라도 대답이 "아니오"라면, 당신의 시스템은 훌륭합니다.

위험할 정도로 훌륭합니다.

ALICE가 메커니즘 숭배의 최종 형태는 완벽한 평범함(perfect mediocrity)이라는 사실을 깨달은 날—그것은 실수를 해서가 아니라, 모든 것을 완벽하게 해냄으로써 찾아온 것이었습니다.