데이터 활용의 세계에서는 오랫동안 Data Warehouse와 Big Data가 서로 다른 맥락에서 발전해 왔습니다.

Data Warehouse는 구조화된 업무 데이터를 고품질로 관리하여 BI나 리포팅에 사용하기 위한 기반입니다.

반면 Big Data는 로그, 센서 데이터, Web 액세스, JSON, 이미지, 문서 등 대량·다양·고속으로 발생하는 데이터를 다루는 맥락에서 확산되었습니다.

그 Big Data의 수용처로서, 데이터를 우선 가공되지 않은 형태로 축적하는 Data Lake가 등장했습니다.

그리고 현재는 Data Lake의 유연성과 Data Warehouse의 관리성·성능을 결합한 Lakehouse가 주목받고 있습니다.

Lakehouse는 Data Lake의 유연성과 Data Warehouse의 관리성·성능을 결합한 아키텍처입니다. 특히 Oracle Autonomous AI Lakehouse의 맥락에서는 단순히 "Object Storage에 데이터를 두는" 것뿐만 아니라, Oracle AI Database를 중심으로 Iceberg, Object Storage, 외부 표(External Table), Database Link, SharePoint, SaaS, Vector Search, BI, AI를 연결하여 사용하는 것에 큰 의미가 있습니다.

따라서 본고에서는 Oracle Autonomous AI Lakehouse를 축으로, Lakehouse에서 다루는 데이터, Oracle AI Database 관점에서의 Lakehouse, 그리고 실제로 "어디에 무엇을 두어야 하는가"를 정리합니다.

Lakehouse에서 다루는 데이터는 한마디로 말해 매우 폭넓습니다.

기존의 Data Warehouse에서는 매출, 고객, 주문, 재고, 회계 등의 구조화된 데이터가 중심이었습니다. 반면 Lakehouse에서는 구조화된 데이터에 더해 JSON, 로그, PDF, 이미지, 음성, 영상, IoT, 이벤트, Embedding 등도 다룹니다.

Oracle의 문서에서도 Lakehouse는 CSV나 Parquet, Iceberg 등의 오픈 파일·테이블 형식을 이용하며, 구조화, 반구조화, 비구조화 데이터를 저장·처리하는 것으로 설명되어 있습니다. 또한 PDF, Word, 이미지 등의 비구조화 데이터도 Lakehouse의 대상으로 언급되어 있습니다.

참고: Autonomous AI Lakehouse - Oracle Documentation

여기서는 우선 "데이터의 형태"로서 구조화, 반구조화, 비구조화의 세 가지로 나눕니다.

그 바탕 위에서 실무에서 자주 등장하는 데이터를 용도별로 정리하면 다음과 같습니다.

데이터의 형태 → 구조화 / 반구조화 / 비구조화
실무상의 분류 → 업무 데이터 / 로그 / IoT / 외부 데이터 / 문서 / AI 데이터
데이터의 성숙도 → Bronze / Silver / Gold / AI-ready

데이터 종별

데이터 종별	구체적인 예	주요 용도
구조화 데이터 (표 형식으로 관리하기 쉬운 데이터)	매출, 고객, 주문, 재고, 회계, 인사	BI, KPI, 리포트, 업무 분석
반구조화 데이터 (어느 정도 구조는 있지만 표로 고정되지 않는 데이터)	JSON, XML, API 응답, 앱 로그	이벤트 분석, 앱 분석, 데이터 통합
비구조화 데이터 (표 형식으로 만들기 어려운 데이터)	PDF, Word, 이미지, 음성, 영상, 메일	검색, 요약, RAG, AI 분석

Lakehouse의 특징은 이 세 가지 종류를 통합하여 다룰 수 있다는 점입니다. 기존의 DWH는 구조화 데이터가 중심이었지만, Lakehouse에서는 로그, 파일, 이미지, AI용 데이터 등도 대상이 됩니다.

실무에서 자주 사용되는 데이터의 종류

종류	구체적인 예	주요 용도
업무 데이터	수주, 매출, 청구, 고객, 계약, 재고	BI, 리포트, 경영 분석
마스터 데이터	상품 마스터, 고객 마스터, 조직 마스터, 거점 마스터	데이터 통합, 데이터 정제 (Data Cleansing), 분석 기준
트랜잭션 데이터	주문 이력, 결제 이력, 출하 이력, 예약 이력	수요 분석, 부정 탐지, 고객 분석
로그 데이터	앱 로그, Web 액세스 로그, 감사 로그, 시스템 로그	장애 분석, 보안 분석, 이용 상황 분석
이벤트 데이터	클릭, 열람, 검색, 장바구니 담기, 앱 조작	행동 분석, 추천 (Recommendation), 마케팅
IoT · 센서 데이터	온도, 압력, 진동, 위치 정보, 가동 상황	예지 보전, 설비 모니터링, 실시간 분석
스트리밍 데이터	Kafka 이벤트, CDC, 실시간 거래	실시간 대시보드, 즉시 탐지
외부 데이터	날씨, 시장 데이터, 인구 통계, SNS, 파트너 데이터	수요 예측, 리스크 분석, 보조 데이터
문서 데이터	PDF, 계약서, 사양서, 문의 내용	검색, 요약, 생성 AI, 지식 활용
이미지 · 음성 · 영상	제품 이미지, 감시 카메라, 통화 녹음, 검사 이미지	AI 분석, 품질 검사, 음성 인식
지리 공간 데이터	GPS, 주소, 배송 경로, 매장 위치	상권 분석, 물류 최적화, 이동 분석
AI · 머신러닝용 데이터	특성량 (Feature), 라벨 (Label), 학습 데이터, 추론 결과, 임베딩 벡터 (Embedding Vector)	모델 학습, MLOps, 생성 AI/RAG

여기서 중요한 것은 데이터의 종류뿐만 아니라, 데이터의 성숙도 (Data Maturity) 또한 나누어 생각하는 것입니다.

Lakehouse의 세계에서는 Bronze / Silver / Gold라는 레이어로 데이터를 정리하는 개념이 자주 사용됩니다. Databricks의 메달리온 아키텍처 (Medallion Architecture)에서는 Bronze는 Raw, Silver는 Validated, Gold는 Enriched와 같이 데이터 품질의 단계로 설명됩니다.

참고: Databricks Medallion Architecture

Oracle Autonomous AI Lakehouse를 고려할 때도 이 정리는 매우 유용합니다.

Bronze / Silver / Gold + AI-ready 레이어

「Bronze / Silver / Gold라는 3개 층에, AI 활용을 위한 Feature / AI-ready를 더하여 생각합니다.

레이어	내용	Oracle에서의 이미지
Raw / Bronze	가져온 그대로의 원천 데이터	Object Storage, Iceberg, Parquet, CSV, JSON, PDF, 로그
...

즉, Lakehouse에서는 단순히 "다양한 데이터를 둘 수 있다"는 것만으로는 불충분합니다.

원천 데이터 (Raw Data) → 정형화된 데이터 (Structured Data) → 분석용 데이터 (Analytical Data) → AI 활용 데이터 (AI-ready Data)

와 같이 단계적으로 관리하는 경우가 많습니다.

중요한 것은,

원천 데이터를 유지하는 것,

분석하기 쉬운 형태로 정돈하는 것,

업무에 사용할 수 있는 의미 있는 데이터로 만드는 것,

그리고 AI가 사용할 수 있는 형태로 변환하는 것입니다.

요약하자면, 다음과 같이 생각하면 정리하기 쉽습니다.

Lakehouse에서 이용되는 데이터는 세부적으로 보면 무수히 많습니다.

다만, 실무상으로는 다음과 같이 정리하면 충분합니다.

Lakehouse에서는 업무 시스템의 구조화 데이터 (Structured Data), 로그나 JSON 등의
반구조화 데이터 (Semi-structured Data), 문서 · 이미지 · 음성 등의 비구조화 데이터 (Unstructured Data)를 일원적으로 축적하여,
BI · 분석 · 머신러닝 · 생성 AI에 활용한다.

더 짧게 말하면,

Lakehouse는 DWH적인 업무 데이터와 Data Lake적인 다양한 원천 데이터를 통합하여 다루는 기반입니다.

Oracle AI Database의 관점에서 Lakehouse를 바라보면 조금 흥미로운 시각을 가질 수 있습니다.

일반적인 설명에서는 Lakehouse를 Object Storage나 Iceberg와 같은 스토리지 계층을 중심으로 이야기하는 경우가 많습니다. 하지만 Oracle의 경우, Database 측이 매우 강력합니다. Oracle Autonomous AI Database는 JSON, Graph, Vector, Oracle Machine Learning, Spatial 등을 다룰 수 있는 통합적인 데이터 기반으로 자리 잡고 있습니다.

참고: Autonomous AI Lakehouse - Oracle Documentation

즉, Oracle AI Database는 단순한 "구조화된 데이터를 넣는 상자"가 아닙니다.

Oracle AI Database에서는 관계형 데이터(Relational Data)뿐만 아니라 JSON, Text, Vector, Spatial, Graph 등을 동일한 Database 내에서 다룰 수 있습니다. 특히 JSON에 대해서는 트랜잭션(Transaction), 인덱스(Index), 선언적 SQL 쿼리(Declarative SQL Query), 뷰(View) 등의 관계형 데이터베이스 기능과 결합하여 네이티브하게 다룰 수 있습니다. 나아가 JSON 데이터를 관계형 데이터와 조인(JOIN)하거나, 외부 테이블(External Table) 상의 JSON을 Database 내부에서 질의할 수 있습니다.

참고: JSON in Oracle AI Database

AI 관점에서는 Oracle AI Vector Search가 중요합니다. Oracle AI Database 26ai에서는 VECTOR 데이터 타입을 통해 임베딩(Embedding)을 업무 데이터와 동일한 Database 내에 저장할 수 있습니다. 비구조화 데이터를 임베딩(Embedding)으로 변환하여 시맨틱 검색(Semantic Search)이나 RAG(Retrieval-Augmented Generation)에 활용할 수 있습니다.

참고: Oracle AI Vector Search Overview

이 점이 Oracle다운 Lakehouse의 특징입니다.

일반적인 Lakehouse에서는 다음과 같이 여러 컴포넌트를 조합하는 경우가 많습니다.

• Lake에 데이터를 배치
• 별도의 엔진으로 분석
• 별도의 Vector DB에 임베딩(Embedding)을 배치

반면, Oracle AI Database를 사용하는 경우에는 다음과 같이 생각할 수 있습니다.

Object Storage / Iceberg / 외부 데이터
↓
External Table / DBMS_CLOUD / Catalog / Database Link
...

물론 모든 데이터를 Database 내로 복사할 필요는 없습니다. Object Storage 상의 파일은 외부 테이블(External Table)로서 질의할 수 있습니다. Autonomous AI Database에서는 DBMS_CLOUD.CREATE_EXTERNAL_TABLE을 사용하여 클라우드 상의 파일에 대한 외부 테이블을 생성할 수 있으며, 대상에는 OCI Object Storage, Azure Blob / ADLS, Amazon S3, Google Cloud Storage 호환 스토리지 등이 포함됩니다.

참고: Query External Data with Autonomous Database

따라서 Oracle AI Database의 관점에서 보는 Lakehouse는 다음과 같이 파악하면 이해하기 쉽습니다.

Lakehouse 스토리지 상의 데이터를 Oracle AI Database의 SQL, 거버넌스(Governance), 뷰(View), 구체화된 뷰(Materialized View), JSON, Vector, Text, Graph, Spatial, AI 기능으로 활용하는 아키텍처

성능 측면에서는 인메모리(In-Memory)도 중요합니다. Oracle AI Database의 Database In-Memory는 실시간 분석이나 혼합 워크로드(Mixed Workload)의 성능 개선을 목적으로 하는 기능으로, 테이블(Table), 파티션(Partition), 서브 파티션(Sub-partition), 구체화된 뷰(Materialized View), 나아가 외부 테이블(External Table)도 인메모리(In-Memory)화 대상으로 설명되어 있습니다.

참고: Use Database In-Memory with Autonomous Database

따라서 인메모리(In-Memory)는 "저장소"가 아니라, **가속 레이어(Acceleration Layer)**로 생각할 수 있습니다.

또한, Oracle Autonomous AI Database에는 Lakehouse를 가속화하는 기능인 Lake Cache / Data Lake Accelerator (DLA)가 있습니다.

Lake Cache와 Data Lake Accelerator는 오브젝트 스토리지 (OCI Object Storage, AWS S3, Azure Blob, GCP 등) 상의 외부 데이터를 고속으로 스캔 및 쿼리하기 위한 핵심 기능입니다. 두 기능은 "데이터 레이크하우스 (Data Lakehouse) 환경의 쿼리 가속화"라는 목적은 동일하지만, 접근 방식이 다릅니다.

・가속화 레이어

기능	주요 역할	메커니즘	적합한 유스케이스
In-Memory	Database 내 데이터 분석 가속화	Table, Partition, Materialized View, 외부 표 등을 In-Memory Column Store에 열 형식으로 유지	Database 내의 핫 데이터 (Hot Data), 반복 실행되는 분석 쿼리, 집계, JOIN
...

Oracle Autonomous AI Lakehouse는 Oracle Autonomous AI Database와 Apache Iceberg를 결합한, 오픈형 멀티 클라우드 대응 Lakehouse 플랫폼으로 자리매김하고 있습니다. Oracle의 제품 페이지에서는 Autonomous AI Database와 벤더 종속성이 없는 Apache Iceberg를 결합하여, OCI, AWS, Azure, Google Cloud, Exadata Cloud@Customer 상의 데이터에 대해 AI 및 분석을 실행할 수 있다고 설명합니다.

참고: Oracle Autonomous AI Lakehouse

이 설명에서 중요한 것은 Iceberg입니다.

Apache Iceberg는 오픈 테이블 포맷 (Open Table Format)입니다. 데이터를 특정 벤더의 폐쇄적인 형식에 가두는 것이 아니라, 여러 엔진에서 읽고 쓰기 쉬운 형태로 관리하기 위한 중요한 기술입니다.

Oracle Autonomous AI Lakehouse에서는 Iceberg 테이블을 즉시 쿼리할 수 있습니다. Oracle의 문서에 따르면, Autonomous AI Database는 Apache Iceberg 테이블 쿼리를 지원하며, AWS Glue, Snowflake Polaris, Databricks Unity Catalog, JSON metadata 등의 구성에 대해서도 언급하고 있습니다.

참고: Query External Data in Apache Iceberg Format

Oracle의 제품 페이지에서는 Autonomous AI Lakehouse가 Iceberg를 통해 각 클라우드 상의 오픈 데이터 플랫폼과 통합되며, Oracle AI Database 26ai의 AI, 머신러닝 (Machine Learning), Graph, Spatial 등을 데이터 이동 없이 이용할 수 있다고 설명합니다. 또한, Data Lake Accelerator 및 테이블 캐싱 (Table Caching)을 통해 외부 데이터 액세스 성능 향상도 도모할 수 있다고 명시되어 있습니다.

참고: Oracle Autonomous AI Lakehouse

여기서 알 수 있는 점은 Autonomous AI Lakehouse가 단순한 "데이터 저장소"가 아니라는 것입니다.

오히려 다음과 같은 역할을 수행합니다.

오픈 Lakehouse 스토리지
- Object Storage
- Apache Iceberg
...

즉, Oracle Autonomous AI Lakehouse는 다음과 같이 생각하면 좋습니다.

Open Lakehouse Storage와 Oracle AI Database의 통합을 통해, 분산된 데이터를 SQL, BI, AI, RAG에서 활용하기 위한 기반

Oracle Autonomous AI Lakehouse의 흥미로운 점은 Object Storage나 Iceberg에만 국한되지 않습니다.

Autonomous AI Database를 중심으로 보면, 연결할 수 있는 데이터의 범위가 상당히 넓어집니다.

대상은 클라우드 스토리지, SharePoint, SaaS, 업무 애플리케이션, 타사 클라우드 데이터베이스, Oracle Database, 외부 데이터 카탈로그 등 매우 다양합니다.

나아가, Autonomous AI Database에서는 Oracle-managed heterogeneous connectivity를 통해,

비 Oracle 데이터베이스나 일부 외부 서비스에 대해 Database Link를 통해 질의하는 구성을 취할 수 있습니다.

Oracle의 제품 페이지에서도, Autonomous AI Lakehouse는 오픈 테이블 형식(Open Table Format)이나 다수의 데이터베이스·애플리케이션 소스에 연결하여, 구조화(Structured), 반구조화(Semi-structured), 비구조화(Unstructured) 데이터를 네이티브하게 지원하는 통합 분석 플랫폼으로 설명되어 있습니다.

참고: Oracle Autonomous AI Lakehouse

먼저 기본이 되는 것은 Object Storage입니다.

Raw / Bronze 데이터, 즉 생로그(Raw Log), CSV, JSON, Parquet, ORC, Avro, PDF, 이미지 등은 Object Storage에 두는 것이 자연스럽습니다. Autonomous AI Database에서는 외부 표(External Table)나 DBMS_CLOUD를 통해 이러한 데이터들을 참조할 수 있습니다.

모든 데이터를 처음부터 Database에 로드할 필요는 없습니다.

필요에 따라 외부 표로서 질의하거나, 로드하여 Database Table로 만들거나, Materialized View로 집계하는 등의 선택을 할 수 있습니다.

업무 데이터 활용 측면에서 매우 흥미로운 점은 SharePoint 연동입니다.

많은 기업에서 중요한 정보는 데이터베이스가 아니라 SharePoint 상의 Word, Excel, PDF, PowerPoint에 존재합니다. 기존에는 이러한 데이터들이 분석 기반 관점에서는 다루기 까다로운 데이터였습니다.

Autonomous AI Database에서는 DBMS_CLOUD와 DBMS_CLOUD_PIPELINE을 사용하여 Microsoft SharePoint 상의 파일에 접근할 수 있습니다. Oracle의 문서에서는 SharePoint 상의 파일을 list / retrieve 하고, 외부 콘텐츠를 다운로드하여 후속 분석이나 인덱스 생성에 활용할 수 있다고 설명합니다. 나아가, DBMS_CLOUD_AI.CREATE_VECTOR_INDEX를 사용하여 SharePoint 파일로부터 직접 Vector Index를 생성하는 예시도 제시되어 있습니다.

참고: Use DBMS_CLOUD with Microsoft SharePoint

이는 Lakehouse 문맥에서 상당히 중요합니다.

왜냐하면 SharePoint 상의 문서를 단순한 파일로 방치하는 것이 아니라, 추출된 텍스트(Extracted Text), 청크(Chunk), 임베딩(Embedding), 메타데이터(Metadata)로서 Oracle AI Database 측으로 가져와 RAG(Retrieval-Augmented Generation)나 시맨틱 검색(Semantic Search)으로 연결할 수 있기 때문입니다.

SaaS나 업무 애플리케이션과의 연결도 중요합니다.

Oracle Autonomous AI Lakehouse의 Data Studio는 데이터 로드, 변환, 분석, 공유를 지원하는 셀프 서비스 데이터 엔지니어링 기능으로 자리 잡고 있습니다. Oracle의 제품 페이지에서는 Data Studio를 통해 100개 이상의 애플리케이션, 클라우드 서비스, 데이터베이스 소스와 통합할 수 있다고 설명합니다.

참고: Oracle Autonomous AI Lakehouse

또한 Data Transforms는 Autonomous AI Database를 위해 데이터 로드, 데이터 흐름(Data Flow), 워크플로우(Workflow)를 로우코드(Low-code)로 설계하기 위한 기능입니다. 데이터 로드, 결합(Join), 필터(Filter), 집계(Aggregation), 매핑(Mapping), 스케줄링(Scheduling), 모니터링(Monitoring) 등을 GUI 기반으로 다룰 수 있기 때문에, SaaS 데이터나 업무 애플리케이션 데이터를 Lakehouse로 가져올 때의 구현 수단이 됩니다.

참고: About Data Transforms

나아가, Autonomous AI Database에서는 Oracle-managed heterogeneous connectivity를 통해, 비 Oracle Database에 대한 Database Link를 생성할 수 있습니다.

Oracle의 문서에서는 Amazon Redshift, Microsoft SQL Server, Azure SQL, Azure Synapse Analytics, Databricks, Google BigQuery, MongoDB, MySQL, PostgreSQL, Salesforce, ServiceNow, Snowflake, SharePoint 등이 db_type

의 예로 들어져 있습니다. 다만, 이 Oracle-managed heterogeneous connectivity는 remote database에 대해 query-only이며, 업데이트(update)는 지원되지 않는다는 점에 주의가 필요합니다.

참고: Create Database Links to Non-Oracle Databases with Oracle-Managed Heterogeneous Connectivity

이 기능을 통해 모든 데이터를 물리적으로 이동시키지 않고도, Oracle AI Database에서 타사 데이터베이스 상의 데이터를 참조하고 Oracle 측의 데이터와 조합하여 분석할 수 있습니다.

이는 Lakehouse의 개념을 확장합니다.

기존에는,

데이터를 모은 다음에 분석한다

라는 생각이 중심이었습니다.

하지만 Autonomous AI Lakehouse에서는,

필요한 데이터를, 필요한 형태로, Oracle AI Database에서 연결하여 사용한다

라는 발상이 가능합니다.

여기까지 살펴보면, 다룰 수 있는 데이터와 접속 대상이 상당히 넓다는 것을 알 수 있습니다.

그렇다면 실제로 어디에 무엇을 두어야 할까요?

제가 정리한 바로는, Oracle Autonomous AI Lakehouse에서의 데이터 배치(data placement)는 다음과 같은 관점으로 이해하는 것이 쉽습니다.

데이터 / 레이어	권장 배치	이유
Raw / Bronze	Object Storage, Iceberg, Parquet, CSV, JSON, PDF	원본성, 저비용, 대량 저장, 재처리(reprocessing)에 적합
...

이 표를 더욱 심플하게 요약하면 다음과 같습니다.

Raw / Bronze
→ Object Storage / Iceberg / SharePoint / 외부 스토리지
Cleaned / Silver
...

여기서의 포인트는, 구조화 데이터(structured data)니까 반드시 Database, 비구조화 데이터(unstructured data)니까 반드시 Object Storage라고 고정하지 않는 것입니다.

보다 실천적으로는 다음 기준에 따라 생각하면 좋습니다.

로그, 이력 파일, PDF 원본, 이미지, JSON 원본, Parquet 파일 등은 Object Storage나 Iceberg에 두는 것이 자연스럽습니다.

이것들은 나중에 재처리하거나, 감사(audit)용으로 남겨두거나, 다른 엔진에서도 사용할 가능성이 있기 때문에 오픈 형식(open format)으로 유지해 둘 가치가 있습니다.

클렌징(cleansing) 완료, 타입 변환(type conversion) 완료, 중복 제거(deduplication) 완료, 비즈니스 키(business key)로 결합 완료된 데이터는 Silver 레이어로 취급합니다.

Oracle AI Database에서 고속으로 JOIN, 검색, AI 처리를 하고 싶다면 Database Table로 만드는 것이 자연스럽습니다. 반면, 여러 엔진에서 공유하고자 하는 대규모 분석 데이터라면 Iceberg Table로 관리하는 선택지도 있습니다.

경영 지표, 부문별 매출, 고객 세그먼트(segment), 재고 회전율, SLA, 이용 현황 등 비즈니스에 활용되는 데이터는 Gold 레이어로 정리합니다.

여기서는 Table, View, Materialized View, Analytic View가 후보가 됩니다. 빈번하게 사용되는 집계는 Materialized View, 빈도는 낮지만 정의를 공통화하고 싶은 것은 View, 성능 요구사항이 높은 것은 In-Memory 등을 검토합니다.

생성형 AI (Generative AI) / RAG에서 사용하는 경우, 원본 파일 그 자체보다 다음과 같은 파생 데이터가 중요해집니다.

AI-ready 데이터	내용
Extracted Text	PDF나 Word에서 추출한 텍스트
...

Oracle AI Database에서는 Embedding을 VECTOR 데이터 타입으로서 비즈니스 데이터와 동일한 Database에 저장할 수 있습니다. 이를 통해 시맨틱 검색(semantic search)뿐만 아니라 고객, 계약, 제품, 문의, 권한 정보 등의 구조화 데이터와 조합한 RAG를 설계하기 쉬워집니다.

참고: Oracle AI Vector Search Overview

예를 들어, SharePoint 상의 기술 문서를 RAG화하는 경우에는 다음과 같은 배치를 생각할 수 있습니다.

SharePoint
- Word
- PDF
...

이 구성에서 SharePoint는 문서 원본의 보관 장소이며, Oracle AI Database는 검색·분석·AI 활용을 위한 실행 기반(execution platform)이 됩니다.

Lakehouse라고 하면, 처음에는 "Data Lake와 Data Warehouse를 결합한 것"이라고 설명되는 경우가 많습니다.

하지만 Oracle Autonomous AI Lakehouse의 맥락에서 보면, 그것만으로는 조금 부족합니다.

Oracle Autonomous AI Lakehouse의 흥미로운 점은 Object Storage나 Iceberg에 데이터를 둘 수 있다는 점만이 아닙니다. Oracle AI Database를 중심으로 구조화 데이터 (structured data), 반구조화 데이터 (semi-structured data), 비구조화 데이터 (unstructured data), SharePoint, SaaS, 타사 클라우드 데이터베이스, 외부 테이블 (External Table), Database Link, Vector Search, BI, AI, RAG를 연결하여 사용할 수 있다는 점에 있습니다.

기존의 발상으로는 분석을 하기 위해 먼저 데이터를 한 곳으로 모아야 했습니다.

물론 지금도 데이터를 모으고 정제하는 것은 중요합니다. 특히 Curated / Gold나 AI-ready와 같이 품질과 재사용성이 요구되는 데이터는 Oracle AI Database 측에 정리해 둘 가치가 있습니다.

하지만 모든 데이터를 억지로 이동할 필요는 없습니다.

원본은 Object Storage나 SharePoint에 둔다.

대규모 오픈 분석 데이터는 Iceberg에 둔다.

업무에서 빈번하게 사용하는 데이터는 Database Table에 둔다.

BI용 데이터는 View나 Materialized View로 만든다.

가속화하고 싶은 데이터는 In-Memory나 Cache를 사용한다.

생성형 AI (Generative AI)에서 사용할 데이터는 Chunk, Embedding, Metadata로서 AI-ready 상태로 만든다.

이렇게 생각하면 Lakehouse는 단순한 "데이터를 모으는 기반"이 아니게 됩니다.

Lakehouse는 분산된 데이터를 필요한 형태로 연결하여 SQL, BI, 분석, AI, 생성형 AI / RAG에서 사용할 수 있도록 하는 기반입니다.

Oracle Autonomous AI Lakehouse는 그러한 사고방식을 Oracle AI Database의 강점과 결합하여 실현하고자 하는 아키텍처입니다.