MCP와 도구 호출, 서비스 기획자 관점으로 정리

 

AI 이야기를 따라가다 보면 요즘 "MCP"라는 단어를 자주 만납니다.
도구 호출이라는 말과 함께 나오는 경우가 많은데, 처음에는 개발자들만 쓰는 용어 같아서 그냥 지나쳤어요.

그런데 예약 시스템 기획을 하면서 "서비스의 기능을 AI가 쓸 수 있게 열어두면 어떨까?"라는 질문이 자꾸 나오다 보니, 기획자도 어느 정도는 이해하고 있어야겠다는 생각이 들었습니다.
이번 글은 제가 이해한 만큼을 기획자 눈높이로 정리한 노트입니다.
개발 세부 사항이나 특정 제품의 사양은 단정하지 않고, 개념과 기획할 때 필요한 판단 위주로 적었어요.

 

먼저 도구 호출부터 이야기해보겠습니다.

언어 모델은 기본적으로 글을 받아서 글을 내놓는 존재입니다.
그래서 "내일 오후 3시에 빈 자리 있어?" 같은 질문을 받아도, 실제 예약 시스템에 접속해서 확인할 수는 없습니다.

도구 호출은 이 한계를 넘기 위한 방식입니다.
미리 "이런 기능이 있다"고 모델에게 알려주면, 모델이 필요하다고 판단했을 때 "이 기능을 이런 값으로 호출해주세요"라는 요청을 내놓습니다.
그러면 서비스 쪽 프로그램이 실제로 그 기능을 실행하고 결과를 모델에게 돌려주고, 모델은 그 결과를 바탕으로 사용자에게 답을 하는 흐름이에요.

중요한 점은 실행하는 주체가 모델이 아니라 서비스라는 사실입니다.
모델은 "호출해주세요"라고 요청할 뿐이고, 실제로 허용할지 말지, 어떤 조건에서 실행할지는 서비스가 결정합니다.
이 구조를 이해하고 나니 "AI가 마음대로 예약을 바꾸면 어떡하죠?" 같은 걱정이 어디에서 풀려야 하는지 보였습니다.
답은 모델이 아니라 서비스 쪽 설계에 있었어요.

 

그렇다면 MCP는 무엇일까요.

제가 이해한 바로는, 모델과 외부 도구를 연결하는 방식을 공통 규칙으로 맞추려는 표준입니다.
각 서비스가 제각각 방식으로 도구를 열어두면, AI 쪽에서는 서비스마다 연결 방법을 따로 만들어야 하죠.
비유하자면 기기마다 충전 단자가 달라서 어댑터를 계속 사야 하는 상황과 비슷합니다.

공통 규칙이 생기면 서비스는 "이런 기능을 이런 입력으로 제공합니다"라는 설명을 한 번 잘 준비해두고, AI 쪽에서는 그 설명을 읽고 같은 방식으로 연결할 수 있어요.
기획자 입장에서는 "서비스의 기능 목록을 AI가 읽을 수 있는 형태로 정리하는 일"이 새로운 산출물이 된다는 의미입니다.

물론 이 표준의 세부 사항은 계속 변하고 있고 제가 다 따라가지는 못합니다.
그래서 이 글에서는 "어떤 문제를 풀려는 규칙인가"까지만 이해하고, 구현 방식은 개발자와 이야기하며 확인하는 입장으로 정리해뒀습니다.

 

기획자로서 가장 실질적인 일은 서비스의 기능을 어떤 단위로 쪼갤지 정하는 것이라고 생각합니다.

가상의 예약 서비스에서 AI가 쓸 수 있는 도구 후보를 적어보겠습니다.

읽기 성격의 도구로는 이런 것들이 있어요.
업장 정보 조회, 서비스 목록 조회, 특정 날짜의 예약 가능 시간 조회, 내 예약 내역 조회입니다.

쓰기 성격의 도구로는 이런 것들이 있습니다.
예약 임시 생성, 예약 확정, 예약 변경, 예약 취소입니다.

여기서 쪼개는 단위가 중요합니다.
"예약하기"라는 큰 도구 하나로 두면 날짜, 서비스, 직원, 결제까지 한꺼번에 처리하려고 해서 어디서 잘못되었는지 알기 어렵습니다.
반대로 너무 잘게 쪼개면 모델이 호출 순서를 잘못 잡을 수 있어요.

제가 쓰는 기준은 이렇습니다.
하나의 도구는 "한 가지 목적"을 가지고, 입력과 출력이 사람이 읽어도 이해되는 수준이어야 합니다.
그리고 되돌리기 어려운 일은 "임시 생성 후 확정"처럼 두 단계로 나눠서, 중간에 사용자 확인이 들어갈 자리를 만들어둡니다.

도구의 이름과 설명도 기획 영역이라고 생각해요.
"예약 가능 시간 조회: 특정 날짜와 서비스를 입력하면 시작 가능한 시각 목록을 돌려준다. 예약을 만들지는 않는다"처럼 하는 일과 하지 않는 일을 함께 적어두면, 모델이 헷갈릴 가능성이 줄어듭니다.

 

도구를 열어두는 순간부터 권한 문제가 시작됩니다.

AI가 쓰는 도구라고 해서 특별한 권한을 갖는 것은 아니어야 합니다.
요청하는 사람이 누구인지, 어느 업장의 정보에 접근할 수 있는지를 서비스가 그대로 확인해야 해요.
예를 들어 손님으로 로그인한 상태에서 호출된 도구는 본인 예약만 조회할 수 있고, 다른 사람의 예약은 볼 수 없어야 합니다.

멀티테넌트 구조라면 더 신경 써야 합니다.
어떤 테넌트의 대화인지가 호출마다 서버에서 붙어야 하고, 모델이 입력으로 다른 업장 식별자를 넣더라도 막혀야 하죠.
이 부분은 기획서에 "도구 호출 시 테넌트 식별은 세션에서 결정한다"처럼 규칙으로 적어둡니다.

또 하나는 감사 로그입니다.
누가, 언제, 어떤 도구를, 어떤 값으로 호출했고, 결과가 무엇이었는지를 남겨두면 문제가 생겼을 때 원인을 찾을 수 있어요.
특히 쓰기 도구는 사용자의 확인 기록과 함께 남겨야, 나중에 "확정한 적 없다"는 분쟁이 생겼을 때 판단할 근거가 됩니다.

로그를 얼마나 오래 보관할지, 어떤 정보는 가려서 저장할지도 미리 정해야 하는 항목입니다.
이름이나 연락처처럼 개인정보가 포함된 값은 보관 기준을 별도로 확인해야 해서, 법적인 부분은 전문가와 공식 안내를 통해 확인하는 것이 맞습니다.

 

여기까지 정리하고 보니, 기획자가 알아야 할 정도가 어디까지인지도 보였습니다.

저는 프로토콜의 내부 구조나 코드를 알 필요는 없다고 생각해요.
대신 아래 질문에는 답할 수 있어야 한다고 봅니다.

서비스의 기능 중 AI에게 열어도 되는 것은 무엇이고, 열면 안 되는 것은 무엇인가.
각 기능은 읽기인가 쓰기인가, 되돌릴 수 있는가.
호출하는 사람의 권한은 어디서 확인되는가.
실패했을 때 사용자에게 어떻게 알리는가.
기록은 무엇을 남기고 얼마나 보관하는가.

이 질문들은 사실 AI가 없어도 필요했던 질문입니다.
다만 AI가 호출 주체로 들어오면서 "누가 호출하는가"라는 부분이 한 겹 더 복잡해졌을 뿐이에요.

 

도구 호출과 MCP는 기술 용어처럼 보이지만, 풀어보면 "서비스의 기능을 어떤 단위와 규칙으로 열어줄 것인가"라는 아주 기획다운 문제였습니다.
저는 앞으로 예약 시스템의 기능 목록을 도구 후보 목록으로 다시 적어보는 연습을 해볼 생각입니다.

 

남은 질문은 모델이 도구를 얼마나 정확하게 고르는가입니다.

도구가 많아질수록 선택이 어려워질 텐데, 설명을 어떻게 쓰고 몇 개까지 한 번에 열어두는 것이 적당한지는 직접 시도해봐야 알 수 있을 것 같아요.
그래서 다음에는 작은 도구 몇 개만 가정하고 설명 문구를 바꿔가며 모델이 어떻게 반응하는지 기록해볼 계획입니다.