Spring AI RAG 시스템 최적화 경험
1. 시작은 단순하게: Redis를 Hash 저장소로 쓰던 구조
처음 RAG 시스템을 만들었을 때 Redis를 아주 단순하게 사용하고 있었다. 당시 구조는 다음과 같았다.
Redis (Hash) → 원본 텍스트 저장
SimpleVectorStore → 메모리에서 벡터 검색즉 Redis는 단순히 텍스트 데이터를 저장하는 저장소였고, 실제 검색은 애플리케이션 메모리에서 동작하는 SimpleVectorStore가 담당하고 있었다. 문제는 서버가 시작될 때 발생했다. 애플리케이션이 실행되면 다음 과정을 매번 반복해야 했다.
1. Redis Hash에서 모든 문서 읽기
2. 각 문서를 임베딩 모델(Ollama)에 전달
3. 벡터 생성
4. SimpleVectorStore 메모리에 로드즉 서버가 실행될 때마다 이미 처리했던 문서를 다시 임베딩하고 있었다. 처음에는 데이터가 많지 않아서 크게 문제가 되지 않았다. 하지만 문서 수가 조금씩 늘어나기 시작하면서 문제가 점점 눈에 띄기 시작했다. 대표적인 문제는 다음과 같았다.
- 서버 부팅 속도가 점점 느려짐
- 매번 같은 문서를 다시 임베딩
- 불필요한 Ollama 호출 증가
- CPU 사용량 증가
특히 같은 데이터를 계속 다시 임베딩하는 과정은 명백한 낭비처럼 느껴졌다.
2. "Redis가 직접 검색하면 안 될까?"
이 문제를 겪으면서 자연스럽게 하나의 질문이 떠올랐다.
"왜 서버가 뜰 때마다 이 과정을 반복해야 하지?"
조금 더 생각해보니 구조 자체가 비효율적이었다.
현재 구조는 사실상 다음과 같았다.
Redis → 단순 데이터 저장
Application → 벡터 생성 + 검색즉 검색의 책임이 전부 애플리케이션에 있었다. 그래서 이런 생각이 들었다.
"차라리 Redis 자체가 검색을 하면 안 될까?"
조금 찾아보니 Redis는 단순한 Key-Value 저장소를 넘어 Vector Similarity Search 기능을 제공하고 있었다. 즉 Redis를 단순 저장소가 아니라 Vector Database처럼 사용할 수 있는 것이었다. 그래서 기존 구조를 다음과 같이 바꾸기로 했다.
3. RedisVectorStore 도입: 구조가 완전히 바뀌다
기존의 SimpleVectorStore를 제거하고 Spring AI에서 제공하는 RedisVectorStore를 사용하도록 구조를 변경했다. 이 변화는 생각보다 훨씬 큰 차이를 만들었다. 기존 구조를 비유하자면 이런 느낌이었다.
이전 구조
서버가 마치 시험 공부하는 학생과 같았다.
학생(서버)
↓
교과서(Redis)
↓
모든 내용 다시 공부(임베딩)
↓
머릿속 저장(SimpleVectorStore)
↓
시험 문제 풀이(검색)즉 시험을 볼 때마다 교과서를 처음부터 다시 읽는 구조였다.
하지만 RedisVectorStore를 도입한 이후에는 구조가 이렇게 바뀌었다.
현재 구조
이제 Redis는 단순한 저장소가 아니라 도서관 사서 역할을 한다.
Application
↓
Redis Vector Search
↓
Relevant Documents
↓
LLM서버는 더 이상 직접 문서를 읽고 임베딩할 필요가 없다. 단순히 Redis에게 이렇게 요청하면 된다.
"이 질문이랑 가장 비슷한 문서 좀 찾아줘."
그러면 Redis가 이미 저장된 벡터 인덱스를 이용해 가장 유사한 문서를 찾아 반환한다.
4. Redis를 Vector DB로 바꾼 뒤 달라진 점
구조를 바꾼 이후 체감되는 변화는 생각보다 컸다.
(1) 서버 부팅 속도 개선
기존에는 서버 시작 시 다음 작업이 필요했다.
문서 로드 → 임베딩 생성 → VectorStore 초기화이 과정 때문에 데이터가 늘어날수록 서버 부팅 시간이 계속 증가했다.
하지만 RedisVectorStore로 변경한 이후에는
Redis 연결이 한 단계만으로 서비스 준비가 끝난다. 체감상 0.1초 수준으로 바로 서비스가 준비됐다.
(2) 임베딩 계산 비용 감소
임베딩 계산은 생각보다 비용이 크다. 특히 로컬에서 Ollama 모델을 호출하는 경우 CPU 자원을 꽤 사용한다. 기존 구조에서는 서버가 시작될 때마다
문서 수 × 임베딩 생성이 작업이 반복됐다. 하지만 이제는 문서가 추가될 때 딱 한 번만 임베딩을 생성하면 된다.
(3) 데이터 영속성 확보
기존에는 벡터 데이터가 애플리케이션 메모리에만 존재했다. 즉 서버가 꺼지면 다시 모든 데이터를 재구성해야 했다. 하지만 Redis Vector Index를 사용하면서
- 벡터 데이터
- 메타데이터
- 문서 정보
모두 Redis 내부에 저장된다. 따라서 서버가 몇 번을 꺼졌다 켜져도 이미 인덱싱된 데이터는 그대로 유지된다.
5. 마무리
돌이켜보면 처음 Redis를 단순 Hash 저장소로만 사용했던 설계는조금은 단순한 접근이었다. 하지만 그 비효율을 직접 경험했기 때문에 Vector Database가 왜 필요한지 훨씬 명확하게 이해할 수 있었다. RAG 시스템을 만들다 보면 단순히 LLM + 문서 만 붙이면 되는 것처럼 보인다. 하지만 실제로는 검색 구조와 데이터 저장 방식이 전체 성능을 크게 좌우한다.
이번 경험을 통해 단순한 저장소였던 Redis를 Vector Database로 활용하는 아키텍처로 전환할 수 있었고, 과정에서 RAG 시스템의 구조를 훨씬 깊게 이해할 수 있었다.
