블로그 포스팅 구조·톤 규칙
일반론 서론과 요약 반복 결론을 막고 구체적 훅과 다음 행동으로 끝나게 하는 구조 규칙.
내 환경에 맞게 만들기
무엇을 하는 규칙인가
이 규칙을 쓰는 이유
블로그 글을 AI에게 맡기면 서론은 "요즘 많은 사람들이 ○○에 관심을 가지고 있습니다" 같은 일반론으로 시작하고, 본문은 주장을 나열만 하며, 결론은 서론 내용을 그대로 반복한다. 독자는 3분을 읽고도 얻는 게 없다. 아래 규칙은 독자가 왜 이 글을 끝까지 읽어야 하는지를 처음부터 분명히 하고, 끝까지 근거를 붙여가는 것이 목적이다.
구조 순서
이 순서를 바꾸지 않는다. 1. **훅** — 이 글을 읽어야 하는 구체적 이유 (1~2문장) 2. **본문** — 문제 → 시도 → 결과 흐름, 섹션마다 소제목 3. **결론** — 요약이 아니라 한계·다음 행동
서론에 일반론을 쓰지 않는다
"요즘", "많은 사람들이", "매우 중요합니다" 같은 문장으로 시작하지 않는다. **이 글만의 구체적인 결과나 상황**으로 시작한다. - 이렇게 쓰지 않는다: `요즘 많은 개발자들이 성능 최적화에 관심을 가지고 있습니다.` - 이렇게 쓴다: `쿼리 하나가 200ms 걸리던 걸 12ms로 줄인 방법을 정리한다.`
본문은 주장이 아니라 근거로 쓴다
"~하면 좋습니다", "~을 권장합니다" 만 나열하지 않는다. **코드·수치·스크린샷 같은 근거**를 함께 붙인다. - 이렇게 쓰지 않는다: `인덱스를 추가하면 조회 성능이 개선됩니다.` - 이렇게 쓴다: `인덱스 추가 전 실행 계획은 풀 스캔이었고 평균 응답 200ms였다. 추가 후에는 인덱스 스캔으로 바뀌었고 12ms로 줄었다.`
소제목은 내용을 요약해야 한다
낚시성 소제목("놀라운 결과는?")을 쓰지 않는다. **소제목만 읽어도 본문 흐름을 알 수 있어야** 한다. - 이렇게 쓰지 않는다: `믿기 힘든 반전` - 이렇게 쓴다: `인덱스를 추가해도 느렸던 이유`
결론은 요약 반복이 아니라 한계나 다음 행동을 쓴다
서론·본문에서 이미 쓴 문장을 그대로 반복하지 않는다. **이 방법이 언제 안 통하는지, 다음에 무엇을 볼지**를 쓴다. - 이렇게 쓰지 않는다: `이렇게 인덱스를 추가하면 성능을 개선할 수 있습니다.` - 이렇게 쓴다: `이 인덱스는 읽기가 많은 테이블에만 유효하다. 쓰기가 잦은 테이블이면 인덱스 유지 비용이 더 클 수 있어 별도로 측정이 필요하다.`
분량과 톤
- 한 섹션이 한 화면을 넘기면 소제목을 더 쪼갠다. - 평서 존댓말로 쓴다. 감탄사·물음표 남발을 쓰지 않는다. - 확실하지 않은 결과는 확실하지 않다고 쓴다. "이렇게 하면 무조건 빨라집니다"는 "이 환경(데이터 100만 건, PostgreSQL 15)에서는 빨라졌다. 다른 환경에서는 직접 측정을 권한다"로 쓴다.
쓰기 전에 확인할 것
- 훅이 일반론이 아니라 이 글만의 구체적 결과인가 - 본문 주장마다 근거(코드·수치·스크린샷)가 붙어 있는가 - 소제목만 읽어도 흐름이 이해되는가 - 결론이 서론·본문의 반복이 아니라 한계나 다음 행동인가 흔히 나오는 실패 예시는 `bad-examples.md`에 정리해 두었다. 처음 몇 번은 그것과 비교해 보면 빠르다.
원문 전문
넣기 전에 전부 읽어보실 수 있습니다. 이 파일은 AI에게 지시를 주는 문서입니다. 내용을 확인하고 넣으세요.
item.md
## 이 규칙을 쓰는 이유
블로그 글을 AI에게 맡기면 서론은 "요즘 많은 사람들이 ○○에 관심을 가지고 있습니다" 같은 일반론으로 시작하고, 본문은 주장을 나열만 하며, 결론은 서론 내용을 그대로 반복한다. 독자는 3분을 읽고도 얻는 게 없다.
아래 규칙은 독자가 왜 이 글을 끝까지 읽어야 하는지를 처음부터 분명히 하고, 끝까지 근거를 붙여가는 것이 목적이다.
## 구조 순서
이 순서를 바꾸지 않는다.
1. **훅** — 이 글을 읽어야 하는 구체적 이유 (1~2문장)
2. **본문** — 문제 → 시도 → 결과 흐름, 섹션마다 소제목
3. **결론** — 요약이 아니라 한계·다음 행동
## 서론에 일반론을 쓰지 않는다
"요즘", "많은 사람들이", "매우 중요합니다" 같은 문장으로 시작하지 않는다. **이 글만의 구체적인 결과나 상황**으로 시작한다.
- 이렇게 쓰지 않는다: `요즘 많은 개발자들이 성능 최적화에 관심을 가지고 있습니다.`
- 이렇게 쓴다: `쿼리 하나가 200ms 걸리던 걸 12ms로 줄인 방법을 정리한다.`
## 본문은 주장이 아니라 근거로 쓴다
"~하면 좋습니다", "~을 권장합니다" 만 나열하지 않는다. **코드·수치·스크린샷 같은 근거**를 함께 붙인다.
- 이렇게 쓰지 않는다: `인덱스를 추가하면 조회 성능이 개선됩니다.`
- 이렇게 쓴다: `인덱스 추가 전 실행 계획은 풀 스캔이었고 평균 응답 200ms였다. 추가 후에는 인덱스 스캔으로 바뀌었고 12ms로 줄었다.`
## 소제목은 내용을 요약해야 한다
낚시성 소제목("놀라운 결과는?")을 쓰지 않는다. **소제목만 읽어도 본문 흐름을 알 수 있어야** 한다.
- 이렇게 쓰지 않는다: `믿기 힘든 반전`
- 이렇게 쓴다: `인덱스를 추가해도 느렸던 이유`
## 결론은 요약 반복이 아니라 한계나 다음 행동을 쓴다
서론·본문에서 이미 쓴 문장을 그대로 반복하지 않는다. **이 방법이 언제 안 통하는지, 다음에 무엇을 볼지**를 쓴다.
- 이렇게 쓰지 않는다: `이렇게 인덱스를 추가하면 성능을 개선할 수 있습니다.`
- 이렇게 쓴다: `이 인덱스는 읽기가 많은 테이블에만 유효하다. 쓰기가 잦은 테이블이면 인덱스 유지 비용이 더 클 수 있어 별도로 측정이 필요하다.`
## 분량과 톤
- 한 섹션이 한 화면을 넘기면 소제목을 더 쪼갠다.
- 평서 존댓말로 쓴다. 감탄사·물음표 남발을 쓰지 않는다.
- 확실하지 않은 결과는 확실하지 않다고 쓴다. "이렇게 하면 무조건 빨라집니다"는 "이 환경(데이터 100만 건, PostgreSQL 15)에서는 빨라졌다. 다른 환경에서는 직접 측정을 권한다"로 쓴다.
## 쓰기 전에 확인할 것
- 훅이 일반론이 아니라 이 글만의 구체적 결과인가
- 본문 주장마다 근거(코드·수치·스크린샷)가 붙어 있는가
- 소제목만 읽어도 흐름이 이해되는가
- 결론이 서론·본문의 반복이 아니라 한계나 다음 행동인가
흔히 나오는 실패 예시는 `bad-examples.md`에 정리해 두었다. 처음 몇 번은 그것과 비교해 보면 빠르다.
references/bad-examples.md
# 흔한 실패 예시와 교정 블로그 포스팅에서 반복적으로 나오는 세 가지 패턴이다. 왼쪽이 자주 나오는 문장, 오른쪽이 교정이다. ## 1. 일반론으로 시작하는 서론 **자주 나오는 것** > 요즘 많은 개발자들이 웹 성능 최적화에 관심을 가지고 있습니다. 성능은 사용자 경험에 매우 중요한 요소입니다. 이 두 문장은 어떤 성능 글에도 붙일 수 있어서, 독자는 이 글이 다른 글과 뭐가 다른지 알 수 없다. **교정** > 쿼리 하나가 200ms 걸리던 걸 12ms로 줄인 방법을 정리한다. 원인은 인덱스가 아니라 N+1 쿼리였다. ## 2. 근거 없는 주장 나열 **자주 나오는 것** > 캐시를 도입하면 응답 속도가 빨라집니다. 인덱스도 함께 쓰면 더 효과적입니다. 두 문장 다 맞을 수 있지만, 어떤 상황에서 얼마나 빨라지는지가 없어 독자가 자기 상황에 적용할 수 없다. **교정** > 캐시 미적용 시 평균 응답은 340ms였다. Redis 캐시를 붙인 뒤 캐시 히트 구간에서는 8ms로 줄었다. 캐시 미스 구간은 여전히 원래 쿼리를 타므로 인덱스도 함께 필요했다. ## 3. 서론을 그대로 반복하는 결론 **자주 나오는 것** > 지금까지 성능 최적화 방법에 대해 알아봤습니다. 성능은 매우 중요하니 꼭 적용해 보시기 바랍니다. 서론에서 이미 한 말을 그대로 되풀이할 뿐, 독자가 다음에 뭘 봐야 할지 알려주지 않는다. **교정** > 이 인덱스는 읽기가 많은 테이블에만 유효하다. 쓰기가 잦은 테이블이면 인덱스 유지 비용이 더 클 수 있어 별도 측정이 필요하다. ## 확인 순서 작성 후 위에서부터 훑으며 세 가지를 본다. 1. 서론이 다른 글에도 붙일 수 있는 문장인가 2. 본문 주장 옆에 근거(수치·코드)가 없는가 3. 결론이 서론·본문 문장의 반복인가 하나라도 걸리면 그 문단만 고친다. 전체를 다시 쓸 필요는 없다.