에이전트 하네스(Agent Harness)는 거대 언어 모델(LLM)을 안전하게 감싸서 메모리, 도구, 실행 경계 및 결정론적 정책 집행(deterministic policy enforcement)을 관리하는 포괄적인 애플리케이션 계층입니다. 엔지니어들이 단순한 대화형 챗봇 구축에서 완전히 자율적인 AI 에이전트로 전환할 때, 보통 한 가지 결정적인 실수를 저지릅니다. 바로 거대 언어 모델(LLM)을 시스템 전체로 취급하는 것입니다.

현실은 상당히 다릅니다. LLM은 에이전트가 아닙니다. LLM은 추론 엔진(reasoning engine)을 제공할 뿐, 그 외의 것은 아무것도 제공하지 않습니다.

그 엔진을 중심으로 우리가 구축하는 나머지 모든 것—메모리, 도구의 실행, 계획 능력(planning capabilities), 컨텍스트 라우팅(routing of context), 그리고 보안 경계—이 바로 **에이전트 하네스(Agent Harness)**입니다.

에이전트 하네스가 중요한 이유

LLM이 자동차의 엔진이라면, 하네스는 스티어링 휠, 브레이크, 변속기 및 대시보드를 나타냅니다.

에이전트에게 운영 데이터베이스, 클라우드 인프라 또는 개인 고객 기록에 대한 접근 권한을 부여할 때, 모델을 안전하게 유지하기 위해 오로지 모델의 내부 프롬프트 지침에만 의존하는 것은 불충분합니다. 모델은 환각(hallucinate)을 일으키고, 적대적 입력(adversarial inputs, 예: 프롬프트 인젝션)에 취약하며, 본질적으로 비결정론적(non-deterministic)입니다. 만약 통제되지 않은 행동에 대한 유일한 방어책이 시스템 프롬프트에 적힌 _"데이터베이스를 삭제하지 마세요"_라는 문장뿐이라면, 귀하의 시스템은 프로덕션(production)에 투입될 준비가 되지 않은 것입니다.

강력한 에이전트 하네스는 비결정론적인 LLM에 부족한 결정론적 보장(deterministic guarantees)을 제공합니다. 이는 모델을 안전하게 감싸는 애플리케이션 계층 역할을 하며, 모델이 볼 수 있는 컨텍스트가 무엇인지, 어떤 도구를 호출할 권한이 있는지, 그리고 어떤 정책이 전체 실행을 제한하는지를 정확하게 관리합니다.

엔터프라이즈 에이전트 하네스의 아키텍처

엔터프라이즈 환경에서 완전한 에이전트 하네스를 정의하는 것은 단일 개발자가 애플리케이션 코드베이스에서 구현할 수 있는 범위를 훨씬 넘어섭니다. 대규모 엔터프라이즈 하네스는 다음과 같은 거대한 인프라 구성 요소와 교차합니다:

• Cloud IAM (Identity and Access Management, 클라우드 ID 및 액세스 관리)
• 기업 데이터 거버넌스 플랫폼 (Corporate Data Governance Platforms) (예: Microsoft Purview)
• 컴플라이언스 및 감사 파이프라인 (Compliance and Auditing Pipelines)
• 네트워크 보안 및 샌드박스 VPC (Network Security and Sandboxed VPCs)

완전한 구현은 조직의 특정 클라우드 아키텍처 및 보안 정책에 크게 의존하기 때문에, 이를 위한 단일하고 보편적인 코드베이스를 제공하는 것은 불가능합니다.

하지만 우리가 할 수 있는 일은 핵심 엔지니어링 개념을 구체적인 소프트웨어 디자인 패턴 (Software Design Patterns)으로 세분화하는 것입니다.

이 시리즈에서 기대할 수 있는 것

이 시리즈에서 저는 여러분이 자신만의 에이전트 하네스 (Agent Harness)를 구축할 때 고려해야 할 별도의 패턴 (Patterns) 모음을 공유할 예정입니다.

이 패턴들이 엔터프라이즈 배포의 모든 미세한 인프라적 뉘앙스를 다루지는 못하겠지만, 코드 내에서 에이전트를 효과적으로 제어하는 데 필요한 기초적인 소프트웨어 아키텍처 (Software Architectures)를 제공할 것입니다. 각 패턴에 대해 우리는 실질적인 구현 방식 (LangGraph와 같은 프레임워크 사용)을 살펴보고, OWASP, Google, Anthropic, Microsoft, OpenAI와 같이 신뢰할 수 있는 업계 발행사들이 수립한 용어 및 가이드라인을 사용하여 이를 하나로 엮을 것입니다.

우리는 각각 별도의 전용 문서에서 상세히 다룰 12가지 핵심 패턴을 탐구할 것입니다:

1. 도구 권한 브로커 (Tool Privilege Broker)
2. HITL 승인 게이트 (HITL Approval Gate)
3. 결정 추적 및 감사 (Decision Trace and Audit)
4. 비용 및 도구 예산 책정 (Cost and Tool Budgeting)
5. 레드액션 경계 (Redaction Boundary)
6. 프롬프트 인젝션 및 목표 하이재킹 (Prompt Injection and Goal Hijacking)
7. RAG 액세스 제어 및 출처 (RAG Access Control and Provenance)
8. 메모리 격리 (Memory Isolation)
9. 샌드박스 실행 (Sandboxed Execution)
10. 에이전트 평가 (Agent Evaluations)
11. CI/CD 평가 게이트 (CI/CD Evaluation Gates)
12. 에이전트 라이프사이클 프로필 (Agent Lifecycle Profile)

첫 번째 패턴인 추론 (Reasoning)과 행동 (Action) 사이의 경계를 정의하는 것부터 시작해 봅시다.