에이전트 아키텍처에는 개발자와 운영자라는 두 가지 권한 계층이 필요하다

2026년 3월, Simon Willison은 Claude Code 및 Codex와 같은 코딩 에이전트(coding agents)로부터 최상의 결과를 얻기 위한 가이드인 "Agentic Engineering Patterns"를 발표했습니다. 이에 대한 Hacker News의 논의가 빠르게 떠올랐습니다. 한 실무자의 댓글은 코딩 에이전트를 훨씬 넘어 적용되는 내용을 담고 있었습니다: "테스트 하네스(Test harness)가 전부입니다. 작업 내용을 검증할 방법이 없다면, 루프(loop)는 길을 잃고 방황할 것입니다."

그 직관은 옳습니다. 하지만 진단은 불완전합니다.

문제 — 통제 불능의 에이전트 루프, 확인되지 않은 출력물, 권한 범위를 초과하는 에이전트 — 는 근본적으로 테스트 하네스의 문제가 아닙니다. 그것은 아키텍처 내에서 제어권(control)이 어디에 위치하느냐의 문제입니다. 오늘날 대부분의 에이전트 시스템(agentic systems)에서 제어권은 전적으로 에이전트 코드 내부에 존재합니다. 에이전트를 구축하는 엔지니어가 에이전트가 무엇을 할 수 있는지, 누구를 호출할 수 있는지, 그리고 언제 멈출지를 정의하는 동일 인물입니다. 해당 에이전트가 프로덕션(production) 환경에 도달했을 때, 이를 실행하는 운영자(operator)는 새로운 배포(deployment) 없이는 조작할 수 있는 독립적인 레버(lever)를 갖지 못합니다.

이것은 테스트의 공백이 아닙니다. 구조적 공백(structural gap)입니다. Gartner가 2026년 말까지 기업용 애플리케이션의 40%가 특정 작업용 AI 에이전트를 통합할 것이라고 예측함에 따라 — 2025년의 5% 미만에서 증가 — 이는 규모의 경제 측면에서 구조적 공백이 됩니다.

에이전트 아키텍처의 단일 계층 문제

오늘날 대부분의 에이전트 시스템은 하나의 권한 계층(authority layer)을 가집니다: 바로 개발자(developer)입니다. 에이전트의 동작, 제약 조건, 허용된 도구, 비용 제한 및 종료 조건은 에이전트 자체의 로직에 인코딩되어 있습니다. 가드레일(Guardrails)은 프롬프트(prompt)나 코드 내에 존재합니다. 승인 게이트(Approval gates)는 워크플로우(workflow)에 하드와이어(hardwired)되어 있습니다.

이는 에이전트가 구축되는 방식의 자연스러운 결과입니다. 개발자는 작업을 이해하고, 도구 호출(tool calls)을 설계하며, 예측 가능한 안전 점검 사항을 추가합니다. 이는 개발 단계에서 잘 작동하며 초기 프로덕션 단계에서도 버텨냅니다.

하지만 조직이 여러 에이전트로 확장되거나, 운영자 — 컴플라이언스(compliance) 팀, 보안 팀, 제품 소유자(product owners) — 가 엔지니어링 사이클을 트리거하지 않고 제약 조건을 업데이트해야 할 때 이 방식은 무너집니다.

현실적인 시나리오: 한 금융 서비스 기업이 고객 데이터를 조회하고 통신 초안을 작성하는 AI 에이전트(AI agent)를 운영하고 있습니다. 개발자는 외부 API 호출을 승인된 벤더 목록으로 제한하는 가드레일(guardrail)을 구축했습니다. 배포 3개월 후, 컴플라이언스(compliance) 팀이 승인된 벤더 목록을 변경합니다. 화이트리스트(whitelist)를 업데이트하기 위해 엔지니어링 팀은 에이전트 코드를 수정하고, 변경 사항을 테스트한 뒤 배포합니다. 이 과정 동안 에이전트는 오프라인 상태가 됩니다. 향후 모든 정책 업데이트도 동일한 경로를 따르게 됩니다.

이것이 실제 사례로 나타나는 단일 권한 계층(single-authority-layer) 아키텍처입니다. 즉, 모든 정책 변경이 곧 코드 변경이 되는 것입니다. 코드 변경에는 리드 타임(lead time), 리뷰 주기, 그리고 배포 리스크(deployment risk)가 따릅니다. 컴플라이언스 요구사항이 지속적으로 진화하는 세상에서 이는 지속 가능한 설계가 아닙니다.

개발자 권한과 운영자 권한은 서로 다른 것이다

구조적인 해결책은 거버넌스(governance)를 "개발자의 업무 중 일부"로 만드는 것이 아닙니다. 개발자는 이미 에이전트가 할 수 있는(can) 것, 즉 작업 로직(task logic), 도구 통합(tool integrations), 추론 루프(reasoning loop), 출력 형식(output format)에 대해 책임을 지고 있습니다. 이것이 개발자 권한(developer authority)입니다. 즉, 에이전트의 역량을 결정하는 결정사항들입니다.

운영자 권한(operator authority)은 다릅니다. 이는 특정 배포 컨텍스트(deployment context)에서 에이전트가 하도록 허용된(allowed to do) 것을 다룹니다. 어떤 데이터에 접근할 수 있는지, 세션당 얼마만큼 지출할 수 있는지, 언제 사람이 행동을 승인해야 하는지, 어떤 출력 패턴이 차단되는지 등이 여기에 해당합니다. 이러한 제약 조건은 배포별로 특화되어 있고, 컴플라이언스에 의해 주도되며, 엔지니어링 팀이 아닌 비즈니스 및 운영 팀이 소유합니다.

이를 해결하는 아키텍처 원칙은 일반적인 소프트웨어 엔지니어링에서 익숙한 개념인 관심사 분리(separation of concerns)입니다. 개발자의 관심사는 에이전트 내부에 속해야 합니다. 운영자의 관심사는 에이전트와 독립적으로 업데이트될 수 있는, 에이전트 상위의 별도 계층에 속해야 합니다.

에이전트 거버넌스(agentic governance) 아키텍처에서 이 별도의 계층은 거버넌스 플레인(governance plane)입니다. 이는 에이전트와 에이전트가 작동하는 시스템 사이에 위치하는 제어 표면(control surface)으로, 에이전트 코드의 변경 없이도 운영자가 정의한 정책을 강제합니다.

관측 가능성(Observability)이 이 문제를 해결하지 못하는 이유

프로덕션 에이전트 리스크에 대한 현재 시장의 대응은 관측 가능성(Observability)이었습니다. Arize, LangSmith, Helicone, Braintrust는 에이전트가 무엇을 하고 있는지에 대한 가시성(visibility), 즉 트레이스(traces), 평가 점수(evaluation scores), 토큰 사용량(token usage), 응답 지연 시간(response latency)을 제공합니다. 이것들은 가치 있는 도구들입니다. 운영자가 무슨 일이 일어나고 있는지 볼 수 있게 해줍니다.

하지만 보는 것이 제어하는 것은 아닙니다.

관측 가능성 플랫폼은 에이전트가 화요일에 토큰 예산을 3,000토큰 초과했다는 사실을 알려줄 수 있습니다. 하지만 수요일에 그런 일이 다시 발생하는 것을 방지할 수는 없습니다. 평가 프레임워크(evaluation framework)는 출력이 낮은 신뢰도(low-confidence)를 가졌다고 점수를 매길 수 있습니다. 하지만 에이전트가 그 낮은 신뢰도의 추론을 바탕으로 행동하기 전에 인간의 승인을 요구할 수는 없습니다.

이것은 관측 가능성 도구에 대한 비판이 아니라, 아키텍처 범위(architectural scope)에 관한 노트입니다. 거버넌스 평면(governance plane)은 실행 계층(execution layer)이지, 관찰 계층(observation layer)이 아닙니다. 거버넌스 평면은 에이전트의 행동이 프로덕션 시스템에 도달하기 전에 가로채어, 운영자가 정의한 정책을 적용하고, 실시간으로 해당 행동을 허용, 수정 또는 차단합니다. 이것은 별개의 아키텍처 구성 요소입니다. 관측 가능성 벤더들은 이를 제공하지 않으며, 그렇게 설계되지도 않았습니다.

이 격차는 특히 중요합니다. 왜냐하면 이 주제에 대해 이용 가능한 가장 철저한 논의 중 하나인 Arize 자체의 에이전트 아키텍처 가이드라인이 거버넌스를 개발자가 에이전트 코드에 내장하는 것으로 명시적으로 프레임화하고 있기 때문입니다: "에이전트의 가이드 시스템에 도메인 및 비즈니스 휴리스틱(heuristics)을 통합하는 것"과 "행동 의도를 명확히 하는 것"입니다. 이 두 가지 모두 개발자 계층(developer-layer)의 솔루션입니다. 둘 중 어느 것도 코드 프리즈(code freeze) 상황에서도 유지되는 운영자 계층(operator-layer)의 제어를 제공하지 않습니다.

실제 적용에서의 2계층 아키텍처

잘 구조화된 에이전트 시스템은 개발자 범위(developer scope)와 운영자 범위(operator scope) 사이에 명확한 경계를 가집니다.

개발자 계층(Developer layer): 에이전트의 작업(task), 사용 가능한 도구(tools), 추론 루프(reasoning loop), 내부 로직(internal logic), 그리고 출력 형식(output format)입니다. 이것들은 에이전트 코드나 설정(configuration)에 존재합니다. 이것들을 변경하려면 엔지니어링 사이클(engineering cycle)이 필요하며, 이는 적절합니다. 왜냐하면 이것들이 역량(capability)을 정의하기 때문입니다.

운영자 계층 (Operator layer): 에이전트가 접근할 수 있는 데이터 소스, 지출 한도, 어떤 액션 카테고리에 인간의 승인이 필요한지, 어떤 출력 콘텐츠가 차단되는지, 각 환경에서 어떤 버전이 활성화되어 있는지 등을 결정합니다. 이것들은 에이전트 코드(agent code)가 아닌 거버넌스 평면(governance plane)에 존재합니다. 이를 변경하는 데는 배포(deployment)가 필요하지 않으며, 이것이 바로 핵심입니다.

이러한 분리는 외부 에이전트에게 중요한 결과를 초래합니다. 제3자 통합(Third-party integrations), 벤더 자동화(vendor automations), 그리고 MCP 네이티브 에이전트(MCP-native agents)는 내장된 거버넌스 없이 도입됩니다. 운영자는 자신이 작성하지 않은 코드에 접근할 수 없습니다. 프로토콜 수준에서 작동하며 프로덕션 시스템에 도달하기 전에 호출을 가로채는(intercepting) 거버넌스 평면만이, 운영자가 직접 구축하지 않은 에이전트를 관리할 수 있는 유일하고 실질적인 접근 방식입니다.

Waxell Connect는 정확히 이 시나리오를 해결합니다. SDK나 에이전트 측의 코드 변경 없이도 운영자가 직접 구축하지 않은 에이전트들(벤더 에이전트, 제3자 통합, MCP 네이티브 에이전트)을 관리합니다. 운영자는 거버넌스 평면에서 정책을 정의하며, Connect는 액션이 실행되기 전에 이를 강제(enforce)합니다.

Waxell Runtime은 팀이 직접 구축하는 에이전트에 대해 운영자 계층을 강제하며, 에이전트 코드를 수정하지 않고도 입력(inputs), 출력(outputs), 도구 호출(tool calls), 실행 상태(execution state) 전반에 걸쳐 26가지 정책 카테고리를 적용합니다.

레지스트리(Registry)가 이를 체계적으로 만드는 핵심이다

어느 권한 계층도 무엇이 실행되고 있는지에 대한 기록 시스템(system of record) 없이는 작동하지 않습니다.

개발자 권한(Developer authority)은 어떤 에이전트의 어떤 버전이 배포되었는지 아는 것을 필요로 합니다. 운영자 권한(Operator authority)은 어떤 에이전트가 어떤 정책을 따라야 하는지 아는 것을 필요로 합니다. 에이전트의 정체성(identity), 버전, 할당된 정책, 배포 컨텍스트를 매핑하는 구조화된 카탈로그인 에이전트 레지스트리 (agent registry)가 없다면, 거버넌스 평면은 일관되게 아무것도 강제할 수 없습니다. 정책은 존재하지만, 어떤 에이전트가 활성화되어 있고 각 에이전트에 어떤 운영자 규칙이 적용되는지에 대한 권위 있는 매핑(authoritative mapping)이 없기 때문에 신뢰성 있게 적용되지 않습니다.

이러한 격차는 규모가 커질 때 명확히 드러납니다. 에이전트가 5개일 때는 팀이 수동으로 관리하거나 공유 문서를 통해 관리할 수 있습니다. 하지만 여러 부서에 걸쳐 50개의 에이전트가 운영될 때는 수동 추적이 불가능해집니다. 정책 검토(policy review)를 트리거하지 않은 채 에이전트가 업데이트되기도 합니다. 컴플라이언스(compliance) 팀이 데이터 액세스 범위(data access scope)를 검토하기 전에 새로운 배포가 라이브 상태가 되기도 합니다. 어떤 버전이 언제 실행 중이었는지 아무도 알 수 없기 때문에, 사고(incident)가 잘못된 버전의 탓으로 돌려지기도 합니다.

레지스트리(registry)는 운영자 권한(operator authority)을 일시적인 것이 아니라 체계적인 것으로 만드는 핵심 요소입니다.

제어된 데이터 인터페이스(Controlled Data Interfaces)를 통한 루프 완성

개발자/운영자 분리는 세 번째 아키텍처 질문인 데이터 액세스 설계(data access design)를 부각시킵니다.

대부분의 에이전트 시스템은 에이전트에게 상대적으로 개방적인 데이터 액세스를 허용합니다. 광범위한 권한을 가진 데이터베이스 연결, 파일 시스템, 또는 특정 작업에 필요한 것보다 훨씬 더 많은 정보를 반환하는 내부 API 등이 그 예입니다. 이는 프로토타입 단계에서는 작동하지만, 에이전트가 운영 환경(production)에서 자율적으로 실행될 때는 리스크(liability)가 됩니다.

Signal and Domain pattern은 이를 아키텍처 수준에서 해결합니다. Signal 레이어는 제어된 읽기 인터페이스(read interface)입니다. 에이전트는 원시 운영 시스템(raw production systems)에 직접 접근하지 않고도 검증되고 타입이 지정된(typed) 데이터 표현을 전달받습니다. Domain 레이어는 쓰기 경계(write boundary)입니다. 에이전트는 상태를 직접 변경(mutating state)하는 대신 구조화된 인터페이스를 통해 의도(intent)를 표현합니다. 이는 단순한 보안 조치가 아닙니다. 운영자 권한(operator authority)을 강제할 수 있게 만드는 아키텍처적 결정입니다.

에이전트가 제어된 인터페이스를 통해 읽고 검증된 경계를 통해 쓸 때, 거버넌스 평면(governance plane)은 명확한 차단 지점(interception points)을 갖게 됩니다. 에이전트가 원시 데이터베이스 액세스 권한을 가지면, 거버넌스는 애플리케이션 레이어에서 일관성 없게 적용되어야 하며, 이는 곧 거버넌스가 누락됨을 의미합니다.

Waxell의 2계층 모델 구현 방식

Waxell의 아키텍처는 개발자/운영자 분리를 직접적으로 반영합니다:

Waxell Observe (초기화에 단 2줄의 코드 필요, 200개 이상의 라이브러리 자동 계측 (auto-instrumented))는 개발자 계층을 계측합니다. 이를 통해 엔지니어는 실제 에이전트의 동작, 트레이스 (traces), 그리고 출력 품질에 대한 가시성을 확보할 수 있으며, 결과적으로 개발 측면의 개선이 가정이 아닌 프로덕션 데이터에 기반하여 이루어지도록 합니다.

Waxell Runtime은 실행 시점에 운영자 계층을 강제합니다. 에이전트 자체를 다시 빌드할 필요 없이 입력, 출력, 도구 호출 (tool calls), 그리고 실행 상태 (execution state) 전반에 걸쳐 26가지 정책 카테고리가 적용됩니다.

Waxell Connect는 팀이 직접 구축하지 않은 에이전트(벤더 통합, MCP 네이티브 에이전트, 제3자 자동화 등)로 운영자의 권한을 확장합니다. 이는 SDK나 에이전트 코드의 변경 없이 프로토콜 수준의 제어 평면 (control plane)을 통해 관리됩니다.

**에이전트 레지스트리 (The agent registry)**는 이 세 가지를 하나로 묶습니다. 각 에이전트를 고유 식별자, 버전 이력, 그리고 활성 정책과 연결하는 영구적인 기록 시스템 (system of record) 역할을 수행하여, 운영자의 권한이 누군가 스프레드시트를 업데이트하는 것을 기억하는 것에 의존하지 않고 체계적으로 작동하게 합니다.

결과적으로 이 아키텍처는 에이전트가 무엇을 할 수 있는지(에이전트 코드 내의 개발자 권한)와 특정 배포 환경에서 에이전트가 무엇을 하도록 허용되는지(거버넌스 평면 내의 운영자 권한)를 분리하며, 경계면에는 제어된 데이터 인터페이스를 두고 레지스트리를 연결 조직으로 활용합니다.

에이전트 규모를 5개에서 50개로 확장하려는 팀에게 이러한 분리는 단순한 최적화가 아닙니다. 모든 정책 변경이 매번 배포 이벤트가 되지 않으면서도 규모를 확장할 수 있게 하는 유일한 아키텍처입니다.

waxell.ai/get-access에서 Waxell을 사용해 보세요.

FAQ

에이전트 아키텍처에서 거버넌스 플레인 (Governance Plane)이란 무엇인가요?
거버넌스 플레인 (Governance Plane)은 에이전트 코드 상위에 위치하여 실행 시점에 운영자(Operator)가 정의한 정책을 강제하는 제어 계층 (Control Layer)입니다. 이는 에이전트의 동작 — 도구 호출 (Tool calls), 데이터 요청 (Data requests), 출력 (Outputs) — 이 운영 시스템 (Production systems)에 도달하기 전에 가로채며, 에이전트 코드를 수정하지 않고도 변경할 수 있는 규칙을 적용합니다. 아키텍처 측면에서 에이전트 로직 (Agent logic) 및 관측성 스택 (Observability stack) 모두와 분리되어 있습니다.

왜 거버넌스 로직이 에이전트 내부에 존재해서는 안 되나요?
거버넌스가 에이전트 코드 내에 존재하면, 엔지니어링 배포 (Engineering deployment)를 통해서만 변경할 수 있습니다. 이로 인해 컴플라이언스 (Compliance) 업데이트, 정책 변경, 사고 대응 (Incident responses)이 엔지니어링 사이클 타임 (Engineering cycle times)에 의존하게 되며, 이는 며칠 또는 몇 주가 소요될 수 있습니다. 또한 운영자가 직접 구축하지 않은 에이전트 — 벤더 에이전트 (Vendor agents), 제3자 통합 (Third-party integrations) — 는 거버넌스를 전혀 적용할 수 없음을 의미합니다. 별도의 거버넌스 플레인 (Governance plane)은 이 두 가지 문제를 모두 해결합니다.