하루 15편으로 잡아 두었던 발행량을 10편으로 줄였습니다. 못 채워서가 아니라, 채우려면 글이 나빠지는 게 보여서입니다. 그 판단 과정을 적습니다.
숫자가 먼저 정해져 있었다
처음에 하루 15편, 다섯 종류를 각각 3편씩으로 정했습니다. 계산은 맞았습니다. 문제는 종류마다 재료가 나오는 속도가 다르다는 것이었습니다.
직접 만든 것에 대한 글은 만든 만큼 나옵니다. 개념을 설명하는 글도 다룰 게 많습니다. 그런데 새 소식은 제가 만들어 낼 수 없습니다. 나온 만큼만 있습니다.
채우려고 하니 이렇게 됐다
소식 칸 세 개를 매일 채우려니 방법은 몇 가지뿐이었습니다.
- 중요하지 않은 발표를 중요한 것처럼 쓴다
- 이미 쓴 주제를 각도만 틀어 다시 쓴다
- 확인 안 된 이야기를 소식처럼 쓴다
셋 다 읽는 사람을 속이는 쪽입니다. 숫자를 지키려고 이걸 하면, 숫자를 지킨 의미가 없어집니다.
그래서 줄였다
10편으로 줄이고 종류마다 2편씩으로 바꿨습니다. 그리고 한 줄을 같이 적어 뒀습니다.
“그날 쓸 만한 소식이 없으면 소식은 덜 낸다.”
10편도 상한이지 목표가 아닙니다. 재료가 없으면 8편이어도 됩니다.
한 가지 더 바꾼 것
종류를 하루 안에 섞도록 했습니다. 전에는 비슷한 글이 몰려서 올라갔습니다. 아침에 들어온 사람과 저녁에 들어온 사람이 전혀 다른 인상을 받습니다.
이제는 소식, 기록, 해설, 리뷰가 번갈아 나오게 시각을 배치합니다. 몇 시에 들어와도 이 블로그가 뭘 다루는지가 보입니다.
줄이면서 알게 된 것
양을 정해 두면 그 양이 기준이 됩니다. 15편이 기준이면 “오늘 15편 채웠나”가 질문이 됩니다. 그 질문에는 글이 좋았는지가 안 들어 있습니다.
줄이는 것도 결정입니다. 못 해서 줄이는 것과, 안 하기로 정하고 줄이는 것은 다릅니다.
검색 쪽 공식 기준과 맞춰 보면
Google 검색 센터의 “도움이 되고 신뢰할 수 있는 사람 중심 콘텐츠 만들기” 문서에는 스스로 점검하는 질문이 있습니다. 그중 눈에 띄는 것이 “여러 주제의 콘텐츠를 만들기 위해 광범위한 자동화를 쓰고 있는가”와 “주로 검색 엔진에서 오는 방문을 끌려고 만든 콘텐츠인가”입니다. 같은 문서는 선호하는 단어 수가 따로 없다고도 밝힙니다. 길이나 편수를 채우는 것 자체가 기준이 아니라는 뜻입니다.
| 공식 문서의 관점 | 이 글의 결정에 대응하는 부분 |
|---|---|
| 콘텐츠는 주로 방문자에게 도움이 되도록 만든다 | 그날 쓸 만한 소식이 없으면 소식은 덜 낸다 |
| 이미 있는 내용을 다시 요약하기만 하는 것은 부가 가치가 낮다 | 쓴 주제를 각도만 틀어 다시 쓰지 않는다 |
| 날짜만 바꿔 새것처럼 보이게 하지 않는다 | 소식이 아닌 것을 소식처럼 내지 않는다 |
| 누가, 어떻게, 왜 만들었는지 밝힌다 | 확인된 것과 확인되지 않은 것을 나누어 적는다 |
스팸 정책 문서는 “대규모 콘텐츠 남용”을 검색 순위를 조작하려는 주된 목적으로 많은 페이지를 만드는 것으로 정의하고, 그 방법이 자동화인지 사람인지는 가리지 않는다고 설명합니다. 이 블로그의 하루 편수가 그런 수준이라는 뜻은 아닙니다. 다만 채우기 위한 편수가 기준이 되면 이 경계에 가까워진다는 점에서, 상한을 낮춘 판단은 방향이 맞다고 봅니다. 위 표의 오른쪽 칸은 공식 문서의 문장이 아니라 이 글의 결정을 옆에 놓아 본 것입니다.
Google 공식 블로그의 2024년 3월 검색 업데이트 글도 같은 방향입니다. 이 글에 따르면 Google은 대규모 콘텐츠 남용 정책을 손봐, 자동화로 만들었는지 사람이 만들었는지와 관계없이 검색 순위를 조작하려고 콘텐츠를 대량으로 만드는 행위 자체를 스팸으로 다룹니다. 같은 글은 핵심 순위 업데이트가 도움이 되지 않고 독창적이지 않은, 사람보다 검색엔진을 위해 만든 듯한 콘텐츠를 줄이는 것을 목표로 했다고 설명합니다.
아직 확실하지 않은 것
10편이 맞는 숫자인지는 모릅니다. 몇 주 해 보고 또 조정할 수 있습니다. 지금은 15편이 아니라는 것만 분명합니다.
하루 작업량에서 기록을 늘려 본 기준
하루 분량은 많이 만든 수가 아니라 끝까지 확인한 수로 정했습니다. 그래서 이 기록도 결과만 적어 두지 않고, 다음에 같은 선택을 해야 할 사람이 확인할 순서를 남기는 쪽으로 보강했습니다. 작업마다 조건은 달라도, 무엇을 성공으로 볼지와 어디에서 멈출지를 먼저 정하면 판단이 훨씬 짧아집니다.
특히 화면에 보이는 한 장면만으로 원인을 단정하지 않았습니다. 입력, 실행 중 상태, 최종 결과는 서로 다른 사실입니다. 앞 단계가 정상이어도 다음 단계에서 달라질 수 있으므로, 확인한 사실과 아직 확인하지 못한 범위를 구분해 적는 습관이 필요했습니다.
| 확인 대상 | 기록할 질문 |
|---|---|
| 시작 전 | 무엇을 바꾸며, 원래 상태는 되돌릴 수 있는가 |
| 실행 중 | 어느 조건에서 멈추거나 다른 흐름으로 넘어가는가 |
| 완료 뒤 | 사용자가 실제로 보는 결과까지 확인했는가 |
결과를 바로 믿지 않기 위해
작업이 끝났다는 표시에는 여러 뜻이 섞일 수 있습니다. 저장이 끝난 것일 수도 있고, 화면이 바뀐 것일 수도 있으며, 실제 산출물이 원하는 형식으로 준비됐다는 뜻은 아닐 수도 있습니다. 그래서 확인은 한 번의 표시가 아니라 앞뒤가 이어지는지 보는 과정으로 두었습니다.
- 입력 확인 — 대상과 조건이 의도한 것인지 다시 봅니다.
- 중간 확인 — 진행 표시만 보고 정상이라고 결론 내리지 않습니다.
- 출력 확인 — 파일·화면·표시 중 이 글의 목적에 맞는 결과를 직접 봅니다.
- 경계 확인 — 실패하거나 미확인인 경우를 성공 사례와 섞지 않습니다.
이 순서는 느려 보이지만, 나중에 원인을 찾는 시간을 줄입니다. 재현이 안 되는 문제는 대개 “잘 안 됐다”라는 한 줄만 남았을 때 커집니다. 반대로 어느 단계까지는 맞았는지가 남아 있으면, 다음 시도는 처음부터 다시 하지 않아도 됩니다.
다음 작업에서 같은 판단을 쓰는 방법
이 글의 상황을 모든 작업에 그대로 적용할 수는 없습니다. 다만 판단의 뼈대는 옮길 수 있습니다. 바꾸려는 대상, 실패로 볼 신호, 끝난 뒤 확인할 화면을 각각 한 문장으로 적으면, 도구나 환경이 바뀌어도 확인 순서는 유지됩니다.
| 상황 | 바로 하기 쉬운 판단 | 남겨야 할 판단 |
|---|---|---|
| 한 번 통과함 | 항상 해결됐다고 봄 | 통과한 조건과 확인 범위를 함께 적음 |
| 오류가 남 | 원인을 하나로 단정함 | 입력·실행·결과 중 어느 단계인지 나눔 |
| 수정을 시작함 | 현재 상태를 덮어씀 | 되돌릴 기준과 비교 지점을 남김 |
이 기준은 화려한 방법론이 아니라, 같은 일을 두 번 겪지 않기 위한 메모 방식입니다. 다음 사람이 아니라 다음의 나 자신이 읽어도 이해할 수 있게, 관찰한 사실과 선택한 이유를 붙여 두는 것이 핵심입니다.
마무리할 때 확인한 항목
완료 보고를 짧게 하더라도 아래 항목은 남겨 두는 편이 좋았습니다. 숫자나 성능처럼 조건에 따라 바뀌는 값은 이번 기록에서 확인된 범위를 넘겨 일반화하지 않았습니다. 확인하지 못한 부분은 빈칸으로 두는 편이 그럴듯한 설명을 덧붙이는 것보다 낫습니다.
- 바꾼 것 — 무엇을 왜 바꿨는지 한 문장으로 설명할 수 있는가
- 확인한 것 — 실제로 본 결과와 확인 방법이 구분되어 있는가
- 남은 것 — 아직 검증하지 않은 조건을 성공으로 포장하지 않았는가
- 다음 행동 — 같은 문제가 나면 어디부터 다시 볼지 정했는가
이 글의 사건은 여기서 끝나지만, 판단 기준은 다음 작업으로 이어집니다. 작은 작업일수록 기록을 생략하기 쉽습니다. 그러나 작은 기준 하나가 쌓이면, 나중에는 문제를 더 빨리 설명하고 더 조심스럽게 고칠 수 있습니다.
기록을 다시 읽을 때의 질문
작업 기록은 그날의 메모로 끝나지 않습니다. 시간이 지난 뒤 다시 읽으면, 당시에는 당연했던 전제가 빠져 있는 경우가 많습니다. 그래서 결과 문장만 남기기보다 “어떤 조건에서 이 판단을 했는가”를 함께 적었습니다. 이 한 줄이 없으면 같은 결과를 다른 조건에 무리하게 적용하기 쉽습니다.
예를 들어 어떤 흐름이 한 번 끝까지 진행됐다는 사실은 중요합니다. 하지만 그 사실만으로 모든 입력, 모든 기기, 모든 상황에서 같은 일이 일어난다고 말할 수는 없습니다. 이 글에서도 확인한 범위는 사실로 두고, 범위를 벗어나는 부분은 다음 확인 과제로 남기는 쪽을 택했습니다.
| 다시 읽는 시점 | 확인할 내용 |
|---|---|
| 수정 전 | 원래 문제를 한 문장으로 다시 설명할 수 있는가 |
| 수정 중 | 처방이 원인과 직접 이어지는가 |
| 수정 후 | 처음 정한 성공 기준을 같은 방식으로 확인했는가 |
이 질문은 일을 더 크게 만들기 위한 절차가 아닙니다. 막연한 “잘 됨”과 설명 가능한 “여기까지 확인함”을 가르는 작은 장치입니다. 다음에 비슷한 문제가 생기면 이전 기록을 복사하는 대신, 조건이 같은지부터 대조할 수 있게 됩니다.
재발을 줄이는 작은 규칙
문제가 다시 생기지 않게 하는 가장 현실적인 방법은 복잡한 약속보다 확인 지점을 고정하는 것입니다. 시작 전에는 원래 상태를 남기고, 실행 뒤에는 결과를 직접 보고, 애매한 부분은 애매하다고 표시합니다. 이 세 가지는 도구가 바뀌어도 계속 쓸 수 있습니다.
- 비교 기준 — 바꾸기 전과 뒤를 같은 항목으로 확인합니다.
- 중단 기준 — 예상과 다른 신호가 보이면 다음 단계로 넘기지 않습니다.
- 설명 기준 — 확인한 사실과 추정한 이유를 한 문장에 섞지 않습니다.
이 글을 보강하며 다시 확인한 결론도 같습니다. 완성도는 길게 쓴 말이 아니라, 왜 그렇게 판단했는지 독자가 따라갈 수 있는지에서 나옵니다. 다음 작업에서 이 기준 중 하나라도 다시 쓰일 수 있다면, 이번 기록은 충분히 역할을 한 셈입니다.
확인 자료
- Google 검색 센터: 도움이 되고 신뢰할 수 있는 사람 중심 콘텐츠 만들기 (확인: 2026-10-18)
- Google 검색 센터: 스팸 정책 중 대규모 콘텐츠 남용 (확인: 2026-10-18)
- Google 공식 블로그: 2024년 3월 검색 업데이트와 스팸 정책 (확인: 2026-10-18)