MCP 서버 만들기 전에 고민할 내용
TL;DR
- 직접 만들기 전에 기존 도구가 풀지 못하는 문제를 확인한다.
- LLM을 어디서 실행할지에 따라 도구 제작자의 책임이 달라진다.
- 클라이언트에 실행을 맡길수록 중단과 모델 차이에 대비해야 한다.
시작하며
에이전트 시대가 되고 나서 나에게 생긴 습관 중 하나는, 하기 싫은 일을 최대한 떠넘기는 도구를 만드는 것이다.
최근에 PPT를 만들 필요가 있었다. 머리에 있는 그림을 손으로 옮기는 일이 귀찮아서 Claude의 pptx 스킬1, PPT 생성용 MCP 서버2, 유료 도구34들을 써봤다. 오픈소스 도구는 고객에게 보여주기에는 품질이 아쉽거나 슬라이드의 원하는 부분만 수정하기 어려웠다. 상용 도구는 품질이 좋은 편이었지만 사내 자료를 외부에 보낼 수 없는 경우에는 쓰기 어려웠다.
결국 PPT 생성기를 직접 만들기로 했다. 그 과정에서 많이 고민한 것은 모델에 시킬 일을 누가 실행할지였다. 도구 안에서 모델을 호출할 수도 있고, 사용자가 이미 쓰는 코딩 에이전트에 맡길 수도 있다.
MCP(Model Context Protocol)는 에이전트가 외부 도구와 연결하는 규약이다. MCP 서버로 만든다고 해서 모델 실행 위치까지 정해지는 것은 아니다. 직접 만들 이유와 실행을 맡길 위치를 나누어 고민하며 겪은 내용을 정리해본다.
1. 구현하기 전에 남아 있는 문제를 확인한다
최근에는 코딩 자체의 가치가 낮아지고 있다는 말을 자주 한다. 내가 겪는 변화는 같은 기능을 만드는 데 필요한 실행 비용이 줄어든다는 것이다. 그럴수록 무엇을 만들지 찾고 검증하는 데 시간을 더 써야 한다고 생각한다.
그런데 만들기 쉬워져서 오히려 키보드에 손이 먼저 간다. 실행 비용이 낮아져도 내 시간은 그대로 들어간다. 고전적인 빌더의 습관을 바꾸는 훈련이 필요한 것 같다.
사업으로 풀 문제라면 개인적으로는 돈을 내고 풀 만한 문제 && 아직 풀리지 않은 문제를 먼저 찾는다. 이번 PPT 도구에서는 기존 제품을 써본 뒤에도 남은 부분 수정의 어려움과 자료 반출 제약이 직접 만드는 이유였다.
구현의 복잡성만으로 경쟁 우위를 만들기도 어려워지고 있다고 느낀다. 에이전트가 서비스의 외부 동작을 조사하고 브라우저 자동화 도구로 확인하면, 비슷한 기능을 구현하는 비용도 낮아진다. 다만 외부에서 보이는 동작만으로 내부 규칙과 운영 경험까지 모두 복제할 수 있는 것은 아니다.
그래서 나는 복잡한 로직 자체보다 고객에게서 얻은 고유한 데이터와 그 데이터를 활용하는 방식에 더 관심이 간다. 실제 고객이 무엇을 원하고 어떤 결과를 유용하게 느꼈는지는 화면을 따라 만드는 것만으로 얻기 어렵기 때문이다.
2. LLM을 어디서 실행할지 결정한다
만들 이유가 분명해졌다면, 다음은 LLM(대규모 언어 모델)을 누가 호출하고 실행을 관리할지 정할 차례다.
사용자에게 MCP 서버나 스킬로 도구를 제공하면 기존 에이전트에서 바로 사용할 수 있다. 이때 LLM 처리를 사용자 클라이언트로 넘기는 것을 여기서는 오프로딩이라고 부르겠다.
alps-writer5를 만들면서 아래 세 방식을 모두 거쳤고, 이번 ppt-generator6도 클라이언트에 LLM 처리를 맡기는 쪽으로 설계하려 했다.
| 제공 방식 | LLM 실행 위치 | 도구가 담당하는 일 |
|---|---|---|
| 사용자가 설치해 실행하는 웹서비스 | 서비스 내부 | 웹 화면과 모델 호출, 작업 상태 관리 |
| 자체 모델 호출이 있는 MCP 서버 | MCP 서버 내부 | 클라이언트의 도구 요청을 받아 모델 호출과 결과 처리 |
| 클라이언트 에이전트에 실행을 맡기는 스킬·MCP 조합 | 사용자 클라이언트 | 작업 지침 제공, 상태 관리와 데이터 처리 |
앞의 두 방식에서는 제작자가 호출할 모델과 프롬프트 흐름을 정한다. 마지막 방식에서는 사용자가 이미 이용하는 에이전트가 추론을 맡으므로 도구가 별도의 모델 호출 경로를 운영하는 부담이 줄어든다.
스킬은 작업 방법을 알려주는 지침이고 MCP는 도구를 연결하는 규약이므로 함께 쓸 수도 있다. 어느 형식을 골랐는지보다 모델 실행을 얼마나 직접 통제해야 하는지가 설계에 더 큰 영향을 준다.
3. 실행을 넘기면 통제할 수 없는 조건이 늘어난다
클라이언트에 LLM 처리를 맡기면 사용자가 도구마다 모델을 따로 설정할 부담을 줄일 수 있다. 대신 제작자가 실행 환경을 모두 정할 수는 없다.
기존 지침과 작업 지침의 충돌
코딩 에이전트에는 이미 역할과 행동을 정하는 시스템 지침이 있다. PPT 도구가 추가한 지침도 그 환경 안에서 동작해야 한다.
이때 새로운 역할을 길게 부여하는 것만으로 원하는 동작을 얻기는 어렵다. 기존 지침과 모순되는 요구가 있으면 작업이 달라질 수 있으므로, 도구가 필요한 입력과 기대하는 결과, 다음 단계를 구체적으로 정해야 한다.
중단과 모델 차이
제작자는 사용자의 남은 실행 한도나 한 번에 처리할 수 있는 정보량을 항상 알 수 없다. 작업이 어느 단계에서 중단되더라도 이어갈 수 있게 상태를 남겨야 한다.
직접 모델을 호출하면 반복되는 프롬프트를 재사용하는 캐싱 방식도 설계할 수 있다. 클라이언트 에이전트에 맡기면 대화의 구성과 캐싱을 같은 수준으로 통제하기 어렵다.
사용자가 고르는 모델도 다르다. Claude Sonnet 4.6에서 확인한 복잡한 작업 지침이 Gemini 3.1 Flash에서도 같은 결과를 낼지는 별도로 확인해야 한다. 모델 이름만 바꾸면 된다고 가정하면 도구가 제공하려던 경험을 유지하기 어렵다.
4. 도구 제작자가 책임질 부분을 남긴다
이렇게 몇 가지 도구를 만들어보니 클라이언트 에이전트가 실행 기반의 일부를 맡기 시작했다는 느낌이 든다. 모델과 에이전트 실행을 모두 직접 운영하던 구조에서, 사용자의 에이전트가 제공하는 기능을 활용하는 구조로 옮겨가는 것이다.
클라우드 인프라가 없어지는 것은 아니다. 사용자에게 보이지 않는 곳에서 실행을 제공한다는 점에서는 서버리스와도 닮아 있다. 도구 제작자는 그 위에서 상태 저장, 파일 처리, 결과 검증처럼 여전히 자신이 책임질 부분을 정해야 한다.
모델이 바뀔 때 도구가 적응하는 일도 남는다. 나도 Cursor에서 Claude 3.5 v2를 쓰다가 3.7로 바뀐 무렵 사용성이 달라졌다고 느껴 떠난 적이 있다. 이 경험 때문에 외부 모델에 의존하는 도구에서는 모델과 작업 지침의 조합을 계속 확인해야 한다고 생각한다.
Bedrock처럼 여러 모델을 선택할 수 있는 환경은 대안을 시험하는 데 도움이 될 수 있다. 하지만 선택지가 있다는 것만으로 호환성이 확보되지는 않는다. PPT라면 생성된 파일이 열리는지, 요청한 부분만 수정됐는지를 도구 쪽에서도 확인할 수 있어야 한다.
마치며
MCP 서버를 다시 만든다면 먼저 기존 도구로 해결되지 않는 문제가 무엇인지 확인할 것이다. 그다음에는 LLM 실행을 직접 통제해야 하는지, 사용자 에이전트에 맡겨도 되는지를 정하려 한다.
클라이언트에 실행을 맡기면 만들고 운영할 부분은 줄어든다. 대신 중단 후 이어갈 상태와 모델이 달라져도 확인할 수 있는 결과 기준을 잘 설계해야 한다. 어디까지 맡기고 무엇을 도구가 책임질지를 정하는 일이, 구현을 시작하기 전에 할 고민이라고 생각한다.