하네스 엔지니어링: 모델 바깥을 설계해 에이전트를 믿을 만하게

왜 필요했나: 모델만 바꿔서는 풀리지 않는 문제

대규모 언어 모델(LLM)의 쓰임새가 답변 한 번으로 끝나는 챗봇에서 넓어졌다. 이제는 도구를 부르고 실제 파일을 고치며 여러 단계를 이어 가는 일에도 쓰인다. Doc2Harness논문는 이런 장기 작업에서 에이전트의 성과가 모델만큼이나 모델을 둘러싼 하네스에 달려 있다고 짚는다. 하네스(에이전트 하네스)는 모델 바깥에서 프롬프트·도구·메모리·오케스트레이션 로직을 묶은 시스템 층이다(범주론 아키텍처 연구논문). 오케스트레이션은 여러 단계와 에이전트를 어떤 순서로 돌릴지 정하는 제어를 말한다.

SemaClaw논문는 2026년 초 OpenClaw가 등장해 수백만 명이 개인 AI 에이전트를 일상에 쓰기 시작한 시점을 전환점으로 본다. 이때부터 AI 엔지니어링의 중심이 프롬프트 엔지니어링과 컨텍스트 엔지니어링에서 하네스 엔지니어링으로 옮겨 가고 있다는 주장이다. 모델 능력이 서로 비슷해질수록 제품 간 차이를 만드는 곳은 하네스 층이 된다고 이 연구는 본다.

문제는 이 층이 오랫동안 손으로 다듬는 기술이었다는 점이다. LLM 에이전트는 같은 과제와 같은 도구를 줘도 실행할 때마다 다르게 움직인다. 결정론 제약 연구논문는 이런 편차가 탐색용으로는 괜찮아도 금융·컴플라이언스 같은 규제 영역에서는 받아들일 수 없다고 지적한다. 범주론 아키텍처 연구논문는 하네스 설계가 즉흥적(ad hoc)이라고 본다. 부품을 조합하는 원리나 프레임워크끼리 비교하는 체계적 이론이 없다는 것이다.

핵심 아이디어: 힘센 말에 맞는 마구

영어 harness는 원래 말에 채우는 마구다. 힘센 말은 혼자서도 달리지만 고삐·멍에·수레가 있어야 원하는 방향으로 짐을 나른다. 이 비유에서 LLM은 말이고, 하네스는 그 힘을 일로 바꾸는 마구 전체다. 하네스 엔지니어링은 이 마구를 설계하는 일이다.

프롬프트·컨텍스트와 견주면 차이가 분명해진다. 프롬프트 엔지니어링은 고삐를 어떻게 당길지, 곧 지시문 문장을 다룬다. 컨텍스트 엔지니어링은 말의 시야에 무엇을 보여 줄지, 곧 컨텍스트 윈도에 넣을 정보를 다룬다. 하네스 엔지니어링은 여기서 더 나아가 어떤 도구를 허락할지, 결과를 누가 검사할지, 실패하면 몇 번 다시 시도할지, 작업 상태를 어디에 남길지까지 정한다. SemaClaw논문는 이를 제약 없는 에이전트를 통제할 수 있고, 감사할 수 있고, 운영에서 믿을 수 있는 시스템으로 바꾸는 전체 인프라를 설계하는 일로 설명한다.

범주론 아키텍처 연구논문는 에이전트가 모델 밖으로 꺼내 둔 능력을 메모리·스킬·프로토콜·하네스 엔지니어링의 네 기둥으로 정리한다. 그리고 전체 하네스를 이들을 묶은 '아키텍처' 자체로 본다. 하네스는 부품 하나가 아니라 부품을 엮는 방식이라는 뜻이다.

어떻게 작동하나: 한 턴이 도는 과정

하네스가 한 턴을 처리하는 흐름은 대략 아래와 같다. 여러 연구에 나오는 부품을 일반적인 순서로 엮은 것이며, 모든 하네스가 이 순서를 그대로 따르지는 않는다.

첫째, 컨텍스트를 구성한다. 시스템 프롬프트와 지금 과제에 필요한 스킬(재사용할 수 있는 작업 지침 묶음), 이전 작업 기록을 골라 모델에 넣는다. SemaClaw논문는 이를 위해 3단 컨텍스트 관리 구조를 둔다. 둘째, 모델이 다음 행동을 제안한다. 도구를 부를지, 어떤 인자로 부를지를 정한다. 셋째, 하네스가 그 제안을 바로 실행하지 않고 검사한다. SemaClaw의 PermissionBridge는 행동 안전을 맡는 권한 계층이다. 결정론 제약 연구논문는 다섯 가지 부품으로 하네스를 짠다. 정해진 상태 사이로만 움직이게 하는 유한 상태 제어, 강제 도구 선택, 출력 검증, 재시도 횟수 상한, 구조화된 계획이다.

넷째, 검사를 통과한 행동은 샌드박스 같은 격리 환경에서 도구로 실행되고, 결과는 상태 저장소에 남는다. 다섯째, 그 결과를 다시 컨텍스트에 반영해 다음 턴을 돈다. NORA논문는 연구 에이전트용 하네스 요소로 다섯 가지를 꼽는다. 특정 시점마다 자동으로 실행되는 생명주기 훅, 안전 게이트, 생성자와 평가자의 분리, 휴먼 인 더 루프, 상태 영속화다. 이 연구는 이런 요소가 신뢰할 수 있고 재현 가능한 자율 연구를 가능하게 한다고 주장한다.

이 구조의 핵심은 '모델이 결정하고, 하네스가 허락·검증·기록한다'는 역할 분담이다. 모델이 틀린 행동을 내놓아도 하네스가 걸러 내거나 다시 시도하게 할 수 있다. 같은 입력이면 같은 경로를 밟도록 범위를 좁힐 수도 있다.

발전 흐름: 만들기에서 자동화·측정으로

2026년 봄부터 '하네스 엔지니어링'을 제목에 내건 연구가 잇달아 나왔다. 첫 흐름은 실제 하네스를 만들어 보이는 일이었다. SemaClaw논문는 오픈소스 멀티 에이전트 프레임워크다. DAG(작업 사이의 선후 관계를 화살표로 이은 그래프) 기반의 2단계 하이브리드 에이전트 팀 오케스트레이션, PermissionBridge, 3단 컨텍스트 관리, 개인 지식 베이스를 자동으로 쌓는 위키 스킬을 담았다. NORA논문는 21개 도메인 스킬, 9개 전문 서브에이전트, 맞춤형 MCP 서버로 공간 데이터 과학 연구의 전 과정을 돌린다.

두 번째 흐름은 하네스를 사람 손에서 떼어 내는 자동화와 이론화다. AHE(Agentic Harness Engineering, 논문)는 자동화가 어려운 이유를 셋으로 든다. 고칠 수 있는 부품이 제각각이고, Trajectory(에이전트의 행동 기록)가 너무 방대해 쓸모 있는 신호가 묻히며, 어떤 수정이 효과를 냈는지 가려내기 어렵다는 것이다. AHE는 이에 맞춰 세 가지 장치를 둔다. 부품마다 되돌릴 수 있는 파일 단위 표현을 주고, 수백만 토큰의 기록을 층층이 파고들 수 있는 증거 묶음으로 Distill한다. 또 모든 수정에 예상 효과를 붙여 다음 회차 결과로 검증한다. 그 결과 10회 반복으로 Terminal-Bench 2의 pass@1(한 번에 성공한 비율)을 69.7%에서 77.0%로 올려, 사람이 설계한 Codex-CLI 하네스(71.9%)를 넘었다고 보고한다. 범주론 아키텍처 연구논문는 하네스를 수학적 구조로 형식화했다. 또 Swarms·DeerFlow·Ralph·Scion·LangGraph를 대상으로 하는 컴파일러가 세 종류의 보장 증명서를 그대로 유지함을 보였다.

세 번째 흐름은 하네스 자체를 재는 일이다. 결정론 제약 연구논문는 하네스가 실행 재현성을 얼마나 바꾸는지 측정했다. LoopsBench논문는 코딩 에이전트 인프라의 중심이 하네스 엔지니어링에서 '루프 엔지니어링'(오래 이어지는 개발 반복을 설계하는 일)으로 옮겨 간다고 보고, 112개 장기 과제로 평가한다. Doc2Harness논문는 고정된 하네스 위에서 과제 성공만 재던 기존 벤치마크와 다르다. 모델이 하네스를 직접 만들게 한 뒤 그 결과물을 평가한다. 19개 모델 중 최고인 GPT-6 Astra는 328개 테스트 케이스에서 53.05%를 통과했고, 가장 낮은 모델은 27.44%였다.

요즘 어디로 가고 있나

최근 연구는 하네스가 얼마나, 어떻게 중요한지를 세 갈래로 묻는다. 첫째, 하네스가 모델 격차를 얼마나 메우는가. 미국 주 법안을 엄격한 스키마의 XML로 바꾸는 산업 파이프라인 연구논문가 이 질문을 다룬다. 이 연구는 하네스 세 가지(제로샷, 도구를 쓰는 단일 에이전트, 분해된 멀티 에이전트 파이프라인)와 Claude 모델 세 가지를 교차해 정답 법안 153건으로 비교했다. 전체 파이프라인에 넣은 가장 약한 모델이 단독으로 쓴 가장 강한 모델을 이겼다(0.948 대 0.806). 두 에이전트형 하네스는 도구가 같았으므로, 저자들은 차이가 오케스트레이션에서 나왔다고 본다. 작업을 나누면서 상태가 유지되고 에이전트마다 컨텍스트가 따로 주어진 덕분이라는 설명이다. 마지막까지 남은 오차는 인용 표기 정규화에 몰려 있었다. 여기서는 정식 식별자를 모델이 생성하지 않고 외부 기관에서 조회하는 결정론적 도구가 정확성을 채웠다.

둘째는 반대 방향의 질문, 정말 복잡한 하네스가 필요한가다. OpenRUA논문는 로봇용 에이전트에 맞춤 추상화 층을 쌓지 않았다. 대신 기성 코딩 에이전트에게 로봇의 기본 소프트웨어 인터페이스인 ROS 2의 터미널 접근과 문서, 기본 도구만 주는 '작업 공간이 곧 하네스' 설계를 택했다. Claude Opus 5 기반 Claude Code로 CaP-Bench 99.0%, LIBERO-PRO 87.0%의 성공률을 보고했다. 맞춤 부품이나 과제별 학습 없이도 작동할 수 있다는 결과다.

셋째는 하네스 진화를 학습 문제로 보는 이론화다. 개인 에이전트의 하네스 진화 연구논문는 모델은 고정하고 컨텍스트·메모리·도구·실행을 관리하는 하네스만 바꿔 사용자 취향에 맞추는 상황을 다룬다. 그리고 이 과정의 한계를 근사·일반화·최적화 오차로 설명한다. 하네스 수정만으로 도달할 수 있는 행동의 범위와, 제한된 상호작용 증거가 만드는 한계를 따지는 시도다.

한계와 쟁점

하네스를 덧댄다고 늘 좋아지지는 않는다. 결정론 제약 연구논문는 Qwen-2.5-7B-Instruct·Gemma-3-27B 두 모델과 금융·법률 두 합성 과제를 조합해 네 칸을 만들었다. 첫 하네스는 한 칸에서만 재현성을 뚜렷이 높였고, 두 칸에서는 오히려 떨어뜨렸으며, 한 칸은 변화가 없었다. 원인은 자유 텍스트로 쓰는 계획 단계였다. 도구 순서·상태 순서·출력이 이미 일관된 뒤에는 이 단계가 남은 편차의 주된 원천이었다. 도구를 부르기 전에 계획을 정해진 스키마로 검증하는 구조화된 계획을 넣자, 네 칸 중 세 칸이 100회 실행에서 재현율과 결정성 지표 1.000에 이르렀다. 대가도 있었다. 토큰 비용은 모든 칸에서 줄었지만, 지연 시간은 한 모델에서 줄고 다른 모델에서는 눈에 띄게 늘었다.

하네스의 두께도 쟁점이다. NORA논문·SemaClaw논문처럼 부품을 많이 쌓는 방향과 OpenRUA논문처럼 최소한만 주는 방향이 함께 쓰인다. 법안 변환 연구논문와 OpenRUA는 다루는 영역이 다르다. 그래서 어느 쪽이 옳다고 단정하기보다, 과제가 요구하는 정확성과 모델이 기존 인터페이스를 얼마나 잘 다루는지에 따라 답이 달라진다고 보는 편이 근거에 맞다.

하네스를 만드는 일 자체도 아직 어렵다. Doc2Harness논문에서는 가장 강한 모델도 테스트 케이스의 절반 가까이를 실패했다. 실패는 여러 모듈에 걸친 기능을 나누는 부분에 몰렸다. LoopsBench논문에서는 가장 강한 구성(Opus-4.7, Claude Code, 바깥 이어 가기 루프)도 과제의 25.00%만 해결했다. 에이전트가 세운 계획은 실제 선후 관계의 일부만 복원했고, 이미 끝낸 부분이 다시 깨지는 회귀도 나타났다.

형식적 보장의 범위도 정확히 읽어야 한다. 범주론 아키텍처 연구논문의 컴파일러는 구조가 그대로 유지되는지와 검증기 재실행을 확인한다. 출력이 맞는지나 모델이 어떻게 행동하는지는 확인하지 않는다고 저자가 직접 밝힌다. 하네스가 보장하는 것과 모델이 여전히 틀릴 수 있는 것은 따로 봐야 한다.

더 공부하려면

처음이라면 SemaClaw논문부터 읽는다. 하네스 엔지니어링이 왜 등장했는지, 권한·컨텍스트 관리 같은 부품이 어떤 모습인지 감을 잡을 수 있다. 이어서 NORA논문를 보면 훅·게이트·생성자-평가자 분리가 실제 연구 에이전트에서 어떻게 쓰이는지 알 수 있다.

설계 효과를 수치로 확인하고 싶다면 결정론 제약 연구논문와 법안 XML 변환 연구논문를 이어 읽는다. 앞의 것은 하네스가 역효과를 낼 수 있음을, 뒤의 것은 같은 도구를 써도 오케스트레이션이 차이를 만든다는 점을 통제 실험으로 보여 준다. 하네스를 자동으로 고치는 방법은 AHE논문에서, 하네스 평가 방법은 Doc2Harness논문와 LoopsBench논문에서 시작하면 된다.

이론에 관심이 있다면 범주론 아키텍처 연구논문와 하네스 진화 연구논문를 읽는다. 반대 관점인 OpenRUA논문도 함께 보면 '하네스를 얼마나 만들어야 하나'라는 질문을 균형 있게 볼 수 있다.