Visual Summary 규약 명세

원문 README.md GitHub 에서 보기 38 KB 원문 제목 「Visual Summary 프로젝트 허브 (내용시각화 Summary 고도화)」

이 문서의 역할 내용시각화 Summary 고도화의 프로젝트 허브다. 로드맵, 고정할 용어, semantic tag 분포, 마일스톤별 범위, I.I.S. 를 한곳에 모은다. 세부 스펙과 일정은 각 티켓과 문서를 인용한다. 이 폴더가 SSoT이다. Confluence 원본은 2026-08-01 부터 보존 전용이다 (아래 0절). 오너 정원석 (MORDOR) · 상태 DRAFT · 최종 갱신 2026-09-05 (D-6 — semantic tag 용어를 Semantic Component Category로 확정) 관련 spec/schema-v0.5.md 규약 · TODO.md 할 일 · MOR-1923 Artifact · MOR-1773 (Done)

먼저 볼 것 셋 PoC 가 무엇이고 어디까지 왔는지는 plan/poc-guide.md, 모듈별 구현 상태와 집중 우선순위는 plan/poc-module-map.md, 규약은 spec/schema-v0.5.md, 할 일은 TODO.md 다.

이 프로젝트를 처음 본다면 plan/poc-guide.md 하나만 읽으면 전체가 잡힌다. 왜 만들었는지, 입력에서 판정까지 무엇이 어떤 순서로 도는지, 어디까지가 실물이고 어디부터가 대행인지, 어떤 정책을 왜 정했는지, 지금 수치가 얼마인지, 무엇이 남았는지가 그 문서에 있다.

통합 PDF (visual-summary-overview.pdf) 인쇄와 통독용 스냅샷이다. 최종 파일은 report/pdf/visual-summary-overview.pdf. PDF에 바로 들어가는 원고는 report/sections/ 의 01-overview.md 부터 06-examples.md 까지 여섯 개다. 원문 SSoT(README.md, TODO.md, spec/, design/, plan/)가 바뀌면 이 파일들을 고친 뒤 report/build/build.py로 PDF를 다시 만든다. 절차와 다이어그램 소스는 report/README.md. 이 PDF와 sections/ 는 파생물이고 SSoT가 아니다.

이 문서 훑기

0. 문서 구성#

폴더를 장르로 나눴다. 규약은 spec/, 왜 그런가는 design/, 외부 사실의 사본은 reference/, 계획은 plan/, 도입 판단에 쓰는 실측은 evaluation/, 대체된 판은 archive/ 다.

핵심 링크 MOR-1923 Artifact (2026-08-06 신설, 실행 트랙의 상위) / MOR-1773 규약 정의 (Done) / 마일스톤 MOR-1774 (2026-08-07 사실상 스킵, 8/18 폐기) MOR-1775 (Cancelled) MOR-1776 (Artifact 하위, Subtask [4-1]~[4-15]) / Visual Summary 스펙 인덱스

0.1 Confluence 에서 이 저장소로 옮긴 경위#

2026-08-01 부터 이 저장소(miridih/mordor-wiki)의 문서가 SSoT다. Confluence 내용시각화 Summary 고도화 허브는 갱신을 멈추고 기록으로만 보존한다. 그 페이지에는 이관 사실을 comment 로 고지해 두었다.

이관은 2026-07-31 #mordor스쿼드 공지를 따른다. 이유는 둘이다. Confluence 는 MCP 로 갱신할 때 결과가 불확실하고, AI 에게 SSoT 를 컨텍스트로 넣기에도 repo 쪽이 낫다.

1. 로드맵#

Summary 고도화는 아래 단계로 간다. 단계마다 바뀌는 건 네 가지다. Summary 형식, 검색 방식, 태그를 어디에 다는가, 그리고 그 태그가 무엇을 가리키는가이다.

2단계를 사실상 건너뛰기로 한 경위 (2026-08-07 확정) 2026-08-03 에 내용시각화 제품의 8/25 production 배포가 취소(연기)로 정해지면서, 2단계 배포(MOR-1774)의 8/18 마감이 이 연기에 포함되는지가 미정으로 남아 있었다. 이 질문을 MOR-1939가 승계했고, 2026-08-07 김수현님이 Visual Summary 발행본 Confluence 코멘트로 답했다. 8/18 마감은 이 연기에 포함된다. 8/18 은 폐기하고 재조정한다. 새 날짜는 아직 안 나왔다. 같은 자리에서 D-2(List 편중 81.1%를 그대로 두고 2단계를 낼지)도 답이 나왔다. 2단계를 안 하고 4단계로 직행하므로 결정할 것이 없다. List 편중 대응은 4단계 fallback map(MOR-1909)으로 넘어간다. MOR-1774 티켓 자체는 MOR-1775처럼 Jira 상 Cancelled 로 전환되지는 않았다(2026-08-08 기준 Draft, due date 필드도 8/18 잠정 유지). 다만 실행 방향은 위 결정으로 사실상 스킵이다. due date 필드 갱신은 새 날짜가 나오는 대로 반영한다.

4단계를 단독 단계로 건너뛰고 5단계로 직행하기로 했다 (2026-09-08 확정, 정원석) 결정은 #mordor스쿼드 스레드에서 났다. 같은 날 세 대화가 이어졌다. (1) 15:21 허재영이 "4단계 바운더리까지만 깎아 두고 있었는데 5단계 프로퍼티 깎는 체계를 구축하겠다"고 밝혔다 (Slack). (2) 16:54 정원석이 이석, 홍지혜와의 구두 논의를 공지하면서 검색·대치 PoC 에 쓸 컴포넌트 풀을 I.I.S. (Semantic Component - Structure and Property) 로, 즉 경계와 속성을 한 묶음으로 10만 건 추출한다고 적었다(실행 허재영) (Slack). (3) 17:46 허재영이 MOR-1776 하위의 정원석 담당 티켓을 닫거나 나누자고 제안했고, 17:51 정원석이 **"4단계 관련해서는 cancel 하고, 문서상으로 결정된 것들 최신화 하겠다"**고 답했다 (Slack). 같은 스레드에서 황현진과의 PoC scope 조정(Complexity-3-Containment 보류, 1-Single·2-Juxtaposition 집중)도 함께 정해졌다.

어떻게 하기로 했나 노드에 태그만 다는 단계를 따로 완주하지 않는다. 경계(I.I.S. Semantic Component Boundary)와 속성(I.I.S. Semantic Component Property)을 한 추출 묶음으로 뽑고, 검색과 대치도 노드 단위 경로로 바로 붙인다. 이미 실행이 그 방향으로 가 있었다 — 로컬 파일럿에서 경계 4,764건·속성 3,955건을 뽑았고(2026-09-06, TODO.md K-10), 그 위에 노드 검색 엔진을 플레이그라운드에 배선했다(2026-09-07, K-9). 후속은 속성 추출 평가(MOR-2381)와 경계·속성 10만 건 추출(MOR-2415)이다. 두 검색 경로는 서로 폴백하지 않는다(정원석 확정, K-9).

Jira 반영 상태 (2026-09-14 조회) 4단계 실행 티켓 여섯이 Cancelled 다 — MOR-1924, MOR-1925, MOR-1926, MOR-1927, MOR-1929, MOR-1936. 스킵 여부를 판정하기로 했던 MOR-1926 자체가 Cancelled 이므로, 이 결정은 그 PoC 실측 없이 났다. 마일스톤 MOR-1776 은 아직 In Progress 이고 due date 도 2026-09-30 그대로다 — 아래 "9월 말 dev/stg, 10월 중순 production 판정"이 5단계 기준으로 그대로 유지되는지는 아직 답이 없다.

3단계를 건너뛰기로 한 이유 7/24 회의에서 정리됐다. 3단계에서 개발하는 내용 대치 로직이 4단계에서는 버려질 수 있어서, 3단계를 건너뛰고 정보가 확실한 4단계로 바로 가는 편이 대치 로직의 불확실성이 적다고 봤다. 다만 스킵 여부는 대치 로직 관점에서 한 번 더 확인이 필요하다.

4단계와 5단계로 쪼갠 이유 원래 4단계였던 것을 둘로 나눴다. node 에 태그를 다는 데까지는 빠르게 갈 수 있고, property 주입(예: 스텝의 연도 표기)은 복잡도가 높은 데다 다이어그램처럼 특정 유형에만 붙을 확률이 높다. 4단계만으로도 제품단 효과가 나므로 우선 4단계에 집중하고, 5단계 실행 여부는 나중에 정한다. 이 판단은 2026-09-08 에 뒤집혔다 — 위 문단대로 4단계를 단독으로 완주하지 않고 5단계로 직행한다. 쪼갠 이유 자체는 기록으로 남긴다.

8/4 회의록 표현과의 대응 (2026-08-06 정원석 확인) 회의록의 "core component 경계 정의"는 4단계의 node 태그와 같은 말이다. node 에 태그가 붙으면 곧 core component 의 경계가 특정된다. 회의록의 "fallback 시 속성 호환"은 5단계다. tagged node 에 semantic category 속성을 붙이고 그 category 고유의 props 를 다는 것이 속성 호환의 전제다. 두 문서의 서술은 같은 것의 다른 표현이고 정의 충돌이 아니다.

단계를 나누는 진짜 이유 태그를 컴포넌트 단위로 다는 한, 그 태그가 무엇을 가리키는지 두 경우를 구분할 수 없다. root node 자체가 그 타입이라 붙은 것인가, 하위 어딘가에 그 타입의 node 가 있어서 컴포넌트 전체가 받은 것인가.

2단계부터 3단계까지는 이 모호성을 안고 간다. 4단계에서 어느 node 부터가 그 semantic tag 에 해당하는 layout container type 인지 특정되면 그때 범위가 정확해진다.

실데이터에서 이것을 읽을 수 있다. 한 컴포넌트에 태그가 최대 4개까지 붙는다(UNICORN-77432). 예를 들어 design_object_id 4757227 에는 Comparison Table, Hierarchical Tree, List, Highlighted Message 넷이 함께 붙어 있다. root 가 이 넷을 동시에 가질 수는 없으므로, 하위에 여러 타입의 node 를 품고 있다는 뜻이다. 복수 태그가 나온다는 사실 자체가 두 번째 경우가 실재한다는 증거다.

7/21 체크인 결정 다이어그램 계열 내용시각화를 스마트 다이어그램이나 스마트 블록으로 갈지, 기존 RLSC 추출로 갈지 논의한 결과 앞단(Summary 생성, 검색 조건 정의)은 기존 RLSC 방식으로 먼저 간다. 두 방식이 앞단에서는 거의 같고 스마트 시리즈의 표현 품질이 아직 검증되지 않았기 때문이다. 스마트 시리즈는 품질이 확인되면 유형별로 전환을 검토한다.

2. 용어#

회의와 문서가 같은 말을 같은 뜻으로 쓰도록 고정한다.

용어 변경 (2026-09-05 확정, 정원석, D-6) semantic tag 대신 Semantic Component Category 로 부른다. 과거 RLSC Role v1.0 의 Role.Component.* 와 유사한 목적의 값을 RLSC tree 안 node 마다 property 로 심는 것과 같기 때문이다.

'property / 속성' 표기 규칙 (2026-08-29 고정)#

이 말 하나가 넓은 뜻과 좁은 뜻으로 함께 쓰이고 있었다. 2026-08-23 에 5단계 산출물을 둘로 넓히면서 모듈 이름은 그대로 두기로 했기 때문이다(1.0.1절). 그래서 표기를 아래로 고정한다. 맨 이름 '속성'이나 'property' 를 단독으로 쓰지 않는다.

• params 와 properties 는 같은 어휘를 쓰지만 같은 것이 아니다. 어휘는 둘 다 capability 의 reads.params(선택 속성 열)이고, 한쪽은 요구(이렇게 그려 달라)이고 다른 쪽은 실측(이 컴포넌트는 이렇게 그려져 있다)이다. 둘을 맞대는 것이 T-8 이다.
• structure 라는 낱말도 두 층이다. 질의 쪽은 내용이고, 색인 쪽은 그 내용을 어느 노드에 넣을지의 대응표다. 색인 쪽을 가리킬 때는 반드시 구조 대응 또는 iis_semantic_component.structure 로 적는다.
• 넓은 뜻은 한 자리에만 있다. 5단계 국면 이름 I.I.S. (Semantic Component Property) 의 'Property' 는 위 오른쪽 열 두 칸을 합쳐 부르는 이름이다. 이 이름은 줄이지 않는다. "Property 모듈", "속성 추출기" 로 줄이면 좁은 뜻과 충돌한다. blueprint 6절의 작업 이름 T-7 시맨틱 컴포넌트 속성 추출기 도 실제로는 두 벌을 다 내므로 넓은 뜻이다.
• '질의' 도 같은 종류의 겹침이 있다. 좁은 뜻은 질의 변환기(query.ts) 산출물이고, 넓은 뜻은 색인 쪽과 대비하는 진영 이름('질의 쪽')이다. 생성기 산출물 자체를 가리킬 때는 Visual Summary 라고 적는다. 복잡도 레벨처럼 생성 단계의 성질을 말할 때 '질의'라고 쓰면 변환기 뒤의 것으로 읽힌다.
• property projection(T-8)은 좁은 뜻이다. 옮기는 것은 params/properties 뿐이고, 내용을 옮기는 structure projection(P1~P8)과 다르다.

헷갈리기 쉬운 셋

첫째, semantic tag(의미 분류)와 Layout Container type(물리 배치, HStack/VStack/Grid)은 다르다. 단어장에 배치명과 겹치는 라벨이 있어 헷갈리기 쉽다. 다만 단어장 v7 이 2단계 배포 이후 또 바뀔 수 있으므로 지금은 capability 규약을 확정하지 않는다.

둘째, Content Archetype(이 페이지가 문서에서 어떤 역할인가, 표지/목차/본문/마무리)과 semantic tag(이 콘텐츠가 어떤 의미 구조인가)는 서로 다른 것을 분류한다. 지금 실데이터에는 이 둘이 섞여 있다. 현재는 Page-level, Component-root-level, Node-level 세 층위의 semantic tag(visual category)로 나눠 볼 수 있다.

셋째, 색인 쪽과 질의 쪽도 다르다. Search Signature v2 는 컴포넌트를 색인하는 쪽이고, Summary 의 structure 는 사용자 입력을 질의로 만드는 쪽이다.

2.1 포맷: YAML 로 확정 (초안)#

결정 (2026-08-01, 초안 확정, 정원석) 표면 형식은 YAML 로 간다. KDL 은 채택하지 않는다.

이 결정이 정하는 것은 하나다. LLM 이 무엇을 써 내는가. 그 답이 YAML 이다.

스키마와 직렬화 형식은 다른 문제다. 의미 스키마(필드, 필수 조건, 유형, 대체 규칙, 버전 규칙)를 먼저 확정하고, 값의 validation 은 YAML 을 JSON 으로 변환한 뒤 진행한다. LLM 은 YAML 을 직접 생성한다(규약 3절 생성 메커니즘, 2026-08-02 정정). 이유는 추론 속도다. YAML 은 JSON 보다 구두점 토큰이 적어 같은 내용을 더 적은 생성 토큰으로 쓴다. JSON 으로 생성한 뒤 YAML 로 직렬화하면 이 이득이 없으므로 쓰지 않는다.

왜 YAML 인가#

2번은 되돌리는 성격이다. 2026-07-16 회의에서 이석님이 KDL 을 제기하며 다시 열렸던 항목을 원래 자리로 되돌린다.

3번은 전환 조건도 함께 정한다. 생성 안정성에서 뚜렷한 차이가 나올 때만 전환할 값어치가 있는데, 지금 근거로는 그 차이를 기대할 이유가 없다.

'초안 확정'이 뜻하는 것#

아래 실측 설계는 지우지 않고 사후 검증으로 남긴다. 실측 결과가 YAML 을 뒤집으면 그때 재검토한다. 다만 뒤집으려면 위 3번대로 KDL 이 뚜렷하게 앞서야 한다.

정렬이 필요한 곳 KDL 을 제기한 것은 이석님이다(2026-07-16 회의, 회의록). 왜 안 골랐는지 위 근거를 전달하고, 이견이 있으면 사후 검증 범위를 같이 정한다.

판단 기준 (7/24 확정) 사람이 읽고 쓰기 좋은지로 고르지 않는다. 이 산출물은 사람이 손으로 쓰는 게 아니라 LLM 이 생성한다. 따라서 기준은 LLM 이 그 형식으로 뽑을 때 결과가 얼마나 안정적인가이다. 스키마 위반율, 들여쓰기나 따옴표 때문에 깨지는 비율, 같은 입력에서 같은 결과가 나오는 정도를 본다.

사전 조사 결과#

KDL 과 YAML 을 LLM 생성 안정성으로 직접 비교한 공개 실측 자료를 찾지 못했다. YAML 쪽은 데이터가 풍부하고, KDL 은 LLM 벤치마크에 거의 등장하지 않는다. 확인한 것은 넷이다.

여기서 셋을 읽는다.

YAML 의 알려진 취약점은 둘이다. 들여쓰기가 토크나이저에 민감해서 스트리밍이나 긴 출력에서 잘못된 들여쓰기를 만들기 쉽다. 그리고 암묵적 타이핑 때문에 문자열이 boolean 이나 숫자로 재해석된다(예: no 가 false 로).

재현성은 포맷이 아니라 디코딩이 정한다. temperature 0 에서 0.2 사이에서 구조 준수율이 높지만, temperature 0 이라도 완전 결정론은 보장되지 않는다. 재현성은 샘플링 설정과 constrained decoding 으로 확보하는 것이 정석이다.

모델 역량 격차가 포맷 효과를 압도한다. 프론티어와 오픈소스 사이 21%p 다. 확인한 소스 여럿이 이 결론에서 일치한다.

그래서 KDL 이 불리하다는 것은 사전 확률이지 실측이 아니다. 학습 데이터 노출량이 YAML 이나 JSON 대비 극히 적고, 생성 안정성은 문법의 우아함보다 학습 코퍼스 내 빈도에 좌우된다는 점에서 나온 추정이다.

실무적 결론 공개 사례로는 우열을 가릴 수 없다. 사전 확률(YAML 우세)로 초안을 확정하고, 자체 실측은 사후 검증으로 돌린다.

YAML 을 골랐으므로 감시해야 할 것 "파싱은 됐는데 타입이 뒤바뀐" silent corruption 을 파싱 실패와 별도로 센다. 조용한 손상은 실패로 보이지 않아서, 안 세면 없는 것처럼 보인다. 생성기를 만들 때 이 지표를 처음부터 넣는다.

사후 검증 설계 (실측)#

초안 확정을 뒤집을 근거가 있는지 나중에 확인하는 용도다. 다른 마감이 걸려 있지 않을 때 돌린다.

1. 같은 스키마 N개 케이스를 YAML, KDL, JSON 각각으로 생성한다. JSON 을 비교군으로 넣는 이유는 문헌 다수가 애초에 JSON 을 권장하기 때문이다(constrained decoding 이나 JSON mode 로 스키마 위반을 원천 차단할 수 있다).
2. 지표는 넷이다. 파싱 실패율, 스키마 위반율, silent corruption 율(파싱은 성공했는데 의미가 변질된 것), 재현성(temperature 0 에서 같은 입력을 k회 반복했을 때 출력 일치율).
3. 프론티어와 오픈소스 두 티어 이상을 교차해, 포맷 효과가 모델 역량에 가려지지 않게 한다.

출처 StructEval (arXiv 2505.20139), Notation Matters: Token-Optimized Formats benchmark (arXiv 2605.29676), Beyond JSON: Picking the Right Format for LLM Pipelines, Best Structured Prompt Formats for LLMs Ranked (MightyBot), Which LLMs Actually Produce Valid JSON?, Which Table Format Do LLMs Understand Best?, KDL Document Language (official), python-cuddle, Does Temperature 0 Guarantee Deterministic LLM Outputs?

3. Semantic Tag 분포 (설계의 실증 근거)#

• 출처 design_object_semantic_tags, 2026-07-22 적재
• 모수 design object 83,771건
• 조사일 2026-07-24

이 절은 색인 쪽 분포다. 질의 쪽과 섞으면 안 된다. 이 절은 색인 쪽(이미 존재하는 컴포넌트에 어떤 태그가 붙어 있나) 분포다. 질의 쪽(사용자가 어떤 구조를 요구하나) 분포는 semantic-taxonomy-v7.md 3절에 따로 있다.

카테고리	색인 쪽	질의 쪽
List	81.1%	31.96%
ListingTable	0.5%	15.08%
Steps	2.4%	10.92%
ComparisonTable	0.2% 이하	7.24%

사용자가 원하는 구조는 다양한데 대치할 풀이 리스트에 쏠려 있다. 아래 'List 편중' 논의의 무게가 여기서 나온다.

핵심 지표#

Category 분포 (design object 기준)#

상위 8종(List 와 준리치 7종)이 전체의 94.5% 이고, List 하나가 81% 이다.

이 분포를 설계에 어떻게 쓰는가#

방침 규약을 정할 때 샘플 데이터로 별도 검색 실험을 크게 돌리지 않는다. 지금 붙어 있는 컴포넌트 데이터의 분포를 근거로 설계하고, 실험은 꼭 필요한 지점(포맷 실측 등)에만 국한한다. 이유는 두 가지다. 하나는 2단계 배포 전에 규약을 확정해야 해서 대규모 실험을 돌릴 시간이 없다는 것이고, 다른 하나는 아래에서 보듯 분포만으로도 설계 판단에 필요한 답이 대부분 나온다는 것이다.

분포가 말해 주는 것은 세 가지다.

첫째, 실제 검색 풀이 두터운 건 List 와 BigNumber 둘뿐이다. VennDiagram, HierarchicalTree, NestedScope, Pyramid 는 각 164건 이하이고, Gauge, StackedBarChart, ComboChart 같은 데이터 차트는 각 51건 이하다. 8만 건 중 51건이면 검색이 거의 못 맞힌다. 그러니 이 카테고리들의 성립 조건을 엄격하게 걸면 후보가 0이 되어 결국 List 로 fallback되기만 한다.

이 근거로 2026-08-02 에 성립 조건의 정의를 좁혔다. 조건에는 '그 종류로 배치가 불가능해지는 것'만 남기고, 나머지는 기본값을 가진 선택 속성으로 옮겼다. 41종 전량은 capability-table.md, 판단 근거는 projection-model.md 에 있다.

둘째, 복수 태그가 0.3%(260개)뿐이라는 것은 지금 태깅이 컴포넌트 root 기준으로만 붙고 있다는 뜻이다. 그런데 그 260개는 한 컴포넌트가 하위에 여러 타입을 품고 있다는 뜻이다(1절의 design_object_id 4757227 예시). 즉 node-level tag 없이는 이 260개를 제대로 쓸 방법이 없고, 4단계가 필요한 이유가 여기서 다시 확인된다.

셋째, List 편중 81%를 그대로 두고 2단계를 내면 태그를 붙여도 검색 결과가 지금과 크게 달라지지 않는다. 이것이 TODO.md D-2 이고, 7/24 회의에서 "리스트를 먼저 제품화한다"로 이어진 판단의 근거다.

주의: 이 스냅샷은 곧 바뀐다. 유효 컴포넌트 v3.4 조건 6(중복 제거)에서 FLCS 비교가 빠져 태깅 대상이 적게 집계됐다. FLCS 를 계산해 원래 기준으로 되돌리면 태깅 대상이 약 9만에서 약 16만(+79%)으로 늘어난다(7/24 이강윤님 공유).

절대 수치는 늘겠지만 category 별 비율은 크게 흔들리지 않을 것으로 보고 설계에 쓴다. 증량분이 반영되면 이 절을 다시 측정해 갱신한다 (TODO.md C-7).

4. 마일스톤 상세#

1단계, 현행#

Markdown Summary 에 임베딩 검색. 컴포넌트는 변동 없음. 별도 티켓 없다.

2단계, 시멘틱 검색 v2 Phase 1 (MOR-1774, 사실상 스킵)#

2026-08-07 확정, 사실상 스킵. 8/18 마감은 폐기됐고 재조정 없이 4단계로 직행한다. 근거와 경위는 1절 로드맵 표 아래 문단에 있다. 아래 진행 상황은 태깅·적재 인프라 자체는 4단계에서도 그대로 쓰이므로 기록으로 남긴다.

지원 범위는 이번에 태깅되는 카테고리 전부다. steps 는 태깅 작업 순서일 뿐 지원 범위가 아니다. 47종이 붙는데 검색이 일부만 받으면 나머지는 붙여 놓고 안 쓰는 셈이 된다.

알려진 한계 태그가 컴포넌트 root 를 가리키는지 하위 node 를 가리키는지 구분되지 않는다(1절). 검색이 알 수 있는 건 '이 컴포넌트 어딘가에 그 타입이 있다'까지다. 4단계에서 해소된다.

범위 입력과 페이지와 컴포넌트를 같은 v7 단어장으로 태깅한다. 태그를 DB 에 적재하고 BE 에 넘긴다. 태그로 검색하고 순서대로 내용을 대치한다(Summary 와 RLSC 는 안 건드리는 범위). 태그가 없는 데이터는 재태깅하거나 보정한다.

확정된 것 layouts 태깅은 RAT pod 용이고 검색에는 component 태깅만 쓴다(MOR-1755). 복수 태그는 허용(최대 4개 관측), 단어장 밖 값은 불허.

진행 상황 (7/24 기준)

• 전달 형식 합의 완료. 태그가 하나든 여럿이든 문자열 배열.
• 적재 기능은 MOR-1744로 7/21 프로덕션 배포 완료(v1.28.104).
• 전달 경로는 류민 → 지우 → 운식 이다. 7/23 늦게 정리됐다. 데이터가 많아 MORDOR DB 에서 바로 처리하는 편이 낫다는 판단으로 황현진님 단계가 빠졌다.
• 7/23 적재 검증에서 design_object_semantic_tags 약 10,410건이 원본과 불일치했다. 값이 아니라 배열 직렬화(따옴표 이스케이프) 형식이 깨진 것이었고, 박지우님이 같은 날 S3 재업로드로 정리했다.

태깅 대상이 늘어난다 3절 마지막 문단 참고. 이번 프로덕션 배포는 기존 계획대로 나간다. 증량분과 시멘틱 태그 재실행분은 묶어서 약 2주 뒤 한 번에 BE 로 전달하기로 김수현님과 합의했다(7/24).

layouts 태깅 건은 닫혔다 태그 적재 컬럼은 layouts 와 design_objects 에 semantic_tags 배열로 담고 S3 object path 도 확정됐다.

한동안 "컴포넌트 태깅값만 주면 되고 layouts 태깅은 BE 에 안 줘도 되는지"가 미결로 적혀 있었으나 이미 결론이 나 있다. MOR-1755 본문 '확인 필요' 절이 이렇게 답해 두었다.

레이아웃 태깅도 있나? → 있긴한데 rat pod 에서 사용하는 데이터이며, 검색에는 쓰이지 않는다

근거 Slack 링크까지 달려 있다. 위 '확정된 것'과 같은 내용이고, 미결로 남아 있던 것은 문서 정합 문제였다 (TODO.md G절).

UNICORN-77437 은 존재하지 않는 키다. 여러 문서가 스키마와 contract 협의 티켓으로 이 키를 걸어 놨다. 7/15 번호 구간에 구멍만 남아 있어 삭제됐거나 다른 프로젝트로 옮겨진 것으로 보인다. 살아 있는 BE 티켓은 둘이고 둘 다 최운식님이다. UNICORN-77316(파이프라인에 태깅 정보 적재, Open)과 UNICORN-77328(시그니처v2에 태그 검색 적용, In Progress)이다.

관련 티켓 MOR-1741 상위 Semantic Tagging / MOR-1744 DB 적재 / MOR-1745 BE 전달 / MOR-1755 전달 프로세스 문서 / UNICORN-77318 컴포넌트 태깅 / UNICORN-77432 복수 태그 max

3단계, Summary 를 YAML 로 바꾸고 구조 정보를 검색에 쓴다 (MOR-1775, 실행하지 않음)#

범위 Summary 생성기가 YAML 로 내보내게 바꾸고, YAML 을 JSON Schema 로 검증한다. structure 를 검색 질의와 대치 계획으로 바꾸는 변환기를 만든다(같은 입력이면 같은 결과가 나와야 한다). 기존 Markdown 호환 계층을 둔다.

현재 상태 7/24 회의에서 건너뛰기로 정했다(1절). 스킵 여부 최종 확인이 TODO.md D-3 에 남아 있다.

생성기 교체는 4단계로 갔다 (2026-08-02 확정) 이 단계는 생성기 교체와 검색 로직 변경을 한 번에 하는 범위였다. 3단계를 건너뛰기로 하면서 생성기 교체만 갈 곳이 없었는데, 4단계(MOR-1776) 범위에 넣기로 정했다. MOR-1775 는 실행하지 않음 상태를 유지하고 티켓을 새로 만들지 않는다.

감수하는 것 4단계에서 생성기 교체와 node 태그와 검색 변경이 한 번에 일어난다. 품질이 떨어졌을 때 원인이 셋 중 무엇인지 가리기 어렵다. 4단계 착수 때 단계별 계측 지점을 설계로 보완한다 (TODO.md C-3).

오너 스키마는 정원석, 생성 실무는 규약이 확정된 뒤 허재영님과 황현진님.

4단계, RLSC node 태그 (MOR-1776)#

범위 I.I.S. 로 신규 layout type 을 page 단위로 태깅하고 추론한다. RLSC 스키마를 확장하고 node 마다 태그를 단다. 피라미드 방향이나 순서 같은 레이아웃 고유 속성은 RLSC page 단위 추론에서 뽑는다. 여기에 Summary 생성기의 YAML 전환이 더해진다 (2026-08-02, 원래 3단계 범위였다).

여기서 해소되는 것 태그가 컴포넌트 어디를 가리키는지가 특정된다. 검색과 대치를 해당 node 범위에 정확히 걸 수 있다.

관련 티켓 (RAT pod, 본편은 2026-06 중순 이후 정지) MOR-1425 I.I.S. skeleton / MOR-1448 Layout Type 편입 / MOR-1426 차트 I.I.S. / MOR-1427 텍스트 role I.I.S. Visual Summary PoC 는 재개를 기다리지 않고 같은 출력을 src/lib/visual-summary/iis/ 에서 대행 생산한다 (TODO.md D-5, 2026-08-22).

실행 티켓 (2026-08-06 재편) 상위 Artifact 는 MOR-1923 이고, 이 마일스톤 하위에 Subtask [4-1][4-15] 가 있다. [4-1][4-3](MOR-19091911)은 생성기 쪽(허재영, 황현진), [4-4][4-9](MOR-19241929)는 변환기 스펙, capability 상수, 대치 PoC, 계측 설계, 평가셋, 판정 지표, [4-10][4-15](MOR-1932~1937)는 내용 대치 contract 와 열린 결정 해소다. 티켓 대응표는 plan/jira-artifact-blueprint.md 8절이다.

PoC 코드와 화면이 세워졌다 (2026-08-12). 질의 갈래 전체(생성 → 검증 → 확정 → 검색 질의 → 실색인 검색 → 대치 → 인라인 실시간 렌더)가 Eregion /visual-summary 화면에서 돈다. capability 상수(MOR-1925)와 질의 변환기(MOR-1924)의 PoC 구현, 규약 예시와 실사용 입력 실측, 구현이 임시로 정한 판단 4건은 plan/eregion-poc.md 다. Summary 생성 튜닝과 검색과 대치 고도화는 이제 시작하는 단계다.

5. I.I.S.#

I.I.S. 는 여기서 새로 만드는 개념이 아니라 이미 있는 모듈이다(원 설계 MOR-1425). 새 element 나 role, layout type 이 생겼을 때 Structuriser 를 바로 재학습하지 않고 두 단계 추출로 대응한다.

이름 (2026-08-15 정원석 확정) I.I.S. 는 하나의 모듈이 아니라 계열이다. 이 프로젝트가 필요로 하는 것은 둘이다: I.I.S. (Semantic Component Boundary)(증분 정보 구조화기, 시맨틱 컴포넌트 경계, 4단계)와 I.I.S. (Semantic Component Property)(증분 정보 구조화기, 시맨틱 컴포넌트 속성, 5단계). 속성은 경계를 포함하므로 4단계 ⊂ 5단계다. 코드 식별자는 iisSemanticComponentBoundary / iisSemanticComponentProperty (규칙: iis + 대상 + 국면). 근거와 전체 표기 규칙은 plan/node-tag-and-property-poc-blueprint.md 1절.

진행 방침 (2026-08-22, D-5 닫힘) RAT pod 본편 I.I.S. 재개를 4단계 착수 조건으로 두지 않는다. Visual Summary PoC 가 같은 출력을 대행 생산하며 경계(T-4), 노드 검색(T-5), 노드 대치(T-6), 속성(T-7)을 계속 진행한다. 대치 경로 비교는 PoC 규약 RLSC(binding.ts, 실서비스 아님) / comp-sign 4단계 / property 5단계(T-8) 셋을 목표로 하며, 같은 평가 pool bake(TODO I-8)가 선행이다. 출력 모양이 같으면 RAT pod I.I.S. 가 재개될 때 통째로 교체 가능하다. 모듈 위치와 구현 상태는 plan/poc-module-map.md 다.

지금 (증분 대응):
  ALSC → Structuriser → Old RLSC → I.I.S. → New RLSC

New RLSC 가 충분히 쌓인 뒤 (자체모델 재학습):
  ALSC → New Structuriser(자체모델) → New RLSC

로드맵과의 접점은 4단계의 node 단위 태그를 I.I.S. 가 담당한다는 것이다. 규약(MOR-1773)이 확정되면 출력 계약을 RAT pod 와 제안과 공유하되, PoC 는 그 답을 기다리지 않고 진행한다 (plan/poc-module-map.md 4절).

2·3단계:  [component] → tag: "Steps"     (컴포넌트에만. root 인지 하위인지 미상)
4단계:          [component] → tag: "Steps"
                  ├─ [node A] → tag: "LayeredDiagram"
                  └─ [node B] → tag: "Timeline"

MOR-1773 에서 정한 것 레이아웃 고유 속성은 RLSC page 단위 추론에서 뽑는다. 아래에서 위로 올라가며 클래스를 추론하는 방식은 쓰지 않는다. 클래스가 어느 영역인지는 잡을 수 있지만 그 속성이 어느 요소에 붙는지를 못 가리기 때문이다.

7/21 체크인 결정 유효성 판단을 layout container 기준으로만 보고 role page 로 보지 않아서 Structuriser 가 전체를 한 페이지로 잡고 역할을 잃는 케이스가 있다. Q3 에 I.I.S. 방식으로 RLSC 전체를 놓고 고치기로 했다.

RAT pod 본편 I.I.S. 계열 티켓 네 건은 2026년 6월 중순 이후 RAT pod 쪽에서 정지 상태다. Visual Summary 4단계는 PoC 대행 생산으로 진행하며, 본편 재개는 교체 시점의 외부 이벤트로만 본다 (D-5).

6. 할 일#

TODO.md 가 SSoT 다. 무엇을 언제 누가 하는지는 전부 거기 있다. 이 문서에는 왜 그 결정이 필요한가만 남긴다.

규약 확정은 2026-08-02 에 끝났다. 2026-08-03 에 장식과 계층 결정(B-2, B-3)이 뒤집혔고, 2026-08-04 에 규약 표기까지 반영했다 (spec/schema-v0.5.md 2.7절). 설계 의도는 design/decoration-model.md 가 갖는다.

2026-08-04 에 자기정합 검사를 돌렸다. 스키마와 capability 와 예시가 서로 어긋나지 않는지 14가지를 봤고, 그 목록은 spec/schema/README.md 에 있다. 이 검사로 결함 다섯을 찾아 고쳤고 열린 결정 둘(B-27, B-28)이 새로 열렸다. fallback 은 그래프로 못 박았다(B-26).

2단계 배포 마감은 폐기됐다 (2026-08-07 확정). 2026-08-03 에 제품 배포가 연기된 뒤(Slack) 그 연기가 MOR-1774 의 2026-08-18 까지 포함하는지가 MOR-1939로 넘어가 미결로 남아 있었는데, 2026-08-07 김수현님이 Confluence 코멘트로 포함된다, 8/18 은 폐기하고 재조정한다고 답했다. 같은 자리에서 List 편중 대응(D-2)도 "2단계를 안 하고 4단계로 직행하므로 결정할 것이 없다"로 정리됐다. 다음 주요 작업은 서머리 생성, 스마트시리즈, 조합 순이다.

2026-08-06 에 Jira 를 재편했다. Artifact MOR-1923 을 신설하고 실행 트랙을 MOR-1776 아래 Subtask [4-1]~[4-15] 로 정리했다. MOR-1773 은 Done, MOR-1775 는 Cancelled 다. 2026-08-04 회의로 목표는 9월 말 dev/stg, 10월 중순 production 판정이고, 판정 지표는 시멘틱 검색과 구조 검색의 교집합 상위 10개 품질이다. 상세는 plan/jira-artifact-blueprint.md 다.

7. 참고 문서와 티켓#

• 규약 티켓: MOR-1773 Summary 와 RLSC 공용 스키마 규약 정의
• 마일스톤: MOR-1774 / MOR-1775 / MOR-1776
• 회의록: 7/24 모르도르 추가 논의 (repo 사본: ../meetings/2026-07-24-mordor-additional-discussion.md) / 7/21 체크인
• 절차: 시멘틱 태그 전달 절차 명세 / 내용시각화 스쿼드 타임라인
• 분류 체계 배경: 내용시각화 시멘틱 강화 분류/검색 체계 정립 (canonical tag 중간 계층 설계)
• Visual Summary 원 스펙 (Confluence, 보존): 스펙 인덱스 / v0.2 / v0.3 / 요구사항 원문
• I.I.S. 티켓: MOR-1425 / MOR-1448 / MOR-1426 / MOR-1427
• 단어장 원본 시트: 시멘틱 레이아웃 단어장
• repo 관련 문서: ../rlsc/incremental-information-structuriser-blueprint.md (I.I.S.), ../valid-component/comp-signature.md (색인 쪽 contract), ../rlsc/design-topology-and-isomorphism.md (용어 SSoT)
• 이 폴더 안: TODO.md 할 일 SSoT · pipeline-flow.md 전체 흐름 · semantic-taxonomy-v7.md 단어장 전량 · markdown-summary-samples.md 현행 Summary 실사용 샘플

↑ 목차로 · 1부 머리로

원문 DASHBOARD.md GitHub 에서 보기 4 KB 원문 제목 「Visual Summary 진행 현황 대시보드」

이 문서의 역할 프로젝트 상태를 한눈에 보기 위한 요약판이다. 파생물이고 SSoT 가 아니다. 세부 근거와 결정 사유는 전부 README.md(로드맵·마일스톤)와 TODO.md(할 일)에 있고, 모듈별 구현 상태와 집중 우선순위는 plan/poc-module-map.md 가 담는다. 자동 갱신되지 않으므로, SSoT 가 바뀌면 이 문서도 같이 고쳐야 최신 상태가 유지된다. 오너 정원석 (MORDOR) · 최종 갱신 2026-09-14 (4단계 스킵·5단계 직행 확정 반영)

1. 지금 한 줄로 말하면#

규약(스펙)은 2026-08-02 에 확정됐고 현행 값은 0.5.4 다. 질의 갈래 PoC 와 I.I.S. 색인 갈래 코드는 이미 돈다. RAT pod I.I.S. 본편은 기다리지 않고 PoC 에서 같은 출력을 계속 만든다 (D-5). B절 열린 결정은 2026-09-05 에 전량 닫혔다. Week 27 PoC 는 로컬 인덱스 12,348건 위에서 자유 입력부터 렌더까지 한 번에 돈다. 노드 검색은 컴포넌트 검색과 폴백 없이 분리돼 있다. "스펙과 규모 있는 로컬 PoC 는 있고, I절 contract, 노드 검색 정확도, 프로덕션 I.I.S. 추출이 다음 병목" 으로 읽는 것이 정확하다.

모듈 지도 plan/poc-module-map.md 에 파이프라인 다이어그램, 세 가지 대치 경로, 모듈별 구현 상태, 집중 우선순위 10항이 있다.

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

로드맵의 각 단계는 Summary 형식과 검색 방식과 태그 범위 셋이 동시에 바뀌는 지점이다. 자세한 내용은 README.md 1절에 있고, 여기서는 진행 여부만 본다.

3. 절별 남은 일, 몇 건씩 남았나#

TODO.md 는 할 일을 A~K 절로 나눈다.

품질을 좌우하는 것은 I절(내용 대치 contract) 이다. 실행 1순위는 I-8(평가 pool bake) 이다. K절은 규모와 화면을 먼저 세운 것이다.

4. 지금 가장 급한 병목 셋#

첫째, 평가 pool + 사전 적재 (I-8). 로컬 색인 12,348건과 I.I.S. 파일럿(경계 4,764, 속성 3,955)이 있다. 세 경로를 같은 DO subset 에서 비교하려면 bake 정의가 남는다.

둘째, 노드 검색 정확도 (K-9-1) + 프로덕션 I.I.S. 추출 (K-11). 화면과 로컬 데이터는 있다. 판정과 프로덕션 쓰기가 남는다.

셋째, 내용 대치 contract (I-7, I-9, I-11). T-8 과 복합 구조 오케스트레이션은 규약만 있고 코드가 없다.

해소됨 (2026-09-05) B절 전량. K-1~K-8. 로컬 인덱스 12,348건.

해소됨 (2026-09-07) K-9 노드 검색 엔진 배선. K-10 로컬 파일럿 추출.

해소됨 (2026-08-22) D-5 I.I.S. 재개 대기.

해소됨 (2026-08-07) 2단계 배포 8/18 폐기, 4단계 직행.

해소됨 (2026-09-08) 4단계를 단독 단계로 완주할지. 완주하지 않고 5단계로 직행한다 (정원석 확정). 경위는 README.md 1절.

5. 남의 답을 기다리는 것 ([?])#

TODO D 절에 [?] 항목은 없다. K-11 은 권한 문제라 에이전트가 못 움직인다.

6. 일정을 시간순으로 보면#

참고#

README.md · TODO.md · plan/poc-module-map.md 모듈 지도 · plan/poc-guide.md · spec/schema-v0.5.md

↑ 목차로 · 1부 머리로

원문 TODO.md GitHub 에서 보기 95 KB 원문 제목 「Visual Summary: 할 일 목록」

이 문서의 역할 이 프로젝트에서 남아 있는 일을 한곳에 모은다. 이 문서가 할 일의 SSoT다. 각 문서에는 맥락(왜 이 결정이 필요한가)만 남긴다. 오너 정원석 (MORDOR) · 최종 갱신 2026-09-09 (I-17 신설 + capability.json 에 표 2절 필드 추가 — 허재영, 정원석 확인 대기. 직전 2026-09-05: K절 신설 — week 27 PoC 목표 가시화. B-10·B-21·B-36·D-4·D-6·F-1·A-6·C-1·C-2·C-4 닫힘, B-34·B-35·B-30 포함 B절 전량 확정 — 정원석 결정, 타인 확인 대기 없이 확정) 관련 README.md 허브 · schema-v0.5.md 규약

2026-09-05 갱신 B-34·B-35·B-30 을 닫았다 (정원석). 셋 다 "OO님 확인 대기"로 남아 있었지만 오너가 직접 결정했다.

• B-34 NestedScope 는 children 을 안 쓴다. 개수 2 이상, entities 배열 순서 자체가 안쪽→바깥쪽이고 direction(inward/outward, 기본 inward) 속성만 둔다. 9/4 정원석 제안 그대로 확정. 후속 5건(capability.ts 반영, fallback 규칙 문구 정정, 골든셋 6건 재작성, 프롬프트 지시문, I.I.S. 추출기 어휘)은 구현 작업으로 남는다.
• B-35 구표기 version: "0.5" 는 JSON Schema 패턴을 넓혀 0.5.0 으로 그대로 수용한다(마이그레이션 대신 패턴 확장). 골든셋 135행을 안 건드린다.
• B-30 measure↔matrix projection 규칙(P9, P10)은 만들지 않는다. 단일 값과 복합 데이터는 형태가 근본적으로 달라 서로 변환하면 원래 의도를 왜곡한다. KPIKeyMetric_Gauge·ProportionComposition_PictogramChart fallback 체인에서 서로를 뺐다(capability-table.md 3.2·3.4·3.5절). 2026-08-17에 plan/fallback-map-review-2026-08-13.md 가 이미 같은 결론을 냈었는데 이후 문서 동기화 중 유실됐던 것을 복원한 것이다.

2026-09-02 갱신 B-20 을 닫았다 (허재영). entity.components[] 를 어느 생성기가 채울지를 갈랐다. PoC 생성기(MOR-1910)는 L3 테스트 범위로 채운다 — 프롬프트 기본값이 이미 L3 다. 실서비스 Summary 생성기(허재영·황현진)는 아직 채우지 않는다. I-11·D-7 과 골든셋 「포함」행은 이 결정의 범위가 아니다. 버전 자리는 올리지 않는다(칸은 원래 optional). 규약 8.7절·8.8절.

지금 상태 규약은 2026-08-02 에 확정됐다(schema-v0.5.md). 마감 2026-08-07 보다 닷새 앞섰다.

2026-08-03 갱신 둘이 바뀌었다. 첫째, 장식과 계층 결정(B-2, B-3)이 뒤집혀 다시 열렸다. 초기 결정은 design/decoration-model.md 에 있고 규약 표기 반영이 남았다(B-18~B-21). 둘째, 제품 배포가 연기됐다. 김수현님이 강창석님과 정렬해 확정했고, 다음 주요 작업 셋을 서머리 생성, 스마트시리즈, 조합 순으로 제시했다 (Slack). 2단계 배포 마감 2026-08-18(MOR-1774)이 그 연기에 포함되는지는 티켓에 반영이 없어 확인이 필요하다.

2026-08-06 갱신 Jira 를 재편했다. Artifact MOR-1923 신설, MOR-1773 Done, MOR-1775 Cancelled, 4단계 MOR-1776(due 9/30)이 Artifact 하위로 옮겨졌고 실행 Subtask [4-1]~[4-15] 가 그 아래 있다. 대응표는 plan/jira-artifact-blueprint.md 8절이다. B-24 는 49종으로 닫혔다 (2026-08-06 정원석 확정, MOR-1909 에 결정 기록).

2026-08-07 갱신 MOR-1939가 8/3 부터 미결이던 질문 셋을 닫았다(김수현님, Confluence 코멘트). (1) semantic tag 없이 검색풀 증량만으로 8/25 배포하는 안은 다루지 않는다, 배포 잠정 연기. (2) judge 실행 여부는 배포 보류. (3) MOR-1774 의 8/18 마감은 이 연기에 포함된다. 8/18 은 폐기하고 재조정한다. 새 날짜는 아직 안 나왔다. 같은 코멘트로 D-2 도 닫혔다 — 2단계를 안 하고 4단계로 직행하므로 List 편중 대응은 결정할 것이 없고, 4단계 fallback map(MOR-1909)으로 넘어간다. C 절 전체와 D-2 를 이 갱신으로 정리한다.

2026-08-14 갱신 대치 결과물의 결함을 기계가 센다. 그동안 이 구간의 품질 판정은 사람이 렌더를 눈으로 보는 것뿐이라 커밋마다 다시 잴 수가 없었다. 결함 15종(나쁜 결과의 원인 넷에 1:1)을 세는 채점기와, 결함을 생성·검색·대치로 나누는 귀속(MOR-1927)과, 두 검색의 교집합 상위 10건 품질(MOR-1929)이 실제로 계산된다. PoC 전체 안내서는 plan/poc-guide.md 다 — 처음 보는 사람은 그것부터 읽는다. 실측 상세는 plan/comp-sign-bridge.md 6.2절. 기준선(실사용 입력 50건·컴포넌트 65개)이 가리키는 것 셋: 넘침이 양쪽 경로 모두 1위 결함이고 수가 거의 같아 경로를 바꿔도 안 줄어든다, 결함의 대부분이 검색 탓이다(생성 36 · 검색 466 · 대치 17), 두 검색은 맨 위에서 거의 합의하지 않는다(1위 일치 65개 중 2개). 마지막 것은 I-5 정합 논의와 MOR-1929 판정 절차 확정의 입력이다.

2026-08-12 갱신 질의 갈래 전체의 PoC 코드·화면이 Eregion 에 세워졌다 → plan/eregion-poc.md. capability 상수(MOR-1925)와 질의 변환기(MOR-1924)의 PoC 구현이 존재하고, 대치 결과를 합성기 없이 브라우저에서 실물 렌더하는 인라인 캔버스가 동작한다. 이 과정에서 B-27 과 P6 에 구현 판단이 임시로 들어갔다(도착 판정은 투영 구조로, P6 은 비교형 도착에서 열 전치 — 그 문서 4절). MOR-1934 확정 시 이 구현 판단을 함께 다룬다. 2026-08-29 갱신 (7) 생성물 둘을 다시 내보내고 자기정합 검사 14가지를 전량 다시 돌렸다. 마지막 전량 실행이 2026-08-04 이었고 그 사이 개정 다섯 번이 검사 없이 들어가 있었다(2026-08-06 병합 헤더, 2026-08-17 fallback v2, 2026-08-21 ComboChart, 2026-08-28 복합 순서, 2026-08-29 type 필수·대분류 제거·enum 45종). 고친 것 셋. (1) spec/schema/visual-summary-0.5.schema.json 을 규약 2.2절에서 다시 내보냈다 — 2026-08-06 병합 헤더 경로(structure.columns, entity.values[])가 그때까지 이 파일에만 빠져 있었다. (2) spec/schema/capability.json 에 PageNavigation 4종을 넣어 41종·엣지 123개에서 45종·엣지 131개가 됐다 — 파일 주석이 "C-4 결정 대기라 뺐다"고 적고 있었으나 그 전제는 2026-08-27 에 이미 깨져 있었다(spec/capability-table.md 2.6절: C-4 가 정하는 것은 뽑힌 뒤의 템플릿 공급이지 성립 조건이 아니다). (3) spec/yaml-examples.md 5.2절 예시가 type: Hierarchy(대분류 단독)를 쓰고 있어 0.5.2 개정 뒤 검증에 걸렸다 — 결합값 + alternatives 로 고쳤다. 검사 정의 자체도 낡아 있었다. F2(두 칸 상한)는 2026-08-17 에 상한이 없어져 폐기했고, F3 은 "종단 셋으로 끝나는가"였는데 같은 날 List 뒤에 ListingTable 을 안전망으로 덧붙인 행이 넷 생겨(List, SWOT, ProfileCard, TableOfContents) "거치거나 자신이 그 셋인가"로 고쳤다. S3·C1·F1·F4·N1 의 수치도 45종·131개로 맞췄다. 14가지 전량 통과. 실행 뒤 상태와 검사 정의는 spec/schema/README.md.

2026-08-29 갱신 (6) 꾸밈 축 값의 모양을 셋으로 갈라 확정했다 (정원석). 종전 문서가 "수치 가중치를 두지 않는다"만 적어 두어서 객체까지 함께 기각된 것처럼 읽혔다. 갈라 적는다. enum(prefer·indifferent·avoid)이 4단계와 5단계가 쓰는 것이고, 객체는 나중 단계의 자리다 — 기각이 아니라 4·5단계 범위가 아닐 뿐이고 그 단계에서 무엇을 담을지는 정하지 않았다. 수치 점수(ornament: 0.8)는 앞으로도 두지 않는다 — 값에 점수를 매기는 것이 의미가 없다고 판단했다(종전 근거인 "채점 코드를 안 건드린다"와 "entity.weight 가 다른 뜻으로 있다"도 그대로다). 그래서 열린 결정이던 "prefer 와 avoid 가 몇 점인지"는 물음 자체가 성립하지 않게 됐고, 남는 것은 점수가 아닌 형태로 검색이 이 선호를 순위에 어떻게 반영하는가와 fallback 보다 먼저 보는가다(이석). 반영은 spec/schema-v0.5.md 2.7절과 design/decoration-model.md 5.2절·6절.

2026-08-29 갱신 (5) page layout 은 규약 범위 밖이고 5단계 이후로 미룬다 (정원석). 여러 컴포넌트를 한 페이지에 어떻게 놓는가를 정하는 규약은 5단계 범위에도 없다 — 5단계가 뽑는 것은 노드 태그와 properties 와 구조 대응이지 배치가 아니다. page 수준에 열려 있는 relations 와 decoration 은 각각 의미 관계와 꾸밈 선호이지 배치 지시가 아니다. 없는 것이 아니라 미룬 것이고, 그때까지 질의 쪽 스키마에 좌표나 그리드를 넣지 않는다(넣으면 색인 쪽과 두 벌로 갈린다). 그 전에 B-32(최상위 컴포넌트 수 상한)와 I-11(조각 조립 오케스트레이션)이 먼저 풀려야 한다 — 개수와 조립이 안 정해진 상태에서 배치 규약을 쓸 수 없다. 규약 2.7절에 상자로 적었다.

2026-08-29 갱신 (4) 규약 enum 을 45종으로 맞추고 지도는 지원하지 않기로 확정했다 (정원석). B-24 가 2026-08-06 에 페이지 역할 4종의 어휘 편입을 정했고 spec/capability-table.md·코드(vocabulary.ts)·생성기 프롬프트는 전부 45종으로 돌고 있었는데, 규약 semanticCategory enum 만 41종에 머물러 있었다 — 그래서 PageNavigation 예시 넷이 스키마 검증에서 거부됐다(부록 F 2번의 결함). enum 을 45종으로 맞췄다. 버전은 0.5.2 → 0.5.3(PATCH) — 이미 정해지고 지켜지던 것을 규약 텍스트에 반영하는 미반영 결함 수정이다. 함께 지도 전용 4종(Distribution, Location, Highlight, Flow)은 지원하지 않기로 확정했다. B-24 원문의 "49종 확정, 지도 4종은 성립 불가로 표시"는 2026-08-17 스쿼드 확인("지도 데이터가 있어야 성립해 structure 가 표현할 대상이 아니다")과 어긋난 채 남아 있었고, 나중 결정이 이긴다. B-24 항목 문구를 45종으로 정정했다.

2026-08-29 갱신 (3) type 어휘에서 대분류 21값을 뺐다 (정원석). type 과 alternatives 는 이제 결합값(대분류.중분류) 41종만 받는다. 근거는 대분류가 실제로 쓰이는 컴포넌트 유형이 아니라는 것이다 — Hierarchy 로는 아무것도 그릴 수 없고, 그릴 수 있는 것은 Hierarchy.HierarchicalTree 이거나 Hierarchy.Pyramid 다. 대분류는 결합값을 묶어 부르는 분류 축이지 표현형이 아니므로 값이 될 수 없다. 종전에는 "중분류를 못 정하면 대분류만 적고 검색이 그 안 전체를 후보로 본다"였는데, 이것은 갱신 (1) 이 막은 것과 같은 회피이고 정도만 약하다. 중분류를 못 정하겠으면 종단 셋 중 하나를 고른다. 대분류 개념 자체가 사라지는 것은 아니다 — fallback 근접도의 "대분류 일치는 강한 신호"와 규약 6절 셋째의 신호는 그대로다. 값으로 못 쓸 뿐 축으로는 계속 쓴다. 깨지는 산출물이 없다 — 골든셋 v1 의 컴포넌트 type 454개가 전부 결합값이고 생성기 프롬프트도 결합값 45종만 준다. 버전은 0.5.1 → 0.5.2(PATCH). fallback.ts 의 major-expansion 경로는 규약상 도달 불가가 됐다 — I-14. 남은 어휘는 결합값 45종이다(갱신 (4)).

2026-08-29 갱신 (2) 규약 버전 규칙을 세웠다 (정원석). 종전에는 v0.5 를 자리에서 네 번 고치면서 버전을 그대로 뒀다(2026-08-06 entities+columns, 2026-08-17 fallback 상한 폐지, 2026-08-28 fallback 규칙 6번, 2026-08-29 type 필수). 그래서 "지금 규약이 무엇인가"를 버전으로 가리킬 수 없었다. 앞으로 규약을 고치면 반드시 올린다. 형식은 MAJOR.MINOR.PATCH 이고 각 자리 0~99 다. 자리 판정 기준은 하나 — 이 변경으로 실제로 무효가 되는 기존 산출물이 있는가. 있으면 MAJOR, 없고 새로 쓸 수 있는 것이 늘면 MINOR, 둘 다 아니면 PATCH 다. 원리가 아니라 실측으로 판정한다. 검증기는 MAJOR·MINOR 만 대조하고 PATCH 는 보지 않는다(PATCH 는 정의상 유효성을 안 바꾸므로). 파일 이름도 MAJOR.MINOR 만 따라간다 — patch 마다 파일명과 링크 30여 곳이 바뀌면 얻는 것보다 잃는 것이 크다. 현행 값은 0.5.1 이고 종전 표기 0.5 는 0.5.0 으로 읽는다. 규칙은 spec/schema-v0.5.md 0.1절.

2026-08-29 갱신 (1) component.type 을 필수로 바꿨다 (정원석). 종전에는 optional 이었고 근거는 "필수로 걸면 '카테고리를 못 고르겠다'가 곧 생성 실패가 된다" 였는데, 뒤집었다. 근거는 이 단계의 존재 이유다 — 규약 1절 설계 원칙 첫째가 "생성 단계에서 최적 semantic category 를 정한다"이고, 어떤 시각 표현형으로 그릴지를 먼저 정해야 표현 방식이 거기서 따라 나온다. type 을 비우고 내보내는 것은 그 판단을 검색 쪽으로 미루는 시각화 책임 회피다. 원칙 1과 optional 은 처음부터 어긋나 있었다. '적을 의무'만 바뀌고 '따를 의무'는 그대로다 — 검색은 여전히 성립 조건과 색인 공급을 보고 fallback 으로 벗어난다. 못 고르겠으면 비우는 것이 아니라 종단 셋 중 하나를 고른다(개수 조건만 보므로 언제나 하나는 성립한다). 깨지는 산출물이 없다 — 골든셋 v1 컴포넌트 470개가 전부 이미 type 을 갖고 있고 PoC 프롬프트도 적으라고 지시하고 있었다. 버전은 0.5.0 → 0.5.1 로 올렸다(PATCH — 실제로 무효가 되는 산출물이 0건이므로. 위 갱신 (2) 의 판정 기준). 고친 자리는 spec/schema-v0.5.md 2절 타입·JSON Schema, 5절, 6절 개정 상자다. 코드 반영은 아직이다 — 아래 I-14. 남은 결정 하나는 대분류만 적는 것을 계속 허용할지다.

2026-08-28 갱신 노드가 여럿인 질의의 fallback 순서를 확정했다. 종전에는 카테고리 하나를 내리는 사다리만 있었고(엣지 131개), 중첩이나 병치로 노드가 여럿일 때 어느 노드부터 포기하는지가 어느 문서에도 없었다. 다섯 단계(N1 전체 일치, N2 모양 보존 강등, N3 최상위 벗기기, N4 반복, N5 평탄화)와 규칙 여섯(N-R1~N-R6)으로 정했고 SSoT 는 spec/capability-table.md 3.6절이다. 한 단계씩 따라가는 예시는 design/content-binding-contract.md 3.7절이다. 정한 사람은 정원석이고 대화로 정했으므로 Slack 이나 Jira 근거 링크가 없다. 핵심 판단은 위부터 벗긴다는 것이다 (그 절 3.6.3). 부모를 벗기면 질의가 여럿으로 갈라져 후보 풀이 커지는데, 자식부터 떼면 내용을 지불하고도 부모가 여전히 복합으로 남는다. 이 확정으로 I-12 가 닫히고 B-31, B-32, D-8, I-11 이 새로 열렸다. 규약 5절에도 fallback 규칙 6번으로 반영했다.

2026-08-11 갱신 MORDOR 체크인에서 D-7 이 새로 열리고 곧바로 닫혔다. 4단계 boundary 태깅 PoC 준비 중 나온 이종중첩 컴포넌트(heterogeneous nested component) — 하나의 컴포넌트 바운더리 안에 서로 다른 type 이 동시에 중첩된 경우 — 를 검색 풀에서 제외하기로 참석자 간 공감대가 형성됐다. 대부분 조합 Fallback 으로 해결되고, 전용 대치 로직을 새로 만들기엔 WSJF 가 낮다고 판단했다. 수량 파악(허재영, 황현진)은 후속 액션으로 남는다. spec/schema-v0.5.md 8.7절에도 용어를 반영했다.

2026-08-13 갱신 D-7 의 후속 액션인 수량 파악이 끝났다. 1,000개 표본에서 이종중첩이 11개로 관측 비율 1.10%(95% Wilson 구간 0.62~1.96%)이고, 전체 183,052개로 환산하면 약 2,014개(1,126~3,586)다. 상한에서도 전체의 2% 미만이라 제외로 잃는 양이 작고, D-7 의 제외 결정과 어긋나지 않는다. 측정 방법과 비용(0원)은 reference/2026-08-13-이종중첩-수량-산출/ 에 적었다. MOR-2048

2026-08-22 (후속) 갱신 대치 경로 역할과 PoC 우선순위를 문서에 못 박았다. binding.ts(규약 RLSC)는 내용시각화·comp-sign 실서비스 경로가 아니다. 4단계 comp-sign vs 5단계 property 비교는 같은 평가 pool에 comp-sign signature와 I.I.S. 속성을 미리 bake한 뒤, 이종 type 간 속성을 슬롯에 맞추는 규칙인 **T-8(cross-type property projection, plan/node-tag-and-property-poc-blueprint.md 6절)**을 붙여야 한다. SSOT: design/content-binding-contract.md 3.6절, I-8/I-9, plan/poc-module-map.md 3절.

상태 표기 [ ] 미착수 · [~] 진행 중 · [x] 완료 · [?] 남의 답을 기다리는 중(내가 못 움직임). 2026-08-22 기준 D 절에 [?] 항목은 없다.

이 문서 훑기

A. 규약 확정#

마감 2026-08-07 (MOR-1773)

A-1 근거 단어장은 확보됐다. 허재영님이 2026-07-24 Semantic Identifier 를 최종 정리했다({Major}_{Minor} PascalCase 결합, Q&A → QnA, A+B=C → CombinedResult, Slack). 류민님 replace 는 MOR-1792 Done(7/28, major_minor_identifier 컬럼 추가), 원본 컬럼 교체는 MOR-1870 Done(7/31). repo 사본 semantic-taxonomy-v7.md 가 이 판을 반영한다. 남은 것은 적재분 검사다. 7/28 시점 dev 적재값이 아직 minor 만(List)이었고, 2.2 로 고쳐 올리는 것이 MOR-1844(8/3~8/5)다. C-6 에서 추적한다.

A-2 근거 2026-08-01 정원석 판단으로 fallback했다. 규약 확정 마감과 무관하게 나중에 정렬한다. 포맷은 YAML 로 확정됐고 산출물이 이미 그 위에 쌓여 있어, 정렬이 늦어도 작업이 막히지 않는다 (README.md 2.1절). 닫힘 (2026-09-05 정원석). 지난 MORDOR 체크인에서 강창석·이석과 함께 이미 논의해 전달 완료.

A-3 근거 2026-08-02 확정 → schema-v0.5.md. B절 열린 결정 12건이 닫혔고(G절), 남은 셋(B-7, B-9, B-10)은 규약을 막지 않는다. 스키마는 JSON Schema 검증기로 자체 유효성, 예시 7종 통과, 부정 사례 12종 거부를 확인했다. 부속 문서는 capability-table.md(41종)와 projection-model.md(설계 의도)다.

A-4 근거 문서 조사는 2026-08-02 에 끝났다 → smart-diagram-data-model.md. 실물 코드로 종류 32종, 슬롯 어휘, 저장 contract 를 확인했고, schema-v0.4.md 10절의 진술 셋이 어긋난 것을 정정했다. 둘은 같은 것이고 2026-07-03 에 제품 명칭만 바뀌었다. 남은 것은 어댑터 실측이고 B-13 과 같은 건이다.

A-5 근거 pipeline-flow.md 로 1차 작성했다(2026-08-01). 그림을 스쿼드가 볼 형태로 옮긴 것이 slides/2026-08-04-visual-summary.md 다(2026-08-03, Marp 24장). 남은 것은 2026-08-04 세션에서 실제로 공유하는 것이다.

A-6 근거 UNICORN-77437 은 존재하지 않는 키다(7/15 번호 구간에 구멍). 새로 만들지, UNICORN-77316 과 UNICORN-77328 에 흡수시킬지 정해야 한다. 같은 깨진 링크가 MOR-1774, MOR-1741, 절차 명세, 허브에도 남아 있다. 닫힘 (2026-09-05 정원석). 새 티켓을 만들지 않는다. 이 repo 안 문서(README.md·sources.md 등)는 이미 존재하지 않는 키로 정확히 플래그해뒀고 대체 티켓(UNICORN-77316·77328)도 적어 뒀다 — repo 쪽은 조치 끝. MOR-1774·MOR-1741 등 repo 밖 Jira 티켓 본문의 잔존 링크는 이 결정의 범위가 아니다(Jira 접근 필요, 별도 처리).

B. 규약 열린 결정#

schema-v0.5.md 9절과 짝을 이룬다. A-3 '초안 완결'은 아래가 닫히는 것이다.

2026-08-02 갱신 장식과 계층 4건 중 B-2 와 B-3 은 '질의 쪽 선언 필드를 두지 않는다'는 결정으로 닫혔다(projection-model.md 6절). 질의 쪽 필드가 없어졌으므로 이 둘은 더 이상 I-2 정렬에 걸리지 않는다. 남은 B-1(요구 등급)과 B-4(포기 가능 여부)는 색인 쪽 capability 상수와 카테고리 fallback 순서의 설계 항목이라, I-2 정렬과 E-2 폴백 테이블과 한 덩어리로 진행한다.

2026-08-03 갱신: 위 문단이 뒤집혔다. B-2 와 B-3 이 다시 열렸고, 질의 쪽 필드가 생기므로 이 둘이 다시 I-2 정렬에 걸린다. 설계 의도는 design/decoration-model.md 로 옮겼고, 그 문서가 I-2 세 축 중 둘(등급, 노드 분류)에 답을 냈다. 남은 절반은 comp-sign 변형 3종을 합치는 것이다(B-19). B-1 과 B-4 는 그대로 닫혀 있다. 장식 축에 require 를 두지 않기로 했으므로 요구 등급 3분이 다시 열리는 것은 아니다.

B-1~B-4: 장식과 계층#

B-1 근거 (2026-08-02) 성립 조건을 '그 종류로 배치가 불가능한 것'으로 좁히고, 나머지는 기본값을 가진 선택 속성으로 옮긴다. 채점 코드는 안 건드린다. 기본값은 표현 선택에만 주고 내용에는 주지 않는다. 41종 전량은 capability-table.md 에 있다.

B-2 근거 (2026-08-02) 타이틀과 디스크립션 수준은 구조에서 파생하고, 그림 장식은 색인 쪽에서 처리한다 (projection-model.md 6절).

B-2 뒤집힘 (2026-08-03 정원석) 위 결정이 판정 책임을 색인 쪽으로 넘겼는데 색인 쪽에 그것을 받을 선언이 없었다. capability-table.md 에 장식 언급이 0건이다. 그리고 근거표가 보존 전용 문서에만 있었다. Summary 가 선호를 적고 시스템 전역 선호도 함께 두는 방향으로 바꿨다. 등급으로 두지 않는다. 누적 등급 3단(N / N+α / N+β)은 확장성이 없다. 한 등급에 서로 다른 것이 섞여 있고, 누적이라 '배경은 원하지만 일러스트는 싫은' 조합을 적을 수 없고, 축이 늘 때 끼워 넣을 자리가 없다. 전용 속성은 DECO 계열에만 둔다 (2026-08-03 정원석). 판정 기준은 '대치가 내용으로 채우는 노드는 선호가 필요 없다'다. 그래서 DESC 계열(Element.Title, Subtitle, Description)과 강조(Element.Highlight)는 축이 아니다. 앞은 structure 와 nested component 가 담고 뒤는 entity.emphasis 가 이미 담는다. 축은 ornament(Element.Decoration)와 background(Element.Background) 둘이고 각각 RLSC role 하나에 대응한다. 값은 셋(prefer, indifferent, avoid)이다. 근거와 차용가치 판정은 design/decoration-model.md 다. N+α 는 개념 자체가 사라졌다. 타이틀과 디스크립션 유무는 표현 밀도가 아니라 내용이다. archive/projection-model.md 6절 규칙 3("구조에서 파생한다")이 이 대목에서는 유효했고, 뒤집히는 것은 규칙 4 하나다. 다만 규칙 3 의 수단은 정정했다 (2026-08-03 정원석 지적). 원문이 파생 근거를 "entities 의 label 과 items 보유 여부"로 적었는데 items 는 평탄화 결과물이다. 규약 1절과 8.7절이 "entity.components[] 를 못 읽는 컴포넌트는 자식 entities 를 부모 items 로 편다"로 정의하므로, items 로 판정하면 설명 문단과 하위 항목 목록과 평탄화된 중첩이 구별되지 않는다. 정확한 수단은 entity.label 과 entity.components[](nested component)다. 이 정정으로 계층(B-3)과 DESC 가 같은 수단을 쓰게 되고, B-20 이 둘 다의 전제가 된다.

B-3 근거 (2026-08-02) 계층 보존 요구는 component.type 이 담고, 평탄화 허용 비용은 카테고리 fallback 순서가 정한다 (projection-model.md 6절).

B-3 뒤집힘 (2026-08-03 정원석) 컴포넌트를 nested 구조로 두어 해결한다. 계층의 존재는 이미 entity.children[](같은 컴포넌트 안)과 entity.components[](컴포넌트 경계를 넘는 중첩)가 표현하므로, 새 필드를 만드는 것이 아니라 그 구조를 실제로 쓰는 것이 결정 내용이다. 전제가 하나 걸려 있었다. entity.components[] 는 스키마에만 열려 있고 생성기가 채우지 않았다 (schema-v0.5.md 1절, 8.7절). 중첩을 못 읽는 컴포넌트에서는 자식 entities 가 부모 items 로 평탄화된다. 언제부터 채울지는 B-20 이고, 2026-09-02 에 닫혔다 — PoC 는 채우고 실서비스는 아직 안 채운다.

B-4 근거 (2026-08-02) 회의록 원문 맥락상 '포기'는 검색 조건에서 그 요구를 빼는 것이고 내용 삭제가 아니다("나머지 영역은 일반 텍스트 쪽으로 흘려보냄"). 여러 요구를 가진 입력에서 어느 종류도 탈락하지 않고 후보로 남으므로, 못 채운 요구는 채점 결과와 fallback 규칙 3번이 처리한다. 별도 선언이 필요 없다.

B-5~B-17: 기존 항목#

B-20 결정 (2026-09-02 닫힘, 허재영) 스키마 칸은 v0.4 부터 열려 있었고 8.8절은 이미 「PoC 는 L3 / 실서비스는 L2」라고 적혀 있었는데, 1절·2.1절·8.7절은 여전히 「생성기는 채우지 않는다」로 남아 있었다. PoC 에서 L3 를 테스트하려면 그 문장을 갈라야 한다. PoC 생성기(MOR-1910)는 entity.components[] 를 채운다. 실서비스 Summary 생성기는 아직 안 채운다. 검색 오케스트레이션(I-11), 이종중첩 풀(D-7), 골든셋 「포함」행은 별건이다. 칸이 원래 optional 이라 기존 산출물을 무효로 만들지 않으므로 버전은 올리지 않는다. 규약 schema-v0.5.md 8.7절.

B-34 근거 (2026-08-31 열림) capability-table.md 2.3절 19행은 NestedScope 를 "개수 2 이상, 내용 조건 children 필수, 선택 내용 children (안쪽이 좁은 범위)"로 적는다. 그런데 구현(src/lib/visual-summary/capability.ts 의 count: { min: 2, basis: 'entities' } 와 establish.ts 의 countFor)은 최상위 entities 만 센다. 그래서 children 을 문서 정의대로 '안쪽 범위'로 읽어 사슬 하나로 적은 산출물은 최상위가 1개라 개수 미달로 떨어진다. Summary 골든셋 v1 검증에서 실측됐다 — 범위를 최상위에 평평하게 나열한 행들은 성립하고(이때 children 은 범위가 아니라 부연 설명을 담아, 문서의 선택 내용 정의와 어긋난 채 통과한다), 사슬형 두 행은 탈락한다. 같은 단일 뿌리 구조인 HierarchicalTree 는 "1 이상 실측"으로 이미 완화된 전례가 있다. 정할 것은 둘이다 — 계수에 children 을 포함할지(또는 min 을 1 로 내릴지), 그리고 NestedScope 의 표준 인코딩을 평평한 나열과 사슬 중 무엇으로 못 박을지. 결정 전까지 골든셋의 NestedScope 행 6건은 동결한다. (초안 작성: Claude, 허재영 검토 후 게시)

B-34 결정 — 첫 초안 (2026-09-02, 허재영, 이후 뒤집힘) 뿌리 1개짜리 NestedScope 를 성립으로 보고 entities.min 을 1 로 내리며 표준 인코딩을 사슬(바깥 범위 label → 안쪽 범위 children)로 못박았었다. 리뷰에서 이 인코딩이 semantic-taxonomy-v7.md 자신의 정의와 부딪힌다는 지적이 나와 뒤집었다 — 아래 결정 참고.

B-34 결정 (2026-09-04 제안, 2026-09-05 정원석 확정 — 타인 확인 대기 없이 결정) NestedScope 는 children 을 쓰지 않는다. 개수는 2 이상(원래 기준으로 되돌림), entities 배열 순서 그 자체가 안쪽→바깥쪽 순서를 나타내고(별도 순서 필드 없음), 방향을 뒤집을 수 있는 direction(속성, inward/outward, 기본 inward — 배열 첫 항목이 안쪽) 만 둔다. Steps·Timeline·Staircase·Cycle 같은 다른 순서형 카테고리가 전부 이 방식이라 — Staircase(11행)와 같은 모양이다.

되돌리자는 이유. semantic-taxonomy-v7.md 145행이 스스로 이렇게 적는다 — "NestedScope 와 HierarchicalTree 를 가르는 것은 의미가 아니라 동심원으로 그리는지다. 단일 사슬 포함 관계는 가지가 하나뿐인 트리와 구조적으로 같은 것." 즉 children 사슬 인코딩을 표준으로 못박으면 NestedScope 가 데이터 구조상 HierarchicalTree 와 동일해진다 — 두 종을 가르는 유일한 근거였던 "표현 방식 차이"를 데이터에서 지워 버리는 셈이다. NestedScope 의 전형인 TAM/SAM/SOM 은 애초에 가변 깊이 트리가 아니라 정해진 개수의 동심원에 라벨 하나씩, 안쪽→바깥쪽 순서만 있으면 되는 구조다. 처음엔 Pyramid(18행)의 weight/apex 를 그대로 본떠 순서를 담는 order 필드를 새로 만들었는데, 다시 보니 불필요했다 — 순서는 배열 위치가 이미 담고 있고(weight는 순서가 아니라 층 크기라 Pyramid엔 별도 필드가 필요했던 것), order라는 이름은 이미 SWOT(5행)이 사분면 배치라는 다른 뜻의 속성으로 쓰고 있어 이름도 겹쳤다. 그래서 order 필드는 빼고 direction 속성만 남긴다. 3.3절 의 Pyramid↔NestedScope 짝은 그대로 둔다. 확정에 따라 남는 후속 작업 다섯 (미착수): ① aippt-prisonbreak capability.ts — entities.min 을 2 로 되돌리고 children 필수 조건을 빼고 direction reads 를 추가한다. direction 타입은 'inward' | 'outward' 문자열 리터럴 유니온(enum)으로 선언한다 — number 나 자유 문자열로 두지 않는다(코드 PR 동봉), ② Pyramid↔NestedScope fallback 규칙(3.6절)의 children 언급을 배열 그대로 전달로 정정, ③ Summary 골든셋의 NestedScope 행 6건을 평평한 나열로 다시 쓴다(동결 해제, 사슬로 쓴 것은 되돌린다), ④ Summary 생성기 프롬프트가 direction 을 기본값에 맡기지 않고 입력 글의 서술 순서를 읽어 명시적으로 판단해 적도록 지시문을 추가한다(schema-v0.5.md 8.2절에 근거와 예시를 이미 적어 뒀다) — apex 같은 진짜 표현 선택과 달리 잘못 판단하면 그림의 안·바깥이 뒤바뀐다, ⑤ I.I.S. 속성 추출기(T-7, extractProperty.ts)가 NestedScope 의 direction 을 실제 컴포넌트에서 실측해 채우도록 어휘를 추가한다(plan/node-tag-and-property-poc-blueprint.md 2.1절에 반영해 뒀다, reads.params 제네릭 추출기가 자동으로 태우므로 ①의 capability.ts 반영이 선행 조건이다). (초안 작성: Claude, 정원석 리뷰 중 제기)

B-34 부작용으로 새로 열린 것 (2026-09-04) report/sections/06-examples.md 의 갱신 전 예시는 시장 둘(국내·해외)을 각각 TAM/SAM/SOM 사슬로 나란히 비교하는 모양이었다 — 최상위 entities 2개, 각각 children 3단. 지금 설계(사슬 하나만 담는 flat 배열)는 이 "여러 사슬을 나란히 비교"를 표현할 방법이 없다. 실사용에서 이 모양이 자주 나오면 별도로 다시 열어야 한다 — 후보는 ① 그룹 라벨을 얹은 2차원 구조를 새로 열거나, ② NestedScope 인스턴스를 여러 개 나란히 두는 상위 구조(예: 비교형 컴포넌트)로 해결. 담당 미정.

B-35 근거 (2026-09-01 열림) 0.1절은 버전 규칙을 세우면서 "종전 표기 0.5 는 0.5.0 으로 읽는다"와 "검증기는 MAJOR·MINOR 만 대조하고 PATCH 는 보지 않는다"를 함께 적었다(2026-08-29 갱신 (2)). 그런데 같은 날 내보낸 spec/schema/visual-summary-0.5.schema.json 의 version 은 "pattern": "^0\\.5\\.(0|[1-9][0-9]?)$" 로 세 자리 표기만 통과시킨다 — 구 표기 0.5 를 0.5.0 으로 읽어 주는 자리가 스키마에는 없다. Summary 골든셋 v1.1 초안 전수 검증(2026-09-01)에서 실측됐다 — 135행 전량이 version: "0.5" 로 이 패턴에 걸려 스키마 검사에서 떨어지는데, 같은 행들이 capability·relations 검사는 대부분 통과한다. 개정 이전에 적힌 산출물이라 표기가 낡은 것이지 내용이 무효인 것이 아니어서, 떨어뜨리는 것이 개정 의도인지가 판정거리다. 코드 쪽(schema.ts 의 z.literal('0.5'))은 반대 방향(두 자리만 수용)으로 낡아 있고 I-14 가 이미 추적한다. 정할 것은 하나였다 — 스키마가 구 표기를 0.5.0 으로 수용하도록 패턴을 넓힐지, 아니면 0.1절에서 "0.5.0 으로 읽는다"를 빼고 기존 산출물의 일괄 치환(마이그레이션) 지침을 두는지.

B-35 결정 (2026-09-05 정원석) 패턴을 넓힌다. 0.1절이 이미 "구표기 0.5는 0.5.0으로 읽는다"고 선언해 둔 규칙이 맞고, 스키마 쪽이 그 규칙을 못 따라간 게 버그였다. 골든셋 135행을 치환하는 마이그레이션은 근본 해결이 아니라 앞으로 낡은 표기가 또 나올 때마다 반복해야 하는 대증치료다. 구현 작업(미착수, I-14 와 같은 건): JSON Schema(spec/schema/visual-summary-0.5.schema.json)의 version 패턴을 ^0\.5(\.(0|[1-9][0-9]?))?$ 로 넓혀 두 자리 표기 "0.5" 도 통과시킨다. 코드 쪽 schema.ts 의 z.literal('0.5') 도 같은 방향으로 맞춘다. (초안 작성: Claude, 허재영 지시로 게시)

B-29 근거 (2026-08-06 열림) 강창석님이 Slack에서 표 검색 매칭 탈락 사례를 공유했다. 병합 셀이 있는 실사용 표 둘이 matrix 성립 조건에 걸려 통째로 탈락했다. 조사해 보니 병합이 두 종류였다. 계층형은 닫혔다. 상위 범주 하나가 하위 행 여럿을 거느리는 경우(예: "PROJECT 01" 이 "성장률"·"매출" 두 행을 거느림)는 entity.children[] 로 그대로 담긴다. ListingTable·ComparisonTable 성립 조건에 entities+columns 대안을 열었다(schema-v0.5.md 2.5.1절, capability-table.md 2.1절, 2026-08-06). 독립축 rowspan 은 못 담는다. 강의 4개 행(주축)이 그대로인데 "주말반" 컬럼 하나만 값이 2행씩 걸쳐 반복되는 사례(와인클래스 캡처)는, 표 전체를 다른 축으로 다시 묶지 않는 한 트리 하나로 표현이 안 된다. 셀 단위 span 메타데이터를 두면 되지만, 그건 matrix(차트와 공유하는 평평한 격자)를 다시 건드리는 길이라 2.5.1절이 피하려던 것과 같은 문제로 되돌아간다.

B-29 결정 (2026-09-05 정원석) 셀 병합(span) 기능 자체를 만들지 않는다 — 실측 없이 확정. 세 근거가 전부 같은 방향을 가리켜서 빈도 데이터 없이도 판단 가능했다. (1) 이건 자연어 설명에서 잘 안 나오는 패턴이다 — Summary는 내용을 의미 구조로 옮기는 것이지 기존 스프레드시트의 셀 레이아웃을 픽셀 단위로 베끼는 게 아니다. (2) 못 담아도 정보가 안 사라진다 — 병합된 값을 각 행에 반복해서 적으면 그만이고, 셀 병합은 내용이 아니라 표현(꾸밈)이다(4.6절 "내용 대치는 꾸밈에 관여하지 않는다"와 같은 성격). (3) 고치는 비용이 구조적으로 비싸다 — matrix는 표뿐 아니라 차트와 공유하는 격자라, 병합 메타데이터를 넣으면 드물게 쓰이는 표 병합 하나 때문에 모든 matrix 소비자(차트 어댑터 포함)가 복잡해진다. 적용 범위: 4단계(comp-sign 생성기)·5단계(I.I.S.) 모두 — 생성 시 병합을 표현하지 않는다.

B-37 근거·결정 (2026-09-05 신설 및 확정, 정원석) schema-v0.5.md의 Matrix.Column은 이미 role?: 'category' | 'value' | 'x' | 'y' | 'size' | 'start' | 'end' | 'date'를 갖고 있는데, rows: Array<string | number | null>[]는 role과 무관하게 전 셀을 느슨하게 허용한다. 그래서 role: 'value'인 컬럼에 문자열이 들어가도(예: 막대 높이가 "많음") 스키마도 capability 성립 조건도 안 걸린다 — 차트는 문자열로 못 그리는데 말이다. 결정: 컬럼의 role이 셀 값 타입을 강제한다.

컬럼 헤더(Column.label)는 스키마 타입이 이미 string 고정이라 모호함이 없다. 적용 기준은 카테고리 이름이 아니라 컬럼의 role이다 — BarChart든 ListingTable이든 상관없이 같은 규칙이 적용되고, 테이블 카테고리는 대부분 value/x/y/size role을 안 써서 자연히 문자열이 허용되며, 차트 카테고리는 이 role들을 선언하니 자동으로 숫자가 강제된다. 카테고리별 예외 규칙을 따로 안 만들어도 된다. 구현 (미착수): establish.ts(또는 zod)에 컬럼 role별 셀 타입 검사를 추가한다.

B-30 근거 (2026-08-17 열림) PictogramChart(matrix 필수)와 Gauge(measure 필수)가 서로의 fallback 후보로 근접도(원칙 2)상 타당한데, capability-table.md 3.4절 P1~P8 어디에도 measure↔matrix 변환 규칙이 없다. 지금은 후보만 순서에 넣어 두고(capability-table.md 3.2절, KPIKeyMetric_Gauge·ProportionComposition_PictogramChart 행) 3.4절에 P9(measure→matrix, value를 1행짜리 matrix로 접는다)와 P10(matrix→measure, 대표값 1행을 value로 쓴다)을 "제안, 미확정"으로만 올려 뒀다. P10 의 대표값 선택 기준(첫 행, 합계, 최대값 등)이 없다 — 확정해야 실제 fallback 이 동작한다.

B-30 결정 (2026-09-05 정원석) P9·P10 을 규칙으로 만들지 않는다. 단일 값(measure)과 복합 데이터(matrix)는 형태가 근본적으로 달라서, 서로 변환하는 규칙을 두면 원래 의도를 왜곡한다 — Gauge(measure)를 BarChart/PictogramChart(matrix)로 접으면 target/min/max/thresholds 가 전부 사라진 막대·아이콘 하나만 남고, 반대로 PictogramChart 의 여러 행 중 하나를 뽑아 Gauge 의 대표값으로 쓰면 원본에 없던 target/max/min 을 채울 근거도 없이 나머지 행을 버리게 된다. 2026-08-17에 plan/fallback-map-review-2026-08-13.md 가 이미 같은 결론(Gauge↔PictogramChart/BarChart 제외)을 냈었는데, 이후 이 문서·report/* 가 옛 체인으로 되돌아가 있었다 — 이번이 그 유실 복원이다. KPIKeyMetric_Gauge 체인을 BigNumber → HighlightedMessage로, ProportionComposition_PictogramChart 체인을 BarChart → List로 되돌렸다(capability-table.md 3.2·3.4·3.5절). PictogramChart → BigNumber(P4)도 재검토 끝에 뺐다 — 처음엔 P4(행마다 entity로 편다)로 행을 보존하니 예외로 봤는데, P4는 label+items만 채우고 BigNumber의 필수 조건인 entity당 value는 안 채운다. BigNumber도 entities가 여럿일 뿐 entity 하나당 값 하나인 단일값 모델이라 matrix를 우겨넣을 수 없다는 점에서 Gauge와 같은 범주다. 엣지 수는 131→127.

B-31 근거 (2026-08-28 열림) capability-table.md 3.6절이 N3(부모를 벗겨 자식을 최상위로 올린다)을 N5(평탄화)보다 먼저 둔다. 둘 다 텍스트를 안 버리는데 N3 이 카테고리 표현을 더 남기기 때문이다. 계층에서는 이 근거가 약해진다. N-R1 이 벗긴 부모의 label 과 items 를 승격된 조각으로 옮기지만 남는 흔적은 부모 한 층뿐이고, 깊이 3 이상이면 소속 관계를 되살릴 수 없다. 평탄화는 들여쓴 items 로 층을 남긴다. 그래서 대분류가 Hierarchy 인 부모는 N3 을 건너뛰자는 제안을 N-R5 로 올려 뒀다.

B-31 결정 (2026-09-05 정원석) 건너뛴다 — 실측 없이 구조적 논증만으로 확정. Root-Peeling(N3)은 한 겹만 벗기므로, 깊이 3단 이상 계층(예: 회사→부서→직원)에 반복 적용(Re-Peeling)하면 직원들이 전부 최상위로 흩어져 "회사-부서-직원" 소속 관계 자체가 사라진다 — 남는 건 형제 인접성뿐이다. Content Flattening(N5)은 들여쓰기로 임의 깊이를 그대로 보존한다. Hierarchy가 대분류라는 건 그 콘텐츠의 핵심이 계층 관계 자체라는 뜻이므로, "카테고리 표현을 더 남긴다"는 Root-Peeling의 일반적 이점보다 "계층 관계를 안 깨뜨린다"는 Content Flattening의 정확성이 우선한다. 이건 실사용 빈도와 무관한 구조적 성질이라 실측을 기다릴 필요가 없었다.

B-33 근거 (2026-08-29 열림) structure 와 params 의 검사 비대칭을 어디까지 둘지다. 먼저 오해를 걷어낸다 — structure 를 검사하지 않는 것이 아니다. 필드 이름·타입·필수 조건은 zod 가 .strict() 로 전량 보고(어휘 밖 필드 이름은 error), 카테고리별 최소 요구는 capabilityCheck.ts 의 성립 조건 판정이 본다. params 는 열린 객체(Record<string, unknown>)라 스키마가 아무것도 못 잡으므로 capability 의 키 검사가 스키마 대역으로 들어간 것이다. 진짜 비대칭은 하나뿐이다 — "그 카테고리가 읽지 않는 값이 실려 있는 것"을 params 는 warning 으로 세고 내용 필드는 아무 등급도 안 붙인다. 지금의 근거는 사라지느냐다. 안 읽는 params 는 P2 로 버려져 의도가 조용히 소멸하고, 안 읽는 내용 필드는 P3 으로 items 에 보존돼 소멸하지 않는다. 다만 소멸하지 않는다고 결함이 아닌 것은 아니다 — List 에 avatar 를 적었다면 그 내용은 ProfileCard 였어야 한다는 신호다. 실패로 올릴 일은 아니지만 info 로 세어 생성 품질 지표에 넣을 수는 있다(같은 성격의 info 등급이 이미 있다 — 자손을 합쳐야 성립하는 경우). 정할 것은 셀지 말지와, 센다면 params 쪽도 warning 에서 내릴지다.

B-33 결정 (2026-09-05 정원석) info로 세지 않는다. "정확하게 생성되지 않으면 내용 자체가 이상하게 생성되고, 사후 처리로는 이미 죽은 semantic 정보를 못 살린다"는 게 이유다 — List에 avatar를 적은 순간 원래 ProfileCard가 표현하려던 사람 카드 구조는 사라지고, items 끝에 붙는 텍스트 한 줄로는 되돌릴 수 없다. 사후 등급이 아니라 생성 시점에 원천 차단한다.

B-33 근거 한 줄 정정 (2026-09-11). 위 근거 문단은 "안 읽는 내용 필드는 P3 으로 items 에 보존돼 소멸하지 않는다"고 적었는데, 그것은 대치 경로 한정이다. P3 는 capability-table.md 3.4절이 "fallback 은 카테고리를 바꾸는 일이므로" 출발→도착 엣지에서 옮길 것을 정하는 규칙이라, 생성기가 처음부터 그 카테고리로 쓰면 돌지 않는다. HierarchicalTree 를 Pyramid 로 재지정한 실측에서 하위 9개가 그대로 소멸했다(iui #1023). 결론(생성 시점 원천 차단)은 그대로고, 근거가 오히려 더 강해진 자리다.

이 결정은 "빈 결과보다 낫다"(색인 검색·fallback 철학, 이 문서 위쪽 성립 미충족 논의)와 범위가 다르다 — 그 철학은 이미 존재하는 디자인 중에서 고르는 색인 검색에 맞는 논리다(재생성이 불가능하므로 흡수가 유일한 선택지). Summary 생성기는 그 자리에서 LLM이 새로 만드는 것이라 재생성이 값싸게 가능하므로, 잘못된 카테고리 선택을 흡수할 이유가 없다. B-33의 결정은 생성기 스코프에만 적용되고, 색인 fallback(B-30 등 대치 경로)에는 적용되지 않는다.

구현 방향 (미착수):

1. B-11 에서 이미 쓴 패턴(생성 시점에 capability 상수에서 뽑은 '생성용 스키마'를 structured output 에 제약)을 내용 필드(entities[].items, params)에도 확장한다 — type 이 선택되면 그 카테고리의 reads.content/reads.params 로 필드가 제한된 스키마를 LLM structured output 에 넘긴다. List 를 고른 순간 avatar 를 애초에 못 쓴다.
2. Summary 생성 파이프라인의 capabilityCheck.ts/strictCapability 는 생성 검증 단계에서 기본값을 켠다 — 카테고리 불일치(성립 조건 미충족, 안 읽는 필드 존재)를 통과시키지 않고 재생성 루프를 돈다.
3. 위 둘을 실제로 하면 이 케이스는 대부분 1번에서 막혀 2번까지 갈 일이 드물겠지만, 안전망으로 둘 다 둔다.

B-32 근거 (2026-08-28 열림) N3 과 N4 는 부모를 벗겨 자식을 최상위 components[] 로 올린다. 반복하면 최상위 원소 수가 늘어난다. design/content-binding-contract.md 3.7절 예시는 1개에서 9개가 됐다. 규약 8.6절이 "원소 수 상한은 두지 않는다. 실데이터에 다중 컴포넌트 페이지가 아직 없어 근거 있는 숫자를 정할 수 없다"로 두었으므로 규약 위반은 아니다. 다만 한 페이지에 9개를 배치할 수 있는지는 배치 엔진의 몫이고 확인한 바 없다. 상한을 둘지, 두면 넘칠 때 N5 로 보낼지 정해야 한다.

B-32 결정 (2026-09-05 정원석) 상한을 두지 않는다. 최신 배치 정책은 Root-Peeling/Re-Peeling으로 갈라진 컴포넌트를 한 페이지에 다 욱여넣지 않고 페이지마다 나눠 배치한다 — 그래서 개수가 9개든 20개든 여러 페이지에 걸쳐 배치하면 되고, 렌더링 실패 위험이 없다. 규약 8.6절 현행(상한 없음) 유지로 닫는다.

부수 아이디어 (2026-09-05, I-11 설계 메모로 이관) Root-Peeling이 잃는 것 중 하나가 "형제 사이의 공간적 인접성"이다(N-R1). 그냥 흩어 배치하는 대신, 같은 부모에서 갈라져 나온 조각들을 배치 시점에 출처 태그로 묶어 크기를 고려해 한 화면/페이지에 2~3개씩 클러스터로 배치하면 이 인접성을 부분적으로 복원할 수 있다. 이건 스키마 결정이 아니라 I-11(복합 구조 fallback 오케스트레이션)의 구현 설계 문제라 그쪽에 메모로 남긴다.

B-26 근거 (2026-08-04 닫힘) 3.2절은 행마다 완결된 경로로 읽히는데 3.3절은 "방문한 카테고리를 기록하고 중복을 건너뛴다"로 순회를 전제했고 3.5절은 엣지 집합이었다. 셋이 같은 것을 다르게 말했다. 행을 이어 붙여 읽으면 나가는 자리가 둘 이상인 카테고리 34종 중 21종에서 우선순위가 정해지지 않는다. 예를 들어 Versus 행은 ComparisonTable → List 인데 ComparisonTable 자기 행은 ListingTable → List 다. 그래프로 정했다. 각 행이 그 카테고리의 후속 우선순위 목록이고 자기 행만 따라간다. 이 정의에서 순환이 불가능해져 방문 기록이 필요 없어지고, 4절의 두 칸 상한도 '어느 행도 대체 후보를 셋 이상 두지 않는다'는 표의 성질이 된다. 3.5절 엣지 표를 이 정의로 다시 계산해 55행(고유 51)에서 75행이 됐다.

B-27 근거 (2026-08-04 열림) 규약 5절 1번은 "성립 조건을 못 채우면 그 카테고리가 후보에서 빠진다"이고 성립 조건에는 개수 범위가 들어 있다. 그런데 capability-table.md 3.4절 P8 은 "도착의 개수 상한을 넘으면 초과분을 마지막 항목의 items 로 접는다"이다. 같은 상황에 답이 둘이다. 항목 20개짜리 Steps 가 Timeline(상한 15)으로 물러날 때, 규칙 1대로면 Timeline 이 후보에서 빠지고 P8 대로면 5개를 접어 Timeline 으로 그린다.

B-27 결정 (2026-09-05 정원석) 규칙 1(탈락)로 확정, P8(접기) 폐기. 접으면 정보는 안 사라지지만 마지막 항목 하나에 텍스트가 몰려 overflow가 눈에 띄게 나기 쉽다 — "내용을 안 버렸다"는 게 "보기 좋다"를 보장하지 않는다. 탈락시키면 fallback 사다리를 계속 타고 내려가는데, 모든 사다리 끝에는 개수 상한이 없는 안전망(List 등)이 있으므로 정보도 안 사라지고 렌더링도 안 깨진다. 표에 P8이 붙어 있던 16개 엣지 전부에서 뗐다(capability-table.md 3.4·3.5절).

부수 효과: P8 폐기로 HighlightedMessage("정확히 1")가 더 이상 개수와 무관하게 항상 성립하지 않는다. KPIKeyMetric_BigNumber, KPIKeyMetric_Gauge, Utterance_QuoteTestimonial 세 카테고리의 체인이 HighlightedMessage에서 끝나고 있었는데, 이러면 개수 초과 질의가 그 지점에서 사다리째 막힌다. 셋 다 끝에 List를 안전망으로 추가했다(3.2·3.5절). 엣지 수는 127→130.

부수적으로 확인된 것 — 개수 상한의 적용 범위. 이 논의 중에 "Timeline의 상한 15" 같은 개수 조건이 Summary 생성기·질의 쪽에만 적용되는 실용적 제약이라는 게 명확해졌다 — 검색 풀의 다양성 한계에 맞춘 것이다. I.I.S.가 실제 디자인의 구조를 인식·태깅할 때는 이 상한을 적용하지 않는다 — 실제 디자인이 20단계짜리 Timeline이어도 그건 그냥 Timeline이다. capability-table.md 2절에 이 구분을 명시했다. 지금 표는 두 해석을 섞어 쓰고 있었다. Steps → Timeline, Pyramid → Staircase, GanttChart → Timeline 셋에는 P8 이 붙어 있는데 같은 조건인 QuoteTestimonial → HighlightedMessage(도착 개수 '정확히 1')에는 빠져 있었다. 2026-08-04 에 P8 을 붙여 표 안에서는 일관되게 했으나, 규칙 1 과 P8 중 무엇이 우선인지는 정해야 한다. 이석님과 정할 항목이다.

B-28 근거 (2026-08-04 열림) capability-table.md 3.4절 규칙 여덟은 fallback 엣지 하나하나에 붙어 있다. 그래서 카테고리가 그대로 성립해 fallback 이 일어나지 않으면 적용될 자리가 없다. 그런데 처음 고른 카테고리도 structure 의 전부를 읽지는 않는다. 규약 1절이 "선언되지 않은 것은 무시한다"로 두었으므로 그냥 지나간다.

B-28 결정 (2026-09-05 정원석) P3·P7("못 읽는 건 버리지 않고 옮긴다")을 fallback 여부와 무관하게 항상 적용한다. 새 판단이 아니라 이미 있는 원칙(내용은 안 버린다)의 적용 범위 누락을 메우는 것이다 — "fallback 엣지에만 건다"는 의도된 제한이 아니라 구현 범위를 좁게 잡은 것으로 보인다. 최종 선택된 카테고리가 fallback을 거쳤든 첫 선택이든 상관없이, 그 카테고리가 못 읽는 relations·내용 필드는 P3·P7대로 옮긴다. 실물 사례가 있다. compares 를 성립 조건으로 선언한 카테고리는 AttributeComparison.Versus 하나뿐이고 개수 조건이 '정확히 2' 다. 3항 이상을 비교하는 입력은 ComparisonTable 로 가는데 ComparisonTable 은 관계를 안 읽는다. 그래서 '가격과 리전 수는 반비례한다' 같은 relation.desc 가 fallback 없이도 사라진다 (yaml-examples.md 3.2절). 규약 5절 4번의 문장이 이 경우를 덮는 것처럼 읽힌다. "선택된 카테고리가 못 읽는 것은 버리지 않고 옮긴다"인데, 옮기는 규칙은 엣지에만 있다. 규칙 P3 과 P7 을 '카테고리 하나에 대해서도' 적용하도록 넓힐지 정해야 한다. 넓히면 B-16 의 관계 어휘 확장 논의도 부담이 줄어든다.

B-24 근거 (2026-08-03 열림) 허재영님이 "41종(v7 단어장 그대로)"라는 Slack 공지 표현이 부정확하다고 지적했다. 단어장은 49종이고 8종이 의도적으로 빠졌다 (Slack). 문서는 이미 맞다. capability-table.md 범위 절이 "49종에서 페이지 역할 4종과 지도 전용 4종을 뺀 41종"으로 적어 두었다. 틀린 것은 공지 문구다. 그런데 범위 자체를 다시 볼 이유가 생겼다. 49종 전량으로 여는 편이 나을 근거가 셋이다.

1. B-11 결정 구조와 맞는다. contract 스키마는 type: string 으로 열고 생성용 enum 은 capability 상수에서 뽑기로 했다. 즉 enum 은 capability 의 파생물이다. 그러면 단어장 49종을 capability 에 다 넣고 8종은 '질의 대상 아님'으로 표시하는 것이 층이 맞다. 지금은 capability 자체가 41종이라 파생 이전에 범위가 잘려 있다.
2. 페이지 역할 4종은 색인에 실재한다. 유효 컴포넌트 v3.5 가 page role 확대(Opening, SectionDivider, Ending 허용)를 반영했고, 페이지 역할 태그는 Page Role 을 승계해 logic 으로 태깅한다(C-4). 색인에 있는 값을 질의로 못 적으면 대조가 비대칭이 된다.
3. 지도 전용 4종을 뺀 근거는 성립 조건 판단이다. '지도 데이터가 있어야 성립해 structure 가 표현할 대상이 아니다'는 capability 의 성립 조건 이야기이고, 어휘에서 빼는 것과는 층이 다르다. capability 에서 '성립 불가'로 두면 같은 효과가 나면서 단어장과 어휘가 어긋나지 않는다. 반대 근거도 있다. 페이지 역할은 의미 구조가 아니라 페이지에서의 자리다. Content Archetype 과 semantic tag 는 서로 다른 것을 분류한다(README.md 2절 '헷갈리기 쉬운 셋' 둘째). 축이 다른 값을 한 enum 에 넣으면 생성기가 둘을 섞을 위험이 있다. 판단이 필요하다. 지금 문서는 41종 유지이고, 이 항목이 닫히기 전에는 41종 표기를 바꾸지 않는다.

B-10 근거 tree 는 답이 나왔다. hierarchical 이 web-2 저장 스키마의 vizType 6종에 들어 있고 jari 에 hierarchy_tree 머신이 있다. TreeItem 이 아니라 스마트 다이어그램이다 (smart-diagram-data-model.md 11절). nested_scope 는 concentric_rectangles 가 후보였다.

B-10 결정 (2026-09-05 정원석). nested_scope는 SmartObject가 아니라 TreeItem(일반 컨테이너)으로 본다. 지금 엔진에 없는 것을 곧 생길 거라고 가정하고 판정을 미뤄두면 안 된다(B-36과 같은 원칙). #프레젠테이션트라이브_스마트다이어그램 채널의 실제 vizType 목록(2026-06-23, 한유진: hub and spoke·hierarchy tree·cycle·staircase·venn diagram·timeline 6종)에 concentric_rectangles는 없고, "동심원" 관련 언급 자체가 그 채널에 없어 계획도 확인되지 않는다. 다행히 생성 쪽엔 이미 안전장치가 있다 — ScopeCoverage_NestedScope는 capability-table.md 10절(B-36)에서 이미 "둘 다 가능"(항목 수가 적고 direction/shape뿐이라 Native Complex Element 없이 손그림으로도 대치 가능)으로 분류돼 있어, 없는 엔진에 기대는 fallback 경로 자체가 없다. 엔진이 실제로 생기면 그때 SmartObject로 재분류한다.

B-11 결정 전 검토 기록 미매핑 라벨이 질의의 절반 이상이라 좁은 enum 을 유지하면 tag 병기가 사실상 필수였다(격차표는 semantic-taxonomy-v7.md 4절). 이 방식은 스키마 고정 원칙과 충돌한다. enum 이 스키마 안에 있으면 단어장이 늘 때마다 스키마가 바뀐다. 셋째 선택지가 결정을 갈랐다. contract 스키마는 type: string 으로 열어 두고, 생성 시점에는 capability 상수에서 enum 을 뽑아 낀 '생성용 스키마'를 따로 조립해 structured output 에 넘긴다. 어휘가 늘어도 스키마 버전이 안 바뀌고 enum 제약도 유지된다. 관련 사실로, 현행 예시 3종이 이미 enum 밖 값을 썼다(H절).

B-13 근거 A-4 와 같은 건이다. 저장 contract 가 version: 2 로 바뀌었으므로 yaml-examples.md Appendix A 기준 설계를 다시 봐야 한다 (smart-diagram-data-model.md 8절, 12절).

2026-09-04 갱신 (정원석) 이 어댑터가 언제 필요한지부터 다시 봤다. poc-module-map.md 2.5절의 대치 경로 셋(PoC 규약 RLSC binding.ts, 4단계 comp-sign, 5단계 property T-8)은 전부 이미 존재하는 실제 컴포넌트(디자이너가 도형·선·텍스트로 만든, native Smart Diagram/Chart 요소가 아니어도 되는 진짜 Design Object)를 검색으로 찾아 그 구조에 내용만 채우는 방식이다. I.I.S. 가 구조만 제대로 뽑으면 native 요소가 아닌 "가짜"(합성 아님) 컴포넌트도 이 세 경로로 대치 가능하고, 이 셋은 dataVizProps/chartProps 어댑터에 의존하지 않는다. 이 어댑터가 필요한 경우는 검색이 실패했을 때 처음부터 새로 합성(synthesis)하는, 아직 착수도 안 한 네 번째 경로뿐이다. 모듈 지도 2.2절 구현 상태 표 어디에도 이 합성 경로가 없다 — 지금 로드맵의 주력이 아니다. 실측 결과도 함께 남긴다. 다이어그램 계열(dataVizProps)은 smart-object-ax 32종 중 화면에 그려지고 에디터가 저장까지 하는 것이 tree(hierarchical)와 venn 둘뿐이다(10절 대응표). 나머지(nested_scope, pyramid, quote 등)는 jari 렌더 머신이 없어 지금은 검증 불가다. 차트 계열(chartProps)은 리스크가 낮다 — ChartBuilder(miricanvas-web-2 packages/engine/miricanvas-engine-util)가 type·dataSource(2차원 배열)·options 세 값만 받아 축·범례·그리드·계열까지 전부 합성해준다. dataSource: Cell[][] 가 dataset.matrix.rows((string|number|null)[][])와 구조적으로 거의 1:1이라, rootComponent 같은 무거운 재귀 트리를 손으로 조립할 필요가 없다. 결론: 지금 당장 급한 항목이 아니다(주력 대치 경로 셋과 무관). 나중에 합성 경로가 실제로 필요해지면, 다이어그램은 tree/venn 만 실측하고 나머지는 jari 확장을 기다리고, 차트는 ChartBuilder 입력 세 값만 만들면 된다.

B-14 근거 semanticTaxonomy.gen.ts 와 같은 방식이다. 내용 41종은 capability-table.md, 상수 모양은 그 문서 5절에 있다.

B-15 근거 page 수준 relations 를 optional 로 열고 생성기는 채우지 않는다. 블록을 가리킬 수단이 필요하므로 컴포넌트 블록에 optional id 도 함께 연다. 근거와 실데이터는 G절에 있다.

B-17 근거 (2026-08-03 닫힘) 규약 5절 4번이 "못 그리는 relations 나 슬롯은 삭제하지 않고 텍스트로 흘려보낸다"까지만 정한다. 어디로 흘려보내는지가 없다. capability-table.md 3절의 '한 번 따라갈 때 잃는 것' 열도 서술이지 규칙이 아니다. Gauge → BigNumber 행은 "목표 대비 위치"를 잃는다고만 적고 measure.target 과 thresholds 가 어디로 가는지는 안 정한다. 지금은 fallback 할 때마다 구현이 알아서 버린다. A 로 정했다 (2026-08-03 정원석). 엣지마다 정의한다. 다만 손으로 쓰지 않고, 규칙 여덟(P1~P8)을 세운 뒤 각 엣지에 어느 규칙이 걸리는지를 2절 capability 에서 계산했다. 그래서 표가 capability 와 어긋날 수 없다. 엣지 수는 결정 당시 55였고 2026-08-04 에 75로 다시 계산했다 (B-26). 계산하다가 2절의 결함 하나가 드러났다. '선택 속성' 열이 내용 필드(period, speaker, avatar)와 표현 선택(orientation, apex)을 섞어 담고 있어서, 그대로 계산하면 Timeline → Steps 에서 시각(period)을 버리는 것으로 나왔다. 둘을 갈라 내용은 옮기고 표현만 버리도록 고쳤다.

B-16 근거 (2026-08-02 닫힘) compares 로 확정했고 규약 스키마에 들어갔다. 아래는 결정 전 기록이다. 지금 enum 이 intersects 하나뿐이라 yaml-examples.md 2.3 이 versus 대비쌍을 intersects 로 적는다. venn 후보가 이 relation 을 교집합으로 소비하면 대비 입력이 벤으로 잘못 그려진다. 판정 기준과 구성은 2026-08-02 에 확정했다(G절). intersects 유지, 비교 관계 1종 추가. 남은 것은 비교 관계의 이름 확정(compares 제안)과 예시 2.3 수정이다 (projection-model.md 7절).

C. 2단계 배포#

사실상 스킵, 8/18 폐기 (2026-08-07 확정, MOR-1774, 근거는 MOR-1939 코멘트). 2단계를 안 하고 4단계로 직행한다. 새 배포 날짜는 없다. 아래 항목 중 태깅·적재·BE 전달 인프라(C-1, C-2, C-6, C-7)는 4단계에서도 그대로 쓰이므로 남겨 두고, '2단계 배포 전' 이라는 마감 표현만 걷어낸다.

C-2 근거 누가 무엇을 언제 어떻게 하는지를 공유한다. 경로는 류민 → 박지우 → 최운식이다. pipeline-flow.md 4절로 1차 그림을 확보했다. C-1·C-2 닫힘 (2026-09-05 정원석) — 낡은 전제로 무효화. 둘 다 "데이터 버전 2.0 시절의 page 단위 semantic tagging을 BE에 전달"하는 구조를 전제로 한 항목인데, 지금은 data version 2.5 추출까지 논의가 진행 중이고, page 단위 tagging은 이미 I.I.S.(component 단위 구조 인식)가 대체하는 방향으로 계획돼 있다. 옛 파이프라인 단계에 대한 협의·공유 항목이라 지금 붙잡을 이유가 없다.

C-3 결론 (2026-08-02) 4단계(MOR-1776)에 넣는다. MOR-1775는 실행하지 않음 상태를 유지하고 티켓을 새로 만들지 않는다. 감수하는 것 4단계에서 생성기 교체와 node 태그와 검색 변경이 한 번에 일어나므로, 품질이 떨어졌을 때 원인이 셋 중 무엇인지 가리기 어렵다(README.md 4절이 지적한 문제). 4단계 착수 때 단계별 계측 지점을 설계로 보완한다.

C-4 근거 방향은 2026-07-27 구두논의에서 정해졌다 (Slack). 페이지 역할 태그 넷(Opening, Agenda, SectionDivider, Ending)은 페이지의 Page Role 을 그대로 승계하고, 다른 semantic tag 와 달리 AI 가 아니라 logic 으로 태깅한다. 남은 판단이었던 것 이 태그를 가진 컴포넌트에 유효컴포넌트 조건을 추가할지, 같은 페이지에서 최상위 node 만 valid 로 볼지였다. 걱정의 실체는 "페이지 단위 라벨을 그대로 승계"하면 한 페이지 안 여러 노드가 일반 유효조건을 각각 통과해 같은 슬라이드의 조각들이 중복 후보로 검색 풀에 여러 개 들어갈 수 있다는 것이었다. 닫힘 (2026-09-05 정원석) — 전제 자체가 무효화. 오늘 Opening 판정을 "페이지 위치 승계"가 아니라 "제목+발표자/날짜/소속 같은 내용 조건"으로 바꾸면서(spec/capability-table.md 2.6절), PageNavigation 4종도 다른 41종과 똑같이 I.I.S.가 구조·내용을 보고 경계를 판단하는 방식으로 넘어갔다. "페이지 라벨을 그냥 승계"하는 로직 기반 태깅이 아니라 다른 카테고리처럼 성립 조건을 만족하는 노드를 정상적으로 하나씩 골라내므로, C-4가 걱정하던 "페이지당 여러 개 중복 후보" 문제는 애초에 로직 승계 방식에서만 생기던 것이고 지금은 발생 조건 자체가 사라졌다. 별도 유효컴포넌트 조건을 추가하지 않는다.

C-5 결론 (2026-08-02) 별도 정책을 두지 않는다. fallback 순서가 처리한다. 마지막 fallback 이 셋(List, LongFormTextLayout, HighlightedMessage)이고 셋 다 개수 조건만 보므로 언제나 하나는 성립한다. 빈 결과를 사용자에게 보여줄 일이 없다 (capability-table.md 3.0절). 저품질 결과에 대한 임계값 정책은 두지 않는다. 기술적 대치 실패는 에러 처리이지 규약 사안이 아니다.

C-6 근거 7/31 에 크게 진척됐다. MOR-1814 "유효컴포넌트 v3.5 증량분과 semantic tag 확장 전량 재전달(data version 2.2)" 이 킥오프 없이 계획대로 진행됐고, design_object_semantic_tags 에 version='2.2' 가 적재됐다. 남은 것은 semantic tag 수령분 검사와 S3 업로드다(7/31 기준 차주 월요일 목표).

C-7 근거 현재 README.md 3절은 2026-07-22 적재분(83,771건) 스냅샷이다. C-6 완료가 선행 조건이다.

C-8 근거 김수현님은 GitHub 계정이 없어 저장소 문서를 못 본다. 기술 논의가 정리되면 Confluence 로 발행해 알리기로 스레드에서 약속했다 (2026-08-02).

D. 스쿼드 차원에서 정할 것#

내 결정이 아닌 것들이다.

D-1 근거 둘 다 아니고 태그 군(tier)이다. comp-sign v4.3.8 comp-match/semanticTags.ts 가 0군(사용자 지정), 1군(LLM 추정), 2군(그 외)으로 후보 풀을 채운다. 군 순서가 점수보다 절대 우선하며 태그 일치 가점은 없다. 남은 것은 이 방식을 규약에 반영하는 것이고, I-5 다.

D-2 근거 7/24 회의에서 "리스트 먼저 제품화"로 방향은 잡혔다. 질의 쪽 분포로 근거가 보강됐다. 색인은 List 81.1% 인데 질의는 31.96% 이고 ListingTable 과 ComparisonTable 수요가 두텁다 (semantic-taxonomy-v7.md 3절). 닫힘 (2026-08-07) MOR-1939 코멘트로 김수현님이 답했다. 2단계 배포 자체가 스킵되므로 List 편중을 안고 2단계를 낼지는 더 이상 결정할 문제가 아니다. List 편중 대응은 4단계 fallback map(MOR-1909)으로 넘어간다.

D-3 범위 리스트를 Q3 지원 4종에 포함할지도 함께 정한다.

D-4 근거 컴포넌트 색인(Search Signature v2)은 이미 분리돼 있어 대상이 아니다.

D-5 근거 MOR-1425, MOR-1448, MOR-1426, MOR-1427 은 RAT pod 쪽에서 2026년 6월 중순부터 정지 상태다. PoC 는 plan/node-tag-and-property-poc-blueprint.md D-2 대로 같은 출력을 src/lib/visual-summary/iis/ 에서 대행 생산한다. 닫힘 (2026-08-22) RAT pod 재개 시점을 4단계 착수 조건으로 두지 않는다. 출력 계약(동 blueprint 9절)을 우리가 먼저 정하고 PoC 에서 경계·속성·T-5/T-6/T-7 을 계속 진행한다. RAT pod 와의 정합은 교체 가능한 계약 제안으로만 맞춘다. 모듈 지도는 plan/poc-module-map.md 4절.

D-6 근거 README.md 2절 제안 상태다.

D-7 근거 8.7절이 정의하는 "중첩 컴포넌트"(entity.components[]) 자체는 자식 type 이 부모와 같든 다르든 이미 표현 가능하다. 이종중첩은 그중에서도 자식들의 type 이 서로 다른 경우(예: 리스트 안에 리스트와 차트가 동시에 포함)를 가리키며, 4단계 boundary 태깅/node 태그 PoC 준비 중 Slack 공유로 처음 논의됐다. 이런 케이스에 내용대치를 하려면 기존 조합 컴포넌트와는 별개의 대치 로직이 필요한데, 실제로는 대부분 조합 Fallback 만으로 해결될 것으로 예상돼 WSJF 가 낮다. 검색 풀에서 애초에 제외하는 편이 4단계 실행을 더 빠르게 만든다는 것이 2026-08-11 체크인 결론이다. 수량 파악은 별도로 허재영, 황현진이 맡았고 2026-08-13 에 끝났다 — 1,000개 표본에서 1.10%, 전체 약 2,014개(reference/2026-08-13-이종중첩-수량-산출/, MOR-2048). 제외로 잃는 양이 상한에서도 전체의 2% 미만이므로 이 결정을 되돌릴 근거는 나오지 않았다.

D-9 근거 (2026-09-08 닫힘) 결정은 #mordor스쿼드 한 스레드에서 났고, 같은 날 세 대화가 이어졌다. 15:21 허재영이 "4단계 바운더리까지만 깎아 두고 있었는데 5단계 프로퍼티 깎는 체계를 구축하겠다"고 밝혔고 (Slack), 16:54 정원석이 이석·홍지혜와의 구두 논의를 공지하며 컴포넌트 풀을 I.I.S. (Semantic Component - Structure and Property) 로 10만 건 추출한다고 적었다 (Slack). 17:46 허재영이 MOR-1776 하위 티켓 정리를 제안하자 17:51 정원석이 **"4단계 관련해서는 cancel 하고, 문서상으로 결정된 것들 최신화 하겠다"**고 답해 닫혔다 (Slack).

방식 노드 태그만 다는 단계를 따로 완주하지 않고, 경계와 속성을 한 추출 묶음으로 뽑아 노드 단위 검색·대치를 바로 붙인다. 실행은 이미 그 방향이었다 — K-10(경계 4,764건·속성 3,955건, 2026-09-06), K-9(노드 검색 엔진 배선, 2026-09-07). 후속은 MOR-2381(속성 추출 평가)과 MOR-2415(경계·속성 10만 건 추출)이다.

Jira (2026-09-14 조회) MOR-1924·MOR-1925·MOR-1926·MOR-1927·MOR-1929·MOR-1936 이 Cancelled 다. D-3 이 "대치 로직 관점의 최종 확인은 MOR-1926 PoC 가 승계한다"고 적어 뒀는데, 그 티켓이 실행 없이 Cancelled 됐다 — 이 결정은 해당 PoC 실측 없이 났다. 마일스톤 MOR-1776 은 아직 In Progress 이고 due 2026-09-30 이 그대로 남아 있다.

D-8 근거 (2026-08-28 열림) D-7 은 색인 쪽 정책이고, 2026-08-28 에 정한 복합 구조 순서는 질의 쪽 정책이다(spec/capability-table.md 3.6절). 둘이 만나는 지점에서 문제가 하나 생긴다. D-7 이 유지되는 동안 N1(질의 트리 전체를 담은 후보 찾기)과 N2(모양을 고정한 채 카테고리만 내리기)는 이종 구조 질의에서 언제나 후보가 0이다. 둘 다 이종중첩인 모양 그대로 후보를 찾는데, 그런 템플릿이 풀에서 빠져 있기 때문이다. 즉 이종 질의는 실질적으로 N3 에서 시작한다(design/content-binding-contract.md 3.7.5절).

D-7 의 결정 근거가 "대부분 조합 Fallback 만으로 해결될 것으로 예상"이었으므로, N3 부터 N5 의 결과 품질이 그 예상의 검증 자료다. 검증 전에 되돌리지 않는다. 되돌릴 후보 수는 실측돼 있다(전체 약 2,014개, 1,126~3,586). 판정 자료는 N3 이후 경로로 대치한 결과의 judge 점수이고, 그것을 재려면 I-11(오케스트레이션 코드)이 먼저다.

E. 7/24 회의에서 새로 받은 것#

E-2 근거 41종 fallback 순서 초안은 완성했다 (capability-table.md 3절). 남은 것은 스쿼드 검토이고 MOR-1909 (49종 fallback map 확정)의 할 일에 들어 있다. fallback 순서의 카테고리 선택 41건이 설계 판단이라 근거가 실측이 아니다(그 문서 8절).

E-2 갱신 (2026-08-13) 정원석이 v1 초안(김수현, 허재영 작성 시트)을 검토한 v2 를 plan/fallback-map-review-2026-08-13.md 로 올렸다 (PR #69). 49종 전량으로 확장했고 두 칸 상한 폐지, 종단 대표값 규칙, ComboChart 조건부 규칙을 담았다. 허재영, 김수현, 류민 확인 대기. E-2 갱신 (2026-08-17) 허재영 1차 피드백(Slack) 중 PictogramChart, BarChart, StackedBarChart normalize 를 plan 문서와 spec/capability-table.md(45종, 엣지 113개)에 반영했다. schema-v0.5.md 규약 5절 2번(두 칸 상한)도 동기화했다. 남은 것: List, SWOT, HighlightedMessage, LongFormTextLayout, ProfileCard, Funnel, TableOfContents 7행 원저자 확인, v7 우선순위(P1~P4) 문서 동기화, PageNavigation 4종 성립 조건(C-4 대기). 김수현, 류민 확인은 여전히 대기. E-2 갱신 (2026-08-27) PageNavigation 4종 성립 조건을 spec/capability-table.md 2.6절에 채웠다 — 정본 시트 값을 옮긴 plan/page-navigation-capability-draft.md 기준. C-4(검색 풀 정책)는 템플릿 공급 문제라 성립 조건의 선행 조건이 아니라고 판단해 대기를 풀었다(허재영 질의, Slack). Opening 맨 앞장 전용 여부도 같은 날 닫혔다 — 최신 정본 시트가 Opening/Ending 을 분리한다(허재영 확인, 초안 4.1절). 검증 코드 반영은 PR #2264 (measure 파생·평탄화 셈법 정합 포함).

E-2 는 B-1(등급 3단계), B-4(포기 가능 여부)와 사실상 한 덩어리다. 함께 푸는 편이 낫다.

E2. Placeholder Text Slot 효과 분석의 후속 (2026-09-20 신설)#

근거와 수치는 evaluation/placeholder-effect.md 가 SSoT 다. 여기에는 항목만 둔다(WRITING.md 5.3절).

E2 결정 사항 (2026-09-20) judge 판정문에서 파생한 지표(증상 태그, residue)를 결론 근거로 인용하지 않는다. 검출률이 판정문 길이에 10배 끌리고, 처치가 결과와 같은 문장에서 나온다 (보고서 2.3절).

F. 마감 후로 미룬 것 (사후 검증)#

YAML 초안 확정(2026-08-01)을 뒤집을 근거가 있는지 나중에 확인하는 용도다. 다른 마감이 걸려 있지 않을 때 돌린다.

F-1 닫힘 (2026-09-05 정원석). 포맷 비교실험은 불필요하다. YAML로 확정된 상태를 재검토할 근거가 없다. 전제 확인 완료 (2026-08-02, 정원석) LLM 이 YAML 을 직접 생성한다. YAML 채택 이유가 추론 속도(생성 토큰 절감)라서 JSON 생성 후 직렬화는 가치가 없다.

F-2 설계 YAML 을 골랐으므로 조건부로 생긴 부채다. "파싱은 됐는데 타입이 뒤바뀐" 건을 별도로 세야 한다. YAML 생성기 교체 작업(C-3)과 묶여야 한다.

G. 최근 해소된 것#

되살아나지 않게 기록해 둔다.

G.1 결론의 근거#

type 표기 처음에는 { major, minor } 두 필드였다. 근거 셋 중 둘이 실측과 어긋나 같은 날 정정했다. 결합 문자열 62값(대분류 21 + 결합 41) enum 은 두 필드 방식과 거부하는 입력 집합이 완전히 같고(어긋난 조합, 없는 대분류, 없는 중분류, 대분류만 적기 전부 동일), 토큰은 18종 기준 4.6% 적다. 그리고 저장 키가 이미 결합 문자열이라 두 필드로 두면 표기가 셋이 된다. semantic-taxonomy-v7.md 0절이 "두 형식을 섞으면 조회가 조용히 0건이 된다"는 사고 기록이 있다. 구분자는 점이다. 저장 키는 밑줄이고, 검색 모듈이 받는 즉시 점을 밑줄로 바꾼다.

entity.id LLM 이 식별자를 지을 이유가 없다. 읽는 곳은 relations[].of 하나인데 relations 는 어디서도 필수가 아니다. 비용은 둘이다. 토큰이 18종 기준 5.9% 늘고, 같은 내용에 다른 이름이 나와 F-1 재현성 지표가 같은 결과를 불일치로 센다. id 패턴이 ASCII 만 받는 것도 한국어 입력에서 실패 자리를 하나 늘린다. 그래서 생성물에서 빼고 파싱 직후 배열 순서로 매긴다. relations[].of 는 label 로 적고 후처리가 id 로 바꾼다.

생성 메커니즘 YAML 채택 이유가 추론 속도(생성 토큰 절감)라서, JSON 으로 생성한 뒤 YAML 로 직렬화하는 방식은 쓰지 않는다. 검증은 YAML 을 JSON 으로 변환해 수행한다. v0.2 원문의 structured output 서술을 대체한다.

최상위 형태 단일 형태는 제거하고, 컴포넌트가 하나면 길이 1 배열이다. 소비자 분기가 하나로 줄고 중첩 깊이 어긋남이 없어진다.

component.type 어휘와 표기 페이지 역할 4종과 지도 전용 4종은 제외한다. 표기는 { major, minor } 중첩 구조로 major 별 허용 minor 를 스키마가 강제하고, minor 는 optional 이다. 저장과 조회 키는 결합값 {major}_{minor} 다. semantic-taxonomy-v7.md 4절 격차표는 이 결정으로 소멸 예정이다.

계층과 장식 계층 존재는 children 과 entity.components[] 가, 계층 보존 요구는 component.type 이, 평탄화 허용 비용은 카테고리 fallback 순서가, 타이틀과 디스크립션 수준은 구조 파생이, 그림 장식은 색인 쪽 변형이 처리한다 (projection-model.md 6절). 이 진술은 2026-08-03 에 뒤집혔다. 계층은 nested 구조로 풀고, 장식은 Summary 가 축별 선호를 적는다. 위 문단에서 "타이틀과 디스크립션 수준은 구조 파생"과 "그림 장식은 색인 쪽 변형" 두 대목이 무효다. 나머지(계층 존재를 children 과 entity.components[] 가 담는다)는 그대로 유효하고, 오히려 B-3 뒤집힘의 근거가 됐다. 대체 문서는 design/decoration-model.md 다.

dataset 모양 component 별 허용 조건은 capability 테이블이 선언한다. 표 계열(ListingTable, ComparisonTable)도 matrix 로 담긴다. 현행 3종(gauge, stacked_bar, combo)은 컴포넌트명이라 '컴포넌트 결정을 데이터에 박지 않는다' 원칙 위반이었다.

relation 판정 기준 intersects 유지, 비교 관계는 compares 로 확정해 스키마에 넣었다(B-16). 전후 변화는 실사용 관측 후, 문제해결과 원인과 결합은 기각 (projection-model.md 7절).

한 페이지 원소 수 상한 실데이터에 다중 컴포넌트 페이지가 아직 없다. 질의 쪽은 block 하나에 중분류 라벨 하나를 붙이고(검증 시트 taxonomy_minor 단수), 색인 쪽 복수 태그는 83,771건 중 260건(0.3%)이며, yaml-examples.md 2절의 다중 예시 3종은 손으로 만든 것이다. 근거 없이 숫자를 박지 않는다. 과분할이 실제로 관측되면 그때 생성기 정책으로 건다.

원소 간 관계 page 수준 relations 를 optional 로 열고 생성기는 채우지 않는다. 블록을 가리킬 수단으로 컴포넌트 블록에 optional id 를 함께 연다. entity.components[] 와 같은 결정 구조다.

fallback 소유 생성기가 type 으로 카테고리를 정하고, 검색이 capability 로 그릴 수 있는지 확인한다. 못 그리면 fallback 순서를 따라간다(예: Gauge → BigNumber → List). alternatives 를 적어 두면 fallback 순서보다 먼저 본다. 처음 형태는 v0.3 4절의 "gauge → big_number → list" 다.

layouts 태깅 레이아웃 태깅은 존재하지만 RAT pod 내부용이고, 검색에는 컴포넌트 태깅만 쓴다. MOR-1755 본문 '확인 필요' 절이 근거다.

레이아웃 태깅도 있나? → 있긴한데 rat pod 에서 사용하는 데이터이며, 검색에는 쓰이지 않는다

원 Slack 근거도 달려 있다.

판별자 키 이름과 다중 래퍼 이름 hint → component, 그 안의 component → type, relation.kind → relation.type, dataset.kind → dataset.type, blocks[] → components[] 로 바꿨다. v0.4 는 component: { type, params, confidence } 와 structure 이고, 다중은 components[] 로 원소마다 { type, params, structure } 를 편다. 바꾼 이유는 셋이다. hint 는 내용이 아니라 세기를 가리켰다. component.params.apex 는 capability 테이블 pyramid 행의 성립 조건이라 참고값이 아닌데도 hint 안에 있었다. 그리고 type 은 RLSC LayoutContainer.type(형태)과 짝을 이루는 이름이라, 의미 축인 component.type 이 같은 키 이름을 쓰면 두 어휘의 대응이 드러난다. kind 와 type 이 섞여 있던 것은 type 으로 몰아 없앴다. 코드 비용은 0 이다. Visual Summary 는 packages/comp-sign 에 구현이 없다.

중첩 컴포넌트 표현 가능성만 열어 두고 켜는 시점은 생성기 정책과 capability 선언이 정한다. 단계가 늘어도 version 은 안 바뀐다. 원소끼리 중첩시키면 부모의 어느 슬롯인지 못 적어서 내용 대치가 위치를 잃는다. entity 가 곧 슬롯이라 여기 매단다. 소화 못 하는 컴포넌트는 규약 1절 '중첩은 평탄화된다'대로 부모 items 에 편다 (schema-v0.4.md 1절, 8-1절).

포맷 YAML 남은 것은 A-2 정렬과 F-1 사후 검증이다 (README.md 2.1절, schema-v0.4.md 6절).

3.5절 규칙 열 6행을 계산과 맞췄다 (2026-09-10, F5 전수 대조로 발견). NestedScope 에서 나가는 세 행(→List, →Pyramid, →Staircase)은 P3 이 남아 있었다 — B-34 로 children 요구가 빠지면서 옮길 내용이 없어졌는데 규칙 열이 안 따라왔다. PictogramChart→List, Calendar→Timeline, ComparisonTable→Versus 세 행은 P3 이 빠져 있었다 — P4(matrix 를 entities 로 편다)가 붙으면 열 내용이 items 로 가므로 P3 이 함께 붙고, 같은 문서의 다른 P4 엣지들은 "P1 P2 P3 P4" 로 적는다

P8 폐기(B-27)를 코드가 따라왔다 (2026-09-10). 3.4절이 2026-09-05 에 P8(개수 상한 초과분을 마지막 항목 items 로 접는다)을 폐기하고 "접지 않고 성립 조건 미충족으로 후보에서 탈락시킨다" 로 정했는데(정원석, MOR-1934), aippt projection.ts 는 그 뒤로도 P8 을 계산하고 projectStructure 가 실제로 접고 있었다. fallback.ts 가 projection 을 성립 판정보다 먼저 돌려 접힌 구조가 개수 조건을 통과했으므로 폐기 전과 같은 동작이었다. aippt PR #2399 에서 규칙 계산과 적용, acceptedWithP8 플래그, query.ts 필터, PoC 화면 칩을 전부 걷어냈다. 동작 확인: Steps 17개가 상한 15인 Timeline 에서 탈락하고 상한 없는 List 까지 내려가며 17개가 그대로 남는다 — 3.2절이 B-27 과 함께 List 안전망 세 행을 더한 이유가 이것이다

표 도착지 projection 규칙을 3.4절에 명문화했다 (2026-09-10 허재영 판단, 정원석 확인 대기). 3.4절은 BarChart→ComparisonTable·ListingTable 엣지를 "P1 P2, 옮길 것이 없다" 로 두어 matrix 가 Column.role 째 그대로 넘어간다. B-37 이 role 별 셀 타입을 카테고리와 무관하게 검사하므로, 값 열에 문자열이 섞인 차트는 표 도착지에서도 같은 사유로 탈락해 List 까지 내려갔다. 3.4절에 P2 보충을 넣어 표 도착지에서는 Column.role·axis·type 을 버리게 했다 — 2.5.1절이 이 셋을 순수 차트 어휘로 둔 것이 근거다. 코드가 먼저 그렇게 돌고 있었고 규약에 명문이 없던 것을 이번에 채웠다. 규칙 라벨은 안 바뀌고 손실 목록에 한 줄이 붙는다

3.5절 두 행의 규칙 열에 P5 가 빠져 있었다 (2026-09-10 발견). BigNumber→List 와 Gauge→List 가 "P1 P2 P3" 으로 적혀 있었는데, 출발지가 measure 를 읽고 List 는 못 읽으므로 P5(value 와 unit 을 entity 로 옮긴다)가 붙어야 한다. 같은 문서의 →HighlightedMessage 두 행은 P5 를 적고 있다. B-27 로 List 안전망 행을 더할 때 옆 행의 규칙 열을 덜 옮긴 것으로 보인다. 코드가 맞고 문서를 고쳤다

2.6절 내용 조건을 배치 가능성으로 좁혔다 (2026-09-10 허재영 판단, 정원석 확인 대기). 1절이 성립 조건을 "이게 없으면 그 종류로 배치가 불가능한 것" 으로 정의한다. 그 기준으로 42행의 "제목 + 발표자·날짜·소속 중 하나 이상" 은 조건이 아니다 — 제목만 있는 표지도 표지 레이아웃에 배치된다. 42행 내용 조건을 없애고 발표자·날짜·소속을 선택 내용으로 내렸다. 43행에서도 "번호와 제목을 나열한다" 를 빼고 "흐름·단계가 없다" 만 남겼다. 44·45행의 설명 문장도 성립 판정에 넣지 않는다(기계가 보는 것은 "본문 콘텐츠가 없다" 뿐이다). 그 결과 Opening·Ending·SectionDivider 는 구조로 구분되지 않는다 — 셋 다 entity 하나에 본문이 없다. 어느 종인지는 질의가 적은 type 과 I.I.S. 태깅이 정한다. 2026-09-05 정원석 확정("위치가 아니라 내용으로 판정한다")의 위치 조항은 그대로다

B-37 의 날짜 조항을 뺐다 — start·end·date 열은 형식을 강제하지 않는다 (2026-09-10 허재영 판단, 정원석 확인 대기). 종전 문구는 "ISO 문자열 또는 timestamp 숫자만, 임의 문자열 금지" 였다. 그 규칙으로는 달력과 간트가 실사용 입력에서 거의 성립하지 않는다 — 생성기 골든셋 v1 의 Calendar 10행과 GanttChart 10행이 전량 탈락했고, 그중 여덟은 입력에 달이 없어("3일 소아과 당직") ISO 로 옮기려면 없는 값을 지어내야 해서 골든셋을 고쳐도 풀리지 않았다. 날짜 셀은 계산 대상이 아니라 표시와 대치 대상이다 — "3월 4일" 을 그대로 담고, 내용 대치가 그 문자열을 검색해 바꾼다. 숫자 계약이 남는 곳은 value·x·y·size 뿐이다. 고친 곳은 spec/schema-v0.5.md 2.1절 주석이다

2.6절 Opening 산문을 개수에 맞췄다 (2026-09-10 허재영 판단, 정원석 확인 대기). 산문 괄호가 "제목·발표자·날짜가 각각 entity" 라고 적어 42행 개수 "정확히 1" 과 어긋났다. 셋을 각각 entity 로 두면 개수가 셋이 된다. 제목이 label 이고 발표자·날짜·소속은 그 entity 의 items 로 정정했다. 개수 열과 시트의 "단일 슬라이드 구조" 정의를 살린 표기이고, 구현과 시트본 골든셋 v1.5 의 Opening 세 행이 이미 이 모양이다. 42행의 내용 조건("제목이 있고 발표자·날짜·소속 중 하나 이상")은 2026-09-05 정원석 확정이라 그대로 둔다

2.5절 column.role 배정은 읽기 규칙이지 성립 조건이 아니다 (2026-09-09 허재영 확인). "x·y·size 는 산점도와 버블, start·end 는 간트, date 는 달력" 문장을 보고 선차트에 x 를 쓴 산출물을 위반으로 볼 뻔했으나, capability-table 1절 "여기 적히지 않은 것은 전부 무시한다" 와 2절 표(성립 조건에 role 없음)가 이미 답을 준다. 실제 위반은 B-37(셀 타입)이 잡는다 — x 열에 "2023년" 문자열이 들어간 것이 잘못이지 x 를 쓴 것이 잘못이 아니다. 골든셋 검수도 role 어휘 불일치는 인코딩 선택으로 다룬다

H. 문서 정합 백로그#

이 문서를 만들면서 드러난 repo 내부 불일치다.

• README.md 4절과 6절의 'layouts 태깅을 BE 에 전달할지 확정'이 4절 '확정된 것'과 모순이었다 → G 표로 정정 (2026-08-01)

• README.md 3절 컴포넌트 분포와 semantic-taxonomy-v7.md 3절 질의 분포가 서로 다른 것을 센다는 것을 3절 본문에도 명시할지 → 3절 머리의 '축 구분에 주의한다' 안내 상자가 이미 이 역할을 한다. 추가 명시 없이 닫음 (2026-08-02)

• schema-v0.4.md 11절 체크리스트를 이 문서로 완전히 이관 → 이관 완료. 11절은 포인터와 맥락 위치 안내만 남김 (2026-08-02)

• content-binding-contract.md 초판이 comp-sign 구현을 확인하지 않고 구간 ②③을 "빈칸"으로 적었다 → 실물 코드 확인 후 정정 (2026-08-01)

• schema-v0.4.md 10절이 2026-07-21 이전 상태를 근거로 쓰여 실물과 어긋난다 → 10절을 smart-diagram-data-model.md 포인터와 유효한 대응표만 남기고 줄였다. 낡은 진술 셋(TreeItem 분리, placeholder, v1 저장 contract)은 본문에서 제거 (2026-08-02)

• yaml-examples.md 예시가 component.type enum 밖 값을 써서 스키마 검증을 통과하지 못하던 문제 → 해소 (2026-08-02). 어휘가 41종으로 늘었고, 예시를 v0.5 표기로 다시 썼다. 본문 예시 18종 전량이 규약 스키마 검증을 통과하는 것을 확인했다

• 문체 통일 (WRITING.md 2.8) 2026-08-02 에 이 폴더와 root 문서를 해라체로 통일했다. 저장소의 기존 문서가 이미 해라체라 그쪽에 맞췄다. 인용 원문은 코드 블록으로 감싸 보존한다

• em dash 와 본문 가운뎃점 정리 (3.2, 3.3) 2026-08-02 에 이 폴더를 정리했다. 인용 원문(모듈 출력, 외부 문서 제목, Slack 과 코드 주석 인용)과 보존 문서(archive/), 허용 예외(표 셀, 메타 줄, 링크 나열의 가운뎃점)는 그대로 두었다. 저장소 나머지는 미정리다

• [~] markdown-summary-samples.md 의 표 20건 줄바꿈 (2026-08-02). 표를 담은 20건이 한 줄로 눌려 있었고 2건은 ** 표기가 잘려 있었다. 규칙 복원으로 20건 전량을 되돌렸고 열 수 검사를 통과했다(그 문서 0.1절). 남은 것은 원본 대조다. 시트(Drive 1wRBwx5...)에서 20건을 다시 뽑아 글자까지 일치하는지 확인해야 한다

• 이 저장소 나머지를 WRITING.md 기준으로 훑어 비유와 과장 표현 정리 (visual-summary/ 는 2026-08-02 에 전면 정리 완료)

• 계약 → contract 표기 통일 (3.4) visual-summary/ 는 2026-08-02 에 맞췄다. 저장소 나머지에 '저장 계약', '전달 계약', '입출력 계약' 등이 남아 있다

• SSOT → SSoT 표기 통일 (5.1) 이 폴더와 root 문서는 2026-08-02 에 맞췄다. 저장소 나머지에 옛 표기가 남아 있다

• B-14 의 자리 진술이 실물과 다르다 (2026-09-09 허재영 진술, 정원석 확인 대기). B-14(2026-08-02)는 "TS 상수를 packages/comp-sign 에 둔다" 고 적었는데, miricanvas-iui 의 packages/comp-sign 에는 capability 코드가 없고 상수(capability.ts)와 검증기(schema.ts, establish.ts, capabilityCheck.ts, validate.ts, vocabValidate.ts)는 전부 aippt-prisonbreak src/lib/visual-summary/ 에 있다. 상수와 검증기가 있는 곳은 aippt-prisonbreak 이고, iui 는 그것을 보고 따로 구현한다 로 B-14 문구를 정정한다. I-17(json 필드 확장)과 B-37 구현의 대상 repo 도 aippt-prisonbreak 다

• SWOT order 의 뜻이 표와 I.I.S. 속성 어휘에서 다르다 (2026-09-09). 2절 표는 order 를 "강점, 약점, 기회, 위협 순"(사분면 배치 순서, B-34 결정문도 같은 뜻)으로 두는데 aippt PROPERTY_PARAM_SPEC 은 boolean(그 순서인가)으로 본다. I.I.S. 의 enum 도 표에 없는 값(direction: backward, descending, rotation: counterclockwise)을 갖는다. 표가 값 어휘를 열거하고 I.I.S. 가 따라가야 한다 (I-17 ③)

• archive/projection-model.md 135행의 ./pipeline-flow.md 링크가 깨져 있다. 폴더를 장르로 재구성할 때 design/ 으로 옮겨진 파일인데 경로를 안 고쳤다. 보존 전용 문서라 본문은 안 건드리고 링크만 고칠지 판단이 필요하다 (2026-08-03 발견)

I. 내용 대치 contract#

고른 다음에 무엇을 어디에 어떻게 넣는가. 맥락과 근거는 content-binding-contract.md 에 있다. 규약이 '어떤 컴포넌트를 고를까'까지만 정의하고 그 다음 구간이 비어 있어서 생긴 묶음이다.

왜 이 묶음이 중요한가 2026-07-26 BAD 원인 분석에서 BAD 의 85% 가 렌더링이 아니라 컴포넌트와 내용이 안 맞는 문제로 나왔다. judge 채점 16,819행 집계에 BAD 200건 직접 분류를 더한 결과다 (Slack). 세부 원인은 텍스트 용량 초과, 매핑과 위계 오류, 슬롯 수 불일치, 대치 실패다. 넷 다 이 절이 다루는 구간이다.

전제 구현은 이미 상당 부분 있다. 이석님의 miridih/miricanvas-iui packages/comp-sign v4.3.8 가 시그니처 추출, 검색, 랭킹, 내용 대치 네 단계와 semantic tag 소비를 모두 구현하고 있다. 비어 있는 것은 규약이다.

PoC 대치 경로 우선순위 (2026-08-22) 아래 표 순서가 실행 우선순위다. I-2(contract 정렬)는 이석·류민 협의가 필요해 병행하되, 공정한 3-way 비교는 I-8( pool bake )이 먼저다.

2026-08-22 fallback 이후 대치 계층 SSOT를 content-binding-contract.md 3.4~3.6절에 추가했다. PoC 대치 경로 비교 탭(/visual-summary)으로 RLSC vs comp-sign을 컴포넌트별로 나란히 볼 수 있다 (poc-guide.md 4.1절). 규약 RLSC는 실서비스·내용시각화 BE 경로가 아님을 3.4·3.6절에 명시했다.

I-1 Steps 의 sequence, rank, attach, span(MOR-1856)을 템플릿 삼아 P0 카테고리부터 채운다. 지금 열거하지 않으면 카테고리마다 다르게 설계된다. 이미 착수했다. 2026-07-27 standup 에 "semantic category 별 속성 정의 schema 파일을 repo schema 폴더에 만들어 초안 공유를 준비. Visual Summary YAML 생성 예시(v0.4)를 기준으로 category 마다 속성과 example 을 하나씩 붙이는 형태"로 적혀 있다 (Slack).

I-2 정렬할 셋은 노드 분류(CORE/DESC/DECO/OUT), 장식 등급(N, N+α, N+β), comp-sign 변형 3종(원본, Subtitle strip, Hl strip)이다. 세 곳이 같은 문제를 서로 다른 기준으로 풀고 있다. 맞추지 않으면 컴포넌트당 변형이 최대 9벌이 된다. B-1~B-4 가 이것에 종속된다. 2026-08-03 에 절반이 풀렸다. design/decoration-model.md 가 등급과 노드 분류를 한 축 집합으로 합쳤다. 장식 등급은 독립 개념이 아니라 노드 분류의 파생물이라는 것이 근거다(DESC 가 설명 축, DECO 가 장식 축). 나머지 절반인 B-19(comp-sign 변형 3종 처리 시점)도 2026-09-05에 닫혔다 — comp-sign은 색인 시점에 3벌을 미리 계산해 저장하는 현행 방식을 그대로 유지한다(대치 시점 처리로 옮기지 않는다). 장식 축은 애초에 색인을 곱하지 않으므로(4.5절, 검색 순위 신호일 뿐 노드를 지우거나 넣지 않는다) 9벌 곱셈 우려는 실재하지 않았다 — 컴포넌트당 색인은 comp-sign 변형 3벌에서 그친다.

I-3 ① 카테고리 층은 2026-08-02 에 정의됐다 (capability-table.md 3절 fallback 순서). 남은 것은 ② 등급 층이고 B-1, B-4, E-2 와 한 덩어리다. ② 등급 층의 설계는 2026-08-03 에 정해졌다 (design/decoration-model.md 4절). DECO 계열 축 둘에 값 셋이고 선언 층이 셋이다. 남은 것은 41종에 카테고리 기본값을 채우는 것과 색인이 role 표식을 받는 경로다. capability 테이블에 장식 축 열이 아직 없다(B-18, B-21, B-22).

I-4 text_map(용량), text_node_roles(role), semantic_tags(태그)는 있는데 sequence, rank, 노드 분류를 담는 자리가 없다. semantic_tags denormalize 방식이 선례다.

I-5 반영할 것은 태그 군 3단계, 채점 항목 20여 종, 대치 box 보정 옵션 4종이다. 규약이 구현보다 뒤에 있다. D-1 의 답도 여기서 확정된다.

I-6 BAD 원인 분석이 지목한 '가장 싸게 검증할 수 있는 다음 수'다 (2026-07-26). B-3 계층 결정의 실측 근거가 된다.

I-7 structure projection(P1~P8)과 구분한다. 이종 type 간 sequence, orientation 등을 슬롯에 맞추는 규칙이 없으면 5단계 대치 PoC(I-9)를 구현할 수 없다.

I-8 평가 pool은 design/content-binding-contract.md 3.6절과 plan/poc-module-map.md 3절이 SSOT다. indexPool 술어와 동일한 DO 집합에서 고정 subset을 정하고, 그 subset에 comp-sign(comp_signatures 또는 PoC 메모리 빌드), I.I.S. 경계, I.I.S. 속성을 bake 한다. 전량 17만 건은 dev/stg 판정(T-2 full) 때 별도로 다룬다.

I-9 5단계 property 대치는 T-7 추출만으로는 부족하다. 이종 type 사이에서 sequence, orientation 같은 속성을 서로 다른 슬롯에 맞추는 규칙인 **T-8(cross-type property projection, plan/node-tag-and-property-poc-blueprint.md 6절)**을 I-7이 정하고, pool bake(I-8) 후 service.ts와 대치 비교 UI에 세 번째 경로를 연동한다. 지금 UI는 PoC RLSC vs comp-sign 2-way만 가능하다.

I-11 (2026-08-28 신설) 순서는 정해졌고 코드가 없다(spec/capability-table.md 3.6절). 지금 있는 것은 조각 하나를 찾는 검색(T-5 노드 태그 검색)뿐이고, 질의가 복합인 것을 인식해 N-R2 로 형제를 묶고 조각마다 검색을 호출하고 N-R1 로 벗긴 부모의 내용을 옮기고 결과를 최상위 components[] 로 다시 조립하는 층이 없다. D-8 판정 자료가 이 코드에 걸려 있다. N3 이후 경로의 결과 품질을 재야 D-7 을 되돌릴지 정할 수 있다.

I-13 (2026-08-29 신설) 복잡도 레벨(L1/L2/L3, spec/schema-v0.5.md 8.8절)을 정책으로 통제하려면 레벨을 올리는 지시가 프롬프트에서 통째로 떼어지고 붙어야 한다. 지금은 절반만 되어 있다 — 위상 지시가 generator/prompts/system.md 의 ## 이종 컴포넌트 한 절에 뭉쳐 있어 물리적으로는 한 덩어리지만, ## 컴포넌트 블록 절에 "entity.components 는 포함 관계를 적을 때만 쓴다" 한 줄이 밖에 남아 있고, 포함(L3)과 병치(L2)가 한 절에 섞여 있어 레벨 경계로 갈리지 않으며, fillPrompt 가 {{TOKEN}} 치환만 해서 블록을 넣고 뺄 수단이 없다. 검사 재료는 이미 있다 — 산출물의 실제 레벨은 entity.components[] 사용 여부 하나로 판정되므로 선언 레벨과의 대조를 validate.ts 계측에 붙일 수 있다. 이것이 없으면 프롬프트 판본마다 실제 레벨이 달라지고, L2 로 내린 줄 알았는데 중첩이 나와 I-11 이 없는 상태에서 조용히 실패한다. 요구사항은 규약 8.9절.

I-12 (2026-08-28 닫힘) 유지하는 쪽으로 정했다. 구조를 그대로 두고 노드마다 카테고리를 내려 보고(N2), 실패하면 최상위 부모부터 벗겨 조각마다 찾고(N3, N4), 평탄화(N5)는 마지막에만 한다. 근거는 부모를 벗기면 질의가 여럿으로 갈라져 후보 풀이 커지는데 자식부터 떼면 내용을 지불하고도 부모가 여전히 복합으로 남는다는 것이다(spec/capability-table.md 3.6.3절). 종전에 이 항목은 design/content-binding-contract.md 3.4절과 report/sections/06-examples.md 7.4절에 "아직 한 문서에 못 박지 않았다"로 적혀 있었다.

I-10 (2026-08-23 신설) T-7(속성 추출)이 137건 전량에 값을 채웠지만(plan/node-tag-and-property-poc-blueprint.md 6절, 2026-08-22), 사람이 그 값을 고쳐 확정하고 재현 가능한 정답으로 남기는 화면과 저장소가 아직 없다. 경계 쪽은 iis_boundary_annotation/iis_boundary_annotation_node 골든셋과 BoundaryAnnotationEditor.tsx 편집기를 갖췄는데 속성 쪽만 비어 있다. 같은 모양(LLM 초안 테이블 iis_semantic_component가 이미 category와 properties를 한 행에 담는 방식)으로 컬럼을 더하고 편집기에 속성 패널을 얹는 설계를 plan/iis-property-annotation-ui-blueprint.md에 정리했다. D-1~D-4 모두 제안 상태이고, 오너 확인 전에는 마이그레이션도 화면 작업도 시작하지 않는다.

J. 생성 모델 파인튜닝#

착수 전이다. 설계는 finetuning-plan.md 에 있다. 대부분 규약 확정에 걸려 있고 J-1 만 지금 독립적으로 진행할 수 있다.

J-1 골든셋 90건이 17 중분류만 덮는데 실사용 관측은 38종이다. 데이터셋에 분할 찌꺼기가 있다. 샘플 58건 중 11건이 빈 heading 으로 시작하고 전부 --- 분할로 쪼개진 조각이다 (markdown-summary-samples.md 0.2절). 평가셋을 넓히기 전에 걷어낸다.

J-4 comp-sign v4.3.8 이 이미 있어 구현은 작다.

J-5 표현 수단은 2026-08-02 에 생겼다. v0.5 matrix 가 표 계열을 담는다 (capability-table.md 2.1절). 남은 것은 RLSC 대응 확인이다(그 문서 7절).

데이터가 스키마에 묶인다. 규약이 흔들리는 동안 대량 생성에 들어가면 그만큼 버린다. J-3 이후는 A절 규약 확정 뒤에 연다.

K. Week 27 PoC — 10,000 규모 인덱스 위 자유 입력 전체 파이프라인 (신설, 2026-09-05 정원석)#

목표. component index 약 10,000건 위에서, 자유 텍스트 input을 넣으면 → Visual Summary 생성(complexity L1/L2/L3 선택 또는 동시 생성) → 검색 질의 변환 → 검색 실행 → 대치(content binding) → 결과물을 화면에서 렌더링까지, 전체 파이프라인이 한 번에 도는 것을 확인하는 PoC. 이번 주(week 27)에서 가장 급한 것.

1차 완료 (2026-09-05, K-1~K-8). 파이프라인 실동작 확인, 인덱스 커버리지 실측(178,095건), 기존 스크립트로 로컬 인덱스 2,494→12,348건 확보, 복잡도 레벨 토글과 동시 생성, L1 위상 지시 누락 버그 수정, 브라우저 실험 결과를 Claude 가 다시 읽는 로컬 로그, "여정 뷰" 화면까지 끝났다.

2차 진행 중 (K-9~K-11). 검색을 지금의 컴포넌트 단위(RLSC 시뮬레이션)에서 I.I.S. 5단계(노드 단위) default로 바꾸는 작업. 조사 결과 코드는 이미 있고 스키마도 안 바꿔도 되는데, iis_semantic_component 데이터가 로컬 176건·프로덕션 60건뿐이라 지금 배선하면 후보가 거의 안 잡힌다. 두 경로는 절대 폴백으로 섞지 않는다 — 평가가 안 되기 때문이다(정원석 확정). 로컬 파일럿 추출은 K-10에서 5,000건 규모로 끝났고(boundary 4,764건·property 3,955건), 그 위에 K-9 배선도 끝났다 — 플레이그라운드에서 검색 엔진을 골라 자유 입력부터 대치까지 노드 경로로 돌려볼 수 있다. 남은 것은 정확도 판정(K-9-1)과 프로덕션 추출(K-11, AI 에이전트가 못 건드리는 영역이라 사람이 별도로 처리한다)이다.

K-2/K-3 근거. indexPool.ts의 WHERE_STRICT가 sheet_json과 structure_json을 둘 다 요구해 검색 후보를 좁힌다. README.md 3절이 인용하는 83,771건은 2026-07-22 적재분 스냅샷이라 낡았다 — 지금 프로덕션 실측(2026-09-05)은 178,095건이고 전량이 strict 조건을 만족한다. 병목은 데이터가 아니라 로컬 개발 환경에 이 데이터가 안 들어와 있다는 것뿐이다.

K-4/K-5 근거. I-13이 이미 같은 내용을 미착수로 적어 뒀다. K절은 I-13을 "이번 주 PoC의 필요조건"으로 승격시키는 것이지 새 설계가 아니다.

참고#

README.md 허브 · schema-v0.5.md 규약 · capability-table.md 41종 capability · projection-model.md 설계 의도 · yaml-examples.md 예시 · semantic-taxonomy-v7.md 단어장 · markdown-summary-samples.md 실사용 샘플 · pipeline-flow.md 전체 흐름 · content-binding-contract.md 내용 대치 contract · smart-diagram-data-model.md 스마트 다이어그램 종류와 스키마

↑ 목차로 · 1부 머리로

원문 spec/schema-v0.5.md GitHub 에서 보기 52 KB 원문 제목 「Summary 와 RLSC 공용 스키마 규약 v0.5」

이 문서가 SSoT이다. schema-v0.4.md 를 대체한다. v0.4 는 기록으로 보존하고 갱신하지 않는다.

오너 정원석 (MORDOR) · 상태 확정 · 최종 갱신 2026-09-05 (B-21 — ornament 축이 Element.Separator/LayoutContainer.Separator까지 흡수, 엣지 130개 동기화) · 티켓 MOR-1773

이 문서의 역할 사용자 입력을 검색과 대치에 쓸 수 있게 구조화한 산출물의 규약이다. 무엇을 어떤 필드에 적는가만 정한다. 어떤 컴포넌트가 그 구조를 받을 수 있는지는 capability-table.md, 왜 이런 모양인지는 1절에 있다.

관련 capability-table.md 45종 성립 조건과 fallback 순서, 복합 구조 순서 3.6절 · semantic-taxonomy-v7.md 단어장 · yaml-examples.md 예시 · TODO.md

이 문서 훑기

0. v0.4 에서 무엇이 바뀌었나#

2026-08-02 에 정한 열두 가지다. 각 결정의 근거는 TODO.md G절에 있다.

6번은 2026-08-03 에 뒤집혔다. 장식과 계층을 질의 쪽에도 적는 방향으로 바꿨다.

• 계층은 새 필드를 두지 않는다. 이미 있는 entity.children[](같은 컴포넌트 안)과 entity.components[](컴포넌트 경계를 넘는 중첩)를 실제로 쓴다. 어느 생성기가 entity.components[] 를 채우느냐는 B-20 이다 (2026-09-02: PoC 는 채운다 / 실서비스 Summary 생성기는 아직 안 채운다. 8.7절·8.8절).
• 장식은 Summary 가 축별 선호를 적는다. traits.decoration 같은 누적 등급 하나로 두지 않는다. 축은 ornament(Element.Decoration, Element.Separator)와 background(Element.Background) 둘이고 각각 RLSC role 군 하나에 대응한다(2026-09-05 정원석, B-21 — Separator는 별도 축을 새로 만들지 않고 ornament에 흡수했다). 값은 셋(prefer, indifferent, avoid)이다.
• 전용 속성은 DECO 계열에만 둔다. 타이틀과 디스크립션(Element.Title, Subtitle, Description)과 강조(Element.Highlight)는 대치가 내용으로 채우는 노드이므로 선호 선언이 필요 없다. 앞은 structure 와 entity.components[] 가 담고 뒤는 entity.emphasis 가 담는다. 그래서 회의 용어 N+α 는 개념 자체가 사라졌고, N 과 N+β 만 프리셋 이름(minimal, rich)으로 남는다.

설계 의도와 근거는 ../design/decoration-model.md 가 SSoT다. 표기 반영은 2026-08-04 에 끝냈다 (../TODO.md B-18). 아래 본문의 2절이 decoration 을 포함하고, 자리와 해석 순서는 2.7절에 있다. 1단계에서 생성기는 이 필드를 채우지 않는다.

'생성기'는 Summary 생성기를 가리킨다. 사용자 입력을 받아 이 규약대로 산출물을 써 내는 LLM 모듈이다. 현행은 Markdown 을 쓰고 4단계에서 YAML 로 바뀐다 (README.md 2절 용어, 4절 마일스톤).

entity 의 필드 구성은 대체로 유지하고 셋(period, avatar, organization)을 더했다. id 는 남아 있지만 optional 이고 생성기가 쓰지 않는다. entity.components[](중첩)는 v0.4 부터 스키마에 열려 있다. PoC 생성기는 채운다. 실서비스 Summary 생성기는 아직 채우지 않는다 (B-20, 8.7절).

0.1 버전 규칙 (2026-08-29 신설)#

규약을 고치면 버전을 올린다. 예외는 없다. 종전에는 v0.5 를 자리에서 여러 번 고치면서 버전을 그대로 두었다(2026-08-06 entities+columns 추가, 2026-08-17 fallback 상한 폐지, 2026-08-28 fallback 규칙 6번 신설, 2026-08-29 type 필수). 그래서 "지금 규약이 무엇인가"를 버전으로 가리킬 수 없었고, 생성물이 어느 판본을 따랐는지도 알 수 없었다.

형식은 MAJOR.MINOR.PATCH 이고 각 자리는 0 부터 99 까지다. 세 자리 모두 두 자리까지 쓸 수 있고, 앞자리를 0 으로 채우지 않는다(0.5.1 은 되고 0.05.01 은 안 된다).

^(0|[1-9][0-9]?)\.(0|[1-9][0-9]?)\.(0|[1-9][0-9]?)$

어느 자리를 올릴지는 하나로 판정한다 — 이 변경으로 무효가 되는 기존 산출물이 실제로 있는가.

type 필수화가 PATCH 인 이유를 적어 둔다. 원리적으로는 required 를 좁히는 변경이라 무효가 되는 산출물이 있을 수 있다. 그런데 실제로는 0건이었다 — 골든셋 v1 의 컴포넌트 470개가 전부 이미 type 을 갖고 있었고 생성기 프롬프트도 적으라고 지시하고 있었다. 판정은 원리가 아니라 실측으로 한다. 그래서 PATCH 다. 실측 없이 좁히는 변경은 MINOR 이상으로 본다.

검증기는 MAJOR 와 MINOR 만 대조하고 PATCH 는 보지 않는다. PATCH 는 정의상 유효성을 바꾸지 않으므로, patch 가 다르다고 옛 산출물을 떨어뜨리면 규칙이 자기모순이 된다. version 값은 0.5.x 대역 전체를 받아들이고, 정확한 patch 값은 계측에만 쓴다.

파일 이름은 MAJOR.MINOR 만 따라간다. 이 문서가 schema-v0.5.md 이고 JSON Schema 가 visual-summary-0.5.schema.json 인 것은 그대로 둔다. patch 를 올릴 때마다 파일 이름과 문서 30여 곳의 링크가 바뀌면 얻는 것보다 잃는 것이 크다. MINOR 이상을 올릴 때만 파일을 새로 판다.

현행 값은 0.5.6 이다. 종전 표기 0.5 는 0.5.0 으로 읽는다. 코드 반영은 아직이다(../TODO.md I-14).

1. 설계 원칙#

생성 단계에서 최적 semantic category 를 정한다. 생성기가 입력을 읽고 어느 카테고리로 그릴지 골라 type 에 적는다. 검색은 그 카테고리를 capability 와 대조해 실제로 그릴 수 있는지 확인하고, 못 그리면 fallback 순서를 따라간다(capability-table.md 3절).

생성기가 고를 수 있는 type 은 규약 enum 45종의 부분집합이다 (2026-09-11). capability-table.md 10.1절과 schema/capability.json 의 generatable 이 그 부분집합을 정한다. 첫 출시 기준 36종 — generatable: false 아홉(엔진 없음 여섯, HierarchicalTree, 공급 제외 Gauge·RadarChart)은 프롬프트 어휘와 검증에서 뺀다. I.I.S. 추출·검색 인식 어휘는 45종 전량이다. 스키마 enum 을 줄이지 않는다. RadarChart 를 빼는 자리의 생성 재지정은 ComparisonTable 이다(다축 보존, capability.json 의 generatorRedirect). BarChart 가 3.2절 첫 후속이지만 생성기가 그리로 가면 축이 붕괴한다. Gauge 는 3.2절과 같이 BigNumber 다.

structure 의 필드 이름을 카테고리에 묶지 않는다. venn.sets 가 아니라 entities 이고, profile.avatar 가 아니라 entity.avatar 다. 필드 중에는 사실상 한 카테고리만 읽는 것도 있다. avatar 와 organization 은 ProfileCard 가, speaker 는 DialogueChat 이, author 와 source 는 QuoteTestimonial 이 읽는다. 그래도 이름이 중립이면 못 읽는 카테고리가 그냥 지나갈 수 있고, fallback 은 그래서 돈다 (1절 "선언되지 않은 것은 무시한다").

카테고리마다 다른 것은 params 가 담는다. structure 는 내용, params 는 표현 선택이다. params 의 허용 키와 기본값은 capability-table.md 2절이 카테고리마다 정한다.

v0.2 와 v0.3 은 반대였다. 그때는 생성물이 표현형에 커밋하지 않고 검색이 골랐다. v0.5 가 이를 뒤집은 경위는 archive/projection-model.md 에 기록으로 남아 있다.

아래 규칙 셋은 어떤 structure 에도 예외 없이 성립한다. 이 셋이 성립하기 때문에 fallback 순서가 반드시 끝나고, 컴포넌트가 무엇을 못 그리든 결과가 비지 않는다.

어떤 구조든 리스트로 읽힌다 모든 structure 는 리스트로 읽히는 entities 를 가진다. dataset 만 있으면 거기서 파생한다. 그래서 마지막 fallback 이 언제나 성립한다.

선언되지 않은 것은 무시한다 relations 와 슬롯과 dataset 은 더해지는 정보다. 못 읽는 컴포넌트는 그냥 안 읽는다. 규약이 따로 정하지 않은 것의 기본 동작이 무시다.

중첩은 평탄화된다 entity.components[] 를 못 읽는 컴포넌트는 자식의 entities 를 부모 entity 의 items 로 편다. 여기에도 첫 규칙이 걸리므로, 깊이가 얼마든 결국 리스트로 읽힌다. 평탄화는 마지막 수단이다. 그 전에 모양을 지키며 카테고리를 내리고(N2), 최상위 부모를 벗겨 조각마다 찾는다(N3). 다섯 단계 전량은 capability-table.md 3.6절이다.

RLSC 로는 컴포넌트가 정해지지 않는다. RLSC 는 컴포넌트의 구조를 기술하는 어휘다. 어느 컴포넌트를 쓸지는 검색 모듈이 capability 와 type 을 대조해 정한다.

2. Core Schema v0.5#

규약을 두 벌로 적는다. 앞의 TypeScript 타입은 사람이 필드 구성을 읽는 용도이고, 뒤의 JSON Schema 는 기계가 생성물을 판정하는 용도다. 둘은 같은 것을 정의한다.

SSoT 는 JSON Schema 다. 정의용 TypeScript 타입과 검증기 zod 스키마는 둘 다 JSON Schema 에서 나온 파생물이고, 셋이 어긋나면 JSON Schema 를 따른다.

2.1 정의용 TypeScript 타입#

RLSC 를 TypeScript 로 정의한 것과 같은 방식이다 (src/app/pipeline/common/type/layoutStructure.ts, packages/structured-layout/src/role-v2.ts).

// 한 입력에서 나온 산출물 전체. 최상위다.
export interface VisualSummary {
  version: '0.5.6';           // 0.1절 버전 규칙. 검증은 MAJOR.MINOR 만 대조한다
  title: string;               // 빈 문자열을 허용하지 않는다
  components: Component[];     // 1개 이상
  relations?: Relation[];      // page 수준 관계. 자리만 예약했고 생성기는 채우지 않는다
  decoration?: Decoration;     // page 수준 꾸밈 선호. 자리만 예약했고 생성기는 채우지 않는다 (2.7절)
}

// 컴포넌트 하나. structure 만 필수다.
export interface Component {
  id?: string;                       // ^[a-zA-Z0-9_-]+$. 생성기는 채우지 않는다
  type: SemanticCategory;            // 필수 (2026-08-29). 생성기가 고른 카테고리. 검색이 그대로 따를 의무는 없다 (6절)
  alternatives?: SemanticCategory[]; // 못 쓸 때 대신 쓸 카테고리를 선호 순서로
  params?: Record<string, unknown>;  // 표현 선택 속성. 허용 키는 capability-table.md 2절
  structure: Structure;
  decoration?: Decoration;           // 이 컴포넌트에만 적용된다 (2.7절)
}

// 꾸밈 축에 담기는 값. 이 셋이 전부다
export type Preference = 'prefer' | 'indifferent' | 'avoid';

// 꾸밈구조. 축 하나가 RLSC role 군 하나에 대응한다.
// minimal 이나 rich 같은 프리셋 문자열은 받지 않는다
export interface Decoration {
  ornament?: Preference;    // Element.Decoration, LayoutContainer.Decoration, Element.Separator, LayoutContainer.Separator
  background?: Preference;  // Element.Background, LayoutContainer.Background
}

// 대분류 21종. 각 대분류는 자기 이름과 그 아래 중분류를 값으로 갖는다.
export type Enumeration = 'Enumeration' | 'Enumeration.List' | 'Enumeration.ListingTable';
export type AttributeComparison = 'AttributeComparison' | 'AttributeComparison.Versus' | 'AttributeComparison.ComparisonTable' | 'AttributeComparison.RadarChart';
export type RelationalComparison = 'RelationalComparison' | 'RelationalComparison.SWOT' | 'RelationalComparison.VennDiagram' | 'RelationalComparison.Quadrant' | 'RelationalComparison.BubbleChart';
export type Transformation = 'Transformation' | 'Transformation.Transformation';
export type ProcessFlow = 'ProcessFlow' | 'ProcessFlow.Steps';
export type LogicFlow = 'LogicFlow' | 'LogicFlow.FlowChart';
export type Progression = 'Progression' | 'Progression.Staircase';
export type TimelineSchedule = 'TimelineSchedule' | 'TimelineSchedule.Timeline' | 'TimelineSchedule.GanttChart' | 'TimelineSchedule.Calendar';
export type Hierarchy = 'Hierarchy' | 'Hierarchy.HierarchicalTree' | 'Hierarchy.Pyramid';
export type ScopeCoverage = 'ScopeCoverage' | 'ScopeCoverage.NestedScope';
export type Cycle = 'Cycle' | 'Cycle.Cycle';
export type ReasoningStructure = 'ReasoningStructure' | 'ReasoningStructure.Fishbone' | 'ReasoningStructure.CombinedResult' | 'ReasoningStructure.ProblemSolution';
export type KPIKeyMetric = 'KPIKeyMetric' | 'KPIKeyMetric.BigNumber' | 'KPIKeyMetric.Gauge';
export type TextBasedCommunication = 'TextBasedCommunication' | 'TextBasedCommunication.HighlightedMessage' | 'TextBasedCommunication.LongFormTextLayout';
export type QnACard = 'QnACard' | 'QnACard.QnACard';
export type Utterance = 'Utterance' | 'Utterance.DialogueChat' | 'Utterance.QuoteTestimonial';
export type PortraitProfile = 'PortraitProfile' | 'PortraitProfile.ProfileCard' | 'PortraitProfile.ResumeCV';
export type Conversion = 'Conversion' | 'Conversion.Funnel';
export type ProportionComposition = 'ProportionComposition' | 'ProportionComposition.TreeMap' | 'ProportionComposition.PieChart' | 'ProportionComposition.DonutChart' | 'ProportionComposition.StackedBarChart' | 'ProportionComposition.PictogramChart';
export type Trend = 'Trend' | 'Trend.LineAreaChart' | 'Trend.ComboChart';
export type MagnitudeRanking = 'MagnitudeRanking' | 'MagnitudeRanking.BarChart';


// 결합값(대분류.중분류) 45종만이다. 대분류 단독은 값이 아니다 (2026-08-29, 6절 상자).
export type SemanticCategory =
  | Enumeration
  | AttributeComparison
  | RelationalComparison
  | Transformation
  | ProcessFlow
  | LogicFlow
  | Progression
  | TimelineSchedule
  | Hierarchy
  | ScopeCoverage
  | Cycle
  | ReasoningStructure
  | KPIKeyMetric
  | TextBasedCommunication
  | QnACard
  | Utterance
  | PortraitProfile
  | Conversion
  | ProportionComposition
  | Trend
  | MagnitudeRanking;


// entities 와 dataset 중 적어도 하나가 있어야 한다
export type Structure =
  | (StructureSlots & { entities: Entity[] })
  | (StructureSlots & { dataset: Dataset });

interface StructureSlots {
  entities?: Entity[];      // 1개 이상
  relations?: Relation[];   // 블록 안 관계
  dataset?: Dataset;
  columns?: Column[];       // entities 로 표를 적을 때 헤더. dataset 없이도 쓴다 (2.5.1절)
}

// label 만 필수다. 나머지는 카테고리가 읽을 수 있으면 읽는다.
export interface Entity {
  id?: string;              // ^[a-zA-Z0-9_-]+$. 생성기가 아니라 후처리가 채운다 (3.2절)
  label: string;            // 빈 문자열을 허용하지 않는다
  items?: string[];
  value?: number;
  unit?: string;
  period?: string;
  emphasis?: boolean;
  weight?: number;
  speaker?: string;
  author?: string;
  source?: string;
  avatar?: string;
  organization?: string;
  values?: Array<string | number | null>; // columns 와 위치 대응. label 이 범주축(첫 열)을 대신한다 (2.5.1절)
  children?: Entity[];
  components?: Component[]; // 중첩. PoC 생성기는 채운다. 실서비스는 아직 안 채운다 (B-20, 8.7절)
}

// 두 개 이상의 대상을 잇는다.
export interface Relation {
  type: 'intersects' | 'compares';
  of: [string, string, ...string[]]; // entity 의 label 을 적는다. 파싱 뒤 id 로 바뀐다 (3.2절)
  desc?: string;
}

// 수치 데이터. shape 가 어느 모양인지 정한다.
export type Dataset = Measure | Matrix;

// 단일 수치
export interface Measure {
  shape: 'measure';
  value: number;
  unit?: string;
  min?: number;
  max?: number;
  target?: number;
  delta?: number;
  thresholds?: Threshold[];
}

export interface Threshold {
  at: number;
  label?: string;
  state?: 'safe' | 'warn' | 'danger';
}

/** 행과 열. 첫 열이 범주 축이다 (2.5절) */
export interface Matrix {
  shape: 'matrix';
  columns: Column[];                        // 1개 이상. 첫 열이 범주 축이다 (2.5절)
  rows: Array<string | number | null>[];    // 1개 이상. 타입은 넓게 열려 있지만 컬럼 role별 제약이 있다 (B-37, 아래)
}

/**
 * B-37 (2026-09-05 확정). 셀 값 타입은 그 열의 Column.role이 정한다 — 타입 시스템은
 * 열마다 다른 타입을 표현할 수 없어 rows는 string|number|null로 넓게 열어 두고,
 * 실제 제약은 establish 단계에서 role별로 검사한다.
 *   - role 미지정 또는 'category': string (row header, 값이 아니라 이름)
 *   - role 'value'|'x'|'y'|'size': number | null 만 허용, string 금지 (막대 높이·좌표·크기)
 *   - role 'start'|'end'|'date': 형식을 강제하지 않는다 (2026-09-10 정정, 허재영 판단 · 정원석 확인 대기).
 *     "3월 4일" 처럼 사람이 읽는 표기를 그대로 담는다. 이 값은 계산 대상이 아니라 표시와 대치
 *     대상이고, 내용 대치는 이 문자열을 그대로 검색해 바꾼다. ISO 표기와 timestamp 숫자도 받는다.
 *     종전 문구는 "ISO 문자열 또는 timestamp 숫자만, 임의 문자열 금지" 였는데, 그러면 달력과
 *     간트가 실사용 입력에서 거의 성립하지 않는다 — 생성기 골든셋 v1 의 Calendar 10행과
 *     GanttChart 10행이 전량 탈락했고, 그중 여덟은 입력에 달이 없어 ISO 로 옮길 수도 없다
 * 카테고리 이름이 아니라 컬럼의 role이 기준이라 모든 matrix 필수 카테고리에 동일하게 적용된다.
 */

export interface Column {
  label: string;
  role?: 'category' | 'value' | 'x' | 'y' | 'size' | 'start' | 'end' | 'date';
  unit?: string;
  axis?: 'left' | 'right';
  type?: 'bar' | 'line' | 'area';
}

타입이 못 담는 조건이 넷이다. 문자열 최소 길이(title, entity.label), id 의 ASCII 패턴, 객체 리터럴이 아닌 값의 초과 필드 거부, params 의 키 검증이다. 앞의 셋은 2.2절 JSON Schema 가, params 는 capability 가 판정한다.

Threshold 라는 이름은 이 타입 정의에서만 쓴다. JSON Schema 는 같은 객체를 measure.thresholds 안에 이름 없이 적는다.

2.2 검증용 JSON Schema#

생성은 YAML 로 하고(3절), 검증은 YAML 을 JSON 으로 변환한 뒤 이 스키마로 한다.

같은 내용이 파일로도 있다. schema/visual-summary-0.5.schema.json 이고, 검증기가 $ref 로 가리킬 수 있게 내보낸 것이다. 아래 코드펜스가 SSoT 이고 파일은 생성물이다. 이 절을 고치면 그 파일도 함께 맞춘다 (schema/README.md).

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://miridih.com/schemas/visual-summary/0.5",
  "title": "VisualSummary",
  "type": "object",
  "required": ["version", "title", "components"],
  "additionalProperties": false,
  "properties": {
    "version":    { "type": "string", "pattern": "^0\\.5\\.(0|[1-9][0-9]?)$" },
    "title":      { "type": "string", "minLength": 1 },
    "components": { "type": "array", "minItems": 1, "items": { "$ref": "#/$defs/componentBlock" } },
    "relations":  { "type": "array", "default": [], "items": { "$ref": "#/$defs/relation" } },
    "decoration": { "$ref": "#/$defs/decoration" }
  },
  "$defs": {
    "componentBlock": {
      "type": "object",
      "required": ["structure", "type"],
      "additionalProperties": false,
      "properties": {
        "id":           { "type": "string", "pattern": "^[a-zA-Z0-9_-]+$" },
        "type":         { "$ref": "#/$defs/semanticCategory" },
        "alternatives": { "type": "array", "items": { "$ref": "#/$defs/semanticCategory" } },
        "params":       { "type": "object" },
        "structure":    { "$ref": "#/$defs/structure" },
        "decoration":   { "$ref": "#/$defs/decoration" }
      }
    },

    "decoration": {
      "type": "object",
      "additionalProperties": false,
      "minProperties": 1,
      "properties": {
        "ornament":   { "$ref": "#/$defs/preference" },
        "background": { "$ref": "#/$defs/preference" }
      }
    },

    "preference": {
      "type": "string",
      "enum": ["prefer", "indifferent", "avoid"],
      "default": "indifferent"
    },

    "semanticCategory": {
      "type": "string",
      "enum": [
        "Enumeration.List", "Enumeration.ListingTable",
        "AttributeComparison.Versus", "AttributeComparison.ComparisonTable", "AttributeComparison.RadarChart",
        "RelationalComparison.SWOT", "RelationalComparison.VennDiagram", "RelationalComparison.Quadrant", "RelationalComparison.BubbleChart",
        "Transformation.Transformation",
        "ProcessFlow.Steps",
        "LogicFlow.FlowChart",
        "Progression.Staircase",
        "TimelineSchedule.Timeline", "TimelineSchedule.GanttChart", "TimelineSchedule.Calendar",
        "Hierarchy.HierarchicalTree", "Hierarchy.Pyramid",
        "ScopeCoverage.NestedScope",
        "Cycle.Cycle",
        "ReasoningStructure.Fishbone", "ReasoningStructure.CombinedResult", "ReasoningStructure.ProblemSolution",
        "KPIKeyMetric.BigNumber", "KPIKeyMetric.Gauge",
        "TextBasedCommunication.HighlightedMessage", "TextBasedCommunication.LongFormTextLayout",
        "QnACard.QnACard",
        "Utterance.DialogueChat", "Utterance.QuoteTestimonial",
        "PortraitProfile.ProfileCard", "PortraitProfile.ResumeCV",
        "Conversion.Funnel",
        "ProportionComposition.TreeMap", "ProportionComposition.PieChart", "ProportionComposition.DonutChart", "ProportionComposition.StackedBarChart", "ProportionComposition.PictogramChart",
        "Trend.LineAreaChart", "Trend.ComboChart",
        "MagnitudeRanking.BarChart",
        "PageNavigation.Opening", "PageNavigation.TableOfContents", "PageNavigation.SectionDivider", "PageNavigation.Ending"
      ]
    },

    "structure": {
      "type": "object",
      "additionalProperties": false,
      "anyOf": [ { "required": ["entities"] }, { "required": ["dataset"] } ],
      "properties": {
        "entities":  { "type": "array", "minItems": 1, "items": { "$ref": "#/$defs/entity" } },
        "relations": { "type": "array", "default": [], "items": { "$ref": "#/$defs/relation" } },
        "dataset":   { "$ref": "#/$defs/dataset" },
        "columns":   { "type": "array", "minItems": 1, "items": { "$ref": "#/$defs/column" } }
      }
    },

    "entity": {
      "type": "object",
      "required": ["label"],
      "additionalProperties": false,
      "properties": {
        "id":           { "type": "string", "pattern": "^[a-zA-Z0-9_-]+$" },
        "label":        { "type": "string", "minLength": 1 },
        "items":        { "type": "array", "items": { "type": "string" } },
        "value":        { "type": "number" },
        "unit":         { "type": "string" },
        "period":       { "type": "string" },
        "emphasis":     { "type": "boolean" },
        "weight":       { "type": "number" },
        "speaker":      { "type": "string" },
        "author":       { "type": "string" },
        "source":       { "type": "string" },
        "avatar":       { "type": "string" },
        "organization": { "type": "string" },
        "values":       { "type": "array", "items": { "type": ["string", "number", "null"] } },
        "children":     { "type": "array", "items": { "$ref": "#/$defs/entity" } },
        "components":   { "type": "array", "items": { "$ref": "#/$defs/componentBlock" } }
      }
    },

    "relation": {
      "type": "object",
      "required": ["type", "of"],
      "additionalProperties": false,
      "properties": {
        "type": { "enum": ["intersects", "compares"] },
        "of":   { "type": "array", "minItems": 2, "items": { "type": "string" } },
        "desc": { "type": "string" }
      }
    },

    "dataset": {
      "oneOf": [ { "$ref": "#/$defs/measure" }, { "$ref": "#/$defs/matrix" } ]
    },

    "measure": {
      "type": "object",
      "required": ["shape", "value"],
      "additionalProperties": false,
      "properties": {
        "shape":  { "const": "measure" },
        "value":  { "type": "number" },
        "unit":   { "type": "string" },
        "min":    { "type": "number" },
        "max":    { "type": "number" },
        "target": { "type": "number" },
        "delta":  { "type": "number" },
        "thresholds": {
          "type": "array",
          "items": {
            "type": "object",
            "required": ["at"],
            "additionalProperties": false,
            "properties": {
              "at":    { "type": "number" },
              "label": { "type": "string" },
              "state": { "enum": ["safe", "warn", "danger"] }
            }
          }
        }
      }
    },

    "matrix": {
      "type": "object",
      "required": ["shape", "columns", "rows"],
      "additionalProperties": false,
      "properties": {
        "shape":   { "const": "matrix" },
        "columns": { "type": "array", "minItems": 1, "items": { "$ref": "#/$defs/column" } },
        "rows": {
          "type": "array",
          "minItems": 1,
          "items": { "type": "array", "items": { "type": ["string", "number", "null"] } }
        }
      }
    },

    "column": {
      "type": "object",
      "required": ["label"],
      "additionalProperties": false,
      "properties": {
        "label": { "type": "string" },
        "role":  { "enum": ["category", "value", "x", "y", "size", "start", "end", "date"] },
        "unit":  { "type": "string" },
        "axis":  { "enum": ["left", "right"] },
        "type":  { "enum": ["bar", "line", "area"] }
      }
    }
  }
}

2.3 type 을 문자열 하나로 적는 이유#

대분류가 중분류의 namespace 다. Pyramid 는 Hierarchy 아래에만 있고 BarChart 는 MagnitudeRanking 아래에만 있다. 그래서 값을 Hierarchy.Pyramid 처럼 대분류를 앞에 붙여 적는다.

한 태그에 표기를 여럿 두지 않는다. 이 저장소는 같은 사고를 이미 한 번 겪었다. minor 이름만 담던 v2.0 어휘와 결합 표기를 섞었다가 조회가 조용히 0건이 났고, 그래서 semantic-taxonomy-v7.md 0절이 표기를 하나로 못 박았다. 필드를 둘로 나누면 세 번째 표기가 생긴다.

스키마는 결합값 45종 목록으로 조합을 강제한다. Hierarchy.BarChart 처럼 어긋난 조합은 목록에 없으므로 검증에서 걸린다.

대분류만 적는 것은 허용하지 않는다 (2026-08-29 개정). 종전에는 생성기가 중분류를 못 정하면 Hierarchy 만 적을 수 있었고, 검색이 그 안 중분류 전체를 후보로 봤다. 그래서 목록이 62값(대분류 21 + 결합 41)이었다. 지금은 41종뿐이다. 대분류는 그릴 수 있는 표현형이 아니라 결합값을 묶어 부르는 분류 축이므로 type 값이 될 수 없다. 근거와 영향은 6절 개정 상자에 있다. 중분류를 못 정하겠으면 종단 셋 중 하나를 고른다 — 그것이 이 규약이 정한 '못 고를 때의 답'이다(5절 3번).

저장 키는 구분자가 다르다. DB 와 comp-sign 이 쓰는 값은 Enumeration_List 처럼 밑줄이다(design_object_semantic_tags.tags, comp_signs_v3_4.semantic_tags). 질의 쪽 표기는 점이다. 검색 모듈이 받는 즉시 점을 밑줄로 바꾼다. 이 변환은 한 곳에만 있어야 한다.

2.4 params 를 열린 객체로 두는 이유#

카테고리마다 표현 선택 속성이 다르다(pyramid 의 apex, timeline 의 orientation, pictogram 의 icon). 41종의 속성을 전부 스키마 조건문으로 쓰면 스키마가 어휘에 묶여 카테고리가 늘 때마다 버전이 오른다.

params 의 허용 키와 기본값은 capability-table.md 2절이 카테고리별로 정한다. 스키마는 객체라는 것까지만 보고, 값 검증은 capability 가 한다. 어휘를 capability 상수로 모으기로 한 결정과 같은 방향이다.

2.5 matrix 의 행과 열#

첫 열이 범주 축이다. 나머지 열이 계열이다. 이 규약을 두지 않으면 생성기가 행과 열을 바꿔 적어도 검증이 통과한다.

column.role 이 각 열의 성격을 밝힌다. category 는 범주 축, value 는 수치, x 와 y 와 size 는 산점도와 버블, start 와 end 는 간트, date 는 달력이다. role 을 생략하면 첫 열은 category, 나머지는 value 로 본다.

표 계열(ListingTable, ComparisonTable)과 차트 계열이 같은 모양을 쓴다. 둘의 차이는 데이터가 아니라 표현이고, 표현은 type 이 정한다.

2.5.1 병합·계층 헤더가 있는 표: entities 경로 (2026-08-06 추가)#

계기. 강창석님 질의로 병합 셀이 있는 실사용 표가 matrix 성립 조건(2.1절)에 걸려 통째로 탈락하는 사례가 나왔다. Column.role(x, y, size, start, end, date)과 type(bar, line, area)이 순수 차트 어휘라, 2.5절의 "표와 차트가 같은 모양을 쓴다"는 전제는 평평한 격자에서만 성립한다. 병합·계층 헤더는 이 전제 밖이고, 지금 45종 어느 차트 카테고리도 그런 구조를 읽지 않는다(capability-table.md 2절). 그래서 matrix 를 확장하는 대신, ListingTable·ComparisonTable 에만 entities 를 대안 구조로 연다.

모양. columns(2.1절 StructureSlots, 헤더 정의)와 entities(행)를 함께 쓴다. entity.label 이 범주축(첫 열), entity.values[] 가 columns 와 위치로 대응하는 나머지 열이다. 부모-자식 행 병합(예: 상위 범주 하나가 하위 행 여럿을 거느리는 것)은 entity.children[] 로 적는다 — 새 필드가 아니라 0절과 6절이 계층에 이미 쓰기로 한 필드를 그대로 쓰는 것이다.

version: "0.5.6"
title: 분기별 프로젝트 성과
components:
  - type: AttributeComparison.ComparisonTable
    structure:
      columns:
        - { label: 항목 }
        - { label: 1Q }
        - { label: 2Q }
        - { label: 3Q }
      entities:
        - label: PROJECT 01
          children:
            - { label: 성장률, values: ["35%", "67%", "55%"] }
            - { label: 매출, values: [14000, 25000, 18000] }

적용 범위는 계층형 병합으로 한정한다. 위 모양은 상위 범주가 하위 행을 거느리는 경우(부모-자식 트리 하나로 표현되는 경우)를 담는다. 주축과 무관하게 특정 컬럼 하나만 값이 여러 행에 걸쳐 반복되는 경우(예: 강의 4개 행 중 "주말반" 컬럼만 2행씩 묶이는 것 — 축이 둘로 갈라지는 독립적 rowspan)는 트리 하나로 담기지 않는다. 이 경우는 지금 범위 밖이고 TODO.md B-29 에 열어 둔다.

fallback 은 matrix 성립 조건을 요구하는 카테고리로 가지 않는다. entities(+children) 로 표현된 표를 억지로 matrix.rows 로 접으면(다른 fallback 엣지가 하듯, capability-table.md 3.4절 P1/P2) 병합 의미가 조용히 사라진다. 그래서 이 경로로 채워진 ListingTable/ComparisonTable 은 Quadrant, GanttChart, Calendar 같은 matrix 필수 카테고리의 fallback 도착지가 되지 않는다. 대부분은 성립 조건(예: Quadrant 의 "항목마다 x, y")을 애초에 못 채워 5절 1번으로 걸러지지만, fallback 변환 규칙을 넓힐 때 이 방향으로 우회하지 않도록 여기 명문화해 둔다. 성립 조건과 이 경로가 capability 쪽에서 실제로 갈리는 지점은 capability-table.md 2.1절과 6절이다.

2.6 relation 어휘를 늘리는 기준#

구조로 적을 수 없는 제3의 내용을 가진 관계만 어휘로 만든다. 배열 순서, entity 내부 필드, children 으로 적히는 것은 어휘로 만들지 않는다. 이 기준으로 후보를 전수 판정한 결과가 아래다 (2026-08-02 확정, 원 논의는 archive/projection-model.md 7절).

2.7 decoration 은 어디 붙고 어떻게 읽나#

structure 의 형제로 붙고 page 수준에도 같은 키를 연다. params 도 structure 도 아닌 이유는 둘이다. params 는 카테고리별 표현 선택인데(2.4절) 꾸밈구조는 카테고리와 무관하고, structure 는 내용인데 꾸밈구조는 내용이 아니다.

축은 둘이고 각각 RLSC role 군 하나에 대응한다. ornament 가 Element.Decoration·LayoutContainer.Decoration·Element.Separator·LayoutContainer.Separator, background 가 Element.Background 와 LayoutContainer.Background 다(Separator 흡수는 2026-09-05 정원석 확정, B-21). 타이틀과 디스크립션과 강조는 대치가 내용으로 채우는 노드라 축이 아니다. 앞은 structure 와 entity.components[] 가 담고 뒤는 entity.emphasis 가 담는다.

값은 셋이고 require 를 두지 않는다. prefer 는 그 role 노드를 가진 후보를 앞에 두고, avoid 는 뒤로 보내며, indifferent 는 보지 않는다이고 기본값이다. 꾸밈을 필수로 걸면 후보가 0이 되어 전부 List 로 강등되기 때문이다(capability-table.md 성립 조건과 겹치지 않는다).

값의 모양은 enum 이고, 수치 점수는 앞으로도 두지 않는다 (2026-08-29 확정, 정원석). 셋을 갈라 적는다.

모양	판정
enum (prefer·indifferent·avoid)	4단계와 5단계가 쓰는 것이 이것이다. 지금 규약에 있는 형태다
객체 (ornament: { ... } 처럼 구체적인 값을 담는 것)	나중 단계의 자리다. 기각된 것이 아니라 4·5단계 범위가 아닐 뿐이다. 그 단계에서 무엇을 담을지는 정하지 않았다
수치 점수 (ornament: 0.8 같은 가중치)	앞으로도 두지 않는다. 값에 점수를 매기는 것이 의미가 없다고 판단했다. 채점 코드를 건드리지 않기로 한 결정과 어긋나고 entity.weight(number)가 다른 뜻으로 이미 있다는 종전 근거도 그대로다

그래서 "prefer 가 몇 점인가"는 물음 자체가 성립하지 않는다. 남는 것은 점수가 아닌 형태로 검색이 이 선호를 어떻게 반영하는가, 그리고 fallback 보다 먼저 보는가 나중에 보는가다(../design/decoration-model.md 6절, 이석).

해석은 축마다 따로 하고 구체적인 쪽을 우선한다. component.decoration → page.decoration → 카테고리 기본값 → 시스템 전역 기본값 → indifferent 순이다. 층 전체를 갈아치우지 않고 축 단위로 병합하므로, page 가 두 축을 prefer 로 둔 상태에서 컴포넌트 하나만 background: avoid 로 덮을 수 있다.

indifferent 를 명시적 값으로 둔 이유가 이 병합에 있다. 위 층에서 물려받은 값을 취소하려면 '안 적음'과 구별되는 값이 필요하다.

version: "0.5.6"
title: 분기 실적
decoration:                    # page 수준. 아래 컴포넌트의 기본값이 된다
  ornament: prefer
  background: prefer
components:
  - type: Enumeration.List     # 물려받는다. 둘 다 prefer
    structure:
      entities: [ { label: 신규 계약, items: [12건] } ]
  - type: ProcessFlow.Steps
    decoration:
      background: indifferent  # 이 축만 되돌린다. ornament 는 prefer 그대로다
    structure:
      entities:
        - { label: 계약 검토 }
        - { label: 체결 }

1단계에서 생성기는 이 필드를 채우지 않는다. 스키마에 자리만 열고 값은 시스템 전역 기본값에서 온다. page 수준 relations 가 같은 방식으로 열려 있다. entity.components[] 는 B-20 으로 갈렸다 — PoC 는 채우고 실서비스는 아직 안 채운다. 소비할 주체인 요소 대치가 아직 동작하지 않고, 색인이 role 표식을 받는 경로도 없어서 지금 적어도 읽는 곳이 없다.

page layout 은 규약 범위 밖이다 (2026-08-29 확정, 정원석). page 수준에 있는 것은 relations 와 decoration 둘뿐이고, 둘 다 배치 지시가 아니다 — relations 는 컴포넌트 블록끼리의 의미 관계를 적을 자리이고 decoration 은 꾸밈 선호다. "컴포넌트 여럿을 한 페이지에 어떻게 놓는가"를 정하는 규약은 5단계 범위에도 없다. 5단계가 뽑는 것은 노드 태그와 카테고리 고유 속성(properties)과 구조 대응이지 배치가 아니다.

없는 것이 아니라 미룬 것이다. 배치를 다루자는 결정은 5단계 이후로 잡혀 있고, 그때까지 질의 쪽 스키마에 좌표나 그리드를 넣지 않는다. 지금 넣으면 색인 쪽(검색이 고른 실제 컴포넌트와 그것이 속한 템플릿이 배치를 정한다)과 두 벌로 갈린다.

그 전에 풀려야 할 것 둘이 먼저다. 복합 구조 fallback 에서 N3·N4 를 반복하면 최상위 컴포넌트 수가 늘어나는데 그 상한이 없고(../TODO.md B-32), 여러 조각으로 쪼갠 검색 결과를 한 페이지로 조립하는 오케스트레이션 코드도 없다(같은 문서 I-11). 개수와 조립이 정해지지 않은 상태에서 배치 규약을 먼저 쓸 수 없다.

설계 의도와 축을 둘로 좁힌 근거, 회의 용어 N / N+β 와의 관계는 ../design/decoration-model.md 에 있다. 안 쓰는 표기 다섯은 그 문서 5.5절이다.

3. 생성 메커니즘: LLM 이 YAML 을 직접 쓴다#

YAML 을 쓰는 이유는 추론 속도다. YAML 은 JSON 보다 구두점 토큰이 적어 같은 내용을 더 적은 생성 토큰으로 쓰고, 생성 토큰 수가 추론 시간을 정한다.

그래서 JSON 으로 생성한 뒤 YAML 로 직렬화하지 않는다. 그 방식은 속도 이득이 없다. v0.2 원문의 "structured output 으로 생성하고 직렬화만 YAML" 서술은 이 결정으로 대체됐다.

3.1 검증은 수동 절차다#

structured output 을 쓰지 않으므로 스키마 위반이 생성 단계에서 막히지 않는다. 그 보호를 검증 절차로 대신한다.

LLM 생성 (YAML)  →  js-yaml 파싱  →  JSON  →  id 할당  →  zod 검증  →  실패하면 재생성

entity.id 는 LLM 이 쓰지 않는다. 파싱 직후에 배열 순서대로 기계가 매긴다(3.2절). 그래서 id 는 스키마에서 optional 이고, 검증 시점에는 항상 채워져 있다.

3.2 id 를 어떻게 매기나#

LLM 이 지은 식별자는 두 가지를 해친다. 하나는 토큰이고(18종 실측 -5.9%), 다른 하나는 재현성이다. 내용이 같아도 agenda 와 a1 로 갈리면 ../TODO.md F-1 의 재현성 지표가 같은 결과를 불일치로 센다. id 패턴이 ASCII 만 받는 것도 한국어 입력에서는 매번 라틴 문자를 지어내야 한다는 뜻이라 실패 자리가 하나 늘어난다.

그래서 파싱 직후에 배열 순서대로 매긴다. 규칙은 둘이다.

1. 한 컴포넌트 블록 안에서 entities 를 훑으며 e1, e2, ... 를 붙인다. children 은 부모 뒤에 이어서 센다.
2. relations[].of 에 적힌 label 을 그 블록에서 찾아 매긴 id 로 바꾼다. 못 찾으면 검증 실패로 다루고 재생성한다.

배열 순서에서 나오므로 같은 입력이면 같은 id 가 나온다.

검증기는 zod 를 쓴다. 규약은 JSON Schema(2절)로 적고, 소비 코드가 TypeScript 이므로 zod 스키마를 생성물로 내보낸다. capability 상수(semanticTaxonomy.gen.ts)와 같은 방식이다. JSON Schema 와 정의용 타입과 zod 셋의 관계는 2절에 있다.

재생성 정책 검증 실패는 오류 메시지를 붙여 같은 모델에 다시 물린다. 반복 상한을 두고, 상한에 걸리면 그 블록을 생성 실패로 기록한다. 상한값은 실측으로 정한다.

계측이 생성기 요건이다. YAML 파싱이 실경로이므로 파싱 실패율과 스키마 위반율을 나눠 세고, 여기에 파싱은 됐는데 타입이 뒤바뀐 경우를 따로 센다. YAML 의 암묵적 타이핑 때문에 no 가 false 로, 1.0 이 숫자로 바뀌는 사고가 알려져 있다. 이 지표를 처음부터 넣는다 (../TODO.md F-2).

형식은 이 절차와 독립이다. 표면을 JSON 으로 바꾸고 검증기를 돌리는 절차는 어느 형식이든 같다. KDL 로 갈 경우의 표현 설계와 토큰 실측은 format-alternatives.md 에 있다.

4. capability 는 별도 문서다#

어떤 카테고리가 어떤 구조를 받을 수 있는지, 못 받을 때 어디로 물러나는지는 capability-table.md 에 45종 전량(49종 단어장에서 지도 전용 4종 제외, capability-table.md 범위 절)이 있다. 규약 본문에 두지 않는 이유는 둘이다.

첫째, 갱신 주기가 다르다. 스키마는 거의 안 바뀌고 capability 는 단어장과 색인 상태를 따라 바뀐다.

둘째, 소비자가 다르다. 스키마는 생성기와 검증기가 읽고, capability 는 검색 모듈이 읽는다.

capability 는 TypeScript 상수를 SSoT 로 두고 BE 소비용은 JSON 으로 내보낸다.

5. fallback 규칙#

1. 카테고리의 성립 조건을 못 채우면 그 카테고리가 후보에서 빠진다. 성립 조건은 개수 범위와 내용 존재만 본다.
2. 후보가 없으면 fallback 순서를 따라 내려간다. 상한을 두지 않는다. 근접도 순서만 지키면 몇 칸이든 허용하고, 그래도 없으면 마지막 fallback 으로 간다 (2026-08-17, capability-table.md 4절 개정 — 종전 "최대 두 번" 규칙 폐지)
3. 마지막 fallback 은 셋이다. entities 가 2개 이상이면 Enumeration.List, 1개이고 여러 문장이면 TextBasedCommunication.LongFormTextLayout, 1개이고 한 문장이면 TextBasedCommunication.HighlightedMessage 다. 셋 다 개수 조건만 보므로 언제나 하나는 성립한다.
4. 선택된 카테고리가 못 읽는 것은 버리지 않고 옮긴다. 어디로 옮기는지는 capability-table.md 3.4절이 규칙 일곱으로 정하고(2026-09-05, B-27로 P8 폐기), 3.5절이 엣지 130개 전량에 적용해 둔다. 표현 선택(params)만 버리고 내용은 items 로 간다.
5. type 이 가리킨 카테고리의 성립 조건을 structure 가 못 채우면 구조가 우선이다. 그 카테고리는 1번대로 후보에서 빠지고 fallback 순서로 넘어간다.
6. 질의가 중첩(entity.components[])이나 병치(최상위 components[] 여럿)로 노드를 여럿 가지면, 위 1번부터 5번과 별개로 어느 노드를 먼저 포기하는지를 정해야 한다. 순서는 다섯 단계(N1 전체 일치, N2 모양 보존 강등, N3 최상위 벗기기, N4 반복, N5 평탄화)이고 capability-table.md 3.6절이 SSoT 다 (2026-08-28 확정). 1절 "중첩은 평탄화된다"는 폐기되지 않고 N5, 즉 마지막 단계로 자리를 옮겼다.

5번이 발동했다는 것은 대개 생성 결함이다. 프롬프트가 "정의의 개수 조건과 dataset 요구를 채울 수 있는지 먼저 확인하고, 못 채우면 정의의 '못 쓸 때 대안' 순서를 따른다"고 지시하므로, 못 채우는 type 을 적은 것은 지시 위반이다. 그런데도 검증 오류로 두지 않는 근거가 셋이다. type 은 권고이고(6절) 최종 결정은 검색이 하며, 데이터가 entity.components[] 중첩 안에 적혀 있어 자손을 합치면 성립하는 경우가 있고(그때는 결함이 아니라 적힌 자리가 다른 것이다), 하드 실패시키면 재생성 루프를 돌고 그마저 실패하면 사용자에게 빈 결과가 간다. 대신 생성 품질 신호로 센다 — capabilityCheck.ts 가 warning 으로 세고(capabilityFallbackCount) strictCapability 를 켜면 검증 실패로 올린다. 어떤 카테고리로도 못 그리는 경우만 항상 error 다. 발생 빈도는 아직 실측이 없다.

반대로 fallback 도착지에서의 미충족은 결함이 아니다. 예를 들어 Gauge 에서 HighlightedMessage(정확히 1)로 내려갈 때 항목이 여럿이면 P8 로 접어 받는데, 이것은 강등 경로가 원래 그렇게 도는 것이다. type 을 아예 적지 않은 것은 여기(fallback 결함)가 아니라 검증 단계에서 스키마 위반으로 걸린다 — type 은 0.5.1 부터 필수다(0.1절·2절). 이 자리에 남아 있던 "optional" 표기는 0.5.0 시절의 잔존 문구였다.

빈 결과가 사용자에게 가지 않는다. 3번이 이를 보장한다. 별도의 실패 표시 정책을 두지 않는 근거다. 6번의 N5 도 3번으로 끝나므로 복합 구조에서도 같다.

6. type 이 하는 일 셋#

type 은 생성기가 고른 카테고리다. 검색은 이 값을 기본으로 따르고, 그릴 수 없을 때만 fallback 순서로 벗어난다. 하는 일이 셋이다.

2026-08-29 개정: type 은 필수다 (정원석). 종전에는 optional 이었고 근거는 "필수로 걸면 '카테고리를 못 고르겠다'가 곧 생성 실패가 된다" 였다. 뒤집는다.

근거는 이 단계의 존재 이유다. 1절 설계 원칙 첫째가 "생성 단계에서 최적 semantic category 를 정한다"이다. 어떤 시각 표현형으로 그릴지를 먼저 정해야 거기서부터 표현 방식이 따라 나온다. type 을 비우고 내보내는 것은 그 판단을 검색 쪽으로 미루는 것이고, 시각화 책임을 회피하는 것이다. 원칙 1과 optional 은 처음부터 서로 어긋나 있었고 이 개정이 그것을 맞춘다.

'적을 의무'만 바꾸고 '따를 의무'는 안 바꾼다. 필수가 된다고 type 이 지시가 되는 것은 아니다. 검색은 여전히 성립 조건과 색인 공급을 보고 fallback 으로 벗어날 수 있다(5절). 권고라는 성질은 그대로다.

못 고르겠는 경우의 답은 '비우기'가 아니라 '종단 셋 중 하나를 고르기'다. entities 가 2개 이상이면 Enumeration.List, 1개이고 여러 문장이면 TextBasedCommunication.LongFormTextLayout, 1개이고 한 문장이면 TextBasedCommunication.HighlightedMessage 다(5절 3번). 셋 다 개수 조건만 보므로 어떤 내용이든 하나는 성립한다. 고를 수 없는 입력은 없다.

깨지는 산출물이 없다. 골든셋 v1 의 컴포넌트 470개가 전부 이미 type 을 갖고 있고, PoC 프롬프트도 type 을 적으라고 지시하고 있었다. 이 개정은 실제로 지켜지던 것을 규약에 올리는 일이다.

버전은 올리지 않는다. required 를 좁히는 변경이지만 위 이유로 무효가 되는 기존 산출물이 없어서, v0.5 를 자리에서 고친다(2026-08-06 entities+columns 추가, 2026-08-17 fallback 상한 폐지와 같은 방식).

2026-08-29 개정 (2): 대분류 단독은 type 값이 아니다 (정원석). type 과 alternatives 는 결합값(대분류.중분류)만 받는다. 어휘에서 대분류 21값을 뺐고, 그래서 enum 이 62값에서 결합값만 남았다(2.1절 타입, 2.2절 JSON Schema, 2.3절 어휘).

근거는 대분류가 실제로 쓰이는 컴포넌트 유형이 아니라는 것이다. Hierarchy 로는 아무것도 그릴 수 없다 — 그릴 수 있는 것은 Hierarchy.HierarchicalTree 이거나 Hierarchy.Pyramid 다. 대분류는 결합값을 묶어 부르는 분류 축이지 표현형이 아니다. 대분류만 적는 것은 앞 개정이 막은 것과 같은 회피이고, 정도만 약하다.

대분류라는 개념 자체가 사라지는 것은 아니다. fallback 근접도 판정에서 "대분류 일치는 강한 신호"로 쓰고(capability-table.md 3.1절), 6절 셋째의 "대분류가 Hierarchy 인가" 신호도 그대로다. 값으로 못 쓸 뿐 축으로는 계속 쓴다.

깨지는 산출물이 없다. 골든셋 v1 의 컴포넌트 type 454개가 전부 결합값이고, 생성기 프롬프트도 결합값만 목록으로 준다(VOCAB_COMBINED). 2026-09-11 부터 생성기 프롬프트(V2)는 그 45종에서 generatable: false 9종을 뺀 36종만 싣는다 — enum 자체는 45종이다(1절). 대분류를 받아 그 안 중분류 전체로 펼치던 경로(fallback.ts 의 major-expansion)는 규약상 도달할 수 없는 경로가 된다.

버전은 0.5.1 → 0.5.2 다. 어휘를 좁히는 변경이지만 실제로 무효가 되는 산출물이 0건이므로 PATCH 다(0.1절 판정 기준).

첫째, 무엇으로 그릴지 정한다. 검색은 type 이 가리킨 카테고리의 후보를 먼저 찾는다. 성립 조건을 채우고 색인에 후보가 있으면 그대로 간다.

둘째, 구조가 똑같은 두 카테고리를 가른다. Hierarchy.HierarchicalTree(조직도)와 ScopeCoverage.NestedScope(포함 범위)는 성립 조건이 같다. 둘 다 children 만 있으면 성립한다. 구조만 봐서는 어느 쪽으로 그릴지 알 수 없고, type 이 그것을 정한다.

셋째, '계층이 이 내용의 핵심인가'를 type 으로 판정한다. 조직도를 들여쓴 리스트로 바꾸면 소속 관계가 사라지고, 단순 분류 목록을 그렇게 바꾸면 별 손해가 없다. 이 차이를 적을 필드를 따로 두지 않기로 했다 (TODO.md B-3). 대신 type 의 대분류가 Hierarchy 인지가 그 신호가 되고, 평탄화를 어디까지 허용할지는 capability-table.md 의 fallback 순서가 정한다.

2026-08-03 갱신 B-3 이 뒤집혔다. type 으로 판정한다는 위 문장은 유효하지만, 그것만으로 두지 않고 컴포넌트를 nested 구조로 두어 계층을 표현한다. 새 선언 필드를 만드는 것이 아니라 entity.children[] 과 entity.components[] 를 실제로 쓰는 것이다 (0절 상자, ../design/decoration-model.md 1절).

6.1 alternatives 는 왜 두는가#

적어도 되고 안 적어도 된다. 생성기가 안 채우면 없는 것이고, 그때는 검색이 capability-table.md 3절의 fallback 순서만 쓴다. 적혀 있으면 그 순서보다 먼저 본다.

둘을 함께 두는 이유는 보는 것이 다르기 때문이다.

fallback 순서는 정적이다. Gauge → BigNumber → List 는 게이지에 무엇이 담기든 같다. 안에 든 내용이 목표 대비 달성률인지 단순 수치인지 구분하지 않는다.

그런데 내용을 보면 더 좁힐 수 있다고 본다. 같은 Hierarchy.Pyramid 라도 층마다 크기 차이가 의미를 지니면 Progression.Staircase 가 낫고, 그냥 3단 분류면 Enumeration.List 로 가도 손해가 적다. 이 판단은 카테고리 이름만 봐서는 안 나오고 내용을 읽어야 나온다. 생성기는 그 내용을 이미 읽었으므로 적어 둘 수 있다.

이건 가정이고 아직 실측이 없다. 생성기가 고른 alternatives 가 정적 순서보다 실제로 나은지는 재 본 적이 없다. 그래서 optional 로 열어 두고 생성기 정책으로 켜고 끌 수 있게 했다.

7. 설계 제약: 기존 RLSC 를 변경 없이 mapping#

structure 는 기존 RLSC 노드를 수정하지 않고 그대로 투영받을 수 있는 형태여야 한다. RLSC 가 이미 가진 것(children, role, chart data)에 structure 의 슬롯이 얹히는 방향이다.

2단계와 3단계에서 RLSC 스키마는 손대지 않는다. node 단위로 RLSC 를 실제 확장하는 것은 4단계(I.I.S.) 소관이다.

RLSC 대응을 41종 전량으로 채우는 것은 남아 있다. v0.4 3절의 11행 표에서 이미 셋(big_number, quote, dialogue)이 전용 컨테이너 없음이었고, 늘어난 30종 중 상당수가 같은 상태로 보인다 (capability-table.md 7절).

8. YAML 예시#

8.1 단일 컴포넌트#

version: "0.5.6"
title: 효과적인 회의를 위한 3가지 원칙
components:
  - type: Enumeration.List
    structure:
      entities:
        - { label: 명확한 아젠다, items: [회의 전 안건 공유, 목표 한 문장 정의] }
        - { label: 시간 관리, items: [시작과 종료 시간 엄수, 항목별 타임박스] }
        - { label: 액션 아이템, items: [담당자 지정, 마감일 명시] }

컴포넌트가 하나여도 배열이다.

8.2 params 와 alternatives#

version: "0.5.6"
title: 매슬로 욕구 5단계
components:
  - type: Hierarchy.Pyramid
    params: { apex: last }
    alternatives:
      - Progression.Staircase
      - Enumeration.List
    structure:
      entities:
        - { label: 생리적 욕구 }
        - { label: 안전 욕구 }
        - { label: 사회적 욕구 }
        - { label: 존경 욕구 }
        - { label: 자아실현 }

apex 는 안 적어도 된다. 기본값이 last 다. alternatives 도 선택이고, 적으면 검색 모듈이 fallback 순서보다 먼저 참고한다.

ScopeCoverage.NestedScope 의 direction 은 다르다 — 기본값에 기대지 말고 반드시 판단해서 적는다 (2026-09-04 B-34).

version: "0.5.6"
title: 목표 시장 규모
components:
  - type: ScopeCoverage.NestedScope
    params: { direction: inward }
    structure:
      entities:
        - { label: 수익 시장, items: ["SOM 연 3,100억원"] }
        - { label: 유효 시장, items: [SAM 연 2.4조원] }
        - { label: 전체 시장, items: [TAM 연 12조원] }

apex 는 안 적으면 last(마지막 항목이 꼭대기)로 정해도 그림이 뒤집힐 뿐 의미가 바뀌지 않는다. direction 은 다르다 — 입력 글이 "가장 좁은 시장부터" 적었는지 "가장 넓은 시장부터" 적었는지에 따라 entities 배열 순서가 반대가 되고, direction 을 잘못 판단하면 안쪽과 바깥쪽이 뒤바뀐 틀린 그림이 나온다(원인이 결과처럼 보이는 것과 같은 종류의 오류다). 그래서 생성기는 direction 을 기본값에 맡기지 않고 입력 글의 서술 순서를 읽어 inward/outward 중 하나를 판단해 항상 명시적으로 적어야 한다. 색인 쪽(I.I.S. 속성 추출, T-7)도 같다 — 실제 컴포넌트를 볼 때 동심원의 어느 쪽이 라벨 순서상 첫 항목인지 실측해서 채운다. 값은 inward/outward 두 가지뿐이다(추측하기 쉬운 값이 아니라 열거형으로 못박는다 — 근거는 아래).

8.3 relations#

version: "0.5.6"
title: 장수기업 HR의 핵심 과제
components:
  - type: RelationalComparison.VennDiagram
    structure:
      entities:
        - { label: 전통, items: [유산, 정체성, 신뢰] }
        - { label: 변화, items: [혁신, 적응, 미래] }
      relations:
        - type: intersects
          of: [전통, 변화]
          desc: 두 요소를 조화롭게 관리하는 것이 장수기업 HR의 핵심

of 에는 entity 의 label 을 적는다. desc 는 어느 entity 에도 속하지 않는 내용이라 관계로 적는다. 이것이 관계 어휘를 만드는 유일한 기준이다.

8.4 measure#

version: "0.5.6"
title: 3분기 목표 달성률
components:
  - type: KPIKeyMetric.Gauge
    structure:
      entities:
        - { label: 목표 달성률, value: 65, unit: "%" }
      dataset:
        shape: measure
        value: 65
        unit: "%"
        min: 0
        max: 100
        target: 80
        thresholds:
          - { at: 50, state: warn, label: 주의 }
          - { at: 80, state: safe, label: 목표선 }

entities 의 헤드라인은 마지막 fallback 으로 갈 때 쓴다.

8.5 matrix#

version: "0.5.6"
title: 분기별 채널 매출 구성
components:
  - type: ProportionComposition.StackedBarChart
    structure:
      dataset:
        shape: matrix
        columns:
          - { label: 분기, role: category }
          - { label: 온라인, role: value, unit: 억원 }
          - { label: 오프라인, role: value, unit: 억원 }
          - { label: 파트너, role: value, unit: 억원 }
        rows:
          - [1분기, 12, 8, 3]
          - [2분기, 15, 7, 4]
          - [3분기, 18, 9, 5]
          - [4분기, 22, 10, 6]

같은 모양으로 표도 적는다. 표와 차트의 차이는 데이터가 아니라 type 이다.

version: "0.5.6"
title: 요금제 비교
components:
  - type: AttributeComparison.ComparisonTable
    structure:
      dataset:
        shape: matrix
        columns:
          - { label: 항목, role: category }
          - { label: 베이직 }
          - { label: 프로 }
        rows:
          - [월 요금, 9900원, 19900원]
          - [저장 용량, 10GB, 100GB]
          - [지원, 이메일, 전화와 이메일]

8.6 다중 컴포넌트#

version: "0.5.6"
title: 2025 사업 성과 요약
components:
  - type: KPIKeyMetric.BigNumber
    structure:
      entities:
        - { label: 총매출, value: 152, unit: 억원, emphasis: true }
        - { label: 전년 대비, value: 38, unit: "%" }

  - type: Enumeration.List
    structure:
      entities:
        - { label: 신규 시장 진출, items: [동남아 3개국] }
        - { label: 반복 구매 증가, items: [구독 전환율 상승] }

원소 수 상한은 두지 않는다. 실데이터에 다중 컴포넌트 페이지가 아직 없어 근거 있는 숫자를 정할 수 없다.

컴포넌트 블록의 id 도 생성기는 채우지 않는다. page 수준 relations 가 블록을 가리킬 자리로 예약만 해 두었다.

8.7 중첩 컴포넌트#

항목 하나가 그 안에 또 컴포넌트를 품는 모양이다. entity.components[] 가 그 자리이고, 스키마에는 v0.4 때부터 열려 있다. 이 칸은 title 바로 아래 최상위 components[](L2 병치)와 다른 자리다 — 최상위는 Visual Summary 의 컴포넌트 목록이고, 여기는 structure.entities[] 항목 안에 매달린 중첩이다.

B-20 (2026-09-02, 허재영). 어느 생성기가 이 칸을 채울지를 갈랐다. PoC 생성기(MOR-1910)는 L3 테스트 범위로 entity.components[] 를 채운다. 이미 프롬프트 기본값이 L3 다. 실서비스 Summary 생성기(허재영·황현진)는 아직 채우지 않는다 — 8.8절 L2 정책은 그대로다. 검색 오케스트레이션(I-11)과 이종중첩 풀 정책(D-7/D-8)은 이 결정의 범위가 아니다. 버전 자리는 기존 산출물을 무효로 만들지 않으므로 올리지 않는다(칸은 원래 optional).

version: "0.5.6"
title: 분기별 사업 현황
components:
  - type: Enumeration.List
    structure:
      entities:
        - label: 1분기
          items: [신규 계약 12건]
          components:
            - type: KPIKeyMetric.BigNumber
              structure:
                entities:
                  - { label: 매출, value: 12, unit: 억원 }
        - label: 2분기
          items: [신규 계약 15건]
          components:
            - type: KPIKeyMetric.BigNumber
              structure:
                entities:
                  - { label: 매출, value: 15, unit: 억원 }

중첩을 못 읽는 컴포넌트는 자식의 entities 를 부모 items 로 편다 (1절 "중첩은 평탄화된다"). 위 예시가 평탄화되면 1분기 항목의 items 가 [신규 계약 12건, 매출 12억원] 이 된다. 깊이가 얼마든 결국 리스트로 읽힌다.

평탄화 앞에 세 단계가 더 있다 (2026-08-28 추가). 위 예시를 그대로 담은 후보가 색인에 없으면, 먼저 모양을 고정한 채 노드마다 카테고리를 내리고(N2), 그다음 Enumeration.List 를 벗겨 KPIKeyMetric.BigNumber 조각을 최상위로 올려 따로 찾는다(N3). 평탄화(N5)는 그 뒤다. 다섯 단계와 규칙 다섯은 capability-table.md 3.6절이 정한다. 부모를 위부터 벗기는 이유는 질의가 작아질수록 후보 풀이 커지는 반면 자식부터 떼면 내용을 지불하고도 부모가 여전히 복합으로 남기 때문이다(그 절 3.6.3).

왜 entity 아래에 매다나. 원소끼리 중첩시키면 그 자식이 부모의 어느 슬롯에 들어가는지 적을 자리가 없다. entity 가 곧 슬롯이므로 거기 매달면 위치가 정해진다.

이종중첩 컴포넌트(heterogeneous nested component) 는 위 중첩 중에서도 자식들의 type 이 서로 다른 경우를 가리킨다(위 예시가 그 경우다: 부모 Enumeration.List, 자식 KPIKeyMetric.BigNumber). 4단계 boundary 태깅 PoC 준비 중 Slack에서 처음 논의됐고, 검색 풀에서는 제외하기로 확정했다(2026-08-11 체크인, ../TODO.md D-7). 이런 케이스에 내용대치를 하려면 기존 조합 컴포넌트와는 별개의 대치 로직이 필요한데, 대부분 조합 Fallback 만으로 해결될 것으로 예상돼 WSJF 가 낮다고 판단했기 때문이다.

Topological Relation (위상 관계) 이종중첩 컴포넌트 안에서 semantic category 가 서로 다른 부분들이 서로에 대해 시각적으로 어떤 공간 관계로 놓이는지로 나눈 분류다(Slack, 2026-08-13). entity.components[] 가 부모 슬롯에 자식을 매다는 스키마 표현 방식과는 다른 층이다 — 이 분류는 스키마가 그 관계를 어떻게 적는지가 아니라, 서로 다른 semantic category 의 시각 영역이 실제로 어떻게 배치돼 있는지를 본다. 또한 ../rlsc/design-topology-and-isomorphism.md가 정의하는 Topology System / Design Isomorphism 체계와도 다르다. 그 문서는 tree invariant 보존 여부로 두 구조를 비교하고, 여기서는 이미 이종으로 판정된 한 컴포넌트 안에서 서로 다른 semantic category 영역이 공간을 어떻게 나눠 쓰는지만 본다.

• Containment(포함): 한 semantic category 의 시각 영역이 다른 semantic category 의 시각 영역 안에 완전히 들어간다. 위 1분기/2분기 예시(List 전체 영역 안에 분기마다 BigNumber 가 들어가 있는 모양, Enumeration.List 와 KPIKeyMetric.BigNumber)가 이 경우다.
• Overlap(중첩): 서로 다른 semantic category 의 시각 영역이 부분적으로 겹친다.
• Juxtaposition(병치): 서로 다른 semantic category 의 시각 영역이 겹치지 않고 나란히 놓인다. 2026-08-13 수량 산출에서 관측된 11건은 전부 이 경우였다(예: 좌측 BigNumber + 우측 List, 상단 List + 하단 VennDiagram).

Overlap 은 현재 RLSC 구조에서는 발생하지 않는다. RLSC 트리에서 한 node 는 하나의 부모 node 아래에만 들어가고, 2개 이상의 node 아래 동시에 들어가는 구조가 없다. 서로 다른 semantic category 영역이 겹치려면 그런 다중 소속이 전제돼야 하므로, 현재 데이터에서 관측 가능한 이종상태는 Containment 아니면 Juxtaposition 뿐이다. Overlap 은 위상 관계 분류 자체의 완결성을 위해 남겨 둔 범주이지, 지금 나오는 실제 사례는 아니다.

D-7의 검색 풀 제외 결정은 위상 관계와 무관하게 이종중첩 전체에 적용된다. 이 분류는 원인을 구분해 부르기 위한 것이지, 제외 범위를 셋 중 일부로 좁히자는 것이 아니다.

8.8 복잡도 레벨 셋 (complexity level)#

8.1 부터 8.7 까지가 보여 준 모양들은 Visual Summary 하나가 가질 수 있는 위상의 범위로 셋으로 묶인다. 그 범위를 가리키는 이름이 복잡도 레벨이다. 레벨은 산출물 한 건의 모양을 분류하는 이름이 아니라, 생성기가 낼 수 있도록 허용된 범위의 이름이다. 그래서 누적이다 — L1 ⊂ L2 ⊂ L3 이고, L3 를 켠 생성기가 컴포넌트 하나짜리 Visual Summary 를 내는 것은 정상이다.

여기서는 '질의'라고 부르지 않는다. 복잡도는 생성기 산출물(Visual Summary) 의 성질이고, 그것이 검색용 질의로 바뀌는 것은 나중이다(질의 변환기, query.ts). 이 문서에서 '질의 쪽'이라고 쓸 때는 색인 쪽과 대비하는 진영 이름이지 질의 변환기 산출물이 아니다.

레벨을 가르는 축은 하나다. 컴포넌트 경계를 넘는 계층(entity.components[])을 쓰느냐다. entity.children[](같은 컴포넌트 안 계층)은 어느 레벨에서나 쓴다 — 그것은 한 컴포넌트 내부의 내용 구조이지 위상이 아니다. L1 과 L2 를 가르는 것은 그다음 축인 최상위 원소 수다.

레벨마다 무엇이 더 필요한가.

생성기가 둘이고 지금 레벨이 서로 다르다. 섞어 읽으면 안 된다.

그래서 "L3 는 자리만 열려 있다"는 말은 생성 쪽에는 더 이상 맞지 않는다. 비어 있는 것은 그다음 두 칸이다 — 조각마다 검색을 호출하고 결과를 조립하는 오케스트레이션(../TODO.md I-11)과 중첩 후보의 대치 로직(D-7)이다. 4단계 실서비스에서 어느 레벨까지 켤지는 정해진 바 없고, 생성기 정책과 I-11 이 함께 풀려야 정할 수 있다.

8.9 복잡도 레벨을 켜고 끄는 방법 (프롬프트 블록화)#

레벨을 정책으로 통제하려면 레벨을 올리는 지시가 프롬프트에서 통째로 떼어지고 붙어야 한다. 지시가 여기저기 흩어져 있으면 "L2 로 내려라"가 한 군데를 지우는 일이 아니라 문장을 골라내는 일이 되고, 그 순간 프롬프트 판본마다 실제 레벨이 달라진다.

지금 상태는 절반쯤 그렇게 되어 있다. PoC 프롬프트에서 위상 지시는 ## 이종 컴포넌트 한 절(포함·병치·판별)에 뭉쳐 있어 물리적으로는 이미 한 덩어리다. 다만 둘이 모자란다.

그래서 필요한 모양은 셋이다. 블록을 레벨 단위로 쪼개고(topology-juxtaposition.md, topology-containment.md 처럼), 프롬프트 조립이 복잡도 레벨을 인자로 받고, 조립 결과가 레벨과 어긋나지 않는지 검사한다. 마지막 것이 특히 중요하다 — 레벨을 L2 로 내렸는데 생성기가 중첩을 내면 검색 오케스트레이션이 없는 상태에서 조용히 실패한다. 검증 쪽에는 이미 판정 재료가 있다. entity.components[] 사용 여부만 보면 산출물의 실제 레벨이 나오므로, 선언한 레벨과 대조하는 검사는 validate.ts 계측에 한 줄로 붙는다. 아직 구현되지 않았고 이 절이 요구사항만 적는다.

L3 안에서 이종이면 실질적으로 N3 부터 시작한다. D-7 이 이종중첩 템플릿을 검색 풀에서 제외했으므로(전체 약 1.10%) N1 과 N2 는 후보가 0이다. 동종중첩(자식 type 이 부모와 같은 경우)은 D-7 밖이라 N1·N2 가 살아 있다. 되돌릴지는 D-8 로 열려 있다.

'병치'라는 말이 두 층에서 쓰인다. 섞으면 안 된다.

• 질의 쪽 병치 (이 절의 L2): 최상위 components[] 에 원소가 여럿인 것. 컴포넌트 경계가 이미 갈려 있다.
• 색인 쪽 Juxtaposition (8.7절 위상 관계): 이종중첩으로 판정된 한 컴포넌트 안에서 서로 다른 semantic category 의 시각 영역이 겹치지 않고 나란히 놓인 것.

방향이 반대다. 앞은 나눠서 찾는 쪽이고 뒤는 이미 하나로 뭉쳐 있는 것을 부르는 이름이다. L2 질의의 조각들이 각각 검색돼 한 페이지에 함께 놓이면 결과물의 겉모습은 색인 쪽 Juxtaposition 과 닮지만, 후보 단위가 다르므로 같은 것이 아니다.

레벨과 카테고리 강등 칸 수는 서로 다른 예산이다. L3 질의라고 해서 카테고리를 더 많이 내릴 수 있는 것도, 덜 내려야 하는 것도 아니다. N-R4 가 정한 것과 같은 구분이다.

9. 열린 결정#

TODO.md B절이 SSoT 다. 2026-08-02 기준 남은 것은 아래 셋이고, 셋 다 규약 확정을 막지 않는다.

capability-table.md 8절의 확인 목록(실측 없는 개수 조건 35종, fallback 순서 두 칸, fallback 순서의 카테고리 선택)도 규약과 별개로 열려 있다.

10. 참고#

• 뒤집기 전 설계 철학 (보존): archive/projection-model.md
• 45종 capability 와 fallback 순서, 복합 구조 순서 N1~N5: capability-table.md 2절, 3절, 3.6절
• 단어장: semantic-taxonomy-v7.md
• 전체 흐름: pipeline-flow.md
• 대치 구간: content-binding-contract.md
• 이전 판: schema-v0.4.md (보존) · v0.2 · v0.3 · 요구사항 원문
• RLSC 실물: src/app/pipeline/common/type/layoutStructure.ts, packages/structured-layout/src/role-v2.ts
• 티켓: MOR-1773

↑ 목차로 · 2부 머리로

원문 spec/capability-table.md GitHub 에서 보기 64 KB 원문 제목 「Capability 테이블: 45종 전량」

이 문서의 역할 semantic category 45종 각각에 대해 성립 조건(못 채우면 후보에서 빠지는 것), 선택 내용과 속성(안 적어도 되는 것. 각각 entity 쪽 값과 params 쪽 표현 값이다), fallback 순서(그 종류가 색인에 없을 때 어디로 물러나는가)를 정한다. 노드가 여럿인 질의에서 어느 노드를 먼저 포기하는지는 3.6절이 정한다. schema-v0.4.md 3절의 capability 테이블 11행을 확장한 것이고, TODO.md B-14 가 말한 rlsc-capability 실물의 내용이다.

범위 v7 단어장 49종에서 지도 전용 4종(Distribution, Location, Highlight, Flow)을 뺀 45종이다. 지도는 지원하지 않는다 (2026-08-29 확정, 정원석) — 어휘에도 capability 에도 규약 enum 에도 넣지 않는다. B-24 의 "49종 확정" 표현은 이 결정으로 정정됐다. 페이지 역할 4종(Opening, TableOfContents, SectionDivider, Ending)은 B-24(2026-08-06 확정)에 따라 어휘에 포함해 이 표에도 넣었다 — 성립 조건은 C-4(페이지 역할 태그를 검색 풀에서 어떻게 다룰지) 확정을 기다리며 미정으로 뒀다가, 2026-08-27에 정본 시트 값(../plan/page-navigation-capability-draft.md)으로 채웠다. C-4 가 정하는 것은 그 종이 뽑혔을 때의 템플릿 공급이지 성립 조건이 아니라서 선행 조건이 아니었다. 지도 전용 4종은 지도 데이터가 있어야 성립해 structure 가 표현할 대상이 아니고, 당분간 summary 생성 대상에서도 뺀다(2026-08-17 스쿼드 확인).

오너 정원석 (MORDOR) · 상태 DRAFT · 최종 갱신 2026-09-11 (1절 생성 시점 쓰기 의무 명문화 — B-33 정본 반영, 규약 0.5.6. 10.1절 생성기 불허 9종 — 첫 출시 공급 제외 Gauge·RadarChart 추가, 재지정을 capability.json generatorRedirect 로. 2026-09-05 판은 B-36 generatable flag 확정, Opening 판정 위치조건 제거, 엣지 130개 동기화 — 10절·2.6절·3.5절)

관련 schema-v0.5.md 규약 · semantic-taxonomy-v7.md 단어장 · smart-diagram-data-model.md 6-1절 항목 수 실측 · ../plan/fallback-map-review-2026-08-13.md v2 반영 근거

아직 미확정인 것 (2026-08-17 3차). 없음 — 원저자(김수현·허재영) 확인 대기 항목이던 Funnel도 2026-08-17에 사용자 결정으로 닫혔다(6.2절). List·SWOT·HighlightedMessage·LongFormTextLayout·ProfileCard·TableOfContents 6행은 "구조 성립해도 색인 공급 부족·구조 상이 시 다음 후보로 진행 가능"(2.1절)이 이미 원칙으로 서 있어 확인 없이 반영했다. PictogramChart↔Gauge는 다시 뺐다(2026-09-05, B-30) — measure↔matrix projection 규칙은 만들지 않기로 확정했다(3.4절). PageNavigation 4종의 성립 조건은 2026-08-27에 정본 시트 값으로 채웠다(2.6절). Opening 의 "마지막 슬라이드" 겹침 우려(../plan/page-navigation-capability-draft.md 4.1절)는 같은 날 닫혔다 — 최신 정본 시트가 Opening/Ending 을 분리한다(허재영 확인). v7 우선순위(P1~P4)는 2026-08-17에 원본 시트에서 동기화 완료(semantic-taxonomy-v7.md 3절).

이 문서 훑기

1. 세 가지를 선언한다#

2026-08-02 결정이다. 요구 등급을 필수와 선호와 무시 세 값으로 나누는 대신, 성립 조건은 최소로 줄이고 나머지는 기본값을 가진 선택 값으로 옮긴다. 채점 코드는 건드리지 않는다.

여기 적히지 않은 것은 전부 무시한다. 규약 1절 "선언되지 않은 것은 무시한다"가 기본 동작이라 따로 선언하지 않는다.

무시는 읽는 쪽의 기본 동작이지 쓰는 쪽의 허가가 아니다 — 생성 시점에는 읽는다고 선언한 것만 쓴다 (B-33, 2026-09-05 정원석 확정). Summary 생성기는 2절이 그 카테고리의 선택 내용으로 선언하지 않은 내용 필드에 값을 담지 않는다. 담을 것이 있으면 그 entity 의 items 로 적는다(3.4절 P3 와 같은 방향). 생성 경로에는 P3 가 돌지 않는다 — 3.4절은 "fallback 은 카테고리를 바꾸는 일이므로" 출발→도착 엣지에서 옮길 것을 정하는 규칙이라, 생성기가 처음부터 그 카테고리로 쓰면 옮겨 줄 주체가 없어 내용이 그대로 소멸한다(HierarchicalTree 를 Pyramid 로 재지정한 실측에서 하위 9개가 사라졌다 — iui #1023). B-33 결정문이 "안 읽는 내용 필드는 P3 으로 보존돼 소멸하지 않는다"고 적은 것은 대치 경로 한정이다. 이 의무는 생성기 스코프에만 적용한다 — 색인 검색·대치 경로는 B-33 결정대로 그대로 두고("빈 결과보다 낫다"), 이미 만들어진 산출물을 소급해 무효로 보지 않는다.

기본값 규칙#

기본값은 속성에만 준다. 내용에는 주지 않는다.

apex(어느 쪽이 꼭대기인가)는 속성이라 기본값을 줘도 된다. value(숫자가 얼마인가)는 내용이라 기본값을 주면 없는 데이터를 지어내는 것이므로 성립 조건에 남긴다.

개수 조건의 출처#

실측 표시가 붙은 값은 jari 0.12.0 의 LAYOUT_CONTENT_CONTRACTS 에서 온 것이다(smart-diagram-data-model.md 6-1절). 배치 머신이 실제로 받는 항목 수 상하한이라 근거가 확실하다.

표시가 없는 값은 단어장 정의문에서 유도한 설계 판단이다. 예를 들어 Pyramid 의 최소 3은 정의문 "3단 이상 수평 층"에서, Versus 의 정확히 2는 "2개의 대상을 서로 대응시켜"에서 왔다. 상한이 없는 것은 상한을 두지 않았다는 뜻이다. 8절에 확인이 필요한 것을 모아 두었다.

2. 성립 조건과 선택 내용, 속성#

이 문서의 카테고리 이름은 밑줄 표기다. 이 표는 색인과 검색이 읽는 쪽이고, 그쪽 저장 키가 Enumeration_List 형식이다. 생성물(질의 쪽)의 표기는 점이다(Enumeration.List, 규약 2.3절). 같은 카테고리를 가리키며, 검색 모듈이 받는 즉시 점을 밑줄로 바꾼다.

선택 내용과 속성을 두 열로 갈랐다 (2026-08-23). 종전에는 "선택 속성" 한 열에 둘을 섞어 담았고, 그래서 fallback 규칙(3.4절)을 기계로 계산할 수 없었다.

두 열의 정본은 schema/capability.json 의 reads.content / reads.relations 와 reads.params 다. 이 표는 그것을 사람이 읽는 모양으로 옮긴 것이고, 두 열의 값이 그쪽과 어긋나면 JSON 을 따른다.

n 은 entities 개수다. dataset 열의 값은 2026-08-02 에 확정한 2모양(measure, matrix)이고, 빈 칸은 dataset 을 쓰지 않는다는 뜻이다. 두 열 모두 빈 칸이면 그 카테고리는 선택 값이 하나도 없다는 뜻이다.

개수 상한(n 이하)은 생성기·질의 쪽 제약이지, I.I.S.가 실제 디자인을 인식하는 쪽 제약이 아니다 (2026-09-05, B-27 병행 확정). Timeline의 "2 이상 15 이하" 같은 상한은 Summary 생성기가 이 카테고리로 요청해도 되는 실용적 범위(검색 풀 다양성에 맞춘 것)를 정한 것이다. I.I.S.는 이미 존재하는 실제 디자인의 구조를 있는 그대로 인식·태깅하므로, 실제 Timeline 디자인이 20단계짜리여도 그 개수 때문에 "이건 Timeline이 아니다"로 재분류하지 않는다. 상한은 질의(생성물)의 성립 조건 판정과 그에 따른 fallback 사다리(3절)에만 적용된다.

2.1 나열과 비교#

#2, #4 의 entities+columns 경로 (2026-08-06 추가). 병합·계층 헤더가 있는 표는 matrix 로 못 채운다 — Column.role/axis/type 이 차트 어휘라 병합을 표현할 자리가 없다. 이 둘만 entities(행, entity.children[] 로 상위 범주가 하위 행을 거느리는 병합을 적는다)와 columns(헤더)의 조합을 대안으로 받는다. 모양과 범위(계층형 병합만, 축이 갈라지는 독립적 rowspan은 범위 밖)는 schema-v0.5.md 2.5.1절, 계기는 Slack. 이 경로로 채워진 컴포넌트는 3.2절 fallback에서 matrix 필수 카테고리(Quadrant, GanttChart, Calendar)로 가지 않는다 — 대부분 그 카테고리의 성립 조건 자체를 못 채우지만, projection 규칙(3.4절)이 entities 를 matrix.rows 로 접는 식으로 우회하지 않도록 여기 못박아 둔다.

2.2 순서와 흐름#

2.3 계층과 범위#

NestedScope 는 children 을 쓰지 않는다 (2026-09-04, ../TODO.md B-34 제안, 정원석 — 허재영 확인 대기). 2026-09-02 초안은 뿌리 1개짜리를 성립으로 보고 개수를 1 이상으로 내리며 표준 인코딩을 사슬(바깥 범위 label → 안쪽 범위 children)로 정했었다. 하지만 semantic-taxonomy-v7.md 145행 자신이 "NestedScope 와 HierarchicalTree 를 가르는 것은 의미가 아니라 동심원으로 그리는지다. 단일 사슬 포함 관계는 가지가 하나뿐인 트리와 구조적으로 같다"고 적어, 사슬 인코딩은 두 종을 데이터상 같은 모양으로 만들어 버린다. NestedScope 의 전형인 TAM/SAM/SOM 은 가변 깊이 트리가 아니라 정해진 개수의 동심원에 라벨 하나씩, 안쪽→바깥쪽 순서만 있으면 되는 구조다. 그래서 개수를 2 이상(원래 기준)으로 되돌리고 내용 조건을 없앤다. 순서는 별도 필드로 담지 않고 entities 배열 순서 그 자체로 표현한다 — Steps·Timeline·Staircase·Cycle 등 다른 순서형 카테고리도 전부 이 방식이고, SWOT 이 이미 order 를 다른 뜻(사분면 배치)의 속성으로 쓰고 있어 이름도 겹친다. 필요한 건 어느 쪽 끝이 안쪽인지 뒤집는 속성 direction(inward/outward, 기본 inward) 뿐이다 — 이 점에서 Pyramid(18행, weight/apex)보다 Staircase(11행, 내용 없음, direction 만)에 더 가깝다. 3.3절의 Pyramid↔NestedScope 짝은 유지하되, fallback 규칙(3.6절)의 children 언급은 배열 그대로 전달로 정정한다. 플랫 배열이 배타 조건과도 맞는다. golden-set-production-notes.md 2절이 골든셋 프롬프트 튜닝에서 역산한 진짜 배타 조건은 서술 순서(안→밖 vs 밖→안)가 아니라 갈라짐 여부였다 — HierarchicalTree는 한 상위가 하위 여럿을 거느려 가지가 갈라지고, NestedScope는 단일 사슬이다. children 트리는 실수로 가지를 칠 수 있지만, entities 배열은 애초에 분기가 불가능한 구조라 이 조건을 데이터 모양으로 강제한다.

2.4 수치#

2.5 텍스트와 사람#

2.6 페이지 역할#

2.6절의 내용 조건은 배치 가능성만 남긴다 (2026-09-10, 허재영 판단 · 정원석 확인 대기). 1절이 성립 조건을 "이게 없으면 그 종류로 배치가 불가능한 것" 으로 정의한다. 그 기준으로 보면 "번호와 제목을 나열한다"(43행), "다음 한 섹션의 번호와 제목"(44행), "종료를 알리는 단일 메시지"(45행)는 종을 설명하는 문장이지 배치 가능성 조건이 아니다. 기계가 보는 것은 43행의 "흐름·단계가 없다"(relations 없음)와 44·45행의 "본문 콘텐츠가 없다"(dataset·children·components 없음)뿐이고, 설명 문장은 남겨 두되 성립 판정에 넣지 않는다. 어느 종인지는 질의가 적은 type 과 I.I.S. 태깅이 정한다.

2026-08-27에 정본 시트 값으로 채웠다. 출처와 근거는 ../plan/page-navigation-capability-draft.md — 원본 시트 레이아웃 텍사노미 신규 탭에 성립 조건이 이미 있었고, C-4(검색 풀 정책)가 정하는 것은 뽑힌 뒤의 템플릿 공급이지 성립 조건이 아니라서 선행 조건에서 풀었다. Opening·SectionDivider·Ending 이 정확히 1인 것은 시트가 셋 다 "단일 슬라이드 구조 / 단일 메시지" 로 적기 때문이고, TableOfContents 만 2 이상인 것은 항목이 하나면 목차가 아니라 간지이기 때문이다. dataset 은 넷 다 없다 — 수치 데이터를 담는 종이 아니다. 단 structure 자체는 필요하다: 규약 v0.5 의 structureSchema 가 entities 나 dataset 을 요구하므로, 이 4종은 entities 로 적는다(Opening 이면 제목이 label 이고 발표자·날짜·소속은 그 entity 의 items 다 — 42행 개수 "정확히 1" 과 시트의 "단일 슬라이드 구조" 를 살린 표기다. 2026-09-10 정정, 허재영 판단 · 정원석 확인 대기. 같은 날 그 items 는 성립 조건에서 선택 내용으로 내려갔다. TableOfContents 면 섹션마다 entity 하나). fallback 순서(3.2절)는 2026-08-17에 이미 유형별로 갈라 뒀다 — TableOfContents 는 List → ListingTable, 나머지 셋은 HighlightedMessage → List. Opening은 위치가 아니라 내용으로만 판정한다 (2026-09-05 정원석 확정). 파이프라인이 페이지를 독립적으로 처리해 추출·생성·검색·대치 어느 구간도 그 페이지가 몇 번째인지 알 수 있는 경로가 없다 — "맨 앞장 전용"은 시스템이 보장하거나 검증할 수 있는 조건이 아니다. 42번 행이 실제 판정 전부이고, 실사용에서 대개 첫 장에 나오는 것은 관습이지 시스템이 위치를 강제해서가 아니다. 2026-09-10 에 42번 행의 내용 조건을 없앴다 (허재영 판단, 정원석 확인 대기). 종전에는 "제목이 있고 발표자·날짜·소속 중 하나 이상이 함께 온다" 를 요구했다. 1절이 성립 조건을 "이게 없으면 그 종류로 배치가 불가능한 것" 으로 정의하는데, 제목만 있는 표지도 표지 레이아웃에 배치된다. 그래서 그 요구는 배치 가능성 조건이 아니라 종을 가르는 조건이었고, 발표자·날짜·소속은 선택 내용으로 내렸다. 그 결과 Opening·Ending·SectionDivider 는 구조로 구분되지 않는다 — 셋 다 entity 하나에 본문이 없다. 어느 종인지는 질의가 적은 type 과 I.I.S. 태깅이 정하고, 성립 판정은 배치 가능성만 본다.

성립 조건이 내용을 요구하는 것은 넷에 페이지 역할 4종이 더해졌다. BigNumber 와 Gauge 의 수치, HierarchicalTree 의 children, ComboChart 의 혼합 조건, 그리고 2.6절의 내용 조건 3행이다(Opening 은 2026-09-10 에 빠졌다). (NestedScope 는 2026-09-04 부로 children 요구가 빠져 다섯에서 넷으로 줄었다 — 2.3절.) 나머지는 개수 조건과 matrix 유무만 본다. 옛 테이블에서 필수였던 apex, author, speaker, intersects 는 전부 기본값을 가진 선택 값으로 내려갔다. 그중 apex 는 속성 열로, 나머지 셋은 선택 내용 열로 간다.

3. fallback 순서#

그 종류의 후보가 색인에 없을 때 어디로 물러나는지다. fallback 을 한 번 따라갈 때마다 무엇을 잃는지 함께 적는다.

3.5절까지는 노드 하나를 다룬다. 질의가 중첩이나 병치로 노드를 여럿 가질 때 어느 노드를 먼저 포기하는지는 3.6절이 정한다.

3.0.1 fallback 은 그래프다 (2026-08-04 확정)#

3.2절의 각 행은 그 카테고리 하나의 후속 우선순위 목록이고, 검색 모듈은 자기 행만 왼쪽부터 따라간다. 다른 카테고리의 행을 이어 붙이지 않는다.

AttributeComparison_Versus 행이 'ComparisonTable → List' 인 것은 'Versus 가 안 되면 ComparisonTable, 그것도 안 되면 List' 라는 뜻이다. ComparisonTable 의 fallback 이 List 라는 뜻이 아니다. ComparisonTable 자신의 fallback 은 자기 행이 정하고 'ListingTable → List' 다. 그래서 Versus 에서 출발한 대치는 ListingTable 을 거치지 않는다.

이 정의가 없으면 구현이 갈린다. 나가는 자리가 둘 이상인 카테고리가 34종이고, 행을 이어 붙여 읽으면 그중 21종에서 '어느 쪽이 먼저인가'가 정해지지 않는다. 예를 들어 ComparisonTable 은 자기 행이 ListingTable 을 먼저 두는데, Versus 행을 이어 붙이면 List 가 먼저인 것처럼 읽힌다.

3.5절 엣지 표는 이 정의대로 계산했다. 엣지 하나는 '출발 카테고리의 자기 행에 적힌 도착' 이다. 그래서 엣지 수가 행마다의 목록 길이 합인 75개다. 행을 경로로 읽어 연속쌍을 뽑으면 51개가 나오는데, 그 51개에는 위 Versus 예시처럼 어느 행에도 적혀 있지 않은 엣지가 섞인다.

3.0 마지막 fallback 은 셋이고 내용 모양이 고른다#

아래 표는 마지막 자리를 Enumeration_List 로 적었지만, 실제 마지막 fallback 은 셋이고 그중 하나를 내용 모양이 고른다 (2026-08-02 정원석). 규약 1절 "어떤 구조든 리스트로 읽힌다"는 나열이 가능하다까지만 보장하고, 나열이 언제나 최선의 바닥이라고 말하지는 않는다. 긴 문단 하나를 글머리표 목록으로 그리면 오히려 어색하다.

셋 다 성립 조건이 개수 조건 하나뿐이어서 언제나 하나는 성립한다. 그래서 fallback 순서는 반드시 끝난다.

이 규칙이 TODO.md C-5 의 답이기도 하다. '맞는 컴포넌트가 없으면 무엇을 보여줄지'는 별도 정책이 아니라 fallback 순서가 처리한다. 마지막 fallback 셋 중 하나가 항상 나오므로 빈 결과를 사용자에게 보여줄 일이 없다.

3.1 차트 계열은 BarChart 와 LineAreaChart 를 오간다 (2026-08-17 갱신)#

차트 아홉 종 대부분이 MagnitudeRanking_BarChart 나 Trend_LineAreaChart 를 거쳐 AttributeComparison_ComparisonTable 로, 최종적으로 List 로 간다. 어떤 matrix 든 막대나 선으로는 그릴 수 있고, BarChart 가 차트 중 색인이 가장 두껍기 때문이다(색인 236건, 질의 120건으로 차트 계열 1위). v2 는 BarChart 와 LineAreaChart 를 서로의 첫 후보로 두어(3.3절) 상한 폐지(4절) 이후에도 두 후보가 함께 막히는 경우를 줄였다.

PieChart ─┐
DonutChart ┤
TreeMap    ┤
Pictogram  ├→ BarChart ⇄ LineAreaChart → ComparisonTable → List
StackedBar ┤
Combo      ┤
Radar      ┤
Bubble    ─┘

3.2 fallback 순서 전량#

이 열은 그 카테고리 하나의 후속 우선순위 목록이다 (3.0.1절). 왼쪽부터 본다. 2026-08-17에 3차에 걸쳐 전량 확정했다 — 원저자 확인 대기였던 Funnel(6.2절)도 사용자 결정으로 닫혔다.

ComboChart 는 BarChart·LineAreaChart 로 물러나지 않는다 (2026-08-21 개정). 종전 규칙은 계열 타입을 읽어 "전부 bar 면 BarChart, 전부 line 이면 LineAreaChart, 섞여 있으면 표로" 판정하는 조건부였다(../plan/fallback-map-review-2026-08-13.md 5절). 폐기한다.

성립 조건이 그 분기를 스스로 배제한다. 2절 32번이 matrix 필수 + 계열 type 2종 이상 또는 axis 2종 이상을 요구한다. 계열이 전부 bar 면 type 은 1종이므로, 그 컴포넌트가 ComboChart 로 성립한 이유는 axis 2종밖에 없다. 즉 "계열이 전부 bar/line 인 ComboChart" 는 언제나 이중 축이다. 그런데 이중 축은 ComboChart 에서만 지원되므로(김수현, 2026-08-21) 막대나 선으로 내리면 반드시 축 하나가 사라진다. 조건부 분기는 발동할 때마다 데이터를 깨는 규칙이었다.

종전 규칙은 area 도 다루지 못했다. Column.type 은 bar·line·area 셋인데(규약 2.1절) "전부 area" 는 세 갈래 어디에도 걸리지 않았다. 고정 목록으로 바꾸면 이 구멍도 함께 닫힌다.

표로 물러나도 이중 축은 잃는다. 표는 축을 그리지 않는다. 다만 matrix 의 행과 열이 그대로 보존되므로 수치가 사라지지는 않는다. 잃는 것을 최소화하는 자리가 표다.

axis 는 이름이 겹친다. ComboChart 의 axis 는 계열이 어느 축에 붙는가(left/right)이고, ComparisonTable 의 axis 는 첫 열이 기준 축인가다(2절 4번). 키 이름이 같아 P2 가 버리지 않고 통과시키지만 뜻이 다르다. 3.5절 표는 이 엣지에서 axis 를 살아남는 것으로 적지 않는다.

3.3 서로를 가리키는 쌍이 있다 (2026-08-17 갱신)#

ListingTable과 ComparisonTable, Steps와 Timeline, Pyramid와 NestedScope, BigNumber와 Gauge, BarChart와 LineAreaChart, PieChart와 DonutChart, DialogueChat와 QuoteTestimonial, ProfileCard와 ResumeCV는 서로를 후속 우선순위의 첫 자리로 가리킨다. 순환이 아니다. 3.0.1절대로 검색 모듈이 자기 행만 따라가므로 도착 카테고리의 행으로 넘어가는 일이 없고, 되돌아갈 자리가 애초에 생기지 않는다. 방문 기록도 필요 없다.

Steps 행은 Timeline → Staircase → List 이고 Timeline 행은 Steps → Staircase → List 다. Steps 에서 출발해 Timeline 후보가 없으면 다음은 Staircase 이지 Timeline 행의 Steps 가 아니다.

이 쌍들은 7/24 회의의 "규칙 관점에서 비슷한 카테고리를 묶어 유형 간 관계도를 만들고"에 해당한다(회의록).

3.4 projection 규칙 열 (여덟 확정 + 둘 제안)#

fallback 은 카테고리를 바꾸는 일이므로, 출발 카테고리가 쓰던 것을 도착 카테고리가 못 읽는 경우가 생긴다. 그때 무엇을 어디로 보내는지를 여기서 정한다. 규약 5절 4번이 "삭제하지 않고 텍스트로 흘려보낸다"까지만 정하고 어디로인지는 안 정하던 자리다.

P2 보충 — 표 도착지에서는 차트 열 어휘를 버린다 (2026-09-10 신설, 허재영 판단 · 정원석 확인 대기). matrix 를 그대로 읽는 표 도착지(2.5.1절 entities+columns 경로를 가진 ListingTable 과 ComparisonTable)로 갈 때 Column.role 과 axis 와 type 을 버린다. 2.5.1절이 이 셋을 순수 차트 어휘라고 적으므로 표에서는 뜻이 없고, P2 가 말하는 표현 선택과 같은 자리다. 이 규칙이 없으면 값 열에 문자열이 섞인 차트가 표 도착지에서도 B-37 로 탈락해 List 까지 내려간다 — 표는 문자열을 담는 자리인데도 그렇다. 규칙 라벨은 바뀌지 않고 손실 목록에 한 줄이 붙는다.

내용은 버리지 않고 표현만 버린다. P2 만 버리는 규칙이고 나머지는 전부 옮기는 규칙이다. 표현 선택(orientation, apex, icon 같은 것)은 도착 카테고리에서 뜻이 없으므로 버려도 내용이 줄지 않는다.

measure↔matrix projection 규칙은 만들지 않는다 (B-30, 2026-09-05 확정). 단일 값(measure)과 복합 데이터(matrix)는 형태가 근본적으로 달라서, 서로 변환하는 규칙(옛 제안 P9·P10)을 두면 원래 의도를 왜곡한다. Gauge(measure)를 matrix 필수인 BarChart·PictogramChart 로 접으면 비교·구성 정보가 사라진 막대 하나·아이콘 그룹 하나만 남고, 반대로 PictogramChart(matrix, 여러 값)의 여러 행 중 하나를 뽑아 Gauge(measure)의 대표값으로 쓰면 원본에 없던 target/max/min을 채울 근거도 없이 나머지 값을 전부 버리게 된다. 그래서 KPIKeyMetric_Gauge와 ProportionComposition_PictogramChart의 fallback 체인에서 서로를 뺐다(3.2절). 2026-08-17에 ../plan/fallback-map-review-2026-08-13.md 가 한 번 같은 결론을 냈었는데, 이후 이 문서와 report/*, TODO.md 가 옛 체인으로 되돌아가 있었다 — 이번이 그 유실 복원이다. PictogramChart → BigNumber도 뺐다(2026-09-05, 재검토). 처음엔 BigNumber가 entities 1개 이상을 받으니 P4(행마다 entity로 편다)로 행을 전부 보존할 수 있어 예외로 남겼는데, 확인해 보니 P4는 label과 items만 채우고 BigNumber의 필수 조건인 entity당 value는 채워주지 않는다. BigNumber도 entities가 여럿일 수 있을 뿐 entity 하나당 값 하나라는 단일값 콘텐츠 모델이라, matrix의 임의 열 구조를 우겨넣을 수 없다는 점에서 Gauge와 같은 범주다.

3.5 엣지 130개 전량#

3.2절의 각 행이 자기 카테고리에서 나가는 엣지를 정한다(3.0.1절). 행마다의 목록 길이를 합하면 130개이고 중복이 없다. 규칙은 2절 capability 에서 계산한 것이다.

2026-08-04 에 51개에서 75개로 다시 계산했다. 행을 경로로 읽고 연속쌍을 뽑는 방식이 어느 행에도 적혀 있지 않은 엣지를 만들고 행에 적힌 엣지 25개를 빠뜨렸기 때문이다(3.0.1절 근거).

2026-08-17 1차에 75개에서 111개로, 2차에 111개에서 125개로 다시 계산했다. fallback map v2 반영(../plan/fallback-map-review-2026-08-13.md)으로 상한이 폐지(4절)되고, 이어서 허재영님 2차 피드백을 반영하면서 List·SWOT·HighlightedMessage·LongFormTextLayout·TableOfContents·ProfileCard(6.1절)가 색인 공급 부족 시나리오로 확정됐고, PictogramChart↔Gauge(6.2절)가 근접도 우선으로 복원됐고, PageNavigation 3종(Opening·SectionDivider·Ending)이 List 대신 HighlightedMessage로 분화됐다(6.4절). Funnel만 여전히 원저자 확인 대기다.

2026-08-21 에 125개(3차 반영 뒤 128개)에서 131개로 다시 계산했다. ComboChart 의 조건부 규칙을 폐기하고 고정 목록(ComparisonTable → ListingTable → List)으로 바꾸면서 엣지 3개가 새로 생겼다(3.2절 상자).