MCP와 개인정보 보호: 왜 나의 MCP 지식 베이스가 개인 메모용으로 ChatGPT보다 더 나은가

솔직히 말해서, 저는 제 모든 개인적인 메모를 ChatGPT에 넣는 것에 대해 정말 편집증적인 불안감을 느꼈었습니다.

생각해 보세요 — 모든 아이디어, 모든 미완성된 프로젝트, 모든 재무 계획, 새로운 것을 배우며 저지른 모든 어리석은 실수들까지 말이죠. 그 모든 것이 OpenAI의 서버로 업로드되고, 영구적으로 저장되며, 어쩌면 그들의 모델을 학습시키는 데 사용될지도 모릅니다. 제가 숨겨야 할 불법적인 무언가가 있어서가 아닙니다 — 그저 _그것은 나의 것_이기 때문입니다, 아시겠어요?

저는 Papers라고 불리는 개인 지식 베이스를 구축하는 데 6년을 보냈습니다. 여기에는 제 경력 전반에 걸쳐 수집한 2,800개 이상의 메모가 담겨 있습니다. 기억하고 싶은 디자인 패턴(Design Patterns)부터, 고생하며 배운 디버깅(Debugging) 기술, 언젠가 만들지도 모를 사이드 프로젝트(Side Projects)에 대한 아이디어까지 모든 것이 들어 있습니다.

MCP (Model Context Protocol)가 등장했을 때, 무언가 깨달음이 왔습니다. 제 지식을 실제로 넘겨주지 않고도 AI가 제 지식을 사용하게 할 수 있다는 것을 깨달았습니다. 그리고 솔직히 말하자면? 기대했던 것보다 훨씬 더 잘 작동했습니다.

핵심은 이렇습니다 — AI 메모 작성의 개인정보 보호 문제

대부분의 AI 메모 작성 앱은 다음과 같이 작동합니다:

1. 모든 메모를 그들의 클라우드에 업로드합니다.
2. 그들은 모든 것을 처리하고, 임베딩(Embedding)하고, 저장합니다.
3. 질문을 하면, 그들은 전체 컨텍스트(Context)를 AI에게 보냅니다.
4. 답변이 돌아오지만, 당신의 데이터는 이미 그들의 서버에 있습니다.

당신은 그들을 신뢰할 수도 있습니다. 아닐 수도 있고요. 저는 신뢰하지 않았습니다.

저는 모든 방법을 시도해 보았습니다. 제 컴퓨터에서 실행되는 로컬 LLM (Local LLMs) — 개인정보 보호에는 훌륭하지만, 제 노트북은 정확히 데이터 센터라고 할 수는 없습니다. 느리고, 뜨거워지며, 배터리가 한 시간 만에 방전됩니다. 셀프 호스팅 벡터 데이터베이스 (Self-hosted vector databases) — 유지 관리가 복잡하고, 24시간 내내 실행하기에 비용이 많이 들며, Claude나 GPT-4와 같은 좋은 모델을 사용하려면 여전히 데이터베이스 전체를 어딘가로 보내야 합니다.

제가 원했던 것은 간단했습니다:

• 모든 메모를 내 자체 서버에 보관하기
• 질문할 때 AI가 메모를 사용할 수 있게 하기
• AI가 지금 당장 필요한 _특정 조각(fragments)_만 전송하기
• 제3자에 의해 영구적으로 저장되는 데이터가 없도록 하기
• 모든 MCP 호환 클라이언트와 쉽게 사용하기

MCP는 저에게 정확히 그것을 제공했습니다.

MCP가 개인정보 보호의 판도를 바꾸는 방식

제가 최종적으로 구축한 아키텍처(Architecture)를 보여드리겠습니다. 이전에 제가 하던 방식과 비교하면 사실 말도 안 될 정도로 간단합니다.

MCP 도입 전:

1. 내 지식 베이스(Knowledge base) → 모든 항목에 대해 전체 임베딩(Embeddings) 생성
2. Pinecone/Weaviate 등 원하는 곳에 임베딩 저장
3. 쿼리(Query)가 들어오면 → 쿼리를 임베딩하고 유사한 메모 검색
4. _유사한 메모 전체_를 OpenAI/Anthropic으로 전송
5. 답변 수신

문제점: 제3자 LLM(Large Language Model)을 사용하는 경우, 여전히 그 모든 메모를 그들에게 전송하게 됩니다. 어떤 사람들에게는 괜찮을지 모르지만, 저에게는 그렇지 않습니다.

MCP 최적화 후:

1. 내 지식 베이스 → MCP 엔드포인트(Endpoints) tools/list 및 tools/call 노출
2. AI 클라이언트가 내 로컬 머신(또는 어디든)에서 실행됨
3. 질문을 하면 → _클라이언트_가 검색을 위해 내 MCP 서버를 호출
4. 내 서버는 일치하는 조각(fragments)만 반환
5. 클라이언트는 질문과 함께 오직 그 조각들만 LLM으로 전송

차이점이 무엇일까요? 내 전체 지식 베이스는 절대 내 서버를 떠나지 않습니다. _이 특정 질문_과 관련된 아주 작은 부분들만 LLM으로 전달될 뿐입니다. 그게 전부입니다.

코드로는 다음과 같이 구현됩니다 (제가 잘 아는 Java Spring Boot를 사용했습니다):

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

기본적으로 이게 전부입니다. 개인정보 보호에 초점을 맞춘 전체 MCP 서버는 150줄 미만의 코드로 구성됩니다. 원하지 않는다면 거창한 임베딩 서버도 필요 없습니다. 저는 단순히 텍스트 검색을 사용하는데, AI가 모든 힘든 작업을 대신 수행하기 때문에 놀라울 정도로 잘 작동합니다.

잠시만요, 도구 정의(Tool definition)도 보여드릴게요. AI 클라이언트가 당신의 도구가 무엇을 하는지 이해하기 위해 사용하는 것이기 때문입니다:

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

무슨 뜻인지 이해하시겠나요? 매우 간단합니다. AI 클라이언트(AI client)는 내 노트에서 관련 내용을 가져오기 위해 search_knowledge를 호출할 수 있다는 것을 알고 있습니다. 내 서버는 모든 것을 노출하지 않으며, 오직 현재 쿼리(query)와 일치하는 내용만 제공합니다.

구체적인 관점에서의 개인정보 보호 차이

제게 2,800개의 노트가 있다고 가정해 봅시다(실제로 그렇습니다). 노트 하나당 평균 500단어라고 하면, 총 140만 단어입니다.

MCP를 사용하기 전, 질문을 하고 싶었을 때:

• LLM에 전송된 양: 약 2,000~5,000단어 (가장 잘 일치하는 노트들)
• 하지만 클라우드 임베딩 (cloud embedding) 방식을 선택했다면, 당신의 데이터베이스 전체가 이미 타인의 서버에 올라가 있는 상태입니다

현재 나의 MCP 설정 방식:

• LLM에 전송된 양: 약 2,000~5,000단어 (가장 잘 일치하는 파편들)
• 당신의 데이터베이스 전체는 절대 당신의 서버를 떠나지 않습니다
• 오직 _이 특정 쿼리_를 위한 파편들만이 어딘가로 전송됩니다

설령 LLM 제공업체가 모든 것을 로그(log)에 남긴다 하더라도, 그들은 당신이 실제로 질문한 파편들만 얻을 수 있습니다. 당신의 나머지 개인적인 정보들은 얻지 못합니다.

저는 이 사실을 뼈아픈 경험을 통해 배웠습니다. 예전에 인기 있는 AI 노트 필기 앱을 사용했는데, 어느 날 그들이 사용자 데이터를 학습에 사용할 수 있도록 개인정보 보호정책을 변경했다는 사실을 깨달았습니다. 안녕히 계세요.

실제로 무엇이 어디에 저장되는가?

이 부분에 대해 100% 명확히 말씀드리겠습니다:

항목	저장 위치	접근 가능 인원
나의 모든 개인 노트	오직 나의 서버	오직 나
...

이것이 바로 큰 승리입니다. 만약 타인의 서버보다 자신의 서버를 더 신뢰한다면, 이 아키텍처(architecture)는 당신을 위한 것입니다.

장단점 — 솔직하게 이야기해 봅시다

단점까지 말씀드리지 않는다면 제 역할을 다하지 않는 것이겠죠. 이것이 모든 사람에게 적합한 것은 아닙니다.

✅ 매우 잘 작동하는 부분

1. 설계 단계부터 고려된 진정한 개인정보 보호 (True privacy by design) — 당신의 데이터는 당신의 것입니다. 당신의 개인적인 생각이 다른 누군가의 모델을 학습시키는 것을 원치 않는다면, 이것이 바로 정답입니다.

2. 점진적 도입 (Incremental adoption) — 모든 것을 새로운 서비스로 마이그레이션(Migration)할 필요가 없습니다. 기존의 노트들을 MCP 엔드포인트(Endpoints)로 감싸기만 하면 됩니다. 저는 6년 된 프로젝트를 단 한 오후 만에 마이그레이션했습니다.

3. 모든 MCP 클라이언트와 호환 (Works with any MCP client) — Claude Desktop, Cursor, 혹은 다음에 등장할 그 무엇이든 상관없습니다. MCP를 지원하기만 한다면 작동합니다. 특정 벤더 종속성(Vendor lock-in)이 없습니다.

4. 매우 저렴한 비용 (Cheap as chips) — 저의 전체 설정은 Fly.io에서 한 달에 약 3달러 정도로 운영됩니다. 데이터베이스, MCP 서버, 모든 것을 포함한 금액입니다.

5. 이미 유지 관리 방법을 알고 있음 (You already know how to maintain it) — 기본적인 웹 서버를 운영할 수 있다면, 이것도 운영할 수 있습니다. 새로 배워야 할 이상하고 생소한 인프라가 없습니다.

❌ 아직 작동하지 않는 부분 (What doesn't work (yet))

1. MCP는 아직 초기 단계임 (MCP is still young) — 아직 모든 AI 클라이언트가 이를 지원하는 것은 아닙니다. 생태계가 빠르게 성장하고 있지만, 아직 보편적이지는 않습니다. 오늘 당장 모든 것이 완벽하게 작동하기를 원한다면 답답할 수 있습니다.

2. 서버를 직접 관리해야 함 (You have to maintain a server) — 어렵지는 않지만, 여전히 관리해야 할 대상입니다. 서버를 다루고 싶지 않다면, 이것은 당신을 위한 것이 아닙니다.

3. 기본적으로 제공되는 기기 간 동기화 기능 없음 (No cross-device sync out of the box) — 아, 사실 이건 쉽습니다. 그냥 Git으로 노트를 동기화하면 됩니다. 저는 이미 그렇게 하고 있었고요. 그래서 저에게는 이것이 큰 단점이 아닐 수도 있습니다. 하지만 이미 동기화를 하고 있지 않았다면, 별도로 설정해야 합니다.

4. 검색이 기본적으로 "스마트"하지 않음 (Search isn't "smart" out of the box) — AI가 이해를 수행하기 때문에 단순 텍스트 검색도 놀라울 정도로 잘 작동합니다. 하지만 노트가 수천 개라면 여전히 임베딩 (Embeddings)이 필요할 수 있습니다. 물론 서버에서 로컬로 임베딩을 수행할 수도 있습니다. 제가 하는 방식이며, 데이터는 절대 외부로 나가지 않습니다.

5. 오프라인 사용이 까다로움 (Offline use is tricky) — 모든 것을 로컬에서 실행하지 않는 한, LLM에 접속하기 위해서는 여전히 인터넷 연결이 필요합니다. 로컬에서 실행할 수도 있지만, 그러면 다시 로컬 LLM 성능 문제로 돌아가게 됩니다.

실제로 누가 이것을 해야 할까요?

이것을 구축하고 몇 달 동안 매일 사용해 본 후, 저의 솔직한 의견은 다음과 같습니다:

이런 분들은 시도해 보세요:

• 이미 수천 개의 개인 메모를 보유하고 있는 경우
• 모든 데이터를 제3자 AI 서비스에 업로드하는 것이 꺼려지는 경우
• 기본적인 웹 서버를 실행할 줄 아는 경우
• Claude Desktop이나 Cursor와 같은 MCP 호환 클라이언트를 이미 사용 중인 경우
• AI가 내 메모를 "소유"하는 것이 아니라, 내 메모를 "사용"하기만을 원하는 경우

이런 분들은 굳이 하지 않으셔도 됩니다:

• 메모가 수백 개 정도밖에 없는 경우
• 개인정보 보호에 크게 신경 쓰지 않는 경우 (이것도 전혀 문제없습니다!)
• 어떠한 인프라(Infrastructure)도 유지 관리하고 싶지 않은 경우
• 설정 없이 모든 것이 즉시 "그냥 작동"하기를 원하는 경우

솔직히 말해서, 단순히 MCP가 어떻게 작동하는지 이해하기 위해서라도 이 작업은 오후 시간 정도를 투자할 가치가 있습니다. 저는 이 150줄짜리 서버를 구축하면서 모든 문서를 읽었을 때보다 MCP에 대해 더 많은 것을 배웠습니다.

예상치 못했던 세 가지 이점

1. 지식 베이스(Knowledge Base)의 더 빠른 반복(Iteration) — 제 서버에서 제 코드가 실행되기 때문에, 원할 때마다 검색 순위(Search Ranking)를 미세 조정할 수 있습니다. 승인을 기다리거나 다른 사람의 API가 변경되는 문제를 겪을 필요가 없습니다. 최신 메모에 더 높은 가중치를 두고 싶다면, 코드 한 줄을 수정하고 배포하기만 하면 됩니다. 끝입니다.

2. AI를 위한 더 나은 컨텍스트(Context) — 메모 전체가 아니라 관련 파편(Fragments)만 전송하기 때문에 컨텍스트 창(Context Window)이 낭비되지 않습니다. AI는 질문에 답하는 데 정확히 필요한 정보만을 얻습니다. 실제로 메모 전체를 보냈을 때보다 지금 더 나은 답변을 얻고 있습니다.

3. 메모를 작성하는 방식의 변화 — 더 간결하고 집중된 메모를 작성하기 시작했습니다. 검색 결과가 파편 단위로 반환된다는 것을 알기 때문에, 예전만큼 장황하게 늘어놓지 않게 됩니다. 장황하게 쓰는 것이 나쁘다는 뜻은 아닙니다. 단지 아키텍처(Architecture)가 당신의 습관을 어떻게 바꾸는지 관찰하는 것이 흥미로울 뿐입니다.

결론

MCP는 단순히 AI 클라이언트를 도구에 연결하는 것에 관한 것이 아닙니다. 그것은 바로 "제어권(Control)"에 관한 것입니다. 데이터가 어디에 머무는지에 대한 제어권, 누가 무엇을 보는지에 대한 제어권, 그리고 당신 자신의 인프라에 대한 제어권 말입니다.

저는 이 지식 베이스(knowledge base)를 구축하기 위해 6년 동안 과도하게 설계(over-engineering)하는 데 시간을 쏟았고, 그 결과 99.4%의 마이너스 ROI(투자 대비 수익, 실제로 제가 계산한 실화입니다)를 기록했습니다. 그러다 MCP가 등장하면서 이것을 다시 실제로 유용하게 만들 수 있었습니다. 제가 해야 했던 일은 단지 이를 MCP 서버로 노출하기 위해 150줄의 코드를 추가하는 것뿐이었습니다.

처음에는 개인정보 보호(privacy) 측면이 제가 이 작업을 수행한 주요 이유는 아니었습니다. 그것은 단지 아키텍처(architecture)에서 자연스럽게 파생된 결과였습니다. 하지만 일단 구축하고 나니, 이전으로 돌아가는 것은 상상조차 할 수 없습니다. AI를 사용하고 있을 때조차 나의 개인적인 메모가 비공개로 유지된다는 사실을 아는 것은 정말 멋진 일입니다.

여러분은 어떠신가요? 여러분의 모든 개인적인 메모를 AI 서비스에 넣는 것이 걱정되시나요? 여러분의 데이터를 위한 MCP 서버를 구축해 보셨나요? 여러분이 어떤 개인정보 보호 아키텍처(privacy architectures)를 사용하고 있는지 아래 댓글을 통해 듣고 싶습니다.

MCP가 개인용 AI의 개인정보 보호 게임의 판도를 바꾼다고 생각하시나요, 아니면 여전히 그만한 가치를 들일 만큼의 노력보다 번거로움이 더 크다고 생각하시나요?