3개의 에이전트 프레임워크 (agent frameworks). 4개의 데이터 소스 (data sources). 12개의 취약한 커넥터 (brittle connectors).

그러다 누군가 컬럼 이름을 하나 바꾸면 세 개의 에이전트가 동시에 고장 납니다. MCP는 이 배선 (wiring) 문제를 해결하지만, 사실 배선은 쉬운 부분이었습니다.

MCP 시맨틱 레이어 (semantic layer) 서버가 실제로 노출하는 것

설계 결정의 핵심은 당신의 도구 인터페이스 (tool surface)가 무엇을 나타내느냐입니다. 테이블을 노출하면 각 에이전트가 의미를 독립적으로 추론합니다. _시맨틱 (semantics)_을 노출하면 모든 에이전트가 동일한 그래프 (graph)를 통해 컴파일됩니다.

거버넌스 (governed)가 적용된 서버는 다음과 유사한 것을 노출합니다:

run_sql이 없다는 점에 주목하세요. 이는 의도적인 것입니다. 임의의 SQL 실행을 노출하는 순간, 모든 거버넌스 보장은 권고 사항 (advisory) 수준으로 전락하기 때문입니다.

요청 경로 (The request path)

의도 (Intent) → 컨텍스트 해석 (context resolution) → 제약된 계획 (constrained planning) → 거버넌스 기반 실행 (governed execution).

1. 에이전트가 의도와 호출자 신원을 전송합니다.
2. 서버가 버전 관리된 시맨틱 그래프 (semantic graph)를 기준으로 컨셉 (concepts)을 해석합니다.
3. 플래너 (Planner)가 조인 경로 (join path)를 증명합니다 — 경로가 없으면 컴파일이 실패합니다.
4. 해당 신원에 대해 RBAC 및 ABAC 술어 (predicates)가 주입됩니다.
5. 방언 (Dialect)에 완벽하게 부합하는 SQL이 생성되어 실행됩니다.
6. 리니지 (lineage) 및 감사 기록 (audit record)과 함께 결과가 반환됩니다.

No-Rip-and-Replace (기존 시스템 교체 없는 방식) 부분

이 레이어는 데이터 웨어하우스 (warehouse)를 대체하는 것이 아니라, 그 _위 (above)_에 위치합니다. Snowflake, Databricks, BigQuery, Postgres는 그대로 유지됩니다. 이 레이어는 기존의 카탈로그 (catalogs)와 BI 모델을 읽어 그래프를 구축한 다음, 각 엔진의 방언 (dialect)으로 컴파일합니다.

가장 흔한 반대 의견은 마이그레이션 피로감 (migration fatigue)입니다. 팀들은 통합을 위해 수백만 달러를 소비했으며 다시 이동하고 싶어 하지 않습니다. 그럴 필요가 없습니다. 추가적인 레이어 (Additive layers)만이 실제로 배포됩니다.

또한 MCP와 REST가 동일한 컴파일된 코어를 전면에 배치할 수 있기 때문에, 나중에 프로토콜을 변경하더라도 거버넌스를 다시 증명할 필요가 없습니다.

전체 분석 — 전체 아키텍처, 서버 코드, 도구 스키마 (tool schemas), 그리고 통합 경로 — 는 여기에 있습니다:

👉 MCP 시맨틱 레이어 서버 구축 방법 (아키텍처, 코드, 그리고 No-Rip-and-Replace 사례)

원문 게시지: colrows.com/blogs/mcp-semantic-layer-integration