개인정보 라벨은 조사할 공개 정보이지, 앱이 아는 모든 것을 측정한 결과가 아닙니다.
“데이터를 가장 적게 수집하는 메신저”의 보편적인 승자를 타당하게 정하려면 먼저 무엇을 세는지 정의해야 합니다. 가입 식별자, 주소록 데이터, 보관된 연결 기록, 광고 목적 사용, 메시지 내용 중 무엇을 뜻할까요? 개인정보 보호 라벨은 유용한 출발점이지, 앱이 처리하는 모든 것을 측정한 결과가 아닙니다.
이 안내서는 공개된 정보를 비교하는 방법을 설명합니다. 모든 메신저에 대한 완결된 독립 감사가 아니며, Livara나 경쟁 제품에 최소 데이터 수집 배지를 부여하지도 않습니다.
항목 수를 세기 전에 라벨을 읽으세요
Apple의 앱 개인정보 보호 항목과 Google Play의 데이터 보안 항목은 개발자의 신고에 기반하지만 정의가 다릅니다. Apple의 지침은 사용자와 연결된 데이터, 추적, 수집 목적을 구분합니다. 기기 안에서만 이루어지는 처리는 수집으로 보지 않으며, 일부 일시적 처리와 선택적 공개에는 특정 예외가 있습니다.
Google의 지침에도 예외가 있습니다. 중간자가 읽을 수 없고 조건을 충족하는 종단 간 암호화 데이터는 수집 데이터 공개 대상에서 제외되며, 일부 서비스 제공업체로의 전송은 공유로 계산하지 않습니다. 스토어 설명의 “전송 중 암호화”는 종단 간 암호화를 보장하는 말이 아닙니다. 따라서 빈 항목이 네트워크 요청이나 서비스 제공업체 관계가 없다는 증거는 아닙니다.
Apple의 체크 항목 수와 Google의 체크 항목 수를 비교해 승자를 선언하지 마세요. 같은 스토어, 날짜, 지역, 기능 사용 가정을 기준으로 비교하세요.
다섯 층으로 살펴보는 개인정보 보호 비교
| 근거 | 유용한 질문 | 이것만으로는 확인할 수 없는 것 |
|---|---|---|
| 스토어 라벨 | 어떤 데이터 유형과 용도를 신고했는가? | 완전한 정확성이나 실제 보관 기간 |
| 개인정보 처리방침 | 누가 어떤 목적으로 얼마 동안 데이터를 받는가? | 구현이 방침과 일치하는지 여부 |
| 기기 권한 | 앱이 연락처, 위치, 마이크, 사진에 접근할 수 있는가? | 이미 업로드된 데이터에 무슨 일이 있었는지 |
| 프로토콜 문서 | 어떤 영역과 키가 내용을 보호하는가? | 모든 기기나 소프트웨어 빌드의 보호 |
| 독립 평가 | 어떤 버전과 구성요소를 시험했고 무엇을 수정했는가? | 향후 버전의 영구적인 보안 |
이 층들은 서로 다른 질문에 답합니다. 오픈 소스 클라이언트는 살펴볼 수 있지만, 그 사실만으로 실제 서버의 보관 방식을 알 수는 없습니다. 감사는 암호 기술을 다루면서 분석 기능은 살피지 않을 수 있습니다. 어느 쪽이든 개인정보 보호 점수로 쓰기 전에 범위를 읽으세요.
이 비교 기록표를 활용하세요
검토 중인 각 앱에 대해 다음을 개인적으로 기록하세요. 날짜를 적은 짧은 기록은 근거 없는 순위보다 유용합니다.
| 항목 | 기록할 내용 |
|---|---|
| 제품과 플랫폼 | 정확한 앱, 스토어 링크, 운영체제와 버전 |
| 관찰 날짜 | 라벨과 방침을 확인한 날짜 |
| 가입 | 필수 및 선택 전화번호, 이메일, 결제 식별자 |
| 상대 찾기 | 주소록, 사용자 이름, QR 코드, 초대 링크, 계정 ID |
| 기술 기록 | 신고된 IP, 기기, 진단, 사용 데이터 |
| 보관 | 명시된 기간, 삭제 조건 또는 “명시되지 않음” |
| 기능별 예외 | 백업, 봇, 기업과의 상호작용, 결제, 공개 채널, 통화 |
| 근거의 공백 | 문서가 답하지 않는 내용 |
방침에 데이터를 “필요한 만큼” 보관한다고만 되어 있다면 기간을 만들어 내지 말고 정확한 기간을 알 수 없다고 표시하세요. 업데이트 뒤 라벨이 바뀌면 비교를 해석할 수 있도록 메모에 이전 날짜도 남기세요.
전화번호 불필요는 한 가지 차원이지 전체 결과가 아닙니다
Session과 SimpleX는 전화번호 기반 신원 없이 연결하는 방법을 제공합니다. Threema는 전화번호나 이메일 연결을 선택 사항으로 둡니다. Livara의 공개 문서는 전화번호나 이메일 없는 가입을 설명하지만 라우팅 및 멤버십 메타데이터도 설명합니다. 이 구조들을 서로 바꿔 쓸 수 있는 동일한 것으로 취급해서는 안 됩니다.
Signal은 이제 선택 가능한 Android 베타의 전화번호 없는 가입 경로를 문서화합니다. 그렇다고 모든 Signal 버전이나 기존 계정이 번호 없이 사용된다는 뜻은 아닙니다. 번호 기반 계정의 사용자 이름과 번호 없이 계정을 만드는 것은 다른 기능입니다.
번호가 없어도 재사용한 프로필 사진, 결제 계정, 공유 파일, IP 주소, 대화 맥락이 계정과 사람을 연결할 수 있습니다. “전화번호 불필요”는 완전한 익명성의 증거가 아닙니다. 별개 문제인 라우팅 정보에 대해서는 메시징 메타데이터 설명을 참고하세요.
주소록을 노출하지 않고 연락처 접근을 시험하는 방법
- 공식 앱을 설치하고 처음에는 연락처 권한을 거부하세요.
- 지원되는 식별자, 초대, QR 코드를 사용해 동의한 시험용 연락처 한 명을 추가하세요.
- 주소록 접근 없이 일반적인 메시징이 작동하는지 확인하세요.
- 운영체제 권한뿐 아니라 앱의 연락처 동기화 설정도 살펴보세요. 둘이 항상 같은 제어는 아닙니다.
- 이전에 연락처를 동기화했다면 별도의 삭제 옵션이나 문서화된 요청 절차를 찾으세요. 권한 철회는 앞으로의 기기 접근을 제한하지만 서버의 사본까지 반드시 없애지는 않습니다.
앱이 주소록을 업로드하는지 알아보겠다는 이유만으로 주소록을 업로드하지 마세요. 권한 요청은 요청된 접근을 보여 줄 뿐 완전한 데이터 흐름 감사가 아닙니다. 네트워크 검사로 목적지와 시점을 볼 수는 있지만, 암호화 때문에 전송된 필드를 이해하지 못할 수 있습니다.
E2EE가 비교에서 다루지 않는 것
종단 간 암호화는 참여하는 종단점 사이의 적용 대상 내용을 보호합니다. 계정 식별자, 연결 시각, 그룹 멤버십 기록, 푸시 토큰 데이터를 자동으로 없애지는 않습니다. 또한 암호화된 대화 밖의 봇, 업무 도구, 지원 서비스로 의도적으로 보낸 사본을 보호하지도 않습니다.
특히 Livara의 보안 문서는 암호화된 직접 메시지와 호환되는 비공개 그룹을 서버가 읽을 수 있는 공개 채널과 구분합니다. 하이브리드 키 합의는 내용 보호에 관한 주장이지, 다른 모든 메신저보다 메타데이터를 적게 수집한다는 증거가 아닙니다. 이 글은 해당 서버의 동작을 독립적으로 측정하지 않았습니다.
자신의 용도에 필요한 최소 데이터를 선택하세요
가장 숨기고 싶은 정보부터 시작하세요. 전화번호라면 번호 없는 가입을 시험하세요. 주소록이라면 수동으로 상대를 찾는 기능을 확인하세요. 클라우드 저장소의 읽을 수 있는 대화 기록이라면 백업을 별도로 조사하세요. 연결 메타데이터라면 암호 목록 대신 라우팅과 보관 설계를 읽으세요.
마지막으로 유용한 질문은 이것입니다. 내게 필요한 바로 그 기능을 사용할 때 이 서비스는 무엇을 알게 되며, 그중 어떤 공개를 피할 수 있을까? 이 질문은 하나의 “최소 데이터” 트로피보다 정직한 결정을 이끌어 줍니다.
