인사이트리포트

들어가며

2025년 2월, WildFly 공식 사이트를 통해 “Making WildFly Glow with Intelligence”라는 뉴스가 발표되었으며, 이 게시물에서는 WildFly의 새 AI 기능인 WildFly AI Feature Pack이 소개되었다. WildFly AI Feature Pack은 다양한 AI 모델, 임베딩, RAG, MCP 등 최신 AI 기능을 WildFly에 쉽게 통합할 수 있게 해주는 확장 패키지이다. 여러 계층으로 구성된 이 패키지는 복잡한 설정 과정을 최소화하여 최신 AI 기술의 도입을 빠르게 지원하는 것을 강점으로 내세우고 있다.

한편, 3월에 개최된 WildFly Mini Conference 2025에서는 “WildFly AI Feature Pack: Deploying an MCP Server” 라는 제목의 발표가 있었으며, 이 발표에서는 AI 챗봇을 통해 자연어로 WildFly 서버 설정 자동화, 로그 분석, 상태를 점검하는 등 흥미로운 기능 시연이 진행되었다. 단순한 모니터링을 넘어 자연어로 서버를 관리하고 문제를 진단하는 등, AI가 미들웨어 운영의 핵심을 직접 맡는 미래의 IT 인프라를 예견할 수 있었다. 이 프로젝트가 고도화된다면 AI가 미들웨어를 알아서 돌봐주는 시대가 도래할지도 모르겠다.

본 글에서는 위와 같이 공개된 WildFly MCP 프로젝트 관련 내용을 소개하고 기능을 테스트하여 실제로 WildFly 운영 환경에서 자연어를 통한 스마트한 관리가 가능한지 확인해본다. 또한, 더 나아가 튜닝을 통해 나만의 WildFly 관리 도우미를 만들어 보도록 하겠다.

WildFly MCP 프로젝트 소개

개요
WildFly MCP 프로젝트는 사용자가 모니터링 및 관리 작업에 생성형 AI를 활용할 수 있도록 지원 도구를 제공한다. 이 프로젝트를 통해 개발자와 운영자는 자연어를 사용하여 WildFly 서버와 상호작용하고 복잡한 관리 작업을 간소화할 수 있다. WildFly MCP 프로젝트의 주요 구성 요소는 다음과 같다.

• WildFly MCP 서버: AI 챗봇과 연동되어, 사용자가 자연어로 WildFly 서버를 제어하고 관리할 수 있도록 돕는 MCP 서버
• WildFly 챗봇: STDIO/SSE 프로토콜로 MCP 서버와 연결되며, 또한 LLM과 연동되어 자연어로 대화가 가능한 AI 챗봇
• MCP STDIO/SSE 게이트웨이: STDIO를 SSE로 변환해주는 MCP 프로토콜 게이트웨이
• Wait MCP 서버: LLM워크플로우에서 지정된 시간만큼 대기하는 기능을 제공하는 MCP 서버

MCP 란?

MCP(Model Context Protocol)는 2024년 11월 Anthropic이 발표한 비교적 새로운 오픈 프로토콜로, 외부 데이터 소스를 LLM(Large Language Model) 컨텍스트 내에 통합하는 방법을 표준화한다. MCP는 AI 애플리케이션에서 일종의 USB-C 포트처럼 동작하여, 다양한 외부 시스템과 AI 모델 간의 연결을 가능하게 한다. 아직은 비교적 새로운 표준이지만 MCP 생태계는 이미 빠르게 발전하고 있다. , 실제 AI 서비스 현장에서 MCP 기반의 통합이 점차 확산되고 있다.

MCP Tools 는 MCP서버가 클라이언트에게 실행 가능한 기능을 공개할 수 있도록 해주는 강력한 기본 요소이며, 이 tool을 통해 LLM은 외부 시스템과 상호작용 및 연산을 수행한다. WildFly MCP 프로젝트에서도 WildFly의 자원을 관리할 수 있는 여러 가지 tool이 구현되어 있으며, 이것을 LLM이 필요에 따라 호출할 수 있도록 연동되어 자연어를 통한 WildFly 관리를 실현하고 있다.

MCP tools 워크플로우

그렇다면 이 프로젝트에서 tool을 어떻게 사용하는지 워크플로우를 통해 확인해보도록 한다. 다음은 챗봇에 “What is the status of my wildfly server?”라고 했을 때 동작하는 흐름이다.

[그림 1] WildFly MCP 프로젝트 워크플로우

0. 챗봇은 기동될 때 MCP 서버로부터 사용 가능한 tool 리스트를 받는다.

1. 사용자가 챗봇에 “What is the status of my wildfly server?”라고 질문한다.

2. 챗본은 질문과 tool 리스트가 포함된 JSON 메시지를 LLM에 전달한다.
이때 “getWildFlyServerAndDeploymentsStatus” tool이 포함된다.

3.  LLM이 질문을 분석해 “getWildFlyServerAndDeploymentsStatus” tool 사용을 챗봇에 지시한다.

4. 챗봇이 MCP 클라이언트를 통해 해당 tool을 MCP 서버에 호출한다.

5. MCP 서버가 WildFly 관리 포트로 서버 상태를 점검하는 명령을 실행한다.

6. WildFly가 요청된 명령을 처리하고 결과를 반환한다.

7. MCP 서버가 이 결과를 챗봇에 전달한다.

8. 챗봇이 결과를 LLM에 전달한다.

9. LLM이 결과를 분석해 챗봇에 답변을 전달한다.

10. 챗봇이 사용자에게 최종 답변을 제공한다.

위와 같은 과정을 통해 챗봇은 “getWildFlyServerAndDeploymentsStatus” tool을 활용하여 LLM 단독으로 답변하기 어려운 질문을 손쉽게 처리한다.

WildFly MCP 프로젝트 테스트 및 응용

이제 이 프로젝트가 실제로 잘 동작하는지 확인해보자. 테스트용 리눅스 환경에서 WildFly MCP 프로젝트의 main 브랜치를 clone하여 Maven 빌드한 후 테스트를 진행했다. 테스트 환경에 대한 정보는 다음과 같다.

• Repository: https://github.com/wildfly-extras/wildfly-mcp.git
• OS: rocky 8.10
• JDK: 21.0.7
• Maven: 3.9.6
• WildFly: 36.0.1
• LLM: ollama/qwen2.5:3b, ollama/qwen2.5:7b

What is the status of my wildfly server? 질문 해보기

위의 워크플로우 대로 동작하는지 똑같이 질문을 해보도록 한다. 참고로 챗봇은 tool을 사용할 때 어떤 툴을 사용하는지 인자 값과 함께 출력한다.

예상 했던 것처럼 getWildFlyServerAndDeploymentsStatus tool을 호출해서 필요한 정보들을 받아와서 답변하는 것을 확인할 수 있다.

참고로 getWildFlyServerAndDeploymentsStatus 의 리턴 값은 다음과 같으며 이 데이터를 바탕으로 LLM 은 최종 답변을 작성한다.

조금 더 스마트 하게 – 한국어로 소통하기

기본 기능이 잘 작동하는 것을 알았고, 이제 조금 더 스마트한 일 처리를 위해서는 한국어로 질문을 해도 문제가 없어야 하기 때문에 한국어로 질문을 해본다.

안타깝게도 소통이 잘 되지 않는다. 같은 의미의 문장인데도 “wildfly 상태 어때?” 만 제대로 답변하였고 나머지는 답변할 수 없다고 응답하는 모습을 볼 수 있다.

LLM의 한국어 구사 능력을 높이기 위해 ollama 에서 제공하는 조금 더 무거운 버전인 qwen2.5:7b 모델로 연동 해보도록 한다.

[그림 2] qwen2.5 모델의 용량 차이 비교

용량이 더 크기 때문에 한국어 능력도 그만큼 뛰어날 것으로 예상 된다.

이전에 이해하지 못했던 질문들을 확실히 잘 해석하고 정확하게 답변하기는 하지만 가끔 답변에서 한자가 발견된다. 더 규모가 큰 모델과 연동을 하면 한국어 처리 능력이 상승할 것으로 예상되지만 이번 테스트 수준에서는 7b 모델을 사용하는 것으로 만족 하고 다음으로 넘어가도록 한다.

조금 더 스마트 하게 – 자연어로 애플리케이션 배포하기

이제는 실제 운영에서 필수적으로 설정하는 항목인 애플리케이션 배포에 대해서 테스트를 해보도록 한다. mw-score.war 라는 테스트 애플리케이션을 자연어 명령으로 배포가 가능한지 확인해 보도록 한다.

LLM이 열심히 분석을 시도하는 모습을 볼 수 있었지만, 방향성이 빗나가면서 혼란스러운 나머지 중국어로 답변하는 상황이 발생했다. 재차 질문을 시도했으나 무한 대기 상태에 빠져버렸다. 사실 이런 요청을 처리할 수 있는 능력이 없다는 것은 예상했던 결과였다.

다만 본 프로젝트에 포함된 챗봇이 CLI 명령어를 직접 실행하는 기능을 갖추고 있기 때문에, 다음과 같이 입력하면 원하는 작업을 수행할 수 있다.

하지만 이런 방식으로 사용한다면 AI를 제대로 활용한다고 보기 어렵다. 따라서 자연어로 명령하면 알아서 애플리케이션 배포 처리를 할 수 있도록 tool을 추가해보자.

우선 서버의 배포 리소스를 조회, 비활성화, 삭제, 추가하는 핵심 관리 기능 구현 한다.

[그림 3] 실제 명령을 수행하는 ManagementRequest 구현

그리고 LLM이 새로운 애플리케이션을 배포하는 요청을 받았을 때 사용할 수 있도록 배포 tool 을 구현한다. 이 tool은 위에 정의된 관리 기능을 사용하여 새로운 애플리케이션을 배포하고 중복된 애플리케이션의 경우 삭제 후 다시 배포 하도록 동작한다.

[그림 4] ManagementRequest 를 사용해서 새로운 애플리케이션을 배포하는 tool 구현

이제 LLM은 새로운 애플리케이션 배포 시 이 tool을 활용할 수 있다. 스마트하게 업그레이드되었는지 다시 빌드하여 확인해보자.

기존에 처리하지 못했던 자연어 명령에 대해서 새로 구현한 deployWildFlyApplication tool에 인자를 정확히 전달하여 처리하고 답변하는 모습을 확인할 수 있다.

추가로 deployWildFlyApplication의 중복 애플리케이션 처리 기능이 제대로 작동하는지 확인하기 위해, score-mw가 배포된 상태에서 score-mw1을 배포해보자.

추가적으로 WildFly의 설정파일인 standalone.xml 파일을 열어서 확인하면 다음과 같이 옵션이 잘 들어가 있는 것을 볼 수 있다.

[그림 5] 자연어 명령을 통해 관리대상 WildFly 설정파일에 적용된 내용

마치며

지금까지 WildFly MCP 프로젝트를 소개하고 부분적인 테스트 및 응용까지 진행해보았다. 표준화된 API를 잘 활용한다면 다양한 애플리케이션과 쉽게 연동할 수 있어, 원하는 서비스를 빠르게 만들고 응용할 수 있었다는 점을 충분히 확인할 수 있었다.

하지만 한계점도 명확했다. LLM의 성능에 따라 전체 시스템의 성능이 크게 좌우되며, 질문의 이해와 답변의 정확성 모두 LLM에 의존한다는 점을 체감했다. 모든 LLM이 WildFly CLI 명령어나 관리 모델을 완벽하게 이해하지 못하기 때문에 복잡한 서버 관리 작업에서는 오작동이나 오해가 발생할 수 있었고, 할루시네이션이나 오답 발생 가능성도 존재했다. 복잡한 작업을 자연어로 요청할 경우 LLM의 해석 능력이 떨어지고, 그만큼 신뢰하기 어려운 답변이 나올 수 있다는 점도 확인할 수 있었다.

또한 LLM을 연동할 때 가장 큰 제약 중 하나는 토큰 제한이었다. 한 번에 처리할 수 있는 텍스트(토큰) 양이 제한되어 실제로 Groq 모델을 연동했을 때도 성능은 우수했지만 금방 토큰 한계에 도달해 결국 로컬 모델로 전환해 테스트를 진행해야 했다.

그럼에도 불구하고 LLM과 MCP에 대한 사전 지식이 없는 상태에서 본 프로젝트를 통해AI를 활용한 WildFly 관리 도우미를 손쉽게 구성하고 나만의 기능을 추가할 수 있었다는 점에서 접근성 및 확장성이 예상보다 높아서 놀라웠다. 아직은 실제 운영 환경에 바로 적용하기에는 다소 불안 요소가 있지만, 관련 기술들이 계속 발전하고 시너지를 발휘한다면 기존 인프라 관리 방식에 혁신적인 변화를 가져올 것으로 기대한다.