<aside> 🏗️

아키텍처의 목적은 기술을 많이 보여주는 것이 아니라, 외부 데이터 변경과 접근성 판단 정책을 서로 격리하는 것이다.

</aside>

전체 흐름

사용자 질문 → AI Agent / MCP Client → MCP Tool → Application Service → Public API Adapter → Normalizer → Evidence / Rule Engine → 구조화 결과 + user_message

Cache, 인증, 입력 제한, Health, Metrics는 이 흐름의 운영 경계를 담당한다.

계층별 책임

영역 구성 책임
MCP FastMCP Tool, Prompt, Resource Agent가 사용할 공개 계약과 답변 정책
Application Service Source 조회, 역별 근거 수집, 결과 조합
Integration Adapter, 공유 HTTP Client 공공 API 호출, 제한된 재시도, 오류 변환
Data Normalizer, Registry 역·호선·시설·상태와 지원 범위 정리
Decision Evidence Model, Rule Engine 이동 조건, 근거 상태, 위험도와 경로 순위 계산
Contract Pydantic Schema, user_message 검증 가능한 구조화 결과와 사용자용 답변 제공
Ops Memory/Redis Cache, Auth, Health, Metrics 외부 장애 흡수, 보안 경계, 운영 상태 확인

핵심 기술 결정

결정 이유
서버 내부에서 LLM을 호출하지 않음 같은 근거에는 같은 판단을 내리고, 안전 판단을 재현 가능하게 유지
Adapter와 Normalizer 분리 외부 API 응답 변경이 판단 로직까지 전파되지 않도록 격리
판단과 사용자 문장 분리 구조화 근거는 검증에, user_message는 실제 사용자 안내에 사용
Memory Cache 기본 단일 로컬 프로세스의 복잡도를 낮추고 다중 Instance일 때만 Redis 선택

대표 구현 근거

남긴 기준

MCP도 결국 운영되는 백엔드다. Tool 등록보다 데이터 경계, 실패 처리, 보안, 관측성, 테스트가 서비스 품질을 결정한다.