Semantic Layer vs MCP: 왜 직접적인 ERP 쓰기 권한(Write Access)이 기업 보안 리스크인가

⚠️ 실패 모드 (Failure Mode): MCP가 LLM을 기업 시스템에 직접 연결할 수 있는 능력을 찬양하는 대부분의 아키텍트들은 매우 중요한 질문을 놓치고 있습니다. 즉, 프롬프트(prompt)가 악의적일 경우 어떤 일이 벌어질까요? 정교하게 설계된 지시 사항 하나가 경보도, 게이트(gate)도, 인간의 검토도 없이 여러분의 ERP에 대해 실제 쓰기 작업(write operation)을 실행할 수 있습니다.

기업용 AI 커뮤니티는 MCP (Model Context Protocol)를 사용하여 대규모 언어 모델 (LLM)을 핵심 비즈니스 시스템에 직접 연결하기 위해 빠르게 움직이고 있습니다. 이러한 열정은 이해할 수 있습니다. 하지만 리스크는 무시되고 있습니다. 이 포스트는 시맨틱 레이어 (semantic layer)와 MCP 사이의 아키텍처 경계를 분석하고, 공격 표면 (attack surface)이 어디에서 열리는지 보여주며, 쓰기 권한 (write access)에 접근하기 전에 모든 기업용 AI 시스템이 갖춰야 할 거버넌스 레이어 (governance layer)를 정의합니다.

시맨틱 레이어 (semantic layer)는 안전합니다 — 하지만 읽기 전용(read-only)입니다

시맨틱 레이어는 LLM과 데이터 사이에 위치합니다. 이는 큐레이션된, 권한을 인식하는 모델 — 지표 (metrics), 차원 (dimensions), KPI — 만을 노출하며 그 외의 것은 노출하지 않습니다. LLM은 이를 자유롭게 쿼리(query)할 수 있는데, 최악의 결과가 이미 볼 권한이 있는 데이터를 읽는 것이기 때문입니다. 역할 기반 권한 (Role-based permissions)은 시맨틱 레이어에서 강제됩니다. 데이터 모델은 정의되고 제어됩니다. 어떠한 실수의 폭발 반경 (blast radius)도 잘못된 쿼리 결과로 제한됩니다.

한계점은 근본적입니다. 시맨틱 레이어는 설계 단계부터 읽기 전용 (read-only)입니다. AI가 행동을 취해야 하는 순간 — 레코드 업데이트, 워크플로 (workflow) 트리거, 가격 수정, 구매 주문 승인 등 — 쓰기 권한 (write access)이 필요하게 됩니다. 바로 그 지점에서 MCP가 등장합니다.

MCP는 쓰기 권한 (write access)을 가능하게 합니다 — 그리고 그것이 모든 것을 바꿉니다

MCP 서버는 실제 기업 시스템에 대해 실질적인 운영(operations)을 실행할 수 있습니다. 그 강력한 권한은 곧 리스크이기도 합니다. 정교하게 설계된 프롬프트 인젝션 (prompt injection)을 처리하는 LLM은 악의적인 의도를 가진 완벽하게 유효한 MCP 도구 호출 (tool call)을 생성할 수 있습니다. 거버넌스 계층 (governance layer)이 없다면, 해당 명령은 검증도, 사람의 검토도, 감사 추적 (audit trail)도 없이 귀사의 ERP로 직행하게 됩니다.

실제 사례:

고객용 AI 어시스턴트에 프롬프트가 인젝션됨
인젝션된 명령이 LLM에게 모든 제품 카탈로그 가격을 $0.00로 설정하도록 지시함
MCP 서버가 유효한 update_product_price 도구 호출을 수신함
ERP가 이를 실행함. 아무런 경보도 울리지 않음.
누군가 알아차렸을 때는 이미 수천 건의 주문이 0원 가격으로 완료된 상태임

모든 MCP 쓰기 경로에 필요한 세 가지 계층

기업 시스템의 쓰기 작업 (write operation)에 관여하는 모든 MCP 도구 호출은 실행 전 반드시 세 가지 거버넌스 통제 (governance controls)를 통과해야 합니다.

1. 프롬프트 검증 계층 (Prompt validation layer)

쓰기 의도가 MCP 서버에 도달하기 전에, LLM과는 독립적으로 명령을 검증해야 합니다. 다음 사항을 확인하십시오: 이 동작이 사용자가 명시한 목표와 일치하는가? 범위 (scope)가 예상된 경계 내에 있는가? 파라미터 (parameter) 값이 허용 가능한 범위 내에 있는가? 예상 범위를 벗어나는 모든 것은 더 진행되기 전에 플래그를 지정하고 차단하십시오.

🔒 보안 패턴 (Security Pattern): 프롬프트 검증 계층을 신뢰할 수 없는 입력 경계 (untrusted-input boundary)로 취급하십시오. 외부 API 입력에 적용하는 것과 동일한 엄격함 — 스키마 검증 (schema validation), 값 범위 확인 (value range checks), 이상 탐지 (anomaly detection), 그리고 형식이 잘못되었거나 범위를 벗어난 모든 것에 대한 거부 — 을 적용하십시오.

2. MCP 서버 입출력 스키마 강제 (MCP server input and output schema enforcement)

MCP 서버 자체는 모든 들어오는 도구 호출에 대해 엄격한 스키마 (schema)를 강제해야 합니다. 각 도구에 대해 명시적인 계약 (contracts)을 정의하십시오: 예상되는 파라미터 타입, 값 범위, 허용된 레코드 타입, 그리고 최대 작업 범위. 실행 전 서버 경계에서 계약을 벗어나는 모든 것을 거부하십시오. 출력에도 동일한 검증을 적용하십시오. 정화 (sanitization) 과정 없이 가공되지 않은 ERP 데이터를 LLM에 절대 반환하지 마십시오.

🔄 회복 탄력성 패턴 (Resilience Pattern): MCP 도구 계약 (tool contracts)을 좁고 구체적으로 설계하십시오. 정의된 최소/최대 범위 내에서 한 번에 하나의 SKU에 대한 가격만 업데이트할 수 있는 도구는 대량 업데이트 (bulk update) 엔드포인트보다 훨씬 안전합니다. 범위 제한 (Scope restriction)은 폭발 반경 (blast-radius)을 제한하는 첫 번째 수단입니다.

3. HITL 거버넌스 게이트 (HITL governance gate)

가격 책정, 재무 기록, 재고, 벤더 데이터, 구매 주문과 같이 중요한 비즈니스 데이터에 영향을 미치는 모든 쓰기 작업 (write operation)에 대해서는 실행 전 인간의 승인을 요구하십시오. 이 게이트는 선택 사항이 아니며 LLM에 의해 우회되어서는 안 됩니다. 에이전트가 제안된 작업을 제출하고 대기하면, 인간이 이를 검토하여 승인 또는 거부합니다. 명시적인 승인이 있을 때만 MCP 서버가 실행합니다.

🤖 에이전트 패턴 (Agent Pattern): LangGraph 워크플로 상태 머신 (state machine)에서 HITL을 강력한 게이트 (hard gate)로 구현하십시오. 에이전트는 PENDING_APPROVAL 상태로 전환되며, 인증된 인간 행위자로부터 승인 신호를 받기 전까지는 EXECUTING 상태로 진행할 수 없습니다. 어떤 LLM 추론 경로도 이 전환을 우회할 수 없어야 합니다.

관찰 가능성 요구 사항 (The observability requirement)

관찰 가능성 (observability) 없는 거버넌스는 보여주기식 행위에 불과합니다. 모든 MCP 쓰기 작업은 완전한 감사 추적 (audit trail)을 생성해야 합니다: 누가 또는 무엇이 이를 시작했는지, 이에 이르게 된 전체 프롬프트 컨텍락 (prompt context), 각 계층에서 내려진 검증 결정, 인간의 승인 기록, 실행된 정확한 작업, 그리고 결과가 포함되어야 합니다. 이 추적 기록은 불변 (immutable)해야 하며 쿼리가 가능해야 합니다.

🔍 관찰 가능성 패턴 (Observability Pattern): 쓰기 작업에 관여하는 모든 에이전트 워크플로에 대해 AgentOps 또는 LangSmith를 사용하여 전체 세션 트레이스 (session traces)를 캡처하십시오. 모든 트레이스에 MCP 도구 이름, 파라미터 해시 (parameter hash), 검증 결과, 승인 행위자, 그리고 ERP 트랜잭션 ID를 태깅하십시오. 무언가 잘못되었을 때 — 그리고 반드시 잘못될 것입니다 — 당신에게 필요한 것은 로그 고고학 (log archaeology)이 아니라 포렌식 재생 (forensic replay)입니다.

아키텍처 규칙 (The architecture rule)

읽기에는 시맨틱 레이어 (Semantic layer)를, 쓰기에는 MCP를 사용하십시오. 하지만 모든 MCP 쓰기 경로는 기업 시스템에 접촉하기 전에 반드시 프롬프트 검증 (prompt validation), MCP 스키마 강제 (MCP schema enforcement), 그리고 HITL 거버넌스 게이트를 통과해야 합니다.

"MCP를 통해 AI가 ERP와 직접 대화하는 것"을 찬양하는 리더들은, 프롬프트 인젝션 (Prompt Injection) 단 한 번으로 비즈니스 위기에 직면할 수 있는 시스템을 설명하고 있는 것입니다. 이 격차를 이해하는 설계자들이 2027년에 발생할 난장판을 수습하게 될 것입니다. 그리고 Gartner는 이미 그때까지 기업용 AI 에이전트 (AI agents)의 50% 이상이 실패할 것이라고 언급했습니다. 거버넌스 (Governance)는 기능이 아닙니다. 그것은 토대입니다.

다음 내용

A2A vs MCP — 그리고 Google의 UCP와 AP2가 에이전트 프로토콜 (agentic protocol) 환경에서 차지하는 위치