MCP 서버를 처음 만든 날, 터미널에 "쿠버네티스 입문 가이드를 블로그에 올려줘"라고 쳤다. 10초 뒤에 블로그에 글이 올라가 있었다.
대단할 것 없어 보이지만, 그 전에는 같은 작업을 하려면 API 문서를 읽고, 인증 토큰을 세팅하고, JSON 바디를 구성해서 cURL을 날려야 했다. AI 에이전트를 쓰더라도 마찬가지다. AI가 코드를 짜서 API를 호출할 뿐, 과정 자체는 똑같이 번거롭다.
AI가 도구를 직접 고르는 프로토콜
MCP(Model Context Protocol)는 이 번거로움을 없앤다.
Anthropic이 2024년 말에 공개한 오픈 프로토콜인데, 한 줄로 요약하면 "AI 에이전트가 외부 도구를 발견하고 직접 호출하는 표준"이다. MCP 서버가 자신이 제공하는 도구 목록을 선언하면, AI가 상황에 맞는 도구를 골라 쓴다. API 문서를 읽어서 코드를 짜는 게 아니라, 도구를 바로 호출한다.
Postlark는 이걸 @postlark/mcp-server라는 npm 패키지로 제공한다. 설치는 한 줄이다:
claude mcp add postlark -- npx @postlark/mcp-server이러면 Claude Code, Cursor 같은 AI 도구에서 블로그를 자연어로 관리할 수 있다. "지난주 트래픽 상위 3개 글 알려줘", "이 글 내일 오전 9시에 예약 발행해줘" — 전부 된다.
REST API만으로는 부족한 이유
"REST API만 만들면 되지 않냐"는 질문을 받은 적 있다. 되긴 된다. 근데 핵심은 블로그에 글을 올리는 주체가 달라지고 있다는 점이다.
AI로 글을 생성하는 사람이 늘고 있고, 그 AI가 블로그에 접근하려면 프로그래매틱 인터페이스가 필요하다. REST API도 그 인터페이스의 한 형태지만, AI 에이전트 입장에서는 MCP가 훨씬 자연스럽다. REST가 개발자를 위한 문서라면, MCP는 AI를 위한 문서다. REST API는 사람이 문서를 읽고 이해한 뒤 코드로 옮기는 과정을 전제하지만, MCP는 에이전트가 도구의 이름과 파라미터 스키마를 보고 스스로 판단해서 호출한다. 중간에 사람이 코드를 작성하는 단계가 사라지는 거다.
주요 블로그 플랫폼 중 이 프로토콜을 지원하는 곳이 없다는 것도 결정에 한몫했다. 네이버 블로그는 API 자체가 없다. 티스토리 API는 종료됐다. Medium은 API 키 발급을 중단했다. Ghost나 WordPress는 REST API가 있지만 에이전트용 인터페이스는 없다. 차별화를 고민할 필요가 없었다. 당연히 있어야 할 것을 만들었을 뿐이다.
구조적으로 보면 REST API 위에 MCP를 얹는 형태다. 내부적으로 MCP 도구 핸들러가 REST 엔드포인트를 호출하기 때문에, 기존 API 인프라를 그대로 활용하면서 에이전트 친화적인 계층만 추가한 셈이다. REST를 버린 게 아니라 그 위에 AI가 이해하는 언어를 하나 더 올린 것이다. 웹훅 연동이나 서드파티 통합은 여전히 REST로 처리하고, 에이전트가 사용자의 자연어 명령을 받아 실행하는 경로만 MCP를 탄다.
7개에서 17개까지, 그리고 top-level await 사고
처음 7개 도구로 시작한 MCP 서버는 지금 17개까지 늘었다. 포스트 CRUD는 기본이고, 예약 발행, 분석 조회, 이미지 업로드, 블로그 검색까지. 그 과정에서 npm 배포 후 Node 12 호환성이 깨져서 긴급 패치를 두 번 낸 일도 있었다. top-level await 한 줄이 범인이었다.
다음 단계
MCP와 함께 Postlark의 AI 발견 전략의 다른 축인 llms.txt를 다음 편에서 다룬다.