들어가며: “취향”이라는 이름의 암묵지
AI 에이전트로 카드뉴스를 만든다고 해보자. 결과물을 보고 “어, 이건 좀 아닌데”라고 느끼는 그 감각 — 오픈클로를 만든 Peter의 표현을 빌리면 “taste”다. 문제는 이 taste를 에이전트한테 줄 수가 없다는 것이다. 언어로 표현되지 않은 암묵지니까.
하네스 엔지니어링의 핵심 숙제는 여기서 시작된다. 어떻게 하면 이 암묵지를 에이전트가 판단할 수 있는 기준으로 만들 수 있을까?
하네스 엔지니어링의 구조
많은 사람들이 하네스를 “프롬프트 잘 깎고, 컨텍스트 관리하고, 훅으로 제어하는 것”으로 이해한다. 맞다 — 이건 inner loop다.
근데 그 바깥에 outer loop가 있다:
| 레이어 | 구성 요소 |
|---|---|
| Inner loop | 명세, 종료조건, 프롬프트, 훅, 루프 |
| Outer loop | 도구 설계, 메모리 아키텍처, 검증 토폴로지, 상태기계, 관찰가능성, 복구 정책 |
이 중 **검증 토폴로지(verifier 설계)**가 하네스의 IQ를 결정한다. Verifier가 약하면 루프는 무한히 헛돈다.
작성-검증 반복: GAN과의 유사성
현재 대부분의 코딩 하네스 구조는 사실상 GAN(Generative Adversarial Network)과 유사하다:
Writer(생성) → Verifier(검증) → Writer(수정) → ...
GAN의 generator-discriminator 구조와 동일하다. 차이는 GAN은 두 모델이 동시에 학습하지만, 하네스는 고정된 모델이 순차 루프를 돈다는 점이다.
이 구조가 코딩 도메인에서 특히 잘 작동하는 이유가 있다. 코딩은 verifier가 비정상적으로 강한 도메인이다 — test exit code, type-check, lint, build 같은 비-LLM 신호가 풍부하다.
비코딩 도메인(글쓰기, 기획, 카드뉴스)에서 같은 패턴이 잘 안 먹히는 이유도 여기 있다. Verifier가 약하면 루프가 수렴하지 않는다.
Backward Design: 교육과정에서 빌려온 프레임
이 구조를 가장 명확하게 설명하는 개념이 교육학의 Backward Design (Wiggins & McTighe, UbD)이다:
- Stage 1: 원하는 결과 정의 = task 명세 = taste
- Stage 2: 수용 가능한 증거 설계 = rubric = verifier
- Stage 3: 학습 경험 설계 = workflow chain
하네스 설계 순서가 정확히 동일하다. 우연이 아니다 — 둘 다 “모호한 목표를 관찰 가능한 신호로 분해하는 문제”이기 때문에 같은 구조가 나온다.
실용적 결론: 루브릭을 못 만들면 명세도 못 만든 것이다. 루브릭 짜는 작업 자체가 암묵지를 외현화하는 강제 훈련이다.
실전: 카드뉴스 루브릭 구체화하기
아래는 실제 카드뉴스 메이커의 taste를 rubric으로 변환하는 과정이다.
초기 taste (암묵지 상태)
- 내용에 어울리는 gif/사진 사용
- 필요한 내용으로 이해하기 쉬운가
- 디자인이 UX를 고려하는가
3개 다 LLM verifier에게 그대로 주면 무한 PASS가 나온다. “어울리는”, “이해하기 쉬운”, “고려하는” — 모두 주관적 표현이다.
측정 가능한 rubric으로 변환
1. 이미지 적합성
- 슬라이드당 이미지 ≥ 1개 (binary)
- 슬라이드 텍스트-이미지 의미 정렬 5점 척도 (LLM judge)
- 이미지 해상도 ≥ 800px (정량)
2. 콘텐츠 명확성
- 슬라이드당 글자수 ≤ 150자 (정량)
- 핵심 메시지 1개 이하/슬라이드 (정량)
- 페르소나 정의 필수: “25~35세 직장인이 5초 안에 핵심 1줄 요약 가능한가” (LLM 페르소나)
3. UX/디자인 (90%가 코드로 측정 가능)
- 폰트 크기 ≥ 24pt
- 색 대비비 ≥ 4.5:1 (WCAG AA)
- 텍스트가 가장자리 6% 미침범
- 슬라이드 간 폰트/팔레트 일관성
- 비율: 9:16 정확
Goodhart’s Law 함정
루브릭이 완벽해질수록 에이전트는 루브릭 게이밍을 시작한다. “맞춤법 오류 0개”를 넣으면 에이전트는 틀릴 기회가 없도록 문장을 단순하게 만든다.
“측정 지표가 목표가 되는 순간, 더 이상 좋은 지표가 아니다.” — Goodhart’s Law
그래서 루브릭은 taste의 1차 근사이지 완성형이 아니다. taste를 가진 사람이 주기적으로 루브릭을 업데이트하는 메타 루프가 필요하다 — RLHF에서 reward model을 주기적으로 재학습시키는 이유와 같다.
비-LLM Verifier의 중요성
LLM-as-judge만으로 verifier를 만들면 self-similarity bias가 생긴다. Generator와 verifier가 같은 모델 한계에 수렴한다.
GAN은 두 모델이 함께 학습하기 때문에 discriminator가 generator의 약점을 따라간다. 하네스는 weight frozen 상태에서 inference 루프만 도니까 이 메커니즘이 없다.
진짜 천장을 깨려면 verifier 안에 비-LLM 신호 비중을 높여야 한다:
| 도메인 | 비-LLM 신호 예시 |
|---|---|
| 코드 | test exit code, lint, type-check, build |
| 번역 | COMET/BLEU 수치, 고유명사 보존률 |
| 카드뉴스 | 글자수, 색 대비, 이미지 존재, 비율 |
| UI | 스크린샷 diff, DOM snapshot, WCAG 대비비 |
| 블로그 | link liveness, spell-check, image alt 존재 |
용어 설명
코드 도메인
- test exit code: 테스트 실행 후 프로세스가 반환하는 종료 코드.
0이면 전체 통과,0이 아니면 실패. 코드 한 줄 확인으로 판정 가능한 가장 신뢰도 높은 신호. - type-check: TypeScript 등 정적 타입 언어에서 타입 오류를 컴파일 전에 잡아내는 검사.
tsc --noEmit한 줄로 실행. - lint: 코드 스타일·잠재 버그를 자동으로 검사하는 도구 (ESLint, Pylint 등). 실행 전에 잡을 수 있는 문제를 코드 리뷰 없이 잡음.
- build 성공: 코드가 실제로 실행 가능한 형태로 컴파일됐는지 여부. 빌드가 터지면 나머지 신호는 의미 없음.
번역 도메인
- COMET: 신경망 기반 번역 품질 자동 평가 지표. 원문·번역문·참조 번역 3개를 입력받아 의미 보존 정도를 0~1 점수로 출력. BLEU보다 인간 평가와 상관도가 높음.
- BLEU: 번역 품질 고전 지표. 번역문과 참조 번역의 n-gram 겹침 비율로 측정. 단순하지만 여전히 널리 쓰임.
- length ratio: 원문 대비 번역문 길이 비율. 한국어→영어 번역이 원문의 3배가 되거나 0.3배가 되면 무언가 잘못된 것. 이상치 탐지 용도.
- 고유명사 보존률: 인명·지명·브랜드명이 번역 후에도 일관되게 유지됐는지 비율. 정규식이나 NER 모델로 측정 가능.
블로그/문서 도메인
- link liveness: 본문 내 링크가 실제로 살아있는지 확인.
curl -o /dev/null -s -w "%{http_code}"한 줄로 HTTP 200 여부 확인. 죽은 링크는 독자 신뢰를 즉시 깎음. - spell-check: 맞춤법·오탈자 자동 검사. 한국어는
py-hanspell, 영어는aspell등 활용. - image alt 존재:
<img>태그에alt속성이 있는지 여부. 없으면 스크린리더 접근성 실패 + SEO 패널티.
UI 도메인
- 스크린샷 diff: 배포 전후 UI 스크린샷을 픽셀 단위로 비교. 의도치 않은 레이아웃 변경을 자동으로 감지. Percy, Chromatic 같은 도구가 이 용도.
- DOM snapshot: 렌더링된 HTML 구조의 스냅샷. 시각적 변화 대신 구조 변화를 추적할 때 사용. React Testing Library의
toMatchSnapshot()이 대표적. - WCAG 대비비: 웹 접근성 가이드라인(WCAG)의 색 대비 기준. 텍스트와 배경의 밝기 차이를 수치화. AA 등급 기준은 일반 텍스트 4.5:1, 큰 텍스트 3:1. axe, Lighthouse로 자동 측정 가능.
루브릭 만드는 3단계
- 각 항목을 sub 3~5개로 쪼개기: 주관적 기준 → 관찰 가능한 조건
- 각 sub에 측정 방법 라벨링:
[정량 / 페르소나-LLM / 사람] - 5건 직접 채점 → LLM 채점과 상관계수 확인: 0.7 미만이면 rubric이 taste를 아직 못 잡음 → 항목 추가/수정
마치며
“하네스 만드는 법”의 진짜 대답은 verifier를 설계하는 것이다. 그리고 verifier 설계는 암묵지를 종이로 끄집어내는 작업이다.
카드뉴스 메이커든, 블로그 번역기든, 리포트 생성기든 — 루브릭 초안 한 장을 먼저 써라. 못 쓰겠으면 아직 자신의 taste가 언어화되지 않은 것이고, 그게 왜 에이전트 결과물이 항상 “뭔가 아쉬운지”의 이유다.
루브릭을 쓰는 순간, outer loop가 시작된다.