인스타 닉네임 변경 추적: 확정할 수 있는 경우와 가능성만 표시하는 경우

1. username은 바뀌고 display name은 겹친다

Instagram에서 @username은 사용자가 바꿀 수 있습니다. 표시 이름은 더 자유롭고 동명이인도 흔합니다. 따라서 어제의 old_name과 오늘의 new_name이 같은 사람인지 문자열만으로 확정할 수 없습니다. old_name을 다른 계정이 나중에 가져갈 가능성까지 고려하면 username 자체도 영구 ID가 아닙니다.

프로필 href가 /_u/username 형태로 들어오는 사례가 있지만 여기서 _u는 파서가 username을 찾기 위해 처리하는 경로 형식일 뿐, 뒤 값이 비밀 해시나 불변 고유 ID라는 뜻이 아닙니다. CheckMate는 URL의 첫 경로가 _u이면 다음 경로를 username으로 꺼냅니다. 경로가 유지될 것이라는 보장은 하지 않습니다.

2. 현재 구현의 매칭 우선순위

각 관계 항목에서 title, string_list_data의 value와 href, 선택적 fbid를 보존합니다. 화면에 보여줄 username은 href username을 우선하고, 없으면 title, 그다음 value를 사용합니다. 이 우선순위는 최신 이름을 보장하는 공식 계약이 아니라 관찰한 파일에서 프로필 링크가 가장 직접적인 표시값이었기 때문입니다.

상대 목록에 같은 계정이 있는지 볼 때 현재 항목에 fbid가 있으면 fbid로만 비교합니다. fbid가 다른데 username이 우연히 같아도 맞팔로 합치지 않아 계정 재사용 오매칭을 줄입니다. fbid가 없을 때는 href username, title, value 중 하나라도 상대 목록의 후보와 일치하면 관계를 연결합니다.

이 보수적 선택에는 두 종류의 비용이 있습니다. 같은 사람이지만 한쪽 파일에만 fbid가 있으면 연결하지 못해 현재 비맞팔 후보로 남을 수 있고, 구형 파일에서는 과거 title과 다른 항목의 현재 username이 우연히 같아 잘못 연결될 가능성을 완전히 없애지 못합니다. 그래서 결과에 식별자 불일치 수와 상세 배지를 함께 보여주고, 프로필 확인 없이 자동 조작으로 이어지지 않게 설계했습니다.

if (record.fbid) {
  return otherFbidSet.has(record.fbid)
}

return [hrefUsername, title, value]
  .filter(Boolean)
  .some(identifier => otherIndex.has(identifier))

3. “닉네임 변경됨” 대신 “변경 가능성”이라고 쓰는 이유

한 항목 안에서 href username이 있고 title 또는 value가 모두 다른 경우 isRenamed 플래그를 true로 만듭니다. 이것은 서로 다른 식별자가 공존한다는 관찰이지 Meta가 “이 계정이 닉네임을 바꿨다”고 제공한 이벤트 로그가 아닙니다. 캐시, export 변환, 계정 재사용 같은 다른 원인을 파일만으로 배제할 수 없습니다.

이전 UI의 “닉네임 변경 N건 자동 보정”은 관계 연결과 사건 확정을 섞었습니다. Recovery Release는 fbid 또는 다중 식별자로 관계 계산에 연결한 수를 “파일 사이 식별자 불일치 N건을 연결”이라고 표시하고, 상세 항목은 “닉네임 변경 가능성”으로 바꿨습니다. 사용자는 결과가 왜 달라졌는지 알 수 있고 도구는 증거보다 강한 표현을 피합니다.

4. 프로필이 열리지 않아도 탈퇴·차단을 단정할 수 없다

결과의 프로필 보기는 instagram.com/username을 새 탭으로 엽니다. 페이지가 없다고 나오면 username 변경, 일시 비활성화, 계정 삭제, Instagram의 로그인 제한, 네트워크 오류, 내 계정에서의 차단 등 여러 원인이 가능합니다. 이 한 번의 화면만으로 원인을 구분할 수 없습니다.

반대로 프로필이 열린다고 export 시점부터 지금까지 같은 관계가 유지됐다는 뜻도 아닙니다. ZIP 생성 뒤에 팔로우·언팔·재팔로우가 발생할 수 있기 때문입니다. 중요한 결정을 하기 전에는 현재 Instagram 앱의 관계와 요청 날짜를 함께 확인하고, 자동 언팔을 연속 실행하지 않는 것이 안전합니다.

• 프로필 미표시 = 탈퇴 확정이 아니다.
• username 일치 = 영구적으로 같은 계정이라는 보장이 아니다.
• 현재 비맞팔 = 과거에 나를 언팔한 사건 기록이 아니다.
• 단일 ZIP의 timestamp = 신원 증명 또는 닉변 이벤트가 아니다.

5. 결과가 의심될 때 사용자가 검증하는 순서

먼저 ZIP의 생성 날짜와 분석 날짜를 비교합니다. 다음으로 followers_N 분할 파일이 모두 있는지, HTML이 아닌 JSON인지 봅니다. 결과에서 “식별자 불일치” 안내가 있다면 그 수만큼 관계 계산이 단순 username 비교와 달라졌다는 뜻입니다. 개별 항목의 프로필은 참고하되 상태를 단정하지 않습니다.

실제 변화가 필요한 경우 오늘 ZIP과 다음 시점의 ZIP을 snapshot compare에서 비교합니다. 두 스냅샷 모두 같은 요청 범위와 JSON 형식을 사용해야 차이가 줄어듭니다. 그래도 username 변경·삭제·재가입은 완전히 분리할 수 없으므로 결과를 “변화 후보”로 보고 수동 확인을 거칩니다.

1. 1시점 맞추기

   ZIP 요청·생성 날짜와 현재 앱 상태 사이의 시간을 확인합니다.

2. 2파일 완전성 확인

   모든 followers_N 파일과 following.json이 같은 계정 ZIP에 있는지 확인합니다.

3. 3식별자 안내 읽기

   fbid 또는 다중 후보로 연결된 수와 변경 가능성 배지를 구분합니다.

4. 4두 스냅샷 비교

   실제 변화가 목적이면 같은 조건의 두 ZIP을 비교하고 후보를 수동 확인합니다.

확인한 출처와 검증 방법

• Instagram Help Center — 계정 정보 내보내기 — 공식 export 기능을 확인하고 식별자 해석은 실제 파일 관찰과 분리했습니다.
• CheckMate 이용약관 — 분석 결과의 범위 — 현재 비맞팔과 닉네임 변경 가능성의 한계를 공개합니다.
• CheckMate Snapshot Compare — 단일 ZIP 현재 상태와 두 시점 변화 비교를 구분하는 실제 도구입니다.

자주 묻는 질문

이어 읽기