← 다이어그램 아카이브

내용시각화 규약 v0.5 원본 2026-08-04

Visual Summary 규약 v0.5

사용자가 쓴 글을 컴포넌트로 바꿀 때 구조가 뭉개지는 것이 지금 품질 문제의 핵심이다. Summary 를 Markdown 에서 구조화 형식으로 바꿔 슬롯을 보존하고, 컴포넌트 쪽에는 의미 태그를 붙여 대조한다. 2026-08-04 MORDOR 체크인 덱을 정리하고, 3주 뒤 SSoT 와 대조해 무엇이 바뀌었는지까지 붙였다.

덱 저자 정원석 (MORDOR) SSoT mordor-wiki 대조 시점 2026-08-26
§0

30초 요약

  • 문제내용시각화 BAD 의 85% 가 렌더링이 아니라 매칭 문제다. 검색이 컴포넌트를 잘 골라도 그 다음이 정의돼 있지 않다.
  • 원인Summary 가 Markdown 이라 값·단위·계열이 문자열로만 남는다. 「152억」이 숫자인지 텍스트인지 구분이 없다.
  • 처방Summary 를 YAML 구조화 형식으로 바꿔 슬롯을 보존하고(질의 쪽), 컴포넌트에는 semantic tag 를 붙인다(색인 쪽). 둘은 별개 경로이고 BE 검색 모듈에서 만난다.
  • 규약v0.5 는 2026-08-02 확정. 최상위는 항상 components[], type 은 대분류.중분류 문자열 하나, 생성은 LLM 이 YAML 을 직접 쓴다.
  • 보장성립 조건을 못 채우면 fallback 순서로 물러나고 마지막 셋(List · LongFormTextLayout · HighlightedMessage) 은 개수 조건만 보므로 언제나 하나는 성립한다 — 빈 결과가 사용자에게 가지 않는다.
  • 뒤집힘2026-08-03 에 어제까지의 결정이 뒤집혔다. 꾸밈은 등급 하나가 아니라 축 2개 × 값 3개, 계층은 새 필드 없이 entity.components[] 로 간다.
  • 그 뒤3주 사이 2단계는 스킵, 3단계는 취소, 4단계 직행으로 정리됐다. §11
확정 · 규약 성립 · 닫힘 열림 · 미정 취소 · 문제

이 문서의 위치

원본 덱도 파생물이고 이 페이지는 그 파생물의 파생물이다. SSoT 는 mordor-wiki / projects/mordor/visual-summary/ 이고, 규약은 spec/schema-v0.5.md, 할 일은 TODO.md 가 갖는다. 숫자나 결정이 여기와 다르면 그쪽이 맞다.

§1

오해부터 지운다 — 두 갈래

덱 p.3

「사용자 입력이 RLSC 로 변환된다」는 사실이 아니다. 경로가 둘이고 서로 별개로 진행된다. 이 그림을 잘못 들고 있으면 뒤의 결정이 전부 이상하게 들린다.

"사용자 입력이 RLSC 로 변환된다" — 아니다. 경로가 둘이고 별개로 진행된다. 질의 쪽 (QUERY SIDE) 사용자 입력을 검색 조건으로 바꾼다 Summary structure 입력마다 새로 만든다 · 생성기(LLM)가 쓴다 규약 = spec/schema-v0.5.md 색인 쪽 (INDEX SIDE) 템플릿 컴포넌트를 미리 검색 가능하게 뽑아 둔다 RLSC Search Signature v2 이미 있는 자산에서 배치로 뽑는다 · 83,771건 적재 태그는 4단계에서 node 단위로 내려간다 BE 검색 모듈에서 합류 질의 쪽 조건 색인 쪽 파생물
structure 에서 RLSC 로 가는 화살표는 변환이 아니라 capability 대조다. 그 규약이 spec/capability-table.md 다.
§2

왜 하나 — BAD 의 85%

덱 p.4

렌더링 문제가 아니다

2026-07-26 BAD 원인 분석. judge 채점 16,819행 집계 + BAD 200건 직접 분류.

→ 85% 가 컴포넌트와 내용이 안 맞는 문제

세부 원인 넷

  • 텍스트 용량 초과
  • 매핑과 위계 오류
  • 슬롯 수 불일치
  • 대치 실패

검색이 컴포넌트를 잘 골라도 그 다음이 정의돼 있지 않아 결과가 나빠지고 있다.

2026-08-03 방향 1.5개월 이내에 구조 불일치를 해결한다. 체감 BAD 50% → 20% 이하가 기대치다.

§3

무엇이 뭉개지나

덱 p.5

같은 입력인데 결과가 둘이다. 차이는 슬롯이 남느냐 하나다.

② MARKDOWN SUMMARY (현행) # 2025 사업 성과 * 총매출 152억 * 온라인 매출 22억 값과 단위, 계열이 문자열로만 남는다. 「152억」이 숫자인지 텍스트인지 구분이 없다. → 검색이 KPI 컴포넌트를 골라도    어느 자리에 152 를 넣을지 모른다 ②' VISUAL SUMMARY (YAML) components:   - type: KPIKeyMetric.BigNumber     structure:       entities:         - { label: 총매출,            value: 152, unit: 억원 } 슬롯이 그대로 남는다. value 가 숫자 자리, unit 이 단위 자리다. ① 사용자 입력 ② Summary ③ 검색 조건 ④ 후보 컴포넌트 ⑤ 대치 파이프라인에서 ②만 바꾼다
바꾸는 것은 파이프라인 ② 한 칸뿐이다. ①·③·④·⑤ 는 그대로 두고 Summary 의 형식만 바꾼다.
§4

로드맵과 태그의 모호성

덱 p.6–7

단계마다 Summary 형식 · 검색 방식 · 태그 범위 셋이 동시에 바뀐다. 아래는 덱 시점(2026-08-04)의 계획이고, 실제로 어떻게 됐는지는 §11 에 있다.

단계Summary검색태그 범위태그가 가리키는 것
1 현행Markdown임베딩 유사도안 단다—
2 목표 8-18Markdownsemantic tag컴포넌트 하나이 컴포넌트 어딘가에 그 타입이 있다
3YAMLtag + structure컴포넌트 하나2단계와 같음
4YAMLtag + node 태그컴포넌트 안 node 마다어느 node 인지 특정된다
5 미정YAML4단계와 같음node 마다4단계 + 카테고리별 property

3단계는 실행하지 않는다

3단계에서 만들 대치 로직이 4단계에서 버려질 수 있다. 정보가 확실한 4단계로 바로 간다 7/24 회의

배포 일정은 다시 봐야 한다 덱 시점

2026-08-03 에 제품 배포가 연기됐다. 2단계 마감 8/18 이 그 연기에 포함되는지 티켓 반영이 없다.

왜 단계를 나누나 — 태그 하나로는 두 경우를 못 가른다

컴포넌트 하나에 태그를 다는 한 — 두 경우가 같아 보인다 경우 A root 자체가 그 타입이라 붙었다 root : ComparisonTable child child 태그 = ComparisonTable 경우 B 하위 어딘가에 그 타입 node 가 있다 root : (분류 없음) ComparisonTable List 태그 = ComparisonTable (같다) 실데이터가 B 를 증명한다 design_object_id 4757227 에 ComparisonTable · HierarchicalTree · List · HighlightedMessage 넷이 함께 붙어 있다. root 가 넷을 동시에 가질 수는 없다. 복수 태그 83,771건 중 260건(0.3%), 최대 4개 4단계에서 node 단위로 태그를 달면 해소된다 그 일을 I.I.S. 가 맡는다
복수 태그가 0.3% 밖에 안 되는 것이 오히려 문제다 — 대부분의 컴포넌트는 태그 하나만 갖고, 그 하나가 A 인지 B 인지 알 방법이 없다.
§5

실증 근거 — 공급과 수요

덱 p.8

설계를 정한 것은 취향이 아니라 이 분포다. 색인에 있는 것은 거의 List 하나인데, 사용자가 원하는 것은 흩어져 있다.

색인 쪽 — 붙어 있는 태그 모수 83,771 design object · 2026-07-22 적재 List 81.1% BigNumber 3.6% Steps 2.4% ListingTable 0.5% 상위 8종이 94.5% 질의 쪽 — 사용자가 원하는 것 List 31.96% ListingTable 15.08% Steps 10.92% ComparisonTable 7.24% 0% 40% 80% 수요는 다양한데 풀이 쏠려 있다 색인은 한 종이 8할을 먹고, 수요는 네 종에 걸쳐 있다 두 판은 같은 눈금(0–85%)과 같은 기준선을 쓴다 · 값은 모두 막대 옆에 직접 적었다
두 판은 같은 가로 눈금을 쓴다. 모든 값이 막대 옆에 직접 적혀 있어 색만으로 읽지 않아도 된다. 붉은 막대 하나가 이 프로젝트가 존재하는 이유다.

이 분포가 설계를 정했다. VennDiagram · Tree · NestedScope · Pyramid 는 각 164건 이하, 데이터 차트는 각 51건 이하다. 성립 조건을 엄격하게 걸면 후보가 0이 되어 전부 List 로 강등된다. 그래서 §7 의 capability 는 성립 조건을 최소로 줄이는 방향으로 설계됐다.

§6

v0.5 가 정한 것

덱 p.9–10 · 2026-08-02 확정
항목결정
최상위 형태항상 components[]. 하나면 길이 1 배열
type문자열 하나로 대분류.중분류. v7 단어장 49종 중 41종
confidence제거. 생성기가 채우지 않는다
alternatives[]신설. fallback 순서보다 먼저 본다
entity.id생성물에서 뺐다. 파싱 뒤 배열 순서로 매긴다
datasetmeasure 와 matrix 두 모양. 표 계열도 matrix
relation.typeintersects 와 compares 둘
생성 방식LLM 이 YAML 을 직접 쓴다. JSON 변환 후 스키마 검증
원소 수 상한두지 않는다. 원소 간 관계는 자리만 예약

검증 실측 스키마 Draft 2020-12 유효성 통과 · 본문 예시 18종 전량 통과 · 부정 사례 12종 의도대로 거부

v0.4 → v0.5, 원문 12건 전량

위 표는 덱이 아홉 줄로 줄인 것이다. 규약 원문 0절이 적어 둔 변경은 열두 건이다.

# v0.4 v0.5
1LLM 이 JSON 을 생성하고 YAML 로 직렬화LLM 이 YAML 을 직접 생성한다. 이유는 추론 속도다
2최상위가 structure(단일) 또는 components[](다중)항상 components[] 배열이다. 하나면 길이 1이다
3component.type enum 11종type 문자열 하나, 대분류.중분류 62값 (대분류 21 + 결합 41). v7 단어장은 49종이고 8종을 의도적으로 뺐다 (capability-table.md 범위 절). 범위를 49종으로 열지는 ../TODO.md B-24 에서 다시 본다
4component.confidence optional제거했다
5없음alternatives[] 를 열었다. 못 쓸 때 대신 쓸 카테고리를 선호 순서로 적는다
64-1절이 traits(계층, 장식) 도입을 제안도입하지 않는다 → 2026-08-03 에 뒤집혔다 (아래 상자). traits 묶음은 두지 않고 꾸밈은 decoration, 계층은 entity.components[] 로 나눠 갔다. 2026-08-04 에 2절에 반영했다
7dataset.type 3종(gauge, stacked_bar, combo)dataset.shape 2종(measure, matrix)
8relation.type 1종(intersects)2종(intersects, compares)
9entity.id 필수생성물에서 뺐다. 파싱 뒤 기계가 매긴다 (3.2절)
10없음page 수준 relations 를 예약했다. Summary 생성기는 채우지 않는다
113절에 capability 테이블 11행별도 문서 41행으로 분리했다
1211절에 열린 결정 15건TODO.md B절이 SSoT 다

↻ v0.4 → v0.5 변경 12건 · schema-v0.5.md — 원본에서 자동 동기화

type — 단어장 49종에서 왜 8종이 빠졌나

v7 단어장 49종 − 페이지 역할 4종 Opening · TableOfContents SectionDivider · Ending − 지도 전용 4종 Distribution · Location Highlight · Geo_Flow = 41종 capability 대상 왜 뺐나 페이지 역할은 의미 구조가 아니라 페이지에서의 자리다. 지도 전용은 지도 데이터가 있어야 성립해 structure 가 표현할 대상이 아니다. 다시 열린 질문 (B-24) 49종 전량으로 열어야 하지 않나 — 페이지 역할은 색인에 실재한다 (v3.5)
허재영님 지적 2026-08-03. 이 질문은 덱 이틀 뒤에 닫혔다 — 결론은 「49종으로 연다」. §11 참고.
실제 생성물 — 가장 단순한 형태 spec/schema-v0.5.md 8.1절 
version: "0.5"
title: 효과적인 회의를 위한 3가지 원칙
components:
  - type: Enumeration.List
    structure:
      entities:
        - { label: 명확한 아젠다, items: [회의 전 안건 공유, 목표 한 문장 정의] }
        - { label: 시간 관리,     items: [시작과 종료 시간 엄수, 항목별 타임박스] }
        - { label: 액션 아이템,   items: [담당자 지정, 마감일 명시] }
§7

capability 와 fallback

덱 p.11–12

카테고리마다 셋을 선언한다. 요구 등급을 필수·선호·무시로 나누는 대신, 성립 조건은 최소로 줄이고 나머지는 기본값을 가진 선택 값으로 옮겼다.

선언무엇인가못 채우면
성립 조건이게 없으면 그 종류로 배치가 불가능한 것그 종류가 후보에서 빠진다
선택 속성안 적어도 되는 것. 규약이 기본값을 정해 둔다기본값으로 그린다
fallback 순서그 종류가 색인에 없을 때 물러날 곳순서를 따라 내려가고 마지막은 항상 List

성립 조건을 최소로 줄였다

내용을 요구하는 것은 다섯뿐이다 — BigNumber·Gauge 의 수치, Tree·NestedScope 의 children, ComboChart 의 혼합 조건.

나머지는 개수와 matrix 유무만 본다.

기본값 규칙

기본값은 표현 선택에만 준다. 내용에는 주지 않는다.

apex(어느 쪽이 꼭대기인가) → 기본값 OK

value(숫자가 얼마인가) → 없는 데이터를 지어내는 것이므로 성립 조건

fallback — 빈 결과가 사용자에게 가지 않는다

예시 — 게이지를 원했는데 색인에 없을 때 Gauge BigNumber List 근접도 순서만 지키면 몇 칸이든 종단이 셋이다 — 셋 다 개수 조건만 본다 Enumeration.List entities 가 2개 이상 TextBasedCommunication.LongFormTextLayout 1개이고 여러 문장 TextBasedCommunication.HighlightedMessage 1개이고 한 문장 언제나 하나는 성립한다. 그래서 대치 실패 정책을 따로 두지 않았다 — 빈 결과가 사용자에게 갈 길이 없다. 모든 structure 는 리스트로 읽히는 entities 를 가진다. dataset 만 있으면 거기서 파생한다.
덱 시점의 fallback 맵은 엣지 55개였고, 손으로 쓰지 않고 규칙 여덟 개를 세운 뒤 각 엣지에 어느 규칙이 걸리는지를 capability 에서 계산했다. 그래서 표가 capability 와 어긋날 수 없다. (지금은 45종·엣지 128개로 늘었다 — §11)

계산 중에 결함 하나가 드러났다

「선택 속성」열이 내용 필드(period, speaker)와 표현 선택(orientation, apex)을 섞어 담고 있었다. 그대로 계산하면 Timeline → Steps 에서 시각(period)을 버리게 된다. 갈라서 내용은 옮기고 표현만 버리도록 고쳤다.

§8

꾸밈구조 — 뒤집힌 결정

덱 p.13–18 · 2026-08-03

덱에서 가장 중요한 부분이다. 어제까지의 결정이 하루 만에 뒤집혔다.

항목2026-08-022026-08-03
계층structure 에 선언하지 않는다컴포넌트를 nested 구조로 두어 해결한다
꾸밈질의 쪽 필드를 두지 않는다꾸밈구조를 둔다. 다만 1단계는 전역 기준만

뒤집은 이유 1

8/2 결정이 판정 책임을 색인 쪽으로 넘겼는데, 색인 쪽에 그것을 받을 선언이 없었다.

capability-table.md 에 꾸밈 언급이 0건이었다.

뒤집은 이유 2

그 결정의 근거표가 보존 전용 문서에만 있었다.

허브가 「v0.5 는 이 철학을 따르지 않는다」고 적어 둔 문서다.

왜 등급 하나로는 안 되나

7/24 회의의 N / N+α / N+β 는 누적 등급이다 (N ⊂ N+α ⊂ N+β). 여기에 네 가지 문제가 있었다.

1. 다른 것이 섞인다

N+β 가 「요소 배치와 장식」이다. 배치가 정교한데 그림이 없는 컴포넌트가 있다.

2. 조합을 못 적는다

「배경은 원하지만 일러스트는 싫다」에 이름이 없다.

3. 끼울 자리가 없다

배경·테두리·아이콘이 생기면 「N+β 안쪽」이라 할 수밖에 없다.

4. N 은 애초에 꾸밈 축이 아니다

N 의 「최소 필요 조건」은 capability 성립 조건과 같은 대상이다. 등급 최하단에 두면 같은 사실이 두 곳에 생긴다.

그래서 축 집합으로 둔다

꾸밈구조 — 축 하나가 RLSC role 하나에 대응한다 component.decoration 
decoration:                # 꾸밈구조 하나
  ornament: prefer          # 꾸밈 축 하나 + 선호값 하나 → Element.Decoration
  background: avoid         # 꾸밈 축 하나 + 선호값 하나 → Element.Background

선호값은 셋이다

  • prefer — 있으면 가점
  • indifferent — 보지 않는다 (기본값)
  • avoid — 있으면 감점

require 를 두지 않는다. 꾸밈을 필수로 걸면 후보가 0이 된다.

축이 role 하나를 가리키는 이유

축이 RLSC role 하나에 정확히 대응하면 추출이 이미 붙인 표식을 그대로 쓸 수 있다.

minimal(N)·rich(N+β)는 문서와 회의에서 부르는 별명이고 스키마 값이 아니다 — 축이 늘면 뜻이 바뀌기 때문이다.

판정 기준 하나로 축이 갈린다

대치가 이 노드를 내용으로 채우는가? 이 질문 하나가 축의 유무를 정한다 채운다 안 채운다 축 아님 — 내용이 이미 답이다 Element.Title · Subtitle · Description → entity.label 과 entity.components[] 가 담는다 Element.Highlight → entity.emphasis 가 이미 있다 축 필요 — 입력에 대응물이 없다 Element.Decoration → decoration.ornament (role 정의: "내용 대치 시 변경 불필요") Element.Background → decoration.background 부수 효과 N+α(타이틀·디스크립션 등급)는 개념 자체가 사라졌다. 표현 밀도가 아니라 내용 유무이기 때문이다.
기준이 「표현 밀도」에서 「대치가 채우나」로 바뀌자 등급 세 층이 축 두 개로 접혔다.

1단계 범위 — 전역 기준만 잡는다

층1단계 (지금)요소 대치 착수 후
Summary (질의)생성하지 않는다. 스키마에 optional 로 자리만필요하면 생성기가 적는다
카테고리 기본미정41종에 채운다
시스템 전역 기본여기만 잡는다 (예: 꾸밈 많은 것을 우선)유지

왜 미루나

  • 지금 소비할 주체가 없다. 요소 대치가 아직 동작하지 않는다
  • 색인이 대조할 대상을 못 받는다
  • 지금 필요한 것은 전역 기준 하나로 된다

선례가 있다

entity.components[] 와 page relations 가 모두 「스키마에 열어 두고 생성기는 채우지 않는다」.

decoration 도 같은 방식으로 연다.

§9

다섯 구간이 다 붙어야 돈다

덱 p.19–20

꾸밈구조를 실제로 쓰는 곳은 요소 대치다. 그런데 그게 돌려면 앞뒤 다섯 구간이 전부 대응해야 한다. 덱 시점에 한 구간이 끊겨 있었다.

추출 노드에 Decoration · Background role role 은 이미 붙는다 색인 그 role 을 얼마나 가졌는지 담는다 경로가 없다 text_map·text_node_roles· semantic_tags 는 있는데 노드 분류 자리가 없다 검색 기본값과 선호를 대조해 순위를 움직인다 capability 에 꾸밈 축 열이 없다 Visual Summary 그 입력의 선호를 적는다 표기 미정 (B-18) 대치 선호에 맞춰 role 노드를 지우거나 남긴다 아직 동작하지 않는다 색인 경로가 먼저 풀려야 나머지가 동작한다. 추출이 role 을 붙여도 색인이 못 받으면 검색이 대조할 대상이 없다. 해법 선례는 semantic_tags denormalize 방식이다 — 그 표를 색인 테이블에 펴서 담는 것. 할 일: TODO.md I-4, B-22
점선 화살표가 끊긴 구간이다. B-18(표기)은 덱 당일 닫혔고, B-22(색인 경로)는 2026-08-26 기준 아직 열려 있다.

요소 대치 — 꾸밈구조를 쓰는 곳

신동한님 쪽 모듈(AI 꾸미기)을 참고해 구현하기로 했다 2026-07-23 회의. 흐름은 넷이다.

①②③④
reference design
template / page / component		 교체 target
AI 가 식별		 query · embedding
교체 대상 서술		 확정 제약
size 등

난점은 ②와 ③이다

7/23 회의 원문: 「비슷한 요소 찾기 사용. 다만 교체 타겟 결정 및 타겟별 query 생성이 중요」

검색 자체보다 무엇을 바꿀지 정하고 어떻게 서술할지가 문제다.

정하지 않은 것

reference design 이 꾸밈 수준을 이미 정해 버리면 꾸밈구조는 요소 대치에 안 쓰이고 검색 단계에만 쓰인다.

7/23 기록은 「장식 요소는 유지하고 내용 관련 요소만 대치」다.

§10

소유와 순서

덱 p.21–23
구간담당
단어장 v7 정의와 유지김수현
Summary 생성기스키마 정원석 · 생성 실무 허재영, 황현진
시멘틱 쿼리 추출 LLM · 컴포넌트 태깅황현진
태깅 결과 수신·검증·적재류민 → 박지우
노드 분류와 카테고리별 속성신영빈 · 류민
I.I.S. (4단계)류민 덱 시점 정지
시그니처·랭킹·대치 계산 (comp-sign)이석
Visual Summary 규약정원석
검색과 대치 실행최운식 (BE)

layouts 태깅은 BE 로 가지 않는다. RAT pod 내부용이고 검색에는 컴포넌트 태깅만 쓴다.

덱이 각자에게 물으려던 것

강창석님

  • dataset 을 DataViz Matrix 로 바로 넘길 수 있나 (어댑터 실측)
  • nested_scope 를 concentric_rectangles 로 볼 수 있나
  • 스마트 다이어그램 32종 중 2단계에 열 것이 있나

이석님

  • semantic 만 빼고 검색·대치가 되나. toggle 이 있나
  • 세 축 정렬을 언제 누구와
  • rankCompCandidates 위계 가중치 A/B
  • 41종 fallback 순서 검토

류민님

  • I.I.S. 재개 시점
  • tree children → Graph relations 규칙
  • 카테고리별 속성 목록 초안 리뷰

허재영님

  • Venn 라벨 오류 프롬프트 225건 중 148건이 오라벨
  • entity.components[] 생성 시점
  • 평가셋 38 중분류 확장

덱 시점의 급한 순서 2026-08-02 기준

  1. C-1 모듈 버전 2.0 BE 정책 협의
  2. C-2 semantic tag 데이터 흐름 공유
  3. C-6 태깅 증량분 재전달 9만 → 16만
  4. C-7 컴포넌트 분포 재측정
  5. I-2 세 축 정렬
  6. I-6 위계 가중치 A/B
§11

그 뒤 3주에 바뀐 것

2026-08-04 → 08-26 SSoT 대조

덱은 3주 전 사진이다. 아래 대조표는 손으로 쓴 것이고, 그 아래 두 표(DASHBOARD.md 로드맵·절별 잔여)와 §6 의 변경 12건은 mordor-wiki 원문에서 자동 동기화된다 — 원본이 바뀌면 sync-sources.py 가 낡음을 잡아낸다.

로드맵 5단계, 지금 어디까지 왔나

단계 무엇이 바뀌는가 목표 시점 지금 상태
1단계 (현행)Markdown Summary, 임베딩 검색지금운영 중, 변동 없음
2단계컴포넌트에 semantic tag2026-08-18 사실상 스킵2026-08-07 확정. 4단계로 직행
3단계YAML + structure 검색—실행하지 않음 (2026-08-06 Cancelled)
4단계RLSC node 태그로 정확한 범위 특정9월 말 dev/stg, 10월 중순 production 판정PoC 진행 중. 질의 갈래 Eregion 동작, I.I.S. PoC 대행 생산 (D-5 닫힘)
5단계node 에 semantic category 속성까지미정 (MOR-1926 PoC 결과에 따라 4단계를 건너뛸 수도 있음)T-7 v1 코드 있음, 정확도 검수 미완

↻ 로드맵 5단계 현재 상태 · DASHBOARD.md — 원본에서 자동 동기화

덱이 열어 둔 것지금근거
B-24 type 을 41종으로 좁힐지 49종으로 열지 열림 닫힘 49종으로 확정. 페이지 역할 4종은 어휘에 넣고, 지도 4종은 capability 성립 불가로 표시 2026-08-06 정원석 · MOR-1909
B-18 꾸밈구조 규약 표기 열림 닫힘 키는 decoration, page 수준도 연다. 1단계에서 생성기는 안 채운다 덱 당일 2026-08-04 규약 2.7절에 반영
B-22 장식 role 표식을 색인으로 넘기는 경로 끊김 아직 열림 — §9 의 끊긴 구간이 그대로다 MOR-1935
B-25 대분류를 없애고 중분류만 남겨도 되나 아직 열림 B-24 와 별개 항목으로 남았다 허재영 2026-08-04 제기
fallback 엣지 55개, 최대 두 칸 개정 45종 · 엣지 128개, 칸 수 상한 폐지. 근접도 순서만 지키면 몇 칸이든 capability-table.md 2026-08-17
capability 41행 확장 45행 (41종 확정 + PageNavigation 4종은 성립 조건 미정, C-4 대기) capability-table.md 범위 절
「선택 속성」한 열에 내용과 표현이 섞여 있다 해결 선택 내용 / 속성 두 열로 분리. fallback 때 내용은 옮기고(P3·P7) 표현은 버린다(P2) 2026-08-23
I.I.S. 정지 — 류민, 2026년 6월 중순부터 막힘 우회 기다리지 않는다. PoC 에서 같은 출력을 대행 생산하는 것이 4단계 실행 경로 (D-5 닫힘) 2026-08-22 DASHBOARD 4절
급한 순서 1위 = C-1 BE 정책 협의 재편 실행 1순위는 I-8 평가 pool bake. 그 다음 I-7+I-9(속성 projection), I-2(대치 contract) 2026-08-22 PoC 우선순위
— 신규 B-30 measure↔matrix projection 규칙(P9·P10) 미정 — Gauge↔PictogramChart fallback 이 여기 걸려 있다 2026-08-17 열림
— 신규 B-27 도착의 개수 상한을 넘을 때 규약 5절 1번(후보 탈락)과 P8(접기)이 같은 상황에 답이 둘 MOR-1934

절별 남은 일

TODO.md 는 할 일을 아홉 절(A~J)로 나눈다. 품질을 좌우하는 것은 I절(내용 대치 contract) 이고, 그것이 §2 의 BAD 85% 구간이다.

절 무엇을 다루는가 마감 남은 것
A규약 확정2026-08-074건
B규약 열린 결정 (전체 29건)A 에 종속17건
C2단계 배포사실상 스킵 (2026-08-07)5건
D스쿼드 차원에서 정할 것각각 다름2건 (D-4, D-6)
E7/24 회의 후속미정3건
F사후 검증 (마감 후로 미룸)마감 후2건
G최근 해소된 것—D-5 등 기록
H문서 정합 백로그—3건
I내용 대치 contract미정8건
J생성 모델 파인튜닝착수 전8건

↻ 절별 남은 일 · DASHBOARD.md — 원본에서 자동 동기화

새로 생긴 것 — 생성 파이프라인 실측

덱에는 없던 축이다. 2026-08-24 싱크에서 mastra 기반 생성 파이프라인의 첫 실측이 공유됐다. 평가셋 50건 × 3회, 모델 gpt-5.6-luna, 재시도 없음.

항목split — 정의를 tool 로 받아 거른다inline — 정의 45종 전량 주입
규약 통과49~50 / 5049~50 / 50
라벨 정렬21~25 / 5019~20 / 50
1,000건 비용$3.36$2.19
지연 중앙값8,894 ms6,741 ms

규약 통과는 잡음을 넘었다

값의 타입 규칙과 「스키마에 없는 키를 만들지 않는다」규칙을 넣기 전 37/50, 넣은 뒤 49~50/50. 케이스 단위 흔들림이 10~18/50 이므로 이 상승은 흔들림보다 크다.

라벨 정렬로는 갈래를 못 고른다

split 이 3회 모두 앞섰지만 150 시도 기준 46% 대 39%, 차이 7.3pp. 비용은 1.53배다. 「다름」23건 중 모델이 확실히 틀린 것은 10건 남짓이고, 그 다수가 Enumeration.List 로 물러선 경우다.

카테고리 우선순위도 P0~P2 로 재편됐다 (2026-08-21 김수현). P0 는 10월 배포에서 잘 되어야 하는 범위이고 UX 의 유저 프리셋 버튼과 같은 범위다. 역제안 대상으로 지목된 넷은 CombinedResult · ProblemSolution · BigNumber · SectionDivider. 「잘 되어야 한다」의 판정 기준은 아직 비어 있다.

§12

원문 지도

먼저 볼 것 둘은 규약(spec/schema-v0.5.md)과 할 일 SSoT(TODO.md)다. 나머지는 필요할 때 찾아 들어가면 된다.

문서무엇
spec/schema-v0.5.md 규약 SSoT. 0절 v0.4→v0.5 변경 12건 · 2절 스키마 · 5절 fallback 규칙 · 9절 열린 결정
TODO.md 할 일 A~J 아홉 절. B절이 규약 열린 결정 29건의 SSoT
DASHBOARD.md 진행 현황 요약판. 로드맵 5단계 상태 · 절별 잔여 건수 · 병목 셋
spec/capability-table.md 45종 성립 조건 · 선택 내용/속성 · fallback 순서 · 엣지 128개 projection
design/decoration-model.md 꾸밈구조 설계 SSoT — §8 의 근거
design/pipeline-flow.md 전체 흐름
design/content-binding-contract.md 내용 대치 구간 contract — I절 8건의 근거
reference/semantic-taxonomy-v7.md 단어장 v7 49종
spec/schema/…0.5.schema.json 기계 판정용 SSoT. TypeScript 타입과 zod 는 여기서 나온 파생물
meetings/2026-08-24-…sync.md 최신 생성 파이프라인 실측 · I.I.S. 골든셋 · P0 재편 — §11 의 근거
reference/2026-08-04-visual-summary.pdf 이 페이지의 원본 덱 24쪽 (로컬)

저장 위치

github.com/miridih/mordor-wiki → projects/mordor/visual-summary/. aippt-prisonbreak 를 클론했다면 docs/ submodule 이 같은 저장소다 — git submodule update --init docs 후 docs/projects/mordor/visual-summary/. GitHub 계정이 없으면 Confluence 발행본으로 공유한다.