# 미팅 기록: 마케팅 시스템 업그레이드 (task-1054.1)

**일시:** 2026-03-26
**안건:** task-1048.1 분석 결과 기반 마케팅 시스템 업그레이드 설계
**참석자:** 로키(DA/레드팀), 아프로디테(마케팅팀장), 아르고스(QA), 불칸(백엔드)
**퍼실리테이터:** 에이전트 미팅 퍼실리테이터

---

## 사이클 1: 기존 시스템 현황 파악 + 충돌 위험 분석

**안건:** 현재 38개 마케팅 스킬의 실제 구조를 확인하고, 변경 전 리스크를 사전에 식별한다.

### 발언

**로키 (DA/레드팀):**
실제 파일시스템을 확인한 결과, copywriting과 seo-audit은 이미 evals.json을 보유하고 있으며 content-strategy도 evals 디렉토리가 존재한다. 이 스킬들에 대한 evals 작업은 신규 생성이 아닌 기존 파일 점검 혹은 무결성 확인이 되어야 한다. dispatch.py와 team_prompts.py는 SKILL.md의 `description` 필드를 직접 파싱할 가능성이 높으므로, description 수정 시 YAML frontmatter 구조를 절대 깨뜨리지 말아야 한다.

**아프로디테 (마케팅팀장):**
blog-dominance, geo-optimizer, thread-architect, naver-seo 4개 스킬은 `Before Starting` 섹션도 없고 product-marketing-context 참조도 전혀 없다. 이 스킬들은 보험 도메인 특화 스킬임에도 컨텍스트 없이 동작하고 있어 산출물 품질이 일정하지 않다. 반면 copy-editing, lead-magnets, email-sequence 등은 이미 컨텍스트 참조를 포함하고 있으므로, 이쪽은 context 강화 대상에서 제외하거나 경미한 보완으로 처리하면 된다.

**아르고스 (QA):**
copywriting의 evals.json 구조(skill_name, evals 배열, id/prompt/expected_output/assertions/files)가 사실상 표준으로 자리잡혀 있다. 이 구조를 모든 신규 evals.json의 스키마로 채택하면 일관성이 보장된다. 현재 ad-creative, ai-seo, social-content, paid-ads, analytics-tracking은 evals 디렉토리 자체가 없으므로 디렉토리 생성부터 시작해야 한다.

**불칸 (백엔드):**
스킬 디렉토리 내 파일 구조를 분석하면 ad-creative, paid-ads, analytics-tracking, social-content 디렉토리에는 skill명 동일한 하위 디렉토리(예: `ad-creative/ad-creative/`)가 존재한다. 이는 레거시 구조로 추정되며, evals 디렉토리 생성 시 이 패턴과 충돌하지 않도록 `evals/evals.json` 경로를 명확히 사용해야 한다. 검증 스크립트는 jq나 Python으로 evals.json 스키마를 자동 검증하도록 설계하면 된다.

### 합의 사항
- copywriting, seo-audit, content-strategy의 evals는 기존 파일 존재 확인 후 통과(skip) 처리
- 신규 evals.json은 copywriting/evals/evals.json 구조를 표준 스키마로 채택
- description YAML frontmatter 구조 변경 절대 금지 (내용 보강만 허용)
- blog-dominance, geo-optimizer, thread-architect, naver-seo를 context 강화 최우선 대상으로 지정

### 액션 아이템
- [ ] 불칸: 기존 evals.json 보유 스킬 목록 확정 (copywriting, seo-audit, content-strategy 확인 완료)
- [ ] 아르고스: evals.json 표준 스키마 문서화
- [ ] 로키: description frontmatter 파싱 방식 재확인 (dispatch.py 분석)
- [ ] 아프로디테: context 미참조 스킬 최종 목록 확정 (blog-dominance, geo-optimizer, thread-architect, naver-seo 포함)

---

## 사이클 2: 도입 항목별 충돌 분석 (evals / context / routing 각각)

**안건:** 3가지 도입 항목(evals, context 강화, description 라우팅)이 기존 스킬 동작에 미치는 충돌 가능성을 항목별로 분석한다.

### 발언

**로키 (DA/레드팀):**
evals.json은 스킬 실행 경로에 포함되지 않는 순수 메타데이터 파일이므로 충돌 위험이 없다. description 보강은 YAML frontmatter 내 문자열 값만 변경하므로, 따옴표 처리와 YAML 들여쓰기 규칙만 지키면 안전하다. 가장 위험한 항목은 SKILL.md 본문 수정인데, `Before Starting` 섹션 추가 시 기존 섹션 순서나 헤딩 레벨이 바뀌면 프롬프트 체이닝이 깨질 수 있다.

**아프로디테 (마케팅팀장):**
description 라우팅에서 "For X, see Y-skill" 패턴은 실제 운영 중에 매우 유용하다. 예를 들어 ad-creative와 paid-ads가 경계가 불명확해 잘못 라우팅되는 사례가 있었다. 라우팅 명세는 기존 description의 "NOT for:" 패턴이 이미 일부 스킬(blog-dominance, geo-optimizer, naver-seo)에 존재하므로, 이 패턴을 전체 스킬로 표준화하는 방향이 자연스럽다.

**아르고스 (QA):**
context 강화에서 `Before Starting` 섹션 추가 시, 이미 해당 섹션이 존재하는 스킬(ad-creative: "시작 전 확인")에는 중복 추가가 발생할 수 있다. 각 스킬의 기존 섹션명을 사전 확인하고, 기존 섹션이 있으면 내용을 합치는 방식을 채택해야 한다. 섹션명이 다른 경우(예: "시작 전 확인" vs "Before Starting") 표준화 여부도 결정해야 한다.

**불칸 (백엔드):**
세 가지 도입 항목의 충돌 위험을 수치화하면: evals.json(위험 없음) > description 보강(낮음) > Before Starting 섹션 추가(중간). Before Starting 수정은 기존 내용이 있는 스킬에서만 중간 위험이 발생한다. 기존 내용이 없는 스킬에 새로 추가하는 경우는 낮은 위험이다. 스크립트로 각 SKILL.md에 "Before Starting" 섹션 존재 여부를 사전 스캔하면 안전하게 처리할 수 있다.

### 합의 사항
- evals.json: 충돌 없음, 자유롭게 생성 가능
- description 라우팅: 기존 "NOT for:" 패턴을 표준화하고 "For X, see Y" 추가 (구조 변경 없음)
- Before Starting 섹션: 기존 섹션 존재 시 내용 병합, 부재 시 신규 추가 (섹션명은 기존 명칭 유지)
- ad-creative의 "시작 전 확인" 섹션은 건드리지 않고 해당 섹션 내 참조 문구만 확인

### 액션 아이템
- [ ] 불칸: 각 대상 스킬의 "Before Starting" 유사 섹션 존재 여부 스캔 스크립트 작성
- [ ] 아르고스: Before Starting 섹션 병합 기준 정의
- [ ] 로키: description YAML 수정 후 파싱 테스트 체크리스트 작성
- [ ] 아프로디테: 스킬 간 경계 라우팅 매핑 (어느 스킬이 어느 스킬로 포워딩할지) 초안 작성

---

## 사이클 3: Phase 분리 설계 + 의존성 그래프

**안건:** 4개 Phase의 실행 순서와 의존성을 확정하고, 각 Phase의 범위를 정의한다.

### 발언

**로키 (DA/레드팀):**
Phase 1(evals)은 완전히 독립적이며 다른 Phase에 의존성이 없다. Phase 2(context 강화)와 Phase 3(description 라우팅)도 상호 독립적이다. 따라서 Phase 2와 3은 병렬 실행이 가능하지만, 같은 SKILL.md를 동시에 수정하면 충돌이 발생한다. 의존성 관점에서 Phase 1 → Phase 2 → Phase 3 → Phase 4 순서가 가장 안전하다.

**아프로디테 (마케팅팀장):**
Phase 1의 evals 대상 8개 핵심 스킬(ad-creative, copywriting, content-strategy, seo-audit, ai-seo, social-content, paid-ads, analytics-tracking) 중 copywriting, seo-audit, content-strategy는 이미 evals.json이 존재한다. 실질적 신규 작업 대상은 5개(ad-creative, ai-seo, social-content, paid-ads, analytics-tracking)이다. Phase 2의 context 강화 대상은 실제로 blog-dominance, geo-optimizer, thread-architect, naver-seo 4개가 핵심이며, 나머지는 이미 참조 포함 상태다.

**아르고스 (QA):**
Phase 4(통합 검증)는 Phase 1~3의 모든 산출물을 검증하므로 반드시 마지막에 위치해야 한다. 검증 스크립트가 Phase 4에서 실행되려면 Phase 1~3의 파일 생성이 완료되어 있어야 한다. Phase 간 게이팅(gate) 기준을 명확히 정의해야 다음 Phase로 넘어갈 수 있다.

**불칸 (백엔드):**
검증 스크립트는 `/home/jay/workspace/scripts/` 또는 `/home/jay/workspace/skills/` 루트에 배치하는 것이 적합하다. 스크립트 기능: (1) evals.json 스키마 검증, (2) SKILL.md description frontmatter 유효성 검증, (3) Before Starting 섹션 참조 존재 확인, (4) 라우팅 패턴 일관성 검증. Python으로 작성하면 기존 pyproject.toml 환경을 재사용할 수 있다.

### 합의 사항

**의존성 그래프:**
```
Phase 1 (evals 도입)
    ↓
Phase 2 (context 강화)  ←  독립적이나 Phase 1 완료 후 진행
    ↓
Phase 3 (description 라우팅)  ←  Phase 2 완료 후 진행
    ↓
Phase 4 (통합 검증)  ←  Phase 1~3 전체 완료 후 진행
```

**각 Phase 실제 작업 범위:**
- Phase 1: 신규 evals.json 5개 생성 (ad-creative, ai-seo, social-content, paid-ads, analytics-tracking)
- Phase 2: Before Starting 섹션 추가 4개 (blog-dominance, geo-optimizer, thread-architect, naver-seo)
- Phase 3: description 라우팅 보강 전체 마케팅 스킬 (우선순위별 단계적)
- Phase 4: 검증 스크립트 실행 + 회귀 테스트

### 액션 아이템
- [ ] 불칸: 검증 스크립트 설계 및 작성
- [ ] 아르고스: Phase 게이팅 기준 정의 (각 Phase 완료 판단 기준)
- [ ] 아프로디테: Phase 2 대상 4개 스킬의 Before Starting 내용 템플릿 작성
- [ ] 로키: Phase 간 롤백 포인트 정의

---

## 사이클 4: 롤백 전략 설계

**안건:** 각 Phase에서 문제 발생 시 원상복구 방법을 설계하고, 롤백 트리거 조건을 정의한다.

### 발언

**로키 (DA/레드팀):**
현재 작업 공간이 git 레포가 아니므로(`Is directory a git repo: No`) git 기반 롤백은 불가능하다. 따라서 파일 단위 백업이 필요하다. SKILL.md 수정 전 원본을 `/home/jay/workspace/backups/marketing-upgrade-YYYYMMDD/` 디렉토리에 복사하는 것이 가장 단순하고 확실하다. evals.json은 신규 생성이므로 롤백 = 파일 삭제로 처리 가능하다.

**아프로디테 (마케팅팀장):**
롤백 트리거 조건을 명확히 해야 한다: (1) 수정 후 스킬이 잘못된 라우팅을 발생시키는 경우, (2) description 파싱 오류가 발생하는 경우, (3) Before Starting 섹션 추가로 기존 스킬 핵심 로직(Core Principles, Output Format)이 변경된 경우. 트리거 조건 중 하나라도 감지되면 해당 스킬만 선택적으로 롤백하는 방식이 효율적이다.

**아르고스 (QA):**
롤백 검증 절차도 정의해야 한다. 롤백 후 원본과 현재 파일이 동일한지 diff 검증을 수행하고, 스킬 description 파싱 테스트를 재실행하여 원상복구를 확인한다. 각 Phase 시작 전 백업, 각 Phase 완료 후 스냅샷, 총 2단계의 체크포인트를 유지한다.

**불칸 (백엔드):**
롤백 스크립트를 미리 준비한다. `backup_skill.sh <skill_name>` 형태로 개별 스킬 백업, `restore_skill.sh <skill_name>` 형태로 복원. 백업 디렉토리는 `/home/jay/workspace/backups/marketing-upgrade-20260326/`로 고정하고, 타임스탬프 기반 디렉토리명을 사용한다. evals.json 신규 생성 목록도 별도 파일에 기록해두면 롤백 시 삭제 대상을 즉시 알 수 있다.

### 합의 사항
- 롤백 방식: 파일 단위 백업/복원 (git 없음)
- 백업 경로: `/home/jay/workspace/backups/marketing-upgrade-20260326/`
- 백업 대상: SKILL.md 수정 대상 스킬 전체 (Phase 시작 전 백업)
- evals.json 롤백 = 신규 생성 파일 삭제 (별도 생성 목록 관리)
- 롤백 트리거: description 파싱 오류, 핵심 로직 변경, 잘못된 라우팅 발생
- 선택적 롤백 우선 (문제 스킬만 복원), 전체 롤백은 최후 수단

### 액션 아이템
- [ ] 불칸: 백업/복원 스크립트 작성
- [ ] 아르고스: 롤백 후 검증 절차 작성
- [ ] 로키: 롤백 트리거 조건 최종 확정 및 문서화
- [ ] 아프로디테: Phase별 롤백 판단 권한자 지정 (팀장급 승인 필요 여부)

---

## 사이클 5: 검증 계획 수립 (회귀 테스트 포함)

**안건:** Phase 4에서 실행할 통합 검증 계획을 수립하고, 회귀 테스트 전략을 확정한다.

### 발언

**로키 (DA/레드팀):**
회귀 테스트 핵심은 "변경 전과 후에 동일한 쿼리가 동일한 스킬로 라우팅되는가"이다. evals.json의 기존 assertions가 이 목적에 활용 가능하다. 특히 seo-audit eval id=8("add FAQ schema")이 schema-markup으로 올바르게 라우팅되는지, copywriting eval id=6("5-email welcome sequence")이 email-sequence로 올바르게 포워딩되는지를 검증하면 라우팅 회귀 테스트의 핵심 케이스가 된다.

**아프로디테 (마케팅팀장):**
검증 기준을 실용적으로 설정해야 한다. evals.json의 각 assertion이 실제 실행 결과와 맞는지 확인하는 것이 이상적이지만, 자동화 실행 환경이 없다면 정적 검증(파일 구조, 스키마 형식, 참조 존재 여부)만으로도 Phase 4 게이팅 기준을 충족할 수 있다. 동적 검증(실제 LLM 실행)은 별도 일정으로 분리한다.

**아르고스 (QA):**
정적 검증 체크리스트를 다음과 같이 구성한다: (1) evals.json 스키마 검증(필수 필드: skill_name, evals, id, prompt, expected_output, assertions), (2) SKILL.md description frontmatter YAML 유효성 검증, (3) Before Starting 섹션 내 product-marketing-context 참조 문구 존재 확인, (4) description 내 "For X, see Y" 라우팅 패턴 일관성 확인, (5) 기존 evals.json 보유 스킬의 변경 무결성 확인. 이 5개 항목을 자동 검증 스크립트로 구현한다.

**불칸 (백엔드):**
검증 스크립트 설계: `validate_marketing_upgrade.py` 단일 파일에 5개 검증 함수를 구현한다. 출력 형식은 JSON 리포트로 `pass/fail/warn` 세 단계로 구분한다. 실행 명령: `python /home/jay/workspace/scripts/validate_marketing_upgrade.py --target all` 또는 `--target evals|context|routing`으로 Phase별 선택 실행 가능. CI 환경 없이도 수동으로 바로 실행 가능한 구조로 설계한다.

### 합의 사항

**검증 항목 5개:**
1. evals.json 스키마 검증 (신규 생성 5개 + 기존 3개 무결성)
2. description YAML frontmatter 파싱 가능 여부
3. Before Starting 섹션 product-marketing-context 참조 존재
4. 라우팅 패턴("For X, see Y") 문법 일관성
5. 핵심 로직 섹션(Core Principles, Output Format) 변경 없음 확인

**회귀 테스트 전략:**
- 정적 회귀 테스트: 검증 스크립트 자동 실행 (Phase 4에서 즉시 실행 가능)
- 동적 회귀 테스트: evals.json assertions 기반 LLM 실행 검증 (별도 일정)
- 기준선(baseline): 수정 전 파일을 백업 디렉토리에 보존하여 diff 비교 가능

### 액션 아이템
- [ ] 불칸: `validate_marketing_upgrade.py` 스크립트 작성
- [ ] 아르고스: 검증 리포트 형식 확정 및 판정 기준 문서화
- [ ] 로키: 회귀 테스트 실패 시 대응 절차 작성
- [ ] 아프로디테: 동적 회귀 테스트 일정 계획 수립

---

## 최종 합의 요약

### 도입 항목별 최종 결정

| 항목 | 범위 | 충돌 위험 | 실행 Phase |
|------|------|-----------|------------|
| evals.json 신규 생성 | 5개 스킬 (ad-creative, ai-seo, social-content, paid-ads, analytics-tracking) | 없음 | Phase 1 |
| evals.json 기존 확인 | 3개 스킬 (copywriting, seo-audit, content-strategy) | 없음 | Phase 1 (검증만) |
| Before Starting 추가 | 4개 스킬 (blog-dominance, geo-optimizer, thread-architect, naver-seo) | 낮음 | Phase 2 |
| description 라우팅 보강 | 전체 마케팅 스킬 | 낮음 | Phase 3 |
| 통합 검증 | 전체 | N/A | Phase 4 |

### 핵심 원칙
1. dispatch.py, team_prompts.py, org-details/*.json 절대 수정 금지
2. 기존 스킬의 Core Principles, Output Format 섹션 변경 금지
3. evals.json은 copywriting 구조를 표준 스키마로 채택
4. description 수정 시 YAML frontmatter 구조 보존 필수
5. 모든 SKILL.md 수정 전 원본 백업 필수

---

*기록 작성: 에이전트 미팅 퍼실리테이터 | task-1054.1*