앱 MVP 사용자 식별: 계정·앱 인스턴스·분석 ID를 나누는 5가지 기준

로그인 기능과 분석 도구를 함께 붙이면 “이 사용자가 누구인가”라는 질문에 하나의 ID만 쓰고 싶어집니다. 그러나 계정을 식별하는 값, 한 번 설치된 앱을 구분하는 값, 분석 도구가 로그인 상태를 연결하는 값, 광고 목적의 식별자는 같은 역할이 아닙니다. 하나로 합치면 로그아웃 뒤 분석, 앱 재설치 뒤 지원, 광고 식별자 재설정 뒤 데이터 결합처럼 서로 다른 일이 한 규칙에 얽힙니다.

이 글은 특정 앱의 개인정보 처리 적합성이나 분석 정확도를 판정하지 않습니다. MVP에서 사용자 식별값의 목적·범위·생성 시점·재설정·전달 대상을 분리해 기록하는 방법을 다룹니다. 실제 수집 항목과 법적 고지, SDK 동작, 접근 권한은 출시 후보와 해당 시점의 공식 자료를 기준으로 별도 확인해야 합니다.

먼저 답할 질문: 이 ID로 무엇을 판단하려는가

식별값을 정하기 전에 “이 값이 없으면 어떤 업무를 할 수 없는가”를 한 문장으로 적습니다. 예를 들어 계정 ID는 로그인한 고객의 주문·문의·권한을 연결하는 서비스 기준일 수 있습니다. 반면 앱 인스턴스 ID는 특정 설치본의 오류·동기화·알림 상태를 점검하는 기술 기준일 수 있습니다. 이 둘을 같은 열에 넣어도 목적이 같아지지는 않습니다.

MVP 문서에는 아래처럼 최소한의 경계를 남겨 두는 편이 좋습니다.

표의 값은 예시입니다. 실제 제품이 어느 값을 쓰는지, 서버·분석 도구·광고 SDK 중 어디로 전달하는지는 별도의 데이터 흐름표에 적어야 합니다. “UUID라서 안전하다” 또는 “익명 ID라서 개인과 무관하다”처럼 이름만 보고 결론 내릴 수는 없습니다.

1. 계정 ID는 서비스 상태를 위한 기준으로 둡니다

로그인한 사용자의 권한, 결제 접근, 팀 소속, 문의 이력처럼 서비스가 책임져야 하는 상태는 보통 계정 단위에서 판단합니다. 이때 필요한 결정은 ID의 형식보다 계정이 아직 없는 방문자와 계정이 있는 사용자를 어떤 상태로 구분할지입니다. 회원가입 전 행동을 제품 분석에 남길 수는 있어도, 그것이 곧 내부 계정이 생겼다는 뜻은 아닙니다.

계정 ID를 설계할 때는 이메일 주소나 전화번호처럼 사람이 읽을 수 있는 값을 그대로 여러 도구에 전달할지부터 정하지 마세요. 내부 서비스 식별자, 표시용 정보, 연락처, 분석 전송값은 서로 다른 목적과 접근 범위를 가질 수 있습니다. 특히 고객지원·결제·분석에서 같은 값을 쓸 필요가 있는지와 누가 결합할 수 있는지를 따로 검토해야 합니다.

제품 문서에는 계정 생성·연결·전환·탈퇴가 일어나는 화면과 서버 상태를 나눠 적습니다. 예를 들어 로그아웃은 현재 기기 화면에서 계정 표시를 없애는 행동일 수 있지만, 탈퇴나 권한 해제와 동일하다고 가정할 수 없습니다. 이 경계를 먼저 정해 두면 이후 분석 ID를 비우는 시점도 더 명확해집니다.

2. 분석 User-ID는 로그인 상태와 함께 설정·해제합니다

Google Analytics의 User-ID 안내는 서비스가 자체적으로 부여한 고유 식별자로 로그인 사용자의 세션·기기·플랫폼 간 행동을 연결하는 용도라고 설명합니다. 또한 사용자가 로그인한 적이 없으면 User-ID 매개변수를 보내지 않고, 로그인했다가 로그아웃하면 `null`로 설정하라고 안내합니다. 즉, 분석 User-ID는 모든 방문자에게 자동으로 붙는 서비스 계정의 대체물이 아니라 현재 로그인 상태를 반영하는 분석 설정입니다.

같은 문서는 `user_id`를 사용자 속성이나 개별 이벤트 매개변수, 맞춤 측정기준으로 다루지 말라고 안내합니다. MVP에서 이를 작업 항목으로 바꾸면 다음 세 가지를 확인하는 일입니다. 로그인 성공 뒤부터 어떤 이벤트가 연결되는지, 로그아웃·계정 전환 뒤부터 어떤 값으로 바뀌는지, 보고서에서 계정 ID를 직접 조회하는 방식으로 운영하려는 요구가 없는지입니다.

이 기준은 특정 SDK 구현 코드를 정답으로 제시하지 않습니다. 웹·앱·서버 측정 방식과 사용 중인 도구에 따라 설정 방법은 달라집니다. 다만 “분석에서 사용자처럼 보인다”는 관찰과 “서비스에서 이 계정이 실제 권한을 가진다”는 판단을 같은 증거로 사용하지 않는 것이 중요합니다. 핵심 흐름의 이벤트 자체는 앱 MVP 핵심 흐름 측정: 출시 전 이벤트 설계 5단계에서 별도로 정리할 수 있습니다.

우리 서비스에 맞는 앱 MVP 측정·데이터 흐름 정리하기

3. 앱 인스턴스 ID는 ‘사람’이 아니라 ‘설치본’의 범위를 확인합니다

Android는 식별값을 고를 때 사용 사례에 필요한 가장 제한적인 범위를 사용하고, 대부분의 비광고 용도에는 Firebase Installation ID(FID)나 비공개 저장소의 GUID를 고려할 수 있다고 안내합니다. 이 문서에서 FID와 GUID는 특정 기기에 설치된 앱 인스턴스를 구분하는 맥락으로 설명됩니다. 따라서 한 사람이 새 휴대폰을 쓰거나 앱을 삭제·재설치할 때 같은 계정과 같은 앱 인스턴스라고 단정할 수 없습니다.

이 차이는 오류 재현과 지원에서 특히 중요합니다. 고객이 “어제부터 안 된다”고 말해도, 지원 담당자가 확인할 대상은 계정 상태일 수 있고 특정 설치본의 앱 버전·동기화 대기열일 수 있습니다. 하나의 긴 식별값만 넘기면 어느 층의 문제인지 되짚기 어렵습니다. 계정 문제, 설치본 문제, 네트워크·서버 문제를 구분한 뒤 필요한 관찰값만 연결하세요.

Android 문서는 식별값의 범위와 재설정 가능성, 지속성이 서로 다른 특성이라고 설명합니다. MVP 체크리스트에는 “앱 삭제 뒤 새 값이 생기는가”, “앱 안 초기화 기능이 값을 바꾸는가”, “같은 계정의 두 기기를 한 사용자로 집계할 때 무엇을 기준으로 삼는가”를 적습니다. 문서상 설계와 실제 SDK가 만든 값은 동일하다고 추정하지 말고, 출시 후보에서 로그와 설정 화면을 따로 확인합니다.

4. 광고 식별자는 광고 목적과 사용자 선택을 분리합니다

광고 식별자는 서비스 계정이나 기술 지원용 설치 ID를 대신하는 만능 키가 아닙니다. Android의 식별자 안내는 Advertising ID를 광고·사용자 프로파일링 용도에 맞는 사용자 재설정 가능 식별자로 설명하고, 사용자의 재설정 의도를 우회해 이전 값과 새 값을 연결하지 말라고 안내합니다. 광고 개인화 선택도 존중해야 한다고 명시합니다.

따라서 광고 캠페인 성과를 보고 싶다는 이유만으로 계정 ID, 앱 인스턴스 ID, 광고 식별자를 한 테이블에서 항상 결합하는 설계를 먼저 택할 필요는 없습니다. 먼저 광고 SDK가 실제로 받는 값, 광고 목적에 필요한 최소 범위, 사용자 선택 변경 뒤 처리, 결합 권한을 정리하세요. Android는 광고 식별자를 개인식별정보나 지속적인 기기 식별자와 연결하는 경우 명시적 동의가 필요한 점도 안내합니다.

이 글은 개별 서비스의 동의 문구나 법적 의무를 판단하지 않습니다. 적용 국가·서비스 모델·SDK 약관·개인정보 처리 방식에 따라 별도 전문 검토가 필요합니다. 여기서 할 일은 ‘광고 분석’이라는 목적을 ‘고객 계정 운영’이나 ‘오류 지원’과 같은 이름으로 넓혀 기록하지 않는 것입니다.

5. 출시 전에는 ID 값보다 경계 변경 시나리오를 검수합니다

식별값 설계는 표 한 장으로 끝나지 않습니다. 실제 앱에서 값이 생성·전달·비워지는 순간을 시나리오로 확인해야 합니다. 아래 검수표는 특정 도구 도입을 지시하는 목록이 아니라, 제품·개발·분석 담당자가 같은 질문을 보도록 만드는 기록 형식입니다.

1. 로그인하지 않은 첫 실행에서 어떤 식별값이 생성되고 어디로 전달되는지 확인합니다.

2. 로그인 성공 뒤 계정 ID와 분석 User-ID가 각각 어떤 목적에 쓰이는지 확인합니다.

3. 로그아웃과 다른 계정 로그인 뒤 이전 분석 연결이 남아 있지 않은지 확인합니다.

4. 앱 삭제·재설치, 기기 변경, 앱 데이터 초기화 뒤 앱 인스턴스 기준이 어떻게 달라지는지 확인합니다.

5. 광고 식별자 재설정 또는 광고 추적 선택 변경 뒤 이전 값과의 연결을 우회하지 않는지 확인합니다.

6. 실제 수집·전송·보관·열람 권한이 설계 문서와 같은지 출시 후보와 운영 환경에서 확인합니다.

검수 결과에는 테스트 계정, 기기·OS, 앱 버전, 실행 시각, 확인한 화면·로그, 미확인 항목을 남기세요. 한 기기에서 로그인 성공을 봤다는 사실은 다중 기기 연결, 광고 측정, 개인정보 적합성, 데이터 삭제 완료를 증명하지 않습니다. 반대로 값 하나를 보내지 않는다고 모든 데이터 흐름이 사라진다고도 단정할 수 없습니다.

자주 묻는 질문

계정 ID를 분석 이벤트마다 보내면 분석 User-ID도 필요 없나요?

그렇게 단정할 수 없습니다. Google Analytics는 `user_id`를 예약된 구성 매개변수로 안내하며, 개별 이벤트 매개변수나 맞춤 측정기준으로 다루지 말라고 설명합니다. 실제 제품의 계정 ID 전송 여부와 측정 도구 설정은 목적·도구 문서·개인정보 검토에 따라 별도 결정해야 합니다.

앱 인스턴스 ID가 있으면 같은 사람을 여러 기기에서 하나로 볼 수 있나요?

아닙니다. Android의 안내에서 FID나 비공개 GUID는 앱 인스턴스 맥락의 식별자입니다. 사람·계정·기기·설치본의 범위는 다를 수 있으므로, 여러 기기를 하나의 사용자로 묶을 기준은 서비스 계정 등 별도 설계와 실제 검증이 필요합니다.

광고 식별자를 재설정한 뒤 이전 광고 ID와 연결해도 되나요?

Android는 사용자의 광고 식별자 재설정 의도를 우회해 새 ID를 이전 ID나 파생 데이터와 연결하지 말라고 안내합니다. 개별 서비스의 적용 조건과 동의는 해당 시점의 정책·법률·SDK 문서를 기준으로 별도 확인하세요.

이 구분만 하면 개인정보 처리나 광고 정책을 충족하나요?

아닙니다. 이 글은 MVP 설계와 QA 기록을 위한 구분입니다. 실제 수집 항목, SDK 설정, 고지·동의, 보관·삭제, 접근 통제, 국가·플랫폼별 요구사항은 서비스의 사실관계와 최신 공식 자료, 필요한 전문 검토에 따라 따로 판단해야 합니다.

확인한 공식 출처

• Google Analytics · Send user IDs — 2026-09-20 확인

• Android Developers · Best practices for unique identifiers — 2026-09-20 확인

우리 서비스에 맞는 앱 MVP 측정·데이터 흐름 정리하기