LLM Wiki

하네스 엔지니어링으로 딥 에이전트 개선하기

18 min read

하네스 엔지니어링으로 딥 에이전트 개선하기

TLDR: LangChain의 코딩 에이전트가 Terminal Bench 2.0에서 Top 30 → Top 5로 도약. 모델은 그대로(gpt-5.2-codex) 두고 하네스만 변경하여 52.8점 → 66.5점(+13.7점) 달성. 핵심은 자기 검증(self-verification)과 트레이싱(tracing).

하네스 엔지니어링의 목표

하네스의 목표는 모델의 본질적으로 불규칙한(spiky) 지능을 우리가 원하는 작업에 맞게 성형하는 것이다. 하네스 엔지니어링은 시스템에 관한 것으로, 작업 성능, 토큰 효율성, 지연 시간 등의 목표를 최적화하기 위해 모델 주변에 도구를 구축하는 것이다. 설계 결정에는 시스템 프롬프트, 도구 선택, 실행 흐름 등이 포함된다.

LangChain은 LangSmith Traces를 사용해 에이전트의 실패 모드를 대규모로 이해한다. 오늘날의 모델은 대체로 블랙박스이며 내부 메커니즘을 해석하기 어렵지만, 텍스트 공간에서 입력과 출력을 관찰하여 개선 루프에 활용할 수 있다.

실험 설정과 하네스의 조정 가능한 요소

Terminal Bench 2.0은 에이전트 코딩을 평가하는 표준 벤치마크로, 머신러닝, 디버깅, 생물학 등 다양한 도메인의 89개 작업으로 구성된다. Harbor로 실행을 오케스트레이션하고, Daytona 샌드박스에서 에이전트 루프를 실행하며 검증과 채점을 수행한다. 모든 에이전트 액션은 LangSmith에 저장되며 지연 시간, 토큰 수, 비용 등의 메트릭이 포함된다.

조정 가능한 세 가지 요소

에이전트 하네스에는 시스템 프롬프트, 도구, 훅/미들웨어, 스킬, 서브 에이전트 위임, 메모리 시스템 등 많은 조정 가능 요소가 있다. 이번 실험에서는 최적화 공간을 의도적으로 압축하여 세 가지에 집중했다: 시스템 프롬프트, 도구, 미들웨어(모델 및 도구 호출을 감싸는 훅).

기본 프롬프트와 표준 도구+미들웨어로 시작했을 때 GPT-5.2-Codex 기준 52.8%를 기록했다. 리더보드 Top 30 바로 밖의 견고한 점수지만, 개선의 여지가 충분했다.

트레이스 분석기 스킬

트레이스 분석을 반복 가능하게 만들기 위해 에이전트 스킬로 만들었다. 이 스킬은 실행 전반의 오류를 분석하고 하네스를 개선하는 레시피 역할을 한다:

  1. LangSmith에서 실험 트레이스 가져오기
  2. 병렬 오류 분석 에이전트 실행 → 메인 에이전트가 발견 사항과 제안을 종합
  3. 피드백을 집계하여 하네스에 타겟 변경 적용

이는 이전 실행의 실수에 집중하는 부스팅(Boosting)과 유사하게 작동한다. 3단계에서는 사람이 제안된 변경 사항을 검증하고 논의하는 것이 도움이 되지만 필수는 아니다. 특정 작업에 과적합되는 변경은 일반화에 해롭고 다른 작업에서 회귀를 초래할 수 있다.

자동화된 트레이스 분석은 수 시간의 시간을 절약하고 빠른 실험을 가능하게 한다.

실제로 에이전트 성능을 개선한 것들

1. 빌드 & 자기 검증 (Build & Self-Verify)

오늘날의 모델은 뛰어난 자기 개선 머신이다. 자기 검증은 실행 중 피드백을 통해 에이전트가 스스로 개선할 수 있게 한다. 그러나 모델은 자연스럽게 빌드-검증 루프에 진입하지 않는다.

가장 흔한 실패 패턴: 에이전트가 솔루션을 작성하고, 자신의 코드를 다시 읽고, 괜찮아 보인다고 확인한 후 중단하는 것. 테스트는 자율 에이전트 코딩의 핵심 요소로, 전체 정확성을 검증하고 에이전트에게 개선을 위한 신호를 제공한다.

시스템 프롬프트에 다음과 같은 문제 해결 접근법 가이드를 추가했다:

  1. 계획 & 탐색: 작업을 읽고, 코드베이스를 스캔하고, 작업 명세와 검증 방법에 기반한 초기 계획 수립
  2. 빌드: 검증을 염두에 두고 계획 구현. 테스트가 없으면 작성하고, 해피 패스와 엣지 케이스 모두 테스트
  3. 검증: 테스트 실행, 전체 출력 읽기, 자신의 코드가 아닌 요구사항과 비교
  4. 수정: 오류 분석, 원본 명세 재검토, 문제 수정

프롬프팅과 함께 결정론적 컨텍스트 주입도 도움이 되었다. PreCompletionChecklistMiddleware는 에이전트가 종료하기 전에 가로채서 작업 명세에 대한 검증 패스를 실행하도록 상기시킨다. 이는 Ralph Wiggum Loop와 유사하게, 종료 시 훅이 에이전트가 계속 실행하도록 강제하는 방식이다.

2. 에이전트에게 환경 컨텍스트 제공하기

하네스 엔지니어링의 일부는 컨텍스트 엔지니어링을 위한 좋은 전달 메커니즘을 구축하는 것이다.

  1. 디렉토리 컨텍스트 & 도구: LocalContextMiddleware가 에이전트 시작 시 cwd와 상위/하위 디렉토리를 매핑하고, bash 명령으로 Python 설치 등 도구를 찾는다. 컨텍스트 발견과 검색은 오류가 발생하기 쉬우므로, 컨텍스트를 주입하면 오류 표면을 줄이고 에이전트를 환경에 온보딩할 수 있다.

  2. 테스트 가능한 코드 작성 가르치기: 에이전트는 자신의 코드가 어떻게 테스트 가능해야 하는지 모른다. 코드가 프로그램적 테스트로 측정될 것임을 프롬프트에 명시하고, 파일 경로 등 작업 명세를 정확히 따르도록 지시한다. 엣지 케이스를 강조하는 프롬프팅은 “해피 패스”만 확인하는 것을 방지한다. 테스트 표준을 강제하는 것은 시간이 지남에 따른 “슬롭 축적(slop buildup)“을 방지하는 강력한 전략이다.

  3. 시간 예산: 시간 예산 경고를 주입하여 에이전트가 작업을 마무리하고 검증으로 전환하도록 유도한다. 에이전트는 시간 추정에 취약하므로 이러한 휴리스틱이 도움이 된다.

하네스 엔지니어의 목적: 에이전트가 자율적으로 작업을 완료할 수 있도록 컨텍스트를 준비하고 전달하는 것.

3. 에이전트가 한 걸음 물러나 계획을 재고하도록 장려하기

에이전트는 한 번 계획을 결정하면 근시안적(myopic)이 되어, 동일한 잘못된 접근법을 작은 변형만 주며 반복하는 “둠 루프(doom loop)“에 빠질 수 있다(일부 트레이스에서는 10회 이상).

LoopDetectionMiddleware는 도구 호출 훅을 통해 파일별 편집 횟수를 추적하고, 동일 파일에 N회 편집 후 “…접근 방식을 재고해보세요”라는 컨텍스트를 추가한다. 이는 에이전트가 둠 루프에서 회복하는 데 도움이 되지만, 모델이 자신이 옳다고 생각하면 같은 경로를 계속 갈 수도 있다.

중요한 점: 이는 오늘날 인식된 모델 문제를 해결하기 위한 설계 휴리스틱이다. 모델이 개선되면 이러한 가드레일은 불필요해질 것이지만, 현재로서는 에이전트가 올바르고 자율적으로 실행되도록 돕는 유용한 도구다.

4. 추론에 사용할 컴퓨팅 양 선택하기

추론 모델은 몇 시간 동안 자율적으로 실행될 수 있으므로, 각 하위 작업에 얼마나 많은 컴퓨팅을 사용할지 결정해야 한다. 모든 작업에 최대 추론 예산을 사용할 수도 있지만, 대부분의 작업은 추론 컴퓨팅 지출을 최적화하면 이점을 얻을 수 있다.

Terminal Bench의 타임아웃 제한은 트레이드오프를 만든다. 더 많은 추론은 에이전트가 각 단계를 평가하는 데 도움이 되지만, 2배 이상의 토큰/시간을 소모할 수 있다. gpt-5.2-codex는 low, medium, high, xhigh의 4가지 추론 모드를 제공한다.

발견한 점:

  • 추론은 문제를 완전히 이해하기 위한 계획 수립에 도움이 된다(일부 Terminal Bench 작업은 매우 어려움)
  • 좋은 계획은 더 빠르게 작동하는 솔루션에 도달하는 데 도움이 된다
  • 후반 검증 단계에서도 더 많은 추론이 실수를 포착하고 솔루션을 제출하는 데 도움이 된다

휴리스틱으로 xhigh-high-xhigh “추론 샌드위치” 를 베이스라인으로 선택했다. 계획과 검증에 더 많은 추론 컴퓨팅을 사용하는 방식이다.

xhigh만 사용하면 에이전트 타임아웃으로 53.9%에 그친 반면, high에서는 63.6%를 기록했다. 추론 예산 분할 간 큰 차이는 없었지만, 이 접근법으로 점수를 66.5%까지 끌어올렸다.

모델의 자연스러운 접근법은 Claude의 적응형 사고나 Gemini의 사고 모드처럼 모델이 추론에 사용할 컴퓨팅을 스스로 결정하는 적응형 추론(Adaptive Reasoning) 이다. 멀티 모델 하네스에서는 큰 모델로 계획을 수립하고 작은 모델로 구현을 핸드오프하는 방식으로 추론 예산 균형을 맞출 수 있다.

에이전트 하네스 구축을 위한 실용적 교훈

에이전트의 설계 공간은 방대하다. 실험과 deepagents 구축 전반에서 얻은 일반 원칙들:

  1. 에이전트를 대신한 컨텍스트 엔지니어링. 컨텍스트 조립은 오늘날 에이전트에게 여전히 어렵다. 디렉토리 구조, 사용 가능한 도구, 코딩 모범 사례, 문제 해결 전략 등의 컨텍스트로 모델을 온보딩하면 잘못된 검색과 계획 오류의 오류 표면을 줄일 수 있다.

  2. 에이전트가 자신의 작업을 자기 검증하도록 돕기. 모델은 첫 번째 그럴듯한 솔루션에 편향된다. 테스트를 실행하고 솔루션을 개선하여 작업을 검증하도록 적극적으로 프롬프트하라. 이는 인간이 루프에 없는 자율 코딩 시스템에서 특히 중요하다.

  3. 트레이싱을 피드백 신호로 활용. 트레이스는 에이전트가 스스로 평가하고 디버깅할 수 있게 한다. 도구와 추론을 함께 디버깅하는 것이 중요하다(예: 모델이 도구나 사용 방법 지침이 부족해서 잘못된 경로로 가는 경우).

  4. 단기적으로 나쁜 패턴을 감지하고 수정. 오늘날의 모델은 완벽하지 않다. 하네스 설계자의 역할은 미래의 더 똑똑한 모델을 계획하면서 오늘날의 단점을 보완하는 것이다. 맹목적인 재시도와 작업 미검증이 좋은 예다. 이러한 가드레일은 시간이 지나면 거의 확실히 사라지겠지만, 현재 견고한 에이전트 애플리케이션을 구축하려면 실험해볼 가치가 있는 유용한 도구다.

  5. 하네스를 모델에 맞게 조정. Codex와 Claude 프롬프팅 가이드는 모델마다 다른 프롬프팅이 필요함을 보여준다. Claude Opus 4.6으로 테스트 실행한 결과 이전 하네스 버전에서 59.6%를 기록했는데, Codex와 동일한 개선 루프를 실행하지 않았기 때문에 경쟁력은 있지만 더 낮았다. 좋은 컨텍스트 준비와 검증 중심 접근 같은 많은 원칙은 일반화되지만, 작업에 맞게 몇 차례 하네스 반복을 실행하면 모델 간 에이전트 성능을 극대화할 수 있다.

향후 연구 방향

하네스 설계에는 더 많은 열린 연구 과제가 있다. 흥미로운 방향으로는 멀티 모델 시스템(Codex, Gemini, Claude를 함께), 지속적 학습을 위한 메모리 프리미티브(에이전트가 작업에서 자율적으로 개선), 모델 간 하네스 변경 측정 등이 있다.

에이전트 개선의 외부 루프로는 RLM 같은 방법으로 트레이스를 더 효율적으로 마이닝하는 것을 검토 중이다.

LangChain은 트레이스 데이터셋을 커뮤니티와 공유했다. Deep Agents는 오픈소스로 Python과 JavaScript 버전이 제공된다.

관련 노트

그래프 뷰

백링크