재배치 개발 경과와
검증 결과

2026-08-30 저장 평가 100건 기준 · 최종 After 실측 20:53:11~20:53:39 KST · 저장 문서 재채점 20:54:38 KST. 이 페이지는 그 자료를 아카이브 서식으로 옮긴 것이며 문장·수치는 원본 그대로다.

주지표는 통과율(SUCCESS+ACCEPTABLE) 96.6%다. 넘침·겹침을 남기지 않고 내용을 담아냈다는 뜻이다. SUCCESS 만 보면 37.1%로 뚝 떨어지는데, 이는 실패가 늘어서가 아니라 정렬선 보존율 0.80 하한이 SUCCESS 조건에 들어가 있기 때문이다 — §3에서 정면으로 다룬다. 두 숫자의 의미를 바꿔 쓰지 않는다.

기본 결함과 가독성 관련 전후 지표

ACCEPTABLE 16건도 원인을 나눠 봅니다. 13건은 유휴 여백 증가, 3건은 10% 초과 폰트 축소 때문이며 이번 결과에서는 두 이유가 겹치지 않습니다. 전자는 공간 활용·균형, 후자는 축소를 대체할 배치 전략을 개선해야 합니다.

Expected는 같은 89건에서 SUCCESS 73 / ACCEPTABLE 15 / FAIL 0입니다. 다만 Expected는 독립적인 완벽한 정답이라는 가정 없이 품질을 계속 감사해야 합니다. 원안은 자기와 비교하므로 항상 SUCCESS가 되는 기준 장입니다.

글을 줄이기 전에 남는 가로 공간을 쓴다.

한 장씩 크게 보기

아래 그림이 한 줄에 한 장씩 커집니다. 다시 눌러 나란히 볼 수 있습니다.

구조는 지켰지만 SUCCESS 기준 0.90 에 못 미친다 — 가독성을 양보한 결과.

실험 조건

“짧은 규칙”과 “긴 규칙”

길이만의 효과로 읽지 않는다. 두 문서는 분량뿐 아니라 내용·구체성이 다르고, 긴 쪽에는 이번 테스트 100건 중 44건의 ID가 과거 사례 설명과 함께 들어 있다.

제약 만족도와 생성 시간 — 최신 100건

통과율 순으로 정렬했다. 한 줄에 분모가 둘이다 — 시간 표본은 평균 시간을 잰 건수(실제로 After 가 나온 것), 통과·SUCCESS는 평가 가능 89건 고정 분모다. Adaptive 가 100/100 인 것은 평가 제외 11건에도 After 를 만들었기 때문이다. · sol 두 설정의 미판정에는 Sol 이 baseline 을 못 만든 5546858·5698327 이 들어 있다.

SUCCESS 가 37.1% 인 이유 — 정렬선 보존율

실패가 늘어서가 아니다. SUCCESS 조건에 정렬선 보존율 0.80 하한이 들어가 있고, 재배치가 그 선을 자주 넘어뜨린다. ACCEPTABLE 53건의 사유를 세어 보면 그대로 드러난다.

한 건이 두 사유에 걸릴 수 있어 합이 53을 넘는다. 사유가 정렬선 하나뿐인 38건의 분포는 최소 0.212 · 중위 0.679 · 최대 0.778 이다 — 넘침·겹침·폰트·여백을 다 지키고 정렬만 못 지킨 결과다.

측정 경계 — 무엇이 시간에 들어가나

문제 정의는 한 문장으로만 짚습니다. 글은 바뀌었는데 공간 배분이 그대로이기 때문에, 한쪽은 넘치고 다른 쪽은 비어 있습니다. 우리가 바꾸는 것은 내용이 아니라 그 배분입니다.

이번 접근에서 먼저 정한 세 가지

1. 변경할 수 있는 것과 없는 것을 나눈다. 텍스트와 배경 도형의 폭·높이·위치·간격을 조정합니다. 내용, 노드 집합, 부모·자식 구조와 그리는 순서는 유지하며 사진·차트 자체를 늘려 문제를 숨기지 않습니다.
2. 문제를 축과 관계로 나눈다. 가로 넘침, 세로 넘침, 한 카드 내부 충돌, 카드 사이 충돌은 각각 다른 방법으로 풉니다.
3. 후보를 만든 뒤 실제 렌더로 검증한다. 좋아 보이는 숫자만 보고 채택하지 않고, 실제 글자 영역으로 넘침·겹침이 남는지 확인합니다.

예전 tidyLayout에서 배운 점: 모든 요소를 힘으로 동시에 밀고 당기는 방식은 확장·정렬·균형의 목표가 충돌했고, 튜닝을 판정할 기준도 부족했습니다. 현재는 먼저 제약과 지표를 정의하고, 목적별 후보를 제한된 범위에서 적용합니다. 이 설명은 과거 실험 기록이다.

함께 움직일 단위를 먼저 정한다

유닛은 배경 도형과 그 안의 글처럼 함께 움직이는 최소 단위입니다. 같은 줄은 밴드, 같은 열에서 공간을 다투는 단위는 체인, 그 전체를 담는 큰 도형은 프레임으로 다룹니다.

이 관계를 먼저 고정하면, “무엇과 무엇이 한 묶음인가”가 이동 도중 바뀌지 않습니다. 그다음 여백을 나누고 겹치지 않게 배치하되, 가능한 한 원래 자리에서 덜 움직이는 해를 구합니다. 모든 레이아웃을 전역 탐색하는 방식은 아닙니다.

현재 UI 의 기본 선택은 Adaptive Relayout(adaptive-relayout)이다. 후보 여덟 개를 가로 넘침 → 세로·가로 재분배 → 유닛 내부 → 유닛 간 → 세로 여백 → 가로 여백 → 폰트 축소 순으로 잇는다.

함수 이름이 번호에서 서술형으로 바뀌었다. 아래 도해의 M1~M8 은 옛 표기이며 개발 식별자일 뿐 실행 순서가 아니다 — 실행 순서는 위 표의 「순서」 칸이다.

무엇을 렌더링으로 재검증하는가

CLI 의 “렌더 횟수”는 문서 단위 글자 측정 호출 수다 — 페이지 썸네일을 만든 횟수가 아니다. 반복 보정에는 실측 tight 에 글머리 기호를 더한 visual 영역을 쓴다.

도형의 바깥 사각형 안에 들어왔다고 실제 도형 안에 들어온 것은 아닙니다. 원·캡슐·말풍선의 모서리와 구멍까지 고려합니다. 텍스트도 저장된 박스 대신 엔진이 잰 글자 영역(tight)에 글머리 기호 몫을 더한 visual 영역으로 판정합니다.

기준은 항상 대치 이전 Original입니다. Before는 재배치 입력, After는 알고리즘 결과, Expected는 비교 목표입니다. Expected와 After의 이미지 유사도를 점수로 쓰지 않습니다. 원안과 대치 문서의 좌표·배율을 맞춰 같은 자로 비교합니다.

일곱 가지 관찰 항목과 판정에서의 역할

측정의 의미: 겹침 총량과 “새로 늘어난 겹침”은 다릅니다. 디자인에 원래 있던 겹침은 보존하되 대치·재배치가 악화시킨 부분을 검출합니다. 저장 결과는 문서 해시와 연결된 실측 파일로 검증하므로, 다른 문서의 오래된 측정값을 성공 근거로 쓰지 않습니다.

이 도해의 정본은 코드다 — relayout-core/verdict.ts 의 judgeMetrics 와 상수 EXCESSIVE_FONT_SCALE=0.7 · SUCCESS_FONT_SCALE=0.9 · SUCCESS_GUIDE_KEPT=0.8 · OVERFLOW_AREA_TOL=0.1 · VERDICT_EPS=5e-4 를 그대로 옮겼다. 같은 파일 머리말 표에는 정렬선 하한이 0.90 으로 적혀 있으나 실제 상수는 0.80 이고 채점도 0.800 으로 돌았다 — 여기서는 코드를 따랐다. 이 페이지의 모든 수치는 커밋 7ebacc1ef · 채점 2026-09-01 11:07 KST 기준이다.

평가 제외와 실패를 섞지 않는다

측정 파일 누락·손상이나 기준 부재는 제외로 숨기지 않고 UNKNOWN 으로 남겨 분모에 포함한다 — 현재 0건이다. 전체 수집 기준으로는 통과 86/100, 평가 제외 11/100, 잔여 FAIL 3/100으로 함께 읽어야 한다.

UNSOLVABLE 11건은 왜 빠졌나 — 세 갈래로 나눈다

제외는 알고리즘이 실패한 것이 아니다. 11건 모두 성적 분모 89에서 빠지지만, 빠진 이유는 서로 다르고 고쳐야 할 곳도 다르다 — 앞단(대치)에서 막을 것, 범위를 넓혀 풀 것, 측정 도구를 고칠 것.

본문이 95.7px 숫자 표식 슬롯에 대치돼 13줄이 됐다. 페이지에 본문용 슬롯이 따로 있는데 긴 설명이 번호 자리에 들어갔다 — 위치·크기로는 못 푼다.

리소스 polygon 이 3조각이라 외곽선 추출이 unsupported-topology 로 떨어진다. 컨테이너가 한 조각이 아니라 막힌 것이고 — 배치가 불가능해서가 아니다.

유닛 사이 글자 충돌은 최신 보정으로 모두 해결됐다. 남은 것은 셋 다 도형을 확장하거나 옮긴 뒤 생긴 겹침이다 — 6690122 약 3,633px², 5699884 2쌍 약 19,754px², 6248263 약 399px². 도형의 확장 후보를 채택할 때 주변 이미지·도형까지 검사하는 것이 다음 과제다.

케이스별 다음 점검 지점

2·4 는 사용자가 확인한 현재 동작 한계이며 이번 100건에서 발생률을 따로 집계하지 않았다. 아래는 항목별 실제 사례다.

1 · 렌더링 재검증 — 사례 대신 호출 수로

이 항목만은 그림으로 보이지 않는다 — 결과가 아니라 비용의 문제다. 자세한 내역과 hand-off 계획은 §11에 있다.

2 · 장식이 따라오지 못한다 — 두 가지 형태

3 · 잘못된 대치는 복구 불가

4 · 그리드·리스트 정렬 — 이제 등급이 잡아낸다

세 건 모두 겹침·넘침 기준으로는 흠이 없다. 세 건 다 전에는 SUCCESS 였다 — 정렬선 0.80 하한이 붙으면서 ACCEPTABLE 로 내려왔다. 판정은 이제 이걸 잡아내지만 재배치는 아직 정렬선을 보고 고르지 않는다(§12 우선순위 2). 하한을 넘겨도 온전한 것은 아니다 — SUCCESS 33건 중 20건이 여전히 정렬선 1 미만이다.

5 · 아직 알고리즘이 커버하지 못하는 디테일

잔여 FAIL 세 건이 그 예다 — 6690122 는 가로 이동 여유가 127.21px 필요한데 좌우 여유가 108px·0px 라 후보가 하나도 만들어지지 않고, 6248263 은 부모–자식 도형이라 분리 대상에서 아예 제외되며, 5699884 는 확장 뒤 두 쌍이 새로 겹친다. 셋 다 공간이 없어서가 아니라 현재 후보가 닿지 못해 남았다 — 원인 분석은 §8에 있다.

FAIL 로 드러나는 것만 문제가 아니다. 사람이 직접 잡았다면 더 나았을 자리가 통과한 결과 안에도 있다 — 정렬선이 흐트러진 ACCEPTABLE 53건, 좁은 칼럼 11개, 장식이 따라오지 못한 배치가 그렇다. 자동 판정을 통과했다는 것과 디자이너가 만든 품질에 닿았다는 것은 다른 말이다.

1 · 지금 무엇이 비용인가

저장된 알고리즘 실험 100건 기준이며 새로 실행한 것이 아니다. 외곽선 사전 추출·입력 준비·최종 채점은 포함되지 않는다. 단계별 시간 비중과 캐시 적중률은 아직 측정하지 않았으므로 특정 비율의 속도 향상을 약속하지 않는다. 위 시간은 외곽선·입력 tight 가 준비된 조건의 개발 환경 값이다.

2 · runtime 에 어떻게 넣는가

현재 iui 는 엔진 패키지와 에디터 페이지 뷰를 가져와 별도 렌더 호스트에서 실행한다. CLI 는 헤드리스 브라우저, 뷰어는 iframe 에서 같은 글자 측정기를 쓴다. 제품에는 기존 엔진을 측정 포트로 연결하는 방향이 가능하지만 iui 결과와 동일하다는 검증이 필요하다.

3 · 사전에 indexing 할 것

줄일 수 있는 쪽은 반복이다. 같은 문서·같은 입력의 결과를 단계 사이에 재사용하고, 폭·폰트·내용·회전이 바뀐 텍스트만 다시 잰다. 검증을 빼서 속도를 얻지는 않는다.

4 · 엔진 부하와 hand-off 범위

엔진 없이 가능한 범위 — 저장된 실측값으로 채점하거나 예측 기반 후보를 만들 수 있다. 다만 폭·폰트가 바뀐 After 가 실제로 어떻게 렌더되는지는 기존 값만으로 보장할 수 없다.

경로는 모두 miricanvas-iui 기준 · 수치는 커밋 7ebacc1ef 재채점본(2026-09-01 11:07 KST). 재배치 전후 네 장 비교는 scripts/relayout-rescore-panes.ts.

측정값

evidence.json · metric-definitions.json · outcome-metrics.json · benchmark.json · five-way-comparison.json · paired-comparison.json · timing-detail.json · failure-actions.json · dependency-map.json · case-geometry.json · image-manifest.json

실행 기록

eval-out/runs/fail-current-df7a02056-20260830/details.json · eval-out/runs/leadership-report-20260830/baseline-panes.json

코드

relayout-core/verdict.ts · relayout-methods/index.ts · relayout-methods/actualOutlineFit.ts · src/text-tight-box/compute.ts · src/text-tight-box/runtime.ts · batch/bakeOutlines.ts · doc-render/DocRenderHost.tsx · relayout-methods/method5.ts

규칙·기록 문서

docs/evaluation-rules.md · docs/relayout_logics.md · docs/before-after-rules.md · docs/post-replace-relayout-handoff.md · source-notes.md · runtime-review-2026-08-31.md