기술 요약: 실패한 궤적에서 신뢰할 수 있는 LLM 에이전트로: 하네스 결함의 진단 및 수리

1. 문제 정의

LLM 기반 에이전트는 실행 환경, 도구 인터페이스, 컨텍스트 관리, 라이프사이클 오케스트레이션, 관측성, 검증 및 거버넌스(ETCLOVG 분류 체계로 요약됨)를 제공하는 런타임 인프라인 **하네스(harness)**에 점점 더 많이 의존하고 있습니다. 자가 개선 에이전트 및 자동 하네스 진화 방법들은 런타임 감독, 프롬프트 최적화 또는 워크플로우 탐색을 통해 성능을 개선하려고 시도하지만, 실패의 근본 원인을 효과적으로 진단하는 데는 종종 실패합니다.

현재의 접근 방식은 세 가지 주요 한계점을 가집니다:

1. 파편화된 증거: 실패 증거가 이질적이고, 언어 중심적이며, 비결정론적인 실행 궤적 전반에 흩어져 있어 정밀한 진단이 어렵습니다.
2. 매핑 격차: 실패가 궤적 내에서 국지화되더라도, 이를 책임지는 특정 정적 하네스 구현(소스 코드, 프롬프트, 설정)으로 매핑하는 것은 어렵습니다. 이는 런타임 동작과 정적 아티팩트가 명시적으로 정렬되지 않는 경우가 많기 때문입니다.
3. 범위가 지정되지 않은 수정: 타겟팅된 인과적 진단 없이는 개선 작업이 광범위하고 간접적이거나 범위가 불분명해집니다. 또한, 하나의 결함을 고치기 위해 하네스 메커니즘을 수정하는 것은 에이전트 시스템의 암시적 의존성으로 인해 다른 곳에서 회귀(regression)를 유발할 위험이 있습니다.

기존 방법들은 실패가 궤적의 어디에 증거가 있는지 또는 어떤 하네스 레이어가 실패했는지를 식별하지 못한 채 최종 결과만을 바탕으로 최적화하므로, 근본적인 구조적 결함을 해결하지 못하는 피상적인 수정에 그칩니다.

2. 방법론: HARNESSFIX

본 논문은 실패를 진단하고 하네스를 수리하기 위해 설계된 4개 에이전트 파이프라인인 궤적 유도형 프레임워크 HARNESSFIX를 제안합니다. 핵심 철학은 미세한 수준의 궤적 기반 실패 진단을 통해 하네스 수리를 유도하는 것입니다.

A. 하네스 인식 궤적 중간 표현 (HTIR)

이질적인 로우(raw) 실행 궤적을 처리하기 위해, HARNESSFIX는 로우 궤적과 하네스 코드를 통합된 HTIR로 컴파일합니다. 이 표현 방식은 파편화된 증거를 정규화하고 다음을 캡처합니다:

• 노드 (TraceSteps): 고유 식별자를 가진 복구 가능한 실행 단계 (모델 호출, 도구 액션, 검증).
• 속성 (Attributes): 요청/응답 메시지, 실행 상태, 그리고 아티팩트/상태 효과 (읽기/쓰기/알 수 없음).
• 링크 (Links):
  • 시간적 링크 (Temporal links): 실행 순서 보존.
  • 입력 프로비넌스 링크 (Input Provenance links): 이전 궤적 내용과 하네스 로직(예: 메모리 조립, 프롬프트 구축)으로부터 요청이 어떻게 구성되었는지 추적.
  • 제어 흐름 링크 (Control Flow links): 하네스 컨트롤러에 의해 왜 해당 단계가 트리거되었는지 설명 (예: 재시도, 위임, 종료).
• 노드 로컬 진단 증거 (Node-local Diagnostic Evidence): 입력 프로비넌스, 제어 흐름 및 아티팩트 효과를 결합한 각 단계의 국지적 뷰.
• 하네스 레이어 책임 측면 (Harness Layer Responsibility Facet): 부착된 증거를 기반으로 각 단계를 관련 ETCLOVG 레이어(실행, 도구, 컨텍스트, 라이프사이클, 관측성, 검증, 거버넌스)에 매핑.

B. 하네스 결함 진단

**진단 에이전트(Diagnosis Agent)**는 HTIR를 처리하여 구조화된 진단 레코드를 생성합니다:

1. 증상 국지화 (Symptom Localization): 최종 평가 결과로부터 실패 증상을 식별합니다.
2. 증거 역추적 (Evidence Backtracking): 시간적, 프로비넌스 및 제어 흐름 링크를 사용하여 후보 책임 단계 세트를 랭킹화하여 생성합니다.
3. 후보 판정 (Candidate Adjudication): 노드 로컬 증거와 하네스 코드 참조를 검사하여 최종 책임 단계(들)를 선택합니다.
4. 레이어 매핑 (Layer Mapping): 책임 단계에 임플리케이션된 ETCLOVG 레이어를 할당합니다.
5. 결함 통합 (Flaw Consolidation): 여러 실행에 걸친 진단 레코드를 그룹화하여 반복되는 결함 패턴을 식별하고, 이를 실행 가능한 **결함 레코드(Flaw Records)**로 요약합니다.

C. 범위 지정된 수리 (Scoped Repair)

불안정한 편집과 아키텍처 파손을 방지하기 위해, HARNESSFIX는 자유 형식의 자가 편집 대신 **수리 연산자(Repair Operators)**를 사용합니다.

• 매핑: 결함 레코드는 에이전트 저장소의 버전 변경 기록에서 추출된 특정 수리 연산자(예: "도구 스키마 축소", "루프 가드")에 매핑됩니다.
• 수리 명세 (Repair Specification): 선택된 연산자는 다음을 정의하는 결함 특화 명세로 구체화됩니다:
  • 대상 및 범위 (Target and Scope): 수정할 구체적인 하네스 아티팩트.
  • 편집 제약 (Edit Constraints): 금지된 리소스 (예: 벤치마크 데이터, 평가기).
  • 필요 동작 (Required Behavior): 패치가 구현해야 하는 특정 동작.
  • 검증 및 리스크 (Validation and Risk): 대상 결함 감소 및 회귀 경계(bounds)를 포함한 수용 기준.

D. 패치 검증 및 하네스 메모리

**검증 에이전트(Validation Agent)**는 안전성과 유효성을 보장합니다:

1. 사전 검증 (Pre-validation): 후보 디프(diff)가 수리 명세 및 기본 구문에 부합하는지 확인합니다.
2. 검증 세트 평가 (Validation Set Assessment): 패치가 부적절한 회귀를 도입하지 않으면서($R_{new} \le r_{max}$) 타겟 결함 발생을 줄이는지($\Delta D_{target} \ge \delta_{min}$) 홀드아웃 검증 세트에서 평가합니다.
3. 하네스 메모리 (Harness Memory): 결과를 기록(수용 또는 거부)하여 향후 반복 작업에 정보를 제공하며, 유사한 결함에 대한 예시를 제공하거나 거부 이유를 설명합니다.

3. 주요 기여

1. HARNESSFIX 프레임워크: 실패 증거를 하네스 인식 진단 및 범위 지정된 하네스 변경으로 명시적으로 연결하여, 결과 중심의 프롬프트 진화를 넘어선 궤적 기반의 진단 및 수리 프레임워크를 제공합니다.
2. HTIR: 이질적인 에이전트 궤적을 단계 수준의 증거 구조로 정규화하여 정밀한 귀속 및 수리 계획을 가능하게 하는 하네스 인식 궤적 표현 방식입니다.
3. 경험적 평가: 네 가지 벤치마크(SWE-Bench Verified, Terminal-Bench 2.0 Verified, GAIA, AppWorld)에 대한 포괄적인 평가를 통해 상당한 성능 향상을 입증했습니다.
4. 체계적 분석: 수용된 수리 사례에 대한 상세한 분석을 통해 ETCLOVG 레이어 전반에 걸친 반복적인 하네스 결함 패턴과 다양한 태스크 설정의 특정 스트레스 지점을 밝혀냈습니다.

4. 실험 결과

저자들은 네 가지 벤치마크에서 초기 하네스($H_0$), 인간이 설계한 하네스, 그리고 자가 진화 베이스라인(GEPA, SCOPE, ReCreate)과 HARNESSFIX를 비교 평가했습니다.

• 성능 향상: HARNESSFIX는 벤치마크 전반에 걸쳐 초기 하네스 대비 홀드아웃 테스트 성능을 15.2%에서 50.0%까지 개선했습니다:
  • SWE-Bench Verified: 45.0% $\to$ 57.0% (상대적 개선율 26.7%).
  • Terminal-Bench 2.0 Verified: 17.6% $\to$ 26.5% (상대적 개선율 50.0%).
  • GAIA: 43.3% $\to$ 61.7% (상대적 개선율 42.3%).
  • AppWorld: 36.7% $\to$ 42.2% (상대적 개선율 15.2%).
• 베이스라인과의 비교: HARNESSFIX는 모든 벤치마크에서 모든 자가 진화 베이스라인과 가장 강력한 인간 설계 하네스를 능가했습니다. 예를 들어, SWE-Bench에서 가장 우수한 인간 설계 하네스(Trae-Agent)가 48개의 태스크를 해결한 반면, HARNESSFIX는 57개를 해결했습니다.
• 절제 연구 (Ablation Study): 핵심 구성 요소를 제거하면 성능이 크게 저하되었습니다:
  • *프롬프트 전용 수리(Prompt-only repair)*는 Terminal-Bench에서 개선에 실패했으며 다른 곳에서도 미미한 이득만을 보여, 소프트 가이드만으로는 불충분함을 입증했습니다.
  • 궤적 기반 진단이 없는 경우에는 중간 정도의 개선은 있었으나 전체 시스템에는 미치지 못해, 정밀한 단계별 귀속의 필요성을 확인했습니다.
  • 범위 지정된 수리 연산자가 없는 경우에는 회귀가 발생하여, 특정 연산자로 편집을 제한하는 것의 필요성을 입증했습니다.
  • 회귀 인식 수용(Regression-aware acceptance)이 없는 경우에는 최종 점수가 낮아져, 유용한 후보를 안전한 하네스 변경으로 전환하는 데 검증이 필수적임을 증명했습니다.

5. 의의 및 주장

본 논문은 하네스 수리가 프롬프트 최적화와는 구별되는 중요하고 독특한 과제라고 주장합니다. HARNESSFIX의 의의는 다음과 같습니다:

• 런타임-정적 격차 해소: HTIR을 사용하여 동적인 실행 실패를 정적인 하네스 구현 아티팩트로 효과적으로 매핑합니다.
• 타겟팅된 안전한 수리 가능: 범위 지정된 수리 연산자와 회귀 인식 검증을 사용하여, 재귀적 자가 편집과 관련된 불안정성 없이 런타임 메커니즘(도구 인터페이스, 라이프사이클 가드, 관측성)에 대한 깊은 수정을 허용합니다.
• 도메인 간 일반화: 소프트웨어 엔지니어링, 터미널 워크플로우, 연구 QA, 애플리케이션 자동화 등 다양한 도메인에서의 성공은 궤적 기반 하네스 수리가 에이전트 신뢰성을 향상시키는 일반화 가능한 접근 방식임을 시사합니다.
• 시스템적 결함 노출: 분석 결과, 서로 다른 태스크 도메인이 서로 다른 하네스 레이어를 압박한다는 점(예: AppWorld는 검증 및 라이프사이클을, GAIA는 도구 인터페이스 및 관측성을 압박)을 밝혀냈으며, 이는 효과적인 에이전트 엔지니어링을 위해 범용 프롬프트 엔지니어링이 아닌 도메인 특화된 하네스 튜닝이 필요함을 시사합니다.

저자들은 에이전트가 점점 더 복잡한 과제를 수행함에 따라 하네스가 시스템 신뢰성의 주요 결정 요인이 될 것이며, HARNESSFIX가 이러한 인프라적 결함을 진단하고 수리하는 체계적인 방법을 제공한다고 결론짓습니다.