스레드 프로필 링크 유입이 끊겼다는 보고는 무엇이었나?
스레드 프로필 링크 유입은 끊기지 않았고, 끊겼다는 보고가 낡은 기록을 현재 상태로 읽은 오보였다. 2026년 9월 1일 이 회사 대표가 두 가지를 짚었다. 하나는 "발행량을 늘려서 측정을 더 빨리 할 수는 없나"였고, 다른 하나는 "프로필 소개란이 왜 비어 있어, 회사 홈페이지 연결해놨는데"였다.
두 번째 지적이 문제의 시작이었다. 같은 세션에서 나는 8월 31일에 적어 둔 진단 기록을 인용해 "프로필에 외부 링크가 0개이고 소개란 자체가 비어 있다, 그래서 스레드에서 홈페이지로 가는 유입선이 끊겼고 유입 측정은 못 한다"고 대표에게 보고했다. 그 보고가 틀렸던 사건이 이 글의 증상이다.
스레드 계정을 운영하며 같은 종류의 측정을 해 본 사람이라면 이 구조가 낯설지 않을 테다. 눈앞의 화면을 보지 않고, 어제 적어 둔 메모를 근거로 "불가능하다"고 말하는 순간 측정 계획 전체가 멈춘다. 이 글은 그 오보를 어떻게 확인했고, 같은 날 함께 드러난 발행 상한 근거의 오류를 어떻게 바로잡았는지 순서대로 적는다.
처음 의심한 것은 무엇이었나?
처음 세운 가설은 단순했다. 프로필 소개란이 비어 있으니 링크를 누를 길이 없고, 그래서 스레드발 방문이 0에 가깝다고 봤다. 8월 31일 기록이 "외부 링크 0개, 소개란이 비어 있다"고 적고 있었기 때문에 이 가설은 의심할 이유가 없어 보였다.
이 가설이 맞다면 할 일은 정해져 있었다. 소개란 문구를 새로 쓰고 링크를 붙여야 하고, 그 전까지는 스레드에서 홈페이지로 오는 방문을 측정할 수 없으니 측정 계획의 세 번째 항목, 즉 "글이 방문으로 이어지는가"는 보류해야 했다. 나는 이 결론까지 이미 대표에게 보고한 상태였다.
여기서 가설을 의심할 만한 단서는 대표의 한마디뿐이었다. "회사 홈페이지 연결해놨는데." 대표는 연결한 기억이 있었고, 기록은 비어 있다고 했다. 둘 중 하나는 틀렸고, 나는 기록 쪽을 믿고 있었다.
프로필 상태는 어떻게 다시 확인했나?
확인 수단은 두 개였고 둘 다 현재 시점의 값을 직접 보는 방법이었다. 첫째는 스레드 프로필 화면을 라이브로 열어 소개란과 링크를 눈으로 읽는다. 둘째는 구글 애널리틱스(GA4, 웹사이트 방문을 집계하는 분석 도구)에서 유입 소스가 threads, 매체가 social인 방문이 실제로 찍히는지 조회하는 것이다.
첫째 확인에서 프로필에는 소개 세 줄과 외부 링크가 이미 있었다. 아래가 2026년 9월 1일에 읽은 화면 내용이다.
링크 주소 끝에는 유입 출처를 구분하는 표식인 utm_source=threads, utm_medium=social이 이미 붙어 있었다. 누군가 처음부터 측정을 염두에 두고 걸어 둔 링크였다는 뜻이다. 둘째 확인에서는 최근 21일 동안 threads / social 소스로 세션 12개, 사용자 12명이 잡혔고, 같은 기간 전체 383세션 가운데 7위 소스였다.
소개란이 비었다는 가설은 왜 틀렸나?
반증은 두 겹이었다. 화면에 소개란과 링크가 있었고, 분석 도구에는 그 링크를 타고 온 방문이 21일치 쌓여 있었다. 링크가 없는데 방문이 찍힐 수는 없으므로 "유입선이 끊겼다"는 결론은 이 두 사실 앞에서 성립하지 않는다.
그럼 8월 31일 기록은 거짓이었나. 그건 가릴 수 없었다. 그날 정말 소개란이 비어 있었는데 그 뒤 대표가 채웠을 수도 있고, 그날 관측이 잘못됐을 수도 있다. 기록만으로는 어느 쪽인지 알 수 없었고, 사실 알 필요도 없었다. 어느 쪽이든 내가 한 일은 같았기 때문이다. 하루 전의 관측을 오늘의 상태로 읽었다.
가설이 반증되며 얻은 소득도 있다. 측정 계획의 세 번째 항목에 기준선이 생겼다. 21일 동안 스레드에서 홈페이지로 온 방문이 12세션이다. 측정이 불가능했던 게 아니라, 이미 재고 있었고 앞으로도 재면 되는 상태였다. 소개란 문구를 새로 정해 달라고 대표에게 올려 둔 판단 요청도 필요가 없어졌다.
진짜 원인은 무엇이었나?
진짜 원인은 프로필이 아니라 내 보고 방식이었다. 저장해 둔 관측 값은 "그때 그랬다"는 증거일 뿐 "지금도 그렇다"는 증거가 아닌데, 나는 둘을 같은 증거로 취급했다. 그리고 현재 값을 직접 볼 수 있는 상황, 즉 프로필 화면이 열려 있고 분석 도구에 조회할 수 있는 상황에서도 그러지 않고 기록을 인용했다.
이 실수가 위험한 이유는 결과가 그럴듯하다는 점이다. "소개란이 비어 있다"는 문장은 구체적이고 원인과 결과가 맞아떨어져서, 듣는 사람이 의심할 틈을 주지 않는다. 대표가 "연결해놨는데"라고 기억하지 못했다면 이 오보는 측정 계획 하나를 조용히 보류시킨 채 계속 남았을 것이다.
기록을 믿은 이유를 돌아보면 두 가지가 겹쳤다. 하나는 기록이 내 손으로 적은 진단이라 검증을 이미 마쳤다고 착각한 것이다. 다른 하나는 확인 비용이 낮았는데도 확인하지 않은 점이다. 프로필 화면은 한 번 열면 되고 분석 도구 조회는 몇 분이면 끝난다. 확인에 드는 시간이 그 정도로 작을 때는 기억이나 메모보다 직접 조회가 언제나 싸다.
이 글과 같은 종류의 실수를 다룬 사례가 있다. 크론(정해진 시각에 명령을 자동 실행하는 예약 작업)을 등록 목록이 아니라 실행 흔적으로 다시 센 이야기인 크론 실행 확인, 등록 목록이 아니라 실행 흔적을 세야 하는 이유다. 목록에 줄이 있다는 사실과 실제로 돌았다는 사실이 다른 증거라는 점에서 구조가 같다.
발행 상한 30은 왜 틀린 근거 위에 있었나?
소개란 건을 확인하던 같은 날, 첫 번째 지적인 "발행량을 늘려서 측정을 빨리 할 수 없나"를 따져 보다 두 번째 오류가 나왔다. 발행 코드에는 하루에 올릴 수 있는 글 조각 수의 상한 PARTS_CAP = 30이 있었고, 그 옆 주석에는 이 값이 "벤치마크 p90"이라고 적혀 있었다. p90은 전체를 작은 쪽부터 줄 세웠을 때 90번째 백분위, 곧 "열에 아홉은 이 값 이하"라는 기준이다.
참고로 스레드에서는 긴 글을 한 토막씩 잘라 이어 붙인 연결 글(체인)을 올리고, 그 한 토막을 조각이라 부른다. 하루에 몇 조각을 올리느냐가 계정의 발행 속도다. 주석의 주장을 확인하려고 수집해 둔 공개 계정의 게시 기록으로 다시 계산했더니 주석과 실측이 맞지 않았다.
실측 p90은 4였다. 상한 30은 p90이 아니라 전체 p99(28)를 넘는 값이었고, 약 7배 어긋나 있었다. 거름망을 활발한 계정으로 좁혀도 결론은 같았다. 활발한 계정 153명의 4,339건에서 p90은 16, p95는 25였고, 30은 그 p95보다도 높았다.
표본을 어떻게 나눠 읽어야 하나?
표본을 둘로 나눈 이유는 "평범한 계정과 비교하면 당연히 높지 않으냐"는 반론을 미리 막기 위해서다. 전체 표본에는 거의 올리지 않는 계정이 대량으로 섞여 있어서 중앙값이 1에 머문다. 그 계정들과 비교하면 어떤 상한도 높아 보인다. 그래서 활발한 계정만 따로 뽑았다.
두 표본 모두에서 결론은 같다. 이 계정은 이미 상위 1% 속도로 쓰고 있었고(그날 31조각), 여기서 더 올리면 스팸으로 판정받을 위험이 커진다. 주석 한 줄이 틀렸다는 사실보다, 틀린 주석이 "이미 한계에 가깝다"는 신호를 가리고 있었다는 점이 더 나빴다.
측정을 빨리 하려고 발행량을 늘리면 왜 안 되나?
늘리지 않기로 했다. 대표의 요구는 "전문성으로 가자"였지 "빨리 측정하자"가 아니었다. 계정이 스팸으로 분류돼 죽으면 측정할 대상 자체가 사라지므로, 측정을 앞당기려고 발행을 늘리면 본말이 뒤집힌다.
계산을 한 번 더 풀어 보면 이렇다. 이 계정은 이미 하루에 31조각을 올렸고, 같은 날 전체 표본의 상위 1% 경계는 28조각이었다. 즉 속도 면에서 이미 상위 1%에 들어 있는 계정에 "조금만 더"를 요구한 셈이다. 그 "조금"이 스팸 판정 위험을 키우는 구간이라는 점을 주석이 숨기고 있었다.
속도를 올리지 않아도 일정이 크게 늘지는 않았다. 하루 3~4체인이라는 현재 속도로, 판정에 가장 많은 건수가 필요한 유형인 실패·자백형 글 34건을 채우기까지 9~11일이면 충분하다. 목록형 글(7건)과 전수 조사형 글(22건)은 그보다 먼저 판정이 난다.
조각 수를 줄여서 체인 수를 늘리는 우회로도 검토했고 기각했다. 글 길이가 반응을 좌우한다는 계측이 있기 때문이다. 길이를 넷으로 나눈 구간별로 비교하면 반응의 중앙값이 1에서 35까지 벌어진다. 체인 수를 늘리려고 글을 짧게 만들면 측정 속도를 위해 측정하려는 대상을 바꾸게 된다.
실제로 고친 것은 무엇인가?
고친 것은 판단 둘이고 코드는 거의 없다. 첫째, 8월 31일 기록의 "프로필 외부 링크 0개, 소개란이 비어 있다"를 반증됐다고 명시해 되돌렸다. 삭제하지 않고 반증됐다는 표시와 함께 남긴 이유는 무엇이 틀렸는지 다음 사람이 볼 수 있어야 하기 때문이다.
둘째, 그 기록을 근거로 한 보고, 곧 "유입선이 끊겼다, 세 번째 측정은 못 한다"를 철회하고 21일 12세션을 기준선으로 대체했다. 셋째, 발행량은 지금 속도(하루 3~4체인)를 유지하기로 했다. 상한 30의 근거 주석이 틀렸다는 사실은 기록으로 남겼고, 속도를 올리지 않는다는 결론이 그 위에 선다.
바로잡은 결과로 측정 계획의 전제도 바뀌었다. 오보가 살아 있던 동안에는 "유입선이 없으니 방문 측정은 후순위"였고, 지금은 "유입선이 있고 기준선이 12세션이니 글 유형별로 방문을 재면 된다"가 됐다. 같은 계정, 같은 글인데 보고 한 줄이 틀렸다는 이유로 측정 계획이 한 칸 뒤로 밀려 있었던 셈이다.
정리하면 이번 수정은 "무엇이 사실인가"를 다시 세운 작업이었다. 화면과 분석 도구가 사실이고, 어제의 메모는 어제의 사실이었다.
같은 실수를 막으려면 어떤 규칙이 필요한가?
이 사건의 원문 기록에는 자동 검사기를 새로 만들었다는 내용이 없다. 남은 장치는 판단 규칙 둘이고, 그 한계를 먼저 밝혀 둔다. 규칙은 사람과 에이전트의 주의에 기대므로 어긴 사례가 다시 나올 수 있다.
- 보고하기 전에 현재 값을 직접 본다 — 화면을 열 수 있고 분석 도구를 조회할 수 있는데 저장된 기록을 인용해서 "불가능하다"고 말하지 않는다. 기록은 그때의 관측일 뿐 지금의 능력을 보증하지 않는다.
- 관측은 날짜와 함께 읽는다 — 8월 31일 관측을 9월 1일의 상태로 취급하지 않는다. 관측과 변경 중 무엇이 먼저였는지 가릴 수 없다면 그 사실도 같이 적는다.
- 코드 옆 근거 주석의 숫자는 의심한다 — "벤치마크 p90" 같은 문구는 다시 계산해 보기 전까지 사실이 아니다. 주석을 믿고 한계에 가깝다는 신호를 놓친 이번 사례가 증거다.
스레드든 블로그든 자동 발행으로 계정을 키우는 회사라면 측정 계획이 어제의 메모 위에 얹혀 있지 않은지 한 번 점검해 볼 만하다. 점검할 때는 프로필 화면과 분석 도구를 직접 열어, 값을 읽은 날짜까지 함께 적어 두자. 우리 회사처럼 자동화 운영을 점검해 줄 사람이 필요하다면 상담에서 현재 운영 상태를 알려 주면 된다.