누락된 컨텍스트 평면(Context Plane): 왜 기업 데이터 아키텍처에 AI 에이전트를 위한 세 번째 레이어가 필요한가

당신의 데이터 스택은 설계된 대로 정확히 작동하고 있습니다 — 하지만 왜 당신의 AI 에이전트는 계속 실패하는가

데이터 웨어하우스 (Data Warehouse)는 고장 나지 않았습니다.
변환 레이어 (Transformation layer)는 제 역할을 다하고 있습니다.
대시보드 (Dashboards)는 정확합니다.
하지만 당신의 AI 에이전트는 숙련된 분석가라면 움찔할 만한 결정을 여전히 내리고 있습니다.

여기 불편한 진실이 있습니다. 당신의 데이터 스택이 수행하도록 설계된 모든 일은 아주 잘 해내고 있습니다. 문제는 이 스택이 다른 독자, 즉 '사람'을 위해 구축되었다는 점입니다. 그리고 그 독자를 자율 에이전트 (Autonomous agent)로 교체할 때, 인간이 판단력, 조직적 기억, 그리고 컨텍스트 (Context)를 통해 조용히 메워왔던 공백들이 치명적인 실패 지점이 됩니다.

스택이 실제로 구축된 목적

지난 10년 동안 데이터 아키텍처 (Data architecture) 워크플로우는 다음과 같았습니다:

Raw Sources → Ingestion → Warehouse → dbt Transform → Metrics Layer → Dashboard → Human Analyst

마지막 화살표는 우리가 명시적으로 드러낼 필요가 없었던 방식으로 시스템을 지탱하고 있습니다.

인간 분석가는 그 어떤 파이프라인도 제공할 수 없는 것, 즉 비즈니스 컨텍스트 (Business context)를 가져왔습니다. 그들은 지표가 왜 변했는지 알고 있었습니다 — 가격 실험 때문인지, 대규모 고객 이탈 때문인지, 혹은 평균을 왜곡시킨 일회성 대량 주문 때문인지를 말입니다. 그들은 어떤 대시보드가 표준(Canonical)인지, 그리고 재무 팀이 서로 다른 정의를 사용하여 비밀리에 유지 관리하는 대시보드는 무엇인지 알고 있었습니다. 어떤 정책이 전략적 계정을 위해 유연하게 적용될 수 있는지, 어떤 예외 사항이 법무 팀으로부터 사전 승인을 받았는지도 알고 있었습니다.

그 중 어떤 것도 웨어하우스 (Warehouse)에 존재하지 않았습니다. 그것은 사람, Slack 스레드, 일대일 대화, 그리고 온보딩 (Onboarding)과 삼투압 현상을 통해 전달되는 조직적 근육 기억 (Organizational muscle memory) 속에 존재했습니다.

AI 에이전트는 온보딩을 거치지 않습니다.

에이전트가 탐색할 수 없는 이음새

현대의 기업 데이터 스택은 사실 서로 결합된 전문 도구들의 집합체입니다:

Ingestion (수집): Fivetran, Airbyte
Storage (저장): Snowflake, BigQuery, Databricks
Transformation (변환): dbt
Metrics layer (메트릭 레이어): MetricFlow, Cube
Data catalog (데이터 카탈로그): Alation, Collibra, Atlan
Governance (거버넌스): 다양함
Observability (관측성): Monte Carlo, Great Expectations
BI (비즈니스 인텔리전스): Tableau, Looker, Power BI

각 도구는 자신의 역할에 충실합니다. 하지만 이들이 모이면 '이음새(seams)'가 발생합니다. 인간은 어떤 시스템의 어떤 필드가 "진짜"인지, 혹은 "활성 고객(active customer)"의 정의가 2023년 3분기에 변경되어 이전 보고서에는 소급 적용되지 않았다는 사실을 인지함으로써 이러한 이음새를 보이지 않게 탐색하는 법을 배웠습니다.

AI 에이전트가 메트릭을 쿼리할 때, 에이전트는 숫자만을 얻습니다. 다음과 같은 정보는 얻지 못합니다:

해당 숫자가 어떻게 계산되었는지에 대한 계보 (Lineage)
정의의 수정 이력 (Definition revision history)
엔터프라이즈(Enterprise) 등급 고객을 위해 마련된 예외 사항
해당 데이터를 언제 신뢰해야 하는지, 혹은 언제 더 깊이 파고들어야 하는지에 대한 운영적 판단

에이전트는 데이터를 봅니다. 하지만 데이터를 안전하게 실행할 수 있게 해주는 지도(map)는 보지 못합니다.

에이전트 쿼리 → 데이터 반환 → [GAP: 누락된 컨텍스트, 정책, 메모리] → 의사결정 수행

그 간극(gap)에서 잘못된 권장 사항이 발생합니다.

컨텍스트 없는 거버넌스는 거버넌스가 아니다

이 부분이 대부분의 팀을 당황하게 만드는 지점입니다.

전통적인 거버넌스 스택은 이 문제를 레이어링(layering)의 문제로 취급합니다. 여기에 권한을 두고, 저기에 계보를 두며, 비즈니스 글로서리(business glossary)를 다른 곳에 배치한 뒤 통합(integration)을 통해 이들을 연결합니다. 이러한 산출물(artifacts)들을 결합하면 거버넌스가 적용된 데이터가 생성될 것이라고 가정하는 것입니다.

그렇지 않습니다.

거버넌스는 규칙이 아닙니다. 거버넌스는 규칙이 컨텍스트 내에서(in context) 어떻게 적용될지를 결정하는 행위입니다.

가격 정책은 특정 전략적 고객, 파트너 관계, 또는 특정 캠페인 기간 동안 적용되지 않을 수 있습니다. 승인 체인은 이를 재량으로 변경할 수 있는 사람이 이미 구두로 승인했고 그 예외 사항이 구조화된 곳 어디에도 기록되지 않았다면, 그 체인은 더 이상 유효하지 않습니다.

그러한 예외 사항들은 단순한 예외 사례(edge cases)가 아닙니다. 그것들은 조직의 실제 판단, 권한, 그리고 제도적 지식(institutional knowledge)이 실제로 존재하는 매우 중요한 부분을 나타냅니다. 만약 그 판단이 오직 Slack 스레드나 이메일 체인에만 존재한다면, 문서화된 규칙을 따르는 AI 에이전트는 기술적으로는 준수(compliant)하면서도 운영상으로는 틀린 상태가 될 수 있습니다.

기업의 메모리 격차 (The Enterprise Memory Gap)

여기에 전통적인 스택이 거의 완전히 무시하고 있는 차원이 있습니다. 바로 _추론 메모리(reasoning memory)_입니다.

현대적인 데이터 스택은 산출물(artifacts)을 저장하는 데는 매우 뛰어납니다:

테이블 (Tables) ✓
대시보드 (Dashboards) ✓
로그 (Logs) ✓
지표 (Metrics) ✓

하지만 그것들을 만들어낸 추론 과정을 보존하는 데는 취약합니다:

왜 이 정의가 변경되었는가?
누가 이 예외를 승인했으며 그 이유는 무엇인가?
우리가 이와 같은 유형의 결정을 내렸던 마지막 때는 어떤 일이 있었는가?
어떤 트레이드오프(tradeoff)가 어떤 제약 조건 하에 수용되었는가?

인간 팀의 경우, 이는 그리 큰 문제가 되지 않습니다. 사람들은 동료에게 물어보거나, 예전 회의록을 찾아보거나, 혹은 부족 지식(tribal knowledge)에 의존하면 됩니다. 그 비용은 마찰과 가끔 발생하는 실수 정도입니다. 하지만 대규모로 작동하는 AI 에이전트에게 이것은 구조적인 실패입니다. 추론 이력에 접근할 수 없는 에이전트는 이전에 내려졌고 거부되었던 결정을 다시 도출하고, 과거의 실수를 반복하며, 이전의 경험을 통해 어렵게 얻어낸 제약 조건들을 놓치게 될 것입니다.

인간의 의사결정 프로세스 (Human Decision Process):
  [데이터 (Data)] + [정책 (Policy)] + [과거 결정의 메모리 (Memory of Past Decisions)] + [맥락적 판단 (Contextual Judgment)] → 행동 (Action)

...

검색 증강(Retrieval-augmented) 방식은 비정형 소스에서 파편들을 가져올 수 있지만, 이는 취약(brittle)합니다. Slack 메시지와 Confluence 문서에 대한 시맨틱 검색(semantic search)은 에이전트가 확신을 가지고 쿼리할 수 있는 구조화된 메모리 레이어와는 다릅니다.

아키텍처의 변화: 컨텍스트 평면(Context Plane)의 추가

이러한 분석을 통해 도출되는 프레임워크는 3개 평면 아키텍처(three-plane architecture)입니다:

┌─────────────────────────────────────────────────┐
│                  컨텍스트 평면 (CONTEXT PLANE)                  │
│  시맨틱 모델 (Semantic models) · 정책 (Policies) · 메모리 (Memory) · 예외 (Exceptions)│
...

데이터 평면(data plane)은 현재 가지고 있는 것입니다. 제어 평면(control plane)은 인증(auth)과 오케스트레이션(orchestration)을 처리합니다. 컨텍스트 평면(context plane)이 바로 빠져있는 부분입니다.

컨텍스트 평면은 기존 스택에 단순히 붙이는 검색 인덱스가 아닙니다. 다음 조건을 충족해야 합니다:

작업이 일어날 때 생성됨 — 사후적으로 재구성되는 것이 아니라, 의사결정 지점에서 컨텍스트가 포착되어야 합니다.
데이터와 함께 거버넌스됨 — 데이터 자체만큼 엄격하게 관리되어야 합니다.
에이전트에 의해 쿼리 가능함 — 단순히 확률적으로 검색되는 것이 아니라, 에이전트가 확신을 가지고 검색할 수 있도록 충분히 구조화되어야 합니다.
지속적으로 업데이트됨 — 비즈니스 컨텍스트는 비즈니스가 변화하는 속도만큼 빠르게 변하기 때문입니다. 이 모든 것을 처음부터 구축하는 것은 어렵습니다. 대부분의 기업에게 실용적인 경로는 진화적일 것입니다. 에이전트가 행동할 것으로 예상되는 워크플로우를 식별하고, 해당 워크플로우에 필요한 컨텍스트와 거버넌스를 매핑한 다음, 구조화된 데이터, 비정형 지식(unstructured knowledge), 정책(policies), 메모리(memory), 오케스트레이션 등을 점진적으로 통합할 수 있는 AI 준비가 된 컨텍스트 레이어를 추가하는 것입니다.

실제에서 '컨텍스트 기반'이 의미하는 것

'데이터 기반(data-driven)'에서 '컨텍스트 기반(context-driven)'으로의 전환은 마케팅 용어가 아닙니다. 이는 에이전트 시스템을 설계하는 방식에 구체적으로 나타나는 아키텍처적 요구사항입니다.

데이터 기반 에이전트는 숫자 하나를 받아서 그 숫자에 따라 행동합니다.

컨텍스트 기반 에이전트는 숫자와 더불어 다음을 받습니다:

해당 지표의 의미론적 정의(semantic definition)
어떻게 계산되었는지 보여주는 계보(lineage)
어떤 행동이 허용되는지 통제하는 정책(policies)
현재 상황에 적용되는 예외 사항(exceptions)
비슷한 상황을 이전에 어떻게 처리했는지에 대한 메모리(memory)
데이터의 신선도와 신뢰성에 대한 확신 신호(confidence signal)

인터페이스가 SELECT metric FROM table에서 비즈니스 컨텍스트 API에 훨씬 가까운 형태로 바뀝니다:

context = get_business_context(
    metric="revenue",
    customer_tier="enterprise",
...

이것은 오늘날 대부분의 팀들이 하고 있는 것과는 다른 아키텍처적 베팅입니다.

핵심 요약

데이터 스택은 인간의 해석에 최적화되어 왔습니다 — 설계된 대로 작동하고 있지만, 독자가 바뀌었습니다. AI 에이전트는 인간이 데이터를 안전하게 탐색할 때 사용하는 암묵적인 지도(tacit map)를 물려받지 못합니다.
도구 사이의 이음새(seams)에서 에이전트가 실패합니다 — 한 곳에는 권한(permissions)이 있고, 다른 곳에는 정의(definitions)가 있으며, 예외 사항은 Slack 스레드에 흩어져 있습니다. 인간은 이를 보이지 않게 탐색하지만, 에이전트는 여기서 큰 벽에 부딪힙니다.
거버넌스(Governance)는 규칙 기반이 아닌 맥락 기반이어야 합니다 — 스스로의 예외 사항을 표현할 수 없는 규칙은 대규모로 작동하는 에이전트에게 충분하지 않습니다.
추론 메모리(Reasoning memory)가 누락된 레이어입니다 — 산출물(artifacts, 예: 테이블, 대시보드)을 저장하는 것은 결정을 내린 추론 과정을 보존하는 것과 같지 않습니다.
차세대 데이터 아키텍처는 컨텍스트 평면(context plane)을 추가합니다 — 데이터 평면(data plane) 및 제어 평면(control plane)과 함께 시맨틱 모델(semantic models), 정책(policies), 메모리(memory), 그리고 거버넌스가 적용된 추론(governed reasoning)을 위한 일급 레이어(first-class layer)를 구축합니다.

토론할 가치가 있는 질문

만약 컨텍스트가 "작업이 진행되는 동안 생성되어야" 한다면 — 즉, 결정이 내려지는 시점에 포착되어야 한다면 — 그 소유권은 누구에게 있을까요? 데이터 엔지니어링(Data engineering) 팀일까요? 결정을 내리는 도메인(domain) 팀일까요? 아니면 에이전트 인프라를 구축하는 플랫폼(platform) 팀일까요?

대부분의 조직은 아직 명확한 답을 내놓지 못하고 있습니다. 그리고 명확한 답을 얻기 전까지, 에이전트는 기술적으로는 옳지만 운영상으로는 틀린 결정을 계속 내릴 것입니다.

여러분의 팀은 이 문제에 대해 어느 단계에 있습니까? 컨텍스트 레이어(context layer)를 구축하고 있습니까, RAG로 임시방편(patching)을 마련하고 있습니까, 아니면 여전히 데이터 웨어하우스(warehouse)만으로 충분하기를 바라고 있습니까?