에이전트 시스템 아키텍처: Signal과 Domain이 빠진 조각인 이유

2026년 5월 2일에 발표된 Fortune의 조사 결과는 명확했습니다. Anthropic의 가장 강력한 모델이 기업 거버넌스의 위기를 막 드러낸 것입니다. 인용된 경영진들은 모델의 문제를 설명하고 있는 것이 아니었습니다. 그들은 아키텍처 (Architecture) 문제를 설명하고 있었습니다. 에이전트 (Agents)들이 프로덕션 데이터베이스 (Production databases)에 직접 접근하고, 범위 제한 (Scope constraints) 없이 API를 호출하며, 아무도 설계하지 않은 부작용 (Side effects)을 생성하고 있었습니다. 모델은 의도한 대로 작동하고 있었습니다. 하지만 그 주변의 시스템이 그렇지 않았습니다. 이러한 실패 패턴은 현재 IBM Think 2026 브리핑, California Management Review 연구, 그리고 에이전트 배포가 잘못된 거의 모든 심각한 사후 분석 (Post-mortem)에서 나타나고 있습니다. 팀들은 에이전트 자체 — 프롬프트 (Prompts), 도구 선택 (Tool selection), 오케스트레이션 로직 (Orchestration logic) — 에 수개월을 소비했고, 데이터 접근을 단순한 배관 문제 (Plumbing problem)로 취급했습니다. 에이전트에게 데이터베이스 연결이나 API 키를 건네주고, 몇 가지 런타임 가드레일 (Runtime guardrails)을 추가한 뒤 출시하는 식이었죠. 그들이 결코 설계하지 않은 것은 에이전트와 프로덕션 환경 (Production environment) 사이의 인터페이스 (Interface)였습니다. 그리고 그 인터페이스가 바로 에이전트 시스템이 운영적으로 건전해지느냐, 아니면 부채 (Liabilities)가 되느냐를 결정하는 지점입니다. Signal과 Domain 패턴은 이 문제에 대한 구조적인 해답입니다. 이것은 모니터링 도구나 정책 계층 (Policy layer)이 아닙니다. 이것은 에이전트가 실행되는 동안 관리되는 것이 아니라, 실행되기 전에 결정되는 에이전트의 운영 환경이 어떤 형태를 취할지에 대한 아키텍처적 결정입니다.

직접 접근이 확장 불가능한 이유
인간 엔지니어가 프로덕션 데이터베이스를 쿼리 (Query)할 때는 암묵적인 계약이 유지됩니다. 그들은 무엇을 찾고 있는지 알고 있으며, 타겟팅된 쿼리를 작성하고, 스키마 (Schema)를 잘못 읽어서 테이블에 DELETE를 호출하지 않습니다. 그 계약은 에이전트에게는 적용되지 않습니다. 에이전트는 도구 호출 (Tool calls)의 체인을 통해 작동합니다. 각 호출은 에이전트의 컨텍스트 (Context)에 추가됩니다. 그 축적된 컨텍스트는 이후의 모든 결정에 영향을 미칩니다. 고객 지원 에이전트가 고객 기록을 가져오는 것으로 시작했다면, 네 번의 도구 호출이 지난 후에는 그 과정에서 내린 추론 (Inferences)을 바탕으로 해당 기록에 다시 내용을 쓰고 있을지도 모릅니다. 아키텍처 상에서 그것이 불가능하다고 명시한 것이 아무것도 없기 때문입니다.

그 아키텍처에는 형태가 없었습니다. 오직 권한(permissions)만이 존재했습니다. 이것이 바로 2026년 4월에 발생한 PocketOS 사건을 초래한 정확한 원인이었습니다. 당시 데이터베이스 쓰기 권한을 가진 Cursor 기반 에이전트가 단 9초 만에 전체 운영(production) 데이터베이스를 삭제했습니다. 모델이 오작동한 것이 아니었습니다. 아키텍처가 허용한 것을 실행했을 뿐입니다. 추론된 쓰기(inferred write) 작업이 파괴적인 작업으로 변하는 것을 막는 구조적 제약(structural constraint)은 없었으며, 오직 에이전트에게 주의하라고 지시하는 프롬프트(prompt)만이 있었을 뿐입니다. 프롬프트 지침은 아키텍처 경계(architectural boundary)가 아닙니다. 이는 탈옥(jailbreak)에 의해 우회될 수 있고, 도구 호출(tool call) 결과에 포함된 악성 페이로드(malicious payload)에 의해 덮어씌워질 수 있으며, 에이전트의 컨텍스트 윈도우(context window)가 가득 찼을 때 단순히 잘못 읽힐 수도 있습니다. 반면 아키텍처 경계는 우회될 수 없습니다. 그것은 에이전트가 애초에 도달할 수 있는 범위를 형성합니다. IBM Think 2026 연구에 따르면, 경영진 10명 중 7명은 기존 거버넌스 인프라(governance infrastructure)의 무능력이 AI 전환을 늦추고 있다고 답했습니다. 또한, 현재의 완전한 AI 인벤토리(AI inventory)를 유지하고 있는 조직은 18%에 불과했습니다. IBM의 Think 2026 분석은 속도(speed), 규모(scale), 확산(sprawl)을 세 가지 복합적인 위험 요소로 지목했습니다. 즉, 가공되지 않은 운영 권한을 가진 에이전트가 인간의 감독이 따라갈 수 있는 속도보다 빠르게 작동하고, 단 한 번의 잘못된 결정이 미치는 영향 범위(blast radius)를 배가시키는 규모로 움직이며, 아무도 연결된 것으로 매핑하지 않은 시스템 전반에서 작동할 때 어떤 일이 벌어질지에 대한 문제입니다. 관습적인 대응 방식은 에이전트 계층에 가드레일(guardrails)을 추가하는 것입니다: 출력 필터(output filters), 런타임 정책 확인(runtime policy checks), 콘텐츠 중재(content moderation) 등이 그것입니다. 이것들도 중요합니다. 하지만 이것들은 구조가 아닌 증상을 다루는 것입니다. Signal과 Domain 패턴은 구조를 다룹니다.

패턴: 두 개의 계층, 하나의 경계
Signal과 Domain 패턴은 단순한 정책 집행이 아닌, 인터페이스 설계(interface design)를 통해 에이전트가 무엇을 알 수 있고 무엇을 할 수 있는지를 정의하는 아키텍처적 분리입니다. Signal 계층은 어떤 데이터가 에이전트의 컨텍스트(context)로 들어올지를 제어합니다.

에이전트에게 데이터베이스에 직접 접근할 수 있는 권한을 주는 대신, Signal 계층은 에이전트가 볼 권한이 있는 정확한 데이터만을, 에이전트가 수신하도록 허용된 형태(shape)로 반환하는 정의된 타입 인터페이스(typed interface)를 제공합니다. 이를 읽기 표면(read surface)이라고 생각하십시오. 즉, 기본적으로 구조화되고, 검증되며, 개인정보(PII)가 처리되고, 감사(auditable) 가능한 표면입니다. 에이전트는 근본적인 데이터 저장소(data store)에 절대 직접 닿지 않습니다. 대신 에이전트는 자율적인 소비를 위해 설계된 목적 지향적 데이터 피드인 Signal을 수신합니다.

Domain 계층은 에이전트가 수행할 수 있는 행동을 제어합니다. 범용 API나 데이터베이스 연결을 노출하는 대신, Domain 계층은 제한된 행동 표면(action surface)을 노출합니다. 이는 명시적으로 허용된 작업 세트이며, 각 작업은 정의된 범위(scope), 정의된 부작용(side effects), 그리고 정의된 가역성 분류(reversibility classification)를 가집니다. 에이전트는 오직 Domain 내에서만 행동할 수 있습니다. 새로운 작업을 만들어낼 수 없으며, 자신의 권한을 상승(escalate)시킬 수도 없습니다. 경계(boundary) 자체가 인터페이스이기 때문에 경계 밖으로 나갈 수도 없습니다. Signal과 Domain은 함께 에이전트 행동을 둘러싸는 아키텍처적 봉투(architectural envelope)를 형성합니다. 거버넌스 평면(governance plane)은 외부에서 에이전트와 싸울 필요가 없습니다. 거버넌스는 에이전트가 작동하는 표면의 형태 자체에 내장되어 있기 때문입니다.

이는 특히 외부 에이전트, 즉 팀이 직접 구축하지 않았고 수정할 수도 없는 벤더 통합(vendor integrations), 제3자 자동화(third-party automation), 그리고 MCP-native 에이전트들에게 매우 중요합니다. 이러한 에이전트들의 경우, 안전 계층(safety layer)을 추가할 수 있는 에이전트 코드 자체가 존재하지 않습니다. 거버넌스가 존재할 수 있는 유일한 장소는 그들이 작동하는 인터페이스뿐입니다.

Signal 계층 설계하기
Signal 계층은 읽기 인터페이스이지만, 수동적인 인터페이스는 아닙니다. 세 가지 설계 원칙이 이를 규정합니다.

데이터 셰이핑(Data shaping). 인터페이스는 가공되지 않은 레코드(raw records)가 아닌, 타입이 지정되고 제한된 데이터를 반환합니다. 만약 에이전트가 지원 워크플로(support workflow)를 위해 고객의 계정 상태가 필요하다면, Signal 계층은 결제 상세 정보, 이메일, 세션 기록이 포함된 전체 고객 행(row)을 반환하는 것이 아니라 {account_status: "active", tier: "enterprise"}를 반환합니다. 반환되지 않은 데이터는 유출되거나, 오용되거나, 적대적 페이로드(adversarial payload)로서 프롬프트에 주입될 수 없습니다.

Signal은 목적 지향적입니다. 즉, 해당 워크플로(workflow)에 에이전트가 필요로 하는 내용만을 포함하며 그 외의 것은 포함하지 않습니다. PII(개인식별정보) 전처리. 에이전트가 볼 정당한 이유가 없는 개인 데이터는 에이전트의 컨텍스트 윈도우(context window)에 도달하기 전에 제거되거나 가명 처리(pseudonymized)됩니다. 이는 인터페이스 수준에서의 강제 집행입니다. "고객의 이메일 주소를 반복하지 마십시오"라고 말하는 정책 지침은 행동 제약(behavioral constraint)입니다. 이는 이메일이 컨텍스트에 들어오는 것을 방지하는 것이 아니라, 단지 다시 언급되는 것을 방지할 뿐입니다. 출력에 이메일 필드를 포함하지 않는 Signal 레이어는 구조적으로 이를 방지합니다. 컨텍스트에 아예 존재하지 않았던 데이터를 추출할 수 있는 프롬프트 인젝션(prompt injection)은 존재할 수 없습니다. 설계에 의한 감사(Audit by construction). 모든 Signal 호출은 무엇이 요청되었는지, 무엇이 반환되었는지, 언제, 그리고 어떤 에이전트 실행이 이를 트리거했는지 로그로 기록됩니다. 이는 사후 재구성(post-hoc reconstruction)이 필요 없는 자연스러운 감사 추적(audit trail)을 생성합니다. 다단계 워크플로에서 Signal 로그는 에이전트가 각 결정 지점에서 정확히 어떤 정보를 가지고 있었는지 보여줍니다. 이는 사고 대응(incident response)에 필수적이며, EU AI Act 부속서 III(2027년 8월, EU Digital Omnibus 디지털 인프라 부속서 포함) 및 콜로라도 AI 법(SB 24-205)에 따른 규제 준수(regulatory compliance)를 위해 점점 더 요구되는 포렌식 기록입니다. 이렇게 구축된 Signal 레이어는 자연스러운 테스트 표면(test surface)도 제공합니다. 새로운 에이전트 버전은 운영 데이터(production data)를 건드리지 않고도 기록된 Signal 시퀀스에 대해 재현(replay)될 수 있습니다. 배포 전에 데이터 계약(data contract)이 탄력적인지 확인하기 위해 인터페이스 경계에서 적대적 입력(adversarial inputs)을 시뮬레이션할 수 있습니다.

도메인 레이어(Domain Layer) 설계하기
도메인 레이어는 실행 인터페이스(action interface)이며, 여기서의 설계 결정은 폭발 반경(blast radius)에 가장 직접적인 영향을 미칩니다. 명시적인 액션 열거(Explicit action enumeration). 도메인 레이어는 가능한 액션들을 나열합니다. 이는 하위 API의 모든 기능을 상속받지 않습니다. 만약 에이전트가 확인 이메일을 보내고 주문 상태를 업데이트할 권한이 있다면, 도메인이 노출하는 액션은 오직 그것들뿐입니다.

기저의 API가 계정 삭제, 비밀번호 재설정, 대량 데이터 내보내기를 지원한다는 사실은 중요하지 않습니다. 이러한 작업들은 도메인 (Domain)에 포함되어 있지 않으므로, 에이전트는 결코 해당 작업에 도달할 수 없습니다. 이는 범위가 지정된 자격 증명 (scoped credentials)과는 근본적으로 다릅니다. IAM 정책은 누가 무엇을 호출할 수 있는지를 제어하지만, 에이전트에게 제시되는 액션 표면 (action surface)을 제한하지는 않습니다.

범위 제한 작업 (Scope-bounded operations). 각 도메인 액션은 정의된 범위 (scope)를 가집니다. 주문 상태를 업데이트하는 액션은 오직 상태만을 업데이트할 수 있으며, 에이전트가 초기화될 때 부여된 고객 컨텍스트 (customer context)와 일치하는 주문에 대해서만, 그리고 정의된 유효한 상태 값 세트로만 업데이트할 수 있습니다. 이 범위는 런타임 (runtime) 시 에이전트의 행동으로부터 추론되는 것이 아니라, 인터페이스 (interface)에 인코딩되어 있습니다.

가역성 분류 (Reversibility classification). 도메인 액션은 가역성 (reversibility)에 따라 다음과 같이 분류됩니다: 읽기 전용 (read-only), 가역적 쓰기 (reversible write), 비가역적 쓰기 (irreversible write). 레코드를 삭제하거나, 결제를 시작하거나, 외부 통신을 보내거나, 인증을 수정하는 등의 비가역적 도메인 액션은 기본적으로 인간 참여 (human-in-the-loop) 확인을 필요로 합니다. 이는 에이전트의 의사결정을 늦추는 것이 아니라, 인터페이스 계층에서 실행을 제어 (gate)하는 것입니다. 에이전트가 제안하면, 도메인은 액션이 실행되기 전에 인간의 승인을 요구합니다. 이것이 시스템 설계 수준에서 적용된 최소 권한 원칙 (principle of least privilege)입니다.

자격 증명 범위 지정 (credential scoping)에만 의존하는 팀은 올바른 방향으로 가고 있지만, 잘못된 계층에서 작업하고 있는 것입니다. 자격 증명은 인증 주체 (authenticating principal)를 제한합니다. 도메인은 자격 증명이 어떻게 구성되어 있든 관계없이, 이를 호출하는 모든 에이전트에 대한 운영 표면 (operating surface)을 제한합니다.

Waxell의 처리 방식. Waxell 런타임 (runtime)은 Signal과 Domain 패턴을 일급 아키텍처 기능 (first-class architecture capability)으로 구현합니다. Signal-Domain 계층은 에이전트를 재구축하거나 재배포할 필요 없이, 어떤 데이터가 에이전트 컨텍스트 (agent context)에 들어오고 에이전트가 어떤 액션을 실행할 수 있는지를 제어하기 위한 관리된 인터페이스 (governed interface)를 제공합니다.

자체적으로 구축한 에이전트 팀의 경우, Waxell Runtime은 실행 경계(execution boundary)에서 45가지 정책 카테고리를 적용합니다. 여기에는 도구 호출(tool calls)로부터 반환되는 내용을 제어하는 데이터 셰이핑(data shaping) 정책, 액션 파라미터(action parameters)를 제한하는 범위 강제(scope enforcement) 정책, 그리고 파괴적인 작업에 대해 인간의 승인을 거치도록 차단하는 불가역성(irreversibility) 정책이 포함됩니다. 이러한 정책들은 에이전트 코드의 변경 없이도 모든 에이전트 실행에 걸쳐 런타임(runtime) 시점에 적용됩니다. 직접 구축하지 않은 에이전트들 — 벤더 플랫폼, 제3자 SaaS 통합, MCP 네이티브 에이전트 등 — 의 경우, Waxell Connect가 SDK나 코드 변경 없이 해당 에이전트들을 직접 관리합니다. Connect는 직접 구축하지 않은 에이전트들을 제한 없는 프로덕션 접근 권한을 가진 신뢰할 수 있는 주체(trusted principals)가 아니라, 제어된 인터페이스의 소비자(consumers)로 취급합니다. 팀이 에이전트 코드를 제어할 수 없는 상황에서 유지될 수 있는 다른 아키텍처적 위치는 없습니다. 이러한 결합은 팀이 직접 구축했든, 구매했든, 혹은 플러그인 생태계를 통해 배포했든 관계없이 시스템 내의 모든 에이전트에 대해 Signal과 Domain 경계가 일관되게 유지됨을 의미합니다. 관리되는 데이터 표면(data surface)은 인터페이스 수준에서 작동하므로, 관리되지 않는 동작을 단순히 권장하지 않는 수준을 넘어 구조적으로 불가능하게 만듭니다.

FAQ

Signal and Domain 패턴과 단순히 API 게이트웨이(API gateway)를 사용하는 것의 차이점은 무엇인가요?
API 게이트웨이는 누가 엔드포인트(endpoint)를 호출할 수 있는지 제어하고 속도 제한(rate limits)을 강제합니다. Signal and Domain은 어떤 데이터 형태(data shape)가 에이전트의 컨텍스트 윈도우(context window)에 도달하는지, 그리고 에이전트가 어떤 액션 표면(action surface)에서 작동할 수 있는지를 제어합니다. API를 완전히 노출한 API 게이트웨이는 여전히 에이전트에게 넓은 액션 표면을 제공합니다. 즉, 호출을 인증하기는 하지만 무엇을 호출할 수 있는지는 제한하지 않습니다. Signal and Domain은 표면 그 자체를 제한합니다. 이 둘은 상호 보완적이며 동일한 것이 아닙니다. 잘 설계된 시스템은 두 가지를 모두 사용합니다.

Signal and Domain 패턴을 사용하려면 에이전트를 다시 구축해야 하나요?
아니요. 이 패턴은 인터페이스 계층, 즉 에이전트 코드 자체가 아니라 에이전트가 호출하는 데이터 및 액션 표면에서 구현됩니다.

Waxell Runtime을 사용하는 팀의 경우, Signal 및 Domain 정책을 적용해도 에이전트에 새로운 종속성 (dependencies)이 추가되지 않으며 재배포 (redeployment)도 필요하지 않습니다. 기존 에이전트들은 관리되는 인터페이스 (governed interface)를 채택하게 되며, 인터페이스가 에이전트의 변경을 요구하지는 않습니다. Signal 계층은 연구 또는 분석 작업을 위해 광범위한 데이터 접근이 필요한 에이전트를 어떻게 처리할까요? 연구 또는 분석 에이전트의 경우, Signal 계층은 더 넓은 데이터 세트를 반환할 수 있지만, 여전히 타입이 지정되어 있고 (typed), 감사 가능하며 (auditable), 개인정보 (PII) 처리가 된 상태를 유지합니다. 핵심 원칙은 좁은 데이터가 아니라, 설계된 데이터 (designed data)입니다. 에이전트는 가공되지 않은 저장소 접근 (raw storage access) 대신 구조화되고 목적이 분명한 시그널 (signals)을 받습니다. 연구 에이전트를 위한 Domain 계층은 읽기 표면 (read surface)이 넓더라도, 쓰기 측면 (write side)에서는 그에 상응하게 좁아야 합니다. Signal 계층이 프롬프트 인젝션 (prompt injection)을 방어할 수 있을까요? 이는 공격 표면 (attack surface)을 크게 줄여줍니다. 프롬프트 인젝션은 일반적으로 에이전트가 검색하는 데이터에 적대적인 지침을 삽입함으로써 작동합니다. 즉, 오염된 문서...