# 이미지 제작 토큰 사용량 최적화 방안 리서치 보고서

**작업 ID**: task-1263.1
**팀**: dev2-team (오딘)
**작업 유형**: Lv.2 리서치
**작성일**: 2026-03-29

---

## 1. 배경 및 문제 정의

### 문제 현상
- **task-1259.1**: 1시간 19분 작업 후 토큰 소진으로 중단 (composite팀, 디자인+QC Phase 2.5~3.5)
- **task-1260.1**: 동시 토큰 소진 (dev2-team, pyright 에러 수정)
- 이미지 5장 제작+QC에 토큰 소비가 극심하여 1회 세션 내 완료 불가

### 근본 원인
이미지 QC 워크플로우 v2.5는 **11개 Phase** (-1, 0, 0.5, 1, 1.5, 2, 2.5, 3, 3.5, 4, 5)를 거치며, Phase 1.5와 3.5는 **최대 3사이클 반복**. 3회 위임 라운드마다 Phase -1 노하우 프리로딩이 반복. 결과적으로 단일 이미지 제작 플로우에 100K~200K+ 토큰이 소비됨.

---

## 2. 웹 서칭 결과 정리

### 2.1 Claude Code 토큰 최적화 Best Practice

**핵심 전략:**
- `/compact`를 70% 용량 도달 시 수동 실행 (auto-compact 95%까지 방치하면 컨텍스트 드리프트 발생)
- `/clear`로 무관한 작업 간 컨텍스트 완전 초기화
- CLAUDE.md 최적화: 매 프롬프트에 prepend되므로 비대해지면 모든 호출에서 토큰 낭비
- 구체적 프롬프트 작성 ("Jira 티켓처럼"): 모호하면 탐색→질문→오답 경로로 토큰 낭비

**API 레벨:**
- Token-efficient tool use: Claude 4 모델에서 기본 활성화 (이전 모델은 beta header 필요)
- Prompt caching: 반복 콘텐츠에 ephemeral 캐시 적용 (5분~1시간)
- Cache-aware rate limits: 캐시 읽기 토큰이 ITPM에 미포함 → 캐싱 활용 시 처리량 대폭 증가

**출처:**
- [Manage costs effectively - Claude Code Docs](https://code.claude.com/docs/en/costs)
- [Stop Wasting Tokens: 60% Optimization](https://medium.com/@jpranav97/stop-wasting-tokens-how-to-optimize-claude-code-context-by-60-bfad6fd477e5)
- [Token-efficient tool use](https://platform.claude.com/docs/en/agents-and-tools/tool-use/token-efficient-tool-use)
- [7 Ways to Cut Token Usage](https://dev.to/boucle2026/7-ways-to-cut-your-claude-code-token-usage-elb)

### 2.2 AI 에이전트 컨텍스트 관리 전략

**ACON (Agent Context Optimization):**
- 압축을 최적화 문제로 취급, paired trajectory 분석으로 full context 대비 compressed context 실패 케이스 추적
- **26~54% peak token 사용량 감소** 달성

**AgentDropout:**
- 멀티에이전트에서 중복 에이전트/통신을 동적 제거
- 평균 **21.6% 입력 토큰, 18.4% 출력 토큰 감소**

**Plan Caching (Agentic Plan Caching):**
- 완료된 에이전트 실행에서 plan template 추출 → 키워드 매칭으로 재사용
- **50.31% 비용 절감, 27.28% 지연 감소**

**컨텍스트 드리프트:**
- 2025년 기업 AI 실패의 **65%가 컨텍스트 드리프트/메모리 손실** 원인
- 30,000 토큰 초과 시 성능 저하 가속 (context rot)

**출처:**
- [Effective context engineering for AI agents - Anthropic](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)
- [AI Agent Context Compression Strategies](https://zylos.ai/research/2026-02-28-ai-agent-context-compression-strategies)
- [AgentDropout Paper](https://arxiv.org/abs/2503.18891)
- [JetBrains Research: Efficient Context Management](https://blog.jetbrains.com/research/2025/12/efficient-context-management/)

### 2.3 프롬프트 압축 기법

**CompactPrompt:**
- self-information scoring으로 저정보 토큰 제거 + n-gram 약어화
- **최대 60% 토큰 절감**, 정확도 손실 5% 미만

**RAG (Retrieval-Augmented Generation):**
- 100페이지 문서에서 상위 3개 관련 청크만 프롬프트에 삽입
- 대용량 참조 문서의 토큰 비용 대폭 절감

**출처:**
- [CompactPrompt Paper](https://arxiv.org/html/2510.18043v1)
- [Prompt Caching: 60% Cost Reduction](https://medium.com/tr-labs-ml-engineering-blog/prompt-caching-the-secret-to-60-cost-reduction-in-llm-applications-6c792a0ac29b)

---

## 3. 우리 시스템 현황 분석

### 3.1 파일 크기 및 토큰 추정

| 파일 | 크기 | 추정 토큰 | 비고 |
|------|------|-----------|------|
| dispatch.py | 57KB | ~23K tok | 프롬프트 빌더+라우터 |
| team_prompts.py | 54KB | ~22K tok | 팀별 프롬프트 템플릿 |
| image_workflow.py | 52KB | ~21K tok | 11개 Phase 프롬프트 |
| DIRECT-WORKFLOW.md | 13KB | ~5K tok | 팀장 워크플로우 |
| design-qc-knowhow.md | 5KB | ~2K tok | QC 피드백 로그 |
| knowhow-design.md | 4.2KB | ~1.7K tok | 디자인 노하우 |
| knowhow-marketing.md | 2.4KB | ~1K tok | 마케팅 노하우 |
| image-workflow-v2.5-final.md | 7.5KB | ~3K tok | 워크플로우 스펙 |

### 3.2 이미지 제작 1건(5장)당 토큰 소비 구조

**Phase별 추정 입력 토큰 (최악 시나리오: 모든 QC 3사이클):**

1차 위임 (Phase -1 ~ Phase 2):
- Phase -1: 노하우 3파일 읽기 = ~4.7K tok
- Phase 0: 브리프 읽기 = ~1K tok
- Phase 0.5: 브리프+QC기준 = ~2K tok
- Phase 1: 브리프+브랜드+마케팅컨텍스트+노하우 = ~8K tok
- Phase 1.5 ×3사이클: (카피+브리프+노하우+QC기준) × 3 = ~12K tok
- Phase 2: QC기준+카피+브리프+노하우 = ~5K tok
- **소계: ~33K tok**

2차 위임 (Phase -1 반복 + Phase 2.5 ~ Phase 3.5):
- Phase -1 (반복): 노하우 3파일 = ~4.7K tok
- Phase 2.5: 파일럿 이미지 3장 읽기 = **~15K~50K tok** (이미지 크기 의존)
- Phase 3: 카피기획서+노하우+디자인가이드 = ~6K tok
- Phase 3.5 ×3사이클: (이미지 읽기+QC기준+노하우) × 3 = **~30K~150K tok** (이미지 토큰 극심)
- **소계: ~56K~211K tok**

3차 위임 (Phase -1 반복 + Phase 4 ~ 5):
- Phase -1 (반복): 노하우 3파일 = ~4.7K tok
- Phase 4: 전체 이미지 읽기+QC기준+카피기획서 = **~25K~100K+ tok**
- Phase 5: 노하우 3파일 정합성 검토 = ~4.7K tok
- **소계: ~34K~110K tok**

**총 추정: ~123K~354K tok (입력만, 출력 토큰 별도)**

### 3.3 토큰 낭비 핵심 포인트 (Top 5)

**1위: 이미지 바이너리 컨텍스트 적재 (~50-70% 비중)**
- Phase 2.5, 3.5, 4에서 PNG 이미지를 Read tool로 직접 열어 시각 평가
- 1080×1080 이미지 1장 = 추정 ~1K~20K+ 토큰 (멀티모달 인코딩)
- 5장 × QC 3사이클 = 최대 15회 이미지 로딩
- **이것이 가장 큰 토큰 소비원**

**2위: QC 사이클 반복 (~15-20% 비중)**
- Phase 1.5: 최대 3사이클 (카피 QC)
- Phase 3.5: 최대 3사이클 (디자인 QC)
- 매 사이클마다 전체 QC 기준, 노하우 파일, 대상 파일을 다시 읽음
- 사이클 간 차분(delta)만 전달하는 메커니즘 없음

**3위: Phase -1 노하우 프리로딩 반복 (~5-10% 비중)**
- 3회 위임 라운드마다 동일 노하우 3파일(~4.7K tok) 재읽기
- 세션 간 메모리 불가로 불가피하나, 요약 캐시로 완화 가능

**4위: 프롬프트 내 중복 QC 기준 (~3-5% 비중)**
- `_build_category_a_section()`, `_build_category_b_section()`, `_build_fail_categories_section()`, `_build_escalation_section()`이 Phase 0.5, 1.5, 2, 3.5, 4 프롬프트에 반복 포함
- 매 Phase 프롬프트에 ~1-2K tok의 QC 기준 텍스트 중복

**5위: 대용량 소스 파일 참조 (~2-3% 비중)**
- image_workflow.py (52KB), dispatch.py (57KB)를 에이전트가 Read할 때 전체 로딩 위험
- offset/limit 분할 읽기 규칙 있으나, 실제 준수 여부 불확실

---

## 4. 적용 가능 방안 우선순위 목록

**평가 기준: 효과 크기(H/M/L) × 구현 난이도(Easy/Medium/Hard)**

### Tier 1: 즉시 적용 가능 (효과 High, 난이도 Easy)

**방안 1: 이미지 QC 자동화 — Playwright 기반 픽셀 검증**
- 효과: ★★★★★ (토큰 절감 50-70%)
- 난이도: Easy-Medium
- 현재: 이미지를 Read tool로 열어 멀티모달 시각 평가 → 토큰 극심
- 개선: A 카테고리(자동 검증)를 Playwright 스크립트로 자동화
  - 글자 겹침(A-01): DOM 요소 bbox 겹침 검사
  - 경계 이탈(A-02): 안전영역 내 존재 확인
  - 해상도(A-03): 이미지 크기 확인
  - 폰트 규칙(A-04): CSS computed style 확인
  - 텍스트 오버플로우(A-06): scrollWidth vs clientWidth
  - 대비율(A-07): 픽셀 샘플링 계산
- 이미지 Read를 B 카테고리 수동 평가에만 한정 → 대폭 절감
- 예상 절감: A카테고리 검증에 이미지 Read 불필요 → 사이클당 ~10-40K tok 절약

**방안 2: Phase 간 /compact 강제 삽입**
- 효과: ★★★★ (토큰 절감 20-30%)
- 난이도: Easy
- 현재: "도구 50회 or 30분" 규칙만 있음 (Phase 전환 시 미적용)
- 개선: 각 Phase 완료 후 /compact 자동 실행 또는 프롬프트에 명시적 지시
- 특히 이미지 Read 후 QC 완료 시 /compact → 이미지 토큰 해제
- 예상 절감: Phase 간 누적 컨텍스트 30-50% 감소

**방안 3: QC 기준 외부 파일 참조화**
- 효과: ★★★ (토큰 절감 5-10%)
- 난이도: Easy
- 현재: 모든 QC Phase 프롬프트에 카테고리 A/B/FAIL/에스컬레이션 인라인 포함
- 개선: QC 기준을 별도 파일(`qc-criteria-compact.md`)에 한 번만 정의하고, 프롬프트에서는 파일 경로만 참조
- 예상 절감: Phase당 ~1-2K tok × 5개 QC Phase = ~5-10K tok

### Tier 2: 단기 적용 가능 (효과 High/Medium, 난이도 Medium)

**방안 4: 노하우 프리로딩 요약 캐시**
- 효과: ★★★ (토큰 절감 5-8%)
- 난이도: Medium
- 현재: Phase -1에서 3개 노하우 파일 전체 읽기 (총 ~4.7K tok × 3라운드 = ~14K tok)
- 개선: 매 워크플로우 시작 시 노하우 핵심 요약을 캐시 파일에 저장 (예: `knowhow-summary-{task_id}.md`, 500자 이내)
- 2차/3차 위임에서는 전체 파일 대신 요약만 참조
- 예상 절감: 2/3차 라운드에서 ~3.5K tok × 2 = ~7K tok

**방안 5: 차분(Delta) QC 사이클**
- 효과: ★★★★ (토큰 절감 15-25%)
- 난이도: Medium
- 현재: QC FAIL 시 전체 내용 재평가
- 개선: 이전 사이클 QC 결과를 구조화된 JSON으로 저장, 다음 사이클에서 변경된 항목만 재검증
- Phase 1.5: "PQ-01 FAIL → PQ-01만 재채점, 나머지 이전 점수 유지"
- Phase 3.5: "FAIL 이미지만 재검수, PASS 이미지 스킵"
- 예상 절감: 2/3차 사이클에서 50-70% 토큰 절약

**방안 6: 이미지 배치 QC (한 번에 다수 검수)**
- 효과: ★★★ (토큰 절감 10-15%)
- 난이도: Medium
- 현재: 이미지를 개별로 Read → 개별 평가
- 개선: 복수 이미지를 한 번의 Read 호출로 비교 평가 (context에 한 번만 로드)
- 단, 이미지 5장 동시 로드 시 context overflow 위험 → 2-3장 단위 배치
- 예상 절감: 중복 프롬프트/기준 전달 횟수 감소

### Tier 3: 중기 구조 개선 (효과 High, 난이도 Hard)

**방안 7: Phase 통합 — 위임 라운드 축소**
- 효과: ★★★★★ (토큰 절감 25-35%)
- 난이도: Hard
- 현재: 3회 위임 라운드 (Phase -1~2 / -1+2.5~3.5 / -1+4~5)
- 개선: 2회로 축소 (Phase -1~1.5 / 2~5), Phase -1 반복 1회 제거
- 위험: 세션당 컨텍스트 부하 증가 → /compact 전략과 병행 필수
- 예상 절감: Phase -1 1회 제거 (~4.7K) + 세션 오버헤드 감소 (~10K)

**방안 8: Playwright 기반 HTML→이미지 파이프라인 최적화**
- 효과: ★★★★ (토큰 절감 15-20%)
- 난이도: Hard
- 현재: Gemini 배경 생성 → HTML 오버레이 → PNG 렌더링 → Read로 QC
- 개선: HTML 렌더링 단계에서 QC A카테고리 자동 검증을 동시 수행
  - 렌더링 스크립트에 자동 검증 로직 내장
  - PASS/FAIL 결과를 JSON으로 반환
  - AI 에이전트는 JSON 결과만 확인 (이미지 Read 불필요)
- 예상 절감: Phase 3.5 사이클당 이미지 Read 전체 제거

**방안 9: Sub-agent 아키텍처 최적화**
- 효과: ★★★ (토큰 절감 10-15%)
- 난이도: Medium-Hard
- 현재: 서브에이전트가 결과를 상세히 반환 → 메인 에이전트 컨텍스트 비대화
- 개선: 서브에이전트 결과를 1,000-2,000 토큰 이내 요약으로 제한
- Anthropic 공식 가이드: "Sub-agents return only condensed summaries"

---

## 5. 총 예상 절감 효과

| 방안 | 예상 절감률 | 구현 기간 |
|------|-----------|----------|
| 방안 1 (Playwright 자동 QC) | 50-70% | 1-2주 |
| 방안 2 (/compact 강제) | 20-30% | 1일 |
| 방안 3 (QC기준 외부파일) | 5-10% | 1일 |
| 방안 4 (노하우 요약 캐시) | 5-8% | 2-3일 |
| 방안 5 (Delta QC) | 15-25% | 3-5일 |
| 방안 6 (배치 QC) | 10-15% | 2-3일 |
| 방안 7 (Phase 통합) | 25-35% | 1주 |
| 방안 8 (파이프라인 통합) | 15-20% | 1-2주 |
| 방안 9 (Sub-agent 최적화) | 10-15% | 3-5일 |

**Tier 1 즉시 적용 시 (방안 1+2+3):** 예상 절감 **60-80%**
**Tier 2 추가 시 (방안 4+5+6):** 추가 **15-25%** 절감
**전체 적용 시:** 현재 대비 **70-90%** 토큰 절감 가능

---

## 6. 발견 이슈 및 해결

### 이슈 1: 이미지 멀티모달 토큰 비용 불투명
- 현황: PNG Read 시 정확한 토큰 소비량 측정 불가 (모델별 인코딩 차이)
- 해결 방향: Playwright 자동 검증으로 이미지 Read 자체를 최소화

### 이슈 2: offset/limit 분할 읽기 규칙 준수 불확실
- 현황: 대용량 파일(50KB+)에 대한 분할 읽기 규칙이 프롬프트에 명시되나 실제 준수 여부 미검증
- 해결 방향: dispatch.py에서 대용량 파일 경고를 자동 생성하는 현재 방식 유지 + 에이전트 프롬프트에 더 강한 제약 추가

---

## 생성/참조 파일 목록
- 생성: `/home/jay/workspace/memory/reports/task-1263.1.md` (본 보고서)
- 생성: `/home/jay/workspace/memory/specs/token-optimization-plan.md` (적용 방안 스펙)
- 참조: `dispatch.py`, `team_prompts.py`, `image_workflow.py`, `DIRECT-WORKFLOW.md`
- 참조: `design-qc-knowhow.md`, `knowhow-marketing.md`, `knowhow-design.md`
- 참조: `image-workflow-v2.5-final.md`