【LLM】MCP를 '관공서의 주소 변경'에 비유하여 쉽게 이해하기

LLM을 사용한 AI 에이전트의 문맥에서, 최근 MCP라는 용어를 자주 접하게 되었습니다.

MCP란 Model Context Protocol의 약자입니다. 간단히 말하면, LLM이 외부 도구(Tool)나 데이터베이스, 애플리케이션과 안전하고 표준화된 방식으로 상호작용하기 위한 메커니즘입니다. 이는 Anthropic이 2024년 11월 25일에 정식 발표한 규격으로, 이듬해 3월에는 경쟁사인 OpenAI에서도 MCP 규격을 채택할 것이라고 Sam Altman 씨가 X(구 트위터)를 통해 알려 당시 화제가 되었습니다.

하지만 위의 설명은 조금 추상적일 수 있습니다. 그래서 본고에서는 MCP를 '관공서에서의 주소 변경 절차'에 비유하여 설명하겠습니다. 자연어(Natural Language)로 요청을 받은 LLM이 MCP에 따라 도구군을 호출하고, 결과를 취득하여, 최종적인 응답을 반환하기까지의 흐름을 관공서의 창구 업무에 대응시켜 이해해 봅시다.

HTTP나 API의 개념도 관공서의 절차에 자주 비유되곤 하는데, MCP 역시 프로토콜(Protocol)의 일종이므로 이들과 마찬가지로 비유할 수 있습니다.

이해를 돕기 위해 세세한 차이점은 여기에서 생략하겠습니다.

MCP는 LLM이 외부 시스템을 이용하기 위한 공통 규격입니다.

기존에 LLM에게 외부 도구를 사용하게 하려면, 도구마다 개별적인 접속 방법이나 API 사양을 준비해야 했습니다. 예를 들어 다음과 같습니다.

- 파일을 읽는 도구
- GitHub 리포지토리를 조작하는 도구
- 데이터베이스를 검색하는 도구
...

이것들을 LLM에서 이용할 때마다 개별적으로 접속 사양을 구축한다면, 개발과 운용 모두 복잡해져 매우 힘들어집니다. MCP는 이 문제를 해결하기 위해 LLM과 외부 도구 사이에 공통된 약속을 마련합니다.

MCP의 역할은 예를 다음과 같습니다.

- 어떤 도구를 사용할 수 있는지 LLM 측에 알림
- 각 도구가 어떤 입력을 받는지 정의
- 도구 호출 형식을 표준화
...

여기서 중요한 점은 MCP가 'LLM 그 자체'가 아니라는 점입니다. MCP는 LLM이 외부 세계와 접속하기 위한 약속을 가리킵니다. 외부와의 접점을 제공하는 것이므로, LLM 입장에서는 외부 도구를 조작하기 위한 인터페이스(Interface)라고도 표현할 수 있습니다.

서두에서도 언급했듯이, MCP를 이해하려면 '관공서에서 어떤 절차를 밟는 장면'을 생각하면 이해하기 쉽습니다.

당신이 시청에 가서 창구에서 다음과 같이 말했다고 가정해 봅시다.

"이사해서 주소를 변경하고 싶습니다."

이것은 자연어에 의한 요청입니다. 이 시점에서 당신은 세부적인 행정 절차의 내부 사양을 알 필요가 없습니다. 예를 들어 다음과 같은 사항을 완전히 이해하지 못하더라도, 창구 직원이 필요한 절차를 안내해 줍니다.

- 어떤 신청서가 필요한지
- 본인 확인 서류가 필요한지
- 주민등록 정보(住民票)를 어떻게 업데이트할지
...

이때 창구 직원은 당신의 자연어 요청을 받아 관공서 내부의 절차로 변환합니다.

MCP에서의 LLM도 이와 유사한 역할을 수행합니다. 관공서의 주소 변경 절차와 LLM + MCP의 구성 요소를 대응시키면 다음과 같습니다.

관공서 비유	MCP에서의 대응물
시민	사용자
...

이 대응 관계를 통해 생각하면 MCP의 역할은 상당히 명확해집니다. MCP는 LLM이라는 '창구 직원'이 관공서 내의 각 부서나 시스템에 대해 정해진 형식으로 문의나 처리 요청을 수행하기 위한 공통 절차라고 이해할 수 있습니다.

여기서는 MCP를 사용한 LLM의 처리를 관공서의 주소 변경 절차와 대응시켜 정리합니다. 먼저 이 흐름을 도식화해 보겠습니다.

이 그림은 AI를 사용하지 않고 필자가 PowerPoint로 작성한 것입니다.

그림의 왼쪽은 LLM + MCP에서의 실제 처리 흐름입니다. 그림의 오른쪽은 그에 대응하는 '관공서에서 주소를 변경하는 경우'의 흐름입니다.

양측에 공통된 것은 다음 구조입니다.

자연어 요청
↓
의도 이해
...

MCP를 이해하는 데 있어 중요한 것은 LLM이 갑자기 외부 시스템을 자유롭게 조작하고 있는 것이 아니라는 점입니다. 사용자의 자연어 요청을 받아 필요한 절차를 판단하고, MCP로 정의된 형식에 따라 도구를 호출하며, 그 결과를 읽어 들여 마지막으로 자연어로 설명합니다.

이는 관공서의 창구 직원이 시민의 상담을 받아 필요한 신청 양식이나 담당 부서를 확인하고, 내부 시스템에서 처리를 수행한 뒤, 마지막으로 시민에게 결과를 안내하는 흐름과 닮아 있습니다.

앞서 보여드린 그림에서 중요한 점은, 사용자가 데이터베이스나 업무 시스템을 직접 조작하는 것이 아니라, 어디까지나 자연어 (Natural Language)로 의뢰하기만 하면 된다는 점입니다. 그 의뢰를 LLM이 해석하고, 필요한 외부 도구 (External Tool)를 판단하여 MCP에 따라 호출합니다. 그리고 결과를 받은 LLM이 최종적으로 사용자에게 이해하기 쉬운 언어로 답변합니다.

이하, 각 단계별로 조금 더 자세히 살펴보겠습니다.

LLM + MCP의 경우, 가장 먼저 있는 것은 사용자의 자연어 의뢰입니다. 예를 들어 다음과 같은 의뢰가 있습니다.

"파일을 검색해서 요약해줘"

이 시점에서 사용자는 어떤 도구를 사용해야 하는지, 어떤 API를 호출해야 하는지, 어떤 인자 (Argument)를 전달해야 하는지를 지정하지 않습니다. 이를 관공서의 주소 변경에 비유하자면, 시민이 창구에서 다음과 같이 말하는 상황에 해당합니다.

"이사했으니 주소를 변경하고 싶습니다"

시민 또한 처음부터 신청서의 내부 처리 방식이나 주민 기록 시스템의 사양을 이해하고 있는 것은 아닙니다. 우선 자연어로 "무엇을 하고 싶은지"를 전달합니다.

다음으로, LLM은 사용자의 의뢰 의도를 이해합니다. "파일을 검색해서 요약해줘"라는 의뢰라면, LLM은 적어도 다음 사항들을 판단합니다.

• 어떠한 파일 검색이 필요함
• 검색 대상이 될 문서나 키워드를 특정할 필요가 있음
• 찾아낸 내용을 읽어야 함
• 읽어낸 결과를 요약해야 함

이 단계에서 LLM은 아직 실제 검색 처리를 하고 있는 것이 아닙니다. 의뢰의 목적을 해석하고, 어떤 외부 도구가 필요할지를 판단하고 있는 것입니다. 관공서의 예로 들자면, 창구 직원이 시민의 상담 내용을 듣고 "이것은 주소 변경 절차이며, 본인 확인과 신청서 작성, 주민 정보 업데이트가 필요하다"라고 판단하는 단계입니다.

LLM이 외부 도구를 사용하려면 이용 가능한 도구나 입력 형식을 알아야 합니다. MCP에서는 이용 가능한 tools, 입력 schema, 참조 가능한 resources 등이 정의됩니다 (이것들은 용어로서 중요합니다).

예를 들어, 파일 검색 도구가 다음과 같은 입력을 요구한다고 가정해 봅시다.

{
"keyword": "string",
"limit": "number"
...
}

이 경우, LLM은 "검색 키워드"와 "취득 건수"를 구조화하여 전달해야 합니다. 이는 관공서에서 주소 변경 신고서의 신청 양식이나 접수 규칙을 확인하는 단계에 해당합니다. 주소 변경 시에는 예를 들어 다음과 같은 정보가 필요합니다.

- 성명
- 구 주소
- 신 주소
...

MCP에서의 schema는 관공서의 신청서 기입란이나 접수 조건에 해당합니다.

다음으로, LLM은 자연어 의뢰를 도구가 처리할 수 있는 구조화된 형식으로 변환합니다. 예를 들어, 사용자의 의뢰가 "MCP에 대해 쓰인 파일을 검색해서 요약해줘"라면, LLM은 다음과 같은 도구 호출 (Tool Call)을 만들 것입니다.

search_documents(keyword="MCP", limit=5)

혹은 JSON 형식으로 표현한다면 다음과 같습니다.

{
"tool": "search_documents",
"arguments": {
...
}
}

여기서 일어나고 있는 것은 자연어에서 구조화된 데이터 (Structured Data)로의 변환입니다. 관공서의 주소 변경으로 말하자면, 시민의 "이사했으니 주소를 변경하고 싶습니다"라는 상담 내용을 신청서에 필요한 항목으로 옮겨 적어, 등록을 위한 준비를 마치는 것과 같습니다.

성명: 야마다 타로
구 주소: 치바현 ○○시……
신 주소: 도쿄도 ○○구……
...

MCP에서의 tool call은 관공서에서 신청서를 작성하여 담당 부서에 전달할 수 있는 상태로 만드는 것에 대응합니다.

구조화된 의뢰가 만들어지면, MCP 서버나 외부 도구가 실제 처리를 수행합니다. 파일 검색의 예라면, 외부 도구는 다음과 같은 처리를 담당합니다.

• 파일 목록을 검색함
• 키워드와 일치하는 문서를 찾음
• 필요에 따라 문서의 내용을 읽음
• 관련 검색 결과를 반환함

여기서 중요한 점은, 실제로 파일 시스템이나 데이터베이스에 액세스하는 것은 LLM 본체가 아니라 MCP 서버나 외부 도구 측이라는 점입니다. LLM은 어떤 도구를 어떻게 호출할지를 판단하고, 실제 검색이나 DB 질의, API 실행은 외부 도구가 담당합니다.

관공서의 예로 들자면, 창구 직원이 주소 변경에 필요한 사항을 확인한 후, 주민과나 내부 시스템에서 주소 변경 처리를 수행하는 단계입니다. 창구 직원이 모든 것을 구두로 끝내는 것이 아니라, 내부의 업무 시스템이나 담당 부서가 실제 처리를 맡고 있는 것입니다.

외부 도구에서 처리가 완료되면, 그 결과가 LLM 측으로 반환됩니다. 파일 검색(File Search)이라면 예를 들어 다음과 같은 결과입니다.

{
"status": "success",
"results": [
...

이 결과에는 검색이 성공했는지, 어떤 문서가 발견되었는지, 어떤 내용이 포함되어 있는지와 같은 정보가 포함됩니다. 관공서의 주소 변경으로 비유하자면, 담당 부서나 내부 시스템으로부터 다음과 같은 처리 결과가 돌아오는 단계입니다.

접수 완료
미비 사항 없음
추가 확인 필요 없음
...

미비 사항이 있는 경우에는 추가 서류나 재확인이 필요하다는 내용도 함께 반환됩니다.

도구(Tool)로부터 결과가 반환된 후, LLM은 그 결과를 읽어 들입니다. 여기서 LLM이 수행하는 것은 단순한 데이터의 전기가 아닙니다. 검색 결과 중에서 중요한 부분을 추출하고, 사용자의 요청에 맞게 정리하여 이해하기 쉬운 설명을 만듭니다.

예를 들어, 파일 검색 결과에 여러 문서가 포함되어 있는 경우, LLM은 다음과 같은 판단을 내립니다.

• 어떤 문서가 요청과 가장 관련이 있는가
• 중복되는 내용은 무엇인가
• 요약에 포함해야 할 핵심 정보는 무엇인가
• 사용자에게 그대로 보여주어서는 안 될 내부 정보가 있는가
• 오류나 불확실성을 어떻게 설명해야 하는가

관공서의 예로 들면, 창구 직원이 내부 시스템의 처리 결과를 보고 시민에게 전달할 이해하기 쉬운 설명을 고민하는 단계입니다. 내부 시스템의 화면이나 처리 로그를 시민에게 그대로 보여주는 것이 아니라, "절차가 완료되었습니다", "이 서류만 추가로 필요합니다"와 같은 형태로 정리하여 전달합니다.

마지막으로, LLM은 사용자에게 자연어(Natural Language)로 응답합니다. 파일 검색과 요약의 예라면 다음과 같은 응답이 됩니다.

"MCP에 관한 파일을 검색한 결과, 주로 2건의 관련 문서가 발견되었습니다. 내용을 요약하면, MCP는 LLM이 외부 도구 및 데이터 소스(Data Source)를 표준화된 형식으로 이용하기 위한 프로토콜(Protocol)이며, AI 에이전트가 파일 검색, DB 조회, API 실행 등을 안전하게 다루기 위한 기반으로 사용됩니다."

관공서의 주소 변경이라면, 창구 직원이 시민에게 다음과 같이 안내하는 상황입니다.

"주소 변경 절차가 완료되었습니다. 기입 사항에 미비한 점은 없었습니다. 필요에 따라 마이넘버 카드나 보험 관련 주소 변경도 확인해 주시기 바랍니다."

이처럼 최종 응답에서는 내부에서 수행된 처리 그 자체보다, 사용자에게 의미 있는 결과가 반환됩니다. 이것으로 일련의 절차는 종료됩니다.

관공서에서는 창구 직원이 각 부서에 자유로운 형식으로 의뢰하지 않습니다. 주민등록 주소 변경 하나를 하더라도 정해진 신청서, 확인 항목, 본인 확인, 주소 기재 형식 등 엄격한 규칙이 존재합니다. 관련 부서와의 정보 공유에도 일정한 업무 흐름(Workflow)이 정해져 있습니다.

MCP도 같은 발상입니다. LLM이 외부 도구를 호출할 때 "적당히 처리해 줘"라고 모호하게 던지는 것이 아니라, 다음과 같은 정보를 구조화하여 전달합니다.

- 호출할 도구 이름
- 입력해야 할 파라미터 (Parameter)
- 입력값의 타입 (Type)
...

이는 관공서에서 "정해진 신청서에 필요 사항을 기입하여 각 담당 부서로 돌리는 것"에 해당합니다.

방금 전부터 이미 몇 번인가 등장한 용어입니다만, 프로토콜로서의 MCP에서 외부 도구나 데이터 소스를 제공하는 측의 서버를 "MCP 서버 (MCP Server)"라고 부릅니다.

이 그림은 GPT-5.5가 작성했습니다.

이것도 관공서의 예로 이해할 수 있습니다.

창구 직원이 주민 기본 대장 데이터베이스를 직접 조작한다고 단정할 수는 없습니다. 실제로는 주민과 시스템이나 담당 부서의 업무 단말기를 통해 정보를 확인합니다. MCP 서버도 마찬가지로, LLM 입장에서 본 외부 기능의 제공 창구입니다. 예를 들어 다음과 같은 것들을 들 수 있습니다.

- 파일 검색
- GitHub 조작
- 데이터베이스 검색
...

LLM은 이러한 실제 시스템을 직접 조작하는 것이 아니라, MCP 서버가 공개하고 있는 기능을 통해 액세스(Access)합니다.

여기서 짚고 넘어가야 할 점은, LLM이 모든 것을 스스로 실행하고 있는 것이 아니라는 점입니다. 관공서의 창구 직원도 마찬가지로, 모든 처리를 혼자서 완결 짓는 것이 아닙니다. 주민등록 갱신에는 주민 기록 시스템이, 보험 변경에는 보험 담당 부서가, 세무 확인에는 세무 부서가 각각 관여합니다.

창구 직원의 역할은 다음과 같이 정리할 수 있습니다.

- 시민의 요청 내용을 이해한다
- 필요한 절차를 판단한다
- 필요한 부서에 조회한다
...

LLM도 같습니다. 사용자의 요청을 자연어로 받아들여, 필요한 도구를 선택해 MCP를 통해 호출하고, 결과를 통합하여 답변합니다.

즉, LLM의 본질적인 역할은 외부 시스템의 '실행 주체'가 아니라, 자연어와 구조화된 절차 사이를 가교하는 '판단·조정·설명의 주체'입니다.

※ 참고: Understanding MCP servers - Model Context Protocol

MCP가 특히 중요해지는 것은 LLM에게 단순한 문장 생성 이상의 작업을 시키고 싶은 상황입니다. 예를 들어 다음과 같은 용도를 들 수 있습니다.

- 파일을 읽고 내용을 요약하기
- GitHub의 Issue나 Pull Request 확인하기
- 로컬 환경에서 스크립트 실행하기
...

이것들은 모두 LLM 단독으로는 완결되지 않습니다. LLM은 자연어를 이해하고, 방침을 세우며, 응답을 생성할 수 있습니다. 하지만 최신 파일, 로컬 PC 상의 데이터, 사내 시스템, 외부 API와 같은 리소스에 액세스하려면 어떠한 접속 기구가 필요합니다. 그 접속 기구를 표준화하는 것이 MCP입니다.

MCP에 대해 생각할 때 파악해 두어야 할 점은, MCP 자체가 LLM의 똑똑함을 높여주는 것은 아니라는 점입니다. MCP는 어디까지나 LLM이 외부 도구를 사용하기 위한 접속 규격입니다. 도입했다고 해서 LLM의 추론 능력 자체가 갑자기 향상되는 것은 아닙니다.

관공서의 예로 들자면, MCP는 '창구 직원의 지식량을 늘리는 기술'이 아니라, 단순히 '창구 직원이 각 부서와 올바르게 연계하기 위한 업무 플로우 (Workflow)'입니다. 아무리 똑똑한 창구 직원(=LLM)이라도 부서 간의 연계 규칙이 갖춰져 있지 않으면 절차는 혼란에 빠집니다. 반대로 연계 규칙이 갖춰져 있더라도, 창구 직원이 의뢰 내용을 오해하면 잘못된 절차로 플로우가 진행되어 버립니다.

LLM + MCP의 경우도 마찬가지입니다. MCP는 외부 도구와의 연계를 정리하는 것이지만, 어떤 도구를 언제 호출해야 할지, 결과를 어떻게 해석해야 할지는 LLM 측에서 판단합니다. 따라서 실용적인 관점에서는 MCP를 따를 수 있을 정도로 똑똑한 LLM을 사용자가 선택해야 합니다.

이는 도서관의 레퍼런스 서비스 (Reference Service)와도 닮아 있습니다.

뛰어난 사서는 모든 지식을 자신의 머릿속에 가지고 있는 것이 아닙니다. 이용자의 질문을 듣고, 필요한 정보를 파악하며, 장서 검색, 분류 체계, 전문 데이터베이스, 참고 도서 등을 구분하여 사용하면서 신뢰할 수 있는 정보에 도달합니다.

제공되는 정보가 매우 방대하고 정확하며 유익하더라도, 그것은 정보를 제공하는 사서 자신이 전지전능하다는 것을 의미하는 것이 아니라, 적절한 정보원에 액세스하고 이를 평가하여 이용자에게 알기 쉽게 정리해서 돌려주는 능력이 있다는 것뿐입니다. (물론, 이러한 능력이 뛰어나다는 점은 틀림없습니다)

LLM + MCP도 이와 유사한 구조를 가지고 있습니다. MCP는 LLM 자체를 똑똑하게 만드는 기술이 아닙니다. 하지만 LLM이 외부 도구나 데이터 소스에 접속하여, 그것들을 일정한 절차에 따라 이용할 수 있게 합니다. 그 결과, LLM 단독으로는 답할 수 없는 질문에도 외부 정보를 참조하며 답할 수 있게 됩니다.

즉, MCP는 LLM의 '지능 그 자체'를 늘리는 것이 아니라,

LLM이 참조할 수 있는 정보원과 실행할 수 있는 절차를 넓히는 메커니즘으로 이해해야 합니다.

지금까지의 내용을 주소 변경의 예로 다시 정리하겠습니다.

시민(=사용자)은 관공서 내부 시스템의 사양을 모릅니다. 그럼에도 '주소를 변경하고 싶다'라고 전달하면, 창구 직원이 필요한 절차를 판단해 줍니다. LLM의 경우도 마찬가지입니다. 사용자는 외부 도구의 API 사양을 알 필요 없이, '이 파일을 읽고 요약해 줘', 'GitHub의 Issue를 확인해 줘', '일정을 조정해 줘'라고 자연어로 의뢰하기만 하면 됩니다. LLM이 그 의도를 해석하여 어떤 것이 목적 달성에 필요한 도구인지를 판단합니다.

MCP는 LLM이 그러한 도구들에 대해 정해진 형식으로 안전하게 액세스하기 위한 공통 절차입니다. 관공서로 치면 신청서 양식, 부서 간의 연계나 정보 전달 규칙, 승인 플로우, 조회 절차 등에 해당합니다.

지금까지 관공서의 비유를 들어 길게 설명해 왔습니다만, 요약하자면 다음과 같습니다.

• LLM = 자연어를 이해하는 창구
• MCP = 그 창구가 외부 시스템에 올바른 형식으로 의뢰를 보내기 위한 절차
• 외부 도구 = 실제 처리를 담당하는 각 부서

이렇게 정리할 수 있습니다. 이 세자의 관계를 이해하면, MCP가 왜 AI 에이전트 시대의 기반 기술로서 중요시되고 있는지 알 수 있습니다.