재배치 · 품질 검증 — 미리디 기술 사전

← 기술 사전 · 원본 문서 확인 2026-09-13

지금 적용되는 기준

현재 README는 크기·간격 조정, 겹침 완화, 세로·가로 여백 활용, 필요한 글자 축소와 카드 크기·정렬선 복원을 설명합니다. 기본 렌더 재검증은 실제 글자 영역과 도형 외곽선을 확인합니다.

최종 이미지의 가독성과 디자인 완결성을 독립적으로 평가합니다. 각 축의 등급은 PERFECT / ACCEPTABLE / BAD이며, 기존 SUCCESS / ACCEPTABLE / FAIL은 원안 대비 내부 진단입니다. 두 체계의 통과율을 섞어 읽지 않습니다.

8월 말~9월 초 문서는 당시 기록으로 옮겼습니다. 확대·대비 보정은 원본 README 기준 shadow 실행이며, 자동 적용 완료를 뜻하지 않습니다.

근거: 원본 README §2·§3 · 평가기 재설계

알고리즘 — 후보 아홉과 합본

단독 후보는 파이프라인의 단계가 아닙니다. 아홉은 서로 경쟁하는 후보이고, 전부 같은 케이스에 태워야 「따로 쓸 때와 합쳐 쓸 때 중 무엇이 나은가」에 답할 수 있습니다. 합본도 후보 하나로 셉니다.

무엇을 보고 가르나

세 기준은 독립입니다. 같은 후보가 ①에서 겹침, ②에서 유닛 사이로 동시에 분류됩니다.

후보 아홉과 보존 후보 둘

후보	무엇을 고치나	텍스트 폭	높이	컨테이너	예측
`redistributeVerticalSlack` m1 · 세로 유휴 여백 재분배	세로 넘침	고정	고정	높이 ↑	없다
`openHorizontalSlack` m2 · 가로 확장	세로 넘침 · 좁은 칼럼 · 부딪힘	↑	↓ (줄 수 ↓)	폭 ↑	줄 수
`resolveHorizontalOverflow` m3 · 가로 넘침 해소	가로 넘침	↓ 또는 고정	↑ (줄 수 ↑)	폭 ↑	줄 수
`separateOverlapsBetweenUnits` m4 · 유닛 사이 겹침	유닛 사이의 겹침	고정	고정	고정 (자리만)	없다
`separateOverlapsWithinUnit` m5 · 유닛 안 겹침	유닛 안의 겹침	↑	↓	폭 ↑ · 높이는 m1에	줄 수
`shrinkFontToReadableFloor` m6 · 폰트 축소	위 다섯이 못 푼 것	고정	↓ (폰트 ↓)	고정	줄 수
`spreadIntoVerticalSlack` m7 · 유휴 세로 스프레드	유닛 사이 세로 겹침	고정	고정	고정 (y만)	없다
`escapeIntoHorizontalSlack` m8 · 유휴 가로 탈출	가로로 파고든 겹침	고정	고정	고정 (x만)	없다
`keepGuides` m9 · 정렬선 동반 이동	흩어진 정렬선	고정	고정	한 변 ↑ (또는 자리만)	없다
`keepSizeGroups`	갈라진 크기	고정	고정	폭·높이 ↑ · 갭 ↓	없다
`keepCenterFromPageEdge`	흔들린 정중앙	고정	고정	고정 (자리만)	없다

「예측」 칸은 렌더하기 전에 줄 수를 맞혀야 하는가입니다. 예측이 없는 후보는 1차원 좌표 문제만 풀면 되고, 예측이 있는 후보는 강력하지만 틀릴 수 있어 렌더 재검증이 따라붙습니다.

공통 법칙 — 위상을 굳히고 좌표를 푼다

아홉의 코드는 대부분 relayout-core/의 같은 부품을 순서만 바꿔 부르는 것입니다. 좌표를 건드리기 전에 위상을 한 번 정해 굳힙니다(freezeRelations). 옮기는 도중에 다시 재면 소속이 바뀌어 결과가 처리 순서에 의존합니다.

되먹임이 하나 있습니다 — 2D로 포개진 둘은 세로 구간도 겹치므로 자동으로 한 밴드가 됩니다. 겹침이 스스로를 지키는 셈이고, m4의 첫 단계가 그 고리를 끊는 일입니다.

음수 갭이 곧 겹침입니다. 그래서 「겹친 것을 떼어 놓기」는 갭 하한을 0으로 두고 다시 나누기와 같은 말이고, m1·m4·m5가 전부 이 한 수를 씁니다.

부품	무엇	파일
여백 대수	그릇 `[from,to]`에 크기들을 놓을 때 갭을 델타 균등 + 하한 water-filling으로 다시 나눈다. 닫힌 형식	`gapAlgebra.ts`
PlaceRow (Abacus)	겹치지 않으면서 가장 덜 움직이는 배치. 1패스 스윕, 가중치(핀) 지원	`placeRow.ts`
실현가능성	못 담으면 조용히 뭉개지 않고 「몇 px 모자란가」를 남긴다	`feasibility.ts`

게이트 — 후보가 스스로에게 거는 제동

게이트	무엇을 묻나	누가 쓰나
① 없던 쌍	자기 입력에 없던 겹침 쌍을 만들었나	m1·2·3·4·5
② 목적 달성	원안 대비 신규 겹침이 실제로 줄었나	m4·5
③ 넘침 증가	넘침이 늘지 않았나	m4·5·6

②가 m4·m5에만 있는 까닭 — 자리를 다시 나누는 연산은 한 쌍을 떼어놓느라 원래 있던 쌍을 키울 수 있는데, ①은 그것을 못 잡습니다(쌍 자체는 있던 것이라서). 되돌림의 단위도 후보마다 다릅니다 — 노드(m1·2·3) · 체인/쌍(m4) · 유닛(m5) · 문서 전체(m6).

컨테이너와 장식 — 후보가 직접 다루지 않는 둘

컨테이너

사각형이 아니다

「담기는가」와 「얼마나 키울 수 있나」의 상대는 배경 도형의 bbox가 아니라 모양이 허락하는 상자입니다(containerShape.ts). 캡슐·원·말풍선처럼 bbox와 실루엣이 다른 도형도 같은 원칙을 따릅니다.

장식

후보는 모르고, 진입점이 되돌린다

리본·머리 아이콘·코너 배지는 주인을 따라가는 것이라 아홉이 각자 다룰 것이 아닙니다. 분류는 기준 문서에서 한 번 굳히고(classifyDecorations), 되돌리기는 진입점이 한 번 부릅니다(carryDecorations). 장식 안의 장식은 그 장식을 따라갑니다 — 배지 안 아이콘이 카드를 따라가면 둘이 갈라집니다.

실행 출처 — 무엇이 프로덕션인가

뷰어는 viewer/afterSources.ts의 Adaptive Relayout과 tidyLayout을 제공합니다. 단독 후보와 실험 합본은 relayout-methods/index.ts의 METHODS와 CLI로 실행합니다. 현재 METHODS에는 15개가 등록되어 있습니다 — 단독 후보 10 · 실험 합본 4 · 프로덕션 합본 adaptiveRelayout 1.

묶음	등록된 것
단독 후보 10	`redistributeVerticalSlack` · `openHorizontalSlack` · `resolveHorizontalOverflow` · `separateOverlapsBetweenUnits` · `separateOverlapsWithinUnit` · `shrinkFontToReadableFloor` · `spreadIntoVerticalSlack` · `escapeIntoHorizontalSlack` · `keepSizeGroups` · `keepGuides`
실험 합본 4	`balanceSlackToFixedPoint` · `resolveOverflowThenBalanceSlack` · `resolveOverflowThenSeparateBetweenUnits` · `resolveOverflowSlackThenOverlaps`
프로덕션 합본 1	`adaptiveRelayout`

진입점 이름이 optimizeLayout이 아니라 replaceLayout인 까닭 — relayout-core에도 실행기가 있고(대조군), 렌더러도 iframe 안에서 재배치를 하고, 대치 파이프라인에는 tidyLayout이 있습니다. 이름이 같으면 「재배치가 됐다」가 무엇을 가리키는지 늘 되물어야 하므로 이 디렉터리가 만드는 것에만 다른 이름을 붙였습니다. 입력은 rendered.json 하나이고, 후보가 「못 담겠다」고 판단하면 예외를 던집니다 — 부르는 쪽이 감싸야 화면 전체가 죽지 않습니다.

근거: 알고리즘 설명 §0~§10 · relayout-methods/index.ts. 「무엇을 만들어야 하는가」의 정본은 before-after-rules.md, 「무엇을 재는가」는 evaluation-rules.md입니다 — 규칙과 이 설명이 어긋나면 규칙이 맞습니다.

평가 — 두 축을 독립으로 판정한다

2026-09-13 재설계의 결론은 기존 SUCCESS가 최종 결과 품질을 식별할 수 없는 대리 지표라는 것입니다. 원안 대비 넘침·축소·정렬·여백의 회귀를 검사하는 목적에는 유효하지만, 최종 이미지의 가독성·완결성과는 판정 대상·면제 조건·분모가 다릅니다. 임계값을 더 엄하게 조정하는 것으로는 해결되지 않습니다.

이번 변경은 재배치 알고리즘을 다시 튜닝한 것이 아니라 그 결과를 평가하는 계약과 실행 경로를 고친 것입니다. 두 등급의 평균이나 합성 등급은 만들지 않습니다.

두 체계의 통과율을 섞어 읽지 않습니다. 뷰어의 내부 성적은 새 시각 평가 등급이 아닙니다.

결함의 소유권을 정해 두었습니다. 텍스트 또는 텍스트 배경이 원인인 결함은 가독성만 소유하고, 같은 defectId가 완결성에도 제출되면 완결성 쪽에서 제거합니다. 페이지 전체 위치·외곽 여백은 두 축 모두 감점하지 않습니다.

원안부터 있던 결함이나 작은 면적을 시각 평가에서 면제하지 않습니다 — 기하 필터를 면제 조건으로 쓰던 것이 오판의 원인이었습니다.

원본에서 동기화한 가독성 평가 기록

엄격 가독성 VLM — TC 316개 · 2026-09-13 19:30:03 KST

GPT-5.5/high로 동일 최종 이미지 316장을 가독성만 평가했다. PERFECT 181 · ACCEPTABLE 75 · BAD 55 · 미판정 5다. 전체 기준 통과율은 256/316 = 81.0%, 판정 가능한 311건 기준은 82.3%다. 미판정 5건도 UNSOLVABLE 라벨과 원래 상태·사유를 담은 JSON으로 보존했다. 기하 통과 274건 중 42건은 VLM BAD였다. 이는 모델 판정이며 독립 사람 정답 대비 정확도가 아니다. 판정 절차·교차표·원시 자료·한계에 기록했다.

↻ 가독성 VLM 평가 기록 · README.md — 원본에서 자동 동기화

최종 이미지 가독성의 모델 판정입니다. 디자인 완결성 전건 평가와 독립 사람 정답 대비 정확도 검증은 별도입니다.

남은 작업 — P1

원본 작업 정리가 다음 검증·자동 적용 전에 우선할 항목으로 꼽은 것들입니다. 미검증 범위를 이미 발생한 운영 결함으로 취급하지 않는다는 단서가 함께 붙어 있습니다.

기존 visual-eval 출력 경합·중단 소실 — 확인된 결함. 같은 출력 경로 22회 중 JSON 손상 2회가 재현됐습니다. rename만으로는 해결되지 않습니다
평가 축별 오류 격리 — 완결성의 형식 오류가 가독성 발급까지 막았습니다
VLM의 영역 이탈 인식 — 한 줄 이탈을 독립 텍스트로 오인해 가독성 PERFECT를 반환한 사례가 있습니다
좌표 모순 재관찰과 실패 응답 보존 — 단어 영역이 subject 밖인 응답을 거절했습니다. 좌표를 억지로 보정하지 않습니다
관찰 정확도·전체 이미지 회귀 — 독립 사람 정답셋, 축별 confusion matrix, BAD recall, 분절 precision/recall이 남아 있습니다
자동 적용 전 측정 보강 — 잘리기 전 glyph 복원, 실제 폰트·리소스 바이트 서명, 적재 실패 확인

회귀 검사는 27,744건 중 27,729 통과 · 15 실패이고, 그 15개는 이번 변경의 새 회귀가 아닙니다(docFrame 7 · openHorizontalSlack 4 · 나머지 4). 기대값을 완화하거나 Expected를 바꿔 통과시키지 않았습니다. 근거: 2026-09-13 작업 정리 · P1 구현·검증 결과

필요한 원본으로 바로 가기

알고 싶은 것	정본 문서
전체 사용법·TC 준비·최신 결과	재배치 README
알고리즘의 실행 순서	알고리즘 설명
평가 계약·미확인 처리	평가기 재설계
최신 전건 가독성 결과·한계	316건 가독성 평가
후속 검증·잔여 작업	P1 구현·검증 결과
확대·대비 보정의 지원 범위	가독성 보정 구현

링크는 로컬 원본을 편집기로 엽니다. 이 페이지의 설명은 위 원본 문서에서 확인한 범위입니다.