Elastic Agent Builder (2) - 구축과 활용

본 문서는 2025년 12월 09일 기준으로 작성되었습니다.
Elasticsearch 9.2.0 버전을 사용하였으며, 해당 버전에 출시된 Elastic Agent Builder와 Claude Desktop을 연동하여 MCP를 활용하는 과정을 담았습니다.

MCP Server 설정

사전 준비

Elastic Agent Builder 활성화

Elastic Agent Builder 활용

MCP Server 설정

사전 준비

지난 포스팅에서 설명하였듯, Elastic Agent Builder는 키바나 웹상에서 MCP 관련 기능을 편리하게 관리 및 사용할 수 있게 해주는 도구 모음입니다. 이번 포스팅에서는 이 Elastic Agent Builder와 Claude Desktop을 연동하여, 실제로 MCP를 통해 여러 기능들을 수행해 볼 것입니다. 이어질 Elastic Agent Builder 구성 과정은 리눅스에 엘라스틱서치 9.2.0 버전 및 키바나를 설치, 윈도우에 유료 구독중인 Claude Desktop을 설치해 진행하였습니다. Claude desktop은 HTTPS 통신으로만 MCP Agent 설정이 가능하기 때문에, 키바나 SSL 인증 설정 및 인증서가 필요합니다.

Elastic Agent Builder 활성화

먼저 Elastic Agent Builder를 활성화 하기 위해, Kibana UI에서 Stack Management -> Agent Builder 메뉴로 이동합니다. UI 우측에 있는 agentBuilder:enabled 라는 토글 버튼을 클릭하여 활성화 합니다. 기본값은 비활성화입니다. 여기서 활성화를 해야 Elastic Agent Builder UI에 접근할 수 있고, 기능이 활성화됩니다. 그 다음, 위쪽 검색 메뉴에서 Elastic Agent Builder를 검색하여 Elastic Agent Builder UI로 이동합니다. (또는 키바나 좌측 메뉴에서 Elasticsearch -> Agents로 이동해도 됩니다.)

정상적으로 활성화되었다면 위와 같은 화면으로 이동됩니다. 이 UI에서 Agent와 Tool을 관리하고, Agent에 직접 채팅을 할 수 도 있습니다. 이렇게 화면이 표기된다면 MCP Server는 준비가 완료된 것입니다.

참고로 별도로 Agent를 구성하지 않은 경우에는 기본 모델로 Elastic Managed LLM을 사용합니다. Elastic Managed LLM은 Elasticsearch에서 제공하는 LLM 모델로, AWS us-east-1 리전에 호스팅되어있습니다. 즉 외부 인터넷이 연결되어 있을 때 작동합니다.

API Key 발급

MCP Server에 MCP Agent를 연결하려면 API Key가 필요합니다. API Key를 생성할 때, MCP Agent에 어떤 권한과 역할을 줄 것인지를 정의할 수 있습니다. 예를 들어 클러스터 내에서 어떤 실행 권한을 가질지, 어떤 인덱스들에 접근할 수 있게 할지, 어떤 키바나 엔드포인트에 접근 가능하게 할지를 정의합니다. 아래는 API Key를 발급하는 Dev Tools 명령어 예시입니다.

POST /_security/api_key

{

"name": "my-mcp-api-key",

"expiration": "365d",

"role_descriptors": {

"mcp-access": {

"cluster": ["all"],

"indices": [

{

"names": ["*"],

"privileges": ["read", "view_index_metadata"]

}

"applications": [

{

"application": "kibana-.kibana",

"privileges": ["read_onechat", "space_read"],

"resources": ["space:default"]

}

]

}

발급된 API Key에서 "encoded" 필드의 값을 복사하여 따로 저장해둡니다.

cURL 테스트

API Key가 발급되었다면, API Key를 사용하여 cURL 요청이 되는지 테스트 해봅니다. cURL로 키바나 URL에 다음과 같이 호출합니다. 설정이 잘 되었다면 사용가능한 Tool들이 JSON 리스트 형태로 돌아올 것입니다.

curl -X POST https://KIBANA_URL:5601/api/agent_builder/mcp

--cacert "KIBANA_CERT_PATH"
-H "Authorization:ApiKey ABCDEF==“

-H "Content-Type: application/json“

-H "Accept: application/json“

-d "{\"jsonrpc\":\"2.0\",\"id\":\"1\",\"method\":\"tools/list\",\"params\":{}}"

--cacert "KIBANA_CERT_PAH" 키바나 인증서 파일의 경로를 지정합니다. 원격지에 키바나가 설치되어 있는 경우에는 인증서 파일을 복사해옵니다.
-H "Authorization:ApiKey ABCDEF==" 위에서 저장해둔 encoded 필드의 값을 사용하면 됩니다.

MCP Agent 설정

Claude Desktop 설정

MCP Server가 설정되었으니 이제 MCP Agent를 설정할 차례입니다. Claude Desktop을 실행하고, 설정 -> 개발자 -> 구성 편집을 클릭합니다. 자동으로 탐색기가 열리면 claude_desktop_config.json 파일을 엽니다.

claude_desktop_config.json 파일에 아래의 코드를 복사하여 넣습니다. 키바나 URL 및 API Key, 그리고 인증서 경로를 수정한 뒤 저장합니다. 참고로 윈도우를 사용중이라면 경로를 쓸 때 \\ 문자로 이스케이프 합니다.

{

"mcpServers": {

"elastic-agent-builder": {

"command": "npx",

"args": [

"-y",

"mcp-remote@latest",

"https://KIBANA_URL:5601/api/agent_builder/mcp",

"--header",

"Authorization:${AUTH_HEADER}"

"env": {

"AUTH_HEADER": "ApiKey ABCDEF==",

"NODE_EXTRA_CA_CERTS": "C:\\PATH\\TO\\CERT.pem"

}

정상 설정 확인

claude_desktop_config.json 작성 및 저장이 완료되었다면, Claude Desktop을 완전히 종료 후 재시작합니다. (트레이에 남아있다면 아이콘 우클릭 후 강제종료합니다) Claude를 재시작 한 뒤, 다시 설정 -> 개발자 -> 구성 편집을 클릭합니다. elastic-agent-builder가 생성되어있고, running 상태라면 정상입니다. 만약 오류가 발생하였다면 이 화면에 오기 전에 Claude를 실행하자마자 우측 상단에 오류 알람이 발생할 것입니다.

채팅 UI도 확인해봅니다. 정상적으로 설정되었다면 채팅창의 '검색 및 도구' 버튼을 클릭했을 때, elastic-agent-builder라는 커넥터와 토글 버튼이 보입니다.

토글 버튼을 클릭하여 elastic-agent-builder 커넥터를 채팅에서 사용할 수 있도록 활성화합니다. 이를 통해 Claude Desktop이 해당 채팅에서 사용자의 명령을 받고 Elastic Agent Builder의 툴들에 접근할 수 있게 됩니다.

Elastic Agent Builder 활용

사용가능한 툴 리스트 확인

Elastic Agent Builder를 사용한 자연어 명령을 하기 이전에, 먼저 실제로 사용가능한 툴들을 확인해봅니다. 키바나의 좌측 메뉴에서 Elasticsearch -> Agents를 클릭하여 Elastic Agent Builder UI로 이동 후, Manage Tools를 클릭하여 툴 리스트를 확인합니다.

기본 제공하는 툴은 모두 엘라스틱서치의 인덱스 자체를 검색하거나, 인덱스에 쿼리를 날리거나, 매핑을 조회하는 등 GET 명령어를 기반으로 합니다.

조금 아쉬운점은, 아직까지는 Technical Preview라 그런지 Dev Tools에서 사용 가능한 cat 명령어들은 사용 불가능합니다. 예를 들어 cat indices나 cat shards, cat allocation 같은 명령어를 사용할 수 는 없습니다.

흔히 인덱스 크기를 정렬하여 보고 싶을 때 GET _cat/indices?v&s=pri.store.size를 사용할텐데요, Elastic Agent Builder 툴에 있는 platform_core_list_indices의 경우 인덱스명만 리스트 형태로 반환하여 용량 조회는 되지 않습니다.

대신, 직접 ESQL을 사용하여 ESQL이 지원하는 범위 내에서 커스텀 툴을 생성할 수 는 있습니다. 추후 Technical Preview에서 정식 출시로 전환될 때 PUT, POST 명령어들과 Dev Tools 명령어들을 지원한다면 활용도가 굉장히 높아질 것으로 기대합니다.

인덱스 리스트 호출 테스트

이제 MCP를 통해 Claude와 Elastic Agent Builder가 통신하는 것을 확인해보려 합니다. Claude 채팅창에 자연어로 '제 클러스터의 인덱스들을 리스트로 보여줘' 라고 테스트 명령을 전송합니다. MCP 연동이 잘 된 경우, Claude Desktop이 자동으로 elastic-agent-builder 커넥터를 사용하여 어떤 툴에 연결하는게 적절한지 판단 후, 툴 실행 허용 확인을 받습니다.

허용을 하면 Claude가 어떤 툴을 사용했는지, 그 툴에 어떤 요청을 했는지를 보여주며, 응답을 받은 경우에는 응답이 어떻게 왔는지를 출력해줍니다. 테스트 명령어 실행 결과 platform_core_list_indices를 실행하였고, 인덱스 패턴으로 *를 전송하였으며, 응답으로 클러스터 내 모든 인덱스의 이름을 돌려받은 것을 확인하였습니다.

인덱스 크기 순 정렬 요청

다음으로, 인덱스 리스트를 크기 순으로 정렬해달라고 해보겠습니다. platform_core_list_indices 툴은 cat indicies와 다르게 인덱스의 용량은 못가져오고 오직 인덱스들의 이름만 리스트만 가져올 수 있습니다. 이 상황에서 크기 순으로 정렬해달라고 하면 어떻게 될까요?

Claude는 먼저 platform_core_list_indices 툴을 호출하여 인덱스 리스트를 조회합니다. 그러나 응답에 인덱스 용량은 없습니다. Claude는 인덱스 목록에서 이 클러스터에 있는 인덱스명들을 응답받고 저장합니다.
저의 클러스터는 모니터링 데이터를 수집하고 있습니다. metrics-elasticsearch.stack_monitoring.index-* 인덱스에는 인덱스 용량에 대한 정보가 있습니다. Claude는 platform_core_generate_esql 툴을 사용해 조회했던 인덱스명을 바탕으로 직접 ES|QL 쿼리를 작성합니다. 이후 platform_core_execute_esql 툴을 실행하여 모니터링 인덱스에서 용량을 검색합니다. 그러나 ES|QL 실행 과정에서, 필드명이 올바르지 않은 이슈가 발생합니다.
모니터링 인덱스에서 올바른 필드명을 확인하기 위해, platform_core_get_index_mapping 툴을 사용합니다. 이제 인덱스의 용량이 담긴 올바른 필드명을 확인하였습니다.
정확한 필드명으로 platform_core_execute_esql 툴을 실행해 용량을 다시 조회합니다.
용량이 큰 순으로 정렬하여 사용자에게 돌려줍니다.

이 테스트를 진행하며, 비록 '인덱스를 용량 순으로 출력해주세요'라는 단순한 질의를 한 것이지만 MCP로 Elastic Agent Builder의 활용 가능성을 느꼈습니다. 단순히 질의에 대해 답변하는 것을 넘어 스스로 생각하여 활용할 수 있는 툴을 전부 활용해 답변을 찾아가고, 그 과정에서의 오류를 자체적으로 피드백하여 올바른 결론을 도출해나가는 과정은 긍정적이고 고무적인 경험이었습니다. 아래는 각 쿼리에 대한 상세 내용으로, 피드백 과정에서의 쿼리 내용을 담았습니다.

클러스터 상태 리포트 작성

다른 활용방법으로, 클러스터의 상태를 점검하고 우려되는 점과 조치 사항, 요약을 작성하여 파일로 저장하도록 해보았습니다. 이 작업을 주기적으로 실행할 수 있게 따로 nodejs 실행 파일로 빼거나, 리눅스의 cronjob 또는 서비스 파일로 만든다면 주기적으로 리포트를 받을 수 있을 것입니다. 아래는 리포트 파일의 결과이며, 여기에 더해 결과를 슬랙으로 전달받을 수 있다면 운영자나 관리자가 직접 확인할 필요 없이 매일 클러스터 상태를 점검할 수 있을 것입니다. 참고로 아래의 리포트 결과에서 frozen 노드의 경우 디스크 사용량이 90%가 넘는것이 정상이며, 이러한 예외사항은 프롬프트나 지식베이스에 추가해 필터링하거나, 추후 더 좋은 모델을 사용하여 조정 할 수 있을 것으로 보입니다.

결론 및 시사점

여태까지 Elastic Agent Builder 소개와 구성, 그리고 활용하는 예시를 포스팅하였습니다. 저희 팀은 이에 그치지 않고 Elastic Agent Builder와 자체 개발한 Standalone MCP Agent를 사용하여, 엘라스틱서치에 적재중인 EDR 로그를 실시간으로 분석하고 매일 리포트하여 그 결과를 NotebookLM에 적재하는 프로젝트를 진행하고 있습니다. 이처럼, 활용하는 목적과 방법에 따라 사용자의 업무를 간편하고 효율적으로 만들어 줄 수 있다는 시사점을 얻었습니다.

비록 아직 Elastic Agent Builder로 실행할 수 있는 툴이 적은 것은 사실입니다. 그러나 LLM의 성능이 향상되어 적은 툴로도 자체 피드백을 통해 원하는 결과를 도출하는 점, 아직 Technical Preview로 추후 GA 되었을 때 더 많은 기능이 나올 수 있다는 점은 충분히 기대되고 고무적이라 할 수 있겠습니다. 9.2.0 버전의 Elastic Agent Builder 업데이트를 통해 엘라스틱서치가 트렌드에 맞춰 기능들을 출시하려 노력하고 있다고 느낄 수 있었으며, 앞으로도 해당 기능의 꾸준한 업데이트를 통해 엘라스틱서치의 활용 가능성을 무궁무진하게 넓힐 수 있기를 기대하는 바입니다.

@김선민

Page updated

Report abuse