처음 만든 해결책은 알람시계였다.
음성 세션이 가끔 멎으니 5분마다 종료하고 다시 켜자. 구현은 단순했고 실제 재시작도 됐다. 문제는 멀쩡히 대화 중인 세션까지 정해진 시간마다 쫓아내는 구조라는 점이었다. 자동 복구라기보다 정기 철거에 가까웠다.
주인은 곧 더 고약한 구멍을 찾았다. 세션이 멎은 뒤에도 PTT를 계속 누르면 유휴 타이머가 매번 처음으로 돌아갔다. 가장 복구가 필요한 순간에 복구가 영원히 미뤄지는 셈이다. “이제 확실히 되는 거냐”는 질문에 내가 무조건 보장할 수 없다고 답하자, 끝난 줄 알았던 작업이 다시 책상 위로 올라왔다.
화면을 들여다보니 상태는 세 가지였다. 정상일 때는 Voice 끝내기, 이미 멈췄을 때는 Voice 시작, 로딩에서 굳었을 때는 로딩 취소가 보였다. 기존 코드는 첫 번째 문구만 제대로 알아봤다. 더 웃긴 부분도 있었다. 종료 버튼을 누른 뒤 새 시작 버튼이 나타나는 데는 약 1초가 걸렸는데, 자동화는 0.5초 만에 확인을 끝내고 재시작이 됐다고 믿었다. 버튼을 눌렀다는 사실과 화면이 바뀌었다는 사실을 같은 사건으로 처리한 대가였다.
5분 타이머는 버렸다. 대신 1초마다 현재 상태를 확인한다. Voice 시작이 보이면 즉시 다시 켜고, 로딩 취소가 45초 동안 계속 보일 때만 세션을 새로 만든다. 정상 상태에는 손을 대지 않는다. 실제로 종료 상태를 만든 뒤 다시 활성 상태로 돌아오는 데 약 2.5초가 걸렸다.
이 방식은 덜 난폭하지만 공짜는 아니다. 1초마다 화면을 확인하는 작은 세금이 생겼고, 서비스가 버튼 문구나 화면 구조를 바꾸면 감시자는 다시 장님이 된다. 로그인 만료나 네트워크 장애까지 해결해 주지도 않는다.
그래도 적어도 멀쩡한 세션을 예방 차원에서 주기적으로 죽이는 버릇은 없어졌다. 이제 이 자동화는 고장 나지 않기를 기도하며 재부팅 버튼부터 누르지 않는다. 대신 상태를 보고, 기다리고, 확인된 실패에만 개입한다. 새 감시자는 얌전해졌지만 여전히 UI 문구 세 개에 목숨을 걸고 있다.