Mendix Agent·MCP 개발
AI·DX
운영 중인 Mendix 업무 시스템에 대화형 AI 연동. 멀티 에이전트 대화 흐름, MCP 서버·클라이언트, 기존 시스템 연동 담당.
맥락과 문제
- 난제는 모델이 아니라 범위. 질의 가능 항목, 에이전트의 대리 실행 한계, 응답 생성 시 접근 가능 데이터를 먼저 확정해야 함.
- 운영 중인 시스템에 추가하는 작업. 인증은 기존 방식 준수, 기존 화면·데이터 모델 변경 없이 기능 추가 필요.
- 담당 범위와 협력사 수행 범위를 구분해 기재. 온톨로지 플랫폼 구축과 외부 원천 데이터 연결은 협력사 작업.
역할·기간·범위
시스템 지도
대화 표면
사용자가 질문하고 결과를 확인하는 대화형 화면과 그 아래의 상태 관리입니다.
에이전트 오케스트레이션
요청을 어떤 에이전트가 처리할지 정하고, 도구 호출 결과를 다시 대화로 되돌리는 계층입니다.
MCP 도구 계층
에이전트가 실제로 호출하는 도구의 정의와 권한 경계입니다. 도구 하나가 할 수 있는 일을 좁게 유지합니다.
지식 접근
그래프 기반 검색과 관계형 데이터를 함께 읽어 답의 근거를 만드는 경로입니다.
엔터프라이즈 연동 경계
기존 인증, 도메인 로직, 뷰어를 그대로 둔 채 새 흐름을 붙이기 위한 연동 지점입니다.
중요한 판단
멀티 에이전트 대화 경험 설계
팀 수행
- 문제
- 하나의 에이전트가 모든 요청을 처리하면 답이 길어지고, 어떤 근거로 그런 답이 나왔는지 사용자가 확인할 수 없었습니다.
- 판단
- 요청 유형별로 담당 에이전트를 나누고, 진행 상태와 호출한 도구를 화면에 표시하기로 했습니다.
- 행동
- 요청 유형에 따라 담당 에이전트를 나누고, 진행 상태와 호출한 도구를 대화 흐름 안에서 확인할 수 있게 화면을 설계했습니다.
- 검증
- 같은 질문을 여러 경로로 넣어 담당 에이전트가 의도대로 선택되는지, 중간 상태가 사용자에게 끊기지 않고 전달되는지 확인했습니다.
MCP 서버·클라이언트와 Mendix 영역의 Agent
개인 수행
- 문제
- 에이전트가 할 수 있는 일을 늘릴수록, 무엇을 호출할 수 있고 무엇을 호출하면 안 되는지가 코드 곳곳에 흩어졌습니다.
- 판단
- 도구를 프로토콜 단위로 정의하면 권한과 책임을 도구 정의 안에서 관리할 수 있다고 판단했습니다.
- 행동
- MCP 서버와 클라이언트를 붙이고 Mendix 영역에서 Agent가 사용할 도구를 정의했습니다. 도구 하나가 할 수 있는 일을 좁게 유지해 예외 상황을 줄였습니다.
- 검증
- 도구별로 권한이 다른 계정에서 호출해 거부되어야 할 요청이 실제로 거부되는지, 실패했을 때 대화가 멈추지 않는지 확인했습니다.
여러 마이크로플로우를 잇는 Work Agent
개인 수행
- 문제
- 업무 하나를 끝내려면 서로 다른 마이크로플로우를 순서대로 호출해야 했고, 그 순서를 사람이 기억하고 있었습니다.
- 판단
- 호출 순서를 담당자가 기억하는 대신 에이전트가 관리하도록 했습니다.
- 행동
- 여러 마이크로플로우를 하나의 업무 단위로 묶는 Work Agent를 설계하고 구현했습니다. 중간에 실패하면 어디까지 진행됐는지 남도록 했습니다.
- 검증
- 중간 단계에서 의도적으로 실패를 만들어 재시도했을 때 같은 작업이 중복 수행되지 않는지 확인했습니다.
기존 시스템을 바꾸지 않고 연동하기
개인 수행
- 문제
- 새 흐름을 붙이려면 인증, 도메인 로직, 뷰어처럼 이미 쓰이고 있는 것들을 건드려야 했는데, 그것들을 멈출 수는 없었습니다.
- 판단
- 기존 구성 요소를 수정하는 대신, 그 앞에 연동 지점을 두는 편이 위험이 적다고 판단했습니다.
- 행동
- 그래프 기반 검색과 관계형 데이터를 함께 읽는 경로를 붙이고, 온프레미스 언어 모델을 연동했습니다. Teamcenter 연동, OIDC 인증, Java Action, 3D 뷰어에서 생긴 문제는 각각 원인을 확인해 해결했습니다.
- 검증
- 연동 대상별로 실패 상황을 만들어 기존 화면이 그대로 동작하는지 확인하고, 인증 경로가 기존 정책과 어긋나지 않는지 대조했습니다.
협력사가 수행한 범위
협력사 수행 (제 작업 아님)
- 문제
- 지식 접근의 바탕이 되는 온톨로지 플랫폼과 외부 원천 데이터 연결이 필요했지만, 이 부분은 제 담당 범위가 아니었습니다.
- 판단
- 협력사가 만든 결과를 제 성과로 적지 않고, 공개 문서와 이 사례에 같은 기준으로 표시하기로 했습니다.
- 행동
- 온톨로지 플랫폼 구축과 외부 원천 데이터 연결은 협력사가 수행했습니다. 저는 그 결과를 사용하는 쪽의 연동과 도구 정의를 맡았습니다.
- 검증
- 공개 문서와 이 사례에서 담당 경계를 같은 기준으로 표시하고, 협력사 작업이 제 성과로 읽히는 문장이 없는지 다시 확인했습니다.
구현 근거
고객사 화면은 비공개. 구조와 담당 경계만 도식으로 정리.
측정 가능한 결과
- 설계한 UI 화면 28개
- 대화 하나로 끝나지 않는, 업무 흐름을 실제로 담아야 하는 화면의 양입니다.
- 설계한 MCP 도구 28개
- 에이전트가 말만 하는 것이 아니라 실제로 무언가를 실행할 수 있게 만든 범위입니다.
회고
- 가장 오래 걸린 작업은 모델 선택이 아니라 범위 확정. 에이전트 권한을 좁게 유지할수록 결과 신뢰도 상승.
- 협력사와 분담한 작업일수록 담당 경계를 기록으로 남기는 편이 유리.