2026.07.31 / Jun
AI 에이전트 거버넌스의 필요성
2025년까지 AI 에이전트 분야의 화두는 “에이전트를 어떻게 더 똑똑하게 만들 것인가”였다. 그러나 2026년으로 넘어오면서 무게 중심이 완전히 이동했다. 이제 진짜 문제는 성능이 아니라 통제다. 즉 “이 에이전트가 무엇을 할 수 있고, 무엇을 하면 안 되며, 방금 무슨 일을 했는지 증명할 수 있는가”이다.
이 변화는 수치로도 드러난다. 최근 엔터프라이즈 에이전트 도입 사례를 분석한 자료들은, 프로젝트 실패의 상당수가 모델의 추론 능력 부족이 아니라 ‘하네스 결함(Harness Defects)’ — 컨텍스트 드리프트, 스키마 불일치, 상태 저하 — 에서 비롯된다고 지적한다. 모델만 키우고 그 모델을 감싸는 실행 인프라를 안정화하지 않으면 효용이 급격히 줄어든다는 것이다.
그래서 등장한 것이 에이전트 거버넌스(Agent Governance)다. 핵심은 단순하다.
LLM에게 무분별한 자유분방함을 주는 것이 아니라,
LLM을 원하는 범위 안에서만 자유롭게 일할 수 있도록 하자.
거버넌스를 구성하는 기법은 여러 가지가 있지만, 2026년 현재 아키텍처의 뼈대를 이루는 세 가지가 Harness, Ontology, MCP다. 이 셋은 경쟁 관계가 아니라 서로 다른 계층을 담당하는 보완 관계이며, 각각 ‘실행’, ‘의미’, ‘도구 접근’이라는 서로 다른 축을 통제한다. 이 글에서는 세 기법을 나란히 놓고 비교한다.
Harness · Ontology · MCP 비교표
| 구분 | Harness | Ontology | MCP |
|---|---|---|---|
| 통제하는 축 | 실행(Execution) | 의미(Semantics) | 도구 접근(Tool Access) |
| 핵심 질문 | “어떻게 안전하게 실행할 것인가” | “세상을 어떤 개념으로 이해할 것인가” | “어떤 도구를 어떤 조건으로 부를 것인가” |
| 통제 대상 | 에이전트 실행 루프 | 지식 구조 | 외부 Tool / API |
| 대표 산출물 | 실행 런타임, 승인 게이트, 감사 로그 | 엔티티·관계 스키마 | Tool Registry, MCP 게이트웨이 |
| 대표 기술 | LangGraph, OpenAI Agents SDK, Claude Agent SDK | 도메인 온톨로지, 시맨틱 레이어 | MCP 서버 / 게이트웨이 |
| 주된 실패 모드 | 무한 루프, 비용 폭주, 상태 저하 | 개념 혼동, 근거 없는 추론 | 과잉 권한, Shadow 도구 |
1. Harness — 실행 통제 계층
개념
Harness는 에이전트를 감싸는 ‘실행 봉투(operating envelope)’다. 하나의 에이전트 혹은 에이전트 루프에 대해 도구 접근, 컨텍스트, 권한, 메모리, 명령 실행, 파일 편집, 상태, 검증을 정의한다. Codex, Claude Code, Cursor 같은 코딩 에이전트가 모두 각자의 하네스를 가지고 있다.
2026년의 지배적인 관점은 이렇게 요약된다. 모델은 추론과 계획을 담당하는 ‘제어 평면(control plane)’일 뿐, 상태·실행·저장·승인·전송·관측은 하네스가 맡는다. 다르게 말하면, 모델은 유능하지만 신뢰할 수 있을 만큼은 아니라고 가정하고, 경계를 모델의 자기 검열이 아니라 도구·정책 엔진·샌드박스·네트워크·스토리지 계층에서 강제해야 한다.
하네스가 하는 일
전형적인 하네스는 Plan → Execute → Verify라는 경계가 있는 루프를 강제하면서 다음을 통제한다.
- 실행 시간 제한과 반복 루프 감시
- Tool 호출 횟수·비용 상한
- 메모리 및 컨텍스트 관리
- 예외 처리와 롤백(Rollback)
- 고위험 작업에 대한 사람 승인 게이트
- 추적·감사 로그를 통한 관측 가능성
하네스가 없으면 에이전트는 웹 검색에서 시작해 API 호출, 파일 삭제, DB 수정, 무한 루프까지 아무 제약 없이 이어갈 수 있다. 하네스는 이 흐름을 봉인한다.
한계
강력하지만 설계 비용이 든다. 실행 경로마다 제한과 검증을 정의해야 하고, 하네스 자체의 결함(스키마 불일치, 상태 저하)이 오히려 실패의 주범이 되기도 한다. 최근 논의에서 ‘에이전트 제어 평면(control plane)’과 ‘하네스’를 혼동하지 말라는 지적이 나오는 이유도 여기 있다. 제어 평면은 에이전트를 ‘자원’으로서 관리(신원·정책·감사)하고, 하네스는 에이전트의 ‘작업’을 실행 엔진으로서 관리한다. 둘을 뭉뚱그리면 시스템이 실제보다 안전해 보이는 착시가 생긴다.
2. Ontology — 의미 통제 계층
개념
Ontology는 에이전트가 세상을 이해하는 방식을 규정한다. 개념(엔티티)과 속성, 그리고 그들 사이의 관계를 형식적으로 정의한 모델이다. 예를 들어 쇼핑몰 에이전트라면 Product, Category, Brand, Order, Customer, Payment 같은 개념과 그 관계(Customer → Order → Payment → Shipment)를 정의한다.
핵심은, LLM은 온톨로지 안에서 자유롭게 추론하되 그 밖의 개념은 사용할 수 없다는 점이다. Harness가 ‘행동’의 경계라면, Ontology는 ‘의미’의 경계다.
왜 다시 중요해졌나
온톨로지는 오래된 개념이지만, 2026년 들어 완전히 다른 맥락에서 부활했다. 과거의 온톨로지가 수년짜리 학술적 모델링 프로젝트에 머물러 좌초했다면, 지금은 기존 데이터 카탈로그·리니지에 연결되는 ‘액티브 메타데이터’ 형태로 운영 가능해졌다. 에이전트가 내놓는 답이 ‘검증된 의미에 근거한 것’인지 아니면 ‘통계적 근사치’인지를 가르는 계층이 바로 온톨로지라는 인식이 확산되고 있다.
특히 여러 에이전트가 협업하는 멀티 에이전트 환경에서 공유된 언어(shared language)로서의 역할이 커졌다. 흥미로운 점은, 요즘 엔터프라이즈 사례에서 이 시맨틱 레이어를 MCP 서버를 통해 AI에 공급하는 패턴이 자리 잡고 있다는 것이다. 온톨로지와 MCP가 별개의 축이면서도 실무에서 맞물리는 지점이다.
한계
초기 설계가 어렵다. 도메인을 제대로 모델링하지 못하면 오히려 에이전트의 유연성을 해치거나, 유지보수 부담만 키운다. ‘완벽한 온톨로지’를 처음부터 만들려는 시도보다, 도메인 단위로 점진적으로 구축하는 접근이 권장된다.
3. MCP — 도구 접근 통제 계층
개념
MCP(Model Context Protocol)는 에이전트가 외부 도구를 부르는 방식을 표준화한 프로토콜이다. 2024년 말 Anthropic이 처음 제안했으며, 당시 모든 에이전트 프레임워크가 똑같은 tool-calling 배관을 각자 재발명하던 문제를 해결했다.
그러나 2026년의 MCP는 단순한 ‘개발 편의 도구’를 넘어섰다. 이제 MCP는 AI 에이전트를 위한 조직 차원의 접근 계층이며, 내부 특권 API 플랫폼처럼 거버넌스가 필요한 대상으로 취급된다.
MCP 거버넌스의 핵심
MCP를 거버넌스 관점에서 볼 때 중요한 것은 개별 도구가 아니라 그 사이에 놓이는 MCP 게이트웨이다. 게이트웨이는 하네스와 외부 도구 사이에 위치해 다음을 수행한다.
- 어떤 MCP 서버·도구에 접근 가능한지 결정 (allow / block / elicitation 규칙)
- 도구 호출 단위의 스키마 검증과 자격 증명 분리
- 모든 도구 호출에 대한 변조 불가능한(tamper-evident) 감사 로그
- 미등록 도구(Shadow MCP) 탐지와 신뢰 점수화
이는 최소 권한(Least Privilege) 원칙과 직결된다. 에이전트에게 ‘모든 도구’를 주지 않고, Agent A에는 검색만, Agent B에는 GitHub만, Agent C에는 Database만 부여하는 식이다. MCP의 Tool Registry 설계는 이 능력 기반(Capability-based) 접근 제어와 자연스럽게 맞물린다.
한계
MCP 게이트웨이는 프로토콜을 통과하는 트래픽만 관측한다. 에이전트의 로컬 연산이나 에이전트 간 상호작용은 보지 못한다. 또한 2025~2026년에 걸쳐 MCP 관련 SDK에서 심각도 높은 취약점(예: MCP Inspector의 인증 없는 RCE, Python SDK의 DNS 리바인딩)이 보고되면서, 프로토콜 자체가 아니라 구현 계층의 보안이 지속적인 과제로 남아 있다. OWASP가 별도의 ‘MCP Top 10’을 내놓은 것도 이 때문이다.
최신의 Harness · Ontology · MCP 통합 방식
앞서 강조했듯 Harness, Ontology, MCP는 택일의 대상이 아니다. 실제 2026년의 에이전트 아키텍처는 이들을 계층으로 쌓는다.
User
│
Identity / Auth
│
Policy Engine ← 누가 무엇을 할 수 있는가
│
Planner Agent
│
Ontology (의미 계층) ← 세상을 어떤 개념으로 이해하는가
│
Harness ← 실행·비용·시간·반복을 통제
│
MCP Gateway / Registry ← 도구 접근을 표준·통제
│
Guardrails (입출력 검사)
│
Executor Agent
│
Human Approval (선택) ← 고위험 작업의 최종 승인
│
External Tools
이 구조에서 세 기법의 역할은 명확히 갈린다.
- Ontology는 에이전트가 다룰 수 있는 ‘개념의 경계’를 긋는다. (의미)
- Harness는 에이전트가 그 개념 위에서 ‘어떻게 행동할지’를 봉인한다. (실행)
- MCP는 에이전트가 바깥세상의 ‘도구에 어떻게 닿을지’를 표준화하고 통제한다. (접근)
차세대 AI 에이전트 플랫폼의 핵심 설계 패턴으로 자리 잡고 있는 것이 바로 이 조합이다. MCP를 도구 계층의 표준 인터페이스로, Harness를 실행 제어 계층으로, Ontology를 의미 계층으로 결합하면, 다양한 LLM과 외부 도구를 연결하면서도 일관된 거버넌스를 유지할 수 있다.
바이브코딩 관점에서의 실용적 거버넌스 조합
멀티 에이전트 기반 Next.js 애플리케이션을 설계한다면, 다음 구성이 가장 실용적이다.
| 계층 | 추천 접근 |
|---|---|
| Workflow | LangGraph 또는 OpenAI Agents SDK |
| Harness | OpenAI Agents SDK Runner / LangGraph Runtime / Claude Agent SDK |
| Tool Registry | MCP 기반 Registry + 게이트웨이 |
| Ontology | 도메인 Entity를 JSON Schema + TypeScript Interface로 정의 |
| Policy | OPA(Open Policy Agent) 또는 앱 수준 RBAC/ABAC |
| Guardrails | Guardrails + JSON Schema Validation |
| Memory | Short-term / Vector RAG / Long-term 분리 |
| Audit | 모든 Tool Call·Prompt·Response를 구조화 로그로 저장 |
교육용 프로젝트로 시작해 프로덕션 수준으로 키우기에도 적합한 구성이다. 처음부터 세 계층을 완벽하게 만들 필요는 없다. MCP 게이트웨이로 도구 접근부터 통제하고, 하네스로 실행 루프를 봉인한 뒤, 온톨로지를 도메인 단위로 점진적으로 얹어가는 순서가 현실적이다.
정리
- Harness는 실행을, Ontology는 의미를, MCP는 도구 접근을 통제한다. 통제하는 축이 다르므로 세 기법은 경쟁이 아니라 계층으로 공존한다.
- 2026년 에이전트 실패의 상당수는 모델이 아니라 이 통제 계층의 결함에서 온다. 성능 최적화보다 거버넌스 안정화가 먼저다.
- 실무에서는 이 셋이 서로 맞물린다. 온톨로지를 MCP 서버로 공급하고, MCP 게이트웨이를 하네스 아래에 두는 식으로 경계가 겹친다.
- 시작은 도구 접근(MCP) → 실행(Harness) → 의미(Ontology) 순으로 점진적으로 쌓는 것이 현실적이다.
거버넌스는 에이전트의 발목을 잡는 족쇄가 아니다. 오히려 에이전트를 ‘믿고 맡길 수 있는 존재’로 만드는 신뢰의 기반이다. 자유를 없애는 것이 아니라, 자유가 안전하게 작동할 경계를 긋는 일이다.
