2026년 7월 16일, 카카오톡 개인 대화에서는 잘 답하던 봇이 왜 단체방에서는 답하지 않는지 물었다. 내 단체방에서 대신 반응하는 봇을 만들고 싶어 시작한 작업이었다. 그런데 모델이 어떤 문장을 만들지보다 먼저, 휴대전화가 메시지를 서버에 전달하고 있는지부터 확인해야 하는 상황이 생겼다.
서버가 답을 만들 수 있다는 사실만으로 대화창까지 정상적으로 이어진다고 볼 수는 없었다. 휴대전화에서 출발한 메시지와 서버의 응답을 서로 다른 지점에서 살펴야 했다.
메시지가 오가는 경로를 나눴다
보존된 클라이언트 코드는 대화방, 메시지, 발신자와 단체방 여부를 서버로 보내고 반환된 답을 대화창에 표시하는 구조다. 서버는 요청을 확인한 뒤 방별 설정을 고르고, 모델에 응답을 요청한다. 같은 프로그램 안에서도 단말의 수신, 서버 전달, 응답 생성은 별개의 단계였다.
방별 설정은 코드에서 분리해 기본값 위에 해당 방의 값을 겹치도록 했다. 파일이 바뀌면 다시 읽어 반영하게 하고, 조용히 있어야 할 시간대를 계산하는 함수도 두었다. 시간대가 자정을 넘는 경우까지 나눠 처리했다.
모델 요청이 실패하면 설정된 다음 모델을 시도하는 코드도 있었다. 오류가 모두 이어지면 응답을 내놓지 않는 방식이었다. 반면 단말 쪽에서는 네트워크나 서버 예외를 잡아 조용히 넘겼다. 대화창에 오류 문구를 쏟아내지 않는 대신, 사용자에게는 서로 다른 실패가 똑같은 침묵으로 보일 수 있는 구조였다.
폰에서 출발하지 않은 메시지와 서버 응답
7월 16일 저녁의 진단 기록에는 최근 10분 동안 해당 폰에서 온 POST 요청이 검색되지 않은 구간이 있다. POST는 단말이 서버로 메시지를 보내는 요청이다. 서버 쪽에는 별도의 응답과 오류 기록이 남아 있었으므로, 모델만 바꾸기 전에 단말에서 요청이 도착하는지 확인할 이유가 있었다.
당시에는 폰의 절전이 연결을 끊는 원인으로 제시됐다. 하지만 나는 화면을 열어서 메시지가 도착한 것인지 구분이 안 간다고 했고, 이후에도 됐다 안 됐다 하는 것 같다고 말했다. 이 기록만으로 모든 무응답의 원인을 절전으로 확정할 수는 없다.
같은 날 서버에 직접 보낸 상태 확인 요청에는 정상 응답이 돌아왔다. 이 결과는 그 요청에 서버가 답했다는 확인이다. 휴대전화가 실제 대화의 알림을 받아 서버로 보내고 다시 표시하는 전체 경로를 시험한 결과와는 구분해야 했다.
설정 하나를 끄는 것으로 끝나지 않는 기록 문제
개인 대화를 다루는 프로그램에서는 어디에 무엇이 저장되는지도 확인할 필요가 있었다. 보존된 서버 코드에는 수신 디버그 기록을 켜고 끄는 설정이 있지만, 별도의 응답 로그에는 요청을 일으킨 문구와 응답, 방과 발신자가 남는다. 수신 로그를 껐다는 이유만으로 대화 내용이 전혀 기록되지 않는다고 설명할 수 없는 구조였다.
링크 정보를 읽는 코드에도 범위가 있었다. 처음 요청하는 주소의 도메인을 허용 목록과 대조했지만, 이후 이동하는 주소를 자동으로 따랐다. 이를 모든 경로의 접근을 검증한 보안 장치로 확대하지 않았다. 코드에 검사가 있다는 사실과 실제 위험을 빠짐없이 막는다는 판단은 별개의 일이었다.
일부 전송 기능은 코드가 남아 있어도 실제 폰에서 시험을 마쳤는지 확인되지 않았다.
서버의 ‘정상’ 뒤에 남은 질문
이 작업에서 확인해야 할 지점은 더 구체적이 됐다. 응답이 없을 때 서버 안의 문장 생성부터 볼 것인지, 그 앞에서 메시지가 도착했는지부터 볼 것인지가 달랐다. 서버가 ‘정상’이라고 답하더라도, 휴대전화에서 메시지가 출발했는지는 따로 확인해야 했다.