Visual Summary · 기본 품질
기본 품질을 이렇게 정의하고,
이렇게 재고, 이렇게 올린다
정의
원문에 맞는 컴포넌트를
결함 없이 채운다
유형 · 구조 · 자리 길이 · 대치, 네 조건
측정
정답을 아는 시험으로
어디서 틀리는지 짚는다
원본 컴포넌트에서 거꾸로 만든 원문 · 단계마다 잰다
개선
가장 크게 잃는 곳부터
실제 원문으로 확인하며
첫 대상 — 검색 후보를 거르는 용량 산정
2026-10-13 내부 공유 · 류민 · 상세 문서 Confluence x/zQcnsQ
왜 지금
응용은 모두 검색 · 대치 위에 선다
visual summary 검색 · 대치는 내용시각화 개선 로드맵의 출발점이다. 기초의 품질이 그 위 모든 응용의 품질을 묶는다.
좁은 범위에서 기본 품질을 먼저 올린다. 그러려면 셋이 필요하다 — 무엇이 기본인지, 무엇이 잘된 결과인지, 어떻게 재는지.
경계
나누는 것은 기본, 합치는 것은 응용
원문을 몇 조각으로 나누든, 장 하나에 컴포넌트 하나를 채우면 기본이다. 지금 서비스되는 세 형태가 모두 여기에 든다.
기본이 다루는 층은 텍스트다. 요소 · 스타일 · 배치는 원본대로 두고, 채운 결과가 원본의 가독성 · 완결성을 깨지 않아야 한다. 기본 안에서는 장 품질(세 형태 공통)을 먼저, 분할 품질(L2 · threading)을 그다음에 잰다.
정의
잘된 결과는 네 조건을 모두 만족한다
① 유형이 맞다
② 구조가 맞다
③ 자리 길이가 맞다
④ 대치 결함이 없다
스타일 · 요소 · 배치는 기본의 범위 밖이다. 네 조건이 같으면 생김새가 달라도 똑같이 좋은 결과다.
측정의 출발점
실제 원문에는 정답이 없다 — 그래서 정답을 아는 문제를 만든다
우리 컴포넌트는 디자이너가 실제 내용을 담아 만든 템플릿에서 왔다. 그 글로 원문을 거꾸로 만들면, 그 원문을 네 조건대로 담는 컴포넌트가 적어도 하나 있다는 것이 보장된다.
정답이 확실하고 원문이 자명한 가장 쉬운 문제다. 여기서 틀리는 곳은 실제 원문에서도 틀릴 곳이다.
판정 기준
원본이 1위일 필요는 없다 — 원본보다 못한 것이 위에 오면 안 된다
통과 위의 후보가 모두 원본과 동등
- 1위컴포넌트 B — 같은 유형 · 같은 구조 · 길이 맞음✓
- 2위컴포넌트 C — 같은 유형 · 같은 구조 · 길이 맞음✓
- 3위원본 A
- 4위컴포넌트 D — 판정에 쓰지 않음
실패 원본보다 못한 후보가 위에
- 1위컴포넌트 E — 유형이 다르다✗
- 2위원본 A
- 3위…
- 원본이 아예 후보에 없어도 실패
| 지표 | 종류 | 뜻 |
|---|---|---|
| 원본 재현율 | 핵심 | 원본만큼 맞는 결과를 내고 대치 결함이 없는 원문의 비율 |
| 원본 1위율 | 진단 | 원본 A 자체가 1위인 비율 |
| 글 보존율 | 진단 | 결과 화면에 원본 글이 남는 비율 |
실제 화면 · iui(정답 YAML) · qa 미리캔버스(원문)
정답 YAML 이면 원본이 재현된다 — 틀어지는 곳은 원문 → YAML 생성





두 사례 모두 IIS · comp_frame · 검색 · 대치는 정답과 일치하고 생성 링크만 실패한 사례다. 생성이 틀리면 원본이 후보에서 사라지기도 하고(위), 원본을 찾아도 글이 바뀐다(아래). PoC 측정에서 이런 사례 18건 모두 원문으로는 재현되지 않았고 정답 YAML 로는 재현됐다(원문 0/18 · YAML 18/18).
두 개의 자
정답 있는 시험으로 찾고 고치고, 실제 원문으로 채택한다
| 정답을 아는 시험 · 원본 재현 | 실제 원문 판정 · judge | |
|---|---|---|
| 답하는 질문 | 어디서 왜 틀리나 | 유저에게 나아졌나 |
| 입력 | 원본에서 거꾸로 만든 원문 | 실제 사용자 원문 |
| 강점 | 단계마다 원인을 짚는다 · 결정적 · LLM 비용 0 | 실제 입력 분포 그대로 |
| 쓰임 | 고칠 곳과 순서를 정한다 | 고친 것을 채택할지 정한다 |
실제 원문 판정만으로는 원인을 짚기 어렵다 — 검색 순위 1위와 10위의 BAD 비율이 21.2% 대 20.7% 로 거의 갈리지 않는다(10/06 전량 판정). 두 자는 서로를 대신하지 않는다.
무엇을 재나
단계(링크)마다 재고, 전체 사슬도 잰다
| 링크 | 통과 조건 — 원본만큼 맞는가를 그 단계에서 본 것 |
|---|---|
| a 생성 | 생성 YAML 이 정답과 유형 · 구조가 같고 원본에 담긴다 |
| b · c IIS | 운영 판독이 구조 정답과 같다 |
| d comp_frame 빌드 | 원본이 자기 글을 담는다고 판정된다 |
| e 검색 | 원본 위의 후보가 모두 원본과 동등하다 |
| f 대치 | 원본의 글이 원본의 자리에 결함 없이 들어간다 |
개선 여지 계단 — 운영 단계를 정답으로 하나씩 바꿔 끼우며 원본 재현율을 다시 잰다. 오른 만큼이 그 단계가 잃는 몫이고, 고칠 순서가 된다.
PoC · 골든 데이터셋
운영 검색 풀에서 18종을 같은 수로 뽑아 정답을 만들었다
모집단 · 운영 풀 판 2.6
63,929
18종 · 종마다 같은 수로 층화
세트
252 · 126 · 366
test · val · train
구조 정답 판정자 일치(test)
93.7 · 94.4%
경계 · 카테고리
- 구조 정답 — 상위 모델 둘이 따로 판정하고, 갈린 것만 셋째가 가른다. 사람 검수(경계 60 · 속성 30)로 신뢰도를 잰다.
- YAML 정답 — 규칙 알고리즘으로 변환하고 규약 검증기로 확인한다(test 237 · val 118).
- 원문 — YAML 의 글을 모두, 글자 그대로 담은 자명한 원문.
- train 으로 고치고, val 로 고르고, test 로 확인한다. test 는 통계만 쓴다.
PoC 결과 · 개선 여지 계단
대치는 된다 — 원본이 검색에서 올라오지 않는다
원문에서 출발
정답으로
정답으로
대치만 남음
원본 재현율 · test 237(val 118 도 같은 그림: 0.8 → 11.0 → 16.9 → 92.4). 원본이 아예 검색 후보에 오르지 못한 원문이 237건 중 175건이다. PoC 측정 · 운영 검색 · 대치 로직 기준으로 측정 장치를 재점검한다
PoC 결과 · 단계별
가장 약한 곳은 comp_frame 빌드 — 원본이 자기 글을 못 담는다고 적힌다
test 기준. d 에서 떨어진 원본은 순위와 상관없이 검색 후보에서 빠진다 — d 를 통과하지 못한 원문에서 원본이 후보에 든 경우는 없다. 생성은 유형은 넷 중 셋이 맞지만(77.6%) 구조 · 길이까지 맞는 것은 셋 중 하나다.
PoC 결과 · 원인
용량 산정이 실물보다 작다 — 원본에 들어 있는 글도 「넘친다」
글자 폭을 글꼴의 0.86배로 고정해 잰다 — 실물 대비 잡히는 용량. 원본에서 한 줄인 글을 0줄로 잡는 칸도 있다.
| 원인 | 원문 |
|---|---|
| 용량 산정 | 117 |
| 차트 자리 규칙 불일치 | 21 |
| label 용량 산정 | 8 |
| label 없는 항목 규약 차이 | 2 |
| 비교 문장 자리 없음 | 1 |
| 합계 | 149 |
원본 글 ÷ 계산 용량
1.33배
중앙값
용량만 실물에 맞추면
37→86%
원본 자기 적합률 최대
개선 · 원칙
측정은 실물대로, 여유는 정책으로 따로
원칙 1
계단이 순서를 정한다
잃는 몫이 큰 단계부터 고친다.
원칙 2
측정과 정책을 나눈다
재는 값이 틀리면 고치고, 여유는 판정으로 정한다.
원칙 3
규약과 구현이 어긋나면 먼저 정한다
어느 쪽이 맞는지 담당자와 결정한 뒤 고친다.
원칙 4
두 관문을 거쳐 채택한다
원본 재현율이 오르고, 실제 원문 BAD 비율이 나빠지지 않는다.
개선 · 실행 계획
검색 앞단부터 고친다
다음 · 넓혀 가는 순서
원본 재현에서 실제 원문까지, 단계마다 확인하며 넓힌다
정의
네 조건 · 원본만큼 맞는가
기본 = 분할은 하되 합성은 하지 않는 서비스 전체
지금
대치는 되고, 원본이 후보에서 빠진다
원인의 대부분은 용량 산정
계획
용량 → 규약 정합 → 생성 → 순위
실제 원문 판정으로 채택한다