채팅에 상주하는 AI 에이전트가 조사, 집계, 복수 툴 호출 등을 수반하는 요청을 받으면 답변까지 수십 초에서 수 분이 걸릴 수 있습니다. 인간 동료라면 '잠시 확인해 보겠습니다'라고 한마디를 덧붙이고 작업을 시작하지만, 에이전트가 아무 말 없이 처리만 진행하면 사용자에게는 '읽음은 되었는데 아무 반응이 없다'는 상태로 비칩니다. 복수 채널에서의 중복 질문에 관한 기사에서 언급된 '5분 후에 답장이 오지 않으니 만약을 위해 이메일로도 물어본다'라는 행동은 바로 이 침묵이 방아쇠가 되어 발생합니다. 본 기사에서는 처리 시간이 걸리는 요청에 대해 에이전트가 어떻게 '작업 중임'을 전달할지를 정리합니다.
왜 '무언의 처리'가 문제가 되는가
서버 측 처리가 정상적으로 진행되고 있어도, 사용자 입장에서는 그것을 확인할 수 있는 수단이 없습니다.
- 정말로 요청을 받았는지, 메시지가 도착하지 않은 것인지 구별할 수 없다.
- '멈춘 것이 아닌가'라고 판단하여 같은 요청을 다른 채널이나 다른 방식으로 재전송해 버린다.
- 재전송된 요청을 별도의 스레드로 처리하게 되면, 같은 작업이 중복으로 실행되거나 모순되는 두 개의 답변이 돌아올 수 있다.
여러 부서에 동시 전개하면서 반응이 느리지 않을까 하는 불안감은 부하 집중으로 인한 시스템 전체의 지연을 다루고 있지만, 여기서 다룰 것은 그것과는 다른 문제입니다. 부하와 관계없이, 개별 요청 자체가 구조적으로 시간이 걸리는 처리이며, 정상적으로 작동하고 있어도 사용자 입장에서는 '멈춰 있다'처럼 보일 수 있다는 이야기입니다.
패턴 1: 수신 직후의 즉시 확인(Acknowledgement)을 '답변'과 분리하기
요청을 받은 시점에서 최종 답변과는 별개로 '받아 처리하기 시작했다'는 것만을 즉시 전달합니다.
- Slack/Teams라면 리액션(👀 또는 ⏳)으로 '확인 중'임을 보이거나, 짧은 텍스트로 '확인하겠습니다. 잠시만 기다려 주세요'만을 먼저 보낸다.
- 이 즉시 확인(Acknowledgement)은 내용을 아무것도 보장하지 않아야 합니다. 후속 답변이 '사실 대응할 수 없습니다'여도 모순되지 않는 문구로 만듭니다. - 즉시 확인 자체에도 지연이 일어나지 않도록, 여기만은 LLM 호출을 거치지 않고 고정 문구/고정 리액션으로 즉시 반환합니다.
즉시 확인을 '답변의 일부'로 생성하려고 하면, 여기서도 LLM의 추론 시간이 추가되어 본말전도가 됩니다. 수신 확인은 생성하지 않고, 고정된 처리로 다루는 것이 안전합니다.
패턴 2: 진행 상황 업데이트는 고정 간격이 아닌 시간 임계값(Threshold)으로 제공하기
'30초마다
필자는 Slack / Teams / Chatwork / LINE WORKS에 상주하며, 채팅・이메일・캘린더・회의록을 자동으로 수집하여 매일 아침 리포트를 전달하는 AI 에이전트 HACH를 개발하고 있으며, 요청을 받은 시점부터 답변을 제공하기까지의 ‘보이지 않는 시간’을 어떻게 처리할지 역시 알림 설계나 확신도에 따른 행동 분기와 더불어 운영상 중요한 관점이라고 생각합니다.
Discussion