MCP 서버 만들기 전에 고민할 내용
2026년 03월 02일 작성TL;DR
- 키보드에 손이 먼저 가는 습관을 고쳐야 한다.
- 복잡한 비즈니스 로직은 더 이상 해자가 아니다. 경쟁 우위는 복제 불가능한 고객 데이터에 있다.
- LLM 처리를 사용자 클라이언트에 오프로딩할지 여부가 핵심 설계 결정이다.
- LLM 오프로딩은 시스템 프롬프트 충돌, 토큰 버짓 불확실성, 모델 호환성 문제를 동반한다.
시작하며
에이전트 시대가 되고 나서 나에게 생긴 현상 중 하나는, 너무 하기 싫은 일을 최대한 떠넘기는 도구를 만들게 되는 것이다.
최근에 PPT 를 만들 필요가 있었는데, 대부분의 경우 PPT 만들때 가장 하기 귀찮은 작업은 머리에 있는 그림을 손으로 그려내는 작업일 것이다. 그리고 GenAI 는 이런 작업을 자동화하기에 더없이 좋은 도구였다.
이런 관점에서 실행을 하지 않기 위한 발버둥의 일환으로 claude pptx 스킬1, PPT 생성용 MCP 서버2, 기타 유료툴34들을 테스트해봤다. 오픈소스 툴은 고객 대상으로 보여주기 퀄리티가 애매하거나, 슬라이드 수정시 정확한 부분 수정이 쉽지 않았다. 상용툴은 퀄리티가 좋은 편이지만 사내의 자료를 유출하면 안되는 경우 사용할 수 없었다.
결국 바이브 PPT 생성기를 직접 만들기로 했고, 바이브 코딩을 하면서 느낀 점이 몇가지 있는데 그중에 한두가지만 공유해본다.
1. 코딩의 가치는 낮다. 그리고 더욱 낮아질 것이다
내가 최근 입버릇처럼 하는 말은 코딩에 대한 가치가 매우 낮아졌다는 것이다. 그리고 매일의 경험상 그 추세는 더 내려갈 것 같다.
실행이라는 행동으로 약간 확장(비약)하면, 최근의 실행은 의미있는 문제를 찾아내는 것보다 가치가 낮다. 따라서 의미있는 문제를 찾고 검증하는데 더 많은 시간을 쓰게끔 생각을 바꿔야 하고, 고전적인 빌더의 마인드를 가진 사람으로써 훈련이 필요한 것 같다.
오히려 실행의 가치가 더 싸졌기 때문에 일단 실행을 하게 된달까? 하지만 시간의 가치는 그대로이므로 가치가 높은 활동에 시간을 쓰게 생각의 방식을 조정해야 한다.
의미 있는 문제의 정의는 다양하지만, 개인적으로는 돈을 내고 풀만한 문제 && 아직 풀리지 않은 문제가 의미있는 문제라고 생각한다. 그 외의 문제는 대부분 부차적인 것으로 안그래도 낮아진 실행의 가치를 더 낮춘다고 생각한다.
개발자는 코딩에 손이 먼저 나가는게 정상이다. 하지만 코딩의 가치가 떨어지는 만큼 그걸 참는 연습을 해야 한다. 꼭 해야하는 건지 한번 더 생각해보고 조사를 많이 해보자. 시간이 가장 중요한 가치가 되었다.
2. 복잡한 비즈니스 로직은 더 이상 해자가 아니다
예전에는 복잡한 비즈니스 로직 그 자체가 경쟁 우위의 중요 요소였다. 정교하게 설계된 로직은 쉽게 따라할 수 없었고, 그것이 곧 서비스의 해자(moat)였다. 하지만 에이전트 도구의 발전으로 이 전제가 무너지고 있다. 딥리서치, Playwright 같은 에이전트 도구를 활용하면 서비스의 로직을 면밀히 분석하고 재현하는 것이 충분히 가능해졌다. 아무리 정교하게 설계된 로직이라도, 에이전트가 동작을 관찰하고 분석할 수 있다면 복제는 시간 문제일 뿐이다.
하지만 그 로직을 뒷받침하는 데이터는 복제할 수 없다. 에이전트를 통해 확보한 high fidelity 고객 데이터만이 진정으로 복제 불가능한 영역이다. 이런 데이터를 쌓아야 유니크한 서비스가 될 수 있으며, 경쟁 우위는 구현의 복잡성에서 데이터의 고유성으로 이동하고 있다.
3. 도구의 방식이 달라지고 있다
사용자들이 달라지면서 도구의 방식도 달라지고 있다. 기존에는 개발자가 사용하는 도구 위주로 개발하고 전달되었다면, 클로드 데스크탑과 바이브 코딩이 활성화 되면서 MCP 서버 방식으로 도구가 개발되기 시작했다. 그리고 이제는 스킬과 플러그인이라는 방식이 대세가 되어가고 있다.
MCP 가 됐든 스킬이 됐든 결국 툴의 구현 방법에서 가장 중요한 것은 LLM 을 오프로딩 할거냐 말거냐를 결정하는 부분이다.
MCP 서버를 예를 들면, MCP 서버가 API 키를 입력받아서 직접 LLM 과 처리할 것이냐, 아니면 클로드 코드 같은 클라이언트가 모든 LLM 을 처리하고 MCP 서버는 그냥 상태관리만 할 것인가 하는 부분이다.
예전에는 얼리어댑터 개발자가 대상이었기 때문에 전자가 일반적이었지만, 최근 비개발자 또는 일반 개발자 사용자가 많아지고, 이로 인해 비용에 대한 압박이 강해지면서 LLM 처리를 사용자의 클라이언트에 오프로딩 하는 후자의 방식이 많아지고 있다.
나도 alps-writer5 를 아래에서 말하는 세 가지 방식 모두를 거쳐서 만들었기 때문에 시행착오를 겪었고, 이번에 만든 ppt-generator6 도 LLM 을 오프로딩 하려고 했었다.
LLM 오프로딩의 세 가지 방식
- 사용자가 직접 실행해야하는 설치형 웹서비스 방식 - 서버가 자체적으로 LLM 을 호출하고 처리한다. 사용자는 웹 UI 를 통해 상호작용한다.
- 서드파티에 의존성이 있는 에이전트기반 MCP 서버 방식 - MCP 서버가 API 키를 입력받아 직접 LLM 을 호출한다. 사용자의 클라이언트 에이전트는 MCP 서버를 툴로 호출하지만, 실제 LLM 처리는 MCP 서버 내부에서 일어난다.
- Claude Skills 방식 - 모든 LLM 처리를 클라이언트 에이전트에 오프로딩한다. 도구는 상태관리와 데이터 처리만 담당하고, 프롬프트와 워크플로우 가이드를 통해 에이전트의 행동을 유도한다.
4. LLM 오프로딩 시 문제
LLM 오프로딩 시 문제는 크게 2가지이다.
시스템 프롬프트 충돌
클라이언트가 되는 에이전트의 시스템 프롬프트가 강력하게 버티고 있는 상황에서 내가 원하는 작업을 에이전트가 실행하게 하는 것은 어렵다.
흔히 말하는 에이전트 프롬프트에는 롤을 주지 말라라는 것과 동일한 이유인데, 이미 클로드 코드 같은 클라이언트 에이전트는 코딩 에이전트로서 롤을 시스템 프롬프트에서 받은 상태이다. 추가적인 롤을 프롬프트에서 지정해서 충돌을 일으키면 성능이 더 떨어진다.
아무리 범용으로 만들어졌더라도 이미 코딩용으로 만들어진 에이전트를 사용하기 때문에, 그 외의 목적으로 에이전트의 동작을 강제하는 것은 상당히 노력이 많이 든다.
예측 불가능한 실행 환경
LLM 오프로딩 자체가 큰 장애요소가 되기도 한다.
일단 남은 토큰 버짓을 알 수 없기 때문에 얼만큼의 작업이 진행되다가 중단될지 알 수 없다. 그래서 모든 단계에 대한 중단을 대비해서 작업해야 한다.
프롬프트 캐싱의 경우에도 내가 설계한 프롬프트와 작업흐름일 경우 최대한 효율적인 캐싱 플로우를 작업해서 토큰 사용량을 최적화 할 수 있지만 에이전트의 경우에는 그렇지 않다.
또한 이 경우 모델 선택도 사용자의 선택에 의존하기 때문에 제작자가 테스트한 대로 동작한다는 보장을 절대 할 수 없다. Claude Sonnet 4.6 에서 잘 동작하던 복잡한 프롬프트가 Gemini 3.1 Flash 에서 그대로 동작할 가능성은, 프롬프트 작업 복잡도에 따라 다르겠지만, 높지 않다.
5. 클라우드 인프라의 역할 변화
이런 과정으로 몇개 만들어보니, 클라우드 회사들의 가치 제안이 변화하고 있다는 생각을 하게 된다.
LLM 처리를 사용자 클라이언트 에이전트로 오프로딩 시키는 방식이 대세가 될수록, 직접 에이전트를 만들고 인프라와 모델을 서빙할 것을 권하는 기존의 클라우드 가치 제안에 새로운 형태의 보완이 필요해지고 있다.
클로드 코드, 코덱스, 제미나이 같은 에이전트 툴 구독이 그 자체로 인프라 역할을 하기 시작했고, 웹 기반으로 해당 툴들을 사용할 수 있게 되면서 인프라의 추상화가 한 단계 더 올라가고 있다는 느낌이다. 인프라가 없어지는 것이 아니라 사용자에게 보이지 않는 형태로 진화하고 있는 것이고, 이는 서버리스의 연장선에서 자연스러운 흐름이기도 하다.
6. 도구 제공자의 모델 적응력
이런 흐름에서 도구 제공자가 모델의 변화에 얼마나 빠르게 적응하느냐가 점점 중요해지고 있다.
새로운 모델이 기존과 다른 특성을 보일 경우 툴이 얼라인 되어 있어야 하는데, 외부 모델에 의존하여 툴을 만드는 경우에는 이 부분에서 연결이 끊어질 가능성이 크다.
예전에 커서에서도 Claude 3.7 이 나오면서 기존 3.5 v2 와 방향성이 크게 달라지면서 사용성에 큰 타격을 입고 사용자가 대거 이탈했는데 (그 중 하나가 본인), 자체 모델이 없으면 내부 학습과정에서부터 나오는 인사이트를 얻을 수 없기 때문에, 공식 툴보다 한두 발 뒤처지는 위험을 항상 짊어지고 가야한다. Bedrock 처럼 멀티모델을 지원하는 접근이 이런 리스크를 완화하는 하나의 전략이 될 수 있을 것이다.
모델이 더 발전하면 이런 제약도 줄어들겠지만, 현 시점에서는 현실적인 고려 사항이다.
마치며
도구의 방식은 빠르게 변하고 있고, 오늘의 최선이 내일의 레거시가 되는 시대이다. 클라우드 인프라의 역할도 함께 변하고 있으며, 에이전트 구독으로 대체되지 않는 새로운 가치 영역을 찾아내는 것이 앞으로의 과제가 될 것이다. 의미있는 문제를 찾는 데 더 많은 시간을 쓰고, 실행은 최대한 검증 후에 하는 습관이 필요한 때인 것 같다.