화면마다 흩어진 권한 분기를 정책 레이어로 옮겨 변경 범위와 테스트 비용을 줄이는 설계 원칙을 정리합니다. 복잡한 기능 이름보다 먼저 확인할 것은 ‘주체’입니다. 로그인 사용자, 역할, 조직, 구독 상태처럼 권한 판단에 필요한 값을 작은 컨텍스트로 정리합니다. 화면이 저장소를 직접 조회하지 않게 합니다.
이 글의 범위
실제 경험이나 측정 결과를 가정하지 않고, 공식 문서로 확인 가능한 개념과 적용 순서를 일반 가이드로 설명합니다. 제품 버전과 서비스 정책은 바뀔 수 있으므로 적용 전 연결된 공식 문서를 다시 확인하세요.
판단의 출발점
공통 권한 레이어의 목적은 조건문을 한 파일로 옮기는 것이 아니라 정책 입력과 결정을 명확히 만드는 데 있습니다. ‘주체’에서 시작해 ‘대상’와의 경계를 정하면 구현할 범위와 실패했을 때 확인할 지점을 구분하기 쉬워집니다.
권한 정책 레이어에 모을 정보
주체
로그인 사용자, 역할, 조직, 구독 상태처럼 권한 판단에 필요한 값을 작은 컨텍스트로 정리합니다. 화면이 저장소를 직접 조회하지 않게 합니다.
대상
화면 이름보다 viewReport, editProfile처럼 기능 행위를 기준으로 권한을 정의하면 UI가 바뀌어도 정책을 재사용하기 쉽습니다.
환경
프로필, 지역, 점검 상태, 기능 플래그처럼 사용자 밖의 조건을 별도 입력으로 둡니다. 역할만으로 모든 예외를 표현하지 않습니다.
결정
허용 여부와 함께 이유 코드를 반환합니다. 로그인 필요, 기능 미제공, 권한 부족을 구분해야 안내 화면과 운영 로그가 정확해집니다.
기본 거부
알 수 없는 기능이나 누락된 컨텍스트를 임의로 허용하지 않습니다. 안전한 기본값을 쓰고 정상 경로에서 누락이 생기면 테스트가 실패하게 합니다.
 |
| 프로필별 권한 로직을 공통 레이어로 모으는 방법 핵심 판단 흐름 설명용 개념도 |
그림 1. 프로필별 권한 로직을 공통 레이어로 모으는 방법의 핵심 판단 순서를 정리한 설명용 개념도입니다. 실제 서비스 화면, 운영 로그 또는 측정 결과가 아닙니다.
중앙화가 실패하는 경우
- 거대한 한 함수에 모든 제품 규칙을 넣기
- UI 표시 여부와 서버 권한을 같은 것으로 믿기
- 권한 실패를 일반 네트워크 오류로 처리하기
- 클라이언트 Guard만으로 민감한 API를 보호했다고 판단하기
화면 조건문을 정책으로 옮기는 순서
- 화면별 조건문을 기능 행위와 상태 입력으로 분해합니다.
- 중복 규칙을 하나의 정책 함수로 합칩니다.
- 정책 결과에 이유 코드와 선택 가능한 대체 행동을 정의합니다.
- 화면은 결과를 렌더링하고 정책 결정은 수정하지 않게 합니다.
- 프로필·역할·상태의 경계값을 표 기반 테스트로 고정합니다.
운영 전 빠른 점검
| 확인 항목 | 질문 |
|---|---|
| 첫 기준: 주체 | 변경 전에 전제와 목적을 확인했는가? |
| 분리 대상: 대상 | 다른 책임과 섞이지 않게 경계를 정했는가? |
| 피할 패턴: 거대한 한 함수에 모든 제품 규칙을 넣기 | 본문에서 경고한 패턴이 남아 있지 않은가? |
| 오류와 복구 | 정상 경로뿐 아니라 실패와 되돌리기도 확인했는가? |
마무리
공통 권한 레이어의 목적은 조건문을 한 파일로 옮기는 것이 아니라 정책 입력과 결정을 명확히 만드는 데 있습니다. 클라이언트는 일관된 UX를 제공하고, 실제 데이터 권한은 서버에서도 같은 원칙으로 검증해야 합니다.
