AI 추론은 전혀 다른 규칙으로 작동한다

AI 에이전트의 추론은 **OLTP++**처럼 동작한다. 사람이 천천히 버튼을 누르는 대신 ReAct 루프가 밀리초 단위로 여러 쿼리를 병렬 발행하면서, 문제는 단순한 컴퓨트가 아니라 폭증하는 동시성과 예측 불가능한 읽기 패턴이 된다.

RAG와 벡터 검색의 병목도 프롬프트가 아니라 데이터 경로에 있다. HNSW와 IVFFlat에 메타데이터 필터링이 붙으면 인덱스 스캔, 임베딩 조회, scatter-gather 지연이 겹치고, 핫 벡터에서 sub-millisecond 읽기와 수억 행 규모의 예측 가능한 처리량이 필요하다고 강조한다. RDS 읽기 복제본을 늘리는 방식은 병목을 옮길 뿐이라는 지적도 나온다.

AWS EBS는 버스트 크레딧과 per-volume IOPS/throughput 상한 때문에 갑작스러운 AI 트래픽을 버티기 어렵다. 그래서 평균 지연시간보다 p99/p999 tail latency를 실제 혼합 부하에서 봐야 하며, 다음 상황을 함께 검증해야 한다.

• Concurrent OLTP + inference + maintenance jobs: 대규모 배치나 vacuum이 돌 때 벡터 검색이 어떻게 변하는지 확인해야 한다.
• AZ-to-AZ variability: 장애 조치나 배치 변화 때 지연이 얼마나 늘어나는지 봐야 한다.
• Autoscaling events and cache warm-ups: 새 EC2 노드가 붙을 때 캐시가 얼마나 빨리 예열되는지가 중요하다.

예시로 든 FinRetail은 40단계 추론과 수백 번의 벡터 검색으로 15분 만에 EBS 버스트 크레딧을 소진했고, 지연시간이 0.8ms에서 120ms로 튀며 사이트 장애와 오래된 재고 추천을 불렀다. 글은 성능과 용량을 분리한 소프트웨어 정의 스토리지가 필요하다고 주장하며, Silk가 분산 캐시와 symmetric active-active 구조로 20 GiB/s 처리량과 안정적인 tail latency를 내세운다고 설명한다.