에이전트 성과를 가르는 하네스 설계

세 줄 요약

무슨 변화/핵심이슈인가? 에이전트 성과는 모델 자체보다 웹 검색·파일 검색·함수 호출·컴퓨터 사용 같은 툴과 권한을 묶는 하네스(harness) 설계에 더 크게 좌우될 수 있다.
왜 중요한가? 같은 미션이라도 브라우저/파일/실행 환경 제약과 세션·컨텍스트 운영 방식 차이로 “완주율”이 흔들려, 벤치마크와 실전 결과가 어긋날 수 있다.
독자는 뭘 하면 되나? 모델 비교 전에 (1) 미션을 단계로 쪼개고 (2) 단계별 필요 툴·권한을 표로 만들고 (3) 세션/컴팩션과 중단 규칙을 먼저 고정한 뒤, 하네스까지 포함해 스택을 점검하라.

리서치부터 이미지 생성, 발행까지 한 번에 끝내려던 에이전트가 “모델은 똑똑한데” 마지막 단계에서 멈추는 경우가 있다. 브라우저가 없거나, 파일을 못 읽거나, 실행 환경이 막혀서다. 그래서 에이전트 성과를 가르는 요인으로 모델의 ‘지능’보다 하네스—툴 접근, 권한, 런타임, 오케스트레이션 설계—를 보는 관점이 설득력을 얻고 있다.

예: 한 팀이 자료를 모아 글을 만들고 게시 화면까지 자동화하려 한다. 검색과 파일 접근은 되는데 화면 제어가 막혀 게시 단계에서 멈춘다. 반대로 화면 제어는 되지만 파일 검색이 없어서 근거를 못 끌어와 품질이 흔들린다. 병목은 추론이 아니라 권한과 도구에서 생긴다.

핵심은 이렇다. 같은 미션이라도 어떤 스택은 내장 웹 검색과 파일 검색, 함수 호출, 원격 MCP 서버 같은 도구를 “tools”로 붙일 수 있고, 어떤 스택은 화면 제어(컴퓨터 사용)를 베타로 열어둔다. 반대로 어떤 환경은 코드 실행을 제공하지만 제약을 분명히 둔다. 벤치마크 점수만으로는 설명하기 어려운 차이가 “도구를 어디까지, 어떤 규칙으로 쓸 수 있나”에서 생긴다.

현황

성공·실패가 모델 성능만으로 갈리지 않고, 툴 접근과 제약에서 갈리는 사례가 늘면서 하네스 구성요소가 문서에서 더 분명하게 드러나고 있다. OpenAI API 문서는 Responses API에서 내장 Tools(웹 검색, 파일 검색)와 개발자 정의 함수 호출, 원격 MCP 서버 연동을 모두 “tools”로 묶어 확장한다고 설명한다. 즉 모델이 답만 하는 것이 아니라, 검색·조회·실행을 호출하는 런타임을 전제로 설계를 시작한다는 뜻이다.

Anthropic은 Messages API에서 Tool use(함수/툴 호출)를 제공하고, 별도 베타 헤더가 필요한 Computer use로 스크린샷과 마우스/키보드 제어를 지원한다고 문서에 적었다. bash·text editor와 조합하는 흐름도 안내한다. 동시에 bash 도구는 “지속되는 bash 세션”을 제공하지만 제한도 명시한다. 예를 들어 대화형 명령을 지원하지 않고 GUI 앱을 실행하지 못한다는 제약이 문서에 포함돼 있다.

Google Gemini API는 Function calling과 Code execution(코드 생성·실행), 그리고 Google Search 기반 Grounding 조합을 제공한다고 정리된다. 여기서도 “코드 실행이 제공된다”는 사실만으로 충분하지 않다. 코드 실행 환경과 라이브러리 등 제약을 명시한다는 점이 설계의 출발점이 된다.

컨텍스트(단기 기억) 운영도 하네스의 일부로 문서화되기 시작했다. OpenAI Cookbook은 Agents SDK에서 Session이 히스토리 처리와 연속성을 대신하며, session.run(...)을 반복 호출하는 패턴을 소개한다. 히스토리가 커지면 OpenAIResponsesCompactionSession 같은 컴팩션(요약·압축)으로 관리할 수 있고, 스트리밍/비동기에서 auto-compaction이 스트림 종료를 지연시킬 수 있으니 저지연이 필요하면 자동을 끄고 턴 사이 유휴 시간에 수동 compaction을 호출하라고 안내한다.

또 하나의 확인 가능한 기준점은 문서에 적힌 날짜다. OpenAI 도움말 문서는 2025년 3월 11일 기준으로 새 Agents 플랫폼의 빌딩 블록을 공개했다고 적으면서 Responses API와 Web Search, File Search, Computer Use 같은 Tools를 함께 언급한다. 이 문구만 놓고 보면 “에이전트=툴 호출+런타임” 관점이 제품/문서 레벨로 올라왔다는 해석이 가능하다. 다만 세부 권한 모델은 문서 범위 밖의 추가 확인이 남는다.

분석

에이전틱 시스템을 “리서치→이미지→발행” 같은 동일 미션으로 비교하면, 벤치마크가 놓치는 구간이 드러난다. 리서치는 웹 검색이 있으면 안정화되지만, 파일 검색이 없으면 내부 문서로 근거를 끌어오지 못한다. 이미지 단계는 별도 생성기나 함수 호출로 우회할 수 있어도, 발행은 브라우저 자동화나 외부 API 호출 권한이 없으면 막힌다. 이때 모델이 더 강해도, 호출할 수 있는 도구가 없으면 결과물은 멈춘다.

운영 측면에서는 “강한 모델이 더 오래 헤맨다”는 문제가 생길 수 있다. 탐색을 오래 하면서 비용과 시간이 늘고, 타임아웃이나 중단 규칙이 없으면 파이프라인이 무한 루프처럼 보일 수 있다. 공식 문서가 재시도·체크포인팅·타임아웃 권장 패턴을 얼마나 구체적으로 제시하는지는 제품/문서별로 차이가 있을 수 있다. 다만 이번 텍스트에서 인용한 범위만으로는 그 수준을 단정하기 어렵다. 그래서 팀이 하네스 레벨의 안전장치(중단 조건, 대체 경로, 인간 승인 지점)를 직접 설계해야 한다.

또한 하네스를 두껍게 만들수록 공격면이 커질 수 있다. 원격 MCP 서버 연동은 확장성을 주지만, 권한 위임·승인 모델·토큰 범위 같은 세부 항목이 제품마다 다를 수 있다. 이 글에 포함된 스니펫만으로는 제품 간 구체 비교가 어렵다. Computer use 같은 화면 제어형 도구는 자동화 범위를 넓히지만, 실패 시 복구가 어렵고 관찰 가능성(왜 클릭했는지, 무엇을 인식했는지)을 별도로 설계해야 한다.

실전 적용

하네스 설계는 “모델 고르기”보다 먼저 해야 한다. 먼저 미션을 단계로 쪼개고(입력→근거 수집→정리→산출→배포), 각 단계가 요구하는 툴을 체크한다. 웹 검색이 필요한지, 파일 검색이 필요한지, 함수 호출로 내부 시스템을 호출할지, 컴퓨터 사용(화면 제어)이 필요한지, 코드 실행이 필요한지부터 확정한다. 그 다음에야 모델 교체의 효과를 해석하기가 쉬워진다. 같은 모델도 하네스가 바뀌면 동작이 달라질 수 있기 때문이다.

오늘 바로 할 일:

미션을 단계로 나누고 각 단계에 필수 툴(웹 검색·파일 검색·함수 호출·컴퓨터 사용·코드 실행)을 한 줄씩 매핑하라.
session.run(...) 반복 패턴을 적용하되, 스트리밍/비동기에서 지연이 문제면 auto-compaction을 끄고 턴 사이에 수동 compaction을 호출하라.
각 단계에 중단 조건과 대체 경로(툴 실패 시 다른 툴, 또는 사용자 승인 요청)를 문서로 고정한 뒤 하네스까지 포함해 비교하라.

FAQ

Q1. “툴 호출 지원”이면 다 같은 에이전트인가?
A. 그렇지 않다. OpenAI는 Responses API에서 내장 Tools(웹 검색, 파일 검색), 개발자 함수 호출, 원격 MCP 서버를 “tools”로 제공한다고 문서에 쓴다. Anthropic은 Tool use 외에 Computer use(베타)로 화면 제어를 제공하고, bash 도구는 대화형 명령과 GUI 앱 실행을 제한한다고 명시한다. “지원 여부”보다 “권한 범위와 제약”이 결과를 바꾼다.

Q2. 벤치마크가 높은 모델을 쓰면 하네스 문제도 줄어드나?
A. 줄어들 수는 있지만 보장하기 어렵다. 하네스가 막히면 추론이 좋아도 실행이 멈춘다. 또한 탐색을 오래 하는 모델은 운영 규칙(타임아웃, 중단, 재시도)을 설계하지 않으면 효율이 떨어질 수 있다.

Q3. 컨텍스트가 길어질 때는 무엇부터 손봐야 하나?
A. 세션 기반 운영을 먼저 정리하는 편이 안전하다. OpenAI Cookbook은 Session이 히스토리 관리와 연속성을 대신하고, 히스토리가 커지면 컴팩션(요약·압축)으로 관리할 수 있다고 설명한다. auto-compaction이 스트림 종료를 지연시킬 수 있으니, 지연이 중요하면 수동 컴팩션 운영을 검토하라.

결론

에이전트의 실전 성과는 “더 똑똑한 모델”만으로 설명되지 않고, “더 잘 설계된 하네스”의 영향을 크게 받는다. 웹 검색·파일 검색·함수 호출·컴퓨터 사용·코드 실행을 어떤 권한과 제약으로 묶을지, 그리고 세션·컴팩션 같은 운영 규칙을 어떻게 둘지부터 고정하면 벤치마크와 실전의 간극을 줄이는 데 도움이 된다. 이후에는 각 플랫폼이 툴 권한의 세부 범위와 승인 모델을 얼마나 투명하게 문서화하는지 확인할 필요가 있다.

Aionda

에이전트 성과를 가르는 하네스 설계

세 줄 요약

현황

분석

실전 적용

FAQ

결론

다음으로 읽기

참고 자료

업데이트 받기