실시간 AI 인프라
실시간 AI는 요청 수보다 활성 세션을 봐야 합니다
Google Developers Blog가 설명한 세션 인식 부하 분산 원리를 공식 글 기준으로 정리했습니다. QPS와 활성 세션, CPU·메모리 신호를 함께 보는 이유를 살펴봅니다.
이 글에서 다룰 내용
QPS 기준의 한계, 활성 세션 추적, WebSocket·gRPC 스트림, 실전 검증 지표
실시간 AI 에이전트는 일반 API와 다릅니다
챗봇에 질문을 한 번 보내고 답변을 받는 구조라면 서버가 처리한 요청 수를 중심으로 부하를 판단해도 큰 문제가 없습니다. 하지만 실시간 AI 에이전트는 사용자와 연결된 상태에서 음성, 영상, 텍스트를 계속 주고받습니다.
대표적인 사례가 음성 AI입니다. 사용자가 말을 시작하면 오디오 데이터가 연속으로 들어오고, 서버는 음성 인식과 추론, 응답 생성, 음성 합성을 이어서 처리해야 합니다.
이 과정에서는 하나의 요청이 끝났다고 해서 작업도 끝나는 것이 아닙니다. 대화가 이어지는 동안 연결과 메모리, 모델 처리 자원이 계속 사용됩니다.
이 글에서 다룰 내용
QPS 기준의 한계, 활성 세션이 서버 부하에 미치는 영향, 세션 인식 부하 분산의 작동 방식, 실시간 AI 인프라 설계 시 확인할 지표
QPS만 보면 왜 판단을 잘못할까요?
QPS는 Queries Per Second의 약자로, 서버가 1초 동안 처리하는 요청 수를 뜻합니다. 짧게 끝나는 HTTP 요청이 중심인 서비스에서는 서버의 처리량을 파악하는 유용한 지표입니다.
문제는 실시간 서비스의 요청 수와 실제 자원 사용량이 항상 비례하지 않는다는 점입니다. Google Developers Blog의 예시에서 작업 A는 각각 50밀리초 만에 끝나는 짧은 요청 100건을 처리합니다.
반면 작업 B는 요청이 5건뿐이지만 각 세션이 20분 동안 이어집니다. 요청 도착률만 보면 B가 한가해 보이지만, 실제로는 더 오래 지속되는 작업을 이미 책임지고 있습니다.
즉, QPS는 순간적인 요청량은 보여 주지만 현재 유지 중인 작업의 무게까지 설명하지 못합니다. 실시간 연결에서는 요청이 몇 번 발생했는지뿐 아니라 세션이 몇 개 살아 있는지, 각 세션이 얼마나 무거운지를 함께 확인해야 합니다.
핵심은 활성 세션입니다
활성 세션은 현재 서버와 연결되어 실제 작업을 수행 중인 사용자 세션을 말합니다. 음성 대화가 진행 중이거나, 모델이 응답을 생성하고 있거나, 스트리밍 데이터를 주고받는 연결이 여기에 포함됩니다.
활성 세션이 많아지면 런타임이 오디오 버퍼, 부분 전사, 진행 중인 도구 호출, 모델 문맥, 사용자별 지표를 더 오래 유지해야 합니다. 이때 CPU와 메모리 같은 현재 자원 압력도 함께 확인해야 합니다.
더 어려운 점은 세션마다 부하가 다르다는 사실입니다. 조용히 연결만 유지하는 세션과 오디오를 계속 전송하며 모델 응답을 받는 세션을 같은 값으로 계산하면 실제 부하를 정확히 반영하기 어렵습니다.
따라서 활성 세션 수에 더해 CPU·메모리 사용률과 세션 시작·종료·취소 상태를 함께 살펴보는 편이 좋습니다. 중요한 것은 단순한 접속자 수가 아니라 현재 서버가 책임지고 있는 실시간 작업의 총량입니다.
세션 인식 부하 분산은 어떻게 다를까요?
일반적인 로드 밸런서는 새 요청이 들어올 때 요청량과 CPU 사용률을 중심으로 서버를 선택합니다. 반면 세션 인식 부하 분산은 각 서버가 이미 보유한 활성 세션과 현재 자원 압력을 함께 고려합니다.
공식 글은 활성 세션 수가 CPU·메모리 기반 지표를 대체하는 것이 아니라 보완해야 한다고 설명합니다. 세션 수는 앞으로 처리해야 할 약속된 부하를, CPU와 메모리는 지금의 처리 압력을 보여 주기 때문입니다.
백엔드가 세션 시작과 종료를 직접 기록하면 라우팅 계층은 단순 연결 수보다 정확한 상태를 받을 수 있습니다. 타임아웃, 취소, 연결 끊김이 겹쳐도 카운터가 한 번만 감소하도록 설계해야 유령 세션이나 거짓 여유 용량을 피할 수 있습니다.
결국 활성 세션과 자원 사용률을 하나의 하이브리드 신호로 결합하는 것이 핵심입니다. 정확한 알고리즘은 프록시와 워크로드에 따라 달라지지만, 새 세션을 받을 여력이 있는지 판단하는 원칙은 같습니다.
WebSocket과 gRPC에서는 더 중요합니다
WebSocket은 클라이언트와 서버가 연결을 유지하며 양방향으로 데이터를 주고받는 데 적합합니다. 실시간 채팅과 음성 스트리밍, 에이전트 상태 업데이트에서 자주 활용됩니다.
gRPC 역시 양방향 스트리밍 통신을 지원합니다. 두 방식 모두 짧은 요청과 응답만 반복하는 구조보다 연결 수명과 스트림 상태가 중요합니다.
연결이 오래 유지되면 로드 밸런서가 새로운 요청만 보고 서버 상태를 판단하기 어려워집니다. 이미 만들어진 연결 내부에서 많은 데이터가 오갈 수 있지만, 겉으로 보이는 신규 요청 수는 적을 수 있기 때문입니다.
그래서 실시간 시스템에서는 활성 세션 분포, 세션 지속 시간, 첫 스트림까지 걸린 시간, 세션 중단률을 함께 관찰해야 합니다. 강제 연결 끊김 뒤 카운터가 정확히 복구되는지도 검증해야 합니다.
AI 인프라에서 함께 봐야 할 지표
안정적인 AI 인프라를 구축하려면 QPS를 버릴 필요는 없습니다. 다만 QPS 하나만으로 확장과 분산을 결정하지 말고 여러 지표 중 하나로 사용해야 합니다.
우선 서버별 활성 세션과 동시 연결 수를 확인해야 합니다. 여기에 CPU와 시스템 메모리 같은 자원 지표를 함께 보면 현재 압력과 앞으로 감당해야 할 부하를 구분하기 쉬워집니다.
사용자 경험을 확인하는 지표도 필요합니다. 공식 글은 백엔드별 활성 세션 분포, 과부하 서버 배정률, 시작 지연의 p95·p99, 첫 스트림까지 걸린 시간, 세션 중단률을 예로 듭니다.
부하 테스트도 짧은 요청만 몰아보는 방식으로는 부족합니다. 동시 세션 수, 세션 지속 시간, 유입 패턴, 유휴·활성 발화 비율, 취소·연결 끊김 비율, 백엔드 수를 바꿔 가며 라우팅 동작을 비교해야 합니다.
결론
Google Developers Blog가 강조한 방향의 핵심은 단순합니다. 실시간 AI 서비스에서는 요청 횟수뿐 아니라 연결된 사용자가 서버에 남기는 지속적인 부하를 봐야 한다는 것입니다.
QPS는 여전히 유용하지만 활성 세션과 스트리밍 상태를 설명하지는 못합니다. 음성 AI처럼 WebSocket이나 gRPC 연결을 오래 유지하는 서비스라면 세션 인식 부하 분산과 자원 기반 확장 전략이 필요합니다.
결국 좋은 부하 분산은 요청을 고르게 나누는 데서 끝나지 않습니다. 각 서버가 감당하는 세션의 무게를 파악하고, 사용자 대화가 끊기지 않도록 안전하게 배치하는 것이 실시간 AI 에이전트 운영의 핵심입니다.
한 줄 요약: 실시간 AI 인프라에서는 QPS와 활성 세션, 현재 자원 압력을 함께 봐야 합니다.
