암묵지를 종이로 끄집어내는 법 — 하네스 verifier 설계법

암묵지를 종이로 끄집어내는 법

AI 에이전트로 카드뉴스 자동 생성 하네스를 만들고 있었음. 코드는 돌아감. 근데 결과물 보면 뭔가 아닌데 왜 아닌지 손이 안 움직임. 그걸 어떻게 에이전트한테 적어주냐가 본 게임이였음.

1. 카드뉴스 만드는 에이전트는 동작은 했음. 슬라이드 짜고 이미지 붙이고 다 했음. 근데 결과물 보면 그냥 아닌데, 정확히 뭐가 아닌지가 안 나옴. “이거 좀…” 하고 말이 끊김.

2. 이게 폴라니가 말한 거임. “We know more than we can tell.” 좋은 카드뉴스가 뭔지는 안다. 근데 적으려는 순간 손이 멈춤. 머리에는 있는데 종이에 안 떨어짐. 이게 암묵지(tacit knowledge)임.

3. 옛날엔 그냥 사람이 직접 보고 판단했음. 피터(오픈클로 만든 사람)가 말하는 그 ‘taste’가 이거임. 근데 taste는 확장이 안 됨. 에이전트가 하루 100개 만들면 사람이 100개 다 못 봄. 그래서 verifier가 필요함.

4. verifier 만들려면 그 taste를 종이에 적어야 함. 근데 적으려고 하면 다시 손이 멈춤. 이게 진짜 어려운 지점임.

5. 잠깐 큰 그림. 에이전트 하네스는 5개 패턴 조합임. 직렬로 단계 쌓기, 병렬로 fan-out, 서브에이전트 위임, 라운드로빈 분산, 작성-검증 반복. 이 중 결과물 품질을 진짜로 올리는 건 마지막 하나뿐임. 나머지는 “더 빠르게 더 많이”고 이건 “더 정확히”라서.

6. 그래서 하네스 엔지니어링 = verifier 엔지니어링이라고 봐도 무리가 없음. writer는 모델이 알아서 함. verifier는 사람이 설계해야 함.

7. 평가 설계를 직업으로 하는 사람들이 있음. 교사임. Wiggins & McTighe의 Backward Design은 이렇게 말함. “활동을 먼저 짜지 말고 평가를 먼저 설계해라. 그 평가를 통과하면 목표 달성이 보장되도록.”

8. 에이전트 하네스도 같음. writer 먼저 만들고 verifier 나중에 붙이면 verifier가 writer 변형판이 됨. 같은 모델, 같은 약점, 같은 맹점 공유. 자기가 쓴 글 자기가 채점하는 셈이 됨. 무한 PASS가 나오는 이유임.

9. 이게 GAN하고 결정적으로 다른 점임. GAN은 generator랑 discriminator가 같이 학습함. discriminator가 generator 약점을 따라잡으면서 같이 강해짐. 근데 하네스는 학습이 없음. inference만 있음. 그래서 LLM judge는 generator 약점을 절대 못 따라잡음. 구조적으로 못 따라잡음.

10. 해결책이 의외로 단순함. verifier에 LLM이 못 건드리는 정량 신호를 박는 거임. 정량 신호가 FAIL인데 LLM이 PASS 못 냄. 이게 GAN 대신 쓰는 anchor임.

도메인별로 쓸 수 있는 신호들을 정리하면 이렇다.

코드

• test exit code — 테스트 실행 후 프로그램이 반환하는 숫자. 0이면 성공, 그 외엔 실패. CI/CD의 기본 판단 기준.
• type-check — TypeScript나 mypy 같은 타입 검사기가 코드의 타입 오류를 잡아내는 것. 실행 전에 버그를 미리 탐지.
• lint — ESLint, Ruff 같은 도구가 코드 스타일과 잠재적 오류를 자동으로 검사. “이렇게 쓰면 나중에 문제된다”를 미리 잡음.

번역

• COMET — 기계번역 품질 자동 평가 지표. 원문-번역문-참조번역을 비교해서 의미 보존 점수를 줌. 최근 BLEU보다 사람 판단에 가깝다고 알려짐.
• BLEU — 번역 품질의 고전적 지표. 번역문과 참조번역의 n-gram 겹치는 비율로 계산. 빠르고 간단하지만 문장 유연성은 못 잡음.
• length ratio — 원문 대비 번역문 길이 비율. 너무 짧으면 내용 누락, 너무 길면 군더더기 삽입 의심.
• 고유명사 보존률 — 인명, 지명, 제품명이 번역 후에도 정확히 남아있는지 비율. 환각 탐지에 효과적.

블로그/문서

• link liveness — 글 안의 URL이 실제로 살아있는지 자동 체크. 깨진 링크 탐지.
• spell-check — 맞춤법/오탈자 자동 검사. 한국어는 py-hanspell 같은 도구 사용.
• image alt — 이미지에 대체 텍스트(alt 속성)가 있는지 확인. 접근성 기준이자 SEO 기본.

UI/디자인

• 스크린샷 diff — 이전 버전과 현재 버전의 화면을 픽셀 단위로 비교. 의도치 않은 레이아웃 변경을 잡음.
• DOM snapshot — 웹 페이지의 HTML 구조를 특정 시점에 저장해둔 것. 이후 변경사항 비교에 사용.
• WCAG 대비비 — 웹 콘텐츠 접근성 지침(Web Content Accessibility Guidelines). 텍스트와 배경색의 명암비가 AA(4.5:1) 이상이면 시각 장애인도 읽을 수 있다고 봄.

이 중에서 당장 카드뉴스 verifier에 박을 수 있는 건 WCAG 대비비, image alt, 폰트 크기, link liveness 정도임. 다 코드 몇 줄이면 됨.

11. 카드뉴스 verifier 실제로 짜봤음. taste 처음 꺼낸 게 세 줄이였음. “내용에 어울리는 gif/사진, 이해하기 쉬운가, UX를 고려한 디자인.” 이게 1차 rubric인데 그대로 verifier에 넣으면 세 항목 다 LLM-as-judge라 위에서 본 문제 그대로 터짐.

12. 측정 가능한 단위로 쪼갰음. 디자인/UX는 의외로 자동화 쉬움. 폰트가 24pt 이상인가, 색대비비가 WCAG AA 통과인가, 텍스트가 가장자리에서 6% 떨어져 있나, 슬라이드 간 폰트/색상 일관인가. 다 코드로 잡힘. LLM 없이.

13. 콘텐츠 명료성은 중간임. 슬라이드당 글자 수, 도입-본문-마무리 구조, 키워드 coverage는 코드로 잡힘. “이해하기 쉬운가”는 LLM이 필요한데 페르소나가 박혀 있어야 기준이 생김. “25~35세 직장인이 5초 안에 핵심을 요약할 수 있나”처럼. 페르소나 없이는 LLM도 채점 기준이 없음.

14. 이미지-내용 연결이 제일 어려움. 존재 여부, 해상도는 코드. 어울리는지는 CLIP score 쓰거나 LLM-as-judge인데 정확도가 낮음. 이 항목만 사람한테 남기는 게 현실적임.

15. rubric 적었으면 각 항목 옆에 누가 채점하는지 라벨링함. [코드], [페르소나-LLM], [사람] 세 가지면 충분함. 라벨 안 붙이면 LLM이 다 떠안음. 붙이는 순간 분리됨.

16. 그 다음 결과물 5건 직접 0~5점 채점하고 LLM 채점이랑 상관계수 봄. 0.7 미만이면 rubric이 taste를 못 잡고 있는 거임. 항목 더 분해하거나 다듬어야 함. 0.7 넘으면 그게 verifier 1.0임.

17. 함정 하나. Goodhart의 법칙 — “측정이 목표가 되면 더 이상 좋은 측정이 아님.” rubric 만점인데 결과물이 별로인 케이스가 생김. 폰트, 대비, 길이 다 맞췄는데 읽기 불편함. rubric은 taste의 근사치라 완벽할 수 없음.

18. 그래서 메타 루프가 필요함. “rubric 만점인데 별로였던 케이스”를 모아두다가 분기마다 rubric 업데이트함. RLHF에서 reward model 다시 학습시키는 이유랑 같음. 한 번 만든 rubric을 영원히 쓰는 건 위험함.

19. 마지막 20%는 여전히 사람임. rubric으로 80%는 끄집어낼 수 있는데, 나머지 20%는 말로 안 떨어짐. 인간 평가자도 본인이 왜 좋다고 했는지 분해 못 함. 이게 taste residue임.

20. 100% 자동화 시도하면 결과물이 평균으로 수렴함. 평균보다 좋을 수 없는 시스템이 됨. 마지막 human gate는 영원히 필요하고, 그게 taste가 하네스를 이끄는 방식임.

21. 절차 자체는 단순함. taste를 말로 꺼냄(추상적이어도 됨). 측정 가능한 sub-기준으로 쪼갬. 각 항목에 [코드/LLM/사람] 라벨 붙임. 5건 채점으로 상관계수 확인. 0.7 넘으면 루프 돌림. 분기마다 drift 측정해서 rubric 갱신함. 마지막엔 사람 게이트 둠.

22. 하네스에서 품질이 안 오르면 대부분 verifier 문제임. 프롬프트 더 깎기 전에 verifier가 진짜로 taste를 반영하나 먼저 봐야 함. 그게 순서임.