Oracle Database 26ai Select AI 실전 가이드: NL2SQL보다 먼저 데이터 이동 경계와 도구 실행 위치를 설계해야 하는 이유

발행일: 2026-05-05 | 카테고리: 개발정보

1) 한 줄 문제 정의

핵심 요약: 사내 데이터에 AI를 붙일 때 가장 흔한 실패는 모델이 아니라, 데이터를 어디로 옮기고 어떤 계층에서 도구를 실행할지 먼저 정하지 않는 데서 시작됩니다.

Oracle Database 26ai의 Select AI는 자연어를 SQL로 바꾸는 기능만 있는 것이 아닙니다. 공식 문서를 보면 26ai는 NL2SQL, RAG, 에이전트, 요약, 번역, 피드백 루프를 모두 데이터베이스 안쪽으로 끌어들입니다. 겉으로 보면 편해 보이지만, 실무에서는 오히려 더 중요한 질문이 생깁니다. “LLM을 붙일 수 있느냐”가 아니라 기업 데이터에 대한 질의, 검색, 도구 호출, 메모리 보존을 어느 실행 경계 안에 둘 것인가를 먼저 정해야 하기 때문입니다.

이 글은 사내 분석 시스템, 데이터 제품, 운영 자동화, AI 기반 내부 도구를 검토하는 백엔드 개발자와 데이터 플랫폼 팀을 위한 해설입니다. 범위는 Oracle Select AI 26ai의 구조와 도입 판단 기준입니다. 반대로 일반적인 생성형 AI 입문, LLM 모델 성능 순위, 전체 데이터 웨어하우스 설계는 다루지 않습니다.

2) 먼저 결론

핵심 요약: Select AI 26ai는 “DB에 챗봇 붙이기”보다 데이터 가까이에서 AI 실행을 통제하려는 팀에 맞습니다.

• 지금 잘 맞는 팀: Oracle 데이터베이스가 이미 핵심 시스템이고, 데이터 이동을 줄이면서 NL2SQL·RAG·내부 에이전트를 빠르게 붙이고 싶은 팀
• 아직 과한 팀: 데이터 소스가 대부분 Oracle 밖에 있고, 브라우저 자동화나 외부 SaaS 쓰기 도구가 더 중요한 팀
• 핵심 판단축: 모델 자체보다 실행 위치, 거버넌스, 데이터 반출 최소화, SQL 정확도 피드백 체계

제 판단은 명확합니다. Select AI 26ai의 진짜 가치는 “자연어로 SQL을 만든다”가 아니라, 데이터 질의·RAG·에이전트 실행을 데이터베이스 보안 경계 안에서 최대한 끝내려는 설계에 있습니다. 그래서 단순 챗 인터페이스를 찾는 팀보다, 감사 로그와 권한 모델을 유지한 채 AI 기능을 붙여야 하는 팀에 더 잘 맞습니다.

3) 핵심 구조 분해

핵심 요약: Select AI 26ai는 한 기능이 아니라 프로필, NL2SQL, RAG, Agent, 피드백이 이어지는 체계로 봐야 이해가 쉽습니다.

3-1. AI Profile 계층

가장 먼저 봐야 할 것은 모델이 아니라 DBMS_CLOUD_AI.CREATE_PROFILE로 만드는 AI 프로필입니다. 이 프로필에는 어떤 제공자를 쓸지, 어떤 자격 증명을 쓸지, 어떤 객체를 질의 허용 범위로 둘지 같은 조건이 들어갑니다. 초보 개발자 기준으로 쉽게 말하면, 프롬프트 이전에 데이터 접근 계약서를 만드는 단계입니다.

3-2. NL2SQL 계층

Select AI는 SELECT AI, SHOWSQL, EXPLAINSQL, CHAT 같은 액션으로 자연어 질의와 SQL 생성·설명을 다룹니다. 중요한 점은 단순 생성만이 아니라, 생성된 SQL을 보여주고 설명할 수 있다는 점입니다. 이 구조는 “AI가 뭘 실행했는지”를 검토해야 하는 팀에 유리합니다.

3-3. RAG 계층

26ai의 RAG는 외부 검색 파이프라인을 따로 만들지 않아도, 객체 스토리지 문서를 청킹하고 임베딩을 생성하고 벡터 인덱스를 갱신하는 흐름을 데이터베이스 쪽에서 관리할 수 있게 설계돼 있습니다. 즉 RAG를 별도 제품이 아니라 데이터베이스 안의 보조 검색 계층으로 붙이는 접근입니다.

3-4. Agent 계층

Select AI Agent는 ReAct 패턴을 따라 계획 → 도구 실행 → 반성 → 메모리 관리의 네 층으로 동작합니다. 여기서 쓸 수 있는 도구는 NL2SQL, RAG, 사용자 정의 PL/SQL, 외부 REST API입니다. 즉 “데이터베이스가 질문에 답하는 것”을 넘어, 데이터를 읽고 도구를 고르고 후속 액션까지 이어가는 실행 프레임이 됩니다.

3-5. 피드백 계층

Oracle 문서가 특히 실무적인 지점은 피드백 루프입니다. DBMS_CLOUD_AI.FEEDBACK으로 SQL 생성 결과에 긍정·부정 피드백을 줄 수 있습니다. 이 기능은 단순 편의가 아니라, 사내 용어와 스키마 특수성 때문에 흔들리는 NL2SQL 정확도를 운영 중에 보정하는 장치입니다.

4) 설계 의도 해설

핵심 요약: Oracle의 방향은 모델 연결 자체보다 기업 데이터와 AI 실행을 같은 거버넌스 안에 두는 것에 가깝습니다.

많은 팀은 AI 기능을 붙일 때 데이터를 ETL로 빼고, 벡터DB를 따로 만들고, 에이전트 런타임을 별도 서버에 둡니다. 이 방식은 유연하지만, 데이터가 여러 계층을 지나가면서 권한, 최신성, 감사 추적이 흔들리기 쉽습니다. Oracle 26ai는 이 반대 방향을 택했습니다. 자연어 질의, 벡터 검색, 에이전트 도구 실행을 데이터베이스 중심으로 묶어 데이터 이동을 줄이고 기존 보안 경계를 활용하려는 것입니다.

얻는 것과 포기하는 것도 분명합니다.

• 얻는 것: 데이터 근접 실행, 감사와 권한 모델 재사용, SQL/PLSQL 기반 빠른 조합, RAG와 에이전트의 통합 운영
• 포기하는 것: 완전한 벤더 독립성, 비Oracle 중심 스택에서의 단순성, 브라우저·외부 SaaS 중심 자동화의 자유도
• 실무 해석: 데이터 중심 업무 자동화에는 강하지만, 화면 조작형 에이전트나 범용 멀티SaaS 자동화의 기본 플랫폼으로 보기에는 과할 수 있습니다

제 해석으로는 Select AI 26ai는 “LLM을 DB에 넣었다”가 아니라, 데이터 계층이 에이전트 런타임 일부를 흡수하기 시작한 사례로 보는 편이 맞습니다. 이 차이를 이해해야 도입 판단이 흔들리지 않습니다.

5) 근거 및 비교

핵심 요약: Select AI 26ai는 단순 NL2SQL 도구와 비교할 것이 아니라, 데이터 이동·운영 경계·피드백 가능성으로 비교해야 합니다.

공식 문서 기준으로 확인되는 핵심 근거는 아래와 같습니다.

• Select AI 예제 문서: SELECT AI, SHOWSQL, EXPLAINSQL, CHAT, SUMMARIZE, FEEDBACK까지 하나의 문법 체계로 제공합니다.
• 지원 제공자 범위: OCI, OpenAI, Cohere, Azure OpenAI, Google, Anthropic, Hugging Face, AWS, OpenAI-compatible 제공자 예제가 공식 문서에 나옵니다. 즉 모델 공급자 폭은 넓지만, 운영 중심은 DB입니다.
• RAG 문서: PDF, DOC, JSON, XML, HTML 등 문서를 평문으로 바꾸고 청킹·임베딩·벡터 인덱스 갱신을 자동화한다고 명시합니다.
• Agent 문서: Planning, Tool Use, Reflection, Memory Management의 4계층과 ReAct 루프를 명시합니다.
• 보안 통제: 관리자가 실제 테이블 데이터나 벡터 검색 문서가 LLM에 전송되지 않도록 비활성화할 수 있다고 RAG 문서에 적혀 있습니다.

즉 Select AI 26ai를 볼 때 핵심은 “얼마나 똑똑한 모델을 쓸 수 있나”가 아니라, 기업 데이터 기반 AI를 얼마나 적은 이동과 적은 별도 인프라로 운영할 수 있나입니다.

6) 실제 동작 흐름 / 단계별 실행 방법

핵심 요약: 처음부터 Agent까지 올리기보다 프로필 제한 → SHOWSQL 검증 → 피드백 → RAG → Agent 순서가 안전합니다.

1. AI 프로필에서 허용 객체를 좁힙니다.
   처음부터 전체 스키마를 열지 말고, 예를 들어 sales.orders, sales.customers처럼 실제 필요한 테이블만 object_list에 넣습니다.
2. RUNSQL보다 SHOWSQL로 먼저 검증합니다.
   바로 실행시키기 전에 생성 SQL을 노출해 검토하는 단계가 필요합니다. 초반에는 사람이 검수하지 않는 자동 실행을 피하는 편이 좋습니다.
3. 피드백 루프를 만듭니다.
   사내 용어가 특이하면 첫 결과가 흔들릴 수 있습니다. 자주 틀리는 패턴을 DBMS_CLOUD_AI.FEEDBACK으로 누적해야 정확도가 안정됩니다.
4. 정형 데이터와 문서 데이터를 분리합니다.
   테이블 질의는 NL2SQL, 매뉴얼·정책·문서 검색은 RAG로 나눕니다. 두 문제를 같은 프롬프트로 밀어 넣으면 정확도도 떨어지고 디버깅도 어려워집니다.
5. RAG는 작은 문서군부터 시작합니다.
   문서를 객체 스토리지에 넣고 벡터 인덱스를 만들되, 처음에는 한 도메인 문서만 넣어서 회수 품질을 확인합니다.
6. Agent는 읽기 도구부터 시작합니다.
   처음부터 외부 REST 쓰기나 변경 작업을 허용하지 말고, NL2SQL·RAG·조회성 REST만 열어 에이전트의 계획 품질을 먼저 봅니다.

-- 1) AI 프로필 생성 예시
BEGIN
  DBMS_CLOUD_AI.CREATE_PROFILE(
    profile_name => 'GENAI',
    attributes => '{
      "provider": "oci",
      "credential_name": "OCI$RESOURCE_PRINCIPAL",
      "object_list": [
        {"owner": "SH", "name": "CUSTOMERS"},
        {"owner": "SH", "name": "COUNTRIES"}
      ]
    }'
  );
END;
/

-- 2) 세션에 프로필 적용
EXEC DBMS_CLOUD_AI.SET_PROFILE('GENAI');

-- 3) 생성 SQL 먼저 확인
SELECT AI SHOWSQL how many customers in San Francisco are married;

-- 4) RAG용 벡터 인덱스 생성 예시
BEGIN
  DBMS_CLOUD_AI.CREATE_VECTOR_INDEX(
    index_name => 'RAG_INDEX',
    attributes => '{
      "vector_db_provider": "oracle",
      "profile_name": "RAG_PROFILE",
      "chunk_overlap": 128,
      "chunk_size": 1024
    }'
  );
END;
/

-- 5) Agent에서 RAG 도구 생성 예시
EXEC DBMS_CLOUD_AI_AGENT.CREATE_TOOL(
  'RAG_TOOL',
  '{"tool_type": "RAG", "tool_params": {"profile_name": "RAG_PROFILE"}}'
);

실무 기준으로는 아래 두 수치를 꼭 봐야 합니다. 첫째, SHOWSQL 검수 통과율. 둘째, RAG 회수 문서 적중률입니다. 이 둘이 낮은데 Agent를 먼저 올리면, 그 위에 쌓이는 자동화는 대부분 착시가 됩니다.

7) 실수/함정(Pitfalls)

핵심 요약: Select AI 26ai의 실패는 대개 모델 문제가 아니라, 허용 범위 과개방과 계층 혼동에서 나옵니다.

• 실수 1: 프로필에 전체 스키마를 열어두는 것
  예방: object_list를 최소화하고 민감 스키마를 분리합니다.
  복구: 사용 로그를 보고 과도한 객체 접근을 줄인 새 프로필로 교체합니다.
• 실수 2: SHOWSQL 없이 바로 RUNSQL 자동 실행
  예방: 초기 단계에서는 생성 SQL을 검토하고 승인 기준을 둡니다.
  복구: 자동 실행을 중단하고 설명 가능한 질의 경로로 되돌립니다.
• 실수 3: NL2SQL과 RAG를 같은 문제처럼 다루는 것
  예방: 구조화 질의와 문서 검색을 별도 경로로 나눕니다.
  복구: 실패 사례를 SQL 오역인지, 문서 회수 실패인지 분리해 다시 측정합니다.
• 실수 4: Agent에 외부 쓰기 도구를 너무 빨리 여는 것
  예방: 읽기 전용 도구와 승인형 작업을 분리합니다.
  복구: REST 쓰기 도구를 잠시 제거하고 반성 로그를 기준으로 정책을 조정합니다.
• 실수 5: 피드백 기능을 쓰지 않는 것
  예방: 자주 틀리는 사내 용어와 조인 패턴을 기록해 피드백합니다.
  복구: 오답 질의를 묶어 정기 보정 세션을 운영합니다.

8) 강점과 한계

핵심 요약: Select AI 26ai는 데이터 중심 AI 운영에는 강하지만, 범용 에이전트 플랫폼으로 과대평가하면 오히려 어긋납니다.

강점

• NL2SQL, SQL 설명, RAG, Agent, 피드백 루프가 하나의 운영 경계 안에 있습니다.
• 기존 Oracle 보안, 권한, 감사 체계를 재사용할 수 있어 규제 산업에 설명이 쉽습니다.
• 문서 기반 RAG의 청킹·임베딩·인덱스 갱신 자동화가 비교적 명확합니다.
• PL/SQL과 REST 도구를 함께 묶어 내부 자동화 시나리오를 빠르게 만들 수 있습니다.

한계

• Oracle이 중심이 아닌 조직에는 구조 자체가 과할 수 있습니다.
• 브라우저 조작, 외부 SaaS 다중 쓰기, UI 중심 워크플로에는 별도 런타임이 더 자연스럽습니다.
• NL2SQL은 피드백과 메타데이터 품질이 없으면 정확도 착시가 쉽게 납니다.
• Agent가 있어도 승인 경계와 정책 설계를 대신해주지는 않습니다.

반례: 여러 SaaS를 오가며 영업 자동화나 마케팅 운영을 하는 팀이라면, Oracle DB 안쪽 에이전트보다 외부 오케스트레이션 플랫폼이 더 나을 수 있습니다.

9) 더 깊게 공부할 포인트

핵심 요약: 다음 단계는 기능 목록 암기가 아니라, 어떤 업무를 DB 안에서 끝낼지를 가르는 것입니다.

• NL2SQL 정확도: 주석, 외래키, 제약조건, 컬럼 설명이 생성 품질에 얼마나 영향을 주는지
• RAG 운영: 어떤 문서군을 벡터화할지, chunk size 1024와 overlap 128이 우리 문서에 맞는지
• Agent 정책: 읽기 도구와 쓰기 도구를 어떻게 분리할지
• 메모리 전략: 장기 메모리에 남겨도 되는 정보와 세션 한정 정보의 경계
• 거버넌스: 실제 테이블 데이터와 벡터 문서의 LLM 전송 비활성화 정책을 언제 켤지

초보 개발자라면 먼저 “왜 SQL 생성 전에 object_list를 제한해야 하는가”, “왜 RAG와 테이블 질의는 분리해야 하는가” 두 가지만 확실히 이해해도 충분히 출발할 수 있습니다.

10) 실행 체크리스트 + 작성자 관점

핵심 요약: Select AI 26ai 도입의 완료 기준은 데모가 아니라, 허용 범위와 검수 루프가 살아 있는 상태입니다.

• AI 프로필에 허용 테이블과 자격 증명 범위를 최소화했는가?
• 초기 질의를 RUNSQL이 아니라 SHOWSQL 중심으로 검수하고 있는가?
• 자주 틀리는 용어와 조인 패턴에 대한 피드백 루프가 있는가?
• 정형 데이터 질의와 문서 RAG를 서로 다른 경로로 나눴는가?
• Agent 도구 중 외부 쓰기 권한은 승인 경계 뒤로 보냈는가?
• 테이블/문서가 LLM에 전송되지 않도록 막아야 하는 시나리오를 문서화했는가?

Definition of Done: 제한된 AI 프로필, SHOWSQL 검수 절차, 피드백 기록, 읽기 중심 Agent 정책, RAG 회수 품질 측정표가 갖춰져 있고 테스트 질의 30건 기준 치명적 오실행 없이 반복되면 1차 도입 완료로 봅니다.

제 추천: Oracle 기반 기업 데이터가 이미 핵심 자산이라면, Select AI 26ai는 꽤 강한 선택지입니다. 다만 처음부터 “DB 안에서 에이전트까지 다 하겠다”로 시작하지 말고, NL2SQL 검수 루프와 RAG 회수 품질부터 안정화한 뒤 Agent를 올리시는 편이 맞습니다. 반대로 데이터 소스가 분산돼 있고 외부 앱 자동화가 주력이라면, Select AI를 중심에 두기보다 보조 데이터 계층으로 제한하는 쪽이 더 현실적입니다.

참고자료

• Oracle Machine Learning Blog - Select AI by release: a quick guide to 26ai and 19c capabilities
• Oracle Docs - Examples of Using Select AI (2026-05-05 확인)
• Oracle Docs - About Select AI Agent (2026-05-05 확인)
• Oracle Docs - Select AI with Retrieval Augmented Generation (RAG) (2026-05-05 확인)