AI에서의 에이전트 하네스(Agent Harnesses) 이해하기
에이전트 하네스는 AI 모델을 감싸서 자율적인 에이전트로 기능하는 데 필요한 구조, 도구 및 지침을 제공하는 소프트웨어 환경입니다. 가공되지 않은 AI 모델이 "intelligence"를 제공한다면, 하네스는 운영 프레임워크를 제공합니다. 즉, 모델의 가중치(weights)와 실질적이고 작업 지향적인 애플리케이션 사이의 가교 역할을 합니다.
에이전트 하네스의 4가지 핵심 구성 요소
기능적인 에이전트 하네스는 일반적으로 모델이 사용자와 외부 세계와 상호작용하는 방식을 제어하는 네 가지 주요 기술 계층으로 구성됩니다.
1. 시스템 프롬프트(System Prompt)
시스템 프롬프트는 에이전트의 페르소나, 규칙 및 행동 지침을 정의하는 기초적인 지침 세트 역할을 합니다. 일부 프론티어 모델에서 발견되는 내장된 학습 데이터나 "soul documents"와 달리, 시스템 프롬프트는 모든 요청과 함께 대화에 주입됩니다. 이를 통해 하네스는 기본 모델을 재학습시킬 필요 없이 특정 문맥 내에서 모델이 어떻게 행동해야 하는지 지시할 수 있습니다.
2. 도구(Tools)
도구는 모델이 텍스트 생성 이외의 작업을 수행하기 위해 "호출"할 수 있는 코드로 작성된 실행 가능한 기능입니다. 하네스는 웹 검색, 코드 실행 환경 또는 이메일 작성과 같은 이러한 도구들을 위한 소프트웨어를 제공하고 이를 모델에게 설명합니다. 결정적으로, 하네스는 도구를 언제 사용할지 지시하지 않습니다. 대신 도구를 사용할 수 있게 만들고 모델이 주어진 작업에 어떤 도구가 적절한지 스스로 결정하도록 합니다.
3. 에이전틱 루프(Agentic Loops)
에이전틱 루프는 반복적인 추론과 자기 수정을 가능하게 하는 프레임워크입니다. 단일 프롬프트-응답 상호작용 대신, 하네스는 모델이 다음과 같은 과정을 수행할 수 있도록 합니다:
- 요청을 분석합니다.
- 도구를 실행합니다 (예: 웹 검색).
- 결과를 검토합니다.
- 결과가 충분한지 또는 다른 도구 호출이 필요한지 결정합니다.
- 목표가 달성될 때까지 이 과정을 반복합니다.
4. 번역 계층(Translation Layer)
번역 계층은 모델 불가지론(model agnosticism)을 제공하여, 단일 하네스가 다양한 AI 모델(예: Anthropic, OpenAI 또는 open-weight 모델 간의 전환)과 작동할 수 있도록 합니다. 이 계층은 벤더 종속성(vendor lock-in)을 방지하고 사용자가 동일한 도구 세트와 시스템 프롬프트를 유지하면서 서로 다른 모델의 비용과 성능을 비교할 수 있게 합니다.
사용자 주도권 및 오픈 소스 하네스
하네스를 소유하는 것은 독점적인 AI 애플리케이션을 사용하는 것과 구별되는 중요한 차이점입니다. 사용자가 하네스를 로컬에서 실행할 때, 데이터, 세션 기록 및 에이전트의 특정 구성에 대한 제어권을 유지할 수 있습니다.
Pi, OpenClaw, OpenCode, 그리고 Hermes와 같은 오픈 소스 하네스는 사용자가 확장 기능이나 수정된 시스템 프롬프트를 통해 에이전트를 커스터마이징할 수 있도록 합니다. 예를 들어, Pi 하네스는 최소한의 기능으로 설계되어, 사용자가 에이전트를 주식 트레이더나 소프트웨어 팩토리와 같은 전문화된 도구로 변환하는 확장 기능을 구축하고 공유할 수 있도록 합니다.
기술적 관점 및 산업적 비유
업계 실무자와 개발자들은 하네스를 AI 에이전트의 "electronics" 또는 "chassis"로 간주합니다. 모델과 하네스 사이의 관계를 명확히 하기 위해 다양한 비유를 사용합니다:
- 자동차 비유: 모델은 엔진, 하네스는 섀시, 토큰은 연료, 그리고 결과물인 에이전트는 자동차입니다.
- 하드웨어 비유: 모델은 뇌세포의 연결을 나타내며, 하네스는 뇌가 세상과 상호작용하는 데 필요한 나머지 모든 것을 나타냅니다. -n도구 비유: 모델은 말과 같고, 하네스는 그 힘을 특정 목표로 유도하기 위해 사용되는 안장과 고삐입니다.
구현을 통한 엔지니어링 통찰력
회계와 같은 전문 분야를 위해 하네스를 구현하는 개발자들은, 도구와 가드레일(guardrails)을이 포함된 유연한 하네스를 제공하는 것이 매우 규정적인 "skills"나 지침의 목록을 만드는 것보다 종종 더 효과적이라는 점을 언급했습니다. 프론티어 모델은 통제된 환경 내에서 문제를 독립적으로 추론할 수 있는 도구를 제공받을 때, 경직된 스크립트보다 더 나은 성능을을 보여줍니다.
일부 개발자들은 또한 에이전틱 루프의 신뢰성을 높이기 위해, 데이터가 올바르게 형식화되었는지 확인하는 도구 호출 전 검증(pre-tool call validation)과 출력을 확인하는 도구 호출 후 검증(post-tool call validation)과 같은 "가드레일"의 중요성을 강조합니다.
Sources
관련
- Dispatch
- Dispatch
- 프로젝트
- Dispatch
- 프로젝트