1P by GN⁺ 13일전 | ★ favorite | 댓글 1개
  • 2026년 4월부터 인증되지 않은 기기는 Element에서 종단간 암호화(E2EE) 메시지를 보내거나 받을 수 없음
  • 이 변경은 Matrix 사양 업데이트에 따른 것으로, 모든 사용자의 대화 보안을 강화하기 위한 조치
  • 기기 인증은 사용자의 각 기기가 실제 본인 소유임을 암호학적으로 증명하는 절차로, 신뢰되지 않은 메시지 표시를 제거
  • 앞으로는 인증된 기기만 대화에 참여할 수 있으며, 경고 아이콘이나 방패 표시는 사라짐
  • 이 조치는 신뢰 기반의 안전한 커뮤니케이션 환경을 구축하기 위한 핵심 단계

보안 업데이트 개요

  • 2026년 4월부터 Element는 인증되지 않은 기기의 종단간 암호화 메시지 송수신을 차단
    • 이는 2025년 10월 Matrix 컨퍼런스에서 발표된 Matrix 사양 업데이트를 따른 조치
    • 사용자는 기존 기기에서 암호화 메시지를 계속 주고받기 위해 기기 인증을 완료해야 함
  • 이 업데이트는 메시지가 실제로 의도한 발신자에게서 온 것임을 보장하는 목적
  • Element는 이를 통해 가장 안전한 커뮤니케이션 기술 제공을 목표로 함

인증되지 않은 기기의 위험성

  • 인증되지 않은 기기는 공격 벡터가 될 수 있음
    • 예를 들어, 대화 중 경고 아이콘이 나타날 때 이는 단순한 미인증 기기일 수도, 계정 탈취 시도일 수도 있음
    • 이러한 경고를 무시하면 네트워크 전반에 보안 위험이 확산될 수 있음
  • Element는 모든 사용자에게 기본적으로 종단간 암호화를 제공하며, 인증 의무화를 통해 불확실성과 악의적 활동 가능성을 제거하려 함

기기 인증의 역할

  • 기기 인증은 각 기기 간의 암호학적 ‘악수(handshake)’ 로, 해당 기기가 사용자 본인 소유임을 증명
  • 인증되지 않은 새 기기에서 보낸 메시지는 신뢰되지 않은 메시지로 표시됨
  • 인증을 의무화함으로써 사용자는 모든 메시지가 신뢰 가능한 상태임을 확신할 수 있음

기본 설계로서의 신뢰

  • 앞으로 기기는 ‘인증됨’ 또는 ‘대화 참여 불가’ 두 가지 상태 중 하나로 구분됨
    • 경고나 방패 아이콘은 더 이상 표시되지 않음
    • 이는 사용자가 경고에 무감각해지는 문제를 방지하기 위함
  • 기기 인증은 개인 보호뿐 아니라 전체 네트워크의 신뢰 환경 강화에도 기여
  • Element는 보안을 최우선으로 하는 시스템 설계를 추진 중이며, 인증 절차는 그 핵심 요소

사용자 조치 사항

  • 이미 기기를 인증하고 복구 키(recovery key) 를 설정한 사용자는 추가 조치 불필요
  • 그렇지 않은 사용자는 다음 단계를 수행해야 함
    • 모바일, 웹, 데스크톱 등 모든 기기의 인증 상태 확인
    • 복구 기능 설정 (선택 사항이지만 강력히 권장)
  • 복구 기능은 새 기기 인증을 단순화하고, 모든 기기를 잃어버린 경우에도 인증 복구 가능
  • 플랫폼별 구체적 절차는 Element의 사용자 문서에서 확인 가능

인증하지 않을 경우의 제한

  • 2026년 4월 이후 미인증 기기의 제한 사항
    • 메시지 전송 불가
    • 수신 메시지의 내용 표시 불가 (메시지가 도착했다는 사실만 확인 가능)
  • 결과적으로 미인증 기기는 E2EE 대화에서 사용할 수 없음
    • 단, 암호화가 비활성화된 대화에는 참여 가능

신뢰 구축과 지원

  • Element는 기기 인증을 통한 신뢰 확보를 안전한 통신의 핵심으로 강조
  • 이 변화는 작지만 보안 수준을 크게 높이는 조치로 평가됨
  • 사용자와 협력해 모든 메시지가 대면 대화만큼 신뢰할 수 있는 수준이 되도록 목표 설정
  • 전환 과정에서 지원팀이 사용자 문의에 대응하며, 원활한 적용을 지원할 예정
Hacker News 의견
  • 3개월 전 서버를 종료하고 커뮤니티를 다시 IRC로 옮겼음
    Podman 컨테이너로 IRC를 돌리던 게 남아 있어서 손쉽게 복귀했음
    매달 기기 인증 오류, 메시지 복호화 실패, UX 문제 등으로 고생했음
    초창기엔 빠르게 발전했지만 최근 몇 년간 UX 개선이 거의 없어 아쉬움
    Matrix와 Element의 관계도 이제는 헷갈림

    • 공개 Matrix 채널에 충격적인 이미지 스팸(CSAM 포함)이 넘쳐남
      개발팀은 무관심해 보이고, 제안된 “policy server”도 미완성 상태임
    • 나는 Element 앱을 설치하고 matrix.org 계정을 만들어 메시지를 보내보려 했지만
      방이 비어 있거나 전송이 멈추는 등 단 한 번도 메시지를 주고받는 데 성공하지 못했음
    • MVP의 정의를 잘못 잡은 게 문제라고 생각함
      “탈중앙화된 JSON 데이터베이스”라는 개념에 집착하다가
      실제 채팅 시스템으로서의 사용성을 놓친 듯함
      여전히 쓰고는 있지만 일반 사용자를 끌어들이기엔 갈 길이 멂
    • IRC로 충분하다면 Matrix는 암호화 기능 등으로 과한 선택일 수 있음
      IRC 기반 커뮤니티를 업그레이드한다면 Jabber(XMPP) 가 더 현실적인 대안이라 생각함
    • 나도 비슷하게 느꼈음
      친구들과 테스트했지만 거친 UX 때문에 다른 메신저보다 불편했고
      IRC 브리지 지원이 끊기면서 쓸 이유가 사라졌음
  • 몇 달 전 내 기기들이 무작위로 인증 해제되었고 복구 키로 로그인했지만 여전히 인증되지 않았음
    iOS, Linux, Windows, Android 간 상호 인증이 전혀 맞지 않았음
    이런 강제 인증 절차는 사실상 비자발적 오프보딩
    문제가 있는 인증 방식이 있다면 블로그로 공지해야 함
    Element를 좋아하지만 이런 부분은 사전 준비가 필요함

    • 인증 기능이 도입된 이후로 끊임없는 문제를 겪고 있음
      가끔은 성공했다가도 바로 로그아웃되고, 예전 기기 인증 팝업이 계속 뜸
      결국 모든 프로필을 잃게 될까 걱정됨
    • 나도 같은 좌절을 겪었음
      가끔 열 때마다 30분씩 문제 해결에 매달려야 했음
      아이디어는 좋지만 노력 대비 보상 비율이 너무 낮음
      OSS 프로젝트 커뮤니케이션에도 악영향을 줌
    • 혹시 자체 서버를 쓰는지 궁금함
      나는 집중적으로 사용하지만 그런 문제는 한 번도 없었음
  • 몇 달 전 Matrix 봇을 구현하려 했는데, Python용 오픈소스 SDK들이
    E2EE와 기기 인증을 전혀 지원하지 않아 끔찍한 경험이었음
    대신 내부 Rust SDK(matrix-rust-sdk)를 발견했는데 꽤 괜찮았음
    Python/Kotlin용 FFI 바인딩도 있었지만 문서가 부족했음
    LLM과 소스코드를 참고해 간신히 동작시켰고, 이모지 인증도 성공했음
    지금은 문서가 많이 개선되고 참고 클라이언트도 제공됨

  • Reddit에서 본 Matrix 비판 글을 읽었는데,
    데이터가 영구 저장·중복되는 구조라 성능과 프라이버시가 낮다고 함
    Signal은 메타데이터조차 보호하지만 Matrix는 방 이름, 참여자, 시간 등이 노출된다고 함
    이게 사실인지, 미래가 있는 프로토콜인지 궁금함

    • Reddit 글이 완전히 틀린 건 아님
      현재 메타데이터 보호 수준은 Signal보다 낮지만 개선 중임
      Matrix는 위협 모델이 다르고, 신뢰 범위를 직접 선택할 수 있음
      소규모 서버로 운영하면 Signal보다 데이터 노출이 적음
      완벽하진 않지만 발전 속도와 방향성은 긍정적으로 봄
    • 방 이름이 암호화되지 않은 걸 보고 충격받았음
      기본적인 프라이버시 요구사항인데도 구현이 느림
      메시지 복호화 문제도 여전함
      그래도 오픈 시스템 중에서는 여전히 최선의 선택지라 생각함
    • Signal도 중앙 권한을 신뢰해야 하고, 여전히 전화번호 기반이라
      SIM 스푸핑 공격에 취약함
    • Matrix는 구조적으로 복잡함
      모듈식·탈중앙화 설계가 장점이자 진입 장벽임
      Signal은 단순한 구조 덕분에 핵심 기능 완성도가 높음
    • Reddit 글 내용은 대체로 맞음
      결국 신뢰할 수 있는 서버를 전제로 한 플랫폼임
  • 이 스레드의 불만에도 불구하고,
    비인증 상태로 로그인해 암호화 메시지를 주고받는 걸 막는 건 합리적이라 생각함
    6년간 Matrix를 써왔는데 인증 과정은 이제 꽤 매끄러움
    QR 코드 로그인까지 완성되면 훨씬 쉬워질 것임

    • 하지만 많은 사용자가 겪는 불안정한 경험에 공감함
      세부 결정은 합리적일지 몰라도 전체적으로 커뮤니케이션 부족
      문서화 미비로 인해 혼란스러움
      자주 쓰는 사람은 괜찮지만 가끔 쓰는 사람은 매번 복구 게임을 해야 함
    • 인증은 암호화 키 교환을 포함함
      로그인 전의 메시지를 복호화할 수 있게 해줌
      인증 단계를 건너뛸 수 있게 한 UX가 문제였음
    • 문제는 정책이 아니라 설명 부족
      블로그에서 인증이 뭔지 명확히 정의했어야 함
  • “인증이란 무엇인가?”라는 질문에

    • Element 공식 문서에 따르면
      새 기기에서 로그인 시 기존 기기로 암호학적 신원 증명을 수행함
    • 새 기기 로그인 시 본인 소유임을 증명하는 절차임
      이모지 비교, QR 코드 스캔, 복구 키 입력 중 하나로 진행됨
      대부분 빠르고 간단하지만 일부 클라이언트는 버그가 있음
    • 제3자 검증은 전혀 아님
      단순히 새 기기를 기존 기기로 승인하는 과정임
      지금까지 써본 암호화 메신저 중 가장 쉬운 인증 방식이었음
    • 현재는 단순한 자기 인증 절차로,
      두 기기에 표시된 이모지가 같으면 승인됨
    • 다행히 Play Integrity 같은 외부 검증은 아님
      새 기기 로그인 시 기존 기기에서 승인만 하면 됨
  • 나는 Thunderbird를 Matrix 클라이언트로 쓰는데
    Element나 Nheko를 열면 서로 인증되지 않았다고 경고
    인증 버튼을 눌러도 아무 반응이 없고, QR 코드도 표시되지 않음
    Matrix의 UX는 정말 악몽 수준임

    • Thunderbird는 아직 베타 버전으로, 버그가 많음
      업데이트가 느려서 사용을 중단했음
    • 나도 같은 상황임
      개선될 기미가 전혀 없음
  • 알파 클라이언트를 써봤는데 인증 팝업이 사라지지 않음
    어떤 클라이언트는 인증 흐름조차 구현되지 않아
    신규 클라이언트 진입 장벽이 더 높아질 것 같음
    클라이언트가 자주 크래시하고, 동기화 지연도 심함
    이런 이유로 Matrix보다는 XMPP가 더 나은 탈중앙 채팅 옵션이라 생각함
    XMPP는 결함을 우아하게 처리하고, 실시간 동기화 문제도 없음

    • 나도 XMPP를 가족과 함께 쓰지만, 웹 인터페이스(converse.js)는 거칠음
      직장 동료를 설득하려면 더 나은 UI가 필요함
    • Element Desktop에서 인증되지 않은 기기 제거로 해결 가능함
      다만 XMPP는 Cross Signing이나 키 백업이 없어
      Matrix만큼의 편의성은 아직 부족함
    • 예전엔 Matrix 팬이었지만 요즘은 흥미가 줄었음
      Element는 무겁고, 다른 클라이언트는 기능 불균형이 심함
      대신 Prosody 서버로 XMPP를 다시 시도했는데
      문서가 다소 불친절하지만 리소스 효율성은 놀라웠음
      XMPP 서버가 저사양에서도 잘 돌아가는 건 인상적임
      클라이언트 쪽은 다소 실망스러웠지만
      문서 개선 여지가 크다고 생각함
      결국 나는 자유·오픈소스 메신저 생태계가 번성하길 바람
  • 최신 Matrix Conference 영상media.ccc.de에 올라와 있음
    흥미로운 내용이 많고,
    직접 서버를 운영하지 않아도 etke.cc 같은 유료 호스팅을 이용할 수 있음

  • 나는 Matrix/Element를 매우 좋아함
    FOSDEM 개발룸용 공간을 여러 개 운영 중인데
    영상 통화까지 완벽하게 작동했음
    다만 더 많은 기능이 추가되길 바람