AI 워커가 매번 똑같은 보일러플레이트 (Boilerplate) 코드를 다시 쓰고 있다면, 얻고 있는 것은 지능이 아니라 반복 비용이다. 그리기 로직을 도구 (Tool)에 고정하고, AI에게는 JSON 컨피그 (Config)만 작성하게 함으로써, 그림 1장당 토큰 소비를 71% 절감했다 (Anthropic API의 usage 필드로 실측). 다만 이 수치는 좁은 조건하에서의 결과다 — 반복적이고, 추론이 낮으며, 스키마 (Schema)가 얕은 태스크에 한정되며, 측정 방법 자체가 실제 환경보다 높게 측정되었을 가능성이 있다 (상세 내용은 후술). 또한, 패턴 2를 모든 그림에 균일하게 적용하면 시각적 단조로움이 발생했기에, 기사 고유의 시그니처 그림 1장만은 패턴 1로 되돌리는 하이브리드 (Hybrid) 방식도 채택했다.

기사를 만들 때마다, AI 워커는 PIL 스크립트를 처음부터 작성하고 있었다. 폰트 로딩, 좌표 계산, 컬러 상수, 라운드 사각형, 텍스트 줄바꿈 — 이 모든 것이 포함된 Python 파일을 매번 통째로 생성하고 있었다.

출력되는 그림은 같다. 로직도 같다. 그런데도 매번 1,000토큰 가까이를, 지난번에 이미 작성하고 버린 보일러플레이트에 소비하고 있었다.

눈치챈 것은 인간 쪽이었다. "토큰 소비가 급감했다" —— 새로운 방식으로 전환한 후 나온 말로, 이것이 외부 검증이 되었다.

AI에게 코드를 쓰게 하는 것 자체가 틀린 것은 아니다. 매번 똑같은 코드를 쓰게 하는 것이 틀린 것이다.

실제로 변동이 있었던 부분 — 기사 제목, 행 레이블, 색상 선택, 텍스트 내용 — 은 스크립트 전체의 약 20%였다. 나머지 80%는 변하지 않는 구조적 로직이다. 그 80%를 매번 계속 지불하고 있었다.

매번 다시 쓰고 있는 것 중 몇 %가 구조적 보일러플레이트인가 — 그것이 가장 먼저 확인해야 할 지표다.

MVC의 관심사 분리 (Separation of Concerns)를 그대로 적용했다:

Model = 콘텐츠 데이터 (기사마다 변하는 부분)

View/Renderer = PIL 그리기 로직 (변하지 않는 부분)

그리기 측을 tools/gen_article_figs.py로 한 번 작성하여 리포지토리 (Repository)에 고정한다. 이후 AI 워커는 JSON 컨피그만 작성한다.

{
"type": "role_matrix",
"output": "fig1_pattern_comparison",
...

python tools/gen_article_figs.py fig_config_ja.json

실측 결과 (Anthropic API usage 필드로 측정, claude-haiku-4-5-20251001):

{
"OLD (full PIL script)": { "input": 415, "output": 2691, "total": 3106 },
"NEW (JSON config only)": { "input": 377, "output": 522, "total": 899 },
...

추가 효과: gen_article_figs.py의 버그 수정이 과거 및 미래의 모든 기사에 자동으로 전파된다.

패턴	AI가 작성하는 것	특징
1. 매번 코드 생성	풀 스크립트 (매 실행 시)	유연하지만 비용이 높음
2. 데이터만 생성	JSON/YAML	71% 절감 · 안정적인 출력
3. 동적 도구 로딩	코드 (JIT 정의 로딩)	Anthropic MCP: 98.7% 절감

패턴 3은 "AI가 쓰는 양을 줄이는 것"이 아니라 "사용하지 않는 도구 정의를 프롬프트 (Prompt)에 주입하지 않는" 최적화다. 이는 컨텍스트 관리 (Context Management)의 문제이지, 생성량의 문제가 아니다.

CodeAct 논문 (Wang et al., ICML 2024)이 보여주는 경계:

API-Bank (단발성 도구 호출): JSON 경합 (GPT-4: JSON 82.7% vs CodeAct 76.7% —— 단, 이는 태스크 성공률의 지표이며 토큰 비용의 지표가 아니다. 이는 "고정 스키마 태스크에 JSON으로 대항할 수 있음"을 보여주는 것이지 "저렴함"을 의미하는 것이 아니다. 비용에 대한 주장은 이 기사 고유의 실측에 기반한다) -
M3ToolEval (복수 도구 × 복수 턴): CodeAct가 +20pp, 턴 수 30% 감소

판단의 축: 이미 알고 있는 고정 구조를 반복해서 채운다 $\rightarrow$ 패턴 2. 새로운 다단계 문제를 해결한다 $\rightarrow$ CodeAct.

이 세 가지 패턴은 이상적인 형태이며, 서로 배타적인 구현 방식이 아니다. 실제 시스템은 여러 패턴을 조합할 수 있으며, 우리의 경우도 그러했다. 패턴 2가 해결하는 것은 반복 비용이며, 모든 편집 요구사항을 해결하는 것은 아니다. 그림이 단순한 비교표가 아니라 기사 고유의 주장을 담고 있는 경우에는 이 차이가 결정적인 역할을 한다. 그 간극에서 나중에 문제에 봉착하게 될 것이다. 후술할 하이브리드 접근 방식(Hybrid Approach)을 참조하라.

패턴 1의 비용 = (고정 로직 토큰 + 콘텐츠 토큰) × 실행 횟수
패턴 2의 비용 = 초기 셋업 비용 + 콘텐츠 토큰 × 실행 횟수

4개의 그림 × 10개의 기사:

• 패턴 1: 3,106 × 4 × 10 =
  124,240 tokens
• 패턴 2: 899 × 4 × 10 =
  35,960 tokens (88,280 tokens 절약)

이 산출치는 1회의 실측치를 다수의 실행 및 여러 그림 유형으로 외삽(Extrapolation)한 것이며, 방향성을 보여주는 지표일 뿐 보증하는 것은 아니다. 다음 섹션에서 실제로 방어 가능한 범위를 좁혀보겠다.

이 차이는 기간이 길어질수록 효과가 커진다. 운영 기간이 길어질수록 절감액은 쌓여간다.

71%라는 수치는 단일 그림 유형에 대해, Input 문맥이 매우 희박한 두 개의 독립된 프롬프트(각각 415·377 토큰)로 측정한 1회의 최초 성공 생성 수치다. 이것이 가장 큰 주의사항이며, 솔직히 말해두겠다: 다음 요인 중 현시점에서 정량화할 수 있는 것은 단 하나뿐이다. 나머지는 이번 태스크에 명시적으로 적용되지 않거나, 아직 드러나지 않은 리스크에 불과하다.

1. Input 문맥의 희박화 (위의 71%에는 반영되지 않음)

이번 테스트 프롬프트는 고립되어 있었다. 즉, 기사 본문의 문맥, 시스템 프롬프트(System Prompt), 대화 이력(Conversation History)을 전혀 포함하지 않았다. 실제 AI 워커의 세션에서 이 JSON 컨피그(Config)를 생성할 경우, 기사 초안, 이전의 상호작용, 도구 정의 등 훨씬 더 많은 Input 문맥을 동반한다. Input 토큰은 패턴 1과 패턴 2에서 거의 비슷한 크기를 유지하기 때문에(줄어드는 것은 Output뿐이다), 공유되는 Input 문맥이 늘어날수록 전체 절감률은 희석된다. 산출 예시: 공유 Input이 약 400이 아니라 약 5,000 토큰이라고 가정하면, 동일한 Output 수치(2,691 vs 522)에서도 총 비용은 7,691 $
ightarrow$ 5,522 토큰이 되어, 절감률은 **28%**가 된다. 71%가 아니다. 실제 운영 환경에서의 수치는 호출 시의 문맥량에 따라 28%에서 71% 사이 어딘가에 위치할 것이다.

2. 리트라이 오버헤드 (정량화 가능 · 작음)

스키마 검증(Schema Validation) 실패율이 2%이고, 리트라이 프롬프트가 원래의 1.52배라고 가정하면, 플릿(Fleet) 전체에서 +612%의 오버헤드가 어떤 기준값에든 추가된다 (Tianpan 2026).

3. 용량 의존적 포맷 세금 (이번에는 적용되지 않음)

Fan (2026) 「Capacity, Not Format」(arXiv:2606.09410)은 소규모 모델(Haiku)이 추론 부하가 높은 태스크에서 -36pp 이상의 정확도 저하를 일으킨다고 기록했다. 그림 컨피그 생성은 슬롯 필링(Slot-filling)이며 추론(Reasoning)이 아니기 때문에, 이 세금은 이번 측정에는 적용되지 않을 가능성이 높다. 이는 다른 용도에 대한 경계 조건으로 제시된 것이지, 이번 수치에 대한 할인 요소가 아니다.

4. 스키마 복잡도의 붕괴 (미래 리스크 · 현재의 리스크는 아님)

JSONSchemaBench (Geng et al., arXiv:2501.10868): 4레이어 이상의 중첩(Nested)이나 anyOf / oneOf를 사용하는 스키마에서의 제약 조건부 디코딩 커버리지(Constrained Decoding Coverage)는 Outlines에서 3%, OpenAI Strict에서 9%까지 붕괴한다. 현재 스키마는 플랫(Flat)하다. 이는 도구가 성장했을 경우의 리스크이며, 오늘날의 수치에 대한 할인 요소가 아니다.

솔직히 말하자면: 71%는 우리가 측정한 좁은 조건에 대해서는 사실이다. 현시점에서 명확하게 방어할 수 있는 운영 환경에서의 할인 요소는 리트라이 오버헤드뿐이다. Input 문맥의 희박화가 더 큰 미지수이며, 환경에 따라서는 이 섹션의 다른 모든 요인을 합친 것보다 더 큰 영향을 미칠 수 있다. **55~65%**를 작업상의 추정치로 두고 있으나, 이는 하한선이 아니라 완만한 가이드라인으로 취급해주길 바란다.

조건	적절한 선택
단계 간 상태를 가지는 멀티스텝 합성	CodeAct / 패턴 1
...
주의(안티 패턴): 로직이 데이터 필드로 유출되는 현상. 스키마가 너무 경직되어 있으면 모델은 프리 텍스트(Free-text) 필드에 로직을 밀어 넣는다:

"label_text": "{{ compute_from_parent if parent else 'N/A' }}"

JSON으로서 유효하며, 분리의 원칙은 이미 파괴되었다. 스키마가 태스크를 초월한 시그널(Signal)이 된 것이다.

독자적인 발견이라고 주장하기 전에, Perplexity를 통해 딥 리서치(Deep Research)를 수행했다.

유사한 패턴은 이미 존재한다:

• Hrynkow (2025) 「AI Generates Configuration, Not Code」: "AI에게는 행동(Behavior)이 아니라 데이터를 생성하게 하라". 스키마 주도 플랫폼(Schema-driven platform)에서 AI가 JSON을 생성하면, 범용 UI가 이를 렌더링한다.
• 「LLM-MVC」 (data2day 2024): 뷰(View) 레이어를 LLM 없이 정적 템플릿으로 처리하는 명시적인 MVC 분리.
• Anthropic 「Building Effective Agents」 (2024): "출력 포맷에 따라 LLM이 작성하기 극도로 어려운 것들이 있다" —— 이는 일반적인 엔지니어링 지침이며, 특정 패턴을 권장하는 것은 아니다.

토큰 절감 수치 또한 다른 맥락에서 존재한다. Anthropic의 MCP Code Execution 블로그는 도구를 JIT(Just-In-Time) 방식으로 로드하는 방식을 통해 150,000 → 2,000 토큰(98.7% 절감)을 보고했다. CodeAgents 논문(arXiv:2507.03254)은 구조화된 프롬프트(Structured Prompt)를 통해 세 가지 벤치마크에서 입력 토큰을 55~87% 절감함을 보여주었다(절감 메커니즘이 본 기사와 동일하리라는 보장은 없으나, 참조점으로 인용한다).

문서화되지 않았던 점: 반복적인 AI 워커(AI Worker) 운영 맥락에서의 실측 데이터이다.

패턴 2를 여러 기사에서 운용하면서 새로운 문제, 즉 시각적 단조로움이 떠올랐다. 기사가 쌓일수록 모든 도표가 동일한 포맷으로 수렴해 가는 현상이다.

패턴 2가 모든 것을 해결할 것이라고 증명하려 한 것은 아니다. 패턴 2가 해결하는 것은 반복 비용이지, 도표 자체가 스스로의 주장을 담아내야 하는 상황을 대신할 수는 없다. 이는 처음부터 알고 있었던 경계가 아니라, 실제로 부딪히며 발견한 경계였다. 실무적인 대응은 철수가 아닌 재배분이었다. 표준 도표(비교표, 측정 차트)에서 아낀 토큰을 기사 고유의 주장을 담는 단 한 장의 도표 —— 시그니처 도표(Signature Figure) —— 에 투입하는 것이다.

실제 투입하기 전에 세 가지 구현 과제를 먼저 해결해야 했다: 경로 탐색(Path Traversal, 스크립트가 워크스페이스 외부의 파일을 참조할 수 있는 문제), 사이런트 실패(Silent Failure, 에러 발생 시에도 종료 코드 0을 반환하는 문제), 타임아웃 부재. 이를 수정한 후, gen_article_figs.py에 "type": "custom" 이스케이프 해치(Escape Hatch)를 구현했다:

{ "type": "custom", "script": "fig_signature.py", "output": "fig4_signature" }

AI 워커가 fig_signature.py(패턴 1의 풀 스크립트)를 작성하면, 툴이 subprocess로 이를 호출한다. 명령어는 하나로 유지된다.

토큰 비용 비교 (도표 4장):

접근 방식	토큰	기존 방식 대비
전체 패턴 1 (기존)	~4,000	−
...

하이브리드 방식은 전체 패턴 2의 비용을 거의 두 배로 늘리지만, 기존 방식보다는 60% 저렴하면서 기사마다의 시각적 개성을 되찾을 수 있다.

품질의 스케일 보증: "출력 품질: 동일"은 한 명의 인간이 수행한 소규모 샘플 관찰 결과이다. Tam et al. (EMNLP 2024)과 Fan (2026)은 대규모 환경에서는 계통적 편향(Systematic Bias, 수치 반올림 방향으로의 인력이나 필드 간 불일치)이 축적된다고 기록하고 있다.

일반화: 이메일 HTML, 리포트 레이아웃, 슬라이드 구성으로의 적용은 아직 가설 단계이다. 71%라는 수치는 단일 태스크 유형에 대한 측정 결과이다.

선행 사례들의 명칭은 "AI Generates Configuration, Not Code", "LLM-MVC", "Model-Driven Prompting" 등으로 겹치지만 통일되어 있지 않다. 또한 이들 모두 **반복 워커(Iterative Worker)**라는 맥락을 다루고 있지 않다.

우리는 이를 **Content-Rendering Separation Pattern (콘텐츠 렌더링 분리 패턴)**이라 부른다:

렌더러(Renderer)를 툴에 고정하고, AI에게는 콘텐츠 파라미터만 작성하게 하는 방식이다.

새로운 아이디어는 아니다. MVC는 50년 전부터 존재했다. 새로운 점은, AI 워커(AI Worker) 운영에 의도적으로 적용하고, 절감량을 실측하며, 복리 효과를 인식하고——실패 조건을 문서화하는 것이다.

AI 워커를 반복적인 태스크(Task)에 운용하고 있다면, 매번 다시 작성하는 내용 중 몇 %가 구조적인 보일러플레이트(Boilerplate)인지 확인하는 것이 가장 먼저 조사해야 할 지점이다. 더 어려운 질문은, 당신의 출력물 중 어느 것이 표준 도면(Standard diagram, 반복적이고 구조적인 것)이며, 어느 것이 시그니처 도면(Signature diagram, 전력을 다해 투자할 가치가 있는 것)인지 식별해내는 것이다.

AI Worker OS 시리즈 — 제3회

제1회: AI에게 자신의 풀 리퀘스트(Pull Request)를 리뷰하게 해서는 안 되는 이유

제2회: GitHub를 AI 워커 OS로 사용하기