# Phase 26 — 매칭 방법 비교 결과와 Figma DB 설계 결론

AI 를 활용한 MDX ↔ Figma 매칭을 **네 가지 방법**으로 비교하고, 그 결과로부터 **Figma DB 를 어떤 구조로 쌓아야 하는지** 도출한다.

## 1. 네 가지 방법

| Phase | 방법 | 공식 | 데이터 |
|-------|------|------|--------|
| **22** | 정제 anchor keywords only (baseline) | `1.0 × 키워드` | keyword_base.yaml + anchor_sets mirror |
| **23** | anchor + content summary | `0.5 × 키워드 + 0.5 × 내용` | + ko-sroberta cosine (MDX summary ↔ frame.content) |
| **24** | anchor + content + legacy structure | `0.5 × 키워드 + 0.3 × 내용 + 0.2 × 구조` | + legacy structure ontology (family/semantic_role) |
| **25** | Template-fit-v1 (최종 운영) | `0.25 anchor + 0.20 card + 0.20 rel + 0.15 slot + 0.20 content − penalties` | templates_v1 (32개: slots + anchor_sets + fit_notes + adaptation_allowed) |

## 2. 정답률

| Phase | 1. (MDX 1) 팝업 — DX와 BIM의 구분 | 2. (MDX 2) 2.2 DX 시행 주체별 기대효과 | 3. (MDX 03) 1. DX 시행을 위한 필수요건 | 4. (MDX 03) 2. Process 혁신과 Product 변화 | 합계 |
|---|---|---|---|---|---|
| **22** | ✓ | ✓ | ✓ | ✓ | **4/4** |
| **23** | ✓ | ✓ | ✓ | ✓ | **4/4** |
| **24** | ✓ | ✓ | ✓ | ✓ | **4/4** |
| **25** | ✓ | ✓ | ✓ | ✓ | **4/4** |

→ **네 방법 모두 4 TARGET 에서는 4/4**. 정답률만으로는 차이 없음.

## 3. 1-2위 margin 비교 (안정성)

| Phase | MDX01-2 | MDX02 | MDX03-1 | MDX03-2 | 평균 |
|-------|---------|-------|---------|---------|------|
| **22** | 0.095 | 0.049 | 0.207 | 0.158 | **0.127** |
| **23** | 0.071 | 0.051 | 0.105 | 0.107 | **0.083** |
| **24** | 0.121 | 0.045 | 0.213 | 0.200 | **0.145** |
| **25** | 0.076 | 0.180 | 0.079 | 0.098 | **0.108** |

## 4. 유닛별 Phase 점수 상세

### 1. (MDX 1) 팝업 — DX와 BIM의 구분 — 정답 Frame **18**

| Phase | 1위 Frame | 1위 점수 | 2위 Frame | 2위 점수 | margin | 라우팅 |
|-------|-----------|----------|-----------|----------|--------|--------|
| 22 | <span style='background:#fff3cd;padding:2px 6px;border:2px solid #dc2626;border-radius:3px;font-weight:bold'>🎯 18</span> | 0.208 | 24 | 0.113 | 0.095 | - |
| 23 | <span style='background:#fff3cd;padding:2px 6px;border:2px solid #dc2626;border-radius:3px;font-weight:bold'>🎯 18</span> | 0.410 | 04 | 0.339 | 0.071 | - |
| 24 | <span style='background:#fff3cd;padding:2px 6px;border:2px solid #dc2626;border-radius:3px;font-weight:bold'>🎯 18</span> | 0.463 | 24 | 0.342 | 0.121 | - |
| 25 | <span style='background:#fff3cd;padding:2px 6px;border:2px solid #dc2626;border-radius:3px;font-weight:bold'>🎯 18</span> | 0.922 | 29 | 0.847 | 0.076 | use_as_is |

### 2. (MDX 2) 2.2 DX 시행 주체별 기대효과 — 정답 Frame **14**

| Phase | 1위 Frame | 1위 점수 | 2위 Frame | 2위 점수 | margin | 라우팅 |
|-------|-----------|----------|-----------|----------|--------|--------|
| 22 | <span style='background:#fff3cd;padding:2px 6px;border:2px solid #dc2626;border-radius:3px;font-weight:bold'>🎯 14</span> | 0.164 | 09 | 0.115 | 0.049 | - |
| 23 | <span style='background:#fff3cd;padding:2px 6px;border:2px solid #dc2626;border-radius:3px;font-weight:bold'>🎯 14</span> | 0.402 | 27 | 0.351 | 0.051 | - |
| 24 | <span style='background:#fff3cd;padding:2px 6px;border:2px solid #dc2626;border-radius:3px;font-weight:bold'>🎯 14</span> | 0.404 | 20 | 0.359 | 0.045 | - |
| 25 | <span style='background:#fff3cd;padding:2px 6px;border:2px solid #dc2626;border-radius:3px;font-weight:bold'>🎯 14</span> | 0.928 | 20 | 0.748 | 0.180 | use_as_is |

### 3. (MDX 03) 1. DX 시행을 위한 필수요건 — 정답 Frame **13**

| Phase | 1위 Frame | 1위 점수 | 2위 Frame | 2위 점수 | margin | 라우팅 |
|-------|-----------|----------|-----------|----------|--------|--------|
| 22 | <span style='background:#fff3cd;padding:2px 6px;border:2px solid #dc2626;border-radius:3px;font-weight:bold'>🎯 13</span> | 0.303 | 20 | 0.096 | 0.207 | - |
| 23 | <span style='background:#fff3cd;padding:2px 6px;border:2px solid #dc2626;border-radius:3px;font-weight:bold'>🎯 13</span> | 0.465 | 15 | 0.360 | 0.105 | - |
| 24 | <span style='background:#fff3cd;padding:2px 6px;border:2px solid #dc2626;border-radius:3px;font-weight:bold'>🎯 13</span> | 0.539 | 20 | 0.326 | 0.213 | - |
| 25 | <span style='background:#fff3cd;padding:2px 6px;border:2px solid #dc2626;border-radius:3px;font-weight:bold'>🎯 13</span> | 0.925 | 20 | 0.846 | 0.079 | use_as_is |

### 4. (MDX 03) 2. Process 혁신과 Product 변화 — 정답 Frame **29**

| Phase | 1위 Frame | 1위 점수 | 2위 Frame | 2위 점수 | margin | 라우팅 |
|-------|-----------|----------|-----------|----------|--------|--------|
| 22 | <span style='background:#fff3cd;padding:2px 6px;border:2px solid #dc2626;border-radius:3px;font-weight:bold'>🎯 29</span> | 0.259 | 09 | 0.101 | 0.158 | - |
| 23 | <span style='background:#fff3cd;padding:2px 6px;border:2px solid #dc2626;border-radius:3px;font-weight:bold'>🎯 29</span> | 0.428 | 01 | 0.321 | 0.107 | - |
| 24 | <span style='background:#fff3cd;padding:2px 6px;border:2px solid #dc2626;border-radius:3px;font-weight:bold'>🎯 29</span> | 0.508 | 27 | 0.309 | 0.200 | - |
| 25 | <span style='background:#fff3cd;padding:2px 6px;border:2px solid #dc2626;border-radius:3px;font-weight:bold'>🎯 29</span> | 0.919 | 18 | 0.821 | 0.098 | use_as_is |

## 5. 관찰

### 5-1. 정답률로는 차이 없음

Phase 22~25 네 방법 모두 4 TARGET 에서 4/4 — 이 4개 유닛만 보면 어느 방법이 더 나은지 결정 불가.

### 5-2. Margin 으로 본 안정성 차이

- **Phase 22 (키워드만)**: IDF Jaccard 만으로는 의미 관계 포착 부족. 추상 주제에서 margin 약함.
- **Phase 23 (+내용)**: 의미 유사도가 정답 margin 을 확대하지만, "의미 비슷한데 구조 다른" 프레임도 함께 상승.
- **Phase 24 (+기존 구조)**: family/semantic_role 매칭이 정답 확정에 기여. 단, 구조 감지 confidence low 일 땐 점수 0 이라 불안정.
- **Phase 25 (template-fit-v1)**: margin 절대값은 Phase 24 대비 일부 케이스에서 좁아지지만, **multi-gate (intent + anchor/content/adaptation/not_suits) 로 정답 후보만 use_as_is** — 운영 관점에선 가장 안전.

### 5-3. Phase 24 기존 구조축의 한계

기존 구조축은 `family=list`, `semantic_role=prerequisites` 같은 **디자인이 어떻게 생겼나**만 기록한다. 실제 운영에서는 '이 콘텐츠가 이 디자인에 들어갈 수 있나'를 알아야 하는데, 기존 구조축은 **slot 개수·재구성 비용·금지 사항**을 다루지 못한다.

### 5-4. Phase 25 (template-fit-v1) 이 제공하는 추가 가치

- **라우팅 (multi-gate)**: 점수만 제공하는 Phase 22~24 와 달리, **structure_intent gate + anchor/content/adaptation/not_suits multi-constraint** 로 `use_as_is` / `light_edit` / `restructure` / `reject` 4단계 운영 판단 제공.
- **structure_intent 축**: 11 frame 에 태깅 (concept_comparison, persona_benefit, requirement_list, problem_diagnosis, process_product_split 등). Tagged mismatch 시 강한 차단 — 예: MDX03-1 × Frame 28 (requirement vs problem polarity 반대) = reject.
- **축별 breakdown**: anchor · cardinality · relation · slot · content 가 각각 몇 점인지 설명 가능 → 왜 이 점수인지 투명.
- **조건부 cap**: 짧은 generic anchor (`[BIM, DX]` 2-term) 가 우연히 매칭되어 점수를 부풀리는 편향 방어. MDX01-2 (진짜 BIM/DX 비교) 는 방증 세트(comparison_dimensions 0.71)로 cap 면제, MDX03-2 (BIM/DX 배경 언급) 는 방증 0.29 로 cap 적용 — 의도대로 작동.
- **not_suits 구조 신호**: `주체별 나열`, `필수요건 나열`, `BIM vs DX 직접 대조` 등 잘못된 매칭을 구조 신호로 감점.
- **adaptation_cost**: cardinality 불일치 시 split/merge/infer 비용으로 자연 감쇠.
- **32 템플릿 스키마화**: Phase 22~24 의 legacy frames 는 analysis.md 키워드 + family 로만 기록된 반면, Phase 25 은 각 프레임마다 slot / anchor / fit_notes / adaptation 을 명시한 templates_v1 스키마로 32개 전부 작성.

## 6. 결론 — Figma DB 는 어떻게 쌓아야 하나

**네 방법 모두 4 TARGET 정답률은 같지만, 제공하는 정보량이 다르다:**

| 제공 정보 | Phase 22 | Phase 23 | Phase 24 | Phase 25 |
|-----------|:-:|:-:|:-:|:-:|
| 1위 Frame | ✓ | ✓ | ✓ | ✓ |
| 단일 점수 | ✓ | ✓ | ✓ | ✓ |
| 축별 분해 | ✗ | 2축 | 3축 | **5축 + 2감점** |
| 원본 그대로 쓸 수 있나 (use_as_is) | ✗ | ✗ | ✗ | ✓ |
| 편집이 필요한가 (light_edit) | ✗ | ✗ | ✗ | ✓ |
| 재구성이 필요한가 (restructure) | ✗ | ✗ | ✗ | ✓ |
| 아예 쓰면 안 되는가 (reject) | ✗ | ✗ | ✗ | ✓ |
| 짧은 anchor 편향 방어 (조건부 cap) | ✗ | ✗ | ✗ | ✓ |
| 구조 신호로 감점 (not_suits) | ✗ | ✗ | ✗ | ✓ |
| 재구성 비용 산정 (adaptation_cost) | ✗ | ✗ | ✗ | ✓ |

**따라서 Figma DB 는 Phase 25 의 templates_v1 스키마로 쌓아야 한다**:

```yaml
templates_v1:
  <frame_id>:
    template_id: <snake_case_name>
    source: {title, original_layout}
    description: |
      <embedding-friendly 자연어 설명 (suits 맥락 포함)>
    visual_pattern:
      family: list | cards | table | compare | diagram | map | composite
      layout: <구체 layout>
      axis: horizontal | vertical
      relation_type: parallel | sequence | compare | hierarchy
      cardinality: {ideal, min, max}
    slots:
      - {id, type, required, max_chars}
    anchor_sets:
      - id: <set_name>
        terms: [...]
        min_hits: <int, optional>
        confidence_cap: <float, 짧은 generic 세트에만>
        cap_exempt_if_corroborated_by: <방증 임계>
    fit_notes:
      suits:     [검수용 bullet, description 에 반영]
      not_suits: [점수 감점 발화 조건]
    adaptation_allowed:
      split, merge, infer_missing_slot, rewrite_label, rewrite_body
    legacy: {family, surface, semantic_role}   # Phase 24 호환용 보존
```

32개 전체 템플릿이 이 스키마로 [`structure_ontology.yaml`](structure_ontology.yaml) 에 정의됨. 스펙: [`TEMPLATE_FIT_V1.md`](TEMPLATE_FIT_V1.md). 엔진: [`template_fit.py`](template_fit.py).

## 7. 운영 권고

- **매칭 엔진**: `template_fit.py` (Phase 25)
- **DB 파일**: `structure_ontology.yaml` → `templates_v1` 블록 (legacy `frames:` 는 Phase 24 호환용으로 보존)
- **MDX 분석**: `detect_mdx.py` — 매칭 단계 LLM 호출 0회
- **임베딩**: `embeddings.py` — ko-sroberta + numpy (32 프레임 규모는 벡터 DB 불필요)
- **라우팅 판정 (multi-gate)**: 단순 threshold 아님 — 여러 조건 AND
  - 1차: **structure_intent gate** (tagged mismatch 강한 차단)
    - `intent_source == 'tagged'` + `intent_compat < 0.4` → **reject**
    - `intent_source == 'tagged'` + `intent_compat < 0.7` → use_as_is/light_edit 금지, restructure 이하만
  - 2차: **route_v2 multi-constraint**
    - `use_as_is`: confidence ≥ 0.90 AND anchor ≥ 0.70 AND content ≥ 0.55 AND not_suits = 0
    - `light_edit`: confidence ≥ 0.75 AND anchor ≥ 0.50 AND content ≥ 0.45 AND adapt_pen < 0.10
    - `restructure`: confidence ≥ 0.60 AND (anchor ≥ 0.35 OR (content ≥ 0.55 AND adapt_pen < 0.20)) AND not_suits ≤ 1
    - 나머지: `reject`
- **운영 의미**:
  - `use_as_is`: 코드로 slot fill, AI 0회
  - `light_edit`: max_chars 초과 시만 AI 1회
  - `restructure`: adaptation_allowed 조작 AI 1회
  - `reject`: 다음 후보 또는 '적합 디자인 없음' 반환

**추가 검증 필요**: 현재 4 TARGET 으로는 엔진 프로토타입 검증까지 완료. 실제 확장 MDX 세트 (17~30개 추정) 회귀 테스트는 별도 진행.