“사고가 날카로운 사람은 작은 위화감을 그냥 넘기지 않는다.”
좋은 말이다.
그런데 그 성향을 콘텐츠 사이트 운영에 가져오면 조금 이상한 일이 벌어진다.
“이 글은 왜 공개가 안 됐지?” “해외 페이지는 왜 이렇게 안 도는 거지?” “새 글 쪽으로 독자가 거의 안 퍼지는데?” “디자인은 꽤 괜찮아졌는데 왜 여기만 막히지?”
이런 “뭔가 이상하다”를 하나씩 쫓다 보면 어느 순간 블로그 글을 쓰는 게 아니라 콘텐츠 공장을 유지보수하고 있다.
콘텐츠 사이트에 대한 조언은 흔히 “글을 많이 써라”, “꾸준히 해라”, “SEO를 공부해라”에서 끝난다.
하지만 대량의 글을 실제로 운영하기 시작하면 문제는 훨씬 산업적으로 변한다.
글을 쓰는 일보다, 글이 생성되고 공개되고 발견되고 읽히고 다른 글로 이어지고 수익으로 연결되는 전체 배관을 만드는 일이 더 무거워진다.
여기까지 오면 새로운 능력을 더 키우고 싶다기보다, 이미 만들어 놓은 능력을 보상이 좀 따라와 줬으면 하는 마음이 든다.
1. 애초에 글 하나가 그냥 큰일이다
“블로그면 글 하나 쓰면 되잖아.”
말은 가볍다.
작업은 전혀 가볍지 않다.
주제를 정한다. 조사한다. 구조를 만든다. 본문을 쓴다. 사실을 확인한다. 제목을 만든다. 이미지를 준비한다. 링크를 넣는다. CMS에 붙인다. 서식을 다듬는다. 모바일 화면을 확인한다. 공개한다. 검색엔진이 찾도록 한다. 접속을 본다. 필요하면 수정한다.
이걸 글마다 반복한다.
제대로 하려고 하면 글 하나에 반나절이나 하루가 사라져도 이상하지 않다.
그리고 가장 무서운 점은 하나 끝내도 다음 글이 기다린다는 것이다.
“수고하셨습니다. 다음 작업물입니다.”
컨베이어 벨트가 멈추지 않는다.
사람이 직접 하는 블로그는 갑자기 공장인데 작업자가 한 명뿐인 구조가 된다.
2. 전통적인 블로그의 진짜 적은 계속 반복되는 변동비다
개인 블로그는 시작만 놓고 보면 비교적 가볍다.
CMS를 설치하고, 테마를 고르고, 디자인을 정리한다.
이런 건 한 번 하면 끝나는 편이다.
문제는 그 뒤다.
글 하나를 만들 때마다 조사, 작성, 편집, 업로드, 확인 비용이 다시 살아난다.
구조적으로 보면,
초기 고정비는 낮지만 글 한 편당 변동비가 높다.
이게 사람을 지치게 한다.
하루 가까이 써서 글을 만들었는데 몇 달이 지나도 월수익이 거의 움직이지 않는다면 그만두고 싶어지는 것은 의지 부족이라고만 볼 수 없다.
들어가는 시간과 돌아오는 돈이 심하게 맞지 않으면 철수는 합리적인 선택일 수 있다.
“계속하는 사람이 이긴다”는 말은 쉽다.
하지만 계속하는 비용 자체가 비싼 구조라면 먼저 구조를 의심할 필요가 있다.
3. 콘텐츠 공장은 비용 구조를 뒤집는다
그래서 발상을 바꾼다.
글을 더 빨리 쓰는 것이 아니라,
글을 만드는 전 과정을 가능한 한 하나의 파이프라인으로 묶는다.
평소의 질문과 대화가 원재료가 된다. 그걸 기사화한다. 개인정보를 제거한다. 구조를 통일한다. 다국어로 만든다. 품질 검사를 한다. GitHub에 넣는다. 공개 파이프라인으로 넘긴다. 검색엔진 발견을 돕는다. 내부 회유와 수익화 동선을 붙인다.
매번 사람이 “오늘은 콘텐츠를 만들자” 하고 앉는 대신, 평소의 사고 자체가 원재료 생산이 된다.
그러면 비용 구조가 뒤집힌다.
초기 고정비는 높아지고, 글 한 편당 변동비는 낮출 수 있다.
처음은 정말 귀찮다.
파이프라인을 만들고, 규칙을 만들고, 검수 구조를 만들고, 공개 경로를 만들고, 망가지면 고친다.
하지만 근본 수리 한 번은 미래의 모든 글에 적용된다.
글 하나에서 두 시간을 줄이는 건 그 글 하나에만 적용된다.
공개 시스템의 근본 버그 하나를 고치면 앞으로 나올 수천 개의 글에 영향을 줄 수 있다.
차이는 크다.
4. 자동화하면 편해질까? 아니다. 지옥의 종류가 바뀐다
자동화라는 말은 너무 낙관적으로 들린다.
“자동화했으니 이제 편하겠네?”
그렇지 않다.
정확히는,
수작업 지옥이 소프트웨어 운영 지옥으로 바뀐다.
수동 블로그라면 문제는 단순하다.
“오늘 글을 아직 안 썼다.”
자동화 파이프라인에서는 이렇게 된다.
“글은 생성됐다.” “GitHub에도 있다.” “검사도 통과한 것처럼 보인다.” “그런데 운영 환경에는 없다.” “왜?”
게다가 버그 하나가 많은 글에 동시에 영향을 줄 수 있다.
대량 생산이 가능하다는 건 실패도 대량 생산될 수 있다는 뜻이다.
갑자기 품질보증, 공정관리, 병목, 대기열, 재처리가 등장한다.
블로그를 쓰기 시작했는데 머릿속에 생산관리팀이 생긴다.
5. 병목은 계속 이동한다
글 생성이 빨라지면 그다음 막히는 곳이 보인다.
단순화하면 흐름은 이렇다.
생성 → 저장 → 검증 → 공개 → 운영 환경 HTML → 사이트맵 → 발견 → 유입 → 회유 → 수익화
처음에는 “글이 부족하다”가 문제다.
글이 늘면 “전부 제대로 공개됐나?”가 문제가 된다.
공개가 되면 “검색엔진이 찾고 있나?”가 문제가 된다.
발견되기 시작하면 “새 글과 덜 인기 있는 글에도 독자가 퍼지고 있나?”가 문제가 된다.
그다음에는 “해외 언어 페이지가 왜 안 도는가”, “일부 페이지만 유입이 몰리는가”, “광고와 제휴 링크는 있는데 수익 효율은 어떤가”가 된다.
문제가 늘어난 것처럼 보인다.
하지만 실제로는 반대다.
앞의 병목을 뚫었기 때문에 다음 병목이 보이는 것이다.
정체가 아니라 병목 이동이다.
6. “글이 공개되지 않는다”는 최적화 문제가 아니라 게이트 장애다
문제에는 우선순위가 있다.
예를 들어,
- 내부 회유가 약하다
- 해외 유입이 천천히 늘어난다
- 수익화가 아직 약하다
이건 최적화 문제다.
이미 돌아가는 걸 더 잘 돌리는 문제다.
하지만,
글은 만들어졌는데 운영 환경에 안 나온다
는 성격이 다르다.
입구 게이트가 닫힌 것이다.
상품을 만들었다. 진열대도 있다. 계산대도 있다. 광고도 있다.
그런데 창고에서 매장으로 상품이 안 나온다.
이 상황에서 POP 디자인을 더 예쁘게 만드는 건 우선순위가 아니다.
그래서 공개 지연과 누락은 다른 개선보다 먼저 파고들 가치가 크다.
7. 모든 걸 동시에 치면 빠르다. 대신 무엇이 효과였는지 사라진다
현실 운영에서는 하나씩 천천히 고치기 어렵다.
공개 문제를 고치면서 검색 발견도 만진다. 내부 링크도 바꾼다. 해외 유입도 본다. 광고와 제휴도 붙인다.
병렬 처리는 빠르다.
하지만 부작용이 있다.
일주일 뒤 트래픽이 올랐을 때,
무엇이 효과였는지 모른다.
어제는 사이트맵을 바꿨다. 그 전날은 내부 링크를 바꿨다. 며칠 전에는 번역 페이지를 수정했다. 수익화 배치도 만졌다.
그리고 숫자가 오른다.
모든 조치가 “제가 했습니다”라고 손을 든다.
그래서 빠른 운영일수록 간단한 변경 로그가 필요하다.
언제 무엇을 바꿨는지, 어떤 지표를 움직이려고 했는지 기록한다.
속도를 늦추지 않고도 학습할 수 있다.
8. 한 달 반 동안 계속 싸우고 있다. 느린 걸까
한 달 반.
매일 만지면 정말 길게 느껴진다.
“왜 아직도 안 끝났지?”라는 생각이 든다.
하지만 무엇을 만들고 있는지 봐야 한다.
겉모습만 다듬은 게 아니다. 콘텐츠 재고를 늘렸다. 여러 언어를 붙였다. 광고를 붙였다. 제휴 수익 경로를 만들었다. 검색 유입을 봤다. 국내외 독자를 확인했다. 회유를 개선했다. 공개 경로 장애를 파고들었다.
이걸 동시에 하고 있다면 “한 달 반 동안 블로그를 만들었다”가 아니다.
작은 미디어 운영 시스템을 만들면서 실제 트래픽으로 디버깅한 것이다.
시간은 걸린다.
하지만 같은 자리에서 한 달 반을 돌고 있는 것과는 다르다.
병목의 위치가 시스템 안쪽으로 이동하고 있다면 전진하고 있다.
9. 능력과 보상 사이에는 긴 파이프라인이 있다
이 부분이 가장 답답하다.
능력은 늘었다.
콘텐츠를 만들 수 있다. 구조화할 수 있다. 위화감을 찾을 수 있다. 자동화할 수 있다. 다국어화할 수 있다. 개선할 수 있다.
그럼 오늘 바로 수익이 늘까?
그렇지 않다.
사이에 긴 배관이 있다.
능력 → 시스템 → 콘텐츠 재고 → 공개 → 발견 → 유입 → 신뢰 → 회유 → 수익화 → 보상
어디 한 군데가 막혀도 능력은 돈으로 바뀌지 않는다.
그래서 “능력 개발은 충분히 했다. 이제 보상이 따라왔으면 좋겠다”는 감정은 자연스럽다.
콘텐츠 사이트에는 시간차가 있다.
예전 글이 나중에 검색에 걸릴 수 있다. 번역 페이지가 어느 날 해외에서 읽힐 수 있다. 내부 링크가 오래된 글을 다시 살릴 수 있다. 제휴 링크도 맞는 유입이 와야 움직인다.
생산 시점과 보상 시점이 맞지 않는다.
급여와는 다르다.
생활 기반이 다른 곳에서 안정되어 있으면 이 시간차를 견디기 쉬워진다.
사이트에 당장 이번 달 돈을 벌라고 압박하지 않고 자산으로 키울 수 있기 때문이다.
10. 이제 볼 숫자는 “글이 몇 개냐”만이 아니다
글 수는 보기 쉽다.
늘면 기분도 좋다.
하지만 콘텐츠 공장이 다음 단계로 가면 질문이 바뀐다.
예를 들면,
- 글 생성부터 운영 환경 반영까지 얼마나 걸리는가
- 공개 누락이 몇 건 발생하는가
- 새 URL이 검색에 발견될 때까지 얼마나 걸리는가
- 실제 독자가 붙은 글과 언어는 몇 개인가
- 한 글에서 다음 글로 얼마나 이동하는가
- 국가와 언어별 유입이 얼마나 편중되어 있는가
- 추가 작업 없이 오래된 글이 계속 읽히는 비율은 얼마인가
- 천 번의 조회가 어느 정도 수익으로 바뀌는가
- 변경 후 실제로 어떤 지표가 움직였는가
이런 숫자가 “많이 만들 수 있다”를 “많이 일하고 있다”로 바꿔 준다.
글은 재고다.
하지만 공개되지 않고, 발견되지 않고, 읽히지 않고, 연결되지 않는 재고는 아직 일하지 않는 재고다.
콘텐츠 공장의 최종 목표는 글을 만드는 것이 아니다.
추가 수작업 없이 계속 일하는 글을 늘리는 것이다.
결론: 글 쓰는 사람을 강화하지 말고, 글이 생기는 시스템을 강화하자
글 하나 쓰는 건 힘들다.
해법이 “더 빨리 써라”뿐이면 언젠가 한계가 온다.
다른 해법이 있다.
글 쓰는 사람을 끝없이 강화하는 대신,
글을 만들고 공개하고 배포하는 시스템을 강화한다.
처음은 고통스럽다.
수작업 지옥을 없애기 위해 먼저 시스템 구축 지옥으로 들어간다.
미래의 일을 줄이기 위해 지금 일을 늘리는 이상한 기간이 생긴다.
하지만 근본 수리 하나는 미래의 모든 글에 영향을 줄 수 있다.
거기에 레버리지가 있다.
그리고 “뭔가 이상하다”를 무시하지 않는 사고는 여기서 강해진다.
위화감은 단순한 불쾌감이 아니다.
다음 병목의 위치를 알려주는 센서다.
다음 과제는 그 센서를 더 예민하게 만드는 것만이 아니다.
이제는 그 센서로 찾아서 고쳐 온 시스템이 실제로 대신 일하게 해야 한다.
능력은 이미 충분히 늘었다.
이제 자산과 보상이 따라올 차례다.
