LLM을 내 두 번째 뇌로 만들기: MCP 서버로 개인 블로그를 RAG로 활용하는 방법

#ai #mcp #llms-txt #claude-code #second-brain #fastmcp #co-work

2025년 12월 31일

안녕하세요. 프롭테크 플랫폼에서 백엔드 개발자로 근무 중인 3년차 백엔드 개발자 정정일입니다.

최근 AI, 특히 LLM(대형 언어 모델)이 개발자들 사이에서 큰 관심을 받고 있습니다. 물론 최근이라기엔 시간이 조금 되긴 했지만 날이 갈수록 개발자들의 일상에 또 여러 산업에서 AI 기술이 스며들고 있죠. 저 역시 LLM을 활용해 생산성을 높이고 학습에 활용하기도 하며 지식을 관리하는 방법에 대해 고민해왔습니다.

그 방법 중에 하나로 LLM과 MCP(Model Context Protocol) Server를 활용해 제가 가진 경험들과 규칙들을 LLM이 활용할 수 있도록 구성해보았고 이번 글에서 이에 관해 적어보려 합니다.

두번째 뇌

Obsidian이라는 툴을 아시나요? Obsidian 은 Notion 혹은 OneNote 와 마찬가지로 필기 혹은 메모를 위한 개발자 도구 입니다. 개발자들에게 친숙한 Markdown 형식을 지원하고, 로컬 파일로 저장되며, 강력한 링크 기능과 플러그인 생태계를 가지고 있죠.

갑자기 Obsidian 이야기를 왜 꺼내지? 하실 수 있습니다. Obsidian 이야기를 꺼내는 이유는 저는 개발자들이 Obsidian을 많이 사용하는 이유중 하나가 “두 번째 뇌(Second Brain)” 로 활용하기 위한 시도라고 생각합니다.

Obsidian만 검색해봐도 “Obsidian 두번째 뇌로 활용하는법!”, “개발자를 위한 두번째 뇌 구축하기” 등과 같은 글들이 나오니까요. 개발자들이 Obsidian 을 활용해 자신의 지식을 체계적으로 정리하고 관리하는 사례가 많기 때문이라고 저는 생각합니다.

두 번째 뇌(Second Brain)란? 내 머릿속 지식을 외부화하여 저장하고 관리하는 시스템을 의미합니다. Obsidian, Notion, Roam Research 등 다양한 도구들이 두 번째 뇌 구축에 활용될 수 있습니다.

왜 사람들은 두 번째 뇌를 원할까?

그렇다면 왜 사람들은 두 번째 뇌를 원할까요?

개발자들은 매일 새로운 문제를 해결하고, 복잡한 시스템을 설계하며, 다양한 도구와 기술을 사용합니다. 이 과정에서 많은 지식과 경험이 쌓이지만, 이를 체계적으로 관리하지 않으면 쉽게 잊혀지거나 활용되지 못할 수 있습니다. 시간이 지나면 자연스레 기억이 희미해지기도 하구요. 물론 이는 꼭 개발자 뿐만 아니라 모든 직군에 해당되는 이야기이긴 합니다.

개발하면서 마주치는 수많은 지식과 경험들인 트러블슈팅 경험, 아키텍처 결정 과정에서의 고민들, 컨벤션과 규칙, 성능 개선 노하우, 배우고 공부한 것들에 대한 정리 이런 지식들을 Obsidian에 정리하고, 링크로 연결하고, 필요할 때 꺼내 보면서 개발자들은 “내 머릿속 지식을 외부화” 할 수 있었습니다.

첫 번째 뇌(머리)는 새로운 문제를 고민하는 데 집중하고, 두 번째 뇌(Obsidian)는 과거 경험을 저장하는 역할 분담이 가능해진 거죠.

하지만 Obsidian에는 한계가 있었습니다

모든 도구들이 그렇듯 Obsidian도 장점이 있다면 단점도 있다고 생각합니다. 제가 생각했던 두번째 뇌로써의 Obsidian의 단점은 수동적이라는 점이라고 생각합니다.

과거에 제가 어떤 경험을 했는지, 어떤 문제를 어떻게 해결했는지에 대한 지식이 Obsidian에 잘 정리되어 있다고 해도, 이를 찾고 활용하는 과정이 직접적이어야 했습니다.

예를 들어, 새로운 문제에 직면했을 때 Obsidian을 열고, 관련된 키워드로 검색을 해야 했습니다. 그리고 검색 결과에서 관련된 노트를 찾아 읽고, 그 내용을 현재 문제에 적용해야 했죠.

“이 문제 어떻게 해결했더라?” 하고 검색창을 열어야 하고, 여러 노트를 뒤적이며 관련 내용을 찾아야 합니다. 정리해두었던 컨벤션 문서를 찾기위해 이 문서 저 문서를 뒤지면서 시간을 허비하는 경험, 다들 있으시죠?

AI 시대, LLM으로 Second Brain을 만들 수 있을까?

그렇다면 수동적이지 않은 두 번째 뇌는 가능할까요? 기존에는 어려웠다 하더라도 AI, 특히 LLM(대형 언어 모델)이 발전하면서 가능해졌다고 생각합니다.

ChatGPT나 Gemini, Claude와 같은 LLM을 사용하시면서 내 이야기를 기억하고 내 상황에 맞는 답변을 해주는 경험, 다들 해보셨을 겁니다. 이는 LLM이 대화의 맥락을 이해하고, 이전 대화 내용을 기억하며, 사용자 맞춤형 응답을 생성할 수 있기 때문이죠.

이는 LLM을 제공하는 플랫폼들이 “Memory”, “Custom Instructions”, “Projects” 와 같은 기능들을 제공하기 때문입니다. 내부적으로는 Short Term Memory 와 Long Term Memory 로 나누어져 있기도 하지만 세부적인 것은 이번 주제와는 조금 거리가 있으니 넘어가겠습니다.

결국은 LLM이 내 말들을 기억하고, 이전에 이야기했던 걸 기억해내 이야기 하는거죠. 이 기능들은 개발자들이 원하는 두 번째 뇌의 역할과도 어느정도 일맥상통하다고 생각합니다. 과거에 내가 쌓아둔 지식과 경험을 LLM이 기억하고, 새로운 문제에 맞게 활용해주는 것이니까요.

그렇다면 특정 플랫폼에서 꾸준히 LLM과 대화를 나누면서 내 지식과 경험을 쌓아가면, LLM이 내 두 번째 뇌 역할을 해줄 수 있지 않을까요?

어떤 일이 있을때마다 ChatGPT나 Claude에게 물어보고 말하고, 그때그때 답변을 받으면서 점점 내 지식과 경험을 LLM이 쌓아가는 거죠. 그리고 나중에 해당 지식을 활용해야 할때 LLM에게 물어보면, 내가 쌓아둔 지식과 경험을 바탕으로 답변을 해주는 겁니다.

과연 이렇게 되면 두번째 뇌를 완성했다고 할 수 있는 것일까요?

이 방식에는 명확한 한계가 있습니다

1. Context Window 제한

Context Window란 LLM이 한 번에 처리할 수 있는 텍스트의 양을 의미합니다. 초기 GPT-4는 8,000 토큰 정도였지만, 최근에는 128k, 200k 토큰 이상을 지원하는 모델들도 등장했습니다. 하지만 아무리 큰 컨텍스트 윈도우라도 결국 한계가 있습니다.

토큰을 초과하면, LLM은 이전 대화 내용을 잊어버리기 시작합니다. ChatGPT나 Gemini와 오래 대화를 나누다 보면, 이전에 이야기했던 내용들이 점점 잊는 것 같은 경험을 다들 해보셨을 겁니다. 이런 원인은 Context Window 한계 때문입니다.

예를 들면 다음과 같은 경험들을 많이 해보셨을 겁니다.

“내가 무슨말을 하든 반말로 대답해줘” → 처음엔 잘 지키다가, 대화가 길어지면 점점 존댓말로 바뀜

결국 Memory에 저장돼 있던 기억들도 제가 다시 언급해주지 않으면 Context Window 한계로 인해 LLM에게 전달되지 못하는 상황이 발생할 수 있습니다.

2. 플랫폼 종속성

또 커다란 문제중 하나는 특정 플랫폼에 쌓아둔 “기억” 들은 플랫폼에 종속적이라는 겁니다.

ChatGPT에 쌓아둔 Memory들은 ChatGPT에만 있고 Gemini에 쌓아둔 Memory들은 Gemini에만 있습니다. 즉, 특정 플랫폼에서 쌓아둔 지식과 경험들은 다른 플랫폼으로 옮겨갈 수 없습니다. ChatGPT와 대화 하다가 “Claude에서 내가 뭐라고 했더라?” 라고 하면 ChatGPT는 알수가 없죠.

만약 ChatGPT를 1년간 사용하며 열심히 Memory를 쌓아가며 사용하던 와중에 ChatGPT 에서 유료버전 정책을 바꾸거나, 성능이 떨어지거나, 다른 플랫폼에 더 좋은 모델이 등장하거나, 다른 이유로 인해 Claude나 Gemini로 갈아타야 한다면 어떻게 될까요?

절망적이게도 다른 플랫폼에서 처음부터 다시 Memory를 쌓아야 합니다.

개발자들은 의존성을 관리하는 데 익숙합니다. 라이브러리나 프레임워크, 특정 클라우드 서비스에 의존성을 가지게 될 때, 이를 관리하고 최소화하려고 노력하죠. 마찬가지로 LLM 플랫폼 의존성도 관리해야 하는 상황이 되는 거죠.

내 지식이 플랫폼에 갇혀버리는 일이 발생하는 겁니다.

3. 프롬프트로 해결할 수 있을까?

그렇다면 종속성을 피하기 위해 특정 프롬프트를 항상 준비해뒀다가 새로운 플랫폼에서 대화를 시작할 때마다 붙여넣으면 될까요?

실제로 많은 LLM 플랫폼들이 Custom Instructions 나 프롬프트 템플릿 기능을 제공하고 있습니다. 이를 활용하면 어느정도는 해결할 수 있습니다. 다만 이는 몇가지 문제를 안고 있습니다.

1번과도 연관이 있는데, Context Window 한계로 인해 너무 긴 프롬프트는 결국 기억하지 못하는 일이 발생합니다.

또 개인 경험과 같은 두번째 뇌를 만들기 위한 지식은 시간이 지날수록 점점 쌓이게 됩니다. 수백, 수천개의 노트와 경험들이 쌓이게 되면, 이를 모두 프롬프트에 담는 것은 불가능해집니다. 게다가 매번 새로운 세션을 시작할 때마다 프롬프트를 붙여넣는 것은 번거로운 일입니다. 비용문제도 있습니다. LLM 플랫폼들은 일반적으로 토큰 사용량에 따라 비용을 측정합니다. 이는 곧 비용 문제로 이어질 수 있겠죠.

LLM의 한계를 극복하기 위한 시도들

이러한 문제는 사실 두번째 뇌와 관련된 문제에만 국한된 것은 아닙니다. Context Window 문제나 Memory, 비용 문제들은 AI를 활용하는 곳이라면 맞이할 수밖에 없는 공통적인 문제이죠.

이는 LLM이 등장한 초기부터 제기되어 왔습니다. 그러나 문제가 있다면 항상 극복하기 위한 다양한 시도들이 있기 마련이죠. 대표적으로는 RAG가 있습니다.

RAG (Retrieval-Augmented Generation)

RAG란 무엇일까요? RAG는 LLM이 외부 지식베이스에서 정보를 검색하여 답변을 생성하는 방법론입니다. 실제 저희 회사에서도 사용하고 있는 방법이기도 합니다.

LLM이 모든 지식을 내부에 저장하거나 하는 것이 아니라 문서화된 지식을 임베딩하여 벡터 DB와 같은 외부 지식베이스에 관련된 정보를 저장해두고, LLM이 질문을 받으면 유사도 기반 검색과 같은 검색으로 관련된 정보를 외부 DB에서 검색하여 프롬프트에 포함시켜 답변을 생성하는 방식입니다.

임베딩이란? 텍스트 데이터를 벡터(숫자 배열)로 변환하는 과정입니다. 이를 통해 텍스트의 의미를 수치적으로 표현할 수 있어, 유사도 검색 등에 활용됩니다. 이는 이번 주제와는 조금 거리가 있으니 넘어가겠습니다.

검색(Retrieval): 사용자의 질문과 관련된 문서를 외부 데이터베이스나 벡터 DB에서 검색합니다.
증강(Augmentation): 검색된 관련 정보를 사용자의 질문과 결합하여 모델에게 전달합니다.
생성(Generation): 모델이 제공된 정보를 바탕으로 최종 답변을 생성합니다.

위와 같은 단계를 거치게 돼죠. 이를 통해 Context Window 한계를 어느정도 극복하고 환각을 방지하며 최신 정보를 활용할 수 있게 됩니다.

이 방법론은 많은 기업들과 개발자들이 활용하고 있습니다. 예를 들어, 기업들은 자사 문서나 위키, 고객 지원 자료 등을 벡터 DB에 저장해두고, LLM이 고객 문의에 답변할 때 이를 활용하도록 구성할 수 있습니다.

과거 StackOverflow에서 검색하던 경험을 생각해보면 이해가 쉽습니다. 개발자들이 새로운 문제에 직면했을 때, StackOverflow에서 관련된 질문과 답변을 검색하여 문제를 해결하곤 했습니다. RAG는 이러한 검색 과정을 LLM이 자동으로 수행하도록 하는 것과 유사합니다.

LLM 플랫폼에서 인터넷 검색과 같은 기능을 제공하기 전에는 RAG로 구축하는 경우가 지금보다 더 많았던 것 같습니다. 왜냐면 모델은 학습됐을때의 지식까지만 알기 때문에 최신 정보를 반영하기 어렵기 때문이죠. RAG를 통해 최신 정보를 벡터 DB에 저장해두고 LLM이 이를 활용할 수 있게 하면 최신 정보를 반영할 수 있게 됩니다.

그러나 LLM의 성능이 가파르게 상승하고 있는 지금 LLM 플랫폼들이 웹 서치를 할 수 있는 모델들을 내놓기도 하면서 RAG의 필요성은 다소 줄어들긴 했다고 생각합니다.

하지만 여전히 특정 도메인 지식이나 개인화된 지식을 활용해야 하는 경우에는 RAG가 유용하게 사용되고 있습니다. 또 웹 서치가 항상 완벽한 답변을 제공하지는 않기 때문에, RAG를 통해 검증된 정보를 제공하는 것이 중요할 수 있다고 생각합니다.

또 RAG에도 한계는 있습니다. 벡터 DB를 구축하고 유지보수하는 비용과 노력이 필요하고, 검색된 정보가 항상 정확하거나 관련성이 높지 않을 수 있습니다. 벡터 DB의 데이터를 최신화를 계속 해줘야 하는 문제도 있죠.

이런 부분을 감안하더라도 RAG는 LLM의 한계를 극복하기 위한 강력한 방법론 중 하나라고 생각합니다. 물론 제가 모르는 더 좋은 방법론들도 있겠지만 제가 아는 한에서는 RAG가 가장 널리 알려져 있고, 많이 활용되고 있는 방법론인 것 같습니다.

MCP 서버: 진짜 Second Brain의 해결책

아무래도 저는 회사에서 RAG도 개발하고 운영하고 있다보니 문득 이런 생각이 들었습니다.

“내 개인 블로그에 있는 문서에 LLM이 자유롭게 접근하게 된다면 RAG처럼 동작하게 한다면 정말 두번째 뇌로써 활용할 수 있지 않을까?”

LLM에게 질의할때마다 LLM이 적절히 판단해서 내 블로그에서 관련된 글을 찾아서 답변에 활용하게 만드는 거죠. 마치 제 개인 RAG와 같이 동작하게 만드는 겁니다. 그렇게 되면 제 경험과 지식에 기반한 추론과 답변이 가능해지겠죠.

그렇다고 해서 RAG Server를 직접 구축하고 운영하는 것은 번거로운 일입니다. 벡터 DB를 구축하고, 문서를 임베딩하고, 검색 로직을 구현하는 등 많은 노력이 필요하니까요. 그러고 싶진 않았습니다.

하지만 그렇게 번거로운 방법을 거치지 않고도, 내 블로그를 LLM이 자유롭게 읽고 활용할 수 있게 만드는 방법이 있었습니다. 바로 MCP(Model Context Protocol) 서버를 활용하는 방법입니다.

물론 이와같은 방법을 이미 다른 분들이 시도하셨고 이를 간단하게 구축할 수 있는 오픈소스 프로젝트들도 있을 수 있을 것 같습니다. 다만 저는 제가 직접 MCP 서버를 구축하는 경험을 해보고 싶어 오픈소스를 찾아보기보다 직접 구축하기로 결심했으니 이번 글에서는 핵심 아이디어에 대해서만 참고해주시면 감사하겠습니다.

MCP(Model Context Protocol)란?

MCP는 LLM이 외부 지식 소스에 접근할 수 있도록 표준화된 프로토콜입니다. 쉽게 생각하시면 MCP는 LLM이 외부와 소통할 수 있는 공용 인터페이스라고 할 수 있습니다.

MCP에 대해 찾아보시면 LLM의 손과 발 역할을 하는 것이라고도 표현합니다. 이 표현이 저는 정확하다 생각하는데 LLM에게 외부 툴들에 대해 접근하는 방법을 제공하는 역할을 하기 때문이죠.

예를 들어, MySQL 데이터베이스에 접근하는 MCP 서버를 만들어두면 LLM이 필요할 때 MCP 서버를 통해 MySQL에 접근하여 데이터를 읽고 쓸 수 있게 됩니다. 실제로 공식 MCP 서버 목록에 MySQL, PostgreSQL, SQLite 등 다양한 데이터베이스 MCP 서버들이 공개되어 있습니다.

자 그럼 MCP가 어떻게 두번째 뇌 문제를 해결할 수 있을까요? 생각보다 간단합니다. 제 개인 개발 블로그에 접근하는 방법을 제공하는 MCP 서버를 제가 만들면 됩니다.

이렇게 하면 MCP를 지원하는 모든 LLM에서 사용 가능하기 때문에 플랫폼 독립적입니다. ChatGPT든, Claude든, Gemini든, 회사 자체 LLM이든 MCP를 활용할 수 있기만 하면 제 블로그에 접근할 수 있게 되는 거죠.

또 RAG처럼 동작하기 때문에 Context Window 한계도 어느정도 극복할 수 있습니다. LLM이 제 블로그에서 관련 글을 검색해서 가져오기 때문에, 블로그에 수백개의 글이 있더라도 필요한 글 몇개만 가져와서 활용할 수 있게 되는 겁니다.

그리고 영구적 지식 저장소가 됩니다. 제 블로그에 쌓아둔 지식과 경험들은 플랫폼이 바뀌어도 그대로 유지되며, 대화가 삭제되어도 남아있습니다. 언제든 필요할 때만 꺼내 쓸 수 있죠.

다른 큰 장점중에 하나는 내가 직접 MCP 서버를 운영하기 때문에, 내가 원하는 방식으로 지식과 경험을 관리할 수 있다는 점입니다. 블로그 글을 수정하거나 추가하는 것만으로도 제 두번째 뇌를 쉽게 업데이트할 수 있죠.

이렇게 되면 저도 모르게 제 블로그를 꾸준히 업데이트하게 된다는 장점도 있게 됩니다. 아무래도 LLM이 참고하는 지식 저장소가 된다면, 더 자주 업데이트하게 되니까요. 😊

이렇게 되면 진짜 LLM을 Second Brain으로 활용될 수 있다 생각합니다.

Obsidian처럼 지식을 정리하고 저장하되, LLM이 능동적으로 찾고, 연결하고, 적용하면서도, 플랫폼에 종속되지 않고 영구적으로 유지되는 것.

그래서 만들었습니다

제 개발 블로그(jeongil.dev)를 Claude Code가 직접 읽고 활용할 수 있게 만드는 MCP 서버를요.

이제부터는 제가 실제로 어떻게 MCP 서버를 구축했는지, 구체적인 구현 과정을 적어보겠습니다.

llms.txt: LLM이 읽을 수 있는 표준 형식

MCP 서버를 만들기로 결심했을 때, 가장 먼저 고민한 것은 “블로그 콘텐츠를 LLM이 어떻게 읽게 할 것인가?” 였습니다.

Http 방식으로 html 페이지를 긁어오는 방법도 생각해봤지만, 이는 비효율적인 부분이 있었습니다.

html은 md 파일보다 불필요한 태그와 스타일 정보가 많아 LLM이 핵심 내용을 파악하는 데 방해가 될 수 있었습니다. 또 블로그 구조가 바뀌면 MCP 서버 코드도 수정해야 하는 번거로움도 있었죠.

그러던 중 llms.txt라는 표준의 존재를 알게 되었습니다.

llms.txt란?

llms.txt는 웹사이트가 LLM에게 자신을 소개하는 표준화된 방법입니다. robots.txt가 검색 엔진 크롤러를 위한 파일이라면, llms.txt는 LLM을 위한 파일인 셈이죠.

/llms.txt 경로에 마크다운 형식으로 사이트의 주요 정보를 정리해두면, LLM이 해당 사이트를 이해하고 활용할 수 있게 됩니다.

llms.txt를 선택한 이유

표준화의 힘
이미 많은 사이트들이 llms.txt를 채택하고 있었습니다. Claude나 ChatGPT 같은 LLM들도 이 표준을 이해하고 있죠. 별도의 설명 없이도 LLM이 바로 내 블로그를 이해할 수 있다는 점이 매력적이었습니다.
단순함
마크다운 파일 하나면 됩니다. 복잡한 JSON 스키마도, 별도의 메타데이터도 필요 없습니다. Hugo 블로그에서 static/ko/llms.txt 파일 하나만 추가하면 끝이었죠.
유연성
블로그에 새 글이 추가되면 llms.txt만 업데이트하면 됩니다. MCP 서버 코드는 건드릴 필요가 없죠. Hugo 빌드 프로세스에 llms.txt 생성 스크립트만 추가하면 자동화도 가능합니다.

제 블로그의 llms.txt 구조

기존에 저는 제 개인 개발 블로그로 Velog를 사용하고 있었습니다. 하지만 Velog는 llms.txt를 지원하지 않았고, 커스터마이징도 어려웠습니다. 그래서 Hugo + GitHub Pages로 블로그를 이전하면서 llms.txt를 도입하기로 결정했죠.

물론 Obsidian도 MCP 서버를 제공하기 때문에 Obsidian을 활용하는 방법도 있긴 했지만 Obsidian을 GitHub Pages로 연동하는 방법이 번거로웠고, 저는 개발 블로그와 개인 지식 저장소라는 두마리 토끼를 모두 잡고 싶었기 때문에 Hugo + GitHub Pages로 만든 개인 블로그에 llms.txt를 도입하는 방법을 선택했습니다.

블로그를 GitHub Pages로 이전하면서 적은 글에서도 밝혔지만 블로그 이전의 핵심 목표 중 하나가 llms.txt 도입이기도 했습니다.

Hugo란 가장 인기 있는 오픈 소스 정적 사이트 생성기 중 하나입니다. Hugo는 마크다운 파일을 기반으로 정적 웹사이트를 생성합니다. static 폴더에 넣은 파일들은 빌드 시 그대로 복사되어 최종 사이트에 포함됩니다. 그래서 static/ko/llms.txt 파일을 추가하는 것만으로도 쉽게 llms.txt를 제공할 수 있었습니다.

Go 기반이기 때문에 빌드 속도도 매우 빠르고, 다양한 테마와 플러그인도 지원되어 커스터마이징도 용이했습니다. 또 다양한 테마가 있어서 디자인도 꽤나 마음에 들었죠. GitHub Pages와의 연동도 쉬워서 배포도 간편했습니다.

블로그를 Hugo + GitHub Pages로 이전하면서 이제 llms.txt를 만드는 것은 간단하게 가능해졌습니다.

그 다음으로 고민했던 부분은 llms.txt를 만들 때 “LLM이 어떤 정보를 어떻게 쉽게 찾을 수 있게 할 것인가?” 였습니다.

그냥 모든 글을 쭉 나열할 수도 있지만, 그러면 LLM이 원하는 정보를 찾기 어려울 것 같았습니다. 그래서 정보의 성격에 따라 두 가지로 나눴습니다.

Documentation (개발 가이드라인)

팀에서 합의한 규칙, 컨벤션, 원칙들을 모아놓은 카테고리입니다. “어떻게 개발해야 하는가?” 에 대한 문서를 여기 모아놨습니다.

코딩 컨벤션, Git 워크플로우, 아키텍처 원칙, API 설계 패턴, 테스트 전략, 데이터베이스 규칙 등입니다.

예를 들어, Claude Code가 새로운 API를 만들 때 “내 개발 규칙을 준수하면서 API를 설계하고 구현해봐"라고 하면 Claude Code가 Documentation를 검색하여 제가 정리해둔 API 설계 원칙과 코딩 컨벤션을 참고해서 코드를 작성합니다.

Tech Blog (실무 경험)

제가 실제로 겪었던 문제들과 해결 과정을 모아놓은 카테고리입니다. “과거에 이 문제를 어떻게 해결했는가?, 예전에 어떤 경험들을 했는지” 등 에 대한 기록이죠. 세부적으로는 다음과 같은 카테고리로 분류했습니다.

Backend: HikariCP Deadlock, Spring Batch Chunk 전환 등
Infrastructure & DevOps: Docker Compose에서 Kubernetes로 마이그레이션, ArgoCD 도입 등
Architecture & Design: MSA에서 Multi-Module로 전환, 멀티 모듈 통합 등
Development Culture: Git Flow 개선, 코드 리뷰 문화 정착 등

물론 이보다 좀더 있긴하지만 대표적인 카테고리들입니다.

이렇게 “규칙"과 “경험"을 분리하니 LLM이 상황에 맞는 정보를 정확히 찾을 수 있게 됐습니다. 제 개발 블로그에 개발 규칙과 같은 문서들을 포함시키고 싶었던 이유도 여기에 있습니다.

기존에 Velog같은 경우는 문서와 블로그 글을 동시에 관리하기 어려웠습니다. 또 Mintlify와 같은 문서화 도구들은 문서화에는 최적화 돼있고 llms.txt도 지원하긴 하지만 블로그 글을 함께 관리하기엔 적합하지 않았죠.

하지만 Hugo로 이전하면서 문서와 블로그 글을 모두 포함시킬 수 있었고, llms.txt에서도 이를 명확히 구분할 수 있게 됐죠.

llms.txt의 전체 내용은 jeongil.dev/ko/llms.txt에서 확인할 수 있습니다.

구현: MCP 서버 만들기

MCP가 무엇인지는 위에서 설명했으니, 이제 실제로 어떻게 만들었는지 이야기해보겠습니다.

기술 스택 선택

FastMCP를 선택한 이유

MCP 서버를 만들 때 공식 MCP SDK 대신 FastMCP를 선택했습니다.

아무래도 FastMCP가 제공하는 간결한 API 덕분에 빠르게 개발할 수 있을 것 같았기 때문이죠.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
# 공식 MCP SDK는 이렇게 작성합니다 (장황함)
from mcp.server import Server
from mcp.server.models import Resource

server = Server("my-blog")

@server.list_resources()
async def list_resources():
    return [
        Resource(
            uri="blog://llms-txt",
            name="Full llms.txt",
            description="Complete content...",
            mimeType="text/plain"
        )
    ]

# FastMCP는 이렇게 작성합니다 (간결함)
from fastmcp import FastMCP

mcp = FastMCP("My Tech Blog")

@mcp.resource("blog://llms-txt")
async def get_full_llms_txt() -> str:
    """Complete llms.txt content from jeongil.dev."""
    return await fetch_content()

FastMCP의 장점:

데코레이터 기반 API (Flask/FastAPI 스타일)
자동 스키마 생성 (Docstring만 작성하면 됨)
타입 안정성 (Pydantic 통합)
코드량 50% 이상 감소

프로젝트 구조

처음에는 모든 코드를 한 파일에 때려박을까 생각했습니다. 간단한 프로젝트니까요. 하지만 나중에 확장할 가능성을 생각해서 관심사를 분리했습니다.

my-tech-blog-mcp-server/
├── src/
│   ├── server.py          # MCP 서버 메인 로직 (Resources, Tools, Prompts 정의)
│   └── llms_parser.py     # llms.txt 파싱 및 검색 (HTTP 요청, 파싱, 검색)
├── run.py                 # 서버 실행 진입점
├── requirements.txt       # 의존성
└── install.sh            # 자동 설치 스크립트

왜 이렇게 나눴나?

llms_parser.py: llms.txt를 가져오고 파싱하는 데이터 레이어
server.py: MCP 프로토콜에 맞춰 데이터를 노출하는 서비스 레이어

나중에 llms.txt 대신 다른 데이터 소스(Notion, Obsidian 등)를 쓰고 싶다면 llms_parser.py만 교체하면 됩니다. server.py는 건드릴 필요가 없죠.

1. llms.txt 파서 구현

먼저 llms.txt를 가져오고 검색하는 모듈부터 만들었습니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
# src/llms_parser.py
class LLMSParser:
    def __init__(self, base_url: str = "https://jeongil.dev"):
        self.llms_url = f"{base_url}/ko/llms.txt"
        self._cache = None  # 캐싱으로 성능 최적화

    async def fetch_content(self) -> str:
        """llms.txt를 HTTP로 가져오기"""
        async with httpx.AsyncClient() as client:
            response = await client.get(self.llms_url)
            return response.text

    async def search_documentation(self, query: str):
        """개발 가이드라인 검색 (간단한 문자열 매칭)"""
        # 일단 단순하게 시작 - 나중에 벡터 검색으로 개선 가능
        ...

핵심만 짚으면:

httpx로 비동기 HTTP 요청 (MCP 서버는 비동기로 동작하니까)
메모리 캐싱으로 성능 최적화 (llms.txt는 자주 안 바뀌니까)
간단한 문자열 매칭으로 검색 (YAGNI 원칙 - 일단 단순하게 시작)

자세한 전체 코드는 제 GitHub 레포에서 확인하실 수 있습니다.

2. MCP 서버 구현

파서가 준비됐으니 이제 MCP 서버를 만들 차례입니다. FastMCP를 쓰면 정말 간단합니다.

1
2
3
4
5
# src/server.py
from fastmcp import FastMCP

mcp = FastMCP("My Tech Blog")
parser = LLMSParser()

MCP는 크게 3가지 개념이 있습니다.

1. Resources (리소스) - 읽기 전용 데이터

1
2
3
4
5
@mcp.resource("blog://documentation")
async def get_documentation() -> str:
    """Development guidelines and conventions."""
    content = await parser.get_content()
    return format_documentation(content)

LLM이 “블로그 전체 내용 뭐 있지?” 하고 궁금할 때 읽어갑니다. Docstring이 자동으로 설명이 되니 별도 스키마 작성이 불필요합니다.

2. Tools (도구) - LLM이 실행할 수 있는 함수

1
2
3
4
5
@mcp.tool()
async def search_experience(query: str) -> str:
    """Search for past experiences and problem-solving stories."""
    results = await parser.search_tech_blog(query)
    return format_results(results)

“Kubernetes 관련 경험 찾아줘"라고 하면 LLM이 알아서 search_experience("kubernetes")를 호출합니다. 제가 명령할 필요가 없죠.

3. Prompts (프롬프트) - 재사용 가능한 템플릿

1
2
3
4
5
6
7
8
9
@mcp.prompt()
def check_past_experience(topic: str) -> str:
    """Check if a similar problem was encountered before."""
    return f"""I'm working on: {topic}

Have I encountered this before? Search and summarize:
1. Similar challenges
2. How I solved them
3. Lessons learned"""

자주 쓰는 질문 패턴을 템플릿으로 만들어두면 매번 긴 프롬프트 입력 안 해도 됩니다.

이게 FastMCP의 전부입니다. 데코레이터만 붙이면 끝이에요. 문서가 너무 잘 되어 있어서 막상 해보시면 구성하기 정말 쉽다는 걸 아실 겁니다.

MCP 서버를 구현해보기 전에는 복잡할 줄 알았는데, 의외로 간단해서 놀랐습니다. 물론 세부적인 기술은 공부할게 많겠지만 구현자체는 정말 간단했습니다.

자세한 구현 방법이나 코드는 아래 자료들을 참고해주시면 감사하겠습니다.

3. 설치 자동화

이제 MCP 서버 코드는 다 작성됐습니다. 하지만 매번 새 환경에서 설정하기 귀찮더라구요. 저는 회사 맥북, 개인 맥북, 데스크탑 등 여러 환경에서 Claude Code를 씁니다. 매번 MCP 서버 설정하기 귀찮아서 설치 스크립트를 만들었습니다.

한 줄로 설치

1
./install.sh

스크립트가 자동으로:

Python 가상 환경 생성
의존성 설치 (fastmcp, httpx, pydantic)
Claude Code에 MCP 서버 등록

Claude Code 재시작하면 바로 쓸 수 있습니다. 새 환경 세팅할 때마다 10분 걸리던 게 1분으로 줄었죠.

자세한 스크립트는 Github Repo - install.sh에 있으니 궁금하신분들은 참고해주세요.

실제 사용 결과

MCP 서버를 구축하고 Claude Code에 연결한 후 사용해보니 생각한 것 이상으로 두번째 뇌 역할을 톡톡히 해줄 수 있겠다 싶었습니다.

위는 단적인 예시지만 과거에 제가 겪었던 문제를 제 블로그에서 Claude Code가 바로 파악하여 년도별로 구별해준 모습입니다.

나중에는 “내 블로그에서 HikariCP Deadlock 관련된 글 찾아서 요약해줘” 라고 하면 바로 찾아서 요약해주더군요.

또 “내 개발 규칙에 맞게 이 코드를 리뷰해줘” 라고 하면 제 블로그에서 코딩 컨벤션과 API 설계 원칙을 참고해서 코드 리뷰를 해줍니다.

결과 및 효과

이제 AI Agent와 협업할 때 매번 제 상황이나 규칙을 설명할 필요가 없게 됐습니다. 그저 “내 블로그에 있는 개발 규칙 확인 해서 지금 코드에 미흡한 부분이 있는지 검토해봐"라고 하면 됩니다.

또 과거에 있었던 일들도 일일히 제가 찾을 필요 없이 AI가 제 블로그에서 알아서 찾아줍니다.

이렇게 되니 기록만 잘 해두면 AI가 제 두번째 뇌 역할을 톡톡히 해줄수 있게 됐습니다.

지금 개발 블로그에는 경험과 규칙들만 있지만 예를 들어 향후 있을 Task들을 관리하는 공간을 추가한다고 가정하면, AI가 제 일정과 할일도 관리해줄 수 있게 됩니다.

“오늘 해야할 일 뭐있지?” 라고 물어보면 AI가 제 일정과 할일을 확인해서 알려주는 거죠.

이렇게 MCP 서버를 통해 제 두번째 뇌가 수동적이지 않고 능동적으로 제 업무를 도와주게 되고 기록을 하면 할수록 저에 대해 더 잘 이해하며 추론도 할 수 있게 됩니다.

경험에 기반한 조언도 해주고, 제가 자주 실수하는 부분도 미리 경고해주고, 규칙도 일관되게 지켜주고 말이죠.

정말 “두번째 뇌"가 무엇인지 체감할 수 있게 됐습니다. 뭔가 계속 이렇게 말하니 과장된 표현 같기도 하지만 실제로 써보면 정말 그런 느낌이 듭니다.

배운 점

1. 잘 정리해야한다

블로그를 쓰는 아주 큰 이유가 하나 더 생기고 명확해졌습니다. 기존에는 단순히 제 경험들을 정리해두는 공간이자 제가 글을 적으며 경험을 되새기는 공간이었습니다.

그러나 LLM이 제 블로그를 읽고 활용할 수 있게 되면서, 블로그는 나의 경험과 지식을 AI가 실시간으로 활용하는 아주 큰 자산이 되었습니다.

블로그에 많은 글을 적어둔건 아니지만 경험에 관련된 부분들은 정리를 해뒀는데 MCP 서버를 만들 생각을 하면서 적어두길 너무너무 잘했다는 생각이 들었습니다.

다만 두번째 뇌로써 잘 활용하려면 잘 정리해야한다고 생각합니다. 제대로 정리되지 않은 글들은 AI가 활용하기 어렵기도 하고 어떤 경우에는 잘못된 정보를 줄 수 있으며 환각을 야기할수도 있기 때문입니다.

그렇게되면 AI와 협업하거나 활용하는데 오히려 방해가 될수도 있죠. 문서화의 중요성은 여기서 다시 한번 강조 되는 것 같습니다. 제대로 정리하고 기록하는 능력은 개발자에게 아주 중요한 역량임을 다시 한번 느꼈습니다.

또 잘 기록하고 정리하면 그만큼 크나큰 자산이 된다는 점을 다시 한번 깨닫게 됐습니다. 앞으로는 그 가치가 더 커질거라 생각하니 더욱 열심히 기록하고 정리해야겠다는 다짐을 하게 됐습니다.

2. AI와 협업하려면 컨텍스트가 중요하다

LLM은 똑똑하지만 컨텍스트가 없으면 일반론만 말합니다. 또 잘못된 정보를 줄 수도 있죠. 그렇기 때문에 내가 미리 검증해둔 컨텍스트를 주입하면, AI는 나만의 전문가가 된다고 생각합니다.

내 과거 경험
내 개발 규칙
내 아키텍처 결정 및 고민

이런 컨텍스트가 있어야 제게 더욱 맞는 유용한 조언을 받을 수 있지 않나 싶습니다. 기존에는 이런 문서들을 .claude에 CLAUDE.md 혹은 skills에 문서로 추가해두곤 했습니다.

CLAUDE.md에 양이 너무 많아져 skills로 분리해 토큰양을 줄이기 위한 작업들도 했었죠. [나는 미래를 받아들였는가? - 개발자 AI 코딩 툴과 협업하는 법]

하지만 문서가 많아지면 관리가 어렵고, 매번 업데이트하는 것도 번거로웠습니다.

또 여러 프로젝트에서 공통적인 규칙들은 프로젝트별로 매번 추가해줘야 했죠.

MCP 서버를 도입하면서 이런 문제들이 모두 해결됐습니다. 제 블로그가 곧 제 컨텍스트 저장소가 되었고, MCP 서버가 이를 LLM에게 실시간으로 제공해주니까요.

3. Second Brain의 유용성

AI Agent와 협업할 때 역할 분담이 명확해졌습니다. 저는 의사결정과 고민의 과정에 중점을 가지게 되고 AI는 제 경험과 지식을 제공하는 역할을 맡게 됐습니다.

제가 하나하나 설명하지 않아도 제 두번째 뇌가 제 경험과 규칙을 알아서 제공해주니까요.

이게 생각보다 정말 편하더라구요. Obsidian 같은 툴도 있지만, MCP 서버는 LLM과의 협업에 특화되어 있다는 점에서 훨씬 더 유용했습니다.

마치며

개발 블로그를 MCP 서버로 만들면서, 블로그의 가치가 제 개인에게는 굉장히 커졌다고 느껴집니다.

단순히 정리용 글이 아니라 제 개인 경험에 대한 벡터 DB이자, LLM이 실시간으로 참고하는 지식 저장소가 되었기 때문입니다.

Obsidian이 두번째 뇌가 아닌 두번째 외장하드라면, MCP 서버는 진짜 두번째 뇌가 된 셈이라는 생각이 듭니다.

물론 아직 부족한 점도 많고 개선할 점 역시 많으며 제가 적은 글들중에 잘못된 정보가 있을 수 있다는 점도 감안해야합니다. 하지만 지금까지 경험한 것만으로도 MCP 서버를 구축한 가치는 충분하다고 생각합니다.

여러분도 만들어보세요

제 MCP 서버 코드는 GitHub에 있습니다.

README에 설치 방법과 사용법이 자세히 나와있으니, 참고하셔서 여러분의 블로그도 Second Brain으로 만들어보세요.

블로그가 없다면 되도록 시작하시면 어떨까 싶습니다. 나중에는 이런 MCP Server들도 직접 만들지 않아도 LLM 플랫폼에서 제공해주지 않을까 싶습니다. 물론 이미 제공하고 있는데 제가 모르는 것일수도 있기도 합니다. ㅎㅎ..

긴 글 읽어주셔서 감사합니다. 이 글이 여러분께 조금이라도 도움이 되었길 바랍니다. 감사합니다.

Reference

나는 미래를 받아들였는가? - 개발자 AI 코딩 툴과 협업하는 법