Oracle 벡터 인덱스 GPU 오프로딩: 구축 시간과 검색 응답은 다르다

“RAG가 느리다”는 말에 두 개의 시계가 있다

사내 매뉴얼이 밤마다 바뀌는데 아침에도 새 내용을 검색하지 못한다. 다른 팀은 문서 준비가 이미 끝났지만 질문 한 번에 답이 늦게 나온다. 두 팀 모두 “RAG가 느리다”고 말할 수 있지만, GPU를 붙일 자리는 같지 않다.

첫 번째는 문서 추출·분할·임베딩·적재·인덱스 구축·검증이 끝나기까지의 자료 준비 시간이다. 두 번째는 검색·재정렬·모델 생성으로 이어지는 질문 응답 시간이다. 인덱스를 빨리 만들었다는 숫자만으로 두 번째 문제도 해결됐다고 판단하면 잘못된 투자를 할 수 있다.

10월 27일 Oracle AI World의 NVIDIA 공식 세션 안내는 cuVS를 활용하는 Oracle 벡터 인덱스 서비스를 다뤘다. 이 글은 그 시점을 계기로 구축 가속의 의미를 분석한다. 세션 영상을 재현한 실험이나 신규 기능 출시 보도는 아니다.

날짜	확인한 자료	이 글에서의 의미
2026년 5월 18일	Oracle의 Vector Index Service 실습 글	행사 이전부터 기능과 실행 사례가 공개돼 있었음
2026년 10월 27일	Oracle AI World 공식 GPU 벡터 검색 세션 일정	지금 구축 가속과 RAG의 관계를 다시 살펴볼 계기
2026년 10월 28일	26ai 사용·설정·제약 문서 확인	아래 기능 범위를 판단한 시점

GPU에서 만들고, 데이터베이스에서 사용한다

벡터 인덱스는 질의 벡터와 가까운 자료를 찾기 위한 검색 구조다. HNSW 원논문은 가까운 벡터를 연결한 그래프를 계층적으로 탐색하는 구조를 설명한다. 모든 벡터를 하나씩 비교하는 비용을 줄이려는 근사 검색이므로, 구축 속도뿐 아니라 필요한 이웃을 얼마나 잘 찾는지도 중요하다.

Oracle의 제품 설명은 이 그래프를 만드는 데 많은 거리 계산이 필요하고, GPU의 병렬 처리와 메모리 대역폭을 활용할 수 있다고 설명한다. 벡터를 만드는 임베딩 모델과 벡터 사이의 검색 구조를 만드는 계산은 별도 단계다.

현재 사용 문서에 따르면 생성 요청과 벡터가 Private AI Services Container의 Compute Offload Server로 전달된다. 외부 NVIDIA GPU는 cuVS의 CAGRA로 그래프를 만들고, 결과가 DB로 돌아오면 HNSW 인덱스로 변환된다. 이 컨테이너는 인덱스 생성 때 쓰이며, 이후 DML과 질의는 DB의 테이블·HNSW 인덱스에서 실행된다. DML은 행을 추가·수정·삭제하는 작업을 뜻한다.

따라서 “GPU 벡터 검색”이라는 넓은 표현을 이 서비스에 적용할 때는 가속 대상부터 확인해야 한다. 질문마다 외부 GPU로 검색을 보내는 구성으로 읽으면 안 된다. 인덱스 생성이 DB CPU 자원을 두고 다른 업무와 경쟁하던 환경이라면 자원 분리도 검토할 가치가 있지만, 그 효과는 동시 부하에서 따로 측정해야 한다.

10배 빠른 계산이 전체 준비 시간을 10분의 1로 만들지는 않는다

밤마다 자료 전체를 다시 준비하는 가상 업무를 생각해 보자. 추출·임베딩·적재·품질 검사에 합계 60분, CPU 인덱스 구축에 80분이 걸린다고 가정한다. GPU 그래프 계산은 8분, 데이터와 결과 전송에 12분, DB 측 변환·마무리에 5분이라고 두자. 이 숫자는 Oracle 실험에서 가져온 값이 아니다.

CPU 경로의 준비 시간 = 공통 작업 + CPU 구축
GPU 경로의 준비 시간 = 공통 작업 + 대기 + 전송 + GPU 구축 + DB 마무리

GPU 경로가 더 빠를 조건:
CPU 구축 > 대기 + 전송 + GPU 구축 + DB 마무리

단계가 겹치지 않고 순서대로 진행된다는 가정이다. 실제 파이프라인에 중첩 실행이 있으면 단순 합 대신 마지막 결과가 준비되는 시점을 비교한다.

가상 상황	CPU 경로	GPU 경로	다음 판단
큰 구축 작업: CPU 80분, GPU 8분	140분	85분	120분 준비 기한이라면 GPU 경로만 충족
작은 구축 작업: CPU 8분, GPU 2분	68분	79분	전송 12분·마무리 5분이 절약보다 큼
첫 상황에 GPU 대기 55분 추가	140분	140분	시간 이득이 사라짐

첫 줄에서 그래프 계산은 80분에서 8분으로 줄었지만 전체는 140 ÷ 85 ≈ 1.65배다. 55분을 줄여 약 39.3% 단축한 셈이다. GPU 구축 시간만 보면 놓치는 질문은 “오늘 아침 업무에 새 자료를 제공할 수 있는가”다. 반대로 공통 작업 60분이 대부분을 차지한다면 임베딩이나 적재를 먼저 개선할 수도 있다.

세 번째 줄은 여러 인덱스 요청을 외부 작업 큐에 순차 배치한다고 가정한 사례다. 서비스 내부에 자동 큐가 있다고 주장하는 것이 아니다. 현재 문서는 동시 오프로딩을 지원하지 않는다고 명시하므로, 여러 작업을 무조건 동시에 보내는 방식은 도입 계획에서 제외해야 한다. 지원 제약

자체 계산 파일을 내려받아 python3 vector-offload-budget.py로 위 세 경우를 재계산할 수 있다. 파일 앞의 SCENARIOS를 자신의 분 단위 값으로 바꾸면 된다. DB나 네트워크에 접속하지 않으며, 출력은 입력 가정의 산술 결과다. 요금·GPU 이용률·검색 성능을 측정하는 도구는 아니다.

공급자 실험의 “수백만 벡터”를 내 자료와 비교하는 법

Oracle의 5월 실습은 DB 23.26.2, 컨테이너 gpu-index-26.1.0.0.0, A10 환경을 사용했다. 320만 벡터로 만든 HNSW에 대해 CPU 경로는 24분부터 40분, GPU 서비스 경로는 76초부터 138초를 보고했다. 이는 공급자가 특정 환경에서 얻은 결과이며 이 글에서 재실행하지 않았다.

여기서 벡터 수만 읽으면 중요한 조건을 놓친다. 공개된 생성 입력의 차원은 2다. 실제 업무에서 쓰는 높은 차원의 임베딩과 같은 입력이 아니다. CPU 측 VM 변동성도 기록돼 있으므로 범위의 양 끝을 나눠 보편적인 가속 배수를 만들지 않는 편이 좋다.

차원 차이가 뜻하는 것은 먼저 데이터 크기다. 자체 계산으로, 100만 개의 조밀한 벡터를 차원당 4바이트로 저장한다고 가정하면 2차원은 8MB, 1,536차원은 6.144GB다. 여기서 MB·GB는 각각 백만·십억 바이트다. 논리적인 벡터 배열만 계산했으며 실제 전송 형식·그래프·임시 버퍼는 제외했다. 768배의 데이터 크기 차이가 768배의 실행 시간이나 메모리 사용량을 뜻하지는 않는다.

비교를 옮길 때는 벡터 수와 함께 차원·자료형·거리 함수·인덱스 설정·DB 자원·전송 경로를 고정해야 한다. 같은 인덱스 이름과 같은 행 수만 맞춘 실험은 충분한 대조가 아니다. 현재 설치 가능 버전·GPU/드라이버 조합은 별도 설치 문서로 확인해야 하며, 5월 실습 버전을 모든 26ai 환경의 지원 보증으로 쓰지 않는다.

메모리는 세 곳에서 확인한다

원격 GPU에 계산을 옮겨도 DB가 최종 인덱스를 사용할 메모리는 필요하다. Oracle 메모리 문서는 DB vector pool, 컨테이너 호스트 메모리, GPU 메모리를 함께 고려하도록 한다. DB vector pool이 인덱스를 담지 못하면 생성에 실패하고, 컨테이너 쪽 메모리 부족에는 ORA-52342가 발생한다고 설명한다.

실무 판단은 다음처럼 나눌 수 있다.

확인할 자리	읽어야 할 값	값이 부족할 때의 선택
DB vector pool	최종 인덱스가 들어갈 여유	DB 메모리 배분과 다른 업무의 영향을 다시 설계
GPU	구축 중 최고 사용량과 다른 프로세스 점유	작업 크기·장비·스케줄을 조정
컨테이너 호스트	데이터와 작업 처리에 필요한 메모리	GPU만 증설하지 말고 호스트 구성도 확인

문서는 NEIGHBORS를 낮추면 메모리를 줄일 수 있지만 정확도가 낮아질 수 있다고 안내한다. 그래서 메모리 부족을 해결한 다음에는 같은 질의 집합으로 검색 품질을 다시 확인해야 한다. “생성이 성공했다”는 결과와 “필요한 문서를 충분히 찾는다”는 결과를 각각 남긴다.

지원 형태도 맞아야 한다. 현행 서비스는 Online·Distributed HNSW, 포함 열이 있는 인덱스, FLOAT64·BINARY 벡터, 스칼라 양자화 HNSW 등을 지원하지 않는다. 거리 함수에도 제약이 있으므로 자신의 설정을 제약 목록과 대조한다. 평소 사용하는 인덱스에서 오프로딩 옵션만 켜면 모두 동작한다고 가정하지 않는다.

작은 성공을 전체 경로의 성공으로 바꾸지 않기

설정에서 먼저 분리할 것은 호스트가 접속할 수 있는지와 DB 사용자가 실제 요청을 보낼 수 있는지다. DB 설정 문서는 연결 확인 외에 SSL wallet, 인증서, 같은 PDB·스키마의 credential, 네트워크 접근 설정을 설명한다. 운영 DB의 기존 wallet을 덮어쓰는 일괄 명령 대신 현재 구성을 확인해 적용해야 한다.

/health가 응답하면 컨테이너에 닿았다는 단서는 얻지만, 큰 데이터의 왕복과 인덱스 완성까지 증명한 것은 아니다. 프록시를 거치면 차이가 더 중요하다. 프록시 문서는 TLS 1.3과 전 구간 HTTP/2, 양방향 스트리밍, 버퍼링과 요청 크기·시간 제한을 점검하도록 한다. 작은 health 응답과 오래 걸리는 데이터 전송은 같은 조건이 아니다.

예를 들어 작은 입력은 성공했는데 큰 입력만 일정 시간 후 실패한다면 GPU 연산 속도만 볼 일이 아니다. 이는 가상 장애 조사 순서다. DB와 컨테이너의 오류 시각을 맞추고, 메모리 부족인지 연결 종료인지 먼저 구분한 뒤, 해당 프록시의 실제 제한과 대조한다. 모든 실패를 timeout으로 단정하거나 전역 제한을 무조건 해제하지 않는다. 연결을 고친 뒤에는 작은 생성부터 확인하고 원래 입력으로 되돌아가 결과를 검증한다.

이 글에서 Oracle DB·컨테이너·CUDA는 실행하지 않았다. 위 내용은 공식 계약을 바탕으로 만든 도입·조사 기준이며 검증된 설치 튜토리얼이 아니다.

첫 비교에서 남길 한 장

팀의 첫 실험은 아래처럼 같은 자료를 두 경로에 넣고 준비 완료 시점을 비교하도록 설계할 수 있다. 복사용 비교 기록표에는 환경과 미확인 결과를 채울 자리를 마련했다. 실제 측정 전에는 빈칸을 공급자 숫자로 대신하지 않는다.

비교 항목	고정하거나 기록할 것
입력	문서 스냅샷, 벡터 수·차원·자료형, 임베딩 버전
인덱스	거리 함수, HNSW 설정, 사용 가능한 기능인지 여부
시간	공통 준비, 대기, 전송, 그래프 생성, DB 마무리, 최종 사용 가능 시각
자원	DB 부하·vector pool, GPU·호스트 최고 메모리, GPU 할당 시간
품질	같은 질의와 필터에서 필요한 근거의 포함 여부, 응답 지연
결정	준비 기한 충족, 비용, 실패 후 재시도·운영 부담

단계별 시간이 도구에서 분리돼 보이지 않으면 GPU 경로 전체 시간부터 기록한다. 전체 시간에 이미 전송이 들어 있는데 추정 전송 시간을 다시 더하면 잘못된 비교가 된다. 품질 역시 목표가 필요하다. 인덱스 구조의 근사 오차를 보려는 정답 이웃 비교와, 업무 질문에 필요한 문서가 들어오는지 보는 평가는 각각 다른 질문이다.

대규모 자료를 새로 넣거나 반복 재구축하는 작업이 준비 기한을 넘고, 지원 조건과 데이터 이동 경로를 맞출 수 있다면 이 오프로딩을 검토할 이유가 있다. 이미 인덱스가 준비돼 있고 모델 생성이 느린 서비스, 전송 비용이 더 큰 작은 작업, 미지원 인덱스가 필요한 업무라면 먼저 바꿀 곳이 다르다.

검색 결과 자체가 틀리는 문제는 하이브리드 검색과 재정렬, 자료를 언제 갱신하고 모델에 무엇을 넣을지는 긴 문맥과 RAG에서 이어 볼 수 있다. 구축 비교표를 다시 사용할 때는 이 글을 저장하고, 후속 분석은 AI 시스템 주제 모음이나 RSS에서 확인할 수 있다.