메신저의 기본 설정은 대화 유형을 명시해야 의미가 있습니다. 같은 제품 안에서도 개인 대화, 공개 커뮤니티, 클라우드 기록, 파일 드라이브, 녹음·녹화는 서로 다른 보안 모델을 사용할 수 있습니다.
다음 비교는 서비스 10종을 다루며 설정 후 가장 먼저 살펴볼 항목에 초점을 맞춥니다. 2026년 10월 24일에 확인한 공식 문서를 반영한 것으로, 이들이 ‘가장 안전한’ 앱 10종이라는 주장이나 모든 클라이언트를 직접 감사한 결과가 아닙니다.
메신저 10종의 기본 암호화
| 서비스 | 문서에 설명된 보호 | 먼저 확인할 예외 또는 항목 |
|---|---|---|
| Signal | Signal 대화는 설계상 E2EE | 연결된 기기와 사용하는 백업·복구 방법 확인 |
| 개인 메시지와 통화는 E2EE | 암호화된 온라인 백업 설정을 별도로 확인 | |
| Telegram | 일반 Cloud Chat이 아닌 Secret Chat에서 E2EE 제공 | Secret Chat은 일대일이며 기기 종속적. 그룹은 클라우드 모델 사용 |
| Messenger | Meta는 개인 메시지의 기본 E2EE를 문서화 | 실제 대화와 기능의 상태 확인 |
| Apple 메시지/iMessage | iMessage는 E2EE이며 다른 전송 방식에는 각자의 규칙이 있음 | SMS/MMS는 E2EE가 아님. 암호화된 RCS에는 지원 소프트웨어와 서비스 제공자 필요 |
| Element/Matrix | Element는 기본 E2EE를 설명하며 암호화된 방 지원 | 암호화되지 않은 방도 존재할 수 있음. 방 구성과 연동 기능이 중요 |
| Wire | 대화 메시지, 통화, 파일은 상시 E2EE 사용 | Wire Drive 파일·폴더는 다른 전송 및 저장 암호화 모델 사용 |
| Threema | 직접 대화, 그룹, 미디어를 포함한 통신에 E2EE | 신원·그룹 백업과 메시지 기록 복구를 구분 |
| Session | 비공개 대화와 그룹은 E2EE | Community는 같은 E2EE 경계를 갖지 않음 |
| Livara | 공개된 LVR1/LGS1 보호는 지원되는 비공개 대화에 적용 | 채널은 공개이며 호환되지 않는 구형 그룹은 E2EE 범위 밖임을 명확히 표시 |
짧은 점검표에 ‘예’라고만 적으면 이러한 차이 대부분이 가려집니다. 주요 버전 출시 후 동작을 다시 확인할 때도 링크된 문서가 적절한 확인 장소입니다.
로고가 아닌 대화부터 살펴보기
소규모 팀이 계약서 초안을 공유한다고 가정해 보세요. 비공개 초대 링크는 누가 참여할 수 있는지 제어하지만 그 자체로 E2EE를 증명하지는 않습니다. 대중을 대상으로 하는 앱도 실제로 암호화된 비공개 대화를 제공할 수 있으며, 개인정보 보호를 중시하는 앱에도 의도적으로 공개된 공간이 있을 수 있습니다.
계약서를 보내기 전에 정확한 방이나 대화와 그 암호화 상태를 확인하세요. 그다음 수신자를 확인하세요. 암호화는 권한 있는 수신자를 위해 메시지를 보호하지만, 잘못 받은 사람이 파일을 잊게 만들 수는 없습니다.
Apple 메시지의 RCS에는 이제 더 정확한 설명이 필요합니다
‘파란색은 암호화, 녹색은 절대 암호화되지 않음’이라는 낡은 단순화는 현재 기능을 놓칩니다. Apple은 iOS 26.5부터 지원 네트워크 제공자 환경에서 베타 버전의 암호화된 RCS를 설명합니다. 모든 참여자의 제공자가 암호화를 지원해야 하며, 적용될 때 대화에 암호화 표시가 나타납니다. SMS와 MMS는 여전히 E2EE 범위 밖입니다.
따라서 비교에는 검토 날짜와 대화별 확인이 필요합니다. 전송 방식 이름이나 인터페이스 색상만으로는 충분하지 않습니다.
기업용 기능은 별도의 신뢰 경계를 가질 수 있습니다
제품은 암호화 메시지 기능과 함께 파일 드라이브, 규정 준수 연동, 보관용 봇, 녹음·녹화 기능을 추가할 수 있습니다. 각각을 데이터가 전달되는 대상으로 평가하세요. Wire가 공개한 Drive 예외는 ‘파일이 암호화된다’고 말할 때 기능 이름이 필요한 이유를 보여 주는 구체적인 사례입니다.
Matrix 배포 환경에서는 방 구성과 콘텐츠를 받는 모든 연동 기능을 살펴보세요. 메시지 복호화 권한을 받은 연동 기능은 사람이 아닌 소프트웨어일지라도 수신자 집합의 일부입니다.
어떤 메신저든 설치 후 확인할 네 가지
1. 계정과 기기의 경계를 정합니다. 제공자가 지원하는 로그인 보호를 사용하고 기기 목록을 검토하세요. 계정 접근, 기기 승인, 과거 복호화 키의 보유는 서로 관련되지만 별개의 사항입니다.
2. 복구에 의존하기 전에 시험합니다. 복구 대상이 신원, 연락처, 구성원 관계, 메시지 기록 중 무엇인지 확인하세요. 복구 문구가 있다는 이유만으로 이전 기기를 지우지 마세요.
3. 대화 밖의 사본을 검토합니다. 다운로드, 내보내기, 알림, 백업, 수신자의 화면 캡처는 별도의 노출 경로를 만들 수 있습니다.
4. 민감한 대화에서는 상대방을 확인합니다. 적절한 경우 신뢰할 수 있는 독립된 채널을 통해 앱 문서에 명시된 키 확인 방법을 사용하세요. 키 변경 알림은 정상적일 수 있지만, 설명되지 않는 변경에는 주의가 필요합니다.
이 점검표에서 Livara의 위치
Livara의 보안 문서는 하이브리드 직접 세션과 발신자 키 비공개 그룹을 설명하면서 운영 메타데이터와 공개 채널을 인정합니다. v7은 암호화 신원을 복구하며 대화 기록은 복구하지 않는다고 명시합니다. 위협 모델 역시 악성코드나 수신자의 평문 노출에 대한 보호를 제외합니다.
이러한 한계는 ‘항상 안전’이라는 표시 아래 숨길 것이 아니라 기능과 함께 평가해야 합니다. 문서에 명시된 경계가 실제로 필요한 대화에 맞는 앱과 작업 방식을 선택하세요.
