"우리도 AI 도입해 보자"는 과제를 받은 기획자(2)
MCP에 대해서 알아봅시다
지난 시간에는 "온라인 쇼핑몰 고객센터 상담 봇"을 만들 때 알아야 하는 세 가지 개념을 정리해 봤다.
모델의 톤 앤 매너와 행동을 제어하는
시스템 프롬프트(system prompt)
정적인 문서를 검색하는
RAG(Retrieval-Augmented Generation)
실시간 데이터를 조회할 수 있는
펑션 콜링(function calling)
이 세 가지를 알면,
고객의 질문에 일관된 답변을 할 수 있고(시스템 프롬프트),
우리 내부의 데이터를 이용해서 두루뭉실한 답변이 아니라 정확한 답변을 할 수 있게 된다(RAG, 펑션콜링)
그런데 위의 개념만 이해한 채로 실제 서비스를 구현하다 보면 개발자에게 이런 말을 듣게 된다.
"근데 지금 구조로 하면 각 기능별로 매번 따로 연결해야 하는데요... 주문 조회 펑션, 상품 조회 펑션, 회원 정보 조회 펑션… 질문마다 각각 호출 로직을 만들어야 해서 공수가 많이 들 것 같아요. 유지보수도 어렵구요."
그러면서 MCP 구조로 통합 구현을 하는 게 요즘 대세라고 하는 말을 듣게 된다.
이건 또 뭐여... 후... 그렇다면 MCP가 뭔지 알아봐야겠지.
AI야 더 쉽게 설명해 봐MCP(Model Context Protocol)의 개념을 찾아보니,
AI 모델과 외부 도구, 데이터 소스, 애플리케이션을 표준화된 방식으로 연결해 주는 프로토콜이라고 한다.
솔직히 뭔 말인지 잘 와닿지 않는다.
하지만 벌써 포기하긴 이르다.
그런 와중에 "표준", "프로토콜"이라는 단어가 눈에 띈다.
이 단어가 들어간다는 것은 정해진 방식이 있다는 것이다! 좋은 시그널이다.
MCP라는 개념은 2024년에 Anthropic이 발표한 오픈 프로토콜인데,
처음엔 관심을 못 받다가 2025년도 들어서 주요 AI 서비스를 하는 기업들이 MCP를 도입하면서.. 표준은 아니지만 거의 표준처럼 쓰고 있어서 핫하다고 한다.
(아..! AI행님들이 많이 쓰는거여..!)
조금 더 찾아보니, 앞서 배웠던 RAG에 쓰이는 PDF 파일이나, 펑션 콜링으로 호출하는 배송조회 API 같은 다양한 형태의 정보들을 통일된 방식으로 요청하고 응답할 수 있게 만든 것이라고 한다. (대충 그런 느낌)
그런데 이렇게 이해를 하니 또 다른 궁금증이 생겼다.
서로 완전히 다른 형태의 데이터인 PDF 파일과 API를 어떻게 하나의 표준 인터페이스로 묶었다는 것인지?
동공지진이 왔지만 침착하게 제미나이와 챗GPT를 닦달해서 개념을 정리해 봤다.
MCP를 이해하기 위해서는 '툴(Tool)'이라는 개념을 짚고 넘어가야 한다.
PDF는 텍스트 문서이고, API는 서버에 HTTP를 요청하면 데이터 응답이 되고, DB는 테이블을 쿼리로 조회해서 얻어가야 한다. 이렇게 다 다른 형태의 데이터를 어떻게 하나로 묶는고..? 하니, 이것들을 '툴'이라는 단위로 묶는다고 한다.
PDF든, API든, DB든 어떤 형식이든 툴로 지정해서 JSON(키밸류) 형태로 응답하게끔 하는 것이다.
예를 들면 이렇게.
툴 이름: get_policy
설명: PDF에서 정책 내용 검색
입력: {"topic": "환불"}
출력: {"topic": "환불", "content": "환불은 구매일로부터 14일 이내 가능합니다."}
툴 이름: get_order
설명: 주문 상태를 조회
입력: {"order_id": "12345"}
출력: {"order_id": "12345", "status": "배송중"}
툴 이름: get_customer_info
설명: 고객 DB에서 고객 정보 조회
입력: {"customer_id": "c12345"}
출력: {"customer_id": "c12345",
"name": "홍길동",
"membership_level": "골드",
"last_order_id": "o67890"}
원래는 정책서 PDF를 RAG로 붙이면 PDF를 파싱해서 텍스트를 검색해서 응답한다. 그런데 MCP 구조에서는 get_policy 하면 내부적으로 파싱해서 JSON(출력 부분의 키밸류)으로 변환해서 응답을 준다.
주문 상태 조회도 마찬가지로 펑션 콜링으로 붙이면 주문 상태 조회 API를 호출해서 응답하는데 MCP에서는 get_order 하면 JSON으로 변환해서 응답을 준다.
고객 정보 조회도 마찬가지다. 무엇이든 툴을 조회하면 -> JSON으로 응답을 준다.
이것이 MCP의 구조다. 어떤 형식이든 JSON으로만 응답하기! 동일한 방식으로 응답하기! 가 핵심이다.
그러니까... MCP는 플랫폼 역할을 하는 것이다! (아! 이제 뭔가 알 것 같아!)
내부에서 PDF를 어떻게 파싱해서 정보를 뽑아오는지, 어떤 API를 호출하는지는 MCP 서버 내부에서 처리므로 그 안에서 어떻게 하는지 상관없이... 그걸 가져다 쓰는 쪽은.. 툴로 조회해서 -> JSON을 받는다! 가 된다.
(물론 여러분이 MCP 플랫폼 기획자.. 라면 이 부분도 함께 기획 팔로업을 해야겠지만요. 우선은 가져다 쓰는 쪽이라고 칩시다. 가져다 쓰는 입장에선 표준 짱! 프로토콜 짱짱!)
그러면 기획자 입장에서는 RAG나 펑션콜을 개별적으로 봐야 할 때보다 난이도가 낮아진다. 모든 자원들이 MCP에 있기 때문에 MCP 내에서 어떤 툴이 어떤 응답을 하는지만 알면 된다! (야호! 플랫폼 최고!)
개발자들도 새로운 툴을 추가할 때 MCP 규격만 맞추면 되니 호출방식이나 인터페이스에 대한 고민을 덜 해도 된다. (얏호! 리소스 절약!)
물론 이렇게 규격화되어 있다는 것 말고도,
MCP는 워크플로우 등록이 가능해서 멀티턴 대화를 처리하는데 특화되어 있다는 장점도 있다.
그런데.. 워크플로우랑 멀티턴.. 에 대해서는 또 다음 편으로 이어가야 할 것 같다.
너무 졸리다...
오늘은 여기까지만 하겠다..!