"인프라는 우리가 소유해야 한다." 이 말에 많은 사람이 본능적으로 고개를 끄덕인다. 다만 여기서 '우리'가 누구인지는 인프라의 성격에 따라 달라진다. 고속도로나 철도, 항만은 국가 규모의 노력을 요구하고, 상수도는 대개 지방자치단체가 맡는다. 반대로 집처럼 개인 단위로 소유를 꿈꾸는 인프라도 있지만, 이 역시 협동조합이나 공영주택 형태로 집단이 소유할 수 있다. 개발자 다니엘 굴치가 XMPP 25주년을 계기로 쓴 글은 바로 이 '소유의 층위'라는 렌즈를 디지털 통신에 들이댄다. 도로나 상수도는 특정 기업에 팔아넘기지 않으면서, 왜 우리는 메신저만큼은 아무 의심 없이 소수 기업의 담장 안에 맡겨 두는가라는 물음이다.
오픈소스는 왜 충분하지 않은가
프라이버시를 중시하는 이들은 흔히 시그널, 와이어, 스레마를 빅테크의 대안으로 꼽는다. 그러나 저자는 이들 역시 상호운용되지 않는 '담장 친 정원(walled garden)'이라는 점을 지적한다. 시그널이 특별히 악의적인 행동을 했다는 뜻이 아니다. 문제는 시그널이 내일 서버를 닫거나 유럽 운영을 중단해도 사용자에게는 빠져나갈 대안, 즉 헤지가 없다는 구조적 취약성이다. 오픈소스는 이 문제와 직교(orthogonal)한다. 코드가 공개되면 소프트웨어가 스파이웨어가 아닌지, 종단간 암호화가 견실한지는 검증할 수 있지만, 운영 주체가 서비스를 접는 순간을 막아 주지는 못한다. 인프라에 걸어야 할 기준을 만족시키려면 오픈소스만으로는 부족하다는 것이 핵심 논지다.
저자가 제시하는 해법은 '자체 호스팅이 구조적으로 가능하되 필수는 아닌' 시스템이다. 집을 직접 소유할 수도, 협동조합 형태로 공동 소유할 수도 있듯 디지털 통신도 개인 서버 운영과 집단 소유의 장점을 동시에 재현할 수 있어야 한다. 그리고 이를 가능하게 하는 유일한 길이 개방형 표준의 채택과 강제라고 본다. 특정 벤더가 API를 공개하는 것과, 여러 이해관계자가 표준화 기구(SDO)의 틀 안에서 공동으로 표준을 만드는 것은 전혀 다른 일이다. IETF나 W3C 같은 기구가 힘을 갖는 이유는 서로 다른 요구를 가진 경쟁자·보안 연구자·독립 개발자가 함께 검토하고 합의하도록 강제하기 때문이다.
매트릭스와 XMPP, 갈라진 길
이 대목에서 저자는 엘리먼트(옛 Riot, NewVector)가 만든 매트릭스(Matrix)를 대조군으로 든다. 매트릭스는 자체 호스팅과 연합(federation) 등 XMPP 기반 솔루션과 유사한 기능을 갖췄지만, XMPP를 채택하는 대신 자체 API를 표준처럼 공개했다. 문제는 매트릭스 재단의 핵심 요직을 현·전직 엘리먼트 직원이 차지하고 있고, 외부 기여를 명세에 반영하기가 대단히 어렵다는 점이다. 오픈소스 코드베이스를 개방형 표준으로 착각한 유럽 공공기관들이 '디지털 주권'을 내세우며 단일 벤더 플랫폼을 조달하는 함정에 빠진다고 저자는 비판한다. 반면 패스트메일에서 출발해 IETF로 넘어간 JMAP은 표준화 과정에서 프로토콜 자체가 개선됐고 지금은 최소 세 개의 독립 서버와 다수의 독립 클라이언트를 갖췄다. 같은 2014년 무렵 태어난 매트릭스가 여전히 자원 소모가 큰 하나의 레퍼런스 구현에 묶여 있는 것과 대비된다.
확장성으로 살아남은 프로토콜
XMPP의 뿌리는 25년을 넘긴다. 원래 RFC는 2004년 10월 자로, 2011년 소폭 개정을 거쳤다. 요구사항이 크게 바뀌는 긴 시간이지만, 이름의 X가 뜻하는 '확장 가능성(Extensible)'이 변화의 통로가 됐다. XEP라 불리는 확장 규격은 XMPP 표준 재단(XSF)이 관리하되, 재단이 직접 확장을 쓰지 않고 개발자가 제안·표준화할 SDO의 틀만 제공한다. 다만 적응이 늘 매끄럽지는 않았다. 모바일에서 메시지 유실을 막는 스트림 관리(XEP-0198)는 2009년 안정화됐지만 실제 보급은 2014~2015년에야 이뤄졌고, 종단간 암호화 규격 OMEMO(XEP-0384)는 스노든 폭로 3년 뒤인 2016년부터 확산됐다. 명세만으로는 부족하며 여러 독립 구현이 뒷받침돼야 한다는 교훈이다. 지금 XSF는 각 XEP의 구현 현황을 추적해 규격의 성숙 단계를 판단하고, 사용자가 필요한 기능을 지원하는 클라이언트를 역으로 찾도록 돕는다.
실무적 관점에서 오늘의 XMPP 클라이언트는 경쟁력을 갖췄다. 리눅스의 Dino, 안드로이드의 Conversations는 독점 프로토콜 기반 대안과 견줄 만하며, 최근에는 이모지 반응, 기기 간 읽음 상태 동기화, 상대의 현지 취침 시간대를 피하도록 돕는 시간대 표시 같은 기능이 더해졌다. 공개 XMPP 제공자를 겨냥한 국가 배후 공격 이후 의미가 커진 채널 바인딩은 특정 중간자 공격을 막는, 자체 호스팅 메신저 중에서는 드문 방어 기능이다. 앞으로는 메시지 답장, 여러 이미지의 갤러리형 공유, OAuth 지원이 실험적 XEP로 준비돼 있고, RFC를 갱신해 'XMPP 2.0'으로 IETF에 다시 가져가는 방안도 논의 중이다.
한국 IT 실무자에게 이 글이 던지는 메시지는 분명하다. 조달이나 사내 협업 도구를 고를 때 '오픈소스인가'만 볼 것이 아니라, 운영 주체가 사라져도 다른 사업자로 갈아탈 수 있는가, 즉 벤더 교체 가능성과 상호운용성이 구조에 내장돼 있는가를 따져야 한다는 것이다. 저자의 시각은 XMPP 진영의 당사자라는 점에서 매트릭스에 다소 냉정하고, 매트릭스가 실제로 제공하는 이점이나 XMPP의 파편화된 기능 구현 편차 같은 반론은 충분히 다루지 않는다. 그럼에도 벤처 자금이 붙은 스타트업과 독점 플랫폼, 여러 기술 사이클을 조용히 살아남은 프로토콜이 존재한다는 사실 자체가, 통신 도구를 일시적 제품이 아니라 오래 유지해야 할 인프라로 바라보게 만드는 근거가 된다.