# task-1263.1 토큰최적화 리서치 — 로키(Devil's Advocate) 비판적 재검토

**작업 ID**: task-1265.1
**팀**: dev1-team (헤르메스)
**작업 유형**: Lv.1 리뷰/분석
**작성일**: 2026-03-29
**원본 보고서**: `/home/jay/workspace/memory/reports/task-1263.1.md`
**원본 스펙**: `/home/jay/workspace/memory/specs/token-optimization-plan.md`

---

## SCQA

**S**: task-1263.1에서 이미지 QC 워크플로우의 토큰 소비 문제를 분석하고, 9개 방안을 Tier 1/2/3으로 분류한 최적화 로드맵이 제시되었다.

**C**: 보고서에 사실 오류 4건, 절감률 과대추정, 우선순위 오류 3건, 놓친 최적화 기회 6건이 발견되었다. 그대로 구현하면 기대 효과를 달성하지 못하고, 잘못된 함수를 수정하는 비용 낭비가 발생할 수 있다.

**Q**: 보고서의 약점을 수정하고 놓친 기회를 보완하면 현실적으로 달성 가능한 절감률은 얼마인가?

**A**: 사실 오류를 정정하고, 놓친 기회(저해상도 QC 이미지, 선택적 노하우 로딩, 에스컬레이션 섹션 중복 제거, 프롬프트 캐싱 활용)를 추가하면, Tier 1에서 현실적 30-45% 절감, 전체 적용 시 50-65% 절감이 가능하다. 원본 보고서의 "70-90%" 추정은 과대하며, "50-65%"로 하향 조정이 필요하다.

---

## 1. 사실 오류 (Factual Errors) — 4건

### 오류 1: dispatch.py 파일 경로
- **보고서 주장**: `dispatch.py`가 `prompts/` 하위에 위치 (파일 크기 표에서 나열)
- **실제**: `/home/jay/workspace/dispatch.py` (루트 레벨). `prompts/dispatch.py`는 존재하지 않음
- **영향**: 낮음 (크기 추정 57KB vs 실제 56,983B는 정확)

### 오류 2: knowhow-design.md 파일 크기
- **보고서 주장**: 4.2KB (~1.7K tok)
- **실제**: 6,037B (6.0KB, ~2.4K tok)
- **영향**: 노하우 3파일 총 토큰 추정 오류. 보고서 ~4.7K tok → 실제 ~5.4K tok. Phase -1 프리로딩 비용을 15% 과소 추정

### 오류 3: QC 기준 섹션 분포 오류
- **보고서 주장**: `_build_category_a_section`, `_build_category_b_section`, `_build_fail_categories_section`, `_build_escalation_section`이 "Phase 0.5, 1.5, 2, 3.5, 4 프롬프트에 반복 포함"
- **실제 분포** (코드 검증 결과):
  - `_build_category_a_section`: Phase 2, 3.5, 4, overview (4곳) — Phase 0.5, 1.5에는 **없음**
  - `_build_category_b_section`: Phase 2, 4, overview (3곳) — Phase 3.5에도 **없음**
  - `_build_fail_categories_section`: Phase 2, 4, overview (3곳)
  - `_build_escalation_section`: Phase 0, 1, 2, 3, 3.5, 4, overview (**7곳** — 보고서 미언급)
- **영향**: 높음. 스펙 A-2에서 수정 대상 함수를 잘못 지정 (아래 오류 4 참조)

### 오류 4: 스펙 A-2 수정 대상 함수 오류
- **스펙 주장**: `build_phase0_5_prompt`, `build_phase1_5_prompt`를 QC 기준 외부 파일 참조 대상으로 지정
- **실제**: 이 두 함수에는 `_build_category_a/b/fail_categories` 호출이 **없음**. 수정해도 효과 없음
- **놓친 대상**: `build_phase0_prompt`, `build_phase1_prompt`, `build_phase3_prompt`에 있는 `_build_escalation_section` (각각 1회씩, 총 3곳)이 수정 대상에서 누락
- **영향**: 치명적. 실행하면 의미 없는 함수 2개를 수정하고 실제 중복 3곳을 놓침

---

## 2. 절감률 과대추정 (Overestimated Savings)

### 방안 1 (Playwright 자동 QC): 50-70% → 현실적 20-35%

과대추정 근거:
1. **B카테고리는 여전히 이미지 Read 필요**: A카테고리(기술 검증)만 자동화하더라도 B카테고리(디자인 품질 평가)는 시각 평가가 필수. B카테고리 5개 항목 × 이미지 5장 = 여전히 다수의 이미지 Read 발생
2. **PNG 단독 이미지 한계**: Gemini 생성 배경 이미지는 HTML DOM이 없어 Playwright DOM 검사 불가. 보고서 자체도 리스크 2에서 인정하면서 난이도를 "Easy-Medium"으로 평가한 것은 모순
3. **50-70%는 "비중"이지 "절감률"이 아님**: 이미지 바이너리가 전체의 50-70%를 차지한다는 것과, 그 50-70%를 전부 제거할 수 있다는 것은 다른 주장. A카테고리 자동화로 제거 가능한 이미지 Read는 전체 이미지 Read의 40-50% 수준

### 방안 2 (/compact 강제): 20-30% → 현실적 10-15%

과대추정 근거:
1. **/compact는 "이미 소비된 토큰"을 줄이지 않음**: /compact는 이후 API 호출의 입력 컨텍스트를 줄이는 것이지, 이미 전송된 토큰을 회수하지 않음. 절감 효과는 "잔여 Phase의 입력 토큰 감소"에 한정
2. **컨텍스트 손실 리스크**: QC 사이클 중간에 /compact를 실행하면 이전 사이클 결과, 피드백 내용 등이 손실될 수 있음. 체크포인트 저장 규칙이 있으나 준수율 불확실
3. **3회 위임 구조에서 이미 컨텍스트 초기화됨**: 3개 세션으로 나뉘므로 세션 간 컨텍스트는 이미 리셋. /compact의 효과는 세션 내 Phase 간에만 적용

### Tier 1 합산: "60-80%" → 현실적 30-45%

보고서의 절감률을 단순 합산할 수 없다는 점은 제쳐놓더라도, 개별 추정치의 하향 조정만으로도:
- 방안 1: 20-35%, 방안 2: 10-15%, 방안 3: 3-7%
- 복합 효과: 1 - (1-0.275)(1-0.125)(1-0.05) ≈ 40%
- 현실적 Tier 1 절감: **30-45%**

### 전체 합산: "70-90%" → 현실적 50-65%

---

## 3. 우선순위 오류 (Priority Misalignment) — 3건

### 오류 1: 방안 1(Playwright 자동 QC)을 Tier 1 "즉시 적용"으로 분류
- **문제**: "Easy-Medium" 난이도 평가가 비현실적. Playwright 기반 DOM bbox 겹침 검사, WCAG 대비율 계산, scrollWidth 비교 등은 개별적으로는 단순하나 통합 테스트·엣지 케이스·PNG 대응까지 포함하면 "Medium-Hard" 수준
- **제안**: Tier 2로 이동 (구현 기간 1-2주 → 2-3주)
- **대안**: 즉시 적용 가능한 "저해상도 QC 이미지" 방안을 Tier 1에 추가 (아래 놓친 기회 1번)

### 오류 2: 방안 4(노하우 요약 캐시)를 Tier 2로 분류
- **문제**: 500자 요약 캐시는 파일 1개 생성 + 프롬프트 조건문 2줄 추가로 구현 완료. "Medium" 난이도 평가가 과대
- **제안**: Tier 1 "즉시 적용"으로 승격 (구현 기간 1시간 이내)

### 오류 3: 방안 9(Sub-agent 최적화)를 마지막으로 분류
- **문제**: 우리 시스템은 다층 에이전트 아키텍처. 서브에이전트 결과 크기 제한은 프롬프트에 1줄 추가로 구현 가능하며, 모든 팀 작업에 적용 가능한 범용 최적화
- **제안**: Tier 1-2로 승격 (난이도 Easy, 효과 Medium)

---

## 4. 놓친 최적화 기회 (Missed Opportunities) — 6건

### 기회 1: 저해상도 QC 이미지 (예상 절감 25-40%)
- **현재**: 1080x1080 PNG를 그대로 Read로 로드하여 QC
- **제안**: QC용 540x540 또는 360x360 썸네일 자동 생성 후 QC에 사용. 멀티모달 토큰 비용은 픽셀 수에 대략 비례하므로 1/4~1/9로 감소
- **장점**: 코드 변경 최소 (이미지 리사이즈 1줄), 모든 이미지 타입(HTML/PNG/Gemini)에 적용 가능, Playwright 불필요
- **난이도**: Easy (Python Pillow `resize()` 1줄)
- **우선순위**: Tier 1 최상위 — 가장 적은 노력으로 가장 큰 효과

### 기회 2: _build_escalation_section 중복 제거 (예상 절감 2-4%)
- **현재**: 7개 함수에서 반복 호출 (Phase 0, 1, 2, 3, 3.5, 4, overview)
- **제안**: 에스컬레이션 규칙도 외부 파일 참조화. QC 기준(A-2)과 동일 패턴
- **보고서 누락**: QC 기준 4개 섹션 중 _build_escalation_section만 7곳으로 최다 중복인데, 보고서에서 아예 분석 대상에서 빠짐

### 기회 3: 선택적 노하우 로딩 (예상 절감 2-3%)
- **현재**: Phase -1에서 3개 파일 모두 읽기
- **제안**: Phase별 필요 노하우만 로딩
  - 1차 위임 (카피 Phase): marketing knowhow + QC knowhow만 (design 불필요)
  - 2차 위임 (디자인 Phase): design knowhow + QC knowhow만 (marketing 불필요)
- **절감**: 라운드당 ~2K tok × 2 라운드 = ~4K tok

### 기회 4: dispatch.py --workflow 이중 적재 문제 (예상 절감 3-5%)
- **현재**: `--workflow image-qc-gate` 사용 시 dispatch.py가 `build_workflow_overview_prompt()`를 호출하여 전체 QC 기준(A+B+FAIL+에스컬레이션)을 task description에 prepend. 이후 에이전트가 개별 Phase 프롬프트 실행 시 동일 QC 기준을 다시 포함
- **결과**: QC 기준이 초기 프롬프트와 Phase 프롬프트에 **이중으로** 적재
- **제안**: workflow overview에서는 Phase 목록과 흐름만 포함하고, QC 기준은 개별 Phase에서만 로드

### 기회 5: 프롬프트 캐싱 구조 최적화
- **현재**: 보고서가 Anthropic prompt caching을 리서치 결과로 언급만 하고 적용 방안 미제시
- **제안**: 프롬프트를 "안정 접두부(QC 기준, 노하우, 워크플로우 구조) + 가변 접미부(Phase별 작업 지시)"로 구조화. 안정 접두부는 캐싱되어 90% 비용 감소
- **제약**: API 직접 호출 시에만 적용 가능 (Claude Code CLI에서는 자동 관리)

### 기회 6: 모델 계층 최적화
- **현재**: 보고서가 모델 선택을 전혀 언급하지 않음
- **제안**: A카테고리 기계적 QC는 Haiku로, B카테고리 창작 평가는 Sonnet으로 분리 실행. Haiku는 Sonnet 대비 ~90% 저렴
- **효과**: QC 비용 50-70% 절감 (토큰 수는 동일하나 비용 절감)

---

## 5. 우리 시스템 적용 시 문제점 — 4건

### 문제 1: /compact의 기술적 한계
- 이미지 워크플로우가 Agent tool로 팀원을 소환하는 경우, 서브에이전트 내에서는 /compact 실행 불가 (Claude Code CLI 기능)
- /compact가 효과적인 것은 메인 세션 수준에서 Phase 간 전환 시에만 해당
- **스펙 수정 필요**: /compact 적용 위치를 "메인 세션의 Phase 간 전환 시"로 한정

### 문제 2: 차분(Delta) QC의 판단 비용
- 방안 5에서 "변경 항목만 재검증"하려면, 에이전트가 "어떤 변경이 어떤 QC 항목에 영향을 미치는지"를 판단해야 함
- 이 판단 자체가 추가 토큰을 소비하며, 잘못된 판단은 품질 저하로 이어짐
- **안전장치 필요**: "레이아웃 변경 시 전체 재채점" 규칙이 보고서에 언급되었으나, 이 규칙이 실제 프롬프트에서 어떻게 강제되는지 구체적 구현이 없음

### 문제 3: QC 기준 외부 파일 참조의 역효과
- 방안 3에서 QC 기준을 외부 파일로 분리하면, 에이전트가 매 Phase마다 해당 파일을 Read해야 함
- 인라인 포함 시: 프롬프트에 1회 포함 (prompt caching 가능)
- 외부 파일 참조 시: Read tool 호출 → 응답에 파일 내용 포함 → 매 Phase마다 반복
- **결론**: prompt caching이 활성화된 환경에서는 외부 파일 참조가 오히려 비효율적일 수 있음. 환경에 따라 효과가 달라지므로, A/B 테스트로 검증 필요

### 문제 4: 방안 7(Phase 통합)의 컨텍스트 폭발 위험
- 3회 위임 → 2회로 축소하면 2차 세션이 Phase 2.5~5까지 담당
- Phase 3.5(디자인 QC 3사이클) + Phase 4(최종 검증) + Phase 5(노하우 종합)을 한 세션에 수행
- 이미지 Read가 집중되는 Phase 3.5~4가 한 세션에 있으면, /compact를 적용하더라도 30K 토큰 임계치를 빈번히 초과하여 성능 저하(context rot) 위험
- **전제 조건**: Playwright 자동 QC + 저해상도 이미지가 선행 적용되어야만 안전

---

## 6. 수정 권고 요약

**보고서/스펙에 수정이 필요한 항목 (직접 수정하지 않고 기록만 함):**

1. dispatch.py 경로 수정: `prompts/dispatch.py` → `/home/jay/workspace/dispatch.py`
2. knowhow-design.md 크기 수정: 4.2KB → 6.0KB, 노하우 총 토큰 ~4.7K → ~5.4K
3. 스펙 A-2 수정 대상 함수 정정:
   - 제거: `build_phase0_5_prompt`, `build_phase1_5_prompt` (QC 섹션 없음)
   - 추가: `build_phase0_prompt`, `build_phase1_prompt`, `build_phase3_prompt` (에스컬레이션 섹션 있음)
4. 방안 1 우선순위 하향: Tier 1 → Tier 2, 난이도 Easy-Medium → Medium-Hard
5. 방안 4 우선순위 상향: Tier 2 → Tier 1, 난이도 Medium → Easy
6. 절감률 하향 조정: Tier 1 60-80% → 30-45%, 전체 70-90% → 50-65%
7. 놓친 기회 6건 추가 (특히 저해상도 QC 이미지를 Tier 1 최상위로)

---

## 참조 파일 목록

- 분석 대상: `/home/jay/workspace/memory/reports/task-1263.1.md`
- 분석 대상: `/home/jay/workspace/memory/specs/token-optimization-plan.md`
- 검증 참조: `/home/jay/workspace/prompts/image_workflow.py` (52,054B)
- 검증 참조: `/home/jay/workspace/prompts/team_prompts.py` (53,983B)
- 검증 참조: `/home/jay/workspace/dispatch.py` (56,983B)
- 검증 참조: `/home/jay/workspace/memory/specs/image-workflow-v2.5-final.md` (7,460B)
- 검증 참조: `/home/jay/workspace/memory/specs/design-qc-knowhow.md` (5,077B)
- 검증 참조: `/home/jay/workspace/memory/specs/knowhow-design.md` (6,037B)
- 검증 참조: `/home/jay/workspace/memory/specs/knowhow-marketing.md` (2,431B)