같은 영업 비서가 지역 관리자와 전국 책임자에게 답하더라도 같은 회사 데이터를 보여 줄 필요는 없다. 어려운 부분은 요청이 화면을 떠나 SQL, 모델 호출, 에이전트 도구 작업이 된 뒤에도 그 구분을 유지하는 것이다.
Databricks는 18개월 이상 공개 프리뷰를 거쳐 2026년 10월 7일 Apps 사용자 권한 부여를 정식 출시했다. OBO(on-behalf-of-user)는 모든 작업을 앱의 서비스 주체로 처리하는 대신 지원 요청을 로그인한 사람의 신원으로 실행한다. 기존 Unity Catalog 통제가 사람을 따라 요청에 적용된다. 중복 정책 코드를 실질적으로 줄이지만 위임만으로 앱이 자동으로 안전해진다는 약속은 아니다.
앱 신원을 대체하지 않고 두 번째 경로를 제공한다
Databricks Apps는 서버리스 기반에서 데이터 앱, 대시보드, 운영 도구, 맞춤형 에이전트를 실행한다. 배포 앱마다 전용 서비스 주체가 생긴다. 해당 인스턴스에 부여된 권한을 가진 비인간 신원이다. 공유 설정, 텔레메트리, 유지 관리, 자동화 작업에는 이 앱 권한 부여가 계속 유용하다.
사용자 권한 부여는 별도 경로를 더한다. 인증된 사람이 지원 작업을 시작하면 Databricks가 런타임에 접근 토큰을 전달하고 앱은 사용자 권한으로 승인된 API를 호출한다. OAuth 2.0 모델은 사용자-머신 위임과 머신-머신 작업을 구별한다.
거버넌스 데이터에 대해서는 Unity Catalog가 기존 권한, 행 필터, 열 마스크를 평가한다. 웨어하우스 권한은 요청 쿼리 실행 가능 여부도 별도로 결정한다. 같은 앱 경로에서 지역 관리자는 한 지역만, 전국 책임자는 더 넓은 범위를 볼 수 있다. 이후 요청은 앱이 따로 보관한 복사본이 아니라 갱신된 카탈로그 정책을 따른다.
이는 흔한 정책 불일치를 줄인다. 공유 앱 신원은 백엔드에 하나의 권한 집합을 제시하고, 개발자는 역할·매핑·미들웨어·별도 정책 서비스로 직원별 결과를 다시 나눈다. 이러한 통제도 작동할 수 있지만 카탈로그만 바뀌고 로컬 매핑이 그대로라면 정보 노출이나 정당한 접근 거부가 발생한다.
Apps OBO 공개 프리뷰는 2025년 3월 26일 시작됐으며 Unity Catalog 테이블과 모델 서빙 엔드포인트 등이 포함됐다. 정식 출시는 문서화된 제한 내에서 프로덕션 준비를 뜻한다. 모든 클라우드, 리전, 워크스페이스, 규정 준수 프로필, 다운스트림 API 지원을 뜻하지 않는다. 원문은 규정 준수 보안 프로필 워크스페이스에 대한 2026년 9월 말 제공 예정도 언급하지만 고객은 자신의 환경을 확인해야 한다.
앱은 자체 신원으로 공유 지침을 읽고 지표를 기록한 뒤 현재 사용자 신원으로 고객·영업 기록을 조회할 수 있다. 인증은 누가 있는지, 권한 부여는 그 신원이 후속 서비스에서 무엇을 할 수 있는지 결정한다. 둘을 혼동하면 이번 변화의 핵심을 놓친다.
사용자 권한과 앱 스코프가 모두 충족되어야 한다
앱이 요청한다고 사용자가 테이블이나 웨어하우스에 접근할 수 있는 것은 아니다. 이미 필요한 리소스 권한을 보유해야 한다. 동시에 개발자는 앱이 사용자를 대신해 수행할 작업 종류를 제한하는 API 스코프를 선언한다.
두 개의 별도 경계다. 스코프는 새 데이터 권한을 만들지 않고 기존 접근의 사용을 제한한다. Databricks는 읽기 전용 SQL 분석용 sql:restricted-query를 문서화한다. 광범위한 웨어하우스 관리나 무관한 관리 작업 권한 없이 현재 사용자로 제한된 쿼리를 실행한다.
이는 권한이 높은 사용자에게 특히 중요하다. 임원이나 관리자가 여러 민감한 데이터셋을 정당하게 볼 수 있어도 좁은 스코프의 앱이 그 사람의 모든 기능을 상속해서는 안 된다. 사용자 접근이 넓어도 앱의 실행 작업은 제한된다.
워크스페이스 관리자는 개발자가 추가할 스코프의 상한도 정한다. 허용 목록은 전체 지원 API, 선택한 스코프, 사용자 권한 부여 없음으로 설정할 수 있다. 발표에 따르면 기본값은 모든 지원 API를 포함할 수 있으므로 엄격한 기본 통제의 증거가 아니라 거버넌스 선택이다.
이 상한에는 중요한 예외가 있다. 계정 관리자는 워크스페이스 허용 목록에서 제외한 스코프도 추가할 수 있다. 이전에 허용한 스코프를 제거해도 기존 앱이 즉시 중단되지는 않는다. 계속 실행할 수 있지만 금지된 스코프를 없애기 전까지 이후 시작·배포·업데이트는 할 수 없다.
따라서 허용 목록 변경은 실행 중인 모든 사용을 즉시 취소하는 것과 다르다. 관리자는 배포 앱 목록, 스코프 책임자, 업무 의존성을 파악해 전환을 이해하고 다음 배포의 갑작스러운 차단을 피해야 한다. 제한된 기준과 기록된 예외 절차가 설정만으로 통제가 끝난다는 가정보다 유용하다.
토큰은 에이전트 전체가 아니라 요청에 속한다
앱은 사용자 범위와 앱 범위 클라이언트를 구분해야 한다. 거버넌스 대화형 쿼리는 사용자 경로로, 공유 설정과 사용자 세션 없이 계속되는 일은 적절히 제한한 앱 경로로 처리한다. 주체를 숨기는 범용 클라이언트보다 의존성과 핸들러를 분리하면 자격 증명 오용을 발견하기 쉽다.
사용자 권한 부여가 필요한 경로에서 전달 토큰이 없으면 요청을 거부해야 한다. 서비스 주체로 조용히 폴백하면 전혀 다른, 예상보다 넓거나 좁은 권한으로 기술적으로 유효한 답변을 만들 수 있다. 사용자는 신원 변경을 알아차리지 못할 수 있다.
전달 토큰을 출력·로그 기록·영구 저장해서는 안 된다. Apps에 배포한 맞춤형 에이전트는 활성 invoke 또는 stream 핸들러 안에서 사용자 범위 워크스페이스 클라이언트를 초기화해야 한다고 Databricks는 설명한다. 토큰은 요청 실행 중에만 존재하고 전역 앱 시작 시점의 상태가 아니다.
한 에이전트 프로세스는 여러 사람을 처리한다. 사용자 신원을 전역 상태로 두면 요청 컨텍스트가 사라지거나 섞일 위험이 있다. 앱 신원으로 공유 지침을 검색하고, 사용자로 재무 데이터를 조회하며, 다시 앱으로 일반 텔레메트리를 기록하는 흐름에서도 사용자 자격 증명을 남기지 않아야 한다. 매 전환에 명확한 주체와 스코프가 필요하다.
장기 실행이나 지연 작업도 별도 경계다. 사용자가 시작한 작업이 요청보다 오래 지속되어도 전달 토큰을 저장할 근거는 아니다. 앱 소유 작업은 제한된 서비스 주체를 사용하고, 사용자 컨텍스트가 필요하면 자격 증명 보관 대신 문서화된 다른 위임 패턴을 따라야 한다.
OBO가 모든 외부 통합으로 자동 전달되는 것도 아니다. 다운스트림이 모델을 지원해야 하며 별도 자격 증명, 동의, 스코프, 감사 통제가 필요할 수 있다. 토큰에는 특정 대상과 목적이 있다. Microsoft OBO 지침도 중간 계층 토큰을 의도하지 않은 수신자에게 전달하지 말라고 경고한다. 이는 전체 도구 체인의 무제한 가장이 아니라 경계가 있는 위임이다.
앱을 열 수 있어도 데이터 접근권은 별개다
Databricks Apps는 익명 공개 앱 모델이 아니다. 사용자는 인증해야 하고 외부 협업자는 지원되는 신원 페더레이션을 통해 온보딩해야 한다. 관리형 직원·파트너 신원이 자연스러운 대상이지 무제한 익명 방문자가 아니다.
CAN USE와 CAN MANAGE는 앱 실행·관리 권한을 정할 뿐 하위 테이블, 레코드, 웨어하우스 접근권을 주지 않는다. 앱을 열 수 있어도 데이터 응답이 거부되거나 제한될 수 있다. 반대로 테이블 권한만으로 앱을 열 수 있다고 보장되지 않는다.
이 통제는 Unity Catalog 권한과 별도로 검토해야 한다. 올바르게 위임된 SQL 응답이 실수로 앱 신원으로 실행한 파일 요청 결과와 화면에서 합쳐질 수 있다. 플랫폼은 개발자가 모든 코드 경로에 의도한 신원을 배정하도록 보장하지 못한다.
에이전트는 자유로운 질문을 해석하고 도구를 고르며 여러 단계로 쿼리를 만들어 위험을 키운다. 검색 콘텐츠의 프롬프트 인젝션은 정보 공개나 부적절한 행동을 유도할 수 있다. OBO는 현재 사용자 접근을 제한하지만 유효한 신원이나 읽기 전용 스코프만으로 모든 허용 쿼리가 사용자 의도에 부합한다고 입증하지는 못한다.
동의도 관리자 검토의 대체물이 아니다. 사람들은 서비스와 결과를 어떻게 결합할지 이해하지 못한 채 스코프를 승인할 수 있다. 입력 처리, 도구 제약, 출력 통제, 런타임 감시는 여전히 필요하며 비정상 쿼리, 반복 거부, 예상 밖 데이터량, 앱 행동 변화를 살펴야 한다.
관리자만으로 시험하면 거부가 드물어 결함을 숨길 수 있다. 지역 권한, 더 넓은 권한, 테이블 권한이 전혀 없는 사용자는 다른 결과를 드러낸다. 반환 데이터와 거부 행동을 모두 확인해야 한다. Databricks는 정책 변경 후 재시험을 권한다. 로그는 앱 작업과 개인을 위한 작업을 구분하되 베어러 토큰이나 민감한 응답을 남기지 않아야 한다.
중복 정책은 줄고 플랫폼 의존성은 커진다
위임은 원본의 과도한 권한을 고치지 못한다. 그룹, 카탈로그 권한, 웨어하우스 접근, 행 필터, 마스크를 정확히 유지해야 한다. 검색 가능한 기술 지식 베이스에 위협 모델, 권한 결정, 검토 증거를 구현 문서와 보관할 수 있지만 문서가 집행 자체는 아니다.
Databricks의 차별점은 위임의 발명이 아니라 자체 거버넌스 데이터·SQL·런타임과의 통합이다. Microsoft는 API 전반의 OBO를 이미 문서화했다. Google 신원 인식 접근은 호스팅 앱과 문맥 정책에, AWS는 맞춤형 시스템용 권한 구성 요소에 초점을 둔다. 플랫폼과 개발자에게 배분되는 통합 책임이 다르다.
이미 Unity Catalog로 관리하는 데이터라면 Databricks는 보안팀과 앱 프레임워크 사이의 정책 변환을 줄일 수 있다. 대신 특정 스코프와 신원 동작에 더 의존하며 멀티클라우드 리소스에는 다른 권한 계층이 필요할 수 있다.
개발 시간 절감이나 기업의 권한 결함 회피율을 입증하는 독립 벤치마크는 없다. 실질적으로 권한이 다른 사용자를 지원하는 프로덕션 패턴, 감사 가능한 혼합 서비스, 세밀한 스코프와 명확한 동의가 GA 문구보다 강한 증거다. 토큰 사고, 스코프 확산, 신원 폴백 버그는 반대 증거가 된다.
이번 출시는 프로덕션 도입 장벽 하나를 낮추면서 어떤 작업이 앱에, 어떤 작업이 사람에게 속하는지라는 핵심 선택을 남긴다. SQL·에이전트·파일·외부 서비스가 한 제품으로 복잡해져도 그 구분을 유지하는 데 가치가 있다. 로그인한 사람을 무제한 자격 증명으로 취급하는 데 있지 않다.
출처와 관련 자료
Databricks 정식 출시 발표; Apps 권한 모델; 2025년 3월 프리뷰; Microsoft OBO 지침; 검색 가능한 기술 지식 베이스 관련 자료; Apps 권한 수준; Google 신원 인식 접근.