TECH 으로 돌아가기
TECH HACKER NEWS 오늘 8분 읽기 28 READS

XMPP는 왜 아직도 못 뜨는 걸까? 25년 된 오픈 메신저 프로토콜의 고민

25년 넘게 살아남았지만, 여전히 '아는 사람만 아는' 프로토콜

혹시 XMPP라는 이름 들어보셨나요? 예전엔 Jabber라고 불렸던 오픈 메시징 프로토콜인데요. 1999년에 처음 나왔으니까 벌써 25년이 넘은 기술이에요. 재밌는 건, 구글 토크(Google Talk)나 초창기 페이스북 메신저, 심지어 왓츠앱도 내부적으로 XMPP를 변형해서 만들어졌다는 거예요. 그런데 지금 XMPP를 쓰는 사람이 주변에 있나요? 아마 거의 없을 거예요.

이번에 안드로이드 XMPP 클라이언트 'Conversations'를 만드는 개발자 다니엘 굴치(Daniel Gultsch)가 「우리는 어떻게 사용자를 늘릴 수 있을까?」라는 글을 올렸어요. XMPP 커뮤니티 안에서 오랫동안 반복되어 온 고민을 다시 정면으로 꺼낸 건데요. 이 글이 흥미로운 이유는, 단순히 XMPP 홍보가 아니라 '오픈 프로토콜이 왜 대중화에 실패하는가'라는 훨씬 보편적인 질문을 던지고 있기 때문이에요.

XMPP가 뭐냐면

이게 뭐냐면, 이메일이랑 비슷한 구조의 채팅 프로토콜이에요. 이메일은 제가 gmail.com을 쓰고 상대가 naver.com을 써도 서로 메일을 주고받을 수 있잖아요? 그게 가능한 이유는 SMTP라는 공통 규칙을 모든 메일 서버가 따르기 때문이거든요. XMPP도 똑같아요. 제가 A 서버에 계정을 만들고 친구가 B 서버에 계정을 만들어도, 두 서버가 XMPP를 지원하면 서로 대화할 수 있어요. 이런 걸 '연합(federation)'이라고 불러요.

반면 카카오톡이나 왓츠앱은 어떤가요? 카카오톡 사용자는 카카오톡 사용자하고만 대화할 수 있죠. 하나의 회사가 서버도, 앱도, 규칙도 전부 독점하는 구조예요. 이걸 '중앙집중형' 혹은 '폐쇄형' 서비스라고 하고요. 편하긴 한데, 그 회사가 정책을 바꾸거나 서비스를 접으면 사용자는 아무것도 할 수 없어요.

기술적으로 XMPP는 XML 기반으로 메시지를 주고받아요. 메시지 하나가 <message> 태그로 감싸진 작은 XML 조각인 거죠. 그리고 확장 기능은 XEP(XMPP Extension Protocol)라는 문서로 정의되는데, 이게 수백 개가 있어요. 파일 전송, 음성 통화, 종단간 암호화(OMEMO), 읽음 확인 같은 기능이 전부 별도의 XEP로 존재해요.

그럼 왜 안 뜨는 걸까?

굴치의 글과 XMPP 커뮤니티에서 오랫동안 지적되어 온 첫 번째 문제는, 바로 이 '확장성'이 양날의 검이라는 거예요. XEP가 너무 많다 보니, 서버마다 클라이언트마다 지원하는 기능이 제각각이거든요. 제 클라이언트는 OMEMO 암호화를 지원하는데 친구 클라이언트는 지원을 안 하면? 그냥 암호화가 안 돼요. 사용자 입장에선 「왜 되다 안 되다 하지?」 싶은 거죠. 왓츠앱은 이런 고민이 아예 없어요. 앱이 하나니까요.

두 번째 문제는 온보딩이에요. 카카오톡은 전화번호 넣고 인증하면 끝인데, XMPP는 「어느 서버에 가입할까요?」부터 시작해요. 개발자한테는 자유로워 보이지만, 일반 사용자한테는 첫 화면에서 벽을 만나는 느낌이에요. 이메일도 사실 같은 구조지만, 이메일은 이미 '내 회사 계정', '내 학교 계정'처럼 자연스럽게 서버가 정해지잖아요. 채팅은 그런 맥락이 없거든요.

세 번째는 네트워크 효과예요. 메신저의 가치는 '누가 거기 있느냐'로 결정돼요. 아무리 프로토콜이 훌륭해도 친구가 없으면 쓸 이유가 없죠. 이 부분은 기술로 해결이 안 되는 영역이라 커뮤니티가 가장 답답해하는 지점이기도 해요.

경쟁자들은 어떻게 하고 있나

여기서 비교해볼 만한 게 Matrix예요. 2014년에 나온 후발 주자인데, XMPP랑 마찬가지로 연합형 오픈 프로토콜이거든요. 차이점은 Matrix가 처음부터 '하나의 대표 클라이언트(Element)'와 '하나의 대표 서버(Synapse)'를 밀면서 기능 파편화를 줄였다는 거예요. 그리고 프랑스 정부의 Tchap, 독일 연방군과 의료 시스템 같은 큰 조직 도입 사례를 만들면서 인지도를 올렸고요. 대신 방 상태를 전부 동기화하는 구조라 서버 자원을 훨씬 많이 먹는다는 단점이 있어요.

Signal은 또 다른 길을 갔어요. 오픈소스지만 연합을 포기하고 단일 서버로 운영하면서, 대신 '프라이버시'라는 명확한 메시지 하나로 사용자를 모았죠. 결과적으로 Signal이 XMPP보다 훨씬 많은 일반 사용자를 확보했어요. 굴치의 글이 던지는 뼈아픈 질문이 바로 이거예요. 사용자가 원하는 건 '개방성'이 아니라 '잘 되는 앱'이 아닐까?

한국 개발자에게 주는 시사점

한국은 카카오톡이 사실상 국가 표준 메신저인 나라라, XMPP를 개인 메신저로 쓰자고 하면 웃음이 나올 수도 있어요. 하지만 실무 관점에서는 얘기가 좀 달라요. 사내 메신저나 IoT 기기 간 통신, 게임 서버의 채팅 기능 같은 걸 만들 때 XMPP는 여전히 검증된 선택지거든요. ejabberd나 Prosody 같은 서버는 수백만 동시 접속을 처리한 사례가 있고, 라이브러리도 거의 모든 언어에 있어요. 특히 '연합' 기능을 끄고 우리 서비스 안에서만 쓰면 파편화 문제도 사라져요.

그리고 이 글이 주는 더 큰 교훈은 프로토콜 설계 자체에 관한 거예요. 확장성을 최대한 열어두면 개발자들은 좋아하지만, 사용자 경험은 파편화돼요. 반대로 꽉 닫아두면 빠르게 좋은 경험을 만들 수 있지만 생태계가 안 생기고요. 여러분이 API나 플러그인 시스템을 설계할 때 똑같은 고민을 하게 될 거예요.

마무리

한줄 정리: XMPP는 기술적으로 훌륭한 오픈 프로토콜이지만, 지나친 확장성과 어려운 온보딩, 네트워크 효과 부재 때문에 25년 넘게 대중화에 실패했고, 커뮤니티는 지금도 그 답을 찾고 있어요.

여러분은 어떻게 생각하세요? 메신저 같은 서비스에서 '개방성'과 '완성도' 중 하나를 골라야 한다면 어느 쪽을 택하시겠어요? 그리고 한국에서 카카오톡을 대체할 오픈 메신저가 나올 가능성이 있다고 보시나요?


🔗 출처: Hacker News

SOURCE · HACKER NEWS
원문 전체 보기 → https://gultsch.de/posts/how-do-we-gain-traction/
SHARE
NEXT · CHOOSE

변화를 읽었다면,
내가 만들 수익 구조를 고릅니다.

정보를 더 모으는 데서 멈추지 않고, 광고·외주·판매·중개·구독 중 내 상황에 맞는 출발점을 정해보세요.

21가지 수익 구조 살펴보기
처리 중...