Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
본 가이드는 검색 기반 AI 엔드포인트의 지연 시간(Latency)을 p99 기준으로 예산 책정하는 방법을 제시합니다. 네트워크, 벡터 검색, 모델 추론 등 각 구성 요소별로 예상되는 최대 지연 시간을 분석하고, 이를 바탕으로 전체 시스템 성능 목표를 설정하는 것이 중요함을 강조합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기AI 기능의 대부분의 지연 시간 목표는 티켓 하나에 하나의 숫자로 도착합니다: "200ms 미만". 아무도 200ms를 전담하지 않습니다. 누군가는 벡터 검색을 담당하고, 누군가는 모델 서버를 담당하며, 누군가는 그 사이 네트워크를 담당하고, 각자 자신이 대부분의 시간을 차지할 것이라고 가정합니다.
아래는 검색 기반 AI 엔드포인트를 위해 제가 시작하는 예산입니다. 쿼리가 들어오고, 관련 항목들이 검색되며, 모델이 이를 순위 매기거나 점수를 매기고, 사용자가 기다리는 동안 결과가 반환됩니다. 시맨틱 검색(Semantic search), 추천 시스템, RAG 스타일의 조회 모두 대략 이와 같은 형태를 가집니다. 이것을 복사하여 자신의 스택에 맞게 조정하고, 인시던트 리뷰가 아닌 디자인 리뷰에서 이에 대해 논쟁하세요.
| Bucket | Line item | p99 budget | What usually blows it |
|---|---|---|---|
| Network | Client to edge, round trip | 25 ms | Fresh TLS handshakes, distant regions |
| ... |
모든 숫자는 평균이 아닌 p99입니다. 각 단계를 p99로 예산 책정하는 것은 의도적으로 보수적입니다. 왜냐하면 모든 단계가 같은 요청에서 꼬리 지연 시간(tail)에 도달하는 경우는 거의 없기 때문입니다. 예외적인 곳은 여러 호출 중 가장 느린 호출을 기다리는 팬아웃(fans out)이 발생하는 경우입니다. 이것이 메타데이터 라인이 벡터 검색 자체보다 더 많은 시간을 할당받는 이유입니다.
추론(Inference)이 가장 큰 항목이며, 재순위화기(reranker)가 가장 큰 단일 항목입니다. 크로스 인코더(cross-encoder)의 비용은 후보 개수와 그 길이에 따라 증가하므로, 재순위화 세트를 50개에서 20개로 줄이는 것이 모델 튜닝을 아무리 많이 해도 얻는 시간보다 더 많은 시간을 절약해 주는 경우가 많습니다.
네트워크(Network)가 40ms로 여유롭게 보이지만, 사용자가 대륙 전역에 퍼져 있다면 그렇지 않습니다. 따라서 더 많은 지역에서 서비스를 제공하거나 출시 전에 테이블을 재조정해야 합니다.
여유분(headroom)은 전체의 15%입니다. 이는 배포(deploys), 가비지 컬렉션 일시 중단(garbage collection pauses), 노이즈 이웃(noisy neighbors), 그리고 다음 분기에 추가될 누군가의 단계를 커버합니다. 종이에 15%의 여유분을 찾을 수 없다면, 프로덕션에서도 찾을 수 없을 것입니다.
이 순서대로 줄이세요.
작업량을 줄이세요. 후보군을 재순위화(re-rank)할 대상을 적게 하고, 문서 대신 ID를 반환하며, 필터를 인덱스 쿼리(index query)로 밀어 넣어 버릴 결과물을 검색하지 않도록 하세요.
요청 경로에서 작업을 분리하세요. 빈번한 쿼리에 대한 임베딩(embeddings)을 캐시하고, 메타데이터를 요청이 한 번에 접근할 수 있는 스토어(store)에 보관하며, 사용자가 요청할 때가 아니라 이벤트가 도착했을 때 피처(features)를 새로 고치세요.
그다음 속도를 구매하세요. 더 빠른 하드웨어 또는 작고 양자화된(quantized) 모델을 사용합니다. 효과는 있지만, 가장 비싼 해결책이며 팀들이 가장 먼저 찾는 방법입니다.
테이블이 균형을 이루면, 전체 합계뿐만 아니라 각 항목에 p99 경고를 설정하세요. 전체가 깨졌을 때, 어떤 항목 때문에 문제가 발생했는지 알고 싶기 때문입니다.
먼저, 200ms라는 시간이 적절한지 확인하세요.
이 테이블은 200ms가 올바른 목표라고 가정하지만, 실제로는 그렇지 않은 경우도 있습니다. 1초 안에 답변할 수 있는 기능이나 페이지 로드 후에 나타나는 기능을 위해서는 더 저렴한 설계가 필요합니다. 만약 그 결정이 아직 내려지지 않았다면, 실시간 AI 아키텍처에 대한 워크스루(walkthrough)를 읽어보는 것이 좋습니다. 이 글을 읽기 전에 어떤 항목에 대해서도 방어하기는 어렵습니다.