5초 요약
처음에는 "글을 많이 만들 수 있으면 이긴다"고 생각합니다.
그런데 글 만들기를 자동화하고, 공개, 품질 검사, 번역, 검색엔진에 새 글 알리기, 검색 로봇 방문 확인, 방문자 수 세기, 다음 글로 넘어가게 하기, 공유, 수익까지 한 줄로 이으면 게임의 정체가 바뀝니다.
글을 쓰는 게임이 아니라, 개선하는 과정 자체를 키우는 게임이 됩니다.
게다가 귀찮은 점이 있습니다. 하나를 고치면 다음 약점이 보입니다.
고칩니다.
또 보입니다.
또 고칩니다.
어느새 사이트 운영이 아니라 끝나지 않는 육성 게임을 켜 놓은 셈이 됩니다.
1. 원래는 "글 쓰기"만으로 체력이 다 닳는다
혼자 사이트를 운영하면 글 한 편에도 할 일이 많습니다.
소재를 찾고, 조사하고, 목차를 짜고, 쓰고, 이미지를 준비하고, 오타를 고치고, 올리고, SNS에 공유하고, 숫자를 봅니다.
여기까지 했으면 사람으로서는 충분합니다.
"다음엔 검색엔진별, 언어별로 검색 로봇 방문을 살펴보자"는 말이 나오기 전에 보통 저녁 먹을 시간이 됩니다.
그래서 드문 것은 검색 노출 관리, 번역, 방문 분석, SNS, 자동화 같은 낱개 기술이 아닙니다. 이런 것들은 예전부터 있었습니다.
드문 것은 이 모든 것을 하나의 끊기지 않는 순환으로 이어 놓는 일입니다.
2. 공개는 도착점이 아니라 중간 정거장이었다
글을 올리면 해냈다는 기분이 듭니다.
하지만 검색으로 오는 방문자 입장에서 공개는 "파일이 생겼다"는 뜻일 뿐입니다.
구글은 사이트맵이 주소(URL)를 찾는 데 도움은 되지만, 거기 적힌 모든 주소를 크롤링하거나 색인에 넣는다고 약속하지는 않는다고 분명히 밝히고 있습니다. [1]
즉 길은 이렇게 깁니다.
공개 → 발견됨 → 검색 로봇이 방문함 → 색인에 들어감 → 검색 결과에 나옴 → 클릭됨 → 읽힘 → 다음 글로 이동 → 다시 찾아옴
"올렸으니 끝"이라는 말은 역 개찰구를 지난 순간 "여행 끝"이라고 하는 것과 같습니다.
3. 자동화하면 게임의 규칙이 바뀐다
사람이 한 편씩 쓰는 세상에서는 성과를 늘리는 주된 방법이 "한 편 더 쓰기"입니다.
하지만 글 만들기가 자동화되면 사람이 쓰는 시간의 가치가 달라집니다.
글 한 편을 더 넣는 것보다 이런 일이 더 잘 먹힐 때가 있습니다.
- 모든 글의 관련 글을 개선한다
- 모든 글의 제목 카드를 개선한다
- 모든 글의 사이트맵을 바르게 한다
- 새 주소와 바뀐 주소를 자동으로 알린다
- 언어별 방문 차이를 잰다
- 공개 실패를 자동으로 알아낸다
이유는 한 번 고친 것이 수백, 수천 편에 한꺼번에 퍼지기 때문입니다.
힘의 중심이 글을 만드는 능력에서 글 전체에 지렛대를 거는 능력으로 옮겨 갑니다.
4. 개선하면 다음 병목이 보인다
이 게임이 끝나지 않는 가장 큰 이유입니다.
처음에는 "글이 적다"가 문제로 보입니다.
그래서 늘립니다.
그러면 "글은 있는데 열리지 않는다"가 보입니다.
카드를 고칩니다.
그러면 "열리지만 다음 글로 가지 않는다"가 보입니다.
이동 경로를 고칩니다.
그러면 "읽히는데 검색에서 사람이 안 온다"가 보입니다.
검색을 고칩니다.
그러면 "검색에는 나오는데 언어마다 차이가 크다"가 보입니다.
알리는 방법을 고칩니다.
즉 개선은 문제를 없애는 데서 끝나지 않습니다.
다음 문제를 눈에 보이게 만듭니다.
보스를 쓰러뜨리면 엔딩이 나오는 게 아니라 지도의 안개가 걷히고 다음 던전이 나타나는 방식입니다.
5. 한 번의 수정이 모든 글에 먹히면 복리처럼 불어난다
글 한 편씩 고치는 것은 더하기에 가깝습니다.
한 편을 고치면 한 편이 좋아집니다.
반면 공통 시스템을 고치는 것은 곱하기에 가깝습니다.
예를 들어 이런 공통 부품을 고치면 이미 있는 글과 앞으로 쓸 글에 모두 효과가 있습니다.
- 내부 링크 만들기
- 추천 방식
- 언어별 템플릿
- 메타데이터(검색엔진에 알려 주는 페이지 정보)
- 구조화 데이터
- 사이트맵
- 공개 후 확인
- 클릭 측정
- 공유 대기열
글이 늘수록 공통 기반을 한 번 고치는 가치도 커집니다.
그래서 어느 시점부터는 "글을 쓰는 것"보다 "모든 글에 효과가 있는 것을 고치는 것"이 더 재미있어집니다.
완전한 기술 트리의 함정입니다.
6. 이건 "글 자동화"보다 "미디어 운영체제"에 가깝다
단순한 글 자동화라면
입력 → 글 생성 → 공개
에서 끝납니다.
하지만 운영이 이어지면
기획 → 집필 → 품질 검사 → 번역 → 공개 → 실제 사이트 확인 → 사이트맵 → 검색엔진에 알림 → 검색 로봇 관찰 → 색인과 방문 측정 → 이동 경로 개선 → SNS·뉴스레터 공유 → 수익화 → 데이터로 다음 개선
이 됩니다.
여기까지 오면 글 자동 생성기라기보다 작은 미디어 운영체제입니다.
글은 앱이 아닙니다.
운영체제 위를 흐르는 데이터가 됩니다.
7. "일주일도 안 돼서 여기까지"가 이상하게 빨라 보이는 이유
속도의 정체는 타자 속도가 아닙니다.
기다리는 시간이 사라진 것입니다.
보통은
아이디어 → 회의 → 요구사항 정리 → 우선순위 → 개발 대기 → 개발 → 테스트 → 배포 → 몇 주 뒤 분석
이 되기 쉽습니다.
AI 도움과 자동화된 배포 경로가 있으면
떠올린다 → 명세를 쓴다 → 만든다 → 검사한다 → 실제 사이트에 올린다 → 지켜본다 → 다음 개선
을 훨씬 짧게 돌릴 수 있습니다.
DORA의 연구에서도 작은 단위의 변경, 지속적인 배포, 모니터링, 빠른 피드백이 중요한 역량으로 정리되어 있습니다. [3]
그러니 정말로 줄어든 것은 "작업 시간"만이 아닙니다.
피드백이 돌아오기까지의 시간입니다.
8. 다만 AI가 빠르기만 하면 그냥 터진다
여기가 중요합니다.
AI가 코드도 글도 빨리 만든다고 해서, 그대로 대량으로 쏟아붓는다고 이기지는 않습니다.
빨리 만든다는 건 버그도 빨리 만든다는 뜻입니다.
그래서 속도를 가치로 바꾸려면 이런 바탕이 필요합니다.
- 작게 바꾼다
- 테스트한다
- 실제 사이트를 읽어 본다
- 실패를 지켜본다
- 되돌릴 수 있게 한다
- 기준이 되는 원본을 하나로 둔다
- "됐을 거야"가 아니라 증거를 본다
DORA도 AI를 도입한다고 소프트웨어 배포가 저절로 좋아지지는 않으며, 작은 단위의 변경과 탄탄한 테스트 같은 기본이 중요하다고 말합니다. [3]
액셀을 크게 만들었다면 브레이크와 계기판도 크게 만들어야 합니다.
9. 검색엔진까지 넣으면 더더욱 끝나지 않는다
공개한 뒤에는 검색엔진이라는 또 다른 세계가 있습니다.
사이트맵을 만듭니다.
바뀐 주소를 알립니다.
IndexNow는 추가, 수정, 삭제된 주소를 검색엔진에 알리는 방식이며, 공식 문서는 내용을 바꾼 뒤 자동으로 보내라고 권합니다. [2]
그런데 알렸다고 검색 결과에 나오는 것은 아닙니다.
그래서 다음에는 이것들을 따로 봅니다.
- 알림이 갔는가
- 검색 로봇이 왔는가
- 색인에 들어갔는가
- 검색 결과에 노출됐는가
- 클릭됐는가
여러 언어라면 이것이 언어 수만큼 늘어납니다.
검색엔진도 하나가 아닙니다.
네, 스킬 트리가 세 페이지 더 늘었습니다.
10. 12개 언어로 하면 "사이트 하나"가 12개의 시장이 된다
여러 언어의 재미있는 점은 번역으로 끝나지 않는다는 것입니다.
같은 글이라도 나라마다 이런 것이 다릅니다.
- 검색엔진 점유율
- SNS 쓰는 방식
- 클릭을 부르는 제목
- 독자가 기대하는 설명의 양
- 수익이 나는 길
- 다시 찾아오는 경로
그래서 "12개 언어 지원"은 콘텐츠 하나를 12번 복사하는 일이 아닙니다.
공통 기반 위에서 12개 시장을 운영하는 일에 가깝습니다.
그러면 "왜 일본어만 늘까", "어떤 언어는 검색 로봇이 오는데 왜 안 읽힐까" 같은 새 연구 주제가 저절로 생깁니다.
콘텐츠를 늘렸더니 연구할 거리까지 늘었습니다.
참 친절한 설계입니다. 누구에게 친절한지는 모르겠지만요.
11. 가장 큰 함정은 "고칠 수 있다 = 고쳐야 한다"가 되는 것
끝이 없는 게임에는 위험도 있습니다.
고칠 곳은 영원히 있습니다.
버튼 여백도 고칠 수 있습니다.
로그 이름도 고칠 수 있습니다.
대시보드의 둥근 모서리도 인생이 허락하는 한 고칠 수 있습니다.
하지만
고칠 수 있다는 것과 지금 고칠 가치가 있다는 것은 다릅니다.
먼저 하고 싶은 개선은 이런 것입니다.
- 많은 글과 독자에게 효과가 있다
- 진짜 병목을 푼다
- 효과를 잴 수 있다
- 실패했을 때 알아채고 되돌릴 수 있다
- 앞으로의 개선 속도 자체를 높인다
이 기준이 없으면 "아무도 안 보는 궁극의 아름다운 관리 화면"을 완성하고 만족하게 됩니다.
12. 진짜 자산은 글의 수가 아니라 개선 속도다
글의 수도 물론 자산입니다.
하지만 자동화된 미디어에는 더 중요한 자산이 있습니다.
문제를 찾고, 고치고, 결과를 확인하기까지 걸리는 시간.
이 시간이 짧을수록
잘못을 빨리 버릴 수 있고,
잘 맞은 것을 빨리 넓힐 수 있고,
독자 행동의 변화를 따라갈 수 있고,
검색엔진이나 공유 서비스가 바뀌어도 고칠 수 있습니다.
그러니 오래 가는 강점은 "처음부터 완벽한 사이트"가 아닙니다.
빨리 배우는 사이트에 있습니다.
13. 그리고 사이트 운영은 끝나지 않는 엔드 콘텐츠가 된다
완성의 조건을 "더 고칠 곳이 없다"로 잡으면 평생 완성되지 않습니다.
그래도 괜찮습니다.
완성의 조건을 이렇게 바꿉니다.
- 다음 병목이 보인다
- 고칠 수 있다
- 실제 사이트에서 확인할 수 있다
- 전체가 조금 좋아진다
그러면 끝이 없다는 것 자체가 더는 결함이 아닙니다.
글을 씁니다.
구조를 고칩니다.
숫자가 돌아옵니다.
또 고칩니다.
어제까지 없던 개선안이 오늘의 개선 덕분에 보입니다.
이건 블로그라기보다 스스로 업데이트를 내보내는 경영 시뮬레이션입니다.
게다가 운영자가 자는 동안에도 글은 늘고, 아침에 일어나면 새 병목이 기다립니다.
운영자: "끝은 언제야?"
시스템: "다음 개선 후보를 만들었습니다."
운영자: "그래……"
아마 이것이 가장 올바른 엔드 콘텐츠의 모습일 겁니다.
[1] Google Search Central, “Learn about sitemaps”
https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview
[2] IndexNow.org, “Documentation”
https://www.indexnow.org/documentation
[3] Google Cloud, “DevOps capabilities” / DORA
https://docs.cloud.google.com/architecture/devops
