Databricks Apps 완벽 가이드

Databricks 플랫폼 위에서 데이터 & AI 애플리케이션을 직접 호스팅하고 배포하는 Databricks Apps의 실전 가이드

---

​

Databricks Apps란?

Databricks Apps는 Databricks 인프라 위에서 직접 데이터 및 AI 애플리케이션을 개발, 배포, 호스팅 할 수 있는 플랫폼 기능입니다. 별도의 서버나 클라우드 인프라를 구성할 필요 없이, 서버리스 환경에서 앱이 실행됩니다. 기존에 Databricks 데이터를 외부 앱에서 사용하려면 별도의 웹 서버를 프로비저닝하고, 인증을 설정하고, 네트워크를 구성해야 했습니다. Databricks Apps는 이 모든 인프라 복잡성을 제거하고, 코드만 작성하면 즉시 배포 할 수 있는 환경을 제공합니다.

---

​

왜 Databricks Apps인가? 기존 배포 방식과의 비교

데이터 팀이 웹 앱을 만들어야 할 때, 전통적으로는 클라우드 인프라를 직접 구성해야 했습니다. EC2 인스턴스를 프로비저닝하고, 보안 그룹을 설정하고, SSL 인증서를 발급받고, 로드 밸런서를 구성하고, Databricks API 인증 토큰을 관리 하는 등의 작업이 필요했습니다. 이 과정에서 데이터 엔지니어가 인프라 엔지니어의 역할까지 맡게 되는 상황이 빈번하게 발생합니다. Databricks Apps는 이러한 인프라 복잡성을 완전히 제거합니다. 아래 표는 기존 배포 방식과 Databricks Apps의 차이를 비교합니다.

참고 핵심 차별점: Databricks Apps의 가장 큰 장점은 인프라가 아니라 Databricks 생태계와의 네이티브 통합 입니다. Unity Catalog 거버넌스가 자동으로 적용되고, 서비스 프린시펄이 자동 생성되며, SQL Warehouse와 Model Serving에 별도 인증 없이 접근할 수 있습니다. 일반적인 PaaS가 “서버 관리 불필요”를 제공한다면, Databricks Apps는 “데이터 플랫폼 인증과 거버넌스 관리 불필요”를 제공합니다.

---

​

주요 특징

아래 표는 Databricks Apps의 핵심 기능을 정리합니다. 각 특징이 실무에서 어떤 의미를 갖는지 함께 설명합니다. 이 특징들의 조합이 의미하는 바는 명확합니다. 데이터 엔지니어나 데이터 사이언티스트가 인프라 전문 지식 없이도 프로덕션 수준의 웹 앱을 배포 할 수 있다는 것입니다. 기존에는 “앱을 만들고 싶다”는 요구에 “DevOps 팀에 티켓을 올려야 한다”로 답해야 했지만, 이제는 코드만 작성하면 됩니다.

---

​

아키텍처: 컨테이너 기반 서버리스 실행

Databricks Apps는 컨테이너화된 서버리스 서비스 로 실행됩니다. 이 아키텍처를 이해하면 앱의 동작 방식, 제약 사항, 성능 특성을 예측할 수 있습니다. 핵심 아키텍처 특성:

• 전용 컴퓨트 리소스, 네트워크 분리, 저장/전송 암호화 적용
• 서버리스 컴퓨트와 동일한 격리 계층(isolation layer)에서 동작
• 컨트롤 플레인 서비스로서 데이터 플레인 서비스에 접근
• 앱 간 완전한 네트워크 격리 보장

참고 아키텍처가 의미하는 것: 앱이 컨트롤 플레인 내부 에서 실행된다는 것은 중요한 의미를 갖습니다. 첫째, 데이터 플레인(고객 VPC)에 있는 리소스에 접근할 때 Databricks의 내부 네트워크를 통하므로 퍼블릭 인터넷을 거치지 않습니다. 둘째, 각 앱은 독립된 Kubernetes 네임스페이스에서 실행되어 다른 앱의 트래픽이나 장애에 영향을 받지 않습니다. 셋째, 서버리스 컴퓨트와 동일한 보안 격리 수준이 적용되므로 엔터프라이즈 보안 요구사항을 충족합니다.

---

​

서비스 프린시펄 자동 생성 동작 방식

앱 생성 시 Databricks가 전용 서비스 프린시펄(SP) 을 자동으로 생성합니다. 이 SP가 앱의 영구적인 아이덴티티로 동작합니다. 이 자동 생성 메커니즘이 왜 중요한지 이해하려면, 기존 방식을 먼저 떠올려 보세요. 일반적으로 외부 앱에서 Databricks에 접근하려면 개인 액세스 토큰(PAT) 을 생성하고, 이를 환경변수나 Secret Manager에 저장하고, 주기적으로 로테이션해야 합니다. PAT는 특정 사용자에게 귀속되므로 그 사용자가 퇴사하면 토큰이 무효화됩니다. 서비스 프린시펄은 이러한 문제를 근본적으로 해결합니다. 이 표에서 전용 이라는 특성이 특히 중요합니다. 각 앱이 독립된 SP를 가지므로, 한 앱의 권한 변경이 다른 앱에 영향을 주지 않습니다. 또한 앱 삭제 시 SP가 함께 삭제되므로 “더 이상 사용하지 않는데 권한만 남아있는” 고아 서비스 계정 문제가 발생하지 않습니다.

주의 중요: 앱의 서비스 프린시펄에 필요한 권한을 반드시 부여해야 합니다. 예를 들어 앱에서 UC 테이블을 조회하려면 해당 SP에 SELECT 권한을, SQL Warehouse를 사용하려면 CAN USE 권한을 부여해야 합니다.

참고 SP 권한 부여 방법: 앱 생성 후 Overview 페이지에서 SP 이름을 확인할 수 있습니다. 이 SP에 Unity Catalog 권한을 부여하는 SQL은 다음과 같습니다: GRANT SELECT ON TABLE catalog.schema.table TO <sp-application-id>. SQL Warehouse 접근 권한은 Warehouse 설정 UI에서 해당 SP를 추가하면 됩니다.

---

​

앱 상태 라이프사이클

앱은 다음 상태를 거칩니다. 각 상태의 의미와 전이 조건을 정확히 이해하면, 운영 중 발생하는 상황에 빠르게 대응할 수 있습니다. 상태 전이 흐름:

• 생성→ Deploying → Running (정상 실행)
• Running ↔ Stopped (수동 중지/재시작)
• Running → Crashed (오류 발생) → 코드 수정 후 재배포 → Deploying → Running

각 상태에서 알아야 할 핵심 사항이 있습니다. Deploying 상태에서도 과금이 발생한다는 점에 주의하세요. 의존성 설치에 시간이 오래 걸리면(예: 대용량 ML 라이브러리) 배포 비용이 증가합니다. Running 상태에서는 실제 트래픽이 없더라도 과금됩니다. 이는 컨테이너가 항상 대기 상태로 유지되기 때문입니다. Crashed 상태에서는 자동 복구가 되지 않으므로, 로그를 확인하고 코드를 수정한 뒤 재배포해야 합니다.

주의 인메모리 상태는 재시작 시 초기화됩니다. 영속적 데이터는 Unity Catalog 테이블, Volume, 또는 Lakebase를 사용하세요.

참고 비용 절감 팁: 사용하지 않는 앱은 Stopped 상태로 전환하세요. Running 상태에서는 트래픽이 없더라도 DBU가 과금됩니다. 개발/테스트 앱은 업무 시간 외에 자동으로 중지하는 스크립트를 구성하면 비용을 크게 절감할 수 있습니다.

---

​

언제 Databricks Apps를 쓰고, 언제 안 쓰는가

모든 도구에는 적합한 사용 사례가 있습니다. Databricks Apps가 빛을 발하는 상황과 다른 솔루션이 더 나은 상황을 구분하는 것이 중요합니다.

​

적합한 사용 사례

​

부적합한 사용 사례

주의 판단 기준: “이 앱의 사용자가 Databricks 워크스페이스에 접근할 수 있는가?”가 첫 번째 판단 기준입니다. 외부 고객이나 Databricks 계정이 없는 사용자가 접근해야 한다면, Databricks Apps는 적합하지 않습니다.

---

​

지원 프레임워크별 장단점 비교

프레임워크 선택은 앱의 목적에 따라 달라집니다. 아래 표는 각 프레임워크의 특성을 정리하여 선택 기준을 제공합니다.

​

Python 프레임워크

​

Node.js 프레임워크

기본 실행 커맨드: Python 앱은 python <my-app.py>, Node.js 앱은 npm run start

참고 프레임워크 선택 가이드: 처음 시작한다면 Streamlit 을 추천합니다. 가장 적은 코드로 가장 빠르게 결과물을 만들 수 있습니다. AI/ML 모델 데모가 목적이라면 Gradio 의 챗봇 UI가 최적입니다. 외부 시스템과 API 연동이 필요하다면 FastAPI 의 자동 문서 생성(Swagger UI)이 큰 도움이 됩니다.

---

​

활용 사례 5가지

​

1. 인터랙티브 대시보드

Streamlit/Dash로 실시간 데이터 시각화. SQL Warehouse에서 데이터를 조회하여 차트와 필터를 제공합니다.

​

2. RAG 챗봇 UI

Gradio로 검색 증강 생성 AI 챗 인터페이스를 구축합니다. Model Serving 엔드포인트를 호출하여 대화형 AI를 제공합니다.

​

3. 데이터 입력 폼

현업 사용자가 직접 데이터를 입력/수정할 수 있는 폼을 제공합니다. 입력된 데이터는 Unity Catalog 테이블에 저장됩니다.

​

4. ML 모델 서빙 UI

Model Serving 엔드포인트를 감싸는 웹 인터페이스를 제공합니다. 사용자가 입력값을 넣으면 예측 결과를 시각화합니다.

​

5. REST API 게이트웨이

FastAPI/Flask로 데이터 파이프라인 트리거 또는 조회 API를 제공합니다. 외부 시스템과의 통합 지점으로 활용합니다.

---

​

비용 구조와 최적화

Databricks Apps의 비용은 DBU(Databricks Unit) 기반으로 과금됩니다. 비용을 정확히 이해하고 최적화하는 것은 프로덕션 운영에서 필수적입니다.

참고 비용 최적화 전략:

1. 개발/테스트 앱은 사용하지 않을 때 반드시 중지 하세요. Running 상태에서는 트래픽이 없어도 과금됩니다.
2. Medium 사이즈로 시작 하세요. 성능 문제가 실제로 발생한 후에 Large로 업그레이드해도 늦지 않습니다.
3. CI/CD로 자동 중지/시작 스케줄 을 구성하세요. 예: 퇴근 시간에 자동 중지, 출근 시간에 자동 시작.
4. SQL Warehouse는 Serverless를 사용 하세요. Classic Warehouse는 항상 켜져 있어야 하지만, Serverless는 쿼리가 없으면 자동 중지됩니다.

---

​

제한 사항

아래 표는 Databricks Apps의 기술적 제한 사항을 정리합니다. 앱을 설계하기 전에 반드시 확인하여 나중에 아키텍처를 변경해야 하는 상황을 방지하세요.

주의 실무에서 가장 자주 겪는 제한: 파일 크기 10MB 제한은 ML 모델 가중치 파일이나 대용량 데이터셋을 앱에 포함시킬 수 없음을 의미합니다. 이런 파일은 Unity Catalog Volume 에 업로드하고, 앱 시작 시 런타임에 다운로드하는 패턴을 사용하세요. 인메모리 상태 초기화는 세션 데이터, 캐시 등을 앱 프로세스 메모리에 저장하면 안 된다는 의미입니다. Lakebase(PostgreSQL 호환)나 UC 테이블을 영속 저장소로 사용하세요.

---

​

보안 베스트 프랙티스

보안은 앱 개발의 모든 단계에서 고려해야 합니다. 아래 원칙들은 단순한 권장사항이 아니라, Databricks 환경에서 반드시 준수해야 할 필수 사항입니다.

1. PAT 하드코딩 금지— 절대로 개인 액세스 토큰을 코드에 직접 넣지 마세요. 자동 주입되는 서비스 프린시펄 인증을 사용하세요.
2. 최소 권한 원칙— 앱에 필요한 최소한의 권한만 부여하세요.
3. 시크릿은 리소스로 관리— valueFrom을 사용하여 런타임에 안전하게 주입하세요.
4. 앱 간 자격 증명 공유 금지— 각 앱은 독립적인 서비스 프린시펄을 사용합니다.
5. 코드 리뷰 시 스코프와 권한 정합성 검증
6. 프로덕션 배포 전 피어 리뷰 필수
7. 사용자 액션에 대한 구조화된 감사 로그 기록

주의 가장 흔한 보안 실수: PAT를 app.yaml의 value 필드에 직접 넣는 것입니다. 이 파일은 Git 리포지토리에 커밋되므로 토큰이 노출됩니다. 반드시 Secret 리소스와 valueFrom을 사용하세요.

---

​

개발 베스트 프랙티스

1. 로컬 테스트 먼저— databricks apps run-local로 배포 전 검증
2. 리소스 하드코딩 금지— valueFrom을 사용하여 환경 간 이식성 확보
3. 상태는 외부 저장소에— Unity Catalog, Volume, Lakebase 사용
4. 의존성 버전 명시— requirements.txt에 버전을 명시하여 재현 가능한 빌드
5. 에러 핸들링— 연결 실패, 권한 오류 등에 대한 적절한 에러 처리
6. Medium 사이즈로 시작— 성능 이슈가 확인될 때만 Large로 업그레이드

---

​

참고 자료

• Databricks Apps 공식 문서
• 앱 개발 가이드
• 인증 설정
• 리소스 설정
• Streamlit 튜토리얼
• 앱 런타임 설정 (app.yaml)
• 컴퓨트 사이즈
• 환경 변수