Threads 조회수 수집이 null이던 날, 노출 2.7만회를 한 번도 못 재고 있었다

Threads 조회수 수집이 98건 전부 null이었다면 무엇이 문제였을까요?

Threads 조회수 수집은 화면에 값이 떠 있는데도 기록에는 98건 전부 null로 남아 있었습니다. 원인은 같은 파일 안에서 팔로워용 정규식과 조회수용 정규식이 서로 다르게 쓰여 있었다는 점이고, 이 때문에 계정의 노출 규모인 최근 조회수 2.7만회를 한 번도 재지 못했습니다.

정규식은 글자 모양을 규칙으로 적어 두고 화면 문구에서 그 모양에 맞는 부분을 뽑아내는 도구입니다. 수집 스크립트는 프로필 화면에 적힌 «최근 조회수 2.7만회» 같은 문구를 이 도구로 읽어 숫자로 바꾸고, 그 숫자를 기록 파일에 한 줄씩 쌓습니다. 읽지 못하면 값이 비고, 비면 null이 남습니다.

null은 «값이 없다»가 아니라 «값을 얻지 못했다»를 뜻합니다. 이 둘은 기록 파일 안에서는 똑같이 빈칸으로 보입니다. 그런데 사람이 그 빈칸을 읽을 때는 대개 앞쪽, 곧 «없다»로 읽습니다. 이번 일은 그 읽기가 판단을 얼마나 틀어 놓는지 확인한 사례입니다.

소규모 회사가 SNS 계정을 키울 때는 노출, 곧 글이 몇 번 화면에 떴는지가 가장 먼저 보는 지표입니다. 노출이 있는데 팔로워가 안 늘면 글의 문제가 아니라 그다음 단계의 문제이고, 노출 자체가 없으면 글이나 계정의 문제입니다. 두 경우는 처방이 정반대입니다. 그래서 노출 칸이 비어 있으면 어느 쪽 처방도 고를 수 없습니다.

이 글은 개선기의 순서를 그대로 따릅니다. 처음 잰 숫자, 그 숫자 위에 세운 가설, 가설이 틀린 지점, 진짜 원인, 고친 내용, 다시 잰 결과, 남은 한계 순입니다. 실패한 가설도 지우지 않고 적었습니다.

처음 잰 숫자: 화면에는 2.7만회, 기록에는 null 98건

측정 방법은 단순했습니다. 프로필 화면을 라이브로 열어 헤더에 적힌 문구를 눈으로 읽고, 같은 시점의 기록 파일 칸과 나란히 놓고 비교했습니다. 화면에는 «최근 조회수 2.7만회»가 있었고, 기록 파일의 조회수 칸은 98건 전부 null이었습니다.

여기서 눈에 띄는 점은 98건이 «대부분»이 아니라 «전부»라는 사실입니다. 일부가 비었다면 화면이 불안정했거나 로딩이 늦었다는 식의 설명이 가능합니다. 전부 비었다면 읽는 규칙 자체가 단 한 번도 맞지 않았다는 신호입니다.

더 불편한 사실도 있었습니다. 같은 수집 파일의 주석에는 2026년 8월 11일에 «노출 지표가 유일하게 잡히는 자리»라고 적혀 있었습니다. 이 칸이 가장 중요한 지표 자리라는 점을 알고 있었는데, 그 값을 한 번도 읽어 내지 못했다는 뜻입니다. 주석이 맞았다는 사실이 오히려 결함을 키웠습니다.

처음 세운 가설: 조회수 칸이 비었으니 확인할 노출이 없거나 못 잡는 구조다

이 발견에 앞서 다른 가설이 먼저 있었습니다. 작업 목록 0-2번에는 «지금 안 깎이는 유일한 표면은 프로필 소개란인데 걸려 있는지 확인 못 했다, 다음엔 그것부터»라는 메모가 있었습니다. 그래서 이번 점검의 출발점은 조회수가 아니라 프로필 소개란이 걸려 있는지 확인하는 일이었습니다.

조회수 칸의 null은 점검하는 도중에 발견했습니다. 그런데 발견하기 전까지 우리는 이 null을 읽고 있었습니다. 암묵적으로 깔려 있던 가설을 말로 옮기면 이렇습니다. «조회수 칸이 비어 있다면 이 화면에서는 노출 수치를 얻을 수 없거나, 얻을 만한 노출이 아직 없다.»

이 가설은 그럴듯했습니다. 팔로워가 2명에서 시작한 작은 계정이었고, 값이 없는 이유로 «노출이 없어서»를 떠올리기 쉬운 상황이었습니다. 그래서 비어 있는 칸을 의심하는 대신 그대로 받아들였습니다.

문제는 이 가설을 한 번도 검증하지 않았다는 점입니다. 가설은 «칸이 비었다»라는 관측에서 곧바로 «노출이 없다»라는 결론으로 건너갔고, 그 사이에 화면을 한 번 열어 보는 확인이 없었습니다.

가설은 어디서 틀렸을까요?

가설은 두 군데서 틀렸습니다. 첫째, 노출은 있었습니다. 화면에는 최근 조회수 2.7만회가 이미 떠 있었습니다. 둘째, 이 화면에서 노출 수치를 얻을 수 있었습니다. 같은 헤더에서 팔로워 수는 정상적으로 읽혔고, 조회수도 눈에 보이는 문구로 같은 자리에 있었습니다.

한마디로 읽는 쪽이 못 읽은 값을 대상이 비었다고 기록한 셈입니다. 값이 존재하는데 코드가 값을 못 읽었고, 그 null을 «없음»으로 해석했습니다. 해석이 틀리면 그 위에 쌓은 판단은 전부 같이 틀어집니다.

틀린 가설을 되짚으면 바로잡을 지점이 분명해집니다. 칸이 비었을 때 가장 먼저 할 질문은 «왜 비었나»가 아니라 «화면에는 있는가»였습니다. 이 질문은 라이브 화면을 열어 보기만 하면 답이 나옵니다. 그 확인이 가설보다 앞섰어야 했습니다.

실패한 가설을 이 글에 그대로 남기는 이유가 있습니다. 이번 가설은 억지로 만든 허수아비가 아니라, 같은 상황에서 누구라도 세웠을 합리적인 추론이었습니다. 합리적인 추론이 틀릴 수 있다는 점이 이 사례의 핵심이라서, 틀린 경로를 숨기면 교훈도 함께 사라집니다.

진짜 원인은 무엇이었나: 같은 파일 안의 정규식 비대칭

진짜 원인은 같은 파일에 나란히 있던 두 정규식의 모양이 달랐다는 점입니다. 팔로워용 정규식은 `[0-9][0-9,.]*\s*[만천]?`였고, 조회수용 정규식은 `[0-9][0-9,]*`였습니다.

• 팔로워용 `[0-9][0-9,.]*\s*[만천]?` — 숫자 뒤에 쉼표와 소수점을 받고, 공백을 건너뛰고, «만»이나 «천»까지 받습니다.
• 조회수용 `[0-9][0-9,]*` — 숫자와 쉼표만 받습니다. 소수점도 «만»도 규칙에 없습니다.

화면의 «2.7만회»는 숫자 2, 소수점, 숫자 7, «만», «회»로 이루어져 있습니다. 조회수용 규칙에는 소수점과 «만»이 들어갈 자리가 없으므로 이 문구는 규칙에 맞지 않았고, 결과는 null로 남았습니다. 팔로워 수 11은 소수점도 «만»도 없는 평범한 숫자라 두 규칙 모두에서 읽혔을 테니, 기록에 남은 값도 문제가 없었습니다. 그래서 팔로워 칸만 멀쩡해 보였습니다.

이 비대칭은 한 번의 실수로 생겼다기보다 두 칸이 따로 만들어졌다는 사실에서 나왔다고 봅니다. 팔로워 규칙을 쓸 때는 «만»을 걱정했고, 조회수 규칙을 쓸 때는 걱정하지 않았습니다. 같은 화면의 숫자들이 같은 표기 규칙을 쓴다는 점을 한 곳에서 정의하지 않고 두 곳에서 따로 적은 결과입니다. 이 문장은 코드 이력을 확인한 결과가 아니라 파일 구조를 보고 세운 추정입니다.

조치: 읽는 규칙과 저장 형식을 함께 고쳤습니다

고친 곳은 두 군데입니다. 하나는 조회수 규칙이 소수점과 «만»을 받게 했고, 다른 하나는 팔로워와 조회수를 둘 다 정수로 바꿔 저장하게 했습니다. 2.7만회는 27,000으로 저장됩니다.

정수로 맞춘 이유는 정렬에 있습니다. 값을 문자열로 저장하면 추이를 정렬할 때 `"10" < "2"`가 됩니다. 문자열 비교는 첫 글자부터 차례로 비교하므로 «1»로 시작하는 «10»이 «2»보다 앞에 놓이기 때문입니다. 지금까지는 팔로워 수가 한 자리였기 때문에 우연히 걸리지 않았을 뿐입니다.

이 정렬 문제는 아직 일어나지 않은 결함이었습니다. 팔로워가 2명에서 10명으로 넘어가는 순간 그래프의 순서가 뒤집힐 수 있었습니다. 실제로 팔로워는 8월 11일 2명에서 8월 28일 10명으로 늘었으니, 두 자리 숫자를 만나기 직전이었던 셈입니다. 읽는 규칙을 고치다가 같은 자리에 있던 잠복 결함까지 함께 닫았습니다.

고치는 범위는 일부러 계측에만 한정했습니다. 소개란에 무엇을 적을지는 코드 문제가 아니라 회사가 자신을 어떻게 소개하고 어디로 보낼지 정하는 사업 판단이어서, 같은 날 손대지 않고 따로 올렸습니다. 읽는 코드를 바로잡는 일은 되돌리기 쉬운 수리이고, 소개란 문구는 밖에서 보이는 약속이라 다르게 다루었습니다.

고친 뒤에는 4케이스를 검증했습니다. 그다음 실제 프로필을 다시 수집해 기록에 남은 값을 확인했습니다. 단위 검증과 라이브 재수집을 둘 다 한 이유는 단위 검증만으로는 «화면의 실제 문구가 규칙에 맞는지»를 보장하지 못하고, 라이브 재수집만으로는 경계 입력을 다 건드리지 못하기 때문입니다.

재측정 결과: 조회수 27,000, 팔로워 11

재수집한 기록에는 조회수 27,000과 팔로워 11이 들어왔습니다. 처음 잰 값이 «98건 전부 null»이었으니 이제 칸이 채워졌고, 화면의 «2.7만회»는 기록에서 27,000으로 남았습니다.

한 번 재고 끝내지 않은 부분도 적어 둡니다. 재수집은 한 번의 수동 확인이었습니다. 이 값이 앞으로도 계속 제대로 들어오는지는 이후 수집 때마다 확인해야 하는 문제이고, 이 글을 쓰는 시점에는 한 번의 재측정만 있습니다.

재측정에서 확인한 항목은 두 가지입니다. 첫째, 조회수 칸에 값이 들어옵니다. 둘째, 그 값이 문자열이 아니라 정수로 저장돼 순서 비교가 숫자 기준으로 돌아갑니다. 앞의 확인이 «읽는다»를, 뒤의 확인이 «다음 단계에서 쓸 수 있다»를 맡습니다. 읽기만 고치고 저장 형식을 그대로 두었다면 팔로워가 두 자리가 되는 순간 다른 곳에서 같은 종류의 문제가 다시 올라왔을 것입니다.

그래도 무엇이 바뀌었는지는 분명합니다. 이제 노출 지표가 숫자로 존재합니다. 다만 지난 98건의 빈칸을 과거 값으로 채웠다는 근거는 없습니다. 이 글이 확인한 값은 재수집한 시점의 27,000과 11뿐이고, 추이는 앞으로 쌓이는 기록부터 볼 수 있습니다.

두 값을 겹치면 무엇이 보였나: 도달은 있고 받을 그릇이 없었습니다

점검 중에 두 번째 발견이 있었습니다. 프로필에 외부 링크가 0개이고 소개란 자체가 비어 있었습니다. 앞에서 고친 조회수 27,000과 팔로워 11명을 이 사실과 겹쳐 보면 구조가 한눈에 들어옵니다.

• 최근 조회 27,000 · 팔로워 11명 — 팔로워는 8월 11일 2명, 8월 28일 10명, 8월 31일 11명으로 늘었습니다.
• 도달은 이미 있습니다. 없는 쪽은 도달에서 관계로 넘어가는 전환입니다.
• 답글이 사람을 데려오고(작성자 답장 비율 38%) 빌드 로그가 신뢰를 쌓는데, 신뢰를 확인한 사람이 다음으로 갈 경로가 아예 없습니다.

소개란이 왜 중요하냐면, 본문에 링크를 넣는 방식은 이미 기각된 상태였기 때문입니다. 647쌍을 짝지어 비교한 실측에서 본문 링크가 글의 도달을 깎는다는 결과가 나왔습니다. 그러면 링크를 놓을 수 있는 자리는 프로필 소개란 하나뿐인데, 그 자리가 비어 있었습니다. 관련 실측은 Threads 프로필 링크와 게시 상한을 다룬 글에 따로 정리해 두었습니다.

두 발견이 따로따로 나왔다면 의미가 훨씬 작았을 것입니다. 조회수만 고쳤다면 «노출이 있다»는 사실만 남고, 소개란만 봤다면 «비어 있다»는 사실만 남습니다. 둘이 한 화면에서 같은 날 나왔기 때문에 «노출은 27,000인데 받을 곳이 없다»는 문장이 성립했습니다. 계측 수리와 유입 점검이 서로의 근거가 된 경우입니다.

팔로워 숫자도 같은 방향을 가리킵니다. 8월 11일 2명에서 8월 28일 10명으로 늘었고 8월 31일에 11명까지 올랐습니다. 늘고는 있으나 최근 조회 27,000에 견주면 팔로워 11명은 아주 작은 숫자입니다. 이 간극이 «도달은 있고 전환이 약하다»는 진단의 수치 근거입니다.

여기서 판단의 순서가 중요합니다. 조회수가 null인 채였다면 «도달이 없다»는 결론에 닿기 쉽고, 그러면 글을 더 쓰는 쪽으로 처방이 갈렸을 수 있습니다. 값을 제대로 읽고 나서야 «도달은 있는데 받을 그릇이 없다»는 진단이 가능해졌습니다. 처방이 정반대로 갈리는 지점이 바로 이 칸이었습니다.

왜 이 결함은 98건이 쌓이도록 조용했을까요?

결함이 조용했던 이유는 null이 오류가 아니라 정상적인 저장 값이었기 때문입니다. 규칙에 맞는 문구를 찾지 못했을 때 스크립트는 멈추지도, 경고를 내지도 않고 빈 값을 한 줄로 적었습니다. 수집은 매번 성공으로 끝났고, 기록 파일은 매번 한 줄씩 늘었습니다.

겉으로 드러나는 신호가 없으니 누구도 칸을 열어 볼 이유가 없었습니다. 팔로워 칸은 값이 들어와 정상으로 보였고, 같은 줄의 조회수 칸이 비어 있어도 줄 전체는 «수집 성공»으로 남았습니다. 한 줄 안에서 일부 칸만 죽은 상태는 줄 단위 성공 판정으로는 잡히지 않습니다.

파일 주석도 한몫했습니다. 주석은 이 칸이 노출 지표를 잡는 유일한 자리라고 적고 있었고, 읽는 사람은 그 문장을 «이 칸은 잡히고 있다»로 받아들이기 쉽습니다. 주석은 의도를 말할 뿐 현재 상태를 보증하지 않습니다. 의도와 상태가 어긋난 채로 98건이 지나갔습니다.

이 결함을 가장 빨리 드러냈을 확인은 아주 단순합니다. 기록의 최신 값과 라이브 화면의 같은 값을 한 번 나란히 놓는 일입니다. 이번에는 프로필 소개란이 걸려 있는지 보려고 화면을 연 김에 그 대조가 저절로 이루어졌습니다. 다시 말해 발견은 계획된 점검이 아니라 다른 목적으로 연 화면에서 나왔습니다.

그래서 수집 도구를 운영하는 쪽이 배울 점은 «결함이 안 보이는 구조는 대조 습관으로 메운다»입니다. 값이 비는 경우를 오류로 올리거나, 최소한 줄 안의 빈 칸 수를 따로 세어 두면 같은 결함이 두 번째 줄에서 드러납니다. 이 글을 쓰는 시점에는 이 두 장치를 만들지 않았고, 제안으로만 남겨 둡니다.

남는 한계: 아직 재지 못한 두 가지

첫째 한계는 소개란에 무엇을 넣을지 정하지 못했다는 점입니다. 이것은 기술 문제가 아니라 포지셔닝 진술과 착지면을 고르는 사업 판단이라 자율로 정하지 않고 결정 대상으로 올렸습니다. 권장안은 이미 있는 허브인 sgkstudio.co.kr이고, 이 사이트에는 리포트 137편이 있습니다. 다만 이 안은 권장일 뿐 결정이 아닙니다.

둘째 한계는 프로필 링크가 도달을 깎는다는 근거가 없다는 점입니다. 앞서 말한 647쌍 실측이 잰 대상은 본문 링크이고, 프로필 소개란은 피드로 배포되는 대상이 아닙니다. 그렇다고 소개란 링크가 안전하다고 단정할 수도 없습니다. 소개란 링크 쪽은 실측한 적이 없으므로 추정이고, 넣은 뒤에 재야 알 수 있습니다.

세 번째 한계도 짚어 둡니다. 이 글의 숫자는 한 계정, 한 시점의 프로필에서 나왔습니다. 조회수 27,000과 팔로워 11명이라는 비율이 다른 계정에도 맞는다고 말할 근거는 없고, 이 글이 주장하는 범위는 «읽는 쪽이 못 읽은 값을 부재로 기록하면 판단이 틀어진다»는 구조까지입니다. 숫자의 일반화는 다른 계정으로 재 보아야 알 수 있습니다.

정리하면 이번에 닫은 문제는 계측이고, 열려 있는 문제는 두 가지입니다. 소개란에 무엇을 둘지, 그리고 그 링크가 도달에 어떤 영향을 주는지입니다. 순서는 정해져 있습니다. 먼저 넣고, 그다음 조회수 27,000이 어떻게 움직이는지 지켜봅니다.

같은 실수를 막으려면 어떻게 해야 할까요?

읽는 쪽이 못 읽은 값을 대상의 부재로 기록하지 않는 습관이 필요합니다. 이번 점검 한 번 동안 같은 형태를 네 번째로 만났습니다. 화면에 값이 있는데 코드가 못 읽었고, 그 null을 «없음»으로 읽었습니다.

• 반응을 측정하지 않고 있었던 일
• 두 계측기의 값이 서로 달랐던 일
• 측정 단계 사이의 연결이 끊겼던 일
• 그리고 이번 조회수 칸의 null

네 건의 모양은 같습니다. 측정 도구가 못 읽은 상태가 «대상에 값이 없는 상태»와 같은 빈칸으로 기록됩니다. 그러면 그 기록 위에서 내리는 모든 판단이 틀어집니다. 처방은 빈칸을 두 종류로 나눠 쓰는 방식입니다. 읽었는데 값이 없는 경우와 읽지 못한 경우에 서로 다른 표시를 남기고, 이 글을 쓰는 시점에는 아직 적용하지 않은 제안입니다.

작게 시작하는 점검 순서도 하나 정해 둘 만합니다. 칸이 비어 있으면 가장 먼저 라이브 화면을 열어 값이 있는지 봅니다. 있으면 읽는 코드가 틀렸고, 없으면 그때 비로소 대상의 부재를 말합니다. 순서를 바꾸면 이번처럼 98건이 쌓인 뒤에야 발견하게 됩니다.

SNS 계정 지표나 자동 수집 스크립트의 빈 칸이 어디서 생기는지 같이 살펴보고 싶다면 상담으로 남겨 주세요. 이 글의 작성자는 SGK 스튜디오입니다.