관리자 권한 설계 — 운영자가 사고 치지 않게
관리자 화면은 “우리 팀만 쓰는 내부 툴”로 취급되기 쉽습니다. 그래서 초기에 이렇게 만들어지는 경우가 많습니다.
관리자 계정 하나를 메신저로 공유합니다. 로그인만 하면 모든 메뉴가 열립니다. 삭제·환불·포인트 지급에 추가 확인이 없습니다. 퇴사자 계정이 그대로 남습니다. 누가 무엇을 바꿨는지 기록이 없거나, 있어도 보지 않습니다.
이 상태는 외부 해킹보다 일상 운영 실수와 내부 권한 남용에 취약합니다. 주문 상태 오변경, 회원 개인정보 과다 조회, 잘못된 일괄 업로드, 정산 금액 수정은 한 번의 클릭으로 매출·신뢰 이슈가 됩니다.
관리자 권한 설계의 목표는 운영을 못 하게 막는 것이 아닙니다. 사고 나지 않게 일하게 만드는 것입니다.
권한의 최소 단위: 역할·대상·행동
실무에서 쓰기 좋은 분해입니다.
| 개념 | 의미 | 예시 |
|---|---|---|
| 역할 | 직무 묶음 | 콘텐츠, 고객센터, 정산, 최고 관리자 |
| 대상 | 다루는 것 | 공지, 주문, 회원, 배너, 정산 |
| 행동 | 허용 연산 | 조회, 생성, 수정, 삭제, 내보내기, 환불 |
“관리자 / 일반” 두 칸만 있으면 조직이 커질수록 권한이 과해집니다. 처음부터 아주 세밀할 필요는 없어도, 메뉴 단위로 조회와 수정을 나누는 정도는 첫 버전에도 넣는 편이 재작업 비용이 작습니다.
흔한 관리자 사고 유형
- 공유 계정: 책임 추적이 어렵고, 유출 시 전원 비밀번호 변경이 어렵습니다
- 과권한: 콘텐츠만 올리는 담당자가 회원 전체 엑셀·주문 환불까지 가능합니다
- 삭제·일괄 작업 무방비: 확인 창만 있고 복구·감사 기록이 없습니다
- 개인정보 화면의 편의 우선: 목록에 전화·주소가 전부 노출됩니다
- 환경 혼동: 운영 관리자 주소로 시험 데이터를 조작합니다
- 외부 인력 임시 권한 미회수: 제작·마케팅 대행 계정이 오래 남습니다
작아도 지키는 설계 원칙
- 최소 권한: 업무에 필요한 메뉴·행동만
- 직무 분리: 가능하면 요청(예: 환불 접수)과 승인(환불 실행)을 나눔
- 개인 계정 + 조직 소유 이메일: 공유 계정 금지
- 위험 행동 강조: 삭제·환불·일괄 변경·권한 부여는 일반 저장과 다르게, 가능하면 재확인·사유 입력
- 감사 기록: 누가·언제·무엇·이전값·이후값 (민감정보는 가림)
- 세션·만료: 오래 비활성 시 로그아웃, 퇴사 시 즉시 비활성
- 내보내기 통제: 엑셀 다운로드 권한·건수·사유를 별도 취급
역할 예시 (쇼핑몰·예약·콘텐츠형 공통)
| 역할 | 허용 예 | 금지 예 |
|---|---|---|
| 콘텐츠 | 배너·공지·FAQ | 주문 환불, 회원 전체 추출 |
| 고객센터 | 주문·예약 조회, 상태 메모 | 정산 단가 수정, 권한 관리 |
| 마케팅 | 쿠폰·캠페인 (정책 범위 내) | 서버 설정, 데이터 직접 조작 |
| 정산 | 정산 조회·마감 | 임의 재고 조작 (정책에 따라 분리) |
| 기술·최고 | 설정·권한·배포 연계 | 일상 고객센터 대행 계정으로 공유 사용 금지 |
업종마다 이름은 달라도, “조회만 하는 사람”과 “돈을 움직이는 사람”을 한 계정에 섞지 않는 것이 핵심입니다.
화면 설계도 보안입니다
권한은 서버 기능에서 강제해야 합니다. 메뉴만 숨기고 뒷단이 열려 있으면 우회됩니다. 동시에 화면도 사고를 줄입니다.
- 위험 버튼의 색·위치·확인 문구를 일반 저장과 다르게
- 일괄 작업 전 영향 건수 미리보기
- 검색 기본값을 “전체 기간 전 회원”처럼 과도하게 넓히지 않기
- 연락처는 가리고, 필요 시 재확인 후 전체 보기
- 시험 데이터와 운영 데이터를 주소·배지로 구분
여러 매장·입점이 있으면 한 겹 더
여러 지점·입점사가 있는 경우 권한은 메뉴뿐 아니라 데이터 범위로 제한되어야 합니다. A 매장 관리자가 B 매장 주문을 보면 이미 사고입니다. 데이터 격리 설계와 함께 봐야 합니다.
왜 “나중에 붙이기”가 비싼가
오픈 후 권한을 쪼개면 기존 화면·기능 전수에 검사를 추가하고, 운영 중 계정을 옮기고, “예전엔 됐는데” 저항을 맞습니다.
초기 제작에 역할 표, 메뉴 연결, 서버 검사, 감사 기록 뼈대만 있어도, 이후 역할 추가는 설정 작업에 가깝습니다.
자주 하는 선택이 만드는 결과
- 공유 최고 관리자 유출: 전체 회원·주문·콘텐츠 일괄 위험
- 고객센터 과권한 환불 실수: 매출·재고·정산 불일치
- 기록 없음: 내부 조사·고객 분쟁 시 입증 불가
- 퇴사자 계정 잔존: 장기 미인지 접근
- 메뉴 숨김만 구현: 기술에 익숙한 사람이 기능을 직접 호출 가능
이렇게 준비하면 좋아요
- □ 관리자 계정이 개인별로 발급되는가 (공유 계정 없는가)
- □ 역할별로 메뉴와 기능이 모두 제한되는가 (화면만 숨김이 아닌가)
- □ 환불·삭제·일괄·권한 변경에 추가 확인 또는 승인 흐름이 있는가
- □ 개인정보 조회·다운로드에 별도 권한과 기록이 있는가
- □ 퇴사·계약 종료 시 계정 회수 절차가 있는가
- □ 운영·시험 관리자 주소와 계정이 분리되어 있는가
- □ 위험 행동 기록을 누가 주기적으로 보는지 정해져 있는가
- □ 멀티 매장·입점이면 데이터 범위 제한이 서버에서 강제되는가
- □ 초기 최고 관리자 비밀번호·추가 인증 정책이 문서화되어 있는가
LB Contents는 쇼핑몰·예약·콘텐츠·플랫폼형 관리자를 만들 때 역할·메뉴·위험 행동·감사 기록을 운영 실무에 맞게 설계합니다. “관리자는 내부용이니 나중에”가 걱정된다면, 권한 구조를 포함한 범위로 상담할 수 있습니다.