서론

샌프란시스코에서 개최된 Data + AI Summit 2026의 2일차 Keynote를 현장에서 직접 보고 왔습니다. 첫날의 Genie Ontology에 대해서는 지난 기사에 작성했으므로, 이번에는 그 후속 편입니다.

Data + AI Summit 2026 の会場（サンフランシスコ Moscone Center）

2일차에도 업데이트 내용은 다방면에 걸쳐 있었지만, 제가 가장 열광했던 것은 Genie App Builder였습니다. 이유는 단순합니다. 제가 평소에 맞닥뜨리고 있는 "대시보드와 자체 개발 앱의 번거로움"을 정면으로 해결해 줄 것 같았기 때문입니다.

이 기사에서는 먼저 2일차 Keynote의 전체적인 모습을 간단히 짚어보고, 이어서 Genie App Builder를 심층적으로 살펴보겠습니다.

※ 수치 및 명칭은 키노트 내용과 공식 블로그를 통해 확인된 범위로 한정하며, 저의 해석은 "소감"으로 구분하여 작성합니다.

2일차 Keynote의 전체상

2일차는 "개발자용(developers)"이 큰 테마였습니다. 첫날이 Genie를 통해 "AI를 사용하는" 측이었다면, 2일차는 "AI로 만드는" 측이라는 정리입니다.

Data + AI Platform の全体像（Context / Control / Cost / Choice）

현장에서 제시된 플랫폼 전체 구조도가 이것입니다. 본 기사의 Genie App Builder는 이 그림에서 Genie 패밀리(ONE / AGENTS / CODE / APP BUILDER / ZERO OPS) 중 하나로 나열되어 있습니다.

발표 내용을 대략적으로 나열하면 다음과 같습니다.

Omnigent— 여러 에이전트 하네스(Agent Harness)(Claude Code, Codex 등) 위에 올라가는 "메타 하네스(Meta-harness)". 오픈 소스로 공개되었습니다. Matei Zaharia가 등단하여 소개했습니다. -
Agent Bricks + Unity AI Gateway— 에이전트 개발 플랫폼. 모델 선택지, 컨텍스트, 비용·보안 제어(예산 상한, 인텔리전트 라우팅, 트레이싱)를 통합하여 제공합니다. -
Apps / Genie App Builder— 본 기사의 주인공. 엔터프라이즈 앱을 "vibe coding"으로 만들기 위한 메커니즘입니다. -
Genie Code for ML / Genie ZeroOps for ML— 머신러닝(ML) 파이프라인의 구축 및 운용을 에이전트가 수행합니다. ZeroOps는 장애 원인 특정부터 수정 제안까지 자율적으로 진행합니다. -
Lakewatch + Panther— 보안 Lakehouse. Panther 인수 발표도 있었습니다. -
Customer Lake— CDP(Customer Data Platform). campaign agents를 통해 개개인에게 전달 판단을 수행하는 데모가 있었습니다.

전체를 관통하는 메시지는 첫날과 마찬가지로 "any data / any model / any harness를 거버넌스와 비용 제어가 작동하는 하나의 장소에서"였습니다. 그중에서 이번에는 Genie App Builder에 집중하겠습니다.

왜 Genie App Builder에 주목했는가

제가 여기에 관심을 가진 이유는 평소 업무에서 다음 세 가지 문제로 어려움을 겪고 있었기 때문입니다.

기존 대시보드는 표현의 제약이 많다. 표준 대시보드에 준비된 위젯 범위를 넘어선 시각화(지도 위의 히트맵이나 독자적인 인터랙션)를 하려고 하면 갑자기 어려워집니다. -
AI에게 대시보드를 만들게 해도 잘 되지 않는다. 쿼리는 작성할 수 있어도, 생성물의 품질 체크(의도대로 표시되는지, 망가지지 않았는지)에 시간이 걸립니다. 대시보드 정의(JSON) 생성은 오류가 나기 쉽고, 디자인을 포함하여 "그대로 사용할 수 있는" 수준까지 가져가는 데 재작업이 많습니다. -
Databricks Apps는 유휴 시간에도 비용이 발생한다. 상시 기동을 전제로 하면, 한 달에 몇 번밖에 사용하지 않는 경량 앱을 위해 계속해서 캐파시티(Capacity)를 확보해야 합니다.

Genie App Builder와 이를 뒷받침하는 Genie Ontology(첫날 이야기)·Serverless Micro Apps는 이 세 가지 문제에 각각 대응해 왔다는 것이 저의 견해입니다.

Genie App Builder란

현장 슬라이드에서 Genie App Builder는 **"Vibe coding that understands your business(당신의 비즈니스를 이해한 vibe coding)"**라고 소개되었으며, 세 가지 기둥이 제시되었습니다.

Genie App Builder の発表スライド

• Context-aware (문맥 인식) — Genie Ontology를 활용하여 의미(Semantics)를 이해한 상태에서 vibe coding을 수행한다.
• Embedded (내장형) — 100% Databricks 관리형 스택으로 구성되어, 데이터의 보안과 거버넌스(Governance)를 보장한다.
• Production-quality by default (기본적인 프로덕션 품질) — AppKit SDK와 커스텀 스킬(Custom Skills)을 통해, 처음부터 프로덕션 품질의 앱을 생성한다.

작동 방식은 공식 블로그에 다음과 같이 기술되어 있습니다. 사용자가 "만들고 싶은 것을 말로 설명하거나 스크린샷을 전달"하면, 생성된 플랜을 확인하면서 사이드 페인의 라이브 프리뷰(Live Preview)를 통해 앱이 업데이트되는 것을 보며 반복(Iteration)해 나가는 흐름입니다.

실제 에디터 화면은 다음과 같습니다. 왼쪽은 에이전트와의 상호작용(배포 절차 및 파일 편집 로그)이며, 오른쪽은 라이브 프리뷰로, samples.nyctaxi.trips를 사용한 NYC 택시 히트맵(Heatmap) 앱이 구동되고 있습니다.

Genie App Builder のエディタ画面

사실 현장에서 직접 찍고 싶었지만, 발표에 너무 몰입한 나머지 중요한 화면을 놓치고 말았습니다... 공식 블로그에서 가져왔습니다.

이 "지도 위의 히트맵"이라는 것이 상징적인데, 표준 대시보드의 위젯만으로 만들려고 하면 번거로운 종류의 시각화입니다. 그것을 데이터와 연결된 프로덕션 앱으로서 생성할 수 있다는 점이 명확한 차이점이라고 느꼈습니다.

과제는 어떻게 해결되었는가

서두에서 언급한 세 가지 문제점에 대해 각각 어떻게 효과를 발휘하는지 정리해 보겠습니다.

1. 표현의 제약 → 대시보드가 아닌 "앱"을 생성한다

Genie App Builder가 만드는 것은 대시보드 위젯의 집합이 아니라, 프론트엔드를 갖춘 웹 앱 그 자체입니다. 위의 히트맵처럼 표준 대시보드로는 표현하기 어려운 것도 코드 기반의 앱으로 만들 수 있습니다. 생성된 앱은 Python / JavaScript 및 주요 앱 프레임워크를 지원하며(키노트 내용), 표현의 한계가 "대시보드의 사양"에서 "앱으로 작성할 수 있는 범위"로 확장됩니다.

2. AI 생성의 불안정성 → 컨텍스트와 SDK로 "프로덕션 품질"을 보장한다

이 부분이 가장 핵심적인 포인트라고 생각합니다. AI에게 대시보드 정의나 앱을 "날것(Raw)" 상태로 쓰게 하면, (a) 어떤 데이터를 사용해야 할지 몰라 엉뚱한 결과를 내놓거나, (b) 생성물의 구조가 깨지는 두 가지 이유로 실패하기 쉽습니다. Genie App Builder는 이 두 가지 모두를 해결합니다.

• (a) 데이터 오용 → Context-aware (Genie Ontology). 공식 블로그에 따르면, Genie App Builder는 Databricks 상에 구축되어 있어 워크스페이스를 직접 인식합니다. "어떤 테이블이 있는지, Unity Catalog에 정의된 시맨틱 레이어(Semantic Layer), 이미 적용된 거버넌스 정책"을 파악하고 있으므로, 프롬프트로 만들고 싶은 것을 설명하면 빌더가 적절한 데이터를 찾아 앱에 반영해 줍니다. 수동으로 연결할 필요가 없다는 설명이었습니다. 첫째 날 언급된 Genie Ontology가 여기서 "의미의 지도"로서 역할을 합니다.
• (b) 생성물 파손 → AppKit SDK + 커스텀 스킬. AppKit은 프로덕션용으로 설계된 TypeScript SDK로, 공식 블로그에 따르면 "캐시, 텔레메트리(Telemetry), 재시도 처리, Databricks 내의 데이터 및 리소스와의 통합"을 처음부터 관리해 줍니다. 생성의 베이스를 이 SDK로 고정하고, 베스트 프랙티스를 커스텀 스킬로組み込む(組み込む, 포함)함으로써 출력이 "처음부터 프로덕션 품질"에 가깝게 나오도록 설계되었습니다.

즉, "AI에게 자유롭게 쓰게 하는 것"이 아니라, "컨텍스트(Ontology)를 통해 올바른 데이터로 유도하고, SDK와 스킬을 통해 구조를 보장한다"는 것입니다. 생성물의 품질을 모델의 지능에만 맡기지 않고 시스템 측면에서 끌어올렸다는 점이 저에게는 인상 깊었습니다.

3. 유휴 비용(Idle Cost) → Serverless Micro Apps

Databricks Apps의 비용 측면에는 새로운 아키텍처인 Serverless Micro Apps가 마련되었습니다. 키노트와 공식 블로그의 설명을 종합하면,

• 각 앱이 경량 가상 머신 (micro-VM) 위에서 동작하며, 필요할 때 빠르게 시작되고 유휴 시에는 제로까지 스케일 다운 (dynamic scale to zero) 합니다. - 리소스는 분할된 (fractional) CPU / 메모리로 할당됩니다. - 시작 속도가 빠르며 (키노트에서는 "초 단위"라고 표현), 공유 인프라에서도 **micro-VM을 통한 커널 수준의 격리 (kernel-level isolation)**를 유지합니다.

공식 블로그의 표현을 빌리자면, 경량 앱의 배포가 "예약 용량 과금이 아니라, 사용한 만큼 (usage-based)" 된다는 의미입니다. 한 달에 몇 번밖에 사용하지 않는 사내용 앱을 위해 상시 용량을 확보해 두어야 한다는 전제가 깨지므로, "일단 만들어 두고 보자"라는 진입 장벽이 낮아집니다.

App Spaces: 거버넌스를 일괄 적용하기

또 하나, 눈에 띄지는 않지만 중요한 것이 App Spaces라는 거버넌스 단위입니다. 공식 블로그에 따르면, 관리자가 스페이스 단위로 "리소스 및 데이터에 대한 액세스, on-behalf-of-user의 API 스코프, 보안 정책"을 정의하면, 해당 스페이스 내의 모든 앱이 설정을 자동으로 상속받습니다. 앱을 하나씩 사후 검토하는 것이 아니라, 빌더가 작업할 수 있는 "승인된 환경"을 미리 준비해 두는 방식입니다.

데모에서도 이 부분이 효과적으로 작동하고 있었는데, 스페이스에 설정되지 않은 Slack 커넥터는 사용할 수 없고, 공유 범위도 스페이스에서 허가된 그룹으로 제한되며, 권한이 없는 운영 데이터는 그 자리에서 관리자에게 신청해야 하는 동작을 보여주었습니다. 생성의 자유도와 통제가 양립하고 있음을 알 수 있는 장면이었습니다.

소감

여기서부터는 제 개인적인 소감입니다.

Genie App Builder에서 가장 효과적이라고 느낀 점은 새로운 UI 그 자체보다도, 토대가 되는 Genie Ontology와 Serverless Micro Apps였습니다.

온톨로지 (Ontology)에 대해서는 지난번에도 썼듯이, 에이전트의 정확도와 비용은 "올바른 컨텍스트 (context)를 어떻게 전달하느냐"에 따라 결정됩니다. 앱 생성이라는 맥락으로 바꾸어 말하면, 이는 "AI가 어떤 데이터를 사용해야 하는지 알고 있는가"와 직결됩니다. 지금까지 제가 AI에게 대시보드나 앱을 만들게 했을 때 잘 되지 않았던 원인의 대부분은, 결국 "데이터의 의미를 모르는 상태에서 쓰게 했기" 때문이었습니다. 의미의 계층을 먼저 정비하고, 생성이 이를 참조하도록 하는 순서가 본질적이라고 생각합니다.

그리고 Serverless Micro Apps. 표현력이나 생성 품질이 아무리 높아져도, "유휴 상태에서도 과금된다"면 결국 "만들고 버려지는 가벼운 앱"은 태어나기 어렵습니다. 제로 스케일 (zero-scale)과 초 단위의 시작으로 인해 이것이 사용량 기반 (usage-based)으로 바뀌면, 대시보드에서 소모되던 표현들을 부담 없이 앱 쪽으로 옮길 수 있게 됩니다. 저에게는 이 부분이 가장 현실적인 변화였습니다.

정리하자면, 표현의 한계 돌파 (앱화) · 생성의 안정성 (Ontology + AppKit) · 비용 (Serverless Micro Apps) · 통제 (App Spaces)가 동시에 움직였다는 것이 2일 차의 가장 큰 수확이었습니다.

Discussion