Databricks Apps 사용자 권한 부여, 이제 GA로 제공되지만 ID 경계는 여전히 중요
Databricks는 18개월이 넘는 공개 프리뷰 기간을 거쳐 10월 7일 Databricks Apps 사용자 권한 부여 기능을 정식 출시했다. 이 기능을 사용하면 애플리케이션이 로그인한 사용자의 ID로 지원되는 플랫폼 서비스를 호출할 수 있다. 이는 데이터 애플리케이션과 AI 에이전트의 핵심 보안 결정을 바꾼다. 각 요청은 누구의 권한을 기준으로 처리되어야 할까?
그동안 개발자는 대개 하나의 앱 인스턴스에 할당되는 비인간 ID인 애플리케이션의 서비스 주체에 의존했다. 개발자가 애플리케이션 내부에 사용자 수준의 액세스 규칙을 재구성하지 않는 한, 모든 사용자는 이 공유 ID를 통해 결과를 받을 수 있었다. 새 모델에서는 기존 Unity Catalog 정책이 사용자를 따라 앱 요청에도 적용된다.
이 약속에는 중요한 단서가 있다. OBO(on-behalf-of-user) 권한 부여가 애플리케이션을 기본적으로 안전하게 만들어 주는 것은 아니다. 개발자는 사용자 주도 작업과 백그라운드 작업을 분리하고, 좁은 범위의 스코프를 요청하며, 전달되는 토큰을 보호하고, 예상한 ID가 없을 때 요청을 거부해야 한다.
이번 발표는 플랫폼 관리형 권한 부여와 애플리케이션 관리형 권한 로직 간의 더 넓은 경쟁 구도 속에 놓여 있다. Microsoft는 자체 OBO 흐름을 통해 위임된 ID를 지원하며, 다른 클라우드 플랫폼은 별도의 ID 및 정책 구성 요소를 제공한다. Databricks는 이 패턴을 거버넌스가 적용된 엔터프라이즈 데이터, SQL 웨어하우스, 에이전트 및 자사 플랫폼에서 실행되는 애플리케이션과 직접 연결하고 있다.
Databricks Apps 사용자 권한 부여가 각 요청의 권한 주체를 바꾼다
정식 출시를 통해 개발자는 애플리케이션 요청 전반에서 사용자의 기존 데이터 권한을 유지할 수 있는 공식 지원 방식을 확보했다.
Databricks Apps는 서버리스 인프라에서 데이터 애플리케이션, 운영 도구, 대시보드 및 맞춤형 에이전트를 호스팅한다. 배포된 각 앱에는 해당 애플리케이션에 부여된 리소스에 액세스할 수 있는 전용 서비스 주체가 제공된다. 이 앱 권한 부여 방식은 계속 사용할 수 있으며, 공유 또는 자동화된 작업에 적합하다.
사용자 권한 부여는 두 번째 ID 경로를 추가한다. 로그인한 사용자가 지원되는 작업을 시작하면 Databricks는 액세스 토큰을 애플리케이션 런타임으로 전달한다. 그러면 앱은 그 사용자의 ID와 권한으로 승인된 Databricks API를 호출할 수 있다.
플랫폼의 권한 부여 모델은 위임된 액세스의 표준 프로토콜인 OAuth 2.0을 사용한다. 이 모델은 사용자-대-머신 권한 부여와 머신-대-머신 권한 부여를 구분한다. 전자는 대화형 사용자를, 후자는 애플리케이션 또는 자동화된 워크로드를 나타낸다.
앱이 거버넌스 적용 데이터를 액세스할 때 Unity Catalog는 사용자의 기존 권한을 평가한다. 행 필터는 표시되는 레코드를 제한할 수 있고, 열 마스크는 민감한 필드를 숨기거나 변환할 수 있다. 웨어하우스 권한 역시 사용자가 요청한 쿼리를 실행할 수 있는지를 결정한다.
결과는 요청을 수행하는 사람에 따라 달라진다. 지역 영업 관리자는 한 지역의 데이터만 받을 수 있는 반면, 전국 단위 책임자는 모든 지역을 볼 수 있다. 두 사람은 동일한 애플리케이션과 요청 경로를 사용해도 동일한 액세스 권한을 받지 않는다.
이는 앱이 거버넌스 규칙을 각각 별도로 복제할 필요가 없다는 점에서 중요하다. 관리자가 Unity Catalog 정책을 변경하면 이후의 앱 요청은 업데이트된 정책을 기준으로 평가된다. 개발자는 플랫폼 제어와 어긋날 수 있는 병렬 권한 부여 시스템을 유지하지 않아도 된다.
Databricks는 2025년 3월 26일 Apps용 OBO 권한 부여를 처음 공개 프리뷰로 도입했다. 프리뷰 릴리스는 Unity Catalog 테이블과 모델 서빙 엔드포인트 등의 리소스를 다뤘다. 정식 출시는 Databricks가 문서화된 제한 내에서 이 패턴이 프로덕션 도입에 준비되었다고 판단한다는 신호다.
GA가 앱 권한 부여를 없애는 것은 아니다. Databricks는 두 모델을 명시적으로 상호 보완적인 관계로 제시한다. 애플리케이션은 공유 구성, 텔레메트리 또는 일상적인 유지 관리에는 자체 ID를 사용하고, 거버넌스가 적용된 쿼리에는 현재 사용자의 ID를 사용할 수 있다.
계정 성과에 관한 질문에 답하는 영업 인사이트 어시스턴트를 생각해 보자. 앱 ID는 공통 구성을 읽고 운영 지표를 기록할 수 있다. 사용자 ID 경로는 요청한 직원이 액세스할 수 있는 고객 및 영업 기록을 쿼리한다.
이러한 구분이 이번 출시의 기반이다. 앱에는 여전히 ID가 있지만, 그 ID가 더 이상 모든 대화형 작업을 위한 범용 게이트웨이가 될 필요는 없다. 개발자는 각 작업의 권한 주체를 결정할 수 있다.
따라서 이 변화는 단순히 로그인 이상의 문제를 다룬다. 인증은 누가 존재하는지를 확인하고, 권한 부여는 그 ID가 무엇을 할 수 있는지를 결정한다. Databricks Apps 사용자 권한 부여는 두 번째 결정을 후속 데이터 및 서비스 호출까지 확장한다.
진짜 압력은 애플리케이션 관리형 액세스 제어에 가해진다
Databricks는 각 애플리케이션 내부에서 엔터프라이즈 데이터 권한을 다시 구축하는 관행에 도전하고 있다.
공유 서비스 주체만 사용하는 앱은 흔히 일관된 하나의 권한 집합을 본다. 이후 개발자는 각 직원이 어떤 결과를 받을 수 있는지 결정해야 한다. 일반적으로 맞춤형 역할, 정책 매핑, 필터링 로직 또는 또 다른 권한 부여 서비스가 필요하다.
이러한 제어 방식은 작동할 수 있지만, 두 번째 단일 진실 공급원을 도입한다. 거버넌스 팀이 Unity Catalog 권한을 업데이트해도 애플리케이션의 로컬 역할 매핑은 그대로일 수 있다. 이로 인한 불일치는 정보를 노출하거나 정당한 액세스를 거부할 수 있다.
사용자 권한 부여는 지원되는 Databricks 리소스에서 이러한 중복을 줄인다. 요청자의 확립된 권한이 실행 컨텍스트의 일부가 된다. 애플리케이션 코드는 요청된 작업에 집중하고, 플랫폼은 거버넌스 적용 액세스를 평가할 수 있다.
이는 AI 에이전트에서 점점 더 중요해지고 있다. 기존 대시보드는 사전에 정의된 보기와 쿼리를 노출한다. 에이전트는 개방형 언어를 해석하고, 도구를 선택하며, 쿼리를 구성하고, 여러 단계에 걸쳐 정보를 검색할 수 있다.
이러한 유연성은 보호된 데이터에 도달할 수 있는 경로의 수를 늘린다. 개발자는 직원이 제기할 수 있는 모든 질문을 안정적으로 예측할 수 없다. 직원의 권한 부여 컨텍스트를 보존하면 후속 플랫폼에 또 하나의 집행 경계가 생긴다.
조직이 프로토타입을 프로덕션으로 옮길 때 이러한 압력은 특히 분명해진다. 초기 데모는 종종 개발자 자격 증명이나 광범위한 권한을 가진 서비스 계정으로 실행된다. 하지만 앱이 역할, 담당 지역 및 기밀 유지 요구 사항이 서로 다른 직원에게 도달하면 이 지름길을 정당화하기 어려워진다.
하나의 애플리케이션이 영업, 재무, 운영 및 경영진을 모두 지원할 수 있다. 이들 그룹이 고객 세부 정보, 예측 또는 직원 정보에 대해 자동으로 같은 보기를 상속해서는 안 된다. 대상 사용자가 확대될수록 중앙 정책의 가치는 더 커진다.
Databricks는 거버넌스 관리자와 애플리케이션 팀 간의 마찰도 줄이고 있다. 보안 팀은 Unity Catalog를 통해 계속 데이터 권한을 관리할 수 있다. 개발자는 모든 정책을 프레임워크별 미들웨어로 옮길 필요가 없다.
그렇다고 개발 작업이 사라지는 것은 아니다. 팀은 특정 작업이 사용자에 속하는지 앱에 속하는지를 여전히 결정해야 한다. 또한 어떤 Databricks API가 OBO를 지원하는지, 각 작업에 어떤 권한 부여 스코프가 필요한지도 이해해야 한다.
대안 플랫폼에 위임된 ID가 없는 것은 아니다. Microsoft의 OBO 흐름은 업스트림 API에서 다운스트림 API로 사용자의 ID와 위임된 권한을 전달한다. Google Cloud는 ID 인식 애플리케이션 액세스를 제공하며, AWS는 맞춤형 애플리케이션을 위한 세분화된 권한 부여 구성 요소를 제공한다.
Databricks는 데이터 거버넌스 환경과의 통합을 통해 차별화한다. 권한 부여 결정은 Unity Catalog 권한, SQL 액세스 및 지원되는 플랫폼 서비스와 연결된다. 이는 데이터가 이미 Databricks 내부에 있는 애플리케이션의 통합 작업을 줄일 수 있다.
그 대가로 플랫폼 의존도는 높아진다. Unity Catalog 규칙과 Databricks 전용 스코프를 중심으로 구축된 애플리케이션은 유용한 제어를 물려받지만, 동시에 하나의 플랫폼 ID 모델과 밀접하게 정렬된다. 멀티클라우드 팀은 Databricks 외부 리소스에 대해 여전히 다른 권한 부여 계층이 필요할 수 있다.
따라서 엔터프라이즈 구매자에게 중요한 질문은 다른 곳에도 위임된 ID가 존재하는지가 아니다. Databricks가 거버넌스 적용 애플리케이션 개발을 충분히 단순화해 더 많은 데이터와 AI 워크로드를 자사 플랫폼 안에 머물게 할 수 있는지다.
OBO 권한 부여가 두 개의 권한 경계를 만드는 방식
OBO 요청은 사용자 권한과 애플리케이션의 승인된 API 스코프라는 두 범위 안에서만 성공한다.
첫 번째 경계는 데이터와 리소스에 관한 것이다. 사용자는 앱이 요청한다는 이유만으로 Unity Catalog 테이블, SQL 웨어하우스 또는 지원되는 서비스에 접근할 수 없다. 해당 사용자는 이미 필요한 권한을 보유하고 있어야 한다.
두 번째 경계는 애플리케이션에 관한 것이다. 개발자는 앱이 사용자를 대신해 수행할 수 있는 작업의 범주를 정의하는 API 스코프를 선언한다. 스코프는 사용자에게 새로운 데이터 액세스를 부여하지 않지만, 애플리케이션이 기존 액세스를 행사할 수 있는 방식을 제한한다.
읽기 전용 SQL 분석을 위해 Databricks는 sql:restricted-query 스코프를 문서화하고 있다. 앱은 웨어하우스를 관리하거나 관련 없는 관리 작업을 수행할 광범위한 권한을 받지 않고도 현재 사용자를 대신해 제한된 쿼리를 제출할 수 있다.
이처럼 교차하는 경계는 하나의 작업에 필요한 액세스만 부여하는 최소 권한 원칙을 뒷받침한다. 높은 권한을 가진 사용자는 직접적으로 많은 데이터세트에 접근할 수 있다. 그러나 좁은 스코프로 제한된 앱은 그 사용자가 보유한 모든 권한을 행사할 수 없어야 한다.
워크스페이스 관리자는 추가적인 상한선을 제어한다. 관리자는 개발자가 워크스페이스의 앱에 추가할 수 있는 사용자 권한 부여 스코프를 결정할 수 있다. 허용 목록에는 지원되는 모든 API, 선택한 스코프 또는 사용자 권한 부여 없음이 포함될 수 있다.
이 구조는 책임을 나눈다. 개발자는 제품에 필요한 최소 기능을 요청한다. 관리자는 워크스페이스 내에서 애플리케이션 개발자가 요청할 수 있는 기능을 결정한다.
그러나 관리자는 구성만으로는 의존할 수 없다. Databricks에 따르면 계정 관리자는 워크스페이스 허용 목록이 제외하더라도 스코프를 추가할 수 있다. 허용된 스코프가 제거된 뒤에도 기존 앱은 계속 실행될 수 있다.
발표에 따르면 영향을 받는 앱은 허용되지 않는 스코프가 제거될 때까지 이후 시작, 배포 또는 업데이트를 수행할 수 없다. 이 동작은 즉각적인 장애를 피하지만, 현재 실행 상태와 현재 정책이 완전히 일치하지 않는 기간을 만든다.
따라서 팀은 스코프 변경을 거버넌스가 적용되는 운영 이벤트로 다뤄야 한다. 관리자는 배포된 앱, 요청된 스코프, 책임 소유자 및 비즈니스 종속성의 인벤토리가 필요하다. 이러한 맥락 없이 기능을 제거하면 조치가 지연되거나 다음 배포 시 애플리케이션이 중단될 수 있다.
애플리케이션 코드도 두 ID를 분리해 유지해야 한다. 사용자 범위 클라이언트는 거버넌스가 적용되는 대화형 작업을 처리해야 한다. 앱 범위 클라이언트는 공유 구성, 지표 및 사용자 세션 없이도 지속되어야 하는 작업을 처리해야 한다.
이는 단순한 명명 선호 이상의 문제입니다. 범용 클라이언트는 민감한 경로를 실행하는 주체가 어떤 ID인지 감출 수 있습니다. 종속성, 테스트, 요청 핸들러를 분리하면 의도치 않은 자격 증명 사용을 더 쉽게 탐지할 수 있습니다.
가장 엄격한 규칙은 사용자 토큰이 누락된 경우에 적용됩니다. 경로에 사용자 권한 부여가 필요하지만 전달된 토큰이 없다면, 애플리케이션은 페일 클로즈 방식으로 동작해야 합니다. 서비스 주체로 조용히 전환하는 대신 요청을 거부해야 합니다.
폴백은 완전히 다른 권한 아래에서도 기술적으로 유효한 답변을 만들 수 있습니다. 사용자는 앱이 예상보다 더 넓거나 더 좁은 정보에 접근했다는 사실을 의심할 이유가 거의 없습니다. 이 때문에 조용한 ID 변경은 특히 위험합니다.
전달된 토큰은 활성 요청 동안에만 존재해야 합니다. Databricks는 개발자에게 해당 토큰을 출력, 기록 또는 영구 저장하지 말라고 권고합니다. 백그라운드 작업은 대화형 세션이 끝난 뒤 사용자 토큰을 보관하는 대신 앱 권한 부여를 사용해야 합니다.
내부 AI 도구를 구축하는 팀에게 이러한 ID 분리는 다른 엔지니어링 통제와 함께 갖춰야 할 요소입니다. 검색 가능한 기술 지식 베이스는 권한 부여 결정, 위협 모델, 검토 증거를 구현 문서와 함께 보존할 수 있습니다.
AI 에이전트는 ID 경계를 유지하기 더 어렵게 만든다
에이전트는 사용자별 권한의 이점을 얻지만, 다단계 동작 때문에 ID 실수의 영향도 더 커진다.
Databricks는 Apps를 통해 배포된 커스텀 에이전트도 동일한 권한 부여 모델을 사용할 수 있다고 설명합니다. 사용자 범위의 워크스페이스 클라이언트는 활성 invoke 또는 stream 핸들러 내부에서 초기화해야 합니다. 전달된 토큰은 요청이 실행되는 동안에만 사용할 수 있습니다.
이 시간 제약은 개발자가 사용자 ID를 전역 애플리케이션 상태로 취급하지 못하도록 합니다. 하나의 에이전트 프로세스는 많은 사용자를 처리할 수 있으며, 애플리케이션 시작 시점은 특정 사용자에게 속하지 않습니다. 사용자 범위 클라이언트를 너무 일찍 생성하면 요청 컨텍스트가 누락되거나 혼합될 위험이 있습니다.
에이전트 워크플로는 서로 다른 유형의 작업도 결합합니다. 한 단계에서는 앱 ID를 통해 공유 지침을 검색할 수 있습니다. 다른 단계에서는 사용자 권한으로 거버넌스가 적용된 재무 데이터를 쿼리할 수 있습니다. 세 번째 단계에서는 사용자 자격 증명을 보존하지 않은 채 일반적인 텔레메트리를 기록할 수 있습니다.
각 전환은 권한 부여 결정을 만듭니다. 개발자는 모든 도구 호출에 대해 주체, 범위, 리소스, 예상되는 실패 방식을 식별해야 합니다. 단일 범용 에이전트 클라이언트는 이런 구분을 흐릴 수 있습니다.
에이전트가 다른 서비스를 호출하면 과제는 더 커집니다. OBO는 다운스트림 통합이 해당 모델을 지원하는 경우에만 사용자 컨텍스트를 보존할 수 있습니다. 외부 API에는 별도의 자격 증명, 동의, 범위, 감사 통제가 필요할 수 있습니다.
에이전트는 전체 도구 체인에서 권한 부여가 자동으로 이전된다고 가정해서는 안 됩니다. 토큰은 특정 대상과 목적을 위해 발급됩니다. Microsoft의 OBO 지침 역시 중간 계층 토큰을 의도하지 않은 수신자에게 전달하지 말라고 경고합니다.
이는 사용자 권한 부여를 포괄적 가장으로 설명해서는 안 된다는 의미입니다. 애플리케이션은 구성된 범위와 지원되는 요청 경로 안에서만 사용자를 위해 행동합니다. 그렇지 않으면 "사용자를 대신해 행동한다"는 표현이 무제한 접근을 시사할 수 있으므로, 이 표현은 중요합니다.
프롬프트 인젝션도 주의가 필요한 또 다른 이유입니다. 공격자는 에이전트가 검색하는 콘텐츠 안에 지침을 넣어 도구 호출이나 정보 공개를 유도할 수 있습니다. OBO는 접근 가능한 데이터를 현재 사용자로 제한하지만, 요청된 작업이 타당한지는 판단하지 않습니다.
사용자 자신의 권한도 광범위할 수 있습니다. 경영진, 관리자 또는 분석가는 여러 비즈니스 기능에 걸친 민감한 데이터세트에 접근할 수 있습니다. 해당 인물의 유효한 ID를 사용하는 손상된 앱은 여전히 심각한 위험을 초래합니다.
이 상황에서 범위는 중요한 두 번째 경계를 제공합니다. 읽기 전용 쿼리 범위는 관련 없는 관리 작업을 막을 수 있지만, 허용된 모든 쿼리가 사용자의 의도에 부합하는지는 판단할 수 없습니다. 애플리케이션에는 여전히 입력 처리, 도구 제약, 출력 통제, 모니터링이 필요합니다.
동의 역시 면밀히 검토해야 합니다. 사용자는 에이전트가 서비스를 어떻게 결합하거나 결과를 처리할지 이해하지 못한 채 요청된 권한을 승인할 수 있습니다. 명확한 범위 이름은 도움이 되지만, 동의는 관리 검토와 제한된 애플리케이션 동작을 대체하지 못합니다.
감사 가능성은 필수적입니다. 보안 팀은 앱 ID로 수행된 작업과 개인을 위해 수행된 작업을 구분할 수 있어야 합니다. 로그는 베어러 토큰이나 민감한 응답 내용을 기록하지 않으면서 관련 주체와 작업을 식별해야 합니다.
테스트에는 서로 다른 권한을 가진 사용자가 포함되어야 합니다. 관리자 계정만으로 수행한 테스트는 해당 계정이 접근 거부를 거의 겪지 않기 때문에 오류를 숨길 수 있습니다. Databricks는 거버넌스 정책이 변경된 뒤에도 테스트를 반복할 것을 권장합니다.
유용한 테스트 사례에는 지역별 접근 권한을 가진 사용자, 더 폭넓은 접근 권한을 가진 사용자, 그리고 쿼리 대상 테이블에 전혀 접근하지 못하는 사람이 포함됩니다. 팀은 반환되는 데이터와 거부 동작을 모두 검증해야 합니다. 또한 토큰 누락이 절대 앱 ID 폴백을 유발하지 않는지도 확인해야 합니다.
따라서 핵심 한계는 분명합니다. Databricks Apps 사용자 권한 부여는 기존 플랫폼 권한을 강제할 수 있지만, 지나치게 광범위한 권한 부여를 바로잡을 수는 없습니다. 조직은 여전히 정확한 그룹, 카탈로그 권한, 웨어하우스 접근 권한, 행 필터, 열 마스크를 유지해야 합니다.
보안 약속은 운영 규율에 달려 있다
이 설계의 가장 강력한 부분은 계층형 통제 모델이지만, 가장 취약한 부분은 여전히 그 모델을 둘러싼 구현과 거버넌스다.
Databricks는 적절한 ID를 전달하고 선언된 범위를 강제할 수 있습니다. 하지만 모든 개발팀이 모든 코드 경로에 올바른 ID를 할당하도록 보장할 수는 없습니다. 그 결정은 애플리케이션 아키텍처 내부에 남아 있습니다.
팀은 SQL 쿼리에 OBO를 올바르게 사용할 수 있지만, 관련 파일 요청에는 실수로 앱 ID를 사용할 수 있습니다. 사용자 인터페이스는 서로 다른 권한 부여 컨텍스트를 드러내지 않은 채 두 응답을 결합할 수 있습니다.
백그라운드 처리도 또 다른 경계를 제시합니다. 사용자가 요청 종료 후에도 계속되는 장기 실행 작업을 시작할 수 있습니다. 전달된 토큰은 활성 요청에 속하므로 개발자는 나중에 실행하기 위해 이를 단순히 보존할 수 없습니다.
더 안전한 설계는 지연된 작업이 애플리케이션에 속하는지, 아니면 지원되는 다른 위임 패턴이 필요한지를 판단하는 것입니다. 작업이 앱에 속한다면 서비스 주체에는 신중하게 제한된 권한이 필요합니다. 사용자 컨텍스트가 필요하다면 개발자는 토큰을 보관하는 대신 문서화된 플랫폼 동작을 따라야 합니다.
환경 전반의 가용성도 확인이 필요합니다. Databricks 문서는 서비스와 규정 준수 구성이 확대되면서 변경됩니다. 팀은 GA를 보편적 가용성으로 간주하기 전에 클라우드, 리전, 워크스페이스, 보안 프로필 지원 여부를 검증해야 합니다.
Apps 자체는 익명 공개 애플리케이션이 될 수 없습니다. Databricks는 사용자가 인증해야 하며, 외부 협업자는 지원되는 ID 페더레이션을 통해 온보딩해야 한다고 설명합니다. 따라서 이 모델은 관리형 ID를 사용하는 직원 및 파트너 시나리오에 가장 자연스럽게 맞습니다.
앱 권한과 데이터 권한 부여의 분리는 검토자를 혼란스럽게 할 수 있습니다. CAN USE와 CAN MANAGE는 누가 앱을 실행하거나 관리할 수 있는지를 결정합니다. 이는 사람이 앱을 통해 어떤 테이블이나 레코드에 접근할 수 있는지를 결정하지 않습니다.
사용자는 앱 사용 권한을 보유하면서도 그 기본 데이터에 쿼리할 권한은 없을 수 있습니다. 해당 요청은 실패하거나 제한된 결과를 반환해야 합니다. 반대로 데이터 접근 권한만으로 애플리케이션을 열 수 있는 권한이 반드시 부여되는 것은 아닙니다.
따라서 문서화된 권한 수준은 Unity Catalog 권한 부여와 별도로 검토해야 합니다. 이를 하나의 통제로 취급하면 감사 과정에서 잘못된 확신을 만들 수 있습니다.
관리자 범위 허용 목록은 또 다른 거버넌스 과제를 도입합니다. 발표에 따르면 기본값에는 지원되는 모든 API가 포함될 수 있습니다. 보안을 중시하는 조직은 광범위한 앱 도입에 앞서 이 기본값이 자사의 개발 모델에 부합하는지 판단해야 합니다.
허용 목록을 좁히면 위험을 줄일 수 있지만, 정당한 제품을 차단할 수도 있습니다. 적절한 프로세스는 제한된 기준선과 문서화된 예외 절차를 결합합니다. 그렇지 않으면 팀은 범위 제한을 피하기 위해 더 광범위한 앱 ID를 추구할 수 있습니다.
탐지 과제도 있습니다. 앱은 승인된 범위만 요청하면서도 그 범위 내에서 잘못 동작할 수 있습니다. 런타임 모니터링은 비정상적인 쿼리 패턴, 반복적인 거부, 예상치 못한 데이터 볼륨, 애플리케이션 동작 변화를 살펴봐야 합니다.
현재 이 기능이 개발 시간을 얼마나 절감하는지, 또는 기업이 권한 결함을 얼마나 효과적으로 피하는지를 입증하는 독립 벤치마크는 없습니다. GA 발표는 메커니즘과 권장 관행을 설명하지만, 도입 성과는 아직 입증되어야 합니다.
Databricks 역시 자사의 거버넌스 계층을 내부 애플리케이션과 에이전트를 위한 기본 기반으로 만들 동기가 있습니다. 구매자는 이 전략적 이점을 이식성, 통합 노력, 기존 권한 부여 시스템의 성숙도와 함께 평가해야 합니다.
관련 비교는 단순한 Databricks 대 Microsoft 경쟁 구도가 아닙니다. Microsoft의 위임 ID 패턴은 성숙했으며 API 전반에 폭넓게 적용할 수 있습니다. Databricks는 관련 원칙을 자체 데이터, 컴퓨팅, 거버넌스, 애플리케이션 런타임을 중심으로 패키징하고 있습니다.
Google의 ID 인식 액세스는 호스팅된 애플리케이션과 컨텍스트 정책에 대한 접근 통제에 초점을 둡니다. AWS는 개발자가 ID 공급자 및 애플리케이션 리소스와 결합할 수 있는 권한 부여 구성 요소를 제공합니다. 각 접근 방식은 플랫폼과 애플리케이션 팀에 서로 다른 업무를 할당합니다.
조직은 정책이 어디에 존재하는지, 어떤 리소스를 포괄하는지, ID가 서비스 경계를 어떻게 넘는지, 거부가 사용자에게 어떻게 표시되는지를 비교해야 합니다. 또한 감사 기록이 작업을 애플리케이션과 이를 시작한 사람 모두에게 명확히 연결하는지도 테스트해야 합니다.
GA 표시는 도입 장벽 하나를 낮추지만, 이러한 아키텍처 질문을 해결해 주지는 않습니다. 데이터 거버넌스가 이미 Unity Catalog에 있고 애플리케이션이 주로 지원되는 Databricks 서비스를 호출하는 경우, 이 기능은 가장 설득력이 있습니다.
GA 릴리스가 성과를 내는지 보여줄 세 가지 신호
다음 시험대는 기업이 토큰 위험, 정책 복잡성 또는 플랫폼 종속을 확대하지 않고 사용자 인식 애플리케이션을 도입할 수 있는지 여부다.
첫 번째 신호는 내부 에이전트와 운영 애플리케이션에서의 프로덕션 도입입니다. Databricks는 명확한 영업 인사이트 시나리오를 제시했지만, 실제 배포는 SQL, 모델, 파일, 대시보드, 외부 서비스가 훨씬 복잡하게 혼합될 것입니다.
성숙한 도입의 증거에는 반복 가능한 아키텍처 패턴, 참조 구현, 명확한 감사 워크플로가 포함됩니다. 또한 이러한 증거에는 코드에서 해당 규칙을 복제하지 않고도 의미 있게 서로 다른 권한을 가진 사용자를 지원하는 애플리케이션이 포함될 것입니다.
저조한 도입은 지원되는 범위, 다운스트림 서비스 또는 조직 프로세스가 여전히 너무 제한적임을 시사할 수 있습니다. 팀은 GA 옵션이 있음에도 광범위한 권한을 가진 서비스 주체나 별도의 권한 부여 제품을 계속 사용할 수 있습니다.
두 번째 신호는 지원되는 API 범위의 확대와 정교화입니다. 세분화된 범위는 개발자가 관련 없는 권한을 받지 않고 하나의 기능만 요청할 수 있게 하므로 최소 권한 설계를 더 쉽게 만듭니다.
넓지만 거친 범위는 두 번째 권한 경계를 약화할 것입니다. 더 세분화된 범위, 개선된 관리 통제, 더 명확한 동의 경험은 앱이 과도하게 권한을 행사하지 않고 사용자를 위해 행동할 수 있다는 Databricks의 주장을 강화할 것입니다.
컴플라이언스 프로필 지원 변경도 중요합니다. Databricks는 컴플라이언스 보안 프로필이 적용된 워크스페이스에 대한 사용자 권한 부여가 2026년 9월 말에 제공될 예정이라고 밝혔습니다. 고객은 각자 환경에서 제공 여부와 제한 사항을 확인해야 합니다.
세 번째 신호는 경쟁사들이 위임된 ID를 에이전트 플랫폼에 통합하는 방식입니다. Microsoft는 이미 기존 API와 최신 호스팅 에이전트 시나리오를 위한 OBO를 문서화하고 있습니다. 다른 플랫폼들도 사용자 ID, 도구 사용, 정책 엔진, 관리형 애플리케이션 런타임을 연결하고 있습니다.
이러한 대안에 상당한 수준의 맞춤형 통합이 필요하다면, Databricks는 거버넌스가 적용된 엔터프라이즈 데이터를 중심으로 구축되는 애플리케이션에서 우위를 확보하게 됩니다. 경쟁사들이 데이터와 에이전트 도구 전반에 걸쳐 동등하게 직접적인 정책 상속을 제공한다면, 구매자는 이식성과 생태계 확장성을 더 중시하게 될 것입니다.
개발자는 발표 문구보다 운영상의 증거를 지켜봐야 합니다. 토큰 처리 사고, 혼란스러운 동의 흐름, 범위 확산, ID 폴백 버그는 이 접근 방식의 설득력을 약화할 수 있습니다. 명확한 감사 체계와 줄어든 권한 관리 부담은 이를 뒷받침할 것입니다.
즉각적인 엔지니어링 과제는 실행에 규율이 필요하더라도 설명 자체는 간단합니다. 모든 애플리케이션 작업을 앱 ID 또는 현재 사용자 ID 중 하나에 매핑해야 합니다. 가장 좁은 범위를 할당하고, 누락된 자격 증명은 거부하며, 실제로 서로 다른 사용자로 테스트해야 합니다.
팀은 에이전트를 통해 기존 Unity Catalog 권한을 노출하기 전에 해당 권한도 검토해야 합니다. OBO는 의도보다 이미 더 넓게 설정된 권한을 포함해 이러한 권한을 충실히 적용합니다. 위임은 취약한 원본 정책을 개선할 수 없습니다.
따라서 Databricks Apps 사용자 권한 부여는 ID 인식 거버넌스를 데이터와 애플리케이션 런타임에 더 가깝게 가져온다는 점에서 의미가 있습니다. 공유 작업을 위한 앱 ID를 유지하면서, 일부 중복된 권한 로직을 플랫폼 차원의 적용으로 대체합니다.
성공 여부는 애플리케이션이 복잡해진 뒤에도 개발자가 이 경계를 유지할 수 있는지에 달려 있습니다. 다음 내부 어시스턴트를 배포하기 전에 모든 요청 경로에 대해 한 가지 질문을 던져야 합니다. 이 작업은 애플리케이션으로 실행되어야 할까요, 아니면 이를 사용하는 사람으로 실행되어야 할까요?
