Spring AI, Oracle AI Database 26ai, 그리고 Oracle True Cache를 활용한 시맨틱 캐싱 (Semantic

핵심 요약 (Key Takeaways)

• 시맨틱 캐싱 (Semantic caching)은 단순한 벡터 검색 (Vector search)이 아니라, 정책에 의해 제어되는 답변 재사용입니다. 최근접 이웃 (Nearest-neighbor) 매칭은 테넌트 (Tenant), 보안 (Security), 모델 (Model), 프롬프트 템플릿 (Prompt-template), 데이터 도메인 (Data-domain), 임계값 (Threshold), 최신성 (Freshness) 및 재사용 정책 (Reuse policy)이 승인하기 전까지는 단지 후보일 뿐입니다.
• 시맨틱 캐시 답변을 검색 증강 생성 (RAG, Retrieval-Augmented Generation) 문서와 분리하여 유지하십시오. RAG는 새로운 답변을 위해 소스 자료를 검색하지만, 시맨틱 캐싱은 재사용이 안전할 때만 이전에 생성된 답변을 검색합니다.
• 캐시 조회 (Cache lookup) 시 벡터 순위 지정 (Vector ranking)과 SQL 술어 (SQL predicates)가 모두 필요한 경우 Oracle AI Database 26ai가 매우 적합합니다. 네이티브 VECTOR, VECTOR_DISTANCE(), 벡터 인덱스 (Vector indexes), 관계형 컬럼 (Relational columns), 트랜잭션 (Transactions), 메타데이터 (Metadata), 출처 (Provenance) 및 무효화 상태 (Invalidation state)가 하나의 SQL 기반 레코드에 공존할 수 있습니다.
• Oracle True Cache는 적절한 읽기 전용 조회 경로 (Read-only lookup path)에 배치되어야 합니다. 이 시리즈에서 우리는 라우팅 (Routing) 및 최신성 규칙이 적합한, 조회 중심의 시맨틱 캐시 SQL 트래픽을 위해 이를 사용합니다. Oracle True Cache는 임베딩 (Embeddings)을 계산하거나, 시맨틱 동등성 (Semantic equivalence)을 판단하거나, 캐시된 답변을 승인하지는 않습니다.

여러분의 Spring AI 애플리케이션은 아마도 다음과 같은 트래픽을 경험했을 것입니다:

프롬프트 A: "비밀번호를 어떻게 재설정하나요?"
프롬프트 B: "로그인 비밀번호를 잊어버렸습니다. 어떻게 재설정하죠?"
프롬프트 C: "계정 액세스 복구를 도와줄 수 있나요?"

만약 정확한 프롬프트 텍스트로만 캐싱한다면, 이것들은 세 개의 서로 다른 문자열입니다. 애플리케이션이 이를 동일한 범위의 키 (Scoped key)로 정규화 (Normalize)하지 않는 한, 세 번의 미스 (Miss), 세 번의 대규모 언어 모델 (LLM, Large Language Model) 호출, 그리고 본질적으로 동일한 답변에 대해 지연 시간 (Latency)과 토큰 (Tokens)을 소비할 세 번의 기회를 얻게 됩니다.

이것이 바로 시맨틱 캐싱이 해결하고자 하는 문제입니다.

시맨틱 응답 캐싱 (Semantic response caching)은 새로운 프롬프트가 시맨틱적으로 유사하고 애플리케이션 정책이 재사용이 안전하다고 판단할 때, 이전에 생성된 답변을 재사용합니다. "이 정확한 문자열을 이전에 본 적이 있는가?"라고 묻는 대신, 애플리케이션은 더 유용한 질문을 던집니다: "충분히 유사한 질문에 이미 답변한 적이 있는가, 그리고 그 답변을 이 요청에 재사용하는 것이 여전히 안전한가?"

그 질문의 후반부는 아키텍처의 정직함을 유지하는 핵심입니다. 시맨틱 캐시 (Semantic Cache)는 단순히 "벡터 검색 (Vector Search) = 캐시 히트 (Cache Hit)"를 의미하는 버튼이 아닙니다. 벡터 검색은 후보군을 제안할 뿐입니다. 재사용을 허용할지 여부는 애플리케이션과 데이터베이스 정책 (Policy)이 결정합니다.

이 지점이 바로 Spring AI 개발자들에게 Oracle AI Database 26ai가 흥미로워지는 부분입니다. 시맨틱 캐시 항목은 단순히 일회용 캐시 키가 아닙니다. 많은 애플리케이션에서 이들은 테넌트 (Tenant), 보안 (Security), 채팅 모델 (Chat Model), 임베딩 모델 (Embedding Model), 프롬프트 템플릿 (Prompt Template), 데이터 도메인 (Data Domain), 최신성 규칙 (Freshness Rules), 출처 (Provenance), 무효화 상태 (Invalidation State), 피드백 (Feedback), 그리고 운영 메트릭 (Operational Metrics)에 의해 제어되는 관리 기록 (Governed Records)입니다. Oracle AI Database 26ai를 사용하면 프롬프트 임베딩 (Prompt Embedding)과 정책 메타데이터 (Policy Metadata)를 동일한 트랜잭션 데이터베이스 레코드에 저장하고 함께 쿼리할 수 있습니다.

Oracle True Cache는 그 결정 단계의 바로 한 단계 아래 계층에 적합합니다. 시맨틱 캐시 조회 (Lookup)가 읽기 집약적 (Read-heavy)으로 변할 때, True Cache는 시맨틱 캐시 히트의 의미를 변경하지 않고도 적절한 읽기 전용 조회 트래픽을 지원할 수 있습니다.

이 글은 시리즈의 첫 번째 기사이므로, 아키텍처 수준에 머무를 것입니다. 우리는 구성 요소들을 정의하고, 경계를 설정하며, 구현과 벤치마크가 보존해야 할 결정 규칙을 세울 것입니다.

서로 다른 캐시 계층은 서로 다른 LLM 애플리케이션 문제를 해결합니다

LLM 애플리케이션을 둘러싼 캐싱 논의는 여러 메커니즘이 반복 작업을 줄여주지만, 이들이 서로 다른 계층에서 작동하기 때문에 혼란스러울 수 있습니다. 이를 명확하게 구분하는 가장 간단한 방법은 각 계층이 무엇을 저장하는지, 그리고 재사용이 안전한지 여부를 누가 결정하는지 묻는 것입니다.

**정확한 응답 캐시 (Exact Response Cache)**는 결정론적 키 (Deterministic Key) 아래에 답변을 저장합니다. 해당 키에는 일반적으로 정규화된 프롬프트 텍스트와 함께 테넌트, 채팅 모델, 프롬프트 템플릿, 애플리케이션, 데이터 도메인과 같은 범위 (Scope)가 포함됩니다. 정확한 캐싱 (Exact Caching)은 단순하며 종종 시작하기에 가장 안전한 방법입니다. 동일한 범위의 요청이 다시 도착하면 동일한 답변을 반환합니다. 만약 문구가 변경되면, 정확한 키도 대개 함께 변경됩니다.

**시맨틱 응답 캐시 (semantic response cache)**는 이전 프롬프트 임베딩 (embedding)과 생성된 답변, 그리고 정책 메타데이터를 저장합니다. 새로운 요청이 도착하면 애플리케이션은 새 프롬프트를 임베딩하고 근처에 있는 이전 프롬프트들을 검색합니다. 유사한 매칭이 발견되면 정책이 재사용을 승인하는 경우에 한해 추가적인 LLM 호출을 피할 수 있습니다.

**검색 증강 생성 (RAG) 저장소 (retrieval-augmented generation (RAG) store)**는 이와 다릅니다. RAG는 새로운 답변을 구성하는 데 사용되는 소스 자료, 즉 문서 청크 (chunks), 정책 텍스트, 제품 매뉴얼, 지원 문서, 티켓 또는 기타 기록들을 검색합니다. RAG 검색은 "이 오래된 모델 답변을 반환하라"는 의미가 아닙니다. 이는 "생성 단계로 관련 소스 콘텐츠를 가져오라"는 의미입니다.

데이터베이스 결과 캐시 (database result cache) 또는 **HTTP 캐시 (HTTP cache)**는 일반적으로 정확한 쿼리나 리소스에 대한 결정론적 (deterministic) 출력을 캐싱합니다. 이는 의역 (paraphrases)을 이해하지 못합니다. 유용하기는 하지만, 시맨틱 매칭 (semantic matching)은 아닙니다.

LLM 제공자 프롬프트 캐시 (LLM provider prompt cache) 또한 인접해 있지만 동일하지는 않습니다. 제공 가능한 경우, 제공자 측의 프롬프트 캐싱 (prompt caching)은 반복되는 프롬프트 접두사 (prefixes)나 컨텍스트 블록 (context blocks)에 대한 제공자 측의 처리량을 줄일 수 있습니다. 하지만 애플리케이션은 여전히 요청을 보내며, 제공자는 여전히 응답을 생성합니다. 시맨틱 응답 캐싱은 생성을 건너뛰고 이전 답변을 재사용하도록 애플리케이션이 제어하는 결정입니다.

Oracle True Cache는 또 다른 계층입니다. True Cache는 Oracle AI Database 앞단에 위치하는 인메모리 (in-memory) 읽기 전용 캐시입니다. 이 아키텍처에서 True Cache는 시맨틱 캐시 후보를 조회하는 동안 적절한 데이터베이스 읽기 작업을 도와줍니다. True Cache 자체가 시맨틱 캐시인 것은 아니며, 두 프롬프트가 동일한 의미를 갖는지 여부를 결정하지도 않습니다.

Oracle AI Database 26ai는 시맨틱 캐시(semantic-cache)의 시스템 레코드(system of record) 역할을 합니다. 벡터 유사도(Vector similarity)가 후보(candidates)를 제안하면, SQL 술어(predicates)가 적격한 집합을 좁히고, Oracle True Cache가 적격한 읽기 전용 조회 트래픽을 지원하며, 앱은 재사용을 위해 승인된 후보가 없을 때만 LLM을 호출합니다.

다이어그램 상으로는 이 차이가 작아 보일 수 있습니다. 하지만 실제 운영 코드(production code)에서는 안전한 재사용과 잘못된 결과(false-positive)를 내놓는 기계 사이의 결정적인 차이가 됩니다.

시맨틱 캐시 후보는 '히트(hit)'가 아니다

비밀번호 예시를 다시 살펴보겠습니다.

정확한 캐시(exact-cache) 조회:
A -> MISS -> LLM 호출 -> 답변 저장
B -> MISS -> LLM 다시 호출
...

이제 이를 시맨틱 캐시(semantic-cache) 경로와 비교해 보겠습니다.

시맨틱 캐시(semantic-cache) 조회:
A -> MISS -> LLM 호출 -> 프롬프트 임베딩(prompt embedding) + 답변 + 정책 메타데이터(policy metadata) 저장
B -> 후보(CANDIDATE) -> 정책 통과 -> 답변 재사용
...

**후보(candidate)**라는 단어에 주목하십시오.

단순한 계정 도움말 FAQ 애플리케이션에서 프롬프트 B는 아마도 프롬프트 A를 안전하게 의역(paraphrase)한 것일 것입니다. 프롬프트 C는 더 광범위합니다. “계정 액세스 복구”는 비밀번호 재설정, 계정 잠금 해제, 사용자 이름 복구, 다요소 인증(multi-factor authentication) 통과 또는 고객 지원 상담을 의미할 수 있습니다. 프롬프트 C가 동일한 답변을 재사용할 수 있는지 여부는 귀하의 도메인과 정책에 달려 있습니다.

이것이 유지해야 할 사고 모델(mental model)입니다: 벡터 유사도는 후보를 제안하고, 정책이 히트(hit)를 승인합니다.

애플리케이션이 캐시된 답변을 반환하기 전에 시맨틱 캐시 후보는 다음과 같은 검사를 통과해야 합니다:

• 동일한 테넌트(tenant) 또는 권한이 부여된 공유 범위(sharing scope)
• 동일한 보안 범위(security scope)
• 동일한 애플리케이션 및 데이터 도메인
• 재사용 정책에 따른 호환 가능한 채팅 모델 또는 모델 제품군(model family)
• 동일한 임베딩 모델(embedding model) 및 임베딩 차원(embedding dimension)
• 동일한 프롬프트 템플릿(prompt template) 및 프롬프트 템플릿 버전
• 만료되지 않았으며 무효화되지 않음
• 허용 가능한 벡터 거리(vector distance) 또는 유사도 임계값(similarity threshold)
• 허용 가능한 출처(provenance) 및 소스 정책(source-policy) 버전

이러한 검사 중 일부는 벡터 저장소(vector-store)의 메타데이터 필터에 포함될 수 있습니다. Oracle 기반 설계에서는 벡터 순위(vector ranking)와 함께 이를 SQL 술어(SQL predicates)로 직접 인코딩할 수도 있습니다.

Spring AI는 AI 흐름을 처리하고, 시맨틱 캐시(semantic-cache) 서비스가 재사용 정책을 소유합니다

Spring AI는 채팅 클라이언트(chat clients), 임베딩 모델(embedding models), 벡터 저장소 추상화(vector-store abstractions), SearchRequest, 메타데이터 필터(metadata filters), 제공자 통합(provider integrations), 그리고 어드바이저 스타일의 요청 인터셉션(advisor-style request interception)을 포함하여 이 아키텍처를 위한 애플리케이션 수준의 구성 요소들을 제공합니다. Spring AI의 벡터 데이터베이스 참조 문서에는 top-k, 임계값(threshold), 필터 표현식(filter expressions)을 포함한 유사도 검색(similarity search) 기능이 포함된 핵심 VectorStore 형태가 설명되어 있습니다. 또한 Spring AI는 Oracle Database AI Vector Search를 위한 OracleVectorStore 통합 기능에 대해서도 문서화하고 있습니다.

Oracle 구현을 위한 중요한 설계 선택 사항은 시맨틱 캐시 저장소를 전용(dedicated)으로 유지하는 것입니다. 애플리케이션에 이미 RAG용 벡터 저장소가 있더라도, 캐싱된 답변을 위해 이를 조용히 재사용하는 것은 피하십시오. 캐시에는 별도의 Oracle 테이블, 스키마 또는 엄격한 메타데이터 범위(metadata scope)를 부여하십시오.

대상으로 하는 Spring AI 버전에 따라 구현은 다음 두 가지 경로 중 하나를 따를 수 있습니다:

• 선택한 버전이 요구되는 정책 및 저장 모델에 적합한 캐시 컴포넌트를 제공하는 경우, Spring AI 캐시 컴포넌트를 사용합니다.
• Spring AI 옆에 작은 Oracle 네이티브 시맨틱 캐시(semantic-cache) 서비스를 구현합니다. 이때 임베딩과 채팅에는 Spring AI를 사용하고, 벡터 및 정책 조회(vector-plus-policy lookup)는 Oracle AI Database 26ai가 처리하도록 합니다.

두 번째 옵션은 임시방편(workaround)이 아닙니다. 캐시 결정에 엄격한 관계형 술어(relational predicates), 트랜잭션 히트 로깅(transactional hit logging), 무효화(invalidation), 출처(provenance) 및 보고(reporting)가 필요한 경우, 이는 더 깔끔한 프로덕션 형태가 될 수 있습니다. Spring AI는 Java AI 프레임워크로 남고, Oracle AI Database 26ai는 관리되는 시맨틱 캐시 백엔드(governed semantic-cache backend) 역할을 수행합니다.

한 가지 실질적인 주의 사항은, 모든 Spring AI 캐시 API가 백엔드에 독립적(backend-agnostic)이라고 가정하거나, 모든 벡터 저장소 추상화가 테넌트(tenant), 보안, 모델, 템플릿, 최신성(freshness) 및 무효화 정책을 엄격하게 관리하기에 충분하다고 가정하지 마십시오. Oracle 경로를 선택할 경우, Spring AI 버전과 Oracle AI Database 대상을 고정한 다음, OracleVectorStore 메타데이터 필터만으로 충분할지 아니면 직접적인 Oracle SQL을 사용하는 것이 더 명확한 구현 방식일지를 결정하십시오.

이 아키텍처 관련 글에서 중요한 경계는 간단합니다. Spring AI는 애플리케이션의 AI 흐름을 처리하고, 시맨틱 캐시 (semantic-cache) 서비스는 답변 재사용 여부를 결정하는 권한을 갖습니다.

시맨틱 캐시 조회 아키텍처

주요 조회 경로는 단순한 리듬을 따릅니다.

애플리케이션은 프롬프트 (prompt)를 수신하고 먼저 범위가 지정된 정확한 캐시 키 (exact-cache key)를 생성합니다. 정확한 일치 항목이 없으면 프롬프트에 대한 임베딩 (embedding)을 생성합니다. 그런 다음 전용 Oracle 시맨틱 캐시 테이블을 쿼리하여 정책 적용이 가능한 가장 유사한 후보들을 찾습니다. 후보가 임계값 (threshold)과 재사용 정책을 통과하면 애플리케이션은 캐시된 답변을 반환합니다. 통과하지 못하면 LLM을 호출하고, 새로운 답변과 메타데이터를 Oracle AI Database 26ai에 저장한 뒤 새로운 답변을 반환합니다.

핵심 포인트는 데이터베이스가 벡터 (vector)를 저장한다는 사실뿐만이 아닙니다(물론 저장하기도 합니다). Oracle AI Database 26ai는 네이티브 VECTOR 데이터 타입, VECTOR_DISTANCE()와 같은 SQL 벡터 거리 함수, 그리고 CREATE VECTOR INDEX를 통한 HNSW 및 IVF와 같은 벡터 인덱스 (vector indexes)를 포함하고 있습니다. 이러한 기능들이 중요한 이유는 재사용의 안전성을 결정하는 것과 동일한 메타데이터를 사용하여 SQL 내에서 캐시 조회를 수행할 수 있게 해주기 때문입니다.

시맨틱 캐시 행 (row)은 문서 청크 (document chunk)보다는 운영 레코드 (operational record)에 더 가깝습니다. 여기에는 테넌트 범위 (tenant scope), 보안 범위 (security scope), 애플리케이션 식별자 (application identity), 모델 식별자 (model identity), 프롬프트 템플릿 버전 (prompt-template version), 데이터 도메인 (data domain), 원본 질문, 질문 임베딩, 생성된 답변, 소스 정책 버전 (source-policy version), 타임스탬프 (timestamps), 무효화 상태 (invalidation state), 출처 (provenance), 히트 메타데이터 (hit metadata), 그리고 피드백 신호 (feedback signals)와 같은 필드들이 포함될 수 있습니다.

첫날부터 모든 필드가 필요하지는 않습니다. 첫 번째 구현은 더 좁은 범위에서 시작할 수 있습니다: 테넌트 (tenant), 도메인 (domain), 모델 식별자 (model identity), 템플릿 버전 (template version), 임베딩 모델 (embedding model), 만료 (expiration), 무효화 상태 (invalidation state), 프롬프트 임베딩 (prompt embedding), 그리고 답변 (answer)입니다. 핵심은 재사용 경계 (reuse boundary)를 명확히 하는 것입니다: 누가 답변을 재사용할 수 있는지, 어떤 모델과 프롬프트 템플릿이 이를 생성했는지, 어떤 도메인에 속하는지, 그리고 언제 답변을 제공하는 것이 안전하지 않게 되는지를 정의하는 것입니다.

벡터 거리(vector distance)로 순위를 매기고 재사용 정책(reuse policy)으로 필터링하기 위해 Oracle SQL 사용하기

시맨틱 캐시 조회 (semantic-cache lookup)는 단순히 다음과 같은 것만이 아닙니다:

ORDER BY VECTOR_DISTANCE(...)

대표적인 조회 쿼리는 다음과 같습니다:

SELECT
    cache_id,
    answer_text,
...