Scale to Zero — App Spaces (Private Preview)
App Spaces 는 microVM 기반의 새로운 런타임으로, Scale to Zero를 지원합니다. 약 30분간 트래픽이 없으면 자동으로 중지되고, 새 요청이 들어오면 자동 재시작됩니다.주의 현재 상태: App Spaces는 Private Preview 입니다. 기존 앱을 App Spaces로 변환할 수 없으며, 새 앱을 생성해야 합니다. GA 전까지는 아래 “현재 비용 절감 방법”을 참고하세요.
동작 방식
| 상태 | 조건 | 과금 여부 | 응답 시간 |
|---|---|---|---|
| Active | 요청 처리 중 또는 최근 트래픽 있음 | 과금 | 즉시 |
| Idle | 트래픽 없음 (30분 미만) | 과금 | 즉시 |
| Scaled to Zero | 30분간 트래픽 없어 자동 중지 | 비과금 | 콜드 스타트 (수 초~수십 초) |
App Spaces의 현재 제한사항
| 항목 | 상태 |
|---|---|
| 기존 앱 변환 | 불가 — 새 앱 생성 필요 |
| 워크스페이스 Network Policy | 아직 미적용 (SEG, Private Link 미지원) |
| 템플릿 기반 생성 | 미지원 — API로 직접 생성 |
현재 비용 절감 방법 (GA 전까지)
App Spaces GA 전까지는 다음 방법으로 비용을 관리할 수 있습니다: 1. Databricks Jobs로 자동 시작/중지 스케줄링:콜드 스타트 최적화
Scale to Zero에서 앱이 다시 시작될 때 콜드 스타트 시간이 발생합니다. 이를 최소화하는 방법:| 최적화 방법 | 효과 | 설명 |
|---|---|---|
| 경량 의존성 | 시작 시간 단축 | requirements.txt에서 불필요한 패키지 제거 |
| Lazy Loading | 초기 로드 단축 | 무거운 라이브러리는 필요할 때 import |
| Serverless Warehouse | 쿼리 응답 단축 | Classic Warehouse는 콜드 스타트가 길어 추가 지연 발생 |
| 캐싱 | 반복 요청 가속 | st.cache_data, st.cache_resource 활용 |
참고 비용 참고: 실제 운영 사례에서 Medium 사이즈 앱의 월 비용은 약 65/월 로 절감할 수 있습니다.
Horizontal Scaling (수평 스케일링, Private Preview)
단일 컨테이너의 성능 한계를 넘기 위해 최대 5개 인스턴스 로 수평 확장할 수 있습니다.| 항목 | 설명 |
|---|---|
| 상태 | Private Preview |
| 인스턴스 수 | 1~5개 (수동 설정) |
| 세션 친화성 | Stateful session affinity 지원 (업계 최초) |
| 무중단 배포 | Zero-downtime deployments |
| 빌드 캐시 | Deployment build caching |
REST API 설정
주의 기존 앱을 Horizontal Scaling으로 업그레이드할 수 없습니다. 새 앱을 생성해야 합니다. 템플릿 기반 생성도 미지원이며, API를 통해 직접 생성해야 합니다.
Git 기반 배포 (Public Preview)
소스 코드를 수동으로 업로드하는 대신, Git 레포지토리에서 직접 배포 할 수 있습니다.주요 기능
| 기능 | 설명 |
|---|---|
| Git 레퍼런스 | 브랜치, 태그, 커밋 해시 지정 가능 |
| 소스 코드 경로 | 레포 내 특정 디렉토리 지정 가능 |
| 강제 적용 | 워크스페이스 관리자가 Git-only 배포를 강제할 수 있음 |
참고 GitHub Enterprise Managed Users(EMU)의 개인 레포는 OAuth 제한으로 인해 PAT를 대안으로 사용해야 합니다.
앱 텔레메트리 / 모니터링 (Beta)
OpenTelemetry 기반으로 앱의 로그, 스팬, 메트릭을 Unity Catalog에 자동 수집할 수 있습니다.설정 방법
app.yaml에 텔레메트리 설정을 추가하면 앱 코드 변경 없이 자동으로 계측됩니다:
참고 텔레메트리 데이터는 near real-time으로 Unity Catalog 시스템 테이블에 저장됩니다. 앱 성능 모니터링, 오류 추적, 사용 패턴 분석에 활용할 수 있습니다.
uv 의존성 관리 (2026년 3월~)
requirements.txt 대신 uv 를 사용하여 Python 의존성을 관리할 수 있습니다.
참고 uv vs pip: uv는 pip보다 최대 10-100배 빠른 의존성 해결과 설치를 제공합니다.pyproject.toml+uv.lock으로 전환하면 배포 시간이 단축됩니다. 기존requirements.txt도 계속 지원됩니다.
Lakebase (PostgreSQL) 연동
Lakebase 는 Databricks가 관리하는 PostgreSQL 호환 데이터베이스입니다. Databricks Apps에서 OLTP(트랜잭션) 워크로드 를 처리할 때 적합합니다.왜 Lakebase인가?
| 비교 항목 | Unity Catalog 테이블 | Lakebase |
|---|---|---|
| 접근 방식 | SQL Warehouse를 통한 분석 쿼리 | 직접 PostgreSQL 연결 |
| 지연 시간 | 수백 ms~수 초 (Warehouse 오버헤드) | 수 ms~수십 ms |
| 용도 | 분석, 대시보드, 배치 처리 | CRUD, 세션 관리, 실시간 데이터 |
| 트랜잭션 | 제한적 | 완전한 ACID 트랜잭션 |
| 스키마 | Delta Lake (읽기 최적화) | PostgreSQL (쓰기/읽기 균형) |
Lakebase 리소스 설정
app.yaml:필수 패키지
Python 연결 예시
Streamlit + Lakebase 예시
주의 OAuth 토큰 로테이션: Lakebase 연결은 OAuth 역할 인증을 사용하며, 토큰은 1시간 후 만료 됩니다. 장기 실행 앱에서는 자동 토큰 갱신을 구현하거나, 연결 풀에서 주기적으로 연결을 재생성해야 합니다. 토큰이 만료되면 연결이 끊어집니다.
Lakebase 사용 시나리오
| 시나리오 | 왜 Lakebase가 적합한가 |
|---|---|
| 사용자 설정 저장 | 빠른 읽기/쓰기, 세션 간 영속성 |
| 피드백/설문 수집 | ACID 트랜잭션으로 데이터 무결성 보장 |
| 채팅 이력 저장 | 실시간 쓰기, 사용자별 격리 |
| 앱 메타데이터 | 설정, 상태, 캐시 등 앱 내부 데이터 |
| 큐/태스크 관리 | 작업 큐, 상태 추적, 워크플로우 |
참고 Lakebase vs UC 테이블 선택 기준: “앱 내부에서만 사용하는 운영 데이터”는 Lakebase, “분석이나 ML에 활용할 데이터”는 UC 테이블에 저장하세요. 물론 Lakebase의 데이터를 Delta Live Tables(DLT)로 UC 테이블에 동기화하는 것도 가능합니다.
Databricks Asset Bundles (DABs) 배포
Databricks Asset Bundles (DABs) 를 사용하면 앱을 Infrastructure as Code로 관리하고, CI/CD 파이프라인과 통합할 수 있습니다.DABs 프로젝트 구조
databricks.yml 예시
앱 리소스 정의 (resources/my_app.yml)
DABs 배포 명령
DABs의 장점
| 장점 | 설명 |
|---|---|
| 환경 분리 | targets로 dev/staging/prod 환경을 코드로 관리 |
| 변수 치환 | ${var.warehouse_id}로 환경별 설정 자동 적용 |
| CI/CD 통합 | GitHub Actions, Azure DevOps 등과 자연스러운 연동 |
| 버전 관리 | Git으로 인프라 설정 포함 전체 이력 관리 |
| 권한 관리 | permissions로 앱 접근 권한을 코드로 선언 |
참고
DABs vs CLI 직접 배포: 소규모 프로젝트나 프로토타이핑에서는 databricks apps deploy CLI가 더 빠릅니다. 프로덕션 환경이나 여러 환경에 배포하는 경우에는 DABs가 훨씬 효율적입니다.
AppKit (React + TypeScript 프레임워크)
AppKit 은 Databricks가 공식으로 제공하는 React + TypeScript 기반 풀스택 프레임워크입니다. 타입 안전한 SQL 쿼리, 내장 차트/테이블 컴포넌트, tRPC 기반 API를 제공합니다.AppKit vs 다른 프레임워크
| 비교 항목 | Streamlit | AppKit (React) |
|---|---|---|
| 언어 | Python | TypeScript/React |
| UI 커스터마이징 | 제한적 (위젯 기반) | 완전한 자유도 (컴포넌트 기반) |
| 타입 안전성 | 없음 | SQL 쿼리 결과까지 타입 자동 생성 |
| 차트 | Streamlit 내장 | ECharts 기반 (고성능) |
| API 레이어 | 없음 | tRPC (타입 안전 RPC) |
| 빌드 | 불필요 | Vite 기반 빌드 |
| 학습 곡선 | 낮음 | 중간~높음 |
| 적합 대상 | 빠른 프로토타입, 데이터 앱 | 프로덕션 SPA, 복잡한 UI |
AppKit 프로젝트 생성
AppKit 프로젝트 구조
SQL 쿼리 + 차트 연동
1. SQL 쿼리 파일 작성:tRPC로 Model Serving 호출
AppKit 배포
주의
AppKit 개발 워크플로우: 반드시 SQL 파일 작성 → npm run typegen → App.tsx 작성 순서를 지켜야 합니다. 타입 생성 전에 UI 코드를 작성하면 컴파일 에러가 발생합니다.
Node.js/React 앱 (수동 구성)
AppKit을 사용하지 않고 Node.js/React 앱을 직접 구성할 수도 있습니다.프로젝트 구조
app.yaml (Node.js)
package.json
server.js (Express)
참고 AppKit vs 수동 구성: AppKit은 SQL 타입 생성, 내장 차트, tRPC 등을 제공하므로 새 프로젝트에서는 AppKit을 권장합니다. 기존 React 앱을 마이그레이션하거나 특수한 요구사항이 있는 경우에만 수동 구성을 사용하세요.