에이전트 하니스 vs 프레임워크, 뭐가 다른가요?
TMT만약 요즘 여기저기서 “에이전트 프레임워크(agent framework)“랑 “에이전트 하니스(agent harness)“라는 말을 듣는데, 둘의 차이를 잘 모르겠다면 이 글이 도움이 될 거예요. 두 용어는 비슷하게 들리지만 같은 뜻은 아닙니다. 저는 에이전트 프레임워크인 @crewAIInc에서 일한 경험이 있어서, 둘 사이 경계가 어디에 있는지 어느 정도 감이 있습니다.
에이전트 프레임워크랑 에이전트 하니스는, “얼마나 틀과 규약이 강하게 정해져 있느냐”라는 스펙트럼에서 서로 다른 자리에 놓입니다. 에이전트를 만드는 입장에서는, 이게 어디에 위치하느냐에 따라 “어디까지를 내가 책임지고, 어디부터를 도구에 맡길 수 있는지”가 달라지기 때문에 이 구분이 중요합니다.
에이전트 개발 과정을 하나의 직선으로 펼쳐 보자고 하면, 맨 왼쪽 끝에는 아무 추상화도 없는 날것의 코드가 있습니다. 각종 API를 직접 호출하고, 상태를 스스로 관리하고, 필요한 부품을 전부 바닥부터 만들어야 하는 단계죠. 자유도는 최대지만, 책임도 전부 본인이 떠안는 구간입니다.
그 중간쯤에 에이전트 프레임워크가 있습니다. 기본적인 구조와 추상화를 제공해 주긴 하지만, 여전히 결정해야 할 게 많습니다. 어떤 메모리 시스템을 쓸지, 어떤 툴들을 붙일지, 오케스트레이션 로직을 어떻게 짤지 등을 직접 고릅니다. 프레임워크는 “컴포넌트들이 어떻게 연결되어야 하는지”에 대해 자기만의 관점을 갖고 있지만, 모듈식이라 마음에 안 드는 부분은 갈아 끼울 수 있습니다.
맨 오른쪽 끝에는 에이전트 하니스가 있습니다. 이쪽은 설계 방향이 가장 강하게 정해져 있어, 거의 모든 게 미리 구워져 있는 상태입니다. API 키만 넣고, 몇 가지 툴만 가리켜 주면 바로 돌아갑니다. 메모리, 컨텍스트 관리, 에이전트 루프, 안전장치 같은 것들이 이미 전부 정해져 있고, 그 기본 설계를 그대로 받아들이고 쓰는 구조에 가깝습니다.
프레임워크는 에이전트를 만들 때 쓸 수 있는 추상화 레이어를 제공합니다. 역할, 태스크, 도구 같은 걸 어떻게 정의할지, 에이전트들이 순차적으로 일할지, 계층적으로 나뉘어 일할지 등 협업 방식을 정하는 건 전부 여러분 몫입니다. 프레임워크는 LLM 호출, 도구 출력 라우팅, 실행 루프 관리 같은 “배관 작업”을 대신 처리해 줄 뿐이고, 전체 아키텍처에 대한 결정권은 여전히 여러분에게 있습니다.
프레임워크는 “빌딩 블록이 어떤 모양이어야 하는지”에 대해 나름의 관점을 갖고 있습니다. 메모리 추상화가 있고, 도구 인터페이스가 있고, 태스크 구조가 있죠. 하지만 이 구성 요소들은 교체 가능하게 설계됩니다. 기본 메모리 구현이 마음에 안 들면 직접 만든 구현으로 바꿀 수 있고, 다른 LLM 제공자를 쓰고 싶으면 설정만 바꿔 끼우면 됩니다. 프레임워크는 표준 인터페이스를 줄 뿐이고, 그걸 어떻게 조합해 시스템을 만들지는 결국 여러분이 정해야 합니다.
이 모듈성이 바로 핵심입니다. 프레임워크는 “에이전트를 그냥 쓰고 싶은 사람”이 아니라 “직접 만들어 보고 싶은 사람”을 위한 도구입니다. 각 부품이 어떻게 맞물리는지 이해하고 있어야 하고, 어떤 조합을 쓸지 스스로 선택해야 하죠.
반대로, 하니스는 이런 빌딩 블록을 주지 않습니다. 대신 “완성된 시스템”을 통째로 줍니다.
최근 사례로 자주 언급되는 게 @openclaw 입니다. 몇 주 전에 크게 화제가 됐던 그 프로젝트는 전형적인 하니스입니다. 코드를 내려받고 API 키만 넣으면, WhatsApp이나 Telegram 같은 여러 플랫폼에서 바로 대화할 수 있는 에이전트를 얻게 됩니다. 메모리는 이미 처리돼 있고, 컨텍스트 관리도 알아서 되고, 에이전트 루프도 짜여 있고, 도구 호출, 권한 처리, 상태 영속성까지 전부 내장되어 있습니다.
여기서는 메모리 시스템을 직접 구성하지도 않고, 툴을 어떻게 등록할지, 에이전트가 에러에서 어떻게 회복할지 같은 걸 신경 쓰지 않습니다. 그런 설계 결정은 하니스를 만든 사람이 이미 내려 둔 것입니다. 여러분이 할 일은 “이 에이전트에게 어떤 일을 시킬지”만 정하고 실행시키는 정도에 가깝습니다.
그게 곧 트레이드오프입니다. 바로 쓸 수 있고 곧장 잘 동작하는 시스템을 얻는 대신, 내부 동작 방식을 마음대로 바꾸기는 어려워집니다. 하니스는 거의 모든 부분에 대해 강한 의견을 갖고 있고, 여러분은 그 의견을 받아들이는 조건으로 이 도구를 쓰게 되는 셈입니다.
이 스펙트럼이 중요한 이유는, 각 지점이 서로 다른 문제 유형에 대응하기 때문입니다.
프로토타이핑을 하거나, 여러 방식을 실험해 보거나, 특정한 요구사항에 맞는 커스텀 시스템을 만들고 싶다면 프레임워크가 필요합니다. 구성 요소를 바꿔 끼우고, 여러 접근을 시험해 보고, 세부 구현을 직접 통제해야 하기 때문입니다. 프레임워크는 구조를 제공하되 특정 구현에 묶어 두지는 않습니다.
반대로, 특정한 문제를 위해 “지금 당장 안정적으로 돌아가는 것”이 필요하다면 하니스가 더 맞습니다. 여기서는 속도를 얻는 대신 제어권 일부를 포기합니다. 컨텍스트 관리, 내구성 있는 실행, 에러 복구 같은 어려운 문제들은 이미 해결돼 있고, 여러분은 그 “해결책”을 그대로 가져다 쓰는 쪽이죠.
요약하면, 프레임워크는 만드는 사람(빌더)을 위한 것이고, 하니스는 사용하는 사람(유저)을 위한 것입니다.
이 말이 어느 한 쪽이 더 뛰어나다는 뜻은 아닙니다. 각자 풀고자 하는 문제가 다를 뿐이고, 여러분이 지금 풀려는 문제가 무엇이냐에 따라 선택지가 달라집니다. 그리고 이 둘 사이 경계는 항상 깨끗하게 나뉘지도 않고, 꼭 그래야 할 필요도 없습니다.
실제로 일부 프레임워크들은 점점 하니스 쪽 기능을 흡수하고 있습니다. 좋은 예가 @LangChain 입니다. 이들은 Deep Agents라는 기능을 내놓으면서, 이를 자사 프레임워크 위에 올라가는 “에이전트 하니스”라고 명시적으로 부릅니다. Deep Agents는 기본 제공 플래너 도구, 컨텍스트 관리를 위한 파일 시스템 접근, 서브에이전트 스폰, 메모리 영속성 등을 내장하고 있습니다. 내부적으로는 여전히 LangChain을 쓰지만, Deep Agents를 사용하면 모든 부품을 일일이 배선하지 않아도 되는 “건전지 포함(batteries-included)” 기본값 세트를 얻게 됩니다.
LangChain은 자사 스택을 세 레이어로 나눠 설명합니다. LangChain(원래 라이브러리)은 프레임워크이고, LangGraph는 실행, 상태 관리, 내구성을 담당하는 “에이전트 런타임”입니다. Deep Agents는 이 둘 위에 올라가는 하니스죠. 한 회사가 에이전트 조합을 위한 프레임워크, 그것을 안정적으로 돌리기 위한 런타임, 바로 꺼내 쓸 수 있는 하니스까지 전체 스펙트럼을 한 번에 커버하는 구조입니다.
이건 프레임워크 회사가 스펙트럼의 오른쪽, 하니스 쪽으로 이동하는 사례입니다. Deep Agents는 여전히 모듈식이라 백엔드를 바꾸거나, 도구를 재구성하거나, 프롬프트를 다듬을 수 있습니다. 하지만 더 이상 모든 조각을 직접 조립하지 않아도, 곧장 쓸 수 있는 시스템을 제공한다는 점이 다릅니다.
반대로, 하니스라고 해서 생각만큼 완전히 잠겨 있는 것도 아닙니다. 다시 OpenClaw를 예로 들면, 기본값은 매우 강한 의견을 갖고 있지만 소스 코드를 내려받으면 구현을 바꿀 수 있습니다. 메모리 동작 방식을 바꾸고, 에이전트 루프를 수정하고, 도구 처리 로직도 갈아엎을 수 있습니다. 다만 대부분의 사람들은 그럴 필요를 못 느끼는 겁니다. 기본 설정이 이미 잘 동작하기 때문이죠.
결국 차이는 “처음 시작할 때 이미 무엇이 결정돼 있느냐”의 문제입니다. 하니스는 많은 결정이 이미 구워진(baked in) 상태로 배송되고, 프레임워크는 대신 선택지를 눈앞에 펼쳐 둡니다. 하니스를 쓰면 대부분의 결정을 받아들이고, 가장자리를 조금만 만지작거리는 식으로 쓰게 됩니다. 프레임워크를 쓰면, 그 결정들을 직접 하나씩 내려서 시스템을 조립해야 합니다.
어떤 문제를 풀고 있는지가 어떤 도구를 선택할지를 결정합니다. 그리고 어떤 경우에는(사실 꽤 많은 경우에) 아예 에이전트 프레임워크를 건너뛰고, 모델 엔드포인트를 직접 두드려서 단순한 ReAct 에이전트를 만들어 쓰는 편이 더 나을 때도 있습니다.
결국 얼마나 많이 이미 만들어져 있기를 원하느냐에 따라 어떤 걸 고를지가 갈립니다.