정보구조에서의 권한 관리 설계

앞선 글에서 정보구조의 핵심은 페이지이며, 메뉴는 폴더일 뿐이라는 점을 정리했습니다. 이제 그 위에 반드시 얹어야 할 구조가 하나 더 있습니다. 바로 권한 관리입니다. 많은 분들이 권한 관리는 화면설계서 단계에서 버튼을 막거나 메뉴를 숨기는 수준으로 다룬다고 생각하지만, 실제로는 정보구조 단계에서부터 구조적으로 설계할 수 있습니다.

즉, 정보구조 안에 ‘권한 그룹’이라는 개념을 하나의 구조 요소로 포함시키는 방식입니다. 페이지가 몇 개인지 정의하듯, 어떤 역할이 어떤 페이지에 접근할 수 있는지도 같은 레벨에서 정의하는 것입니다.

정보구조 단계에서 권한을 설계한다는 의미

권한 관리는 화면을 다 그린 뒤에 “이건 막고, 이건 열고” 식으로 덧붙이는 작업이 아닙니다. 정보구조를 정의하는 시점에서 이미 “이 페이지는 누구의 영역인가”를 함께 정리할 수 있습니다.
예를 들어 주문 관리, 상품 관리, 전시 관리가 각각 독립된 페이지 묶음이라면, 각 묶음에 대해 어떤 권한 그룹이 접근 가능한지 구조적으로 표시할 수 있습니다. 이 작업을 나중으로 미루면, 화면설계가 끝난 뒤에 권한 때문에 다시 수정이 반복되는 일이 발생합니다.

그래서 권한은 기능의 부속 요소가 아니라, 정보구조의 일부로 보는 것이 안정적입니다.

 

권한 그룹 개념 정의

정보구조 단계에서 설정하는 것은 “사람”이 아닙니다. “역할”입니다. 보통 다음과 같은 권한 그룹 단위를 정의합니다.

• 슈퍼 어드민
• 어드민 1
• 어드민 2
• 필요 시 운영자, CS 전용, 조회 전용 등

여기서 중요한 점은, 이 단계에서는 “홍길동이 누구인지”를 정의하지 않는다는 것입니다. 대신 “어떤 역할이 어떤 권한을 가진다”를 정의합니다.
즉, 개인을 정의하는 것이 아니라 역할 단위를 정의하는 것입니다. 이것이 구조적 설계입니다.

 

권한 그룹과 사용자 매핑 구조

권한 관리는 크게 두 단계로 나뉩니다.

• 첫 번째는 권한 그룹 정의입니다. 슈퍼 어드민, 어드민 1, 어드민 2 처럼 역할 단위를 시스템 기준으로 정의합니다.
• 두 번째는 사용자 매핑입니다. 예를 들어 홍길동은 어드민 1에, 성춘향은 어드민 2에 속하도록 연결합니다.

이 구조를 명확히 이해해야 합니다.

권한 그룹은 시스템 관점이고, 사용자는 운영 관점입니다. 시스템은 “누가 누구인가”보다 “어떤 역할이 무엇을 할 수 있는가”에 집중합니다.
이 두 개를 분리해 두지 않으면, 특정 사람이 이동하거나 조직이 바뀔 때마다 시스템 권한 구조까지 흔들리게 됩니다.

 

권한 그룹은 BO에서 처음 정의되는 것이 아니다

중요한 원칙이 하나 있습니다. 권한 그룹은 쇼핑몰이나 서비스 백오피스에서 처음 만들어지는 것이 아닙니다. 대부분의 조직에는 이미 인터라넷, 조직 관리 시스템, 인사 시스템이 존재합니다.
그 안에는 이미 다음 정보가 정의되어 있습니다.

• 이 사람이 누구인지
• 어떤 조직에 속해 있는지
• 어떤 역할을 맡고 있는지

백오피스는 이 구조를 가져다 쓰는 입장입니다.

백오피스는 사원이 누구인지 알 필요가 없습니다. 백오피스가 알아야 하는 것은 “이 권한 그룹이 무엇을 할 수 있는가”입니다. 
즉, BO는 사람을 관리하는 시스템이 아니라, 역할 기반 접근 제어 시스템입니다.

 

권한 설계의 목적은 접근 제어다

권한 설계의 목적은 단순합니다.

• 이 페이지에 들어갈 수 있는가?
• 이 화면에서 수정할 수 있는가?
• 조회만 가능한가?

이 세 가지를 제어하는 것입니다.

예를 들어 슈퍼 어드민은 모든 메뉴 접근 및 수정이 가능하도록 설정할 수 있습니다. 어드민은 본인 담당 메뉴만 수정 가능하도록 할 수 있습니다. 조회 전용 권한은 보기만 가능하고 수정 버튼은 비활성화됩니다.
이처럼 권한은 메뉴 접근과 수정 가능 여부를 구분하는 기준이 됩니다.

 

동시 접근과 동시 수정 문제

권한 설계에서 자주 마주치는 이슈가 있습니다. 여러 명이 동시에 같은 페이지를 수정하는 경우입니다. 예를 들어 슈퍼 어드민 A와 담당자 B가 동시에 같은 상품 수정 페이지에 들어간 상황을 생각해 볼 수 있습니다.

첫 번째 처리 방식은 가장 일반적인 방식입니다. 먼저 저장한 사람이 반영되고, 나중에 저장한 사람이 다시 덮어씁니다. 시스템은 이를 특별히 제어하지 않습니다. 구현이 단순하고 대부분의 시스템에서 사용하는 방식입니다. 운영 관점에서는 “최종 저장자가 책임자”라는 인식이 자연스럽게 형성됩니다.

두 번째 방식은 안내 메시지를 제공하는 방식입니다. 예를 들어 “현재 홍길동 님이 이 상품을 수정 중입니다.”와 같은 안내를 띄웁니다.
이 방식은 진입을 막지 않습니다. 수정 가능 여부를 제한하지도 않습니다. 단지 주의를 주는 역할만 합니다.

여기서 중요한 판단 기준이 있습니다. 진입 자체를 막는 방식은 바람직하지 않습니다. 사용자가 반드시 수정 목적으로 들어오는 것은 아닙니다. 단순 조회나 확인 목적일 수도 있고, 슈퍼 어드민은 관리 차원에서 접근할 수도 있습니다.

그래서 현실적인 설계 원칙은 이렇습니다.

1. 접근은 허용한다.
2. 수정은 책임 기반으로 한다.
3. 안내는 제공한다.

이 정도가 실무적으로 가장 합리적인 구조입니다.

 

실무 관점에서의 현실적인 전제

실제 운영 환경에서는 한 페이지를 동시에 여러 명이 적극적으로 수정하는 경우는 많지 않습니다. 슈퍼 어드민은 직접 수정하기보다 확인이나 관리 목적으로 접근하는 경우가 많습니다. 대부분의 수정은 담당자가 책임지고 수행합니다. 이 전제가 깔려 있기 때문에, 시스템은 지나치게 복잡한 동시 수정 제어를 두지 않고, 책임 기반 구조로 설계하는 것이 일반적입니다.

 

정보구조 단계에서 권한을 정의해야 하는 이유

권한이 명확히 나뉘어 있으면 화면설계 단계에서 충돌이 줄어듭니다. 예를 들어 상품 관리 페이지를 설계할 때 “이 버튼은 누가 누를 수 있는가”를 나중에 고민하지 않아도 됩니다. 이미 정보구조 단계에서 역할별 접근 범위가 정리되어 있기 때문입니다. 권한이 정리되지 않은 상태에서 화면을 설계하면, 이후 개발 단계에서 “이 메뉴는 누구에게 열려야 하죠?”라는 질문이 반복됩니다. 그리고 그때마다 설계 문서를 수정해야 합니다.

그래서 권한 그룹은 정보구조 단계에서 정의하는 것이 가장 안전합니다.

 

핵심 원칙 정리

1. 권한 그룹은 정보구조 단계에서 정의할 수 있습니다.
2. 사용자 정보와 권한 그룹은 반드시 분리합니다.
3. 백오피스는 사람을 관리하는 것이 아니라 역할을 기준으로 설계합니다.
4. 동시 수정은 차단보다 안내가 우선입니다.
5. 접근은 열고, 책임은 명확히 합니다.

정보구조에서 페이지와 메뉴를 구분하는 것이 기본이라면, 권한 설계에서는 사람과 역할을 구분하는 것이 기본입니다. 이 두 가지가 명확하게 정리되어 있으면, 화면설계 단계에서 구조적 충돌은 거의 발생하지 않습니다.