[메신저를 한 화면에 ③] tsuba, 하루 만에 메신저가 넷

카카오톡, 텔레그램, 슬랙, 디스코드, 채팅+ 대화를 브라우저 한 화면에서 보는 도구를 만든 기록, 세 번째다. 1편이 터미널 도구, 2편이 그 앞에 세운 화면 이야기였다면, 이번에는 카카오톡만 보던 화면 앞에 다른 메신저들이 줄을 선 날의 이야기다. 10월 1일과 2일, 이틀 사이에 일어난 일이다.

칼날과 칼집 사이의 코등이

카카오톡 화면을 만들고 나니 자연스럽게 욕심이 생겼다. 텔레그램도, 업무용 슬랙도, 게임할 때 쓰는 디스코드도 한곳에서 보고 싶었다. 10월 1일, 메신저 어댑터들을 모아 둘 저장소를 새로 팠다.

이름은 tsuba(つば)라고 붙였다. 일본도에서 칼날과 칼집(saya) 사이에 끼우는 둥근 쇠붙이, 코등이다. 칼을 쥘 때 손을 베이지 않게 지켜주는 부품이다. 화면(saya)이 각 메신저의 복잡한 API나 비밀키를 직접 쥐고 휘두르다 베이지 않도록, 중간에서 규격을 안전하게 번역해 주는 코등이 역할을 맡겼다.

하나로 묶고 싶다는 유혹

시작하자마자 큰 유혹을 만났다. '이참에 카카오톡까지 tsuba 어댑터 규격으로 감싸서, 세상 모든 메신저를 완벽하게 똑같은 API 하나로 통일해 버릴까?'

개발자라면 누구나 빠지기 쉬운 설계의 유혹이다. 하지만 몇 시간 고민하고 접었다. 카카오톡 도구가 가진 고유한 기능들 때문이었다. 대화 발췌 다이제스트, 공지사항, 로컬 데이터베이스 기반의 전송 확인 같은 동작들은 다른 네트워크 메신저 규격에 존재하지 않는다. 억지로 하나의 틀에 우겨넣으면 둘 중 하나는 망가진다.

결국 선을 그었다. 카카오톡은 화면과 직접 통신하게 두고, 텔레그램·슬랙·디스코드 같은 네트워크 메신저들만 tsuba 규격으로 묶었다. 모든 걸 하나로 통일하지 않는 것이 시스템을 살리는 길이었다.

선언된 것만 그린다

메신저는 저마다 성격이 너무 다르다. 텔레그램은 메시지 수정, 삭제, 리액션이 자유롭지만 어떤 채널은 읽기 전용이다. 슬랙은 스레드와 리액션이 중심이고, 디스코드는 서버와 채널 구조다.

그래서 tsuba는 각 어댑터가 자기가 무엇을 할 수 있는지 스스로 선언하게 했다. 기능 목록(Capabilities)을 물어보면 "나는 메시지 읽기와 보내기가 되고, 리액션도 지원한다"고 답한다.

화면(saya)은 철저히 이 선언만 보고 그린다. 선언되지 않은 기능은 "대충 되겠지" 하고 버튼을 두지 않는다. 특정 대화방에서 보내기 권한이 없으면(false), 화면은 입력창 자체를 그리지 않는다. 추측해서 그리지 않는 것, 그것이 오류를 막는 원칙이었다.

연결 탭 화면. 각 메신저가 자신이 지원하는 기능(Capabilities)을 스스로 선언한다. 화면은 이 선언만 보고 버튼과 입력창을 그린다.

안 되는 건 조용히 숨긴다

어댑터를 붙이다 보니 현실적인 문제가 생겼다. 텔레그램 로그인이 안 되어 있거나 슬랙 토큰이 없으면 화면이 온통 빨간색 에러 메시지로 뒤덮였다.

그때 정한 원칙이 있다. "못 불러온다고 에러 띄우지 말고 그냥 조용히 가려."

메신저 하나가 연결되지 않았다고 해서 전체 목록에 "텔레그램 연결 실패", "슬랙 토큰 없음" 같은 경고를 늘어놓지 않기로 했다. 연결되지 않은 메신저는 사이드바와 탭에서 조용히 숨긴다. 아무것도 연결되지 않았을 때만 딱 한 번 "연결된 메신저가 없습니다"라고 말한다. 구체적인 진단과 원인은 오직 '설정 > 연결' 탭에 들어갔을 때만 차분하게 보여준다. 에러 메시지는 자랑거리가 아니다.

텔레그램 대화방. 사진, 답장 인용, 리액션 이모지가 붙어 있다. 이름과 내용은 모두 지어낸 것이다.

현실의 네트워크와 제약들

실제로 메신저들을 붙이는 과정은 생각보다 험난했다.

텔레그램을 붙이려는데 작업용 PC 네트워크에서 텔레그램 서버 접속이 통째로 막혀 있었다. 결국 해외 VPS 서버에 SOCKS5 프록시 터널을 뚫어 트래픽을 우회시켜야 했다. 메시지 길이 제한도 골치였다. 4,096자 제한이 UTF-16 기준인지 유니코드 코드포인트 기준인지 직접 수천 자를 쏴 보며 실측해야 했다.

슬랙도 만만치 않았다. 읽지 않은 메시지 수를 계산하는 기준이 까다로웠고, 채널이 많은 워크스페이스에서는 순식간에 API 호출 한도(Rate Limit)에 걸렸다. 결국 채널을 조회할 때마다 3초씩 간격을 두는 페이싱 처리를 넣어야 했다.

슬랙 채널 화면. 이미지 첨부와 리액션이 렌더링된 모습이다. 가상의 데이터로 확인했다.

아직 못 푼 것

겉으로는 하나의 메신저처럼 매끄럽게 보이지만, 속에서는 메신저마다 제각각인 규격을 맞추느라 분기 처리가 늘어나고 있다. 텔레그램의 묶음 사진(앨범), 슬랙의 블록 구조, 디스코드의 채널 트리까지. 완전히 다른 세상들을 한 화면에 나란히 세우는 일에는 생각보다 많은 어댑터의 땀이 들어간다.

다음 편은 또 다른 벽, 통신사 문자 메신저인 채팅+를 붙이면서 "안 된다"고 적었던 결론을 하루 만에 뒤집은 이야기다.

---

메신저를 한 화면에

1. 카톡을 터미널에서 읽던 작은 도구
2. saya, 아무것도 모르는 화면
3. tsuba, 하루 만에 메신저가 넷 (이 글)
4. 채팅+, 안 된다고 적었다가 지운 결론
5. nichirin과 heimdal, 남에게 건네기