블로그 주제를 좁히는 법: 독자의 질문과 글감 중복 점검
질문 카드와 글감 지도로 주제를 구체화하고 비슷한 글을 통합하는 기준을 설명합니다.
‘개발 이야기’처럼 범위가 넓은 주제는 글을 계속 만들기 쉽지만, 독자가 어느 글을 읽어야 하는지는 모호해집니다. 먼저 한 사람이 해결하려는 질문을 적고, 그 질문에 필요한 설명이 한 글 안에 들어가는지 확인해 보세요. 아래는 개인 기술 블로그를 위한 편집 예제입니다.
글감 대신 질문 카드를 만들기
각 카드에 독자, 막힌 상황, 읽은 뒤 할 수 있는 행동, 필요한 근거를 적습니다.
| 항목 | 모호한 기획 | 범위를 정한 기획 |
|---|---|---|
| 독자 | 모든 개발자 | Python으로 작은 API를 운영하는 사람 |
| 질문 | 성능을 높이는 법 | 목록 조회마다 같은 ID 검색이 반복되는 이유 |
| 결과 | 성능 이해 | list와 dict 중 어떤 구조를 쓸지 판단 |
| 근거 | 일반적인 장점 | 중복 키 예제와 반복 검색 코드 |
카드만 읽고도 필요한 예제를 떠올릴 수 없으면 아직 주제가 넓은 것입니다. ‘최적화의 중요성’ 같은 문장을 더 쓰기 전에 범위를 줄입니다.
같은 답을 하는 글은 합치기
제목에서 키워드를 지운 뒤 목차와 결론을 비교합니다. 캐시의 필요성, 캐시의 장점, 캐시의 함정이라는 세 글이 모두 ‘상황에 맞게 쓰자’로 끝나면 하나의 글에서 데이터 신선도와 무효화 사례를 다루는 편이 독자에게 낫습니다.
반대로 HTTP 캐시 설정과 Redis 장애 복구처럼 입력 조건과 실행 절차가 달라지면 분리할 이유가 있습니다. 분리 기준은 검색 키워드 수보다 독자의 작업 단위입니다. 통합할 때는 기존 주소에서 가장 관련 있는 글로 연결하고, 관련 없는 글을 전부 홈페이지로 보내지는 않습니다.
근거가 있는 유형으로 제목 정하기
실제 제품을 사용한 기록이 있으면 사용기로, 공식 자료를 비교했다면 비교 안내로, 가상 데이터로 설명했다면 예제로 명확히 씁니다. 사용 기간이나 측정값이 없는데 ‘직접 써본 최고의 도구’라고 쓰면 제목이 본문보다 큰 약속을 하게 됩니다.
제목 후보가 ‘데이터 구조 하나로 성능이 뒤집힌다’라면 ‘Python 목록 검색을 dict로 바꾸기 전에 확인할 조건’으로 바꿀 수 있습니다. 후자는 독자가 무엇을 확인할지 알려주고 모든 경우에 빨라진다는 오해도 줄입니다.
발행 전 다른 글과 나란히 읽기
첫 문단, 핵심 예제, 결론을 나란히 놓고 비교합니다. 주제명만 바꿔 다른 글에 붙여도 자연스러운 문단은 삭제하거나 구체적인 조건으로 바꿉니다. 출처를 붙였더라도 자료 요약만 있다면 직접 만든 비교표나 재현 가능한 사례를 보완합니다.
완료 기준은 정해진 글자 수가 아니라 질문에 답했는지입니다. 다음 행동, 실패할 조건, 근거까지 설명했다면 의미 없는 문단으로 길이를 늘리지 않습니다. 발행 뒤 오류가 발견되면 수정 내역과 수정일을 남기고, 내용이 그대로라면 날짜만 새롭게 바꾸지 않습니다.