RAG와 MCP 기반 Agent로 학사 업무를 실제로 수행시키기
자연어 요청에 답만 하는 것이 아니라 실제 시스템 동작까지 이어지는 Agent를 만들었다. 실행형 Agent는 오답보다 잘못된 실행이 더 위험하다.
- Next.js
- Spring Boot
- FastAPI
- LangChain
- Vector DB
- RAG
- MCP
- JWT
- MariaDB
제원
- 구성
- 4인 팀
- 기간
- 2025
- 프론트엔드
- Next.js
- 백엔드
- Java Spring Boot · REST API
- Agent 서버
- Python FastAPI · LangChain · MCP
- 데이터
- Vector DB (규정 검색) · MariaDB
- 역할
- 프론트엔드 개발 · 전체 서비스 흐름 설계 · 팀원 간 인터페이스 조율
배경
학사 관련 질문에 답하는 챗봇은 많다. 하지만 사용자가 원하는 것은 답변이 아니라 처리인 경우가 많다. 답을 듣고 다시 시스템에 들어가 직접 해야 한다면 문제가 반만 풀린 것이다.
그래서 자연어 요청이 실제 시스템 동작까지 이어지는 구조가 필요했다.
수행
학사 규정과 안내 데이터를 Vector DB에 넣고, RAG로 관련 규정을 검색한 뒤 답하도록 했다. 규정은 모델이 기억하는 것이 아니라 검색해 오는 것이다.
MCP 서버로 Tool을 제공했다. Agent가 요청을 이해하고 필요한 Tool을 선택해 실행한다.
프론트엔드를 개발하면서 Frontend · Spring Boot · FastAPI Agent 사이의 호출 관계와 실행 순서, 인증, 사용자 상태, 예외 처리를 정리했다. 세 서버가 붙는 지점에서 책임이 흐려지면 장애 원인을 찾을 수 없다.
테스트 중 Agent가 잘못된 조건을 사용해 데이터를 수정하는 문제가 발생했다. 조건문 하나를 고치고 끝내지 않았다. 실행형 Agent에서는 이 유형이 구조적 문제라고 보고 Tool 실행 권한, 실행 범위, 작업 조건, 사용자 권한, 로그, 실패 처리, 복구 가능성을 다시 검토했다.
시스템
답변에서 끝나지 않고 Tool 실행으로 이어진다.
사용자 요청은 Next.js를 거쳐 Spring Boot API로, 다시 FastAPI Agent 서버로 전달된다. Agent는 Vector DB에서 관련 규정을 검색하고, LLM이 필요한 Tool을 선택하면, MCP Tool이 실제 시스템 작업을 수행한다.
역할 경계
- Agent 서버 전체 구현과 모델 관련 작업은 팀원이 담당했다. 나는 프론트엔드와 전체 서비스 흐름 설계, 서버 간 인터페이스 조율을 맡았다.
- 모델 학습이나 파인튜닝은 하지 않았다. 사용한 것은 LLM API와 검색 구조다.
- 권한·범위·로그·복구는 검토하고 정리한 항목이며, 전 항목을 완결된 형태로 구축했다고 말하지 않는다.