연결을 붙잡지 않고 AI 어시스턴트 트래픽 감당하기

배경

온라인 이커머스 플랫폼으로, 기존 업무 흐름 외에 고객을 응대하는 AI 고객 지원 어시스턴트가 있었습니다.

과제와 불분명했던 점

모든 LLM 제품의 중심에는 구조적인 불일치가 있습니다: 모델의 한 턴은 수십 초가 걸릴 수 있는데, 웹 요청이 모델에 닿기까지 지나는 모든 것 —— 게이트웨이, 방화벽, 프록시 —— 은 밀리초 단위 요청을 전제로 타임아웃이 잡혀 있습니다. 그래서 동기 설계에는 실패 방식이 둘 있습니다. 눈에 띄는 쪽은 느린 답이 경로 어딘가의 상한을 넘는 것입니다. 간과되는 쪽은 그것이 도는 동안 경로를 붙잡고 있어서, 다음 고객이 뒤에서 기다린다는 것입니다. 밖에서 보면 이 둘은 똑같습니다: AI가 느리다. 그리고 둘 다 모델의 문제가 아닙니다.

내 역할

회사의 AI 고객 지원에 참여했고 —— 지식 구조, 응답 라우팅, 도구 호출, 대화 관리, 평가, 안전 장치, 상담원 인계 —— 여기서 설명하는 요청 경로 변경을 설계하고 납품했습니다. 플랫폼 자체의 운영 중 이커머스 시스템 유지보수도 맡았습니다.

재직 중에 의도적으로 택하고 있는 공개 수준의 표현입니다. 내부 기록은 더 강한 동사를 뒷받침하지만, 공개 페이지에서는 이쪽을 씁니다.

요구사항 파악

쓸모 있는 질문은 "어떻게 모델을 빠르게 할까"가 아니라 "이 경로에서 요청이 금방 끝날 것을 전제하는 것이 무엇인가? 그리고 끝나지 않으면 다른 사람들은 어떻게 되는가"였습니다. 이 질문에 답하면 문제가 모델 튜닝에서 연결 구조로 바뀝니다.

설계와 트레이드오프

동기 처리를 그만뒀습니다. 요청은 큐에 들어가고, 브라우저가 몇 초마다 폴링해서 준비되면 그립니다. 연결을 붙잡는 것이 없으므로 경로의 타임아웃 상한이 대화 한 건을 좌우하지 않고, 고객은 서로 기다리는 대신 병렬로 처리됩니다. 대가는 클라이언트가 조금 복잡해지는 것과 눈에 보이는 대기 상태입니다 —— 이 교환이라면 몇 번이라도 다시 합니다. 다른 선택지는 조용히, 그리고 불공평하게 실패하게 두는 것이니까요.

구현과 연동

플랫폼의 기존 프레임워크 위의 queue workers와 프론트엔드 폴링, 그리고 모델 호출 주위의 재시도와 오류 처리입니다. 여기에 두 가지 장치를 더했습니다: 유휴 대화는 만료시킵니다 —— 조용해진 대화에는 한 번 알린 뒤 응답이 없으면 닫고 붙잡고 있던 자원을 놓습니다. 그리고 가벼운 요청은 더 작은 모델 계층으로 보내, 매번 가장 큰 모델을 두드리지 않게 했습니다 —— 중요한 답의 품질을 희생하지 않으면서 할 수 있는 가장 단순한 추론 비용 통제입니다.

운영 단계의 장치

모델 호출 주위의 재시도와 오류 처리, 대화 수명 주기 관리, 그리고 "나중에 붙이는 것이 아니라 설계에 넣는" 평가 방식 —— 한 번의 답이 여러 정보를 검색해 합쳐야 할 때의 정확성과, 적대적·사회공학적 탐색에 대한 동작을 포함합니다. 그 평가는 만들어 가는 중이지 완료된 운영 강화가 아닙니다 —— 제가 설명하는 것은 설계이지 결과가 아닙니다.

결과

이 재구성은 완료되어 플랫폼에 머지되었습니다. 이 작업에 대해서는 성능 숫자를 공개하지 않으며 앞으로도 하지 않습니다 —— 정직하게 주장할 수 있는 운영 결과를 갖고 있지 않기 때문입니다.

가져갈 수 있는 배움

AI 기능이 "느리다"는 말을 들으면, 모델에 손대기 전에 경로를 재십시오. 제 경험으로는 모델은 여태 하던 일을 그대로 하고 있고, 바뀐 것은 그 주위의 구조가 사용자 경험에 미치는 영향입니다 —— 그리고 고치는 방법은 거의 언제나 연결을 붙잡는 것을 그만두는 것입니다.