스레드 게시물 조회수 측정, 79건 동안 한 번도 재지 않았다

발행은 계속됐는데 반응은 없었다

SGK 스튜디오는 스레드(Threads)에 개발 기록을 자동으로 올리는 프로그램을 운영합니다. 소재를 고르고 초안을 쓰고 발행하는 과정까지 사람 손을 거치지 않는 자동화 파이프라인이고, 스레드는 글 하나를 여러 조각으로 나눠 순서대로 이어 올릴 수 있는 형식을 지원합니다. 이 프로그램이 발행한 이력을 감사해 봤습니다.

결과는 79건 발행에 반응이 거의 없다는 것이었습니다. 8월 9일부터 9월 6일까지 29일 동안 자동 파이프라인으로 76건, 손으로 소급 등록한 것까지 합쳐 79건이 올라갔습니다. 그런데 계획한 480개 조각 중 실제로 나간 것은 426개뿐이었고, 발행 19건(24%)은 일부 조각만 올라간 채 끝났습니다. 29일 중 9일은 하루도 발행이 없었습니다(가동률 69%).

좋아요를 셀 수 있었던 글 73건 중 54건(74%)은 좋아요가 0이었고, 가장 많이 받은 글도 3개에 그쳤습니다. 외부 계정에서 달린 답글은 79건 통틀어 4건, 리포스트는 0건이었습니다. 이 숫자만 보면 원인은 명확해 보입니다 — 콘텐츠가 별로였다고요.

그런데 이 판단에는 구멍이 있었습니다. 같은 소셜미디어에서 따로 모아 둔 다른 계정 글 44,966건과 비교하면 좋아요가 0인 글은 14.6%뿐이라 우리 74%는 확실히 낮습니다. 문제는 이 비교가 '읽혔는데도 반응이 없었다'는 것만 보여줄 뿐, '애초에 읽히지도 않았다'는 가능성은 전혀 배제하지 못한다는 점이었습니다. 조회수라는 지표가 아예 없었기 때문입니다.

그래서 콘텐츠가 문제라고 생각했다

발행 프로그램에는 사람이 다시 손대기 전에 글을 걸러내는 검수 기준이 여러 겹 있습니다. 소재 521건을 살펴보는 동안 초안 자체가 만들어지지 못한 경우가 382건(73%)이었고, 만들어진 초안이 검수를 통과하지 못해 반려된 횟수는 753회였습니다. 반려는 최대 3회까지 다시 시도하는데, 1회차에 걸린 것이 297건, 3회차까지 가서도 결국 버려진 소재가 전체의 40%였습니다.

반려 사유 1,338건을 분류해 보니 93%가 형식 문제였습니다.

• 낯선 영어 표현 383건
• 조각 개수 문제 320건
• 번호 표기 139건
• 글자 수 137건
• 줄 수 72건

가장 많이 걸린 사유는 '낯선 영어 표현을 쓰지 말라'는 규칙이었습니다. 이 규칙이 실제로 반응을 늘리는지는 별도로 세 차례 검증했는데 한 번도 지지되지 않았습니다. 그런데도 이 규칙 하나가 걸러내는 소재가 전체의 29%나 됐다는 비용은 이번 감사에서 처음 확인됐습니다. 그 밖에 일주일 사용 한도에 막힌 경우가 63회, 발행 자체가 실패한 경우가 33회 있었는데, 이 실패는 8월 26일부터 30일까지 닷새 동안 하루도 안 올라간 구간과 겹칩니다.

형식을 다듬는 데 이만큼 공을 들였다는 뜻입니다. 그런데 정작 '이 글이 사람 눈에 띄기는 했는가'를 재는 지표는 이 검수 기준 어디에도 없었습니다. 콘텐츠를 아무리 고쳐도 그 글이 노출조차 안 됐다면 반응이 없는 게 당연합니다. 이 가능성을 확인하려면 코드를 열어야 했습니다.

코드는 무엇을 재고 있었나?

발행 이력을 재는 프로그램(buildlog-metrics.py)을 열었습니다. 96번째 줄 근처의 함수(COUNTS_JS)는 게시물 화면에서 좋아요·답글·리포스트 아이콘 옆 숫자만 읽고 있었습니다. 조회수는 전혀 다른 함수(131번째 줄, ACCOUNT_JS)가 맡고 있었는데, 이 함수가 읽는 자리는 게시물 화면이 아니라 프로필 화면 맨 위, 계정 전체의 '최근 조회수'였습니다.

즉 좋아요·답글·리포스트는 게시물 단위로 읽히는데, 조회수만 계정 단위로 읽히고 있었습니다. 이 구조라면 '좋아요 0'이라는 숫자가 안 읽혀서 0인지 읽혔는데도 0인지 구분할 방법이 처음부터 없습니다.

조회수는 원래 못 잰다고 이미 적혀 있었다

인사이트가 잠겨 있으니 조회수는 원천적으로 수집 불가

이 프로그램의 코드 맨 위 설명글에는 이렇게 적혀 있었습니다. 스레드에는 계정 전체의 조회수·방문자 같은 통계를 모아 보여주는 별도 화면(인사이트)이 있는데, 이 화면이 로그인 방식 때문에 잠겨 있어서 못 연다는 사실을 2026년 8월 11일에 실제로 확인하고 남긴 메모였습니다. 문제는 이 결론이 그 뒤로 26일 동안 한 번도 재검증되지 않았다는 것입니다. 그동안 다른 지표(좋아요·답글)만으로 콘텐츠를 계속 다듬었습니다.

이번 감사에서도 처음엔 이 메모가 맞는 것처럼 보였습니다. 화면에서 '조회수'라는 글자를 찾도록 코드를 짜서 다시 시도했는데, 전건 모두 값을 찾지 못했습니다. 조회수는 역시 잴 수 없나 보다 — 그렇게 결론 내리기 직전이었습니다.

잠긴 건 다른 화면이었다 — 게시물에는 숫자가 떠 있었다

찾지 못한 이유를 확인하려고 게시물 화면을 실제로 열어 봤습니다. 통계 화면(인사이트)은 여전히 잠겨 있었지만, 게시물 하나를 눌러 들어간 화면에는 '조회 488회'라는 문구가 그대로 떠 있었습니다. 잠긴 건 별도 통계 화면 하나뿐이었고, 게시물 자체의 조회수는 처음부터 누구나 볼 수 있는 자리에 있었습니다.

찾지 못했던 원인도 함께 드러났습니다. 코드는 '조회수'라는 글자를 찾고 있었는데, 실제 화면 문구는 '조회'였습니다. 글자 하나 차이로 26일 전 메모가 옳다는 증거처럼 보였던 것입니다.

그리고 계정 헤더에 뜨는 '최근 조회수'(40,000)와 게시물 화면의 조회수를 구분하지 않으면 어떤 일이 생기는지도 확인했습니다. 두 숫자를 먼저 갈라놓지 않고 매칭하면 계정 전체 누적치가 게시물 하나의 조회수로 잘못 붙습니다. 게시물 하나가 계정 전체의 몫을 통째로 뒤집어쓰는 셈입니다.

게시물 화면의 숫자를 직접 읽게 고쳤다

고친 내용은 세 가지입니다. 먼저 프로필 헤더의 '최근 조회수' 문구를 찾아 먼저 지운 뒤에 게시물 화면의 '조회 N회'를 매칭하도록 순서를 바꿨습니다. 다음으로 '만'·'천' 단위로 줄여 쓴 숫자를 실제 숫자로 펼치도록 했습니다. 마지막으로, 값을 못 찾았을 때는 0이 아니라 '확인되지 않음'으로 남기도록 했습니다. 0과 모름을 같은 값으로 두면 나중에 진짜 0인지 아직 못 잰 것인지 다시 구분할 수 없기 때문입니다.

고친 코드로 실제 게시물 3건을 다시 확인했습니다. 각각 488회, 139회, 102회가 나왔습니다. 계정 헤더의 40,000과는 자릿수부터 다른, 게시물 하나하나의 진짜 숫자였습니다.

같은 실수를 막으려면 무엇을 검증해야 하나?

재발 방지 장치는 두 가지를 만들었습니다. 하나는 테스트 방식입니다. 화면에서 숫자를 읽는 코드(COUNTS_JS)는 원래 자바스크립트로 짜여 있는데, 이걸 파이썬 정규식으로 옮겨 적어 따로 테스트하면 두 코드가 서로 다른 것을 검사하게 됩니다. 화면 쪽 문구가 바뀌어도 파이썬 쪽 정규식만 그대로면 테스트는 계속 통과합니다. 그래서 자바스크립트 코드를 그대로 노드(Node.js)로 실행해 검증하는 테스트 6건을 새로 만들었습니다. 두 코드가 하나뿐이면 이런 어긋남 자체가 생기지 않습니다.

다른 하나는 값 자체의 규칙입니다. 못 찾은 값을 0이 아니라 확인되지 않음으로 남기기로 한 결정이 그것입니다. 26일 동안 이 구분이 없었기 때문에 '조회수 0'이 진짜 0인지 그냥 못 잰 것인지 아무도 구분하지 못했습니다. 지금부터는 이 둘을 코드 차원에서 갈라 둡니다.

새벽에 올리면 반응이 더 좋을까?

감사 도중에 확인한 가설이 하나 더 있습니다. 발행 시간을 보면 오전 8시부터 오후 1시 사이에 79건 중 47건(59%)이 몰려 있었는데, 원자료만 보면 새벽 시간대(오전 3시~8시)에 올라간 글의 좋아요 중앙값이 11~25인 반면 낮·저녁 시간대(오전 9시~오후 11시)는 2~4에 그쳐, 새벽이 4~8배 높아 보였습니다.

그런데 같은 계정 안에서만 비교하면 이 차이는 사라졌습니다. 새벽과 낮 모두 5건 이상 올린 계정 30개를 골라 계정별로 어느 시간대가 더 나았는지 세어 보니, 새벽이 나은 계정 16개, 낮이 나은 계정 10개, 비슷한 계정 4개였습니다. 통계 검정(부호검정)으로도 유의미하다고 보기 어려웠습니다(p값 약 0.33).

시간대 차이처럼 보인 것은 실제로는 어떤 계정이 새벽에 많이 올리는지의 차이였을 뿐입니다. 그래서 발행 시간은 바꾸지 않기로 했습니다.

안 읽혀서가 아니라, 읽혔는데도 0이었다

조회수를 실제로 잴 수 있게 되면서 앞서 봤던 계정 헤더의 '최근 조회수' 40,000이라는 숫자도 다시 봐야 했습니다. 최근 발행글 3건의 노출을 합치면 729에 그쳐, 서른 배 넘게 차이가 났습니다. 4만이라는 숫자의 대부분은 발행한 글에서 나온 게 아니라 답글 활동에서 나왔을 가능성이 큽니다 — 다만 계정 단위 숫자라 직접 갈라 확인하지는 못했습니다.

같은 계정에서 단 한 문장짜리 답글이 좋아요를 받은 비율(66%)은 정성껏 만든 발행글이 받은 비율(26%)보다 훨씬 높았습니다. 팔로워도 8월 11일 2명에서 8월 31일 11명으로 늘었다가 9월 6일에는 10명으로, 8월 26일 이후 올라간 글 30건 동안 순증가가 없었습니다. 발행이 아니라 답글이 실제 성장의 원천이었을 가능성이 있다는 뜻입니다.

발행글 세 건은 각각 488회, 139회, 102회가 노출됐는데도 좋아요는 0이었습니다. 안 읽혀서 반응이 없던 게 아니라, 읽혔는데도 반응이 없었던 것입니다. 이 구분이 생기기 전까지는 콘텐츠 검수 기준을 더 세게도 느슨하게도 만들지 않기로 했습니다. 다음에 손댈 곳은 노출을 늘리는 방향이 아니라 글 자체라는 게, 이제서야 근거를 갖고 말할 수 있게 됐습니다.

측정 지표 하나가 비어 있으면, 그 옆에서 다른 지표를 아무리 정교하게 다듬어도 정작 물어야 할 질문에는 답할 수 없습니다. 반응이 없다는 사실 자체는 콘텐츠 탓처럼 보이기 쉽지만, 노출이 됐는지조차 모르는 상태에서는 그 판단이 근거를 갖지 못합니다. 이번 감사로 확인한 건 결국 '어디를 고쳐야 하는가'를 말하기 전에 '무엇을 재고 있는가'부터 다시 확인해야 한다는 점이었습니다. 계측 프로그램 자체를 의심하지 않으면, 콘텐츠를 아무리 잘 만들어도 그 판단이 맞는지 확인할 길이 없습니다. 조회수를 재기 시작한 뒤로는 콘텐츠 검수 기준을 손대는 대신, 노출은 되는데 반응으로 이어지지 않는 글의 공통점을 따로 모아 보는 작업을 다음 순서로 남겨 뒀습니다.

이런 식으로 우리 채널의 반응을 실측한 다른 기록은 스레드 바이럴 유형을 42,661건으로 재본 글에도 있습니다. 발행 이력이나 지표 설계를 비슷하게 감사하고 싶다면 상담에서 이야기할 수 있습니다.