모델을 바꾸지 않고 하니스를 진화시키는 법
에이전트의 실제 성능은 모델만이 아니라 프롬프트·도구·상태·제어 흐름을 엮는 하니스가 함께 결정합니다. 모델을 동결한 채 하니스를 진화시키는 최근 설계 흐름을 법마디의 검증 계층 관점에서 해부합니다.
초록 최근 에이전트 연구는 성능 향상의 지렛대를 모델 가중치에서 런타임 하니스로 옮기고 있습니다. 하니스는 프롬프트를 구성하고 상태를 관리하며 도구를 호출하고 실행을 조율하는 층으로, 배포 환경에서 실무자가 실제로 손댈 수 있는 거의 유일한 변수입니다. 이 칼럼은 하니스를 편집 가능한 산출물로 문서화하려는 흐름, 하니스 자체를 탐색·진화시키는 흐름, 그리고 하니스를 조립 가능한 부품으로 재구성하려는 흐름을 나란히 놓고, 법률 AI에서 이 접근이 왜 검증 계층과 결합할 때만 안전한지를 따집니다.
법마디 OS의 대명제는 단순합니다. 답변 품질의 책임은 어떤 모델을 쓰느냐가 아니라 검증 자산과 fail-closed 검증 계층이 진다는 것입니다. 이 명제는 오랫동안 저희 내부의 설계 원칙이었지만, 최근 에이전트 연구가 같은 방향을 독립적으로 가리키고 있다는 점은 짚어둘 만합니다. 여러 연구가 공통적으로 지적하는 사실은, 배포된 시스템에서 실무자가 조정할 수 있는 대상은 대체로 모델 가중치가 아니라 그 주변을 감싸는 실행 구조라는 점입니다. 프롬프트가 어떻게 조립되는지, 어떤 근거가 어느 위치에 주입되는지, 도구 호출이 어떤 순서와 조건으로 이루어지는지, 실패했을 때 무엇을 되돌리는지가 모두 그 구조에 속합니다. 모델은 교체 가능한 부품이고, 그 부품을 어떻게 물리느냐가 시스템의 실제 능력을 규정한다는 관점입니다. 오늘은 이 실행 구조를 일급 설계 대상으로 승격시키려는 세 갈래의 시도를 살펴보고, 법률 도메인에서 그 시도가 어디까지 허용될 수 있는지를 정리합니다.
핵심 기술 개념
하니스(harness)
모델을 감싸 실제 과제를 수행하게 만드는 런타임 층입니다. 프롬프트 구성, 주입 지식, 상태·메모리 관리, 도구 호출, 제어 흐름, 실패 처리 정책이 모두 여기에 포함되며, 모델 가중치와 달리 배포 후에도 편집할 수 있습니다.
하니스 진화(harness evolution)
모델을 재학습하지 않고 하니스의 구성 요소를 후보로 놓고 반복적으로 변형·평가·선택해 개선하는 방식입니다. 학습이 아니라 탐색에 가까우며, 평가 신호의 품질이 결과를 좌우합니다.
게이트된 품질-다양성 탐색
성능 점수만 좇지 않고 후보들의 서로 다른 해법 특성을 함께 유지하되, 일정 기준을 통과하지 못한 후보는 탐색 대상에서 배제하는 방식입니다. 국소 최적에 갇히는 문제와 부적격 후보의 유입을 동시에 억제하려는 설계입니다.
기술 심층 분석
1. 성능의 지렛대는 왜 하니스로 옮겨왔는가
지난 몇 해 동안 성능 개선의 표준 경로는 더 큰 모델, 더 많은 데이터, 더 정교한 미세조정이었습니다. 그러나 실제 제품에서 그 경로는 대부분 닫혀 있습니다. 대다수 팀은 모델을 API 너머에서 호출할 뿐이고, 가중치에 손댈 권한도 비용도 없습니다. 반대로 프롬프트가 어떻게 조립되는지, 어떤 근거를 어느 순서로 주입하는지, 도구 호출이 실패했을 때 무엇을 재시도하고 무엇을 포기하는지는 전적으로 팀의 통제 아래 있습니다. 최근 하니스 연구들이 공통적으로 출발하는 관찰이 바로 이것입니다. 배포 환경에서 하니스는 종종 손댈 수 있는 유일한 레버이며, 같은 모델을 쓰고도 결과가 크게 갈리는 이유의 상당 부분이 이 층에 있다는 것입니다. 이 관찰은 법마디의 설계 전제와 정확히 겹칩니다. 저희가 모델 교체 가능성을 전제로 검증 계층을 두꺼운 쪽에 배치해 온 것도, 품질의 책임을 통제 불가능한 부품이 아니라 통제 가능한 구조에 지우기 위해서였습니다.
2. 하니스를 읽을 수 있게 만든다는 것
하니스가 성능을 좌우한다는 사실이 받아들여지면 곧바로 다음 문제가 따라옵니다. 하니스가 대개 읽기 어렵다는 것입니다. 프롬프트 조각, 조건 분기, 도구 래퍼, 예외 처리가 코드 여기저기에 흩어져 있고, 어느 문장이 어떤 동작을 유발하는지 추적하기 어렵습니다. 모델·API·환경·요구사항이 계속 바뀌는 상황에서 이 불투명성은 곧 유지보수 불가능성을 뜻합니다. Harness Handbook이 제기하는 문제의식이 이 지점입니다. 진화하는 하니스를 읽을 수 있고, 탐색할 수 있고, 편집할 수 있는 형태로 만들자는 것입니다. 이것은 성능 최적화라기보다 공학 위생에 가깝지만, 법률 도메인에서는 그 이상의 의미가 있습니다. 어떤 근거가 어떤 경로로 답변에 들어왔고 어느 게이트에서 걸러졌는지를 사후에 설명할 수 없다면, 그 시스템은 정확하더라도 신뢰 가능한 시스템이라고 부르기 어렵습니다. 저희가 인용 게이트의 판정 근거를 응답에 함께 실어 보내는 이유도 같습니다.
3. 하니스를 자동으로 진화시킬 때의 함정
다음 단계는 자연스럽게 자동화입니다. 하니스 구성 요소를 후보로 놓고 변형·평가·선택을 반복하면, 사람이 손으로 튜닝하는 것보다 넓은 공간을 탐색할 수 있습니다. Self-Evolving Agent Harnesses가 게이트된 품질-다양성 탐색을 제안하는 배경도 여기에 있습니다. 다만 이 접근에는 구조적 함정이 있습니다. 탐색은 평가 신호를 최대화하는 방향으로만 움직이므로, 평가 신호가 측정하지 못하는 속성은 조용히 희생된다는 점입니다. 응답의 표면적 완성도만 점수화하면 탐색은 근거 없이 매끄러운 문장을 만드는 방향으로 수렴할 수 있습니다. 법률 도메인에서 이는 치명적입니다. 인용이 실재하는지, 그 인용이 해당 쟁점을 실제로 뒷받침하는지는 문장의 매끄러움과 무관하며, 오히려 반대 방향으로 상충하기 쉽습니다. 따라서 자동 진화를 도입한다면 평가 함수 안에 검증 통과 여부가 가산점이 아니라 필수 관문으로 들어가 있어야 합니다.
4. 조립 가능한 하니스와 부품화의 경계
HarnessX 계열의 시도는 하니스를 손으로 만든 일회성 구조물이 아니라 조립 가능한 부품의 집합으로 다시 정의하려 합니다. 프롬프트, 도구, 메모리, 제어 흐름을 교체 가능한 모듈로 쪼개면 조합을 바꿔가며 실험할 수 있고, 환경이 바뀌었을 때 영향 범위를 좁힐 수 있습니다. 법마디의 프로바이더 추상화 계획도 같은 사고의 산물입니다. 모델 호출을 어댑터 경계 뒤로 숨기면 상위 코드는 특정 사업자의 인터페이스에 결합되지 않고, 부품 교체가 시스템 전체의 재작성을 요구하지 않게 됩니다. 다만 부품화에는 명확한 경계가 필요합니다. 교체 가능해야 하는 것은 생성기이고, 교체되어서는 안 되는 것은 검증입니다. 검증 계층까지 조합 실험의 대상이 되는 순간, 어떤 조합에서는 게이트가 느슨해지는 상태가 만들어지고 그 조합이 점수상 우수해 보일 수 있습니다. 부품화는 생성기 쪽에서만 자유로워야 합니다.
5. 법마디에 적용할 때의 순서
정리하면 하니스 중심 설계는 저희가 이미 서 있는 자리를 이론적으로 보강해 주지만, 도입 순서를 틀리면 위험을 키웁니다. 먼저 해야 할 일은 자동 진화가 아니라 가독성입니다. 현재 프롬프트 조립과 게이트 판정 경로가 코드 여러 곳에 흩어져 있다면, 그 구조를 한곳에서 읽고 편집할 수 있게 정리하는 작업이 선행되어야 합니다. 그다음이 평가 하니스의 정비입니다. 어떤 변경이 좋은 변경인지 판정할 수 있는 고정된 질의 집합과 통과 기준이 없으면, 진화는 방향 없는 표류가 됩니다. 저희에게는 이미 인용 게이트와 품질 시나리오라는 두 축이 있으므로, 이를 프로바이더별로 동일하게 돌리는 패리티 하니스가 그 역할을 할 수 있습니다. 자동 탐색은 그 뒤에 와야 하며, 그때에도 탐색 대상은 프롬프트 구성과 근거 배치 같은 생성기 쪽 변수에 한정되어야 합니다.
기술적 트레이드오프
긴장 관계 하니스를 자동으로 진화시키면 사람이 도달하기 어려운 조합까지 탐색할 수 있지만, 탐색은 평가 신호가 보는 것만 개선하고 보지 못하는 것은 대가로 지불합니다. 법률 도메인에서 그 대가는 대개 근거의 엄밀성이며, 이는 표면 품질 지표에 거의 잡히지 않습니다.
실무적 해소 탐색 공간과 검증 계층을 분리하는 것으로 해소합니다. 진화의 대상은 프롬프트 구성·근거 배치·재시도 정책처럼 생성기 쪽 변수로 한정하고, 인용 실존 검증과 fail-closed 차단은 탐색 대상에서 제외해 모든 후보가 반드시 통과해야 하는 고정 관문으로 둡니다. 게이트를 통과하지 못한 후보는 점수를 매기기 전에 탈락시켜, 검증 완화가 성능 향상으로 오인될 여지 자체를 없앱니다.
법마디 OS에 적용한다면
법마디에 이 논의를 적용할 때 첫 작업은 새로운 알고리즘이 아니라 경계선 긋기입니다. 지금 저희 파이프라인에서 생성기에 해당하는 부분은 분류·검색·프롬프트 조립·응답 생성이고, 검증에 해당하는 부분은 인용 추출과 실존 대조, 법리 일관성 게이트, 그리고 미검증 인용을 문장 단위로 제거하는 fail-closed 처리입니다. 하니스 진화라는 개념을 받아들이더라도 이 두 영역은 서로 다른 규칙 아래 놓여야 합니다. 앞쪽은 얼마든지 실험하고 교체하고 자동 탐색의 대상으로 삼아도 되지만, 뒤쪽은 어떤 실험에서도 상수로 고정되어야 합니다. 그다음 작업은 평가 하니스를 프로바이더 중립적으로 다시 세우는 일입니다. 동일한 질의 집합을 서로 다른 생성기로 돌렸을 때 두 경우 모두 인용 게이트를 통과하고 동등한 근거를 제시하는지를 측정할 수 있다면, 그것이 곧 모델 비종속성의 증명이자 하니스 변경을 판정하는 기준선이 됩니다. 마지막으로 가독성입니다. 하니스가 무엇을 하고 있는지 코드를 읽지 않고도 설명할 수 있어야, 사고가 났을 때 원인을 하니스에서 찾을 수 있습니다.
기술적 함의
- 모델 교체는 시스템 재작성이 아니라 부품 교체가 되어야 하며, 그러려면 생성기 호출이 어댑터 경계 뒤에 숨어 있어야 합니다.
- 하니스 변경을 판정하는 평가 집합이 없으면 개선과 표류를 구분할 수 없으므로, 고정된 질의 집합과 통과 기준이 자동화보다 먼저 갖춰져야 합니다.
- 검증 계층은 탐색 대상이 아니라 탐색의 전제이며, 게이트 완화가 점수 상승으로 보이는 평가 설계는 그 자체로 결함입니다.
"하니스 연구가 던지는 메시지는 결국 하나입니다. 능력은 모델 안에만 있지 않고 모델을 둘러싼 구조에도 있다는 것입니다. 법마디는 그 구조를 검증이라는 이름으로 먼저 두껍게 쌓아왔고, 앞으로 그 위에 실험 가능한 층을 얹으려 합니다. 다만 순서는 바뀌지 않습니다. 먼저 읽을 수 있게 만들고, 다음에 측정할 수 있게 만들고, 그러고 나서 진화시킵니다."
