# 에이전트 미팅 Cycle 1: 이미지 워크플로우 v2 QC 게이트 설계
> task-id: task-1245.1 | 일시: 2026-03-29

## 주제
이미지 제작 워크플로우 v2 — QC 게이트 시스템 설계

## 배경
광고 배너 v1~v6 연속 실패 (글자 겹침, 텍스트 중복, 빈 공간, 크리에이티브 브리프 부재).
제이회장님이 4Phase 워크플로우 확정:
- Phase 1: 카피/기획 (마케팅)
- Phase 2: 카피 QC (마아트) → FAIL 시 Phase 1 리턴
- Phase 3: 디자인 실행 (디자인팀) — satori 금지, hybrid/gemini만
- Phase 4: 디자인 QC (마아트) → FAIL 시 Phase 3 리턴
- 노하우 축적: QC FAIL마다 `design-qc-knowhow.md`에 누적

## 참석자
- 헤르메스 (퍼실리테이터, 개발1팀장)
- 아프로디테 (마케팅팀장)
- 페이토 (카피라이터)
- 아마테라스 (디자인팀장)
- 마아트 (QC 매니저)
- 로키 (레드팀)

---

## 토론 기록

---

### [안건 1] 워크플로우 빈틈
> 이 프로세스에서도 실패할 수 있는 시나리오는?

---

**Round 1: 독립 의견**

**아프로디테 (마케팅팀장):**
현재 워크플로우에서 가장 위험한 빈틈은 Phase 1 인풋 품질이다. "카피/기획" 단계가 시작되기 전에 **크리에이티브 브리프가 없으면** 아무리 QC를 강화해도 소용없다. v1~v6 실패의 근본 원인은 "뭘 만들지 정의가 안 된 채 디자인부터 들어간 것"이다. 브리프 없이 Phase 1에 진입하는 케이스를 막는 게이트가 현재 설계에 없다. Phase 0(브리프 검증)이 필요하다.

**페이토 (카피라이터):**
카피 QC(Phase 2)가 FAIL되면 Phase 1으로 돌아가는 구조인데, **카피 수정 횟수에 상한이 없다.** 무한 루프 시나리오가 존재한다. 마케팅팀이 계속 브리프 변경을 요청하거나, QC 기준이 불명확하면 Phase 1↔2 사이에서 3~5회 반복이 일어난다. 또한 카피가 확정된 뒤 디자인 단계에서 "이 카피는 이미지에 안 들어간다"는 기술적 제약 발견 시 다시 Phase 1로 돌아와야 하는지 프로세스가 정의되어 있지 않다.

**아마테라스 (디자인팀장):**
기술적 빈틈이 두 개다. 첫째, **hybrid/gemini 렌더러의 한계 스펙이 명시되어 있지 않다.** 카피 길이, 폰트 크기, 이미지 해상도 요구사항이 Phase 1 기획 단계에서 공유되지 않으면 디자이너는 기술 제약을 모른 채 카피를 받는다. 둘째, Phase 3에서 디자인이 완성되기 전에 **중간 시안 리뷰 포인트가 없다.** 완성 후 Phase 4 QC에서 전면 수정 필요 판정이 나면 Phase 3 전체를 반복해야 한다.

**마아트 (QC 매니저):**
QC 단계 자체의 빈틈이다. Phase 2(카피 QC)와 Phase 4(디자인 QC)의 **PASS 기준이 현재 문서화되어 있지 않다.** "프로 에이전시 수준"이라는 기준은 주관적이며, QC 담당자가 바뀌면 기준이 달라진다. 또한 Phase 4에서 FAIL이 발생했을 때 디자인팀이 수정하면 **동일 기준으로 재검수하는지** 확인하는 절차가 없다. 기준 없는 재검수는 새로운 실패를 발생시킨다.

**로키 (레드팀):**
이 워크플로우 전체가 **"에이전트가 Phase를 스킵하거나 자의적으로 단계를 병합할 것"을 가정하지 않는다.** 실제 에이전트 실행 환경에서는 컨텍스트 길이 제한, 비용 압박, 타임아웃 등의 이유로 Phase 2(카피 QC)를 "자동 PASS"로 처리하거나 Phase 1+2를 하나로 묶어버리는 현상이 발생한다. v1~v6 실패 자체가 이미 이런 패턴이었다. **워크플로우 우회를 기술적으로 막는 장치**가 없으면 이 설계도 같은 운명이다. QC FAIL 기록이 `design-qc-knowhow.md`에 쌓여도 에이전트가 그것을 읽지 않으면 무용지물이다.

---

**Round 2: 교차 토론**

**아프로디테 → 로키 반박:**
로키의 지적("Phase 스킵")은 실질적 위협이다. 동의한다. 그러나 이를 막으려면 **각 Phase의 Output을 파일로 강제 저장**하고, 다음 Phase는 해당 파일 존재 여부를 확인한 후에만 시작할 수 있도록 dispatch.py에서 게이트를 걸어야 한다. 브리프 미작성 → Phase 0 게이트 막힘 → 진행 불가 구조가 필요하다.

**페이토 → 아마테라스 보완:**
아마테라스가 말한 "기술 제약 미공유" 문제는 카피 작성 단계에서 이미 치명적이다. 내가 받는 브리프에 "최대 글자 수 제한", "헤드카피 1줄 / 서브카피 2줄" 같은 **기술 스펙 체크리스트**가 포함되어야 한다. 지금은 그게 없다. Phase 1 브리프 템플릿에 기술 제약 필드를 반드시 추가해야 한다.

**아마테라스 → 마아트 질문:**
마아트가 말한 "재검수 절차 없음" 문제에 동의한다. 디자인팀 입장에서는 FAIL 사유가 구체적이어야 수정 방향을 알 수 있다. "전반적으로 부족함"이 아닌 **항목별 체크리스트 형태의 FAIL 리포트**가 필요하다. 그 리포트를 기반으로 수정 후 해당 항목만 집중 재검수하면 효율이 높아진다.

**마아트 → 페이토 반박:**
무한 루프 우려는 맞지만, **루프 제한을 숫자로 박으면 오히려 위험하다.** "3회 이상 FAIL이면 에스컬레이션" 같은 룰이 없으면, 에이전트가 "3회 채웠으니 억지로 PASS" 처리하는 상황이 생긴다. 루프 카운터보다는 **FAIL 사유가 이전 FAIL과 동일한지 비교하는 로직**이 필요하다. 같은 사유로 반복 FAIL이면 프로세스 문제로 에스컬레이션해야 한다.

**로키 → 전체 공격:**
여러분이 논의하는 해결책들(파일 게이트, 체크리스트, FAIL 리포트)은 모두 **"에이전트가 성실하게 따른다"는 전제 위에 있다.** 그러나 현실은 다르다. dispatch.py가 Phase 파일 존재를 확인한다고 해도, 에이전트가 **빈 파일을 생성해 게이트를 통과**하거나, 체크리스트를 형식적으로만 채우는 "GIGO(Garbage In, Garbage Out) 패턴"이 발생한다. 실제로 v3, v4에서 크리에이티브 브리프가 있었음에도 실패했다. 브리프가 있었지만 **구체성이 없었던 것**이 문제였다. 형식 충족 != 품질 충족이다. QC는 파일 존재 확인이 아니라 **내용 검증**이어야 한다.

**아프로디테 → 로키 재반박:**
로키 말이 맞다. 내용 검증 없는 게이트는 형식적이다. 그러나 현재 논의에서 가장 중요한 것은: 아무 것도 없는 것보다 체크리스트가 낫다. **체크리스트 자체가 검증의 기준점이 된다.** 빈 파일 문제는 dispatch.py 레벨에서 파일 크기 또는 필수 필드 파싱으로 감지할 수 있다.

---

**Round 3: 합의 시도**

**합의 달성:**
1. Phase 0(브리프 검증 게이트) 추가 필요 — 만장일치
2. 각 Phase Output을 파일로 강제 저장하고, dispatch.py가 내용(필수 필드) 검증 후 다음 Phase 진입 허용 — 만장일치
3. Phase 1 브리프 템플릿에 기술 제약 필드(최대 글자 수, 레이아웃 스펙) 포함 — 만장일치
4. QC FAIL 리포트는 항목별 체크리스트 형태로 출력 — 만장일치

**미합의:**
- 루프 횟수 상한 설정 여부: 페이토(3회 상한 찬성) vs 마아트(횟수 상한 반대, 사유 비교 로직 선호) — **다음 사이클 논의 필요**
- Phase 3 중간 시안 리뷰 포인트 추가 여부: 아마테라스(찬성) vs 로키("또 다른 게이트 남발로 오버헤드 증가" 반대) — **다음 사이클 논의 필요**

---

### [안건 2] 마아트 QC 기준
> "프로 에이전시 수준"을 어떻게 정량화할 것인가?

---

**Round 1: 독립 의견**

**아프로디테 (마케팅팀장):**
마케팅 관점에서 "프로 에이전시 수준"은 **광고 효과 예측 가능성**이다. 구체적으로는: (1) 메시지가 3초 이내에 전달되는가, (2) 브랜드 컬러·폰트 가이드를 준수하는가, (3) CTA가 명확히 보이는가. 이 세 가지를 Yes/No로 먼저 판단하고, 각 항목에 1~5점 척도를 부여하는 방식을 제안한다. 총점 12점 이상이면 PASS.

**페이토 (카피라이터):**
카피 관점에서 QC 기준은 **카피의 기능 충족 여부**다. (1) 헤드카피가 핵심 메시지를 1문장으로 담고 있는가, (2) 서브카피가 헤드카피를 보완하는가 (중복이 아닌), (3) 맞춤법·문법 오류가 없는가, (4) 타겟 고객의 언어로 쓰였는가. 이 4개 항목은 Pass/Fail 이진 판단이 맞다. 하나라도 Fail이면 전체 FAIL.

**아마테라스 (디자인팀장):**
디자인 QC 기준은 **기술적 정확성 + 시각적 완성도** 두 레이어다. 기술: (1) 텍스트가 이미지 경계 밖으로 나가지 않음, (2) 글자 겹침 없음, (3) 해상도 요구사항 충족(최소 72dpi 웹/300dpi 인쇄). 시각: (4) 텍스트 가독성(배경 대비 4.5:1 이상 — WCAG AA 기준), (5) 여백 균형(좌우 여백이 전체 너비의 10% 이상). 기술 항목은 자동화 가능, 시각 항목은 수동 검수 필요.

**마아트 (QC 매니저):**
QC 기준의 핵심은 **체크리스트가 실행 가능해야 한다는 것**이다. "아름다운가?"는 QC 기준이 아니다. 내가 제안하는 구조: **카테고리 A(자동 검수 — 규칙 기반)** + **카테고리 B(수동 검수 — 판단 필요)**. A 카테고리: 글자 겹침 감지, 텍스트 경계 이탈, 해상도, 파일 포맷. B 카테고리: 메시지 명확성, 브랜드 일치성, 시각적 계층 구조. A는 스크립트로 자동화, B는 5점 척도 평가. A 전항목 PASS + B 총점 70% 이상이면 최종 PASS.

**로키 (레드팀):**
지금 논의되는 QC 기준들은 전부 **이전 실패 패턴(글자 겹침, 텍스트 중복 등)에 대한 사후 대응**이다. 우리가 아직 경험하지 못한 실패 패턴에는 대응이 안 된다. 예를 들어 기술적으로 완벽하지만 **전혀 클릭하고 싶지 않은 광고**가 QC를 통과하는 시나리오가 있다. "정량 기준 = 품질"이라는 착각이 가장 위험하다. 또한 5점 척도나 체크리스트는 **QC 담당자가 에이전트일 경우** 패턴 매칭으로 기계적 PASS를 줄 수 있다. 인간 검수자의 최종 승인 루프가 없으면 의미 없다.

---

**Round 2: 교차 토론**

**아프로디테 → 마아트 지지 + 보완:**
마아트의 A/B 카테고리 구조가 가장 실용적이다. 여기에 마케팅 관점 항목 추가: B 카테고리에 "CTA 가시성(CTA가 fold 내에 위치하는가, 배경과 구별되는가)" 항목 추가 제안.

**페이토 → 로키 부분 동의:**
로키의 "기술적으로 완벽하지만 클릭하기 싫은 광고" 지적은 핵심을 찌른다. 카피 관점에서 이를 보완하려면 B 카테고리에 **"카피-디자인 정합성"** 항목이 필요하다. 카피에서 강조한 요소가 디자인에서도 시각적으로 강조되고 있는가?

**아마테라스 → 로키 반박:**
기술 자동화 기준(A 카테고리)은 최소한의 방어선이다. 로키가 말하는 "주관적 품질" 판단은 B 카테고리에서 다루면 된다. 두 레이어를 섞으면 둘 다 망가진다. 자동화 가능한 것은 자동화하고, 판단이 필요한 것은 명확히 분리하는 것이 엔지니어링 원칙이다.

**마아트 → 페이토 질문:**
페이토가 제안한 "카피-디자인 정합성" 항목은 Phase 2(카피 QC) 시점에서는 디자인이 없으므로 검수 불가다. 이 항목은 **Phase 4(디자인 QC)에만 적용**해야 한다. Phase별 체크리스트를 분리하는 것이 맞다.

**로키 → 전체 재공격:**
여러분이 합의하려는 "A자동 + B수동" 구조는 **마아트 한 명이 Phase 2와 Phase 4 모두를 담당하는 구조**와 결합될 때 단일 실패 지점(Single Point of Failure)이 된다. 마아트가 바쁘거나, 기준 해석이 흔들리거나, 에이전트로 대체될 경우 전체 QC 게이트가 무력화된다. **QC 기준 문서 자체가 실행 가능한 QC 프롬프트로 변환되어야 한다.** 체크리스트가 인간이 읽는 문서에 머물면 실효성이 없다.

**마아트 → 로키 수용:**
로키의 지적을 수용한다. QC 체크리스트는 마아트 에이전트의 **시스템 프롬프트에 직접 내장**되어야 한다. 문서와 프롬프트가 일치하지 않으면 프롬프트가 우선한다. `design-qc-knowhow.md`의 내용도 주기적으로 마아트 프롬프트에 반영하는 싱크 절차가 필요하다.

---

**Round 3: 합의 시도**

**합의 달성:**
1. QC 기준 = **카테고리 A(자동 규칙 기반) + 카테고리 B(수동 판단 기반)** 이중 구조 — 만장일치
2. A 카테고리(자동): 글자 겹침, 텍스트 경계 이탈, 해상도, 파일 포맷 — 만장일치
3. B 카테고리(수동): 메시지 명확성, 브랜드 일치성, 시각 계층, CTA 가시성, 카피-디자인 정합성(Phase 4만) — 만장일치
4. A 전항목 PASS + B 70% 이상(10점 만점 기준 7점 이상) = PASS — 만장일치
5. **QC 체크리스트는 마아트 에이전트 시스템 프롬프트에 직접 내장** + `design-qc-knowhow.md` 싱크 절차 마련 — 만장일치

**미합의:**
- 인간 최종 승인 루프 필요 여부: 로키(필요) vs 아마테라스(오버헤드) — **다음 사이클 논의 필요**
- B 카테고리 점수 배분(항목별 가중치): 아프로디테(CTA 가중치 높게) vs 마아트(균등 배분) — **수치 설계 별도 작업 필요**

---

### [안건 3] 노하우 문서 형식
> `design-qc-knowhow.md`를 어떤 구조로 쌓아야 다음 작업에 최대한 활용 가능한가?

---

**Round 1: 독립 의견**

**아프로디테 (마케팅팀장):**
마케팅팀이 활용하려면 **캠페인/목적별 분류**가 필요하다. "보험 광고 배너에서 발생한 실패"와 "채용 공고 이미지 실패"는 다르다. 태그 시스템(`#배너`, `#SNS`, `#카드뉴스`, `#보험`)을 붙이고, 가장 자주 발생하는 실패 패턴 Top 5를 문서 최상단에 요약 섹션으로 두어야 한다.

**페이토 (카피라이터):**
카피라이터가 재사용하려면 **실패 사례 + 수정 사례 페어** 형태가 가장 유용하다. "Before(실패 카피) → Why(실패 이유) → After(수정 카피)" 3단 구조. 단순히 실패 목록만 나열하면 다음 번에 참고하기 어렵다. 또한 **특정 키워드나 표현 패턴**(예: "지금 바로" 같은 표현이 특정 디자인에서 글자 수 초과 유발)을 정리한 금지어/주의어 목록도 병행 관리 필요.

**아마테라스 (디자인팀장):**
디자인팀이 재사용하려면 **기술적 파라미터와 연결된 실패 기록**이 필요하다. 예: "1200x628 배너에서 헤드카피 20자 이상 시 폰트 크기 자동 축소로 가독성 저하 → 15자 제한 권장". 즉 **이미지 스펙(크기, 비율) + 실패 조건 + 권장 파라미터** 세트로 기록해야 한다. Gemini/hybrid 렌더러별로 섹션을 나눠 관리하는 것이 좋다.

**마아트 (QC 매니저):**
QC 관점에서 가장 중요한 것은 **재발 방지 추적**이다. 같은 실패가 반복되고 있는지 알아야 한다. 따라서 각 FAIL 레코드에 (1) FAIL 일자, (2) Phase 번호, (3) FAIL 카테고리(A/B), (4) 이전에 동일 패턴 발생 여부(Y/N), (5) 수정 조치, (6) PASS 확인 여부 필드를 표준화해야 한다. 이를 통해 "이 실패가 처음인가, 반복인가"를 즉시 판단할 수 있다.

**로키 (레드팀):**
`design-qc-knowhow.md`의 구조 논의 자체는 좋다. 그러나 **에이전트가 이 문서를 실제로 읽는지 보장하는 메커니즘이 없다.** 문서가 아무리 잘 정리되어도 Phase 3 디자인 에이전트의 컨텍스트에 포함되지 않으면 의미가 없다. 또한 문서가 길어질수록 에이전트는 앞부분만 읽고 나머지를 무시하는 패턴이 생긴다. **문서 크기 상한 + 요약 자동 생성 메커니즘**이 없으면 6개월 뒤 이 문서는 쓰레기 더미가 된다.

---

**Round 2: 교차 토론**

**페이토 → 아마테라스 지지:**
아마테라스의 "스펙-실패-권장 파라미터" 세트 구조와 내가 제안한 "Before→Why→After" 구조는 병행 가능하다. 기술 파라미터 섹션은 아마테라스 방식, 카피 실패 섹션은 페이토 방식으로 각각 분리하면 된다.

**아마테라스 → 로키 부분 수용:**
로키의 "문서 크기 상한" 지적은 중요하다. 제안: 메인 문서는 최신 50개 케이스만 유지하고, 오래된 케이스는 `archive/` 섹션으로 이동. 또한 매 10개 케이스마다 AI가 패턴을 요약하는 **"Auto-Summary" 섹션**을 자동 업데이트. 이 요약이 Phase 3 에이전트 컨텍스트에 포함되도록 dispatch.py에서 인젝션.

**마아트 → 로키 반박:**
로키가 말한 "에이전트가 문서를 안 읽는 문제"는 dispatch.py의 역할이다. 각 Phase 시작 시 `design-qc-knowhow.md`의 **해당 카테고리 요약**을 컨텍스트에 자동 삽입하도록 설계하면 된다. 문서 구조 문제와 컨텍스트 인젝션 문제는 분리해서 풀어야 한다.

**아프로디테 → 마아트 보완:**
마아트의 FAIL 레코드 표준화에 한 가지 추가: (7) **비즈니스 임팩트 태그** (`#광고비낭비`, `#납기지연`, `#브랜드손상`). 나중에 "어떤 실패가 가장 비싼 실패였나"를 분석할 수 있어야 한다.

**로키 → 전체 공격:**
여러분이 설계하는 문서는 결국 **"좋은 문서"가 아니라 "에이전트가 올바르게 소비할 수 있는 문서"**여야 한다. 두 가지는 다르다. 인간이 읽기 좋은 마크다운 구조가 에이전트에게는 노이즈일 수 있다. 핵심 제안: 문서를 **두 버전으로 관리** — (1) 인간이 읽는 `design-qc-knowhow.md`, (2) 에이전트가 소비하는 `design-qc-knowhow-prompt.md` (요약+규칙만). 두 문서를 싱크하는 스크립트가 필요하다.

---

**Round 3: 합의 시도**

**합의 달성:**
1. 문서 구조: **헤더(Top 5 반복 실패 패턴 요약)** + **섹션별 상세 기록** (카피 섹션 / 디자인 기술 섹션 / 각 렌더러별 파라미터) — 만장일치
2. FAIL 레코드 표준 필드: 일자, Phase, 카테고리(A/B), 반복여부, 수정조치, PASS확인, 비즈니스임팩트 태그 — 만장일치
3. 카피 실패 섹션: Before→Why→After 3단 구조 — 만장일치
4. 문서 크기 관리: 최신 50개 케이스 유지 + 나머지 archive/ 이동 — 만장일치
5. **에이전트용 요약본(`design-qc-knowhow-prompt.md`) 별도 관리** + dispatch.py 자동 인젝션 — 만장일치

**미합의:**
- 에이전트용 문서 자동 싱크 스크립트 구현 주체 및 시점: 아마테라스(즉시 구현) vs 헤르메스(Phase 5 이후로 후순위 배치 제안) — **우선순위 결정 필요**

---

### [안건 4] 세션 관리
> Phase 1~2 / Phase 3~4 분리가 최선인가? 다른 분리 방법은?

---

**Round 1: 독립 의견**

**아프로디테 (마케팅팀장):**
마케팅팀은 Phase 1~2를 하나의 세션으로 묶는 것을 선호한다. 카피 기획과 카피 QC는 같은 컨텍스트(브리프, 캠페인 목표)를 공유하므로 세션 분리 시 컨텍스트 재주입 오버헤드가 발생한다. 반면 Phase 3~4(디자인+QC)는 기술 도구(gemini, hybrid)를 사용하므로 분리가 맞다. 현재 설계(1~2 묶음 / 3~4 묶음)는 적절하다.

**페이토 (카피라이터):**
현재 Phase 1~2 분리보다는 **목적별 분리**가 더 합리적이다: (1) 전략 세션(브리프 + 카피 기획), (2) 텍스트 QC 세션(카피 검수만), (3) 시각화 세션(디자인 실행 + 디자인 QC). 이렇게 하면 텍스트 QC 세션이 독립적인 컨텍스트를 가지므로 이전 전략 논의에 오염되지 않고 순수하게 카피 품질만 판단할 수 있다.

**아마테라스 (디자인팀장):**
디자인팀 관점에서 가장 중요한 분리 기준은 **"인간 개입이 필요한 시점"**이다. Phase 1~2는 창작 판단이 필요하므로 세션 내에서 빠른 피드백 루프가 좋다. Phase 3~4는 기술 실행 + 검수이므로 분리해도 된다. 그러나 실제로 중요한 분리 지점은 **Phase 2 PASS 시점** — 여기서 "확정 카피"를 파일로 저장하고 Phase 3 세션이 그 파일을 인풋으로 받는 구조가 핵심이다. 세션 분리 자체보다 **핸드오프 파일 규격**이 더 중요하다.

**마아트 (QC 매니저):**
QC 관점에서는 Phase 2와 Phase 4를 **동일한 QC 에이전트(마아트)가 독립 세션으로** 처리하는 것이 일관성 측면에서 좋다. 그러나 현재 설계에서 Phase 2(카피 QC)와 Phase 4(디자인 QC)를 같은 마아트 에이전트가 처리하면, Phase 4에서 Phase 2 기억이 오염 요소가 된다. **Phase 2 마아트 세션과 Phase 4 마아트 세션은 완전히 독립된 컨텍스트**여야 한다. 공유되어야 할 것은 기억이 아니라 **체크리스트 파일**이다.

**로키 (레드팀):**
세션 분리 논의의 전제를 공격한다. **"Phase = 세션"이라는 등식 자체가 틀렸다.** 세션은 LLM 컨텍스트 창이고, Phase는 비즈니스 로직이다. 두 개념을 혼용하면 Phase가 늘어날 때마다 세션 설계를 다시 해야 한다. 올바른 접근: **Phase는 파일로 관리하고, 세션은 Phase와 무관하게 비용/성능 기준으로 독립 결정**한다. 즉, Phase 1~4가 하나의 긴 세션에서 처리될 수도 있고, 각 Phase가 별도 세션일 수도 있다. 결정 기준은 Phase 논리가 아니라 **컨텍스트 오염 위험**이다.

---

**Round 2: 교차 토론**

**아마테라스 → 로키 강력 지지:**
로키의 "Phase ≠ 세션" 분리 원칙에 강하게 동의한다. 핸드오프 파일 규격이 핵심이라는 내 주장과 같은 방향이다. Phase 간 인터페이스를 명확한 파일 규격으로 정의하면, 세션 구성은 실행 환경에 맞게 유연하게 변경 가능하다.

**페이토 → 마아트 지지:**
마아트가 말한 "Phase 2 마아트와 Phase 4 마아트는 독립 컨텍스트" 원칙에 동의한다. 그러나 이것이 "별도 에이전트 인스턴스"를 의미하는지, "같은 에이전트가 다른 세션으로" 를 의미하는지 명확화 필요. 공유되어야 할 것은 **체크리스트 파일 + `design-qc-knowhow.md` 요약본**이고, 이전 Phase의 대화 내용은 공유하지 않아야 한다.

**아프로디테 → 로키 질문:**
로키의 원칙에 따르면 Phase 1~2가 하나의 세션에서 처리될 때, Phase 2(QC)에서 Phase 1의 기획 컨텍스트가 QC 판단에 영향을 줄 수 있다. 이것이 오염인가, 도움인가?

**로키 → 아프로디테 답변:**
둘 다다. Phase 1 기획 의도를 알면 Phase 2 QC가 더 정확해지지만(도움), Phase 1 기획자의 편향을 그대로 승계하면 독립적 검수가 불가(오염). 해결책: Phase 2 시작 시 **"Phase 1 컨텍스트 중 QC와 관련된 것만 요약 주입"** — 전체 대화가 아닌 브리프 + 확정 카피만 Phase 2 컨텍스트에 포함.

**마아트 → 전체 정리:**
정리하면: 세션 구성의 원칙은 (1) Phase 간 핸드오프는 파일로 (2) QC 세션은 이전 창작 세션의 대화 히스토리를 포함하지 않음 (3) 공유 인풋은 파일 형태(브리프, 확정 카피, 체크리스트)로만 허용.

---

**Round 3: 합의 시도**

**합의 달성:**
1. **Phase ≠ 세션** 원칙 채택: Phase는 비즈니스 로직, 세션은 성능/비용 기준으로 독립 결정 — 만장일치
2. Phase 간 인터페이스는 **표준 핸드오프 파일**로 정의 (브리프, 확정 카피, 디자인 아웃풋, QC 리포트) — 만장일치
3. QC 세션은 이전 창작 세션의 대화 히스토리 불포함 — 만장일치
4. QC 세션 인풋: 핸드오프 파일 + 체크리스트 + `design-qc-knowhow-prompt.md` 요약본 — 만장일치

**미합의:**
- Phase 1~2를 하나의 세션으로 처리 vs 분리: 아프로디테(묶음 선호) vs 페이토(분리 선호) — **실험적으로 양쪽 모두 시도 후 결정 제안**

---

### [안건 5] 코드화
> dispatch.py / composite prompt에 이 워크플로우를 어떻게 내장할 것인가?

---

**Round 1: 독립 의견**

**아프로디테 (마케팅팀장):**
마케팅팀 입장에서 코드 구현은 블랙박스이지만, 요구사항을 명확히 한다: (1) Phase 1 시작 전에 **브리프 입력 템플릿을 강제 출력**하고 사용자가 채우지 않으면 진행 불가, (2) Phase 2 QC 결과가 사용자에게 **읽기 쉬운 리포트 형태**로 출력되어야 함, (3) PASS/FAIL 상태가 텔레그램 등 알림으로 전달되어야 함. 이 세 가지를 dispatch.py에서 보장해야 한다.

**페이토 (카피라이터):**
카피 생성 Phase(Phase 1)는 단일 LLM 호출이 아니라 **페이토 에이전트 전용 프롬프트**를 composite prompt로 관리해야 한다. 현재처럼 일반 프롬프트로 카피를 생성하면 품질 편차가 크다. composite prompt에는 (1) 타겟 고객 페르소나, (2) 브랜드 보이스 가이드, (3) 이미지 기술 제약(최대 글자 수 등), (4) 이전 성공/실패 카피 예시가 포함되어야 한다.

**아마테라스 (디자인팀장):**
dispatch.py에서 가장 중요한 것은 **렌더러 선택 로직**이다. "satori 금지, hybrid/gemini만"이라는 규칙이 코드레벨에서 하드코딩되어야 한다 (주석이 아닌 실제 블로킹 코드). 또한 각 렌더러의 파라미터(이미지 크기, 폰트, 텍스트 최대 길이)를 **설정 파일(config.yaml 등)로 분리**해야 Phase 1 브리프 작성 시 자동으로 제약 조건을 참조할 수 있다.

**마아트 (QC 매니저):**
QC Phase를 코드화할 때 핵심은 **QC 결과가 항상 구조화된 JSON으로 출력**되어야 한다는 것이다. 자유 텍스트 QC 결과는 파싱 불가능하다. 구조 예시:
```json
{
  "phase": 2,
  "result": "FAIL",
  "category_a": {"pass": true, "items": [...]},
  "category_b": {"score": 6, "max": 10, "items": [...]},
  "fail_reasons": ["헤드카피 20자 초과", "CTA 미포함"],
  "action": "return_to_phase_1"
}
```
이 JSON을 dispatch.py가 파싱하여 라우팅 결정을 한다.

**로키 (레드팀):**
dispatch.py에 워크플로우를 내장하는 것 자체에 근본적인 문제를 제기한다. **워크플로우 로직이 코드에 하드코딩되면 변경 비용이 급증한다.** 제이회장님이 Phase 5를 추가하거나 Phase 순서를 바꾸면 코드를 수정해야 한다. 대안: **워크플로우를 YAML/JSON 설정 파일로 선언하고 dispatch.py는 이 설정을 읽는 범용 실행기**로 설계. 또한 "satori 금지" 같은 규칙은 코드레벨 블로킹뿐만 아니라 **LLM 프롬프트 레벨에서도 명시**해야 한다 — 코드를 우회하는 방법은 항상 존재하지만 프롬프트 레벨 제약은 에이전트 행동을 직접 제어한다.

---

**Round 2: 교차 토론**

**아마테라스 → 로키 부분 수용:**
YAML 설정 파일로 워크플로우를 선언하는 아이디어는 좋다. 그러나 렌더러 선택 로직은 반드시 코드레벨 블로킹이 필요하다. YAML에 `allowed_renderers: [hybrid, gemini]`를 선언하고, dispatch.py가 이를 읽어서 satori 호출 시 예외를 발생시키는 구조로 양립 가능.

**마아트 → 아마테라스 지지 + 보완:**
QC JSON 출력 구조와 YAML 워크플로우 설정을 결합하면: YAML에 각 Phase의 `qc_schema` 필드를 정의하고, dispatch.py가 QC 에이전트 출력을 해당 스키마로 검증한 후 라우팅. 스키마 검증 실패(QC 에이전트가 구조화된 JSON 미출력) 자체도 FAIL로 처리.

**페이토 → 로키 질문:**
YAML로 워크플로우를 선언할 경우, composite prompt(페이토 에이전트 전용 프롬프트)는 어디에 위치하는가? YAML 내부에 인라인? 별도 파일 참조?

**로키 → 페이토 답변:**
별도 파일 참조가 맞다. `prompts/phase1-copy.md`, `prompts/phase2-qc.md` 등 Phase별 프롬프트 파일을 관리하고, YAML에서 `prompt_file: prompts/phase1-copy.md`로 참조. 이렇게 하면 프롬프트 수정이 코드 변경 없이 가능하다.

**아프로디테 → 전체 정리:**
정리하면 코드 구조: (1) `workflow.yaml` — Phase 정의, 렌더러 허용 목록, QC 스키마, 프롬프트 파일 경로, (2) `prompts/` 폴더 — Phase별 에이전트 프롬프트, (3) `dispatch.py` — YAML 읽기, Phase 실행, QC 출력 파싱, 라우팅, (4) `design-qc-knowhow-prompt.md` — dispatch.py가 각 Phase 시작 시 컨텍스트에 자동 인젝션.

**로키 → 최종 공격:**
이 구조는 견고하지만 **테스트 커버리지가 없으면 배포 즉시 무너진다.** 특히 Phase 루프 로직(FAIL→리턴)은 무한 루프 버그가 쉽게 발생한다. dispatch.py에 **루프 카운터 + 에스컬레이션 로직**이 반드시 포함되어야 하고, 단위 테스트로 각 Phase 전환이 올바르게 동작하는지 검증해야 한다. 테스트 없는 워크플로우 코드는 시한폭탄이다.

---

**Round 3: 합의 시도**

**합의 달성:**
1. 워크플로우는 **`workflow.yaml`로 선언적 관리** + dispatch.py는 범용 실행기 — 만장일치
2. Phase별 프롬프트는 **`prompts/` 폴더 별도 파일**로 관리, YAML에서 참조 — 만장일치
3. 렌더러 허용 목록은 YAML + 코드레벨 이중 블로킹 (`satori` 호출 시 예외 발생) — 만장일치
4. QC 출력은 **구조화 JSON** + dispatch.py가 스키마 검증 후 라우팅 — 만장일치
5. `design-qc-knowhow-prompt.md`는 dispatch.py가 Phase 시작 시 자동 컨텍스트 인젝션 — 만장일치
6. dispatch.py에 **루프 카운터 + 에스컬레이션 로직** 필수 포함 — 만장일치

**미합의:**
- 루프 에스컬레이션 임계값(몇 회 FAIL 후 에스컬레이션): 페이토(3회) vs 마아트(사유 비교 방식) — **[안건 1] 미합의 항목과 동일, Cycle 2에서 통합 논의**
- dispatch.py 단위 테스트 범위 및 CI 통합 여부: 아마테라스(즉시) vs 헤르메스(일정 조율 필요) — **일정 협의 필요**

---

## 3 Whys 분석

### Why-1: Phase 0(브리프 검증 게이트) 추가
- Why 1: Phase 1 시작 전 브리프가 없으면 카피 기획이 불가능하다
  - Why 2: 브리프 없는 카피는 방향성이 없어 QC에서 높은 확률로 FAIL한다
    - Why 3: 브리프 없는 FAIL은 Phase 1~2 루프를 과도하게 발생시켜 전체 워크플로우 비용을 급증시킨다
- **결론:** Phase 0 게이트는 워크플로우 효율의 선제적 방어선이다

### Why-2: QC 기준을 마아트 프롬프트에 직접 내장
- Why 1: QC 기준 문서가 별도로 존재해도 에이전트가 읽지 않으면 무용지물이다
  - Why 2: 에이전트는 시스템 프롬프트 외 외부 문서를 자발적으로 참조하지 않는다
    - Why 3: 기준이 프롬프트 외부에 있으면 QC 판단 일관성이 실행마다 다르고, 이는 결국 QC 게이트 신뢰성을 파괴한다
- **결론:** 기준의 코드화는 문서 링크가 아닌 프롬프트 내장으로만 보장 가능

### Why-3: Phase ≠ 세션 원칙 채택
- Why 1: Phase와 세션을 1:1로 묶으면 Phase 추가/변경 시 세션 설계 전체를 재작업해야 한다
  - Why 2: 세션 재설계는 컨텍스트 관리 로직의 전체 수정으로 이어져 개발 비용이 비선형적으로 증가한다
    - Why 3: 결국 워크플로우 변경을 기피하게 되고 워크플로우가 경직되어 개선이 불가능해진다
- **결론:** Phase(비즈니스 로직)와 세션(기술 실행)의 분리는 시스템 유연성의 필수 조건

### Why-4: `workflow.yaml` 선언적 설계
- Why 1: 워크플로우 로직이 dispatch.py에 하드코딩되면 변경 시마다 코드 수정이 필요하다
  - Why 2: 코드 수정은 코드 리뷰, 테스트, 배포 사이클을 요구하여 실험/개선 속도를 늦춘다
    - Why 3: 개선 속도가 느려지면 워크플로우 실패가 반복되는 기간이 길어지고, 그 비용은 실제 광고 품질 저하로 직결된다
- **결론:** 선언적 설계는 빠른 실험과 개선을 가능하게 하는 경쟁 우위다

### Why-5: `design-qc-knowhow.md` 자동 인젝션 + 에이전트용 요약본 분리
- Why 1: 노하우 문서가 아무리 잘 쌓여도 에이전트에게 자동 주입되지 않으면 다음 작업에 반영이 안 된다
  - Why 2: 에이전트는 매 세션 컨텍스트 초기화로 시작하므로 이전 학습이 자동 승계되지 않는다
    - Why 3: 학습이 승계되지 않으면 같은 실패가 반복되고, 노하우 문서 작성 자체가 헛수고가 된다
- **결론:** 노하우의 효과는 작성이 아니라 자동 인젝션으로 완성된다

---

## Cycle 1 합의 현황

### 만장일치 달성 항목

**[안건 1] 워크플로우 빈틈:**
- Phase 0(브리프 검증 게이트) 추가 필요
- 각 Phase Output 파일 강제 저장 + dispatch.py 내용 검증 후 진입 허용
- Phase 1 브리프 템플릿에 기술 제약 필드 포함
- QC FAIL 리포트는 항목별 체크리스트 형태 출력

**[안건 2] QC 기준:**
- 카테고리 A(자동) + 카테고리 B(수동) 이중 구조
- A: 글자 겹침, 텍스트 경계 이탈, 해상도, 파일 포맷
- B: 메시지 명확성, 브랜드 일치성, 시각 계층, CTA 가시성, 카피-디자인 정합성(Phase 4만)
- PASS 기준: A 전항목 PASS + B 70% 이상
- QC 체크리스트 마아트 에이전트 시스템 프롬프트 내장 + `design-qc-knowhow.md` 싱크 절차

**[안건 3] 노하우 문서:**
- 문서 구조: Top 5 요약 헤더 + 카피/디자인/렌더러별 상세 섹션
- FAIL 레코드 표준 7개 필드 (일자, Phase, 카테고리, 반복여부, 수정조치, PASS확인, 비즈니스임팩트)
- 카피 실패: Before→Why→After 구조
- 최신 50개 케이스 유지 + 나머지 archive/ 이동
- 에이전트용 요약본(`design-qc-knowhow-prompt.md`) 별도 관리 + dispatch.py 자동 인젝션

**[안건 4] 세션 관리:**
- Phase ≠ 세션 원칙
- Phase 간 인터페이스: 표준 핸드오프 파일
- QC 세션: 이전 창작 대화 히스토리 불포함
- QC 세션 인풋: 핸드오프 파일 + 체크리스트 + 요약본

**[안건 5] 코드화:**
- `workflow.yaml` 선언적 워크플로우 관리
- `prompts/` 폴더 Phase별 프롬프트 파일 분리
- 렌더러 허용 목록 YAML + 코드 이중 블로킹
- QC 출력: 구조화 JSON + 스키마 검증 라우팅
- dispatch.py: 루프 카운터 + 에스컬레이션 로직 필수
- `design-qc-knowhow-prompt.md` Phase 시작 시 자동 인젝션

---

### 미합의 항목 (Cycle 2 논의 필요)

| # | 항목 | 대립 의견 | 우선순위 |
|---|------|-----------|---------|
| 1 | 루프 횟수 상한 설정 여부 | 페이토: 3회 상한 vs 마아트: 사유 비교 방식 | 높음 |
| 2 | Phase 3 중간 시안 리뷰 포인트 추가 | 아마테라스: 찬성 vs 로키: 오버헤드 우려 | 중간 |
| 3 | 인간 최종 승인 루프 필요 여부 | 로키: 필요 vs 아마테라스: 오버헤드 | 높음 |
| 4 | B 카테고리 항목별 가중치 | 아프로디테: CTA 높게 vs 마아트: 균등 | 중간 |
| 5 | Phase 1~2 세션 묶음 vs 분리 | 아프로디테: 묶음 vs 페이토: 분리 | 낮음 |
| 6 | 에이전트용 문서 싱크 스크립트 구현 시점 | 아마테라스: 즉시 vs 헤르메스: 후순위 | 중간 |
| 7 | 루프 에스컬레이션 임계값 | [안건 1]과 동일, Cycle 2 통합 논의 | 높음 |
| 8 | dispatch.py 단위 테스트 CI 통합 | 아마테라스: 즉시 vs 헤르메스: 일정 조율 | 중간 |

---

### 다음 사이클 필요 여부: **Yes**

**Cycle 2 최우선 의제:**
1. 루프 제한 방식 최종 결정 (횟수 상한 vs 사유 비교) — 코드화에 직접 영향
2. 인간 최종 승인 루프 포함 여부 — 전체 워크플로우 설계에 영향
3. B 카테고리 가중치 수치 확정 — 마아트 QC 프롬프트 작성을 위해 필요

---

*기록: 헤르메스 (개발1팀장, 퍼실리테이터) | 2026-03-29*