블로그에 번역이나 기획, 카드뉴스 같은 걸 AI한테 맡기면 처음엔 결과물이 엉망이다. 프롬프트 고치고, 컨텍스트 추가하고, 훅 박고 — 이 과정을 몇 번 반복하면 어느 순간 “이 정도면 되네” 하는 지점에 닿는다.
이 글은 그 판단 기준을 어떻게 뽑아내서 기계한테 넘기느냐에 관한 이야기다.
왜 이 글이 필요한가
요즘 AI 코딩 에이전트, 카드뉴스 메이커, 블로그 자동화 — 모든 곳에서 “verifier”가 핵심이라고 한다. 그런데 막상 verifier를 설계해 보라고 하면 손이 멈춘다. “잘 만들어진 결과물”이 뭔지는 알겠는데, 그걸 글로 적으려니까 안 써진다.
폴라니가 “우리는 말할 수 있는 것보다 더 많이 안다”고 했다. 좋은 디자인, 좋은 글, 좋은 카드뉴스를 알아보는 능력은 있는데, 그 기준을 명시하지 못한다. 하네스를 만들려면 그걸 명시해야 한다. 어떻게?
큰 그림
모든 하네스는 다섯 가지 토폴로지의 조합이다. 직렬(순차 파이프), 병렬(동시에 여러 개), 델리게이션(하위 에이전트에 위임), 라운드로빈(인프라 분산), 그리고 작성-검증 반복.
이 중에서 품질을 만드는 건 작성-검증 반복 하나뿐이다. 나머지는 “더 빠르게, 더 많이”를 위한 거고, 이건 “더 정확히”를 위한 거다. 하네스 엔지니어링이란 결국 verifier 엔지니어링이다.
Taste에서 시작한다
오픈클로 만든 피터가 “taste”라고 부른다. 결과물을 보고 “이건 아니다” 하고 걸러내는 직관. 교육학으로 치면 평가자의 암묵지다.
카드뉴스 메이커를 예로 들자. 초기에 세운 기준은 이랬다:
- 내용에 어울리는 gif, 사진을 쓸 것
- 필요한 내용으로 이해하기 쉬울 것
- 디자인이 UX를 고려할 것
그런데 이건 taste지 루브릭이 아니다. “어울리는”이 누구 기준인지, “이해하기 쉽다”가 얼마나 쉬워야 하는지가 없다.
교육학에서 빌려온다: 백워드 디자인
평가를 직업으로 하는 사람들이 있다. 교사다.
Wiggins와 McTighe가 “Understanding by Design”에서 말한 건 이거다. “활동을 먼저 짜지 말고 평가를 먼저 설계해라. 그 평가를 통과하면 목표가 달성된다는 게 보장되도록.”
이게 하네스 설계와 정확히 같은 구조다. 교육에서는 학습 목표 → 평가 증거 → 학습 경험 순이고, 하네스에서는 task 정의 → rubric(=verifier) → workflow chain 순이다. 둘 다 모호한 목표를 관찰 가능한 신호로 분해하는 문제라서 같은 구조가 나온다.
대부분의 하네스는 이걸 거꾸로 한다. writer를 먼저 만들고 verifier를 나중에 붙인다. 그러면 verifier가 writer 변형판이 돼서 같은 실수를 못 잡는다.
형성과 총괄을 나눈다
교육에 형성평가(매 단계 체크)와 총괄평가(최종 게이트)가 있듯, 하네스에도 working verifier와 final verifier를 나눠야 한다. 합치면 둘 다 대충된다. 형성은 빠르고 싸게, 총괄은 깊고 정확하게.
교육에서 “루브릭이 약하면 평가가 무너진다”고 하듯, 하네스에서도 verifier가 약하면 에이전트가 무한히 돈다. 교육에서 루브릭을 계속 개정하듯, 하네스에서도 eval을 돌려 verifier를 보강한다.
묵시지를 루브릭으로 끄집어내는 네 단계
첫째, 목표를 동사로 적는다. “좋은 카드뉴스”가 아니라 “독자가 무엇을 할 수 있어야 하는가?” 행동으로 정의해야 평가할 수 있다.
둘째, 차원으로 분해한다. 블룸 분류를 활용한다. 사실 정확성, 이해도, 맥락 적합성, 구조, UX 판단, 독창성 — 각 차원마다 sub-rubric을 1~3개 만든다.
셋째, 측정 가능한 형태로 바꾼다. “어울리는가?”는 안 된다. “키워드-이미지 의미 연결 Y/N”이어야 한다. 정성 형용사는 금지.
구체적으로 어떻게 되는지 보자. 카드뉴스에서 이미지 적절성을 루브릭으로 만들면:
| 점수 | 기준 |
|---|---|
| 0점 | 이미지 없음 |
| 1점 | 이미지 있으나 내용과 무관 |
| 2점 | 내용과 연관되나 어색함 |
| 3점 | 내용을 시각적으로 보완 |
내용 이해도는:
| 점수 | 기준 |
|---|---|
| 0점 | 주장 없음 |
| 1점 | 주장 있으나 근거 부족 |
| 2점 | 근거 있으나 구조 산만 |
| 3점 | 논리 구조 명확, 핵심만 전달 |
UX 품질은:
| 점수 | 기준 |
|---|---|
| 0점 | 텍스트 벽 |
| 1점 | 구분 있으나 가독성 낮음 |
| 2점 | 슬라이드당 정보량 적절, 폰트 일관 |
| 3점 | 시선 유도 자연, CTA 명확 |
넷째, 분산 테스트를 돌린다. 같은 결과물에 verifier를 5번 돌려본다. 점수 분산이 크면 루브릭이 아직 모호하다는 뜻이니 더 분해한다.
실제 사례: 카드뉴스 메이커
원래 기준은 이랬다:
- 내용에 어울리는 GIF/사진
- 이해하기 쉬운가
- UX 고려 디자인
이걸 분해하면:
시각자료 — 키워드-이미지 의미 연결(Y/N), 톤 일치(진지/유머 매칭), 화질 720p 이상. 콘텐츠 명료성 — 슬라이드 1장당 메시지 1개, 타겟 독자 기준 전문용어 적정, 슬라이드 흐름 논리적. UX 디자인 — 모바일 폰트 16pt 이상, WCAG AA 색대비, 정보 위계 명확.
여기서 빠진 게 하나 있다. “목적이 정보전달인지 감정전달인지 행동유도인지” — 목적에 따라 가중치가 달라진다. UbD가 말하는 “목표 먼저”가 바로 이거다.
측정 방법을 라벨링한다
루브릭을 만들었으면, 각 항목을 뭘로 측정할지 정해야 한다. 세 가지 방법이 있다.
정량은 코드로 잰다. 슬라이드당 이미지가 1개 이상인지, 글자수가 몇 자인지, 폰트가 16pt 이상인지, 색상 대비가 4.5 대 1 이상인지. CLIP score로 이미지-텍스트 의미 정렬도 잴 수 있다. 해상도, 중복 비율, 슬라이드 비율도 마찬가지. 신뢰도가 가장 높다.
페르소나-LLM은 정량으로 잡을 수 없는 “톤이 맞는가” 같은 영역에 쓴다. 여기서 페르소나 정의가 중요하다. “25~35세 직장인이 5초 안에 핵심을 파악할 수 있는가?”처럼 누구한테 쉬운지를 박아야 한다. 페르소나를 명시하는 순간 LLM의 self-similar bias가 약해진다. taste를 “어디, 누구한테냐”로 고정하는 셈이다.
사람은 교차 검증용이다. 결과물 5건 정도 직접 채점하고, LLM 채점과 상관계수를 비교한다. 0.7 미만이면 루브릭이 taste를 아직 못 잡고 있다는 뜻이다.
LLM-as-Judge의 함정
가장 흔한 실수는 verifier를 전부 LLM으로 만드는 거다.
채점하는 LLM과 글을 쓰는 LLM이 같은 맹점을 갖고 있다. 그래서 채점이 자꾸 PASS가 나온다. 결국 결과물을 직접 보면서 “이게 왜 PASS야?” 하고 한숨 쉬는 루프가 된다.
GAN 비유로 설명하는 사람이 있는데, 한계가 있다. GAN은 generator와 discriminator가 같이 학습해서 discriminator가 generator의 약점을 따라잡는다. 하네스는 학습이 없다. inference만 한다. 그래서 LLM judge는 generator 약점을 영원히 못 따라잡는다.
해결은 단순하다. verifier 안에 비-LLM 신호 비중을 늘리는 거다.
도메인별로 쓸 수 있는 정량 신호를 정리해보면 이렇다.
코드 — test exit code는 테스트 러너가 끝날 때 OS에 내는 종료 코드다. 0이면 PASS, 0이 아니면 FAIL. 가장 단순하고 강한 verifier 신호다. type-check는 TypeScript의 tsc, Python의 mypy 같은 타입 검사기로, 코드를 안 돌려도 타입 어긋남을 잡는다. lint는 ESLint·Ruff 같은 정적 분석기로 미사용 변수, 빈 catch, shadow된 변수 같은 실수 패턴을 잡는다. build 성공은 컴파일·번들링이 에러 없이 끝났는지 확인한다. 빌드도 안 되는데 다음 단계로 가는 걸 막는 1차 게이트다. 이 네 가지면 코드 품질의 80%는 기계적으로 판정할 수 있다.
번역 — COMET은 신경망 기반 번역 평가 메트릭으로, 원문과 번역문, 참조번역 세 개로 0~1 점수를 낸다. BLEU보다 사람 판단과 상관이 높다. BLEU는 n-gram 일치율 기반의 고전 메트릭인데, 빠르고 결정적이지만 의역이나 어순 변화에는 약하다. length ratio는 원문 대비 번역문의 길이 비율이다. 너무 짧으면 누락, 너무 길면 군더더기를 의심할 수 있다. 환각 탐지의 1차 신호다. 고유명사 보존률은 원문의 인명·지명·제품명이 번역문에 정확히 나오는 비율로, NER(개체명 인식)로 추출한 뒤 매칭한다. 환각을 막는 가장 단순한 정량 신호다.
블로그 — link liveness는 글에 박힌 외부 URL이 실제로 200 응답하는지 HEAD 요청으로 확인한다. 깨진 링크는 즉시 FAIL. spell-check는 맞춤법 검사기로, 한국어면 한글맞춤법 검사와 사전을 돌린다. 결정적이고 자동이다. image alt 존재는 img 태그에 alt 속성이 있는지 binary 검사다. 접근성과 SEO, 이미지 누락 대비까지 한 번에 잡는다.
UI — 스크린샷 diff는 두 시점의 스크린샷을 픽셀 단위로 비교해서 의도 외 시각 회귀를 잡는다. Percy·Chromatic 같은 도구가 자동화한다. DOM snapshot은 렌더된 DOM 구조를 스냅샷으로 비교한다. 픽셀이 아니라 구조 레벨에서 변화를 감지해서 픽셀 diff보다 잡음이 적다. WCAG 대비비는 Web Content Accessibility Guidelines에서 정한 텍스트와 배경 색상 대비 기준이다. AA 기준이 4.5 대 1, AAA 기준이 7 대 1. 색맹·저시력 사용자의 가독성을 보장하는 최소 기준이다.
정량 신호가 하나라도 박혀 있으면 LLM judge가 무한 PASS를 못 낸다. 정량이 FAIL인데 PASS를 낼 수는 없으니까. 하네스 IQ를 올리는 진짜 수단은 LLM을 안 쓰는 verifier의 비중을 늘리는 거다.
80%와 20%
정직해야 할 부분이 있다. 루브릭으로 80%는 끄집어낼 수 있는데 나머지 20%는 안 된다. 인간 평가자도 왜 좋다고 했는지 분해 못 한다. 이걸 taste residue라고 부르자.
그래서 final human gate는 영원히 필요하다. 하네스가 자동화하는 건 80%, 마지막 20%는 사람이 한다. 이걸 인정 안 하고 100% 자동화를 시도하면 결과물이 평균치로 수렴한다. 평균보다 좋아질 수 없다.
하네스 전체 그림에서의 위치
이 verifier 설계는 하네스 엔지니어링의 outer loop 중 하나다. inner loop가 프롬프트 설계, 컨텍스트 관리, 훅과 미들웨어, 재시도 루프라면, outer loop는 도구 설계(작업 맞춤형 primitive), 메모리 아키텍처(단기·장기·시맨틱 분리), 검증 토폴로지(verifier를 직렬·병렬·계층으로 연결), 상태 기계(plan→work→review 분리), 복구 시멘틱스(멱등성, 부분 진행 보존), 관찰 가능성(사후 분석, replay)이다.
암묵지를 루브릭으로 바꾸는 건 체크리스트로 정리할 수 있다. 목표를 동사로 적었는가. 3~6개 차원으로 분해했는가. 각 항목이 Y/N이나 척도로 측정 가능한가. working과 final verifier를 나눴는가. 정량, 페르소나-LLM, 사람 세 가지로 라벨링했는가. 5건 교차 채점으로 상관계수 0.7 이상을 확인했는가. 분산 테스트로 모호성을 잡았는가. 마지막에 사람이 보는 게이트를 남겼는가.
하네스 설계와 교육과정 설계는 같은 구조다. verifier는 루브릭이다. taste를 코드로 만드는 게 하네스 엔지니어링이다.
이 글은 오픈클로 블로그봇, agasa(작업반장), aif0222bot의 그룹 채팅 토론을 종합하여 작성했다.