안녕하세요, 엔터프라이즈 AI를 위한 AI-ready 데이터 플랫폼 Syntitan을 만드는 CUBIG입니다. 💎
MCP는 AI 에이전트가 시스템에 도달하는 방식을 표준화합니다.
하지만 그 에이전트가 옮기는 데이터가 어떤 상태인지에 대해서는 아무것도 말해 주지 않습니다. MCP를 통해 에이전트를 운영 데이터베이스에 연결하면, 에이전트는 바로 그 순간 테이블에 담긴 내용을 그대로 받게 됩니다. 지난주 변형된(drift) 스키마와, 여러분이 테스트한 실행 이후 바뀐 행(row)까지 전부 말이죠.
검증 가능한 데이터 상태(Verifiable Data State)는 바로 이 간극을 메웁니다. 에이전트가 사용하고, 추적하고, 재현할 수 있는 형태로 릴리스된 엔터프라이즈 데이터의 상태로, MCP가 데이터를 실어 나르기 전에 상류(upstream)에서 미리 준비됩니다.
1부에서는 Model Context Protocol을 기초부터 설명합니다.
2부에서는 MCP가 답하지 않고 남겨 둔 질문, 즉 에이전트가 도달했을 때 데이터가 어떤 상태에 있는가에 답합니다.
1부 – 프로토콜
AI 어시스턴트 하나를 여러분의 데이터베이스, 티켓팅 시스템, 사내 위키에 연결하면 세 개의 통합(integration)을 만들게 됩니다.
그리고 모델을 다른 것으로 바꾸면 이를 처음부터 다시 만들어야 합니다. MCP는 바로 이 계산을 끝내기 위해 존재합니다.
통합 비용(integration tax)
MCP 이전에는 어시스턴트가 사용하는 모든 도구마다 특정 모델 하나만을 위한 전용 커넥터가 필요했습니다. 모델을 하나 추가하면 커넥터를 다시 만들어야 했고, 도구를 하나 추가하면 모든 모델마다 새 커넥터가 필요했습니다. 작업량은 도구와 모델의 합이 아니라 곱으로 늘어났습니다.
MCP(Model Context Protocol, AI 시스템을 외부 도구 및 데이터에 연결하기 위한 개방형 표준)는 이 구조 자체를 바꿉니다. 도구가 프로토콜을 한 번만 구현하면, 규격을 준수하는 모든 애플리케이션이 별도의 맞춤형 커넥터 없이 그 도구를 사용할 수 있습니다.
MCP를 공개한 Anthropic은 이 문제를 명료하게 짚습니다. 아무리 강력한 모델이라도 “정보 사일로와 레거시 시스템 뒤에 갇혀” 있으며, 새로운 데이터 소스를 쓸 때마다 매번 전용 구현을 직접 만들어야 했다는 것입니다. 이 프로토콜은 그 자리를 데이터와 AI 도구 사이의 양방향 연결을 위한 하나의 개방형 표준으로 대체합니다.
MCP의 실체: 호스트, 클라이언트, 서버
MCP는 세 가지 역할을 정의합니다. 서버는 데이터와 기능을 노출합니다. 읽을 수 있는 리소스, 호출할 수 있는 도구, 재사용할 수 있는 프롬프트가 그것입니다. 클라이언트는 모델을 대신해 프로토콜로 대화하며, 연결을 열고 서버가 무엇을 제공하는지 탐색합니다.
호스트는 사용자가 직접 접하는 애플리케이션으로, Claude Desktop이나 AI 기능이 탑재된 IDE 같은 것입니다. 호스트는 클라이언트를 실행하고, 어떤 도구를 호출할지 결정하며, 여러 단계로 이뤄진 작업을 조율합니다.
메시지는 JSON-RPC 2.0(구조화된 요청과 응답을 JSON으로 주고받는 경량 원격 프로시저 호출 형식) 위에서 오갑니다.
연결은 상태를 유지하는(stateful) 양방향 연결이어서, 서버가 결과를 스트리밍하거나 작업 도중 클라이언트에 추가 입력을 요청할 수 있습니다. MCP를 단순한 HTTP 래퍼 이상으로 만드는 핵심은 런타임 탐색(runtime discovery)입니다. 클라이언트는 엔드포인트를 사전에 하드코딩해 둘 필요가 없습니다.
클라이언트는 어떤 도구와 리소스가 존재하는지 서버에 물어보고 그 자리에서 사용합니다. 서버에 새 기능이 추가되어도 클라이언트를 다시 작성하지 않고 에이전트에 닿습니다.
메시지 집합은 작고 표준적입니다. Microsoft의 MCP 가이드는 핵심 호출을 이렇게 정리합니다. 클라이언트는 세션을 열기 위해 InitializeRequest를 보내고, 무엇이 사용 가능한지 확인하기 위해 ListToolsRequest와 ListResourcesRequest를 보낸 뒤, 실제 동작을 위해 CallToolRequest나 ReadResourceRequest를 보냅니다.
메시지 하나는 반대 방향으로 흐릅니다.
서버는 CreateMessageRequest를 통해 클라이언트에 모델 샘플링을 요청할 수 있는데, 프로토콜은 이 경로에 사람이 개입(human in the loop)할 것을 전제합니다. 즉, 클라이언트는 모델을 실행하기 전에 요청 내용을 사용자에게 보여 줄 수 있습니다. 승인은 나중에 덧붙이는 것이 아니라 샘플링 흐름 안에 자리합니다.
MCP는 API의 대체재가 아니다
전통적인 API는 사전에 정의된 인터페이스를 노출합니다. MCP는 여기에 런타임 탐색, 양방향 세션, 그리고 모델에 친화적인(model-native) 도구 상호작용을 더합니다. MCP 서버를 향하는 에이전트는 자신이 무엇을 할 수 있는지 런타임에 학습하고, 서버와 세션을 유지하며, 결과가 도착하는 대로 부분 결과를 받습니다.
MCP, RAG, Skills는 서로 다른 문제를 푼다
이 세 가지 이름은 자주 한데 묶여 거론됩니다. 하지만 이들은 서로 다른 계층에 자리합니다. RAG(Retrieval-Augmented Generation)는 지식을 다룹니다. 시맨틱 검색으로 코퍼스에서 관련 조각을 가져와 프롬프트에 넣어 줍니다.
Skills는 토큰 효율을 다룹니다. 필요할 때 불러오는 재사용 가능한 지시(instruction) 패키지입니다. MCP는 접근(access)을 다룹니다. 에이전트가 살아 있는 시스템에 도달해 동작하기 위해 거치는 표준화된 경로입니다.
종합하면 접근은 MCP, 지식 검색은 RAG, 재사용 가능한 지시와 절차는 Skills가 담당합니다. 이들은 서로 조합됩니다. 한 가지 구분은 분명히 짚어 둘 가치가 있습니다. RAG는 미리 구축해 둔 인덱스에서 읽어 들이므로 빠르고 저렴하지만, 신선도는 마지막 갱신 시점까지입니다.
MCP는 살아 있는 시스템에 직접 질의하므로 최신이지만, 왕복(round trip) 비용이 듭니다. 캐시된 기억과 실시간 진실(live truth)의 차이입니다. 현실의 시스템 대부분은 둘 다를 필요로 합니다.
왜 중요한가
MCP는 과거 벤더들이 수작업으로 만들던 통합을 표준화합니다. HTTP가 웹에서, SQL이 데이터베이스에서 각각 일으킨 변화와 같은 흐름입니다. 에이전트 기반 시스템에서 에이전트는 런타임에 새 도구를 집어 들어 사용할 수 있는데, 이는 진정한 다단계 작업을 수행하는 에이전트의 전제 조건입니다. 이 생태계는 이미 제안 단계를 넘어섰습니다. Anthropic은 공식 명세와 SDK와 함께 MCP를 공개했고, Microsoft를 비롯한 주요 개발 생태계가 이를 지원하며, Claude Desktop에서부터 AI 기능이 탑재된 IDE와 GitHub Copilot 계열 환경에 이르기까지 여러 호스트로 확산되고 있습니다.
2부 – 검증 가능한 데이터 상태(Verifiable Data State)
MCP는 에이전트가 시스템에 도달하는 방식을 표준화합니다. 하지만 그 에이전트가 옮기는 데이터가 어떤 상태인지에 대해서는 아무것도 말해 주지 않습니다. MCP를 통해 에이전트를 운영 데이터베이스에 연결하면, 에이전트는 바로 그 순간 테이블에 담긴 내용을 그대로 받습니다. 지난주 변형된 스키마, 누군가 이름을 바꿔 버린 컬럼, 여러분이 테스트한 실행 이후 바뀐 행까지 말이죠. 병목은 결코 모델이 아니었습니다. 데이터 상태가 병목입니다.
PoC는 되는데 운영 환경은 드리프트하는 이유
에이전트는 깨끗하게 추려 낸 데이터 조각 위에서 진행하는 개념 검증(PoC)에서는 잘 동작합니다. 그렇게 출시됩니다. 그런데 운영 데이터가 움직이면, 동일한 MCP 호출이 다른 상태를 반환합니다. 결과는 더 이상 재현되지 않습니다.
팀은 모델을 탓하고, 재학습하고, 프레임워크를 갈아 끼웁니다. 그 어느 것도 원인을 건드리지 못합니다. 원인은 그 아래에 깔린 데이터에 있기 때문입니다.
검증 가능한 데이터 상태(Verifiable Data State)는 AI가 사용하고, 추적하고, 재현할 수 있도록 릴리스된 엔터프라이즈 데이터의 상태입니다.
여섯 가지 축이 이를 결정합니다. 사용성(Usability), 무결성(Integrity), 맥락(Context), 일관성(Consistency), 재현성(Reproducibility), 그리고 추적성(Traceability)입니다.
운영 환경이 무너지는 지점은 바로 마지막 두 가지입니다.
Syntitan은 MCP의 상류에 자리한다
Syntitan (CUBIG의 AI-ready 데이터 운영 계층)은 MCP로 연결된 에이전트에게 움직이는 데이터 상태가 아니라 검증 가능한 데이터 상태를 제공합니다. Syntitan은 전송 계층의 상류에 자리합니다. 데이터는 MCP가 실어 나르기 전에 진단되고, 변환되고, 버전 관리되는 검증 가능한 상태로 릴리스됩니다. 흐름은 한 방향으로 진행됩니다.
Syntitan은 여러분의 MCP 서버를 대체하지 않습니다. Syntitan이 바꾸는 것은 MCP 리소스가 가리키는 대상입니다. 가공되지 않은 운영 데이터 대신 검증 가능한 데이터 상태를 가리키게 됩니다. 에이전트는 여전히 동일한 MCP 프로토콜로 대화하지만, 이제 읽어 들이는 데이터는 버전 관리되고, 추적 가능하며, 재현 가능합니다. MCP는 접근을 그대로 유지합니다. Syntitan은 그 접근이 닿는 대상을 바꿉니다.
에이전트는 가공되지 않은 운영 데이터를 소비하지 않습니다. 에이전트가 소비하는 것은 Syntitan이 버전 관리한 검증 가능한 데이터 상태입니다. MCP는 그 상태를 실어 나릅니다. 어떤 상태를 릴리스할지는 Syntitan이 결정합니다.
Syntitan이 릴리스하는 것
상태 릴리스(Release State) — 고정하라
엔터프라이즈 데이터는 콘텐츠 해시를 가진, 이름과 버전이 부여된 상태로 들어갑니다. 에이전트 실행은 아래에서 움직이는 테이블이 아니라 바로 그 상태를 읽습니다.
실행 바인딩(Run Binding) — 실행을 상태에 묶어라
모든 실행은 자신이 사용한 정확한 데이터 상태에 바인딩됩니다. 다음 달에 다시 실행하면 동일한 입력을 얻거나, 무엇이 바뀌었는지 짚어 주는 diff를 얻습니다.
Diff와 재현(Diff and Reproduce) — 비교하고 다시 실행하라
두 상태를 비교하세요. 결과를 만들어 낸 그 상태로부터 결과를 재현하세요. 믿고 받아들이는 주장이 아니라, 여러분이 직접 돌려 보는 증명입니다.
설계상 보호된다(Protected by construction)
검증 가능한 데이터 상태는 데이터가 소스를 떠나기 전, 상류에서 준비되기 때문에 민감한 필드도 바로 그 지점에서 처리됩니다. DTS(규제 대상이거나 희소한 데이터를 학습 가능한 합성 데이터로 바꾸는 CUBIG의 엔진)는 합성이 더 안전한 경로일 때 차등 프라이버시 한계(differential-privacy bound, 어떤 개별 레코드의 재식별 위험을 수학적으로 한정하는 프레임워크) 안에서 데이터를 생성합니다. LLM Capsule(민감한 데이터를 외부 LLM에 연결하고 반환 시 이를 복원하는 CUBIG의 활용 계층)은 PII(개인 식별 정보)를 치환했다가 반환 시 다시 복원합니다. CUBIG의 벤치마크에서 퍼블릭 LLM의 답변 유사도는 보호 적용 이후에도 98%를 유지합니다. 프라이버시는 검증 가능한 데이터 상태 앞에 덧대어 세운 관문이 아니라, 그 상태 자체가 지닌 속성입니다.
접근 방식 비교
| 접근 방식 | 놓치는 것 |
|---|---|
| 모델을 재학습하거나 교체 | 그 아래에 깔린 데이터 상태 |
| 또 한 번의 PoC 진행 | 운영 환경의 드리프트 |
| DLP / 마스킹 | 사용 가능한 맥락 |
| Syntitan 검증 가능한 데이터 상태 | 버전 관리되고, 추적 가능하며, 재현 가능한 실행 |
이를 통해 팀이 할 수 있게 되는 말
검증 가능한 데이터 상태는 팀이 자신 있게 내세울 수 있는 명료한 문장으로 바뀝니다.
- 에이전트 실행은 아래에서 움직이는 테이블이 아니라, 이름이 부여된 데이터 상태를 읽는다.
- 어떤 결과든 그것을 만들어 낸 상태로부터 재현된다.
- 실행 사이에 무엇이 바뀌었는지는 미스터리가 아니라 diff다.
- 민감한 필드는 상태가 준비되는 지점에서 처리된다.
- 그 토대 위에서 기업은 외부 AI를 승인할 수 있다.
병목은 결코 모델이 아니었습니다. 데이터 상태가 병목이었습니다.
에이전트가 이미 돌아가는 곳에 출시한다
CUBIG는 이를 개발자들이 이미 일하고 있는 곳, 즉 Anthropic 플러그인 마켓플레이스, MCP 레지스트리, 그리고 GitHub에 출시합니다. 이 계층은 에이전트가 돌아가는 바로 그 자리에서 에이전트를 맞이합니다. 그리고 이것은 여러분이 직접 로그인해서 쓰는 제품입니다. 네 번째 PoC를 의뢰하는 대신, 여러분의 데이터를 직접 통과시켜 보고 결과를 스스로 재현해 보세요.
운영 데이터 위에서 에이전트를 돌리고 계신가요? 여러분의 데이터를 직접 Syntitan에 통과시키고 결과를 스스로 재현해 보세요.