PrepStack에 처음 게시되었습니다. 이것은 기업용 AI를 위한 컨텍스트 엔지니어링(Context Engineering for Enterprise AI)의 파트 6 (최종장)입니다.

파트 1~5는 멀티 테넌트(multi-tenant) 마케팅 분석 SaaS인 Mattrx(110k MAU, 약 9,000개 테넌트, 피크 시 약 3,200 req/sec, Azure SQL 기반의 ASP.NET Core / .NET 9 및 Python FastAPI AI 서비스)를 위한 역량을 구축했습니다. 즉, 예산이 책정된 컨텍스트 윈도우(context window), 메모리 레이어(memory layer), 멀티 에이전트 오케스트레이션(multi-agent orchestration), 엔터프라이즈 디자인 스파인(enterprise design spine), 그리고 멀티 테넌트 격리(multi-tenant isolation)를 구축했습니다. 이번 파트는 이 모든 것의 아래에 있는 레이어, 즉 _어떤 데이터가, 누구에게, 어떤 목적으로 컨텍스트에 들어오거나 나가는 것이 허용되는지_를 결정하는 제어 평면(control plane)입니다. 거버넌스(governance)가 없는 역량은 침해 사고를 기다리는 위반 사항일 뿐입니다.

요약 (TL;DR)

거버넌스는 체크리스트가 아니라 제어 평면(control plane)입니다. 다섯 가지 통제 항목이 컨텍스트에 들어오거나 나갈 수 있는 것을 결정하며, 각 항목은 데이터 침해가 발생한 후가 아니라 모델이 데이터를 보기 _전_에 집행됩니다:

• 관리되지 않은 상태로 공유 임베딩 저장소(shared embedding store)에 도달하는 기밀/제한(Confidential/Restricted) 문서: ~3,100개 -> 0개.
• 테넌트 내부 원칙 간 유출(Intra-tenant cross-principal leaks) (예: 지원 에이전트가 자신의 테넌트 내부에 있는 재무 문서를 검색하는 경우), 레드팀(red-team) 테스트: 재현 가능성 -> 0.
• "모델이 대상 X에 대해 무엇을 보았으며, 왜 허용되었는가?": 생성 결과의 0% -> 100% 답변 가능; 데이터 주체 접근 권리(DSAR) 이행 시간 ~2일 -> 3분 미만 (단일 쿼리).
• 동의된 목적 없이 평가/미세 조정(fine-tuning)에 사용되는 고객 데이터: 무제한 -> 0.
• 거버넌스 강제 적용: ~14개의 분산된 사이트 -> 1개의 정책 결정 지점(PDP) + N개의 버전 관리된 정책; 서비스 코드 수정 없이 정책 변경 배포 가능.
• 핫 패스(hot path)에서의 거버넌스 오버헤드: +4 ms p95 (PDP 결정 ~3 ms 캐싱됨, 기본 거부(deny-by-default) 방식). 검색(Retrieval) p95 31 ms -> 35 ms, recall@5 0.94 유지; 쿼리당 비용 $0.008 (변동 없음).

단 하나의 사고방식 전환

거버넌스는 사고가 발생한 후에 생성하는 보고서가 아니라, 검색(retrieval) 전에 실행되는 제어 평면(control plane)입니다. 모든 데이터 접근을 하나의 질문 — can(주체, 데이터, 목적, 컨텍스트)? — 으로 만드세요. 이 질문은 하나의 엔진에 의해 기본 거부(deny-by-default) 방식으로 답변되고 기록되어야 합니다. 그래야만 "이것이 유출될 수 있었는가?"라는 질문에 대한 답이 기도가 아닌 쿼리(query)가 될 수 있습니다.

1. 수집 시 분류: 라벨을 붙이지 않은 것은 관리할 수 없다

이전: 테넌트가 연결한 모든 것은 도착하는 즉시 임베딩되었습니다. 민감도 라벨도, 목적도 없었습니다. "지식 베이스(knowledge base)" 동기화 과정에서 고객 이메일이 담긴 스프레드시트와 API 토큰 파일이 벡터화될 수 있었으며, 이제는 어떤 프롬프트에서도 코사인 유사도(cosine similarity) 한 번의 거리 안에 놓이게 되었습니다.

이후: 수집(ingestion) 단계에서 **분류 게이트(classify gate)**가 작동합니다. 모든 자산은 민감도 등급(Public / Internal / Confidential / Restricted)과 목적 태그(purpose tags)를 부여받고 데이터 카탈로그(Data Catalog)에 등록된 후에 라우팅됩니다. Public/Internal은 풀 인덱스(pool index)로, Confidential은 제한된 인덱스(restricted index)로 라우팅되며, Restricted는 카탈로그에 기록된 후 격리(quarantined)되며, 임베딩(embedding)조차 되지 않습니다. 저비용의 결정론적 탐지기(비밀번호 및 개인정보(PII)를 위한 regex/Presidio)가 먼저 실행되며, LLM 분류기는 모호한 나머지 항목만을 처리합니다. 입구에서 분류를 수행한다는 것은, 다운스트림(downstream)에서 필터가 누락되더라도 인덱싱되지 않은 데이터가 노출될 수 없음을 의미합니다. 이 게이트를 통해 약 3,100개의 민감한 문서가 공유 저장소에서 제외되었습니다 (0.4%의 과잉 격리율, 인간 검토 완료).

2. 권한 인식 검색(Entitlement-aware retrieval): 테넌트(tenant)뿐만 아니라 주체(principal)를 인증하라

파트 5에서는 검색을 테넌트(tenant) 범위로 제한했습니다. 하지만 테넌트 내부에서는 해당 테넌트가 소유한 것이라면 누구에게나 검색 결과로 반환되었습니다. 예를 들어, 지원 에이전트가 매출 운영 매뉴얼(revenue runbook)을 가져올 수도 있었습니다. 이를 해결하기 위해 테넌트 조건(predicate) 위에 주체(principal) 조건(사용자의 그룹/승인 등급)을 쌓아 올리며, 두 조건이 동시에 적용됩니다. Mattrx는 하이브리드(hybrid) 방식을 실행합니다. 인덱스 내에서 빠른 ACL 필터를 먼저 적용한 다음, 살아남은 상위 k개(top-k) 항목에 대해 권한 서비스(entitlements service)를 통해 실시간 재검증을 수행합니다. 이를 통해 방금 취소된 권한이 오래된 인덱스(stale index)를 통해 유출되는 것을 방지합니다. 테넌트 내 역할 간(intra-tenant cross-role) 유출은 재현 가능한 수준에서 0으로 감소했으며, recall@5는 0.94를 유지하면서 p95 지연 시간은 4ms 증가했습니다.

3. 동의 및 목적 제한: 보유할 권한이 있다고 해서 사용할 권한이 있는 것은 아니다

Mattrx가 데이터를 저장했다면, 모든 기능(feature)은 이를 검색(retrieval), 에이전트 분석(agent analysis), 평가(eval), 미세 조정(fine-tuning) 등 자유롭게 사용할 수 있는 대상으로 취급했습니다. 하지만 "고객의 캠페인을 실행하기 위해 이 데이터를 보유한다"는 것이 "우리 제품을 개선하기 위해 사용한다"는 것에 대한 동의는 아닙니다. 모든 자산에는 **목적 태그(purpose tags)**가 부여되며, **동의 레지스트리(consent registry)**는 각 테넌트(tenant)가 무엇에 동의했는지 기록합니다. 각 AI 사용은 그 목적(serve / eval / train)을 명시하며, 개인정보 보호 정책 엔진(PDP)은 해당 목적이 포함되지 않은 데이터의 접근을 거부합니다. 옵트아웃(Opt-out) 테넌트는 자신의 기능은 온전히 제공받으면서도, 평가(eval) 및 학습(train) 과정에서는 구조적으로 제외됩니다. 동의된 목적 없이 사용된 고객 데이터는 → 0이 되었습니다.

4. 계보(Lineage) 및 출처(Provenance): 모델이 무엇을 보았는지 정확히 증명하라

DSAR("당신의 AI는 나에 대해 무엇을 알고 있으며, 그 정보는 어디에서 왔습니까?")은 과거에는 상태가 없는(stateless) 로그를 며칠 동안 뒤져야 하는 작업이었습니다. 이제는 모든 생성(generation) 시점에 하나의 **추가 전용 계보 기록(append-only lineage record)**을 작성합니다. 여기에는 출력 해시(output hash), 프롬프트에 입력된 정확한 소스 자산(id, 버전, 클래스), 주체(principal), 선언된 목적, 그리고 각 소스를 허용한 PDP 결정 사항이 포함됩니다. 이는 **원시 콘텐츠가 아닌 참조와 버전(references and versions)**을 저장하므로(따라서 감사 추적(audit trail)이 민감한 데이터의 복사본이 되지 않음), 해당 테이블에는 UPDATE/DELETE 권한이 부여되지 않으며, 쓰기 작업은 핫 패스(hot path)를 벗어나 수행됩니다. 출처(Provenance) 커버리지는 **0% → 100%**로 향상되었으며, DSAR 처리 시간은 약 2일 → 3분 미만으로 단축되었습니다.

5. 코드로서의 정책(Policy-as-code): 모든 요청이 따르는 단일 결정 지점

위에서 언급한 각 규칙(그리고 파트 2/4/5의 규칙들)은 각자의 서비스 내에서 개별적인 if 문으로 존재했습니다. 약 14개의 집행 지점(enforcement sites)이 있었고, "허용됨"에 대한 네 가지의 서로 다른 방언이 존재했으며, 중앙에서 읽거나 테스트하거나 변경할 수 있는 것이 아무것도 없었습니다. 드리프트(Drift, 괴리)는 불가피했습니다. 해결책은 다음과 같습니다. can(principal, data, purpose, context)?라는 질문에 답하는 단일 **정책 결정 지점 (Policy Decision Point, PDP)**을 구축하고, 기본 거부 (deny-by-default) 원칙을 적용하며, 규칙을 버전 관리되고 단위 테스트(unit-tested)가 가능한 **코드로서의 정책 (Policy-as-code)**으로 관리하는 것입니다 (Mattrx는 OPA/Rego를 사이드카(sidecar)로 실행합니다). 데이터 수집(Ingest), 검색(retrieval), 출력(output), 그리고 에이전트 도구(agent tools)는 모두 동일한 PDP에 요청합니다. 모든 결정은 캐싱되어 (~3 ms) 기록되며 리니지(lineage, 계보)에 저장됩니다. PDP는 실패 시 폐쇄 (fails closed) 방식으로 작동합니다. 즉, 장애가 발생하면 접근을 허용하는 대신 차단하며, 이는 거버넌스 측면에서 올바른 실패 모드(failure mode)입니다 (동시에 설계 시 고려해야 할 실제 가용성 결합(availability coupling)이기도 합니다).

솔직한 이야기

• 거버넌스는 보여주기식 행위(theater)가 될 수 있습니다 — 아무도 신뢰하지 않는 카탈로그와 아무도 테스트하지 않는 정책은 거짓된 확신을 만들어냅니다. PDP가 신뢰를 얻는 이유는 정책이 CI에서 단위 테스트되고 그 결정이 기록되기 때문입니다.
• 분류(Classification)는 확률적입니다 — 실패의 범위를 제한하고 검토 가능하게 만드십시오 (모든 자산은 카탈로그 행을 가져야 함). 그리고 인간을 격리 큐(quarantine queue)에 배치하십시오.
• PDP는 가용성 결합(availability coupling)입니다 — 기본 거부(deny-by-default) 원칙은 PDP를 티어-1 종속성(tier-1 dependency)으로 만듭니다 (사이드카, 상태 확인(health checks), 캐싱된 결정 필요).
• 삭제할 수 있는 것은 분류하지 마십시오 — 최소화(minimization)가 거버넌스보다 강력합니다. 거버넌스 비용이 가장 적게 드는 데이터는 아예 보관하지 않은 데이터입니다.

마무리 멘탈 모델 (Mental Model)

현관문에서 거버넌스를 수행하십시오 (데이터가 임베딩되기 전에 분류하고 결정하십시오). 하나의 엔진에 묻고, 기본적으로 거부하십시오 (모든 경로가 동일한 PDP에 물어야 합니다. 만약 새로운 경로가 묻지 않는다면, 그것은 보안 홀(hole)입니다). 증명할 수 있도록 기록하십시오 (추가 전용(append-only) 리니지는 "우리 말을 믿으세요"를 "여기 쿼리 결과가 있습니다"로 바꿔줍니다). 만약 모델이 무엇을 보았고 왜 그것이 허용되었는지 재구성할 수 없다면, 당신은 거버넌스를 가진 것이 아니라 그저 희망 사항을 가지고 있는 것입니다.

👉 전체 기사 — 모든 C# (.NET 9), Python, OPA/Rego, SQL 코드, 컨트롤 플레인 (control-plane) 다이어그램, 출시 전 체크리스트, 그리고 모든 "솔직한 내용"이 포함된 전체 내용은 PrepStack에서 확인하실 수 있습니다:
기업용 AI를 위한 컨텍스트 엔지니어링 (Context Engineering), 파트 6