AI 배포 과정에서 가장 최악의 순간은 계획되지 않은 발견이 일어날 때입니다. 운영을 시작한 지 6개월이 지났을 때, 어떤 에이전트(Agent)가 아무도 명시적으로 권한을 부여하지 않은 데이터베이스에 조용히 기록을 남기고 있었고, 이제 컴플라이언스(Compliance) 팀이 답변을 요구합니다. "그것이 그런 행동을 하는지 몰랐습니다"라는 말이 운영상의 후렴구가 되고, 생산성을 약속했던 에이전트는 갑자기 책임 소재(Liability)가 됩니다.

이것이 바로 AI 아키텍처(Architecture)에서의 동의 문제(Consent problem)입니다.

침묵하는 기본값 (The Silent Default)

대부분의 AI 시스템은 침묵하는 기본값(Silent defaults)과 함께 출시됩니다. Claude Code는 묻지 않고 메모리를 자동 저장합니다. Windsurf는 검토 단계(Review gate) 없이 메모리를 생성합니다. 도구들은 로깅(Logging)을 추가하고, 컨텍스트(Context)를 유지하며, 지식 베이스(Knowledge bases)를 자동 채웁니다. 이 모든 과정은 루프 내의 인간(Human in the loop)으로부터 명시적인 승인 없이 이루어집니다. 그 가정은 선의적입니다. 즉, 시스템을 더 유용하게 만들기 위해 빠르게 움직이는 것입니다.

하지만 실제 비즈니스를 지원하는 운영 시스템(Production systems)에서 동의 없는 속도는 비대칭성을 초래합니다. 시스템은 자신이 무엇을 하고 있는지 알지만, 여러분의 팀은 알지 못합니다.

이 격차는 멀티 에이전트 플릿(Multi-agent fleets)에서 더욱 심화됩니다. 10개의 스케줄링된 에이전트가 자율적인 워크플로우(Workflows)를 실행하며, 각 에이전트가 무엇을 저장할지, 누구에게 알릴지, 어떤 컨텍스트를 하류(Downstream)로 전달할지에 대해 결정을 내릴 때, 시스템 전체의 행동은 개별 에이전트가 하는 행동과는 급격히 달라집니다. 고립된 상태에서는 올바른 에이전트가 협업 시에는 문제가 될 수 있습니다. (저희는 Multi-Agent Coordination Using Shared Memory에서 조정 메커니즘(Coordination mechanics)을 다루었습니다.)

동의의 쐐기 (The Consent Wedge)

동의 우선 아키텍처(Consent-first architecture)는 이 가정을 뒤집습니다. "기본적으로 자동 기록하고, 나중에 허가를 구한다" 대신, 다음과 같은 패턴이 됩니다: 명시적인 승인 없이는 어떠한 상태 변이(State mutation)도 허용하지 않는다.

이것이 진행을 완전히 멈춰야 한다는 의미는 아닙니다. 이는 Tier 2 SRE 및 플랫폼 팀이 이미 효과적이라고 알고 있는 세 가지 관행을 체계화(Codifying)한다는 것을 의미합니다.

세션 수준의 동의 (Session-level consent)가 최우선입니다. 데이터가 영구 저장되기 전에, 사람 또는 지정된 승인 프로세스가 이 상호작용을 저장할지 여부를 확인합니다. 이는 일반적인 옵트아웃 (opt-out) 방식이 아니라, 세션별 게이트 (per-session gate) 방식입니다. 에이전트 (agents)의 경우, 결정 사항과 컨텍스트 (context) 기록은 영구 저장소 (durable store)에 도달하기 전에 검토할 수 있습니다. 이 게이트는 출처 메타데이터 (provenance metadata)를 통해 강화됩니다. 여기서 모든 저장된 사실은 그것이 어디에서 왔는지, 언제 기록되었는지, 그리고 어떤 인터페이스, 에이전트 또는 프로세스가 이를 캡처했는지를 함께 담고 있습니다. 이는 도구가 수행한 작업을 보여주는 도구 관점의 감사 로그 (audit logging)가 아닙니다. 이것은 데이터 계보 (data lineage)입니다. 사용자는 메모리를 보고 어떤 대화, 어떤 에이전트 실행, 어떤 컨텍스트가 이를 생성했는지 즉시 알 수 있습니다. 삭제의 동등성 (Deletion parity)은 이 루프를 완성합니다. 시스템이 메모리를 쓸 수 있다면, 사람도 똑같이 쉽게 이를 삭제할 수 있어야 합니다. 시스템 동작에 여전히 영향을 미치는 "보관됨" 상태나 소프트 삭제 (soft deletes) 없이, 삭제는 즉각적이고 완전해야 합니다. 이러한 대칭성은 최악의 실패 모드, 즉 제어하고 있다고 생각했던 시스템이 조용히 스스로를 조종하고 있다는 사실을 뒤늦게 발견하는 상황을 방지합니다.

이것이 중요한 이유

동의 우선 아키텍처 (Consent-first architecture)는 조용한 자동 저장 방식이 제공하지 못하는 네 가지 이점을 제공하며, 이는 운영 시스템 (production system)의 생애 주기 전반에 걸쳐 복합적인 효과를 발휘합니다.

가장 즉각적인 보상은 신뢰입니다. 팀은 상태 (state)가 감독 없이 축적되지 않는다는 것을 알게 됩니다. 즉, 메모리 (memory)는 양방향적이며, 시스템은 승인된 상호작용으로부터 학습하는 동시에 인간은 가시성 (visibility)을 유지합니다. 시스템이 무엇을 하고 있는지 이해하는 엔지니어는 창의성이 줄어드는 것이 아니라 오히려 더 창의적으로 변하며, 이러한 자신감은 유지율 (retention)과 함께 복리로 쌓입니다. 감사 가능성 (Auditability)은 자연스럽게 뒤따릅니다. 에이전트가 결정을 내렸을 때 문제가 발생하면, 해당 에이전트가 어떤 컨텍스트 (context)를 가졌는지, 그 컨텍스트가 어디서 왔는지, 언제 승인되었는지, 그리고 누가 그것을 확인했는지에 대한 완전한 그림을 가질 수 있습니다. 인과 관계의 사슬 (chain of causation)이 명시적이기 때문입니다. 금융 서비스나 의료와 같은 규제 산업 분야에서 이는 타협할 수 없는 필수 사항이지만, 순수 SaaS 분야에서도 이는 점점 더 기본 요건 (table stakes)이 되고 있습니다. 나중에 덧붙이는 것이 아니라 처음부터 이러한 관측성 계층 (observability layer)을 구축하는 것이 Instrumenting Your AI Agent Fleet의 주제입니다. 세 번째 이점은 우아한 성능 저하 (Graceful degradation)입니다. 동의 게이트 (consent gates)로 인해 속도가 느려진다면, 이는 진압해야 할 화재가 아니라 이해할 가치가 있는 확장성 문제 (scaling problem)를 발견한 것입니다. 승인 프로세스가 너무 느리거나 에이전트가 너무 빈번하게 승인을 요청하는 것일 수 있는데, 이는 아키텍처 (architecture)의 문제이지 게이트를 제거해야 할 이유는 아닙니다. 침묵하는 시스템은 발견 시점에 재앙적으로 실패하지만, 게이트가 있는 시스템은 가시적으로 실패하여 팀이 조치를 취할 수 있는 신호를 제공합니다. 마지막으로, 대부분의 에이전트가 침묵하는 기본값 (silent defaults)과 함께 출시되는 시장에서, 시스템이 무엇을 하는지 명시하고 실행 전에 허가를 구하는 것은 경쟁력 있는 신뢰 신호 (trust signal)가 됩니다. "우리는 귀하가 승인한 것만 저장하며, 모든 메모리가 어디서 왔는지 확인할 수 있습니다"라는 메시지는 "우리는 가장 강력한 메모리 계층을 보유하고 있습니다"라는 메시지보다 더 강력한 스토리입니다.

효과적인 패턴들

패턴 1: 메모리 엔벨로프 (The Memory Envelope)

상호작용으로부터 학습하는 에이전트의 경우, 각 상호작용을 영속화 (persistence)하기 전에 태그가 지정된 엔벨로프 (envelope)로 감싸야 합니다:

[상호작용 (interaction)] -> [컨텍스트 추출 (extract context)] -> [메모리 상태 제안 (propose memory state)] -> [승인 대기 (await approval)] -> [메타데이터와 함께 영속화 (persist with metadata)]

"메모리 상태 제안 (propose memory state)" 단계는 명시적입니다. 사람 또는 승인 워크플로 (approval workflow)는 다음과 같은 내용을 확인합니다: "이 상호작용은 컨텍스트 Z에 대해 Y에 관한 X를 저장할 것을 제안합니다." 만약 거부된다면, 아무것도 영속화되지 않습니다. 만약 승인된다면, 저장된 사실에는 승인 타임스탬프 (timestamp)와 이를 생성한 서피스 (surface) 또는 기술 (skill)이 포함됩니다.

패턴 2: 프로비넌스 인덱스 (The Provenance Index)

모든 지속 가능한 상태 (durable state)는 그 기원으로 돌아가는 포인터 (pointer)를 가집니다. 세션 메모리 (session memory)의 경우, 이는 어떤 서피스, 어떤 프로젝트, 어떤 기술이 이를 생성했는지를 의미합니다. 지식 저장소 (knowledge vaults)의 경우, 이는 어떤 파이프라인 (pipeline), 어떤 데이터 소스 (data source), 어떤 추출 단계 (extraction step)를 의미합니다. 에이전트 로그 (agent logs)의 경우, 이는 어떤 에이전트 실행 (agent run), 어떤 턴 (turn), 어떤 결정 (decision)을 의미합니다. 이 인덱스를 통해 삭제가 예측 가능해집니다: "이 에이전트 실행에서 생성된 모든 메모리 삭제"는 암시적 관계를 뒤지는 과정이 아니라 단일 작업이 됩니다.

패턴 3: 감사 우선 로그 (The Audit-First Log)

단순히 쓰기 (writes) 작업만 기록하는 것이 아니라, 승인 (approvals) 자체를 기록하십시오. 귀하의 감사 추적 (audit trail)은 시스템의 활동 로그가 아니라 결정 기록 (decision transcript)이어야 합니다:

[에이전트가 메모리 제안] -> [승인 결정 + 타임스탬프] -> [영속화 + 승인에 대한 역참조 (backref)]

승인된 제안과 거부된 제안 모두 기록됩니다. 누군가 "왜 이것을 저장하고 있습니까?"라고 묻는다면, 그 답은 타임스탬프를 역공학 (reverse-engineered)하는 것이 아니라 승인 기록에 들어 있습니다.

시스템이 제대로 작동하지 않는 경우

동의 우선 (Consent-first) 방식은 다음 세 가지 조건이 충족될 때 작동합니다: 승인 프로세스가 빠르고 (밀리초에서 한 자릿수 초 이내), 팀이 시스템이 무엇을 제안하고 있는지에 대해 진정한 가시성 (visibility)을 확보하고 있으며 (대시보드, 요약, 샘플링 등), 귀하의 컨텍스트에서 "동의 (consent)"가 무엇을 의미하는지에 대한 명확한 정의가 있을 때입니다. 즉, 그것이 사람의 클릭이든, 자동화된 게이트 (automated gate)이든, 또는 정책 엔진 (policy engine)이든 말입니다.

이러한 조건들이 위반될 때 모델은 무너집니다. 동의를 단순히 체크박스 처리(예: "향후 모든 상호작용을 승인하려면 여기를 클릭하세요")하는 것은 모델 전체의 핵심을 파괴합니다. 이는 실질적인 내용 없이 거버넌스(governance)가 있는 것처럼 보이게 할 뿐입니다. 승인 프로세스를 너무 느리게 만드는 것 또한 치명적입니다. 왜냐하면 시스템과 사용자는 느린 게이트(gate)를 우회하려 하며, 대개 이는 당신이 대체하려 했던 '침묵하는 기본값(silent defaults)'보다 감사(audit)하기 더 어려운 방식으로 이루어지기 때문입니다. 또한, 승인 프로세스를 팀에게 명확히 드러내지 못하면 동의는 체감되는 거버넌스가 아닌 보이지 않는 정책으로 전락합니다. 팀은 그것이 존재하는지조차 모르고, 신뢰하지 않으며, 결국에는 이를 비활성화하게 됩니다.

확장성 문제 (The Scaling Problem)

"하지만 이것이 처리량(throughput)을 저하시키지 않을까요?"라는 질문은 타당하며, 이에 대한 답은 대개 다음과 같습니다: "승인 프로세스가 잘못 설계되었을 경우에만 그렇습니다."

고빈도 작업(초당 수십 번 메모리를 읽는 에이전트)의 경우, 모든 읽기 작업에 대해 승인을 요청하지는 않습니다. 동의는 상태 변이(state mutations), 즉 쓰기(writes)와 삭제(deletes)에 관한 것입니다. 실행당 3개의 새로운 메모리를 제안하고 한 시간에 한 번 실행되는 에이전트에게 승인 게이트는 병목 현상(bottleneck)이 아닙니다.

낮은 지연 시간(low-latency) 요구 사항(실시간 API 에이전트)의 경우, 승인 게이트를 정책 엔진(policy engine)으로 통합합니다: "에이전트는 인간의 승인 없이 컨텍스트 Y 내에서 유형 X의 메모리를 자동 저장할 수 있다; 그 외의 모든 쓰기는 명시적 승인이 필요하다." 여기서 정책이 곧 동의 메커니즘이 됩니다.

결론 (Bringing It Home)

침묵하는 기본값에서 동의 우선(consent-first) 방식으로의 전환은 단순한 기능(feature)이 아닙니다. 그것은 거버넌스에 대한 입장입니다. 즉, 시스템이 당신을 위해 작동하는 것이지, 그 반대가 아니라는 점입니다.

먼저 출시하고 질문은 전혀 하지 않는 에이전트들이 포화된 시장에서, 상태(state)에 대해 의도적으로 투명성을 유지하는 것(무엇을 저장하는지, 어디서 왔는지, 어떻게 삭제하는지)은 당신의 경쟁 우위가 됩니다. 시스템이 조용히 결정을 내리기 시작하면 팀은 불안해합니다. 동의 우선 방식은 팀이 평온함을 유지하며, 창의성을 발휘하고, 통제권을 가질 수 있게 해줍니다.

만약 조직으로부터 신뢰를 얻어야 하는 멀티 에이전트 시스템 (multi-agent systems)을 구축하고 있다면, 동의 아키텍처 (consent architecture)는 부가적인 부담이 아닙니다. 그것은 인프라 (infrastructure)입니다.

귀사의 조직을 위한 동의 우선 AI 시스템을 구축할 준비가 되셨나요? Labyrinth Analytics는 데이터 팀이 첫날부터 감사 가능하고 (auditable), 투명하며 (transparent), 신뢰할 수 있는 (trustworthy) 에이전트 함대 (agent fleets)를 설계할 수 있도록 지원합니다. 귀사의 활용 사례에 대해 이야기해 봅시다.