이 탐색기는 무엇인가

Visual Summary 검색이 「구조·길이」 기준에서 「유형 우선」 기준으로 바뀌면서, LLM이 고른 유형에 맞는 컴포넌트가 충분한가를 사례 단위로 확인하는 도구다(MOR-2418).

• 수요 — 8월 유저 입력 22,663건을 생성기가 Visual Summary로 바꾼 컴포넌트 29,360개
• 공급 — dv2.4 IIS 컴포넌트 100,025 DO에서 만든 검색용 Frame 112,227행. 텍스트 슬롯마다 담을 수 있는 글자 수(용량)가 들어 있다
• 검색 — 운영 검색 코드(comp-frame searchFrames)를 그대로 쓰되, 개수 한도를 풀어 공급이 낼 수 있는 후보를 전부 셌다

숫자는 모두 전수 집계다. 다만 컴포넌트마다 저장한 후보 카드는 등급별 상위 20개까지다.

사내판과 로컬 완전판

지금 보고 있는 것은 사내판이다.

지금 보고 있는 것은 로컬 완전판이다. 원문이 들어 있으므로 폴더를 공유하거나 사내 사이트에 올리지 않는다.

매칭 등급 L0–L3

후보 하나가 질의에 얼마나 정확히 맞는지를 두 축으로 나눈다. 유형을 지켰는가(tier)와 모양이 얼마나 같은가(stage)다.

배타 등급과 누적 등급

• 후보 카드의 탭(L0·L1·L2·L3)은 배타다. 후보 하나는 한 탭에만 들어가서 목록이 겹치지 않는다
• 최선 등급 — 그 컴포넌트가 받은 가장 정확한 등급. L0 후보가 하나라도 있으면 L0다
• 누적 L0–L3(첫 화면과 유형 화면의 타일) — 「L1 이상」처럼 그 등급까지 내려가면 덮이는 비율이다. 누적 L1 = 유형을 지킨 비율, 누적 L2 = 대체 유형까지 허용한 비율(티켓의 정본 기준)이다. 리포트 본문의 L0·L1·L2와 같은 정의다

검색이 매칭하는 방식

유형만 같다고 바로 매칭되지는 않는다. 컴포넌트의 구조(엔티티)와 글자 길이도 함께 본다.

1. 성립 확인(establish) — Visual Summary가 요청 유형의 조건을 채우는지 본다. 못 채우면 tier 1을 조회하지 않는다
2. 질의 만들기(buildQueryFrames) — 컴포넌트를 검색용 모양으로 바꾼다. 여기서 실패하면 검색 자체를 하지 않는다
3. 거르기 — 카테고리 · 모양 비트 · 엔티티 수 하한 · 데이터셋 종류 · 글자 수 하한이 맞는 공급만 남긴다
4. 용량 배제 — 질의 글자 수가 공급 슬롯에 들어가지 않는 후보를 뺀다
5. 중복 제거 · 정렬 — 같은 Frame 지문은 하나만 남기고, tier → 비용 순으로 줄 세운다

유형 (type)

생성기 어휘 45종 가운데 하나. Enumeration.List 처럼 적는다. 공급 쪽 카테고리는 같은 이름을 Enumeration_List 로 적는다

tier 1 · 2 · 3

조회하는 카테고리 묶음. 1 = 요청 유형, 2 = 그 유형에 정해진 대체 유형들, 3 = 모든 유형에 공통인 마지막 안전망 3종(Enumeration_List · LongFormTextLayout · HighlightedMessage, 요청 유형 자신과 앞 tier 에 이미 든 것은 뺀다). 유형 화면의 「검색 계층」에 실제로 조회한 카테고리가 나온다

stage 0 · 1 · 2

질의와 후보의 모양 비트가 몇 개 다른가. 모양 비트는 필드(label · items · value · unit · 제목 · 설명 등)가 있는지를 비트로 적은 것이다. 3개 이상 다르면 후보가 아니다

Frame

검색이 보는 컴포넌트의 모양. 유닛(엔티티)마다 어떤 필드에 어떤 텍스트 노드가 묶였는지, 위성 텍스트(제목·설명), 데이터셋, relations를 담는다

엔티티

Visual Summary 안의 항목 하나(e1, e2 …). label · items · value 같은 필드와 하위 항목(children)을 가진다

dataset

표·차트 데이터. matrix(열 × 행) 같은 모양과 열마다의 역할(category · value · x · y)을 가진다

relations

엔티티 사이의 관계(예: compares 는 둘을 비교). Versus · VennDiagram 이 읽는다

비용 (cost)

같은 tier 안에서 후보를 줄 세우는 값. 낮을수록 질의에 가깝다. 0 이면 모양·길이 차이가 없다

질의 상태와 원인

정상

질의가 제대로 만들어져 검색까지 갔다

질의 결함

질의 만들기가 실패해 검색을 하지 않았다. 대부분 relations의 of 에 엔티티 label 대신 id(e1)를 적은 생성 결함이다(Versus · VennDiagram). 공급이 있어도 결과가 0이 된다

tier 1 없음

성립 확인에서 요청 유형이 서지 않아 같은 유형을 조회하지 않았다. 대부분 표·차트의 value · x 열에 수가 아닌 값이 들어간 경우다(규칙 B-37). 이때 받은 후보는 L2·L3뿐이다. 사유 문장은 컴포넌트 화면에 나온다

공급 부족

질의는 정상인데 L0를 받지 못했다. 같은 유형·같은 모양·담을 수 있는 길이의 공급이 없다는 뜻이다

「L0 를 못 받은 이유」 막대는 이 세 가지로 나눈 것이다. 질의 결함과 tier 1 없음은 공급이 아니라 질의 쪽 문제라서, 공급을 늘려도 해결되지 않는다.

숫자 지표

컴포넌트 · 입력

입력 하나가 여러 컴포넌트로 바뀔 수 있다(평균 1.30개). 유형 화면의 수는 그 유형 컴포넌트 수와, 그것들이 나온 입력 수다

공급 IIS 행

그 카테고리가 붙은 공급 Frame 행 수. 괄호의 「수치 데이터셋 보유」는 dataset이 matrix·measure 인 진짜 표·차트 행이다

후보 수

한 컴포넌트가 그 등급에서 받은 공급 컴포넌트 수(개수 한도를 푼 전량). 「중앙」·「90분위」는 유형 안 컴포넌트들의 분포, 「0개 비율」은 그 등급 후보가 하나도 없는 컴포넌트 비율이다

tier 1 풀

같은 유형으로 받은 후보 수 = L0 + L1. 유형을 지킨 공급이 얼마나 두꺼운가를 보는 핵심 지표다. 구간은 0 · 1–9 · 10–49 · 50+ 이고, 50은 운영 기본 노출 개수(top_n)에 맞춘 참고선이다

용량 배제

글자 수가 넘쳐 빠진 후보 수. 유형 화면은 컴포넌트별 값의 중앙값이다

상위 20 합

그 유형의 모든 컴포넌트에서 해당 등급 상위 20 목록을 합친 칸 수

고유 DO · 고유 템플릿

그 상위 20 목록들에 나온 서로 다른 디자인 오브젝트 · 템플릿 수. 작을수록 같은 후보가 반복해서 뽑힌다

상위 10 DO 점유

가장 자주 뽑힌 DO 10개가 상위 20 칸에서 차지하는 비율. 높으면 유저가 비슷한 결과만 보게 될 가능성이 크다

IIS 출처 · 루트 노드

상위 20 후보 중 IIS 추출에서 온 비율(나머지는 RLSC 규칙 폴백), DO 전체가 곧 컴포넌트인 비율

자주 뽑힌 DO

상위 20 목록에 가장 많이 등장한 DO 썸네일. 오른쪽 아래 숫자가 등장 횟수다

검색 계층 막대

그 카테고리를 조회한 컴포넌트 수. tier 1 막대가 100% 보다 작으면 나머지는 tier 1 없음(성립 실패)이다

후보 카드와 후보 창

순위 · 비용

그 등급 안에서의 검색 순위(tier → 비용 순)와 비용 값

DO · 노드

공급 디자인 오브젝트 id와 매칭된 노드 id. 긴 노드 id 는 앞 8자만 보이고, 마우스를 올리면 전체가 보인다

stage 칩

모양 비트 차이 개수

≠label 칩

질의와 모양이 다른 필드. 예: ≠satDesc 는 설명 위성 텍스트 유무가 다르다

IIS / RLSC 규칙

Frame 을 만든 출처. IIS = 의미 추출 결과, RLSC 규칙 = IIS 가 없을 때 구조 규칙으로 만든 폴백

루트

매칭 노드가 DO 의 최상위라 썸네일 전체가 곧 이 컴포넌트다. 루트가 아니면 매칭된 것은 썸네일의 일부다

밖 텍스트 · 묶이지 않은

컴포넌트 영역 밖에 딸린 텍스트 수 · 영역 안에 있지만 어떤 필드에도 묶이지 않은 텍스트 수

후보 창 — IIS 구조

카드를 누르면 열린다. IIS 가 그 컴포넌트를 어떤 엔티티·필드로 봤는지를, 노드 id 대신 실제 템플릿 텍스트로 풀어 보여 준다

후보 창 — Frame

검색이 실제로 비교한 모양. 유닛별 필드 텍스트, 위성 텍스트, 데이터셋(행 × 열), relations

배지와 표기

비허용

첫 출시 생성 허용 목록에서 빠진 9종(Quadrant · GanttChart · Calendar · TreeMap · PictogramChart · BubbleChart · HierarchicalTree · Gauge · RadarChart). 현재 생성기는 45종을 모두 내므로 수요에는 들어 있다

차트

진짜 차트 데이터(수치 데이터셋)가 필요한 유형 8종(N.C.E.)

⟨7자⟩ ⟨수⟩

사내판에서 가린 유저 문구의 글자 수 · 가린 숫자

◇ 텍스트 아님

필드에 묶인 노드가 텍스트가 아니다(도형 · 그림 · 표 · 그룹)

—

값이 없다

사용법

1. 전체 유형 — 어디부터 볼지 고른다

• 머리글(컴포넌트 · L0 · L0–L1 · tier 1 풀 0 · 질의 결함 · 공급 행)을 누르면 정렬된다. 한 번 더 누르면 방향이 바뀐다
• 공급이 걱정되는 유형을 찾으려면 「tier 1 풀 0」 내림차순으로 정렬하고, 같은 줄의 「질의 결함」이 그 대부분을 설명하는지 함께 본다
• 유형 이름 검색 칸으로 좁히고, 유형 이름이나 줄을 누르면 유형 화면으로 간다

2. 유형 화면 — 통계를 위에서 아래로 읽는다

1. 타일 — 컴포넌트 수, 누적 L0 · L1 · L3, tier 1 풀 중앙값
2. 매칭 등급 — 최선 등급 분포 막대, 등급별 후보 수와 다양성 표, 자주 뽑힌 DO 썸네일(누르면 원본 썸네일이 새 탭에 열린다)
3. tier 1 풀 크기 · L0 를 못 받은 이유 · 용량 배제 — 부족이 공급 탓인지 질의 탓인지 가른다. 「tier 1 이 빈 사유」를 펼치면 성립 실패 문장이 나온다
4. 어떤 Visual Summary로 변환됐나 — 엔티티 수 · 데이터셋 모양 · relations/children · 입력 길이 · 쓰인 필드
5. 검색 계층 — tier별로 실제 조회한 카테고리
6. 컴포넌트 목록 — 최선 등급 · 질의 상태 · dataset 으로 거르고, 정렬(tier 1 풀 적은 순 · 등급 나쁜 순 등)을 바꾼다. 50개씩 쪽으로 나뉜다. 줄을 누르면 컴포넌트 화면으로 간다

3. 컴포넌트 화면 — 한 사례를 끝까지 따라간다

1. 유저 입력 — 원문과 생성 제목사내판은 글자 수만 보인다
2. Visual Summary 변환 결과 — 엔티티 카드 · 데이터셋 표 · relations. 「컴포넌트 원본 JSON」을 펼치면 원본 구조가 보인다. 「입력 전체 VS YAML」은 같은 입력의 다른 컴포넌트까지 담은 생성 결과다
3. 매칭된 컴포넌트 — 질의 상태 칩, 등급별 후보 수 타일, 등급 탭. 탭을 바꾸면 그 등급의 상위 20 카드가 나온다
4. 후보 카드를 누르면 후보 창이 열린다. 썸네일 · 메타 · IIS 구조 · Frame · 밖/안 텍스트를 본다
5. 이전 · 다음 컴포넌트는 유형 화면에서 건 필터와 정렬 순서를 따른다. 예: 목록을 「tier 1 없음」으로 거른 뒤 들어오면 그런 사례만 차례로 넘겨 본다

4. 편의 기능

• 주소창의 주소(#/t/유형/번호)를 복사하면 같은 화면을 다른 사람에게 보낼 수 있다 — 단 완전판은 로컬 파일이라 받는 쪽에도 같은 폴더가 있어야 한다
• 브라우저의 뒤로 가기가 화면 이동을 따라간다
• ? 로 이 도움말을 열고, Esc 로 도움말 · 후보 창을 닫는다
• 막대 · 칩 위에 마우스를 올리면 설명이 뜬다. 같은 수치는 범례와 표에도 적혀 있다

읽을 때 주의할 점

• 후보 수는 능력 상한이다. 개수 한도를 풀고 전부 셌으므로, 운영에서 유저에게 실제로 보이는 개수(기본 50)와 다르다
• 풀 0 을 곧바로 공급 부족으로 읽지 않는다. 질의 결함 · tier 1 없음이면 공급이 있어도 0 이다
• 썸네일은 DO 전체다. 루트가 아닌 후보는 그중 일부 영역만 매칭됐다
• 다양성 지표는 상위 20 안에서 쟀다. 후보 전체의 다양성이 아니라, 앞쪽에 무엇이 반복해서 오는지를 본다
• L2 · L3 는 요청한 유형이 아니다. 누적 L2 가 높아도 「요청대로 충족됐다」는 뜻은 아니다
• 공급은 dv2.4 IIS 100,025 DO 기준이고, 텍스트 용량은 현재 코드로 다시 계산한 값이다. 운영 적재본과 시점이 다를 수 있다