Amazon Quick, 액세스 공백 없이 사용자 수준 맞춤 권한을 자동화하는 네 가지 방법 추가

Amazon Quick은 기업마다 사용자를 생성하고 관리하는 방식이 다른 상황에 맞춰 Amazon Quick의 사용자 수준 맞춤 권한을 자동화하는 네 가지 패턴을 제공한다. AWS는 Quick의 확장되는 AI 기능으로 수동 권한 할당을 지속하기 어려워진 가운데, 2026년 9월 9일 이 가이드를 공개했다.

중요한 변화는 또 하나의 권한 설정 화면이 아니다. AWS는 맞춤 권한 프로필을 사용자 수명 주기의 네 가지 고유 시점, 즉 등록, 기본 할당, 그룹 멤버십 변경, 사후 보정에 연결했다.

이는 보안 팀에 유의미한 긴장을 만든다. 광범위한 기본값은 즉각적인 보호를 제공하지만 모든 비즈니스 규칙을 표현할 수는 없다. 사용자별 자동화는 정밀도를 높이지만 이벤트 처리, 충돌 해결, 모니터링, 복구 작업도 수반한다.

Microsoft Power BI와 Salesforce Tableau도 분석 플랫폼이 생성형 AI와 워크플로 기능을 흡수하면서 비슷한 거버넌스 압박에 직면해 있다. 다만 AWS는 Quick 역할과 그룹 전반에서 사용자를 따라갈 수 있는 계층형 프로필을 중심으로 해법을 제시한다.

Amazon Quick의 권한 모델에서 달라진 점

AWS는 맞춤 권한을 관리자가 온보딩 이후에만 할당하는 프로필이 아니라 수명 주기 제어 수단으로 전환했다.

맞춤 권한을 통해 관리자는 선택한 사용자에 대해 특정 Quick 기능을 활성화하거나 비활성화할 수 있다. 재무 분석가는 보고서를 만들 수 있지만 원본 데이터 내보내기 기능은 제한될 수 있다. 외부 파트너는 공유 제어 기능 없이 대시보드만 볼 수 있다.

이 프로필은 ID 인증이나 일반적인 리소스 권한 부여를 대체하지 않는다. 인증된 사용자가 접근할 수 있는 제품 기능을 결정하기 위한 또 하나의 제어 계층을 만든다.

Amazon Quick이 기존 비즈니스 인텔리전스를 넘어 확장됨에 따라 이 구분은 더욱 중요해진다. 이 플랫폼에는 이제 AI 지원 작성, 에이전트, 플로우, 지식 베이스, 커넥터, 애플리케이션, 생성형 비즈니스 인텔리전스 기능이 포함된다.

따라서 AUTHOR와 같은 역할은 과거보다 사용자의 전체 위험 프로필을 덜 설명한다. 두 작성자가 같은 역할을 보유하더라도 내보내기, 공유, AI 기능 또는 데이터 연결에 필요한 접근 수준은 크게 다를 수 있다.

AWS의 새 가이드는 자동화를 네 가지 운영 시나리오로 구성한다. 첫 번째는 API 기반 등록 중에 프로필을 연결한다. 두 번째는 별도의 자동화를 유지하지 않고 계정 또는 역할 기본값을 적용한다.

세 번째는 Amazon EventBridge와 AWS Lambda를 사용해 그룹 멤버십 이벤트에 대응한다. 네 번째는 조직이 자동화된 제어를 도입하기 전에 이미 존재하던 사용자를 업데이트한다.

이 방식들은 서로 바꿔 쓸 수 있는 네 가지 배포 옵션이 아니다. 각각 ID 수명 주기의 다른 지점을 다루며, 성숙한 환경에서는 여러 방식을 함께 사용하는 경우가 많다.

이러한 조합의 동작은 계층 구조가 결정한다. 사용자 수준 설정은 역할 수준 설정을 재정의하며, 역할 수준 설정은 계정 수준 기본값을 재정의한다.

이 순서는 관리자가 통제된 예외와 함께 제한적인 기반을 마련하도록 한다. 동시에 사용자 수준의 단일 할당이 더 넓은 수준에서 상속된 보호를 무효화할 수 있으므로 거버넌스 책임도 발생한다.

시점도 중요하다. AWS는 8월 19일 맞춤 권한 프로필의 AI 기능 범주에 대해 기본 거부를 발표했다.

이 설정은 관리자가 명시적으로 허용할 때까지 영향을 받는 사용자의 새 AI 기능을 차단한다. 이전에는 새 기능이 출시와 동시에 제공됐기 때문에 보안 팀은 사후 대응해야 했다.

자동화 가이드는 이 제어 체계의 또 다른 부분을 완성한다. 기본 거부는 미래 기능에 대한 더 안전한 태도를 정의한다. 수명 주기 자동화는 어떤 사람이 언제 각 태도를 적용받는지를 결정한다.

AWS는 조건부 이벤트 처리를 구축하기 전에 계정 또는 역할 기본값부터 시작할 것을 권장한다. 이 권고는 핵심 문제를 드러낸다. 가장 안전한 제어는 예외 워크플로가 실행되기 전에 이미 활성화된 제어다.

계정 및 역할 기본값이 가장 큰 보안 비중을 갖는 이유

가장 단순한 패턴은 관리자가 각 사용자의 분류를 마치기 전에 적용되므로 가장 큰 액세스 공백을 해소한다.

계정 수준 옵션은 UpdateAccountCustomPermission API를 사용한다. 이는 적시 프로비저닝으로 생성된 사용자를 포함해 명시적인 사용자 또는 역할 할당이 없는 사용자에게 적용되는 대체 프로필을 설정한다.

적시 프로비저닝은 연동 사용자가 서비스에 처음 접근할 때 계정을 생성한다. 수동 온보딩을 줄이지만, 그룹 기반의 비즈니스 컨텍스트가 아직 없는 기간을 만들 수 있다.

계정 기본값은 그 기간을 포괄한다. 분류되지 않은 모든 사람은 새로 도입된 기능에 무제한으로 접근하는 대신 조직이 허용할 수 있는 최소 제한부터 적용받는다.

역할 수준 옵션은 UpdateRoleCustomPermission을 사용한다. 관리자는 네임스페이스 안에서 리더, 작성자, 관리자 및 이에 대응하는 전문 역할별로 서로 다른 기본값을 설정할 수 있다.

역할 기본값은 주된 정책 구분이 이미 직무 역량을 따르는 조직에 적합하다. 작성자는 콘텐츠를 만들기 때문에 하나의 프로필을 받고, 리더는 주로 콘텐츠를 소비하기 때문에 다른 프로필을 받을 수 있다.

AWS는 계정, 역할, 사용자 할당에 걸친 3단계 계층 구조를 설명한다. 관리자 구성 문서는 사용자 수준 프로필이 더 광범위한 기본값보다 우선한다는 점을 확인한다.

이 계층 구조는 기준 거버넌스와 예외를 분리한다. 보안 팀은 계정 전체에서 기능을 제한하고, 역할별로 정책을 세분화하며, 특정 사용자에게는 다른 프로필을 부여할 수 있다.

동일한 구조는 운영 복잡성도 제한한다. 모든 작성자나 모든 계정 사용자에게 균일하게 적용되는 규칙을 위해 기업이 Lambda 함수를 만들 필요는 없다.

기본값은 보안 검토가 제품 출시보다 느리게 진행될 때 특히 중요하다. 기업은 새 AI 범주를 즉시 차단하고, 평가한 뒤 승인 후 선택한 기능을 허용할 수 있다.

AWS는 기업이 새 생성형 비즈니스 인텔리전스 기능과 커넥터를 60~90일 동안 검토하는 사례를 제시한다. 이 수치는 서비스 요구사항이 아니라 정책 적용 기간을 보여주는 예시다.

예시의 규모와 무관하게 기본 취지는 타당하다. 기능 출시일은 조직의 개인정보 평가, 공급업체 검토 또는 내부 변경 절차와 일치하는 경우가 드물다.

따라서 광범위한 기본값은 보안 팀을 생산적인 방향으로 이끈다. 새로운 사용자를 각각 독립적인 티켓으로 취급하는 대신 예외를 설계하기 전에 최소 보안 태도를 정의해야 한다.

이는 더 빠른 접근을 원하는 제품 소유자에게도 압박이 된다. 기본값이 불확실한 상황에서 제한을 우선하기 때문에, 이들은 반복 가능한 승인 경로를 마련해야 한다.

하지만 기본값만으로는 모든 비즈니스 컨텍스트를 식별할 수 없다. 별도 사업부의 두 작성자가 같은 Quick 역할을 공유하면서도 내보내기, 자산 공유, AI 도구에 대해 서로 다른 요구사항을 가질 수 있다.

바로 여기서 광범위한 보호의 한계가 드러난다. 정책이 부서, 고객 권한, 지리적 위치 또는 승인 상태에 따라 달라지면 관리자는 더 정밀한 신호가 필요하다.

Amazon Quick의 사용자 수준 맞춤 권한을 자동화하는 방법

네 가지 패턴은 제어 순서를 이룬다. 조기에 할당하고, 안전하게 기본값을 적용하며, 컨텍스트에 반응하고, 기존 적용 범위를 보정한다.

가장 직접적인 패턴은 조직이 맞춤형 포털이나 프로비저닝 스크립트를 통해 사용자 생성을 제어할 때 적용된다. RegisterUser 요청은 계정 생성 중 CustomPermissionsName 값을 받을 수 있다.

AWS CLI는 --custom-permissions-name 매개변수를 통해 이 값을 제공한다. 이를 통해 다른 이벤트나 예정된 조정을 기다리지 않고 사용자의 의도된 프로필을 설정할 수 있다.

이 패턴은 등록 시점에 고객 권한을 이미 알고 있는 임베디드 분석 제공업체 및 기타 소프트웨어 서비스에 적합하다. 서비스는 해당 권한을 확립된 권한 프로필에 매핑할 수 있다.

예를 들어 제공업체는 고객 계약에서 제외된 사용자의 페이지 매김 보고서나 생성형 기능을 제한할 수 있다. 이 결정은 기존 프로비저닝 경로 안에서 이뤄진다.

이 접근 방식은 EventBridge 규칙이나 Lambda 함수가 필요하지 않으므로 구성 요소가 가장 적다. 단점도 분명하다. 조직이 등록 과정을 처음부터 끝까지 제어할 때만 작동한다.

연동 온보딩은 이 가정을 복잡하게 만든다. 조직이 부서, 그룹 또는 정책 속성을 확인하기 전에 ID 시스템이 Quick 사용자를 만들 수 있다.

계정 및 역할 기본값은 기준선을 설정해 이러한 불확실성을 처리한다. 맞춤형 인프라가 덜 필요하며, 더 높은 우선순위의 할당이 없는 기존 및 신규 사용자를 모두 포괄한다.

조건부 규칙에는 세 번째 패턴이 필요하다. AWS의 설계는 AWS CloudTrail에 기록된 그룹 멤버십 활동을 감시하고, 일치하는 이벤트를 EventBridge로 라우팅한 뒤 Lambda를 호출한다.

기본 Quick 그룹의 경우 CloudTrail은 누군가 가입하면 CreateGroupMembership을, 탈퇴하면 DeleteGroupMembership을 기록한다. IAM Identity Center는 AddMemberToGroup 및 RemoveMemberFromGroup을 사용한다.

EventBridge는 이 기록을 필터링한다. Lambda는 관련 Quick API를 호출하기 전에 계정, 네임스페이스, 사용자, 작업 및 대상 그룹을 추출한다.

멤버십 추가가 구성된 그룹과 일치하면 Lambda는 UpdateUserCustomPermission을 호출한다. 사용자 권한 API는 해당 사용자에 대해 하나의 맞춤 권한 프로필 이름을 받는다.

사용자가 모니터링 대상 그룹을 떠나면 Lambda는 DeleteUserCustomPermission을 호출한다. 명시적 할당을 제거하면 사용자는 적용 가능한 역할 또는 계정 기본값으로 돌아간다.

이 제거 동작은 매우 중요하다. 추가 시점에만 접근을 부여하거나 제한하는 자동화는 직원이 팀을 옮길수록 오래된 할당을 누적하게 된다.

AWS는 이벤트 기반 아키텍처용 CloudFormation 템플릿을 제공한다. 스택에는 EventBridge 규칙, Lambda 함수, 실행 역할 및 필요한 정책 리소스가 포함된다.

스택은 Quick 구독과 동일한 AWS Region에서 실행해야 한다. EventBridge는 구성된 Region 내에서 관련 서비스 이벤트를 캡처하므로, 배포 위치가 일치하지 않으면 예상 활동을 놓칠 수 있다.

각 배포는 하나의 기본 Quick 그룹 또는 하나의 IAM Identity Center 그룹을 대상으로 한다. 게시된 설계에서는 두 그룹 소스를 모두 모니터링하려면 별도 스택이 필요하다.

권한 프로필은 이미 존재해야 한다. 자동화는 프로필을 할당하지만 기능 설정을 정의하거나 조직의 정책을 결정하지는 않는다.

네 번째 패턴은 이벤트 기반 자동화가 존재하기 전에 가입한 사람들을 다룬다. 미래의 멤버십 이벤트로는 관련 그룹 할당이 몇 달 전에 이뤄진 사용자를 보정할 수 없다.

AWS는 ListGroupMemberships를 호출하고 반환된 사용자를 반복 처리한 뒤 각 사용자에게 UpdateUserCustomPermission을 적용하는 Python 배치 방식을 제공한다.

페이지네이션은 쉽게 놓치는 세부사항이다. ListGroupMemberships는 응답당 최대 100명의 멤버만 반환하므로 스크립트는 NextToken으로 계속 진행해야 한다.

그러한 루프가 없다면 팀은 첫 페이지 이후의 모든 구성원을 그대로 둔 채 마이그레이션이 성공했다고 보고할 수 있습니다. 대규모 그룹에서는 이런 실패가 발생할 가능성도 높고 알아차리기도 어렵습니다.

예시 스크립트는 후속 조치를 위해 실패한 업데이트를 CSV 파일에 기록합니다. 관리자는 DescribeUser를 호출하고 CustomPermissionsName을 검토하여 개별 할당을 확인할 수도 있습니다.

이러한 패턴을 함께 사용하면 모든 조직이 동일한 ID 아키텍처를 갖고 있다고 가정하지 않으면서 Amazon Quick의 사용자 수준 사용자 지정 권한을 자동화할 수 있습니다. 적절한 조합은 신뢰할 수 있는 정책 컨텍스트를 언제 확보할 수 있는지에 따라 달라집니다.

그룹 기반 정밀 제어는 새로운 통제 문제를 야기한다

이벤트 기반 권한은 반복 작업을 없애지만, 위험은 이벤트 전달, 그룹 품질, 충돌 해결로 이동합니다.

AWS의 그룹 기반 설계는 동일한 Quick 역할을 공유하는 사용자에게 서로 다른 프로필을 적용할 수 있으므로 가장 유연한 패턴입니다. 그러나 그 유연성은 가장 큰 운영 부담도 수반합니다.

CloudTrail은 올바른 리전에서 예상 이벤트를 캡처해야 합니다. EventBridge 규칙은 실제 이벤트 구조와 일치해야 합니다. Lambda에는 충분한 권한, 오류 처리, 로깅 및 재시도 동작이 필요합니다.

실행 역할 자체도 최소 권한 원칙을 따라야 합니다. AWS는 사용자 할당을 업데이트, 삭제, 설명 및 관리하기 위한 Quick 작업과 Identity Center 통합이 관련된 경우 Identity Store 읽기 작업을 나열합니다.

이 자동화는 계정 전반의 사용자 기능을 변경할 수 있으므로 서비스 권한 부여가 중요합니다. Quick 권한 부여 참조는 UpdateUserCustomPermission을 사용자 리소스에 대한 쓰기 작업으로 분류합니다.

따라서 Lambda는 단순한 통합 연결 장치가 아니라 권한을 가진 정책 시행 구성 요소입니다. 팀은 다른 액세스 제어 인프라와 마찬가지로 코드와 실행 역할의 변경을 신중하게 검토해야 합니다.

그룹 정확성도 또 다른 위험입니다. 이벤트 기반 시스템은 기본 멤버십이 잘못되었더라도 그룹에 매핑된 정책을 충실히 적용합니다.

따라서 오래된 부서 그룹은 기술적으로는 성공했지만 조직적으로는 잘못된 할당을 초래할 수 있습니다. 자동화는 수동 실행 오류를 줄이지만 원본 데이터의 정확성을 보장하지는 않습니다.

여러 그룹 멤버십은 가장 명확하게 해결되지 않은 문제를 만듭니다. Quick은 사용자당 하나의 사용자 지정 권한 프로필을 지원하지만, 한 사람이 서로 다른 의도된 프로필을 가진 여러 그룹에 속할 수 있습니다.

AWS 예시는 이 경우에 대한 자동 충돌 해결을 구현하지 않습니다. 조직은 어떤 프로필이 우선하는지 결정하고 그 선택을 Lambda 로직에 인코딩해야 합니다.

가장 제한적인 프로필 우선 전략은 최소 권한 원칙에 부합하지만 정당한 업무를 막을 수 있습니다. 우선순위 목록은 더 유연하지만, 담당자와 문서화된 예외 처리 절차가 필요합니다.

계층 구조에는 또 다른 고려 사항이 있습니다. 명시적 프로필이 상속된 기준선보다 덜 제한적이더라도, 그룹에 의해 트리거된 사용자 프로필은 역할 및 계정 기본값을 재정의합니다.

따라서 팀은 사용자 수준 프로필을 완전한 정책 결과로 취급해야 합니다. 예외 설계에서 제외된 기능을 계정 기본값이 계속 보호한다고 가정해서는 안 됩니다.

AWS의 이벤트 패턴은 또한 반응형입니다. 관리자가 해당 사용자를 적절한 그룹에 추가하기 전에 새 연동 사용자가 존재할 수 있습니다.

AWS는 이 프로비저닝 기간을 포괄하기 위해 제한적인 계정 또는 역할 기본값을 사용할 것을 명시적으로 권장합니다. 이후의 그룹 이벤트가 사용자의 권한을 세분화합니다.

이 관계는 기본값과 이벤트가 상호 보완적임을 보여 줍니다. 기본값은 알 수 없는 상태를 보호하고, 그룹 자동화는 분류 이후 알려진 컨텍스트를 적용합니다.

조직은 실패한 Lambda 호출, 일치하지 않는 이벤트 및 예기치 않은 권한 변경을 모니터링해야 합니다. CloudWatch 알람은 실행 실패를 식별할 수 있지만, 팀에는 비즈니스 수준의 조정도 필요합니다.

권한 있는 그룹과 할당된 프로필을 정기적으로 비교하면 두 번째 검증 수단을 제공합니다. 이를 통해 누락된 이벤트, 수동 재정의, 이름이 바뀐 그룹, 예상 워크플로 외부에서 변경된 프로필을 감지할 수 있습니다.

배치 스크립트도 이러한 조정을 지원할 수 있지만, AWS는 스크립트를 주로 초기 시정 조치 용도로 제시합니다. 동일한 페이지네이션 및 검증 원칙이 반복 감사에도 적용됩니다.

또한 이러한 패턴이 복잡한 프로덕션 환경 전반에서 어떻게 작동하는지 보여 주는 제3자 증거는 아직 없습니다. 이 지침은 새로 나왔으며, 가장 큰 규모 수치는 예시 시나리오로 제시됩니다.

그렇다고 아키텍처가 무효가 되는 것은 아닙니다. 구매자는 자체 ID 트래픽 환경에서 전달 지연 시간, API 제한, 재시도 동작 및 충돌 규칙을 검증해야 한다는 의미입니다.

보안 팀이 다음으로 주목해야 할 사항

다음 검증 과제는 조직이 이러한 구성 요소를 스크립트 모음이 아닌 감사 가능한 정책 시스템으로 전환할 수 있는지 여부입니다.

첫 번째 신호는 그룹 자동화와 함께 제한적인 계정 기본값을 도입하는 것입니다. 멤버십 이벤트만 사용하는 배포에는 분류 이전의 공백 구간이 남습니다.

기본 거부의 폭넓은 사용은 AWS의 수명 주기 모델을 강화할 것입니다. 이는 기업이 새로운 AI 기능을 자동으로 공개하기보다 검토를 위해 보류하기를 원한다는 점을 보여 줄 것입니다.

두 번째 신호는 그룹 수준 사용자 지정 권한 할당에 대한 네이티브 지원입니다. AWS는 사용자 지정 권한 프로필을 그룹에 할당하는 직접 API가 없다고 말합니다.

이 공백이 CloudTrail, EventBridge 및 Lambda 아키텍처를 설명합니다. 네이티브 그룹 할당은 인프라를 제거하는 동시에 관리자가 우선순위를 정의할 더 명확한 위치를 제공할 것입니다.

이러한 기능에는 충돌 의미 체계도 필요합니다. 한 사람이 서로 다른 프로필에 매핑된 그룹에 속할 때 어떤 일이 발생하는지 AWS가 설명해야 합니다.

결정론적 우선순위 없이 네이티브 지원이 도입된다면 문제를 해결하는 대신 옮기는 것에 그칠 것입니다. AWS가 명시적 우선순위 규칙을 추가한다면 이벤트 기반 우회 방식의 필요성은 줄어들 것입니다.

세 번째 신호는 실제 배포 사례의 증거입니다. 팀은 대규모 ID 사용자 집단 전반의 할당 지연 시간, 실패 복구, API 제한 및 조정을 다루는 공개 데이터를 찾아야 합니다.

현재 지침에는 50,000명, 125,000명 및 200,000명 이상의 사용자가 포함된 예시가 있습니다. AWS는 이를 측정된 고객 결과가 아니라 설계 요구 사항을 설명하는 시나리오로 제시합니다.

프로덕션 증거는 이 아키텍처의 근거를 강화하거나 약화할 것입니다. 엔터프라이즈 규모에서 신뢰할 수 있는 이벤트 처리는 계층형 설계를 검증할 것입니다.

이벤트 누락이 빈번하거나 충돌 처리가 복잡하다면, 조직은 대신 예약된 조정 또는 중앙 집중식 ID 거버넌스로 향하게 될 것입니다.

지금 이 모델을 구현하는 관리자는 인벤토리부터 시작해야 합니다. 모든 사용자 지정 프로필, 해당 소유자, 영향을 받는 기능, 할당 범위 및 승인된 예외 경로가 필요합니다.

그다음 가장 제한적이면서도 사용할 수 있는 계정 기본값을 설정해야 합니다. 직무 기능에 따라 일관된 차이가 생기는 경우 역할 수준 프로필로 이 기준선을 세분화할 수 있습니다.

직접 등록 할당은 신뢰할 수 있는 권한 데이터를 보유한 프로비저닝 시스템으로 제한해야 합니다. 그룹 기반 Lambda 로직은 광범위한 기본값으로 표현할 수 없는 규칙만 처리해야 합니다.

팀이 향후 이벤트를 신뢰하기 전에 기존 사용자는 완전한 배치 처리를 거쳐야 합니다. 마이그레이션은 성공을 기록하고 실패를 보존하며, 페이지네이션이 완료된 후 할당을 검증해야 합니다.

관리자는 추가뿐 아니라 제거도 테스트해야 합니다. 사용자가 그룹을 떠날 경우 오래된 재정의를 유지하지 않고 의도된 계정 또는 역할 프로필로 되돌아가야 합니다.

더 넓은 교훈은 Amazon Quick을 넘어섭니다. AI 기능은 익숙한 역할 안에 숨겨진 기능의 수를 늘려, 시간이 지날수록 정적인 역할 이름의 정보 가치를 낮춥니다.

제품 팀은 새 도구를 빠르게 사용할 수 있기를 원합니다. 보안 팀에는 데이터 이동, 공유 동작, 모델 액세스 및 커넥터 권한을 평가할 시간이 필요합니다.

Amazon Quick의 해법은 단일 정책 메커니즘이 아닌 계층형 시행입니다. 광범위한 기본값이 안전성을 확립하고, 등록 및 그룹 이벤트가 사용자별 컨텍스트를 추가합니다.

이러한 결정을 문서화하는 팀에게는 검색 가능한 기술 지식 기반이 프로필 정의, 승인 기록, 사고 메모 및 운영 절차를 연결할 수 있습니다.

실질적인 다음 단계는 통제된 그룹을 대상으로 제한적인 프로필 하나를 테스트하는 것입니다. 적용 범위를 확장하기 전에 등록, 추가, 제거, 페이지네이션, 실패 로깅 및 대체 동작을 검증하십시오.

현재 프로세스가 모든 Quick 사용자가 정확히 어떤 프로필을 받는지, 그 프로필이 왜 우선하는지, 자동화가 실패하면 어떻게 되는지를 설명할 수 있습니까? 그렇지 않다면 네 가지 패턴을 통제 맵으로 활용하십시오. 기준선부터 시작하고, 과거의 공백을 해소하며, 비즈니스 컨텍스트가 실제로 필요한 경우에만 이벤트 기반 예외를 추가하십시오.