기술 블로그 주제를 꾸준히 확보하는 방법

블로그를 꾸준히 쓰는 사람들은 글을 잘 쓰는 게 아니라 주제를 꾸준히 모으는 사람들이라는 걸 나중에야 알았다. 뭔가를 해결했을 때, 찾는 데 오래 걸렸을 때, 처음 알았을 때 — 그 순간에 적어두지 않으면 흔적도 없이 사라진다.

주제는 문제를 해결한 직후에 잡는다

에러 메시지와 씨름하다 해결책을 찾은 직후가 글 주제를 포착하기 가장 좋은 순간이다. "이거 나중에 정리해야지"는 거의 안 된다. 그 자리에서 짧게라도 제목 후보를 적어둔다.

나는 ~/notes/blog-queue.md 파일을 하나 두고, 터미널이나 에디터를 쓰다가 메모할 게 생기면 바로 줄 하나를 추가한다.

# 블로그 주제 큐
- certbot --dry-run 왜 실패하는지 (DNS 안 잡혔을 때 증상)
- PM2 cluster 모드와 fork 모드 차이
- SQLite busy_timeout 설정으로 SQLITE_BUSY 줄이기
- Next.js generateMetadata에서 params를 못 받는 경우

한 줄짜리 메모여도 나중에 보면 무슨 상황이었는지 기억이 떠오른다.

잘 되는 글의 공통점

검색해서 들어오는 글은 대부분 "구체적인 에러 상황 + 해결 방법" 형태다. 추상적인 정리보다 "이 에러 메시지가 떴을 때 뭘 했는지"가 더 잘 검색된다.

• SQLITE_BUSY: database is locked 에러를 WAL 모드로 해결한 과정
• certbot 갱신이 Connection refused 로 실패할 때 원인 파악
• PM2 restart가 계속 반복될 때 에러 로그 보는 법

반면 "X를 쓰는 이유 5가지" 같은 글은 쓰기는 쉬운데 검색에서는 잘 안 잡힌다.

초안이 거칠어도 일단 완성한다

한 주제를 깔끔하게 다듬으려다 결국 안 올리는 경우가 많았다. 지금은 "이 정도면 나 같은 상황인 사람에게 도움이 되겠다"는 기준으로 올린다. 100% 완성된 글보다 실제로 올라간 80% 글이 낫다.

코드 스니펫이 있고, 내가 겪은 상황과 해결 방법이 명확하면 충분하다. 서론을 길게 쓰거나 결론을 요약할 필요 없다.

주제가 안 떠오를 때

• 최근 PR 목록을 훑어본다. 해결한 이슈 중 설명하기 복잡했던 것.
• 팀원이나 커뮤니티에서 비슷한 질문이 반복되는 주제.
• 공식 문서에는 있는데 예제가 없어서 직접 삽질한 부분.

"이미 다른 사람이 쓴 주제"라서 안 쓰는 건 이유가 안 된다. 내가 겪은 구체적인 상황은 다른 사람 글과 겹치지 않는다.