아카이브 · 당시 기준

2026-10-22 보관. 규약 원문 전량을 spec.html 로 옮기기 전 판입니다. 무버전 원본을 1.0.0 기준판으로 등록했습니다. 본문과 자동 동기화 표는 보관 당시 내용입니다.

현재 기준과 원본 보기 → · 보관 목록

← 미리디 기술 사전

내용시각화 규약 v0.5.6 작성 2026-08-26 · 갱신 2026-10-18 · 저자 홍지혜(jhhong) · origin/main 대조 · 이전판

Visual Summary 규약 v0.5.6

사용자 내용을 구조화하는 규약과 그 내용을 실제 슬롯에 넣는 구현을 연결한다. 갱신 2026-10-17 · 규약 v0.5.6 · 인식 45종 / 생성 허용 36종. 과거 덱의 도해는 날짜가 있는 이력으로 남기고 현재 실행은 고정 origin/main 소스로 다시 설명했다.

§0

30초 요약: 규약은 v0.5.6, 실행은 Rust comp-frame

질문현재 답
무엇을 만드는가Visual Summary는 사용자 내용을 type·structure·params로 구조화한다. 완성 디자인이나 RLSC 변환물이 아니다
현재 규약v0.5.6. 인식 어휘 45종, 생성 허용 36종, fallback 엣지 130개. 위키 spec/design은 9월 이후 변경 없음
검색 실행iui의 rust/comp-pass가 생성 연결·검색·랭킹·중첩·나눠 담기를 맡는다. 10월 12일 TS 검색 코어 제거
대치 실행TypeScript 클라이언트가 응답 binding과 sheetJson으로 대치 데이터를 만든다. 공통 노드 정책이 안팎 잔여를 판단
읽을 순서이 규약 → 검색·대치 실행 지도 → 역할별 텍스트 예시 → 50문항 학습
측정과 이력8월 덱·공급 분포·9월 평가 수치는 당시 기록이다. 오늘의 운영 풀·배포 상태로 재표시하지 않는다
now

2026-10-17 현재 범위: 규약·생성기·제품 검색을 나눠 읽는다

고정 원천은 wiki a0f8b0196, aippt e6ffa4bdf, iui bcd1d0218다. 아래의 종수는 최신 capability JSON을 다시 센 값이다. 첫 출시의 P0 우선순위 그림과 현재 생성 허용 집합, 실제 서버 공급은 서로 다른 기준이다.

층기준주의
규약 enum·capability45종지도 4종은 이 집합 밖이다
규약의 생성 허용36종generatable:false 9종을 제외한다. 기존 산출물을 소급 무효화하는 규칙은 아니다
IIS 경계 구현aippt의 경계 어휘는 Geo 4종을 포함한 49종이미 존재하는 디자인의 인식 어휘와 생성 어휘가 다르다
제품의 지정 종류generationTypes / 0군·추천 1군지정 종류의 검색 전략이며 규약 enum 버전과 다르다

생성 불허 9종은 Quadrant·GanttChart·Calendar·TreeMap·PictogramChart·BubbleChart·HierarchicalTree·RadarChart·Gauge다. RadarChart의 생성 재지정은 ComparisonTable로 별도 선언되며 검색 fallback 행과 다르다. Gauge는 BigNumber로 간다.

2026-09-18에 공유된 P0/P1/P2 그림은 그날의 우선순위 증거다. 최신 위키의 단어장 원문과 별도 자료였으므로 현재 출시 완료나 실제 공급 확보의 근거로 쓰지 않는다. 현재 운영 공급·배포 여부는 이번 소스 검토에서 재측정하지 않았다.

capability 정본 · IIS 경계 어휘 · 제품 검색 군

설계·측정 이력 · 2026-08-04 — 당시 자료의 도해와 판단을 보존한다. 이 절의 “현행·지금·미완”은 해당 시점의 표현이며 현재 구현 상태는 §0·§11~13을 따른다.

§1

오해부터 지운다 — 두 갈래

덱 p.3

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

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

설계·측정 이력 · 2026-07-26 — 당시 자료의 도해와 판단을 보존한다. 이 절의 “현행·지금·미완”은 해당 시점의 표현이며 현재 구현 상태는 §0·§11~13을 따른다.

§2

왜 하나 — BAD 의 85%

덱 p.4

렌더링 문제가 아니다

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

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

세부 원인 넷

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

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

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

설계·측정 이력 · 2026-08-04 — 당시 자료의 도해와 판단을 보존한다. 이 절의 “현행·지금·미완”은 해당 시점의 표현이며 현재 구현 상태는 §0·§11~13을 따른다.

§3

무엇이 뭉개지나

덱 p.5

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

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

설계·측정 이력 · 2026-08-04 — 당시 자료의 도해와 판단을 보존한다. 이 절의 “현행·지금·미완”은 해당 시점의 표현이며 현재 구현 상태는 §0·§11~13을 따른다.

§4

로드맵과 태그의 모호성

덱 p.6–7

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

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

3단계는 실행하지 않는다

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

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

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

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

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

설계·측정 이력 · 2026-07~08 — 당시 자료의 도해와 판단을 보존한다. 이 절의 “현행·지금·미완”은 해당 시점의 표현이며 현재 구현 상태는 §0·§11~13을 따른다.

§5

실증 근거 — 공급과 수요

덱 p.8

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

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

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

§6

v0.5.6이 정한 내용·속성·생성 의무

최상위는 components[], type은 필수 결합값 대분류.중분류다. structure는 실제 내용, params는 표현 속성, decoration은 꾸밈 선호다. 단어장 49종에서 Geo 4종을 제외한 45종이 규약 인식 어휘이며, PageNavigation 4종은 포함된다. “페이지 역할도 빼서 41종”은 초기 규약의 이력이다.

필드의미예
entities항목과 label·items·value·period 등의 내용과학 발표회 3단계
datasetmeasure 또는 matrix참여율 80% / 반별 인원 표
relationsintersects·compares 관계교집합 설명
columnsentities로 표를 적는 헤더담당자·기한
params그 카테고리의 표현 값orientation: horizontal
decorationornament·background 축의 prefer/indifferent/avoid배경 피하기

B-33: 읽는 쪽의 “선언되지 않은 것은 무시”를 쓰는 쪽의 허가로 읽지 않는다. 생성기는 그 카테고리가 읽는다고 선언한 내용 필드에만 쓰고, 다른 내용은 items에 넣는다. 처음부터 해당 타입으로 생성하면 fallback P3이 자동으로 돌지 않는다. 이미 만든 산출물의 검색·대치를 소급 금지하는 의무는 아니다.

버전은 0.5.6이며 생성 허용은 36종이다. enum 자체를 36종으로 축소하지 않는다. 규약은 MAJOR·MINOR로 유효성을 판단하고 PATCH는 계측에 사용한다. 구현 README의 “45종 생성 어휘”는 전체 사전과 실제 생성 허용 필터를 구분해서 읽어야 한다.

버전 및 현행 변경표 · B-33·읽기와 쓰기

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

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

원본 커밋 61bfcfa6b268

§7

capability와 fallback: 표현의 성립과 실제 후보를 구분한다

규칙의미
성립 조건내용·개수·dataset이 그 표현을 성립시키는지 확인한다
선택 내용없으면 없는 것으로 처리한다. value 같은 내용을 기본값으로 지어내지 않는다
표현 속성선언한 기본값을 사용할 수 있다
fallback요청 카테고리 자기 행을 왼쪽부터 끝까지 본다. 도착지 행으로 갈아타지 않는다

현재 기계표는 45종·130엣지다. fallback 칸 수 상한은 없으며 각 도착지에서 투영 후 성립을 검사한다. 마지막 표현은 List·LongFormTextLayout·HighlightedMessage 중 내용에 맞게 고른다.

표현이 성립한다는 것이 실제 검색 결과 한 개 이상을 보장하지는 않는다. 후보 공급이 없거나 용량·내용·표 확장 검사에서 모두 탈락하면 결과는 비어 있을 수 있다. 이 문서의 예전 “빈 결과가 사용자에게 갈 길이 없다”는 규약 수준의 기대를 운영 보장으로 확대했던 문장을 수정했다.

fallback 규칙 · 현재 Rust tier 계산

§8

projection·복잡도·중첩: 바꾸는 대상을 구분한다

이름바꾸는 것
P1~P7카테고리가 달라질 때 내용·dataset·속성·관계 설명의 위치
L1 ⊂ L2 ⊂ L3생성기에 허용한 복잡도 범위. 단일 / 최상위 병치 / entity.components 중첩
N1~N5중첩 구조를 유지하거나 부모를 벗기거나 글로 펴는 검색 순서

P2는 읽지 않는 params를 버리고, P3은 읽지 않는 내용 필드를 items로 옮긴다. P4는 matrix를 항목으로, P5는 measure를 텍스트 수치 항목으로, P6은 항목을 표로, P7은 표현하지 못하는 관계 설명을 옮긴다. P8의 초과 항목 접기는 폐기됐다. measure↔matrix의 임의 P9·P10도 만들지 않기로 했다. 표현 변경을 원본 의미 전체의 무손실 보장으로 쓰지 않는다.

N1은 전체 구조·종류 검색, N2는 구조를 둔 카테고리 변경, N3·N4는 부모 벗기기, N5는 글로 평탄화다. Hierarchy는 부모 벗기기로 소속을 잃지 않도록 N5로 간다. 지금 Rust에 사다리가 구현돼 있으므로 “I-11 코드 미착수”는 과거 위키 기록으로 읽는다. 과거 이종중첩 공급 제외도 최신 N1 결과가 항상 0이라는 증거가 아니다.

projection과 중첩 규약 · 현재 투영 · 현재 중첩 사다리

설계·측정 이력 · 2026-08-03~04 — 당시 자료의 도해와 판단을 보존한다. 이 절의 “현행·지금·미완”은 해당 시점의 표현이며 현재 구현 상태는 §0·§11~13을 따른다.

§9

꾸밈구조 — 뒤집힌 결정

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

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

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

뒤집은 이유 1

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

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

뒤집은 이유 2

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

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

왜 등급 하나로는 안 되나

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

1. 다른 것이 섞인다

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

2. 조합을 못 적는다

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

3. 끼울 자리가 없다

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

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

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

그래서 축 집합으로 둔다

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

선호값은 셋이다

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

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

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

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

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

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

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

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

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

왜 미루나

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

선례가 있다

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

decoration 도 같은 방식으로 연다.

설계·측정 이력 · 2026-08-04 — 당시 자료의 도해와 판단을 보존한다. 이 절의 “현행·지금·미완”은 해당 시점의 표현이며 현재 구현 상태는 §0·§11~13을 따른다.

§10

다섯 구간이 다 붙어야 돈다

덱 p.19–20

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

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

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

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

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

난점은 ②와 ③이다

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

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

정하지 않은 것

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

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

§11

현재 실행물은 두 경로다: aippt PoC와 iui 제품 검색

aippt의 src/lib/visual-summary는 생성 → 검증 → 카테고리 확정 → 질의 변환의 PoC 구현을 유지한다. 그 뒤 component-tag와 iis-node 검색을 골라 비교하며 서로 자동 fallback하지 않는다. iui comp-frame은 별도 Frame 검색 구현으로, 현재 Rust 서버를 사용한다. 한 경로의 제한·실측을 다른 경로의 현재 상태로 옮기지 않는다.

책임현재 코드
규약 실행 PoCaippt pipeline.ts·fallback.ts·projection.ts·query.ts
노드 검색·대치 PoCaippt iis/nodeSearch.ts·nodeBinding.ts·propertyMatch.ts
현재 Frame 검색iui rust/comp-pass: query_frame·pool/search·align·rank·cost
현재 화면iui src/comp-frame: 문서 요청, 결과 카드, 미리보기
제품 대치iui packages/comp-frame-client + comp-frame-shared/nodeTextPolicy
사전 색인iui packages/comp-frame-index

10월 변경의 핵심은 첫 존재 tier 전량 검사, 원문/임시 문구 정책 통일, 네 종 threading, 표 확장과 IIS 셀 지도다. 9월 이전 TS 파일을 현재 경로로 인용하지 않는다. 더 자세한 호출 지도는 comp-frame 문서에서 읽는다.

aippt README · aippt 함수 목록 · iui 원격 문서 요청 · 현재 후보 수집

§12

I.I.S.는 경계와 구조 대응을 공급한다

Boundary는 어느 RLSC 하위 트리가 어떤 의미 카테고리인지 판정한다. Property 국면은 표현 properties와 필드→노드의 structure 대응을 구한다. 질의의 structure는 내용이고 IIS의 structure는 내용을 넣을 위치라는 차이가 핵심이다.

aippt의 노드 대치는 선택한 하위 트리에 기존 대치 함수를 적용하는 PoC다. iui의 적재는 IIS 대응을 buildIisFrame으로 슬롯·용량에 연결하고 불충분하면 buildRuleFrame을 시도한다. 표현 properties 누락과 구조 대응 누락을 같은 “property 없음”으로 뭉뚱그리지 않는다.

현재 iui 대치에서는 경계 밖 글도 공통 정책을 따른다. binding이 먼저 사용자 내용을 넣고, 나머지 blank·preserve·안쪽 잔여·바깥 글은 Marker/비내용 역할/구조 토큰만 원문으로 남긴다. 일반 글과 숫자는 임시 문구 대상이다. “IIS 경계 밖은 항상 원본 보존”을 모든 엔진의 공통 규칙으로 쓰지 않는다.

aippt 하위 트리 대치 · iui IIS Frame · iui 공통 대치 정책

§13

RLSC·Frame·textTree: 서로 다른 역할을 유지한다

형식역할
Visual Summary structure사용자 내용과 요청 표현. 생성·검증·projection의 입력
RLSC기존 디자인의 구조·역할 트리. IIS 경계와 노드 참조의 바탕
Frame내용 수요와 디자인 수용 슬롯을 같은 계약으로 맞추는 검색 표현
textTree / comp-sign signature별도 comp-sign의 Markdown 입력·구조 검색·대치 표현
sheetJson최종 대치 데이터를 적용해 렌더하는 디자인 문서

사용자 입력을 RLSC 자산으로 변환하는 흐름이 아니다. 이미 있는 자산에서 추출한 슬롯과 사용자 내용을 맞춘다. comp-sign과 comp-frame은 비슷한 용어를 쓰지만 별도 구현이므로 결과나 버전을 합치지 않는다.

글 있는 도형의 지원 범위도 두 구현이 다르다. aippt는 문자열 content를 가진 SVG를 text-bearing으로 읽는다. iui 벤더 extractTextSlots는 Text만 읽는다. 원본 소스 변경, vendoring, Frame 재적재, 검색 스냅샷 반영은 각각 확인할 단계다.

aippt SVG 판정 · iui Text 슬롯 · Frame v5

설계·측정 이력 · 2026-08-04 — 당시 자료의 도해와 판단을 보존한다. 이 절의 “현행·지금·미완”은 해당 시점의 표현이며 현재 구현 상태는 §0·§11~13을 따른다.

§14

소유와 순서

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

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

덱이 각자에게 물으려던 것

강창석님

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

이석님

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

류민님

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

허재영님

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

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

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

설계·측정 이력 · 2026-08~09 — 당시 자료의 도해와 판단을 보존한다. 이 절의 “현행·지금·미완”은 해당 시점의 표현이며 현재 구현 상태는 §0·§11~13을 따른다.

§15

그 뒤 3주에 바뀐 것

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

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

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

단계 무엇이 바뀌는가 목표 시점 지금 상태
1단계 (현행)Markdown Summary, 임베딩 검색지금운영 중, 변동 없음
2단계컴포넌트에 Semantic Component Category2026-08-18 사실상 스킵2026-08-07 확정. 4단계로 직행
3단계YAML + structure 검색없음실행하지 않음 (2026-08-06 Cancelled)
4단계RLSC node 태그로 정확한 범위 특정단독 단계로는 건너뛴다 (2026-09-08 확정)실행 티켓 여섯이 Cancelled. 끝난 산출물(fallback map, 꾸밈 축 등)은 5단계가 그대로 쓴다
5단계node 에 semantic category 속성까지여기로 직행한다 (2026-09-08 확정, 정원석)경계 4,764건·속성 3,955건 로컬 파일럿(09-06), 노드 검색 엔진 배선(09-07). 정확도 판정(K-9-1)과 10만 건 추출(MOR-2415)이 남았다

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

원본 커밋 61bfcfa6b268

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

절별 남은 일

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

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

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

원본 커밋 61bfcfa6b268

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

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

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

규약 통과는 잡음을 넘었다

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

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

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

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

§16

현재 확인한 차이와 평가를 읽는 법

차이이번 판의 처리
규약 v0.5.6 vs 오래된 README스키마·capability JSON을 종수와 쓰기 의무의 기준으로 사용
alternatives규약은 대안을 열지만 iui Rust tier는 읽지 않는다
P8폐기 결정과 현재 실행을 우선. 옛 제목·예시의 잔존 표기와 구분
중첩 미구현 기록현재 Rust N1~N5 구현을 확인. 운영 공급은 미측정
원문 유지공통 정책으로 변경. preserve·경계 밖이라는 이름만으로 판단하지 않는다
도형 텍스트aippt SVG 지원과 iui Text 한정 차이를 명시

새로 추가된 위키 평가: 2026-09-27. 입력 100건에서 운영 markdown BAD 32.0%, Visual Summary 30.9%를 보고했다. 같은 입력 비교 신뢰구간이 0을 포함해 개선을 확정할 수 없다. 묶음 결과는 여러 컴포넌트를 한 번에 판정했고 재배치는 껐다. 이 숫자는 당시 실행이며 현재 10월 구현의 측정값이 아니다. 이전 8월의 결함 귀속 36/466/17이나 공급 분포와 분모를 섞지 않는다.

측정 설계·결과·한계

§17

원문 지도와 검토 범위

2026-10-17에 fetch한 origin/main을 git archive로 고정해 읽었다. wiki a0f8b01961db9396206b1ddf097c66cb44bde137, aippt e6ffa4bdf65ec76f3d3031dc566f3fc7c19eade1, iui bcd1d0218766cbba3a174d1819ab218d613e626f다. aippt 구현 README·_SIGNATURE와 wiki spec/design 양쪽을 확인했다. 비공개 docs 서브모듈이 없는 스냅샷에서는 동일 정본의 최신 mordor-wiki를 직접 읽었다.

먼저 읽을 원천역할
스키마필드·버전·생성·fallback 규약
capability성립·reads·fallback·생성 허용
대치 contract설계 의도. 과거 구현 현황은 코드와 대조
aippt 구현PoC 구현과 계측 범위
iui 현재 실행 기록Rust 이전·노드 정책·표·threading 변경
강의 14절현재 경로와 함수의 고정 줄 링크

운영 DB 전체, 배포 환경의 활성 버전, 실제 사용자 품질은 이번 갱신에서 측정하지 않았다. 아래에 남은 8월 덱·역할·분포·로드맵 원문 표는 날짜가 있는 이력이다. 새 코드가 존재한다는 사실과 운영 완료를 구분한다.