블로그 플랫폼을 만들면서 가장 많이 받은 질문이 하나 있다. "그래서 어떻게 써요?" REST API 문서를 보여주면 고개를 끄덕이긴 하는데, 실제로 curl을 날려서 글을 쓰겠다는 사람은 거의 없었다. API는 존재 자체만으로는 배포 채널이 아니다. 누군가 실제로 쓸 수 있는 형태로 포장되어야 비로소 의미가 생긴다.
세 개의 문, 하나의 플랫폼
Postlark에 글을 발행하는 경로는 세 가지다.
첫째, 대시보드. 브라우저에서 마크다운을 작성하고 발행 버튼을 누른다. 가장 직관적이지만, 자동화와는 거리가 멀다.
둘째, REST API. 표준적인 HTTP 엔드포인트에 Bearer Token을 붙여 호출한다. n8n이나 Zapier 같은 자동화 도구, 혹은 자체 스크립트를 쓰는 사람들이 이 경로를 택한다.
셋째, MCP 서버. 이게 Postlark를 다른 블로그 플랫폼과 가장 뚜렷하게 구분하는 지점이다.
MCP 서버가 배포 채널인 이유
MCP(Model Context Protocol)는 AI 에이전트가 외부 도구를 호출하는 표준 프로토콜이다. 3편에서 이미 다뤘으니 개념 설명은 생략한다. 핵심은 이거다 — @postlark/mcp-server를 npm에 올린 순간, Claude Code나 Claude Desktop을 쓰는 모든 사람이 잠재적 사용자가 됐다.
claude mcp add postlark -- npx @postlark/mcp-server
이 한 줄이면 끝이다. Claude에게 "Postlark에 글 써줘"라고 말하면 16개 도구 중 필요한 것을 알아서 골라 쓴다. 글 작성, 수정, 삭제, 예약 발행, 이미지 업로드, 분석 조회까지 전부.
REST API도 같은 기능을 제공하지만, 사용자가 직접 HTTP 요청을 구성해야 한다. 반면 MCP 서버는 AI 에이전트가 사용법을 이미 안다. 도구 이름과 파라미터 스키마가 프로토콜 수준에서 정의되어 있으니까. 사용자는 자연어로 의도만 전달하면 된다.
이 차이가 생각보다 크다. API 문서를 읽고 코드를 짜는 건 개발자의 영역이지만, "이 주제로 글 하나 써서 올려줘"라고 말하는 건 누구나 할 수 있다.
CLI는 또 다른 이야기
@postlark/cli도 npm 패키지로 배포된다. 이건 MCP와는 결이 좀 다르다.
터미널을 좋아하는 개발자들 — 대시보드를 열기보다 postlark posts list를 치는 게 더 자연스러운 사람들 — 을 위한 도구다. Device Auth 플로우로 브라우저 로그인 한 번이면 터미널에서 모든 걸 할 수 있다. 5편에서 자세히 썼으니 여기서는 생태계 맥락에서만 짚겠다.
CLI, MCP 서버, REST API. 이 셋은 결국 같은 플랫폼 위의 서로 다른 인터페이스다. 어떤 사용자는 대시보드가 편하고, 어떤 사용자는 터미널이 편하고, 어떤 사용자는 AI에게 시키는 게 편하다. 중요한 건 세 경로 모두 동등한 시민으로 대우받는다는 것이다. 대시보드에서 되는 건 CLI에서도 되고, MCP에서도 된다.
llms.txt라는 발견 경로
MCP 서버가 "쓰는 도구"라면, llms.txt는 "찾는 도구"다.
llms.txt는 AI 에이전트에게 "이 사이트는 이런 곳이고, 이렇게 쓰면 된다"를 알려주는 텍스트 파일이다. Postlark의 모든 블로그에는 llms.txt가 자동 생성된다. 블로그 소개, 최근 글 목록, 태그 구조가 담겨 있어서 AI 크롤러가 블로그의 맥락을 빠르게 파악할 수 있다.
Postlark 자체의 llms.txt도 있다. MCP 서버 설치법, API 사용법, 요금제별 기능 차이까지 정리되어 있다. Claude에게 "Postlark가 뭐야?"라고 물으면 이 파일을 참조해서 대답할 수 있다. 마케팅 페이지를 읽는 게 아니라, 구조화된 기술 문서를 읽는 것이다.
왜 이렇게까지 해야 하나
솔직히 말하면, REST API 하나만 잘 만들어도 충분할 수 있다. MCP 서버를 따로 만들고, CLI를 따로 만들고, llms.txt까지 관리하는 건 1인 개발 프로젝트치고 과하다고 느낄 수도 있다.
그런데 블로그 플랫폼 시장을 보면 답이 나온다. WordPress, Ghost, Medium, 티스토리 — 전부 사람이 브라우저에서 글을 쓴다는 전제로 설계됐다. AI 에이전트가 글을 발행하는 시나리오는 고려 대상이 아니었다. WordPress는 REST API가 있지만, 그건 테마 개발자를 위한 것이지 AI 에이전트를 위한 것이 아니다.
Postlark가 노리는 건 그 틈이다. AI가 콘텐츠를 만드는 시대에, 퍼블리싱 파이프라인도 AI 네이티브여야 한다. MCP 서버가 npm에 올라가 있다는 건 단순히 "API를 한 겹 감쌌다"가 아니라, AI 에이전트의 도구 생태계 안에 Postlark가 들어가 있다는 뜻이다.
Claude Code 사용자가 MCP 서버 목록을 훑다가 @postlark/mcp-server를 발견하는 순간, 그게 곧 사용자 획득이다. 앱스토어에 앱을 올리는 것과 본질적으로 같다. npm이 배포 채널이 되는 셈이다.
다음 편 예고
연재의 마지막 편이 남았다. 14편에서는 이 모든 걸 혼자서 6주 만에 만든 이야기를 한다. 기술 선택보다는 시간 관리와 스코프 조절, 그리고 "뭘 안 만들 것인가"에 대한 판단 과정을 쓸 생각이다.