문의 응대 시스템 관리자 권한 설정: RBAC 및 보안 설계 가이드

단일 관리자 계정이 사고로 이어지는 이유: 권한 분할 전제조건과 ERD 구조

협찬사 부스에서 참가자가 QR을 스캔하면, 개인정보 동의 기반으로 연락처가 즉시 수집된다. 홍커뮤니케이션 e-Regi가 제공하는 파트너 포털의 핵심 동선인데, 여기서 모이는 데이터는 이름·전화번호·이메일이다. 이 포털에 접속하는 계정이 단 하나라면 — 담당자가 바뀌어도 같은 아이디로 로그인하고, 협찬사 직원도 그 비밀번호를 공유받는 상황이 된다.

계정 공유가 사고가 되는 순간

"지금은 괜찮아"라고 넘기다가 문제가 되는 지점은 세 곳이다.

• 열람 추적 불가: 퇴사한 담당자의 접속 기록이 남아 있어도, 실제 열람자가 누구인지 증명할 수 없다.
• 권한 과잉 노출: 결제 통계, 회원 DB, 논문 심사 데이터까지 단일 계정이 모두 열람 가능하면, 협찬사 담당자에게 불필요한 정보까지 열린다.
• 책임 소재 모호: 실시간 운영 대시보드의 참가 현황이 임의 수정됐을 때, "누가 언제 바꿨는가"를 특정할 수 없다.

RBAC 도입 전, 정리해야 할 전제조건

해결 방향은 사람이 아니라 역할에 권한을 부여하는 것이다. 이 구조를 도입하기 전에 선행해야 할 점검 항목은 다음과 같다.

흔한 권한 설계 실수 vs 권장 구조: 콜센터·운영자·최고 관리자 분리 기준

관리자 화면에서 특정 메뉴만 안 보이게 숨기는 걸 권한 제어라고 착각하는 경우가 참 많습니다. 현장에서는 콜센터 상담원이 주소창에 URL을 직접 쳐서 고객 결제 통계 화면에 들어가거나, 임시 배정된 운영자가 전체 학회원 DB를 엑셀로 다운로드하는 사고로 이어지기 일쑤입니다. 화면을 가리는 걸로 끝나선 안 됩니다.

목적별 계정 분리 기준

사용자의 역할에 따라 접근할 수 있는 데이터와 실행할 수 있는 액션을 명확히 나눠야 합니다. 학회 플랫폼이나 CRM 시스템 운영을 예로 들면, 목적별로 세 가지 권한으로 분리하는 구조가 안전합니다.

개인정보 보호와 감사를 위한 행위자별 데이터 통제 및 접근 로그 구현

"전체 조회"가 만드는 가장 흔한 사고

문의 응대 시스템에서 가장 많이 놓치는 위험 구간은 관리자 페이지 첫 화면이다. 담당자가 로그인하면 문의 목록이 한 화면에 펼쳐지고, 이름·연락처·문의 내용이 기본 노출되는 구조라면 이미 개인정보 보호 관점에서 치명적이다. 한 명의 계정이 유출되는 순간 전체 문의자의 데이터가 함께 노출되기 때문이다.

협찬사 부스에서 참가자 QR 스캔으로 개인정보 동의 기반 연락처를 즉시 수집하는 파트너 포털이 실제로 운영되는 환경이라면, 수집 주체와 조회 주체가 다를 때의 통제 설계는 선택이 아니라 필수다.

행위자별로 보이는 데이터를 다르게

핵심 원칙은 하나다. 화면에서 가리는 게 아니라 쿼리에서 거른다.

프론트엔드에서 숨기기만 하면 DOM 검사나 API 직접 호출로 드러난다. 데이터베이스 쿼리 단계에서부터 WHERE assigned_admin_id = current_user.id 조건을 걸어, 담당자에게 할당된 문의만 결과셋에 포함시켜야 한다.

MICE 행사 및 외부 인력을 위한 임시 권한 부여와 안전한 회수 절차

행사 당일 가장 많이 꼬이는 지점은 정규 관리자가 아니라 외부 인력이다. 협찬사 부스 담당자, 아웃소싱 상담원, 일손 보충을 위해 투입된 프리랜서까지, 하루아침에 시스템 접근 권한이 필요한 사람들이 몰린다. 이때 "일단 아이디 하나 만들어드려요"로 시작하면, 행사가 끝나도 그 계정은 살아있다.

e-Regi 플랫폼이 제공하는 협찬사(파트너) 포털은 정확히 이 문제를 해결하는 구조다. 정회원·준회원·학생회원 데이터가 있는 본운영자 화면과, 협찬사 부스에서 QR 스캔으로 방문자 연락처를 수집하는 화면이 아예 분리되어 있다. 외부 인력은 본 시스템이 아니라 서브도메인 기반 별도 포털에서만 활동하며, 개인정보 동의 기반 수집 범위 안에서만 데이터를 다룬다. 즉, 임시 권한의 핵심은 "어디까지 열어줄 것인가"가 아니라 "어떤 격리된 공간에서만 움직이게 할 것인가"다.

결론 및 요약: 권한 설계 체크리스트와 맞춤형 시스템 구축

지금까지 권한 분리의 원칙부터 데이터 통제, 접근 로그까지 살펴봤습니다. 마지막으로, 실무에 바로 적용할 수 있는 5가지 점검 항목으로 정리하겠습니다.

권한 설계 체크리스트

• 역할 기반 접근 제어(RBAC) 구조가 정의되어 있는가? — 정회원·준회원·학생회원처럼 등급별로 접근 범위와 요금 계산 로직이 분리되어 있어야 합니다.
• 개별 사용자 인증 체계가 이중으로 작동하는가? — PIN 인증, UID 화이트리스트처럼 역할뿐만 아니라 개별 식별까지 겹쳐서 검증해야 합니다.
• 데이터 조회·수정 권한이 화면 단위로 분리되는가? — 운영 대시보드는 전체 통계를 보되, 협찬사 포털은 QR 스캔으로 수집한 연락처만 조회하는 식으로 범위를 한정해야 합니다.
• 변경 이력이 추적 가능한가? — 버전 히스토리 기능으로 누가 언제 어떤 항목을 바꿨는지 남아야 사후 대응이 됩니다.
• 접근 로그를 정기적으로 검토하는가? — 실시간 모니터링 대시보드로 이상 접근을 즉시 포착하고, 엑셀 내보내기로 정기 보고 자료까지 만들 수 있어야 합니다.

맞춤형 시스템이 필요한 순간

체크리스트를 보면서 "지금 우리 시스템은 여기까지 못 한다"는 생각이 들었다면, 권한 분리를 처음부터 설계하는 편이 더 빠를 수 있습니다.