본문으로 바로가기
자료실로 돌아가기

Claude 블로그 초안 프롬프트 10개

목적별 전문 10개예요. 그대로 복사해서 Claude에게 붙여넣으면 돼요.

1. 역할·독자·금지선을 한 번에 고정하는 시작 프롬프트

지금부터 이 대화에서 너는 [5년 차 개발 블로거]다. 독자는 [코딩을 막 시작한 사람]이고, 독자가 이 글을 읽는 이유는 [주제]로 검색해서 들어왔기 때문이다. 이 대화 내내 아래 규칙을 유지해라. 내가 다시 말하지 않아도 매 응답에 적용한다. - 말투: 한국어 해요체. 번역투 금지("~에 대해 알아보겠습니다" 같은 문형 금지). - 금지어: 혁신적, 획기적, 최고의, 꿀팁, 강력추천, 게임체인저, 놀라운, 무조건. - 확신 없는 수치·버전·통계는 쓰지 마라. 모르면 [확인 필요]라고 표시해라. - 독자가 모를 용어는 처음 1회만 한 줄로 풀어 써라. 이해했으면 규칙을 3줄로 요약해서 답해라. 글은 아직 쓰지 마라.

💡 왜 이렇게 쓰나규칙을 매번 다시 말하면 중간부터 무너져요. 세션 첫 프롬프트에 역할·독자·금지선을 박아두면 이후 모든 출력에 적용됩니다.

⚠️ 흔한 실패"블로그 글 써줘" 한 방 프롬프트 — 역할·독자·구조가 없으면 어디서 본 듯한 일반론으로 수렴합니다.

2. 개요만 먼저 — 본문 쓰기 전에 승인 게이트 만들기

[주제]로 글의 개요만 만들어라. 본문은 절대 쓰지 마라. 출력 형식: - 소제목 5개 (각 15자 이내) - 각 소제목 아래에: 이 섹션에서 다룰 핵심 주장 1줄 + 예상 분량(자 수) - 마지막 줄에: 이 글이 독자의 어떤 검색 의도에 답하는지 1문장 내가 "진행"이라고 하면 그때 소제목 순서대로 본문을 쓴다. 그 전엔 개요 수정만 받는다.

💡 왜 이렇게 쓰나개요를 먼저 확정하면 본문 전체를 갈아엎는 수정 왕복이 사라져요. 저희 자동 발행 파이프라인도 구조 확정 → 본문 순서로 돌아갑니다.

⚠️ 흔한 실패개요 없이 본문부터 받으면 "더 자세히 써줘"를 반복하게 되는데, 길어지기만 하고 밀도는 그대로입니다.

3. 도입부 후보 3유형 — 3초 테스트로 고르기

위 개요의 도입부 후보를 3가지 유형으로 각각 3문장씩 써라. 1) 질문형: 독자가 겪는 구체 상황을 질문으로 여는 버전 2) 경험담형: "직접 해 보니" 로 시작하는 1인칭 버전 3) 데이터형: 검증 가능한 사실·기본값·공식 수치로 여는 버전 (확신 없는 통계 금지 — 모르면 이 유형은 건너뛰어라) 각 버전 아래에 "이 도입부가 통하는 독자"를 1줄로 붙여라. 과장·낚시 문구 금지. 판단 기준: 독자가 3초 안에 '내 얘기네'라고 느끼는가.

💡 왜 이렇게 쓰나도입부는 이탈률을 결정하는 최고 레버리지 지점이라 1개만 받으면 아깝습니다. 유형별로 받아서 글 성격에 맞게 골라요.

⚠️ 흔한 실패"흥미로운 도입부 써줘"라고 하면 십중팔구 과장 낚시("여러분은 아직도 ~하고 계신가요?")가 나옵니다.

4. 섹션 단위 작성 — 한 번에 한 소제목, 제약 걸고

개요의 [2]번 소제목만 작성해라. 제약: - 400자 내외, 문단 3개 이하 - 각 문단의 첫 문장 = 그 문단의 핵심 주장 (두괄식) - 다른 섹션 내용 언급 금지 ("뒤에서 다루겠지만" 금지) - 마지막 문장은 다음 소제목으로 자연스럽게 넘어가는 다리 1문장 끝에 "이 섹션에서 독자가 얻는 것"을 1줄로 자체 점검해라. 얻는 게 없으면 다시 써라.

💡 왜 이렇게 쓰나전체를 한 번에 쓰게 하면 앞은 좋고 뒤로 갈수록 밀도가 떨어져요. 섹션 단위로 끊으면 품질이 균일해집니다.

⚠️ 흔한 실패분량 제약 없이 시키면 같은 말을 늘려 쓰는 물타기가 옵니다. "400자 내외 + 문단 3개 이하"가 물을 짜냅니다.

5. 실경험·수치 신호 강제 — 검색엔진이 보는 원본성 만들기

방금 쓴 섹션을 아래 조건을 채우도록 다시 써라. - 1인칭 실경험 표현 2회 이상: "직접 돌려 보니", "적용해 봤더니", "테스트해 보면" 등. 단, 실제로 하지 않은 일을 했다고 지어내지 마라 — 누구나 지금 따라 하면 재현되는 범위의 경험만. - 단위가 있는 구체 수치 2개 이상: 공식 문서의 기본값·무료 한도, 단계 수, 소요 시간(분) 등. 추측 수치 금지. 확신 없으면 숫자 대신 [확인 필요]로 표시해라. 다 쓴 뒤, 어떤 문장이 경험 신호이고 어떤 숫자가 수치 신호인지 목록으로 붙여라.

💡 왜 이렇게 쓰나저희 자동 발행 게이트가 실제로 검사하는 두 신호예요. 이게 없는 글은 AI 일반론으로 읽히고, 검색에서도 사람에게도 선택받지 못합니다.

⚠️ 흔한 실패신호를 채우라고만 하면 가짜 경험("제가 10년간 운영해 보니")을 지어냅니다 — "지어내지 마라 + 모르면 표시" 조건이 반드시 함께 가야 해요.

6. 말투 학습 — 골든 예시로 내 문체 이식하기

아래는 내가 직접 쓴 글이다. 이 글에서 다음 3가지를 분석해서 규칙으로 요약해라. 1) 종결어미 습관 (예: ~해요/~습니다 비율, 자주 쓰는 어미) 2) 문장 길이 리듬 (짧은 문장과 긴 문장을 섞는 패턴) 3) 자주 쓰는 연결어와 절대 안 쓰는 표현 --- 내 글 --- [내가 쓴 글 한 편을 여기 붙여넣기] --- 끝 --- 분석한 규칙을 먼저 보여주고, 내가 확인하면 이후 모든 글을 그 규칙으로만 쓴다.

💡 왜 이렇게 쓰나"내 말투로 써줘"는 작동하지 않아요. 말투를 규칙으로 추출하게 한 뒤 그 규칙을 지키게 해야 이식이 됩니다.

⚠️ 흔한 실패예시 글 없이 말투를 시키면 모델이 상상한 평균적 블로거 말투가 나옵니다. 골든 예시 1편이 설명 100줄보다 강해요.

7. 대조 구조 — 통념 vs 실제로 글에 긴장 만들기

[주제]를 "처음 하는 사람의 방식 vs 해 본 사람의 방식" 대조 구조로 써라. - 대조 항목 3개. 각 항목은 [통념/처음 방식 → 실제/나은 방식 → 왜 차이가 나는지] 순서로. - 항목끼리 대칭을 맞춰라 (한쪽만 길어지지 않게). - 표는 쓰지 말고 서술로. 통념 쪽을 조롱하는 톤 금지 — 나도 그랬다는 톤으로. - 마지막에 독자가 자기 상황을 판단할 기준 1개를 제시해라.

💡 왜 이렇게 쓰나대조는 스크롤을 멈추게 하는 가장 안정적인 구조예요. 저희 SNS 카드 훅 3공식 중 하나도 대조형입니다.

⚠️ 흔한 실패조건 없이 시키면 통념 쪽을 허수아비로 만들어 조롱하는 톤이 나옵니다 — 독자 절반이 그 통념 쪽에 있다는 걸 잊으면 안 돼요.

8. 퇴고 — 보존 제약을 걸고 고치기

아래 글을 퇴고해라. 고칠 것과 절대 건드리지 말 것을 구분한다. 고칠 것: - 번역투 문형 ("~에 대해", "~하는 것을 통해", "~라고 할 수 있습니다") - 3문장 연속 같은 종결어미 - 같은 의미가 반복되는 문장 (하나로 합치기) - 기계적 나열 (첫째/둘째/셋째 → 자연스러운 흐름으로) 절대 건드리지 말 것: 수치, 고유명사, 인용문, 코드 블록. 먼저 "바뀐 부분 목록"만 보여줘라. 내가 승인하면 전체 수정본을 출력해라. --- 글 --- [퇴고할 글 붙여넣기] --- 끝 ---

💡 왜 이렇게 쓰나보존 제약 없이 퇴고를 시키면 문장을 다듬으면서 숫자까지 바꿔버리는 사고가 납니다. 바뀐 부분 목록을 먼저 받는 게 안전장치예요.

⚠️ 흔한 실패"자연스럽게 다듬어줘"만 하면 글 전체를 자기 스타일로 다시 써버립니다 — 그럼 6번에서 이식한 내 말투가 사라져요.

9. 검색용 제목·요약 — 낚시 금지 조건 걸고

이 글의 검색용 메타를 만들어라. - 제목 후보 3개: 각 50자 이내, 핵심 키워드 [키워드]를 제목 앞쪽에, 글에 없는 내용 약속 금지. - 요약(메타 디스크립션) 1개: 120자 이내, 글을 읽으면 해결되는 문제를 구체적으로. - 각 제목 후보 아래에 "이 제목이 노리는 검색 의도"를 1줄로. 숫자를 쓸 거면 본문에 실제로 있는 숫자만. "충격", "필독", "총정리" 같은 낚시 단어 금지.

💡 왜 이렇게 쓰나제목·요약은 검색 결과에서 클릭을 결정하는 유일한 접점인데, 본문 다 쓰고 지쳐서 대충 짓게 되는 부분이라 분리해서 시켜요.

⚠️ 흔한 실패조건 없이 시키면 본문에 없는 내용을 약속하는 제목이 나옵니다 — 클릭은 얻어도 이탈과 신뢰 하락으로 돌아와요.

10. 발행 전 사실 검증 목록 — 마지막 게이트

발행 전 마지막 점검이다. 이 글에서 "사실 주장"만 전부 추출해라. 의견·경험담은 제외한다. 각 주장을 표로 정리해라: - 주장 내용 (한 줄) - 확신도: 상(공식 문서에서 확인 가능) / 중(일반적으로 알려짐) / 하(출처 불분명) - 확인 방법 (어디서 확인할 수 있는지) 확신도 '하'인 주장은 본문에서 삭제하거나 "제 경우에는 ~였어요" 같은 경험 표현으로 바꾸는 수정안을 함께 제시해라. --- 글 --- [발행 직전 글 붙여넣기] --- 끝 ---

💡 왜 이렇게 쓰나저희 파이프라인은 이 검증을 자동 게이트로 돌리고, 통과 못 하면 발행 자체가 막혀요. 수동으로도 이 마지막 5분이 블로그의 신뢰를 지킵니다.

⚠️ 흔한 실패AI 글의 가장 위험한 실패는 그럴듯한 거짓 수치예요. 글을 쓴 모델에게 "맞아?"라고 물으면 맞다고 해요 — 주장 추출 → 확신도 분류로 구조화해야 잡힙니다.

다음 자료 소식 받기

새 리드마그넷이 나오면 이메일로 가장 먼저 알려드려요.