**Oracle AI Data Platform (AIDP)**에서는 Knowledge Base나 Agent와 같은 AI 기능을 이용하기 위해 Oracle Autonomous AI Lakehouse(이하, AI Lakehouse)를 연결합니다. 이 AI Lakehouse는 Knowledge Base의 벡터 저장 및 검색을 담당합니다.
이 AI Lakehouse를 Private Endpoint만으로 구성했을 경우, 어느 Workspace에서 Compute를 생성해야 하는지 궁금했습니다. 공개된 문서를 확인했음에도 불구하고, 이 구성에서의 AI Compute 생성 조건을 파악할 수 없었기 때문에, 실제로 AIDP 생성부터 문서 가져오기, RAG 검색까지 시도해 보기로 했습니다.
이번에는 이 AI Lakehouse를 'Private Endpoint 접근만'으로 설정했습니다. Public Access를 비활성화한 상태에서, AIDP 생성부터 문서 가져오기, RAG 툴을 이용한 검색 및 답변 생성까지 확인합니다.
따라서 Private Endpoint만 있는 AI Lakehouse를 AIDP에 연결하고, RAG 검색까지 시도해 보겠습니다.
이번 환경에서는 다음 사항들을 확인할 수 있었습니다.
| 확인 항목 | 결과 |
|---|
| 기존의 Private Endpoint만 있는 Lakehouse를 지정하여 AIDP 생성 | 성공 |
| ... | |
| 핵심 포인트는 AI Compute를 생성하는 Workspace의 네트워크 설정입니다. Private Endpoint만 있는 AI Lakehouse를 연결했을 경우, AI Compute의 생성 위치에는 AI Lakehouse와 동일한 Subnet을 설정한 Private Workspace를 사용합니다. | |
이후 내용은 2026년 10월 검증 환경에서의 화면 및 조작을 소개합니다.
| 항목 | 검증 시 값 |
|---|
| AIDP 이름 | Private-AIDP |
| ... | Workspace : Private Network 비활성화 |
| 자동 생성된 Private Workspace | Pvt_vector_db_CDB : 상기 VCN・Subnet 설정 |
| 표준 카탈로그/스키마 | default /default |
| Volume | vol_aal_test |
| Knowledge Base | kb_aal_connection_test2 |
| Private Workspace 내 Spark Cluster | Cluster1 |
| Spark 버전 | 3.5.0 (검증 시 선택지는 이 1종류) |
| AI Compute | ai_compute_aal_test |
| Agent project | agent_aal_connection_test |
리소스명 및 IP 주소는 검증 시의 값입니다. 재현할 때는 이용 환경의 값으로 대체합니다. Subnet 이름뿐만 아니라, Lakehouse와 Workspace가 참조하는 Subnet OCID의 일치도 확인합니다.
| 구성 요소 | 역할 |
|---|
| Volume/OCI Object Storage | 원본 TXT 저장 |
| ... | |
| Workspace는 Notebook・Compute・Agent 등을 모아 놓은 논리적인 단위입니다. Private Workspace에서는 데이터 소스 연결에 사용되는 VCN・Subnet 등을 설정합니다. AI Lakehouse 측에서는 지정된 Subnet에 Private Endpoint가 생성됩니다. | |
또한, 문서 가져오기용 Spark Compute와 Agent・RAG 툴을 실행하는 AI Compute는 별도의 리소스입니다. 문서를 가져오는 단계와, 가져온 문서를 검색하는 단계에서 각각의 Compute를 사용합니다.
본 기사에서 설정하는 것은 Workspace에서 Private한 데이터 소스로 연결하기 위한 네트워크입니다. AIDP 자체에 대한 접근을 Private화하는 Private Service Access (PSA) 구성은 본 검증 대상에 포함하지 않았습니다.
참고로, AIDP 이름의 Private-AIDP는 이번에 임의로 붙인 명칭일 뿐입니다. 이 명칭이 AIDP 자체의 Private 접근 구성을 의미하는 것은 아닙니다.
1) Lakehouse 네트워크 확인하기
OCI 콘솔에서 대상 Autonomous AI Lakehouse를 엽니다.
- DB 버전이 26ai 이상인지 확인합니다.
- 네트워크 및 액세스를 'Private Endpoint 액세스 전용'으로 설정합니다.
- VCN, Subnet, Private Endpoint IP, NSG를 기록해 둡니다.
- 'Public 액세스'가 비활성화되었는지 확인합니다.
- 연결에 필요한 NSG/Security List 규칙을 확인합니다.
NSG/Security List에서는 Private Workspace 측에서 AI Lakehouse로 필요한 연결을 허용합니다. 같은 Subnet이나 NSG 지정만으로 통신이 자동으로 허용되는 것은 아닙니다. 네트워크 규칙 설정은 마지막의 'Configure Network Access with Private Endpoints'도 참조해 주세요. 본 기사에서는 연결 원본 IP 및 포트의 실측까지는 진행하지 않았기 때문에, 최소 규칙 정의는 다루지 않습니다.
이번에 사용한 NSG 설정은 다음과 같습니다. 화면의 'Stateless'는 모두 No였습니다. 용도는 화면의 Description을 따릅니다.
・ Autonomous AI Lakehouse(ALH)용 NSG
| NSG | 방향 | 연결 원본/대상 (CIDR) | 프로토콜 | 대상 포트 | 용도 및 비고 |
|---|
NSG-ALH | Ingress | 연결 원본: 10.100.0.0/16 | TCP | 1521 | TLS |
NSG-ALH | Ingress | 연결 원본: 10.100.0.0/16 | TCP | 1522 | mTLS |
NSG-ALH | Ingress | 연결 원본: 10.100.0.0/16 | TCP | 443 | Database Actions/APEX/ORDS |
NSG-ALH | Egress | 대상: 10.100.0.0/16 | All Protocols | 모든 프로토콜 | VCN 내부로의 전송 허용 |
・ AIDP용 NSG
| NSG | 방향 | 연결 원본/대상 (CIDR) | 프로토콜 | 대상 포트 | 용도 및 비고 |
|---|
NSG-AIDP | Ingress | 연결 원본: 10.100.0.0/16 | All Protocols | 모든 프로토콜 | 지정 CIDR로부터의 수신 허용 |
NSG-AIDP | Egress | 대상: 10.100.0.0/16 | All Protocols | 모든 프로토콜 | VCN 내부로의 전송 허용 |
NSG-ALH의 TCP 수신 규칙에서는 연결 원본 포트가 모두 All입니다. 위 내용은 성공한 검증 환경 설정이며, 각 규칙이 이번 RAG 처리에 필수적이라는 의미나 실제로 사용된 포트를 나타내는 것은 아닙니다. 특히, 1522의 허용은 이번 연결에서 mTLS를 사용했다는 것을 의미하지 않습니다.
여기에 게재된 것은 NSG 설정입니다. Subnet 측의 Security List 목록은 게재하지 않았으므로, 재현할 때는 NSG와 함께 확인해야 합니다.
2) 기존 Lakehouse를 지정하여 AIDP 생성하기
- OCI 콘솔에서 AI Data Platform 생성 화면을 엽니다.
- AIDP 이름과 초기 Workspace 이름을 입력합니다.
- Oracle autonomous AI lakehouse configuration에서 Choose existing을 선택합니다. - 대상 컴파트먼트와
AI-Lakehouse를 선택합니다. - ADMIN 비밀번호를 입력하고, 필요한 IAM 정책 등의 전제 조건을 충족하여 생성합니다.
- 생성 후, AIDP를 엽니다.
3) 초기화 결과 및 Workspace 확인하기
Notifications에서 다음의 성공을 확인합니다.
CREATE_WORKSPACE
CREATE_CATALOG: vector_db_CDB 등
CREATE_USER_SCHEM…: 벡터 DB용 사용자/스키마 프로비저닝
LOAD_MODEL_IN_CAT…: 모델 로드
Workspaces 목록에는 이번에 Workspace와 Pvt_vector_db_CDB가 자동 생성되어 있었습니다.
Pvt_vector_db_CDB의 Actions → Edit을 열고 다음을 확인합니다.
기본 Workspace의 편집 화면에는 Private network cannot be enabled for Default workspace 라고 표시되어 Private Network를 활성화할 수 없었습니다. 이번에는 자동으로 생성된 Pvt_vector_db_CDB를 사용합니다.
1) TXT 파일 생성하기
파일명: aidp_connection_test.txt
문자코드: UTF-8
이것은 AIDP와 AI Lakehouse의 연결 확인용 문서입니다.
검증 프로젝트명은 「시로쿠마호」입니다.
시로쿠마호의 확인 코드는 「AAL-7319」입니다.
...
질문문에는 확인 코드나 담당자의 답을 넣지 않고, 가져온 문서에서 얻을 수 있는지 확인합니다.
2) Managed Volume 생성하기
- 왼쪽 메뉴의 Master catalog를 엽니다. - 표준 카탈로그
default를 엽니다. - 스키마 default를 엽니다. - Volumes → Create Volume을 선택합니다. - 이름을 vol_aal_test, 종류를 Managed로 하여 생성합니다.
Volume은 Master catalog → default(표준 카탈로그)→ default(스키마)→ Volumes에 생성합니다. 원문서는 이 Volume에 배치하고, 벡터의 저장 및 검색에는 연관된 AI Lakehouse를 사용합니다.
3) TXT 업로드하기
vol_aal_test를 열고, 업로드 작업에서 aidp_connection_test.txt를 배치합니다. 이번 저장소는 다음과 같습니다.
/Volumes/default/default/vol_aal_test/aidp_connection_test.txt
이번 전용 Volume에는 테스트 문서만 배치하고, Knowledge Base의 데이터 소스로 Volume 전체를 지정합니다. 여러 문서를 있는 경우, 전용 폴더를 준비하여 그 폴더를 지정합니다.
1) Private Workspace로 전환하기
왼쪽의 Workspace 선택에서 Pvt_vector_db_CDB를 선택합니다.
2) Spark Cluster 확인 및 생성하기
Compute → Clusters을 엽니다. 기존 Cluster가 없으면, 동일 Workspace에서 가져오기용 Spark Cluster를 생성합니다. 이번에는 Cluster1을 사용하고, 상태가 Active가 된 것을 확인한 후 진행합니다.
Create Cluster 화면에서는 Spark 버전으로 3.5.0을 선택했습니다. 검증 시 화면에 표시된 선택지는 이 1종류뿐이었습니다. 이는 해당 환경 및 검증 시점의 표시이며, 다른 버전과의 비교 검증은 수행하지 않았습니다.
이번 입력은 작은 TXT 파일 1건입니다. 가져오기용 Cluster는 검증용 구성으로 생성합니다.
공식 절차에서는 Knowledge Base 생성 시 Cluster를 미선택하면 Default Master Catalog Compute가 사용됩니다. 이번에는, 가져오는 데 사용할 환경을 명시하기 위해 Private Workspace 내의 Spark Cluster를 선택합니다.
Knowledge Base 생성 화면의 「Cluster used for ingestion」에서 고르는 것이 이 Spark Cluster입니다.
1) Knowledge Base 생성하기
Master catalog → default → default → Knowledge Bases → Create Knowledge Base를 엽니다.
일본어 문서를 사용하기 때문에 임베딩 모델로는 다국어 지원이 가능한 MULTILINGUAL_E5_SMALL을 선택합니다. 청크 크기(Chunk size)는 분할되는 텍스트의 글자 수, 청크 오버랩(Chunk overlap)은 인접한 청크에서 중복시키는 글자 수입니다. 이번 짧은 테스트 문서에서는 각각 500, 50으로 설정했습니다.
이후 JSON에서도 여기서 생성한 이름인 kb_aal_connection_test2를 사용합니다.
2) 데이터 소스 추가하기
- 생성된 KB(Knowledge Base)를 엽니다.
- Data Source → Add data source를 선택합니다. -
default.default.vol_aal_test을 지정합니다. - 필요에 따라 Private Workspace 내의 가져오기 클러스터(Cluster)를 지정합니다.
- 파일 형식에서는 TXT에 해당하는 항목을 선택합니다. 이번 화면에서는 text로 표시되었습니다. - Start ingestion job on add를 선택하여 추가하거나, 추가 후에 Parameters → Ingest now를 실행합니다.
KB의 가져오기 원본은 Volume 또는 Volume 내의 폴더입니다. 파일 단일체를 선택하는 방식이 아닙니다.
3) 가져오기 결과 확인하기
KB → Data Source → vol_aal_test → Job runs를 엽니다.
| 항목 | 이번 성공 값 |
|---|
| Status | Succeeded |
| ... | |
| Parameters에서는 저장소 경로(save path), Workspace 키, Cluster 키도 확인할 수 있습니다. 작업이 성공했더라도 처리 대상이 0건인 경우라면, 경로와 파일 형식 선택을 확인해야 합니다. | |
1) 동일한 Private Workspace에서 AI Compute 생성하기
Compute → AI Compute → Create를 하거나 Agent 화면에서 AI Compute의 신규 생성을 선택합니다.
| 항목 | 이번 설정 |
|---|
| Name | ai_compute_aal_test |
| ... | |
| The 생성 화면에 표시된 사용량은 115 AIDP units per hour였습니다. 이는 해당 화면의 구성 표시이며, 통화로 환산한 요금은 아닙니다. 재현할 때는 현재 표시를 확인합니다. | |
생성 후, 상태가 Active가 될 때까지 기다립니다.
2) Private Workspace 내에 Agent project 생성하기
Pvt_vector_db_CDB를 선택한 상태에서 Agents → Create를 엽니다.
| 항목 | 설정 |
|---|
| Name | agent_aal_connection_test |
| ... | |
| 먼저 생성한 AI Compute를 선택하여 Agent project를 만듭니다. Agent 정의를 생성할 때는 생략할 수도 있지만, RAG 툴의 Test/Playground 실행까지는 연결이 필요합니다. | |
3) Agent와 AI Compute 연결 확인하기
Agent 화면 오른쪽 상단의 Select Playground AI Compute에서 ai_compute_aal_test를 선택합니다. 이름과 ACTIVE가 녹색으로 표시되는지 확인합니다.
기본 Workspace로 AI Compute를 생성했을 때, 다음과 같은 오류가 표시되었습니다.
AI compute cannot be created because the Oracle Autonomous AI
Lakehouse (ALH) attached with this AIDP workbench is configured
with a different subnet than current workspace. To resolve this
...
대응책으로, Lakehouse와 동일한 Subnet을 설정한 Pvt_vector_db_CDB로 전환하고 AI Compute를 생성했습니다.
이 동작에 대해 제품팀에 확인해 본 결과, 의도된 동작이라는 답변을 받았습니다. 이번 Private Endpoint 구성에서는 연결된 AI Lakehouse와 동일한 Subnet을 설정한 Private Workspace에 AI Compute를 생성하게 됩니다.
이번 오류는 DB 연결 테스트 시가 아니라, AI Compute를 생성할 때 표시되었습니다. 네트워크상의 도달 가능성과 별개로, 생성 시 조건으로 Workspace와 AI Lakehouse의 동일 Subnet이 요구됨을 확인했습니다. 같은 VCN이라도 Subnet이 다르면 이 조건을 충족하지 못합니다.
한편, 후술하는 SQL 확인에서는 AI Lakehouse와는 다른 Subnet에 배치된 Oracle Linux Compute에서 연결할 수 있었습니다. 따라서 이번에 확인한 동일 Subnet 조건은 AI Compute 생성 시의 Workspace 설정과 관련된 것이며, 모든 SQL 클라이언트에 동일 Subnet을 요구한다는 의미가 아닙니다. 별도의 Subnet으로 Workspace를 설정하여 AI Compute를 생성하는 구성이나, 다른 VCN으로부터의 연결은 이번에 검증하지 않았습니다. 또한, 이 동일 Subnet 조건을 명시한 공개 문서도 검증 시점에서는 찾을 수 없었으며, 문서 업데이트에 대한 검토가 요청되었습니다.
이 조건은 이번 AI Compute 생성 건에 대해 확인된 것입니다. Notebook에서 수행하는 Python/Spark의 머신러닝이나 External Catalog를 통한 외부 DB 연결과는 구분하여 생각해야 합니다.
1) RAG 도구 배치하기
Agent project의 Flow → Development를 열고, 왼쪽의 Tool templates → RAG를 캔버스에 드래그합니다. 이번 노드명은 RAG_1입니다.
이번에는 RAG 도구의 Test 기능을 사용합니다. Agent project 내부에 RAG 도구를 배치하고, 도구 단독으로 질문을 보내 문서 검색과 답변 생성을 확인합니다.
2) 모델 및 Knowledge Base 지정하기
RAG_1를 선택하고 Parameters에 다음과 같이 설정합니다.
| 항목 | 이번 설정 |
|---|
| Model configuration | OCI Generative AI service |
| ... | |
Limit은 벡터 스토어에서 검색으로 가져오는 문서 청크(chunk) 수의 상한입니다. 이번 설정값은 5이지만, 5개의 파일을 가져오도록 지정하는 것은 아닙니다. | |
답변 생성에 사용되는 LLM으로는 이번 화면에 표시된 xai.grok-4.7를 선택했습니다. 이용 가능한 모델은 리전이나 권한 등에 따라 확인해야 합니다.
이번에는 Knowledge base 항목의 ▼를 눌러도 후보가 열리지 않았고, 문자 입력도 할 수 없었습니다. KB는 이미 생성되어 있었고, 문서 가져오기(ingestion)도 성공했었습니다.
Configuration 오른쪽의 <> 클릭하여 JSON 보기로 전환합니다. 이번 화면에서 얻은 JSON 형식에 맞춰 다음과 같이 입력했습니다.
{
"catalogKey": "default",
"schemaKey": "default",
...
}
원래 JSON에서는 catalogKey, schemaKey, knowledgeBase가 null이었기 때문에, 각각 default, default, kb_aal_connection_test2를 입력했습니다. 표 형식으로 돌아가니 Knowledge base 항목에 default.default.kb_aal_connection_test2가 표시되었습니다.
Apply/저장 작업이 있다면 반영하고, 노드를 다시 열어 값이 유지되는지 확인합니다. 다른 제품 버전에서는 필드 형식이 다를 수 있으므로, 이용 화면에서 얻은 JSON을 기반으로 변경해야 합니다. 이번 topK는 원래 GUI의 문자열 형식을 유지했습니다.
드롭다운이 반응하지 않는 원인은 특정할 수 없었으나, 이번에는 JSON으로 직접 지정함으로써 회피할 수 있었습니다.
1) Test 실행하기
- Agent 화면 우상단에서 AI Compute가 ACTIVE 상태로 연결되었는지 확인합니다.
RAG_1
‘Test’ 탭을 열고, Query에 다음을 입력합니다.
Submit 버튼을 누릅니다.
2) 답변과 참조 원본 확인하기
이번에는 Test results에 다음이 표시되었습니다.
しろくま湖の確認コードは「AAL-7319」、担当者は「青葉」입니다.
더불어, 가져온 문서와 다음 참조 원본 경로가 표시되었습니다.
/Volumes/default/default/vol_aal_test/aidp_connection_test.txt
답변의 정확성 외에도, 가져온 문서와 참조 원본이 표시되는 것을 성공 조건으로 합니다. 화면에 표시된 Score는 검색 결과 지표이며, 답변의 정답 확률이나 연결 신뢰도로 간주하지 않습니다.
3) 연결 확인 결과
| 단계 | 확인된 내용 |
|---|
| AIDP 초기화 성공 | 연관 설정・스키마 생성・모델 로드 등의 초기화 |
| ... | |
| AI Lakehouse의 Public Access를 비활성화한 구성에서, 문서 가져오기부터 RAG 검색 및 답변 생성까지 성공했습니다. | |
참고로, 이번에는 기능 동작 확인을 진행했기 때문에 VCN Flow Log 등을 통한 통신 경로나 연결 원본 IP 상세 확인은 진행하지 않았습니다.
RAG의 답변은 얻었지만, 가져온 문서와 벡터가 AI Lakehouse의 어디에 저장되어 있는지 궁금합니다.
이에 따라 AI Lakehouse에 SQL로 연결하여, 가져온 문서와 벡터의 저장 위치를 확인해 보았습니다.
이번에는 AI Lakehouse와는 다른 Subnet에 배치된 Oracle Linux Compute에서, AIDP와 연관된 AI Lakehouse에 ADMIN 권한으로 접속하여 다음 SELECT 문을 실행했습니다. 스키마명・테이블명은 이번 환경에서 확인된 값이라, 다른 환경에서는 검색 결과에 맞춰 읽어 사용합니다.
1) 연결 대상 AI Lakehouse 확인하기
SELECT
SYS_CONTEXT('USERENV', 'DB_NAME') AS db_name,
SYS_CONTEXT('USERENV', 'SERVICE_NAME') AS service_name,
...
이번 실행 결과는 다음과 같았습니다.
| 항목 | 실행 결과 |
|---|
| DB_NAME | G912A29DFC5DE89_CDB |
| ... | |
| 2) VECTOR 타입 컬럼을 가진 테이블 찾기 | |
데이터 디크셔너리에서 VECTOR 타입을 가진 컬럼이 있는 테이블을 검색합니다.
SELECT
c.owner AS schema_name,
c.table_name,
...
| SCHEMA_NAME | TABLE_NAME | VECTOR_COLUMN |
|---|---|
| AIDP_2UHUP2WQ_KB_WRITE | EMBEDDING_TABLE_D46AC2B | EMBEDDING |
| VECSYS | CANDIDATE_QUERY_VECTORS$ | QUERY_VECTOR |
이번에는 AIDP_2UHUP2WQ_KB_WRITE.EMBEDDING_TABLE_D46AC2B를 후보로 조사합니다. 테이블명만으로 판단하지 않고, 후속 SQL에서 테스트 문서의 본문과 일치하는지 확인합니다.
3) 후보 테이블의 컬럼 구성 확인하기
SELECT
column_id,
column_name,
...
| COLUMN_ID | COLUMN_NAME | DATA_TYPE | DATA_LENGTH |
|---|---|
| 1 | DOCID | VARCHAR2 | 1024 |
| ... |
본문을 저장하는 BODY 컬럼은 CLOB 타입, 벡터를 저장하는 EMBEDDING 컬럼은 VECTOR 타입이었습니다. 참고로, DATA_LENGTH의 8200은 벡터의 차원수가 아닙니다. 실제 벡터의 차원수와 형식은 다음 SQL에서 확인합니다.
4) 테스트 문서 본문과 벡터 차원수 확인하기
문서에 들어간 'しろくま湖'를 검색하여, 같은 행의 벡터 정보를 가져옵니다.
SELECT
docid,
chunkid,
...
VECTOR_DIMENSION_COUNT
벡터의 차원 수, VECTOR_DIMENSION_FORMAT
벡터가 저장된 형식을 반환합니다.
이번에 다음 행을 가져올 수 있었습니다.
| 항목 | 실행 결과 |
|---|
| DOCID | 3_2 |
| ... | CHUNK_TEXT |
에는 다음 테스트 문서의 본문이 들어있었습니다. 읽기 쉽도록 줄 바꿈하여 게재합니다.
これはAIDPとAI Lakehouseの接続確認用文書です。
検証プロジェクト名は「しろくま湖」です。
しろくま湖の確認コードは「AAL-7319」です。
...
테스트 문서의 본문과, 384차원・FLOAT32 벡터가 AI Lakehouse의 같은 테이블의 같은 행에 저장되어 있음을 확인할 수 있었습니다.
5) 벡터의 수치를 표시하기
VECTOR_SERIALIZE로 벡터를 문자열로 변환하고, 앞 500자리를 표시합니다.
SELECT
chunkid,
DBMS_LOB.SUBSTR(
...
chunk_0의 벡터는 다음 수치부터 시작했습니다. 여기서는 실행 결과의 초반부만 발췌했습니다.
[7.12562129E-002,-1.042281E-002,-3.45408507E-002,1.05754682E-003,7.66558498E-002,...
이로써 벡터의 차원 수나 형식뿐만 아니라, 저장된 수치도 확인할 수 있었습니다. SQL에서는 앞 500자리에 잘라내기 때문에, 표시가 수치의 도중에 끝날 수도 있습니다.