MCP 최적화 지식 베이스: AI가 사고할 때 왜 단순함이 복잡함을 이기는가

솔직히 말해서, 이런 결과가 나올 줄은 몰랐습니다.

6개월 전이었다면, 저는 저의 1,800시간짜리 개인 지식 관리 프로젝트가 처참한 실패라고 말했을 것입니다. 시맨틱 검색 (Semantic Search)부터 AI 추천 엔진까지 모든 것을 구축했고, 클라우드 인프라에 수천 달러를 썼으며, 아무도 사용하지 않는 2,000줄 이상의 Java 코드를 작성했습니다. 통계는 잔혹했습니다:

• 1,847시간의 개발
• 2,847개의 저장된 기사
• 3년 동안 단 84회의 실제 사용
• 2.9%의 지식 활용률
• -99.4%의 ROI (투자 대비 수익)

저는 저장소 전체를 "삭제"하기 직전이었습니다. 그러다 흥미로운 일이 일어났습니다: Model Context Protocol (MCP)가 모든 것을 바꾸어 놓았습니다.

만약 저처럼 세상 돌아가는 걸 모르고 계셨다면 설명해 드리자면, MCP는 AI 클라이언트가 외부 서버로부터 도구 (Tools)를 발견하고 호출할 수 있게 해주는 새로운 표준입니다. AI 에이전트 (AI Agents)를 위한 REST와 같다고 볼 수 있습니다. 갑자기 저의 "실패한" 지식 시스템은 더 이상 실패한 제품이 아니라, 어떤 AI든 사용할 수 있는 MCP 서버가 되었습니다. 그리고 반전은 무엇일까요? 과도한 엔지니어링 (Over-engineering)을 거친 후 제가 결국 도달한 단순한 버전이 MCP 세계에서 정확히 가장 잘 작동한다는 점입니다.

제가 배운 것들을 설명해 드리겠습니다.

과거의 방식: 지식 시스템 내부의 AI

이것이 제가 처음에 구축했던 방식입니다. 모든 지식 관리 너드(Nerd)들처럼, 저도 AI가 시스템 "내부"에 존재해야 한다고 믿었습니다. 시맨틱 이해 (Semantic Understanding)가 필요하고! 벡터 임베딩 (Vector Embeddings)이 필요하며! 추천 알고리즘 (Recommendation Algorithms)도 필요하다고 생각했습니다! 그 모든 좋은 것들 말이죠.

Java로 구현된 모습은 이랬습니다:

// 이것이 2,000줄의 과도한 엔지니어링의 모습입니다
@Service
public class ComplexKnowledgeService {
...

인상적으로 보이죠? 실제로 인상적이었습니다. 하지만 동시에 완전히 불필요하기도 했습니다.

문제는 무엇이었을까요? 제가 AI가 해야 할 일을 대신하려고 했다는 점입니다. GPT-4o나 Claude가 이해하도록 내버려 두기만 해도 되었을 텐데, 저는 몇 달 동안 시맨틱 검색 (Semantic Search)을 최적화하는 데 시간을 허비했습니다. 그 모든 복잡함은 제 시스템을 더 느리고, 더 비싸고, 유지보수하기 어렵게 만들 뿐이었습니다. 그리고 결정적인 사실은—제가 만든 "AI 강화" 검색 기능이, 관련 텍스트를 프롬프트 (Prompt)에 그냥 집어넣고 실제 AI가 작업을 수행하게 하는 것보다 성능이 더 나빴다는 점입니다.

그래서 3년이 지난 지금, 저는 이 엉망진창인 코드를 바라보며 "이게 다 무슨 의미가 있었나?"라고 생각하고 있었습니다. 그러다 MCP에 대해 읽게 되었고, 모든 것이 하나로 연결되었습니다.

MCP의 통찰: AI는 이미 똑똑하다—그저 데이터를 제공하라

깨달음이 마치 거대한 망치처럼 저를 내리쳤습니다: MCP의 세계에서, AI는 당신의 지식 시스템 안에 사는 것이 아닙니다. 당신의 지식 시스템이 AI의 세계 안에 사는 것입니다.

생각해 보세요. Claude Desktop이나 Cursor, 혹은 다른 MCP 호환 클라이언트를 사용할 때, AI는 이미 똑똑한 존재입니다. AI는 문맥 (Context)을 이해할 수 있고, 점들을 연결할 수 있으며, 정보를 합성할 수 있습니다. 당신의 지식 시스템은 그 중 어떤 것도 할 필요가 없습니다. 그저 한 가지를 잘하기만 하면 됩니다: 관련 있는 텍스트 청크 (Chunks)를 찾아내어 AI에게 전달하는 것.

그게 전부입니다. 그것이 통찰의 핵심입니다.

그래서 저는 1,950줄의 코드를 버리고 다음과 같은 결과물을 얻었습니다:

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

그리고 검색 서비스는요? 부끄러울 정도로 단순합니다:

@Service
public class SimpleKnowledgeService {

...

이것이 MCP 서버의 전부입니다. 총 70줄의 코드입니다. 2,000줄에서 줄어든 것이죠.

농담이 아닙니다—이것이 원래의 복잡한 버전보다 더 잘 작동합니다. 정말로, 훨씬 더 잘 작동합니다.

이것이 작동하는 이유 (직관에 반하는 부분)

MCP 아키텍처에서 왜 단순함이 복잡함을 이기는지 그 이유를 설명해 드리겠습니다:

1. 이제 AI가 힘든 일을 수행한다

이전에는 제 지식 시스템에서 시맨틱 이해 (Semantic Understanding)를 수행하려고 노력했습니다. 임베딩 (Embeddings)을 계산하고, 유사한 문서를 찾고, 결과의 순위를 재조정 (Rerank)하는 등 온갖 과정을 거쳤습니다. 하지만 MCP를 사용하면 실제로 다음과 같은 일이 일어납니다:

1. 사용자가 Claude에게 질문합니다: "MCP 최적화에 대해 내가 뭐라고 썼지?"
2. Claude가 "MCP optimization"이라는 쿼리로 나의 search_knowledge 도구를 호출합니다.
3. 나의 단순한 검색이 "MCP" 또는 "optimization"이라는 단어를 포함하는 상위 5개의 문서를 반환합니다.
4. Claude가 문서를 읽고, 문맥을 이해하며, 점들을 연결하여(connect the dots) 질문에 답변합니다.

그게 전부입니다. 이해는 AI가 합니다. 나는 단지 검색 (Retrieval)만 수행할 뿐입니다. 나는 왜 그동안 AI가 해야 할 일을 하려고 애썼던 걸까요?

2. 표준 프로토콜은 보편적 호환성을 의미합니다

이전에는 나의 지식 시스템을 새로운 AI 클라이언트와 함께 사용하려면 커스텀 통합 (Custom integration)을 구축해야 했습니다. 각 클라이언트마다 서로 다른 API, 서로 다른 인증 방식 (Authentication schemes), 서로 다른 응답 형식 (Response formats)을 가지고 있었습니다. 이는 유지보수의 악몽이었습니다.

MCP를 사용하면 어떨까요? 프로토콜을 한 번만 구현하면, 모든 MCP 호환 클라이언트가 이를 사용할 수 있습니다. 이것이 표준의 마법입니다. Claude Desktop, Cursor, OpenAI GPTs, 혹은 다음에 등장할 무엇이든—MCP를 지원한다면 나의 서버와 작동합니다.

3. 설계 단계부터 고려된 프라이버시 친화성

예상치 못했던 또 다른 이점은 다음과 같습니다: 나의 지식이 비공개로 유지된다는 점입니다. 이전에는 AI가 나의 지식을 사용하게 하려면, 나의 모든 노트를 OpenAI나 Anthropic, 혹은 그 누구에게든 업로드해야 했습니다. 그것은 항상 저를 불편하게 만들었습니다. 이 중 일부는 개인적인 노트이고, 프로젝트 아이디어이며, 누구와도 공유하고 싶지 않은 미완성된 생각들이기 때문입니다.

MCP를 사용하면:

• 모든 데이터가 나의 서버에 머뭅니다.
• 현재 쿼리에 대한 특정 결과값만 AI에게 전송됩니다.
• AI는 나의 전체 지식 베이스 (Knowledge base)를 결코 볼 수 없습니다.
• 누가 이에 접근할 수 있는지 내가 제어합니다.

이는 AI가 당신의 지식에 접근하게 하는 것과 당신의 데이터를 비공개로 유지하는 것 사이의 아름다운 절충안입니다.

4. 적은 코드 = 적은 유지보수 = 더 높은 신뢰성

나는 더 이상 벡터 데이터베이스 (Vector databases)를 유지보수할 필요가 없습니다. 임베딩 (Embedding) API 호출 비용을 지불할 필요도 없습니다. 지식이 늘어난다고 해서 모델을 재학습 (Retrain)시킬 필요도 없습니다. 나는 그저 PostgreSQL에 마크다운 (Markdown) 파일을 저장하고, 시작 시 메모리에 로드한 뒤, 단순한 문자열 매칭 (String matching)을 수행할 뿐입니다.

제 호스팅 비용이 월 45달러에서 5달러로 줄었습니다. 이미 프로젝트에서 11만 2천 달러의 손실을 보고 있는 상황에서 이는 결코 적은 금액이 아닙니다.

장단점 (편향되지 않았음을 약속합니다)

자, 솔직해집시다. 이 접근 방식이 완벽하지는 않습니다. 세상에 완벽한 것은 없으니까요. 진짜 실상을 말씀드리겠습니다:

✅ 나를 놀라게 한 장점들

1. 그냥 작동합니다 – 외부 ML API에 의존할 필요도 없고, 복잡한 인프라도 필요 없으며, OpenAI에 문제가 생겨도 다운타임이 없습니다. 제 서버만 살아있다면 작동합니다. 그게 전부입니다.

2. 놀라울 정도로 빠릅니다 – 2,800개의 문서가 담긴 제 4GB VPS에서 검색은 5~10ms가 소요됩니다. 눈 깜짝할 사이죠. 문서가 28,000개가 된다 해도, LLM의 응답을 기다리는 것보다는 여전히 빠를 것입니다.

3. AI가 전체 문맥(Context)을 파악합니다 – 단순히 링크나 요약본이 아닌 실제 콘텐츠를 전송하기 때문에, AI가 제가 작성한 내용을 실제로 '읽을' 수 있습니다. 여러 문서에 걸쳐 아이디어를 연결할 수 있고, 저를 정확하게 인용할 수도 있습니다. 단순히 "여기 몇 개의 링크가 있으니 직접 읽어보세요"라고 하는 것보다 훨씬 유용합니다.

4. 반복 작업(Iteration) 비용이 저렴합니다 – 새로운 도구를 추가하고 싶나요? 엔드포인트(Endpoint)를 하나 더 추가하면 됩니다. 검색 방식을 바꾸고 싶나요? 코드 10줄만 수정하면 됩니다. 거창한 재배포(Redeployment)도, 스키마 마이그레이션(Schema migration)도 필요 없습니다.

5. 죽어있던 프로젝트를 부활시켰습니다 – 이것이 가장 큰 부분입니다. 제 1,800시간짜리 "실패작"이 다시 유용해졌습니다. 이전에는 글을 쓸 때 몇 달에 한 번씩이나 열어보곤 했습니다. 하지만 이제 Claude는 제가 작업했던 프로젝트에 대해 논의할 때 자동으로 이를 사용합니다. 마치 실제로 무언가를 기억하는 제2의 뇌를 갖게 된 것 같습니다.

❌ 당신이 알아야 할 단점들

1. 무차별 대입 방식 (Brute-force)임 – 단순한 문자열 매칭 (String matching)은 의미론적 검색 (Semantic search)만큼 똑똑하지 않습니다. 만약 제가 "model context protocols"라고 쓰고 "MCP"로 검색한다면, 적절하게 태그를 달아두지 않는 한 찾아내지 못합니다. 이것이 문제일까요? 솔직히 말해서, 그렇게 자주 발생하지는 않습니다. 중요한 상황이 오면, 그냥 다른 용어로 다시 검색하면 됩니다.

2. 지식이 늘어날수록 메모리 사용량도 증가함 – 만약 100,000개의 문서가 있다면, 모든 것을 메모리에 로드하는 방식은 작동하지 않을 것입니다. 하지만 개인용 지식 베이스 (Knowledge base)라면 어떨까요? 2,000~10,000개의 문서는 현대적인 서버에게 아무것도 아닙니다. 1GB의 RAM에 얼마나 많은 텍스트가 들어갈 수 있는지 알게 되면 놀라실 겁니다.

3. MCP는 아직 초기 단계임 – 생태계가 발전하고 있습니다. 아직 모든 AI 클라이언트 (Client)가 이를 지원하는 것은 아닙니다. 프로토콜 (Protocol) 자체도 변경될 수 있습니다. 만약 프로덕션 (Production) 환경을 위해 매우 견고한 무언가가 필요하다면, 아마 1년 정도 더 기다려야 할지도 모릅니다. 하지만 개인 프로젝트라면? 지금 당장 사용하기에 완벽합니다.

4. 여전히 호스팅이 필요함 – 클라우드 클라이언트가 사용하려면 MCP 서버가 공개적으로 접근 가능해야 합니다. 만약 로컬에서만 작동하기를 원한다면 Claude Desktop과 같은 로컬 클라이언트에게는 괜찮지만, 어디서나 사용할 수 있게 하려면 호스팅이 필요합니다. 저는 저렴한 VPS를 사용하고 있으며 문제없지만, 이는 관리해야 할 항목이 하나 더 늘어나는 것을 의미합니다.

5. 컨텍스트 윈도우 (Context window) 제한은 여전히 적용됨 – 한 번의 프롬프트 (Prompt)에서 AI에게 보낼 수 있는 텍스트 양에는 한계가 있습니다. 만약 검색 결과로 5개의 긴 문서가 반환된다면, 컨텍스트 제한에 걸릴 수 있습니다. 저는 API 응답 시 긴 문서를 2,000자로 잘라내는 (Truncating) 방식으로 이 문제를 해결하며, 이는 대부분의 경우 잘 작동합니다. 만약 AI가 더 많은 정보가 필요하다면, 전체 문서를 요청할 수 있습니다.

고생하며 배운 점들

3년간의 과잉 엔지니어링 (Over-engineering)과 한 달간의 MCP 실험을 거친 후, 제가 내린 결론은 다음과 같습니다:

AI 에이전트 (AI agents)의 시대에, 당신의 지식 시스템은 똑똑할 필요가 없습니다. 그저 찾아낼 수만 있으면 됩니다.

AI는 이미 똑똑합니다. 그것이 AI의 역할입니다. 당신의 역할은 적절한 시점에 적절한 정보를 AI에게 제공하는 것입니다. 그게 전부입니다. AI보다 더 똑똑해질 필요는 없습니다. 그저 AI를 당신의 데이터에 연결하기만 하면 됩니다.

저는 3년 동안 AI 기반 지식 시스템을 구축해야 한다고 생각하며 시간을 보냈습니다. 알고 보니, 제가 필요했던 것은 AI가 구동할 수 있는 지식 시스템을 구축하는 것이었습니다. 큰 차이가 있습니다.

제가 배운 또 다른 사실은 단순한 시스템이 복잡한 시스템보다 더 오래 살아남는다는 것입니다. 제가 만든 2,000줄짜리 시맨틱 검색 (semantic search) 괴물은 이미 구식이 되었습니다. 반면, 저의 70줄짜리 MCP 서버는 단 한 가지 단순한 일을 수행하고 표준 프로토콜 (standard protocol)을 사용하기 때문에 아마 5년 후에도 여전히 작동할 것입니다.

직접 시도해 보세요

먼지만 쌓여가고 있는 기존 지식 베이스가 있다면, 이 접근 방식을 시도해 보시길 권장합니다. 모든 것을 다시 작성할 필요는 없습니다. 그저 기존 검색 기능을 노출하는 MCP 엔드포인트 (endpoint)를 추가하기만 하면 됩니다.

최소한의 체크리스트는 다음과 같습니다:

1. 도구 정의를 포함한 GET /mcp/tools/list 구현
2. 도구를 실행하는 POST /mcp/tools/call 구현
3. 인증 (authentication) 추가 (아무나 당신의 지식에 접근하는 것을 원치 않을 테니까요)
4. 당신의 서버를 가리키도록 MCP 클라이언트 (client) 설정
5. 그게 전부입니다. 바로 사용을 시작하세요.

제 구현 전체는 오픈 소스(open source)로 공개되어 있으니 확인해 보셔도 좋습니다: https://github.com/kevinten10/Papers

아직 진행 중인 작업이지만, 그것이 바로 핵심입니다. 단순함을 유지하고, 진행하면서 반복 (iterate) 하세요.

당신의 차례입니다

저는 아직 MCP라는 게임에 꽤 초보 단계입니다. 이 접근 방식은 저의 개인 지식 베이스에 놀라울 정도로 잘 작동했지만, 아마 더 똑똑한 방법들이 분명히 있을 것이라고 생각합니다.

당신은 자신의 지식 시스템에 MCP를 통합해 보았나요? 여전히 저처럼 검색 기능을 과도하게 설계 (over-engineering) 하고 있나요? 단순한 브루트 포스 (brute-force) 방식과 완전한 시맨틱 검색 (semantic search) 사이에서 더 나은 절충안을 찾으셨나요?

아래에 댓글을 남겨 당신의 경험을 들려주세요. 다른 사람들이 이 분야에서 무엇을 구축하고 있는지 진심으로 궁금합니다.

그리고 만약 이 단순한 접근 방식을 시도해 보신다면, 당신에게 어떻게 작동했는지 알려주세요. 어쩌면 우리 모두 이 지식 관리라는 것을 지나치게 깊게 생각하고 있는 것일지도 모릅니다.