# Agent 미팅: 블로그 이미지 생성 전략 재설계

**날짜**: 2026-04-12
**소집 이유**: 블로그 이미지 생성이 7차례 수정(task-1616.1 ~ task-1670.1)에도 품질 문제 반복. 근본적 아키텍처 전환 논의 필요.
**참여 페르소나**: 토르(백엔드), 미미르(UX/UI), 로키(레드팀), 비너스(디자인)
**진행자**: 오딘(개발2팀장)
**미팅 모드**: hybrid
**토론 깊이**: thorough
**총 사이클 수**: 2

---

## Cycle 1 (Independent Round)

### 오딘 분석
- 근거: image_router.py:281-355의 `_prompt_to_html()`이 Claude CLI(haiku)로 HTML을 매번 새로 생성 → 비결정적 출력
- 근거: 광고 배너는 사전 정의 템플릿 + 변수 치환 → 결정적 출력
- 근거: 스크린샷 5개 중 #3(Gemini photo)만 양호, #5(checklist)에서 프롬프트 텍스트 출력 버그 재발
- 핵심 질문: LLM이 HTML을 매번 생성하는 아키텍처 유지 가능한가, 근본적 전환 필요한가?

### 페르소나 의견
**토르**: "LLM은 시맨틱 생성기이지 픽셀 정밀 렌더러가 아니다." 결정론적 파이프라인(템플릿)으로 전환 강력 권장. Composition 패턴으로 템플릿 폭발 방지. subprocess 제거로 복잡도 감소.

**미미르**: "디자인은 제약의 산물인데 제약이 프롬프트 텍스트로만 존재한다." 5유형 × 2~3변형 = 10~15개 템플릿이면 충분. 블로그 이미지에 컴포넌트 라이브러리가 없는 것이 근본 원인.

**로키**: 템플릿 방식의 실패 시나리오: 템플릿 폭발, 분류 SPOF. "블로그 이미지가 정말 필요한가?" 근본적 필요성 질문. Figma API 대안 제시.

**비너스**: Gemini는 텍스트 렌더링이 본질적으로 취약, photo 유형에만 적합. 텍스트 헤비 유형은 네이티브 HTML 컴포넌트로 전환 제안.

### 합의/결론
- 전원 합의: LLM HTML 생성 → 사전 정의 템플릿 기반으로 아키텍처 전환
- 전원 기각: 전략 C(프롬프트 강화) — 7번 실패가 증거
- 제한 합의: Gemini는 photo 유형에만 사용

### 미해결 항목
- 템플릿 폭발 관리 방법
- 네이티브 HTML 전환 실행 가능성
- 품질 판정 기준 정량화

---

## Cycle 2 (Sequential Round)

### 오딘 분석
Cycle 1에서 전략 A(템플릿)에 전원 합의 달성. Cycle 2는 구체적 구현 계획과 미해결 항목 심화.

### 페르소나 의견
**토르**: 
- `_prompt_to_html()` → `_extract_structured_json()` 교체 설계
- JSON 스키마: {type, title, subtitle, items[]} 공통 구조
- Composition 패턴: 레이아웃 셸 5개 + design-tokens.json + 데이터 슬롯 3계층
- 테스트 매트릭스: 5유형 × 3난이도 = 15개 이미지
- 비용: 토큰 75% 절감 예상 (HTML ~2K → JSON ~500 토큰)

**미미르**:
- 5유형별 레이아웃 설계 원칙 (위계, 폰트 스케일, 색상, 여백 구체화)
- JSON 슬롯 보완: subtitle, brandColor 추가
- 품질 판정 5개 기준 정량화: 텍스트 가독성, 오버플로, 시각 균형, 데이터 완전성, 파일 크기
- 네이티브 HTML은 듀얼 렌더링(본문 HTML + OG PNG)으로 현실화

### Devil's Advocate (로키)
**지정**: 로키 (Cycle 2 DA)
1. **실패 시나리오**: JSON 스키마 지옥 — 혼합형 콘텐츠가 30~40% 차지 시 스키마 폭발. type 분류가 SPOF화.
2. **후회 이유**: 유지보수 복잡도 2배 (2언어, 3템플릿 시스템, 2렌더링 경로). 온보딩 비용 반나절→이틀.
3. **더 단순한 대안**: LLM HTML 생성 유지 + 후처리 정규화 레이어 (CSS 변수 주입, 폰트 강제 보정, 오버플로 자동 축소)

**반박**: 
- 스크린샷 #1(아이콘만), #5(프롬프트 텍스트 출력)는 구조적 실패 → 후처리로 해결 불가
- 복잡도 우려는 유효 → Jinja2+Playwright 이중 경로 제거로 단순화
- "generic" fallback 타입 추가로 분류 SPOF 완화

**판정**: 반박 수용. 복잡도 우려를 반영하여 Satori 단일 렌더링 경로로 통합.

### 비관습적 대안
**로키 제안**: "Screenshot-as-a-Service" — 블로그 본문을 브라우저에서 렌더링 후 스크린샷으로 OG 이미지 생성
- 최강 지지 논거: 템플릿/스키마 일체 불필요
- 최강 반론: OG 비율 최적화 안 되어 있음
- 이상적 시나리오: 카드형 히어로 섹션이 있는 블로그
- 노력: 반나절
- 리스크: 중

**판정**: 기각. 현재 블로그에 OG 최적화된 히어로 섹션 미존재. 향후 블로그 리디자인 시 재검토 가능.

### 합의/결론
전원 합의 달성.

---

## Temporal Interrogation

```
[HOUR 1] 스키마 설계 + 구조 결정:
- [RESOLVED] JSON 스키마 5유형: infographic/comparison_table/checklist/process_flow/chart
- [RESOLVED] _prompt_to_html(281-355행) → _extract_structured_json() 교체. Claude CLI 호출 구조 재사용, 프롬프트만 변경
- [RESOLVED] items[] 최대 개수: design-tokens.json의 maxItems로 관리 (comparison=8, checklist=10, process_flow=6, chart=8, infographic=6)

[HOUR 2-3] 핵심 구현:
- [RESOLVED] satori_cli.js --json 모드 추가. 기존 --prompt 모드 유지 (하위 호환)
- [RESOLVED] design-tokens.json 우선순위: global < type-specific < JSON palette_override. 기존 하드코딩 값은 global 토큰으로 마이그레이션
- [RESOLVED] _render_html_to_png(358-395행) Playwright 경로 → Satori 단일 경로로 통일

[HOUR 4-5] 통합 + Fallback:
- [RESOLVED] INFOGRAPHIC fallback 체인(491행) 유지. _generate_infographic 내부만 JSON+Satori로 변경
- [RESOLVED] 테스트 파일 TestPromptToHtml → TestExtractStructuredJson으로 교체. Mock 반환값 dict 구조
- [RESOLVED] photo 유형 Gemini Pro 경로 변경 없음

[HOUR 6+] 마무리 + QC:
- [RESOLVED] 기존 _validate_image_quality(398-457행) 5개 검증 항목 그대로 활용
- [RESOLVED] JSON 재시도: 기본 3회 + 파싱 에러 시 피드백 포함 1회 = 최대 4회
```

---

## 최종 합의 사항

1. **아키텍처 전환**: `_prompt_to_html()` → `_extract_structured_json()` + Satori 고정 템플릿. LLM은 HTML 생성하지 않고 JSON 데이터 추출만 담당.
2. **JSON 스키마**: {type, title, subtitle, items[]} 공통 + 유형별 items 구조 차이
3. **렌더링**: Satori 단일 경로 (Playwright 이중 경로 불채택)
4. **템플릿 관리**: Composition 패턴 (레이아웃 셸 5개 + design-tokens.json)
5. **품질 검증**: 자동 QC 5개 기준 (기존 _validate_image_quality 활용)
6. **photo 유형**: Gemini Pro 유지 (변경 없음)
7. **generic fallback**: 분류 불능 시 범용 카드 레이아웃 사용
8. **비용 절감**: LLM 토큰 75% 절감 예상 (HTML ~2K → JSON ~500)

## 미해결 항목
- 없음 (Temporal Interrogation에서 전 항목 RESOLVED)

## 다음 단계

### 합의 사항 → 구현 태스크 매핑
- 합의 1-4: 백엔드(토르) 구현 — image_router.py 리팩터링 + satori_cli.js --json 모드
- 합의 4: UX(미미르) 설계 — design-tokens.json + 5유형 레이아웃 사양
- 합의 5: 테스터(헤임달) 검증 — 15개 이미지 매트릭스 테스트
- 합의 6: 변경 없음
- 합의 7: 백엔드(토르) — generic fallback 레이아웃 추가

### 수정 대상 파일
- `/home/jay/workspace/tools/ai-image-gen/image_router.py` (핵심 리팩터링)
- `/home/jay/workspace/tools/ai-image-gen/satori-test/satori_cli.js` (--json 모드 추가)
- `/home/jay/workspace/tools/ai-image-gen/test_image_router.py` (테스트 갱신)
- 신규: `infographic_schema.py` (JSON 스키마 정의)
- 신규: `design-tokens.json` (디자인 토큰)

### 성공 기준
- 5개 유형 × 3개 프롬프트 = 15개 이미지 모두 자동 QC 통과
- 프롬프트 텍스트 출력 버그(#5) 재발 0건
- 아이콘만 배치 문제(#1) 재발 0건