Llm Eval on ICE-ICE-BEAR-BLOG

Polaris MCFG — 라이센스 안전한 폰트 메트릭 호환 생성기, 그리고 LLM 평가 루브릭 토론

Wed, 06 May 2026 00:00:00 +0900

개요

PolarisOffice/polaris_mcfg는 2026-04-26에 풀린 폴라리스오피스 제품팀의 도구로 보인다. 한컴 폰트나 사내 상용 폰트처럼 재배포가 제한된 폰트에서 레이아웃 메트릭만 추출해, NotoSans·Pretendard 같은 자유 라이센스 폰트의 글리프 디자인에 입혀 새 폰트를 만든다. 결과물은 원본 문서의 줄바꿈/페이지 분할이 그대로 유지되면서도 라이센스가 안전한 폰트다. 흥미로운 점은 같은 시기에 LLM 평가 루브릭 이야기가 함께 회자됐다는 것 — 두 토픽 모두 production-grade engineering의 단면이다.

graph TD
 Source["Source font.ttf <br/> (상용/제한)"] --> Extract["mcfg extract"]
 Extract --> Metrics["metrics.json <br/> advance/ascender/descender"]
 Free["Free font.ttf <br/> (NotoSans/Pretendard)"] --> Generate["mcfg generate"]
 Metrics --> Generate
 Generate --> Output["Polaris font.ttf <br/> OFL-safe"]
 Output --> Validate["mcfg validate <br/> HarfBuzz 렌더링 회귀"]
 Validate --> Pass["PASS <br/> advance widths 일치 <br/> 렌더링 ±0.5 percent"]

풀려는 문제

기업 문서 환경에서 한컴 폰트로 작성된 .hwp/.docx를 다른 환경에서 열면 줄바꿈과 페이지 분할이 깨진다. 글리프 모양이 다른 게 문제가 아니다 — advance width, ascender, descender, line gap 같은 숫자 메트릭이 다르기 때문이다. polaris_mcfg는 이 문제를 정확히 한 줄로 풀었다: outline은 건드리지 않고, 숫자 메트릭만 자유 폰트에 이식한다.

핵심 분리 — 라이센스 안전 경계

도구가 다루는 데이터는 숫자 메트릭만이다. 글리프 outline은 추출도 복제도 하지 않는다. 따라서 생성된 폰트의 시각적 디자인은 100% 자유 폰트 쪽이고, 라이센스도 자유 폰트의 라이센스를 따른다. SIL Open Font License (OFL) 1.1 — 2007년 SIL International의 Victor Gaultney와 Nicolas Spalinger가 마지막으로 손본 이후 20년 가까이 변하지 않은, 폰트 산업의 사실상 표준 자유 라이센스다. NotoSans·Pretendard 모두 OFL.

CLI

서브커맨드	설명
`mcfg extract <font.ttf>`	메트릭 → JSON
`mcfg compare a b`	두 폰트(또는 JSON) 비교 (text/json/html)
`mcfg generate --metrics … --design …`	합성 폰트 생성
`mcfg validate <font> --against …`	메트릭 만족 여부 검증

mcfg extract NotoSansKR-Bold.ttf -o bold.json

mcfg generate \
 --metrics bold.json \
 --design NotoSansKR-Regular.ttf \
 --output PolarisBoldMetrics-Regular.ttf \
 --apply global,advance \
 --license-text "SIL Open Font License 1.1"

mcfg validate PolarisBoldMetrics-Regular.ttf \
 --against NotoSansKR-Bold.ttf \
 --render-default \
 --render-tolerance-pct 0.5
# → result: PASS (advance widths 일치, 렌더링 ±0.5% 이내)

검증 단계에 HarfBuzz를 쓴다. OpenType shaping의 사실상 표준 엔진이라 — 실제 렌더링 결과를 픽셀 단위로 비교해야 메트릭 이식이 진짜 통했는지 확인할 수 있기 때문이다.

마일스톤과 라이센스 책임

M1 메트릭 추출기 + JSON 스키마부터 M7 패키징/문서까지 모두 완주, 84 tests 통과. 도구 코드는 MIT, 생성된 폰트는 디자인 폰트 라이센스(OFL 등)을 따른다. 다만 소스 폰트의 EULA가 메트릭 추출을 허용하는지 검토할 책임은 사용자 본인(Requirements.md §6)이다. 도구가 라이센스 회피 자동화 머신이 아니라 정직한 분리 도구라는 점을 분명히 한다.

함께 회자된 LLM 평가 루브릭 토론

이 링크의 직전 대화가 무관해 보이지만 사실 매우 흥미로운 LLM 평가 토론이었다.

“벡터유사도나 RAGAS 지표는 채점에 적합한 방법은 아닌 것 같구요. 주관식 채점은 무조건 결국 llm 태우셔야 하고, 평가 루브릭을 먼저 작성해서 이거 기반으로 하는게 보통일 것 같습니다.”

이 한 줄에 LLM-as-Judge 운영의 통념이 압축되어 있다. (1) Vector similarity / RAGAS는 의미 일치를 점수화한다고 해도 채점 기준이 못 됨. (2) 주관식 채점 = LLM 호출 필수 — rule-based로 점수화 불가. (3) 평가 루브릭을 먼저 작성. LLM에게 “잘 했는지 봐줘"는 안 됨. 명시적 기준표가 있어야 일관성이 나온다.

이 흐름은 최근 LLM eval 도구들 — DeepEval, Evidently, OpenAI Evals — 가 모두 가는 방향과 일치한다. rubric-driven judge가 사실상 표준이 됐다.

인사이트

폰트 메트릭 추출기와 LLM 평가 루브릭이 같은 시기에 함께 회자된다는 점은, 이 영역이 “실제 제품을 만드는 사람들의 일상” 임을 보여준다. 두 토픽이 표면상 무관해 보여도 본질은 같다 — 둘 다 “사람의 직관에 의존하는 영역을 명시적·검증 가능한 규칙으로 환원하는 작업"이다. 폰트 도구는 “메트릭이 호환되는가"를 HarfBuzz 렌더링 회귀로 객관화하고, LLM-as-Judge는 “답이 좋은가"를 루브릭으로 객관화한다. 둘 다 자동화 가능한 검증 단계를 만들어내야 production에 쓸 수 있고, 그 검증 단계가 곧 도구의 정체성이 된다. polaris_mcfg가 validate 서브커맨드를 가진 것과 LLM eval 도구가 rubric을 1급 객체로 다루는 것은 완전히 같은 사고방식의 발현이다. 생산 환경에서 “그냥 잘 돌아가더라"는 통하지 않고, 명시적 기준 + 자동 검증 + 회귀 추적이 새 표준이라는 점에서 두 토픽은 같은 지점을 가리킨다.

참고

Tool repo and demo

PolarisOffice/polaris_mcfg — Metric-Compatible Font Generator (MIT, Python, ★4)
데모 페이지

Font ecosystem

HarfBuzz — OpenType shaping 엔진
SIL Open Font License — 폰트 산업 자유 라이센스 사실상 표준 (OFL 1.1, 2007)
SIL International — OFL 관리 단체
Noto Sans · Pretendard — OFL 기반 자유 한글 폰트

LLM evaluation methodology

RAGAS — RAG eval 프레임워크
DeepEval — LLM-as-Judge + rubric 기반 eval
Evidently — ML/LLM 모니터링과 eval
OpenAI Evals — OpenAI 공식 eval 프레임워크

Simon Willison의 Granite 4.1 3B 펠리컨 갤러리 — 양자화 21종이 똑같이 망한 이유

Mon, 04 May 2026 00:00:00 +0900

개요

Simon Willison이 IBM Granite 4.1 3B 양자화 21종(1.2GB ~ 6.34GB, 합계 51.3GB)에 자기 시그니처 프롬프트인 “Generate an SVG of a pelican riding a bicycle"를 던졌다. 결론은 한 줄: “There’s no distinguishable pattern relating quality to size — they’re all pretty terrible!”. 이번 글은 그 갤러리를 출발점으로, 비공식 벤치마크가 공식 점수판이 못 잡는 무엇을 잡아내는지, 그리고 양자화-품질 곡선을 측정하려면 어디서부터 봐야 하는지를 정리한다.

flowchart LR
 P["프롬프트 <br/> pelican on a bicycle"] --> Q["Granite 4.1 3B <br/> 21 quant variants"]
 Q --> S1["1.2GB ~ 6.34GB"]
 S1 --> O["SVG 출력 21장"]
 O --> J["Simon의 눈 판정"]
 J --> R["크기-품질 상관 없음 <br/> 전부 추상 도형"]

“SVG 펠리컨” 이 뭐길래

Simon Willison의 pelican-riding-a-bicycle 시리즈는 새 LLM이 나올 때마다 그가 고정으로 돌리는 비공식 평가다. 프롬프트는 단 한 줄.

“Generate an SVG of a pelican riding a bicycle.”

SVG는 텍스트 모델이 좌표·path·viewBox를 직접 출력해야 하는 양식이라 시각적 사고를 강제한다. 더 중요한 건 결과가 즉시 그림으로 렌더링 되어 모델 간 비교가 직관적이라는 점이다. LMArena 의 익명 페어 비교나 MMLU 의 객관식 점수에는 잡히지 않는 실패 모드 — 비례, 선의 연속성, 부품 배치 — 가 한 장의 SVG에서 드러난다.

이번 실험

항목	내용
대상	IBM Granite 4.1 3B Instruct
변형	양자화 21종 (1.2GB ~ 6.34GB, 합 51.3GB)
프롬프트	“Generate an SVG of a pelican riding a bicycle”
출력	SVG 21장, 한 페이지 갤러리
판정자	Simon Willison 본인 (눈)

원본 갤러리 글에 21장이 그대로 펼쳐져 있다.

결과 — Simon의 평가

“There’s no distinguishable pattern relating quality to size — they’re all pretty terrible!”

모델 크기와 품질 사이에 구별 가능한 패턴이 없다. 1.2GB와 6.34GB가 사실상 같은 줄에 선다.
21장 모두 추상 도형 덩어리. 펠리컨도, 자전거도 명확히 식별되지 않는다.
흥미롭게도 가장 작은 모델이 자전거를 가장 잘 표현했고, 가장 큰 모델이 펠리컨에 가까운 형태를 그렸다 — 크기-품질 관계가 단조 증가가 아닐 수 있다는 작은 단서.
Simon 본인은 “기대보다 덜 흥미롭다”, “더 잘 그리는 모델로 다시 해보겠다"고 마무리.

의미 — 무엇을 측정한 것인가

1. 양자화 곡선은 본판 capability ceiling에 막힌다

5배 메모리 차이(1.2GB → 6.34GB)에도 출력 품질에 의미 있는 차이가 없었다. 그러나 결론은 “양자화가 무해하다” 가 아니다. “이 모델 자체가 SVG 펠리컨에서 약하다” 가 더 정확한 해석이다.

양자화 영향을 깔끔하게 측정하려면 본판이 그 과제에서 충분히 강해야 한다. 본판이 이미 floor 근처면 AutoRound·GGUF·AWQ 어떤 방식으로 누르든 변별이 안 나온다. 즉 양자화 벤치를 설계할 때는 모델의 capability ceiling을 먼저 확인 해야 한다는 교훈.

2. 비공식 벤치마크가 공식 점수판을 보완한다

LMArena 의 페어 비교나 MMLU 같은 표준 벤치는 텍스트 토큰의 정답률·선호도를 잡는다. 하지만 “이 모델이 좌표 평면에 부품을 배치할 줄 아는가” 같은 질문은 잘 안 잡힌다. SVG 펠리컨은 그 갭에 정확히 들어간다 — 공식 벤치엔 없지만 모두가 동의하는 빠른 sanity check.

3. Granite 패밀리에 대한 시사

IBM Granite / watsonx Granite 라인업은 엔터프라이즈 RAG·도구 호출·코드 작업을 타깃으로 잡혀 있다. 그 좌표계에서 보면 SVG 펠리컨은 분포 밖 과제라 약한 게 어쩌면 당연하다. 다만 같은 시기 풀린 Google Gemma + LiteRT MTP 같은 모바일 친화 small model 흐름과 나란히 두면, 3B 클래스 small open model의 실용성은 모델 패밀리/제조사가 어디에 capability를 몰아넣었는지에 따라 크게 갈린다.

인사이트

비공식 벤치마크가 살아남는 이유는 점수판이 못 잡는 결함을 한 장의 그림으로 보여주기 때문이다. SVG 펠리컨은 MMLU·LMArena 의 보완재이지 대체재가 아니다 — 둘이 같이 있어야 모델의 강점·약점이 드러난다. 양자화-품질 곡선은 본판 capability에 강하게 의존하므로, 양자화 벤치를 설계할 때는 본판이 그 과제에서 충분히 위에 있는지를 먼저 본다. AutoRound 같은 방식으로 압축률을 더 짜내도 floor 근처 모델에서는 변별이 안 난다. 21장 갤러리에서 가장 작은 모델이 자전거를 가장 잘 그렸다는 디테일은 단조 관계 가정 자체를 의심하게 만든다 — 양자화 비교는 단일 점수가 아니라 분포로 봐야 한다는 뜻. IBM Granite가 엔터프라이즈 좌표계를 정조준하는 동안 시각적 추론 같은 분포 밖 과제가 약한 건 당연한 결과이고, 그래서 small open model을 고를 때는 “어느 패밀리가 어디에 capability를 몰아넣었나"를 봐야 한다. Simon 같은 외부 관찰자가 21종을 한 페이지에 깔아주는 건 결국 모두를 위한 빠른 모델 카드 역할 — 공식 벤치 결과가 풀리기 전에 한 장으로 감을 잡게 해준다.

참고

Original gallery post

IBM Granite

Related benchmark refs