Iris로 카카오톡 봇을 포팅하면서 가장 흥미로웠던 부분은, 공식 문서가 없는 프로토콜을 상대로 직접 원인을 추적해야 하는 순간들이었습니다. 이번 글은 그중에서도 가장 인상 깊었던 사례 하나를 기록합니다.

만들고 싶었던 기능: 메시지 삭제 감지

오픈채팅방을 운영하다 보면 메시지가 사라지는 경우가 두 가지 있습니다. 하나는 운영진이 특정 메시지를 “가리기”(숨김) 처리하는 경우, 다른 하나는 작성자 본인이 자기 메시지를 “스스로 삭제"하는 경우입니다. 이 둘을 구분해서 감지하는 기능을 만들고 싶었습니다 — 운영 로그를 남기거나, 특정 조건에서 자동 대응하기 위해서였습니다.

잘못된 가정에서 시작하다

처음에는 두 가지 삭제 방식이 결국 같은 종류의 이벤트일 거라고 가정하고 코드를 짰습니다. Iris가 제공하는 이벤트 중 SYNCMODMSG(메시지 수정/상태 변경 관련 이벤트로 추정)를 두 경우 모두에 대응하는 트리거로 사용했습니다. 하지만 실제로 테스트해보니 한쪽 케이스만 제대로 잡히고, 다른 한쪽은 전혀 감지되지 않았습니다.

문제 해결 흐름

채팅 로그 DB를 직접 열어서 확인하다

문서가 없으니 추측만으로는 한계가 있었습니다. 결국 Iris가 읽는 로컬 채팅 로그 DB를 직접 쿼리해서, 실제로 메시지를 “가리기"했을 때와 “스스로 삭제"했을 때 각각 어떤 이벤트가 기록되는지 직접 눈으로 확인하는 방법을 택했습니다. 두 상황을 각각 재현해보면서 로그를 비교한 결과, 예상과 다르게 “스스로 삭제"는 SYNCMODMSG가 아니라 전혀 다른 이벤트 타입인 SYNCDLMSG로 들어온다는 걸 확인했습니다.

코드를 실제 동작에 맞춰 고치다

원인을 알고 나니 수정은 간단했습니다. SYNCMODMSG는 운영진의 “가리기” 처리를, SYNCDLMSG는 작성자 본인의 “스스로 삭제"를 감지하는 트리거로 각각 분리했습니다. 두 이벤트를 구분한 뒤로는 의도한 대로 각 상황을 정확히 구별해서 처리할 수 있게 됐습니다.

돌아보며

이런 종류의 작업은 API 문서를 읽고 기능을 구현하는 것과는 완전히 다른 종류의 작업이라고 느꼈습니다. 가정을 세우고, 코드를 짜고, 실제 동작과 다르면 로그를 직접 파서 진실을 확인하고, 다시 가정을 고치는 과정의 반복입니다. 비공식 API나 리버스엔지니어링이 필요한 프로젝트를 할 때는 “그럴듯한 가정"보다 “직접 관찰한 사실"을 항상 우선해야 한다는 걸 다시 한번 느낀 경험이었습니다.

핵심 요약

🤖 이 포스팅은 AI의 도움을 받아 작성되었습니다.