심사 배정 시스템 관리자 권한 분리 및 보안 구현 가이드

심사 배정 시스템 권한 설계: 최고관리자·운영자·심사위원장 역할 정의

일괄 권한이 만드는 가장 위험한 순간

논문 심사가 한창 진행 중인 학회 현장에서, 한 명의 운영자 계정이 점수 수정 로그까지 열람할 수 있다고 가정해 보자. 배정 실수가 의심될 때 누군가 점수를 다시 들여다봐야 하는데, 그 권한을 가진 사람이 곧 점수를 바꿀 수 있는 사람이다. 감시자와 수정자가 동일인이면, 사고가 나도 추적이 안 된다. 이것이 권한을 일괄 부여했을 때 가장 먼저 깨지는 지점이다. 논문 점수 변조, 심사위원 정보 유출, 미배정 논문 목록 외부 노출 — 이 위험들이 한꺼번에 존재하는 이유는 시스템이 "관리자"라는 단일 계정층으로 모든 데이터 접근을 허용하기 때문이다.

학회 홈페이지 솔루션이 회원관리·논문 투고·심사·결제를 단일 플랫폼에서 통합 운영하는 구조라면, 권한 설계도 그만큼 정교해야 한다. 통합 플랫폼일수록 한 계정이 닿을 수 있는 데이터의 범위가 넓기 때문이다. 아래 세 역할은 데이터 접근 최소화 원칙을 기준으로 나눈 것이다.

운영자별 특정 학회 및 트랙 조회 제한 기획과 DB 백엔드 제어

대규모 학술대회라면 학회가 여러 개로 쪼개지거나 부서(트랙)가 분리되기 마련입니다. 이때 다수의 서브 관리자가 동시에 접수 창구와 심사 배정 화면에 접속해서 작업하게 됩니다.

이 상황에서 가장 흔히 하는 실수가 "이 운영자는 A트랙 담당이니, A트랙 메뉴만 보이게 UI를 숨기자"라고 기획하는 것입니다. 화면 단에서 버튼을 지우는 것만으로는 보안이 절대 완벽해지지 않습니다. 직접 API 주소를 호출하면 타 학회의 논문 할당 내역이나 점수 데이터가 그대로 노출될 위험이 있기 때문입니다.

프론트엔드 숨김 vs DB 백엔드 강제 필터링

결국 데이터를 안전하게 보호하려면 백엔드와 데이터베이스(DB) 수준에서 접근을 통제해야 합니다. 운영자가 로그인할 때 부여받은 고유 ID와 Role(역할) 값을 기준으로, 특정 학회나 트랙의 민감 정보를 쿼리 단에서부터 강제로 걸러내는 방식입니다.

권한 기반 프론트엔드 메뉴 노출 제어(UI/UX) 구현 방식

단순 숨김을 넘어선 '우회 접근 차단' 설계

운영자가 대시보드에 로그인하는 순간, 화면에 보이는 메뉴와 버튼이 제각각이어야 합니다. 예를 들어 심사위원 계정에는 '참가 현황'이나 '결제 통계' 대시보드 대신 본인에게 배정된 논문 파일 다운로드와 채점 입력 폼만 노출되는 식이죠. 하지만 프론트엔드에서 단순히 버튼을 숨기는 것(visible: false)만으로는 부족합니다. 주소창에 직접 경로를 입력하거나 숨겨진 버튼을 강제로 누르는 우회 접근을 원천적으로 막아야 하기 때문입니다. 따라서 권한에 따른 UI 렌더링은 프론트엔드의 시각적 제어와 백엔드의 데이터 접근 제어가 동일한 기준(RBAC 상태)으로 묶여 있어야 합니다.

회원 등급(정회원, 준회원, 학생회원)에 따라 요금을 다르게 계산하고 회원증번호를 검증하는 것처럼, 관리자 페이지 역시 계정의 역할에 따라 접근 가능한 액션을 엄격히 분리해야 합니다. - 심사 배정 버튼: 논문 투고 현황과 심사위원 DB를 모두 볼 수 있는 '총괄 운영자' 권한에서만 활성화합니다. - 점수 통계 대시보드: 세션별 출결률과 결제 통계를 라이브 모니터링하는 콘솔은 주최 측 핵심 운영자에게만 노출합니다. - 논문 파일 다운로드: 해당 논문의 배정 심사위원에게만 개별 다운로드 권한을 부여하고, 목록 자체를 분리해 렌더링합니다.

흔한 실수 vs 권장 기준: 운영 중단 없는 유연한 권한 그룹(RBAC) 확장

"이번 학회부터 트록가 하나 더 늘었는데, 권한 설정을 어디서 바꿔야 해요?" 개발자에게 이런 연락이 가면, 이미 늦었다. 코드를 열어 조건문을 추가하고, 다시 배포하고, 테스트하는 사이 행사 준비 일정은 멈춘다.

하드코딩이 만드는 전형적인 병목

운영자 등급을 if (user.role == "admin") 같은 고정 조건으로 분기해두면, 학회가 늘어날 때마다 코드가 부풀려진다. 부서 추가, 신규 트랙 개설, 협찬사 포털 분리 — 어느 하나 그냥 넘어가지 않는다.

결국 매번 개발자를 끌어들여야 하니, 운영자가 스스로 권한을 조정할 수 없는 구조가 된다.

코드 수정 없이 Role을 추가하는 구조가 기준

결론 및 체크리스트: 심사 배정 보안 강화를 위한 데이터 연동

결론 및 체크리스트: 심사 배정 보안 강화를 위한 데이터 연동

심사 배정 시스템에서 가장 위험한 순간은 같은 논문에 두 명의 심사위원이 동시에 접근할 때다. 한 사람은 점수를 수정하고, 다른 한 사람은 화면을 새로고침하면 — 어느 쪽 데이터가 '정답'인지 시스템이 판단하지 못한다. 이 충돌이 현장에서 발견되면 이미 늦다.

• 역할 분리 — 심사위원, 사무국, 최종 관리자의 권한이 각각 다른 메뉴에 도달하는가? 심사위원이 타 심사위원의 배정 현황을 볼 수 없어야 한다. - [ ] DB 접근제어 — 관리자 페이지에서 회원등급(정회원·준회원·학생회원)별로 요금 자동 계산과 회원증번호 검증이 분리되어 작동하는가? 접수 데이터와 심사 데이터가 같은 테이블에서 뒤섞이지 않는가? - [ ] 동시성 충돌 방지 — 두 관리자가 동시에 배정을 변경할 때 잠금(Lock) 처리나 버전 관리가 작동하는가?