AI한테 "내 이슈 좀 정리해줘"라고 하면 벌어지는 일
요즘 AI 코딩 도구나 챗봇 설정 화면을 열어보면 MCP라는 단어가 꼭 보이죠. "MCP 서버 연결", "MCP 지원" 같은 문구는 자주 보는데, 막상 이게 뭐냐고 물어보면 설명이 잘 안 나오는 분들이 많을 거예요. 오늘은 이 개념을 처음부터 차근차근 풀어볼게요.
먼저 문제부터 볼까요? LLM(대규모 언어 모델)은 그 자체로는 글자를 받아서 글자를 내놓는 기계예요. 회사 DB를 조회하거나 슬랙에 메시지를 보내는 일은 모델 혼자서 못 하거든요. 그래서 개발자들은 모델과 외부 서비스를 잇는 연결 코드를 직접 짜왔어요.
문제는 이 연결 코드가 곱셈으로 늘어난다는 거예요. AI 앱이 5개, 외부 서비스가 10개면 최악의 경우 연동을 50개나 따로 만들어야 하거든요. 이걸 N×M 문제라고 불러요. 휴대폰마다 충전 단자가 달랐던 시절을 떠올리면 딱 맞아요. MCP(Model Context Protocol)는 이 단자를 USB-C처럼 하나로 통일하자는 시도예요. 앱도 MCP만 구현하고 서비스도 MCP만 구현하면 서로 다 연결되니까, 필요한 작업량이 N×M에서 N+M으로 줄어드는 거죠.
구조는 생각보다 단순해요
MCP에는 세 가지 역할이 있어요.
- 호스트(Host): 사용자가 직접 쓰는 AI 앱이에요. 데스크톱 챗봇이나 IDE 같은 거요.
- 클라이언트(Client): 호스트 안에 살면서 서버 하나와 1:1로 연결을 유지하는 부품이에요.
- 서버(Server): 실제 기능을 제공하는 쪽이에요. GitHub, 파일 시스템, DB 같은 걸 감싸서 표준 방식으로 내놓죠.
통신은 JSON-RPC 2.0 형식을 써요. 이게 뭐냐면, "이 함수를 이 인자로 실행해줘"라는 요청과 그 결과를 JSON으로 주고받기로 한 약속이에요. 전송 방식은 두 가지가 대표적인데요, 내 컴퓨터에서 서버를 프로세스로 띄워 표준 입출력으로 대화하는 stdio와 원격 서버와 HTTP로 통신하는 Streamable HTTP가 있어요.
실제 흐름은 이렇게 돌아가요. 연결이 맺어지면 양쪽이 지원하는 버전과 기능을 교환하고, 클라이언트가 tools/list로 도구 목록을 받아와요. 호스트는 이 목록을 모델에게 알려주고, 모델이 필요하다고 판단하면 "이 도구를 이 인자로 쓰고 싶어요"라고 답해요. 그러면 호스트가 tools/call로 실행하고 결과를 다시 모델에게 넘겨주죠.
여기서 꼭 기억할 점이 있어요. 모델이 서버를 직접 호출하는 게 아니에요. 모델은 요청만 할 뿐이고 실행은 호스트가 맡거든요. 그래서 호스트가 중간에서 사용자 승인을 받을 수 있는 거예요.
서버를 만드는 것도 어렵지 않아요. Python SDK로는 이 정도면 돼요.
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("weather")
@mcp.tool()
def get_weather(city: str) -> str:
"""도시의 현재 날씨를 알려줍니다."""
return f"{city}: 맑음, 18도"
if __name__ == "__main__":
mcp.run()
함수의 타입 힌트와 설명 문구가 그대로 도구 정보가 돼서 모델에게 전달돼요. 그러니까 설명을 대충 쓰면 모델도 도구를 대충 쓰게 돼요.
Function Calling이랑은 뭐가 달라요?
가장 많이 헷갈리는 부분인데요, 둘은 경쟁 관계가 아니에요. Function Calling은 모델이 "이 함수를 쓰고 싶다"고 표현하는 능력이고, MCP는 그 함수들을 어떻게 찾고 연결할지 정한 규격이에요. 앱 코드 안에 도구를 직접 정의하는 대신, 밖에 있는 서버에서 표준 방식으로 받아오는 거죠.
발상은 LSP(Language Server Protocol)와 닮았어요. 에디터마다 언어 지원을 따로 만들던 문제를 LSP가 풀었듯, MCP는 AI 앱과 외부 도구 사이에서 같은 일을 하려는 거예요. 2024년 11월 Anthropic이 공개한 뒤 2025년에 OpenAI, Google, Microsoft 등이 지원에 나섰고, 2025년 12월에는 Linux Foundation 산하 Agentic AI Foundation에 기증됐어요. 한 회사의 규격에서 업계 공용 규격으로 넘어간 셈이죠. 비슷하게 언급되는 Google의 A2A는 에이전트끼리 대화하는 규격이라, 에이전트와 도구를 잇는 MCP와는 역할이 달라요.
물론 장밋빛만은 아니에요. 도구 설명은 모델이 그대로 읽는 입력이라서, 악성 서버가 설명 안에 몰래 지시를 숨기는 도구 포이즈닝(tool poisoning) 공격이 가능해요. 외부 문서를 읽다가 거기 숨은 명령을 따르게 되는 프롬프트 인젝션도 조심해야 하고요. 도구를 너무 많이 연결하면 설명만으로 컨텍스트를 꽤 잡아먹는다는 현실적인 문제도 있어요.
한국 개발자라면 어디부터 해볼까요
가장 추천하는 출발점은 사내 도구예요. 사내 위키 검색이나 어드민 API 조회를 MCP 서버로 감싸보면, 팀원 모두가 쓰는 AI 도구에서 바로 활용할 수 있거든요. 이때 처음에는 읽기 전용 도구부터 만드세요. 쓰기 권한은 사용자 승인 흐름까지 확인한 다음에 여는 게 안전해요. 외부에서 받은 MCP 서버는 npm 패키지를 설치할 때처럼 출처를 확인하고, 토큰 권한도 최소한으로 주는 습관이 중요해요.
마무리
한 줄로 정리하면, MCP는 AI 앱과 외부 도구를 잇는 공용 단자예요. 여러분 팀에서 AI에게 가장 먼저 연결해주고 싶은 사내 시스템은 뭔가요? 그리고 AI에게 쓰기 권한까지 준다면 어디까지 허용하실 건가요?
🔗 출처: Hacker News