Threads URL 분석기, 공개 데이터만으로 어디까지 가능한가

빌더로그에는 /analyzer/ 와 /ko/analyzer/ 라는 경로가 하나 있어요. 스레드 게시물 URL을 하나 넣으면 뭔가 보여주는 페이지인데, 이번 편에서는 이게 실제로 어디까지 가능한지 정직하게 정리해보려고 해요.

URL 하나 넣으면 뭐가 나오나

애널라이저는 이름 그대로 단순해요. 게시물 URL을 하나 받아요. 여러 개 넣거나 계정 전체를 긁어오는 구조가 아니에요. 저는 처음 설계할 때부터 “하나만 정확하게”를 목표로 잡았어요. 이것저것 다 되는 척하는 것보다, 뭐가 안 되는지 명확한 게 낫다고 생각했거든요.

기능을 넓히기보다 경계를 명확히 하는 게 먼저였어요.

공개 미리보기와 계정 승인 데이터는 다른 길로 갑니다

여기가 이번 편의 핵심이에요. 겉으로 보면 “URL 넣고 결과 보기”로 똑같아 보이는데, 내부적으로는 두 경로가 완전히 분리돼 있어요.

하나는 공개 미리보기 경로예요. 로그인이나 별도 인증 없이 누구나 접근 가능한 데이터만 가져와요. 게시물이 공개돼 있고 접근 가능한 상태라면 미리보기 형태의 정보가 나오는 구조예요.

다른 하나는 계정 승인이 필요한 경로예요. 이건 사용자가 자기 계정으로 권한을 부여했을 때만 열리는 길이에요. 저는 이 두 경로를 처음부터 섞지 않으려고 했어요. 왜냐면 섞는 순간 “이게 공개 정보야, 아니면 승인받은 정보야?”를 사용자도 저도 헷갈리게 되거든요.

같은 결과 화면이라도 데이터가 어디서 왔는지는 완전히 다른 문제예요.

왜 이렇게 나눴나

편의점 1+1 행사 앱을 상상해보면 이해가 쉬워요. 앱에 진열대 사진을 올리면 “이 상품 지금 몇 개 남았어요”라고 알려주는 기능이 있다고 쳐요. 그런데 그 정보를 누구나 볼 수 있는 진열대에서 가져온 건지, 아니면 특정 매장 직원이 권한을 준 재고 시스템에서 가져온 건지는 완전히 다른 이야기잖아요. 사용자 입장에서 그 출처를 모른 채 결과만 보면, “왜 내 URL은 더 자세히 나오고 저 URL은 안 나오지?” 하는 혼란이 생겨요.

저는 이걸 미리 나누지 않았다면 나중에 훨씬 골치 아파졌을 거라고 생각해요. 경로가 섞인 채로 커지면 어디서부터 풀어야 할지 감이 안 잡히거든요.

경계를 나중에 긋는 것보다 처음부터 긋는 게 훨씬 쉬워요.

지금 상태에서 말할 수 있는 것과 없는 것

이 글에서 분명히 하고 싶은 건, 애널라이저가 몇 명이 썼는지, 얼마나 정확한지, 얼마나 걸렸는지에 대해서는 아직 검증된 수치가 없다는 점이에요. 파이프라인은 Astro로 짜여 있고 Cloudflare Pages에 올라가 있어요. 콘텐츠나 요약 관련 작업에는 claude-sonnet-4-6을 쓰고 있고요. 하지만 사용자 수나 비용, 실험 기간 같은 건 아직 말할 단계가 아니에요.

저는 이런 부분을 억지로 채워 넣기보다 “아직 모른다”고 쓰는 게 이 시리즈의 원칙에 더 맞다고 생각해요. 숫자가 없으면 없는 대로 두는 게, 나중에 실제 데이터가 쌓였을 때 더 믿을 만한 글이 될 거라고 봐요.

모르는 걸 아는 척하지 않는 것도 결국 영수증이에요.

Threads URL 분석기 직접 확인

이어지는 기록

• 예약 작업 모니터링 체크리스트: 실행보다 공개 결과가 먼저
• 무료 플랜 4개를 조합했더니 어느 날 데이터 312건이 사라졌다