로컬 DB를 읽는 것만으로 해결되지 않는 작업이 하나 있습니다. 지금 이 순간 새로 오는 메시지를 실시간으로 받는 일입니다. 이건 저장소를 뒤지는 게 아니라 서버와 살아 있는 연결을 유지해야 하는 문제이고 카카오톡이 그 연결에 쓰는 프로토콜은 공개돼 있지 않습니다. LOCO라 불리는 이 내부 프로토콜을 문서 없이 동작만 보고 복원한 과정을 정리합니다. 이 글은 특정 서비스를 우회하는 방법이 아니라, 공식 명세가 없는 바이너리 프로토콜을 어떻게 안전하게 재구성하는지를 다룬 엔지니어링 기록입니다.
왜 프로토콜을 직접 구현했나
실시간 감시(watch)와 이벤트 자동화는 서버에서 밀어 주는 메시지를 계속 받을 수 있어야 성립합니다. REST 방식으로 주기적으로 물어보는 폴링으로는 지연이 크고 무엇보다 잦은 요청이 계정 활동으로 쌓입니다. 서버가 클라이언트에게 직접 이벤트를 밀어 주는 지속 연결이 필요했고 그 연결의 언어가 LOCO였습니다.
문제는 이 프로토콜에 공식 문서가 없다는 점입니다. 그래서 접근 방식은 관찰과 대조였습니다. 실제 앱이 서버와 주고받는 절차를 단계별로 분해하고 이미 공개된 다른 언어의 구현체들과 교차 검증하며 각 단계가 무엇을 하는지 확인해 나갔습니다. 한 조각씩 맞춰 전체 핸드셰이크를 다시 세우는 작업이었습니다.
핸드셰이크의 단계
연결은 한 번에 열리지 않습니다. 먼저 예약 서버에 접속해 실제로 붙을 접속 지점 정보를 받아 옵니다. 그다음 그 지점에 체크인해 세션을 시작할 준비를 하고 여기서부터 암호화 계층이 세워집니다. 클라이언트가 만든 세션 키를 서버의 공개 키로 감싸 보내고 이후의 모든 통신은 그 세션 키로 암호화됩니다.
이 계층 구조가 중요한 이유는 각 단계의 실패 모드가 다르기 때문입니다. 예약 서버 조회가 실패하는 것과 세션 키 교환이 실패하는 것은 원인이 완전히 다릅니다. 단계를 뭉뚱그리지 않고 명확히 나눠 두면, 연결이 어디서 끊겼는지 진단할 수 있고 재연결도 정확한 지점에서 다시 시도할 수 있습니다.
암호화 계층의 세부
세션 키를 감싸는 데는 서버의 공개 키를 이용한 비대칭 암호화가 쓰이고 실제 데이터는 그렇게 교환한 대칭 키로 암호화됩니다. 비대칭으로 키를 안전하게 전달하고 이후 빠른 대칭 암호화로 본 통신을 처리하는, 널리 쓰이는 하이브리드 구조입니다. 세부 파라미터를 정확히 맞추는 것이 관건이었는데, 값 하나만 어긋나도 서버는 아무 설명 없이 연결을 끊기 때문입니다.
특히 까다로웠던 것은 앱 업데이트에 따라 이런 파라미터가 바뀔 수 있다는 점이었습니다. 예전에는 한 방식이던 암호화가 새 버전에서 다른 방식으로 넘어가기도 합니다. 그래서 구현은 관찰된 현재 값을 명확히 상수로 고정해 두고 무엇이 어느 버전 기준인지 코드에 근거를 남기는 방식을 택했습니다. 나중에 값이 바뀌었을 때 어디를 고쳐야 하는지 분명하게 하려는 것입니다.
패킷 구조
핸드셰이크가 끝나면 실제 메시지는 BSON 형식의 패킷으로 오갑니다. 각 패킷에는 어떤 종류의 이벤트인지, 어떤 방과 관련되는지, 본문은 무엇인지가 담깁니다. 수신 쪽은 이 패킷을 해석해 새 메시지, 읽음 표시, 방 정보 갱신 같은 이벤트로 분류합니다.
여기서 얻은 구조화된 이벤트가 이후 자동화의 재료가 됩니다. 패킷을 해석해 얻은 메시지는 그대로 아카이브 저장소에 쌓이거나, 필터를 거쳐 hook과 webhook으로 흘러갑니다. 즉 프로토콜 계층은 그 자체가 목적이 아니라, 위쪽의 실시간 감시와 이벤트 파이프라인이 딛고 설 토대입니다.
안정적으로 연결을 유지하기
지속 연결은 끊기기 마련이라 유지 전략이 필수였습니다. 인증이 만료되면 정해진 코드로 신호가 오는데, 이걸 감지해 토큰을 자동 갱신하고 연결을 다시 세웁니다. 연결이 끊어지면 곧바로 재접속을 몰아치지 않고 간격을 점점 늘리는 지수 백오프로 재시도하며 살아 있는 연결에는 주기적으로 신호를 보내 유지합니다.
이런 안정화 장치가 없으면 실시간 감시는 몇 시간을 못 버팁니다. 반대로 이 장치들이 자리 잡으면, 사람이 지켜보지 않아도 연결이 스스로 회복하며 오래 도는 감시자가 됩니다. 이 계층 위에 올라가는 실시간 이벤트 처리는 watch에서 hook·webhook으로 잇는 이벤트 파이프라인에서, 프로토콜 연구를 Python으로 재사용한 이야기는 자격증명 암호화와 메시지 아카이브에서 이어집니다. 전체 도구의 안전 우선 설계는 카카오톡 자동화 CLI 오픈소스 사례에 정리돼 있습니다.
자주 묻는 질문
공식 문서 없이 프로토콜을 어떻게 복원했나요?
실제 앱이 서버와 주고받는 절차를 단계별로 관찰하고 이미 공개된 다른 언어의 구현체들과 교차 검증하는 방식으로 한 조각씩 맞춰 나갔습니다. 예약 서버 조회, 체크인, 세션 키 교환, 패킷 해석을 각각 분리해 확인하며 전체 핸드셰이크를 다시 세웠습니다. 문서가 아니라 동작이 근거였습니다.
앱이 업데이트되면 프로토콜 구현이 깨지지 않나요?
암호화 방식이나 파라미터가 앱 버전에 따라 바뀔 수 있어서 그 위험은 실재합니다. 그래서 구현은 관찰된 현재 값을 명확한 상수로 고정하고 무엇이 어느 버전 기준인지 코드에 근거를 남깁니다. 값이 바뀌면 어디를 고쳐야 하는지 바로 찾을 수 있게 해서 유지보수 비용을 줄이는 쪽으로 설계했습니다.
지속 연결은 어떻게 안정적으로 유지하나요?
인증 만료 신호를 감지해 토큰을 자동 갱신하고 연결이 끊기면 간격을 점점 늘리는 지수 백오프로 재접속하며 살아 있는 연결에는 주기적으로 유지 신호를 보냅니다. 이 장치들이 있어야 사람이 지켜보지 않아도 실시간 감시가 스스로 회복하며 오래 돌 수 있습니다.