MCP

대규모 언어 모델은 아주 많은 글을 미리 읽어 두고 앞말에 이어질 말을 골라 내놓는 프로그램입니다. 학습해 둔 글 밖의 일은 모르기 때문에, 우리 회사 문서나 오늘 일정처럼 바깥에 있는 것을 쓰게 하려면 그것을 가져다 붙여 줘야 합니다.

붙이는 일 자체는 오래전부터 해 왔습니다. 문제는 붙일 때마다 처음부터 짰다는 점입니다. 문서 저장소에 붙이는 코드, 일정표에 붙이는 코드, 고객 관리 도구에 붙이는 코드를 각각 만들고, 그 코드를 쓰는 앱이 네 개면 같은 일을 네 번 했습니다. 도구 다섯 개와 앱 네 개면 연결이 스무 개 생기고, 도구 하나가 응답 형식을 바꾸면 그 도구에 걸린 네 곳을 전부 고쳐야 했습니다.

태오가 페이지덱에서 겪은 것도 그 모양이었습니다. 사내 문의 답변 기능에 붙여 둔 문서 검색 연결을, 두 달 뒤 회의록 요약 기능을 만들며 거의 그대로 다시 짰습니다. 두 곳의 코드가 조금씩 달라지면서 한쪽만 고쳐지는 일이 생겼고, 같은 질문에 두 기능이 다른 답을 냈습니다.

MCP 는 그 연결의 모양을 한 가지로 정해 둔 규격입니다. 2024년 말에 앤트로픽이 공개 규격으로 내놓았고, 특정 모델이나 특정 앱에 묶이지 않도록 공개돼 있습니다.

도구마다 다르게 생겼던 연결을 하나의 약속으로 바꿔서, 곱하기로 늘어나던 연결 수를 더하기로 바꿉니다. 도구 다섯 개와 앱 네 개면 예전에는 스무 벌이 필요했지만, 양쪽이 같은 규격을 따르면 도구 쪽 다섯 벌과 앱 쪽 네 벌로 끝납니다.

규격은 양쪽에 역할을 나눠 줍니다.

1. 서버 — 도구나 데이터를 가진 쪽이 자기가 무엇을 할 수 있는지 규격에 맞춰 내놓습니다. 문서 저장소라면 검색과 읽기와 쓰기를 각각 이름과 입력 형식과 함께 알립니다.
2. 클라이언트 — 모델을 품은 앱 쪽입니다. 서버에 연결해 무엇을 할 수 있는지 목록을 받아 오고, 모델이 고른 것을 대신 실행한 뒤 결과를 모델에게 돌려줍니다.
3. 약속된 대화 형식 — 목록을 묻고 실행을 요청하고 결과를 받는 말의 모양이 정해져 있습니다. 앱은 붙는 상대가 무엇이든 같은 말로 묻습니다.

이 구조에서 중요한 건 앱이 도구의 속사정을 몰라도 된다는 점입니다. 문서 저장소가 API 주소를 바꾸든 인증 방식을 바꾸든, 고쳐야 할 곳은 그 도구의 서버 한 곳이고 거기 붙어 있던 앱 네 개는 그대로 둡니다.

붙일 수 있게 됐다고 해서 제약이 사라지지는 않습니다. 서버가 내놓은 도구 목록은 모델에게 글로 전달되므로 토큰을 먹습니다. 토큰은 모델이 글을 쪼개 다루는 최소 단위이고, 한 번에 볼 수 있는 양인 컨텍스트 윈도는 정해져 있습니다. 서버 열 개를 한꺼번에 붙여 도구가 백 개가 되면 설명만으로 창의 상당 부분이 차고, 남은 자리에 정작 사용자의 질문과 자료를 넣을 공간이 줄어듭니다.

붙이는 방법은 이것 하나가 아닙니다. 무엇이 필요한지에 따라 아래 셋 중 하나로 충분한 경우가 많습니다.

1. 앱 안에 직접 짜기 — 붙일 도구가 하나나 둘이고 그 앱에서만 쓴다면 규격을 들일 이유가 적습니다. 함수 몇 개를 모델에게 알려 주고 호출 결과를 돌려주는 코드가 하루면 끝납니다. 규격은 붙일 곳이 늘어날 때부터 값을 합니다.
2. 자료만 미리 붙이기 — 도구를 부를 필요 없이 우리 자료를 보고 답하면 되는 일이라면 RAG 로 충분합니다. 질문이 들어오면 사내 문서에서 관련 대목을 찾아 지시문에 넣어 주는 방식입니다. 읽기만 하면 되는 기능은 대개 여기서 끝납니다.
3. 각 제품의 전용 연동 — 도구를 만든 회사가 자사 앱에서만 쓰는 연동 방식을 따로 제공하는 경우입니다. 그 안에서는 잘 맞지만 다른 앱으로 옮길 때 통째로 다시 짜야 합니다.

셋과 견줄 때 규격이 값을 하는 자리는 세 가지가 겹칠 때입니다. 붙일 도구가 여럿이고, 그 도구를 쓸 앱도 여럿이고, 앞으로 도구가 더 늘어날 것이 분명한 경우입니다. 페이지덱은 문서 검색 하나만 붙일 때는 직접 짰고, 일정표와 고객 관리 도구가 더해지면서 규격으로 옮겼습니다.

"그 기능 우리가 직접 붙이지 말고 MCP 서버로 하나 띄워 둡시다."

지금 앱에만 붙이지 말고 다른 기능에서도 쓸 수 있게 규격에 맞춰 내놓자는 제안입니다.

"붙은 서버가 몇 갠데요? 도구 설명만으로 창이 절반 차겠는데요."

연결을 너무 많이 열어 모델이 볼 수 있는 분량을 잡아먹고 있다는 지적입니다.

"이건 규격 문제가 아니라 권한 문제예요. 서버 쪽에서 막아야 합니다."

연결 방법이 아니라 그 도구로 무엇까지 할 수 있게 둘지를 도구 쪽에서 정해야 한다는 말입니다.

페이지덱에서 태오가 처음 띄운 것은 문서 저장소 서버였습니다. 검색과 읽기만 내놓고 쓰기는 빼 두었습니다. 기능 세 개가 같은 서버에 붙으면서, 두 달 전 두 곳에 따로 짜 두었던 검색 코드가 한 벌로 줄었습니다.

이어 지현이 일정표를 붙이자고 하면서 논의가 한 번 걸렸습니다. 일정 만들기까지 내놓으면 모델이 판단만으로 회의를 잡을 수 있어서, 만들기는 사람이 확인 버튼을 누를 때만 실행되도록 앱 쪽에 가드레일을 두기로 했습니다. 가드레일은 출력이나 실행이 넘으면 안 되는 선을 코드로 걸어 두는 장치입니다.

규격을 붙이면 모델이 더 똑똑해진다고 읽는 경우가 많습니다. 붙인 뒤에 모델이 전에는 못 하던 일을 해내는 것을 보기 때문입니다. 실제로 달라진 것은 모델이 아니라 모델 앞에 놓인 재료입니다. 규격은 무엇을 가져다줄지와 어떻게 가져다줄지를 정할 뿐, 가져온 것을 어떻게 판단할지는 그대로입니다. 그래서 답이 틀리는 문제를 이것으로 고치려 들면 서버만 늘어나고 오답은 남습니다.

붙이기만 하면 안전해진다고 읽는 것도 흔합니다. 정해진 규격을 따른다는 말이 검증을 거친다는 말처럼 들리기 때문입니다. 그러나 규격이 정하는 것은 말을 주고받는 모양이지 그 말의 내용이 아닙니다. 쓰기와 지우기를 내놓은 서버를 붙이면 모델이 지울 수도 있습니다. 무엇을 내놓을지, 누구에게 열어 둘지, 실행 전에 사람 확인을 받을지는 서버와 앱에서 따로 정해 둬야 합니다.