# 토큰 최적화 최종 집대성: 퀄리티 보존 관점 재검토

**작업 ID**: task-1267.1
**팀**: dev1-team (헤르메스)
**작업 유형**: Lv.2 리서치+분석
**작성일**: 2026-03-29
**원본 보고서**: task-1263.1 (오딘/dev2), task-1265.1 (로키 재검토)

---

## SCQA

**S**: task-1263.1에서 이미지 QC 워크플로우의 토큰 최적화 9개 방안이 제시되었고, task-1265.1에서 로키가 사실 오류 4건, 절감률 과대추정, 놓친 기회 6건을 발견하여 재검토하였다.

**C**: 제이회장님의 핵심 우려는 "토큰 절약하려다 quality 높은 결과물을 내지 못할 경우"이다. 현재 두 보고서 어디에도 각 방안이 **결과물 퀄리티에 미치는 영향**을 체계적으로 분석한 내용이 없다. 절감률만 보고 적용하면 퀄리티 저하를 사전에 방지할 수 없다.

**Q**: 15개 방안 각각의 퀄리티 영향을 분석하고, 퀄리티를 보존하면서 현실적으로 달성 가능한 토큰 절감률은 얼마인가?

**A**: 15개 방안을 GREEN(4건)/YELLOW(8건)/RED(1건)으로 분류하였다. GREEN만 적용 시 15-22% 절감(퀄리티 위험 제로), GREEN+YELLOW 핵심 적용 시 40-55% 절감(안전장치 전제), 전체 적용 시 50-65% 절감. 특히 "일석이조" 방안 4건(토큰 절약+퀄리티 향상)을 최우선 적용 권장.

---

## 1. 방안별 퀄리티 영향 분석

### 범례
- **절감값**: 원본 추정 → 로키 보정 → 최종 채택
- **퀄리티 영향**: (+) 향상 / (0) 중립 / (-) 위험
- **판정**: GREEN(Safe) / YELLOW(Caution) / RED(Hold)

---

### GREEN (안전) — 퀄리티 영향 없거나 오히려 향상. 즉시 적용

#### G-1. 선택적 노하우 로딩 [신규, 로키 기회3]

- **절감값**: 2-3% (신규 발굴)
- **퀄리티 영향**: (+) 향상
  - 카피 Phase에서 디자인 노하우를 로딩하면 모델 주의력이 분산됨
  - 필요한 노하우만 로딩하면 모델이 핵심 정보에 집중하여 더 정확한 적용
- **퀄리티 위험 시나리오**: Phase별 필요 노하우를 잘못 매핑하여 필수 정보 누락
- **퀄리티 보호 장치**: Phase-노하우 매핑 테이블을 스펙에 명시적 정의
  - 1차 위임(카피): marketing + QC knowhow
  - 2차 위임(디자인): design + QC knowhow
  - 3차 위임(최종검증): 3개 전체
- **구현 난이도**: Easy (프롬프트 조건문 추가)
- **판정**: GREEN — 불필요한 컨텍스트 제거는 퀄리티를 올리는 방향

#### G-2. dispatch.py 이중 적재 해결 [신규, 로키 기회4]

- **절감값**: 3-5% (신규 발굴)
- **퀄리티 영향**: (+) 향상
  - 동일 QC 기준이 overview + 개별 Phase에 이중으로 적재되면 모델이 두 버전 간 미세 차이에 혼동 가능
  - 단일 소스로 통일하면 일관된 QC 수행
- **퀄리티 위험 시나리오**: overview에서 QC 기준을 완전 제거하면 전체 흐름 맥락 부족
- **퀄리티 보호 장치**: overview에는 "QC 기준은 각 Phase에서 로딩됨" 안내만 유지, 상세는 Phase에서만 포함
- **구현 난이도**: Easy (build_workflow_overview_prompt 수정)
- **판정**: GREEN — 중복 제거는 일관성과 퀄리티 모두 향상

#### G-3. 에스컬레이션 섹션 중복 제거 [신규, 로키 기회2]

- **절감값**: 2-4% (신규 발굴)
- **퀄리티 영향**: (0) 중립
  - 에스컬레이션 규칙은 참조용으로, 외부 파일화해도 에이전트 행동에 변화 없음
  - 현재 7곳에서 반복되어 오히려 수정 시 불일치 위험 존재 → 단일 소스가 더 안전
- **퀄리티 위험 시나리오**: 거의 없음. 에스컬레이션 규칙은 예외 상황 대응이므로 일반 퀄리티에 영향 미미
- **퀄리티 보호 장치**: 파일 경로를 모든 해당 Phase에 명시
- **구현 난이도**: Easy
- **판정**: GREEN — 7곳 중복은 유지보수 리스크가 오히려 높음

#### G-4. Sub-agent 결과 구조화 [원본 방안9, 로키 승격 제안]

- **절감값**: 원본 10-15% → 로키 Easy 승격 → 최종 10-15%
- **퀄리티 영향**: (+) 향상
  - 현재: 서브에이전트가 상세 결과를 텍스트로 반환 → 팀장 컨텍스트 비대화 → context rot 위험
  - 개선: "상세는 파일 저장 + 요약만 전달" → 팀장이 핵심 빠르게 파악 + 필요시 파일 드릴다운
  - 구조화된 결과물이 비정형 텍스트보다 정보 전달 정확도 높음
- **퀄리티 위험 시나리오**: 요약 과정에서 critical FAIL 정보 누락 → 팀장이 문제를 간과
- **퀄리티 보호 장치**: 요약 필수 포함 항목 정의 — FAIL 항목 수, FAIL 코드, 심각도. "FAIL 존재 시 반드시 FAIL 코드와 사유를 요약에 포함"
- **구현 난이도**: Easy (프롬프트 1줄 추가)
- **판정**: GREEN — context rot 방지 효과가 크고, 파일 백업으로 정보 손실 방지

**GREEN 합산 절감률**: 1-(1-0.025)(1-0.04)(1-0.03)(1-0.125) ≈ **20%** (현실적 15-22%)

---

### YELLOW (주의) — 퀄리티 영향 가능성 있으나 안전장치로 방지 가능. 조건부 적용

#### Y-1. /compact 강제 삽입 [원본 방안2]

- **절감값**: 원본 20-30% → 로키 보정 10-15% → 최종 10-15%
- **퀄리티 영향**: (-) 위험 가능
  - /compact는 컨텍스트를 요약 압축함 → 이전 Phase 피드백, QC 사유 등 디테일 손실
  - 특히 QC 사이클 중간 compact는 "왜 FAIL이었는지" 기억 상실 → 같은 실수 반복
  - 반면 적절한 compact는 context rot 방지 → 후반 Phase 퀄리티 유지
- **퀄리티 위험 시나리오**: Phase 3.5 사이클 2에서 compact → 사이클 1의 FAIL 사유를 잊음 → 동일 오류 반복 → 3사이클 소진 후 에스컬레이션
- **퀄리티 보호 장치**:
  1. **compact 금지 구간**: QC 사이클 진행 중(Phase 1.5, 3.5 내부)에서는 compact 금지
  2. **compact 허용 구간**: Phase 완료 후 다음 Phase 진입 전에만 허용
  3. **체크포인트 필수**: compact 전 `memory/checkpoints/{task_id}.md`에 현재 상태 저장
  4. 로키 지적: 서브에이전트 내에서는 /compact 실행 불가 → 메인 세션 수준에서만 적용
- **구현 난이도**: Easy
- **판정**: YELLOW — 적용 위치 제한 조건 하에서만 안전

#### Y-2. 저해상도 QC 이미지 [신규, 로키 기회1]

- **절감값**: 25-40% (신규 발굴, 로키 Tier 1 최상위 제안)
- **퀄리티 영향**: (-) 위험 가능
  - 360x360에서는 정상으로 보이나 1080x1080에서 미세 문제(글자 겹침 경계, 미세 흐림, 1px 오프셋) 발견 불가
  - A카테고리 기술적 검증(글자 겹침, 대비율)은 저해상도에서 오탐/미탐 증가
- **퀄리티 위험 시나리오**: 540x540 QC에서 PASS → 1080x1080 실제 배포 시 텍스트 겹침 발견 → 재작업 필요
- **퀄리티 보호 장치**:
  1. **최소 해상도**: 540x540 (360은 위험, 사용 금지)
  2. **최종 검증은 원본 사용**: Phase 4(최종 QC)에서는 반드시 1080x1080 원본으로 검증
  3. **A카테고리는 원본 필수**: 기술적 검증(글자 겹침, 대비율)은 해상도 민감 → 원본 사용
  4. **B카테고리만 저해상도 허용**: 디자인 품질, 전체 레이아웃 등 시각적 평가는 540에서도 가능
- **구현 난이도**: Easy (Python Pillow resize 1줄)
- **판정**: YELLOW — 안전장치(A카테고리 원본, 최종 원본)를 지키면 효과적

#### Y-3. 노하우 요약 캐시 [원본 방안4, 로키 Tier 1 승격 제안]

- **절감값**: 원본 5-8% → 로키 Tier 1 승격 → 최종 3-5% (보수적)
- **퀄리티 영향**: (-) 위험 가능
  - 500자 요약은 원본 노하우의 미묘한 예외 규칙, 엣지 케이스를 누락할 가능성
  - "보통은 이렇게 하되, 이 경우엔 다르게"와 같은 조건부 규칙이 요약에서 빠지기 쉬움
- **퀄리티 위험 시나리오**: 요약에 "폰트 크기 84/64/40px 규칙"만 남기고 "단, 서브카피가 2줄 이상이면 36px 허용" 누락 → 2차 위임에서 규칙 위반
- **퀄리티 보호 장치**:
  1. **요약 생성 후 검증**: Phase -1 완료 시 원본과 요약을 대조하여 "누락된 규칙 없는가" 체크
  2. **불확실 시 원본 참조**: 요약에 명시 — "확실치 않은 규칙은 원본 파일을 참조하세요"
  3. **예외 규칙 전용 섹션**: 요약에 "예외 및 조건부 규칙" 섹션을 필수 포함
- **구현 난이도**: Easy (프롬프트 조건문 + 캐시 파일)
- **판정**: YELLOW — 요약 품질이 핵심. 예외 규칙 포함 여부가 성패를 가름

#### Y-4. Delta QC 사이클 [원본 방안5]

- **절감값**: 원본 15-25% → 최종 15-25%
- **퀄리티 영향**: (-) 위험 가능
  - "PASS 항목 스킵"이 위험: 수정이 인접 요소에 영향을 미칠 수 있음
  - 예: 텍스트 크기 수정 → 레이아웃 이동 → 이전에 PASS였던 경계 이탈이 FAIL로 변경
  - 로키 지적: "어떤 변경이 어떤 항목에 영향을 미치는지" 판단 자체가 토큰 소비
- **퀄리티 위험 시나리오**: 사이클 2에서 PQ-01(키 메시지) 수정 → 텍스트 길이 변경 → 레이아웃 시프트 → 사이클 1에서 PASS였던 A-02(경계 이탈)가 실은 FAIL
- **퀄리티 보호 장치**:
  1. **구조적 변경 시 전체 재채점**: 텍스트 길이 변경, 레이아웃 이동, 요소 추가/삭제 → 전체 재채점
  2. **점수 변경만 delta**: 동일 요소의 문구 수정(오타, 어조)만 해당 항목 재채점
  3. **이미지 단위 delta만 허용**: 항목 단위 delta는 위험 → 이미지 단위(FAIL 이미지만 재검수)로 제한
- **구현 난이도**: Medium
- **판정**: YELLOW — 이미지 단위 delta만 허용하면 안전. 항목 단위 delta는 보류

#### Y-5. QC 기준 외부 파일화 [원본 방안3]

- **절감값**: 원본 5-10% → 로키 보정 3-7% → 최종 3-7%
- **퀄리티 영향**: (-/0) 약간 위험
  - 로키 지적: 외부 파일 참조 시 에이전트가 매번 Read해야 함. 안 읽으면 기준 누락
  - 인라인 포함 시 prompt caching으로 자동 최적화되는데, 외부 파일화하면 이 이점 상실
- **퀄리티 위험 시나리오**: 에이전트가 QC 기준 파일을 Read하지 않고 "기억"에 의존 → 기준 누락 또는 변형된 기준 적용
- **퀄리티 보호 장치**:
  1. 프롬프트에 "QC 기준 파일을 반드시 Read하고, Read 결과를 인용하여 채점하라" 명시
  2. A/B 테스트: 인라인 vs 외부파일 → 실제 토큰 비교 후 결정
  3. 로키 제안 수용: 환경(prompt caching 유무)에 따라 효과가 달라지므로 검증 후 적용
- **구현 난이도**: Easy
- **판정**: YELLOW — A/B 테스트 결과에 따라 적용 여부 결정. 섣부른 적용 금지

#### Y-6. Playwright 기반 A카테고리 자동 QC [원본 방안1]

- **절감값**: 원본 50-70% → 로키 보정 20-35% → 최종 20-35%
- **퀄리티 영향**: (-) 위험 가능하나 관리 가능
  - A카테고리(기술 검증) 자동화 자체는 인간보다 정확할 수 있음 (일관된 기준 적용)
  - 위험은 구현 품질: 자동 검증 스크립트 자체에 버그가 있으면 False PASS 발생
  - 로키 지적: PNG 단독 이미지는 HTML DOM이 없어 Playwright DOM 검사 불가
- **퀄리티 위험 시나리오**: auto-qc.py 스크립트의 bbox 겹침 로직에 2px 마진 오차 → 실제 겹침인데 PASS 판정 → B카테고리 수동 평가에서도 놓침
- **퀄리티 보호 장치**:
  1. **병행 검증 기간**: 최초 1-2주는 자동 QC + 수동 QC 병행. 일치율 95%+ 달성 후 자동만 적용
  2. **HTML 전용 1단계**: 1단계에서는 HTML 기반 이미지만 대상. PNG는 수동 유지
  3. **자동 QC 결과 로깅**: 모든 자동 판정을 JSON으로 기록하여 사후 검증 가능
  4. 난이도 상향: Easy-Medium → Medium-Hard (로키 보정 수용)
- **구현 난이도**: Medium-Hard (Tier 2로 하향, 로키 제안 수용)
- **판정**: YELLOW — 병행 검증기간이 핵심 안전장치

#### Y-7. 이미지 배치 QC [원본 방안6]

- **절감값**: 원본 10-15% → 최종 8-12%
- **퀄리티 영향**: (-) 약간 위험
  - 2-3장 동시 평가 시 개별 디테일 주의력 분산 가능
  - 다만 비교 평가 시 일관성 확보에는 오히려 유리 (같은 세트에서 톤 차이 발견 등)
- **퀄리티 위험 시나리오**: 3장 동시 로드 → 컨텍스트 과부하 → 3번째 이미지에 대한 평가가 부실
- **퀄리티 보호 장치**:
  1. **배치 크기 2장 제한**: 3장은 과부하 위험, 2장이 최적
  2. **항목별 체크리스트 필수**: 배치 평가 시에도 개별 이미지에 대해 전 항목 채점 필수
- **구현 난이도**: Medium
- **판정**: YELLOW — 배치 2장 제한 시 안전

#### Y-8. 모델 계층 최적화 [신규, 로키 기회6]

- **절감값**: 토큰 수 동일, 비용 50-70% 절감
- **퀄리티 영향**: (-) 위험 가능
  - Haiku로 A카테고리 QC 시 Sonnet 대비 미묘한 판단력 차이
  - A카테고리는 규칙 기반(글자 겹침, 해상도)이므로 Haiku로도 충분할 수 있음
  - B카테고리는 창작성 평가이므로 반드시 Sonnet 이상
- **퀄리티 위험 시나리오**: Haiku가 A-07(대비율) 판정에서 WCAG AA 기준 4.5:1을 4.3:1과 혼동 → False PASS
- **퀄리티 보호 장치**:
  1. **A카테고리 벤치마크 필수**: 기존 QC 결과 20건으로 Haiku vs Sonnet 일치율 측정
  2. **90% 이상 일치 시에만 적용**
  3. **B카테고리는 Sonnet 고정**: 창작성/디자인 품질 평가는 모델 다운그레이드 금지
- **구현 난이도**: Medium (모델 분기 로직)
- **판정**: YELLOW — 벤치마크 데이터 확보 후 결정. 비용 절감이므로 토큰 최적화와는 별도 트랙

---

### RED (보류) — 퀄리티 저하 위험 높음. 전제조건 충족 후 재검토

#### R-1. Phase 통합 — 위임 라운드 축소 [원본 방안7]

- **절감값**: 원본 25-35% → 최종 15-25% (보수적)
- **퀄리티 영향**: (--) 높은 위험
  - 로키 지적: Phase 3.5(디자인 QC 3사이클) + Phase 4(최종 검증) + Phase 5가 한 세션 → 이미지 Read 집중 → 30K 토큰 임계치 빈번 초과 → context rot
  - context rot은 후반 Phase 퀄리티를 직접적으로 저하시키는 가장 큰 위험
  - 2025년 기업 AI 실패의 65%가 context drift/memory loss 원인 (리서치 데이터)
- **퀄리티 위험 시나리오**: 2차 세션에서 Phase 3.5 사이클 3 + Phase 4 진행 중 context rot → Phase 4에서 이전 FAIL 사유를 잊어버리고 동일 오류 PASS 처리
- **퀄리티 보호 장치**: Playwright 자동 QC + 저해상도 이미지가 선행 적용되어 이미지 Read 대폭 감소한 후에만 가능
- **전제조건**: Y-6(Playwright) + Y-2(저해상도) + Y-1(/compact) 모두 적용 및 검증 완료
- **구현 난이도**: Hard
- **판정**: RED — 전제조건 3개 모두 충족 + 실측 데이터 확보 후에만 재검토

---

### 참고 — 현재 환경에서 제한적 적용

#### 파이프라인 통합 QC [원본 방안8]

- **절감값**: 15-20%
- **퀄리티 영향**: (+) 긍정 가능 (렌더링과 동시 QC)
- **상태**: 디자인팀 협업 필요, 장기 과제
- 방안 Y-6(Playwright 자동 QC)의 확장 버전. Y-6 검증 후 순차 적용

#### 프롬프트 캐싱 구조 최적화 [로키 기회5]

- **상태**: Claude Code CLI에서는 자동 관리되므로 현재 환경에서 직접 적용 불가
- API 직접 호출 환경으로 전환 시 적용 검토
- **참고**: 프롬프트를 "안정 접두부 + 가변 접미부"로 구조화하는 것 자체는 가독성/일관성 향상에 도움

---

## 2. 일석이조 방안 — 토큰 절약 + 퀄리티 향상

토큰을 절약하면서 **오히려 퀄리티를 올리는** 4개 방안:

**1. 선택적 노하우 로딩 (G-1)**
- 메커니즘: 불필요한 컨텍스트 제거 → 모델 주의력이 관련 정보에 집중
- 효과: 카피 Phase에서 디자인 노하우가 섞이면 "디자인 관점에서 좋은 카피"를 쓰려다 핵심 메시지가 약해짐. 분리하면 각 Phase의 전문성 강화

**2. 이중 적재 해결 (G-2)**
- 메커니즘: 동일 정보의 두 버전 제거 → 모델 혼동 없음
- 효과: QC 기준이 overview와 Phase에서 미묘하게 다르게 표현되면 채점 기준 일관성 저하. 단일 소스로 통일하면 채점 정밀도 향상

**3. Sub-agent 결과 구조화 (G-4)**
- 메커니즘: 비정형 텍스트 → 구조화된 요약 + 상세 파일 → 팀장의 정보 처리 효율 향상
- 효과: 팀장이 3,000토큰의 비정형 결과를 읽을 때보다, 500토큰 요약 + 필요시 파일 드릴다운이 판단 정확도 높음. context rot도 방지

**4. /compact 적절한 적용 (Y-1, 조건부)**
- 메커니즘: 30K 토큰 임계치 도달 전 정리 → context rot 방지
- 효과: 제이회장님 우려의 핵심인 "후반부 퀄리티 저하"를 직접 방지. 단, QC 사이클 중간 금지 조건 필수

---

## 3. 적용 순서 로드맵

### Wave 1: 즉시 적용 (1-2일) — GREEN 전량

절감률: **15-22%**, 퀄리티 위험: **제로**

1. G-1: 선택적 노하우 로딩 (프롬프트 조건문 추가)
2. G-2: dispatch.py 이중 적재 해결 (overview에서 상세 QC 기준 제거)
3. G-3: 에스컬레이션 섹션 중복 제거 (7곳 → 1곳 외부 파일)
4. G-4: Sub-agent 결과 구조화 (프롬프트 지시 추가)

### Wave 2: 조건부 적용 (3-7일) — YELLOW 핵심

절감률: 추가 **20-30%** (누적 35-50%), 퀄리티 위험: **안전장치로 관리**

5. Y-1: /compact 강제 (Phase 간 전환 시만, 사이클 내 금지)
6. Y-2: 저해상도 QC 이미지 (540x540, B카테고리만, 최종은 원본)
7. Y-3: 노하우 요약 캐시 (예외 규칙 포함 검증 후)
8. Y-4: Delta QC (이미지 단위만, 항목 단위 금지)

### Wave 3: 검증 후 적용 (1-3주) — YELLOW 나머지

절감률: 추가 **10-15%** (누적 45-60%), 퀄리티 위험: **벤치마크 기반 판단**

9. Y-5: QC 기준 외부 파일화 (A/B 테스트 결과 기반)
10. Y-6: Playwright 자동 QC (2주 병행 검증 → 일치율 95%+ 확인)
11. Y-7: 이미지 배치 QC (2장 단위, 체크리스트 강제)

### Wave 4: 전제조건 충족 후 (1개월+) — RED

절감률: 추가 **10-15%** (누적 50-65%), 퀄리티 위험: **전제조건 검증 필수**

12. R-1: Phase 통합 (Y-1 + Y-2 + Y-6 모두 검증 완료 후)
13. Y-8: 모델 계층 최적화 (벤치마크 20건 일치율 90%+ 확인 후)
14. 파이프라인 통합 QC (Y-6의 확장, 디자인팀 협업)

---

## 4. 절감률 종합 비교

**원본 보고서 (task-1263.1)**:
- Tier 1 즉시: 60-80% (과대추정)
- 전체: 70-90% (과대추정)

**로키 재검토 (task-1265.1)**:
- Tier 1 현실적: 30-45%
- 전체 현실적: 50-65%

**본 보고서 (퀄리티 안전 기준)**:
- Wave 1 (GREEN, 퀄리티 위험 0): **15-22%**
- Wave 1+2 (GREEN+YELLOW 핵심): **35-50%**
- Wave 1+2+3 (안전장치 검증 완료): **45-60%**
- 전체 (전제조건 충족): **50-65%** (로키 보정값과 일치)

핵심: **퀄리티 위험 제로인 Wave 1만으로도 15-22% 절감**. 이것만으로 task-1259.1과 같은 토큰 소진 사태의 버퍼를 확보할 수 있음.

---

## 5. 사실 오류 정정 반영

로키 재검토에서 발견된 사실 오류 4건을 스펙에 모두 반영:

1. dispatch.py 경로: `prompts/dispatch.py` → `/home/jay/workspace/dispatch.py` (루트)
2. knowhow-design.md 크기: 4.2KB → 6.0KB, 노하우 총 토큰 ~4.7K → ~5.4K
3. QC 기준 섹션 분포 정정:
   - `_build_category_a_section`: Phase 2, 3.5, 4, overview (4곳)
   - `_build_category_b_section`: Phase 2, 4, overview (3곳)
   - `_build_fail_categories_section`: Phase 2, 4, overview (3곳)
   - `_build_escalation_section`: Phase 0, 1, 2, 3, 3.5, 4, overview (7곳)
4. 스펙 A-2 수정 대상 정정:
   - 제거: `build_phase0_5_prompt`, `build_phase1_5_prompt` (QC 섹션 없음)
   - 추가: `build_phase0_prompt`, `build_phase1_prompt`, `build_phase3_prompt` (에스컬레이션)

---

## 6. 발견 이슈 및 해결

### 자체 해결 (2건)

1. **원본과 로키의 절감률 추정 간극** — 본 보고서에서 퀄리티 안전 기준으로 재분류하여 Wave별 현실적 절감률 산출
2. **원본 스펙의 수정 대상 함수 오류** — 로키 검증 결과를 반영하여 스펙 전면 업데이트 (아래 스펙 참조)

### 범위 외 미해결 (1건)

1. **이미지 멀티모달 토큰 정확한 측정** — 범위 외 사유: 모델별 인코딩 차이로 정확 측정 불가. 향후 Anthropic API의 토큰 카운트 응답으로 실측 필요

---

## 생성/수정 파일 목록

- 생성: `/home/jay/workspace/memory/reports/task-1267.1.md` (본 보고서)
- 수정: `/home/jay/workspace/memory/specs/token-optimization-plan.md` (최종 스펙 업데이트)
- 참조: `/home/jay/workspace/memory/reports/task-1263.1.md` (원본 보고서)
- 참조: `/home/jay/workspace/memory/reports/task-1265.1.md` (로키 재검토)