에이전트 하네스란 무엇인가: AI 에이전트를 움직이는 실행 환경의 정체

암벽 등반에서 하네스는 벨트와 스트랩으로 몸을 지지하고, 카라비너와 로프에 연결해 추락을 막고 등반 속도와 경로를 조절하는 장비다. 초크백이나 퀵드로 같은 도구를 걸어 쓸 수 있고, 산이나 코스가 달라져도 그대로 가져가 지형에 맞게 개조할 수 있다. 최근 AI 업계에서 자주 등장하는 '에이전트 하네스(agent harness)'라는 용어도 바로 이 등반 장비의 은유에서 출발한다. 소프트웨어 엔지니어에게는 익숙하지만 그 외의 실무자에게는 여전히 모호한 이 개념을, 개념 정의부터 실무적 함의까지 정리해 본다.

흔히 'AI 에이전트 = 모델 + 하네스'라는 단순화된 등식이 통용된다. 여기서 모델은 우리가 아는 대규모 언어 모델이고, 하네스는 그 모델이 실제로 일하도록 환경을 제공하는 소프트웨어다. 에이전트 하네스는 AI 모델을 감싸 하나의 '에이전트'로 만들어 주며, 최초의 활용처는 코딩이었다. 지금은 이메일, 채팅앱, 메신저 등 다양한 인터페이스로 확장되고 있다. 원문에 등장하는 사례로는 터미널에서 쓰는 Pi, iMessage나 채팅앱·이메일을 쓰는 OpenClaw, 이메일 중심으로 설계된 Lefos 등이 있다. 중요한 점은, 모델 자체는 사용자가 소유하기 어렵지만 하네스는 사용자가 직접 소유하고 개조할 수 있다는 것이다.

하네스가 하는 네 가지 일

인터페이스가 무엇이든 하네스는 대체로 네 가지 기능을 수행한다. 첫째는 시스템 프롬프트다. 이는 모델이 어떻게 응답할지 규율하는 지시문으로, 모든 요청과 함께 대화에 주입된다. 원문은 이를 모델의 학습 과정에 깊이 각인된 규칙과 구분한다. 예컨대 Claude Opus 4.5의 이른바 '소울 문서(soul document)'가 모델 내부에 내재화된 정체성이라면, 시스템 프롬프트는 신입 직원이 첫 출근날 받는 업무 지침에 더 가깝다. 아직 몸에 밴 것은 아니지만 그 일을 할 때 따라야 한다는 것을 아는 수준이다.

둘째는 도구(tool)다. 웹 검색, 코드 작성·실행, 이메일 작성처럼 코드로 구현된 기능을 모델이 '호출'할 수 있게 하네스가 정의하고 제공한다. 여기서 핵심은 하네스가 도구를 '언제 어떻게' 쓸지 지시하지 않는다는 점이다. 하네스는 도구를 명확히 설명해 사용 가능하게만 해두고, 그 판단은 모델 스스로에게 맡긴다. 셋째는 모델의 행동을 관장하는 프레임워크이며, 그 핵심이 바로 '에이전틱 루프(agentic loop)'다. 넷째는 서로 다른 AI 모델과 하네스를 연결해 주는 번역 계층이다.

에이전틱 루프와 번역 계층

루프의 작동을 원문의 예시로 살펴보자. 이메일 기반 하네스에 웹검색·코드작성·이메일작성 도구가 있고, 사용자가 '동네 초등학교들의 순위와 시험 성적을 비교해 추천해 달라'고 요청했다고 하자. 에이전트는 먼저 요청을 해석해 '초등학교'나 '동네'가 무엇을 뜻하는지 사전 학습으로 파악하고, 검색 쿼리를 구성해 최신 데이터를 가져온다. 여기서 결과가 충분치 않다고 스스로 판단하면 다시 검색을 시도한다. 이 '스스로의 재평가에 따른 재호출'이 루프의 첫 사례다. 데이터가 모이면 코드작성 도구로 스프레드시트를 만들어 계산과 정리를 하고, 그 결과를 원래 요청과 대조한다. 만족스럽지 않으면 다시 루프를 돈다. 즉 루프란 모델이 도구 실행 결과를 스스로 검토하고 다음 행동을 결정하며 목표에 수렴해 가는 반복 과정이다.

번역 계층은 실무적으로 가장 주목할 만한 부분이다. 이 계층 덕분에 하나의 하네스를 Anthropic, OpenAI, 혹은 비용 대비 성능이 좋은 오픈웨이트 모델에 두루 붙일 수 있고, 심지어 같은 루프 안에서 작업 성격에 따라 다른 모델을 섞어 쓸 수도 있다. 원문의 관점에서 이는 단순한 호환성 문제가 아니라 통제권의 문제다. 사용자가 하네스를 자기 컴퓨터에서 직접 운영하면, 같은 이메일을 여러 모델에 보내 결과와 비용(작업당 비용)을 한자리에서 비교하고, 기계와 나눈 대화 기록을 세 개의 앱에 흩어 놓는 대신 로컬에 모아 둘 수 있다. AI 랩이 제공하는 완제품 앱을 쓰는 대신 하네스와 관계를 맺음으로써 선택의 자유를 유지한다는 논리다.

개방성과 실무적 한계

하네스가 처음부터 개방적이거나 중립적이었던 것은 아니다. 최초로 대중화된 에이전트 하네스인 Claude Code는 모델 중립적 번역 계층이 아니라 Claude 모델로 코딩하기 위한 애플리케이션으로 출발했다. 이후 OpenClaw, OpenCode, Hermes, Pi 같은 무료 오픈소스 하네스가 늘고 있다. 글을 쓴 Earendil은 Pi를 중립적 하네스로 개발 중이라고 밝히며, Pi는 시스템 프롬프트가 짧고 도구가 최소화된 '길을 비켜 주는' 설계이고, 사용자들이 시스템 프롬프트를 바꾸거나 확장을 만들어 5,000개 이상을 서로 공유해 왔다고 소개한다.

다만 이 글이 특정 제품을 개발하는 회사의 관점에서 쓰였다는 점은 감안할 필요가 있다. '통제권을 랩에서 사용자에게로 되돌린다'는 서사는 매력적이지만, 로컬에서 여러 모델을 직접 운영하고 확장을 관리하는 일은 상당한 기술적 부담을 수반하며, 순위 비교 같은 예시도 실제 데이터 품질과 검증의 문제를 낙관적으로 건너뛴다. 그럼에도 '에이전트 = 모델 + 하네스'라는 틀, 그리고 시스템 프롬프트·도구·루프·번역 계층이라는 네 요소는 요즘 쏟아지는 AI 에이전트 제품들이 실제로 무엇으로 구성돼 있는지를 읽어 내는 실용적인 렌즈가 된다. 어떤 도구를 채택하든, 그 안에서 무엇이 모델이고 무엇이 하네스인지 구분하는 것만으로도 제품의 성격과 종속성을 훨씬 명료하게 판단할 수 있다.