MCP 서버에는 LLM 이 없다

사내에서 쓰는 어떤 SaaS 도구가 있다. 거기에 글을 쓰고 고치는 일을 AI 에게 시키고 싶었다. 방법을 찾다 보니 MCP 라는 단어가 계속 나왔고, 붙이기로 했다. 그런데 막상 손을 대려니 머릿속에 정리되지 않은 질문 세 개가 걸렸다.

• 이 MCP 서버 안에는 대체 무엇이 들어 있는가.
• 내 프로젝트는 그것을 어떻게 연동하는가.
• 연동한 프로젝트는 그것을 어떤 식으로 쓰는가.

세 질문은 사실 하나의 오해에서 갈라져 나온 것이었다. 그 오해를 걷어 내자 셋 다 한꺼번에 풀렸다.

MCP 서버에는 지능이 없다

오해는 이것이다. MCP 서버 안에 똑똑한 무언가가, LLM 이 들어 있다는 착각.

이름 끝에 붙은 MCP 라는 글자 때문에 그 서버가 알아서 판단해 줄 것 같다. 실제로는 아니다. MCP 서버는 어떤 서비스의 API 를 감싸는 얇은 어댑터일 뿐이다. “문서를 만들어라” 라는 요청이 들어오면 그 서비스의 생성 API 를 호출하는, 지능이라고는 한 톨도 없는 변환기다.

LLM 은 서버 안이 아니라 서버를 부르는 쪽에 있다.

[LLM]  ←MCP 프로토콜→  [MCP 서버: 멍청한 어댑터]  ←API→  [실제 서비스]
 지능은 여기                    LLM 없음

무엇을 쓸지, 언제 부를지, 인자를 어떻게 채울지 판단하는 것은 부르는 쪽 LLM 의 몫이다. 서버는 그 판단의 결과를 받아 기계적으로 실행한다. 이 한 줄을 받아들이고 나니, 걸렸던 세 질문이 차례로 답을 내놓았다.

질문 1 — 서버 안에는 무엇이 들어 있나

지능이 아니라면 무엇인가. 자격증명이다.

MCP 서버가 감싸는 그 실제 서비스는 아무나 호출하게 두지 않는다. 토큰이든 키든, 그 서비스의 인증정보가 있어야 API 가 열린다. 그래서 MCP 서버는 그 자격증명을 들고 동작한다. 서버를 띄울 때 환경변수로 주입하든 설정에서 읽든, 자격증명은 서버 런타임 안에 산다. 서버의 정체는 지능을 가진 무엇이 아니라, 자격증명을 들고 나 대신 그 서비스를 호출해 주는 대리인이다.

여기서 내가 가장 오래 헷갈린 지점이 있었다. 작성자를 구분하려면 인증정보가 필요한데, 그렇다면 그 정보를 도구를 부를 때마다 같이 넘겨야 하는가. id 와 password 를 요청 본문에 실어 보내는 그림 말이다.

답은 분명하다. 그래서는 안 되고, 그럴 필요도 없다.

도구 호출의 인자는 전부 LLM 의 컨텍스트를 통과한다. 모델이 읽고, 대화 기록에 남고, 로그에 찍힌다. 거기에 자격증명을 실으면 시크릿이 그 모든 경로로 새어 나간다. LLM 은 시크릿을 보면 안 되는 경계 바깥에 있다고 보아야 한다. 그래서 자격증명은 도구 인자가 아니라 서버 안에 머문다. 모델이 만드는 호출에는 글의 제목과 본문 같은 업무 데이터만 담기고, 인증은 서버가 자기 손으로 처리한다. 모델은 그 토큰을 한 번도 보지 못한다.

정리하면 서버에 들어 있는 것은 두 가지다. 감쌀 서비스를 부르는 방법, 그리고 그 서비스의 자격증명. 지능은 목록에 없다.

질문 2 — 내 프로젝트는 어떻게 연동하나

연동이라고 하면 라이브러리를 깔고 코드를 짜는 그림을 떠올리기 쉽다. 여기서는 아니다. 등록이다.

프로젝트 경로에 설정 파일 하나를 두고, 이 MCP 서버를 이런 방식으로 띄워라 를 적는다. 그게 전부다. 클라이언트(예컨대 Claude Code)는 그 프로젝트에서 작업을 시작할 때 그 설정을 읽어 서버를 인식한다.

서버를 띄우는 방식은 두 갈래다.

• stdio: 클라이언트가 필요할 때 그 서버를 자식 프로세스로 띄우고, 일이 끝나면 내린다. 미리 띄워 둘 것이 없다. 상시 가동이라는 개념 자체가 없다.
• HTTP: 어딘가 상시 떠 있는 서버의 주소를 적어 두고 거기에 붙는다. 이쪽은 서버를 먼저 가동해 두어야 한다.

혼자 자기 기계에서 쓰는 도구라면 stdio 로 충분하다. 서버를 상시 띄워 둘 이유가 없다. 설정 파일에 실행 방법과 자격증명(질문 1)만 적어 두면, 부를 때 클라이언트가 알아서 띄우고 끈다. 연동은 배선이 아니라 포인터를 하나 꽂는 일에 가깝다.

보안상 사족 하나. 그 설정 파일이 공개 저장소에 커밋된다면 자격증명을 거기 직접 적지 말고 환경변수를 참조하게 둔다. 시크릿은 코드 바깥에 둔다.

질문 3 — 연동한 프로젝트는 어떻게 쓰나

등록을 마치면 사용법 매뉴얼을 따로 쓰지 않아도 된다. 이 부분이 가장 낯설었다.

서버는 자기가 가진 도구의 목록과 각 도구의 설명, 입력 형식을 스스로 알려 준다. 클라이언트의 LLM 은 그 설명을 읽고 어떤 도구를 어떻게 부를지 안다. 그래서 사람은 자연어로 지시하기만 하면 된다. 이 내용으로 문서를 하나 만들어 줘 라고 말하면, LLM 이 알맞은 도구를 골라 인자를 채워 호출한다. 호출법을 가르치는 가이드는 도구 설명 안으로 들어가 있다.

다만 자동으로 되는 것과 안 되는 것을 갈라야 한다. 어떤 도구가 있고 어떻게 부르는가는 자동이다. 그러나 언제 불러야 하고 우리 팀의 규칙은 무엇인가는 자동이 아니다. 그 판단과 정책은 프로젝트 지침 문서에 따로 적어 두어야 한다. 도구의 시그니처만으로 맥락까지 알 수는 없다.

여기서 세 질문을 관통하는 결론이 나온다. MCP 가 값을 하는 경우는 단 하나다. 사람이 자연어로 매번 다르게 지시하고, 그 지시를 LLM 이 해석해 도구를 고를 때. 동작이 코드에 고정돼 있다면 — 정해진 시각에 정해진 내용을 보내는 일 같은 것 — LLM 이 낄 자리가 없고, MCP 는 한 겹의 군더더기다. 판별식은 한 문장이면 충분하다. 이 동작을 누가 결정하는가. 사람의 자연어인가, 코드에 박힌 고정값인가.

확장성 — 팀으로 키울 때

지금까지는 혼자 자기 기계에서 쓰는 그림이었다. 팀으로 넓히면 새로운 요구가 생기고, 그제야 더 무거운 장치들이 값을 하기 시작한다.

대표적인 것이 신원이다. 여러 사람이 한 서버를 공유하면서 누가 무엇을 했는지를 사람별로 남겨야 한다면, 공유 토큰 하나로는 안 된다. 그 토큰은 모든 흔적을 계정 하나로 뭉개기 때문이다. 이때 등장하는 것이 두 층의 인증이다. 한 층은 너는 누구인가를 묻는다. 회사의 통합 인증(SSO)으로 서버의 문을 연다. 다른 한 층은 그 신원을 열쇠 삼아 사람마다 다른 자격증명으로 실제 서비스를 호출한다. 이렇게 해야 작성자가 사람별로 정확히 남는다.

핵심은 순서다. 이 통합 인증, 상시 HTTP 서버, 중앙 자격증명 보관 같은 것들은 규모가 요구할 때 더하는 층이지, 처음부터 까는 토대가 아니다. 혼자 쓰는 단계에서 미리 짓는 것은 비용일 뿐이다. 팀이 커지고 감사 로그를 한곳에서 봐야 하는 순간이 오면, 그때 한 층씩 올리면 된다.

마무리

걸렸던 세 질문의 답은 결국 단순했다.

• 서버 안에는 지능이 아니라 자격증명이 들어 있다.
• 연동은 코드가 아니라 경로에 등록 하나다.
• 사용은 사람이 자연어로 시키고 LLM 이 도구를 고르는 것이다.

그리고 이 셋을 떠받치는 한 문장이 남는다. MCP 를 붙이기 전에 물어야 할 것은 기술 선택이 아니라 주체다. 이 동작을 누가 결정하는가. 사람이 매번 자연어로 지시하는 것이 아니라면, 필요한 것은 MCP 가 아니라 그냥 API 다.

다음 글

이 글은 MCP 를 언제 쓰고 언제 쓰지 않을지를 가르는 질문에 머물렀다. 정작 그 MCP 가 어떤 규약으로 짜였길래 LLM 과 도구를 잇는 표준이 되었는지는 열지 않았다. 프로토콜의 안쪽 — JSON-RPC 위의 구조, 서버의 자기 설명, 그리고 통합의 곱셈을 덧셈으로 접은 설계 — 은 다음 글 “MCP 는 어떻게 표준이 되었나” 에서 따로 살펴본다.