위대한 디커플링: The Enterprise Capability Graph

I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Please paste the content (excluding the source line you’ve already provided) and I’ll return a Korean version while preserving the original formatting, markdown, and any code blocks or URLs.

Source: …

핵심 질문

외부 SaaS 제품이 MCP를 통해 기능을 노출한다면, 내부 엔터프라이즈 시스템도 동일하게 하지 않을 이유가 무엇일까요? 그리고 만약 그렇게 한다면 **“우리 소프트웨어”**와 “그들 소프트웨어” 사이의 경계는 어떻게 될까요?

답변: 경계가 사라집니다. 내부 시스템과 외부 시스템이 통합된 기능 그래프의 동등한 노드가 되며, 이는 기업이 아키텍처, 벤더, 그리고 제어에 대해 생각하는 방식을 완전히 바꿉니다.

대부분의 MCP 논의는 AI 에이전트가 외부 서비스를 호출하는 것에 초점을 맞춥니다 — 예를 들어, 어시스턴트가 CRM을 조회하고, 문서 플랫폼에서 데이터를 가져오며, 자동화 도구에서 워크플로를 트리거하는 경우입니다. 이는 가치가 있지만 전체 그림의 절반에 불과합니다.

이 패턴은 내부 시스템에도 동일하게 적용됩니다:

• 여러분의 맞춤형 ERP.
• 여러분이 직접 만든 분석 파이프라인.
• 플랫폼 팀이 유지 관리하는 방대한 내부 도구 모음.

이들 각각은 동일한 프로토콜을 통해 기능을 노출할 수 있습니다. 한 번 노출되면 흥미로운 일이 발생합니다. 오케스트레이션 레이어 — 요청을 라우팅하고, 인증을 관리하며, 권한을 처리하는 모든 것 — 기능의 출처에 대해 신경 쓰지 않게 됩니다. get_customer_credit_limit 를 라우팅할 때, 그 기능이 내부 Oracle 인스턴스에 있는지 외부 Experian API에 있는지 알 필요도, 신경 쓸 필요도 없습니다.

(Meridian는 가상의 CRM이며, 여러분이 이미 생각하고 있는 주요 플랫폼을 대신합니다. 이 패턴은 벤더에 관계없이 적용됩니다.)

내부와 외부는 구현 세부 사항에 불과해집니다. 기업은 내부에서 제공되든 외부에서 제공되든, 모두 동일한 인터페이스를 통해 접근 가능한 통합된 기능 그래프를 보게 됩니다.

이 대칭의 함의

“Build vs. Buy”에서 “Expose vs. Consume”로

전통적인 build vs. buy 결정은 두 옵션을 서로 대립시킵니다:

통합은 어느 쪽이든 동일합니다 — 같은 프로토콜, 같은 오케스트레이션 레이어, 같은 개발자 경험. 평가 기준은 오로지 역량 자체, 즉 비용, 품질, 신뢰성, 컴플라이언스, 전문성에만 집중됩니다.

• 결정 형태가 변함 – 이제 “우리 맞춤형 도구와 맞춤 UI”와 “그들의 제품과 UI(모두 교육 필요)”를 비교하는 것이 아니라, 순수히 역량 자체를 비교합니다.
• 가역성이 향상 – 외부 공급자를 내부 구현(또는 그 반대)으로 교체해도 아키텍처 변경이 필요 없으며, 오케스트레이터가 출처를 추상화합니다.

이 가역성은 전략적 금이며, 정답이 계속 변하는 환경에서 큰 가치를 제공합니다.

현재 기업 현실

• AI 역량이 평가 주기보다 훨씬 빠르게 등장합니다.
• 공급업체 환경이 매월 변합니다 — 인수·합병, 전략 전환, 신규 진입, 갑작스러운 서비스 종료 등.
• 6개월 전에는 타당해 보였던 build‑vs‑buy 결정이 오늘은 의문스럽게 보입니다.
• 각 새로운 AI 도구마다 자체 연결 패턴이 필요해지면서 통합 복잡성이 폭발합니다.
• 당시에는 타당했지만, 포인트‑투‑포인트 연결에서 기술 부채가 누적됩니다.

제가 대화하는 모든 기업 아키텍트는 이와 같은 혼돈의 버전을 묘사합니다. 상황은 계속해서 변하고 멈추지 않습니다.

역량 기반 아키텍처가 직접 대응

이는 먼 미래를 대비하는 것이 아니라 현재를 살아남는 것입니다. 오늘날 여러분의 아키텍처를 유지 가능하게 만드는 패턴—격리, 명시적 계약, 표준 인터페이스—은 정답이 계속 변하는 환경을 헤쳐 나가기 위해 정확히 필요한 것입니다.

기업에 대한 제안은 “미래를 위해 채택하라”가 아니라 “지금 민첩성을 유지하기 위해 채택하라” 입니다.

오케스트레이터: 새로운 레이어

기업이 역량 기반 아키텍처를 도입함에 따라 새로운 레이어가 구체화됩니다: 오케스트레이터. 이는 단순히 API 게이트웨이나 서비스 메시가 아니라, 두 기술과 DNA를 공유합니다. 오케스트레이터는 다음을 담당합니다:

• 역량 탐색 – 어떤 역량이 사용 가능한가? 이 정체성이 접근할 수 있는 역량은? 오케스트레이터는 레지스트리를 유지하고 동적 탐색을 처리합니다.
• 요청 라우팅 – 요청이 들어오면 어디로 가야 하는가? 라우팅은 역량 유형, 데이터 거주 요구사항, 부하, 비용 최적화 또는 사용자 정의 규칙에 기반합니다.
• 인증 및 인가 – 이 정체성이 이 데이터에 대해 이 파라미터로 이 역량을 호출할 수 있는가? 오케스트레이터는 내부 및 외부 역량 전반에 걸쳐 일관된 접근 제어를 적용합니다.
• 감사 및 가시성 – 무엇이 언제, 누가, 어떤 파라미터로 호출했으며, 어떤 결과를 반환했는가? 오케스트레이터는 규정 준수를 위한 감사 로그를 유지합니다.
• 컨텍스트 관리 – 세션 상태는? 어떤 권한이 위임되었는가? 적용되는 제약은? 오케스트레이터는 상호작용 전반에 걸쳐 컨텍스트를 유지합니다.

시리즈의 나머지 부분에서는 오케스트레이터 설계 패턴, 거버넌스 모델, 실제 사례 연구를 더 깊이 탐구할 것입니다.

교차 기능 호출

오케스트레이터는 기업의 기능 제어 평면이 된다 – 기능 자체가 아니라(그 기능들은 내부 시스템과 외부 공급자에 걸쳐 분산되어 있다) 기능들을 접근 가능하고, 관리 가능하며, 조합 가능하게 만드는 계층이다.

이것은 새로운 유형의 인프라스트럭처이다.

• 완전한 통합 플랫폼은 아니다(통합을 처리하지만).
• 완전한 AI 프레임워크는 아니다(AI를 가능하게 하지만).
• 완전한 신원 관리도 아니다(신원을 처리하지만).

이는 기능 우선 기업의 연결 조직이다.

플랫폼 팀의 새로운 역할

오늘

• “우리는 Meridian 인스턴스를 소유합니다.”
• “우리는 내부 분석 플랫폼을 유지합니다.”
• “우리는 통합 미들웨어를 운영합니다.”

각 시스템은 고유한 전문성을 가진 별개의 책임입니다.

역량‑우선 모델에서

플랫폼 팀은 역량 큐레이터가 됩니다. 이제 단순히 시스템을 유지하는 것이 아니라 역량 그래프를 큐레이션합니다. 그들의 책임이 변합니다:

이것은 의미 있는 상승입니다. 플랫폼 팀은 시스템 관리자에서 역량 중개인으로, 도구 유지보수자에서 그래프 설계자로 이동합니다.

The Enterprise AI Fabric

조합:

1. Unified capability graph – 내부 및 외부 시스템이 동등한 노드로 취급됩니다.
2. Orchestration layer – 탐색, 라우팅, 인증, 감사.
3. Contextual rendering – 필요에 따라 인터페이스가 생성됩니다.
4. AI agents – 주요 기능 소비자.

…이것이 새로운 개념, Enterprise AI Fabric을 구성합니다. 이는 AI‑네이티브 운영을 가능하게 하는 연결 계층입니다.

Fabric이 가능하게 하는 시나리오

• 통합 프로젝트 없이 시스템 간 작업

  “고객 레코드를 업데이트하고, 신용 한도를 조정하며, 계정 팀에 알린다”는 작업이 CRM, 재무 시스템, 커뮤니케이션 플랫폼을 가로지르는 단일 오케스트레이션 흐름이 됩니다 – 별도의 맞춤형 통합이 필요 없습니다.

• 우아한 기능 교체
  공급업체가 가격을 인상하거나 품질이 저하될 경우, 소비자 측 변경 없이 대체 옵션으로 전환합니다. 오케스트레이터가 라우팅을 다르게 지정하고, 나머지는 그대로 유지됩니다.

• 적절한 기업 접근 권한을 가진 AI 에이전트
  AI 도구에 모든 API 키를 직접 제공하는 보안 위험(보안 악몽)이나 전혀 제공하지 않아 쓸모 없는 상황을 피하고, 오케스트레이터가 적절한 인증 및 감사를 통해 접근을 중재합니다.

• 조직 경계를 초월한 연합된 기능
  파트너, 공급업체, 고객이 자신의 기능을 그래프에 노출할 수 있습니다(적절한 접근 제어와 함께). 이를 통해 포인트‑투‑포인트 통합 없이도 조직 간 워크플로우를 구현할 수 있습니다.

왜 이것이 “10년 비전”이 아닌가

모든 주요 기업이 AI 도입에 직면하며 같은 장벽에 부딪히고 있습니다:

• AI에게 우리 시스템에 대한 안전한 접근을 어떻게 허용할까?
• N × M 통합을 구축하는 것을 어떻게 피할까?
• 실험을 가능하게 하면서 거버넌스를 어떻게 유지할까?

Capability‑based architecture는 이러한 압력에서 떠오르는 해답이다.

• MCP(또는 그것이 진화하는 형태)는 혼돈 속에서 구체화되는 활성화 표준이다.
• 오케스트레이션 레이어는 기업이 역량을 체계적으로 관리해야 함을 깨달을 때 구축하는 것이다.

MCP의 현재 형태가 중요한 것이 아니라, 그 패턴이 작동하고 주요 플레이어들이 이에 맞춰 정렬했으며 이제 아키텍처 방향이 명확해졌다는 것이 핵심이다. 2028년의 MCP는 오늘과 다를 수 있지만, 열어준 문은 닫히지 않을 것이다.

문제는 이 아키텍처가 등장하느냐가 아니다. 당신의 기업이 선도할지 따를지가 문제다.

가치가 어디에 존재하는가?

• 20년 동안 SaaS 벤더들은 데이터 주변에 방어벽을 구축해 왔습니다.
• 귀하의 CRM은 단순히 CRM 기능을 제공하는 것이 아니라 귀하의 조직 기억(상호작용, 거래, 패턴)을 축적합니다.
• 그것은 기능이 아니라 인질입니다.

기능‑우선 아키텍처는 이러한 인질 잡기를 가시화합니다. 오케스트레이터가 고객 데이터를 요청하고 기능이 데이터가 벤더의 벽 안에 머물도록 설계된 마찰을 발생시킬 때, 고객은 이를 인지합니다.

이는 기업에게 불편하지만 잠재적으로 해방적인 현실을 초래합니다: 우리가 20년 동안 미뤄왔던 데이터‑주권 질문.

파트 3

다음 시리즈:

위대한 분리: 데이터 주권 교정

능력‑우선 아키텍처가 SaaS 권력 구조를 뒤집는 방식.

지원 통계

• 기업 AI 에이전트 도입

  • G2의 2025년 8월 설문조사: **57 %**의 기업이 AI 에이전트를 운영 중이며, **22 %**가 파일럿 단계에 있습니다.
  • PwC 연구: **79 %**의 조직이 어느 정도 AI 에이전트를 도입했습니다.
  • Source: Deepak Gupta – MCP Enterprise Adoption Guide

• 멀티 에이전트 시스템 설계

  • **66.4 %**의 기업이 단일 에이전트 방식보다 멀티 에이전트 시스템 설계를 사용하고 있어, 조정 프로토콜에 대한 수요가 증가하고 있습니다.
  • Source: Deepak Gupta – MCP Enterprise Adoption Guide

• 에이전시 AI 프로젝트 과제

  • Gartner는 ROI가 불분명하고 구현 과제 때문에 40 % 이상의 에이전시 AI 프로젝트가 2027년 말까지 취소될 것으로 예측합니다.
  • Source: Gartner Press Release

• AWS 에이전시 AI 보안 프레임워크

  • (원본에서 내용이 축약됨; 사용 가능한 경우 관련 세부 정보를 삽입하세요.)

모든 인용은 원본 텍스트에 제공된 대로입니다.

# AWS Agentic AI Security Scoping Matrix
**Source:** AWS Security Blog  

AWS published the *Agentic AI Security Scoping Matrix*, defining four security scopes ranging from basic tool use to fully autonomous systems.

---

# AI Agent Security Concerns
**Source:** CIO – *Autonomous AI Agents = Autonomous Security Risk*  

Gartner predicts that **25 % of enterprise breaches will trace back to AI‑agent abuse by 2028**.

---

# MCP and A2A Protocols
**Source:** Koyeb – *A2A and MCP: Start of the AI Agent Protocol Wars?*  

An analysis of how **MCP** (tool integration) and Google’s **A2A** (agent‑to‑agent coordination) are positioned as **complementary rather than competing standards**.