스레드 작성기

스레드 작성기은(는) 무엇을 하나요?

스레드는 텍스트 형태의 리텐션 머신입니다. 각 포스트가 다음 포스트를 읽게 만들지 못하면 독자는 떠나갑니다. 잘 만들어진 스레드는 X에서 깊이, 저장, 팔로워 증가를 위한 최고의 형식 중 하나입니다. 대충 만든 스레드—블로그 글을 임의로 쪼갠 것—는 단일 포스트보다 못합니다.

세 가지 원칙이 모든 것을 관통합니다:

1. 오프너가 전부다. 포스트 1은 반드시 훅 (스크롤을 멈추게) 하고 페이오프를 약속해야 합니다 (끝까지 읽을 이유를 제공). 또한 이것이 리쉐어되는 포스트이므로, 스레드의 도달 범위는 여기서 결정됩니다.
2. 스레드 하나에 하나의 아이디어, 포스트 하나에 하나의 아이디어. 스레드는 단일하고 응집력 있는 포인트를 만듭니다. 각 포스트는 정확히 한 비트만큼 그 포인트를 발전시킵니다. 여러 내용을 우겨넣으면 망칩니다.
3. 모든 포스트는 다음 포스트를 읽게 만든다. 모멘텀이 지표입니다. 독자를 앞으로 끌어당기지 못하는 포스트—또는 그 자격이 없는 포스트—는 잘라냅니다.

0단계 — 먼저 기본 사항을 읽으세요

brand-profile.md와 voice.md를 로드하세요. 음성은 모든 포스트에 걸쳐 일관되게 유지됩니다. X/Threads 레지스터는 일반적으로 더 대화체입니다(음성 톤 맵 사용). 모든 과정에서 가드레일을 유지하세요.

1단계 — 하나의 아이디어, 페이오프를 확정하고 스레드가 적합한지 확인하세요

• 하나의 아이디어 — 단일 포인트나 이야기. 여러 개가 있다면 하나를 선택하거나 별도 스레드를 계획하세요.
• 페이오프 — 독자가 끝까지 읽고 얻는 것 (교훈, 목록, 결과).
• 스레드인가 단일 포스트인가? 아이디어가 진정으로 여러 비트를 필요로 하는 경우에만 스레드를 사용하세요. 단일 포스트에 들어맞는다면, 강력한 단일 포스트가 억지로 만든 스레드보다 거의 항상 낫습니다. references/platform-and-when.md를 참조하세요.

2단계 — 오프너 쓰기 (훅 + 약속)

포스트 1에는 hook-writer를 사용하세요. 오프너는 동시에 두 가지 작업을 수행해야 합니다: 실제 메커니즘으로 훅을 걸고, 페이오프를 약속해야 합니다 ("여기 우리가 한 방법이 있습니다," "7가지 교훈," "어떻게 고장 났는지에 대한 이야기"). 오프너는 또한 그 자체로 강력한 포스트로 독립할 수 있어야 합니다. 왜냐하면 그것이 리쉐어되기 때문입니다. 느린 시작은 금물입니다. references/post-craft.md를 참조하세요.

3단계 — 스레드 구조 설계하기

아이디어에 맞는 구조(목록형, 이야기형, 논증형, 방법형, 분석형)를 선택하고 스파인을 개요로 작성하세요: 오프너의 약속과 그 약속을 이행하는 순서화된 포스트들. 스파인은 스레드를 쪼개진 기사가 아니라 응집력 있게 만드는 요소입니다. 포스트 하나에 하나의 아이디어. references/architecture.md를 참조하세요.

4단계 — 본문 포스트 쓰기

각 포스트: 포인트를 앞에 배치하고, 하나의 비트를 전달하며, 플랫폼의 문자 제한을 준수하고, 다음 포스트로 끌어당기세요 (미니 훅, 번호 단계, "하지만 여기 중요한 점이 있습니다"). 채우기나 불필요한 내용이 있는 포스트는 잘라내세요. 모든 포스트를 브랜드 음성으로 유지하세요. references/post-craft.md를 참조하세요.

5단계 — 마무리와 하나의 CTA로 끝내기

마지막 포스트는 페이오프를 전달/요약하고, 목표에 맞고 음성에 맞는 하나의 요청을 합니다. X에서 일반적인 성장 전략은 사람들에게 오프너를 리쉐어해 달라고 요청하는 것입니다("이게 유용했다면 첫 번째 포스트를 RT해 주세요") 및/또는 팔로우. CTA는 하나만. 링크가 있다면 여기나 댓글에 넣으세요.

6단계 — 플랫폼에 맞춰 포맷팅하기

references/platform-and-when.md에서 X와 Threads의 메커니즘(제한, 번호 매기기, 링크, 해시태그)을 적용하세요. 방향 감각에 도움이 되도록 포스트에 번호를 매기세요. 생각 중간에 어색하게 나누지 마세요. 가독성을 위해 포스트 내에서 줄바꿈을 사용하세요.

품질 기준 — 자체 점검

• 오프너가 훅과 약속을 모두 제공하고 리쉐어 가능한 포스트로 독립할 수 있습니까?
• 하나의 아이디어이며, 명확한 스파인이 있습니까? 쪼개진 기사가 아닙니까?
• 모든 포스트가 다음 포스트를 읽게 만듭니까 (모멘텀, 채우기 없음)?
• 각 포스트가 포인트를 앞에 배치하고 플랫폼 제한을 준수합니까?
• 마무리가 페이오프를 전달하고 정확히 하나의 CTA를 포함합니까?
• 브랜드 음성에 맞으며, 적절한 레지스터입니까?
• 이것이 스레드여야 합니까? 아니면 단일 포스트가 더 강력합니까?

어떤 포스트든 독자를 앞으로 끌어당기지 못하면, 전달하기 전에 잘라내거나 다시 쓰세요.

엣지 케이스

• 단일 포스트여야 하는 경우 → 그렇게 말하고 스레드를 억지로 늘리지 말고 강력한 단일 포스트를 작성하세요.
• 여러 아이디어 → 스레드 하나에 하나의 아이디어; 시리즈를 제안하세요.
• 쪼개진 장문 (블로그 글을 쪼개서 "스레드로 만든" 경우) → 하지 마세요. 아이디어를 분해하고 네이티브 스레드로 재구축하세요 (cross-platform-repurposing 참조하여 원본→스레드 흐름 확인).
• Threads (Meta) vs X → 적응하세요: Threads는 더 캐주얼하고, 스레드 문화가 약하며, 500자/포스트입니다. X는 강한 스레드 문화와 오프너 리쉐어 메커니즘이 있습니다. 단일 대화형 Threads 포스트는 threads-post를 사용하세요.
• 진정한 페이오프가 없는 경우 → 아이디어에 실제 테이크어웨이가 없다면 스레드가 아닙니다. 먼저 아이디어를 구체화하세요.
• 민감/규제 대상 → 모든 포스트에 규정 준수 가드레일을 적용하고, 과장된 주장을 하지 마세요.

관련 스킬

• brand-profile, voice-builder — 음성 + 레지스터 + 가드레일.
• hook-writer — 오프너 (및 재훅).
• caption-writer — 단일 포스트/캡션; threads-post — 단일 Meta Threads 포스트 (체인 아님); cross-platform-repurposing — 장문을 스레드로 변환.
• scheduling-and-queue — WoopSocial을 통한 예약. 참고: WoopSocial은 단일 포스트만 게시합니다 (네이티브 멀티 포스트 체인 불가). 따라서 오프너를 예약하고 나머지 체인은 네이티브/수동으로 게시하세요.

참조

• references/architecture.md — 스레드 구조, 스파인, 포스트당 하나의 아이디어, 길이.
• references/post-craft.md — 오프너 공식, 포스트 단위, 전환, 마무리 + CTA.
• references/platform-and-when.md — X 대 Threads 메커니즘, 그리고 스레드를 사용하지 말아야 할 때.
• references/examples.md — 완전히 작성된 예제 스레드 (목록형 및 이야기형), 음성 일치.