좋은 모델이 아니라 좋은 하네스가 성과를 만든다 — 하네스 엔지니어링과 실록 구조 매핑

Sillok · 하네스 엔지니어링 백서

기반 모델(foundation model)은 점점 강해집니다. 그런데 조직의 실제 성과는 모델의 지능만으로 결정되지 않습니다. 무엇을 언제 불러오고, 어떤 절차와 품질 기준을 적용하고, 실패를 어떻게 기록해 다음에 반영하고, 어디까지 자동화하고 어디서 사람이 승인할지 — 이 결정을 하는 주변 장치가 성과를 가릅니다. Lilian Weng은 그 장치를 하네스(harness)라 부릅니다. 이 글은 그 하네스론을 실측 잣대로 삼아, 한국형 대규모언어모델 운영 하네스 실록(Sillok)의 구조를 한 칸씩 매핑하고, 무엇이 유용하며 무엇이 아직 부족한지를 정직하게 결산하는 백서입니다.

“AI 도구를 몇 개나 쓰세요?”는 자주 틀린 질문입니다. 도구를 아무리 모아도, 언제 무엇을 꺼내 어떤 지식으로 채우고 어떻게 검증하는지가 없으면 매번 처음부터 다시 시작합니다. 사용자는 “시장 분석을 해줘”, “회의록에서 작업을 만들어줘”, “이 문서를 경영진 백서로 바꿔줘”라고 말합니다. 모델은 문장을 만들 수 있지만, 조직은 그보다 많은 것을 요구합니다 — 최신성과 권위가 확인된 지식, 업무별 절차와 산출물 계약, 권한과 승인, 장기 작업을 이어갈 상태, 결과가 좋았는지 판단할 평가, 실패를 보존해 재발을 줄이는 루프. 프롬프트 하나가 이 모든 책임을 지면 곧 길어지고 충돌하며 관측 불가능해집니다.

이 백서는 두 개의 저장소 문서를 압축한 것입니다. 하나는 Weng의 하네스론을 잣대로 실록의 기능 적합도를 실측한 비교 테스트 리포트이고, 다른 하나는 실록을 “프롬프트 모음”이 아니라 “운영 가능한 시스템”으로 서술한 엔지니어링 백서입니다.

두 문서 모두 2026-07-13에 같은 저장소에서 healthcheck·drift·linkage·router self-check·pytest를 실제로 돌린 관측을 근거로 씁니다. 이 글도 그 규율을 그대로 물려받아 — 관측한 값과 목표(KPI)를, 측정과 추론을 구분해 적었습니다.

01 · Harness하네스란 무엇인가 — 모델과 현실 사이의 계층

Weng은 하네스를 기반 모델과 실제 환경 사이에서 사고·계획, 도구 호출, 행동, 맥락 관리, 산출물 저장, 결과 평가를 조율하는 시스템으로 정의합니다. 초기의 “대규모언어모델(LLM) + 기억 + 도구 + 계획”보다 넓게 — 워크플로우 설계, 권한 통제, 평가, 지속 상태 관리까지 포함하는 런타임 관점입니다. 그리고 세 가지 기본 설계 패턴을 제시합니다.

이어 Weng은 최적화의 대상이 시간이 지날수록 더 높은 추상 계층으로 이동한다고 설명합니다. 프롬프트 문구를 다듬는 데서 시작해, 맥락 구조 → 워크플로우 → 하네스 코드 → 옵티마이저 코드 자체로 올라갑니다. “무엇을 고칠 것인가”의 사다리입니다.

Weng의 최적화 대상 진화 — 아래에서 위로 올라갈수록 손대는 계층이 높아진다. 출처: Weng, Harness Engineering for Self-Improvement (2026-07-04)

마지막으로 Weng이 강하게 경고하는 안전 경계가 있습니다. 자기개선하는 하네스일수록 지켜야 하는 원칙들입니다 — 평가기와 권한 통제는 자기수정 루프 밖에 두어야 하고, 빠르고 객관적인 평가기가 없는 과제는 자기개선이 어렵고, 실패·음성 결과를 보존해야 탐색 공간이 줄어듭니다.

또 진화 루프는 다양성 붕괴와 보상 해킹(reward hacking) 위험을 안고, 단기 점수는 유지보수성·소유권·미래 디버깅 비용을 반영하지 못하며, 사람은 제거 대상이 아니라 중요한 결정 지점에서 더 높은 추상도로 개입해야 합니다. 이 경계선들이 뒤에서 실록을 평가하는 잣대가 됩니다.

02 · Map다섯 가지 설계 패턴 — 실록은 어디에 해당하는가

실록의 정본 설명은 한 줄로 요약됩니다 — “의도 분류 → 팩 선택·합성 → 실행 보조 → 텔레메트리 → 제안 → 관리된 승격”. 이 루프를 다섯 개의 설계 패턴으로 펼치면, Weng의 하네스 패턴이 어디에 대응하는지가 보입니다.

제어면과 지식면의 분리 — 실록 구조의 뼈대

실록 P3의 지식·제어 분리는 실록 아키텍처의 뼈대입니다. 제어면은 “무엇을 적용할지”를 결정하고, 지식면은 “무엇을 아는지”를 댑니다. 두 면은 실행 계약에서 만나 호스트 에이전트로 흘러가고, 그 산출물과 추적이 다시 두 면으로 환류됩니다.

실록 P3 — 제어면/지식면 분리 구조. 프롬프트 비대화를 줄이고 정책 변경과 지식 추가의 위험도를 분리 관리한다.

Weng의 세 패턴 ↔ 실록 — 무엇이 같고 무엇이 다른가

같은 점은 철학이고, 다른 점은 실행 주체입니다. Weng의 하네스는 코딩·리서치 에이전트 런타임 그 자체를 다루지만, 실록은 Claude·Codex 같은 호스트 런타임 위에서 도는 제어면입니다. 도구 실행·서브 에이전트 프로세스 관리·샌드박스는 호스트의 책임을 재사용합니다.

03 · Context프롬프트에서 맥락 공학으로 — 레지스트리는 컨텍스트 컴파일러다

초기 프롬프트 시스템은 질문 앞에 좋은 지시문을 붙이는 데 집중했습니다. 하지만 팩이 늘어나면 최적화의 대상이 이동합니다. 레지스트리(registry)는 그래서 “프롬프트 목록”이 아니라 컨텍스트 컴파일러의 정본입니다 — 팩 ID와 파일 경로만이 아니라 트리거 신호, 범주, 호환성, 가시성, 품질 메타데이터, 평가 커버리지를 묶어 라우터가 어떤 맥락을 조립할지 결정합니다.

다만 양이 곧 활용도는 아닙니다. 좋은 검색증강생성(RAG · Retrieval-Augmented Generation)은 “모든 것을 기억”하는 방식이 아니라, 가장 결정적인 기록에서 가장 추론적인 기록으로 내려가며 근거를 선택하는 순서입니다.

실록의 검색 우선(retrieval-first) 순서 — 긴 문맥을 많이 넣는 대신 필요한 근거를 선택하고 출처와 처분(disposition)을 남긴다.

04 · Eval평가 없는 자기개선은 자기확신이다 — 2026-07-13 스냅샷

그리고 같은 날, 이 센서망을 실제로 돌렸습니다. 가장 중요한 발견은 “운영 정상”과 “회귀 정상”이 같은 말이 아니라는 것입니다.

healthcheck는 프로세스의 존재·신선도·핵심 probe에 강하고, pytest는 세부 계약 위반에 강합니다. 지금은 두 판정이 따로 놉니다. 다음 과제는 기능 추가가 아니라 이 두 판정을 하나의 릴리스 결정으로 수렴시키는 것입니다.

증거 등급 — 주장보다 “어디서 왔는가”

실록은 주장 자체보다 주장이 어디서 왔는지를 중요하게 다룹니다. 이 구분이 자기개선 루프가 “계획된 기능”을 “검증된 효과”로 오해하지 않게 막습니다. 이 백서의 모든 수치에도 같은 등급이 붙어 있습니다.

05 · Loop두 개의 학습 루프 — GEPA와 SORL, 그리고 제안-전용 경계

실록의 이중 학습 루프. GEPA = 유전-파레토 반성적 프롬프트 진화(Genetic-Pareto reflective prompt evolution) · SORL = 산출물 보상 루프(Sillok Outcome Reward Loop). 2026-07-13 기준 SORL은 2,612개 에피소드를 축적(관측 A).

여기서 제안-전용(proposal-only) 경계는 속도 저하가 아니라 추상화 경계입니다. 자기개선 시스템이 자신의 평가기·권한·정본을 동시에 수정하면 보상 해킹과 회귀를 막기 어렵습니다.

실록은 개선 후보를 세 가지 성질의 경계 밖으로 밀어냅니다 — ① 모델은 약점을 발견하고 변경안을 제안할 수 있고, ② 평가기와 보호 정책은 제안 루프 밖에서 심사하며, ③ 거절된 후보도 실패 이유와 함께 남아 다음 탐색을 제한합니다. Weng이 “평가기와 권한 통제는 진화 루프 밖에 있어야 한다”고 경고한 지점과 정확히 정합합니다.

다음 단계 — held-in과 held-out을 공통 수용 계약으로

현재 평가 자산은 풍부하지만 여러 스크립트와 운영 경로에 분산돼 있습니다. 다음 구조는 수용 기준을 네 개의 게이트로 단순화합니다. 후보 변경은 네 게이트를 모두 통과하고 사람이 승인할 때만 승격됩니다.

held-in은 목표 약점 해결, held-out은 미지 회귀 방지 — 이 둘을 함께 요구하는 것이 “안전한 자기개선”의 최소 계약이다.

06 · OS운영체제로서의 하네스 — 그러나 독립 OS는 아니다

07 · Field현업에서의 유용성 — 여섯 고객 도메인이 학습장이다

Weng 프레임 적합도 — 11개 축, 45/55

비교 리포트는 Weng의 요구를 11개 기능 축으로 나눠 실록의 구조적 성숙도를 3/5~5/5 정성 루브릭으로 평가했습니다. 이 수치는 동일 제품 성능 비교가 아니라 기능 축의 성숙도 평가입니다.

11축 정성 적합도 = 45/55(약 82%). 강한 축은 기억·권한·HITL(전부 5/5), 개선 우선 축은 병렬 작업·음성 결과 보존(각 3/5). 출처: 비교 테스트 리포트 §4.1.

현업에서 확인된 실록의 역할은 다섯 가지로 수렴합니다 — 고객 언어를 실행 맥락으로 조립하는 맥락 컴파일러, 회의→분석→계획→보고 흐름을 유지하는 딜리버리 백본, 참가자의 사고 순서를 구조화하는 코칭 스캐폴드, 품질·인용·평가를 강제하는 품질 거버너, 그리고 현장 결과를 다음 고객의 재사용 자산으로 회수하는 학습 플라이휠. 2026년 상반기 강의·프로젝트 자산을 재정리한 작업에서는 46개 자산 원장과 154/154 골든 회귀 통과가 기록됐습니다.

08 · Honest정직한 하네스 — 살아 있음과 회귀 없음은 다른 질문이다

그래서 실록의 다음 도약은 규칙을 더 추가하는 데 있지 않습니다. 평가 판정을 통합하고, held-out 비회귀를 승격의 공통 조건으로 만들고, 실록이 실제 산출물에 주는 효과를 통제 실험으로 증명하는 데 있습니다. 특히 아직 없는 것은 동일 모델·동일 과제에서 실록 on/off의 산출물 품질을 비교한 눈가림(blinded) A/B입니다. 최소 30개 과제를 도메인별로 나누고 정확성·근거성·실행가능성·비용·지연을 함께 측정해야 합니다.

신뢰할 수 있는 자기개선 제어면으로 가는 로드맵. Phase 0~1이 “판정 일관성”, Phase 2가 “효과 증명”의 최소 관문이다.

Action이번 주 시작할 수 있는 다섯 가지

하네스는 거창한 인프라가 아니라 습관의 상설화에서 시작합니다. 실록을 그대로 복제하지 않아도, 오늘 다섯 가지를 시작할 수 있습니다.

Bridge이어서 읽으면 좋은 글