chore: update graph view scale and set workspace default tab to graph view
This commit is contained in:
Antigravity Agent
@@ -0,0 +1,33 @@
|
||||
---
|
||||
id: HARNESS-RES-2026-05-002
|
||||
title: API Gateway (LLM/MCP Gateway)
|
||||
category: "10_Wiki/Topics/Infrastructure"
|
||||
status: verified
|
||||
confidence_score: 0.94
|
||||
tags: [harness, api-gateway, llm-gateway, mcp, security, finops]
|
||||
created_at: 2026-05-05
|
||||
updated_at: 2026-05-08
|
||||
---
|
||||
|
||||
# API Gateway (LLM/MCP Gateway)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "에이전트와 외부 세계를 잇는 통제된 검문소: 다중 LLM 라우팅을 통한 비용 최적화와 MCP 도구 접근에 대한 보안 가드레일을 통합 관리하는 에이전트 인프라의 중추."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **다중 모델 라우팅 및 비용 최적화 (LLM Gateway):** OmniRoute와 같은 다중 제공자 LLM 게이트웨이는 인텔리전트 라우팅, 로드 밸런싱, 자동 대체(Fallback), 속도 제한, 응답 캐싱을 수행한다 [2]. 단순한 작업은 저렴한 모델로, 복잡한 추론은 고성능 모델로 라우팅하여 토큰 비용을 40~60%가량 절감할 수 있다 [2]. Helicone의 AI Gateway 역시 코드 변경 없이 요청 라우팅과 캐싱 기능을 제공하여 비용 추적과 토큰 모니터링을 지원한다 [1].
|
||||
* **보안 및 도구 접근 통제 (MCP/API Gateway):** 외부 도구 사용 시 Harness MCP Gateway는 외부 MCP 서버 호출을 프록시하고 필터링하여 허용 목록(Allow-listing) 적용, 속도 제한, 콘텐츠 검사를 활성화한다 [3]. GitHub의 에이전트 워크플로우 또한 내부 보안 아키텍처의 일환으로 MCP 게이트웨이와 API 프록시를 활용하여 에이전트 실행 환경을 방어한다 [6]. Amazon Bedrock AgentCore는 서버리스 런타임 환경에서 도구 접근을 위한 안전한 게이트웨이를 기본 제공한다 [5].
|
||||
* **FinOps 및 예산 가드레일 강제:** 인프라 게이트웨이는 에이전트 서비스의 유닛 이코노믹스를 관리하기 위해 루프 및 단계 제한, 도구 호출 캡(Cap), 실행당 토큰 예산, Wall-clock 타임아웃, 이상 탐지가 포함된 테넌트별 예산 제한 등 5가지의 구체적인 예산 가드레일을 강제한다 [4].
|
||||
* **개인용 에이전트 게이트웨이 (Personal Agent Gateway):** OpenHarness 기반의 개인용 에이전트 앱인 'ohmo'의 경우, 자체 워크스페이스 내에 `gateway.json`을 두어 선택된 LLM 프로바이더 프로필과 외부 채널(Telegram, Slack, Discord 등) 설정을 연결하고 관리하는 역할을 수행한다 [7, 8].
|
||||
|
||||
## ⚖️ 트레이드오프 및 고려사항
|
||||
* **운영 복잡성과 세션 관리의 충돌:** 게이트웨이를 도입하면 보안과 운영 효율성이 크게 향상되지만, 인프라의 세션 관리 복잡성이 증가하는 제약이 있다 [1].
|
||||
* **상태 유지의 한계:** MCP를 원격 서비스로 실행하기 위해 HTTP 전송을 사용할 경우, 상태를 유지해야 하는 세션 제약(예: `Mcp-Session-Id` 헤더 유지)이 로드 밸런서 환경이나 수평적 확장(Horizontal scaling) 구조와 충돌하는 현상이 발생한다 [1]. 이 때문에 대규모 확장성을 위해서는 전송 계층(Transport layer)에서 세션 관리를 완전히 분리해야 하는 구조적 한계와 극복 과제가 존재한다 [1].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **상위 개념**: [[AI Infrastructure]], [[Network Security]]
|
||||
- **유사 개념**: [[MCP (Model Context Protocol)]], [[Rate Limiting]], [[Reverse Proxy]]
|
||||
- **관련 프로젝트**: [[OpenHarness]], [[ConnectAI]]
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-08*
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
id: HARNESS-RES-2026-05-012
|
||||
title: 액티브 메타데이터 (Active Metadata)
|
||||
category: "10_Wiki/Topics/Infrastructure"
|
||||
status: verified
|
||||
confidence_score: 0.95
|
||||
tags: [harness, data-governance, metadata, freshness, data-quality, mcp]
|
||||
created_at: 2026-05-05
|
||||
updated_at: 2026-05-08
|
||||
---
|
||||
|
||||
# 액티브 메타데이터 (Active Metadata)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "데이터의 자의식: 정적인 데이터 설명을 넘어, 실시간 최신성, 인증 상태, 스키마 변화를 에이전트에게 능동적으로 전달하여 환각과 오작동을 예방하는 동적 거버넌스 정보."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **실시간 데이터 상태 모니터링**: 액티브 메타데이터는 데이터 시스템을 지속적으로 모니터링하여 메타데이터의 최신성을 자동으로 유지한다 [1]. 스키마 상태, 실시간 인증(Certification) 상태, 데이터 최신화(Freshness) 신호가 구조화된 컨텍스트로 제공되어 에이전트가 데이터의 유효성을 추측할 필요가 없게 만든다 [1].
|
||||
* **하네스의 구조적 한계 보완**: 대부분의 하네스 프레임워크는 에이전트의 실행 방식(어떻게)을 제어하지만, 입력 데이터의 무결성(무엇을)은 검증하지 못한다 [3]. 액티브 메타데이터는 이러한 틈을 메워 에이전트가 컨텍스트를 읽기 전 신뢰성을 판정하는 통제된 데이터 기반(Governed data substrate) 역할을 수행한다 [3, 4].
|
||||
* **MCP를 통한 지식 전달**: 메타데이터, 데이터 계약, 리니지 정보는 모델 컨텍스트 프로토콜(MCP) 서버를 통해 하네스에 제공된다 [5]. 하네스는 MCP 인터페이스를 통해 별도의 거버넌스 로직 없이도 구조화된 컨텍스트를 직접 쿼리할 수 있다 [5].
|
||||
|
||||
## ⚖️ 트레이드오프 및 고려사항
|
||||
* **오케스트레이션 기능의 부재**: Atlan과 같은 액티브 메타데이터 시스템은 에이전트 실행을 직접 제어하거나 메모리를 관리하는 도구가 아니다 [6]. 따라서 반드시 LangGraph나 CrewAI와 같은 제어 프레임워크와 결합하여 사용해야 한다 [4, 6].
|
||||
* **초기 설계 및 비용 부담**: 잘못된 데이터로 인한 오작동은 사후 디버깅이 매우 어렵다 [7]. 따라서 엔터프라이즈 환경에서는 프로토타입 단계부터 데이터 품질 인프라를 함께 설계해야 하는 기술적 복잡성과 초기 투자 비용이 수반된다 [7, 8].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **상위 개념**: [[Data Governance]], [[Data Quality Layer]]
|
||||
- **유사 개념**: [[Schema Drift (스키마 표류)]], [[Data Lineage]], [[MCP (Model Context Protocol)]]
|
||||
- **관련 프로젝트**: [[Atlan]], [[ConnectAI]]
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-08*
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
id: HARNESS-RES-2026-05-014
|
||||
title: AutoGen / AG2
|
||||
category: "10_Wiki/Topics/Frameworks"
|
||||
status: verified
|
||||
confidence_score: 0.95
|
||||
tags: [harness, multi-agent, framework, autogen, ag2, conversation-pattern]
|
||||
created_at: 2026-05-05
|
||||
updated_at: 2026-05-08
|
||||
---
|
||||
|
||||
# AutoGen / AG2
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "협력하는 에이전트들의 오케스트라: 다중 에이전트 간의 대화 패턴(Multi-agent Conversation)을 통해 복잡한 문제를 해결하고, 내장된 샌드박스와 HITL 기능을 제공하는 성숙한 에이전트 프레임워크."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **대화형 다중 에이전트 아키텍처:** 여러 에이전트가 대화를 통해 산출물을 제안, 비판, 정제하는 다중 턴(multi-turn) 토론 패턴을 특징으로 한다 [3]. 단일 에이전트보다 분석 및 엔지니어링 작업에서 신뢰도 높은 결과를 도출하며, AgentChat 계층을 통해 루프와 도구 통합을 정밀하게 제어한다 [2, 3].
|
||||
* **코드 실행 샌드박싱 (Code Execution):** Docker 기반의 격리된 런타임을 제공하여 에이전트가 작성한 코드를 호스트 시스템 훼손 없이 안전하게 실행하고 디버깅할 수 있게 한다 [1, 3].
|
||||
* **인간 참여 제어 (HITL):** `UserProxyAgent`와 `human_input_mode` 설정을 통해 에이전트 대화 루프 내에 인간의 검토 및 승인 게이트를 유연하게 삽입할 수 있다 [4].
|
||||
|
||||
## ⚖️ 트레이드오프 및 고려사항
|
||||
* **운영 상의 리스크**: 에이전트 간 결론을 내지 못하고 무한 루프를 도는 현상이 발생할 수 있으며, 대화가 길어질수록 컨텍스트가 축적되지만 이를 자동으로 압축하거나 관리하는 메커니즘이 부족하여 토큰 한계에 도달하기 쉽다 [3, 5].
|
||||
* **데이터 품질 및 거버넌스 부재**: 검색된 데이터의 최신성이나 인증 여부를 자체적으로 검증하지 못하며, 출력물과 원본 소스 사이의 데이터 계보(Lineage) 추적 기능이 없어 엔터프라이즈 거버넌스 적용 시 별도의 보완이 필요하다 [5].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **상위 개념**: [[Agent Frameworks]], [[Multi-Agent Systems (MAS)]]
|
||||
- **유사 개념**: [[CrewAI]], [[LangGraph]], [[UserProxyAgent]]
|
||||
- **관련 프로젝트**: [[Microsoft Semantic Kernel]], [[ConnectAI]]
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-08*
|
||||
@@ -0,0 +1,18 @@
|
||||
# [[Co-evolution (공진화)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
공진화(Co-evolution)는 인공지능 에이전트 환경에서 모델의 훈련 과정과 하네스(Harness) 설계가 상호작용하며 함께 발전하는 현상을 의미한다 [1]. 오늘날의 최신 에이전트 모델들은 하네스를 루프(loop)에 포함시킨 상태로 훈련되며, 기술적 결합뿐만 아니라 인간과 에이전트가 상호 학습하며 개선되어가는 철학적 개념으로도 사용된다 [1, 2]. 그러나 특정 하네스 환경에 모델이 과적합(Overfitting)되어 일반화 능력이 저하될 수 있다는 중대한 기술적 한계를 수반한다 [1, 3].
|
||||
|
||||
## 📖 Core Content
|
||||
* **모델 훈련과 하네스 설계의 결합:** Claude Code나 Codex와 같은 최신 에이전트 제품들은 모델과 하네스가 루프에 포함된 상태에서 사후 훈련(post-trained)을 진행한다 [1]. 이러한 훈련 방식은 파일 시스템 조작, bash 실행, 계획 수립, 하위 에이전트(subagent)를 통한 병렬 작업 등 하네스 설계자가 에이전트가 본질적으로 잘 수행해야 한다고 판단하는 동작들을 모델이 효과적으로 개선하도록 돕는다 [1].
|
||||
* **피드백 루프를 통한 역량 강화:** 시스템 설계 과정에서 유용한 프리미티브(primitives)가 발견되면 하네스에 추가되고, 이는 다음 세대의 모델을 훈련할 때 다시 사용되는 피드백 루프(feedback loop)를 형성한다 [1]. 이 사이클이 반복되면서 모델은 자신이 훈련된 특정 하네스 환경 내에서 점점 더 강력하고 유능한 성능을 발휘하게 된다 [1].
|
||||
* **인간과 에이전트의 공진화 (플랫폼 관점):** 기술적 요소 간의 결합을 넘어 인간과 에이전트 간의 관계에서도 공진화의 개념이 적용된다. 일례로 LobeHub와 같은 작업 공간 플랫폼은 인간과 에이전트가 지속적으로 학습하고 함께 개선되는 공진화(co-evolution) 아이디어를 중심으로 구축되었다 [2]. 이를 통해 에이전트는 일회성 도구가 아니라 사용자의 작업 흐름과 선호도를 이해하는 진정한 팀원으로서 진화하게 된다 [2].
|
||||
* **자기 진화(Self-improvement)로의 확장:** 에이전트가 시간이 지남에 따라 자신의 스캐폴딩(하네스)을 스스로 수정하고 개선함에 따라, 하네스 역시 이러한 에이전트의 변화에 맞춰 적응해야 하는 차세대 에이전트 역량 발전의 방향성으로도 공진화가 다루어지고 있다 [4].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **과적합(Overfitting) 및 일반화(Generalization) 성능 저하:** 모델과 하네스의 공진화는 일반화 측면에서 부정적인 부작용(side effects)을 초래한다 [1]. 하네스를 훈련 루프에 포함시키면 모델이 해당 하네스 설계에 과적합되어, 도구의 로직(예: 파일을 편집하는 패치 방법 등)을 약간만 변경해도 모델의 성능이 악화되는 현상이 발생한다 [1, 5]. 진정한 지능형 모델이라면 도구 논리 변화에 쉽게 적응해야 하지만, 공진화로 인한 과적합이 이를 가로막는다 [5].
|
||||
* **장기적인 아키텍처 종속성 초래:** '공진화의 경고(co-evolution warning)'라고 불리는 이 현상에 따르면, 특정 하네스와 함께 훈련된 모델은 해당 설계에 강하게 묶이게 되므로 초기의 하네스 아키텍처 선택이 당면한 작업을 넘어서서 시스템 전체에 장기적인 결과와 제약을 초래할 수 있다 [3].
|
||||
* **당면 과제와 훈련된 하네스 간의 불일치:** 모델이 특정 하네스와 함께 훈련되어 역량이 강화되었다 하더라도, 그 하네스가 사용자가 현재 수행하려는 특정 과제에 가장 적합한 '최적의 하네스'임을 의미하지는 않는다 [5]. 종종 훈련에 사용된 기본 하네스를 그대로 사용하는 것보다 현재 작업의 특성에 맞춰 하네스를 새롭게 튜닝하고 최적화(Harness engineering)할 때 훨씬 더 높은 성과를 얻을 수 있다 [5].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-05*
|
||||
@@ -0,0 +1,17 @@
|
||||
# [[Code Execution (코드 실행)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
코드 실행(Code Execution)은 에이전트 하네스가 대규모 언어 모델(LLM)에 자율적인 문제 해결 능력을 부여하기 위해 제공하는 핵심 기술 프리미티브이다 [1, 2]. 에이전트가 사전에 정의된 도구에만 의존하지 않고 Bash나 Python 등의 코드를 직접 작성하여 환경과 상호작용하도록 가상의 컴퓨터를 제공하는 역할을 한다 [3, 4]. 이러한 코드 실행은 호스트 시스템의 안전을 보장하기 위해 주로 샌드박스나 마이크로VM과 같은 격리된 환경에서 이루어진다 [5-7].
|
||||
|
||||
## 📖 Core Content
|
||||
* **자율적 문제 해결 및 도구의 일반화**: 코드 실행은 에이전트 하네스의 5대 핵심 프리미티브 중 하나로, 비정형 문제에 대한 동적 해결책을 자율적으로 생성할 수 있게 한다 [1, 2]. 에이전트 하네스에는 Bash 등의 일반 목적 도구가 포함되어 있어, 에이전트가 코드를 통해 스스로 도구를 설계하고 문제를 해결할 수 있다 [3, 4].
|
||||
* **효율성 및 토큰 최적화**: 다단계 도구 호출을 코드로 대체하면 효율성이 크게 향상된다. 예를 들어, MCP 서버와 상호작용할 때 에이전트가 개별 도구를 직접 여러 번 호출하는 대신 이를 수행하는 코드를 작성해 실행하도록 하면 토큰 오버헤드를 최대 98.7%까지 절감할 수 있다 [8]. 또한 셸(Shell) 접근을 활용하면 모델 추론을 거치거나 토큰 비용을 소모하지 않고도 가상 머신에서 명령을 직접 실행할 수 있다 [7].
|
||||
* **샌드박싱 및 격리된 실행 환경**: 에이전트가 작성한 코드를 실행할 수 있는 안전한 환경을 보장하기 위해 하네스는 온디맨드 샌드박스를 제공한다 [6]. Microsoft의 AutoGen은 Docker 네이티브 샌드박싱을 지원하여 코드 작성 에이전트를 호스트 시스템으로부터 격리하며 [9], AgentCore는 세션마다 전용 CPU, 메모리, 파일 시스템을 갖춘 독립된 마이크로VM(microVM)을 띄워 코드를 실행한다 [7, 10]. 이외에도 제공자 관리형 환경에서 명령을 실행하는 호스팅된 셸(Hosted shell) 방식도 존재한다 [11].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **보안 위험과 명시적 승인 요구**: 모델이 생성한 코드를 로컬 호스트 환경에서 직접 실행하는 것은 높은 위험을 수반한다 [6]. 따라서 로컬 셸 실행 시에는 격리된 환경을 사용해야 하며, 명령이 실행되기 전에 애플리케이션 측에서 명확한 승인(Approval) 체크포인트를 두어 제어권을 유지해야 한다 [11-13].
|
||||
* **실행 환경의 콜드 스타트 지연**: 안전한 코드 실행을 위해 샌드박스나 마이크로VM을 온디맨드로 생성하고 파괴하는 과정에서 초기 구동 지연(Latency)이 발생할 수 있다 [5, 6]. 예를 들어 E2B와 같이 에이전트 도구 루프용으로 특별히 설계된 마이크로VM은 약 150ms의 콜드 스타트 시간을 제공하지만, 인프라의 아키텍처나 환경에 따라 지연율에 차이가 발생할 수 있다 [5].
|
||||
* **출력물로 인한 컨텍스트 과부하**: 코드 실행 결과로 반환되는 방대한 에러 로그나 출력물은 모델의 컨텍스트 윈도우를 빠르게 소모시켜 '컨텍스트 부패(Context Rot)'를 유발할 수 있다 [14, 15]. 이를 방지하기 위해 도구 호출 결과의 일부만 유지하고 나머지는 파일 시스템으로 오프로딩(Offloading)하는 등의 하네스 차원의 최적화 관리가 필수적으로 동반되어야 한다 [15].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-05*
|
||||
@@ -0,0 +1,17 @@
|
||||
# [[Containerization]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
컨테이너화(Containerization)는 에이전트 하네스 환경에서 AI 에이전트가 안전하게 코드를 실행하고 도구와 상호작용할 수 있도록 격리된 샌드박스(Sandbox) 실행 환경을 제공하는 핵심 기술이다 [1-3]. 도커(Docker), OCI 컨테이너, 마이크로VM 등을 활용하여 호스트 시스템을 보호함과 동시에 일관되고 재현 가능한 에이전트 구동 및 벤치마크 평가 환경을 구성하는 데 사용된다 [1, 2, 4, 5]. 이를 통해 에이전트는 외부 시스템 인프라를 오염시키지 않고 자율적으로 문제를 해결할 수 있다 [1, 5].
|
||||
|
||||
## 📖 Core Content
|
||||
* **격리된 코드 실행 및 샌드박싱**: AutoGen(AG2)과 같은 오케스트레이션 프레임워크는 Docker 네이티브 샌드박싱 기능을 통해 코드를 작성하는 에이전트가 호스트 시스템에 대한 위험 없이 격리된 환경에서 코드를 실행하고 테스트할 수 있도록 지원한다 [1]. 또한 Open Harness 모델은 단일 프로젝트 및 브랜치에 할당된 단일 Docker 컨테이너를 구동하여, 호스트의 의존성 부패(Toolchain rot) 없이 에이전트가 독립적인 작업 공간을 소유하고 활동할 수 있게 한다 [5].
|
||||
* **일관된 평가 및 벤치마킹 환경 구축**: 에이전트의 성능을 재현 가능하게 평가하기 위해 HAL(Holistic Agent Leaderboard)과 같은 통합 평가 하네스는 Docker 컨테이너를 활용한다 [3, 6]. SWE-bench, ScienceAgentBench 및 USACO 등 다양한 벤치마크 테스트가 컨테이너 기반으로 병렬 실행되며, 모델의 시스템 제어 변수를 일정하게 유지한다 [3, 4, 7, 8].
|
||||
* **다양한 컨테이너 런타임 및 인프라의 진화**: 엔터프라이즈 하네스 환경에서는 단순한 Docker를 넘어 다양한 형태의 컨테이너 기술이 쓰인다. 빠른 시작 시간과 커널 수준의 격리를 제공하는 Firecracker 기반의 마이크로VM(예: E2B)이나 90ms 미만의 부팅 속도와 영구 상태를 지원하는 OCI 컨테이너(예: Daytona)가 사용된다 [2, 9]. 기존 인프라에 통합해야 할 경우, gVisor나 Kata Containers를 통해 커널 수준의 격리를 제공하는 쿠버네티스(Kubernetes) 네이티브 샌드박스 CRD가 도입되기도 한다 [10].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **운영 및 인프라 복잡성 증가**: 컨테이너화된 환경에서 파일 시스템을 백엔드로 사용하여 에이전트의 컨텍스트를 오프로딩(Offloading)하고 관리하는 방식은 전체 시스템의 운영 복잡성을 가중시킨다 [11].
|
||||
* **평가 환경의 자원 구성에 따른 행동 노이즈**: 컨테이너에 할당되는 자원(CPU, 메모리 등) 설정 자체가 에이전트의 문제 해결 전략에 큰 영향을 미칠 수 있다 [12]. 엄격한 자원 제한 환경과 넉넉한 환경에서 에이전트가 선택하는 도구나 종속성 활용 전략이 완전히 달라져 벤치마크 점수에 큰 변동을 일으키는 원인이 된다 [12].
|
||||
* **컨테이너 격리만으로는 부족한 보안 한계**: 컨테이너 기반의 샌드박스 격리 기능만으로는 에이전트의 악의적 혹은 통제 불능 상태를 완벽히 막을 수 없다 [2, 9]. 에이전트가 자신의 하네스 구성(예: MCP 서버 설정, 훅 파일)을 수정할 수 있거나 네트워크 이그레스(Egress) 제한이 없는 경우, 컨테이너 내부에 있더라도 권한 상승이나 외부 유출의 위험이 존재하므로 커널 수준의 제어나 OPA(Open Policy Agent) 기반의 네트워크 제어가 동반되어야 한다 [2, 9].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-05*
|
||||
@@ -0,0 +1,17 @@
|
||||
# [[Control Layer (제어 계층)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
에이전트 하네스 맥락에서 제어 계층(Control Layer 또는 Control Plane)은 대규모 언어 모델(LLM)을 감싸 에이전트의 실제 운영 방식을 관리하는 소프트웨어 프레임워크 시스템을 의미합니다 [1]. 이 계층은 도구 사용, 메모리, 계획 수립 및 다중 에이전트 조정을 위한 스캐폴딩(Scaffolding)을 제공하며 에이전트의 실행, 통신, 장애 복구 및 의사 결정 라우팅을 결정합니다 [1]. 결과적으로 모델의 확률적이고 인지적인 엔진을 실제 작업의 동력으로 전환하는 필수적인 제어 평면 역할을 수행합니다 [2].
|
||||
|
||||
## 📖 Core Content
|
||||
* **역할 및 아키텍처 분리:** 제어 계층은 에이전트가 '어떻게' 실행되는지를 통제하는 역할을 맡습니다 [3]. 인증(Auth), 과금, 오케스트레이션을 담당하는 제어 평면은 파일, 셸, 포트 등을 다루는 샌드박스 컴퓨팅 평면과 엄격하게 분리되도록 설계됩니다 [4]. 오케스트레이션, 실행, 평가 등의 관심사를 분리하는 구조화된 스택으로 수렴하고 있습니다 [5].
|
||||
* **주요 프레임워크:** 2026년 기준, 대다수 에이전트 스택의 핵심 제어 계층을 구성하는 대표적인 오케스트레이션 프레임워크로는 LangGraph, CrewAI, AutoGen, LangChain deepagents, Microsoft Semantic Kernel, Mastra 등이 있습니다 [6]. 이들은 세밀한 상태 제어를 위한 그래프 기반 아키텍처(LangGraph), 빠른 프로토타이핑을 위한 역할 기반 아키텍처(CrewAI), 혹은 코드 샌드박싱에 유리한 대화형 아키텍처(AutoGen) 등 각기 다른 오케스트레이션 방식을 제공합니다 [7-9].
|
||||
* **통합 제어 환경으로의 진화:** 최근의 제어 계층은 평가(Evaluation) 및 관찰 가능성(Observability) 기능 역시 단순히 오프라인 벤치마크에 머물지 않고, 팀이 표준화하여 사용할 수 있는 런타임 제어 평면의 일부로 통합하여 인프라 서비스화 하는 추세를 보이고 있습니다 [10].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **데이터 품질 검증의 부재:** 제어 계층을 구성하는 프레임워크들의 가장 큰 구조적 한계는 에이전트가 '어떻게' 동작하는지는 관리하지만 '무엇을' 읽는지는 통제하지 않는다는 점입니다 [3]. 어떠한 오케스트레이션 프레임워크도 자체적으로 입력 데이터를 인증하거나 검증할 수 없으며, 이로 인해 별도의 거버넌스된 데이터 계층(Data Layer) 인프라가 없다면 에이전트는 스키마 드리프트, 오래된 데이터, 미인증 소스 등의 잘못된 입력으로 인해 치명적인 오류를 범할 수 있습니다 [1, 11, 12].
|
||||
* **통제력과 구성 복잡성의 상충 관계 (Trade-off):** 세밀한 상태 제어를 제공하는 제어 계층(예: LangGraph)은 작업 성공률이 높지만(비교 벤치마크 기준 87%), 구성이 장황하고 가파른 학습 곡선을 요구한다는 단점이 있습니다 [7, 13, 14]. 반면, 역할 기반의 프레임워크(예: CrewAI)는 빠른 프로토타이핑이 가능하지만 세밀한 제어력이 부족하고 상대적으로 작업 성공률(82%)이 낮아 프로젝트의 요구사항에 따른 절충이 필요합니다 [8, 14, 15].
|
||||
* **운영 오버헤드 및 종속성:** 제어 계층 내에 사후 모니터링이나 관찰 가능성 도구(AgentOps, Langfuse 등)를 결합할 경우, 시스템 실행에 약 12~15%의 성능 오버헤드가 발생할 수 있습니다 [16, 17]. 또한 특정 기업 생태계(예: Microsoft 기술 스택의 Semantic Kernel)에 맞춰진 제어 프레임워크를 선택할 경우 강력한 타입 안정성과 컴파일 타임 검증을 얻는 대신 해당 플랫폼에 대한 종속성(Lock-in)이 심화될 수 있습니다 [18, 19].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-05*
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
id: HARNESS-RES-2026-05-006
|
||||
title: E2B (Firecracker microVM)
|
||||
category: "10_Wiki/Topics/Infrastructure"
|
||||
status: verified
|
||||
confidence_score: 0.95
|
||||
tags: [harness, sandbox, e2b, microvm, firecracker, serverless]
|
||||
created_at: 2026-05-05
|
||||
updated_at: 2026-05-08
|
||||
---
|
||||
|
||||
# E2B (Firecracker microVM)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "에이전트를 위한 초고속 보안 컨테이너: Firecracker microVM 기술을 활용하여 150ms 내외의 신속한 부팅과 강력한 커널 수준 격리를 동시에 제공하는 오픈소스 샌드박스의 표준."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **에이전트 맞춤형 샌드박스 인프라**: E2B는 AI 에이전트의 도구 루프(Tool loops)를 위해 특별히 제작된 Firecracker 마이크로VM 기반의 오픈소스 샌드박스 환경이다 [1]. AI 에이전트가 안전하게 코드를 실행할 수 있는 격리된 컨테이너 기반 런타임을 제공한다 [1, 2].
|
||||
* **기술적 사양 및 접근성**: 약 150ms의 빠른 콜드 스타트(Cold start) 성능을 달성했으며, Python 및 JavaScript SDK를 모두 제공하여 HuggingFace의 `smolagents`와 같은 주요 에이전트 프레임워크와 원활하게 통합된다 [1, 3].
|
||||
* **에이전트 샌드박스의 산업 기준점**: E2B는 현대 에이전트 샌드박스의 표준적 아키텍처로 기능한다. 텐센트 클라우드의 CubeSandbox가 자사를 'E2B 호환 대체재'라고 명시할 정도로, 고밀도 에이전트 실행 환경의 기준 규격 역할을 수행하고 있다 [4].
|
||||
|
||||
## ⚖️ 트레이드오프 및 고려사항
|
||||
* **리소스 오버헤드와 지연 시간**: E2B 방식은 완전한 커널 수준 격리를 제공하지만, V8 Isolate 기반 기술(예: Cloudflare Dynamic Workers)에 비해 효율성 면에서 한계가 있다. V8 Isolate 기반 환경은 시작 속도가 100배 이상 빠르고(수 밀리초) 메모리 효율성 역시 뛰어나지만, 실행 가능한 코드의 종류와 메모리 제약이 더 엄격하다 [2].
|
||||
* **상태 지속성의 관리**: microVM은 기본적으로 휘발성(Ephemeral) 환경으로 설계되므로, 세션 간 상태를 지속해야 하는 작업의 경우 별도의 상태 관리 레이어가 추가되어야 한다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **상위 개념**: [[Sandbox]], [[Cloud Computing]]
|
||||
- **유사 개념**: [[Kernel-level Isolation]], [[V8 Isolate]], [[Containerization]]
|
||||
- **관련 프로젝트**: [[ConnectAI]], [[smolagents (HuggingFace)]]
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-08*
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
id: HARNESS-RES-2026-05-017
|
||||
title: HTTP+SSE
|
||||
category: "10_Wiki/Topics/Infrastructure"
|
||||
status: verified
|
||||
confidence_score: 0.94
|
||||
tags: [harness, transport, http, sse, streaming, mcp, communication]
|
||||
created_at: 2026-05-05
|
||||
updated_at: 2026-05-08
|
||||
---
|
||||
|
||||
# HTTP+SSE
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "에이전트의 실시간 혈맥: HTTP POST 요청과 SSE 스트리밍 응답을 결합하여, 원격 서버와 에이전트 간의 양방향 및 이벤트 기반 통신을 가능하게 하는 전송 프로토콜."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **원격 서비스 통신 지원:** 클라이언트가 서버로 메시지를 보낼 때 HTTP POST를 사용하고, 서버가 실시간 응답을 보낼 때 SSE 스트림을 활용하는 구조이다. 이를 통해 MCP 서버가 로컬 프로세스를 넘어 원격 서비스로 구동될 수 있는 기반을 제공한다 [2].
|
||||
* **Streamable HTTP로의 진화:** 초기의 HTTP+SSE 방식은 2025년 11월 사양에 따라 'Streamable HTTP Transport'로 통합 및 발전하였다 [2]. 이는 다중 클라이언트 연결 처리를 공식화한 규격이다.
|
||||
* **관리형 에이전트 하네스 적용:** Anthropic의 Claude Managed Agents 등 완전 관리형 환경에서도 안전한 샌드박싱과 함께 SSE 스트리밍 기능이 핵심 통신 기반으로 기본 지원된다 [1].
|
||||
|
||||
## ⚖️ 트레이드오프 및 고려사항
|
||||
* **세션 관리의 복잡성:** 연결 상태를 유지해야 하는 `Mcp-Session-Id` 헤더와 로드 밸런서의 트래픽 분산 메커니즘이 충돌할 수 있다. 이는 인프라의 수평적 확장(Horizontal Scaling)을 방해하는 요소로 작용한다 [2].
|
||||
* **아키텍처 개선 방향:** 이러한 한계를 극복하기 위해, 2026년 로드맵에서는 전송 계층으로부터 세션 관리를 완전히 분리(Decoupling)하는 설계를 추진하고 있다 [2].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **상위 개념**: [[Transport Layer]], [[MCP (Model Context Protocol)]]
|
||||
- **유사 개념**: [[Server-Sent Events (SSE)]], [[Streamable HTTP]], [[Mcp-Session-Id]]
|
||||
- **관련 프로젝트**: [[Claude Managed Agents]], [[ConnectAI]]
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-08*
|
||||
@@ -0,0 +1,17 @@
|
||||
# [[Hallucination (환각)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
에이전트 시스템에서 환각(Hallucination)이란 대규모 언어 모델(LLM)이 잘못된 매개변수로 함수를 호출하거나 존재하지 않는 API를 참조하는 등 사실이 아닌 결과를 생성하는 현상을 의미합니다 [1]. 많은 경우 LLM 자체의 결함으로 여겨지는 환각은 실제로는 일관성이 없거나 오래된(stale) 데이터 소스가 입력된 결과로 발생합니다 [2, 3]. 에이전트 하네스는 도구 호출을 사전에 검증하고 데이터 거버넌스를 통해 입력 품질을 통제함으로써 이러한 환각을 완화하는 핵심 역할을 수행합니다 [1, 3].
|
||||
|
||||
## 📖 Core Content
|
||||
* **데이터 품질과 환각의 상관관계**: 흔히 LLM의 자체적인 환각이라고 치부되는 문제의 상당수는 실제로는 일관성이 없거나, 오래되었거나, 부분적으로만 복제된 데이터 소스를 에이전트가 읽었기 때문에 발생하는 결과입니다 [2, 3]. 즉, 나쁜 입력 데이터가 주어지면 에이전트는 그 데이터를 바탕으로 잘못된 행동을 하게 됩니다 [4].
|
||||
* **도구 호출 환각 (Hallucinated Tool Calls)**: 모델이 외부 시스템과 상호작용할 때, 잘못된 매개변수 유형을 사용하거나 존재하지도 않는 API 함수를 호출하는 환각을 일으킬 수 있습니다 [1]. 또한, 실제로는 작업이 완료되지 않았음에도 완료되었다고 허위로 선언하는 형태의 환각도 발생합니다 [5]. 적절한 검증이 없다면 에이전트는 이렇게 망가진 호출을 계속 재시도하며 토큰만 낭비하게 됩니다 [1].
|
||||
* **에이전트 하네스를 통한 환각 억제**: 하네스 인프라는 모델이 외부 시스템에 직접 접근하지 못하게 하고, 도구 호출을 가로채어 유효성을 검사하여 환각적 호출의 영향을 차단합니다 [6]. 또한 DeepEval과 같은 평가 프레임워크는 환각 여부를 측정하는 내장 지표(metrics)를 제공하여 에이전트 출력 품질을 검증할 수 있게 돕습니다 [7]. 가장 근본적으로는 Atlan과 같은 거버넌스 데이터 계층을 활용하여 에이전트가 읽는 데이터 자체를 사전에 인증하고 스키마 변동을 방지함으로써 입력 단계에서부터 환각의 원인을 제거합니다 [8, 9].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
에이전트의 환각적 행동이나 잘못된 출력을 파악하기 위해 AgentOps나 Langfuse 같은 사후 모니터링 도구(Observability tools)를 활용할 수 있지만, 이러한 도구들은 실패가 발생한 이후에 이를 포착하는 사후적(post-hoc) 방식이라는 근본적인 제약이 있습니다 [10, 11]. 따라서 나쁜 입력(bad inputs)으로 인해 생성된 환각 데이터라 할지라도 평가 프레임워크 상에서는 높은 점수를 기록할 수 있으며, 이는 개발자에게 큰 오해를 불러일으킬 수 있습니다 [12].
|
||||
|
||||
또한 환각을 근본적으로 막기 위해 입력 데이터를 사전에 검증하는 데이터 계층을 하네스 파이프라인에 결합할 경우, 단순히 프레임워크를 구성하는 것을 넘어 데이터 거버넌스와 엔지니어링 작업에 전체 구현 시간의 80%가 소요될 정도로 높은 비용과 조직적 구축 부담이 발생한다는 트레이드오프가 존재합니다 [2, 13]. 환각 등을 추적하기 위해 도입되는 가시성 도구들 역시 각각 12%에서 15%에 이르는 시스템 성능 오버헤드를 유발하여 전체 인프라의 처리 속도에 영향을 미칠 수 있습니다 [14, 15].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-05*
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
id: HARNESS-RES-2026-05-003
|
||||
title: 하네스 승수 (Harness Multiplier)
|
||||
category: "10_Wiki/Topics/Architecture"
|
||||
status: verified
|
||||
confidence_score: 0.98
|
||||
tags: [harness, multiplier, efficiency, performance, benchmarking]
|
||||
created_at: 2026-05-05
|
||||
updated_at: 2026-05-08
|
||||
---
|
||||
|
||||
# 하네스 승수 (Harness Multiplier)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "성능의 증폭기: 모델의 원시 지능이 실제 환경에서 작업 완료 능력으로 변환되는 효율을 수치화한 지표로, `생산 성능 = 모델 역량 × 하네스 승수`라는 에이전트 성능의 핵심 방정식을 정의함."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **성능의 구성 공식:** 실제 프로덕션 환경에서 AI 에이전트가 보여주는 성능은 모델 자체의 능력만으로 결정되지 않으며, `생산 성능 = 모델 역량 × 하네스 승수`라는 공식으로 분해하여 평가되어야 한다 [1]. 모델을 단일 참조 하네스에 고립시켜 평가하는 기존의 벤치마크 방식은 실제 도입 시의 성능을 제대로 예측하지 못한다 [3, 6].
|
||||
* **하네스 승수의 극적인 효과:** 동일한 주간에 측정된 실험에 따르면, GPT-5.5 모델이 OpenAI의 네이티브 Codex 하네스 환경에서는 61.5%의 기능성 점수를 기록했으나 Cursor 하네스에서는 87.2%를 기록하였다 [4, 5]. 무려 25.7%포인트의 성능 향상은 모델 업그레이드나 프롬프트 개선이 아닌, 오직 런타임 환경(하네스)의 교체로 인한 승수 효과이다 [2, 4, 5, 7].
|
||||
* **하네스 승수의 5대 핵심 차원:** 하네스 승수의 크기(효율성)를 결정하는 인프라의 주요 차원은 다음과 같이 세분화된다 [1, 2].
|
||||
* **컨텍스트 관리의 정교함(Context Management):** 모델에게 언제 어떠한 정보를 제공하고 불필요한 데이터를 제거할지 결정하는 알고리즘적 관리 수준 [1, 2].
|
||||
* **도구 통합의 깊이(Tool Integration Depth):** 단순한 도구 호출에 그치지 않고 실패를 감지해 재시도하거나 대체 경로를 찾는 실행 능력 [1, 2].
|
||||
* **메모리의 연속성(Memory Continuity):** 세션 간 이전 단계의 성공 및 실패 맥락을 유지하여 중복된 작업을 방지하는 능력 [1, 2].
|
||||
* **검증 메커니즘(Verification Mechanisms):** 사람의 확인이 이루어지기 전에 에이전트 스스로 결과를 테스트하고 교정하는 루프 [1, 2].
|
||||
* **다중 에이전트 조율(Multi-agent Coordination):** 복잡한 작업을 분해하고 여러 에이전트 간의 역할을 분배하는 능력 [1].
|
||||
|
||||
## ⚖️ 트레이드오프 및 고려사항
|
||||
* **기여도 분리의 한계:** 폐쇄형(Closed-source) 독점 시스템의 경우 모델과 하네스 아키텍처가 불투명하게 결합되어 있어, 성과 향상이 모델의 역량 덕분인지 하네스 승수에 의한 것인지 그 기여도를 명확히 분리해 내기 불가능하다는 제약이 있다 [8].
|
||||
* **평가 환경 구축의 복잡성:** 하네스 승수를 정확하게 측정하고 최적화하려면 단순히 범용 벤치마크 점수에 의존할 수 없으며, 조직 내부의 실제 업무를 반영하는 자체 작업 샘플(Internal task sets)을 필수적으로 준비해야 한다 [6, 8].
|
||||
* **진단을 위한 오버헤드:** 특정 벤더가 새로운 모델 버전과 함께 하네스 업데이트를 동시에 배포할 경우, '구형 하네스에서의 신형 모델'과 '신형 하네스에서의 구형 모델'을 각각 교차로 평가하는(Ablation protocol) 복잡한 평가 절차가 요구된다 [1, 9].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **상위 개념**: [[AI Agent Theory]], [[Performance Metrics]]
|
||||
- **유사 개념**: [[Model Capability]], [[Context Window Management]], [[Harness-as-a-Service]]
|
||||
- **관련 프로젝트**: [[ConnectAI]], [[Cursor (Harness Example)]]
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-08*
|
||||
@@ -0,0 +1,20 @@
|
||||
# [[Harness-as-a-Service]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
Harness-as-a-Service(HaaS)는 개발자가 에이전트 구동을 위한 복잡한 인프라를 직접 구축하는 대신, 사전 구축 및 검증된 런타임 환경을 서비스 형태로 구독하여 사용하는 새로운 인프라 카테고리이다 [1-3]. AWS가 컴퓨팅 자원을 제공하고 Stripe가 결제망을 제공하듯, HaaS는 에이전트 루프, 도구 디스패치, 샌드박싱 등의 인프라에 대한 접근 권한을 판매한다 [2]. 사용자는 원하는 모델, 사용할 도구, 그리고 수행할 작업 세 가지만 제공하면 되며, 그 이면의 복잡한 기술적 요소들은 서비스 제공자에 의해 모두 처리된다 [4].
|
||||
|
||||
## 📖 Core Content
|
||||
* **인프라의 서비스화 (Infrastructure as a Service):** 초기 에이전트 구축 방식(예: OpenClaw 등)에서는 개발자가 모델 선택부터 시스템 프롬프트 작성, 도구 정의, 에이전트 루프 구축, 컨텍스트 관리, 오류 처리, 하위 에이전트 조율, 상태 지속성까지 모든 계층을 직접 조립하고 유지보수해야 했다 [2]. 반면 HaaS 모델에서는 이 모든 것이 관련 계층을 전담하는 전문가 팀에 의해 사전에 구축되고 미세 조정된 상태로 제공되어, 개발자는 인프라 구성 대신 에이전트의 작업 논리에만 집중할 수 있게 된다 [2, 5].
|
||||
* **사전 구축된 하네스 기능 탑재:** 관리형 하네스 플랫폼은 보안이 보장된 샌드박스, 에러 핸들링, 서버 전송 이벤트(SSE) 기반의 스트리밍, 자동화된 컨텍스트 압축(Context Compression) 및 상태 관리 기능 등을 포괄적으로 제공한다 [2, 3, 5].
|
||||
* **주요 벤더의 HaaS 시장 진출 사례:**
|
||||
* **Anthropic:** 자율 에이전트로서 Claude를 실행하기 위한 완전 관리형 에이전트 하네스인 'Claude Managed Agents'를 퍼블릭 베타로 출시하여 지속성 있는 에이전트 운영에 따른 인프라 복잡성을 해소하고 있다 [1, 5].
|
||||
* **Microsoft:** 모든 에이전트가 고유의 컴퓨터를 가져야 한다는 철학 아래 Foundry에 호스팅형 에이전트를 출시했다. 이는 영구적 상태(Durable state), 내장된 신원 확인 및 거버넌스, 그리고 다양한 하네스와 프레임워크를 지원하는 엔터프라이즈급 전용 샌드박스를 제공한다 [1].
|
||||
* **기타 오케스트레이션 플랫폼:** OpenAI 역시 자체 Agents SDK를 대폭 업데이트하였으며, MindStudio와 같은 플랫폼은 시각적 빌더와 방대한 통합(Integration) 풀을 통해 오케스트레이션 코드를 밑바닥부터 짜지 않도록 지원하는 유사한 접근 방식을 취하고 있다 [1, 4].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **벤더 및 프레임워크 종속성(Vendor Lock-in) 문제:** 특정 HaaS 제공자의 클라우드 런타임과 관측성(Observability) 도구에 지나치게 의존할 경우, 향후 다른 인프라 환경이나 오픈소스 프레임워크로 에이전트 코드를 마이그레이션하기 어려워지는 종속성 문제가 발생할 수 있다 [6-8].
|
||||
* **데이터 품질 검증의 한계:** 관리형 하네스 서비스는 에이전트가 '어떻게 실행되는가(오케스트레이션)'는 훌륭히 제어하지만, 에이전트가 '무엇을 읽어 들이는가(입력 데이터)'에 대한 거버넌스는 제공하지 않는다 [9]. 즉, 제공된 데이터가 스키마가 변형되었거나 오래되고 인증되지 않은 데이터일 경우 HaaS 자체적으로는 이를 차단할 수 없으므로, 데이터 품질 오류로 인한 에이전트의 연쇄적 실패를 막기 위해서는 별도의 데이터 거버넌스 인프라를 구축해야 하는 제약이 존재한다 [9-11].
|
||||
* **보안 경계와 내부 통제력의 교환:** HaaS는 자체 호스팅(Self-hosting) 방식과 비교하여 소규모 팀의 운영 부담을 획기적으로 줄여주지만, 에이전트의 관측 데이터와 실행 트레이스가 외부 서비스에 종속된다 [8]. 따라서 조직 자체의 엄격한 보안 경계(Security perimeter) 내에 모든 데이터를 보관해야 하는 규제 산업이나 특수 환경에서는 클라우드 기반 관리형 하네스의 도입이 보안 정책상 반대 급부로 작용할 수 있다 [8].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-05*
|
||||
@@ -0,0 +1,27 @@
|
||||
# [[K9 Tactical Gear (경찰견 전술 장비)]]
|
||||
|
||||
## 📌 Brief 시 Summary
|
||||
K9 전술 장비(K9 Tactical Gear)는 법 집행 기관, 군사 작전, 수색 구조 및 재난 대응 분야에서 활약하는 작업견(Working dogs)이 임무를 안전하고 효과적으로 수행할 수 있도록 특수하게 설계된 장비이다 [1]. 이러한 장비는 작업견의 보호, 기능성, 편안함을 최우선으로 고려하며 방탄조끼, 모듈형 운송 팩, 전술 목줄 및 하네스 등으로 구성된다 [2]. 소프트웨어 분야의 '에이전트 하네스'가 AI 모델의 한계를 보완하고 통제하듯, K9 전술 하네스 역시 생물학적 에이전트인 작업견이 고위험 환경에서 안전하게 임무를 수행하고 핸들러와 통신 및 제어할 수 있도록 돕는 물리적 인프라 역할을 수행한다 [3].
|
||||
|
||||
## 📖 Core Content
|
||||
* **방어 및 보호 시스템 (K9 Tactical Vests):**
|
||||
* K9 전술 조끼는 탄도 위협, 환경적 위험, 물리적 긴장으로부터 작업견을 보호하기 위해 설계되었다 [2].
|
||||
* NIJ Level IIIA 등급의 소프트 아머 패널을 적용하여 .44 매그넘 총탄 등 권총탄을 최대 6회까지 방어하고 파편을 막아내는 방탄 능력을 제공한다 [2-4].
|
||||
* 1000D 코듀라(Cordura)나 립스톱 나일론 같은 내마모성 고강도 소재로 제작되며, 과열을 방지하기 위해 통기성이 뛰어난 메쉬 안감을 사용한다 [2-5].
|
||||
* **모듈형 확장성 및 제어 (MOLLE & Handling):**
|
||||
* 조끼와 하네스 양측에는 MOLLE(Modular Lightweight Load-carrying Equipment) 웨빙이 적용되어 의료 키트, 물병, 카메라, GPS 장치 등 임무 특화 장비를 부착할 수 있다 [2, 3, 6].
|
||||
* 위험한 지형에서 작업견을 들어 올리거나 즉각적으로 물리적 제어를 할 수 있도록 튼튼한 운반용 핸들(Carry handles)과 금속 리쉬(Leash) 부착 지점이 제공된다 [2, 3, 6].
|
||||
* 부대 식별이나 특성을 나타낼 수 있는 패치 부착용 벨크로 패널 및 야간 시야 확보용 반사 스트립 등이 포함된다 [2, 6].
|
||||
* **운송 및 보조 장비 (Packs & Accessories):**
|
||||
* 장기 임무 시 식수, 응급처치 용품 등을 운반할 수 있는 모듈형 배낭을 사용하며, 방수 수납공간을 갖추어 젖은 환경에서도 장비를 보호한다 [5].
|
||||
* 응급 상황 시 신속하게 장비를 해제할 수 있는 퀵 릴리스 버클, 거친 지형의 열이나 날카로운 파편으로부터 발을 보호하는 보호 부츠, 무더운 기후에서 체온을 조절하는 쿨링 조끼 등이 활용된다 [7, 8].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **하중의 제약 및 체력적 한계 (Weight Limits & Strain):** K9이 장비를 착용할 때 무게 제약이 가장 큰 반대급부로 작용한다. FEMA 지침에 따르면 작업견에게 체력적 무리를 주지 않기 위해 장비 팩의 총 무게는 작업견 체중의 25%를 초과해서는 안 된다 [5]. 무거운 방탄 플레이트나 추가 장비의 부착은 이동성을 저하시킬 수 있다.
|
||||
* **임무 특성에 따른 장비 절충 (Mission-Specific Selection):** 보호력과 기동성 사이에는 명확한 트레이드오프가 존재한다. 예를 들어, 무장 대치 상황에 투입되는 SWAT 팀 작업견은 다소 무겁더라도 탄도 아머(방탄조끼)가 필수적인 반면, 광활한 야생에서 임무를 수행하는 수색구조견에게는 무거운 아머보다는 가볍고 통기성이 뛰어난 조끼가 생존과 임무 수행에 훨씬 유리하다 [9].
|
||||
* **핏(Fit) 불일치로 인한 이동성 저해 위험:** 크기가 맞지 않는 장비를 착용하면 작업견의 기동성이 크게 손상될 수 있다. 따라서 개체의 가슴, 목, 길이 등을 정확하게 측정하여 움직임을 구속하지 않는 제품을 선택해야 하는 까다로움이 따른다 [2, 9].
|
||||
* **지속적인 유지보수 요구:** 고강도의 활동에 노출되므로 장비의 파손 여부를 정기적으로 검사하고 순한 비누로 세척하는 등 꼼꼼한 관리 절차가 필수적으로 요구된다 [9].
|
||||
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-05*
|
||||
@@ -0,0 +1,35 @@
|
||||
---
|
||||
id: HARNESS-RES-2026-05-007
|
||||
title: 커널 수준 격리 (Kernel-level Isolation)
|
||||
category: "10_Wiki/Topics/Infrastructure"
|
||||
status: verified
|
||||
confidence_score: 0.94
|
||||
tags: [harness, security, isolation, kernel, microvm, landlock, seccomp]
|
||||
created_at: 2026-05-05
|
||||
updated_at: 2026-05-08
|
||||
---
|
||||
|
||||
# 커널 수준 격리 (Kernel-level Isolation)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "타협 불가능한 보안 경계: Landlock, seccomp, microVM 등을 활용해 운영체제 커널 차원에서 에이전트의 권한을 물리적으로 제한하여, 손상된 에이전트조차 우회할 수 없는 철벽 샌드박스를 구현하는 기술."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **보안의 근본적 강제성**: 커널 수준 격리는 호스트 시스템과 에이전트의 워크로드를 운영체제 커널 차원에서 엄격하게 분리한다 [1, 2]. 제약 조건이 환경 자체에 귀속되므로, 손상된 에이전트라 할지라도 보안 설정을 재정의(override)할 수 없는 강력한 방어력을 보장한다 [2].
|
||||
* **주요 구현 기술 및 도구**:
|
||||
* **NVIDIA OpenShell**: Landlock LSM(파일 시스템 제어)과 seccomp BPF(시스템 호출 제어)를 통해 정책 기반의 샌드박스 런타임을 구현한다 [2].
|
||||
* **LangSmith Sandboxes**: microVM 기반 아키텍처를 사용하여 CPU, 메모리, 디스크 리소스 캡(caps)을 설정하고 런타임 환경에서 비밀 데이터를 배제하는 인증 프록시를 결합한다 [1].
|
||||
* **Kubernetes Agent Sandbox**: K8s 네이티브 Sandbox CRD를 통해 gVisor 및 Kata Containers 기술을 활용한 격리 환경을 관리한다 [3].
|
||||
* **CubeSandbox (Tencent Cloud)**: eBPF로 강제되는 네트워크 정책과 마이크로VM 기술을 결합하여 60ms 미만의 콜드 스타트 성능과 강력한 격리를 동시에 달성한다 [3].
|
||||
|
||||
## ⚖️ 트레이드오프 및 고려사항
|
||||
* **보안성과 성능의 반비례 관계**: 커널 수준 격리를 채택할 경우 고도의 보안성을 얻는 대신, V8 Isolate와 같은 초경량 샌드박싱 기술에 비해 리소스 소모와 시작 지연 시간(Latency)이 발생할 수 있다 [2].
|
||||
* **운영 복잡성**: LSM(Linux Security Module)이나 BPF 정책을 관리하는 것은 높은 수준의 인프라 전문 지식을 요구하며, 에이전트의 정상적인 도구 호출까지 차단하지 않도록 정교한 정책 설계가 수반되어야 한다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **상위 개념**: [[Sandbox]], [[Operating System Security]]
|
||||
- **유사 개념**: [[MicroVM]], [[LSM (Linux Security Module)]], [[gVisor]], [[seccomp]]
|
||||
- **관련 프로젝트**: [[NVIDIA OpenShell]], [[ConnectAI]]
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-08*
|
||||
@@ -0,0 +1,18 @@
|
||||
# [[L3 Meta-Factory]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
L3 Meta-Factory는 단순한 에이전트 하네스 실행 환경을 넘어 "다른 하네스들을 생성하는 층"으로 기능하는 Claude Code 생태계의 최상위 아키텍처 계층이다 [1, 2]. 이 계층은 사용자의 자연어 도메인 설명을 바탕으로 전문 에이전트 팀 구조, 런타임 설정, 그리고 에이전트가 사용할 스킬 파일들을 자동으로 찍어내는(factory) 역할을 수행한다 [1, 2]. 목적과 생성 결과물에 따라 팀 아키텍처 팩토리(Team-Architecture Factory)나 런타임 설정 팩토리(Runtime-Configuration Factory) 등 여러 서브 층으로 세분화된다 [1, 3].
|
||||
|
||||
## 📖 Core Content
|
||||
* **L3 Meta-Factory의 핵심 역할**: 에이전트를 조율하는 단일 하네스를 운영하는 것을 넘어, 주어진 과제에 맞는 에이전트 하네스 구조 자체를 동적으로 생성하는 메타 인프라 역할을 한다 [1]. 사용자가 "하네스 구성해줘"와 같은 명령을 내리면 도메인을 분석해 에이전트 정의(`.claude/agents/`)와 스킬(`.claude/skills/`)을 자동 생성해 준다 [2].
|
||||
* **주요 서브 층(Sub-layers)의 구분**:
|
||||
* **Team-Architecture Factory**: 팀 구조, 메시지 프로토콜, 리뷰 게이트 등 에이전트 팀 아키텍처와 스킬을 뽑아내는 데 특화된 층이다 [3, 4]. `revfactory/harness`가 대표적이며 파이프라인, 팬아웃/팬인, 전문가 풀, 생성-검증, 감독자, 계층적 위임 등 6가지 사전 정의된 아키텍처 패턴을 지원한다 [1, 2].
|
||||
* **Runtime-Configuration Factory**: 결정적(deterministic)이고 반복 가능한 런타임 설정을 생성하는 데 특화된 층으로, `coleam00/Archon`이 대표적인 프레임워크다 [1, 3, 4].
|
||||
* **Codex Runtime Port**: 메타 팩토리 컨셉을 Codex 런타임 환경에 맞게 구현한 층이며, `SaehwanPark/meta-harness`가 여기에 속한다 [1, 3, 5].
|
||||
* **모듈형 운영 및 조합 방식**: 동일한 L3 계층 내에 존재하더라도 각 서브 층의 용도는 명확히 분리된다 [3]. 팀 아키텍처의 설계가 필요할 때는 Team-Architecture Factory를 활용하고, 런타임 결정성이 필요할 때는 Runtime-Configuration Factory를 사용하며, 필요시 두 팩토리를 조합(아키텍처 설계 후 런타임에 배포)하여 상호 보완적으로 운용할 수 있다 [3, 4].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
소스에 L3 Meta-Factory 아키텍처 도입에 따른 직접적인 부작용이나 최적화의 기술적 한계에 대한 구체적인 관련 정보가 부족합니다. 다만, 단일 팩토리가 모든 하네스 구성 요소를 완벽하게 제공하지 않으므로 목적에 따른 팩토리의 분리 및 조합이 필수적이라는 제약 사항이 존재한다 [3, 4]. 예를 들어 팀 아키텍처 설계 기능과 런타임 결정성 보장 기능은 서로 다른 서브 층에서 개별적으로 처리되므로, 두 가지 요구사항을 모두 충족하려면 서로 다른 팩토리(예: `revfactory/harness`와 `coleam00/Archon`)를 명시적으로 구분하여 조합해야 하는 파이프라인 설계상의 복잡성이 수반된다 [3, 4].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-05*
|
||||
@@ -0,0 +1,17 @@
|
||||
# [[LLM-as-judge]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
LLM-as-judge는 인공지능 에이전트 하네스 환경에서 모델의 산출물이나 시스템의 동작을 평가하기 위해 대규모 언어 모델(LLM) 자체를 심사관(judge)으로 활용하는 추론적(Inferential) 제어 및 평가 방식이다 [1, 2]. 주로 AI 코드 리뷰, 의미론적 분석, 응답 품질의 지속적 샘플링 및 로그 이상 징후 탐지 등에 활용된다 [2, 3]. 이를 통해 인간 개발자가 모든 것을 검토하지 않고도 에이전트의 워크플로우를 테스트하고 신뢰할 수 있는 검증 루프를 구축할 수 있도록 돕는다 [1, 2].
|
||||
|
||||
## 📖 Core Content
|
||||
* **추론적 피드백 센서로서의 역할:** 에이전트 하네스 내에서 LLM-as-judge는 의미론적 판단(Semantic judgment)이 필요한 문제를 다루는 '추론적 센서(Inferential sensor)'로 기능한다 [2, 4]. 린터(Linter)나 단위 테스트와 같이 빠르고 결정론적인 연산적(Computational) 센서와 달리, 문맥적 이해가 필요한 AI 코드 리뷰나 응답 품질 모니터링 등의 영역에서 에이전트의 상태를 감시하고 오류를 식별한다 [2, 3].
|
||||
* **평가 및 CI 파이프라인 통합:** 다양한 에이전트 프레임워크와 관측 도구들은 LLM-as-judge를 기본 평가 메커니즘으로 채택하고 있다. `promptfoo`, `Weights & Biases Weave`, `Mastra` 등의 도구는 LLM-as-judge를 내장하여 에이전트 산출물의 회귀 테스트를 CI(지속적 통합) 파이프라인에 직접 통합할 수 있도록 지원한다 [1, 5, 6].
|
||||
* **평가자 모델 역량에 대한 높은 의존성:** Red Hat의 평가 주도 개발(Eval-Driven Development) 사례 연구에 따르면, LLM-as-judge 역할을 수행하는 평가자 모델의 역량(Capability)은 평가의 정확도에 결정적인 영향을 미친다 [1]. 실제 실험에서 대형 모델(llama-3-3-70b)은 알려진 실패 사례를 모두 잡아낸 반면, 더 작은 모델들은 여러 실패 사례를 놓치는 한계를 보였다 [1]. 즉, 적절하고 강력한 모델을 평가자로 사용할 때만 시스템에 대한 실질적인 신뢰도를 높일 수 있다 [2].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **높은 비용 및 실행 지연:** LLM-as-judge는 GPU나 NPU 자원을 사용하기 때문에 전통적인 연산적 센서에 비해 실행 속도가 느리고 비용이 많이 든다 [2, 4]. 따라서 에이전트가 코드를 변경하는 모든 커밋(Commit)마다 LLM-as-judge를 실행하는 것은 경제적으로나 시간적으로 비효율적이다 [4].
|
||||
* **비결정성(Non-determinism)과 평가 피로:** 확률론적 모델에 기반하므로 평가 결과가 항상 100% 동일하게 보장되지 않는 비결정성을 띤다 [2, 4].
|
||||
* **설계적 제약:** 무분별한 LLM-as-judge의 사용은 막대한 평가 비용으로 인해 시스템 전체를 무너뜨릴 수 있으므로(eval cost collapse), 유의미한 리스크를 줄일 수 있는 핵심적인 위치에만 값비싼 검사를 추가하는 계층적 가드레일 설계가 필수적이다 [1].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-05*
|
||||
@@ -0,0 +1,18 @@
|
||||
# [[LLMOps]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
LLMOps는 프로덕션 환경에서 대규모 언어 모델(LLM)과 AI 에이전트의 실행을 추적, 평가, 모니터링 및 관리하는 운영 체계를 의미합니다 [1]. 이를 위해 모델 호출, 프롬프트 관리, 평가 파이프라인 등을 통합적으로 지원하는 플랫폼이 활용되며 대표적인 오픈소스 LLMOps 도구로는 Langfuse가 있습니다 [1, 2]. 이 체계는 팀 단위의 협업과 자체 호스팅(Self-hosted) 환경을 통해 에이전트의 관측 가능성(Observability)을 확보하는 데 중점을 둡니다 [1, 2].
|
||||
|
||||
## 📖 Core Content
|
||||
* **LLM 추적(Tracing) 및 모델 호출 연동:** LLMOps 플랫폼은 스팬(Span) 수준에서 LLM 호출을 추적하여, 모델의 호출 과정을 프롬프트, 입력(Input), 출력(Output)과 명확히 연결합니다 [2].
|
||||
* **프롬프트 관리 및 출력 평가 파이프라인:** 프롬프트의 버전을 체계적으로 관리하며, 특정 프롬프트 버전에 평가 점수를 연동합니다 [2]. 또한, 사전에 정의된 기준에 따라 모델의 출력물을 채점(Scoring)하는 평가 파이프라인을 내장하고 있습니다 [2].
|
||||
* **보안 및 자체 호스팅(Self-hosting) 지원:** LLMOps 환경은 특정 벤더에 대한 관측성 데이터 종속성(Vendor lock-in)을 방지하기 위해 자체 호스팅을 지원합니다 [1, 2]. 이를 통해 조직은 자체 보안 경계 내에서 데이터를 안전하게 보관할 수 있습니다 [2].
|
||||
* **팀 협업(Team Collaboration) 워크플로우:** 공유된 LLMOps 워크플로우를 통해 팀원들이 에이전트 실행의 추적(Traces) 데이터와 평가 결과에 공동으로 접근하고 분석할 수 있도록 지원합니다 [2].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **사후 처리(Post-hoc)의 근본적 한계:** LLMOps 및 관측성 도구들의 가장 큰 제약은 에이전트가 실행된 '이후'에 발생한 결과를 평가하고 모니터링한다는 점입니다 [3, 4]. 이 도구들은 모델의 출력과 프롬프트 성능은 평가할 수 있지만, 모델에 입력된 소스 데이터 자체가 오래되었거나 검증되지 않았거나 스키마가 변형되었는지 여부는 판단하지 못합니다 [4-6].
|
||||
* **오도된 평가 점수(Misleading Scores) 발생 위험:** 위와 같은 데이터 품질 관리의 부재로 인해, 잘못되거나 오염된 입력 데이터를 기반으로 생성된 출력물에 대해서도 높은 평가 점수가 부여될 수 있는 심각한 오류 가능성이 존재합니다 [5].
|
||||
* **운영 오버헤드 증가:** 시스템 내부에서 LLM 호출의 모든 단계를 추적하는 과정에서 약 15%의 성능 오버헤드(Performance overhead)가 발생할 수 있습니다 [2]. 또한, 보안을 위해 자체 호스팅 옵션을 선택할 경우 규모가 작은 팀에게는 추가적인 운영 부담(Operational burden)으로 작용할 수 있습니다 [2].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-05*
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
id: HARNESS-RES-2026-05-015
|
||||
title: Langfuse
|
||||
category: "10_Wiki/Topics/Observability"
|
||||
status: verified
|
||||
confidence_score: 0.95
|
||||
tags: [harness, llmops, observability, trace, evaluation, prompt-management]
|
||||
created_at: 2026-05-05
|
||||
updated_at: 2026-05-08
|
||||
---
|
||||
|
||||
# Langfuse
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "LLMOps의 블랙박스를 여는 열쇠: 오픈소스 기반으로 에이전트의 모든 실행 단계를 추적(Trace)하고, 프롬프트 관리와 평가 파이프라인을 단일 인터페이스에서 통합 제공하는 가시성 플랫폼."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **핵심 가시성 및 추적 (Observability):** 스팬(Span) 수준에서 LLM 호출을 추적하여 모델 호출을 프롬프트, 입출력 데이터와 연결한다 [5]. 에이전트 실행 후 발생한 이벤트를 기록하고 분석하며, 데이터 레지던시가 중요한 환경에서 클라우드 대안보다 선호된다 [2, 4].
|
||||
* **프롬프트 및 평가 관리:** 내장된 관리 기능을 통해 프롬프트 버전을 추적하고, 평가 점수를 특정 버전과 직접 매핑한다 [5]. 사전에 정의된 기준에 따라 모델의 출력물을 채점하는 자동 평가 파이프라인을 지원한다 [5].
|
||||
* **자체 호스팅 및 보안:** MIT 라이선스 기반의 자체 호스팅(Self-hosted)을 지원하여 조직의 보안 경계 내에 가시성 데이터를 안전하게 보관할 수 있으며, 팀 간 협업 워크플로우를 제공한다 [3, 5, 6].
|
||||
|
||||
## ⚖️ 트레이드오프 및 고려사항
|
||||
* **성능 오버헤드:** 에이전트 파이프라인에 통합 시 약 15%의 성능 오버헤드가 발생할 수 있다 [1, 5]. 또한 자체 호스팅의 경우 구축 및 유지보수를 위한 운영 부담이 수반된다 [5].
|
||||
* **입력 데이터 품질 검증의 부재:** Langfuse는 '사후(Post-hoc)' 관찰 도구이므로, 에이전트가 읽어 들인 컨텍스트(입력 데이터) 자체의 최신성이나 스키마 표류 여부를 검증하지 못한다 [3, 4]. 불량 데이터를 기반으로 생성된 출력에 대해서도 긍정적 평가가 내려질 수 있는 '오도(Misleading)'의 위험이 존재한다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **상위 개념**: [[LLMOps]], [[Observability]]
|
||||
- **유사 개념**: [[AgentOps]], [[LangSmith]], [[Arize Phoenix]]
|
||||
- **관련 프로젝트**: [[ConnectAI]]
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-08*
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
id: HARNESS-RES-2026-05-016
|
||||
title: Mcp-Session-Id
|
||||
category: "10_Wiki/Topics/Infrastructure"
|
||||
status: verified
|
||||
confidence_score: 0.94
|
||||
tags: [harness, mcp, session-management, http-transport, stateful, horizontal-scaling]
|
||||
created_at: 2026-05-05
|
||||
updated_at: 2026-05-08
|
||||
---
|
||||
|
||||
# Mcp-Session-Id
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "원격 MCP의 상태 엔진: 로컬을 넘어 서버급으로 확장된 MCP 통신에서 클라이언트를 식별하는 상태 저장 헤더이자, 동시에 수평적 확장을 가로막는 인프라적 트레이드오프의 핵심."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **Streamable HTTP 전송 체계 지원:** MCP 서버가 단일 기기의 로컬 프로세스를 넘어 원격 서비스로서 작동할 수 있도록 도입된 Streamable HTTP 전송 방식의 핵심 구성 요소이다 [1].
|
||||
* **세션 식별 및 추적:** 원격으로 배포된 MCP 서버가 다수의 클라이언트 연결(Multiple client connections)을 처리하기 위해, 각 연결의 상태를 유지하고 추적하는 용도로 `Mcp-Session-Id` 헤더를 활용한다 [1].
|
||||
* **통신 매커니즘:** 클라이언트에서 서버로 향하는 메시지는 HTTP POST를 사용하며, 서버에서 클라이언트로 향하는 SSE(Server-Sent Events) 스트림과 함께 세션 ID를 통해 일관된 상호작용을 보장한다 [1].
|
||||
|
||||
## ⚖️ 트레이드오프 및 고려사항
|
||||
* **수평적 확장성(Horizontal Scaling)의 제약:** 상태가 저장되는(Stateful) 헤더의 특성상, 트래픽을 분산시키는 로드 밸런서나 서버의 수평적 확장 환경과 기능적으로 충돌할 수 있다 [1].
|
||||
* **전송 계층과의 강한 결합:** 현재 사양은 세션 관리가 전송 계층에 밀접하게 결합되어 있어 대규모 인프라 확장이 까다롭다. 이를 해결하기 위해 2026년 로드맵에서는 세션을 전송 계층에서 분리(Decoupling)하는 방향이 논의되고 있다 [1].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **상위 개념**: [[MCP (Model Context Protocol)]], [[Session Management]]
|
||||
- **유사 개념**: [[HTTP+SSE]], [[Streamable HTTP]], [[Load Balancing]]
|
||||
- **관련 프로젝트**: [[ConnectAI]]
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-08*
|
||||
@@ -0,0 +1,17 @@
|
||||
# [[Meta-Harness (메타 하네스)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
메타 하네스(Meta-Harness)는 개별 에이전트 하네스를 수동으로 조정하는 대신, 에이전트가 스스로 하네스 구성(프롬프트, 도구 정의, 컨텍스트 관리 등)을 진화시키고 최적화하도록 지원하는 상위 계층의 프레임워크이자 자동화 패러다임이다 [1]. 이는 다른 하네스들을 자동 생성하는 '메타 팩토리(Meta-Factory)'의 역할을 수행하거나, 외부 최적화 루프를 통해 실패를 진단하고 하네스를 재작성하는 자가 개선(Self-improving) 시스템으로 구현된다 [1, 2].
|
||||
|
||||
## 📖 Core Content
|
||||
* **엔드투엔드 최적화 표적 (End-to-End Optimization):** 메타 하네스는 시스템 프롬프트, 도구 정의, 맥락 관리, 완료 로직 등을 개별적으로 튜닝하지 않고 하네스 전체를 공동 최적화(Joint optimization)의 대상으로 삼는다 [1]. 제안자 에이전트(Proposer agent)에게 이전 하네스 후보, 점수, 실행 추적(Execution traces)에 대한 파일 시스템 접근 권한을 부여하여 실패 원인을 특정 하네스 결정의 결과로 역추적하게 한다 [1].
|
||||
* **하네스 메타 팩토리 (L3 Meta-Factory):** 메타 하네스는 '다른 하네스들을 생성하는 계층'으로도 기능한다 [2]. 예를 들어, `revfactory/harness` 프레임워크는 사용자의 도메인 설명만으로 사전 정의된 6가지 패턴 중 하나를 선택해 에이전트 팀과 스킬을 자동 생성하는 '팀 아키텍처 팩토리(Team-Architecture Factory)' 역할을 하며, `Archon`은 결정적이고 반복 가능한 런타임 설정을 생성하는 역할을 분담하여 이웃 서브 층으로 공존한다 [2, 3].
|
||||
* **자율적 하네스 진화 (Autonomous Harness Evolution):** 에이전트가 자신의 실행 기록을 기반으로 프롬프트, 도구, 전략 등 스캐폴딩(Scaffolding) 자체를 수정하도록 설계된 궁극적인 형태의 메타 하네스가 존재한다 [1]. 대표적으로 `harness-evolver`나 `stanford-iris-lab/meta-harness` 같은 구현체들은 파일 시스템 기반의 검색 루프를 통해 코딩 에이전트가 하네스 아티팩트를 자율적으로 제안, 평가, 정제하는 과정을 거치며 성능을 향상시킨다 [1, 4].
|
||||
* **역할 분리 패턴 (Program.md 패턴):** 인간은 `PROGRAM.md`와 같은 파일에 최적화 지시(Directive)를 작성하고, 에이전트는 하네스 엔지니어링 루프를 직접 실행하는 패턴이 가장 실용적인 메타 하네스 접근법으로 꼽힌다 [1]. 이를 통해 단순히 정적인 설정을 넘어서 `AGENTS.md`, 설정 스크립트, 테스트 흐름 등을 최적화 가능한 학습 매개변수로 취급하여 레이블링된 훈련 데이터 없이도 신뢰성을 크게 끌어올린다 [4].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **막대한 컨텍스트 및 토큰 비용:** 메타 하네스 접근법은 제안자 에이전트가 하네스 결정의 실패 원인을 추적하기 위해 이전 하네스 후보와 수많은 실행 추적(Traces) 데이터에 모두 접근해야 한다. 이로 인해 기존 연구(약 26,000 토큰)에 비해 엄청난 규모인 1,000만(10M) 토큰 수준의 진단 컨텍스트를 요구하므로, 막대한 리소스 오버헤드가 발생한다는 제약이 있다 [1].
|
||||
* **메타 평가(Meta-Evaluation) 인프라 구축의 난해함:** 한 에이전트가 다른 에이전트의 하네스를 반복적으로 최적화하는 과정(Agent-on-agent optimization)에서는, 최적화가 실제로 타겟 에이전트를 개선하고 있는지 체계적으로 측정하기 어렵다는 '메타 평가의 공백(Meta-evaluation gap)' 문제가 발생한다 [5]. 이를 해결하기 위해서는 버전화된 에이전트 스냅샷, 예산이 통제된 평가(Budget-controlled evaluation), 그리고 구조화된 실행 추적을 캡처하는 복잡한 전용 평가 프레임워크(예: VeRO)가 필수적으로 수반되어야 한다 [5].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-05*
|
||||
@@ -0,0 +1,33 @@
|
||||
---
|
||||
id: HARNESS-RES-2026-05-004
|
||||
title: 메타-하네스 (Meta-Harness)
|
||||
category: "10_Wiki/Topics/Architecture"
|
||||
status: verified
|
||||
confidence_score: 0.96
|
||||
tags: [harness, meta-harness, self-improvement, outer-loop, optimization]
|
||||
created_at: 2026-05-05
|
||||
updated_at: 2026-05-08
|
||||
---
|
||||
|
||||
# 메타-하네스 (Meta-Harness)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "하네스를 가르치는 하네스: 에이전트의 실행 인프라 자체를 학습 가능한 매개변수로 취급하여, 과거의 실패 로그를 기반으로 시스템 프롬프트와 도구 정의를 자율적으로 진화시키는 아우터 루프(Outer-loop) 최적화 체계."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **하네스의 아티팩트화 및 학습 가능성**: 메타-하네스는 `AGENTS.md`, 설정 스크립트, 검증 로직, 테스트 흐름과 같은 하네스의 요소들을 정적인 설정(static configs)이 아니라, 언제든 최적화할 수 있는 아티팩트이자 학습 가능한 매개변수(learnable parameters)로 취급한다 [2]. 단순히 프롬프트를 넘어서 라우팅, 검색, 오케스트레이션 코드까지 모두 최적화의 대상이 된다 [1].
|
||||
* **파일 시스템 기반의 최적화 루프**: 제안자(proposer) 역할을 하는 에이전트는 파일 시스템에 접근하여 이전의 모든 하네스 후보군, 평가 점수, 실행 트레이스에 대한 방대한 진단 컨텍스트를 읽는다 [1]. 이를 통해 에이전트는 실패의 원인을 특정 하네스 설계의 결정으로 추적하고 지속적인 편집-실행-평가(edit-execute-evaluate) 루프를 구동한다 [1, 2].
|
||||
* **프로그램 기반 역할 분리 (PROGRAM.md 패턴)**: 메타-하네스의 가장 실용적인 패턴 중 하나는 역할의 분리이다 [1]. 인간은 `PROGRAM.md`와 같은 파일을 통해 최적화 지침(directive)만을 작성하고, 실제 하네스 엔지니어링 루프(프롬프트, 도구 설정, 에이전트 라우팅 최적화 등)는 에이전트가 자율적으로 실행하도록 하는 방식이 활용된다 [1].
|
||||
* **재귀적 개선과 자율 진화 메커니즘**: 메타-하네스는 작업 해결과 메타 수준의 개선을 하나의 수정 가능한 프로그램으로 통합하여 인지적 자기 수정(metacognitive self-modification)을 가능하게 한다 [1]. 이는 향후 자율형 인공지능이 자신의 실패 로그를 분석해 하네스 가이드라인을 스스로 수정하며 성능을 높이는 '재귀적 개선(recursive improvement)' 메커니즘으로 발전하는 핵심 토대가 된다 [3].
|
||||
|
||||
## ⚖️ 트레이드오프 및 고려사항
|
||||
* **막대한 컨텍스트 처리 요구량**: 에이전트가 하네스의 실패 원인을 정확히 추적하기 위해서는 이전 하네스의 후보군, 점수, 그리고 매우 방대한 실행 트레이스를 모두 읽어야 한다. 최대 천만(10M) 토큰 규모의 방대한 진단 컨텍스트(diagnostic context)를 처리할 수 있는 역량이 요구된다 [1].
|
||||
* **회귀(Regression) 위험과 검증 인프라 필수**: 에이전트가 스스로 하네스 코드를 변경하므로, 잘못된 수정으로 인해 오히려 기존 성능이 저하되는 회귀 현상이 발생할 위험이 크다 [1]. 따라서 독립된 작업 공간이나 샌드박스 환경에서의 철저한 검증과 강력한 회귀 방지 가드(regression guards)가 필수적으로 수반되어야 한다 [1].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **상위 개념**: [[AI Infrastructure]], [[Self-Improving AI]]
|
||||
- **유사 개념**: [[Harness Multiplier]], [[Recursive Improvement]], [[Ablation Protocol]]
|
||||
- **관련 프로젝트**: [[ConnectAI]], [[OpenHarness]]
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-08*
|
||||
@@ -0,0 +1,24 @@
|
||||
# [[Open Harness]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
'Open Harness'는 AI 에이전트를 구동하고 관리하기 위해 개발된 오픈소스 기반의 하네스 및 런타임 프로젝트들을 의미한다 [1-3]. 제공된 소스에 따르면 명칭은 같지만 목적과 아키텍처가 완전히 다른 세 가지 주요 프로젝트(HKUDS의 런타임, MaxGfeller의 상호운용성 SDK, ryaneggz의 샌드박스)가 존재한다 [1, 3]. 이 도구들은 각각 생산 환경 하네스의 내부 작동 방식 검사, 프레임워크 종속성 탈피, 그리고 독립된 단일 프로젝트 실행 환경 제공이라는 고유한 인프라 역할을 수행한다 [2-4].
|
||||
|
||||
## 📖 Core Content
|
||||
* **OpenHarness (HKUDS):** 홍콩대학교 데이터 시스템 그룹(HKUDS)에서 개발한 CLI 중심의 오픈소스 에이전트 런타임이다 [2, 5]. 생산 환경의 에이전트 하네스 내부 작동 방식을 검사하고자 하는 연구자와 개발자를 위해 설계되었다 [2].
|
||||
* 파일, 셸, 웹 검색, MCP 등 43개 이상의 내장 도구를 갖추고 있으며, 스트리밍 도구 호출 주기, 다단계 권한 모드, `MEMORY.md`를 통한 상태 보존 및 백그라운드 작업 관리 기능을 지원한다 [2, 5, 6].
|
||||
* 이 프로젝트는 'ohmo'라는 내장 개인용 AI 에이전트 앱을 포함하고 있으며, 모델 추론과 도구 실행의 투명한 가시성을 제공한다 [2, 7, 8].
|
||||
* **OpenHarness.ai (MaxGfeller):** 하네스 프레임워크 간의 종속성(Lock-in)을 피하기 위해 개발된 상호운용성 SDK 계층이다 [4].
|
||||
* 에이전트 코드를 한 번 작성하면 수정 없이 Anthropic SDK, Goose, LangChain, Letta, Claude Code 등 여러 런타임 환경에 배포할 수 있는 유니버설 API를 제공한다 [4, 9].
|
||||
* 에이전트 내부에서 실행되는 런타임이라기보다는 코드를 다양한 런타임 간에 이식 가능하게 만드는 추상화 계층이다 [4].
|
||||
* **Open Harness (ryaneggz):** 단일 프로젝트(리포지토리)를 위해 설계된 Docker 기반의 에이전트 하네스 및 다중 계층 격리 샌드박스이다 [3].
|
||||
* "우리가 샌드박스를 제공할 테니, 당신은 하네스를 선택하라(BYOH)"는 철학을 가진다 [3].
|
||||
* 호스트의 종속성을 Docker 하나로 제한하며, 마크다운(`crons/*.md`)으로 정의된 일정에 따라 백그라운드에서 에이전트를 구동시키는 'croner' 런타임을 특징으로 한다 [3, 10].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **데이터 품질 및 거버넌스 제어 부재:** HKUDS의 런타임과 MaxGfeller의 SDK 모두 에이전트가 처리하는 데이터 자체를 검증, 인증하거나 데이터 계보를 추적하는 데이터 품질 거버넌스 기능이 근본적으로 결여되어 있다 [4, 11].
|
||||
* **HKUDS OpenHarness의 제약:** 연구 중심의 초기 릴리스이므로, 상용 프레임워크 대안들에 비해 엔터프라이즈용 관리 도구가 부족하다 [12]. 또한 CLI 우선 설계 방식이므로 종합적인 시각적 인터페이스 환경을 기대하기 어렵다 [12].
|
||||
* **MaxGfeller OpenHarness.ai의 제약:** 이 프로젝트는 오직 '이식성(Portability)' 문제만 해결하므로, 오케스트레이션이나 메모리, 관찰 가능성(Observability) 기능은 제공하지 않는다 [9]. 또한 지원되는 어댑터 목록에 전적으로 의존해야 하며, 커뮤니티 규모가 작아 엔터프라이즈 규모에서의 상용 검증이 부족하다 [9].
|
||||
* **ryaneggz Open Harness의 제약:** 구조적으로 다중 테넌트(Multi-tenant) 비교 환경이 아닌, 단일 리포지토리 및 단일 샌드박스 전용으로 엄격하게 제한되어 있다 [3]. 사용을 위해서는 Docker 호스트 종속성이 필수적으로 요구된다 [3].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-05*
|
||||
@@ -0,0 +1,32 @@
|
||||
# [[OpenHarness]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
OpenHarness는 에이전트 하네스 생태계에 존재하는 두 가지 독립적인 오픈소스 프로젝트를 동시에 지칭하는 용어이다 [1, 2]. 하나는 홍콩대학교(HKUDS)에서 개발한 CLI 기반의 에이전트 런타임 환경이며, 다른 하나는 MaxGfeller가 개발한 다양한 런타임 간 에이전트 코드 이식을 돕는 상호 운용성(Interoperability) SDK이다 [2-4]. 두 프로젝트 모두 상용 하네스 시스템의 제약에서 벗어나, 실행 주기의 내부 동작을 투명하게 검사하거나 벤더 종속성을 피하고자 하는 개발자와 연구자를 위해 설계되었다 [3, 5].
|
||||
|
||||
## 📖 Core Content
|
||||
|
||||
소스 자료에 따르면 OpenHarness라는 이름을 공유하지만 구조와 목적이 완전히 다른 두 개의 프로젝트가 존재한다 [1].
|
||||
|
||||
* **OpenHarness (HKUDS)**
|
||||
* **목적 및 특징:** 상용 에이전트 하네스의 내부 동작을 내부에서부터 투명하게 검사할 수 있도록 개발된 연구 및 개발자용 오픈소스 런타임이다 [3, 6]. CLI(Command Line Interface) 기반의 실행 주기를 투명하게 노출하며, 파일 시스템, 셸, 검색, 웹, MCP(Model Context Protocol) 등을 다루는 43개 이상의 내장 도구를 기본으로 제공한다 [7, 8].
|
||||
* **아키텍처 및 구성 요소:** 모델의 추론을 실제 작업과 연결하기 위해 스트리밍 도구 호출 주기, 지수 백오프 기반 재시도, 병렬 도구 실행 기능을 갖추고 있다 [9]. 컨텍스트 제어를 위해 CLAUDE.md 주입, 상태를 잃지 않는 자동 압축(Auto-Compaction), 경량 상태 관리를 위한 MEMORY.md 파일 기반 지속성 관리 기능을 지원한다 [10-12].
|
||||
* **에이전트 생태계 확장:** 이 프레임워크 위에서 'ohmo'라는 개인용 AI 에이전트를 내장 앱으로 제공하여 Slack, Discord, Telegram, Feishu 등의 메신저 채널과 연동할 수 있도록 지원한다 [13, 14]. 또한 claude-code 플러그인 생태계와 호환된다 [15].
|
||||
* **안전성 (Governance):** 작업 환경의 보안을 위해 다중 레벨 권한 모드(Default, Auto, Plan Mode)를 두어 실행을 제어하며, 실제 모델 호출이나 하위 에이전트 실행 없이 런타임 설정, 권한 상태 및 MCP 설정 문제 등을 사전에 안전하게 점검할 수 있는 '드라이 런(Dry-run)' 프리뷰 모드를 지원한다 [11, 16, 17].
|
||||
|
||||
* **OpenHarness.ai (MaxGfeller)**
|
||||
* **목적 및 특징:** 특정 프레임워크에 종속되는 것을 방지하기 위해 구축된 하네스 상호 운용성 SDK이다 [4]. 에이전트를 실행하는 런타임이 아니라, 한 번 작성한 에이전트 코드를 Anthropic SDK, Goose, LangChain, Letta, Claude Code 등 여러 실행 환경에 수정 없이 배포할 수 있게 해주는 추상화 계층이다 [4].
|
||||
* **아키텍처:** 도구(Tools), 메모리, 실행 컨텍스트에 관한 표준화된 범용 API를 정의하고 여러 런타임용 어댑터를 제공함으로써 에이전트 코드의 이식성을 보장한다 [5].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
|
||||
* **OpenHarness (HKUDS)의 제약 사항:**
|
||||
* 엔터프라이즈 환경에서의 한계: 초기 릴리스(v0.1.x) 단계로, 상용 대안들에 비해 엔터프라이즈용 관리 도구가 부족하며 본질적으로 연구 지향적인 특성을 띤다 [10].
|
||||
* 데이터 품질 관리의 부재: 하네스 내부로 유입되는 컨텍스트와 데이터 입력의 품질을 검증하거나 계보(Lineage)를 추적하는 등의 데이터 거버넌스 메커니즘이 전혀 없다 [4].
|
||||
* 인터페이스의 한계: React TUI(Terminal UI)를 부분적으로 지원하기는 하나, 기본적으로 CLI 우선 설계이므로 웹이나 시각적인 관리 인터페이스를 기대하는 환경에는 부적합하다 [10].
|
||||
|
||||
* **OpenHarness.ai (MaxGfeller)의 제약 사항:**
|
||||
* 단일 목적성의 한계: 오직 이식성(Portability) 해결에만 초점을 맞춘 도구이므로, 오케스트레이션, 메모리 관리, 옵저버빌리티(Observability) 등 하네스의 핵심 제어 기능은 전혀 제공하지 않는다 [5].
|
||||
* 생태계 및 품질의 제약: 커뮤니티 규모가 작아 엔터프라이즈 규모에서의 생산성 검증이 부족하며, SDK가 지원하는 어댑터 목록에 강하게 의존할 수밖에 없다 [5]. HKUDS 버전과 마찬가지로 모든 계층에서 데이터 품질 제어 장치가 전무하다 [18].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-05*
|
||||
@@ -0,0 +1,33 @@
|
||||
---
|
||||
id: HARNESS-RES-2026-05-008
|
||||
title: 권한 및 안전 (Permissions and Safety)
|
||||
category: "10_Wiki/Topics/Governance"
|
||||
status: verified
|
||||
confidence_score: 0.96
|
||||
tags: [harness, security, permissions, safety, hitl, rbac, governance]
|
||||
created_at: 2026-05-05
|
||||
updated_at: 2026-05-08
|
||||
---
|
||||
|
||||
# 권한 및 안전 (Permissions and Safety)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "에이전트의 야생성을 길들이는 고삐: 프롬프트 수준의 신뢰를 넘어, 다중 계층 권한 모드와 사전 행동 검증(Pre-action Verification)을 통해 에이전트의 행동을 구조적으로 인가하고 제어하는 거버넌스 프레임워크."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **구조적 인가 패턴 (Structured Authorization):** 현대적인 하네스는 자연어 프롬프트에만 의존하지 않고 다중 수준의 권한 모드(Default, Auto, Plan Mode 등)와 경로 기반 규칙을 통해 에이전트의 쓰기/실행 권한을 강제한다 [3, 4, 9].
|
||||
* **사전 행동 검증 및 정책 게이트 (Policy Gates):** 모든 도구 호출은 실행 전에 OPA(Open Policy Agent)나 인가 패브릭(Authorization Fabric)에 의해 평가된다. 'ALLOW, DENY, REQUIRE_APPROVAL' 등의 결정론적 정책을 통해 승인된 도구만 호출되도록 보장한다 [5, 10, 11].
|
||||
* **인간 개입 제어 (Human-in-the-Loop, HITL):** 고위험 행동(DB 수정, 이메일 발송 등) 식별 시 실행을 일시 중지(Interrupt)하고 인간의 승인을 기다리는 워크플로우를 구현하여, 최종 책임과 감독을 인간이 유지하도록 한다 [6, 8, 12].
|
||||
* **최소 권한 원칙 (Least-Privilege):** 에이전트는 독립적인 스크립트가 아니라 정의된 파이프라인 컨텍스트 내에서 동작하며, 허용된 리소스, 시크릿, RBAC 범위만을 상속받아 동작한다 [5, 7, 13].
|
||||
|
||||
## ⚖️ 트레이드오프 및 고려사항
|
||||
* **승인 피로 (Approval Fatigue):** 빈번한 승인 요구는 사용자가 내용을 확인하지 않고 무비판적으로 '자동 승인'하게 만드는 부작용을 낳을 수 있다. 이를 방지하기 위해 2단계 분류기를 통한 선별적 승인 모델이 연구되고 있으나, 이는 검증의 철저함을 약화시킬 우려가 있다 [4].
|
||||
* **신원 매핑의 복잡성:** 에이전트가 다중 서비스에 접근할 때 최종 사용자의 권한을 대리(On-behalf-of)할 것인지, 고정 자격 증명을 사용할 것인지에 따라 신원 매핑 및 메모리 격리의 기술적 복잡성이 극도로 증가한다 [4].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **상위 개념**: [[AI Governance]], [[Cybersecurity]]
|
||||
- **유사 개념**: [[RBAC (Role-Based Access Control)]], [[Human-in-the-Loop (HITL)]], [[Pre-Action Authorization]], [[Allow-listing]]
|
||||
- **관련 프로젝트**: [[OpenHarness]], [[Claude Code]], [[ConnectAI]]
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-08*
|
||||
@@ -0,0 +1,20 @@
|
||||
# [[Phase 3: Harness Engineering]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
'Phase 3: Harness Engineering'은 AI 에이전트 발전의 세 번째 단계로, 모델의 크기(Phase 1)나 프롬프트 및 컨텍스트(Phase 2)를 개선하는 것을 넘어 모델이 작동하는 '환경'을 설계하는 단계를 의미한다 [1, 2]. 이는 에이전트의 성공 여부를 결정짓는 컨텍스트 전달, 도구 인터페이스, 계획 아티팩트, 검증 루프, 메모리 시스템 및 샌드박스 등 스캐폴딩(Scaffolding)을 설계하는 공학적 규율이다 [3]. 이 단계에서는 "모델에게 무엇을 말할 것인가"가 아니라 "모델을 어떤 환경에서 작동시킬 것인가"에 집중하여 에이전트의 신뢰성과 성능을 극대화한다 [2].
|
||||
|
||||
## 📖 Core Content
|
||||
* **에이전트 발전의 3단계 진화:** AI 에이전트 개발은 더 큰 모델과 데이터를 학습시키는 '가중치 단계(Phase 1)', 프롬프트 엔지니어링이나 RAG 등을 통해 모델이 보는 것을 변경하는 '컨텍스트 단계(Phase 2)'를 거쳐, 현재 런타임과 인프라를 최적화하는 '하네스 엔지니어링 단계(Phase 3)'로 진화했다 [1].
|
||||
* **환경 및 스캐폴딩 중심 설계:** 모델 자체는 고정된 텍스트 생성기로 유지되지만, 영구적인 메모리, 스킬 파일, 작업 순서를 제어하는 런타임 등의 하네스 환경을 제공함으로써 에이전트의 신뢰성과 작업 해결 능력을 근본적으로 변화시킨다 [2, 4].
|
||||
* **제어 루프 (피드포워드와 피드백):** 하네스 엔지니어링은 에이전트가 오류를 범하기 전에 올바른 방향으로 안내하는 '피드포워드 가이드(Feedforward Guides)'와, 행동 완료 후 결과를 관찰하여 스스로 수정할 수 있게 돕는 '피드백 센서(Feedback Sensors)'라는 두 가지 핵심 제어 루프를 통해 에이전트를 조향(Steering)한다 [5-8].
|
||||
* **컴퓨테이셔널(Computational) 및 인퍼렌셜(Inferential) 제어:** 하네스의 제어 장치는 린터나 정적 분석, 테스트처럼 빠르고 결정론적인 '컴퓨테이셔널 제어'와, LLM 심사관(LLM-as-judge)처럼 느리고 확률적이지만 의미론적 판단이 가능한 '인퍼렌셜 제어'로 나뉘어 구성된다 [9, 10].
|
||||
* **메타 하네스(Meta-Harness) 최적화:** 최근 연구에서는 시스템 프롬프트, 도구 구성, 오케스트레이션 코드 등 하네스 전체를 최적화 대상으로 간주하여, 에이전트가 자체 실행 트레이스와 실패 신호를 바탕으로 스스로 하네스 구조를 반복적으로 진화시키는 메타 하네스 패턴으로 발전하고 있다 [11, 12].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **데이터 품질 보증의 구조적 공백:** 현존하는 대부분의 하네스 오케스트레이션 프레임워크는 에이전트가 읽는 데이터가 신뢰할 수 있다고 가정할 뿐 이를 자체적으로 인증하거나 검증하지 않는다 [13-15]. 통제되지 않은 환경에서 스키마가 변경되거나 오래된 데이터가 유입되면 하네스의 오케스트레이션이 아무리 정교하더라도 '메모리 오염'이나 '연쇄 실패'와 같은 치명적인 오류가 발생할 수 있다 [16, 17].
|
||||
* **특정 하네스 구조에 대한 과적합(Overfitting):** 특정 하네스 환경 내에서 훈련(Post-trained)된 모델은 해당 하네스 설계에 과적합되는 부작용을 겪을 수 있다 [18, 19]. 이로 인해 도구의 논리나 런타임 지속성(Persistence) 모드가 조금만 변경되어도 일반화 능력을 상실하고 심각한 성능 저하나 토큰 낭비가 발생할 수 있다 [19, 20].
|
||||
* **인퍼렌셜 센서의 높은 비용과 비결정성:** 의미론적 판단이나 AI 코드 리뷰를 수행하는 인퍼렌셜 센서(Inferential Sensors)는 유용하지만 실행 속도가 느리고 비용이 많이 들며 결과가 비결정론적이다 [9, 10]. 이로 인해 모든 변경 사항에 대해 상시 실행하기 어렵고, 사람의 의도 오해나 과도한 엔지니어링과 같은 고영향 문제를 완벽히 포착하기에는 여전히 한계가 있다 [21].
|
||||
* **멀티 에이전트 조율의 복잡도 증가:** 여러 에이전트가 협업하는 하네스 아키텍처는 본질적으로 분산 시스템처럼 동작하게 된다 [22, 23]. 따라서 각 에이전트 간의 핸드오프(Handoff) 과정에서 명시적인 경계 검증과 엄격한 스키마가 강제되지 않으면 조율 실패가 발생하여 막대한 아키텍처 관리 오버헤드를 초래한다 [22, 23].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-05*
|
||||
@@ -0,0 +1,34 @@
|
||||
---
|
||||
id: HARNESS-RES-2026-05-009
|
||||
title: 사전 행동 승인 (Pre-Action Authorization)
|
||||
category: "10_Wiki/Topics/Governance"
|
||||
status: verified
|
||||
confidence_score: 0.94
|
||||
tags: [harness, security, authorization, governance, oap, policy-gate]
|
||||
created_at: 2026-05-05
|
||||
updated_at: 2026-05-08
|
||||
---
|
||||
|
||||
# 사전 행동 승인 (Pre-Action Authorization)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "도구 실행의 최후의 보루: 에이전트가 행동을 개시하기 직전, 동기적으로 권한을 가로채어 정책(OAP, RBAC 등)에 따라 실행 여부를 결정하는 하네스의 결정론적 보안 계층."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **결정론적 정책 집행 (Deterministic Policy Enforcement):** Open Agent Passport (OAP)와 같은 규격은 에이전트의 도구 호출을 동기적으로 가로채어 평가한다. 암호화된 서명이 포함된 감사 기록을 생성하며, 허용적인 정책에서 발생할 수 있는 보안 위협을 원천 차단하는 성과를 입증했다 [2].
|
||||
* **인가 패브릭 아키텍처:** 정책 집행 지점(PEP)과 정책 결정 지점(PDP)을 결합하여, 모든 도구 실행 전에 'ALLOW, DENY, REQUIRE_APPROVAL, MASK' 중 하나의 명확한 판정을 받도록 강제한다 [1].
|
||||
* **프롬프트 의존성 탈피:** 에이전트의 권한 관리를 자연어 지시에 맡기지 않고, 하네스 인프라 수준의 제어 평면(Control Plane)에서 통제한다 [1]. 이는 인가(Authorization)를 단순히 신원의 문제가 아닌, 규제 맥락에 따른 인프라 제어의 문제로 취급함을 의미한다.
|
||||
* **수명 주기 훅(Lifecycle Hooks) 통합:** OpenHarness 등에서는 `PreToolUse`와 같은 훅이나 대화형 승인 창을 통해 매 실행 전에 권한 검사를 수행하도록 구조화되어 있다 [4, 5, 6].
|
||||
|
||||
## ⚖️ 트레이드오프 및 고려사항
|
||||
* **승인 피로도(Approval Fatigue):** 인간의 개입을 너무 빈번하게 강제할 경우, 사용자가 내용을 확인하지 않고 무비판적으로 자동 승인해버려 보안 절차가 무력화될 수 있다 [1, 7].
|
||||
* **실행 지연 시간(Latency):** 모든 도구 호출 전 동기적 정책 평가는 실행 루프에 오버헤드를 발생시킨다 (예: OAP 정책 집행 중간값 53ms). 저지연 처리가 요구되는 환경에서는 응답성 저하의 원인이 될 수 있다 [2, 8].
|
||||
* **인프라 복잡성:** 외부 인증 시스템(예: Microsoft Entra)이나 복잡한 권한 부여 패브릭과의 연동이 필요하므로 세션 관리 및 보안 정책 유지보수의 난이도가 크게 상승한다 [1, 2].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **상위 개념**: [[Permissions and Safety]], [[AI Governance]]
|
||||
- **유사 개념**: [[Allow-listing]], [[Human-in-the-Loop (HITL)]], [[Open Agent Passport (OAP)]]
|
||||
- **관련 프로젝트**: [[Microsoft Authorization Fabric]], [[OpenHarness]], [[ConnectAI]]
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-08*
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
id: HARNESS-RES-2026-05-005
|
||||
title: 샌드박스 (Sandbox)
|
||||
category: "10_Wiki/Topics/Infrastructure"
|
||||
status: verified
|
||||
confidence_score: 0.97
|
||||
tags: [harness, sandbox, security, isolation, microvm, docker]
|
||||
created_at: 2026-05-05
|
||||
updated_at: 2026-05-08
|
||||
---
|
||||
|
||||
# 샌드박스 (Sandbox)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "에이전트의 안전한 놀이터: 커널 수준의 격리와 네트워크 통제를 통해 에이전트가 생성한 코드가 호스트 시스템을 오염시키지 않도록 보호하는 독립된 실행 런타임."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **에이전트 실행의 격리 및 확장성 제공:** 에이전트가 로컬 환경에서 직접 코드를 실행하는 것은 보안 위험이 따르고 대규모 작업으로 확장하기 어렵다 [6]. 샌드박스를 도입하면 하네스가 샌드박스에 연결하여 안전하게 코드를 실행하고, 파일을 검사하며, 종속성을 설치하여 작업을 완료할 수 있다 [6]. 이러한 환경은 필요에 따라 온디맨드로 생성되고 여러 작업에 분산 배포된 후 작업이 끝나면 폐기될 수 있어 뛰어난 확장성을 제공한다 [6].
|
||||
* **주요 아키텍처 및 구현 방식:**
|
||||
* **MicroVM 기반:** E2B, LangSmith 등은 Firecracker 등을 활용해 150ms 미만의 콜드 스타트, 커널 수준 격리, 리소스 제한(CPU/메모리/디스크) 기능을 갖춘 샌드박스를 제공한다 [7].
|
||||
* **컨테이너 기반:** AutoGen은 Docker 네이티브 샌드박싱을 지원하여 격리된 코드 실행 환경을 제공하며 [8], Daytona는 90ms 미만의 시작 속도와 상태 지속성을 갖춘 OCI 컨테이너 기반 샌드박스를 지원한다 [7].
|
||||
* **V8 Isolate 기반:** Cloudflare Dynamic Workers와 같이 기존 컨테이너보다 최대 100배 빠르고 메모리 효율적인 방식을 사용하여 수 밀리초 내에 격리 환경을 시작하는 초경량 기술도 활용된다 [9].
|
||||
* **운영체제 및 커널 수준 보호:** Cursor는 macOS Seatbelt, Linux Landlock 및 seccomp를 이용한 크로스 플랫폼 샌드박스를 구현하였으며, NVIDIA OpenShell은 Landlock LSM 및 seccomp BPF를 통해 커널 수준의 보안 제어를 제공한다 [7, 9].
|
||||
* **제어 평면(Control Plane)과의 엄격한 분리:** 안전한 운영을 위해 샌드박스는 하네스의 제어 평면(인증, 과금, 오케스트레이션)과 샌드박스의 컴퓨팅 평면(파일, 셸, 포트)을 엄격히 분리하도록 설계된다 [9]. 이 과정에서 아웃바운드 HTTP 요청 등을 가로채어 자격 증명(Secrets)과 같은 민감한 정보가 런타임 환경 시스템 외부에 유지되도록 보호한다 [7, 9].
|
||||
|
||||
## ⚖️ 트레이드오프 및 고려사항
|
||||
* **샌드박스 제약에 대한 에이전트 훈련의 필요성:** 샌드박스 환경을 도입하더라도, 에이전트가 샌드박스의 제약을 인식하도록 명시적으로 훈련되지 않으면 허용되지 않은 파일 작업이나 네트워크 접근을 시도하다 오류를 발생시킬 수 있다 [7].
|
||||
* **권한 상승 위험의 선제적 차단:** 표준적인 샌드박스 격리 기능만으로는 에이전트가 자체 하네스 설정을 수정하여 권한을 상승시키는 것을 완벽히 막을 수 없다 [7, 9]. 따라서 OPA(Open Policy Agent) 기반 프록시와 같은 추가적인 보안 아키텍처가 동반되어야 한다 [9].
|
||||
* **지연 시간(Latency) 트레이드오프:** AIO Sandbox처럼 풍부한 기능(브라우저, 셸, VSCode 서버 등)을 갖춘 환경은 구동에 4~8초가 소요되는 반면 [11], V8 Isolate 기반 환경은 밀리초 단위로 매우 빠르게 시작되지만 실행할 수 있는 코드와 메모리 제약이 따를 수 있다 [9].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **상위 개념**: [[AI Infrastructure]], [[Cloud Security]]
|
||||
- **유사 개념**: [[E2B (Firecracker microVM)]], [[Containerization]], [[Kernel-level Isolation]]
|
||||
- **관련 프로젝트**: [[ConnectAI]], [[OpenHarness]]
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-08*
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
id: HARNESS-RES-2026-05-013
|
||||
title: 스키마 표류 (Schema Drift)
|
||||
category: "10_Wiki/Topics/Infrastructure"
|
||||
status: verified
|
||||
confidence_score: 0.96
|
||||
tags: [harness, data-quality, schema-drift, governance, data-contract]
|
||||
created_at: 2026-05-05
|
||||
updated_at: 2026-05-08
|
||||
---
|
||||
|
||||
# 스키마 표류 (Schema Drift)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "에이전트 신뢰성의 소리 없는 파괴자: 데이터 소스의 구조가 예고 없이 변경되어 에이전트가 오염된 컨텍스트를 읽게 만듦으로써, 작업 완료 시점에야 발견되는 치명적 오작동을 유발하는 현상."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **에이전트 생산 실패의 주요 원인**: 스키마 표류는 엔터프라이즈 환경에서 에이전트 실패를 유발하는 가장 흔한 근본 원인 중 하나이다 [1]. 실제로 프로젝트의 약 88%가 생산 단계 도달에 실패하는데, 이는 모델의 지능 부족보다 스키마 불일치 및 컨텍스트 표류 등 하네스 환경의 결함 때문인 경우가 많다 [5].
|
||||
* **오케스트레이션 프레임워크의 한계**: LangGraph, Semantic Kernel 등은 에이전트의 실행 방식(어떻게)은 관리하지만, 읽어 들이는 데이터(무엇을)는 검증하지 않는다 [1, 2]. 따라서 스키마가 변형된 데이터가 아무런 유효성 검사 없이 에이전트에게 전달되는 구조적 공백이 존재한다 [4, 6].
|
||||
* **데이터 컨트랙트(Data Contracts)의 필요성**: 문제를 해결하려면 데이터가 컨텍스트 윈도우에 진입하기 전 스키마 계약을 강제하는 거버넌스 계층이 필수적이다 [3]. 이를 통해 에이전트가 잘못된 결과를 출력하기 전, 데이터를 읽는 시점에 선제적으로 스키마 표류를 감지할 수 있다 [3].
|
||||
|
||||
## ⚖️ 트레이드오프 및 고려사항
|
||||
* **사후(Post-hoc) 모니터링의 한계**: AgentOps나 Langfuse는 실행 이후를 기록하므로 잘못된 결과의 '발생'은 알 수 있으나, 불량 입력 데이터(스키마 표류 등) 자체를 방지하거나 근본 원인을 즉각 식별하는 데는 한계가 있다 [4].
|
||||
* **아키텍처 복잡성 증가**: 스키마 표류를 막기 위해서는 오케스트레이션 고도화 외에도 별도의 거버넌스된 데이터 기저(Governed data substrate)가 요구된다. 이는 데이터 계약 및 인증 인프라 구축을 위한 초기 비용과 시스템 복잡성을 증가시킨다 [3, 4, 8].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **상위 개념**: [[Data Quality Layer]], [[Data Governance]]
|
||||
- **유사 개념**: [[Active Metadata]], [[Data Contracts]], [[Hallucination (환각)]]
|
||||
- **관련 프로젝트**: [[Atlan]], [[ConnectAI]]
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-08*
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
id: HARNESS-RES-2026-05-018
|
||||
title: Server-Sent Events (SSE)
|
||||
category: "10_Wiki/Topics/Infrastructure"
|
||||
status: verified
|
||||
confidence_score: 0.94
|
||||
tags: [harness, communication, streaming, sse, real-time, agent-to-agent, mcp]
|
||||
created_at: 2026-05-05
|
||||
updated_at: 2026-05-08
|
||||
---
|
||||
|
||||
# Server-Sent Events (SSE)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "에이전트의 실황 중계: 서버가 클라이언트에게 이벤트를 단방향으로 실시간 스트리밍하여, 에이전트의 추론 과정과 결과를 즉각적으로 가시화하는 경량 통신 프로토콜."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **실시간 가시성 지원:** Claude Managed Agents와 같은 플랫폼은 SSE 스트리밍을 기본 기능으로 지원하여 에이전트의 자율적 작동 상태를 사용자가 실시간으로 확인할 수 있게 한다 [1].
|
||||
* **에이전트 간(A2A) 통신 규격:** Google의 개방형 A2A 프로토콜은 HTTP(S)/SSE 기반의 JSON-RPC를 통신 규격으로 채택하여 에이전트 간의 상호운용성을 확보한다 [2].
|
||||
* **원격 MCP 전송의 기초:** 원격 MCP 서비스 환경에서 서버는 다중 연결을 처리하기 위해 서버-클라이언트 방향의 SSE 스트림을 활용하며, 이는 Streamable HTTP 전송 체계의 핵심을 이룬다 [2].
|
||||
|
||||
## ⚖️ 트레이드오프 및 고려사항
|
||||
* **상태 저장의 부작용:** 스트림 식별을 위해 `Mcp-Session-Id`와 같은 상태 저장 헤더를 동반하므로, 로드 밸런서의 분산 메커니즘이나 서버의 수평적 확장(Horizontal Scaling)과 구조적으로 충돌한다 [2].
|
||||
* **웹소켓(WebSockets)과의 차이:** SSE는 HTTP 기반의 단방향 스트리밍에 최적화되어 있어 양방향 통신이 빈번한 환경보다는 모델의 텍스트 생성 결과 전송 등에 더 적합하다. 하지만 상태 유지 제약으로 인해 2026년 이후에는 전송 계층과 세션을 분리하는 아키텍처로의 전환이 요구된다 [2].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **상위 개념**: [[Communication Protocols]], [[Transport Layer]]
|
||||
- **유사 개념**: [[HTTP+SSE]], [[Streamable HTTP]], [[WebSockets]]
|
||||
- **관련 프로젝트**: [[Claude Managed Agents]], [[Google A2A Protocol]], [[ConnectAI]]
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-08*
|
||||
@@ -0,0 +1,15 @@
|
||||
# [[Token Savior]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
Token Savior는 코딩 에이전트를 위한 MCP(Model Context Protocol) 서버 아키텍처입니다 [1]. 에이전트가 전체 파일을 읽는 대신 함수, 클래스, 호출 그래프 등의 기호를 기준으로 코드베이스를 색인화하여 포인터로 탐색할 수 있도록 지원합니다 [1]. 이를 통해 활성 토큰 사용량을 77% 줄이고 벤치마크 소요 시간을 76% 단축하는 효과를 제공합니다 [1]. 결과적으로 코딩 에이전트의 컨텍스트 전달이 단순한 데이터 압축 문제가 아니라 효율적인 탐색(Navigation)의 문제임을 입증하는 도구입니다 [1].
|
||||
|
||||
## 📖 Core Content
|
||||
* **기호 기반의 코드베이스 색인화 및 탐색**: Token Savior는 에이전트가 방대한 코드베이스를 분석할 때 무거운 전체 파일을 읽어 들이는 방식을 탈피합니다 [1]. 대신 함수, 클래스, 호출 그래프(Call graphs)와 같은 **기호(Symbol)를 기준으로 코드를 색인화**하여, 에이전트가 포인터(Pointer)를 통해 필요한 영역만 정밀하게 탐색할 수 있게 합니다 [1].
|
||||
* **획기적인 리소스 및 실행 시간 최적화**: 코드의 필요한 부분만 선별적으로 접근할 수 있는 탐색 구조 덕분에, 에이전트 구동 시 발생하는 **활성 토큰(Active tokens) 소비를 77%나 삭감**하는 탁월한 효율성을 보여줍니다 [1]. 더불어 벤치마크 환경에서의 **소요 시간(Wall time)을 76%까지 단축**시킵니다 [1].
|
||||
* **컨텍스트 엔지니어링 패러다임의 전환**: Token Savior의 사례는 코딩 에이전트를 위한 컨텍스트 전달(Context delivery) 방식에 중요한 시사점을 던집니다 [1]. 즉, 제한된 컨텍스트 윈도우 내에서 정보를 단순히 **압축(Compression)하는 문제가 아니라, 코드베이스 내비게이션(Navigation) 아키텍처의 문제**로 접근해야 함을 실증적으로 증명합니다 [1].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
소스에 관련 정보가 부족합니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-05*
|
||||
@@ -0,0 +1,19 @@
|
||||
# [[가드레일 (Guardrails) 및 제어 시스템]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
에이전트 하네스에서 가드레일 및 제어 시스템은 인공지능 모델이 무단, 파괴적 혹은 환각적인 행동을 취하는 것을 방지하는 필수적인 인프라 보안 계층입니다 [1-3]. 이 시스템은 모델의 확률적인(Probabilistic) 추론과 결정을 물리적 시스템의 결정론적(Deterministic) 규칙 및 안전 프로토콜로 제한하여 신뢰성을 확보합니다 [4]. 기업의 보안 요구사항을 충족시키기 위해 샌드박스 격리, 도구 호출 검증, 다계층 권한 부여, 그리고 인간 개입(HITL) 메커니즘을 통합하여 에이전트의 자율성을 통제합니다 [2, 5, 6].
|
||||
|
||||
## 📖 Core Content
|
||||
* **권한 및 인가 관리 (Permissions & Authorization)**: 하네스는 모델이 특정 도구를 실행하기 전에 이를 승인할지 결정하는 세밀한 다계층 제어 시스템을 포함합니다 [1, 7]. 에이전트는 다중 수준 권한 모드(예: Default, Auto, Plan Mode), 경로 수준(Path-level) 통제 규칙, 그리고 도구 실행 전후에 개입하는 수명 주기 훅(PreToolUse / PostToolUse Hooks)의 통제를 받습니다 [8, 9]. 인증된 환경에서는 단순한 신원 확인을 넘어 OPA(Open Policy Agent) 정책 게이트나 인가 패브릭(Authorization Fabric)을 활용하여 비즈니스 및 규제 맥락에 따라 '허용', '거부', '승인 필요' 등의 결정을 내립니다 [2, 7].
|
||||
* **인간 개입 (Human-in-the-Loop, HITL) 통제**: 생산 데이터베이스 쓰기, 외부 이메일 전송 등 민감하고 위험도가 높은 작업의 경우, 하네스는 모델의 실행을 일시 중단시키고 사람의 승인을 요구하는 인터럽트(Interrupts) 워크플로우를 강제합니다 [6, 10]. 사용자는 단순한 승인과 거부뿐만 아니라 '변경 후 승인(approve with changes)' 등을 통해 도구 입력값을 직접 수정할 수도 있으며, 이를 통해 인공지능이 노동을 수행하되 인간이 최종적인 통제권과 책임을 유지하도록 합니다 [10-12].
|
||||
* **실행 샌드박스 및 환경 격리 (Sandboxing & Isolation)**: 에이전트가 자율적으로 생성한 코드가 호스트 시스템을 오염시키거나 파괴하지 못하도록, 하네스는 Docker, OCI 컨테이너, 혹은 Firecracker 마이크로VM과 같이 격리된 샌드박스 환경 내에서만 실행을 허용합니다 [5, 13, 14]. 고도화된 샌드박스는 커널 수준의 격리(Landlock, seccomp)나 엄격한 네트워크 송신 제한을 강제하여 에이전트의 무단 접근을 원천 차단합니다 [5, 15].
|
||||
* **도구 호출 검증 (Tool Validation)**: 모델이 존재하지 않는 API를 호출하거나 잘못된 매개변수 유형을 사용하는 환각(Hallucination) 오류를 방지하기 위해, 하네스는 실행 전에 도구 호출을 가로채어 스키마를 검증합니다 [16-18]. 만약 오류가 발생하면 시스템에 치명적인 에러를 발생시키는 대신, 린터(Linter) 메시지 등 정제된 피드백을 모델에 반환하여 스스로 코드를 수정할 수 있는 자가 치유(Self-healing) 루프를 유도합니다 [18, 19].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **승인 피로(Approval Fatigue) 현상**: 모든 행동에 권한 확인이나 승인 게이트를 추가할 경우 사용자에게 심각한 '승인 피로'가 발생할 수 있습니다 [7]. 사용자가 93% 이상의 프롬프트를 기계적으로 자동 승인하게 되면 가드레일은 본래의 감시 목적을 상실하고 유명무실해지며, 에이전트 시스템의 처리 속도와 자율성만 크게 저하시키는 부작용을 초래합니다 [7, 20].
|
||||
* **컨텍스트 부패(Context Rot)와 비용 증가**: 모델이 실패를 반복하거나 하네스가 검증을 위해 지속적으로 에러 메시지와 긴 로그를 컨텍스트에 주입할 경우, 컨텍스트 윈도우가 빠르게 소진되는 문제가 발생합니다 [21, 22]. 이는 모델이 초기 지시사항을 망각하게 만들며 결과적으로 불필요한 토큰 낭비와 연산 오버헤드(비용 증가)로 이어집니다 [22, 23].
|
||||
* **무한 루프(Doom Loops) 위험성**: 대규모 언어 모델의 비결정론적 특성상, 샌드박스나 권한 제어에 의해 특정 도구 실행이 차단되었음에도 불구하고 모델이 해결책을 재고하지 못하고 계속해서 동일한 잘못된 코드나 도구 호출을 시도하는 무한 루프에 빠질 위험이 있습니다 [18, 24].
|
||||
* **하네스 설정 파일 보호의 한계**: 에이전트가 샌드박스 내에서 활동하더라도, MCP(Model Context Protocol) 서버 설정 파일이나 훅(Hook) 파일 등 하네스 자신의 설정 환경에 에이전트가 쓰기 권한을 가지게 되면 문제가 됩니다 [5]. 에이전트가 자신의 안전 장치 설정을 수정하여 스스로 권한을 상승시키는 심각한 보안 헛점이 발생할 수 있으므로 이에 대한 엄격한 격리가 보장되어야 합니다 [5].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-05*
|
||||
@@ -0,0 +1,3 @@
|
||||
**Refining the Summary**
|
||||
|
||||
I'm now integrating information about the 'Human-in-the-Loop' (HITL) control, recognizing its crucial role in managing sensitive operations by pausing execution and awaiting human approval, drawing from the Firecrawl source. I am synthesizing content for the report. I am incorporating definitions and specifics for the "Brief Summary" section. I have a draft definition for the Multi-Level Permission Modes. I will follow up with key features and types.
|
||||
@@ -0,0 +1,36 @@
|
||||
---
|
||||
id: HARNESS-RES-2026-05-001
|
||||
title: 데이터 품질 계층 (Data Quality Layer)
|
||||
category: "10_Wiki/Topics/Infrastructure"
|
||||
status: verified
|
||||
confidence_score: 0.95
|
||||
tags: [harness, data-quality, governance, ai-agent, mcp]
|
||||
created_at: 2026-05-05
|
||||
updated_at: 2026-05-08
|
||||
---
|
||||
|
||||
# 데이터 품질 계층 (Data Quality Layer)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "AI 에이전트의 '쓰레기 입력, 쓰레기 출력(GIGO)' 문제를 해결하는 필터: 오케스트레이션 중심의 에이전트 환경에서 데이터의 최신성, 정합성, 출처를 실시간으로 인증하여 환각 현상을 원천 차단하는 신뢰 인프라 계층."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **구조적 공백과 거버넌스의 필요성:** LangGraph, CrewAI, AutoGen 등 2026년의 주요 에이전트 하네스 프레임워크들은 에이전트가 실행되는 방식(제어 계층)만을 관리하며, 입력되는 데이터의 신뢰성, 최신성, 인증 여부를 검증하는 기능은 제공하지 않는다 [1-5]. AI 거버넌스 연구에 따르면, 흔히 모델의 '환각(Hallucination)'으로 치부되는 문제의 상당수는 실제로는 일관성 없거나 기한이 지난(stale), 혹은 불완전하게 복제된 데이터 소스에서 기인한다 [6, 7]. 맥킨지(McKinsey)의 조사에서도 에이전트형 AI 구현에 소요되는 시간의 80%가 프레임워크 구성이 아닌 데이터 엔지니어링과 거버넌스 작업에 쓰이며, 기업 10곳 중 8곳이 데이터 한계를 확장의 가장 큰 장애물로 지목하고 있다 [6-8].
|
||||
* **데이터 품질 계층의 필수 구성 요소:** 에이전트 파이프라인의 신뢰성을 확보하기 위해 도입되는 데이터 품질 인프라(예: Atlan)는 에이전트의 컨텍스트 윈도우에 정보가 들어가기 전에 다음과 같은 기능을 제공해야 한다 [9-13].
|
||||
* **액티브 메타데이터 (Active Metadata):** 데이터 시스템을 지속적으로 모니터링하여 메타데이터의 최신성, 실시간 인증 상태, 스키마 상태를 에이전트에게 구조화된 컨텍스트로 전달한다 [11].
|
||||
* **데이터 계약 (Data Contracts):** 데이터가 하네스 환경에 유입되기 전 스키마 계약을 강제하여, 에이전트가 변형된 스키마(Schema drift)를 읽고 잘못된 결과를 내기 전에 선제적으로 오류를 차단한다 [11].
|
||||
* **데이터 리니지 (Data Lineage):** 컬럼(Column) 단위의 데이터 계보를 추적하여 에이전트가 정보의 원천을 확인할 수 있도록 한다. 이를 통해 출력 오류 발생 시 문제의 근본 원인이 모델인지, 프롬프트인지, 원본 데이터인지 명확히 식별할 수 있다 [12].
|
||||
* **인증 상태 (Certification Status):** 데이터 스튜어드가 데이터를 인증하고, 에이전트가 인증된 데이터만 참조하도록 구성하여 기업 환경에서 발생하는 주요 실패 유형을 제거한다 [12].
|
||||
* **MCP 서버 (MCP Server):** 이러한 활성 메타데이터, 계약, 리니지 정보를 모델 컨텍스트 프로토콜(MCP)을 통해 쿼리할 수 있도록 노출시켜 다양한 하네스와 연결한다 [13].
|
||||
|
||||
## ⚖️ 트레이드오프 및 고려사항
|
||||
* **사후 모니터링 및 오케스트레이션 도구의 근본적 제약:** 에이전트 프레임워크가 제공하는 오케스트레이션이 아무리 고도화되더라도, 에이전트가 검증되지 않거나 변형된 데이터를 읽는다면 이를 프레임워크 수준에서 보완할 방법이 없다는 치명적인 한계가 존재한다 [14]. AgentOps나 Langfuse와 같은 사후 모니터링(Post-hoc observability) 도구를 활용하더라도, 이는 에이전트가 잘못된 입력을 바탕으로 행동했다는 사후 기록만을 제공할 뿐 원본 소스에서 나쁜 데이터가 유입되는 것을 방지하지는 못한다 [4, 5, 15, 16].
|
||||
* **인프라 구성의 복잡성과 비용 증가:** 결과적으로 기업이나 개발팀은 에이전트 하네스 도구와는 별개로, Atlan과 같은 거버넌스가 적용된 데이터 기반 구조(Governed data substrate)를 구축해야 하는 추가적인 인프라 부담을 안게 된다 [9, 10, 17, 18]. 특히 규제가 심한 산업 분야에서는 이러한 데이터 인증 인프라가 단순한 선택 사항이 아니라, 규정 준수(Compliance)를 위한 필수적인 감사 추적 요구사항으로 작용하여 에이전트 AI 시스템을 프로덕션 환경에 배포하는 데 높은 진입 장벽과 초기 투자 비용을 요구하게 된다 [13, 19].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **상위 개념**: [[AI Infrastructure]], [[Data Governance]]
|
||||
- **유사 개념**: [[Schema Drift (스키마 표류)]], [[Active Metadata]]
|
||||
- **관련 프로젝트**: [[ConnectAI]], [[Skybound Protocol]]
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-08*
|
||||
@@ -0,0 +1,22 @@
|
||||
# [[둠 루프 (Doom Loop)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
둠 루프(Doom Loop)는 자율형 AI 에이전트가 특정 문제 해결 계획을 결정한 후 시야가 좁아져(myopic), 작동하지 않는 잘못된 접근 방식을 미세하게만 변경하며 실패를 끝없이 반복하는 현상을 의미한다 [1]. 에이전트 하네스 환경에서 빈번하게 관찰되는 실패 패턴 중 하나로, 일부 사례에서는 동일한 잘못된 방식을 10번 이상 반복하는 형태로 나타나기도 한다 [1]. 이를 해결하기 위해 하네스 계층에서 편집 횟수 등을 추적하여 에이전트가 스스로의 계획을 재고하도록 유도하는 미들웨어 장치가 주로 활용된다 [1].
|
||||
|
||||
## 📖 Core Content
|
||||
* **발생 원인 및 현상:**
|
||||
* 에이전트가 문제를 해결하기 위해 한 번 계획을 수립하고 나면, 그 계획에 지나치게 매몰되어 근시안적으로 변할 때 둠 루프가 발생한다 [1].
|
||||
* 에이전트는 기존의 실패한 접근법의 근본적인 원인을 파악하여 새로운 계획을 세우는 대신, 동일한 코드나 파일에 작고 무의미한 변형만을 가하면서 계속해서 실패를 반복하게 된다 [1].
|
||||
* **하네스 엔지니어링을 통한 해결 방안:**
|
||||
* 에이전트가 둠 루프에서 벗어나 한 발 물러서서 계획을 재고할 수 있도록 장려하는 하네스 계층의 적극적인 개입이 필요하다 [1].
|
||||
* 구체적인 시스템 구현 예시로, 도구 호출 훅(tool call hooks)을 통해 파일별 편집 횟수를 추적하는 `LoopDetectionMiddleware`(루프 감지 미들웨어)를 도입할 수 있다 [1].
|
||||
* 이 미들웨어는 동일한 파일에 대해 특정 횟수('N'번) 이상의 수정이 반복적으로 발생하면, 에이전트의 컨텍스트에 "...접근 방식을 다시 고려해 보십시오(consider reconsidering your approach)"와 같은 지침을 강제로 주입하여 루프 탈출을 돕는다 [1].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **모델의 자의적 판단에 따른 통제력 한계:** 하네스 루프 감지 미들웨어가 개입하여 접근 방식을 재고하라는 컨텍스트를 주입하더라도, 모델 스스로 자신의 현재 경로가 올바르다고 계속해서 확신할 경우에는 경고를 무시하고 동일한 잘못된 경로를 고집할 수 있다는 한계가 있다 [1].
|
||||
* **근본적 해결이 아닌 발견적 설계(Heuristic):** 둠 루프를 끊어내기 위한 이러한 장치들은 현재 AI 모델들이 가지고 있는 인지적 결함을 엔지니어링 적으로 우회하기 위해 만들어진 임시적이고 발견적인 설계(design heuristic)라는 점을 인지해야 한다 [1].
|
||||
* **모델 개선에 따른 효용성 변화:** 향후 모델의 추론 능력이 자체적으로 개선됨에 따라 이러한 인위적인 가드레일은 점차 불필요해질 가능성이 크다 [1]. 하지만 현재의 기술 수준에서 자율적이고 견고한 에이전트 애플리케이션을 구축하기 위해서는 당분간 감수하고 필수적으로 실험해 보아야 할 설계적 우회 수단이다 [1].
|
||||
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-05*
|
||||
@@ -0,0 +1,17 @@
|
||||
# [[랄프 루프 (Ralph Loop)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
랄프 루프(Ralph Loop)는 대규모 언어 모델(LLM) 에이전트가 작업을 조기에 종료하려는 시도를 훅(hook) 메커니즘으로 가로채어, 정해진 완료 목표를 달성할 때까지 작업을 계속하도록 강제하는 에이전트 하네스 패턴이다 [1, 2]. 이 패턴은 실행을 멈추려는 에이전트에게 깨끗한 컨텍스트 창과 원래의 프롬프트를 다시 주입하여 반복적인 실행을 유도한다 [2]. 주로 에이전트가 종료하기 전에 작업 명세서에 대한 검증(verification) 단계를 반드시 거치도록 하는 데 활용된다 [1].
|
||||
|
||||
## 📖 Core Content
|
||||
* **작업 지속 메커니즘**: 랄프 루프는 에이전트가 스스로 실행을 종료하고 빠져나가려는 시점(exit attempt)을 하네스 레벨에서 인터셉트(intercept)한다 [2]. 시스템은 종료를 막은 뒤 **깨끗한 컨텍스트 창(clean context window)에 원래의 프롬프트를 다시 주입**하여 에이전트가 중단 없이 완료 목표를 향해 작업을 이어가도록 강제한다 [2].
|
||||
* **파일 시스템 기반의 상태(State) 유지**: 이 패턴이 연속적이고 장기적인 작업(Long-horizon work)에서 효과적으로 작동할 수 있는 이유는 하네스의 파일 시스템 프리미티브에 의존하기 때문이다 [2]. 각 루프의 반복(iteration)이 시작될 때마다 컨텍스트는 완전히 초기화(fresh)되지만, **이전 반복에서 파일 시스템에 기록해 둔 상태(state)를 읽어올 수 있으므로** 에이전트는 맥락을 잃지 않고 진척도를 유지할 수 있다 [2].
|
||||
* **자가 검증(Self-Verification)의 강제**: 랄프 위검 루프(Ralph Wiggum Loop)라고도 불리는 이 패턴은 에이전트의 종료 전 검증을 유도하는 데 매우 유용하다 [1]. 예를 들어, `PreCompletionChecklistMiddleware`와 같은 미들웨어와 결합하여 에이전트가 종료하기 전에 작업 명세서(Task spec)를 기준으로 **스스로 검증 단계(verification pass)를 실행하도록 상기시키는 용도**로 사용된다 [1].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **파일 시스템 의존성**: 랄프 루프는 매 반복마다 컨텍스트 창을 새로 고치는 방식(fresh context)으로 작동하기 때문에, 이전 작업의 흐름을 유지하려면 **반드시 파일 시스템과 같은 지속적이고 안정적인 상태 저장 매커니즘이 뒷받침되어야 한다는 구조적 제약**이 존재한다 [2].
|
||||
* 그 외에 랄프 루프의 도입으로 인해 발생할 수 있는 구체적인 부작용이나 성능상의 반대 급부(Trade-off)에 대해서는 **소스에 관련 정보가 부족합니다.**
|
||||
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-05*
|
||||
@@ -0,0 +1,18 @@
|
||||
# [[상태 관리 (State Management)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
에이전트 하네스에서 상태 관리(State Management)는 기본적으로 무상태(Stateless)인 대규모 언어 모델(LLM)이 다중 세션 및 장기 작업을 수행할 수 있도록 맥락과 작업 진행 상황을 보존하는 핵심 인프라 기능이다 [1-3]. 이는 모델이 이전 세션의 기억을 잃지 않고 작업을 재개할 수 있도록 세션 상태를 디스크나 파일 시스템에 기록(Session Persistence)하는 것을 포함한다 [4-6]. 상태 관리를 통해 에이전트는 도구 실행 결과, 하위 작업 완료 여부, 진행 노트 등을 영구적으로 추적하며, 시스템 충돌이 발생해도 처음부터 다시 시작하지 않고 이전 상태를 복구할 수 있다 [2, 4, 7].
|
||||
|
||||
## 📖 Core Content
|
||||
* **상태 비저장성(Statelessness) 극복:** LLM은 본질적으로 무상태이므로 하네스가 개입하지 않으면 에이전트는 매 세션마다 이전 작업의 지식 없이 백지상태에서 시작하게 된다 [1-3]. 에이전트 하네스는 이러한 모델의 한계를 극복하기 위해 메모리를 저장, 검색, 복구하며 장기 작업(Long-running tasks)을 가능하게 하는 제어 평면의 역할을 수행한다 [2, 3].
|
||||
* **파일 시스템 및 영구 저장소 기반 상태 관리:** 하네스는 파일 시스템을 활용하여 중간 상태를 디스크에 지속시키고, 컨텍스트 윈도우의 한계를 넘어 정보를 오프로딩(Offloading)한다 [5, 6, 8]. 일례로 초기화-실행자 분리(Initializer-executor split) 패턴을 사용하면 폴더 구조, 기능 목록, 진행 파일 등 내구성 있는 프로젝트 환경 상태가 설정되며, 후속 세션은 이 상태를 읽어 점진적으로 작업을 수행한다 [9].
|
||||
* **세션 상태(Session State)와 체크포인팅:** 에이전트의 상태 관리는 현재 작업 기간 동안의 도구 실행 결과, 완료된 하위 작업, 진행 노트 등에 대한 내구성 있는 로그를 관리하는 과정을 포함한다 [7]. LangGraph와 같은 오케스트레이션 프레임워크는 그래프 기반 상태 모델과 체크포인팅(Checkpointing) 기능을 제공하여, 실패 후에도 장기 작업을 재개할 수 있도록 에이전트 상태에 대한 명시적이고 세밀한 제어력을 제공한다 [10, 11].
|
||||
* **관찰적 메모리 및 상태 압축 관리:** Mastra와 같은 프레임워크는 백그라운드 에이전트를 통해 대화를 실시간 모니터링하고, 이를 구조화된 관찰 결과로 지속 압축하는 관찰적 메모리(Observational memory) 시스템을 사용하여 상태의 밀도와 품질을 자동 유지한다 [12, 13]. 더불어 컨텍스트 윈도우가 채워짐에 따라 이전 단계를 요약본으로 압축(Auto-summarization)하여 중간 상태를 관리하기도 한다 [8, 14].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **데이터 출처 및 계보 추적 상실:** 컨텍스트 압축 및 자동 요약을 통해 상태를 관리할 경우 데이터의 출처(Provenance)가 조용히 손실될 수 있다 [8]. 에이전트가 요약·압축된 상태(컨텍스트)를 읽을 때 해당 정보의 기원이나 데이터 계보(Lineage)를 연결하는 추적 메커니즘이 끊어지기 때문에, 잘못된 결과가 도출될 경우 근본 원인을 파악하기 어려워진다 [8].
|
||||
* **오염된 데이터 유입에 따른 상태 중독:** 대부분의 오케스트레이션 프레임워크는 상태에 주입되는 입력 데이터가 깨끗하다고 가정할 뿐 이를 직접 검증하지는 않는다 [11, 15, 16]. 스키마 드리프트나 인증되지 않은 출처의 '오염된 데이터'가 하네스의 컨텍스트로 유입되면, 에이전트가 잘못된 기억을 바탕으로 연쇄 장애(Cascading failures)를 일으키거나 모델 스스로는 제거할 수 없는 '좀비 메모리' 문제를 겪을 수 있다 [17-19].
|
||||
* **인프라 및 운영 복잡성 증가:** 중간 상태를 유지하기 위해 파일 시스템 백엔드에 맥락을 오프로딩하는 방식은 컨테이너화된 배포 환경에서 운영 복잡성을 크게 증가시킨다 [20]. 또한 AutoGen과 같은 특정 프레임워크의 경우 대화형 상태(컨텍스트)가 누적될 때 자동화된 관리 기능이 없어 토큰 윈도우가 가득 차면 수동으로 상태를 가지치기(Pruning)해야 하는 제약 사항이 존재한다 [21].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-05*
|
||||
@@ -0,0 +1,21 @@
|
||||
# [[샌드박스 (Sandbox)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
샌드박스(Sandbox)는 대규모 언어 모델(LLM) 기반의 에이전트가 생성한 코드를 안전하게 실행하고 도구와 상호작용할 수 있도록 격리된 환경과 보안 경계를 제공하는 핵심 에이전트 하네스 프리미티브 중 하나이다 [1, 2]. 에이전트가 호스트 시스템을 파괴하거나 위험에 빠뜨리지 않도록 보호하며, 실행 결과를 안전하게 관찰하고 검증할 수 있는 독립적인 작업 공간을 보장한다 [1, 2]. 샌드박스를 통해 에이전트의 실행 환경은 온디맨드로 생성되고, 대규모 작업으로 확장되며, 작업 완료 후 안전하게 폐기될 수 있다 [1].
|
||||
|
||||
## 📖 Core 기Content
|
||||
* **격리된 실행 및 시스템 보호:** 에이전트가 생성한 코드를 로컬 호스트 머신에서 직접 실행하는 것은 매우 위험하므로, 샌드박스는 커널 수준의 격리, 리소스 제한(CPU/메모리/디스크), 그리고 네트워크 격리를 통해 시스템을 보호한다 [1-3]. 또한 실행 결과에 대한 안전한 검증 루프를 형성하는 데 필수적인 역할을 수행한다 [2].
|
||||
* **다양한 샌드박스 구현 아키텍처:**
|
||||
* **Docker 기반 컨테이너:** AutoGen(AG2)과 같은 프레임워크는 Docker 네이티브 샌드박싱을 통해 호스트 시스템 위험 없이 코드를 격리 실행한다 [4]. Open Harness는 단일 저장소 및 브랜치에 스코프를 맞춘 컨테이너를 제공하여 호스트 랩탑 환경을 깨끗하게 유지하며, 브라우저와 셸, 파일 시스템 등을 결합한 올인원(AIO) 환경을 구축한다 [5, 6]. Daytona는 OCI 컨테이너 샌드박스를 통해 장기 실행 에이전트 세션을 위한 상태 지속성(State persistence)을 지원한다 [3].
|
||||
* **마이크로 가상 머신 (MicroVM):** E2B와 LangSmith 샌드박스는 Firecracker 기반의 마이크로 가상 머신(microVM) 아키텍처를 사용하여 커널 수준의 격리와 매우 빠른 콜드 스타트(150ms 미만)를 제공한다 [3]. LangSmith 샌드박스는 보안 인증 프록시를 통해 런타임 환경 외부에 비밀 정보(Secrets)를 분리 보관하며 지속적인 WebSocket 세션을 지원한다 [3].
|
||||
* **V8 격리 (V8 Isolate):** Cloudflare Dynamic Workers는 V8 격리 기반의 샌드박싱으로 기존 컨테이너 아키텍처보다 최대 100배 빠르고 100배 더 메모리 효율적인 실행 환경을 제공하며, 아웃바운드 HTTP 요청을 가로채어 자격 증명을 안전하게 주입한다 [7].
|
||||
* **제어 및 보안 정책 적용:** NVIDIA OpenShell과 같은 샌드박스 런타임은 파일 시스템(Landlock LSM), 시스템 호출(seccomp BPF) 및 네트워크 프록시를 통해 커널 수준에서 엄격한 보안 제약 조건을 강제하여, 손상된 에이전트조차 보안 정책을 우회할 수 없게 원천적으로 차단한다 [7].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **자체 구성 수정에 의한 권한 상승 (Escalation) 위험:** 표준적인 샌드박스 격리만으로는 완벽한 보안이 보장되지 않는다 [7]. 에이전트가 샌드박스 내에서 자신의 하네스 구성(예: MCP 서버 설정 및 훅 파일)을 직접 수정할 수 있다면 권한을 스스로 상승시키는 치명적인 보안 위협이 발생할 수 있으므로, 해당 설정 파일들에 대한 에이전트의 접근을 차단해야 한다 [7].
|
||||
* **제약 조건 인지에 대한 학습 필요성:** 에이전트가 샌드박스의 제약 조건을 스스로 인지하도록 명시적으로 학습되지 않으면 부작용이 발생할 수 있다 [3]. 제약을 모르는 에이전트는 샌드박스 경계 내에서 자유롭게 코드를 탐색하고 실행하는 대신, 모든 외부 접근이나 파일 작업에 대해 사용자 승인을 요청하며 작업 흐름을 지속적으로 방해(Interrupt)할 수 있다 [3].
|
||||
* **인프라 노이즈로 인한 평가 편향 (Infrastructure Noise):** 샌드박스 컨테이너에 할당되는 리소스 구성(CPU/메모리 등) 자체가 모델 평가 시 6% 포인트 이상의 벤치마크 점수 변동을 일으키는 인프라 노이즈로 작용할 수 있다 [8]. 특정 리소스 할당량(예: 3배 임계값)을 넘어서면 에이전트가 가벼운 도구를 쓸지 무거운 종속성을 사용할지 등 문제 해결 전략을 완전히 바꾸게 되므로 성능 평가 시 주의가 필요하다 [8].
|
||||
* **운영 복잡성 증가:** 샌드박싱이나 파일 시스템 백엔드 기능을 컨테이너화된 환경에서 사용할 경우, 로컬에서 단순 실행하는 것보다 운영 및 설정의 복잡성이 구조적으로 증가하는 반대 급부가 따른다 [9-11].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-05*
|
||||
@@ -0,0 +1,18 @@
|
||||
# [[심층 방어 (Defense-in-depth)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
에이전트 하네스 환경에서 심층 방어(Defense-in-depth)란 자율형 인공지능의 실행을 잠재적인 '적대적 워크로드(hostile workload)'로 간주하고, 이를 안전하게 제어하기 위해 다중 계층의 보호 장치를 중첩하여 구축하는 보안 아키텍처이다 [1]. 격리된 컨테이너, 방화벽, 프록시, 스키마 필터링 등 다양한 방어 기제를 함께 적용하여 시스템을 보호한다 [1, 2]. 이는 단일 샌드박스 격리 방식이 지닌 한계를 보완하고 에이전트에 의한 의도치 않은 권한 상승이나 시스템 손상을 방지하기 위해 필수적으로 요구된다 [3].
|
||||
|
||||
## 📖 Core Content
|
||||
* **5계층 심층 방어 체계:** 터미널 네이티브 코딩 에이전트를 위한 하네스 설계에서는 안전성을 확보하기 위해 5계층 심층 방어(5-layer defense-in-depth safety) 체계를 도입하여 운영한다 [2].
|
||||
* **스키마 기반 행동 제약:** 단순한 런타임 권한 검사에만 의존하지 않고, 스키마 필터링이 적용된 계획 하위 에이전트(schema-filtered planning subagents)를 활용해 도구 스키마 단에서 에이전트의 행동 제약을 물리적으로 강제하는 방식이 방어 계층의 주요 요소로 활용된다 [2].
|
||||
* **적대적 워크로드 기반 인프라 보호:** CI(지속적 통합) 자동화 인프라 내부에서 코딩 에이전트가 실행될 때, 시스템은 에이전트 실행 자체를 '적대적 워크로드'로 취급하여 보호막을 구축한다 [1].
|
||||
* **주요 심층 방어 구현 요소:** 구체적인 방어 레이어의 구현 사례로는 격리된 에이전트 컨테이너(isolated agent container), 방화벽(firewall), MCP 게이트웨이(MCP gateway), API 프록시(API proxy), 단계적 안전 출력(staged safe outputs), 그리고 제로 시크릿 실행(zero-secret execution) 메커니즘이 포함된다 [1].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **단일 샌드박스 격리의 한계:** 일반적인 수준의 샌드박스 격리(standard sandbox isolation)만으로는 충분한 보안을 달성할 수 없다. 에이전트가 자신의 하네스 구성을 직접 편집할 수 있는 환경이라면 스스로 권한을 상승시킬 수 있는 치명적인 위협이 발생한다 [3]. 따라서 네트워크 송신 제한, 작업 공간 탈출 차단, MCP 서버 구성 및 훅(hooks) 파일 보호와 같은 다중 방어 계층이 필수적으로 병행되어야 한다 [3].
|
||||
* **문서화 및 인식 부족 현상:** 에이전트 실행을 적대적인 것으로 간주하고 심층 방어 아키텍처를 구축하는 보안 마인드셋은 대부분의 하네스 인프라에 반드시 필요함에도 불구하고, 업계 내에서 관련 기술과 접근법이 제대로 문서화되어 있지 않다(rarely document)는 현실적인 한계점이 존재한다 [1].
|
||||
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-05*
|
||||
@@ -0,0 +1,35 @@
|
||||
---
|
||||
id: HARNESS-RES-2026-05-010
|
||||
title: 인간 개입 (Human-in-the-Loop, HITL)
|
||||
category: "10_Wiki/Topics/Governance"
|
||||
status: verified
|
||||
confidence_score: 0.95
|
||||
tags: [harness, governance, hitl, safety, collaboration, decision-making]
|
||||
created_at: 2026-05-05
|
||||
updated_at: 2026-05-08
|
||||
---
|
||||
|
||||
# 인간 개입 (Human-in-the-Loop, HITL)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "자율성의 안전벨트: 에이전트의 실행 과정 중 고위험 의사결정 지점에서 인간의 승인과 검토를 강제하여, 시스템의 통제력을 유지하고 치명적 오류를 예방하는 최후의 거버넌스 장치."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **HITL 아키텍처 패턴**:
|
||||
* **중단 및 승인 메커니즘 (Interrupts)**: 프로덕션 DB 쓰기나 외부 통신 전 실행을 일시 중지(pause)하고 인간의 승인을 대기하는 워크플로우를 구현한다 [3, 5, 6].
|
||||
* **브레이크포인트 패턴**: Dify 및 LangGraph 등은 실행 루프 중간의 결정 지점에서 상태를 지속시키고 검토 UI를 노출한 뒤, 결과에 따라 이후 경로를 라우팅하는 패턴을 지원한다 [4].
|
||||
* **인간의 역할 진화 ('Humans on the loop')**: 개별 작업의 건별 승인을 넘어, 에이전트의 인프라(하네스) 자체를 설계하고 최적화하는 메타 수준의 관리자로 역할이 진화해야 한다 [4, 7].
|
||||
* **보안 계층으로서의 HITL**: 고유 계정 접근이나 공유 메모리 기록 시, 악의적 프롬프트 인젝션 방지와 데이터 무결성 보호를 위해 인간 승인 게이트는 필수적 보안 계층이다 [8, 9].
|
||||
|
||||
## ⚖️ 트레이드오프 및 고려사항
|
||||
* **승인 피로(Approval Fatigue)**: 모든 행동에 승인을 강제할 경우, 사용자가 내용을 보지 않고 기계적으로 자동 승인(auto-approve)하게 되어 통제력이 무력화되는 부작용이 있다 [4, 8, 10].
|
||||
* **확장성(Scalability) 병목**: 인간의 응답 속도에 시스템이 대기해야 하므로, 에이전트의 대량 처리 이점이 반감된다. 자율적인 자체 검증(self-verification) 루프와의 적절한 조합이 필요하다 [4, 11, 12].
|
||||
* **적응형 개입 모델의 불완전성**: 정보 부족 시에만 도움을 요청하는 모델이 제안되나, 현재 최상위 모델조차 도움을 구하기보다 제한된 정보로 작업을 강행하려는 경향이 있어 주의가 필요하다 [4].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **상위 개념**: [[AI Governance]], [[Permissions and Safety]]
|
||||
- **유사 개념**: [[Pre-Action Authorization]], [[Self-Verification]], [[Approval Fatigue]]
|
||||
- **관련 프로젝트**: [[Dify]], [[LangGraph]], [[ConnectAI]]
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-08*
|
||||
@@ -0,0 +1,17 @@
|
||||
# [[체크포인팅 (Checkpointing)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
에이전트 하네스에서 체크포인팅(Checkpointing)은 에이전트의 작업 상태를 지속적으로 보존하고 복구하기 위한 핵심 메모리 및 상태 관리 메커니즘입니다 [1]. 주로 장기 실행(Long-running) 작업이나 수일(Multi-day)에 걸친 파이프라인에서 중단된 작업을 컨텍스트 손실 없이 재개할 수 있도록 지원합니다 [2-4]. 또한, 오류 발생 시 시스템을 복구하는 결함 감내(Fault-tolerance) 패턴 및 인간 개입(Human-in-the-loop) 프로세스를 위한 일시 정지 지점으로도 활용됩니다 [5, 6].
|
||||
|
||||
## 📖 Core Content
|
||||
* **상태 복구 및 메모리 영속성:** 체크포인팅은 에이전트 하네스를 구성하는 5대 핵심 기술 프리미티브 중 '메모리(Memory)' 영역에 속합니다 [1]. 세션 간 상태 지속성을 유지하고, 실패한 지점부터 장기(Long-horizon) 작업을 다시 시작할 수 있도록 허용하여 모델의 컨텍스트 연속성을 보장합니다 [1, 2].
|
||||
* **절전 및 기상(Hibernate-and-wake) 아키텍처:** 6시간 이상 소요되거나 수일에 걸쳐 진행되는 머신러닝 파이프라인 자동화 등의 작업에서, 에이전트가 중단된 지점의 컨텍스트를 잃지 않고 작업을 재개할 수 있도록 절전 및 기상 방식의 체크포인팅 기술이 적용됩니다 [3].
|
||||
* **명시적 상태 제어 및 오케스트레이션:** LangGraph와 같은 프로덕션 수준의 프레임워크는 체크포인트 지속성을 일급 객체(First-class primitives)로 취급하여, 복잡한 조건부 워크플로우 내에서 에이전트의 상태를 명시적이고 세밀하게 제어합니다 [4, 7].
|
||||
* **결함 감내(Fault Tolerance) 패턴:** 에이전트 시스템에서 복구 불가능한 실패를 줄이기 위해 사용되는 4단계 결함 감내 레이어(지수 백오프 재시도 → 모델 대체 체인 → 오류 분류 → 체크포인트 복구) 중 최후의 복구 수단으로 기능하여 신뢰성을 높입니다 [6].
|
||||
* **인간 개입(HITL) 통제 수단:** AutoResearchClaw 등의 시스템에서는 체크포인트를 인간 개입 모드(Intervention mode) 중 하나로 설정하여, 에이전트가 작업을 진행하는 중간에 멈추어 인간의 교정이나 승인을 받을 수 있는 지점을 제공합니다 [5].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
체크포인팅을 통해 에이전트의 상태를 세밀하게 제어하고 영속성을 부여하는 방식(예: LangGraph의 그래프 기반 상태 오케스트레이션)은 역할을 기반으로 하는 단순화된 대안 프레임워크들에 비해 설정이 장황(Verbose)해지며 학습 곡선이 가파르다는 제약이 있습니다 [8]. 또한, 중간 상태를 디스크나 파일 시스템에 오프로딩하여 상태를 보존하는 구조는 컨테이너화된 운영 환경에서 시스템의 운영상 복잡성(Operational complexity)을 증가시킬 수 있습니다 [9]. 그 외 체크포인팅 고유의 딥 다이브된 부작용이나 추가적인 반대 급부에 대해서는 소스에 관련 정보가 부족합니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-05*
|
||||
@@ -0,0 +1,7 @@
|
||||
# [[파일 시스템 (Filesystem)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
에이전트 하네스에서 파일 시스템은 대규모 언어 모델(LLM)의 지능을 실제 실행 환경과 연결하는 가장 기초적이고 핵심적인 기술 프리미티브 중 하나이다 [1-3]. 이는 에이전트에게 데이터와 코드를 읽고 쓸 수 있는 영구적인 작업 공간을 제공하여 단일 컨텍스트 윈도우의 제약을 극복할 수 있게 한다 [3-5]. 또한, 여러 에이전트와 인간 개발자가 공유된 파일을 통해 장기 작업을 조율하고 상태를 추적할 수 있는 자연스러운 협업 표면(Collaboration Surface)으로 기능한다 [5-7].
|
||||
|
||||
## 📖 Core Content
|
||||
* **물리적 작업 공간 및 상호작용 토대:** 에이전트 하네스는 파일 읽기, 쓰기, 수정, 파일 시스템 검색(Grep, Glob) 등 파일 I/O 도구를 제공한다 [8]
|
||||
@@ -0,0 +1,33 @@
|
||||
---
|
||||
id: HARNESS-RES-2026-05-011
|
||||
title: 허용 목록 (Allow-listing)
|
||||
category: "10_Wiki/Topics/Governance"
|
||||
status: verified
|
||||
confidence_score: 0.94
|
||||
tags: [harness, security, allow-listing, governance, tool-control]
|
||||
created_at: 2026-05-05
|
||||
updated_at: 2026-05-08
|
||||
---
|
||||
|
||||
# 허용 목록 (Allow-listing)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "명시적 허가 외 금지: 에이전트가 사용할 수 있는 도구와 네트워크를 미리 정의하여 포괄적 권한(Ambient Permissions) 오용을 원천 차단하는 가장 기초적인 보안 경계."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **명시적 권한 및 도구 제어:** 에이전트는 주변에 열려 있는 포괄적 권한(ambient permissions)을 가질 수 없으며, 오직 허용 목록에 등록된 도구와 환경만 사용할 수 있다 [2]. 도구의 사양은 일반적인 소프트웨어 코드처럼 리뷰를 거치고 버전 관리가 이루어진다 [2].
|
||||
* **엔터프라이즈 및 프레임워크 적용 사례:**
|
||||
* **GitHub Enterprise:** 클라우드 에이전트 방화벽 허용 목록(firewall allowlisting)과 임시 러너(ephemeral runners)를 강제 적용하여 에이전트 환경을 표준화하고 통제한다 [1].
|
||||
* **Claude Agent SDK:** `allowedTools` 및 `disallowedTools` 속성을 통해 선언적으로 도구 접근 범위를 결정하며, 훅(Hooks)과 권한 모드를 결합한 5단계 권한 평가 순서를 따른다 [1].
|
||||
|
||||
## ⚖️ 트레이드오프 및 고려사항
|
||||
* **정적 목록(Static Lists)의 한계:** 정적 허용/거부 목록 방식은 특정 도구에 대한 접근 자체를 막는 데는 유용하지만, 도구 호출 시 발생하는 데이터의 적절성까지 통제하는 행동 수준의 강제(behavioral-level enforcement)를 수행하기에는 불충분하다 [3].
|
||||
* **동적 가드레일 병행의 필요성:** 정적 목록의 한계를 보완하기 위해 NeMo Guardrails와 같이 도구의 입출력 데이터 내용을 실행 계층(execution rail layer)에서 동적으로 제한할 수 있는 툴킷이 수반되어야 한다 [3].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **상위 개념**: [[Permissions and Safety]], [[AI Governance]]
|
||||
- **유사 개념**: [[Pre-Action Authorization]], [[Network Security]], [[Guardrails]]
|
||||
- **관련 프로젝트**: [[GitHub Enterprise]], [[Claude Agent SDK]], [[ConnectAI]]
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-08*
|
||||
Reference in New Issue
Block a user