token-inspector 수동 점검 체크리스트

백필(/reconcile, 과거 토큰 일괄 기록) 전후로 token-inspector.html 화면을 사람이 직접 눈으로 훑어, 숫자로는 안 잡히는 이상 신호를 찾는 절차. 개발 지식이 없어도 이 문서만 보고 진행할 수 있도록 작성했다.

2026-08-19 · 대상: 팀 전원(비개발자 포함) · 기준: 표본 개수를 정하지 않고, C-1~C-6 × 플랫폼 8종 조합이 한 번씩은 확인됐는지로 커버리지를 잡는다

§0 시작하기 전에

필요한 건 브라우저와 접속 주소뿐이다. 로그인·설치·개발 도구 전부 필요 없다 (화면 맨 위 ⚙ Ops 탭만 예외 — 그 탭은 실제로 재시도를 실행하는 쓰기 기능이라 이 체크리스트에서는 누르지 않는다).

• 개발팀에게 받은 token-inspector 주소를 브라우저 주소창에 입력해서 연다
• 화면 왼쪽에 토큰(코인) 목록이 뜨는지 확인한다 — 안 뜨면 진행하지 말고 개발팀에 알린다

§1 화면 첫걸음

1. 화면 맨 위에 탭이 여러 개 있다. 아래 6개 중 Tokens부터 시작한다.
2. 왼쪽 목록에서 토큰(코인) 하나를 클릭하면 오른쪽에 그 토큰의 상세 정보가 펼쳐진다.
3. 아래 카테고리(C-1~C-6)는 전부 이 상세 화면, 또는 Contents/Venues/Accounts 탭에서 확인한다.

이 예시에서 url 3/4는 "URL 4개 중 3개가 정상 수집됐다"는 뜻이고, 아래 아이콘 배지 줄은 어떤 소셜이 걸려 있고 각각 어떻게 끝났는지를 보여준다. 배지가 회색이거나 빨간색이라고 무조건 버그는 아니다 — §5(C-5)에서 플랫폼별로 정상 형태를 미리 확인하고 진행한다.

C-1 URL과 실제 게시물이 맞는지

확인하는 것: 상태가 "정상 수집"으로 표시된 URL을 열어보면, 그 URL이 가리키는 진짜 게시물·채널과 화면에 뜬 카드 내용이 실제로 일치하는가.

왜 사람이 봐야 하나: 자동 감사는 "행이 있다/없다"만 센다. 그 행의 텍스트·사진이 그 URL과 진짜 관련 있는 내용인지는 못 본다.

어디서 보는가

1. 토큰 상세 화면에서 Social URLs 표를 찾는다.
2. Status 칸이 초록 배지인 행을 하나 고른다. URL 칸의 링크를 눌러 원본 게시물을 새 탭에서 연다.
3. 아래로 스크롤해 Linked Contents 섹션에서 같은 URL의 카드를 찾아 두 화면을 나란히 비교한다.

• Status가 초록(ok)인 URL을 하나 골라 원본 링크를 새 탭에서 열었다
• 원본 게시물의 작성자·글 내용이 카드에 뜬 것과 동일하다
• 카드에 사진/영상이 있어야 할 자리에 빗금(깨짐) 표시만 있지 않다

C-2 인용·답글 사슬이 실제 관계와 맞는지

확인하는 것: 어떤 글이 다른 글을 인용/리트윗/답글했다고 표시돼 있을 때, 실제로 그 관계가 맞는가.

어디서 보는가

1. Linked Contents 섹션에서 "인용 N" 배지가 붙은 행을 찾는다.
2. 그 행을 클릭하면(▸ 화살표) 안쪽에 인용된 글 카드가 중첩되어 펼쳐진다.
3. 바깥 카드(원글)와 안쪽 카드(인용/답글)를 읽고 실제로 서로 관련된 대화인지 확인한다.

• "인용 N" 배지가 붙은 행을 펼쳐, 안쪽 카드가 실제로 바깥 카드와 대화가 이어지는 내용이다
• 서로 무관한 글 두 개가 인용 관계로 묶여 있지 않다

C-3 같은 사람·채널이 여러 장으로 쪼개져 있는지

어디서 보는가

1. 상단 탭에서 Accounts(계정) 또는 Venues(채널·커뮤니티) 탭을 누른다.
2. 플랫폼 아이콘 칩(🐦 x, 📷 ig 등) 중 하나를 눌러 그 플랫폼만 걸러 본다.
3. 목록을 위에서 아래로 훑으며, 프로필 사진·이름·핸들이 서로 비슷한 두 줄이 있는지 찾는다.

→ 위 예시처럼 이름·프로필 사진이 똑같은데 핸들만 미세하게(_ 하나) 다른 두 줄이 보이면 정규화가 같은 사람을 서로 다른 계정으로 쪼갰을 가능성이 있다. (그림의 빨간 테두리는 실제 화면에 없다 — 이 문서에서 의심 사례를 표시하려고 넣은 것이다.)

• Accounts 탭에서 플랫폼 하나를 골라 목록 전체를 훑었다
• Venues 탭에서도 같은 방식으로 훑었다
• 프로필 사진·이름이 겹치는데 줄이 두 개 이상인 항목이 없다

C-4 채널/커뮤니티(Venue) 정보가 말이 되는지

확인하는 것: 텔레그램 채널, X 커뮤니티 같은 "장소" 정보가 이름·설명 없이 껍데기로만 남아있지 않은지, 종류(subtype) 분류가 실제 성격과 맞는지.

어디서 보는가

1. 토큰 상세 화면의 Venues 섹션, 또는 상단 Venues 탭.
2. 행을 클릭해 펼치면 이름·설명·인원 수가 보인다.

• 이름이 채워져 있다 (링크 원문 값만 나오는 껍데기 행이 아니다)
• 인원 수(members)가 0이거나 비정상적으로 크지 않다
• 종류(subtype 배지)가 실제로 그 채널의 성격과 맞는다 — 예: 공지용 채널인데 "guard_group"(가드 포털)로 분류돼 있지 않다

C-5 플랫폼별 "정상 형태" 참고표

플랫폼마다 원래부터 만들지 않는 게 있다. 아래 표에 없다고 표시된 칸은 결함이 아니라 설계다 — 이걸 모르고 보면 정상을 결함으로 오인하기 쉽다.

• 위 표를 먼저 훑고, "없어야 정상"인 칸을 결함으로 보고하지 않는다

C-6 필드가 정확히 매핑됐는지 (Metrics · data)

확인하는 것: C-1이 "카드 전체가 맞는 게시물을 가리키는가"를 봤다면, 이건 한 단계 더 들어가 카드 안 개별 숫자·값 하나하나가 원본과 맞는지, 그리고 그 필드가 애초에 왜 그 이름으로 저장되는지 확인하는 항목이다. C-1보다 시간이 더 걸리므로 의심스러운 카드를 발견했을 때만 추가로 연다 — 모든 카드에 매번 적용하는 항목이 아니다.

어디서 보는가

1. 콘텐츠/계정/채널 카드 안의 메트릭 숫자 그리드(조회수·팔로워·멤버 수 등)를 원본 게시물·프로필과 대조한다.
2. 카드 맨 아래 ▸ 데이터 data{} · N개 필드 를 클릭해 펼치면, 그 플랫폼 고유 필드가 키-값 표로 그대로 나온다.
3. 아래 표에서 해당 플랫폼의 문서 두 개를 연다 — ①원본 필드 근거(그 플랫폼 API/응답이 실제로 뭘 주는지)와 ②매핑 결정(그중 무엇을 왜 그 이름으로 저장하기로 했는지)이다. 펼친 표의 키 이름과 문서에 적힌 필드명을 대조한다.

플랫폼별 근거 문서

• 의심스러운 카드 하나를 골라 data{}를 펼쳤다
• 해당 플랫폼의 근거 문서를 열어 필드 이름을 대조했다 — 문서에 없는 낯선 키가 없다
• 메트릭 숫자가 원본과 자릿수 단위로는 맞는다

§2 이상을 발견했다면

1. 해당 화면을 스크린샷으로 캡처한다.
2. 토큰 주소(또는 문제가 된 계정/채널의 platform_key)를 함께 적는다.
3. 어떤 카테고리(C-1~C-6)에서 발견했는지 한 줄 적는다.
4. 담당 개발자에게 위 세 가지와 함께 공유한다. 직접 고치거나 재시도 버튼을 누르지 않는다 — 원인 파악 전에 데이터를 건드리면 재현이 어려워진다.

근거: public/token-inspector.html(2026-08-19 기준 렌더링 로직) 직접 검토. 자동 감사 범위는 docs/features/production-recording-audit/design.md §3 기준으로 구분. 배지 색상·아이콘은 실제 화면 CSS 값을 그대로 사용했다(스크린샷은 아니다).