# Matrix를 포기한 이유 (2024)

> Clean Markdown view of GeekNews topic #25339. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=25339](https://news.hada.io/topic?id=25339)
- GeekNews Markdown: [https://news.hada.io/topic/25339.md](https://news.hada.io/topic/25339.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-12-26T08:35:21+09:00
- Updated: 2025-12-26T08:35:21+09:00
- Original source: [forum.hackliberty.org](https://forum.hackliberty.org/t/why-we-abandoned-matrix-the-dark-truth-about-user-security-and-safety/224)
- Points: 1
- Comments: 1

## Topic Body

- **Matrix 프로토콜의 구조적 보안 한계**와 **운영상의 문제**로 인해 Hack Liberty 커뮤니티가 **SimpleX**로 이전함  
- **메타데이터 노출**, **관리자 권한 남용**, **암호화 취약점** 등으로 인해 사용자 프라이버시와 안전이 심각하게 훼손됨  
- **Matrix.org 조직**이 수집하는 개인 데이터와 **Cloudflare 중간자 개입**, **Tor 브라우저 지원 중단** 등도 신뢰 저하 요인으로 지적됨  
- **SimpleX**는 사용자 식별자 없이 메시지를 전달하고, **2-hop onion 라우팅**과 **포스트 양자 암호화 키 교환**으로 보안을 강화함  
- 이러한 전환은 **탈중앙화 커뮤니티의 보안·프라이버시 확보**를 위한 실질적 대안으로 제시됨  

---

### 연합형 프로토콜의 한계
- 연합형(federated) 네트워크는 여러 서버 간 상호작용을 통해 검열 저항성을 제공하지만, **설계상 근본적인 보안 문제**를 내포함  
  - 2년 이상 Matrix와 Lemmy 같은 공개 연합 서비스를 운영한 결과, **모든 연합형 프로토콜이 공통적으로 갖는 구조적 결함**이 확인됨  

### Matrix 프로토콜의 문제점

#### 메타데이터 노출
- Matrix는 **메시지 송신자, 닉네임, 프로필 사진, 반응, 읽음 표시, 타임스탬프** 등이 암호화되지 않음  
  - 메시지 검증, 성능 요구, 프로토콜 설계 미비 등으로 인해 일부 메타데이터 노출이 **의도적 혹은 설계적 결함**으로 존재  
  - 예시 링크로 실제 누출 사례가 제시됨  

#### 관리자 중간자 공격(Admin in the Middle)
- 악의적인 서버 관리자는 **Synapse 데이터베이스 조회**만으로 사용자 정보, 반응, 방 메타데이터 등을 수집 가능  
  - **사용자 사칭**, **방 주제 변경**, **임의 초대·추방**, **권한 조작** 등 적극적 공격 수행 가능  
  - 새 기기를 추가해 **E2EE 메시지 접근**도 가능하며, 사용자 경고를 무시하도록 설정할 수도 있음  

#### 프로토콜 구조적 약점
- Matrix는 **부분 복제 그래프 데이터베이스** 형태로 동작하며, 다음과 같은 22가지 주요 취약점이 지적됨  
  - **삭제 불가 이벤트**, **스팸 취약성**, **이력 불일치**, **메시지 위조 가능성**, **선택적 암호화**, **서명 불일치**, **Split-brain 방 생성**, **불법 미디어 복제 위험** 등  
  - **서버 간 상태 불일치**로 인해 관리 권한 상실이나 방 폐쇄 불가 문제가 발생  

#### Megolm 암호화 취약점
- **Matrix의 Megolm 프로토콜**에서 다수의 **실질적 암호학적 취약점**이 보고됨  
  - **기밀성 붕괴**, **검증 공격**, **신뢰된 사칭**, **IND-CCA 공격** 등 다양한 공격 시나리오 존재  
  - 공격은 서버 협조를 전제로 하며, **Element 클라이언트의 핵심 라이브러리(matrix-js-sdk 등)** 에서 재현 가능  

#### 리소스 과소비
- **Synapse 서버**는 높은 CPU, 메모리, 디스크, 대역폭을 요구  
  - 사용자 수에 따라 4~12개의 인스턴스가 필요하며, **운영 비용이 과도함**  

### Matrix.org 조직의 문제

#### 데이터 수집
- **matrix.org**와 **vector.im**은 사용자 **이메일, 전화번호, IP, 기기 정보, 사용 패턴, 대화방 ID** 등을 정기적으로 수집  
  - 기본 설정에서 개인정보가 공개되며, 업로드된 파일·이미지·프로필 정보가 **공개 접근 가능**  
  - 자체 서버를 사용하더라도 **중앙 서버로 민감 데이터가 전송됨**  

#### 아동 성착취물 유통
- **Matrix.org의 느린 대응**으로 인해 수만 명의 **소아성애자들이 불법 콘텐츠를 유포**  
  - **방 폐쇄 불가**, **미검증 미디어 업로드**, **자동 복제 기능**으로 인해 **불법 자료가 연합 전체에 확산**  
  - 각 홈서버가 **불법 콘텐츠를 호스팅할 가능성**이 높음  

#### Cloudflare 중간자 개입
- `matrix.org`와 `vector.im`의 TLS 트래픽이 **Cloudflare에서 종료됨**이 확인되어, **중간자 공격 가능성** 존재  

#### Tor 브라우저 지원 중단
- **Element 웹클라이언트**가 Tor 브라우저를 더 이상 지원하지 않음  
  - Tor의 구버전 Firefox 기반, 테스트 불가, 자금 부족 등을 이유로 **지원 계획 없음**으로 종료  

### Lemmy 관련 문제
- **Matrix와 동일한 연합형 구조**로 인해 **데이터 복제, 검열, 불법 콘텐츠 책임** 문제가 동일하게 발생  
  - “de-federation”을 통한 **검열형 탈중앙화**, **집단사고(groupthink)** 유도, **업·다운보트 조작** 등으로 **자유로운 토론이 제한됨**  

### SimpleX로의 전환

#### 식별자 없는 통신 구조
- **SimpleX는 사용자 식별자(전화번호, 이메일, 공개키 등)를 전혀 사용하지 않음**  
  - 각 대화마다 독립된 단방향 메시지 큐 주소를 사용해 **상대방과의 연결을 익명화**  
  - 향후 자동 큐 교체 기능으로 **서버 간 이동 및 추적 방지** 지원 예정  

#### 스팸 및 남용 방지
- **초대 링크나 임시 주소를 직접 공유해야만 연락 가능**, 원치 않는 접근 차단  
  - 주소 변경 또는 삭제로 **스팸 완전 차단 가능**  

#### 데이터 완전 소유
- **모든 사용자 데이터는 클라이언트 기기에만 저장**, 서버는 **임시 릴레이 역할**만 수행  
  - 서버 간 트래픽에서도 송수신자 식별 불가, **추적 불가능한 메시지 전달 구조**  

#### 사용자 운영 네트워크
- 누구나 **자체 SimpleX 서버를 운영**할 수 있으며, **SDK와 오픈 프로토콜**로 **봇·서비스 개발** 가능  

#### Matrix와의 비교
| 항목 | SimpleX | Matrix |
|------|----------|---------|
| 암호화 | **이중 암호화 + 포스트 양자 키 교환** | Megolm (취약점 존재) |
| 메시지 라우팅 | **2-hop onion 라우팅** | 연합형 구조, 메타데이터 노출 |
| 탈중앙화 | **중앙 구성요소 없음** | 중앙 부트스트랩 노드 존재 |
| 미디어 처리 | **로컬 암호화 및 수동 큐 회전** | 미검증 업로드, 자동 복제 |
| Tor 지원 | **지원 및 onion 라우팅 제공** | **지원 중단** |
| Cloudflare | **비사용** | **TLS 종료 Cloudflare** |

### SimpleX의 기술적 특징
- **더블 래칫 기반 종단간 암호화**, **포스트 양자 키 교환**, **2-hop onion 라우팅**  
- **Tor 및 SOCKS 프록시 지원**, **TLS 1.2/1.3 보안 채널**, **재전송 방지 서명 구조**  
- **완전한 탈중앙 네트워크**, **Flux 통합으로 메타데이터 보호 강화**  

### 사용자 경험 및 추가 기능
- **E2EE 음성·영상 통화**, **암호화된 알림**, **로컬 파일 암호화**, **메시지 편집·반응**, **배터리 절약형 그룹 채팅**  
- **익명 모드**, **콘솔 클라이언트**, **봇 SDK**, **Linode 원클릭 서버 배포** 등 다양한 확장 기능 제공  

### 향후 로드맵
- **안정성 향상**, **대규모 커뮤니티 지원**, **프라이버시·보안 슬라이더**, **에페메랄 대화**, **위치 공유**, **자동화 규칙** 등 개발 예정  

---  
**결론:** Hack Liberty는 Matrix의 구조적 보안 결함과 운영 불신으로 인해 **SimpleX 기반의 완전한 프라이버시 중심 네트워크**로 이동함. SimpleX는 **식별자 없는 통신, 강력한 암호화, 탈중앙 구조**를 통해 차세대 안전한 커뮤니티 플랫폼으로 제시됨.

## Comments



### Comment 48256

- Author: neo
- Created: 2025-12-26T08:35:21+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46376201) 
- 나는 **Matrix**가 성공하길 정말 바랐지만 이제 완전히 포기했음  
  상태 해결(state resolution) 시스템이 너무 복잡하고 자원 소모가 심함. 방이 망가지는 일도 여전히 발생함. 단순히 방의 멤버 리스트를 계산하는 것조차 DB 용량이 수 GB에 달할 정도로 비효율적임.  
  게다가 몇 년이 지나도 **커스텀 이모지**, 사용자 상태, 초대 링크 같은 기본 기능조차 없음  
  관련 이슈: [#339](https://github.com/element-hq/element-meta/issues/339), [#573](https://github.com/element-hq/element-meta/issues/573), [#426](https://github.com/element-hq/element-meta/issues/426)  
  요즘은 **SimpleX**가 Signal과 비슷한 타깃을 노리지만 다른 접근을 취하는 것 같아 흥미로움. 다만 아직 대중적으로 확산된 느낌은 없음
  - 나도 Matrix가 성공하길 바랐지만 절반쯤 포기한 상태임. 예전엔 Synapse 홈서버를 직접 운영했는데, **리소스 소모**가 너무 심했음. 그래서 다시 **XMPP**로 돌아감. 단순히 채팅만 제공하려면 XMPP가 훨씬 효율적임. SimpleX는 아직 좀 더 성숙해질 때까지 기다릴 생각임
  - 상태 해결 문제는 [Project Hydra](https://matrix.org/blog/2025/08/project-hydra-improving-state-res/) 이후로 많이 개선되었음. DB 용량 문제는 Synapse의 저장 효율성 문제 때문임. 내가 [이 영상](https://youtu.be/D5zAgVYBuGk?t=1853)에서 해결 방법을 보여줬지만, 우선순위는 상태 리셋 수정이었음.  
    커스텀 이모지나 사용자 상태 같은 기능은 이미 **MSC 제안**이 존재하고 구현이 진행 중임. 2023년 이후 자금난으로 생존을 위해 정부 프로젝트 위주로 개발을 집중했기 때문임
  - XMPP 써봤는지 물어보고 싶음
  - 나는 1년 정도 SimpleX를 기본 서버로 사용했는데 잘 작동했음. Signal 그룹을 SimpleX로 옮기려 했지만 실패했고, 결국 사용이 중단됨
  - 나는 몇 년째 같은 Matrix 방을 유지 중임

- 나와 내 주변 사람들은 **Matrix 경험이 매우 긍정적**이었음. Beeper와 Element를 통해 수십 명의 비기술 사용자들을 온보딩했는데, 다들 잘 쓰고 있음. 기기 변경도 문제없고, Discord와 비교해도 UX가 꽤 경쟁력 있음.  
  그래서 HN에서 나오는 불만들이 이해가 안 됨. 아마도 오래된 서버나 비호환 클라이언트를 쓰는 게 아닐까 추측함
  - Matrix가 거의 완성 단계에 가까워서, 남은 결함에 사람들이 더 민감하게 반응하는 것 같음. 최근 몇 년간은 **공공 부문 배포**에 집중하느라 Discord 경쟁 기능은 후순위였음
  - 셀프 호스팅은 괜찮았지만, Discord에서 옮겨온 사람들에게는 초대 링크나 등록 절차가 너무 복잡했음. 특히 **음성 채팅 시스템 변경**으로 기존 설치가 깨졌고, 문서화도 부족했음
  - 나도 개인 서버를 ansible 스크립트([matrix-docker-ansible-deploy](https://github.com/spantaleev/matrix-docker-ansible-deploy))로 관리 중인데, 안정적으로 잘 작동함. 아마도 **공용 서버(matrix.org)** 와의 경험 차이일 듯함
  - 나도 문제 없이 잘 쓰고 있음. 친구들과의 소규모 채팅에서는 완벽하게 작동함
  - 보안 측면에서의 경험은 어떤지 궁금함

- SimpleX가 “사용자 식별자가 없다”고 주장하지만, 실제로는 **IP 주소가 그대로 노출**됨. 전체 퍼블릭 네트워크가 Akamai와 Runonflux 두 회사에 의해 호스팅되고 있음.  
  Tor를 기본 번들로 제공하고, IP 마스킹 옵션을 명확히 설명해야 함. 현재는 “추가 식별자를 만들지 않는다”는 의미일 뿐, IP 자체는 보호되지 않음
  - 나는 **SimpleX 네트워크 설계자**임. IP 주소는 인터넷 식별자이지 SimpleX 식별자가 아님. SimpleX의 목표는 IP 간 상호 연관을 막고, 사용자가 선택하지 않은 서버로의 노출을 방지하는 것임.  
    Tor를 내장하지 않는 이유는 [FAQ](https://simplex.chat/faq/#why-dont-you-embed-tor-in-simplex-chat-app)에 설명되어 있음
  - SimpleX가 자체 **암호화폐**를 만들려는 움직임이 있어서 걱정됨

- 나는 Matrix에 대한 의견은 없지만, **Nebuchadnezzar 논문**을 꼭 읽어보길 권함. 그룹 보안 메시징의 핵심은 암호화가 아니라 **그룹 멤버십 관리**임  
  [논문 링크](https://nebuchadnezzar-megolm.github.io/)
  - 여기에 **FOKS**([https://foks.pub](https://foks.pub)) 같은 시스템을 결합하면 흥미로울 것 같음
  - 처음 Matrix 프로토콜 문서를 읽었는데, 분산 시스템 이해가 부족한 사람이 만든 듯한 인상임. **Lamport clock**이나 **virtual synchrony** 개념도 없이 IRC와 XMPP를 섞은 느낌임.  
    여러 번의 DAG 정렬 시도로 합의를 시도하는 부분에서 프로젝트가 근본적으로 잘못되었다는 생각이 들었음. 차라리 **NNTP + GnuPG**로 직접 그룹 채팅을 만드는 게 나을 듯함

- Matrix의 연말 업데이트를 올렸음: [Matrix Holiday Special 2025](https://matrix.org/blog/2025/12/24/matrix-holiday-special/)  
  모두 즐거운 연말 보내길 바람 :)

- 나는 6년째 Matrix를 사용 중임. 2020년 대규모 유입 때는 힘들었지만 지금은 안정적임.  
  여전히 **Element Web의 버그와 느림**이 불만이지만, 가벼운 대안 클라이언트들이 많음.  
  메타데이터 암호화는 아직 완전하지 않지만, 내 일상 대화에서는 큰 문제 아님.  
  Matrix를 계속 쓰는 이유는 **분산형 구조**, **E2EE**, **멀티디바이스**, **자유 소프트웨어**, **셀프 호스팅 가능성** 등 대체 불가능한 조합 때문임.  
  프로젝트 리더의 **침착한 리더십**도 신뢰감을 줌
  - 나도 동의함. Element Web의 **메모리 누수 문제** 때문에 커스텀 포크를 쓰고 있음([이슈 링크](https://github.com/element-hq/element-web/issues/27983#issuecomment-3606125651)).  
    **matrix-rust-sdk**로 전환되면 큰 개선이 있을 듯. [Aurora 프로젝트](https://github.com/element-hq/aurora)도 기대됨
  - XMPP도 거의 같은 기능을 훨씬 적은 자원으로 구현 가능함. 영상 통화에는 TURN 서버가 필요하지만 잘 작동함

- **Moxie (Signal 창립자)** 가 2020년 CCC에서 연합형(federation) 시스템의 문제를 지적한 강연이 있음.  
  [영상 링크](https://youtu.be/DdM-XTRyC9c)
  - 그의 2016년 블로그 글 [The Ecosystem Is Moving](https://signal.org/blog/the-ecosystem-is-moving/)도 여전히 유효함. 분산 시스템이 겪는 문제를 볼 때마다 다시 읽음
  - 중앙화된 시스템은 **조정력**에서 항상 우위를 가지므로, 분산 시스템은 명확한 존재 이유가 없으면 결국 틈새로 밀려남
  - 관련 토론 모음:  
    - [Why federated protocols don't work (2022)](https://news.ycombinator.com/item?id=30314454)  
    - [The Ecosystem Is Moving (2019)](https://news.ycombinator.com/item?id=21904041)  
    - [Reflections: The ecosystem is moving (2016)](https://news.ycombinator.com/item?id=11668912)
  - 결국 “우리는 빠르게 움직이고 클라이언트를 자유롭게 바꾸고 싶다”는 논지였음. 하지만 클라이언트에 대한 **절대적 통제**가 필요하다면 E2EE의 의미가 줄어듦

- “**Why Federation Must Die**” 주장에는 동의하지 않음. 연합형은 어렵지만, **Chatcontrol** 같은 규제 속에서도 EU 내에서 안전한 통신을 유지할 유일한 방법임.  
  중앙화된 시스템은 한 조직만 압박하면 되지만, 연합형은 모두가 서버를 운영하므로 통제하기 어려움
  - 그 글은 연합형이 아니라 **완전한 탈중앙화**를 주장하는 내용임
  - 나도 연합형을 지지함. **Mastodon**을 보면 중앙화보다 자유로운 구조가 얼마나 중요한지 알 수 있음. 발견성(discoverability)은 어렵지만, 그만큼 **자율성**이 큼

- **반(反) 빅테크 진영**은 사실 여러 가치관의 연합체임.  
  한쪽은 **연합과 자율성**을, 다른 쪽은 **암호화와 프라이버시**를 우선시함.  
  서로의 우선순위가 다르다는 걸 인식하면, 완벽히 일치하지 않아도 더 **관대한 협력**이 가능할 것 같음
  - 나도 같은 생각임. 나는 **자기 호스팅과 상호운용성**을 중시하지만, 다른 사람들은 **E2EE와 메타데이터 최소화**를 더 중요하게 봄.  
    Matrix 같은 프로젝트가 이 두 진영을 모두 만족시키기란 거의 불가능함.  
    게다가 보안·프라이버시 진영의 목소리가 더 크기 때문에, 담론이 실제보다 부정적으로 들릴 때가 많음

- 올해 우리는 **Matrix의 메타데이터 보호**를 개선 중임.  
  - [MSC4362](https://github.com/matrix-org/matrix-spec-proposals/blob/kaylendog/msc/simplified-encrypted-state/proposals/4362-simplified-encrypted-state.md): 룸 상태 암호화  
  - [MSC4256](https://github.com/dklimpel/matrix-spec-proposals/blob/mls-RFC-9420/proposals/4256-rfc9420-mls-mode-matrix.md): 송신자 제거 및 MLS 기반 암호화  
  과거에는 분산형 암호화 안정화에 집중하느라 메타데이터 보호가 후순위였음.  
  또한 네트워크 트래픽 자체가 이미 많은 메타데이터를 노출하기 때문에 완전한 은닉은 어려움.  
  그래도 2026년에는 더 나은 개선이 예정되어 있음  
  참고로 2016년 발표 자료도 있음: [Matrix Jardin Entropique (PDF)](https://matrix.org/~matthew/2015-06-26%20Matrix%20Jardin%20Entropique.pdf)  
  일부 주장(예: 중앙 서버로 데이터 전송)은 사실이 아님. 미디어 인증은 2024년 6월부터 적용되었고, 2025년에는 **신뢰·안전 팀**도 강화됨  
  - 사람들은 스스로 호스팅하고 싶어 하지만, 결국 **유료 호스팅 서비스**를 원하게 됨. 보안 이슈가 많다면 오히려 **호스팅 비즈니스 기회**가 될 수도 있음
  - “직접 서버를 운영하라”는 태도는 장기적으로 지지를 얻기 어려움. 일반 사용자가 **반(半)시스템 관리자**가 되길 기대하는 건 현실적이지 않음