던스커버리 | Dawnscovery

구글 클라우드 사례로 본 에이전트 하네스(Harness)

거대 언어 모델(LLM)의 발전 속도를 보면 감탄이 절로 나온다. 벤치마크 점수는 매달 갱신되고, 복잡한 코딩과 추론 문제를 척척 풀어낸다.

하지만 최신 프론티어 모델을 가져와 실제 업무 시스템이나 자율 에이전트에 붙이는 순간, 수많은 개발팀이 거대한 벽에 부딪힌다.

모델이 엉뚱한 리눅스 명령어를 실행해 환경을 망가뜨리거나, 외부 API 호출 도중 네트워크가 끊겼을 때 어디서부터 다시 시작해야 할지 몰라 헤매고, 최종 답변은 그럴듯하지만 내부 실행 과정에서 수많은 보안 규칙을 위반하는 현상이 발생하기 때문이다.

최근 구글 클라우드 테크(Google Cloud Tech)는 이러한 에이전트 구축의 한계를 돌파하기 위한 핵심 개념으로 에이전트 하네스(Agent Harness) 아키텍처를 집중적으로 조명했다.

구글 클라우드의 기술 블로그와 에이전트 프레임워크 연구를 바탕으로, 왜 지금 AI 엔지니어링의 초점이 단순한 모델 자체보다 하네스로 이동하고 있는지 알기 쉽게 정리했다.

1. 하네스(Harness)란 무엇인가?

하네스(Harness)라는 단어는 원래 말에게 씌우는 마구(고삐, 굴레, 안장)나 암벽 등반가가 착용하는 안전벨트를 뜻한다.

강력한 힘을 가진 야생마나 거대한 엔진이 아무리 뛰어나도, 이를 통제하고 사람과 안전하게 연결해 주는 장치가 없다면 아무런 일도 할 수 없다.

시스템 구성 요소 자동차 비유 AI 시스템에서의 실제 역할
LLM 두뇌 (Model) 고출력 엔진 (Engine) 막강한 추론 및 자연어 처리 능력 제공
에이전트 하네스 (Harness) 차체, 브레이크, 에어백, 블랙박스 샌드박스 격리, 권한 통제, 오류 복구, 궤적 평가

AI 엔지니어링에서 하네스란 “LLM이 실제 환경에서 도구를 호출하고, 데이터를 다루며, 장시간 작업을 자율적으로 수행할 수 있도록 감싸주는 런타임 실행 환경이자 안전 통제 프레임워크”라는 개념을 의미한다.

2. 구글 자료를 바탕으로 재구성한 하네스의 역할

먼저 단서를 달아야 한다. 아래 세 항목은 구글이 하네스의 정의로 제시한 분류가 아니다. 구글이 하네스 개념 문서에서 직접 꼽는 메커니즘은 MCP 기반 도구 연결, 상태와 메모리 관리, 가드레일 세 가지다 [1]. 아래 표는 구글이 공개한 에이전트 런타임 Agent Executor의 기능 목록(Secure isolation, Trajectory branching, Durable execution)에서 [2] 런타임과 안전 축을 프로덕션 관점으로 다시 묶은 것이다.

핵심 기둥 담당 역할 세부 구현 메커니즘
1. 샌드박스 격리 실행
(secure-by-design sandbox)		 안전한 코드 및 도구 실행 • 요청마다 새로 뜨는 격리 환경
• 사용자 지정 격리 경계와 워크로드 정책 강제
2. 궤적(Trajectory) 분기
(Trajectory Branching)		 실행 경로 시험과 평가 • 체크포인트에서 궤적을 갈라 여러 경로 비교
• 입출력 전량이 하네스를 거쳐 모니터링·자동 평가 부착 용이
3. 상태 보존 및 복구
(Durable Execution)		 중단 없는 워크플로우 보장 • 장기 세션 단계별 체크포인트 저장
• 장애 이후 자동 재개 및 응답 백필

1) 안전한 일회용 샌드박스 격리 (Secure Sandboxing)

에이전트가 코드를 실행하거나 터미널 명령을 내릴 때, 운영체제나 본 서버를 직접 건드리게 두는 것은 극도로 위험하다.

구글은 자사 에이전트 런타임 Agent Executor가 구성요소를 설계상 안전한 샌드박스에 격리해, 악의적 활동이 서비스 전반을 침해하지 못하도록 돕는다고 설명한다. 에이전트가 코드를 생성하거나 여러 테넌트의 데이터를 동시에 다룰 때 특히 그렇다.

에이전트가 악성 스크립트를 잘못 실행하거나 치명적인 에러를 내더라도, 샌드박스만 폐기하고 새로 만들면 되므로 피해가 번지는 것을 크게 줄일 수 있다. 다만 구글도 이를 완전한 차단이 아니라 악의적 활동이 서비스 전반을 침해하지 못하도록 돕는 장치로 표현한다 [2]. 샌드박스 탈출은 여전히 실재하는 위협이다.

2) 추론 궤적(Trajectory) 기반 실시간 평가

기존의 AI 테스트는 “사용자의 질문에 맞는 정답을 내놓았는가?“라는 결과(Final Output)만 확인했다.

하지만 에이전트 시스템에서는 우연히 정답을 맞혔더라도, 그 과정에서 엉뚱한 DB를 뒤지거나 비효율적인 루프를 도는 침묵의 실패(Silent Failure)가 빈번하게 일어난다.

구글이 문서에서 밝힌 기능은 궤적 채점이 아니라 궤적 분기다 [2]. 체크포인트에서 에이전트의 결정 경로를 임의 지점에서 갈라, 맥락을 잃지 않은 채 여러 경로를 시험하고 비교할 수 있다. 하네스가 입출력을 전부 거치므로 모니터링과 자동 평가를 붙이기 좋은 지점이라는 것이 구글의 설명이다 [1].

3) 장기 실행 세션과 내구성 복구 (Durable Execution)

10단계, 20단계에 걸쳐 수십 분 동안 이어지는 복잡한 에이전트 워크플로우는 네트워크 순단이나 토큰 제한으로 언제든 끊어질 수 있다.

하네스와 무관하게 동작하도록 설계된 런타임 레이어인 Agent Executor는 각 단계마다 상태(State)를 안전하게 스냅샷으로 저장한다.

장애가 발생하면 처음부터 다시 비용과 시간을 들여 실행하는 대신, 직전 체크포인트에서 정확하게 세션을 이어받아 작업을 완수한다.

3. 프롬프트 래퍼 vs 에이전트 하네스 비교

단순히 프롬프트로만 제어하는 초기 래퍼 시스템과 엔터프라이즈급 하네스 시스템은 구조적으로 큰 차이를 보인다.

비교 항목 단순 프롬프트 래퍼 (Wrapper) 엔터프라이즈 에이전트 하네스 (Harness)
실행 환경 로컬 프로세스 직접 실행 (위험) 격리된 일회용 샌드박스 (안전)
품질 검증 최종 답변 텍스트만 육안 확인 실행 궤적 기록 및 시뮬레이션 환경에서의 자동 평가
오류 복구 실패 시 처음부터 다시 시작 체크포인트 기반 상태 복구 및 재시도
보안 통제 시스템 프롬프트(지시문)에 의존 샌드박스와 IAM 권한 경계로 런타임이 강제 차단
모델 교체성 모델 변경 시 프롬프트 전면 수정 하네스 규격 유지로 모델 무중단 스왑

4. 왜 하네스가 기업의 진짜 ’해자(Moat)’가 되는가?

최근 AI 생태계에서 가장 중요한 교훈 중 하나는 “기반 모델(Foundation Model)은 범용재(Commodity)가 되어가고 있다”는 점이다.

오늘 1등 모델이었던 Gemini가 내일은 Claude나 GPT로 바뀔 수 있다. 특정 모델의 파라미터나 API에만 강하게 결합된 시스템은 모델이 바뀔 때마다 붕괴 위험을 겪는다.

반면, 사내 권한 체계, 엄격한 샌드박스 규칙, 궤적 평가 메트릭, 복구 런타임이 견고하게 갖춰진 하네스 인프라는 어떤 모델이 시장에 등장하든 즉시 갈아 끼울 수 있는 회사의 영구적인 핵심 자산이 된다.

5. 마치며: 하네스 엔지니어링의 시대로

과거 2~3년이 “프롬프트를 얼마나 기가 막히게 작성하는가”를 다투는 프롬프트 엔지니어링의 시대였다면, 지금은 “모델을 어떤 안전망과 런타임 위에서 달리게 할 것인가”라는 질문을 설계하는 하네스 엔지니어링의 시대로 진화하고 있다.

신뢰할 수 있고 예측 가능한 자율 AI 에이전트를 프로덕션에 배포하고 싶다면, 모델의 크기만 고민할 것이 아니라 그 뒤를 든든하게 받쳐주는 하네스 체계를 먼저 점검해야 할 때다.

참고 자료

관련 글