API를 바꾸는 AI와 ‘의도 이해’ 기반 웹 — SOA 2.0의 부상

▲ 이미지: Unsplash (무료 저작권, 상업 이용 가능)

---

SOA 1.0의 유산과 실패 — 왜 한 번 망했나

2000년대 초반, 엔터프라이즈 IT 세계는 하나의 이상을 품었다. 재고 시스템과 청구 시스템이 사람의 개입 없이 서로를 찾아내고, 필요한 데이터를 교환하며, 비즈니스 프로세스를 자동으로 완성하는 세상이었다. 이 이상을 실현하기 위한 기술 집합이 바로 서비스 지향 아키텍처(SOA, Service-Oriented Architecture)였다.

SOA의 기술 스택은 야심찼다. SOAP(Simple Object Access Protocol)으로 서비스 간 메시지를 주고받고, WSDL(Web Services Description Language)로 서비스 인터페이스를 선언하며, UDDI(Universal Description, Discovery and Integration)로 서비스 레지스트리를 만들었다. 이 모든 것을 중앙에서 조율하는 ESB(Enterprise Service Bus)가 허브 역할을 맡았다.

결과는 실패였다. 이유는 복잡하지 않다. 먼저 기술적 경직성이 문제였다. XML 태그 하나가 틀리거나, WSDL 파일이 한 줄 바뀌면 클라이언트 전체가 코드를 재생성해야 했다. 변경 비용이 너무 컸다. 다음으로 ESB의 단일 장애점 문제가 있었다. ESB는 모든 서비스 통신이 거쳐가는 중앙 허브였는데, 이것이 곧 병목이자 장애 발생 시 전체 시스템을 마비시키는 단일 실패점이 되었다. IBM의 분석에 따르면, SOA는 공유 인프라와 중앙화된 거버넌스로 문제를 해결하려 했지만, 마이크로서비스는 각 서비스가 자체 데이터를 소유하고 독립적으로 배포되는 탈중앙화로 방향을 전환해 살아남았다.

결국 업계는 단순성을 선택했다. REST API와 JSON이 승자가 됐다. 개발자가 직접 읽을 수 있는 엔드포인트, 가벼운 HTTP 동사(GET/POST/PUT/DELETE), 사람이 이해할 수 있는 JSON 페이로드. 자동화의 꿈을 포기한 대신 안정성과 실용성을 얻었다. 그리고 약 20년간 이 방식이 웹을 지탱해왔다.

하지만 그 포기했던 꿈이 다시 돌아오고 있다. 이번엔 AI와 함께.

---

무엇이 달라졌나 — AI, MCP, 그리고 ‘의도 이해’

과거 SOA가 실패한 핵심 이유는 서비스들이 서로를 이해하지 못했기 때문이다. UDDI 레지스트리에 서비스가 등록되어 있어도, 다른 서비스가 그것을 찾아 맥락에 맞게 활용하려면 여전히 사람이 명세를 읽고 코드를 써야 했다. 진정한 자동화가 아니었다.

오늘날 대형 언어 모델(LLM)은 이 문제를 다른 방식으로 접근한다. 자연어로 표현된 의도를 이해하고, 사용 가능한 도구 목록에서 적합한 것을 선택해 실행한다. “스테이징 환경의 청구 시스템을 설정해 줘”라는 단 한 문장이 여러 API 호출의 조합으로 변환된다. 이것이 핵심 변화다.

이 변화를 구조적으로 뒷받침하는 것이 MCP(Model Context Protocol)다. Anthropic이 2024년 11월 공개한 이 오픈 표준은 AI 모델(클라이언트)과 외부 데이터·도구 제공자(서버) 사이의 통신을 표준화한다. JSON-RPC 2.0 기반의 클라이언트-서버 구조로, MCP 서버는 Tools(실행 가능한 함수), Resources(데이터 접근), Prompts(재사용 가능한 프롬프트 템플릿), Sampling(LLM 직접 호출)이라는 네 가지 핵심 요소를 노출한다.

Anthropic의 공식 발표에 따르면, MCP는 “가장 정교한 모델조차도 데이터 사일로와 레거시 시스템 뒤에 갇혀 있다”는 문제를 해결하기 위해 설계됐다. Google Drive, Slack, GitHub, PostgreSQL 같은 엔터프라이즈 시스템을 위한 사전 빌드 서버가 이미 오픈소스로 공개되어 있으며, OpenAI·Microsoft·Google·Cloudflare가 이 표준을 채택하면서 사실상 산업 표준의 위치를 굳히고 있다. Python·JavaScript SDK 다운로드는 2024년 11월 공개 이후 폭발적으로 늘어 2026년에는 월 수천만 회 규모에 이른 것으로 집계된다.

MCP만이 아니다. 2025년에는 IBM의 ACP(Agent Communication Protocol), Google의 A2A(Agent-to-Agent Protocol), 그리고 분산 P2P 방식의 ANP(Agent Network Protocol)가 잇따라 등장했다. arXiv에 게재된 에이전트 상호운용성 프로토콜 서베이 논문(2025)은 이들을 비교하며 “단일 프로토콜이 모든 시나리오를 해결하지 못한다”고 결론짓는다. MCP는 LLM과 도구의 단단한 통합에, A2A는 신뢰된 엔터프라이즈 환경의 에이전트 간 협업에, ANP는 탈중앙화된 개방 인터넷 에이전트 생태계에 각각 적합하다.

---

SOA 2.0의 기술 구성요소 — 구체적으로 무엇이 바뀌는가

SOA 2.0이라는 표현은 아직 공식 용어가 아니다. 하지만 기술 칼럼니스트 Matthew Tyson이 ITWorld에서 처음 사용한 이 표현은 현재 일어나는 변화를 가장 정확하게 포착한다. 과거 SOA와 SOA 2.0의 차이를 기술 요소별로 대조하면 다음과 같다.

구성요소	SOA 1.0	SOA 2.0 (AI 기반)
서비스 계약	WSDL (XML 선언적 명세)	LLM 기반 유연한 해석
서비스 탐색	UDDI 레지스트리	벡터 DB + 함수 레지스트리
메시지 중계	ESB (중앙 허브)	‘추론 버스’ 계층 (의미론적 라우팅)
통신 프로토콜	SOAP/XML	JSON-RPC, MCP, REST, gRPC
오케스트레이션	개발자가 명시적 코드 작성	AI가 도구 선택·실행 자율 결정
결합 방식	결정론적 (동일 입력 = 동일 출력)	확률론적 (의미 기반 추론)

이 전환을 이해하는 유용한 비유는 전통적 ESB(Enterprise Service Bus)와의 대비다. ESB가 XML 메시지를 미리 정의된 경로로 라우팅했다면, 새로운 계층은 사용자의 의도를 의미론적으로 해석해 적절한 서비스에 연결하는 ‘추론 버스(reasoning bus)’에 가깝다. 각 서비스는 더 이상 단단한 계약 명세서를 가질 필요 없이, “무엇을 할 수 있는지”를 자연어로 설명하면 된다.

서비스 탐색도 바뀐다. UDDI 레지스트리 대신 벡터 데이터베이스가 그 역할을 한다. 함수와 API의 설명이 임베딩 벡터로 변환되어 저장되고, AI 에이전트가 사용자 의도와 의미적으로 가장 가까운 함수를 검색·선택한다. 이것이 바로 기능 레지스트리(Function Registry)의 현대적 구현이다.

arXiv에 발표된 논문 Beyond Static Endpoints: Tool Programs as an Interface for Flexible Agentic Web Services(2026)는 한 걸음 더 나아간다. 정적 REST 엔드포인트나 GraphQL 스키마 대신, 실행 가능한 프로그램 자체가 인터페이스가 되는 “Tool Programs” 모델을 제안한다. WebAssembly 같은 기술로 샌드박스화된 도구 프로그램을 서비스로 제공하면, AI 에이전트가 런타임에 그 동작을 탐색하고 조합할 수 있다. 미리 정의된 엔드포인트 명세가 필요 없다는 것이 핵심이다.

Composio의 2026년 가이드는 실제 현장에서의 패턴을 보여준다. 단순한 직접 API 호출에서 시작해, 통합과 거버넌스 요구가 커질수록 Unified API + MCP 조합으로 발전하는 여정이 기업들의 표준 경로가 되고 있다. 하나의 에이전트가 CLI, MCP 서버, 함수 호출, 직접 REST API를 한 요청 안에서 혼합 사용하는 것이 이미 일상이다.

---

기회와 위험 — 확률론적 웹의 두 얼굴

Matthew Tyson은 이 변화를 “확률론적 웹(Probabilistic Web)”으로 명명한다. 과거의 웹은 결정론적 상태 기계였다. 동일한 GET 요청은 항상 동일한 응답을 반환했다. 하지만 LLM이 라우팅과 해석을 담당하는 순간, 네트워크의 근본에 의미 기반 불확실성이 내장된다.

이 변화가 가져오는 기회는 분명하다. 서비스 통합의 자동화 수준이 과거와 비교할 수 없을 만큼 높아진다. 새 서비스를 추가할 때 클라이언트 전체를 수정하는 대신, 서비스가 스스로를 설명하는 텍스트를 업데이트하면 된다. 마이크로서비스 간 하드코딩된 연결이 점점 필요 없어진다. 소프트웨어 엔지니어링이 “완전한 제어의 환상”에서 벗어나 “시스템 정원 가꾸기(System Gardening)”로 전환된다는 Tyson의 표현은 이 변화의 철학적 함의를 잘 담는다.

하지만 위험도 동등하게 크다.

첫째, 지연 시간(Latency)이다. LLM 추론은 수백 밀리초를 추가한다. 마이크로초 단위의 응답이 필요한 금융 거래, 실시간 시스템에서는 이 지연이 치명적이다. AI 기반 라우팅을 쓸 수 있는 경로와 쓸 수 없는 경로를 명확히 구분하는 설계가 필요하다.

둘째, 비결정성(Non-determinism)이다. 미묘하게 다른 프롬프트가 완전히 다른 API 경로를 선택할 수 있다. 존재하지 않는 파라미터를 생성하거나, 같은 요청에 매번 다른 함수를 실행할 수 있다. Tyson이 언급한 Google Imagen API 사례가 대표적이다 — 코드 오류 없이 이미지 생성이 거부되는데, 애플리케이션 맥락과 사용자 입력의 조합이 정책 위반으로 의미론적으로 해석됐기 때문이다. 이런 행동은 전통적 디버깅으로 추적하기 매우 어렵다.

셋째, 보안 공격면 확대다. 함수 호출 기능은 전통적 RBAC, OAuth, JWT 프로토콜을 넘어서는 새로운 가드레일을 요구한다. 에이전트 상호운용성 프로토콜 서베이는 프롬프트 인젝션을 통한 신원 스푸핑, 메시지 변조, 오퍼니드 리소스 남용을 주요 위협으로 꼽으며, TLS와 암호화 서명(JWS), 불변 매니페스트, 감사 로깅의 중요성을 강조한다.

넷째, 거버넌스 공백이다. Gartner 계열 가트너는 2027년 말까지 에이전틱 AI 프로젝트의 40% 이상이 부적절한 리스크 통제 등을 이유로 취소될 것으로 전망한다. SOA 1.0이 과도한 중앙화로 실패했다면, SOA 2.0은 과도한 탈중앙화와 거버넌스 부재로 같은 함정에 빠질 수 있다.

---

프로토콜 생태계의 분화 — 단일 표준은 없다

2025년 한 해 동안 등장한 에이전트 통신 프로토콜의 수는 이 분야가 얼마나 빠르게 움직이는지를 보여준다. MCP(Anthropic, 2024년 11월), ACP(IBM, 2025년 3월), A2A(Google, 2025년 4월), ANP가 각각 다른 문제를 해결하기 위해 설계됐다.

이 프로토콜들의 선택은 배포 맥락에 따라 달라진다. 단일 LLM과 외부 도구를 단단히 통합하려면 MCP가 최적이다. 다양한 에이전트 프레임워크에 걸쳐 멀티모달 메시징이 필요하면 ACP가 적합하다. 신뢰된 엔터프라이즈 경계 안에서 에이전트 간 동적 협상이 필요하면 A2A를 선택한다. 탈중앙화된 개방 인터넷에서 암호화 신원(DID)을 기반으로 에이전트 마켓플레이스를 구축하려면 ANP가 필요하다.

현실에서는 단계적 도입이 권장된다. 에이전트 상호운용성 서베이는 4단계 경로를 제안한다: ① MCP로 단일 LLM의 도구 호출 기반을 닦고 → ② ACP로 다양한 프레임워크 간 멀티모달 메시징을 도입하며 → ③ A2A로 엔터프라이즈 내부 에이전트 워크플로를 조정하고 → ④ ANP로 탈중앙화 개방 생태계로 확장한다. 이 경로는 SOA가 한 번에 모든 것을 해결하려다 실패한 교훈을 반영한다.

---

중소기업 시사점 — 지금 무엇을 준비해야 하는가

SOA 2.0은 대기업만의 이야기가 아니다. 중소기업에게 이 전환은 오히려 기회일 수 있다. 과거 SOA의 장벽이 높은 기술 복잡성과 전문 인력 부족이었다면, AI 기반 SOA 2.0은 진입 장벽을 낮춘다. 자연어로 의도를 표현하면 AI가 API 연동을 처리하는 세상이 눈앞에 있다.

• MCP를 지원하는 SaaS 도구를 선택 기준에 포함하라. CRM, ERP, 회계 소프트웨어를 새로 도입하거나 교체할 때, 해당 서비스가 MCP 서버를 제공하는지 또는 표준 API를 공개하는지를 평가 기준으로 삼아라. AI 에이전트 시대에 폐쇄적 시스템은 통합 비용을 기하급수적으로 높인다.
• 비결정성을 인식하고 안전망을 설계하라. AI가 API 호출을 자율적으로 결정하는 구간에는 항상 사람의 확인(Human-in-the-loop) 단계를 두어라. 특히 결제, 계약, 개인정보 처리와 관련된 작업은 AI의 판단을 그대로 자동화하면 안 된다.
• 레거시 API부터 점검하라. 외부에 노출된 내부 API가 있다면, 그 인터페이스가 자연어 설명으로 표현될 수 있는지 검토하라. OpenAPI 명세를 최신화하고, 각 엔드포인트의 역할을 명확한 자연어로 문서화하는 것이 SOA 2.0 대비의 첫걸음이다.
• 소규모로 실험을 시작하라. Claude, ChatGPT, Gemini 같은 AI 도구에서 MCP 서버를 연결해 내부 업무를 자동화하는 파일럿을 진행해 보라. 벡터 DB나 복잡한 인프라 없이도 MCP 기본 구조를 경험할 수 있다. 이 경험이 나중에 큰 아키텍처 결정을 내릴 때 실질적 판단 기준이 된다.
• SOA 1.0의 실수를 반복하지 마라. IBM의 분석이 지적하듯, 마이크로서비스 전환에서 가장 흔한 실수는 “데이터베이스를 공유하는 서비스” 또는 “새로운 ESB가 된 API Gateway”다. AI 오케스트레이터가 그 역할을 대신할 때도 같은 함정이 존재한다. 중앙 AI 에이전트가 모든 결정을 독점하는 구조는 결국 새로운 ESB다.
• 지연 시간이 허용되지 않는 경로를 미리 식별하라. 재고 조회, 보고서 생성 같은 비실시간 업무는 AI 오케스트레이션에 적합하다. 결제 처리, 실시간 재고 감산처럼 마이크로초 응답이 필요한 경로는 전통적 API를 유지해야 한다. 이 구분을 설계 초기에 명확히 해야 한다.

---