MCP (Model Context Protocol) 커넥터는 Claude의 범위를 외부 서비스로 확장하지만, 플랫폼마다 커넥터 지원 범위가 불균형합니다. dev.to는 그러한 공백 중 하나로, 현재 이를 위한 쓰기(write) 기능을 지원하는 MCP 커넥터가 없습니다. 이 포스트는 dev.to의 REST API를 직접 호출하고, 해당 워크플로우를 재사용 가능한 Claude skill로 변환하며, 해당 skill에 API 키를 완전히 포함하지 않는 이유에 대한 논리적 근거를 다룹니다.

1. 공백: dev.to 쓰기 기능을 위한 MCP 커넥터 부재

Claude는 Gmail, Google Drive, Shopify 등 MCP (Model Context Protocol) 커넥터를 통해 외부 서비스에 연결됩니다. 커뮤니티에서 구축한 dev-to-mcp server가 존재하지만, 이는 dev.to의 공개(public) API인 get_articles, get_article, get_user, get_tags, get_comments, search_articles만을 래핑(wrap)하고 있습니다. 설계상 읽기 전용(Read-only)이며, 작성자는 초기 릴리스를 단순하게 유지하기 위해 인증이 필요한 쓰기 엔드포인트(write endpoints)를 명시적으로 제외했습니다.

특정 서비스에 대한 MCP 서버가 존재한다고 해서 해당 서비스의 API가 할 수 있는 모든 기능이 노출된다는 의미는 아닙니다. 이러한 차이점은 제3자 플랫폼을 대상으로 AI 에이전트 통합을 계획할 때 매우 중요합니다.

2. 해결책: dev.to의 실제 REST API

dev.to는 수년 동안 기사 생성, 읽기, 업데이트, 삭제(CRUD)를 비롯하여 팔로워 및 알림 엔드포인트를 포함한 완전한 인증 기반 REST API를 제공해 왔습니다. 이는 MCP 도구가 아닌 일반적인 API이므로, 이를 사용하려면 HTTP 호출을 수행할 수 있는 범용적인 방법, 즉 네트워크 액세스와 셸(shell)이 있는 샌드박스 환경이 필요합니다. 모든 엔드포인트, 필수 헤더, 응답 스키마를 포함한 전체 레퍼런스는 developers.forem.com/api/v1에 게시되어 있습니다. AI 에이전트(또는 사람)는 API 구조에 대한 사전 학습 지식에 의존하기보다, 통합 코드를 작성하기 전에 이 페이지를 직접 읽어야 합니다.

워크플로우는 세 가지 일반적인 HTTP 호출로 요약됩니다:

1. GET  /api/articles/:username/:slug   → 숫자 형태의 article ID를 찾습니다.
2. GET  /api/articles/:username/:slug   → 로컬에서 편집하기 위해 body_markdown을 가져옵니다.
3. PUT  /api/articles/:id  (api-key 헤더 포함)  → 새로운 제목, 태그, 본문을 전송합니다.

Raw markdown을 가져와 표준 텍스트 교체 방식으로 편집한 후, 서명된 요청(signed request)과 함께 다시 전송합니다. 제목을 편집한 후에도 게시된 URL과 slug는 변경되지 않으므로, 기존 링크들은 계속해서 올바르게 연결됩니다.

3. 재사용 가능한 Skill로 전환하기

Claude는 "skills"를 지원합니다. 이는 워크플로우를 문서화한 markdown 파일로, 향후 세션에서 동일한 단계를 다시 발견할 필요가 없도록 해줍니다. 위의 dev.to 워크플로우는 정확한 curl 패턴, 공식 API 레퍼런스 링크, 태그 형식 제약 사항(최대 4개, 영문/숫자만 허용), 그리고 PUT 요청은 명시적으로 전송된 필드만 변경한다는 유의 사항을 포함하는 SKILL.md로 작성되었습니다.

이 파일은 Shopify 교차 리스팅(cross-listing) 워크플로우 및 WordPress 발행 워크플로우를 위해 구축된 유사한 skill들과 함께 나란히 놓여 있습니다. 각 skill은 일회성 문제 해결 세션을 매번 동일한 제약 사항을 다시 설명해야 하는 과정이 아닌, 재사용 가능한 무언가로 변환해 줍니다.

🔐 코드보다 더 중요했던 규칙: API key는 절대로 skill 파일에 포함하지 않는 것입니다.

Skill 파일은 영구적으로 보존됩니다. 이 파일들은 향후 모든 대화에서, 어떤 기기에서든, 무기한으로 컨텍스트에 자동으로 다시 읽힙니다. 활성화된 자격 증명(credential)이 파일에 들어있는 것은 지속적인 보안 위험 요소입니다. 만료 기간도 없고, 암호화도 없으며, 감사 추적(audit trail)도 불가능하고, 나중에 누가 또는 무엇이 이에 접근했는지 확인할 방법도 없습니다. 따라서 skill은 키를 어디에서 얻을 수 있는지 문서화하고 매 세션마다 새로 요청하라는 알림을 포함하되, 값 자체는 절대 기록하지 않습니다. 키는 단일 대화의 curl 호출에 사용된 후 폐기됩니다.

키는 dev.to → Settings → Extensions의 해당 페이지 하단에 있는 "DEV API Keys" 섹션에서 생성할 수 있습니다.

4. 이 패턴을 다른 곳에 적용하기

이 패턴은 dev.to에만 국한된 것이 아닙니다. MCP 커넥터가 아직 존재하지 않거나, API의 일부만 지원하는 모든 서비스에 적용할 수 있습니다:

• MCP 래퍼 (wrapper)가 없더라도 해당 서비스에 일반적인 REST API가 있는지 확인하세요. 대부분의 기성 플랫폼은 이를 지원합니다.
• 문제가 한 번 해결된 후에 Claude가 스킬 (skill) 파일을 작성하도록 하세요. 그래야 추측이 아닌 실제 제약 사항(속도 제한 (rate limits), 필수 헤더 (required headers), 필드 명명 규칙의 특이점 (field-naming quirks))을 포착할 수 있습니다.
• 영구적인 저장소에 비밀 정보 (secrets)를 남기지 마세요. 워크플로우에 인증 정보 (credential)가 필요한 경우, 스킬은 이를 어떻게 얻고 어디에 제공해야 하는지를 설명해야 하며, 값 자체를 절대 저장해서는 안 됩니다.
• 스킬을 생성해 달라고 요청할 때 '저장 금지' 요구 사항을 명시적으로 언급하세요. 스킬의 전체 목적은 대화보다 더 오래 지속되는 것이기 때문입니다.

5. 각 단계별 예시 프롬프트 (Example Prompts)

위의 단계들은 일상적인 언어로 된 요청으로 직접 연결됩니다. 다음은 워크플로우의 각 단계를 구동하는 실제 프롬프트입니다:

각 프롬프트는 기술적인 지침 세트가 아니라 원하는 결과에 대한 평이한 설명입니다. 스킬 파일이 메커니즘(엔드포인트 (endpoints), 헤더 (headers), 필드 제약 조건 (field constraints))을 제공하므로, 요청 자체는 짧게 유지될 수 있습니다.