블로그를 만들면서 글쓰기 규칙 같은 걸 정한 적이 없습니다. 그냥 겪은 걸 순서대로 적었습니다.

그런데 얼마 전에 제목 열여덟 개를 한 화면에 늘어놓고 보다가, 이상하게 비슷하다는 생각이 들었습니다. 그래서 세어봤습니다.

제목에 없는 단어들

먼저 흔히 쓰이는 단어부터 찾아봤습니다.

전부 0이었습니다. 방법, 해결, 총정리, 완벽, 가이드, 팁, 추천. 물음표도 하나 없었고요.

의도한 게 아닙니다. 세어보고 알았습니다.

왜 그렇게 됐나 생각해보니 답이 시시했습니다. 제 글이 대부분 해결한 이야기가 아니라 막힌 이야기라서입니다. “컨테이너 재시작 루프 해결 방법”이라고 쓸 수가 없었습니다. 원인을 못 밝히고 우회했으니까요.

쓸 수 없는 단어는 안 쓰게 됩니다. 그게 규칙처럼 굳었습니다.

열다섯 개가 문장으로 끝납니다

제목이 명사로 안 끝나고 “~습니다”, “~더군요”로 끝납니다. 열여덟 개 중 열다섯 개가요.

✗  Docker 컨테이너 재시작 루프 해결 방법
○  로그를 열었더니 같은 줄이 2,900번 있었습니다

차이가 하나 있습니다. 명사구는 내용이 없어도 쓸 수 있는데, 문장은 안 그렇습니다. “해결 방법”이라고 붙여놓고 본문에 별 내용이 없는 글은 흔합니다. 그런데 “같은 줄이 2,900번 있었습니다”라고 써놓으면 본문에 그 2,900번이 나와야 합니다.

제목을 문장으로 쓰면 제목이 그 글에서 실제로 일어난 일이 됩니다. 쓸 게 없으면 문장이 안 나옵니다. 저한테는 이게 일종의 검사 장치가 됐습니다.

다만 이게 약점이기도 합니다

솔직하게 적어두겠습니다. 검색에 약합니다.

“docker 재시작 루프”로 검색하는 사람이 있다고 해봅시다. 제 제목에는 그 단어가 없습니다. 있는 건 “로그를 열었더니 같은 줄이 2,900번”입니다.

세어보고 나서야 이게 눈에 들어왔습니다. 지금은 설명문과 본문 소제목에서 벌충하고 있는데, 충분한지는 모르겠습니다. 당분간 신경 써서 지켜볼 생각입니다.

첫 문장은 결론이 아니라 상황입니다

실제 첫 문장들입니다.

휴대폰으로 글 목록을 열었다가 이상한 걸 봤습니다.

서치 콘솔에 사이트를 등록하고 며칠 뒤에 페이지 색인 리포트를 열었습니다.

git을 이번에 처음 설치했습니다.

댓글 서버를 NAS에 올리는 중이었습니다.

전부 그때 뭘 하고 있었는지로 시작합니다. “이 글에서는 ~을 다룹니다” 같은 문장이 하나도 없습니다.

요약으로 시작하면 두 번째 문단을 읽을 이유가 없어집니다. 상황으로 시작하면 다음 줄이 궁금해지고요. 이것도 세어보고 알았습니다.

뼈대가 같습니다

소제목을 나란히 놓고 보니 순서가 거의 똑같았습니다.

증상 → 엉뚱한 의심 → 진짜 원인 → 고친 것 → 남은 것.

여기서 중요한 건 두 번째입니다. 엉뚱하게 의심했던 걸 안 빼는 것.

결과만 적으면 공식 문서와 똑같아집니다. 공식 문서는 이미 있고 저보다 정확합니다. 제가 보탤 수 있는 건 거기까지 가는 데 잘못 든 길입니다. rss.xml이 중복이라는 보고를 받고 RSS 코드를 한참 들여다봤다는 이야기요. 그게 남의 시간을 아껴주는 부분이라고 생각합니다.

절반 넘는 글에 실패가 적혀 있습니다

이것도 세어봤습니다.

패턴	편수
원인을 끝내 못 밝힘	3
“솔직히”로 시작하는 고백	4
알고 보니 제가 쓴 코드가 문제	4
제가 틀렸거나 잘못 읽었음	3
결과를 아직 모름	5
원인을 모른 채 우회함	2

겹치는 것도 있지만, 합치면 절반이 넘습니다.

비율을 맞춘 게 아니라 그냥 사실이 그랬습니다. 다만 안 적을 수도 있었는데 적었다는 건 선택입니다.

원인을 모르고 우회한 걸 적어두면 다음에 같은 자리에서 막혔을 때 뭘 건너뛰었는지 압니다. “이유는 모르겠지만 이거 지우니까 되네”로 끝내면 반년 뒤에 똑같이 막힙니다.

숫자로 본 나머지

• 소제목 평균 6.8개 (최소 5, 최대 10)
• 본문 평균 3,848자 (최소 3,043, 최대 5,388)
• 코드 블록 평균 6.7개
• 도식 대표 이미지 1장 + 본문 1~2장
• 문서 원문을 그대로 인용한 글 6편

마지막 항목이 제 나름의 규칙입니다. 남의 문서를 요약하지 않고 그대로 옮깁니다. 제 말로 바꾸면 “제가 그렇게 읽었다”가 되지만, 원문을 그대로 두면 독자가 직접 판단할 수 있습니다. 제가 잘못 읽었을 수도 있으니까요.

실제로 그런 적이 있습니다. 예약 실행이 60일 만에 꺼진다는 이야기를 옮기려다 원문을 찾아보니 “공개 저장소에서”라는 조건이 붙어 있었습니다. 요약본만 봤으면 그냥 넘어갔을 겁니다.

코드는 돌려본 버전만 적습니다

이건 세어보기 전부터 의식하던 거라 규칙이라고 부를 만합니다.

git clone --depth 1 --branch v1.16.4 ...

남의 글을 읽을 때 제일 답답했던 게 어느 버전 이야기인지 모르겠는 코드였습니다. 그대로 따라 했는데 안 되고, 그게 내 실수인지 버전 차이인지 알 방법이 없습니다.

그래서 설정값이나 코드 조각을 적을 때는 제가 실제로 돌려본 버전을 같이 적습니다. 나중에 안 맞게 되더라도 읽는 사람이 “아, 이건 그때 버전 얘기구나” 하고 판단할 수 있으니까요.

정리

세어보고 나서 든 생각은 이겁니다.

규칙은 만들어서 지키는 게 아니라, 지키고 나서 발견하는 것 같습니다. 저는 “제목을 문장으로 쓰자”고 정한 적이 없습니다. 쓸 수 있는 말이 그것뿐이어서 그렇게 됐고, 열여덟 개가 쌓이고 나서야 보였습니다.

그리고 세어보는 게 중요합니다. 제목이 검색에 약하다는 것도 세어보기 전에는 몰랐습니다. 감으로는 “나는 정직하게 쓰고 있다” 정도만 알고 있었는데, 숫자로 보니 강점과 약점이 같은 데서 나오고 있었습니다.

블로그를 몇 편 쓰신 분이라면 한 번 늘어놓고 세어보시길 권합니다. 십 분이면 됩니다. 저는 grep 몇 줄이었습니다.

참고한 문서

• Google 검색 센터 — 검색결과의 제목 링크 — 제목 말고 소제목도 참고한다는 점
• GitHub 문서 — 워크플로 비활성화와 활성화 — 60일 규칙의 “공개 저장소에서” 조건