2026.03.24 공식 발표
IT/AI
오라클 Vectors on Ice, 데이터 안 옮기는 이유가 있습니다
AI 에이전트가 벡터 검색을 할 때마다 데이터 레이크에서 데이터를 복사해 온다고 생각하는 경우가 많습니다. Vectors on Ice는 그 가정을 정면으로 깨뜨립니다. 벡터 인덱스만 Oracle 쪽에 두고, 원본 데이터는 Apache Iceberg 레이크에 그대로 놔둡니다. 왜 이게 가능한지, 그리고 어떤 상황에서는 이 방식도 한계가 있는지 — 공식 문서와 실측 데이터를 같이 놓고 확인했습니다.
오라클 DB 사용
쓰기 한계 (Adobe 실측)
파이프라인 코드
Vectors on Ice가 뭔지 한 줄로 정리
결론부터 말씀드리면, 오라클 Vectors on Ice(Oracle Vectors on Ice)는 Apache Iceberg 테이블에 저장된 벡터 데이터를 Oracle AI Database 안으로 복사하지 않고도 벡터 인덱스를 생성하고 유사도 검색을 수행할 수 있는 기능입니다. 오라클이 2026년 3월 24일 런던 AI World Tour에서 공식 발표했습니다. (출처: Oracle 공식 발표, 2026.03.24)
왜 이름이 “Ice”냐면, Apache Iceberg의 약자입니다. 데이터는 Iceberg 테이블에 얼음처럼 그대로 냉동 보존되고, Oracle 쪽에는 그 위치를 가리키는 벡터 인덱스만 생성됩니다. 데이터를 녹여서(=이동해서) 가져오는 방식이 아닙니다.
기존에 Databricks나 Snowflake에 이미 Iceberg 레이크를 운영하는 기업이라면 별도의 데이터 파이프라인을 추가로 구축하지 않아도 Oracle의 AI 벡터 검색을 붙일 수 있다는 뜻입니다. 오라클 공식 기술 블로그는 이를 “추가 로드 없이 Iceberg 거주 벡터에 유사도 검색 적용”이라고 표현합니다. (출처: Oracle Database 공식 블로그, 2026.03.24)
데이터 레이크의 벡터를 어떻게 인덱싱하는가
작동 방식은 생각보다 단순합니다. Oracle AI Database 26ai(버전 23.26.1)에서 Iceberg 테이블을 외부 테이블(External Table)로 정의하고, 그 외부 테이블 위에 벡터 인덱스를 생성합니다. 원본 데이터는 OCI Object Storage나 AWS S3 같은 클라우드 오브젝트 스토리지에 그대로 남아있습니다.
💡 공식 발표문과 실제 사용 흐름을 같이 놓고 보니 이런 차이가 보였습니다 — 오라클은 인덱스를 “데이터베이스 안에 독립적으로” 저장한다고 표현합니다. 즉 오브젝트 스토리지 접근이 일시 끊겨도 인덱스 자체는 살아 있어 검색 서비스가 일정 수준으로 유지됩니다. 다른 방식처럼 레이크 자체를 쿼리하는 구조가 아닙니다.
공식 기술 블로그의 SQL 예시를 직접 보면 흐름이 명확해집니다. 외부 테이블을 만들 때 com.oracle.bigdata.access_protocol=iceberg 파라미터를 지정하면 됩니다. 그 다음 CREATE VECTOR INDEX로 IVF_Flat(Neighbor Partition) 인덱스를 만들면 끝입니다. 데이터를 Oracle 테이블 안으로 INSERT할 필요가 없습니다. (출처: Oracle Database Blog — “How to run similarity search on Apache Iceberg”, 2026.03.24)
인덱스가 생성된 이후에는 Iceberg 원본 데이터가 변경되면 자동으로 업데이트됩니다. 별도의 파이프라인을 짜서 동기화할 필요가 없다는 점이 실무에서 꽤 중요합니다. 데이터가 바뀔 때마다 재적재 작업을 수동으로 돌리던 팀이라면 이 차이를 바로 느낍니다.
“벡터 전용 DB가 낫다”는 말이 흔들리는 지점
Pinecone, Qdrant, Weaviate 같은 전용 벡터 데이터베이스는 벡터 검색 자체에는 최적화되어 있지만, 한 가지 구조적 한계가 있습니다. 오라클의 스티브 지바닉 글로벌 부사장은 VentureBeat 인터뷰에서 이 점을 직접 짚었습니다. “벡터만 쓰고 나면 선택지가 없다. 그래프가 필요하면? 공간 데이터가 필요하면? 시계열이 필요하면? 또 다른 데이터베이스를 붙여야 한다.” (출처: VentureBeat, 2026.03.25)
💡 전용 벡터 DB 도입 당시엔 보이지 않는 비용이 있습니다 — 에이전틱 AI 워크로드는 “벡터 검색 후 관계형 데이터 조인, 그 다음 그래프 탐색”처럼 여러 데이터 타입을 한 쿼리 안에서 섞습니다. 이걸 별도 시스템으로 처리하면 동기화 지연이 쌓이고, 에이전트가 ‘낡은 컨텍스트’로 판단을 내리게 됩니다.
오라클의 Unified Memory Core는 벡터, JSON, 그래프, 관계형, 공간, 컬럼형 데이터를 단일 ACID 트랜잭션 엔진에서 처리합니다. 이 구조에서 에이전트는 동기화 레이어 없이 모든 데이터 타입에 실시간으로 접근합니다. 전용 벡터 DB + 관계형 DB + 그래프 DB를 각각 운영하는 조직이라면 그 통합 비용이 이미 상당합니다.
단, Dickens HyperFRAME Research CEO의 평가도 균형 있게 볼 필요가 있습니다. “벡터 검색, RAG 통합, Iceberg 지원은 이제 Postgres, Snowflake, Databricks도 모두 제공하는 표준 기능이다. 오라클의 차별화는 기능 수준이 아니라 아키텍처 수준에 있고, Unified Memory Core가 그 주장이 맞는지 틀린지를 가릅니다.” (출처: VentureBeat, 2026.03.25) — 실제 생산 환경에서 검증되기 전까지는 마케팅 주장과 성능 수치가 다를 수 있습니다.
Iceberg가 항상 정답은 아닌 현실적 이유
Vectors on Ice를 쓴다는 건 전제 조건으로 Apache Iceberg를 쓴다는 뜻입니다. 그런데 Iceberg 자체가 모든 상황에 최적인 건 아닙니다. 이 부분을 짚지 않으면 나중에 곤란해집니다.
| 상황 | Iceberg 적합도 | 이유 |
|---|---|---|
| 대용량 배치 분석 (수 TB~PB) | ✅ 최적 | Netflix 스케일에서 설계된 포맷 |
| 소규모 데이터 (수 GB 이하) | ❌ 과도 | 메타데이터 오버헤드가 데이터보다 큼 |
| 실시간 스트리밍 (초 단위) | ❌ 부적합 | Parquet 업로드 완료 전까지 새 행 미노출 |
| OLTP 트랜잭션 (초당 수백 건) | ❌ 한계 | Adobe 엔지니어 실측 최대 약 15 TPS |
| 멀티 클라우드 데이터 공유 | ✅ 강점 | Databricks·Snowflake·BigQuery 동시 쿼리 가능 |
핵심 수치 하나 — Adobe 엔지니어 팀이 실측한 Iceberg의 최대 쓰기 처리량은 분당 약 15건입니다. 반면 일반적인 OLTP 데이터베이스는 초당 수천 건을 가볍게 처리합니다. (출처: Adobe Tech Blog, “High-throughput ingestion with Iceberg”) 즉, 쓰기가 잦은 운영 데이터를 Iceberg에 저장하고 Vectors on Ice를 붙이는 구조는 실시간성이 중요한 서비스엔 처음부터 맞지 않습니다. 인덱스는 자동 갱신되지만 Iceberg 자체가 반영을 늦게 하면 의미가 없습니다.
MCP 서버 연동: 코드 없이 에이전트 접근
같은 날 발표된 오라클 자율운영 AI 데이터베이스 MCP 서버(Autonomous AI Database MCP Server)는 Vectors on Ice와 함께 볼 때 훨씬 실용적 그림이 나옵니다. MCP(Model Context Protocol)는 AI 에이전트가 데이터 소스에 접근하는 표준 프로토콜인데, Oracle이 이 MCP 서버를 Autonomous AI Database에 직접 내장했습니다.
💡 MCP 연동 구조를 Oracle DB와 같이 보면 이런 그림이 됩니다 — 외부 에이전트(Claude, Cursor, Copilot 등)가 MCP 표준 API 호출을 하면 Oracle의 행 수준·열 수준 접근 제어가 자동 적용됩니다. 별도 보안 코드를 추가로 짜지 않아도 됩니다.
오라클 마리아 콜건 부사장은 VentureBeat 인터뷰에서 이 점을 이렇게 표현했습니다. “다른 플랫폼과 동일한 표준 API 호출을 하더라도, 해당 사용자가 가진 권한이 LLM이 질문을 던지는 순간에도 그대로 적용된다.” (출처: VentureBeat, 2026.03.25) 에이전트가 프롬프트 인젝션 공격으로 다른 사용자 데이터를 꺼내려 해도 데이터베이스 레이어에서 막힌다는 뜻입니다.
현재 MCP 서버는 Oracle SQL Developer VS Code 확장 프로그램을 통해 Oracle Database 19c 이상에서 이용 가능합니다. Autonomous AI Database MCP Server는 완전 관리형(fully managed)으로 별도 통합 코드나 수동 보안 설정이 필요 없습니다. (출처: Oracle 공식 발표문, 2026.03.24)
누가 쓰면 좋고, 누가 쓰면 곤란한가
Vectors on Ice가 실질적으로 강점을 가지는 구간을 솔직하게 짚겠습니다.
✅ 이런 환경에서 효과 큽니다
- 이미 Databricks나 Snowflake에 Iceberg 레이크를 운영 중인데 AI 벡터 검색을 붙이고 싶은 경우
- 데이터 이동 파이프라인 구축에 드는 DevOps 인력 비용이 아까운 중견 기업
- Oracle DB를 핵심 트랜잭션 DB로 쓰는 조직에서 기존 보안·규정 준수 정책을 AI 에이전트에도 그대로 적용하고 싶을 때
- 에어갭(인터넷 차단) 환경에서 임베딩 모델을 로컬로 실행해야 하는 금융·공공 영역
❌ 이 경우엔 다른 방법을 먼저 검토하세요
- 초당 수백 건 이상 쓰기가 발생하는 운영 데이터에 Iceberg를 쓰고 있다면 — 분당 15건 한계를 먼저 확인해야 합니다
- 데이터 규모가 수 GB 이하인 소규모 팀 — Iceberg 메타데이터 오버헤드가 오히려 느려집니다
- Oracle DB를 전혀 쓰지 않고 Postgres + pgvector 스택만 운영 중인 경우 — 전환 비용 대비 효용을 면밀히 따져야 합니다
오라클이 Fortune Global 100의 97%가 자사 DB를 쓴다고 강조하는 이유가 있습니다. 이미 오라클 생태계 안에 있는 기업일수록 Vectors on Ice의 도입 장벽은 낮고, 그 반대 상황에선 기대보다 추가 작업이 많습니다.
Q&A 5가지
Q1. Vectors on Ice를 쓰면 Iceberg 원본 데이터를 Oracle 안으로 복사해야 하나요?
＋
Q2. Databricks나 Snowflake의 Iceberg 테이블에도 바로 연결됩니까?
＋
Q3. Autonomous AI Vector Database는 무료로 쓸 수 있나요?
＋
Q4. Iceberg 데이터가 바뀌면 벡터 인덱스도 자동으로 갱신되나요?
＋
Q5. Oracle DB를 안 쓰는 조직도 Vectors on Ice를 도입할 수 있나요?
＋
마치며
오라클 Vectors on Ice의 핵심은 “데이터를 이동시키지 않는다”는 역발상입니다. 벡터 인덱스만 Oracle 쪽에 두고 원본은 Iceberg 레이크에 그대로 — 이 구조가 통하는 이유는 에이전틱 AI 환경에서 데이터 이동 파이프라인 자체가 병목이 됐기 때문입니다. 콘스텔레이션 리서치의 홀거 뮬러 애널리스트가 VentureBeat에서 지적했듯, 다른 벤더들은 이 통합 구조를 바닥부터 다시 짜지 않으면 복제하기 어렵습니다.
동시에 Iceberg 자체의 한계도 명확합니다. 실시간 쓰기가 많은 워크로드, 소규모 데이터, OLTP 구조에서는 Iceberg가 오히려 발목을 잡습니다. Adobe 엔지니어 팀이 실측한 분당 15건 쓰기 한계는 화려한 공식 발표문 어디에도 나오지 않는 수치입니다. 도입 전에 자신의 데이터 구조가 Iceberg에 맞는지 먼저 확인하는 게 순서입니다.
솔직히 말하면, Vectors on Ice는 이미 Oracle 생태계 안에 있는 조직에게 가장 즉각적인 가치를 줍니다. 그 밖의 상황에선 진입 방법은 있지만 “공짜로 얻는 건 없다”는 점은 변하지 않습니다.
본 포스팅 참고 자료
- Oracle 공식 발표문 — “Oracle Unveils AI Database Agentic Innovations for Business Data” (oracle.com/kr/news, 2026.03.24)
- Oracle Database 기술 블로그 — “Oracle AI Database Delivers Mission-Critical Agentic AI Built for Business Data” (blogs.oracle.com, 2026.03.24)
- Oracle Database 기술 블로그 — “How to run similarity search on Apache Iceberg” (blogs.oracle.com, 2026.03.24)
- VentureBeat — “Oracle converges the AI data stack to give enterprise agents a single source of truth” (venturebeat.com, 2026.03.25)
- Forbes — “How Oracle AI Database 26ai Addresses The Enterprise AI Data Paradox” (forbes.com, 2026.01.27)
- Quesma Blog — “Don’t Let Apache Iceberg Sink Your Analytics: Practical Limitations” (quesma.com, 2025.05)
본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. Oracle AI Database 26ai (2026.03.24 기준) 공식 발표 및 기술 문서를 바탕으로 작성되었으며, 이후 업데이트로 내용이 달라질 수 있습니다. 투자·도입 결정 전 공식 문서를 반드시 재확인하시기 바랍니다.
댓글 남기기