카카오톡 자동화 CLI, 안전을 기본값으로 설계한 오픈소스

문제

카카오톡은 공식 자동화 API를 일반 사용자에게 열어두지 않습니다. 그래서 개인이 자기 대화 기록을 백업하거나, 특정 방의 메시지를 다른 도구로 넘기거나, 스크립트에서 카카오톡을 하나의 입력 채널로 쓰고 싶어도 마땅한 방법이 없습니다. 데스크톱 앱을 사람이 직접 클릭하는 것 외에는 선택지가 없는 셈입니다.

문제는 여기서 시작합니다. 비공식 접근은 필연적으로 두 가지 위험을 안습니다. 하나는 내부 프로토콜을 잘못 다뤄 계정이 제재되는 위험이고, 다른 하나는 이런 도구가 대량 발송이나 스팸 같은 오남용으로 흐르기 쉽다는 점입니다. 개인 운영 편의와 아카이빙이라는 정당한 필요를 채우면서도 도구 자체가 위험한 행동을 부추기지 않게 만드는 일이 설계의 핵심 과제였습니다.

기존에 떠도는 방식들은 대체로 이 균형을 무시했습니다. 로그인 토큰을 평문으로 굴리거나, 서버에 쓰기 요청을 거리낌 없이 보내거나, 대화 기록을 손실 없이 보관할 방법을 주지 않았습니다. 카카오톡 데스크톱 앱의 로컬 저장소는 암호화돼 있고 오래된 메시지는 시간이 지나면 잘려 나가기 때문에, 안전하게 읽고 안전하게 보관하는 일조차 간단하지 않았습니다.

그래서 이 프로젝트는 시작부터 비공식 도구임을 분명히 밝히고 카카오 이용약관과 운영정책은 사용자가 직접 확인하도록 안내하는 전제 위에 섰습니다. 목표는 "무엇이든 자동으로 보낸다"가 아니라 "위험을 기본값으로 막아둔 채, 꼭 필요한 개인 작업만 안전하게 한다"였습니다. 아래는 그 원칙이 코드로 굳어진 결정들입니다.

접근

전체 도구는 Rust로 만든 CLI 본체(openkakao-cli)와, 같은 프로토콜 연구를 재사용할 수 있게 떼어 낸 Python 모듈(openkakao-py) 두 갈래로 이뤄집니다. 두 갈래 모두 "위험한 것은 기본값에서 잠가 둔다"는 같은 철학을 따릅니다.

읽기 쪽은 위험도에 따라 다시 세 갈래로 나눴습니다. 가장 안전한 것은 로컬 데이터베이스를 직접 읽는 경로입니다. 카카오톡이 로컬에 쌓아 둔 암호화 DB(SQLCipher)를 열어 채팅 목록과 메시지, 검색 결과를 가져오는데, 이 과정에는 서버 통신이 전혀 없습니다. 계정 제재의 표면적이 원천적으로 0인 경로입니다.

실시간으로 새 메시지를 받아야 하는 경우에는 LOCO라는 카카오톡의 내부 통신 프로토콜을 직접 구현했습니다. 예약 서버 조회와 체크인, RSA-OAEP로 감싼 세션 키 교환, AES-GCM 암호화, BSON 패킷까지 실제 앱과 같은 절차를 밟아 연결합니다. 이 계층이 있어야 watch로 방을 감시하고 이벤트를 실시간으로 흘려보낼 수 있습니다.

마지막 축은 이 도구를 사람뿐 아니라 스크립트와 에이전트가 함께 쓰게 만드는 것이었습니다. 거의 모든 명령이 --json 출력을 지원해서 jq나 cron, SQLite, LLM 흐름에 그대로 물릴 수 있습니다. 진단 메시지는 표준에러로, 구조화된 결과는 표준출력으로 분리해 파이프라인에서 깨지지 않게 했습니다.

전체 구조는 다음과 같습니다.

글로 요약하면 이렇습니다. 카카오톡의 로컬 DB와 서버에서 나온 데이터는 먼저 안전 게이트를 지납니다. 게이트는 쓰기를 기본값에서 잠그고 dry-run과 속도 제한을 강제합니다. 이후 흐름은 서버를 건드리지 않는 읽기 경로와 명시적 허용이 필요한 쓰기 경로로 갈리고 watch가 만든 실시간 이벤트는 hook과 webhook으로, 모든 명령의 결과는 --json으로 에이전트와 파이프라인에 전달됩니다. 수신한 메시지는 손실형 원본을 우회해 별도 아카이브 DB에 쌓입니다.

결과

사람이 앱을 직접 열어 클릭하는 것 말고는 방법이 없던 개인 작업들이 하나의 CLI로 정리됐습니다. 대화 백업, 로컬 스크립트 연동, 새 메시지 이벤트의 후속 처리 같은 일을 터미널과 스크립트에서 처리할 수 있게 됐고 그 과정 내내 계정 보호가 기본값으로 깔려 있습니다.

무엇보다 이 도구는 오픈소스로 공개돼 프로토콜 연구가 다른 프로젝트로 재사용되고 있습니다. Rust CLI에서 다진 통신 계층은 Python 모듈로도 떼어져 나갔고 자격증명 암호화와 채팅 기록 영구 저장 같은 조각들이 독립적으로 쓰입니다. 안전 우선이라는 뼈대 위에서 기능이 계속 늘어나는 구조가 갖춰졌습니다.

이 프로젝트에서 내린 기술적 결정들은 아래 글에서 더 자세히 풀었습니다.

• 계정을 지키는 안전 우선 CLI 설계: 읽기 기본, 쓰기 opt-in, dry-run, 속도 제한
• 서버를 건드리지 않는 로컬 DB 읽기: SQLCipher 저장소를 직접 여는 아카이빙 경로
• LOCO 프로토콜 리버스 엔지니어링: 체크인, 세션 키 교환, BSON 패킷
• watch에서 hook·webhook으로 잇는 이벤트 파이프라인: 필터와 속도 제한이 있는 실시간 알림
• 사람과 에이전트가 함께 쓰는 JSON CLI: --json 하나로 만든 이중 인터페이스
• 자격증명 암호화와 메시지 아카이브: 암호화 저장과 손실형 원본 우회

자주 묻는 질문

이 도구는 카카오톡 공식 API인가요?

아닙니다. 카카오와 무관한 비공식 CLI이고 카카오의 승인이나 보증을 받지 않았습니다. 사용 방식에 따라 이용약관이나 운영정책 위반으로 해석될 수 있어, 프로젝트는 이 점을 처음부터 경고로 밝히고 관련 정책은 사용자가 직접 확인하도록 안내합니다. 이 사례 글의 목적도 대량 발송 같은 자동화 권유가 아니라, 비공식 접근을 다룰 때 위험을 어떻게 기본값으로 낮췄는지 설계를 공유하는 데 있습니다.

계정이 제재될 위험은 어떻게 낮췄나요?

가장 큰 축은 서버에 쓰기 요청을 보내는 명령을 기본값에서 잠근 것입니다. 전송·삭제·수정·반응 같은 작업은 설정 파일에서 명시적으로 켜야만 동작하고 켠 뒤에도 dry-run 미리보기와 최소 실행 간격이 붙습니다. 반대로 로컬 DB를 읽는 경로는 서버 통신이 아예 없어서 대화 백업과 검색처럼 보기만 하는 작업은 제재 표면이 원천적으로 없습니다.

개인이 아니라 대량 메시지 발송에 써도 되나요?

이 프로젝트는 그런 용도를 위해 만들지 않았고 설계 자체가 대량 발송을 어렵게 만들도록 기울어 있습니다. 쓰기는 기본 비활성이고 연속 전송에는 속도 제한이 걸립니다. 스팸과 대량 발송은 상대에게 피해를 주는 것은 물론 계정 제재로 직결되는 행동이라, 이 도구는 개인 운영 편의와 아카이빙이라는 범위 안에서만 쓰는 것을 전제로 합니다.

Rust CLI와 Python 모듈은 어떻게 나뉘나요?

사람이 터미널에서 바로 쓰는 본체는 Rust CLI(openkakao-cli)이고 같은 프로토콜 연구를 코드로 재사용하려는 경우를 위해 Python 모듈(openkakao-py)을 따로 뒀습니다. Python 쪽은 로그인 흐름, 실시간 감시, 자격증명 암호화 저장, 채팅 기록 영구화를 하나의 모듈로 묶어 다른 프로젝트에서 임포트해 쓸 수 있게 했습니다. 두 갈래 모두 안전 기본값이라는 같은 원칙을 공유합니다.