사이드 프로젝트 #2 - MCP라는 신대륙, 그리고 '나만 되는' 마법

레퍼런스 전멸, 믿을 건 내 기억뿐

MCP를 하려고 구글을 뒤졌지만 나오는 건 피그마(Figma)나 지라(Jira) 연결법뿐이었습니다. 마치 교수님이 툭 던져준 고서 한 권으로 유튜브를 구현해야 했던 대학 시절의 막막함이 재림했죠.

영어 블로그 사이에서 파이썬과 노드 사이를 방황하다가, 문득 Spring AI 밋업에서 본 장면이 스쳤습니다.

"그래, 익숙한 Spring으로 가자!"

쇼츠는 안 돼도 택배는 된다

PlayMCP 환경을 뜯어보니 모델이 요청을 보내면 MCP가 연동된 정보를 물어다 주는 체계였습니다. 여기서 고민이 깊어졌죠. 웹툰이나 쇼츠 제작처럼 타임아웃이 긴 작업은 MCP와 어울리지 않았습니다.

"하지만 내 택배 서비스라면? 연동만 잘 되면 사용자가 늘어날수록 배송 예측 데이터도 정교해질 거야!"

어노테이션이냐 DSL이냐, 그것이 문제로다

먼저 Swagger처럼 어노테이션으로 기능과 파라미터를 정의했습니다. /mcp 엔드포인트로 초기 리스트를 조회하는 구조를 짰죠. 여기서 개발자의 고집이 발동했습니다

AI의 헛소리(Hallucination)를 잡는 Self-Correction

테스트 중 문제가 터졌습니다. AI가 편의점 택배 유무를 자꾸 틀리게 답하는 겁니다. 저는 MCP 서버 측에 전체적인 오류 메시지를 던져 자기 교정(Self-correction)을 유도하도록 짰습니다. try-catch 로직 하나로 AI가 "아, 이게 아니구나!" 하고 다시 생각하게 만든 거죠.

에러처리을 하는걸 개발자 사용성을 위해 어노테이션과 Kotlin DSL 중 고민하다가, 런타임 오버헤드를 줄이고 더 유연한 구조를 위해 DSL 형식을 선택했습니다.

특히 GS 편의점 조회가 실패할 땐 RAG(검색 증강 생성)를 줄 수 없는 환경이라, 토큰을 더 써서라도 GPT가 리스트를 강제 조회하게 밀어붙였습니다. 어차피 카카오 '카나나'를 통하면 토큰 문제는 희석될 것이고, 컨텍스트에 한 번 올라가면 description을 보고 똑똑하게 판단할 거라 믿었으니까요.