[GeekNews 요약] AI 에이전트가 기술 블로그 69편을 검색하도록 MCP 서버로 공개한 과정
1
설명
AI 에이전트가 방대한 기술 블로그 콘텐츠를 효과적으로 탐색하고 원문을 정확히 추적하는 것은 중요한 과제입니다. 본 글은 AI아키텍트 블로그의 공개 글 78편 중 69편을 모델 컨텍스트 프로토콜(MCP) 기반의 읽기 전용 서버로 구축하고, 이를 PyPI 패키지로 배포한 과정을 상세히 설명합니다. 이 접근 방식은 AI 에이전트의 정보 접근성을 높이고 콘텐츠의 출처 명확성을 강화하는 새로운 방법을 제시합니다.
### 배경 설명
기술 블로그는 시간이 지남에 따라 방대한 양의 정보가 축적되지만, AI 에이전트가 이러한 콘텐츠를 정확하게 검색하고 원문으로 연결하는 데에는 어려움이 따릅니다. 기존의 검색 엔진 색인 방식은 실시간성이 떨어지거나, AI 에이전트가 필요한 정보를 정확히 찾아내기 위한 구조적인 지원이 부족한 경우가 많습니다. 이러한 문제를 해결하기 위해, 본 글에서는 모델 컨텍스트 프로토콜(MCP)이라는 새로운 접근 방식을 제안합니다. MCP는 AI 에이전트가 외부 데이터를 보다 효율적으로 탐색하고 활용할 수 있도록 설계된 프로토콜입니다. 특히, 본 글에서 소개하는 방식은 블로그의 공개 글을 MCP 서버로 직접 제공함으로써, AI 에이전트가 별도의 웹 크롤링이나 복잡한 API 연동 없이도 콘텐츠 목록, 검색, 본문 조회를 수행할 수 있도록 합니다. 이는 AI 에이전트가 단순히 정보를 소비하는 것을 넘어, 신뢰할 수 있는 출처를 기반으로 정확한 정보를 생성하고 활용하는 데 기여할 수 있습니다. 2026년 8월 2일 기준으로 78편의 공개 글 중 69편이 검증되어 패키지 v0.1.1에 포함되었으며, 이는 AI 에이전트가 접근 가능한 고품질 콘텐츠의 스냅샷을 제공합니다. 이 과정은 AI 에이전트의 정보 탐색 능력을 향상시키고, 콘텐츠 제공자의 출처 명확성을 강화하는 실질적인 사례를 보여줍니다.
### 1. MCP 서버 실행 및 연동
Claude Code 환경에서는 `claude mcp add aiarchitect-blog -- uvx aiarchitect-blog-mcp` 명령어로 간편하게 MCP 서버를 등록할 수 있습니다. JSON 설정을 사용하는 클라이언트의 경우, `mcpServers` 설정에 `aiarchitect-blog` 서버 정보를 추가하여 연동할 수 있습니다. uvx가 설치되지 않은 환경에서는 `pipx run aiarchitect-blog-mcp` 명령어를 통해 직접 실행 가능합니다. 서버 연결 후에는 자연어 질의를 통해 블로그 콘텐츠를 검색하고 요약하며 원문 링크까지 얻을 수 있습니다. 예를 들어, "AI아키텍트 블로그에서 MCP OAuth 관련 글을 찾아줘. 가장 관련 있는 글의 핵심을 요약하고 원문 링크도 알려줘."와 같은 요청이 가능합니다. 이 과정에서 별도의 벡터 데이터베이스나 API 키, 원본 저장소가 필요하지 않아 간편하게 활용할 수 있습니다.
### 2. 블로그를 MCP 서버로 만드는 이유
블로그를 MCP 서버로 노출하는 것은 세 가지 주요 이점을 제공합니다. 첫째, '탐색 가능성' 측면에서 AI 에이전트가 자연어 질의를 통해 콘텐츠 목록, 검색, 본문 조회를 직접 수행할 수 있게 됩니다. 둘째, '출처 연결'을 강화하여 도구 응답에 정식 원문 URL을 포함시킴으로써 답변의 출처가 명확하게 남을 가능성을 높입니다. 셋째, '도그푸딩(Dogfooding)'을 통해 MCP 설계를 실제 콘텐츠에 적용하고 운영 경험을 축적할 수 있습니다. 이러한 패턴은 블로그뿐만 아니라 공개 문서, FAQ, 릴리스 노트 등 외부에 공개 가능하고 재배포 권한이 명확한 텍스트 묶음에도 적용될 수 있습니다. 다만, 웹 공개가 자동적인 재배포 권한을 의미하는 것은 아니며, 공개 데이터 MCP와 비공개 사내 문서를 다루는 MCP는 별개의 시스템으로 구분되어야 합니다.
### 3. 설계 원칙: 작게, 읽기 전용으로, 결정적으로
이 프로젝트는 구현 전에 네 가지 핵심 원칙을 설정했습니다. 첫째, '읽기 전용(Read-only)'으로 목록, 검색, 본문 조회 기능만 제공하며 쓰기, 수정, 삭제 기능은 포함하지 않습니다. 둘째, '작은 도구 표면'을 유지하여 에이전트가 탐색 후 좁혀갈 수 있는 5개의 도구만 제공합니다. 셋째, '결정적 검색 우선(Deterministic first)'으로, 69편 규모에서는 임베딩이나 벡터 DB보다 단순하고 재현 가능한 키워드 랭킹 방식을 채택했습니다. 넷째, '출처 링크 내장(Source link by construction)'으로, 프롬프트 의존성을 줄이고 데이터 자체에 원문 URL을 포함시켜 외부 네트워크나 데이터베이스 없이도 정적 읽기 서비스가 가능하도록 했습니다.
### 4. 다섯 개 도구로 탐색 흐름 만들기
공개된 v0.1.1 버전은 `list_categories`, `list_articles`, `search_articles`, `get_article`, `blog_home`의 다섯 가지 도구를 제공합니다. `list_categories`는 분류별 개관과 편수를, `list_articles`는 분류 및 페이지 기반의 목록을 반환합니다. `search_articles`는 키워드 랭킹 검색을 통해 요약, 점수, 스니펫, URL을 제공하며, `get_article`은 글 전체를 원문 URL로 감싼 마크다운 형식으로 반환합니다. `blog_home`은 블로그 홈 URL과 번들 편수 정보를 제공합니다. 이 도구들은 `readOnlyHint`, `idempotentHint`, `openWorldHint`와 같은 힌트를 통해 클라이언트가 도구의 성격을 이해하도록 돕습니다. 실제 서버 골격은 `fastmcp` 라이브러리를 사용하여 구현되었으며, `corpus` 객체를 통해 콘텐츠 접근을 관리합니다.
### 5. 임베딩 없이 시작하는 결정적 검색
초기 검색 방식은 제목, 태그, 설명, 본문에 각각 다른 가중치를 부여하는 키워드 랭킹을 사용했습니다. 제목 일치에 가장 높은 가중치를 두고, 태그, 설명, 본문 순으로 가중치를 낮추는 방식입니다. 이 방식의 가장 큰 장점은 동일한 코퍼스와 질의에 대해 항상 동일한 결과를 반환한다는 점이며, 이는 골든 테스트 구축에 용이합니다. 하지만 의미론적 유사성 검색 능력은 제한적이며, 긴 본문이나 반복되는 단어에 점수가 치우칠 수 있습니다. 따라서 현재 규모에서는 합리적이지만, 콘텐츠 양이 수백, 수천 편으로 늘어날 경우 키워드 검색을 1차 후보 생성기로 사용하고 임베딩 기반 재랭킹을 추가하는 방식이 더 적합할 수 있습니다. 처음부터 벡터 DB를 도입하는 것보다 실패 지점과 운영 비용 측면에서 유리합니다.
### 6. 원문 URL은 프롬프트가 아닌 데이터에 내장
이 서버의 중요한 설계 특징 중 하나는 `get_article` 도구가 단순히 본문만 반환하는 것이 아니라, 정식 원문 URL을 본문의 앞뒤에 구조적으로 포함시킨다는 점입니다. 이는 서버의 `instructions`에 "인용할 때 원문 URL을 함께 표기하라"는 안내와 함께 제공되어, AI 에이전트가 답변 생성 시 출처 링크를 포함할 가능성을 높입니다. 하지만 이는 모델이나 클라이언트에 제공되는 입력일 뿐, 최종 답변 형식을 강제하는 것은 아닙니다. 이 링크는 AI 답변에서 발생할 수 있는 추천 유입의 가능성을 열어두지만, 검색 엔진의 SEO 백링크와는 다른 개념이며, 실제 유입 효과는 별도의 분석 도구를 통해 측정해야 합니다.
### 7. 미게시 글 제외 및 Fail-Closed 정책
초기 구현에서는 공개 URL이 없는 글에 대해 블로그 홈으로 연결하는 폴백(fallback) 메커니즘이 있었으나, 이는 링크 깨짐을 막는 데는 효과적이었지만 해당 글의 원문이 아니라는 문제가 있었습니다. 더 심각한 문제는 미게시 원고가 목록과 검색 결과에 노출될 수 있다는 점이었습니다. 이를 해결하기 위해 공개 버전에서는 다음 조건을 모두 만족하는 글만 코퍼스에 포함하도록 엄격한 정책을 적용했습니다: HTTPS 스킴, `aiarchitect.tistory.com` 도메인, 숫자로 구성된 경로, 0보다 큰 글 번호. 빈 URL, 홈 URL, 외부 도메인, 비정상적인 경로 또는 글 번호는 모두 거부되며, 인덱스의 `published` 플래그가 `True`인 경우에만 통과됩니다. 이 'fail-closed' 정책은 단순한 데이터 정리를 넘어 출처 정확성에 대한 보안 경계 역할을 하며, 불확실한 콘텐츠는 노출하지 않는 것이 안전하다는 원칙을 따릅니다.
### 8. 콘텐츠 스냅샷을 Self-Contained 패키지로 만들기
서버 실행 시 원본 블로그나 작업 저장소를 직접 읽는 방식은 네트워크 장애나 경로 차이로 인해 재현성이 떨어질 수 있습니다. 이를 방지하기 위해, 빌드 단계에서 검증된 인덱스와 본문 스냅샷을 패키지 내에 포함시키는 'self-contained' 방식을 채택했습니다. 이 빌드 과정에서는 기대한 글 ID 집합과 실제 파일 집합의 일치, ID와 원문 URL의 중복 없음, 모든 URL의 HTTPS 형식 준수, 인덱스 편수와 번들 본문 파일 수의 일치, 작성용 메타데이터 제거, 기존 데이터의 불완전한 새 빌드로의 덮어쓰기 방지 등 여러 불변 조건을 검사합니다. 이렇게 생성된 wheel 패키지는 원본 저장소 없이도 동작하며, `fastmcp`와 같은 런타임 의존성만 필요합니다. 패키지 스냅샷이 실시간 블로그보다 최신이 아닐 수 있는 이유는 이 검증 단계를 릴리스 경계로 선택했기 때문입니다.
### 가치와 인사이트
이 프로젝트는 AI 에이전트가 외부 지식을 효과적으로 활용하기 위한 실질적인 방안을 제시합니다. 단순히 정보를 검색하는 것을 넘어, 원문의 출처를 명확히 하고 신뢰성을 확보하는 것은 AI의 답변 정확성과 윤리적 사용에 직결됩니다. MCP 서버 구축 및 PyPI 패키지 배포는 개발자가 자신의 콘텐츠를 AI 에이전트가 쉽게 접근하고 활용할 수 있도록 만드는 구체적인 방법론을 제공합니다. 특히, '읽기 전용', '결정적 검색', '출처 링크 내장'과 같은 설계 원칙은 AI 에이전트와의 상호작용에서 발생할 수 있는 불확실성을 줄이고, 콘텐츠 제공자에게는 자신의 지적 재산에 대한 통제권을 유지하면서도 AI 생태계에 기여할 수 있는 길을 열어줍니다. 이는 개인 개발자뿐만 아니라 기업의 기술 문서, FAQ, API 레퍼런스 등 다양한 형태의 콘텐츠에도 적용 가능하며, AI 기반 정보 검색 및 활용의 새로운 패러다임을 제시합니다.
### 기술·메타
* **프로그래밍 언어**: Python
* **MCP 프레임워크**: fastmcp
* **패키징**: PyPI (aiarchitect-blog-mcp v0.1.1)
* **소스 코드 저장소**: GitHub
* **라이선스**: 코드 - MIT, 콘텐츠 - LicenseRef-AIArchitect-Articles
### 향후 전망
향후 이와 같은 MCP 기반 콘텐츠 배포 방식은 더욱 발전할 가능성이 높습니다. AI 에이전트의 성능 향상과 함께, 더 정교한 검색 및 요약 기능, 그리고 다양한 형태의 콘텐츠(예: 코드 스니펫, 데이터셋)를 MCP로 제공하는 시도가 늘어날 것입니다. 경쟁 구도 측면에서는, MCP 프로토콜을 지원하는 다양한 클라이언트 및 서버 구현체가 등장하며 생태계가 확장될 수 있습니다. 또한, 콘텐츠 제공자는 자신의 콘텐츠가 AI 에이전트에 의해 어떻게 활용되는지에 대한 더 많은 통찰력을 얻게 될 것이며, 이는 콘텐츠 전략 수립에 중요한 영향을 미칠 것입니다. 잠재적 리스크로는, MCP 서버의 보안 취약점이나 콘텐츠의 최신성 유지 문제가 있을 수 있습니다. 하지만 본 글에서 제시된 'fail-closed' 정책, 아티팩트 검사, 라이선스 분리와 같은 접근 방식은 이러한 리스크를 완화하는 데 기여할 것입니다. 궁극적으로, 이러한 노력은 AI 에이전트와 인간 사용자 간의 정보 격차를 줄이고, 지식의 접근성과 활용성을 극대화하는 방향으로 나아갈 것입니다.
📝 원문 및 참고
- 원문: [링크 열기](https://aiarchitect.tistory.com/63)
- GeekNews 토픽: [보기](https://news.hada.io/topic?id=32404)
---
출처: GeekNews ([원문 링크](https://aiarchitect.tistory.com/63))
신고 · 불법·유해·아동 안전(CSAE) 관련 콘텐츠
댓글 0
아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.