[AI 에이전트 4편] MCP — 도구를 표준 규격으로 꽂다
AI 에이전트 5부작의 4편. 도구가 늘고 에이전트도 여럿이 되면 연결이 골치 — 이를 푸는 표준이 MCP(Model Context Protocol)입니다. 'AI의 USB-C'라 불리는 이유, 2·3편의 in-process 도구와 MCP 외부 서버의 차이, 클라이언트↔서버(list_tools/call_tool) 구조를 다룹니다. MCP 공식 문서('USB-C port for AI') 캡처, 실제 연결된 MCP 서버를 claude mcp list로 확인한 캡처(공개용 일반 도구만), USB-C 실사진(CC0)까지 넣어 표준으로 도구를 꽂는 개념을 보여줍니다. 생태계 서버를 골라 에이전트를 확장하는 법까지.
도구가 늘어나니 연결이 골치다 — 표준이 필요해
2·3편에서 도구를 함수로 만들어 에이전트에 붙였습니다. 잘 됐죠. 근데 도구가 늘고, 에이전트도 여럿(Claude·Cursar 등)이 되면 문제가 생겨요.
도구마다 연결 방식이 제각각이면, 에이전트 × 도구 조합마다 코드를 새로 써야 합니다. 이걸 푸는 게 MCP(Model Context Protocol)예요.
MCP는 도구와 에이전트 사이의 표준 규격입니다. 한 번 표준을 따르면, 도구를 한 번만 만들어도 어느 에이전트에나 꽂히고, 남이 만든 도구 서버도 그대로 가져다 씁니다.
MCP는 흔히 'AI의 USB-C'에 비유된다 — 한 규격으로 다 꽂힌다. (사진: Wikimedia Commons, CC0)
4편에서 하는 것: MCP가 왜 'AI의 USB-C'인지 → in-process 도구(2·3편)와 MCP 외부 서버의 차이 → 클라이언트↔서버 구조(list/call 메시지) → 실제로 연결된 MCP 서버를 claude mcp list로 확인 → 생태계 서버를 꽂아 확장. 공식 문서·실제 연결 화면을 직접 캡처했습니다.
'AI의 USB-C'라는 말, 무슨 뜻이죠?
USB-C 하나면 충전기·모니터·외장하드가 다 꽂히듯, MCP 하나면 여러 도구가 에이전트에 표준으로 붙습니다. 표준이 없으면 도구마다 전용 연결 코드를 짜야 하고, 에이전트가 바뀌면 또 다시 써야 합니다(N×M). MCP는 그 사이에 공통 규격을 끼워, 한 번 만든 도구 서버를 어디서나 재사용하게 합니다.
이게 제가 만든 비유가 아니라, MCP 공식 문서가 직접 그렇게 설명합니다. "Think of MCP like a USB-C port for AI applications." 문서를 열어보면 그 한 줄이 그대로 나와요.
MCP 공식 문서 'What is MCP?' (출처: modelcontextprotocol.io)
2·3편 도구랑 뭐가 다른가요?
2·3편의 도구는 에이전트 코드 안의 함수(in-process)였습니다. 빠르고 단순하지만 그 에이전트 전용이라, 다른 앱은 재사용을 못 합니다. MCP는 도구를 독립된 외부 서버로 빼냅니다. 언어·배포가 에이전트와 분리되고, 여러 에이전트가 같은 서버를 공유하며, 남이 만든 생태계 서버도 그대로 씁니다.
솔직히 도구 1~2개일 땐 in-process가 편합니다. 굳이 서버로 뺄 이유가 없죠. MCP가 빛나는 건 도구가 많아지고 여러 에이전트가 공유할 때예요. 우리 게코 도구도 지금은 함수지만, 나중에 여러 곳에서 쓰려면 MCP 서버로 빼는 게 답입니다.
그래서 어떻게 통신하나요?
MCP는 클라이언트(에이전트)와 서버(도구 제공) 사이의 약속입니다. 클라이언트가 "도구 목록 줘(list_tools)" 하면 서버가 목록을 주고, "이거 실행해(call_tool)" 하면 결과를 돌려줍니다. 전송은 stdio나 HTTP로요. 핵심은, 에이전트가 서버 속을 몰라도 메시지 규격만 맞으면 통한다는 겁니다.
2편의 tool_use/tool_result 왕복 기억나시죠? MCP도 결국 같은 '도구 목록 + 실행' 패턴인데, 그걸 네트워크 표준으로 끌어올린 거예요. 그래서 도구가 에이전트 바깥에 있어도 똑같이 돕니다.
이것도 제 추측이 아니라 공식 아키텍처 문서에 그대로 정리돼 있어요. 데이터 레이어·전송 레이어, 도구 발견(tool discovery)·실행 흐름까지요.
MCP 공식 아키텍처 개요 (출처: modelcontextprotocol.io)
실제로 연결돼 있나요?
말로만 하면 와닿지 않으니, 실제 제 환경에 붙어 있는 MCP 서버를 확인해봤습니다. claude mcp list 한 줄이면 연결 상태가 줄줄이 뜹니다. 표준을 따르는 서버라면 종류가 달라도 다 같은 방식으로 붙죠.
여기엔 공개해도 되는 일반 개발용 서버만 추려서 띄웠습니다(문서 조회·UI 생성·브라우저 자동화 등). 개인·사업용 서버는 캡처에서 뺐어요. 핵심은, 이것들이 전부 같은 MCP 규격으로 한 번에 붙는다는 점입니다.
서버 하나하나도 표준 명령으로 들여다봐집니다. claude mcp get으로 개별 서버의 등록 범위·연결 상태를 확인할 수 있어요(역시 비밀정보는 안 나옵니다).
그리고 진짜 핵심 — 그 MCP 서버의 도구를 실제로 불러봤습니다. 문서 조회 MCP(context7)에 "MCP Python SDK 문서 찾아줘"를 시켰더니, 표준 호출로 실시간 결과가 돌아옵니다. 도구가 에이전트 바깥(외부 서버)에 있는데도 2편의 함수 호출과 똑같이 동작하죠.
이게 MCP의 맛이에요. 내가 만들지 않은 도구 서버(context7)인데, 표준만 맞으니 내 에이전트가 그냥 부릅니다. ㅎㅎ
덕분에 도구를 매번 새로 안 짜도 됩니다. 파일시스템·DB·웹검색·브라우저 같은 MCP 서버는 이미 생태계에 많아서, 골라 꽂으면 에이전트 능력이 바로 늘어요. 3편에서 게코 KB 검색을 붙인 Neo4j도 이런 식으로 MCP 서버화하면 어느 에이전트에서나 재사용됩니다.
정리
4편 핵심만 정리합니다.
- MCP = 도구와 에이전트 사이의 표준 규격. 흔히 'AI의 USB-C'에 비유됩니다.
- 2·3편 도구는 코드 안(in-process), MCP는 도구를 외부 서버로 빼 표준으로 통신합니다.
- 클라이언트가 list_tools/call_tool로 서버에 요청하고, 서버는 표준 메시지로 응답합니다.
- claude mcp list로 연결을 확인 — 종류가 달라도 같은 규격이면 다 붙습니다.
- 생태계 서버를 골라 꽂으면 도구를 새로 안 짜도 에이전트가 확장됩니다.
여기까지 오면 에이전트 하나가 꽤 강력해집니다. 생각하고(1편), 도구 쓰고(2편), 여러 도구를 연쇄하고(3편), 표준으로 도구를 무한히 확장(4편)하니까요.
마지막 5편에서는 에이전트를 여럿 둡니다. 역할을 나눠 동시에 일하고 결과를 모으는 멀티에이전트 — 우리가 실제로 쓰는 Workflow로 돌려 캡처해볼게요. ㅎㅎ