관리자 권한 모델과 감사 이벤트의 행동 단위

여러 관리 애플리케이션이 하나의 인증·권한 플랫폼을 사용하고 있었습니다. 그런데 사용자 등록과 역할 할당이 얼마나 발생하는지, 어떤 기능이 사용되는지 같은 질문에 답할 일관된 기록은 부족했습니다.

디버깅 로그가 있어도 업무 행동을 같은 단위로 집계하기는 어려웠습니다. 감사 이벤트를 준비하면서 먼저 사용자와 역할, 조직·앱 권한이 어떻게 연결되는지 정리해야 했습니다.

역할 하나로 설명하기 어려운 권한

같은 사용자라도 조직과 애플리케이션에 따라 접근 범위가 달랐습니다. 사용자에게 역할을 부여한 것과 특정 앱에서 사용할 수 있는 기능도 바로 일치하지 않았습니다.

문서화할 때는 이 연결과 상속, 예외 권한을 함께 봤습니다. 메뉴를 볼 수 있다는 것과 서버에서 특정 변경을 수행할 수 있다는 것도 구분해야 했습니다.

사용자 생성과 역할 할당

사용자를 생성하는 행동과 생성한 사용자에게 역할을 부여하는 행동은 다른 기록입니다. 같은 작업자가 연달아 실행했어도 변경 대상과 결과가 다릅니다.

감사 이벤트에서는 수행한 사람인 Actor, 행동인 Action, 변경 대상인 Target을 나눠야 했습니다. 역할 할당이라면 사용자뿐 아니라 어떤 역할을 어느 조직·앱 범위에서 부여했는지도 알아야 그 기록을 해석할 수 있습니다.

이 구조를 정리하면서 사용자 생성, 역할 할당·해제, 앱 권한 연결, 조직 변경처럼 남길 행동을 구분했습니다.

이벤트와 지표의 관계

행동을 정의한 뒤에는 시도와 완료, 실패 중 무엇을 세는지도 정해야 합니다. API 호출 횟수를 그대로 사용자 생성 건수로 볼 수는 없습니다. 실패하거나 재시도한 요청이 섞일 수 있기 때문입니다.

감사 이벤트만 있으면 모든 KPI를 만들 수 있는 것도 아닙니다. 처리 시간이나 온보딩 완료율을 보려면 시작·종료 조건과 관련 이벤트를 더 연결해야 합니다. 이번 작업에서는 그 전에 필요한 권한 관계와 행동의 단위를 정리했습니다.

운영 화면과 로그의 연결

권한 모델을 정리하면 운영 화면이 어떤 사용자와 역할, 조직을 다루는지도 설명하기 쉬워집니다. 이후 로그에 사용자 맥락을 남기거나 감사 기록에서 변경 대상을 찾을 때 같은 관계를 사용할 수 있었습니다.

문서와 실제 권한이 계속 맞는지는 별도 관리가 필요합니다. 역할이나 예외 정책이 바뀌면 기록할 이벤트와 운영 화면도 함께 확인해야 합니다.

다음 글에서는 이 흐름과 연결된 애플리케이션·접근 로그의 구조화를 다룹니다.