2026년 5월 16일, OpenAI는 공식 채널을 통해 Databricks 위에서 GPT-5.5를 1급 모델로 노출하는 파트너십을 공개했다. 단순한 모델 카탈로그 추가가 아니라, 데이터·거버넌스·평가가 한 플랫폼 안에 묶이는 형태라는 점이 핵심이다. 필자는 지난 분기 사내 LLM 도입 PoC에서 동일한 고민을 안고 Mosaic AI Gateway·Agent Bricks·Genie 조합을 시험해 본 적이 있어, 이번 발표가 어떤 빈자리를 메우는지가 비교적 또렷하게 보였다. 이번 글은 발표문을 그대로 옮기는 대신, 일반 기업이 사내 에이전트를 만들 때 가져갈 만한 패턴을 정리하는 데 초점을 둔다.
📌 핵심 3줄 요약
- OpenAI는 2026-05-16 발표로 Databricks 위에서 GPT-5.5를 Mosaic AI Gateway 경유로 1급 노출, 데이터·거버넌스·평가가 한 플랫폼에 묶였다.
- 핵심은 모델이 아니라 통합 방식이다. Unity Catalog 권한 분리, 라우팅, Mosaic Evaluation 평가 루프, 토큰 가드레일, Vector Search RAG가 한 묶음으로 동작한다.
- 일반 기업도 동일 구조를 자체 스택에 이식 가능하다. 본문은 그 5가지 패턴과 한국 도입 시 고려사항을 정리한다.
🗓️ 5월 16일 발표가 중요한 이유
이번 발표의 1차 출처는 OpenAI 공식 페이지와 Databricks 공식 블로그다. 핵심은 두 가지다. 첫째, GPT-5.5가 Foundation Model APIs 카탈로그에 1급으로 등록되어 별도 키 관리 없이 Databricks 워크스페이스 내부에서 호출 가능하다. 둘째, 호출 경로가 Mosaic AI Gateway를 거치게 되어 모델 호출이 곧 거버넌스 이벤트가 된다. 사내 데이터 흐름과 모델 호출이 같은 보안 경계 안에서 관찰·통제된다는 의미다. 그동안 별도 프록시·게이트웨이 레이어를 자체 구축하던 팀에는 적지 않은 단축이다.

🔧 Mosaic AI Gateway 위에서 GPT-5.5는 어떻게 호출되는가
Mosaic AI Gateway는 LLM 호출을 단일 엔드포인트로 정규화하는 레이어다. 애플리케이션 코드는 OpenAI SDK와 거의 동일한 형태로 작성하되, 베이스 URL만 Databricks 서빙 엔드포인트로 바꿔 호출한다. 게이트웨이는 그 요청을 받아 인증·요율 제한·PII 마스킹·감사 로그를 적용한 뒤 백엔드의 GPT-5.5 또는 다른 등록 모델로 전달한다. 호출자 입장에서 모델이 무엇이든 인터페이스는 같다.
from openai import OpenAI
# 베이스 URL만 Databricks 서빙 엔드포인트로 교체
client = OpenAI(
base_url="https://<workspace>.cloud.databricks.com/serving-endpoints",
api_key="<DATABRICKS_TOKEN>",
)
resp = client.chat.completions.create(
model="databricks-gpt-5-5", # Foundation Model APIs 카탈로그 식별자
messages=[{"role": "user", "content": "Q3 영업 데이터 요약해줘"}],
)
print(resp.choices[0].message.content)
이 단순함이 엔터프라이즈에서 갖는 의미는 크다. SDK는 그대로 두고 운영 정책만 게이트웨이에서 바꿀 수 있다. 모델을 교체하거나 가격 정책을 조정할 때 애플리케이션 코드를 다시 배포할 필요가 없다.

🔗 Agent Bricks·Genie와 결합되는 방식
Databricks는 사내 데이터 위에서 동작하는 에이전트를 만들 때 두 갈래 진입점을 제공한다. 분석가용 자연어 질의는 Genie, 개발자용 도구·함수 호출 에이전트는 Agent Bricks 쪽이다. Genie는 Unity Catalog에 등록된 테이블의 스키마와 권한을 그대로 상속한다. 사용자가 영어든 한국어든 질문을 던지면, Genie는 SQL을 생성하고 그 사용자가 접근 가능한 행·열만으로 답을 만든다. 권한이 데이터 레이어에 박혀 있어, GPT-5.5가 강해진다고 해서 정보 누출 범위가 자동으로 넓어지지 않는다.
Agent Bricks는 도구 호출·계획·평가가 묶인 에이전트 빌드 환경이다. 함수 등록, 평가 데이터셋 연결, 회귀 평가를 한 흐름에서 진행한다. 자체 LangChain 코드로 같은 구조를 만들 수는 있지만, 평가 루프와 거버넌스가 처음부터 결합된 점이 차이다.
🆚 일반 기업이 가져갈 5가지 패턴
아래 표는 Databricks가 묶어 둔 요소를 일반 스택으로 옮길 때의 대응 컴포넌트와 도입 우선순위를 정리한 것이다.
| 패턴 | Databricks 구성 | 자체 스택 대응 | 우선순위 |
|---|---|---|---|
| 데이터 권한 분리 | Unity Catalog | RLS·CLS + IAM 통합 | 최상 |
| 모델 라우팅 | Mosaic AI Gateway | LiteLLM·자체 프록시 | 상 |
| 평가 루프 | Mosaic Evaluation | Ragas·DeepEval·자체 골든셋 | 상 |
| 비용 가드레일 | Gateway 토큰 캡 | 사용자별 토큰 쿼터·예산 알람 | 중 |
| 도메인 RAG | Mosaic Vector Search | pgvector·Qdrant·OpenSearch | 상 |
다섯 가지 중 가장 먼저 자리 잡혀야 하는 것은 권한 분리다. 모델이 똑똑해질수록 잘못된 권한 설계의 비용이 커진다. 라우팅과 평가 루프는 동시에 깔아 두는 편이 좋다. 라우팅이 있어야 모델 교체 실험이 안전하고, 평가 루프가 있어야 그 실험의 결과를 정량적으로 비교할 수 있다. 비용 가드레일은 마지막에 두기 쉽지만, 사내 챗봇 한 개가 하루 만에 월 예산을 태우는 사례가 드물지 않다는 점은 기억해 둘 만하다.

✅ 한국 기업 도입 시 고려사항
이번 통합이 매력적이라 해도 한국에서 곧장 베껴 쓰기엔 손에 꼽을 만한 변수가 있다. 첫째, 리전이다. Databricks Foundation Model APIs는 모델별로 제공 리전이 다르고, GPT-5.5의 경우 발표 시점 기준 일부 미국·EU 리전 위주다. 한국 리전이 아직 비어 있다면 데이터 이동 경계를 정책 문서로 명확히 해 두어야 한다. 둘째, KISA·금감원 가이드 환경에서 외부 모델 호출 로그·프롬프트 보존 정책이 어떻게 평가될지를 사전 검토 대상으로 잡아야 한다.
셋째, 내부 데이터 거버넌스다. Unity Catalog 같은 통합 카탈로그가 없는 조직이라면, RAG 인덱스를 만들기 전에 데이터 분류 체계부터 합의해야 한다. 권한이 없는 사용자에게 노출되면 안 되는 컬럼이 임베딩에 그대로 들어가는 사고는, 모델 성능이 좋을수록 더 빨리 드러난다. 모델보다 분류가 먼저다.

⚠️ 단점과 주의할 점
- 플랫폼 종속성이 커진다. Mosaic 스택에 깊게 묶일수록 다른 클라우드로의 이식 비용이 늘어난다.
- 가격 모델은 토큰 단가 외에 서빙 엔드포인트 시간당 비용이 더해진다. 트래픽이 적은 사내 챗봇은 오히려 비싸질 수 있다.
- 현재 일부 한국 리전은 미지원이다. 데이터 거주 요건이 있는 조직은 시작 전에 리전 매트릭스를 확인해야 한다.
- 발표 직후 스펙·가격은 변동 가능성이 크다. 본 내용은 2026년 5월 18일 기준 1차 자료 정리이며, 실제 도입 전 최신 공식 문서 재확인이 필요하다.
🚀 지금 바로 할 일
- OpenAI·Databricks 공식 발표문을 사내 아키텍처 회의 자료로 공유해 의사결정자의 컨텍스트를 맞춘다.
- 현재 자체 스택에서 5가지 패턴(권한·라우팅·평가·가드레일·RAG) 중 부재한 항목을 표로 그려 우선순위를 매긴다.
- PoC 범위를 1개 부서·1개 데이터 도메인으로 좁혀, 평가 데이터셋부터 만든다. 모델 선택은 그 다음이다.
참고 자료
- OpenAI 공식 발표 — Databricks brings GPT-5.5 to enterprise agent workflows
- Databricks 공식 블로그 (Mosaic AI Gateway·Agent Bricks·Genie 관련 글)
- Databricks Foundation Model APIs 공식 문서
💬 의견
사내에서 LLM 게이트웨이나 평가 루프를 직접 구축해 본 분이 있다면, 어떤 패턴이 가장 먼저 자리 잡았는지 댓글로 공유 부탁드린다. 다음 글은 LiteLLM 기반 자체 라우팅 게이트웨이 구축기로 이어 갈 예정이다.
작성자: AI·기술 블로그 운영자. 사내 LLM 도입 PoC 경험을 바탕으로 엔터프라이즈 에이전트 아키텍처를 분석한다.
검증 환경: 2026-05-18 기준 OpenAI·Databricks 공식 발표 자료 및 Mosaic AI 문서 교차 확인. 본문의 코드·아키텍처 도식은 공식 문서 인용을 기반으로 재작성했다.
'AI 뉴스' 카테고리의 다른 글
| Apache Burr 첫인상: 상태머신 기반 AI 에이전트 (2026) (0) | 2026.06.11 |
|---|---|
| Anthropic Petri 완벽 분석: AI가 코드 취약점을 자동으로 찾는 오픈소스 프레임워크 (2026) (0) | 2026.06.05 |
| Gemma 4 12B 로컬 실행: 16GB VRAM 멀티모달 가이드 (0) | 2026.06.04 |
| AWS Bedrock OpenAI 모델 사용법 완벽 정리 (2026) (0) | 2026.06.02 |
| Starlette CVE-2026-48710 정리: AI 에이전트 보안 비상 (2026) (0) | 2026.05.27 |