<aside> 🎯
Backend / AI / Ops · 공공데이터를 근거 기반 접근성 판단으로 바꾸고, 부분 실패와 미확인 범위를 숨기지 않는 서울 지하철 MCP 서버
</aside>
<aside> 👨💻
Role: 백엔드·AI·운영 설계 및 구현
</aside>
<aside> 🧱
Stack: FastMCP, Async Python, Pydantic, HTTPX, Redis 선택형
</aside>
<aside> 🛡️
Focus: Evidence, 부분 실패, Cache, 보안, 사용성
</aside>
<aside> ⚠️
현재 상태: 2026-07-15 로컬 검증 기준입니다. 공개 Hosted Endpoint와 실제 교통약자 사용자 검증은 아직 완료하지 않았습니다.
</aside>
| 항목 | 현재 기준 | 해석 |
|---|---|---|
| 공공데이터 | 공식 API 4종 · 내부 5개 Source | 실패 범위와 정규화 책임에 따라 내부 경계를 분리 |
| MCP 계약 | Tool 8개 · Prompt 4개 · Resource 1개 | 조회, 판단, 사용자 답변과 Agent 정책을 분리 |
| 자동 검증 | 로컬 테스트 447개 · Ruff 통과 | 2026-07-15 로컬 작업본 기준 |
| 지원 Registry | 65개 역·호선 조합 | 완전 지원 28개 · 부분 지원 37개 |
| 상호운용성 | FastMCP Client · MCP Python SDK | 동일한 Tool, Prompt, Resource 계약 확인 |
| 구분 | 페이지 | 내용 |
|---|---|---|
| 📝 목표 | 프로젝트 목표와 운영 기준 | 사용자 문제, 제품 경계, 지원 범위와 개발 원칙 |
| 🗓️ 타임라인 | 개발과 검증 타임라인 | Mock부터 Live·운영·사용성 검증까지의 진행 순서 |
| 🏗️ 아키텍처 | 전체 아키텍처와 책임 경계 | MCP, Service, Adapter, Normalizer, Engine, Ops 책임 경계 |
| 🗂️ 공공데이터 | 공공 API와 데이터 정규화 | 공식 API 4종, 내부 5개 Source와 정규화 기준 |
| 🧭 Evidence/MCP | Evidence 기반 판단과 MCP 계약 | 이동 근거, Rule Engine, Tool·Prompt·Resource 계약 |
| 🛡️ 운영·보안 | 운영·보안·배포 설계 | 부분 실패, Cache, 인증, 관측성과 배포 경계 |
| 🧪 검증 | 테스트·성능·사용성 검증 | 자동 테스트, Live 품질, 성능, 상호운용성과 사용성 |
| 🛠️ 트러블슈팅 | 트러블슈팅과 운영 시나리오 | 실제 재현 문제와 실패 주입 운영 시나리오 |