사용자·사업자·관리자가 한 플랫폼에 있을 때 권한 설계
서비스 기획 단계에서는 사용자용 앱과 관리자 화면을 나누는 일부터 시작하기 쉽습니다. 하지만 사용자, 사업자, 관리자가 하나의 플랫폼 안에서 같은 상품이나 주문, 정산, 문의 데이터를 다루는 구조라면 화면 구분만으로는 부족합니다.
문제는 출시 직전이나 운영 중에 드러나는 경우가 많습니다. 사업자가 다른 사업자의 주문을 볼 수 있거나, 일반 사용자가 관리자용 API를 호출할 수 있는 식입니다. 이때 화면을 숨기는 방식만 추가하면 잠시 보이지 않게 만들 수는 있어도 권한 경계 자체가 해결되지는 않습니다.
플랫폼 권한 설계는 개발 언어보다 먼저 결정할 제품 구조에 가깝습니다. 발주 전에는 역할 이름보다 어떤 리소스를 누가, 어떤 범위에서, 어떤 상태로 다룰 수 있는지부터 문서화해야 합니다.
역할 이름보다 데이터 접근 범위를 먼저 정한다
‘사용자’, ‘사업자’, ‘관리자’라는 명칭은 출발점일 뿐입니다. 실제 권한은 역할과 리소스의 조합으로 정의됩니다. 사업자라고 해도 자신이 등록한 상품만 관리할 수 있는지, 소속 지점의 상품까지 볼 수 있는지에 따라 필요한 설계가 달라집니다.
관련 항목은 먼저 주요 리소스를 목록으로 나눕니다. 예를 들면 계정·사업자 프로필·상품·주문·결제 상태·문의·정산 자료 등을 함께 보면 됩니다.
권한 설계의 기준은 ‘이 화면을 보여줄 것인가’가 아니라 ‘이 요청이 어떤 데이터를 어떤 조건으로 바꿀 수 있는가’여야 합니다.
역할과 테넌트, 리소스 스코프를 분리한다
여러 사업자가 입점하거나 조직 단위로 서비스를 사용하는 플랫폼이라면 테넌트 개념을 초기에 정리해야 합니다. 여기서 테넌트는 데이터가 소속되는 조직이나 사업 단위를 뜻합니다. 사업자 A가 만든 상품과 주문을 사업자 B가 조회할 수 없어야 한다면, API와 데이터 조회 조건에 이 소속 범위가 함께 적용되어야 합니다.
권한을 다음처럼 세 겹으로 나누면 논의가 선명해집니다.
관련 항목은 첫째는 역할입니다. 사용자인지·사업자인지·운영 담당자인지 구분합니다. 둘째는 행동입니다. 조회·생성·수정·승인·특정 테넌트인지·본인이 만든 데이터인지·담당자로 배정된 항목인지 정합니다. 등을 함께 보면 됩니다.
예를 들어 사업자가 주문을 조회할 수 있다는 문장은 부족합니다. ‘자신의 테넌트에 속한 주문을 조회할 수 있다’처럼 범위를 포함해야 합니다. 관리 담당자 역시 모든 사업자의 데이터를 볼 수 있는지, 담당 테넌트만 볼 수 있는지, 개인정보가 포함된 항목은 별도 승인이 필요한지 정해야 합니다.
이 구조를 요구사항에 반영하지 않으면 개발사는 화면별 예외 처리를 반복하게 됩니다. 초기에는 빠르게 보이지만 기능이 늘어날수록 권한 규칙이 여러 화면과 API에 흩어질 가능성이 커집니다.
API 경계에서 권한을 판정해야 하는 이유
모바일 앱이나 관리자 웹에서 버튼을 숨기는 것은 사용자 경험을 위한 처리입니다. 보안과 데이터 보호를 위한 최종 판정은 서버 API에서 이뤄져야 합니다. 화면에 버튼이 없더라도 요청을 직접 보내는 상황을 가정해야 하기 때문입니다.
발주 전에는 다음 질문을 개발사와 함께 정리하는 편이 좋습니다.
- 로그인한 계정의 역할은 어디에서 판정하는가
- 요청한 리소스가 어떤 테넌트에 속하는지 어떻게 확인하는가
- 본인 데이터와 다른 사용자의 데이터를 어떤 기준으로 구분하는가
- 승인이나 반려처럼 상태를 바꾸는 행동에 추가 조건이 필요한가
- 관리자 계정의 접근 기록을 어떤 수준으로 남길 것인가
API마다 역할 확인만 넣고 데이터 소속 검사를 빠뜨리면 역할은 맞아도 범위가 틀릴 수 있습니다. 반대로 데이터 소속만 검사하고 상태 변경 권한을 구분하지 않으면 조회 권한이 운영 권한으로 확대될 수 있습니다.
따라서 권한은 인증과 인가를 나눠 설계하는 것이 좋습니다. 인증은 ‘누가 요청했는가’를 판단하고, 인가는 ‘그 요청자가 이 리소스에 이 행동을 할 수 있는가’를 판단합니다. 두 단계가 요구사항과 API 목록에 함께 드러나야 개발 범위와 테스트 범위를 산정하기 쉽습니다.
관리자 권한과 감사 기록을 별도로 설계한다
관리자는 운영을 위해 넓은 접근 권한을 가질 수 있습니다. 그렇다고 모든 관리자가 같은 권한을 가져야 하는 것은 아닙니다. 운영 담당자, 정산 담당자, 콘텐츠 담당자처럼 업무에 따라 접근 범위를 나누면 실수 가능성을 줄이고 인수인계 기준도 세우기 쉬워집니다.
관리자가 특정 사용자나 사업자 화면을 대신 보는 기능도 주의가 필요합니다. 이른바 관리자 임퍼서네이션은 문의 대응이나 오류 재현에 유용할 수 있지만, 일반 로그인과 구분되지 않으면 누가 어떤 계정의 정보를 열람했는지 추적하기 어렵습니다.
이 기능을 고려한다면 최소한 접근 주체, 대신 본 계정, 시작과 종료 시점, 수행한 주요 행동을 기록하는 방향을 요구사항에 포함하는 것이 좋습니다. 개인정보나 정산 정보처럼 민감도가 높은 데이터는 별도의 접근 사유나 승인 절차가 필요한지도 함께 논의해야 합니다.
감사 기록은 문제가 생긴 뒤에만 보는 자료가 아닙니다. 운영 과정에서 반복되는 권한 요청을 파악하고, 관리자 역할을 다시 나누며, 유지보수 범위를 판단하는 근거가 될 수 있습니다. 다만 어떤 정보를 얼마나 오래 보관할지는 서비스의 데이터 정책과 운영 환경에 맞춰 정해야 합니다.
개발사 선정 전에 준비할 권한 문서
개발사에 문의하기 전, 복잡한 기술 문서까지 만들 필요는 없습니다. 대신 역할별 업무 흐름과 데이터 소속을 간단한 표나 문장으로 정리해 두면 견적과 일정의 편차를 줄이는 데 도움이 됩니다.
다음 항목을 준비하면 초기 상담이 구체적으로 진행됩니다.
- 플랫폼에 참여하는 역할과 각 역할의 실제 업무
- 주요 리소스와 리소스의 소속 단위
- 역할별 조회, 생성, 수정, 승인, 삭제 권한
- 사용자 본인 데이터와 조직 데이터의 구분 기준
- 관리자 계정의 세부 권한과 접근 기록 필요 여부
- 관리자 임퍼서네이션의 필요성 및 허용 범위
- 앱, 관리자 웹, API 중 권한 판정이 필요한 영역
- 출시 후 역할이나 조직이 추가될 가능성
이 자료가 있으면 개발사는 단순 화면 목록이 아니라 API, 데이터베이스, 관리자 웹, 모바일 앱을 함께 검토할 수 있습니다. 특히 Flutter 앱과 관리자 웹, API, 데이터베이스를 연결하는 프로젝트라면 권한 규칙을 화면별로 따로 적기보다 공통 정책으로 정리하는 편이 유지보수에 유리합니다.
플랫폼 권한 설계의 핵심은 역할을 많이 만드는 데 있지 않습니다. 누가 어떤 데이터에 접근하고, 어떤 행동을 수행하며, 그 사실을 어떻게 추적할지 경계를 먼저 고정하는 데 있습니다. 이 기준이 정리되면 개발사 선정 과정에서도 필요한 범위와 제외할 범위를 더 정확히 비교할 수 있습니다.
사용자·사업자·관리자의 권한 경계가 아직 화면 목록에만 머물러 있다면, API와 데이터 범위까지 포함해 발주 전 구조를 점검하는 상담이 필요합니다. 플랫폼 권한 설계와 관리자 운영 범위를 함께 진단하려면 https://www.universoft.kr/contact