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

최신 저장 채점 2026-09-01 11:38:59 KST · 평가 가능 89건 · 실제 글자 영역 실측 2026-08-31 19:01:03~19:01:20 KST. 원시값은 eval-out/runs/methods/adaptive-relayout/evaluation.json과 eval-out/runs/rescore-20260901e/panes.json을 직접 합산했다.

게이트 통과율은 (SUCCESS+ACCEPTABLE) 94.4%다. 넘침·겹침을 남기지 않고 내용을 담아냈다는 뜻이다. SUCCESS 는 73.0%다. method 9 전 같은 89건의 37.1%에서 35.9%p 올랐다 — §3에서 정렬선 개선을 분리해 본다. 두 숫자의 의미를 바꿔 쓰지 않는다.

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

사유별 건수는 중복 집계라 합이 19를 넘는다. 최신 Sol baseline은 같은 89건에서 SUCCESS 58 · ACCEPTABLE 23 · FAIL 6 · UNKNOWN 2다. UNKNOWN 2건은 baseline 결과가 없어 비교 분모에서 빠진다.

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

한 장씩 크게 보기

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

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

채점 시각 2026-09-01 11:38:59 KST. UNKNOWN 2건은 5546858·5698327의 baseline 결과 없음이며, Adaptive 성적에는 포함된다.

8월 30일 5-way 실험 조건 · 역사 기록

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

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

제약 만족도와 생성 시간 — 2026-08-30 역사 기록

아래 5-way 표와 그림은 method 9·정렬선 붕괴 바닥(0.60) 적용 전 역사 기록이다. 최신 성적과 직접 비교하지 않는다. 한 줄에 분모가 둘이다 — 시간 표본은 평균 시간을 잰 건수(실제로 After 가 나온 것), 통과·SUCCESS는 평가 가능 89건 고정 분모다. Adaptive 가 100/100 인 것은 평가 제외 11건에도 After 를 만들었기 때문이다. · sol 두 설정의 미판정에는 Sol 이 baseline 을 못 만든 5546858·5698327 이 들어 있다.

SUCCESS 73.0% — method 9가 정렬선을 다시 세웠다

정렬선 보존율 0.80 하한은 그대로 두고 알고리즘을 고쳤다. ACCEPTABLE은 53건에서 19건으로 줄었고, 정렬선 사유는 6건만 남았다. 임계값을 낮춰 등급을 올린 것이 아니다.

한 건이 두 사유에 걸릴 수 있어 합이 19를 넘는다. 정렬선 평균은 method 9 전 0.799에서 0.943으로, 중위는 0.832에서 1.000으로 올랐다.

2026-08-30 시간 측정 경계 — method 9 적용 전 역사값

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

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

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

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

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

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

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

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

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

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

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 · EXCESSIVE_GUIDE_KEPT=0.6 · SUCCESS_GUIDE_KEPT=0.8 · OVERFLOW_AREA_TOL=0.1 · VERDICT_EPS=5e-4 를 그대로 옮겼다. 이 페이지의 최신 수치는 워크스페이스 HEAD 3095b6596 · 채점 2026-09-01 11:38:59 KST 기준이다.

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

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

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

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

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

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

method 9가 5699884의 정렬 그룹을 다시 세우며 신규 겹침 2쌍을 없애 SUCCESS로 바꿨다. 최신 FAIL은 서로 다른 두 갈래다. 겹침 2건은 기존 겹침을 밀어 키운 증가분이 게이트에 걸렸고, 정렬선 붕괴 3건은 새 바닥 0.60이 이전 ACCEPTABLE을 FAIL로 드러낸 것이다.

케이스별 다음 점검 지점

2는 사용자가 확인한 현재 동작 한계이며 이번 100건에서 발생률을 따로 집계하지 않았다. 4는 method 9가 좌표 정렬선 수준에서 크게 개선했지만 의미 그리드까지 해결한 것은 아니다. 아래는 항목별 실제 사례다.

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

이 항목만은 그림으로 보이지 않는다 — 결과가 아니라 비용의 문제다. 이전 판의 평균 2.69회·p95 0.60초는 method 9 전 실행 기록이다. 최신 평균과 지연시간은 다시 재야 한다. 자세한 내역과 hand-off 계획은 §11에 있다.

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

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

4 · 좌표 정렬선 복구 — method 9가 바꾼 결과

method 9는 같은 L/R/T/B 정렬선을 공유하는 요소를 함께 옮긴 뒤 실제 렌더로 다시 확인한다. 그 결과 같은 89건에서 평균 정렬선 보존율이 0.799 → 0.943, SUCCESS가 33 → 65로 올랐다. 다만 하한을 넘겨도 온전한 것은 아니다 — SUCCESS 65건 중 22건은 여전히 정렬선 1 미만이다.

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

잔여 FAIL은 다섯 건이다. 6690122·6248263은 각각 3,633px²·399px²의 신규 겹침이 남고, 5546858·5628689·6869327은 넘침과 신규 겹침은 0이지만 정렬선 보존율이 0.60 FAIL 바닥 아래다. 즉 남은 문제는 충돌 2건 + 정렬선 붕괴 3건으로 갈렸다 — 원인 분석은 §8에 있다.

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

1 · 지금 무엇이 비용인가

269회·2.69회·0.16초는 method 9 이전 판의 저장 기록이며 외곽선 사전 추출·입력 준비·최종 채점은 포함되지 않는다. 최신 경로는 정렬선 검증이 추가되어 호출 상한이 6회로 늘었다. 평균 지연시간과 캐시 적중률을 다시 재기 전에는 속도 개선이나 저하 폭을 단정하지 않는다.

2 · runtime 에 어떻게 넣는가

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

3 · 사전에 indexing 할 것

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

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

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

경로는 모두 miricanvas-iui 기준 · 수치는 커밋 3095b6596의 최신 저장 재채점본(2026-09-01 11:38:59 KST). 재배치 전후 pane 비교는 scripts/relayout-rescore-panes.ts.

최신 측정값

eval-out/runs/methods/adaptive-relayout/evaluation.json · eval-out/runs/rescore-20260901e/panes.json

정렬선 알고리즘

relayout-methods/keepGuides.ts · adaptiveRelayout.ts · relayout-core/betterOf.ts · relayout-core/verdict.ts

규칙·구조 문서

src/post-replace-relayout/README.md · docs/relayout_logics.md · docs/architecture.md · docs/evaluation-rules.md

이전 판 역사 기록

evidence.json · outcome-metrics.json · five-way-comparison.json · timing-detail.json · runtime-review-2026-08-31.md