MCP가 주목받는 이유와 실제 적용의 한계

“이번 주 A사업부의 실적과 주요 이슈를 정리해 줘.”

사용자에게는 하나의 질문이지만, 인공지능(Artificial Intelligence, AI) 에이전트가 답을 찾는 과정은 단순하지 않습니다. 실적은 비즈니스 인텔리전스(Business Intelligence, BI) 시스템에서 확인하고, 주요 이슈는 Weekly 시스템에서 찾아야 합니다. 관련 정책이나 과거 사례가 필요하다면 사내 문서 시스템도 검색해야 합니다. 기업의 정보가 데이터베이스, BI, 업무 시스템, 문서 저장소 등 여러 곳에 분산돼 있기 때문입니다.

여러 사내 시스템을 AI 에이전트와 연결하는 표준으로 모델 콘텍스트 프로토콜(Model Context Protocol, MCP)이 주목받고 있습니다. MCP는 AI 에이전트와 여러 사내 시스템을 표준 방식으로 연결하는 프로토콜입니다. MCP를 이용하면 각 시스템의 데이터와 기능을 AI가 사용할 수 있는 도구(Tool) 형태로 제공할 수 있습니다.

그러나 실제로 MCP를 적용하면 연결만으로 해결되지 않는 문제가 나타납니다.

MCP는 AI가 사용할 수 있는 Tool을 제공하지만, 그 Tool을 업무에 맞게 어떤 순서와 조건으로 사용해야 하는지는 결정해 주지 않습니다.

사내 경영정보 조회 AI 에이전트를 구축하는 과정에서도 같은 문제를 경험했습니다. BI, Weekly, 사내 문서 시스템을 각각 MCP로 연결했지만, 대형 언어모델(Large Language Model, LLM)이 MCP 안에 등록된 여러 Tool을 기대만큼 안정적으로 사용하지 못했습니다.

이 글에서는 MCP가 Tool의 업무별 실행 순서와 조건을 결정하지 않으며, LLM이 등록된 여러 Tool을 안정적으로 사용하지 못하는 문제를 해결하기 위해 적용한 두 가지 방법, 즉 시스템별 서브 에이전트(Sub-Agent)와 SKILL.md를 활용한 Tool 실행 설계를 살펴봅니다. 이어서 기업 환경에서 이와 별도로 반드시 고려해야 하는 사용자별 인증·인가 설계도 함께 다룹니다.

MCP 도구 선택 오류가 발생하는 이유

BI시스템의 애플리케이션 프로그래밍 인터페이스(Application Programming Interface, API)를 MCP로 연결한다고 가정해 보겠습니다. 이제 AI에이전트는 BI시스템을 호출할 수 있습니다. 필요한 시스템 연결은 이 단계에서 완료됩니다.

하지만 실제 업무 시스템의 API는 하나의 단순한 조회 기능으로 구성되지 않습니다. BI MCP 안에는 다음과 같은 API가 각각 Tool로 등록될 수 있습니다.

1. 조회 가능한 테이블 목록 확인
2. 특정 테이블에서 사용할 수 있는 파라미터 확인
3. 테이블과 파라미터를 지정해 실제 데이터 조회

사용자가 “이번 주 A사업부의 실적을 알려줘”라고 질문하면 AI는 먼저 적절한 테이블을 선택해야 합니다. 이후 해당 테이블에서 사용할 수 있는 파라미터를 확인하고, 사용자의 표현을 조직 코드나 기준주차처럼 시스템이 이해할 수 있는 값으로 변환해야 합니다. 필요한 조건이 모두 준비된 뒤에야 실제 데이터 조회 Tool을 호출할 수 있습니다.

사람이 보기에는 자연스러운 절차이지만, LLM에는 여러 선택지가 주어집니다.

비슷한 이름의 테이블이 여러 개 있을 수 있고, 유사한 의미의 파라미터가 함께 제공될 수도 있습니다. 같은 ‘사업부’라는 조건도 어떤 API에서는 조직 코드로, 다른 API에서는 사업 단위 코드로 표현될 수 있습니다. 기간 역시 기준일, 기준월, 기준주차 중 무엇을 사용해야 하는지 판단해야 합니다.

이러한 정보만 Tool 설명으로 제공하면 LLM은 관련성이 낮은 테이블을 선택하거나, 잘못된 파라미터를 넣거나, 필수 조건을 확인하기 전에 데이터 조회를 시도할 수 있습니다. 결과가 비어 있으면 다시 테이블 목록과 파라미터 목록을 확인하면서 호출을 반복하기도 합니다. 실제로 메타데이터 확인, 조회 대상 선택, 데이터 조회 기능 사이를 오가며 불필요한 호출과 재시도가 늘어나는 문제가 나타났습니다.

문제는 단순히 API가 많다는 데 있지 않습니다.

각 API 사이에 선후 관계가 있고, 적절한 테이블과 파라미터를 선택하려면 업무 지식이 필요하다는 점이 핵심입니다.

MCP는 Tool을 호출할 수 있는 연결 구조를 제공합니다. 그러나 Tool 사이의 업무적 관계와 실행 순서까지 자동으로 구성해 주지는 않습니다.

서브 에이전트와 SKILL.md를 활용한 실행 설계

MCP 도구 선택 오류를 줄이려면 시스템별 전문 서브 에이전트로 탐색 범위를 제한하고, 각 에이전트에 SKILL.md 기반의 도구 호출 시나리오를 적용해야 합니다. 서브 에이전트는 어떤 시스템을 사용할지 판단하는 범위를 줄이고, SKILL.md는 해당 시스템에서 어떤 도구를 어떤 순서와 조건으로 호출할지 정의합니다.

아래 그림 1은 메인 에이전트가 사용자의 질문을 업무 영역별로 나누고, BI·Weekly·문서 시스템을 담당하는 전문 서브 에이전트에 요청을 전달하는 구조를 보여줍니다

^{[그림 1. MCP 기반 멀티에이전트 구성도]}

시스템별 전문 서브 에이전트 구성

메인 에이전트가 모든 시스템의 세부 Tool을 직접 다루게 하면 판단해야 할 범위가 지나치게 넓어집니다. BI Tool과 Weekly Tool, 문서 검색 Tool이 한꺼번에 주어지면 메인 에이전트는 어느 시스템을 사용할지 결정하는 것부터 각 시스템의 API 사용법까지 모두 판단해야 합니다.

이를 시스템별 전문 에이전트로 분리했습니다.

메인 에이전트는 질문에 어떤 정보가 필요한지를 판단합니다. “이번 주 A사업부의 실적과 주요 이슈를 정리해 줘”라는 질문이라면 실적 조회는 BI 전문 에이전트에, 주요 이슈 조회는 Weekly 전문 에이전트에 맡깁니다. 필요하면 문서 전문 에이전트를 추가로 호출합니다.

반면 BI 전문 에이전트는 BI MCP만 사용합니다. Weekly 전문 에이전트와 문서 전문 에이전트도 각각 자신이 담당하는 MCP만 다룹니다.

BI 전문 서브 에이전트는 BI MCP의 도구만 사용하고, Weekly 전문 서브 에이전트와 문서 전문 서브 에이전트도 각각 담당 MCP의 도구만 사용합니다. 이처럼 역할을 분리하면 각 에이전트가 탐색해야 하는 Tool의 범위를 줄일 수 있습니다. 메인 에이전트는 어떤 업무 영역에 요청을 보낼지 결정하고, 전문 에이전트는 자신이 담당하는 시스템 안에서 조회 방법을 판단합니다.

SKILL.md를 활용한 MCP 도구 호출 순서 설계

SKILL.md에는 질문 유형별로 우선 확인할 테이블, 선택할 파라미터, 도구 호출 순서, 필수 조건 검증, 실패 시 재확인 절차와 종료 기준을 정의해 MCP 도구 실행 경로를 설계합니다. 각 전문 서브 에이전트는 이 실행 기준에 따라 담당 MCP 도구를 호출합니다.

서브 에이전트가 담당 범위를 좁혀 주더라도, MCP 내부에는 여전히 여러 Tool과 파라미터가 존재합니다. 어떤 테이블을 먼저 확인할지, 어떤 조건을 사용할지, 어느 시점에 실제 조회 API를 호출할지에 대한 기준이 필요합니다.

이를 위해 각 전문 에이전트에 Skill을 적용했습니다. 실제 구현에서는 이 가이드를 SKILL.md 형태로 관리했습니다.

예를 들어 BI Skill에는 다음과 같은 내용이 포함될 수 있습니다.

Skill은 단순한 API 설명서가 아닙니다. 질문 유형에 따라 어떤 Tool을 먼저 호출하고, 어떤 테이블과 파라미터를 선택하며, 실패했을 때 무엇을 다시 확인하고, 언제 조회를 종료할지를 정리한 실행 시나리오입니다.

서브 에이전트와 Skill은 서로 다른 역할을 담당합니다.

서브 에이전트가 탐색 범위를 좁힌다면, Skill은 그 범위 안에서 따라야 할 실행 경로를 구체화합니다.

전문 서브 에이전트와 SKILL.md를 함께 적용하면 LLM이 유사한 테이블과 파라미터 사이를 반복적으로 탐색하는 문제를 줄이고, 질문 유형에 적합한 API 호출 경로를 우선적으로 선택하도록 할 수 있습니다.

시스템별 API나 조회 기준이 변경됐을 때도 해당 전문 에이전트와 Skill을 중심으로 실행 기준을 수정할 수 있습니다. 메인 에이전트 전체의 지시문이나 다른 시스템의 로직까지 함께 수정하지 않아도 되기 때문입니다.

물론 모든 MCP 환경에 서브 에이전트와 Skill이 필요한 것은 아닙니다. Tool 수가 적고 호출 절차가 단순하다면 하나의 에이전트가 직접 처리해도 충분합니다. 하지만 하나의 MCP 안에 여러 API와 파라미터가 있고, 그 사이에 업무적 선후 관계가 존재한다면 별도의 실행 가이드가 필요해집니다.

MCP 환경의 사용자 인증·인가 및 접근 통제

기업 환경에서는 Tool 실행의 정확성과 효율성 외에도 반드시 고려해야 할 문제가 있습니다. 바로 사용자별 인증·인가입니다.

AI 에이전트가 BI나 사내 문서 시스템을 호출할 수 있다는 사실과, 현재 질문한 사용자가 해당 정보를 볼 수 있다는 사실은 서로 다릅니다. 같은 질문이라도 사용자의 소속 조직과 직무, 문서 열람 권한에 따라 조회할 수 있는 정보의 범위가 달라져야 합니다.

사용자는 하나의 채팅창에서 질문하지만, 실제 요청은 메인 에이전트와 전문 에이전트, MCP를 거쳐 여러 업무 시스템으로 전달됩니다. 따라서 사용자가 누구인지와 어떤 범위까지 접근할 수 있는지가 전체 호출 경로에서 유지되어야 합니다.

이번에 구축한 사내 경영정보 조회 AI 에이전트 구조에서는 별도의 백엔드에서 사용자 신원과 권한 정보를 확인하고, 각 MCP가 해당 사용자에게 허용된 범위 안에서 시스템을 조회하도록 구성했습니다.

인증(Authentication)은 사용자가 누구인지 확인하는 과정이며, 인가(Authorization)는 확인된 사용자가 어떤 정보와 기능에 접근할 수 있는지를 판단하는 과정입니다. MCP로 시스템을 연결했다고 해서 기존 시스템의 사용자별 권한이 자동으로 AI 에이전트에 적용되는 것은 아닙니다.

중요한 원칙은 사용자의 권한을 에이전트의 판단에만 맡겨서는 안 된다는 것입니다.

프롬프트나 Skill에 “권한이 없는 정보는 조회하지 않는다”는 지침을 작성하는 것만으로 접근 통제가 완성되지는 않습니다. 호출 전략을 안내하는 실행 가이드와 실제 데이터 접근을 통제하는 보안 정책은 서로 다른 역할을 합니다.

사용자 식별과 권한 검증은 백엔드, MCP 또는 실제 업무 시스템처럼 정책을 강제할 수 있는 신뢰 영역에서 수행해야 합니다. 또한 누가 어떤 시스템을 통해 어떤 정보를 조회했는지 추적할 수 있도록 감사 체계도 함께 고려해야 합니다.

사내 정보 통합 조회와 의사결정 지원

사내 경영정보 조회 AI에이전트 시스템이 현업에 제공하는 변화는 BI, Weekly, 사내 문서 및 보고서에 흩어진 정보를 하나의 대화에서 함께 활용할 수 있게 했다는 점입니다. 사용자가 실적과 주요 이슈를 함께 요청하면 에이전트가 필요한 시스템의 정보를 조회해 하나의 맥락으로 정리합니다. 사용자는 시스템별로 질문을 나누거나 조회 결과를 직접 취합할 필요가 없습니다.

고객이 얻는 가치는 단순히 조회 창구가 하나로 통합되는 데 그치지 않습니다. 시스템별 서브 에이전트와 SKILL.md를 통해 질문에 적합한 정보 소스와 조회 절차를 적용하고, 사용자별 인증·인가를 통해 허용된 범위의 데이터만 사용합니다. 이에 따라 사용자는 여러 검색 결과를 단순히 모아 놓은 답변이 아니라, 업무 기준과 접근 권한이 반영된 통합 결과를 받을 수 있습니다.

현업의 정보 활용 방식도 개별 데이터를 찾고 조합하는 과정에서, 통합된 결과를 해석하고 판단하는 방향으로 달라집니다. 최초 답변을 바탕으로 이전 기간과의 비교, 실적 변동의 원인, 관련 이슈와 근거 문서를 같은 대화에서 추가로 확인할 수 있습니다. 다양한 사내 정보에 한곳에서 접근하면서도 신뢰할 수 있는 통합 인사이트를 얻고, 이를 업무 판단에 활용할 수 있다는 점이 이 시스템이 제공하는 핵심 가치입니다.

MCP 기반 AI 에이전트 운영 시 고려사항

지금까지 살펴본 것처럼, MCP를 도입한다고 해서 AI 에이전트가 곧바로 사내 시스템을 능숙하게 다루는 것은 아닙니다. MCP가 제공하는 것은 일관된 연결 방식이며, 실제 업무에서 필요한 것은 그 위에서 Tool이 예측 가능한 절차에 따라 실행되도록 만드는 설계입니다.

어떤 Tool을 먼저 호출할지, 필요한 조건을 어떻게 확인할지, 조회가 충분한 시점에 언제 실행을 멈출지를 정하지 않으면 연결된 기능이 많아질수록 오히려 에이전트의 판단 부담도 커질 수 있습니다. 여기에 기업의 데이터가 사용자의 권한 범위 안에서만 조회되도록 통제하는 구조도 함께 갖춰져야 합니다.

이러한 설계는 한 번 완성하고 끝나는 작업도 아닙니다. 업무상 조회 기준이 변경되거나 새로운 테이블과 파라미터가 추가될 때, 전문 에이전트의 역할과 Skill도 함께 보완해야 합니다. 따라서 Skill은 적용 결과를 관찰하면서 불필요한 재시도를 줄여 나가며 에이전트의 동작을 최적화하는 운영 자산에 가깝습니다.

기업이 MCP 기반 AI 에이전트의 완성도를 판단할 때도 ‘몇 개의 시스템을 연결했는가’만을 기준으로 삼아서는 안 됩니다. 같은 유형의 질문에 일관되게 답변하는지, 허용된 권한 범위 내에서 결과를 반환하는지 등을 함께 살펴봐야 합니다.

MCP는 AI 에이전트가 사내 시스템에 접근할 수 있게 만드는 출발점입니다. 여기에 예측 가능한 도구 실행 절차, 사용자별 접근 통제, 지속적인 개선 체계를 함께 적용해야 MCP를 실제 업무 수행 방식으로 활용할 수 있습니다.

▌요약

• 모델 콘텍스트 프로토콜(MCP)은 AI 에이전트와 사내 시스템을 연결하지만, 여러 도구의 업무적 선후 관계와 실행 조건까지 자동으로 설계하지는 않습니다.
• 시스템별 전문 서브 에이전트는 탐색 범위를 줄이고, SKILL.md에 정의한 실행 시나리오는 테이블·파라미터 선택, 실패 시 재확인, 조회 종료 기준을 구체화합니다.
• MCP 기반 업무 시스템에서는 인증과 인가를 에이전트의 판단에만 의존하지 않고, 백엔드·MCP·업무 시스템 등 정책을 강제할 수 있는 영역에서 적용해야 합니다.
• 운영 단계에서는 답변의 일관성, 권한 범위 준수, 불필요한 재시도 감소 여부를 관찰하고 전문 에이전트와 SKILL.md를 지속적으로 보완해야 합니다.

▌ FAQ

Q1. MCP만 연결하면 AI 에이전트가 사내 업무 시스템을 바로 사용할 수 있나요?

A1. MCP만 연결해서는 AI 에이전트가 사내 업무 시스템을 안정적으로 사용할 수 없습니다. MCP는 AI 에이전트가 사내 시스템의 데이터와 기능을 사용할 수 있도록 연결 구조를 제공합니다. 그러나 여러 도구의 업무적 선후 관계, 파라미터 선택 기준, 실패 시 재시도와 종료 조건까지 자동으로 정해 주지는 않으므로 별도의 실행 설계가 필요합니다.

Q2. MCP 도구가 많을 때 서브 에이전트는 왜 필요한가요?

A2. MCP 도구가 많은 환경에서는 시스템별 전문 서브 에이전트를 구성해야 각 에이전트가 탐색해야 하는 도구의 범위를 줄일 수 있습니다. 메인 에이전트는 필요한 업무 영역을 선택하고, 전문 에이전트는 담당 시스템 안에서 적절한 조회 방법을 판단합니다.

Q3. MCP 도구 실행을 위한 SKILL.md에는 어떤 내용을 작성해야 하나요?

A3. MCP 도구 실행을 위한 SKILL.md에는 질문 유형별 도구 호출 순서, 테이블과 파라미터 선택 기준, 필수 조건 확인 절차, 실패 시 재확인 항목, 조회 종료 기준을 작성해야 합니다. 단순한 API 설명보다 실제 업무 흐름에 따른 실행 시나리오를 중심으로 구성하는 것이 중요합니다.

Q4. MCP 기반 AI 에이전트의 인증·인가는 어디에서 처리해야 하나요?

A4. MCP 기반 AI 에이전트의 인증·인가는 백엔드·MCP·업무 시스템 등 접근 정책을 강제할 수 있는 계층에서 처리해야 합니다. 사용자 식별과 권한 검증은 프롬프트나 에이전트의 판단에만 맡기지 않아야 합니다. 백엔드, MCP 또는 실제 업무 시스템처럼 정책을 강제할 수 있는 신뢰 영역에서 사용자의 권한을 확인하고, 전체 호출 경로에서 해당 권한을 유지해야 합니다.

Q5. MCP 기반 AI 에이전트의 운영 품질은 어떻게 평가하나요?

A5. MCP 기반 AI 에이전트의 운영 품질은 연결한 시스템 수만으로 평가하기보다 같은 유형의 질문에 일관되게 답하는지, 허용된 권한 범위 안에서 결과를 반환하는지, 불필요한 호출과 재시도가 줄어드는지를 함께 확인해야 합니다. 운영 결과에 따라 전문 에이전트의 역할과 SKILL.md도 지속적으로 보완해야 합니다.

관련 오퍼링 및 문의하기

• Agentic AI | LG CNS | Korea
• LG CNS 홈페이지 문의하기

본 콘텐츠는 저작권법에 의해 보호받는 저작물로 LG CNS에 저작권이 있습니다.

사전 동의 없이 2차 가공 및 영리적인 이용을 금합니다.