블로그 포스트 작성기

블로그 포스트 작성기은(는) 무엇을 하나요?

코드 변경사항, 마케팅 브리프, 기능 설명에서 고품질 블로그 포스트를 작성합니다. SEO, 구조, 톤 매칭, 시각적 콘텐츠를 처리합니다.

작성 규칙(절대 예외 없음): em-dash(— 또는 –)를 절대 사용하지 마십시오. 대신 하이픈(-)을 사용하세요. 생성된 모든 카피의 모든 줄에 적용됩니다.

입력 해석

인자가 제공된 경우 다음 순서로 해석합니다:

1. 기존 마케팅 브리프 파일 경로(.md 파일로 "Executive Summary" 또는 "Key Messages" 포함) → 마케팅 브리프
2. GitHub URL 또는 #\d+ 패턴과 일치 → PR
3. ... 또는 .. 포함 → git ref 범위
4. 기존 파일/디렉토리로 확인 → 코드베이스 기능
5. 그 외 → 자유 형식 텍스트

인자가 제공되지 않으면 다음 질문을 합니다: "무엇에 대해 작성할까요? 마케팅 브리프 경로, PR URL/번호, git ref 범위(예: v1.0...v2.0), 파일/디렉토리 경로를 제공하거나 주제를 설명해 주세요."

여러 해석이 일치하는 경우 사용자에게 확인합니다.

프로세스 흐름

digraph blog_post {
    rankdir=TB;
    "입력 해석" [shape=box];
    "1단계: 탐색" [shape=box];
    "2단계: 조사" [shape=box];
    "3단계: 설정" [shape=box];
    "4단계: 개요" [shape=box];
    "개요 승인됨?" [shape=diamond];
    "5단계: 작성" [shape=box];
    "6단계: 출력" [shape=box];

    "입력 해석" -> "1단계: 탐색";
    "1단계: 탐색" -> "2단계: 조사";
    "2단계: 조사" -> "3단계: 설정";
    "3단계: 설정" -> "4단계: 개요";
    "4단계: 개요" -> "개요 승인됨?";
    "개요 승인됨?" -> "4단계: 개요" [label="아니요, 수정"];
    "개요 승인됨?" -> "5단계: 작성" [label="예"];
    "5단계: 작성" -> "6단계: 출력";
}

단계를 건너뛰지 마세요. 자연스러운 속도로 질문하세요. 사용자를 압도하지도 말고 인위적으로 속도를 늦추지도 마세요. 사용자가 여러 질문에 한 번에 답변하면 번들로 받아들이고 건너뛰세요.

사용자가 "그냥 기본값으로 해줘", "네가 골라" 또는 이와 유사한 말을 하면, 문맥에 따라 합리적인 기본값을 선택하고 선택한 내용을 알린 후 진행 전에 한 번의 확인을 요청하세요.

확인 없이 가정하지 마세요.

1단계: 탐색

1단계 - 입력 분석

입력 유형	읽을 내용
마케팅 브리프	브리프 읽기 - 문제 정의, 가치 제안, 대상, 핵심 메시지, 경쟁 포지셔닝 추출. 제품 맥락이 부족하면 2단계도 수행한 후 3단계로 진행.
PR	차이점, PR 설명, 리뷰 코멘트, 커밋 메시지(gh pr view, gh pr diff). 큰 PR(20개 이상 파일)의 경우 사용자 대상 변경사항에 집중.
Git refs	ref 간 git diff 및 git log. 큰 범위의 경우 커밋 메시지와 사용자 대상 변경사항 우선.
코드베이스 기능	지정된 파일/디렉토리 읽기.
자유 형식 텍스트	사용자의 설명 분석. 구체성 부족(기능 이름, 가치 제안, 맥락 없음) 시 추가 세부정보나 특정 파일/PR을 요청. 그래도 안되면 개방형 질문에 의존.

사용자 대상 변경사항에는 신규 기능, UI 변경, API 변경, 성능 개선, 버그 수정, 문서 업데이트가 포함됩니다. 내부 변경사항에는 리팩터, 테스트 추가, CI 변경, 의존성 업데이트가 포함됩니다. 불확실할 경우 찾은 내용을 나열하고 사용자에게 관련 항목을 물어보세요.

오류 처리:

• gh 미설치/미인증 → 사용자에게 알리고 gh auth login 제안, 대안 입력 제공
• 잘못된 PR/ref → 사용자에게 알리고 확인 요청
• 파일 없음 → 올바른 경로 요청

2단계 - 더 넓은 제품 맥락 읽기

존재하는 경우 읽기: README, docs/, package.json(또는 동등 파일), 마케팅 참조.

목표: 제품이 무엇인지, 누구를 위한 것인지, 무엇을 하는지 이해.

아무것도 없으면 질문: "저장소에서 제품 맥락을 찾을 수 없습니다. 제품이 무엇이고 누구를 위한 것인지 간단히 설명해 주시겠습니까?"

3단계 - 이해한 내용 제시

"제가 이해한 내용은 다음과 같습니다:"

• 기능 A - 짧은 설명
• 기능 B - 짧은 설명

"이 중 어떤 것을 블로그 포스트에서 다뤄야 할까요? 추가, 삭제, 수정할 사항이 있나요?"

범위를 완전히 이해할 때까지 필요한 만큼 질문하세요. 사용자가 확인할 때까지 진행하지 마십시오.

4단계 - 민감 항목 플래그

다음 항목 스캔: 호환성 깨짐 변경, 폐기(Deprecation), 보안 수정, 마이그레이션 요구사항.

발견되면 각각을 플래그하고 진행 전에 어떻게 표현할지 물어보세요.

2단계: 경쟁 블로그 조사

포스트 설정 전, 해당 분야의 유사 블로그 포스트를 검색:

1. WebSearch를 사용해 동일 주제, 경쟁 제품, 유사 기능 발표를 다루는 기존 블로그 포스트 3-5개 찾기
2. 해당 포스트의 장단점 분석 - 구조, 헤드라인, 훅, SEO 키워드, 깊이
3. 콘텐츠 격차 식별 - 경쟁사가 다루지 않는 부분
4. 이 결과를 SEO 전략, 헤드라인 생성, 콘텐츠 구조에 활용

WebSearch를 사용할 수 없으면 이 단계를 건너뛰고 자체 지식에 의존하세요.

사용자에게 간단한 요약 제시:

"비슷한 포스트를 찾았습니다. 발견한 내용은 다음과 같습니다:"

• [효과적인 부분에 대한 주요 발견]
• [콘텐츠 격차 / 기회]
• [SEO 키워드 기회]

"이 통찰력을 포스트 구성에 활용하겠습니다."

3단계: 설정

다음 질문:

Q1 - 대상: "이 블로그 포스트의 대상은 누구인가요?" (개발자, 최종 사용자, 기술 의사결정자, 일반 대상, 기타)

Q2 - 톤: 저장소의 기존 블로그 포스트, README, 문서를 읽어 제품의 목소리를 감지. 그런 다음 확인:

"기존 콘텐츠를 바탕으로 톤이 [예: 대화형이고 개발자 친화적]인 것 같습니다. 이에 맞출까요, 아니면 다른 방향으로 갈까요?"

분석할 기존 콘텐츠가 없으면 원하는 톤을 직접 물어보세요.

Q3 - 포스트 유형: 입력과 대상을 바탕으로 포스트 유형을 추천하고 확인:

• 기능 발표 - "X를 출시했습니다, 왜 중요한지" (~600-1000단어)
• 심층 기술 - "X를 구축한 방법, 결정과 아키텍처" (~1500-2500단어)
• 문제-해결 서사 - "X 문제가 있나요? 여기 해결 방법이 있습니다" (~1000-2000단어)

"[입력/대상]을 고려하여 [유형] 포스트를 추천합니다. 이유는 [이유]입니다. 맞을까요?"

Q4 - CTA: 문맥에서 가장 적절한 행동 유도 문구 추론:

• 오픈소스 → 저장소 스타, 기여하기, 사용해보기
• SaaS → 가입, 무료 체험 시작
• 기능 업데이트 → 새 기능 사용해보기, 문서 읽기
• 라이브러리/SDK → 설치, 마이그레이션 가이드 읽기

"CTA는 [추론된 CTA]를 제안합니다. 이대로 갈까요, 아니면 다른 것을 원하시나요?"

Q5 - 참여 수준: "작성 과정에 얼마나 참여하고 싶으신가요?"

• A) 그냥 작성해 주세요 - 제가 모든 것을 처리하고 가장 좋은 헤드라인을 선택해 최종 포스트를 저장합니다. 이후 변경을 요청할 수 있습니다.
• B) 먼저 개요를 보여주세요 - 구조를 승인하면 전체 포스트를 작성합니다
• C) 단계별로 진행해 주세요 - 개요 승인 후 섹션별로 확인하며 진행

4단계: 개요

구조화된 개요 생성:

## [작업 제목]

1. **훅/소개** - [접근 방식: 질문/통계/대담한 주장/스토리]
   - 확립할 핵심 포인트
   - 본문으로 전환

2. **섹션 이름** - [목적]
   - 핵심 포인트
   - 예상 단어 수

3. **섹션 이름** - [목적]
   - 핵심 포인트
   - 예상 단어 수

[...필요한 만큼 섹션]

N. **결론** - [요약 + CTA]
   - 강화할 핵심 내용
   - CTA: [구체적 행동]

총 예상 단어: ~X단어

참여 수준이 A이면 개요를 내부적으로 생성하고 보여주지 않습니다. B와 C의 경우 개요를 제시하고 승인을 기다립니다.

5단계: 작성

내부 작성 프로세스(참여 수준과 관계없이 항상 실행)

각 섹션마다:

1. 섹션 작성
2. 자체 검토: 콘텐츠를 다르게 구조화할 수 있는지, 독자가 이해하고 소화하는 데 필요한 맥락이 누락되었는지, 주제에 익숙하지 않은 사람을 혼란스럽게 할 간격이 있는지 분석
3. 백필: 누락된 부분이 발견되면 연결 문단, 맥락 추가 또는 구조 변경 후 진행

참여 수준이 C이면 자체 검토 후 각 섹션을 제시하고 진행 전에 확인을 받습니다. A와 B의 경우 이 프로세스를 자동으로 실행합니다.

헤드라인

본문 완성 후 다양한 공식을 사용해 3-5개의 헤드라인 옵션 생성:

• 방법("[제품]으로 [문제] 해결하는 방법")
• 숫자/목록("[기능]이 [워크플로]를 바꾸는 3가지 이유")
• 질문("[고통점]에 지치셨나요?")
• 대담한 주장("[기능]은 [결과]를 위한 가장 빠른 방법입니다")
• 전후("[고통] → [결과]: [기능]이 어떻게 실현하는가")

하나를 추천하고 이 포스트의 대상, SEO, 맥락에 가장 적합한 이유를 설명합니다. 또한 다른 옵션의 장단점을 설명합니다.

참여 수준 B와 C의 경우 옵션을 제시하고 진행 전에 사용자의 선택을 받습니다. A의 경우 추천을 사용합니다.

SEO 제약보다 가독성을 우선시합니다. 먼저 최고의 헤드라인을 작성합니다. 50-60자 SEO 제목 제한에 맞지 않으면 프론트매터를 위해 별도의 짧은 타이틀 태그를 만듭니다.

SEO 프론트매터

포스트 상단에 YAML 프론트매터로 생성:

---
title: "[선택된 헤드라인]"
meta_description: "[140-160자, 주요 키워드 포함, 설득력 있는 가치 제안]"
primary_keyword: "[주요 타겟 키워드]"
secondary_keywords: ["키워드1", "키워드2", "키워드3"]
long_tail_keywords: ["더 긴 구문 1", "더 긴 구문 2"]
slug: "[url-friendly-slug]"
---

규칙:

• 타이틀 태그: 50-60자, 주요 키워드 앞쪽 배치
• 메타 설명: 140-160자, 사람을 위해 작성, 고유 가치 제안 포함
• 키워드는 2단계 경쟁 조사 결과에 기반
• 키워드 스터핑 금지 - 자연어만 사용

콘텐츠 서식 규칙

• 짧은 문단: 최대 2-4문장
• 소제목: 주요 섹션에 H2, 하위 섹션에 H3 사용. 소제목은 자체로 스캔 가능한 개요 역할을 해야 함
• 핵심 구문을 굵게 표시하여 F-패턴 스캐닝 지원
• 3개 이상 항목은 글머리 기호와 목록 사용
• 문단당 하나의 아이디어
• 생성된 콘텐츠에 em-dash를 절대 사용하지 마세요. "—" 문자 금지. 대신 쉼표, 콜론, 마침표, 괄호 사용

훅/소개

소개는 세 가지 구성 요소로 이루어짐:

1. 훅(첫 1-2문장) - 놀라운 통계, 대담한 주장, 공감되는 고통점, 도발적인 질문. 읽은 지 3초 안에 호기심이나 감정적 공명을 만들어야 함
2. 권위 - 왜 이것이 중요한지 또는 독자가 왜 이것을 신뢰해야 하는지 간략히 확립
3. 약속 - 이 포스트에서 독자가 얻을 수 있는 것을 명확히 기술

소개는 3-5개의 짧은 문단으로 유지. 긴 텍스트 블록 금지.

결론

1. 주요 내용 재진술(새로운 아이디어 도입 금지)
2. 행동 동사가 포함된 단일 명확한 CTA("지금 사용해보기", "저장소에 별표 표시", "무료 체험 시작")
3. 선택적으로 토론을 유도하는 미래 지향적 문장이나 질문으로 마무리

시각적 콘텐츠

가능하면 직접 생성:

• 아키텍처 다이어그램 → mermaid 코드 블록 또는 인라인 SVG
• 데이터 흐름 다이어그램 → mermaid 코드 블록
• 비교 테이블 → 마크다운 테이블
• 코드 예제 → 구문 강조 코드 블록

외부 생성이 필요한 이미지의 경우:

<!-- TODO: 이미지 추가 -->
<!-- 제안: [이미지가 보여줘야 할 내용 설명] -->
<!-- LLM 프롬프트: "[이미지 생성 모델용 프롬프트, 예: '다크 모드 토글이 있는 대시보드를 보여주는 깔끔하고 미니멀한 일러스트레이션, 플랫 디자인 스타일, 개발자 도구 미학, 16:9 비율']" -->
![대체 텍스트 설명](placeholder.png)

이해를 돕는 곳이면 어디든 시각 자료 사용 - 복잡한 개념 설명 후, 옵션 비교 시, UI 변경 표시 시.

코드 예제

개발자 대상의 경우 실제 동작하는 기능을 보여주는 코드 예제를 최소 하나 포함. 5-15줄의 최소한의 실행 가능한 스니펫 선호. 개선 사항을 보여줄 때는 전후 비교 표시.

5b단계: 전체 초안 검토

모든 섹션이 작성되고 헤드라인이 선택된 후 전체 포스트(프론트매터 + 본문)를 조립.

• 수준 A: 검토 건너뜀. 바로 출력으로 진행. 최종 포스트를 제시하고 저장. 사용자는 이후 변경 요청 가능.
• 수준 B: 저장 전에 전체 초안을 사용자에게 제시하여 검토. "전체 포스트입니다. 저장하기 전에 변경할 사항이 있나요?"
• 수준 C: 사용자가 각 섹션을 개별적으로 보았지만, 그래도 조립된 초안을 최종 검토용으로 제시. "전체 포스트입니다. 저장하기 전에 변경할 사항이 있나요?"

B와 C의 경우 사용자가 수정을 요청하면 수정하고 다시 제시. 사용자가 승인할 때만 출력으로 진행.

6단계: 출력

먼저 기존 블로그 디렉토리 탐지. 다음 확인:

• content/blog/, src/pages/blog/, _posts/, blog/, posts/, articles/

찾으면 해당 디렉토리 사용. 없으면 기본값 blog/posts/ 사용.

사용자에게 제시:

"이것을 [탐지된 또는 기본 경로]/<slug>.md에 저장하겠습니다. 다른 곳에 저장할까요, 아니면 저장하지 않고 그냥 출력만 할까요?"

디렉토리가 없으면 생성.

파일이 이미 존재하면: 덮어쓸지 버전 복사본을 만들지 질문.

오류 처리

• gh 사용 불가 → 사용자에게 알리고 대안 입력 제공
• 잘못된 PR/ref → 사용자에게 확인 요청
• 제품 맥락 없음 → 사용자에게 제품 설명 요청
• WebSearch 사용 불가 → 2단계 건너뛰고 자체 지식으로 진행
• 기존 블로그 디렉토리 없음 → blog/posts/ 기본값 사용, 생성

이 스킬이 수행하지 않는 작업

• 소셜 미디어 카피 생성(/social-copy 사용)
• 포스트를 어떤 플랫폼에도 게시 또는 배포
• 마케팅 브리프 생성(/marketing-brief 사용)
• 다양한 대상을 위한 여러 변형 생성 - 다른 대상이 필요하면 스킬을 다시 실행