블로그 운영대행을 다시 열 때 무엇을 가정했나?
블로그 운영대행은 저희가 한 번 접었다가 다시 연 서비스입니다. 이 글은 2026년 8월 7일 판매를 멈춘 날부터 8월 28일 재개를 확정한 날까지 벌어진 일을 정리한 회고이고, 결론부터 적으면 판매 상태를 한 곳에서 정한다고 믿었던 가정이 틀렸습니다.
판매를 멈춘 계기는 한 고객 문의였습니다. 구글 자연검색으로 들어온 문의에 회신 초안을 쓰다가, 홈페이지에 올려 둔 자사 블로그 증빙이 사실과 다르다는 점을 발견했습니다. 그 김에 인도 방식 전체를 다시 봤고, 네이버 이용약관 원문에서 두 조항이 걸렸습니다. 하나는 계정을 다른 사람이 쓰도록 허락하면 안 된다는 조항으로 위반 주체가 계정을 넘기는 고객이고, 다른 하나는 매크로 같은 자동화 수단으로 로그인하거나 글을 올리면 안 된다는 조항으로 위반 주체가 저희입니다. 블로그 글쓰기 API는 2020년 5월 6일에 이미 종료돼 공식 우회로도 없었습니다. 약관 검토 과정은 병원 블로그 관리 대행, 네이버 약관을 한 층만 읽고 접었다에 따로 적었습니다.
중단 조치는 네 갈래였습니다. 서비스 목록 파일 offers.json에서 상태를 retired(판매 중단)로 바꾸고, 서비스 소개 페이지를 지우고 주소를 상위 페이지로 돌렸고, 네이버 광고 키워드 5종을 껐고, 표준 계약서는 나중을 위해 남겼습니다. 손실은 작다고 판단했습니다. 블로그 광고 그룹은 7일 동안 노출 23,641회 가운데 99.7%가 확장검색이었고 클릭은 0이었습니다. 대신 월 3,900회 안팎의 검색 수요를 겨냥하던 트랙 하나를 내려놓았습니다.
이때 저희가 깔고 있던 가정은 셋이었습니다. 돌아보면 셋 다 이후 17일 동안 하나씩 무너졌습니다.
- 판매 상태는 offers.json 안의 값 하나이고, 그 값만 바꾸면 광고·콘텐츠 발행·챗봇이 따라 멈춘다
- 다시 열 때는 발행 1건에 사람 손이 얼마나 드는지 10건을 재 보고 대표가 판정하면 된다
- 판정이 나기 전까지 임시 차단을 걸어 두면 판매는 멈춘 상태로 유지된다
실제로 벌어진 일: 8월 7일부터 8월 28일까지
첫 균열은 중단 당일 아침에 났습니다. 콘텐츠 자동 발행기가 방금 판매를 멈춘 블로그 운영대행을 겨냥한 새 글을 그대로 발행했습니다. 검색어 발굴 단계의 차단 장치는 발행 대기열에 새로 들어오는 글만 막았고, 이미 대기열에 들어 있던 21건은 발행 직전에 다시 검사하지 않았습니다. 같은 모양의 실패는 7월 27일 다른 서비스를 접을 때 이미 한 번 있었고, 이번이 두 번째였습니다.
그날 바로 발행 직전 시점에 offers.json을 다시 읽어 판매 중단 서비스를 겨냥한 글을 건너뛰는 필터 `_retired_offers()`를 넣었습니다. 라이브 대기열에 돌려 보니 4개 항목이 즉시 걸렸습니다. 이미 발행된 글 6편의 상담 버튼 연결도 따로 고쳤습니다.
이 필터의 첫 초안에는 반증된 판단이 하나 들어 있었습니다. 처음에는 상태가 active가 아니면 전부 막도록 썼는데, 라이브 offers.json과 대조해 보니 광고 그룹 연결만 빠졌을 뿐 실제로 팔고 있는 서비스(예: AI마케팅)까지 막고 있었습니다. 그래서 retired만 막도록 좁혔습니다. 막는 범위를 넓게 잡으면 안전해 보이지만, 그만큼 팔아야 할 것을 조용히 숨깁니다.
8월 11일에는 중단 판단의 전제를 바로잡는 결정이 나왔고, 재개 조건이 붙었습니다. 발행 1건에 사람 손이 얼마나 드는지 10건을 직접 재고, 그 숫자로 대표가 재개 여부를 판정한다는 조건입니다. 측정 기록지와 원고 10건 변환까지는 준비를 마쳤습니다.
8월 19일, 검색 수요가 있는 검색어로 콘텐츠 시드를 채우는 작업을 하다가 문제가 드러났습니다. 블로그 관련 검색어 5종을 시드에 넣으려는데, 이 서비스의 상태를 적은 세 곳이 서로 다른 말을 하고 있었습니다.
8월 7일에 고친 필터 `_retired_offers()`는 offers.json만 읽었습니다. 그래서 active라고 적힌 블로그 운영대행을 그대로 통과시켰고, 시드 5건이 섞여 들어갔다가 기존 테스트에 걸려 빠졌습니다. 테스트가 잡아 준 덕분에 밖으로 나가지는 않았지만, 필터를 고친 사람이 믿은 값과 테스트를 쓴 사람이 믿은 값이 달랐다는 뜻입니다.
그날 작업에서는 세 곳 중 무엇이 맞는지 정하지 않았습니다. 서비스를 팔지 말지는 대표가 정할 사업 결정이고, 코드 작업 중에 한쪽 편을 들 권한이 없었기 때문입니다. 대신 `GATED_OFFERS`라는 임시 차단 목록을 만들어 블로그 시드만 막고, 근본 판정은 대표에게 올렸습니다. 다시 찾는 비용을 없애려고 보류한 시드 5종의 검색량은 코드 주석에 실측값 그대로 남겼습니다.
그 판정은 쉽게 나오지 않았습니다. 결정 요청은 11.9일 동안 답이 없었고, 정해 둔 응답 기한을 8.1일 넘겼고, 그 사이 재촉 알림이 8회 나갔습니다. 그리고 임시 차단이 시드를 막고 있는 동안에도 상담 챗봇은 블로그 운영대행을 가격까지 붙여 안내하고 있었습니다. 판정이 없는 서비스를 파는 상태가 17일간 이어졌습니다.
가정 중 무엇이 틀렸나?
첫째, 상태 값 하나만 바꾸면 모든 곳이 따라온다는 가정이 틀렸습니다. offers.json을 읽는 쪽은 최소 세 갈래였습니다. 이미 발행된 글의 상담 버튼 연결, 발행 대기열에 새로 들어오는 글의 차단, 대기열에 이미 있던 글의 발행입니다. 셋 중 하나만 고쳐도 나머지 길로 샜고, 실제로 8월 7일에는 세 번째 길이 열려 있었습니다. 여기에 offers.json을 아예 읽지 않는 곳도 있었습니다. 상담 챗봇 지식 베이스는 이 서비스를 `blog-retired`라는 id로 부르고 있었고, 두 저장소가 같은 서비스에 서로 다른 id를 쓰던 점이 따로 기록해 둔 오류 한 건의 원인이었습니다.
이런 모양은 처음이 아니었습니다. 7월 24일에도 광고 키워드 관리 스크립트가 이전 판정을 보존하는 로직 때문에 판매 중단 서비스를 무시하고 있었고, 그 버그를 고치자 키워드 109개가 한꺼번에 꺼졌습니다. 사유는 서비스 목록에 연결되지 않은 키워드 72개, 정보성 검색 14개, 판매 중단 13개, 경제성 미달 10개였습니다. 상태를 바꾸는 일과 그 상태가 소비되는 모든 지점에 닿는 일은 별개였습니다.
둘째, 사전 실측 10건이면 재개를 판정할 수 있다는 가정이 틀렸습니다. 측정 기록지는 설계상 대표가 직접 발행해야 채워지는 항목이라 AI 코딩 에이전트가 대신 채울 수 없었습니다. 그래서 기록지는 통째로 비어 있었고, 비어 있는 기록지를 전제로 한 결정 요청은 답을 받을 수 없었습니다. 재개 결정 기록에 남긴 문장이 이 상황을 그대로 말해 줍니다.
17일간 아무도 하지 않았고, 그 노동을 요구하는 한 다음 17일도 같다. 큐를 잠그는 조건은 조건이 아니라 차단기다.
셋째, 임시 차단이면 판매가 멈춘다는 가정도 틀렸습니다. `GATED_OFFERS`는 콘텐츠 시드 한 경로만 막았습니다. 고객이 직접 말을 거는 챗봇은 그 목록을 보지 않았고, 차단이 걸려 있는 동안 가격을 안내했습니다. 차단 장치를 하나 더 만들수록 그 장치를 모르는 소비자가 하나 더 생기는 구조였습니다.
그래서 바꾼 것: 사전 실측을 첫 고객 발행으로 옮겼다
8월 28일, 대표 승인으로 재개를 확정했습니다. 다만 범위를 좁혔습니다. 월 8건짜리 단일 패키지만 팔고, 동시에 운영하는 고객은 1개사로 묶고, 사전 실측 10건을 재개 조건에서 뺐습니다. 첫 고객의 발행 8건이 실측을 겸합니다.
근거는 두 가지였습니다. 방향은 대표가 이미 두 번 가리켰습니다. 8월 13일에 학원 고객에게는 블로그 운영대행이 맞다고 말했고, 8월 27일에는 블로그 재가동 승인을 올렸습니다. 남은 미지수는 사업 판단이 아니라 원가, 곧 발행 1건에 드는 시간 하나였고, 그 값은 첫 고객의 8건에서도 똑같이 나옵니다.
모르는 채로 시작하는 위험은 정원으로 묶었습니다. 동시 운영이 1개사면 최악의 경우를 건당 20분으로 잡아도 월 2.7시간이라 혼자서도 감당할 수 있습니다. 위험을 없애지 못할 때는 크기에 상한을 거는 쪽을 골랐습니다.
기각한 안은 둘입니다. 사전 10건 실측을 유지하는 안은 17일 동안 아무도 수행하지 않았다는 사실 하나로 기각했습니다. 월 12건 패키지까지 함께 여는 안도 기각했습니다. 원가를 모르는 구간이 1.5배로 넓어지는데, 그 대가로 늘어나는 매출이 작았습니다.
판정이 나자 어긋나 있던 곳을 한 번에 맞췄습니다. offers.json에는 승인 기록을 남겼고, REJECTED.md의 기각 항목은 닫았고, `GATED_OFFERS`는 비웠습니다. 서로 다른 상태를 단언하던 테스트 4건을 정리했고, 코드 주석에 보관해 둔 검색어 시드 5종을 복원했습니다. 챗봇 지식 베이스의 id도 `blog-retired`에서 `blog-agency`로 바꿔 두 저장소가 같은 이름을 쓰게 했습니다.
지금의 숫자
재개 결정 시점에 잰 숫자는 이렇습니다. 전체 테스트는 674개가 통과했고, 서로 다른 상태를 단언하며 실패하던 테스트 4건이 그 안에 들어 있습니다. 상태를 적은 곳은 offers.json, REJECTED.md, 테스트, 챗봇 지식 베이스 네 곳이 모두 같은 말을 합니다. 임시 차단 목록에 남은 서비스는 0개입니다.
- 판정 없는 서비스를 판 기간: 17일
- 결정 요청 무응답: 11.9일 (응답 기한 초과 8.1일, 재촉 8회)
- 중단 당일 재검사 없이 남아 있던 발행 대기 글: 21건, 필터 투입 직후 즉시 차단 4건
- 복원한 검색어 시드: 5종 (가장 큰 블로그지수 월 5,450회)
- 재개 범위: 월 8건 패키지 1종, 동시 운영 1개사, 최악 원가 월 2.7시간
- 발행 건당 원가 실측값: 아직 0건
마지막 줄이 이 회고에서 가장 중요한 숫자입니다. 재개를 막던 실측을 첫 고객에게 넘겼으니, 첫 고객이 생기기 전까지 원가는 여전히 가정입니다. 결정을 풀어 준 대가로 원가를 모르는 기간이 그만큼 길어졌습니다.
아직 못 푼 것은 무엇인가?
원가가 첫 번째입니다. 건당 20분은 최악의 경우를 잡은 상한이지 잰 값이 아닙니다. 첫 고객의 발행 8건이 끝나야 패키지 구성과 정원을 다시 볼 수 있습니다.
정원 1개사는 위험을 묶는 대신 판매를 묶습니다. 두 번째 문의가 오면 대기시켜야 합니다. 월 12건 패키지 소개 문구도 내려 두었기 때문에, 첫 고객 실측이 끝나면 되돌리는 작업이 한 번 더 남아 있습니다.
8월 7일 판매를 멈추던 무렵 구매 의사를 보였다가 놓친 문의가 하나 있습니다. 재접촉 메일은 초안만 써 두었고, 밖으로 나가는 메일이라 대표 승인 뒤에 보냅니다.
구조 문제도 남았습니다. 이번에는 네 곳이 같은 말을 하도록 맞췄을 뿐, 판매 상태를 한 파일에서만 정하고 나머지가 그 값을 읽기만 하게 바꾸지는 않았습니다. 판매를 멈추거나 다시 열 때마다 사람이 소비 지점을 기억해 고쳐야 하는 상태라면, 같은 어긋남은 다음 서비스에서 또 납니다. 서비스를 접는 결정의 기준을 따로 다룬 글은 서비스 종료 결정 기준, 시작할 때만 있고 접을 때는 없었다입니다.
판매 상태가 여러 시스템에 흩어져 있어 비슷한 어긋남을 겪고 있다면, 어디서부터 한 곳으로 모을지 상담에서 함께 짚어 볼 수 있습니다.