KPI를 뽑을 수 없었던 관리자 플랫폼
측정할 수 없으면 개선할 수 없다
이 플랫폼은 수만 명의 사용자가 매일 쓰고 있었다. 그런데 “이 플랫폼이 비즈니스에 어떤 영향을 주고 있는가?”라는 질문에 답할 데이터가 없었다.
- 하루에 사용자 등록이 몇 건 일어나는지
- 역할 할당이 평균 얼마나 걸리는지
- 어떤 기능이 가장 많이 쓰이고, 어떤 기능은 안 쓰이는지
- 파트너 온보딩 완료율이 얼마인지
로그는 있었지만, 그건 디버깅용 텍스트 로그였다. “유저 A가 유저 B를 생성했다”라는 비즈니스 행위를 구조적으로 추적하는 체계가 없었기 때문에, KPI라고 부를 만한 지표를 뽑아낼 수 없었다.
KPI를 뽑으려면 무엇이 먼저 필요했나
KPI는 “무엇을 측정할 것인가”를 정의해야 나온다. 그런데 이 플랫폼에서 “무엇”을 정의하려면 먼저 두 가지를 이해해야 했다:
- 권한 모델 — 누가, 어떤 맥락에서, 무엇을 할 수 있는가
- 행동의 단위 — “사용자 생성”과 “역할 할당”은 같은 행위인가, 다른 행위인가
이 두 가지가 정리되지 않으면 Audit Event를 설계할 수 없고, Audit Event가 없으면 KPI를 뽑을 수 없다.
권한 모델이 왜 복잡했나
| 계층 | 의미 | 왜 단순 RBAC로 보기 어려웠나 |
|---|---|---|
| 사용자 | 실제 로그인 주체 | 한 사람이 여러 운영 맥락을 가질 수 있다 |
| 조직 | 소속과 운영 범위 | 조직 단위 제약이 역할 의미를 바꾼다 |
| 역할 | 묶음 단위 권한 | 애플리케이션별 세부 권한과 1:1이 아니다 |
| 앱 권한 | 특정 관리 애플리케이션에서의 권한 | 동일 사용자라도 앱마다 다른 수준 |
사용자에게 역할 하나를 붙이면 끝나는 구조가 아니었다. 역할은 다시 애플리케이션별 권한과 연결되고, 그 권한은 조직 맥락 안에서 해석된다. 이 관계를 이해하지 않으면 “누가 무엇을 했는가”라는 질문 자체를 정확히 정의할 수 없었다.
당시 가장 큰 문제는 코드가 없어서가 아니라 전체 그림이 설명되지 않는 상태였다. 사용자, 역할, 조직, 애플리케이션별 접근 권한이 전부 시스템 안에는 있었지만, 누군가가 새로 들어와 빠르게 이해할 수 있는 형태로 정리되어 있지 않았다.
권한 모델에서 Audit Event 정의로
권한 모델을 정리하고 나니, “추적해야 할 행위”가 자연스럽게 도출됐다:
- Actor — 누가 행동했는가 (사용자 + 조직 맥락)
- Target — 무엇에 대해 행동했는가 (사용자, 역할, 앱 권한, 조직)
- Action — 어떤 종류의 변경이었는가 (생성, 수정, 삭제, 할당, 해제)
사용자 생성과 역할 할당은 이름만 비슷하지 실제로는 서로 다른 감사 대상이다. “사용자 A가 사용자 B를 생성했다”와 “사용자 A가 사용자 B에게 역할 X를 할당했다”는 Actor는 같지만 Target과 Action이 다르다. 이 구분이 있어야 의미 있는 지표가 나온다.
이것이 이후 설계에 미친 영향
이 정리가 단순한 문서화에서 끝나지 않은 이유는, 이후 Audit Event 시리즈 전체의 설계 입력값이 됐기 때문이다:
- Audit Event의 필드 표준(ActionType, TargetType, ActorType)이 이 모델에서 나왔다
- 구조화 로깅에서 MDC에 담을 사용자 맥락이 이 모델을 따랐다
- 감사 보고서에서 “누가 어떤 권한을 언제 부여했는가”를 쿼리할 수 있게 됐다
역할 계층이 깊어질수록 설명 비용도 같이 커지고, 운영에서 예외 권한이 생기면 정의와 현실이 벌어질 수 있다. 하지만 이 구조를 먼저 정리한 덕분에, 이후에는 “무엇을 추적하고, 무엇을 측정할 것인가”에 대한 공통 언어가 생겼다.
다음 글에서는 그 기반 위에서 구조화 로깅이 왜 단순 포맷 변경이 아니라 운영 모델 자체의 변화였는지 이어서 본다.