Visual Summary 규약 v0.5.6

① 두 층은 같은 목록을 다르게 본다

이것을 먼저 잡아야 나머지가 읽힌다. 불허는 생성기 한 층에서만 거른다 — 검색과 I.I.S. 태깅은 45종 전량을 그대로 쓴다.

② 4색 × 3등급으로 놓으면

색은 생성 가능 여부, 행은 단어장 v2 우선순위다. 두 축은 서로를 참조하지 않으므로 교차해야 실제 범위가 나온다.

③ 충돌 P0 인데 생성 불허인 둘

RadarChart 의 P2 → P0 승격이 충돌을 하나에서 둘로 늘린 원인이다. 승격 전이었다면 Gauge 하나만 걸렸다.

④ 노란 6종 — 막히지는 않았지만 조건이 붙는다

생성기는 허용하고 엔진도 있다. 문제는 손그림 후보에 새 값을 넣으면 정보가 틀린다는 것이다. 막대 길이·각도가 값과 무관한 그림에 숫자만 갈아 끼우면 보이는 것과 뜻이 어긋난다.

⑤ 단어장 우선순위가 v1 에서 v2 로 바뀌었다

규약 폴더의 semantic-taxonomy-v7.md 는 2026-08-25 스냅샷(v1) 이라 P0=19 · P1=13 · P2=7 · P3=3 · P4=7 로 적혀 있다. 위 표의 v2 는 그 문서에 아직 반영되지 않았다 — 이 절은 공유된 그림을 기준으로 적었고, 저장소 값과 대조해 차이 셋을 확인했다.

v2 등급 체계는 P0·P1·P2 셋뿐이고 합이 49종(45 + Geo 4)이다. v1 의 P2~P4 가 v2 P2 로 합쳐진 모양이지만, 그 합침 규칙 자체는 확인하지 않았다 — 그림이 제시한 것은 최종 배치다.

⑥ 다음에 확인할 것

1. 범위 명세 문서. 「visual summary 첫출시 시점에 generator에 담을 생성범위 확정」에 Gauge·RadarChart 를 P0 범위에서 빼는지를 명시해야 한다. 안 적으면 다음 사람이 P0 20종 전부로 읽는다. 허재영님 완료처리 예정.
2. 단어장 v2 를 저장소에 반영. semantic-taxonomy-v7.md 3절이 아직 v1 이다. 반영 전까지는 저장소만 읽는 사람과 이 그림을 본 사람의 숫자가 갈린다.
3. native Chart 공급. 노란 5종(P0)의 실질을 정하는 값이다. 공급 일정이 첫 출시에 닿는지 확인한다.
4. Gauge 의 우선순위 역전. P0 요청이 P1 카테고리로 떨어지는 유일한 자리다. 허용할지, 다른 도착지를 줄지 정한다.
5. 「기본」의 경계. 「기본 + 표/차트」에서 기본이 색 없음 13종을 뜻하는지, 별도 목록인지 확인이 필요하다.

출처 범위 확정과 위 4색 × 3등급 배치는 사용자가 공유한 구현 범위 그림(2026-09-18)과 Slack 대화(miridih.slack.com · C091C6JFYH0)다. Slack 링크를 따로 조회하지 않고 공유된 본문과 그림만 사용했다. generatable 9종·generatorRedirect·불허 사유는 mordor-wiki bbabab9(2026-09-16)의 spec/schema/capability.json 과 spec/capability-table.md 10.1절에서 직접 확인했고 그림과 일치한다. v1↔v2 우선순위 차이 셋은 그림과 저장소 semantic-taxonomy-v7.md 3절을 대조해 이 문서에서 계산한 것이다.

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

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

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

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

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

2026-08-29 개정 셋 — 회피를 막고, 판번호를 붙였다

v0.5 는 확정 뒤에도 자리에서 네 번 고쳐졌고, 그동안 판번호가 그대로였다. 그래서 「지금 규약이 무엇인가」를 버전으로 가리킬 수 없었다. 2026-08-29 에 세 건을 한꺼번에 고치면서 판번호 규칙을 함께 신설했다.

판번호 규칙 — 원리가 아니라 실측으로 가른다

type 필수화는 원리적으로는 required 를 좁히는 변경이지만, 무효가 되는 산출물이 실제로 0건이라 PATCH 다. 실측 없이 좁히는 변경은 MINOR 이상으로 본다. 검증기는 MAJOR·MINOR 만 대조하고 PATCH 는 보지 않는다 — PATCH 가 유효성을 안 바꾼다고 정의해 놓고 patch 차이로 옛 산출물을 떨어뜨리면 자기모순이기 때문이다. 그래서 파일 이름(schema-v0.5.md)은 그대로다.

0.5.6 — 생성기가 고를 수 있는 것은 36종이다

규약 enum 은 45종 그대로다. 줄인 것은 생성기 어휘뿐이고, 그 부분집합을 capability.json 의 generatable 이 정한다(첫 출시 기준 36종). I.I.S. 추출·검색 인식 어휘는 45종 전량이다.

0.5.6 — 생성 시점 쓰기 의무 B-33

version 은 LLM 이 쓰지 않는다. 프롬프트가 「쓰지 말라」고 지시하고 후처리(generator/postprocess.ts)가 상수를 붙인다. 2026-08-20 100회 실행에서 모델도 100/100 정확히 적었으므로 품질 개선이 아니라 책임 분리다 — 모델이 판단할 것이 아닌 값은 모델에게 맡기지 않는다.

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

projection — 내용은 버리지 않고 옮긴다

fallback 은 카테고리를 바꾸는 일이라 출발 카테고리가 쓰던 필드를 도착이 못 읽는 경우가 생긴다. 이때 어디로 옮기는지를 정하는 것이 규칙 여덟이다. 버리는 규칙은 P2 하나뿐이고 나머지 일곱은 전부 옮기는 규칙이다.

복잡도 레벨 셋 — 산출물의 모양이 아니라 생성기에 허용된 범위

레벨은 산출물 한 건을 분류하는 이름이 아니다. 누적이고(L1 ⊂ L2 ⊂ L3), 그래서 L3 를 켠 생성기가 컴포넌트 하나짜리를 내는 것은 정상이다. 「질의」라고 부르지 않는다 — 검색용 질의로 바뀌는 것은 질의 변환기를 거친 뒤다.

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

복합 구조 fallback — 노드가 여럿일 때 어느 것부터 포기하나

앞 절의 사다리는 노드 하나의 카테고리를 내리는 규칙이다. 질의가 중첩이나 병치로 노드를 여럿 가지면 그것과 별개로 포기 순서가 필요하다. 2026-08-28 확정, SSoT 는 capability-table.md 3.6절이다. 위에서부터 시도하고 후보가 나오면 멈춘다.

alternatives 와 fallback 순서는 보는 것이 다르다

Gauge → BigNumber → List 는 게이지에 무엇이 담기든 같다. 반면 생성기는 입력을 이미 읽었으므로, 같은 Hierarchy.Pyramid 라도 층마다 크기 차이가 의미를 지니면 Staircase 가 낫다는 것을 안다. 다만 이것은 가정이고 실측이 없다 — 생성기가 고른 alternatives 가 정적 순서보다 나은지 검증된 적이 없어 optional 로 열어 두고 생성기 정책으로 켜고 끈다.

SSoT — projection 은 규약 5절, 복잡도 레벨은 규약 8.8절, 복합 구조 순서는 spec/capability-table.md 3.6절. 코드는 projection.ts(P1~P8 계산·적용) · fallback.ts(카테고리 확정)이고, N1~N5 는 규약만 확정되고 코드는 미착수(I-11)다.

왜 등급 하나로는 안 되나

그래서 축 집합으로 둔다

decoration:                # 꾸밈구조 하나
  ornament: prefer          # 꾸밈 축 하나 + 선호값 하나 → Element.Decoration
  background: avoid         # 꾸밈 축 하나 + 선호값 하나 → Element.Background

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

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

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

전체 흐름 여덟 단계

사용자 입력
  → ① LLM YAML 생성    generator/       LLM 이 YAML 을 쓴다 · 재생성 루프
  → ② 검증            validate.ts      파싱 → id 부여 → zod → capability
  → ③ 카테고리 확정     fallback.ts      성립 조건 + 자기 행 fallback + projection
  → ④ 검색 질의 변환    query.ts         structure → 태그·제약 (④ 는 ⑤ 의 입력)
  → ⑤ 실색인 검색      search.ts        태그 군 우선 · 군 안에서 구조 적합도
  → ⑥ 내용 대치        binding.ts       RLSC 슬롯에 직접 삽입 (규약 경로)
  ┈┈┈┈┈┈┈ 여기까지가 질의 갈래. 아래는 실서비스 경로와의 대조 ┈┈┈┈┈┈┈
  → ⑦ comp-sign 비교   markdown.ts → compSignService.ts → intersect.ts
                             structure → markdown → textTree → 구조 검색·대치
  → ⑧ 렌더·채점        sheet.ts · audit.ts   같은 기준으로 두 경로를 비교

여섯 구간의 관계 — 무엇이 무엇의 입력인가

각 구간은 앞 구간의 산출물만 입력으로 받는다. 그래서 어느 구간이 나빴는지를 뒤의 귀속 채점이 가를 수 있다. 모듈 이름은 전부 src/lib/visual-summary/ 기준이다.

「PoC」가 어디까지 임시인가

색인 규모는 로컬 태깅 컴포넌트 2,468건(시그니처 3,424벌 · 고유 구조 해시 668개 · 빌드 33초 · 30분 캐시). 실서비스는 178,095건이라 이 방식을 그대로 쓸 수 없고, 그것이 아직 스쿼드가 정해야 할 열린 결정이다. 범위 밖 — 차트·이미지 데이터 대치, 색상 대치, 실제 테이블 적재, 백엔드 검색 실행.

왜 검색 경로를 두 갈래로 나란히 두었나

두 축이 깨끗하게 갈린 것이 뜻밖의 자산이 됐다. 스쿼드가 합의한 판정 지표가 「두 검색의 교집합 상위 10건 품질」인데, 이 PoC 에 그 두 검색이 각각 실서비스 코드로 있어서 교집합을 실제로 계산할 수 있다.

결함 16종과 심각도

이전 라운드에서는 대치 결과 23장을 손으로 봤다. 결함을 실제로 찾아냈지만 코드를 고칠 때마다 23장을 다시 볼 수 없어 「이 변경이 좋아졌나」를 말할 수 없었다. 그래서 같은 판정 기준을 기계로 옮겼다. 16종 각각이 §2 의 원인 넷 중 하나에 대응한다.

심각도는 셋이다 — blocker ×5(사용자 내용이 사라졌거나 남의 내용이 남음), major ×2(위계 어긋남), minor ×1(빈 자리·임시 문구). 결함 수를 그냥 더하면 가벼운 결함이 많은 결과가 더 나빠 보이므로 가중치를 곱해 더한다.

결함을 생성 · 검색 · 대치 중 누구 탓으로 돌리나

귀속은 단일 결과가 아니라 대안과의 비교에서만 나온다. 두 경로 다 상위 후보 전부에 대치를 돌려 보고 그중 하나만 쓰는데, 채점기가 그 버려지던 것을 주워 담아 셋으로 나눈다.

정직성 장치가 하나 붙는다 — 랭킹이 애초에 볼 수 없었던 결함(시그니처 밖 자리의 넘침 등)은 검색 탓에서 덜어낸다. 랭킹에게 없는 정보로 벌점을 매기면 이 수치로 가중치를 튜닝할 때 잘못된 방향으로 간다.

기준선 수치 2026-08-15 · 입력 50건 · 컴포넌트 65개 · 상위 10건

다만 두 검색은 1위 후보가 65개 중 2개(3%)만 겹쳐서, 「교집합 상위 10건」을 그대로 지표로 쓰면 표본이 거의 남지 않는다.

군(tier) 이 둘 있고 나누는 축이 다르다

양쪽 다 군이 점수보다 절대 우선이다. 1군 후보가 아무리 점수가 높아도 0군을 앞설 수 없고, 2군은 fallback 행의 순서 그대로라 Timeline 이 List 보다 항상 먼저다. 이 규칙은 원래 없었고 실사용 로그 10건 실행에서 「같은 군 안에서 순서가 점수에 밀리는」 문제를 발견해 고정한 것이다.

대치 계층 다섯 — fallback 이 끝난 뒤

실사용 E2E 실측 2026-08-12 · 로그 원문 10건 · gpt-5.4-mini

절반 이상이 2군이라는 것은 생성기가 고른 카테고리를 색인이 그대로 대 주지 못한다는 뜻이다. 이 실행에서 시스템 구멍 두 가지를 찾아 코드에 반영했다 — 같은 군 안에서 순서가 점수에 밀리는 문제(2군 정렬을 태그 순위 우선으로 고정), 마지막 fallback 카테고리마저 색인에 없으면 후보가 0이 되는 문제(4군 안전망 추가).

평가 pool 을 고정하는 규칙 다섯

전 컴포넌트(실서비스 17만여 건)에 시그니처와 속성을 한꺼번에 구울 수는 없다. 세 대치 경로를 공정하게 비교하려면 같은 후보 풀 위에 미리 구워 둬야 한다.

비용 어림의 근거는 실측이다 — 시그니처 빌드가 2만 건에 약 4.4분, 5만 건에 약 9.9분이고 properties 추출이 137건에 4분(입력 23만 토큰)이었다. 5,000건이면 추출 약 2.4시간 · 입력 약 840만 토큰으로 어림된다.

코드가 어디 있는가

comp-sign v4.3.8 의 네 함수 — buildCompSignatures(구조 해시·text_map·채점 feature, DB 적재용) · buildCompSearchData(markdown → textTree 와 조회용 해시) · rankCompCandidates(채점·중복 제거·정렬) · buildContentReplacement(대치 텍스트 생성·box 보정·형제 그룹). DB 접근과 후보 fetch 는 호출자(BE) 몫이고 이 패키지는 순수 계산만 한다. 입력이 markdown 이라는 점이 중요하다 — Visual Summary YAML 이 이 경로에 직접 들어갈 자리가 아직 없다.

I.I.S. 는 색인 쪽 모듈이다. 질의를 만들지 않고, 이미 있는 컴포넌트 안을 더 잘게 나눈다. 그 결과가 대치에 닿는 경로가 이 절이다.

왜 필요한가 — 컴포넌트 단위 태그로는 자리를 못 짚는다

네 단계 — 경계 → 검색 → 대치, 그리고 속성

T-7 은 한 번의 호출로 둘을 낸다

한 컴포넌트에 한 번만 부른다. 노드마다 따로 부르지 않는 이유가 코드에 적혀 있다 — 한 컴포넌트 안의 경계 여럿이 같은 그림 하나를 공유하고, 회전 방향·오름차순 같은 속성은 서로 무관하지 않다 (Cycle 의 rotation 과 그 안 Steps 의 sequence 가 같은 그림에서 나온다).

속성은 「읽어낼 수 없으면 뺀다」가 계약이다. 허용 밖 키·모양 밖 값·없는 노드 참조는 버리고 보고할 뿐 재시도를 걸지 않는다 — 값 하나가 어긋났다고 컴포넌트 전체를 다시 물으면 맞게 읽은 나머지까지 버리게 된다. 재시도는 응답을 아예 못 읽을 때만 건다.

RLSC 가 실제로 하는 일 셋

슬롯 대응 — binding.ts 가 실제로 넣는 자리

entity.label   → 단위의 Title 슬롯
entity.value   → 단위의 Subtitle 슬롯
                 (없으면 Description 앞줄, 그것도 없으면 label 병기)
entity.items[] → 단위의 Description 슬롯들에 분배
                 (모자라면 마지막 슬롯에 이어 붙임)
순번             → 단위의 Marker 슬롯 (01, 02, …)
페이지 제목       → 머리 영역(반복 단위 밖)의 Title/Subtitle/Description

색인 쪽 노드 분류 — CORE / DESC / DECO

추출 쪽은 이미 노드 단위로 핵심·위성·장식을 식별하고 있다. §6 이 지적한 「질의 쪽에 위성 자리가 없다」는 구멍의 반대편이 이것이다.

「트리」가 층마다 다르다 — 넷을 갈라 읽는다

다리는 structure → markdown → buildCompSearchData → textTree 다. comp-sign 경로는 Visual Summary YAML 을 직접 받지 않는다 — markdown 과 textTree 를 받는다. 이름을 섞어 쓰면 fallback 이후 대치 계층을 따라갈 수 없다.

덱이 각자에게 물으려던 것

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

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

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

절별 남은 일

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

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

통합본이 부록을 쓰면서 문서 사이에 어긋난 자리를 다섯 확인했다. 파생물이 규약 본문보다 뒤처진 것이 셋이었고, 넷은 그 자리에서 닫혔다. 남은 것은 5번 하나와 3번의 꼬리다.