매트릭스로 커뮤니티를 운영한다는 것: 어느 관리자의 일주일 보고서

오픈소스 분산 메시징 프로토콜 매트릭스(Matrix)는 흔히 '탈중앙화된 디스코드 대안'으로 소개된다. 여러 홈서버가 연합(federation)해 하나의 대화방을 공유하고, 사용자는 원하는 서버나 클라이언트를 골라 쓸 수 있다는 점이 핵심 매력이다. 그러나 한 커뮤니티의 관리자이자 모더레이터가 남긴 경험 보고서는, 실제로 규모 있는 커뮤니티를 굴려 보면 이 이상이 곳곳에서 삐걱거린다는 현실을 담담하게 기록한다. 이 글은 새 기능의 화려함이 아니라, 관리자가 반복해서 마주치는 구조적 마찰을 실무 관점에서 짚어 준다는 점에서 읽을 가치가 있다.

스페이스라는 이름의 일반 대화방

첫 번째 사건은 사소해 보이지만 시사적이다. 매트릭스의 '스페이스(space)'는 여러 방을 묶는 상위 개념이지만, 내부적으로는 그냥 일반 대화방이다. 스페이스를 지원하지 않는 구형 클라이언트는 이를 평범한 채팅방으로 렌더링하고, 그 결과 한 사용자가 무심코 스페이스 방에 글을 쓰면 스페이스 전체 구성원에게 알림이 발송된다. 반대로 스페이스를 지원하는 신형 클라이언트는 '여기서 대화가 일어나선 안 되는데' 하는 혼란스러운 UI를 보여 준다. 대부분의 클라이언트가 스페이스 방의 권한을 자동으로 채팅 불가로 설정하지 않기 때문에, 관리자는 Element 웹의 개발자 도구로 스페이스를 일반 방처럼 열어 스스로 관리자 권한을 부여하고 수동으로 권한을 조정해야 했다.

더 뼈아픈 부분은 그 조정이 몇 달 뒤 저절로 풀려 있었다는 점이다. 방이 이른바 '스플릿 브레인' 상태로 디싱크되어, 권한 변경을 다시 적용해도 다른 홈서버 사용자들에게는 반영되지 않았다. 일부 서버는 변경을 받고 일부는 받지 못하니, 후자에 속한 사용자는 여전히 스페이스에서 떠들 수 있고 그 메시지는 변경을 받은 서버에서 소프트 페일 처리되어 보이지 않게 된다. 결국 다른 홈서버의 누군가가 같은 변경을 적용해 최대한 많은 서버로 전파되기를 기대하는 것이 유일한 우회책이었다.

모더레이션은 왜 이렇게 힘든가

밴 처리의 경험은 도구의 한계를 더 선명하게 드러낸다. 포럼에서 영문 모를 밴을 호소한 사용자를 조사하려고 모더레이션 봇 Draupnir에 계정 핸들을 넣었지만 아무것도 나오지 않았다. 도메인 단위로 다시 조회하고서야, 커뮤니티가 구독 중인 외부 정책 방에서 해당 도메인(개인용 1인 인스턴스로 추정) 전체가 차단됐음을 확인할 수 있었다. 관리자는 그 정책 방에 속해 있지도 않았고 매트릭스는 방 제목조차 알려 주지 않아, 공개 방이라는 점에 기대어 직접 참여해야 했다. 그 과정에서 홈서버는 백필을 요청하며 버벅였고, 클라이언트는 캐시를 비우고 새로고침해야 했으며 그 바람에 모든 대화가 읽지 않음으로 표시됐다.

정책 방의 밴 기록은 m.policy.rule.user 타입 메시지로 쌓여 있는데, Element의 검색은 일반 메시지 타입만 훑기 때문에 검색 결과가 비어 나온다. 결국 대화방을 HTML로 내보내 grep으로 도메인을 찾는 우회책을 써야 했고, 원인은 해당 사용자의 홈서버가 과거 한때 가입을 개방했다가 스팸에 노출된 것이었다. 2분이면 끝날 조사에 40분이 걸렸다. 더 답답한 것은 후속담이다. 2주 뒤 같은 사용자가 다시 연락했지만, 구독 중인 밴 목록에 대해 로컬 예외를 두는 손쉬운 방법이 없어, 목록 전체를 구독 해지해 커뮤니티를 스팸 위험에 노출시키는 것 말고는 할 수 있는 일이 거의 없었다.

연합의 대가와 낡아 가는 토대

연합 구조 자체가 만들어 내는 유령 같은 버그도 잇따른다. 스페이스에서 '추천'으로 표시된 방이 신규 참여자에게는 보이지 않다가, 스페이스 관리자가 그 방에 들어가 있는 동안에만 목록에 나타나는 현상은 방을 지웠다 다시 만들어도, 심지어 방을 툼스톤 처리해 재생성해도 고쳐지지 않았다. 서버 정기 점검 뒤에는 Draupnir가 관리 명령에 응답하지 않았는데, 로그상 명령은 정상 처리되고 있었다. 원인은 Dendrite 기본 설정이 별 이유 없이 아웃바운드 IPv6 트래픽을 전부 버린다는 데 있었고, 이를 발견해 디버깅하기까지 한 달 넘게 걸렸다. 그동안 커뮤니티는 모더레이션 봇의 보호 없이 방치됐고, 필자는 그 기간에 스팸 공세를 맞지 않은 것을 다행으로 여겼다.

이 대목에서 홈서버 선택의 딜레마가 드러난다. 서버를 처음 세울 당시 Dendrite는 Synapse보다 배포와 운영이 쉬워 2세대 구현의 밝은 미래처럼 보였지만, 지금은 사실상 개발 우선순위에서 밀려 최근 커밋 대부분이 의존성 갱신에 그친다. 그럼에도 매트릭스 홈서버 구현 간 마이그레이션은 만족스러운 해법이 없어, 커뮤니티는 서서히 낡아 가는 토대 위에 묶여 있다. 필자 자신의 홈서버도 DNS 문제로 며칠간 연합이 저하됐다가 복구 후에도 특정 계정이 방에 없다고 착각하는 디싱크를 겪었다. 봇 계정이라 강퇴 후 재초대로 해결됐지만, '내 서버가 잊어버린 실제 사용자는 몇 명일까'라는 질문이 남는다.

PR과 현실의 간극

필자가 가장 씁쓸해하는 지점은 기술적 결함 그 자체가 아니라 기대 관리의 실패다. 매트릭스 재단의 소셜 계정이 부스팅하는 행복한 사용자 후기는 대체로 1:1 대화나 소규모 그룹을 쓰고 스페이스가 무엇인지도 모르는, 사실상 매트릭스 공식 서버와 공식 클라이언트에 머무는 이들의 이야기다. 도구의 좋고 나쁨이 용도에 달렸다는 점, 그리고 WhatsApp·Signal 사용자층을 먼저 겨냥하는 전략이 나름 합리적이라는 점은 필자도 인정한다. 그러나 소프트웨어 다양성과 상호운용성이 오히려 경험을 해친다면, 프로젝트가 내건 가치의 근본이 훼손되는 것이라고 그는 짚는다. '진지한 디스코드 대안'이라는 홍보와 '스페이스는 고급 사용자용이라 우선순위가 낮다'는 개발 현실 사이의 간극이, 수년간 쌓인 약속들과 겹쳐 관리자에게 배신감으로 다가온다는 것이다.

한국의 IT 실무자에게 이 보고서는 두 가지 교훈을 준다. 첫째, 분산·연합형 시스템을 도입할 때 매력적인 데모나 1:1 사용 경험만 보고 판단해서는 안 되며, 권한 전파, 모더레이션 도구의 검색 한계, 구현체 간 마이그레이션 부재처럼 규모가 커질 때 드러나는 운영 비용을 미리 가늠해야 한다는 점이다. 둘째, 오픈 생태계의 '다양성'은 그 자체로 상호운용성을 보장하지 않으며, 특정 공식 스택에서만 매�끄럽게 작동한다면 탈중앙화의 실익은 반감된다는 점이다. 도구의 강점과 한계를 분리해 보는 냉정한 시선이야말로, 커뮤니티 인프라를 책임지는 사람이 갖춰야 할 최소한의 준비물이다.