새 채팅 플랫폼을 설계할 때 연합(federation), 종단간 암호화(E2EE), 음성 채팅 모델에 대해 어떤 선택이 적절한지에 관한 견해를 정리한다.
Discord가 최근 장기적인 쇠퇴의 시작이 될 수도 있는 논란의 여지가 있는 결정을 내렸다. 이 상황 때문에 사람들이 대안을 찾고 있다. 하지만 많은 대안들이 내가 보기엔 방향을 잘못 잡고 있거나, 어떤 특정한 니치에는 좋지만 다른 곳에는 맞지 않는다(예: 나는 집중적인 기술 커뮤니티에는 Zulip을 좋아하지만, 사교 클럽에는 영 안 맞는다). 이 글에서는 많은 대안들이 무엇을 잘못하고 있는지(혹은 이상적으로는 무엇을 제대로 하고 있는지)를 개략적으로 정리해 보려 한다. 이 주제는 자기만족적인 사색과 자전거 헛소리(bikeshedding)가 많으니, 여기서는 내가 생각하는 가장 눈에 띄는 의견들만 다루겠다.
탈중앙화 이야기를 할 때 ‘연합(federation)’은 엄청난 유행어이자 판매 포인트다. 이론상으로는 P2P와 완전 중앙집중 사이의 괜찮은 절충안처럼 보인다. 하지만 커뮤니티를 호스팅하는 채팅 플랫폼의 경우에는, 연합이 해결하는 문제보다 만들어내는 문제가 더 많다고 생각한다.
Fediverse(또는 그에 대응하는 ATProto) 같은 것에서는 연합이 말이 된다. 여러 서버가 합쳐져 사실상 하나의 커뮤니티처럼 동작하고, 서버 간 커뮤니티의 구분이 크지 않기 때문이다(서버의 로컬 타임라인 정도를 제외하면 말이다. Fediverse에서는 ‘그룹’ 기능이 결국 크게 뜨지 못했다). 하지만 ‘당신의 커뮤니티’는 그 자체로 하나의 커뮤니티다. 다른 커뮤니티와 상호작용할 필요가 없을 가능성이 높다. 그런데도 그런 가능성을 열어두면 확장(스케일링), 정책 도메인의 차이, 법적 책임(리어빌리티) 측면에서 복잡도가 폭증한다.
그래서 채팅 플랫폼이 택해야 할 더 나은 해법은 ‘단독 서버(standalone server)’ 사용 사례에 전적으로 집중하는 것이라고 본다. 사람들이 연합에서 실제로 기대하는 것(앱 수와 계정 수를 줄이는 것)은, 대신 싱글 사인온(SSO)과 동일한 API를 쓰는 단일 클라이언트가 여러 서버를 지원하는 방식으로 달성할 수 있다.
커뮤니티가 자체 서버를 호스팅함으로써 주권(sovereignty)을 유지하도록 할 수도 있다. 그걸 하지 않을 99%를 위해서는 호스팅 서버를 제공하고, 서버 간 마이그레이션을 지원하면 된다. Zulip이 쓰는 모델이 이런 식이고, 나는 이게 합리적이라고 생각한다.
정부의 과도한 사생활 침해가 우려되는 불안정한 시대에 살고 있고, 암호화는 많은 사람들에게 기본 요건(table stakes)이 되어 가고 있다. 하지만 누구나 참여할 수 있는 공개 커뮤니티에 대해 E2EE(End-to-End Encryption, 종단간 암호화)는 오히려 연극에 가깝고, 시스템을 훨씬 복잡하게 만들 뿐이다.
E2EE는 정확히 구현하지 못하면 보안이 깨지거나, 그냥 장애물이 되어버리기 쉽다. 공개 그룹에서는 더 황당해진다. 그냥… 들어가면 되기 때문이다. 게다가 사람이 많을수록(예: 스크린샷) 정보가 유출됐을 때 ‘누가 유출했는지’를 특정하기는 더 어렵다. 두 자릿수 정도의 구성원만 되어도 커뮤니티 입장에서는 그 복잡도를 감수할 가치가 없다.
그렇다고 해서 E2EE가 중요하지 않다는 뜻은 아니다. 소규모 그룹이나 1:1 대화에서는 E2EE가 매우 중요하다. 다만 공개 커뮤니티 플랫폼이 그걸 같이 처리하려 들면 안 된다고 본다. DM 같은 용도는 그 사용 사례에 초점을 맞춘 플랫폼에 맡기는 게 낫다.
Signal은 그런 면에서 제대로 하고 있지만, 중앙집중적이라는 특성에 대해 꺼림칙해하는 사람들도 있다. 그 영역에는 대안의 여지가 있다. 다만, 수십~수백 명 규모의 커뮤니티를 다루는 플랫폼과 같은 플랫폼일 수는 없을 것이다.
대부분의 채팅 플랫폼은 텍스트 채팅에 집중하고 A/V(오디오/비디오) 경험은 소홀히 한다. 흔히 하는 방식은 Jitsi/BigBlueButton 같은 것들을 덧붙여서( bolt on ) 지원하는 것인데, 이들은 Zoom 같은 ‘회의’ 경험을 제공한다. 작동은 하지만, 사교 커뮤니티에는 잘 맞지 않는다. Zoom 같은 도구는 캘린더에 잡힌 시간 제한(timeboxed) 회의를 중심으로 설계되어 있고, ‘놀러 가는 공간’으로 설계된 게 아니다.
직접 꾸준히 써 보고 그 주변에 커뮤니티가 형성되는 걸 보지 않으면 설명하기 어렵지만, 핵심 차이는 “음성 채널은 장소(place)다”라는 점이다. 언제든지 부담 없이 들어갔다가 나올 수 있고, 통화를 ‘설정’해야 하는 오버헤드가 없다. 또 그 채널의 상태가 어떤지도 한눈에 보기 쉽다.
화면 공유나 카메라를 켜는 것도 쉽게 시작할 수 있고, 모두가 동시에 그렇게 할 수 있다(Zoom 같은 것과는 달리. Zoom은 한 번에 하나의 화면 공유만 허용하고, 그걸 커다란 초점으로 만들어 모두가 반드시 그걸 봐야 하는 형태가 된다).
이 음성 채팅 모델은 Mumble 같은 게임용 VoIP 플랫폼이 제공하던, 가볍게 나뉜 여러 방(room)들과 가장 비슷하다. 의외로 Slack도 이걸 잘 해내는데, ‘허들(huddles)’이 사실상 각 텍스트 채널에 연결된 가벼운 음성 채널을 추가해 준다.
어쩌면 전략은 다른 것에 음성 채널을 붙이는 게 아니라, Mumble을 확장해서 범용 채팅 플랫폼으로 만드는 쪽일지도 모르겠다.
기술 chat, discord, e2ee, federation, matrix, mumble, slack, zulip
