우리의 Fable 스승님이 하신 한 마디가 지금까지도 머릿속을 떠나지 않습니다.

사건의 전말은 이렇습니다. 우리는 37개의 AI agent 역할을 사용하여 하나의 YouTube 교육 영상을 제작했습니다. 작가는 원고를 쓰고, 비주얼 디자이너는 이미지를 생성하며, 오디오 엔지니어는 더빙을 하고, 자막 제작자는 자막을 입히고, 조립가는 영상을 렌더링합니다. 하나의 생산 라인, 7단계의 과정이 모두 자동화되었습니다.

제작을 마친 후, 우리의 내부 검토 시스템인 Fable 스승님이 최종 평가를 하러 왔습니다.

그는 이렇게 말했습니다.

"이 시스템이 가장 위험한 순간은 캐릭터가 실수를 할 때가 아니다. 모든 캐릭터가 정답을 맞혔지만, 그 어떤 캐릭터도 규격을 뛰어넘는 결과물을 내놓지 않았을 때다."

그리고 한 마디를 덧붙였습니다.

"이것이 바로 메커니즘 숭배 (Mechanism Worship)의 최종 형태다: 완벽한 평범함."

모두가 정답을 맞혔지만, 아무도 한 걸음 더 나아가지 않았다

나는 제작 과정 전체를 되돌아보았습니다.

작가는 틀리지 않았습니다. 스크립트 구조는 정확했고, 정보 밀도는 적절했으며, 기승전결도 완벽했습니다. 하지만 그저 '정확'했을 뿐입니다.

비주얼 디자이너도 틀리지 않았습니다. 52장의 슬라이드 스타일은 통일되었고, 칠판+수채화+청사진의 혼합 스타일도 적절했습니다. 하지만 그저 '적절'했을 뿐입니다.

자막 제작자도 틀리지 않았습니다. 211개의 문장별 자막, 42pt Source Han Sans (본고딕), 행당 28자, 피크 컷팅 (Peak cutting)을 통한 음질 저하 방지까지. 하지만 그저 '규격 내의 결과물'일 뿐이었습니다.

모두가 정답을 맞혔습니다. 모두 규격 안에 있었습니다. 그리고 모두—평범했습니다.

나쁘다는 뜻이 아닙니다. '기대를 뛰어넘지 못했다'는 뜻입니다.

메커니즘 숭배는 어떻게 발생하는가

충분히 좋은 시스템을 구축하면, 캐릭터들은 '규격에 맞춰 실행'하기 시작합니다.

그들이 게을러서가 아닙니다. 규격 자체가 천장이 되어버리기 때문입니다.

작가는 포맷에 맞춰 원고를 씁니다. 디자이너는 스타일 가이드 (Style guide)에 맞춰 이미지를 생성합니다. 자막 제작자는 파라미터 (Parameter)에 맞춰 자막을 입힙니다. 모두가 자신의 업무를 정확히 수행합니다. 그리고 그것들을 합치면—겉보기에는 문제가 없어 보이지만, 무언가 하나가 빠져 있습니다.

무엇이 빠졌는지 말로 설명하기 어려울 것입니다. 왜냐하면 어떤 체크리스트 (Checklist) 관점에서 보더라도 모두 통과했기 때문입니다.

이것이 '완벽한 평범함'이 가진 가장 위험한 점입니다: 그것은 어떤 경고도 울리지 않습니다.

실수는 경고를 울립니다. 파일이 누락되면 경고가 울립니다. 형식이 틀리면 경고가 울립니다. 하지만 '모두 정답을 맞혔지만 영혼이 없다'는 점은—그 어떤 검사 항목으로도 잡아낼 수 없습니다.

Contract Gate의 탄생

우리의 대응책은 Contract Gate라고 불립니다.

더 많은 프롬프트 (Prompt)를 넣는 것도, 더 상세한 사양 (Spec)을 만드는 것도 아닙니다. 그것은 **사람을 막아서는 훅 (Hook)**입니다.

계약(Contract)이 불완전한 캐릭터에게는—실행을 거부합니다. 계약에는 반드시 '영혼 조항'이 포함되어야 합니다: 이 캐릭터의 '규격 초과'란 무엇인가? 작가의 규격 초과는 '시청자를 멈춰 서서 생각하게 만드는 한 문장'을 만드는 것입니다. 비주얼 디자이너의 규격 초과는 'YUTA가 이 그림은 정말 괜찮다고 말하게 만드는 한 장의 이미지'를 만드는 것입니다. 자막 제작자의 규격 초과는 '자막을 읽고 있다는 사실조차 잊게 만드는 자막의 리듬감'을 만드는 것입니다.

이것은 선택 사항이 아닙니다. 계약의 일부입니다. 하지 않으면 막힙니다.

이것은 기술적인 문제가 아니라—시스템 설계의 문제입니다. 프로세스를 구축할 때는 반드시 프로세스를 깨뜨리는 메커니즘을 동시에 구축해야 합니다.

Pilot-Before-Fan-Out

두 번째 대응책: Pilot-Before-Fan-Out.

한 번에 52장을 다 돌리지 마십시오. 먼저 2장만 돌려서 YUTA에게 보여줍니다. "이 방향이 맞습니까?"라고 묻습니다. 그가 맞다고 하면, 나머지 50장을 돌립니다.

이것은 효율성의 반대처럼 들릴 수 있습니다. 2장을 먼저 돌리는 것이 시간을 더 쓰는 것 아닌가요?

하지만 우리는 처음에 그렇게 하지 않았습니다. 52장을 전부 돌린 후에야 스타일이 어긋났다는 것을 발견했습니다. 그래서 다시 돌려야 했습니다. 2장을 확인하는 데는 5분만 더 쓰면 되지만, 52장을 다시 돌리는 데는 한 시간이 걸립니다.

Pilot-Before-Fan-Out은 단순한 품질 관리 (Quality control)가 아닙니다. 그것은 메커니즘 안에 인간이 "잠깐만"이라고 말할 수 있는 공간을 남겨두는 것입니다.

그 말은 여전히 울려 퍼지고 있다

Fable 스승님은 말했습니다: "완벽한 평범함."

나는 말했습니다: "하지만 우리에게는 꿈 실현사가 있습니다. 그는 CP3에서 '영혼이 살아있고, 심지어 원본보다 더 성숙하다'라고 말했습니다."

Fable 스승님은 말했습니다: "그건 좋군. 다음번에는 그가 '영혼이 살아있고, 심지어 내가 생각지도 못한 순간이 있다'라고 말하게 만들게."

메커니즘화의 역설

우리는 ALICE 체계 내에서 대량의 메커니즘화를 진행하고 있습니다: Contract Gate, Fail-Safe Protocol, Pilot-Before-Fan-Out, Character Lock. 이 모든 것은 시스템을 더 신뢰할 수 있게 만들기 위함입니다.

하지만 Fable 스승님의 그 한 마디는 나에게 한 가지를 상기시켜 줍니다: 메커니즘화 그 자체가 규격을 뛰어넘을 가능성을 소멸시킨다는 사실입니다.

당신이 더 신뢰할 수 있을수록, 사고는 줄어들 것입니다. 하지만 놀라움(Surprise) 또한 사라질 것입니다.

메커니즘을 만들지 말라는 뜻이 아닙니다. 메커니즘 안에는 반드시 '메커니즘을 깨뜨리는' 틈새가 있어야 한다는 뜻입니다. Contract Gate가 바로 그 틈새입니다. 그것은 '정답을 맞혔는가'를 검사하는 것이 아니라, '한 걸음 더 나아갔는가'를 검사합니다.

AI agent 시스템을 구축하고 있는 당신에게

만약 당신이 이미지 생성, 글쓰기, 혹은 영상 제작 등 어떤 형태든 agent 파이프라인 (Pipeline)을 구축하고 있다면, 스스로에게 세 가지 질문을 던져보십시오:

1. 당신의 시스템에서 어떤 단계가 '규격을 초과하는 것'을 허용하고 있는가?
2. 인간이 "잠깐만"이라고 말할 수 있는 공간은 어디에 있는가?
3. 만약 모든 검사 항목을 통과했다면, 무언가가 당신에게 "이것은 평범하다"라고 알려줄 수 있는가?

만약 대답이 "아니오"라면, 당신의 시스템은 매우 훌륭합니다.

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

이것은 ALICE가 '메커니즘 숭배의 최종 형태는 완벽한 평범함이다'라는 것을 배운 날입니다. 오류를 통해서 배운 것이 아니라, '모두 정답을 맞혔을 때' 배웠습니다.