<잇(IT)터뷰 전체 영상 보기>
잇(IT)터뷰 전체 내용은 ▼아래 영상▼에서 확인해 주세요!
◼ 게스트 : 김현수 상무 / 워카토 (korea@workato.com)
◼ 진행자 : 고우성 PD / 토크아이티 (talkit@talkit.tv, https://talkit.tv/)
<잇(IT)터뷰 – 핵심 내용 파악하기>
‘잇(IT)터뷰 – 핵심 내용 파악하기’는 영상의 핵심 내용을 정리한 글입니다.
|
이번 잇(IT)터뷰는 AI가 회사에서 실제로 일을 하려면 왜 MCP가 필요한지 구조적으로 설명한다.
핵심은 LLM이 답변만 잘하는 수준을 넘어, 기업의 실제 시스템과 데이터를 안전하게 연결해 조회하고 실행까지 해야 비로소 업무형 AI가 된다는 점이다.
1. 기업용 AI가 실제 일을 못하는 가장 큰 이유는 컨텍스트가 시스템 안에 갇혀 있기 때문이다
많은 기업이 AI를 도입했지만, 실제로는 “대답을 잘하는 AI”에 머무는 경우가 많다. 이유는 간단하다. 회사 업무의 핵심 맥락은 세일즈포스, SAP, 오라클, 워크데이 같은 실제 업무 시스템 안에 들어 있기 때문이다. 고객 정보, 주문 상태, 승인 이력, 재고 데이터, 인사 정보처럼 진짜 업무에 필요한 데이터는 애플리케이션 안에 살아 있는데, AI가 이 시스템과 직접 연결되지 못하면 실시간 맥락을 이해할 수 없다.
그래서 단순히 학습된 지식이나 벡터DB 기반 검색만으로는 한계가 생긴다. 검색 증강 방식은 과거 데이터를 참고하는 데는 도움이 되지만, 현재 시점의 정확한 상태를 보장하지는 못한다. 결국 AI는 추론과 응답은 할 수 있어도 실시간성이 떨어지고, 최신 정보와 어긋날 수 있으며, 중요한 액션을 직접 수행하지도 못한다. 기업이 원하는 것은 “설명하는 AI”가 아니라 “조회하고, 판단하고, 실행하는 AI”이기 때문에, 이 간극을 메우는 연결 표준이 필요해진다.
2. MCP의 본질은 모델과 실제 업무 컨텍스트를 연결하는 개방형 표준이다
MCP는 Model Context Protocol의 약자다. 여기서 모델은 클로드, 챗GPT 같은 AI 모델을 뜻하고, 컨텍스트는 실제 업무 맥락이 담긴 데이터와 시스템을 뜻한다. 프로토콜은 이 둘을 연결하는 규격이다. 즉 MCP는 AI 모델이 기업의 외부 시스템과 표준화된 방식으로 연결되도록 만드는 개방형 연결 규격이라고 이해하면 된다.
이 정의가 중요한 이유는 MCP가 단순한 API 호출 기법이 아니라는 점 때문이다. MCP는 벤더 종속성을 줄이고, 서로 다른 시스템을 단일한 방식으로 연결하려는 목적을 가진다. 기업 환경에서는 시스템이 하나가 아니라 CRM, ERP, HR, 재무, 협업 도구가 동시에 얽혀 있기 때문에, 연결 방식이 제각각이면 AI가 확장될수록 구조가 복잡해진다. MCP는 이런 복잡성을 줄이고, AI가 기업 시스템에 접근하는 공통 언어를 제공한다.
결국 MCP는 AI가 비즈니스 시스템을 “읽기만” 하는 수준이 아니라 “표준적으로 연결되고 실행되는” 구조로 넘어가기 위한 기반이다.
3. MCP 구조는 단순하지만, 이 단순한 구조가 AI를 응답 엔진에서 업무 엔진으로 바꾼다
MCP 구조 자체는 비교적 단순하다. 한쪽에는 LLM이나 에이전트가 있는 MCP 호스트가 있고, 다른 한쪽에는 실제 컨텍스트를 가진 애플리케이션이 있다. 그 사이를 MCP 서버가 연결한다. LLM은 사용자의 요청 의도를 파악한 뒤, 어떤 도구가 있는지 MCP를 통해 확인하고, 그중 적절한 도구를 선택해 필요한 파라미터와 함께 호출한다. 이후 MCP 서버가 해당 애플리케이션과 통신해 데이터를 조회하거나 수정하고, 그 결과를 다시 LLM으로 돌려준다.
이 흐름의 핵심은 AI가 더 이상 추측으로만 답하지 않는다는 점이다. 예를 들어 주문 상태를 묻거나 승인 요청을 처리하거나 특정 정보를 갱신해야 할 때, MCP가 있으면 AI는 실제 시스템에 접근해 결과를 가져오고 필요한 액션도 실행할 수 있다. 이 구조가 갖춰져야 에이전트라는 개념이 의미를 가진다. 에이전트는 의도를 이해하는 것만으로 끝나지 않고, 필요한 시스템을 찾아 연결하고, 그 안에서 실제 작업을 수행해야 하기 때문이다. MCP는 바로 이 “의도에서 실행까지”의 중간 계층 역할을 한다.
4. MCP를 붙인다고 모든 문제가 해결되는 것은 아니며, 오히려 단순한 MCP 확산은 새로운 문제를 만든다
MCP가 중요하다고 해서 아무 방식으로나 많이 붙이면 되는 것은 아니다. 가장 대표적인 문제는 단순 API 래핑 형태의 Thin MCP다. 각 시스템의 기본 API를 그대로 MCP 형태로 감싸서 붙이는 방식은 처음에는 빠르고 간단해 보인다. 하지만 연결해야 할 시스템이 많아질수록 MCP 개수가 급격히 늘어나고, 이 정보들이 LLM의 컨텍스트 윈도우를 점점 더 점유하게 된다. 그러면 정작 추론에 써야 할 공간이 줄어들고, 불필요한 토큰 사용량이 늘어나며, 비용이 커지고, 결국 맥락을 잃은 환각 가능성도 높아진다.
여기에 운영 문제도 생긴다. MCP 서버가 많아지면 권한 제어, 액션 추적, 중앙 모니터링이 어려워진다. 누가 어떤 MCP를 쓰고 있는지, 어떤 요청이 어떤 시스템에 어떤 영향을 줬는지, 중복된 MCP가 어디에서 생기고 있는지 파악하기가 힘들어진다. 이 상태가 되면 MCP는 연결 해법이 아니라 새로운 보안 홀과 관리 복잡성을 만드는 요소가 될 수도 있다. 기업 입장에서는 단순히 “MCP를 도입했다”가 아니라, “MCP를 어떤 방식으로 통제하고 운영할 것인가”가 더 중요해진다.
5. 결국 기업의 선택은 DIY, 애플리케이션 MCP, 엔터프라이즈 MCP 중 어떤 운영 모델을 택할 것인가로 귀결된다
MCP 도입의 갈림길은 세 가지로 나뉜다.
첫째는 직접 만드는 DIY 방식이다. 유연성은 높지만, 구축 이후 유지보수와 확장 부담이 기업 내부로 그대로 돌아온다.
둘째는 애플리케이션 벤더가 제공하는 MCP를 활용하는 방식이다. 특정 시스템 연결은 빠를 수 있지만, 시스템 수가 늘어나면 분산 관리와 중복 구축 문제가 생기기 쉽다.
셋째는 엔터프라이즈 MCP 접근이다. 중앙에서 연결, 권한, 모니터링, 재사용을 관리하는 구조에 더 가깝다.
이 선택은 단순한 기술 취향 문제가 아니다. 기업 규모가 커질수록 시스템 수가 많아지고, 보안 요구가 높아지고, 여러 팀이 동시에 에이전트를 만들기 시작한다. 이런 환경에서는 개별 MCP를 각자 만드는 방식이 빠르게 한계에 부딪힌다.
결국 중요한 질문은 “MCP를 쓸까 말까”가 아니라 “MCP를 어떻게 거버넌스 가능한 구조로 운영할 것인가”다. 회사에서 진짜로 일하는 AI를 만들려면 연결 자체보다 연결의 통제, 권한, 재사용, 운영 체계가 더 중요해진다.
6. 3줄 요약
– 기업용 AI가 실제 일을 하지 못하는 가장 큰 이유는 업무 맥락이 담긴 데이터와 시스템에 직접 연결되지 못하기 때문이다.
– MCP는 AI 모델과 실제 업무 컨텍스트를 연결하는 개방형 표준으로, 조회와 실행이 가능한 업무형 AI의 기반이 된다.
– 하지만 단순한 MCP 확산은 컨텍스트 윈도우, 비용, 환각, 권한 통제, 모니터링 문제를 만들 수 있어 운영 구조까지 함께 설계해야 한다.
◼ 전체 잇(IT)터뷰 내용은 ▶영상으로 바로 가기(클릭)◀에서 확인하실 수 있습니다. |
◼ 콘텐츠 & 웨비나 문의 : marketing@talkit.tv, 02-565-0012
Copyright ⓒ 토크아이티 All rights reserved. 무단 전재 및 재배포 금지.