결정론적 후보 선택기

후보 전부를 돌리고 고정 우선순위(사전순 비교)로 케이스마다 최선을 고르는 선택 층 — 학습·가중치 없음

상세 설계안 C · 이번 라운드는 설계만, 구현은 A·B 이후 · 2026-08-27

§1한 줄 요약

후보는 이미 11개(단독 6 + 합본 5)이고 A·B가 붙으면 파이프라인 변형이 더 는다. 고정 순서 합본 하나로는 「케이스 X에는 4→7 순서가, 케이스 Y에는 7→4 순서가 낫다」를 담을 수 없다. 선택기는 후보 풀 전체를 실행하고, 결과 지표를 고정 우선순위로 비교해 케이스마다 최선을 확정한다. PowerPoint Designer의 generate-and-rank나 Jacobs(SIGGRAPH 2003)의 템플릿 선택과 같은 구조이되, 랭커가 ML이 아니라 닫힌 규칙이다.

§2비교 규칙 — 사전순(lexicographic), 가중치 없음

가중치 튜닝은 새 자유도(회귀·과적합)를 만든다. 대신 이미 합의된 판정 체계의 서열을 그대로 비교 순서로 쓴다 — 아래 항목을 위에서부터 견주고, 같으면 다음 항목으로 내려간다.

순위	비교 항목	근거
1	판정 라벨 랭크 (SUCCESS > ACCEPTABLE > FAIL)	`verdict.ts`가 정본 — 라벨이 이기면 나머지는 안 본다
2	⑤-b 신규 겹침 쌍 수 ↓, 그다음 면적 ↓	게이트 지표 — FAIL끼리도 덜 나쁜 쪽
3	① 넘침 노드 수 ↓, 그다음 면적 ↓	게이트 지표
4	② 최소 폰트 배율 ↑	덜 줄인 쪽 — SUCCESS 불가를 만든 대가의 크기
5	④ \|유휴 여백 − 원안\| ↓	원안의 밀도로 돌아간 정도
6	③ 정렬선 보존율 ↑	라벨이 같은 결과 중 무엇이 나은가를 이미 이 값으로 고른다(evaluation-rules §3)
7	총 변위(Σ\|Δ좌표\|) ↓, 마지막으로 후보 등록 순서	같은 값이면 덜 움직인 쪽 — 마지막 항목이 결정론을 보장한다

결정론 보장 — 모든 항목이 순수 함수의 산출이고 마지막 비교가 등록 순서라 동률이 없다. 같은 입력이면 언제나 같은 후보가 뽑힌다. 무작위성·학습·환경 의존이 0이다.

§3실행 구조

selectLayout(doc, original, pool = METHODS):
  results = pool.map(m => ({ m, out: m.run(doc, { base }) }))   // 전부 순수 함수
  scored  = results.map(r => metricsOf(r.out))                  // computeLayoutMetrics 재사용
  return argmaxLexicographic(scored)                            // §2의 순서

재료가 전부 있다 — 실행(replaceLayout), 채점(computeLayoutMetrics + judgeMetrics), 변위 계산(절대 박스 비교)까지 기존 함수만 조합한다. 새 알고리즘이 0줄이다.
비용 — 후보 N개 × 문서 1회. 후보는 브라우저에서 그때그때 도는 순수 함수라(뷰어가 이미 전 후보를 판정 필터용으로 미리 잰다 — useCaseVerdicts) 구조적 부담이 없다. CLI에서는 relayout-metrics.ts가 이미 전 후보를 돌린다 — 선택기는 그 표에 「고른 것」 한 줄을 얹는 셈이다.
등록 형태 — RelayoutMethod 하나(key: 'select')로 감싸면 드롭박스·러너·리포트가 저절로 따라온다.

§4장단점

장점	단점 · 리스크
고정 순서 합본의 조합 한계를 케이스 단위로 해소 — 후보가 늘수록 가치가 커진다	실행 비용 N배 (순수 함수라 감당 가능하나 뷰어 초기 로딩에 영향)
새 알고리즘 없이 기존 자산만 조합 — 구현 리스크 최소	후보들이 못 만드는 배치는 여전히 못 만든다 — 생성력이 아니라 선택력
완전 결정론 · 재현 가능 — 가중치 튜닝 루프가 없다	비교 순서 자체는 사람이 정한 규칙 — 순서를 바꾸면 결과가 바뀐다(단, 문서화된 한 곳)
지표·판정 정본과 어긋날 수 없다 — 같은 함수를 쓴다	「최선 합본」이라는 단일 서사가 사라져 성적표 읽기가 한 겹 복잡해진다

§5왜 지금이 아니라 A·B 다음인가

지금 후보 풀에서 선택기의 상한은 「후보별 최고 라벨의 합집합」이다 — 베이스라인 실측으로 이 합집합을 먼저 재 보고(공짜 분석), 이득이 확인되면 붙인다.
A·B(+τ 변형)가 들어오면 풀이 커져 선택기의 이득도 커진다 — 그때가 적기다.
운영 관점에서는 「케이스마다 다른 후보」보다 「하나의 파이프라인」이 디버깅이 쉽다 — 선택기는 그 비용을 상쇄할 만큼 라벨이 좋아질 때만 채택한다.

§6측정 계획 (채택 게이트)

공짜 선행 분석: 기존 베이스라인 JSON에서 argmaxLexicographic을 오프라인으로 돌려 「선택기 상한」을 계산한다 — 구현 전에 이득 크기를 안다.
채택 기준: 최선 합본 대비 (FAIL 감소 ≥ 2건) 또는 (SUCCESS 증가 ≥ 3건), 그리고 정렬선 평균이 나빠지지 않을 것.