MCP 프로토콜을 활용한 사내 AI 에이전트 자동화 도입기

MCP 프로토콜을 활용한 사내 AI 에이전트 자동화 도입기

이러한 문제를 해결하기 위해 처음 도입했던 MCP 서버의 통신 로그 화면을 보면 그 이유를 알 수 있다.

위 화면은 MCP를 통해 외부 데이터를 조회하려던 에이전트가 통신 에러에 빠진 상태를 캡처한 것이다. 이 에러 로그를 분석하면서 에이전트 자동화의 진정한 벽을 만나게 되었다.

1. 시작하며: 끝없는 파이썬 스크립트 작성에서 벗어나기 위해

최근 사내 업무 효율을 극대화하기 위해 다양한 AI 에이전트 도입을 검토하고 있었습니다. 기존의 사내 자동화는 지라(Jira)에서 이슈를 가져오거나 깃허브(GitHub)의 코드 리뷰 요청을 읽어오기 위해 매번 새로운 파이썬 스크립트를 작성해야만 했습니다.

단순 반복 작업임에도 불구하고 연동할 외부 도구가 추가될 때마다 API 코드를 하드코딩하고 유지보수하는 일은 심각한 리소스 낭비였습니다. 그러던 중 모델 컨텍스트 프로토콜(MCP, Model Context Protocol)이라는 새로운 표준 기술을 접했습니다.

LLM이 로컬 파일 시스템이나 외부 데이터 소스에 '표준화된 방식'으로 접근할 수 있게 해주는 이 기술은 매우 매력적이었습니다. 매번 복잡한 연동 코드를 짜지 않아도, 에이전트가 스스로 필요한 도구를 찾아 쓸 수 있는 '에이전트 중심의 유연한 자동화 환경'을 구축하는 것, 이것이 이번 프로젝트의 출발점이었습니다.

2. 우리가 꿈꿨던 이상적인 자동화 (기대효과)

MCP 도입을 통해 가장 크게 기대했던 것은 단연 '유연성'과 '확장성'이었습니다. 이론상 MCP 서버만 띄워두면 AI 에이전트가 알아서 데이터베이스 구조를 파악하고 쿼리를 실행해 결과를 가져올 수 있었기 때문입니다.

우리는 다음과 같은 유기적인 워크플로우를 상상했습니다.

"오늘 들어온 고객 문의 중 긴급한 것만 추려줘"

사용자가 메신저에 이렇게 입력하면, 에이전트가 알아서 '슬랙(Slack) MCP'와 '고객 DB MCP'를 차례로 호출합니다. 복잡한 프롬프트 엔지니어링이나 중간 데이터 파이프라인 없이도, 에이전트가 자율적으로 도구를 선택하고 연결해 보고서까지 작성해 내는 안정적인 그림을 그렸습니다.

상황을 분석하는 파이선생 캐릭터

하지만 실제 현업에 도입하기 위해 코드를 돌려보았을 때, 이 훌륭한 시나리오는 처참하게 무너져 내렸다.

3. 현실의 벽: 에러의 늪과 무한 루프

하지만 초기 프로토타입을 완성하고 마주한 현실은 기대와는 정반대였습니다. 에이전트에게 간단한 사내 데이터 조회를 요청하자, 시스템이 그대로 멈춰버리는 현상이 발생했습니다. 로그를 확인해 보니 에이전트는 끔찍한 '무한 루프'에 빠져 있었습니다.

• 끊임없는 재요청: 도구(Tool) 실행 결과를 제대로 처리하지 못한 채 동일한 요청을 수십 번씩 반복했습니다.
• 존재하지 않는 도구 호출: 스키마에 없는 엉뚱한 도구 이름을 지어내는 환각(Hallucination) 현상이 나타났습니다.
• 필요 파라미터 누락: 검색에 꼭 필요한 값을 빼먹은 채 요청을 보내 서버에서 에러를 발생시켰습니다.

결국 자동화의 편리함은커녕, 끝없이 올라가는 에러 로그와 무의미하게 소모되는 API 호출 비용만을 바라봐야 하는 난감한 상황에 직면했습니다.

4. 문제의 진짜 원인을 찾아서 (가설과 검증)

가설 1. AI 모델의 환각(Hallucination) 현상인가? 처음에는 에이전트가 프롬프트를 제대로 이해하지 못해 엉뚱한 도구를 호출한다고 생각했습니다.

가설 2. 네트워크 지연(Latency)에 따른 타임아웃인가? 로컬 환경의 MCP 서버 응답이 미세하게 늦어지자, 모델이 이를 실패로 간주하고 '타임아웃 재시도'를 하는 것이라 의심했습니다. 시스템 프롬프트에 "반드시 한 번만 호출하고 기다리라"는 강력한 지시를 추가하고, 네트워크 타임아웃 시간도 대폭 늘려보았습니다. 하지만 문제는 전혀 해결되지 않았습니다.

수많은 테스트와 로그 분석 끝에, 우리는 진짜 원인 두 가지를 찾아냈습니다.

1. MCP 도구 스키마(Schema)의 모호성 에이전트에게 제공한 도구 설명이 일상어처럼 너무 포괄적이었습니다. 예를 들어 날짜를 입력해야 할 때, 이것이 2023-10-01 형태여야 하는지, 오늘이라는 텍스트여야 하는지 명확한 타입(Type) 지정이 없으니 에이전트가 잘못된 값을 던지고 있었습니다.
2. 에러 피드백 루프(Error Feedback Loop)의 부재 파라미터 누락으로 에러가 발생했을 때, 서버는 친절한 설명 없이 시스템 에러 코드만 뱉거나 연결을 끊어버렸습니다. 에이전트 입장에서는 '왜' 실패했는지 알 길이 없으니, 성공할 때까지 기존의 잘못된 방식을 고집하며 무한 재시도를 했던 것입니다.

5. 시스템 구조 전면 개편: 에이전트에게 제대로 일 시키는 법

진짜 원인을 파악한 후, 에이전트와 MCP 서버가 통신하는 구조를 대대적으로 뜯어고쳤습니다.

• 도구 스키마의 엄격한 정의 JSON 스키마를 활용해 파라미터의 데이터 타입(String, Integer 등)을 강제했습니다. 각 파라미터가 어떤 형태여야 하는지 정규식(Regex) 수준으로 아주 구체적이고 엄격한 설명을 추가했습니다.
• 친절한 에러 피드백 로직 보강 (핵심) 서버에서 에러가 발생하면, 단순히 HTTP 400이나 500 에러를 뱉고 끊는 대신 "날짜 형식이 틀렸습니다. YYYY-MM-DD 형식으로 다시 요청해 주세요"와 같은 구체적인 가이드 메시지를 에이전트에게 리턴하도록 수정했습니다. 이 피드백을 받은 에이전트는 스스로 파라미터를 수정하여 즉시 재요청에 성공했습니다.

결과적으로, 이 두 가지 근본적인 변화 덕분에 에이전트의 무한 루프 현상은 깔끔하게 사라졌으며, 이제는 우리가 의도한 대로 훌륭하게 자동화된 워크플로우를 보여주고 있습니다.