AI에서 하네스란 정확히 무엇일까요?

최근에 OpenClaw가 하네스로 지칭되는 것을 보았습니다. 저는 “흥미롭군”이라고 생각했습니다. OpenClaw는 하네스가 아닙니다. 이는 에이전트 루프를 구동하는 에이전트 런타임입니다. 그렇다면 "하네스"라는 단어는 정확히 무엇을 의미할까요?

지금까지의 논의 경과

이 개념의 구조적 기준은 Birgitta Böckeler의 2026년 4월 문서에서 가져왔으며, 에이전트를 다음과 같이 명쾌하게 정의합니다: model + harness = agent. 이 문서에서는 스택을 빌더 하네스(툴과 함께 제공되는 내부 런타임)와 사용자 하네스(개발자의 사용자 정의 컨텍스트)로 나누었습니다. 이러한 정의는 2026년 2월에 이어졌던 논의의 흐름을 기반으로 발전한 것입니다. 당시 논의에는 AGENTS.md 컨텍스트 엔지니어링에 대한 Mitchell Hashimoto의 실용적인 접근 방식, 자동화된 배포를 위한 OpenAI의 내부 하네스 엔지니어링 개요, Böckeler의 요약 메모 원본 등이 포함됩니다.

외부에서 내부로 이어지는 5개 계층

에이전트에는 모델과 하네스 이상의 요소가 필요하다고 생각합니다. 저는 에이전트 런타임을 완전히 신뢰할 수 없다는 관찰에서부터 시작합니다. 에이전트 팩토리에서 생성된 코드의 소프트웨어 공급망 보안을 어느 정도 보장하려면, 출처 정보를 캡처하고 제어 범위를 벗어난 에이전트가 미칠 수 있는 영향을 제한할 수 있는 별도의 샌드박스 계층이 필요합니다.

저는 이 보안 에이전트 런타임 아키텍처를 외부에서 내부로 겹쳐진 마트료시카 인형과 같다고 생각합니다.

인프라 → 샌드박스 → 에이전트 하네스 → 런타임 → 모델

각 계층은 소유자, 장애 모드, 설계 원칙이 서로 다릅니다. 각 계층을 자세히 살펴보겠습니다.

계층 1: 인프라

인프라는 에이전트가 물리적으로 실행되는 환경입니다. GitHub Actions 러너, 쿠버네티스 포드 또는 가상 머신(VM) 등이 여기에 해당합니다. 이 계층은 컴퓨팅, 네트워킹, 리소스 관리에 관한 것이며, 사람들이 생각하는 것보다 훨씬 더 중요합니다.

하나의 에이전트에서 수십 개의 에이전트를 병렬로 실행하도록 확장할 때 어떤 일이 일어나는지 생각해 보세요. Roy Belio는 Andrej Karpathy의 autoresearch 시스템을 활용해 사람의 개입 없이 GPU 스케줄링 및 작업 오케스트레이션을 포함한 OpenShift AI 기반의 198개 자율 실험을 실행했습니다. 이는 하네스 문제가 아닙니다. 샌드박스 문제도 아닙니다. 바로 인프라 문제입니다. 플랫폼이 경합하는 리소스 요청을 관리하고, 동시 실행되는 에이전트가 서로의 리소스를 고갈시키지 않도록 하며, GPU 워크로드를 예약할 수 있나요?

GPU 스케줄링 자체가 핵심적인 인프라 분야로 자리 잡고 있습니다. Red Hat OpenShift 4.21은 워크로드가 단순 개수가 아닌 속성(모델, 메모리, 컴퓨팅 성능)별로 GPU를 요청할 수 있도록 지원하는 쿠버네티스 API인 동적 리소스 할당(DRA) 기능을 출시했습니다. 또한 컨테이너 간 GPU 공유를 지원하므로, 경량 추론 사이드카가 기기 전체를 점유하여 낭비하는 일을 방지합니다. 이는 샌드박스 정책, AGENTS.md 항목, 모델 선택과는 무관한 순수 인프라의 영역입니다. 플랫폼이 본연의 역할을 수행하는 것입니다.

계층 2: 샌드박스

샌드박스는 에이전트가 수행할 수 있는 작업을 제한하고, 문제가 발생할 경우 잠재적인 영향을 최소화합니다. 핵심은 격리입니다. 제 동료인 Marta Anon Ruiz는 이 계층을 "에이전트의 의도성 형성"이라고 설명했습니다. NVIDIA의 OpenShell과 같은 프로젝트가 이 계층에서 작동합니다. 소프트웨어 공급망 보안 관점에서 볼 때, 이는 주요 신뢰 경계입니다. rm -rf /특정 작업을 수행할 수 있는 에이전트와 그렇지 못한 에이전트의 차이, gh issue delete 또는 모든 GitHub 이슈를 읽을 수 있는 에이전트와 그렇지 못한 에이전트(또는 동일한 작업을 위해 자체 스크립트를 작성하고 실행할 수 있는 에이전트) 사이의 차이를 결정합니다.

인프라가 "에이전트가 어디에서 실행되는가?"를 묻는다면, 샌드박스는 "에이전트가 무엇에 접근할 수 있는가?"를 묻습니다. 이는 서로 다른 질문이며 그에 대한 답변도 다릅니다.

Red Hat은 제한된-v2 보안 컨텍스트 제약 조건(SCC), 기본 거부 이그레스 NetworkPolicies, 에이전트별 역할 기반 액세스 제어(RBAC)를 포함하여 쿠버네티스에서 AI 에이전트를 위한 탄력적인 가드레일을 구축하는 방법에 대한 상세 가이드를 발표했습니다. 이들은 각각 에이전트가 수행할 수 있는 모든 권한에서 시작하여 필요한 기능만 남을 때까지 권한을 제거하는 감산 방식의 제어입니다.

샌드박스 계층은 네트워크 정책보다 더 심층적인 영역을 다룹니다. Kata Containers 및 peer-pods를 기반으로 하는 Red Hat OpenShift 샌드박스 컨테이너는 이 계층의 핵심 기술로, 호스트로부터 에이전트 프로세스를 격리하기 위한 추가 단계를 수행합니다. 또한 실행 전에 출처를 확인할 수 있도록 에이전트 스킬에 대한 암호화 서명을 포함하여 위협과 솔루션을 살펴보는 에이전트 스킬 및 보안 위협에 관한 문서를 확인해 보세요. 에이전트의 툴체인에 주입된 서명되지 않은 스킬은 소프트웨어 공급망 공격에 해당합니다. 샌드박스 계층은 이러한 문제를 해결하는 데 도움이 됩니다.

NVIDIA의 OpenShell과 같은 프로젝트는 물론 일반 컨테이너 런타임에 내장된 보안 기본 요소들이 이 계층과 관련이 있습니다. 이 중 어느 것도 Hashimoto가 정의한 의미의 "하네스"가 아닙니다. 즉, 에이전트가 작업을 더 잘하도록 가르치는 것이 아니라 위험하거나 예기치 않은 작업을 하지 못하도록 방지하는 것입니다.

계층 3: 에이전트 하네스

이 계층은 Hashimoto가 기술한 내용이자 Birgitta Böckeler가 사용자 하네스라고 부르는 부분입니다. 이는 지원 계층으로, AGENTS.md 파일, 스킬, 사용자 정의 툴, 수작업으로 제작된 린터, 시스템 프롬프트, 우수한 테스트 제품군 등을 포함합니다. 에이전트가 작업을 올바르게 수행할 가능성을 높이기 위해 반복적으로 엔지니어링하는 요소들입니다.

Marco Rizzi의 정형화된 워크플로우를 통한 하네스 엔지니어링에 관한 문서는 "구조화된 입력, 구조화된 출력(structure in, structure out)"의 원칙을 명확히 보여줍니다. 이 문서에서는 LSP 및 MCP를 사용하여 프로젝트 구조를 스캔하고 컨텍스트 인식 프롬프트를 생성하는 방법을 설명합니다. 이는 에이전트에 단순히 할 일을 지시하는 것이 아니라, 작업을 잘 수행하는 데 필요한 구조적 정보를 제공하는 것입니다. 이것이 Birgitta의 용어로는 피드포워드 제어에 해당합니다.

툴 사용은 Birgitta Böckeler가 컴퓨팅 지향(computational guides)이라고 부르는 것을 가능하게 하는 하네스의 핵심 부분입니다. 툴 사용의 등장과 MCP라는 표준 토대는 의미 있는 에이전트 구현을 가능하게 했으며, 에이전트 런타임이 목표를 달성할 확률을 높여주었습니다. MCP를 활용한 효과적인 AI 에이전트 구축에서는 MCP에 대해 자세히 다루며, 하네스에 기업 리소스에 동적으로 접근할 수 있는 방법을 제공하여 에이전트 역량을 강화하는 방법을 보여줍니다.

하네스가 제대로 작동하는지 어떻게 알 수 있을까요? 바로 평가를 통해 확인합니다. Michael Dawson은 DeepEval 및 LLM-as-judge 패턴을 활용한 8단계 평가 프레임워크를 제시하며 평가 기반 개발에 대해 설명합니다. 평가는 하네스의 변경 사항이 에이전트의 성능을 개선했는지 혹은 악화시켰는지 알려주는 피드백 루프입니다. 평가가 없다면 하네스 엔지니어링은 추측에 불과합니다. 평가 허브와 같은 툴은 이를 대규모로 관리하는 데 도움이 됩니다.

하네스 아티팩트에는 관리상의 어려움이 따릅니다. AGENTS.md가 방대해지고 사용자 정의 툴이 늘어나며 시스템 프롬프트가 발전함에 따라, 이를 어떻게 버전 관리해야 할까요? 프로젝트 간에 이를 어떻게 공유할 수 있을까요? AI 컨텍스트 패키지 관리자인 Lola에 관한 문서에서는 AI 컨텍스트를 버전 관리되는 패키지로 취급합니다. 이러한 관점은 매우 타당합니다. 하네스 아티팩트가 엔지니어링 아티팩트라면, 엔지니어링 아티팩트와 동일한 방식으로 관리해야 합니다.

계층 4: 에이전트 런타임

에이전트 런타임은 에이전트 루프를 구동하는 엔진입니다. Claude Code, OpenCode, Goose 또는 사용자 정의 빌드 런타임 등이 여기에 포함됩니다. 이는 툴 디스패치, 컨텍스트 창, 대화 관리를 처리합니다.

Anthropic은 해당 이메일에서 이를 "하네스"라고 불렀습니다. 저는 이것이 틀렸거나 최소한 부정확한 표현이라고 생각합니다. 런타임은 직접 구축하지 않는 한 사용자가 엔지니어링하거나 개선할 수 있는 영역이 아닙니다. 런타임은 프롬프트 전송, 응답 수신, 툴 호출 전달, 결과 피드백으로 이어지는 루프를 실행합니다. 이 계층의 중요성은 아무리 강조해도 지나치지 않습니다. 런타임은 계속해서 발전하고 있으며 우리 모두가 그 혜택을 누리고 있습니다.

하지만 일부 조직은 자체적으로 런타임을 구축하기도 합니다. 데이터 주권 요구 사항이 있거나, 기성 런타임에서 제공하지 않는 기능이 필요하거나, 활용 사례에서 런타임 동작에 대한 매우 높은 수준의 제어가 필요한 경우에는 자체적으로 구축해야 하며 이를 위한 API가 필요합니다. 이 지점에서 응답, 파일 처리, 검색, 그리고 향후 메모리 기능을 위한 오픈 API를 제공하는 Llama Stack과 같은 프로젝트가 중요해집니다. 오픈 API를 기반으로 구축된 소버린 런타임은 독점 서비스에 종속된 런타임과는 완전히 다른 가치를 제공합니다. Red Hat의 플랫폼은 기존 런타임을 채택하고 그 주변의 사용자 하네스를 엔지니어링하는 팀과, 특정 상황에 맞춰 오픈 API를 기반으로 자체 런타임을 구축하는 팀을 모두 지원합니다.

계층 5: 모델 및 추론 엔드포인트

OpenShift 기반 Red Hat AI Inference Server와 Claude Code 통합에 관한 Red Hat 가이드는 온프레미스 추론을 위해 Red Hat AI에 vLLM을 배치하는 방법을 설명합니다. 사용자의 모델, 클러스터, 데이터를 직접 관리할 수 있습니다. 자체 하드웨에서 추론을 실행하는 것은 전체 에이전트 스택의 신뢰 모델에 큰 영향을 미칩니다.

현대적인 소프트웨어 공급망 보안, 특히 Red Hat Trusted Artifact Signer와 암호화 모델 서명에 대한 Red Hat의 노력이 중요합니다. 실행 중인 모델의 출처를 확인하고 관리할 수 없다면, 그 위의 전체 스택은 검증되지 않은 기반 위에 세워진 것과 같습니다. 모델 서명이 모델 계층에서 갖는 의미는 스킬 서명이 하네스 계층에서 갖는 의미와 같습니다. 즉, 현재 실행 중인 것이 의도한 것과 일치함을 암호학적으로 보장합니다.

감산 방식과 가산 방식의 비교

샌드박스와 하네스는 서로 상반된 설계 철학을 가지고 있습니다. 샌드박스는 감산 방식(subtractive)으로, 위험을 줄이기 위해 기능을 제한합니다. 하네스는 가산 방식(additive)으로, 역량을 강화하기 위해 지식과 툴을 계층화합니다. 이 둘을 혼동하면 각 계층의 지향점이 되어야 할 설계 원칙이 흐려질 수 있습니다.

또한 두 계층은 서로 다른 장애 모드를 가집니다. 샌드박스 장애는 에이전트가 허용되지 않은 작업을 수행했음을 의미합니다. 하네스 장애는 에이전트가 충분히 잘 수행했어야 할 작업을 제대로 처리하지 못했음을 의미합니다. 이는 서로 다른 문제이며 각각 다른 대응이 필요합니다.

샌드박스는 에이전트 활동의 중립적인 관찰자인 기록자로서 부차적인 역할을 수행할 수 있습니다. 이는 에이전트 런타임의 자체 증명보다 훨씬 더 신뢰할 수 있는 방식으로 에이전트의 행위를 입증할 수 있습니다.

샌드박스는 제약하고 관찰합니다. 하네스는 기능을 지원하며 사용자가 이를 개선할 수 있습니다. 런타임은 실행을 담당하며, 반드시 필요한 경우가 아니라면 직접 구축하지 않는 것이 좋습니다. 에이전트의 안전성과 신뢰성은 그 하단의 스택에 달려 있습니다. Red Hat은 GPU 스케줄링부터 암호화 모델 서명에 이르기까지 모든 계층에서 오픈소스인 해당 스택을 구축하고 있습니다. 프로덕션 환경에 에이전트를 배포하면서 막연한 기대가 아닌 검증 가능한 기반을 원하신다면, 그것이 바로 Red Hat이 나아가는 방향입니다.