우리가 MCP에 베팅한 이유 (그리고 여전히 파악 중인 것들)

Data Workers를 구축하기 시작했을 때, 우리는 근본적인 결정을 내려야 했습니다. 우리의 AI 에이전트(AI agents)가 현대적인 데이터 스택(data stack)에 있는 수십 개의 도구와 어떻게 연결될 것인가 하는 문제였습니다. 각 도구에 대해 맞춤형 통합(custom integrations)을 구축할 수도 있었고, 기존의 오케스트레이션 프레임워크(orchestration frameworks)를 사용할 수도 있었습니다. 또는 Model Context Protocol (MCP)에 베팅할 수도 있었습니다.

우리는 MCP에 베팅했습니다. 그 이유와 우리가 여전히 파악 중인 것들을 소개합니다.

MCP의 실제 정체

MCP는 원래 Anthropic에서 개발한 개방형 프로토콜(open protocol)로, AI 모델이 외부 도구 및 데이터 소스와 상호작용하는 방식을 표준화합니다. 이를 AI를 위한 USB-C 포트라고 생각하면 됩니다. 즉, AI 에이전트가 해당 프로토콜을 구현하는 어떤 도구와도 통신할 수 있게 해주는 범용 커넥터(universal connector)입니다.

생태계가 폭발적으로 성장했습니다. 현재 데이터베이스부터 CI/CD 도구, 클라우드 플랫폼에 이르기까지 모든 것을 아우르는 12,230개 이상의 MCP 서버를 사용할 수 있습니다. 1년 전만 해도 이 숫자는 수백 개 수준이었습니다.

맞춤형 통합 대신 MCP를 선택한 이유

계산은 간단합니다. Data Workers는 데이터 웨어하우스(Snowflake, Databricks, BigQuery, Redshift), 오케스트레이터(Airflow, Dagster, Prefect), 변환 도구(dbt, Spark), 카탈로그(Unity Catalog, Datahub, Hive Metastore), BI 도구(Tableau, Looker, Power BI) 등에 연결해야 합니다.

이 각각에 대해 맞춤형 통합을 구축하고 유지 관리하는 것은 우리 규모의 팀에게는 전업 업무(full-time job)나 다름없습니다. MCP를 사용하면 표준 인터페이스(standard interface)를 얻을 수 있습니다. 어떤 도구가 MCP 서버를 가지고 있다면, 우리의 에이전트가 그 도구에 연결될 수 있습니다. 우리는 우리 군집(swarm) 내의 각 에이전트를 위해 맞춤형 MCP 서버를 구축하고 있습니다.

잘 작동하고 있는 것들

• 신속한 프로토타이핑 (Rapid prototyping). 우리의 장애 디버깅 에이전트 (Incident Debugging Agent) 프로토타입은 MCP를 통해 Snowflake 쿼리 로그, dbt 매니페스트 (manifests), Airflow DAGs에 몇 주가 아닌 단 며칠 만에 연결되었습니다.
• 조합성 (Composability). 각 에이전트가 자체적인 MCP 서버를 가지고 있기 때문에, 에이전트들은 프로토콜을 통해 컨텍스트 (context)를 공유할 수 있습니다. 장애 디버깅 에이전트가 데이터 품질 문제를 식별하면, 품질 모니터링 에이전트 (Quality Monitoring Agent)의 서버에 있는 도구들을 호출할 수 있습니다.
• 커뮤니티 활용 (Community leverage). Airflow를 위한 커뮤니티 MCP 서버들이 이미 존재하기 때문에, 우리는 Airflow 연동 기능을 처음부터 직접 구축할 필요가 없습니다.

우리가 여전히 파악 중인 것들

• 대규모 환경에서의 인증 (Authentication at scale). 엔터프라이즈 환경에서 수십 개의 도구에 걸쳐 자격 증명 (credentials)을 관리하는 것은 복잡합니다. OAuth 흐름, 서비스 계정 (service accounts), 토큰 로테이션 (token rotation), 최소 권한 원칙 (least-privilege access) 등이 이에 해당합니다.
• 지연 시간 (Latency). 각 MCP 호출은 네트워크 오버헤드 (network overhead)를 추가합니다. 에이전트가 장애를 진단하기 위해 15~20개의 도구 호출을 수행해야 할 때, 이러한 왕복 시간 (round trips)이 누적됩니다.
• 서버 품질의 편차 (Server quality variance). 12,230개 이상의 MCP 서버들은 품질 면에서 큰 차이를 보입니다. 우리는 예상보다 더 자주 커뮤니티 서버를 포크 (fork)하여 수정해야 했습니다.
• 상태 유지 워크플로 (Stateful workflows). MCP는 근본적으로 요청-응답 (request-response) 방식입니다. 하지만 데이터 엔지니어링 워크플로는 상태를 유지 (stateful)해야 합니다. 우리는 이를 처리하기 위해 MCP 상단에 컨텍스트 레이어 (context layer)를 구축하고 있습니다.
• 보안 공격 표면 (Security surface area). 모든 MCP 연결은 공격 표면 (attack surface)이 됩니다. 에이전트가 데이터 웨어하우스 (warehouse)에 대해 쿼리를 실행할 수 있게 되면, 보안상의 영향은 매우 심각합니다.

우리의 솔직한 평가

MCP는 우리에게 올바른 선택입니다. 대안인 커스텀 연동 (custom integrations) 구축은 우리의 엔지니어링 대역폭 (bandwidth) 전체를 소모하게 만들 것입니다. MCP는 소규모 팀이 광범위한 도구 생태계에 연결할 수 있게 해줍니다.

하지만 MCP가 만능 해결책 (silver bullet)은 아닙니다. MCP는 커넥터 (connector) 문제를 해결할 뿐, 지능 (intelligence) 문제를 해결하지는 않습니다. 우리의 에이전트들은 여전히 어떤 쿼리를 실행해야 하는지, 결과를 어떻게 해석해야 하는지, 그리고 언제 사람에게 에스컬레이션 (escalate)해야 하는지를 알아야 합니다. MCP는 우리에게 배관 (plumbing)을 제공할 뿐이며, 로직 (logic)은 여전히 우리가 구축해야 합니다.

원문은 https://dataworkers.io/blog/why-we-bet-on-mcp/에서 처음 게시되었습니다. Data Workers는 데이터 엔지니어링을 위한 오픈 소스 자율 에이전트 스웜 (autonomous agent swarm)입니다 — 리포지토리 확인.