MCP 서버 설계 교훈: MCP 최적화 이후 나의 1,800시간 지식 베이스가 마침내 의미를 갖게 된 이유

솔직히 말해서, 이런 일이 일어날 줄은 몰랐습니다.

6년 전, 저는 저의 "완벽한" 개인 지식 관리 시스템인 Papers를 만들기 시작했습니다. 비전은 원대했습니다. AI 기반의 시맨틱 검색 (Semantic Search), 자동 태깅 (Automatic Tagging), 추천 엔진 등 현대적인 지식 베이스에서 기대할 수 있는 모든 것을 갖추는 것이었습니다. 저는 제 자유 시간 중 1,847시간을 여기에 쏟아부었습니다. 2,847개의 기사를 저장했죠. 그리고 오늘날에는요? 하루에 약 15분 정도 사용합니다. 이는 0.05%의 효율성입니다. 그리고 순 ROI (Return on Investment)는 -$112,090입니다.

네, 제대로 읽으신 게 맞습니다. 마이너스 11만 2천 달러입니다.

하지만 중요한 점은 이겁니다. 6개월 전, 저는 MCP (Model Context Protocol)를 발견했습니다. 그리고 무언가 딱 맞아떨어졌습니다. 저의 "실패한" 지식 베이스가 갑자기 다시 유용해졌습니다. 더 많은 AI를 추가했기 때문이 아닙니다. 거의 모든 AI를 제거했기 때문입니다.

무슨 일이 일어났는지, 제가 무엇을 배웠는지, 그리고 왜 MCP가 AI 준비형 (AI-ready) 도구를 구축하는 방식에 대한 여러분의 생각을 바꿀 수 있는지 보여드리겠습니다.

과거의 방식: 모든 곳에 AI가 있었지만, 아무것도 작동하지 않았다

MCP 이전에는 저는 다음과 같은 거짓말을 믿었습니다: "당신의 지식 베이스는 똑똑해야 한다. 콘텐츠를 이해하고, 점들을 연결하며, 추천을 제공할 수 있어야 한다."

그래서 저는 그 모든 것을 구축했습니다:

// 이것이 2023년 당시 저의 KnowledgeService 모습이었습니다 — 2,000줄 이상의 고통
@Service
public class ComplexAIDrivenKnowledgeService {
...

인상적으로 들리나요? 그렇지 않았습니다.

평균 검색 시간은 4.2초가 걸렸습니다. AI 추천의 클릭률 (Click-through rate)은 0.2%였습니다. 지식 그래프 (Knowledge Graph)는 거의 사용하지 않았습니다. 그리고 절반의 경우, 시맨틱 검색 (Semantic Search)은 그냥... 평범한 텍스트 검색보다 더 나쁜 결과를 반환했습니다.

저는 시스템이 똑똑해야 한다고 생각했기 때문에, 엄청나게 과잉 설계 (Overengineered)를 해버렸습니다.

MCP의 깨달음: AI는 이미 클라이언트에 있다

MCP는 모든 것을 바꾸어 놓았습니다. 하지만 더 나은 AI를 제공해주었기 때문이 아닙니다. 당연한 사실을 깨닫게 해주었기 때문입니다:

AI 클라이언트는 이미 똑똑합니다. 당신의 서버에 AI가 있을 필요는 없습니다.

한번 생각해 보세요. Claude Desktop, GitHub Copilot이 포함된 VS Code, 또는 그 어떤 MCP 호환 클라이언트를 사용할 때 — AI는 이미 그곳에 있습니다. AI는 자연어 (Natural Language)를 이해할 수 있습니다. 점들을 연결할 수 있습니다. 정보를 합성 (Synthesize)할 수 있습니다. 당신이 해야 할 일은 그저 관련 문서를 제공하는 것뿐입니다.

그게 전부입니다.

그래서 저는 모든 것을 다시 작성했습니다. 현재 저의 MCP 최적화 지식 서비스는 다음과 같은 모습입니다:

// 2026 — MCP 최적화됨. 50줄. 더 잘 작동함.
@Service
public class SimpleMcpKnowledgeService {
...

그게 전부입니다. 50줄. 임베딩 (Embeddings) 없음. 시맨틱 검색 (Semantic Search) 없음. 추천 엔진 (Recommendation Engine) 없음. 그저... string.contains() 뿐입니다.

그리고 MCP 서버 컨트롤러 (Controller)는요? 매우 단순합니다. 당신은 그저 두 개의 엔드포인트 (Endpoints)인 tools/list와 tools/call을 구현하기만 하면 됩니다.

@RestController
@RequestMapping("/mcp")
public class McpServerController {
...

이것이 MCP 서버의 전부입니다. 두 개의 엔드포인트. 세 개의 도구 (Tools). 150줄 미만의 코드.

그리고 이것은 제가 이전에 가졌던 2,000줄짜리 AI 괴물보다 더 잘 작동합니다.

이것이 실제로 작동하는 이유 (직관에 반하는 교훈들)

여러분이 무슨 생각을 하는지 압니다: "잠깐, 그게 끝인가요? 화려한 AI는 없나요?" 네. 그게 끝입니다. 그리고 이것이 작동하는 이유는 다음과 같습니다:

1. AI는 이미 클라이언트에 살고 있습니다

제가 MCP 서버와 함께 Claude Desktop을 사용할 때, 이해(Understanding)는 Claude가 수행합니다. 제 서버가 쿼리 (Query)를 이해할 필요는 없습니다. 저는 그저 관련 문서를 Claude의 컨텍스트 (Context)에 넣어주기만 하면 됩니다. Claude는 이미 어떻게 정보를 합성하고, 점들을 연결하며, 질문에 답하는지 알고 있습니다.

제 서버는 똑똑할 필요가 없습니다. 그저 좋은 데이터 제공자 (Data Provider)가 되기만 하면 됩니다. 그게 전부입니다.

2. 단순함 = 빠름 = 더 유용함

이전에는 검색당 3~7초가 걸렸습니다. 지금은 50ms입니다. 60배 더 빠릅니다. 이는 밤과 낮의 차이입니다. 검색이 즉각적일 때, 당신은 그것을 더 많이 사용합니다. 느릴 때, 당신은 그것을 피하게 됩니다. 그것은 그저 인간의 본성입니다.

저는 단지 빠르다는 이유만으로 첫 달에 사용량을 두 배로 늘렸습니다.

3. 기본 설정으로서의 프라이버시 (Privacy By Default)

모든 지능이 클라이언트(Client)에 있기 때문에, 제 데이터는 제 서버에 그대로 머뭅니다. 2,847개의 모든 기사를 어떤 제3자 임베딩 (Embedding) 서비스에 업로드할 필요가 없습니다. Claude는 제가 지금 검색하고 있는 특정 기사들만 전달받습니다. 나머지는 비공개 상태로 유지됩니다.

이는 프라이버시 측면에서 엄청난 이점입니다. 게다가 비용도 들지 않습니다. 무언가를 업데이트할 때마다 2,847개의 임베딩에 대해 비용을 지불할 필요가 없습니다.

4. 표준 프로토콜은 어디서나 작동함을 의미한다 (Standard Protocol Means It Works Everywhere)

MCP를 구현하고 나니, MCP 호환 클라이언트라면 무엇이든 바로 작동했습니다. Claude Desktop, VS Code, 그리고 향후 MCP를 지원할 모든 클라이언트들 말입니다. 각 클라이언트마다 맞춤형 통합 (Custom Integration)을 구축할 필요가 없습니다. 한 번 구현하면 어디서나 사용할 수 있습니다.

이것이 표준의 힘입니다. 저는 오후 한때를 투자해 MCP를 구현했고, 이제는 어디서나 작동합니다.

솔직한 장단점

솔직하게 말씀드리겠습니다. 이 방식이 모든 사람에게 적합한 것은 아닙니다. 무엇이 잘 작동하고, 무엇이 그렇지 않은지 정리해 보겠습니다.

장점 ✅

• 압도적인 속도: 50ms 대 3~7초. 밤과 낮의 차이만큼 극명합니다.
• 매우 간단한 구현: 저는 주말 동안 전체를 다시 작성했습니다.
• 프라이버시 친화적: 데이터가 귀하의 서버에 머뭅니다. 필요한 것만 전송됩니다.
• 저렴한 운영 비용: 비싼 임베딩 API 호출이 필요 없습니다. GPU도 필요하지 않습니다.
• 모든 MCP 클라이언트와 호환: 한 번의 구현으로 어디서나 사용 가능합니다.
• 실제로 사용됨: 속도가 빠르면 = 사용량이 늘어나고 = 가치가 높아집니다. 아이러니한 점은 저의 "멍청할" 정도로 단순한 시스템이 "똑똑하고" 복잡한 시스템보다 더 많이 사용된다는 것입니다.
• 함께 진화함: 필요할 때마다 새로운 도구를 추가하면 됩니다. 대대적인 재작성이 필요 없습니다.

단점 ❌

• MCP 생태계가 아직 초기 단계임 (MCP ecosystem is still young): 모든 AI 클라이언트가 아직 MCP를 지원하는 것은 아닙니다. 호환 가능한 클라이언트가 필요합니다.
• 서버 접근성 필요: 어디서든 사용하려면 MCP 서버에 접근할 수 있어야 합니다. 로컬 개발 시에는 ngrok을 사용할 수 있지만, 24/7 상시 사용을 위해서는 호스팅이 필요합니다.
• 서버 측의 "이해" 능력 부재: 클라이언트가 똑똑하지 않다면 이 방식은 무너집니다. 하지만 그것이 핵심입니다. 클라이언트가 잘하는 일을 클라이언트가 하도록 맡기는 것입니다.
• 기본적인 검색만 가능: string.contains()는 완벽하지 않습니다. 때로는 잘못된 결과(false positives)가 나올 수 있습니다. 하지만 솔직히 말해서, AI 클라이언트가 제가 예전에 사용하던 시맨틱 검색 (semantic search)보다 이를 더 잘 걸러냅니다.
• 확장성 문제: 만약 100,000개의 문서가 있다면, 모든 것을 메모리에 로드하는 방식은 작동하지 않을 수 있습니다. 하지만 개인적인 용도(수천 개의 문서)라면 전혀 문제없습니다.

언제 이 방식을 사용해야 할까요?

제 경험에 비추어 볼 때, 이 MCP 최적화된 "단순하게 유지하라 (keep it simple stupid)" 아키텍처는 다음과 같은 경우에 매우 효과적입니다:

• 개인용 도구 또는 소규모 서비스를 구축할 때
• 데이터 규모가 비교적 작을 때 (10,000개 미만)
• 이미 강력한 추론 (reasoning) 능력을 갖춘 AI 클라이언트에 연결할 때
• 개인정보 보호가 중요할 때
• 복잡한 인프라를 관리하고 싶지 않을 때

반면, 다음과 같은 경우에는 덜 이상적입니다:

• 수천 명의 사용자를 위한 공개 서비스를 구축할 때
• 대규모 인덱싱이 필요한 방대한 양의 데이터를 보유하고 있을 때
• MCP를 지원하지 않는 클라이언트를 지원해야 할 때

하지만 개인 지식 베이스, 내부 도구, 데이터를 AI에 노출하는 커넥터의 경우에는 이것이 정답입니다.

고생하며 배운 점

저는 "모든 시스템에는 AI가 필요하다. 모든 컴포넌트는 똑똑해야 한다"라는 유행에 휩쓸려, 6년 동안 지식 베이스를 과도하게 설계(overengineering)하며 시간을 보냈습니다.

MCP는 저에게 그 반대를 가르쳐 주었습니다:

AI 클라이언트 시대에는, 당신의 서버가 똑똑할 필요가 없습니다. 그저 사용 가능(available)하기만 하면 됩니다. 표준 프로토콜을 통해 데이터를 노출하기만 하면 됩니다. 힘든 작업은 이미 AI 클라이언트가 다 하고 있습니다.

저의 1,800시간 동안의 "실패한" 프로젝트는 이제 실제로 유용해졌습니다. 더 많은 AI를 추가했기 때문이 아닙니다. 거의 모든 AI를 제거하고 클라이언트가 잘하는 일을 하도록 내버려 두었기 때문입니다.

아이러니한 점은 무엇일까요? 제가 구축하는 데 6년이 걸린 시스템이 코드의 90%를 버리고 나서야 비로소 유용해졌다는 것입니다.

그러니 만약 잘 풀리지 않는 오래된 프로젝트를 가지고 있다면, 아마도 이 방법을 시도해 볼 수 있을 것입니다. 모든 복잡성을 걷어내세요. MCP를 통해 데이터를 노출하세요. AI 클라이언트가 지능적인 처리를 담당하게 하세요.

저처럼 여러분도 놀라게 될지도 모릅니다.

여러분의 차례

MCP 서버를 구축해 보셨나요? 과하게 설계되었다(overengineered)고 느껴지는 지식 관리 시스템을 작업 중이신가요? AI가 어디에나 존재하게 된 이후, 더 단순한 것이 결국 더 나은 결과로 이어졌던 유사한 경험이 있으신가요?

아래 댓글을 통해 여러분의 생각을 듣고 싶습니다. 여러분의 MCP 설계 철학은 무엇인가요?