Visual Summary 결함 지도

cost.ts:456-463 이 unitMismatch 에 새 가중치를 안 넣은 근거로 "기존 provenance 가중치가 이미 벌한다"고 적어 뒀다. 그런데 그 가중치가 cost.ts:81 에서 0이다.

fontHierarchy: 0 에는 "2026-09-14: 1 → 0" 이라는 날짜와 근거가 붙어 있는데 provenance: 0 에는 아무것도 없다. git log -S 로 따라가니 최초 커밋 e82e02846 부터 0이다 — 처음부터 안 켠 것이다.

늘어나는 구간이 색인(20.1%) → 창(38.2%) 이라 랭킹 탓이 아니라 하드 필터가 이런 행을 잘 통과시키는 것이다. 규칙 기반 추출은 프레임이 단순해 정렬이 잘 맞고 빈 슬롯이 적다.

대치하고도 저자 글이 아닌 자리가 셋 남는다 — 빈 슬롯, 경계 안 잔여(둘 다 임시 문구로 채움), 경계 밖 잔여(컴포넌트 원문이 그대로). 셋의 합이 unauthored_count 다.

기본 가중치만으로는 천장이다. cost.ts:47-67 이 "더 올려도 성적이 한 칸도 안 움직인다"고 실측으로 못 박았다. tier_pool 에서 tier 가 첫 키라, tier 1 풀에 온전한 후보가 없으면 가중치는 풀 안 순서만 바꾼다.

13.6%(53건)는 온전한 후보가 창 안에 아예 없다 — 어떤 정렬로도 못 고친다. 얕은 풀과 이어진다.

B-37 은 열의 role 과 셀 타입이 맞는지를 본다. 양방향이다 — value·x·y·size 열은 number 또는 null 을, category 열은 string 을 요구한다. 하나라도 어긋나면 그 카테고리의 성립 판정이 통째로 깨진다.

role 을 쓰는 게 121건(30.9%)이고 그중 26건(6.6%)이 위반이다. 위반하면 예외 없이 tier 1 이 사라진다 — tier 1 소실 33건 중 26건(79%)이 이 경로다.

26건을 원문으로 다 열어 봤더니 성격이 넷으로 갈린다. 고치는 방법이 서로 다르다.

A. 연도 축에 문자열 — 12건 (46%)
role: x 인 연도 열에 "2023년"·"2021" 처럼 문자열이 들었다. csv-19·21·26·52·54.
데이터는 멀쩡하고 표기만 문제다. 축 라벨로는 "2023년" 이 오히려 자연스럽다.

B. 서술 열에 role: value — 11건 (42%)
주요 지원 내용·교육부·혜택 같은 서술 열 전체에 value 를 붙였다. csv-4·5·8·20·32·65·7.
csv-8 은 4개 열 16셀이 전부 문장이다. role 을 잘못 붙인 것이지 셀이 틀린 게 아니다.

C. category 열에 빈 칸 — 2건
csv-14 세부유형(category) 에 null, csv-51 내용(category) 에 null.
처음 24건으로 셌을 때 놓친 둘이 이것이다 — 숫자 role 만 검사했는데 B-37 은 category 열도 본다.

D. YAML 이 깨진 것 — 1건
csv-49 의 행이 ["기타(미혼", "비혼", "별거 등)", 5.4] 다. 원문은 "기타(미혼, 비혼, 별거 등)" 한 칸이었을 텐데 따옴표 없이 쉼표가 들어가 3칸으로 쪼개졌다.
여기서는 B-37 이 제 일을 했다 — 진짜 깨진 데이터를 잡아냈다.

tier 1 은 요청한 type 하나만 본다(alternatives 도 안 읽는다). 그 카테고리가 성립 판정을 못 넘으면 tier 1 이 통째로 비고 tier 2 의 fallback 행으로 내려간다.

33건이 실제로 무엇을 받았는지 세어 봤다. 1위가 Enumeration_List 인 게 28건(85%), ComparisonTable 4건, Versus 1건이고 33건 전부 tier 2 이상이다. 표·차트를 요청했는데 목록 카드가 오는 게 과장이 아니라 다수다.

비용도 같이 뛴다. csv-19 는 LineAreaChart 를 요청했는데 ComparisonTable 이 cost 201 로 1위다 — tier 1 이 살아 있었으면 나오지 않았을 값이다.

사유는 둘뿐이고 겹치지 않는다.

① B-37 셀 타입 위반 — 26건 (79%)
아래 항목에 성격 넷으로 갈라 적었다.

② 개수 미달 — 7건 (21%), 전부 ScopeCoverage.NestedScope
사유가 전부 "개수 미달: 1 < 2 (entities)" 다. 원문을 보니 9건 모두 entities 를 하나만 두고 포함 관계를 children 중첩으로 적었다.

이게 왜 탈락인지가 중요하다. 정본이 그렇게 정했다. capability.ts:300-305 의 주석이 근거까지 적어 뒀다 — B-34(2026-09-04)로 「NestedScope 는 동심원이라 children 사슬로 적으면 단일 사슬 HierarchicalTree 와 데이터상 같은 모양이 되어 버린다」며 평평한 entities ≥ 2 로 되돌렸다. 규칙이 맞고 생성기가 안 지킨 것이다.

쿼리 유닛에는 items 가 있는데 매치된 컴포넌트에 items 슬롯이 없으면, items 를 쉼표로 이어 붙인 뒤 "items: …" 를 만들어 label 슬롯 뒤에 줄바꿈으로 붙인다. 아무도 접두를 벗기지 않는다.

색인 점유율(11.8%)보다 실제 노출이 낮다. 쿼리에 items 가 있는 게 197건(50.4%)인데, 그중 1위 행에 items 슬롯이 없는 경우가 14건(3.6%)이다. fieldMove 벌점이 items 슬롯 있는 쪽으로 밀기 때문이다.

ListingTable·ComparisonTable 을 matrix 로 적으면 "matrix 가 행 텍스트를 통째로 소유한다"며 쿼리 units 를 비운다. 그러면 매치된 컴포넌트의 모든 유닛이 blank 로 가고, 표 옆 제목·목록이 전부 임시 문구가 된다.

8.7%가 작아 보이지만 착시다. ListingTable 485행 중 matrix 는 57행뿐이고 그 57행 중 56행(98.2%)이 텍스트 유닛을 갖고 있다. 그래서 ListingTable 검색의 1위 미대치율이 71.4%다 — 전체 평균의 세 배다.

색인 공급이 극단적으로 치우쳐 있다. P0 13종 중 넷이 세 자리 수다.

List 34,607 · LongForm 33,169 · HighlightedMessage 10,051 · Steps 3,008 · Timeline 1,553 · Versus 986 · Transformation 730 · ListingTable 485 · ComparisonTable 161 · Cycle 138 · SWOT 131 · Staircase 94

그런데 프롬프트는 "넓은 것과 좁은 것이 둘 다 맞으면 좁은 쪽이다"라고 시킨다. 정본이 시키는 방향이지만, 효과는 tier 1 을 34,607행 풀에서 94행 풀로 옮기는 것이다.

IIS 가 글리프 노드를 슬롯으로 안 잡아서 경계 안 잔여로 떨어진다. 화면은 잔여를 임시 문구로 채우는데, 임시 문구 표가 Marker 를 모르는 역할로 보아 1~2자 자리에 "내용" 을 넣는다.

앞서 이 결함을 크게 잡았던 건 틀렸다. 색인 점유율은 11.0%지만 창에는 1.6%만 들어오고 1위에 온 검색은 1건(0.3%)이다. insideResidue 벌점 10이 이미 잘 밀어낸다. 비내용 잔여 전체로 넓혀도 1위 17건(4.3%), 창 79건(20.2%)이다.

제목 처리에서 반대 방향의 실패가 둘 있다 — 제목을 넣을 자리가 있는데 버리는 것과 제목을 넣으면 안 될 자리에 넣는 것이다.

① 버리는 쪽 (1위 5.4% · 창 21.7%). 제목 위성이 없는 컴포넌트에서 쿼리 제목은 titleDropped 로 사라진다. 그런데 같은 경계 안에 RLSC 역할이 Title 인 잔여 노드가 있으면 거기엔 임시 문구가 들어간다. 화면은 "제목 자리가 있는데 임시 문구를 넣고 진짜 제목은 버렸다" 가 된다. 색인에서 이런 행이 5,694개(5.1%)이고 1위에 온 검색이 21건이다.

② 넣는 쪽 (1위 0.8% · 창 6.1%). 경계 밖에 Title 역할 노드가 하나도 없으면 outside_text 전체가 제목 후보가 된다. 역할 제한이 없어서 위·왼쪽·큰 글꼴 가중합으로 뽑으면 Marker(크고 위에 있는 번호)가 이기기 쉽다. 부분 매치 52,882행 중 Title 역할이 0개인 행이 5,572개이고, 그중 후보 풀이 비내용 역할로만 된 행이 2,654개, 풀 크기가 1이라 기하 계산도 안 거친 행이 4,133개다.

컴포넌트가 entities 와 dataset.matrix 를 동시에 들고 있을 때, tier 2 투영이 matrix 행을 entity 로 바꿔 라벨 중복 제거 없이 뒤에 붙인다. 유닛 4개가 8개가 된다.

앞 판에서 39건(10.0%)이라 적은 건 과대였다. 39건을 라벨로 대조해 보니 둘로 깨끗이 갈린다 — 부분 겹침은 0건이다.

① 진짜 중복 — 11건 (2.8%)
entities 와 matrix 행의 라벨이 순서까지 완전히 같다. csv-89 Funnel(4개), csv-68 BarChart(3개), csv-15 StackedBarChart(4개) 등.
앞 절반은 라벨만, 뒤 절반은 라벨+수치라 화면에 같은 항목이 두 줄씩 뜬다.

② 축이 달라 중복이 아닌 것 — 28건 (7.2%)
라벨이 하나도 안 겹친다. csv-54 는 entity 가 지표(운영 인지도…)이고 행이 연도(2023년…)다. csv-7 L3 는 entity 가 회사(농심·오뚜기), 행이 지표(매출·연평균 성장률) — 전치 관계다.
이어 붙이는 게 틀린 건 아니지만 유닛 수가 부푼다. 28건 중 3건은 합친 수가 도착 카테고리의 색인 최대 유닛을 넘는다 — csv-6 은 11 > 10, csv-48·50 은 5 > 4 라 후보가 깎인다.

벤더는 제대로 하고 있다. eregion/…/projection.ts:201 의 P4 는 label 이 겹치는 행을 뺀다. 우리 래퍼가 그 앞에서 delete prepared.dataset 을 해 버려 벤더 P4 가 아예 돌지 않는다.

정렬 키에서 fallback_order — 그 tier 안에서 쿼리 프레임이 몇 번째 칸인가 — 가 cost 보다 앞이다. 같은 tier 안에서 비용이 훨씬 비싼 후보가 1등이 된다.

같은 tier 인접 쌍 3,347개 중 41개에서 앞선 것이 더 비싸고 41개 전부 매치된 카테고리가 다르다. 최대 역전 +435: ComparisonTable 쿼리에서 cost 440짜리가 cost 5짜리를 이긴다.

묶음 점수는 슬롯 비용의 합인데, 결과가 0건인 슬롯은 비용 0이다. tier 셈에서도 빠지고 「온전한가」 판정에서도 온전하다고 본다. 빈 칸이 채운 칸보다 유리하다.

프리셋 #9(「미식축구 vs 럭비」)의 L2 묶음은 슬롯 3개 중 핵심 ComparisonTable 이 결과 0건인데 점수 6.00 · tier 1 로 1등이다. 표를 온전히 맞춘 L1 단일 카드는 비용 201 로 3등이다. 슬롯 2개 이상 묶음 57개 중 2개가 이 모양이고 둘 다 1·2등을 먹었다.

정렬에 두 번 쓰이는 template_idx 가 색인 112,227행 전부 NULL 이다. 적재기에 그 컬럼을 쓰는 코드가 없다 — 채우는 건 build-comp-signs.ts 와 build-post-replace-relayout.ts 뿐이고 build-comp-frames.ts 에는 한 줄도 없다.

fetch 순서의 첫 키가 무력해 실질 design_object_id DESC 다. 타이브레이커도 무력해 비용이 같으면 do_id 큰 것이 1등이다. 랭킹 블루프린트가 List 오탐 가설로 세운 "template_idx DESC 가 1위를 정한다"는 틀렸다.

frame.decorations 가 색인 112,227행 전부 {ornament:false, background:false} 다. 예외가 0이다.

적재기가 detectDecoration 을 부르긴 하고 역할 표기도 맞다 — Element.Decoration 이 실제 표기라는 걸 boundaryPrompt.ts:155 가 실측 사례로 인용한다. 문제는 그 함수가 경계 서브트리 안만 훑는데 장식·배경은 그 밖에 있다는 것이다.

그래서 rank.ts:116 과 documentSearch.ts:728 의 compareDecoration 은 항상 0을 돌려준다. Visual Summary 가 decoration 선호를 적어도 순서가 한 칸도 안 바뀐다.

capOverflow(가중치 4)와 capChars(2)가 overflow_multiplier 기본 1.0에서 항상 0이다.

논리적으로 확실하다. capOverflow 가 0이 아니려면 lines > cap.lines(cost.ts:286-288) 여야 하는데, 그 조건이 용량 게이트의 배제 조건(cost.ts:344)과 정확히 같다. 게이트를 통과한 후보는 정의상 이 항목이 0이다. capChars 도 softAt = 1.0 이라 같은 처지다.

결과적으로 글이 상자에 빡빡하게 들어가는 후보와 여유 있게 들어가는 후보가 같은 점수를 받는다.

src/comp-frame/align.ts:617-621 의 규칙 (e)는 ctx.preserveTexts 가 있어야 짧은 원문(단위·기호 같은 것)을 보존한다. 그런데 저장소 전체에서 이걸 채우는 곳이 scripts/frame-oracle/dump-frame-goldens.ts 하나뿐이다.

search.ts·candidateSource.ts·useFrameSearch.ts 어디도 안 넘긴다. 골든을 뜰 때만 살아 있고 화면에서는 한 번도 안 돈다. 그래서 골든은 통과하는데 실제 대치는 다르게 동작한다.

QnA 의 marker 슬롯 3건이 blank 로 떨어지는 것도 이 경로다 — 보존 규칙이 돌았으면 살았을 자리다.

순번 카테고리(Steps·Staircase·Timeline)를 쓰는 검색이 31건(7.9%)인데, marker 슬롯을 가진 행이 1위에 온 검색은 0건이고 창 안에도 7건(1.8%)뿐이다. 규칙 (d)가 실제로 도는 일이 거의 없다.

색인 쪽을 보면 이유가 보인다. marker 슬롯을 가진 행이 1,282개(1.14%)뿐이고 ProcessFlow_Steps 3,008행 중에는 2개다. 반면 Marker 역할의 잔여는 33,193개다 — 마커 텍스트는 널려 있는데 IIS 가 슬롯으로 안 잡는다.

부수로 src/comp-frame/orderedCategories.ts:18-21 의 접두 목록(ProcessFlow_·Progression_·TimelineSchedule_)에 Cycle_ 이 빠져 있다. 주석은 벤더 reads.content 에 order 계열 필드가 없다는 걸 근거로 셋이면 끝이라 적었는데, 그건 Cycle 이 순서를 갖느냐와 다른 질문이다. 다만 위 숫자 때문에 실효 반경이 거의 0이다.

얕은 풀과 다른 문제다. tier 1 카테고리는 성립했는데, filter.ts:175 의 dataset_kind 하드 필터를 통과하는 행이 그 카테고리에 0개인 경우다. 22건(5.6%)이다.

ListingTable 이 전형이다 — 색인 485행 중 matrix 인 건 57행뿐이고 나머지 428행은 텍스트로 그린 표라 dataset: none 이다. matrix 쿼리는 그 428행을 영영 못 본다. 반대로 entities 형 쿼리는 57행을 못 본다.

그래서 tier 1 이 성립해도 결과가 tier 2 에서만 나온다. 배지는 tier 2 인데 사용자는 왜인지 모른다.

뒤집으라는 신호는 나오는데 적용하는 코드가 없다. 벤더 iis/propertyMatch.ts 가 reverse: true 를 제대로 내는데, rank.ts:240 은 이미 뒤집지 않은 프레임으로 align 을 돌린 뒤고 :373 은 결과에 싣기만 한다.

게다가 cost.ts:415-424 는 쿼리에 적힌 키만 대조한다. apex 를 생략하면 충돌이 0이라 문서 순서 그대로 정렬된다. 색인 80행 중 78행이 apex: first 인데 정본 기본값은 last 다.

L1·L2·L3 가 구조적으로 같으면 한 문서로 합치고 첫 레벨을 대표로 쓴다. 코드는 "어느 것을 남기든 검색에는 상관없다"고 적어 뒀는데 틀렸다 — 제목은 위성 슬롯이 되어 titleDropped 비용을 좌우하고 카드의 제목 자리에 그대로 들어간다.

합쳐진 68그룹 중 25그룹(36.8%)이 레벨 간 제목이 다르다. 잘못 합쳐진 건 0건이다. 반대로 갈린 268쌍 중 16쌍은 셀·라벨이 완전히 같고 열의 role·unit·axis 메타만 다르다.

중첩 컴포넌트는 N1 → N2(강등 조합 전부) → N3/N4 → N5 순으로 내려간다. 시도 상한이 없다 — nestedSearch.ts:43-44 에 "No attempt quota"라고 의도적으로 적혀 있다.

후보 0인 공급에 실제 함수를 돌려 셌다. List 아래 Staircase 자식이 1~5개일 때 7 · 52 · 277 · 1,402 · 7,027회다. count 왕복 중앙값 70ms 면 자식 5개에 8분이다.

그런데 색인에 중첩 경계를 가진 행이 154개(0.14%)뿐이다. 경계 4개 이상은 0행이라 자식 4개짜리 질의는 1,402회 중 1,400회가 반드시 빈 응답이다.

프리셋 403조각에 중첩이 0개다 — 생성기가 entity.components 를 안 쓴다. 이 경로는 손으로 쓴 YAML 에서만 닿고 프리셋 리포트로는 영영 못 잰다.

관계 해석이 하나라도 실패하면 쿼리 프레임을 통째로 버리고 빈 결과에 meta.error 를 달아 돌려준다. 그런데 meta.error 를 읽는 곳이 src/comp-frame 전체에 없다. useFrameSearch.ts:100 의 주석 한 줄뿐이다.

of 소비처 여섯을 다 확인했는데 하나도 실패로 끝나지 않는다. cost.ts 에 .of 참조는 0건이다. 이 코퍼스에서는 0건이고 of 를 쓰는 17건(4.3%)이 전부 label 로 적혀 있다. 빈도가 아니라 침묵이 문제다.

• 슬롯 키 겹침 (묶음 3.5%) — 슬롯 카드 키가 do_id|node_id 뿐이라 두 슬롯이 같은 결과를 고르면 React 키가 겹치고 iframe 큐 키도 공유한다. #12 의 L2 묶음은 슬롯 9개 중 두 쌍이 같고, L2·L3 묶음이 같은 1등을 고른 프리셋이 134 중 16이다. FrameGroupCard.tsx:369-371, 413-416
• peel 이 부모 잔여를 엉뚱한 자식에 붙인다 — 부모의 모든 entity 를 펴서 children[0] 에만 붙인다. nestedSearch.ts:196-213
• 문서 병합 1위가 미대치 (문서 32.6%) — 묶음 점수가 슬롯 비용의 합이라 슬롯이 둘이면 두 비용을 합쳐 단일 카드와 겨룬다.
• N2·묶음 결과가 언제나 tier 1 · 보기 모드가 반쯤 죽는다 · 첫 완주 분할 우선 — 중첩 입력에서만. query-frame.ts:402-448 · documentSearch.ts:412-417 · nestedSearch.ts:168-181

• 큐 리셋 고아 카드 — 검색 한 번에 iframe 큐가 통째로 비워지는데, 그 순간 waiting 이던 카드는 pending 에서 빠지고 phase 는 그대로다. error 에서 나가는 전이도 하나도 없다. useIframeQueue.ts:23-26 · FrameThumbnail.tsx:521-527, 727
• REQUEST 2회 전송 — 리셋은 setPhase(idle) 을 예약만 하고 REQUEST effect 는 클로저의 phase === 'loaded' 를 보고 즉시 보낸다. 첫 전송은 옛 색상 doc 을 싣는다. FrameThumbnail.tsx:715-727, 741-790
• 미대치 표시 위치 어긋남 — renderedOverlayBoxes 가 루트 배치만 실측하고 노드 상자는 원본 것을 쓴다. resultMaps.ts:387 의 allowedIdsFromResult 가 바로 이 용도로 만들어졌는데 아무도 안 부르는 죽은 코드다. untouchedOverlay.ts:259-291
• 자산 캐시 미충전 — 데이터셋 토글이 캐시를 비우는데 가져오기 effect 는 옛 클로저로 need = ∅ 를 낸다. 실패한 id 도 doc: null 로 영구 캐시된다. useResultAssets.ts:374-376, 385, 399-426
• Cycle·SWOT 이 프롬프트 본문에 0회 — 「List 는 마지막 수단」 표에 순환 행이 없어 Cycle→Steps 오분류가 코퍼스 판정에 4건 있다. 이 저장소 사본(generate/prompts/v2/system.md)에서 고치면 이 화면만 바뀌고, 실서비스는 aippt generator/prompt.ts 를 고쳐야 한다.
• LOADED 10초 초과가 「서버 실행」으로 굳는다 · 형제 축소가 빈 슬롯 임시 문구를 못 본다 · 별칭이 진짜 텍스트를 가린다 — 코드 읽기로 확정했고 빈도는 안 쟀다.