Source: Dev.to

---

나는 초안에 12개의 미발행 글이 있었고, MCP 서버가 그것을 해결했다

배경

몇 주 동안 내 블로그에 12개의 초안이 쌓여 있었어요.
이 글들은 모두 완성된 상태였지만, 실수로 draft 상태로 남아 있었고, 실제로는 공개하고 싶었죠.

문제는 두 가지였습니다.

1. 시간 낭비 – 매번 초안을 찾아서 published 로 바꾸는 작업이 번거로웠습니다.
2. 실수 위험 – 실수로 초안을 그대로 두면, 독자들이 새 글을 못 보게 됩니다.

해결책: MCP 서버 활용

MCP(Managed Content Publishing) 서버는 자동화된 게시 파이프라인을 제공해 줍니다.
다음과 같은 기능을 통해 초안 문제를 한 번에 해결할 수 있었습니다.

• 조건 기반 트리거: 특정 메타데이터(예: status: draft)를 감지하면 자동으로 published 로 전환합니다.
• 배치 처리: 한 번에 여러 글을 처리할 수 있어, 12개의 초안을 한 번에 공개했습니다.
• 로그 및 알림: 어떤 글이 언제 전환됐는지 로그와 슬랙 알림을 받아 추적이 쉬웠습니다.

구현 단계

1. MCP 서버 설정

   triggers:
     - name: publish-drafts
       condition: status == "draft"
       action: set_status
       params:
         new_status: "published"

2. 메타데이터 추가
   각 글의 헤더에 status: draft 라는 라인을 넣었습니다.

   ---
   title: "My Unpublished Article"
   status: draft
   ---

3. 배치 실행

   mcp run publish-drafts --all

4. 검증
   실행 후 블로그 대시보드에서 모든 글이 published 로 바뀐 것을 확인했습니다.

결과

• 12개의 초안이 즉시 공개되었습니다.
• 매번 수동으로 상태를 바꾸던 시간을 5분 이하로 단축했습니다.
• **오류 발생률이 0%**에 가까워졌습니다.

교훈

• 자동화는 작은 반복 작업에서도 큰 차이를 만든다는 점을 다시 한 번 깨달았습니다.
• MCP 서버와 같은 CI/CD 개념을 콘텐츠 관리에 적용하면, 블로그 운영이 훨씬 효율적입니다.

---

Tip:
초안을 자동으로 공개하고 싶지 않은 경우, 메타데이터에 auto_publish: false 같은 플래그를 추가하고 트리거 조건에 포함시켜 예외 처리를 할 수 있습니다.

이제 초안이 쌓여서 고민할 일은 없습니다. 🎉

나는 글쓰기로 배우는 개발자… 하지만 절대 끝을 못 내요

내 하드 드라이브에 반쯤 완성된 글들의 묘비비석이 진짜 이야기를 말해줍니다: 12개의 초안을 진심으로 공개하려고 했어요. 흥미롭다고 생각한 주제, 해결한 문제, 공유할 가치가 있다고 여긴 것들. 각각이 *“거친 아이디어”*와 “게시하기에 충분히 좋음” 사이 어딘가에서 포기되었습니다.

작가의 블록이 아니라 마찰이었습니다:

• 이미 다루어진 내용이 무엇인지 조사하는 작업
• 편집자, Dev.to, 그리고 내 노트 사이를 오가는 왕복
• 포맷팅, 태그, 시리즈 선택

이것들 자체가 어렵지는 않지만, 모두 합쳐지면 내 뇌가 즉각적으로 보상이 더 큰 일—예를 들어 또 하나의 버그를 고치거나 다른 사람의 완성된 글을 읽는 일—에 집중하게 만들 정도의 저항이 됩니다.

나는 매일 AI 도구를 사용합니다. Claude Code가 무거운 엔지니어링 작업을 담당하죠. 코드베이스를 주면 리팩터링하고, 디버깅하고, 함께 계획까지 세워줍니다. 하지만 글쓰기—내가 더 많이 하고 싶다고 계속 말하던 그 일—에 대해서는 여전히 모든 것을 손수 해야 했습니다.

그래서 나는 다리를 만들었습니다: Claude를 Dev.to에 직접 연결하는 MCP 서버를 구축해, 전체 게시 워크플로우를 대화식으로 전환했습니다.

그것은 단순히 더 빨리 게시하도록 도와준 것이 아니라, 게시에 대한 심리 자체를 완전히 바꾸어 놓았습니다.

Source: …

마찰이 사라지면 무엇이 바뀔까

내가 가장 크게 느낀 변화는 속도가 아니라 스스로를 설득하는 걸 멈췄다는 것이었다.

그 연구 단계만으로도 내 기사 대부분이 시작되기도 전에 사라졌다. 이를 없애니 모든 것이 바뀌었다.

초안 작성도 달라졌다. 나는 빈 공간에 글을 쓰고 결과를 기대하지 않는다. 내가 말하고 싶은 것을 설명하면 Claude가 초안을 만들고, 나는 그것을 내 목소리로 다듬는다. 구조는 이미 잡혀 있다. 나는 편집을 하는 것이지, 처음부터 시작하는 것이 아니다. 편집은 쉽다. 시작은 어렵다. 이로써 어려운 일을 쉬운 일로 옮긴 셈이다.

그리고 초안이 완성되면 — 출판은 문자 그대로 한 줄의 메시지다:

“괜찮아, 출판해.”

끝.

Source: …

실제 워크플로우

실제 세션이 아이디어 단계부터 게시까지 어떻게 진행되는지 보여드립니다:

Me: "I want to write about setting up a local MCP server for Outlook.
     Search Dev.to — what's already covered on this topic?"

Claude: [searches Dev.to]
        "There are a few articles on MCP setup generally, but nothing
         specifically about Outlook or email automation workflows.
         Strong gap to write into."

Me: "Good. Check my existing series — does this fit anywhere?"

Claude: [checks my articles and series]
        "You have an 'AI‑Powered Developer Workflows' series.
         This fits perfectly as the next entry."

Me: "Write it. Focus on the local server setup and the automation
     angle. Keep it practical, not theoretical. Draft it on Dev.to."

Claude: [writes article, creates draft]
        "Draft created. ID: 3341092. Ready for your review."

Me: "The setup section needs more detail — add the exact config file
     path and a sample rule."

Claude: [updates the draft]

Me: "Perfect. Publish it."

Claude: [publishes]
        "Live at https://dev.to/themeticulist/..."

시작 → 게시: 한 번의 대화로 완료됩니다. 탭을 전환하거나 복사‑붙여넣기를 할 필요가 없고, 컨텍스트 손실도 없습니다.

그 세션에서 나온 글은 이제 제 Dev.to 프로필에 반응과 댓글과 함께 게시되어 있습니다. 그렇지 않았다면 초안 #13에 머물렀을 것입니다.

직접 설정하는 방법

서버는 yashaswiyogeshwara/devto-mcp 에서 오픈 소스로 제공됩니다. 아래 단계를 따라 실행해 보세요.

1. Dev.to API 키 얻기

1. Dev.to → Settings → Extensions → DEV Community API Keys 로 이동합니다.
2. 새 키를 생성하고 잘 보관합니다.

2. 클론하고 빌드하기

git clone https://github.com/yashaswiyogeshwara/devto-mcp.git
cd devto-mcp
npm install
npm run build

3. .env 파일 만들기

# devto-mcp/.env
DEVTO_API_KEY=your_key_here

4. Claude Desktop에 추가하기

%APPDATA%\Claude\claude_desktop_config.json 파일을 열고 다음을 추가합니다:

{
  "mcpServers": {
    "devto": {
      "command": "node",
      "args": ["C:/path/to/devto-mcp/dist/index.js"],
      "env": {
        "DEVTO_API_KEY": "your_key_here"
      }
    }
  }
}

Claude Desktop을 재시작하면 MCP 패널에 Dev.to 도구가 자동으로 나타납니다.

5. Claude Code 사용자용

같은 블록을 claude_mcp_config.json (보통 %APPDATA%\Claude\claude_mcp_config.json 위치)에 추가합니다. Claude Code는 다음 실행 시 이를 자동으로 인식합니다.

서버가 할 수 있는 일

전체 사이클을 포괄하는 8가지 도구:

이 도구들을 사용하면 Claude와의 대화를 떠나지 않고도 조사, 계획, 작성, 편집, 게시를 할 수 있습니다.

TL;DR

마찰은 글쓰기를 죽인다. Claude를 MCP 서버와 직접 연결해 Dev.to에 연결하면, 연구, 초안 작성, 출판 단계가 끊김 없는 대화가 됩니다. 결과는? 더 빠른 출판, 포기된 초안 감소, 그리고 아이디어가 실제로 세상에 드러날 것이라는 자신감이 상승합니다. 한번 시도해 보세요—미래의 당신이 고마워할 겁니다.

Publishing — publish_article은 의도적인 별도 단계입니다. 한 번의 메시지로 배포합니다. 이 구분이 중요한 이유는 언제 무언가가 라이브될지 항상 알 수 있기 때문입니다.

Tracking — get_article_analytics는 모든 기사에 대한 반응 수와 댓글을 반환합니다.

One Gotcha Worth Knowing

If you’re building on top of this or customizing it: don’t put YAML front‑matter in your article body. The Dev.to API has a quirk where front‑matter in body_markdown silently overrides your JSON parameters — your tags get replaced, your series disappears. The server already guards against this and throws a clear error if it detects front‑matter, but it’s worth knowing why.

알아두면 좋은 함정

이것을 기반으로 구축하거나 커스터마이징한다면: 기사 본문에 YAML 프런트매터를 넣지 마세요. Dev.to API에는 body_markdown에 프런트매터가 있으면 JSON 파라미터를 조용히 덮어쓰는 특성이 있습니다 — 태그가 교체되고 시리즈가 사라집니다. 서버는 이미 이를 방지하고 프런트매터를 감지하면 명확한 오류를 발생시키지만, 왜 그런지 알아두면 좋습니다.

실제로 나에게 바뀐 점

지난 달에 나는 지난 1년보다 더 많이 출판했다. 갑자기 아이디어가 더 많아졌거나 시간이 더 생긴 것이 아니라, “이걸 써야겠다”는 생각과 “출판했다”는 결과 사이의 단계가 여러 차례에 걸친 고된 과정에서 단 한 번의 대화로 줄어들었기 때문이다.

이 도구가 내 대신 글을 써 주는 것은 아니다. 내 목소리, 내 예시, 내 관점은 여전히 내가 직접 제공해야 한다. 하지만 글쓰기와 관련된 모든 것을 처리한다: 연구, 구조, 포맷팅, 출판 메커니즘 등. 글쓰기를 프로젝트가 아니라 대화로 바꿔준다.

만약 미출판 초안이 무덤처럼 쌓여 있다면, 그것이 바로 고쳐야 할 문제다.

This article was drafted using the MCP server it describes.