에이전트 하네스와 루프 엔지니어링

에이전트의 신뢰성은 모델 한 번의 똑똑함보다, 그 호출을 감싸 도는 런타임 루프의 설계에서 갈립니다.

하네스의 세 갈래

하네스(harness)는 고정된 명칭이 아닙니다. 무엇을 감싸고 있느냐에 따라 뜻이 바뀌는 상대적 용어입니다. 같은 단어가 최근 문헌에서 최소 세 대상을 가리키므로, 먼저 갈래를 나눠 두지 않으면 논문을 읽을 때마다 헷갈립니다.

원래 하네스는 소프트웨어 공학의 테스트 하네스(test harness)에서 온 말입니다. LLM 맥락에서는 2022~2023년 lm-evaluation-harness처럼 평가 하네스로 먼저 퍼졌습니다. 2024년부터는 모델 호출을 감싸는 런타임 계층을 가리키는 에이전트 하네스로 뜻이 넓어졌습니다.

이 글이 다루는 것은 세 번째인 에이전트 하네스입니다. 첫 프롬프트 이후에 일어나는 모든 것이 여기에 들어갑니다. 모델이 도구·파일시스템·환경과 주고받는 대화를 관리하는 코드 계층입니다.

에이전트 하네스의 네 가지 일

에이전트 하네스가 맡는 일은 도구 실행, 컨텍스트 관리, 상태 영속화, 안전·검증 네 갈래로 나뉩니다. 네 갈래를 따로 떼어 놓고 보면, 작업이 길어질수록 실행 신뢰성이 모델 능력보다 하네스 인프라에 더 크게 제약된다는 점이 분명해집니다.

그림은 한 턴이 도는 순서를 보여줍니다. 모델이 행동을 정하면 하네스가 도구를 실행하고, 그 결과를 컨텍스트에 다시 넣기 전에 압축합니다. 이어 진행 상태를 세션 밖에 적고, 안전 불변식과 종료 조건을 검사한 뒤 다음 턴으로 넘깁니다. 모델은 이 루프 안에서 여러 번 호출되며, 각 호출 사이를 이어 주는 것이 하네스입니다.

네 일 중 컨텍스트 관리는 토큰 예산과 직결됩니다. 압축은 검색·도구 출력에서 필요한 정보만 남기는 단계로, 원문을 보존하는 추출과 의미를 재구성하는 요약이 기본 축입니다. 출처 추적이 중요한 작업은 추출을, 길이를 줄이는 것이 급한 작업은 요약을 기본으로 고릅니다.

루프가 길어질 때 새는 비용

같은 하네스도 한 턴짜리 작업과 수십 턴짜리 작업에서 비용이 전혀 다릅니다. 단일 턴 챗봇은 검색·도구 오버헤드가 딱 한 번 발생하므로 문제가 되지 않습니다. 장기 실행 에이전트는 매 루프 단계마다 같은 비용이 누적되고 복리로 불어납니다.

지배적인 비용 동인은 입력 토큰입니다. 매 턴 모델에 다시 올라가는 누적 컨텍스트가 호출마다 과금되기 때문입니다. 업계 추정으로 10회 반복 루프는 단일 패스 대비 토큰 소비가 530배까지 늘고, 추론이 에이전트 시스템 비용의 8090%를 차지한다고 봅니다(추정).

세 실패 모드는 모두 루프가 스스로 멈추지 못할 때 생깁니다. 검색을 언제 끝낼지, 도구를 몇 번까지 부를지, 어떤 출력을 버릴지를 모델 판단에만 맡기면 비용이 새는 쪽으로 쏠립니다. 그래서 멈추는 장치를 하네스가 직접 들고 있어야 합니다.

도구 호출 루프를 멈추는 장치

도구 호출 RAG의 기본 설계 원칙은 최대 호출 횟수 제약과 루프 종료 조건을 명시하는 것입니다. 모델이 검색·도구를 언제 호출할지 스스로 정하는 구조에서는 두 방향의 실패가 함께 나타납니다. 호출해야 할 때 호출하지 않는 실패와, 매 질의마다 과도하게 호출하는 낭비입니다. 둘 다 종료 조건이 약할 때 커집니다.

# 의사 코드: 도구 호출 루프의 종료 제어 (개념 설명용)
MAX_STEPS = 12
step = 0
while step < MAX_STEPS:                    # 호출 횟수 상한
    action = model.decide(context)         # 다음 행동 결정
    if action.is_final:                    # 모델이 종료를 선언
        break
    result = dispatch(action)              # 도구 디스패치·실행
    context = compact(context + result)    # 컨텍스트 압축
    if evaluator.met(goal, context):       # 별도 평가자가 종료 조건 판정
        break
    step += 1

여기서 MAX_STEPS는 무한 루프를 막는 마지막 안전망입니다. evaluator.met은 일을 한 모델이 아니라 작고 빠른 fresh 모델이 종료 조건을 판정하는 자리입니다. 이는 maker-checker 원칙으로, 큰 이체를 입력하는 사람과 승인하는 사람을 분리하듯 생성자와 검증자를 나눕니다. 코드를 쓴 에이전트는 자기 결과를 후하게 채점하기 때문입니다.

도구 호출은 새로운 실패 축을 만들므로 관측 지표도 따로 둡니다. 흔한 실패는 도구 선택 오류, 입력 형식 오류, 결과 해석 오류 세 가지입니다. 운영에서는 도구 호출 수, 실패율, 평균 루프 길이를 지속 관측해 셋이 비정상으로 튀는 순간을 잡습니다.

부작용이 있는 도구는 종료 제어와 별개로 권한 가드를 둡니다. 이메일 전송·파일 쓰기처럼 외부에 쓰기를 일으키는 도구는 사용자 확인 후에만 실행합니다. 권한이 있는 도구만 모델에 노출하고, 모든 호출을 감사 로그로 남깁니다. 안전 필터가 답변 내용만이 아니라 도구 호출 결정 자체를 검사 대상으로 삼아야 합니다.

검색을 도구로 끼워 넣기

검색 증강 생성(Retrieval-Augmented Generation, RAG)을 하네스에 넣는 방식은 두 갈래입니다. 검색을 파이프라인의 고정 단계로 두는 방식과, 모델이 필요할 때만 부르는 도구로 노출하는 방식입니다. 후자는 RAG의 제어권을 시스템에서 모델로 옮깁니다.

도구로 노출하면 모델 입장에서는 search(query, k) → documents 같은 시그니처를 가진 함수가 하나 더 생긴 셈입니다. 이때 도구 스키마 설계가 품질을 크게 좌우합니다. 인자를 질의 문자열 하나로만 노출하면 모델이 질의를 다듬는 부담을 전부 집니다. 날짜·도메인·권한 같은 필터 인자를 더하면 모델이 메타데이터 필터를 직접 활용합니다. 다만 인자가 너무 많으면 모델이 혼란을 겪거나 불필요한 필터를 매번 채우려 시도합니다.

같은 검색 인프라를 써도 에이전트 루프가 다르면 성능 분포가 통째로 이동합니다. 이는 코딩 벤치마크의 '모델 × 하네스' 행렬과 같은 형태로, 하네스 계층만 바꿔도 점수가 움직인다는 관찰로 이어집니다. 모델을 그대로 두고 하네스 계층만 손봐 같은 벤치마크 점수가 올랐다는 커뮤니티 보고도 있습니다.

하네스 코드 자체를 최적화 대상으로 보는 연구도 나왔습니다. 이런 관점은 하네스를 '어떤 정보를 저장·검색·제시할지 결정하는 코드'로 정의하고, 피드백을 요약으로 압축하지 않고 원형으로 유지하며 하네스를 탐색합니다.

루프 엔지니어링이라는 한 층 위

프롬프트, 컨텍스트, 하네스 위에 한 층이 더 있습니다. Addy Osmani가 루프 엔지니어링이라 명명한 관점으로, 사람을 일하는 위치에서 빼내 일을 시키는 시스템 자체를 설계하는 것입니다. 하네스가 한 턴을 잘 돌게 한다면, 루프 엔지니어링은 그 턴을 스케줄에 걸어 반복으로 만듭니다.

한 턴은 다섯 가지 move로 이뤄집니다. 발견(discovery), 인계(handoff), 검증(verification), 영속화(persistence), 스케줄링(scheduling)입니다. 이 중 가장 코너를 자르기 쉬우면서 가장 건너뛰면 안 되는 것이 검증입니다. 진짜 체크가 없는 루프는 자기 자신에게 끄덕이는 에이전트일 뿐입니다.

여기서 컨텍스트와 메모리를 구분해야 합니다. 컨텍스트는 이번 라운드에 모델이 보는 것으로, 윈도우가 비워지면 함께 사라집니다. 메모리는 라운드와 날짜를 가로질러 지속하는 상태로, 마크다운이나 보드처럼 대화 밖에 적어 둔 것입니다. 루프의 진행 기록을 컨텍스트 윈도우에만 두면 한 번의 새로고침으로 전부 잊습니다.

정리

에이전트 하네스는 모델 호출을 감싸 도는 런타임 루프이며, 도구 실행·컨텍스트 관리·상태 영속화·안전 검증 네 일로 나뉩니다. 작업이 길수록 신뢰성은 모델보다 하네스 설계에 제약되고, 루프가 길어지면 입력 토큰 비용이 복리로 불어나며 검색 반복·도구 폭주·컨텍스트 과적으로 샙니다. 그래서 최대 호출 횟수와 종료 조건, 별도 평가자에 의한 maker-checker 검증, 도구 호출 지표 관측이 기본 설계로 들어갑니다. 검색을 도구로 노출하면 제어권이 모델로 옮겨 가므로 스키마 설계가 품질을 좌우하고, 같은 검색 인프라라도 하네스가 다르면 성능 분포가 이동합니다. 한 층 더 올라간 루프 엔지니어링은 이 턴을 스케줄에 걸어 반복으로 만들되, 컨텍스트와 메모리를 구분하고 검증 move를 건너뛰지 않을 때 비로소 작동합니다.