본 문서는 2025년 12월 05일 기준으로 작성되었습니다.
Elasticsearch 9.2.0 버전을 사용하였으며, 해당 버전에 출시된 Elastic Agent Builder 기능과 MCP에 대해 기술합니다.
컴퓨터에 마우스와 같은 주변기기를 연결하려면 어떻게 해야할까요? 대부분은 USB 포트를 사용하여 연결할 것입니다. 우리는 서로 다른 제조사의 마우스나 키보드, 프린트 등의 주변기기들을 서로 다른 제조사의 컴퓨터에 USB 포트를 통하여 연결할 수 있습니다. 이렇게 컴퓨터와 주변기기를 연결하는 표준 규격이 USB 포트라면, 대규모 언어 모델(이하 LLM)과 외부 시스템을 연결해주는 표준 규격이 MCP라고 할 수 있습니다.
MCP(Model Context Protocol)는 말 그대로 ChatGPT와 같은 LLM을 위한 프로토콜, 통신 규약 입니다. 기존의 LLM은 단순히 질문에 대한 답변만을 제공해왔습니다. 예를 들어 메일을 쓰기 위한 초안이나, 어려운 문제풀이나, 연애 상담까지도요. MCP를 적용한다면 직접 메일을 쓰게 하거나, 문제를 직접 해결하게 할 수 있습니다. 연애는 대신해주지 못하겠지만요.😅
MCP 설명 도식화
MCP에 대한 관심과 수요는 날이 갈 수록 증가하고 있습니다. 그렇다면 정확히 무엇 때문에 MCP가 필요할까요?
첫째, LLM과 사내 시스템을 연동하고자 하는 수요가 증가했기 때문입니다. 사용자들은 이제 단순히 대답만을 하는 LLM에서 벗어나, 자연어 명령을 받아 ERP나 CRM에서 기능을 수행하는 LLM을 원하고 있습니다. 예를 들어, “이번 분기 매출 상위 10명 고객을 표로 뽑아줘”라고 말했을 때 LLM이 CRM 시스템의 API를 호출해 데이터를 조회하고 표나 그래프 형태로 정렬 및 집계하여 사용자가 보기 편한 방식으로 제공해줄 수 있습니다. 또는, "엘라스틱서치가 설치된 리눅스 서버에서 리소스 사용량과 보안위협을 조사하고 대응 방안 및 예방 가이드를 알려줘" 라고 하면 LLM이 SSH를 통해 리눅스 서버에서 쉘을 실행하고, 콘솔 출력 결과를 반환해주도록 할 수 있습니다. 이를 LLM이 명령어를 실행할 때 마다 사용자에게 허가를 받게 하거나, 가드레일을 설정하면 안전하게 이용할 수 있을 것입니다.
둘째, 개발에 확장성과 유연성을 더해주고 유지보수 비용을 줄이기 때문입니다. MCP가 없던 때에는 각 시스템에 연결하기 위해서는 전용 SDK, 플러그인이 필요했고, 만약 AI 플랫폼이 변경된다면 개발을 다시 해야했습니다. 예를 들어, Claude에서 GPT로 변경이 된다면 여태 개발한 코드를 전부 수정해야했고, 추가되는 시스템이 있다면 그에 맞게 추가 개발을 해야했죠. 즉, 연동하는 시스템과 LLM에 종속되는 코드 개발을 필요로 했기에 유지보수 부담도 늘고, 개발 비용도 높았습니다.
다행히 MCP라는 표준 규격이 등장한 이후로, 이런 종속성 문제에서 벗어날 수 있게 되었습니다. 어떤 LLM이든, 어떤 시스템이든, 동일한 방식으로 붙일 수 있게 해주는 중간 계층이 생긴 것입니다. 이로서 한 번 MCP 서버를 만들어 두면, Claude이든 GPT이든, 혹은 이후에 등장할 다른 LLM이든 MCP 클라이언트만 바꿔 끼워서 재사용할 수 있게 되었습니다. 정리하자면 LLM과 사내 시스템을 연동하려는 수요가 늘고, 그에 따라 필요한 개발과정에서의 비용을 감소시켜주기 때문에 MCP가 필요하다고 할 수 있겠습니다.
LLM의 기능을 확장하는 최신 기술로 RAG(Retrieval-Augmented Generation)가 있습니다. LLM이 답변을 생성할 때, 사내 지식베이스와 연동하여 사내 데이터나 프라이빗한 데이터에 대해 답변할 수 있게 하는 기술입니다. MCP는 RAG 처럼 특정 시스템에 연동 할 수 있다는 점은 같지만, 데이터를 가져와서 응답만 하는 것이 아니고 실제로 작업을 수행한다는 점에서 크게 차이점이 있습니다.
트렌드에 뒤쳐지지 않는 Elastic 답게, MCP 수요가 많아지자 Elastic은 9.2.0 버전에 Elastic Agent Builder라는 MCP용 플랫폼을 출시하였습니다. Elastic Agent Builder는 키바나 웹UI 상에서 프롬프트, 에이전트, 에이전트가 사용할 툴을 관리할 수 있는 관리 도구 모음입니다.
그럼 Elastic Agent Builder를 사용해서 우린 정확히 무엇을 할 수 있을까요? 미리 프롬프트를 생성해둘 수 있고, 목적에 따라 프롬프트와 LLM 그리고 역할이 정의 된 에이전트를 생성하고 관리할 수 있으며, 각 에이전트가 Elasticsearch 내에서 어떤 기능을 수행할 것인지 규정하는 Tool을 생성하고 관리할 수 있습니다.
덕분에 Elastic Agent Builder를 통해 우리는 외부 LLM이나 Private LLM에서 엘라스틱서치의 데이터를 MCP 규격으로 호출할 수 있게 되었습니다.
Elastic Agent Builder가 출시되기 이전인 Elasticsearch 8버전 및 9.0~9.1 버전은 Elastic MCP Server라는 컨테이너형 MCP 서버를 사용했습니다. 9.2.0버전에는 기존의 Elastic MCP Server 기능에 Tool을 조금 더 추가하여 키바나에 통합하고, 키바나 UI 상에서 프롬프트, 역할 정의, 사용할 Tool 목록 등을 쉽게 관리할 수 있는 하나의 플랫폼으로서 출시한 것입니다. Elasticsearch는 공식적으로 Elastic Agent Builder 사용을 권고하고 있으며, 9.2.0버전 이후 Elastic MCP Server는 보안 패치만 적용하고 Deprecate 된다고 명시되어있습니다. 아래는 둘의 간단한 비교 도표입니다.
저희 팀은 사내 PC에 Elastic Agent를 설치하여 EDR 로그를 적재중이며, 이를 Elastic Agent Builder를 활용하여 1분마다 50개 로그에서 위험한 동작이 있는지 Private LLM을 통해 분석합니다. 그리고 하루마다 적재중인 로그를 Merge 하고 있습니다. 추후 이를 NotebookLM에 적재하여 분석 도구로 사용하려 합니다. 또한, 정기적으로 사내 클러스터 상태를 확인하는 데에도 사용해 보았으며 주기적으로 리포트 파일을 생성하게 하였습니다. 데이터에 따라, 용도에 따라 활용 가능성은 무궁무진할 것으로 생각됩니다.
현재 Elastic Agent Builder는 Technical Preview 상태입니다. 활용 가능한 기본 제공 Tool은 7개이고, ESQL을 활용하여 Tool 개발이 가능합니다. 현재버전에서는 PUT, POST, DELETE와 관련된 명령어를 지시할 수 는 없는것으로 보이나, 추후 GA가 되고 버전업이 된다면 GET 이외의 동작도 가능하지 않을까 기대하고 있습니다. 만약 그렇다면 파이프라인 생성, 탬플릿 생성, ILM 관리, 오류 분석 및 수정 등 많은 작업을 Elastic Agent Builder를 통해 해결할 수 있을거라 생각됩니다.
다음 포스팅에서는 Claude Desktop을 활용하여 MCP Agent와 Elastic Agent Builder의 MCP Server를 연동하는 과정을 담을 예정입니다. 그와 함께 본격적으로 MCP를 활용하는 예시와 더불어, NodeJS로 리눅스에서 동작하는 MCP Agent를 만들고 EDR 로그를 분석 및 리포트를 받는 과정도 담아볼 예정입니다.