수상 시상 관리 시스템 관리자 권한 설계 방법을 단계별로 정리했습니다. 역할 정의, 기능 권한 매핑, 조회 범위 설계, RBAC와 승인 워크플로우, 감사 로그까지 실무 기준을 확인해 보세요.
- 결론 먼저: 권한 분리의 핵심은 '심사'와 '확정'을 다른 사람이 나눠 갖는 것
- 단계 1~3: 역할 정의 → 기능 권한 매핑 → 조회 범위 설계
결론 먼저: 권한 분리의 핵심은 '심사'와 '확정'을 다른 사람이 나눠 갖는 것
시상식 일주일 전에 자주 벌어지는 장면입니다. 심사 점수를 집계하던 관리자가 화면을 잘못 눌러 미확정 수상자 명단이 홈페이지에 공개되고, 증서 파일이 협력사에 이미 전달된 뒤에야 발견하는 경우가 많습니다. 사고의 시작은 버그가 아니라, 한 계정이 평가 집계부터 확정·공개까지 모든 버튼을 들고 있었다는 구조 자체입니다.
판단 기준부터 확인하세요
다음 항목이 한 계정에 2개 이상 겹치면 그 시스템은 사고 예비 후보입니다.
- 평가 점수 입력·집계
- 수상자 확정
- 증서 출력
- 명예의 전당 등 공개 페이지 게시
- 관리자 계정 생성·삭제
표준 3역할 모델
| 항목 | 총관리자 | 심사운영자 | 시상담당자 |
|---|---|---|---|
| 전체 설정·계정 관리 | 가능 | 불가 | 불가 |
| 평가 집계·결과 조회 | 조회만 | 가능 | 불가 |
| 수상자 등록·확정 | 불가 | 불가 | 가능 |
| 증서 출력·명예의 전당 공개 | 불가 | 불가 | 가능 |
핵심은 '심사'와 '확정'을 다른 사람이 나눠 갖는 선 하나입니다. 심사운영자는 결과를 조회만 하고 확정 버튼이 없어야 하고, 시상담당자는 점수 원본에 손을 댈 수 없어야 서로가 서로를 확인해 주는 구조가 완성됩니다.
단계 1~3: 역할 정의 → 기능 권한 매핑 → 조회 범위 설계
시상식 이틀 전, 아직 확정되지 않은 수상자 명단을 홍보 담당자 계정이 그대로 꺼내 갔다면 어떻게 될까요. 시스템을 아무리 잘 갖춰도 누가 무엇을 보고 무엇을 바꿀 수 있는지 정의되지 않으면, 사고 가능성은 계정 수만큼 늘어납니다. 권한 설계는 아래 세 단계로 정리됩니다.
단계 1: 역할 정의 — 조직도가 아니라 실제 사람 명단부터
회의록이 아니라 지금 실제로 일하는 사람을 이름으로 적어보는 게 시작입니다. 한 줄씩 채워보세요.
- 총관리자: 수상 확정, 삭제 승인, 계정 권한 부여·회수
- 시상담당자: 수상자 등록·수정, 시상식 운영 자료 준비
- 사무국: 증서 발송, 개인정보 포함 전체 데이터 관리
- 홍보: 보도자료·명예의 전당 게시
- 심사위원: 본인 담당 분과 심사
"이 일은 누가 하지?"에 답이 안 나오는 항목이 있다면, 그게 곧 권한 구멍입니다.
단계 2: 기능 권한 매핑 — 되돌리기 어려울수록 승인을 더한다
판단 기준은 하나면 충분합니다. 한 번 실행하면 복구가 어려운 행위일수록 상위 승인 단계를 붙인다.
- 수상자 등록·수정: 시상담당자
- 수상자 삭제: 시상담당자가 요청하고 총관리자 승인으로만 실행
- 명예의 전당 공개: 별도 권한으로 분리
- 증서 출력: 별도 권한으로 분리
단계 4~5: RBAC·승인 워크플로우·감사 로그 설계와 견적 확인
시상식 리허설 직전, 수상자 명단에서 이름 하나가 빠져 있다는 걸 발견했다고 상상해 보세요. 누가 언제 무엇을 바꿨는지, 이전 명단은 무엇이었는지 아무도 대답하지 못한다면 그건 담당자 실수가 아니라 권한 설계 실패입니다.
한 계정이 전부 처리하면 생기는 일
등록부터 공개까지 한 계정으로 되는 구조는 편하지만, 그 대가는 명확합니다.
| 항목 | 단일 관리자 구조 | 2단계 승인 구조 |
|---|---|---|
| 수상자 확정 | 한 계정이 등록·수정·공개까지 | 심사운영자 제출 → 총관리자 승인 |
| 임의 변경·실수 | 즉시 반영, 흔적 불명확 | 승인 전까지 확정되지 않음 |
| 책임 소재 | 특정 개인에게 몰림 | 단계별 기록으로 분리됨 |
RBAC(역할 기반 접근 제어)는 이 문제를 사람이 아니라 역할 단위로 푸는 방식입니다. "심사운영자는 제출까지만, 총관리자는 승인과 공개까지"처럼 권한을 역할에 묶어두는 거죠. 담당자가 바뀌어도 계정에 역할만 다시 붙이면 되고, 수상자 확정은 반드시 두 사람을 거치게 됩니다.
흔한 실수 vs 권장 기준: 사고를 막는 운영 규칙
시상식 전날 밤, 아직 확정되지 않은 이름이 증서에 들어가 있는 걸 발견했다고 상상해보자. 이런 사고의 출발점은 대부분 해킹이 아니라 권한 설정의 빈틈이다. 심사위원이 "점수만 좀 볼게요" 하다 확정 버튼을 누르거나, 퇴직한 담당자 계정으로 미확정 자료가 출력되는 식이다.
4개 영역, 표로 비교하면 기준이 명확해진다
| 구분 | 흔한 실수 | 권장 기준 |
|---|---|---|
| 심사 | 심사위원이 시스템에서 직접 수상자 확정 | 평가 입력만 허용, 확정은 별도 승인 단계로 |
| 공개 | 증서 출력 권한으로 미확정 자료 유출 | 확정 완료 건만 출력·공개하는 조건부 권한 |
| 사후 | 오류 수정을 직접 덮어쓰기 | 로그 확인 후 롤백, 수정 이력 보존 |
왼쪽 열의 공통점은 한 사람이 여러 단계를 혼자 처리한다는 것이다. 공용 계정을 쓰면 누가 무엇을 했는지 로그가 한 명으로 몰리고, 심사와 확정 권한이 같으면 점수 집계 오류가 그대로 증서로 넘어간다.
참고로 관리자 페이지와 신청 데이터 관리가 포함된 구독형 솔루션, 실시간 대시보드가 있는 플랫폼을 쓰더라도 이 규칙이 없으면 사고는 막히지 않는다. 판단 기준은 도구가 아니라 규칙이다.
요약 체크리스트와 시스템 구축 시 현실적인 판단 기준
지금까지 역할 설계, 권한 분리, 계정 회수까지 살펴봤으니 마지막으로 한 번에 점검할 수 있는 기준을 정리해두겠습니다. 시스템을 도입하든 직접 만들든, 이 다섯 가지를 통과하지 못하면 심사일이나 시상식 전날 반드시 문제가 터집니다.
최종 점검 5가지
- 역할 3종 이상 분리 — 총괄 관리자 / 실무자 / 심사 위원(또는 부서 담당자)이 최소한 나뉘어 있는가
- 심사-확정 권한 분리 — 점수를 입력하는 사람과 수상자를 확정하는 사람이 다른 계정인가
- 부서별 조회 범위 제한 — 특정 부서 담당자가 다른 부서의 지원·심사 데이터를 열지 못하는가
- 감사 로그·롤백 포함 — 누가 언제 무엇을 바꿨는지 기록이 남고, 잘못된 확정을 되돌릴 수 있는가
- 계정 발급·회수 절차 문서화 - 심사 위원 계정을 언제 만들고 언제 회수하는지 문서 한 장이라도 있는가
이 중 하나라도 "아직이다" 싶은 항목이 있다면, 그 항목이 곧 상담할 때 가장 먼저 물어봐야 할 질문입니다.
맞춤 개발 vs 구독형 시작
처음부터 맞춤 개발로 모든 권한 구조를 만들면 초기 비용과 리스크가 커집니다. 반대로 이미 운영 중인 학술대회 데이터와 수상 관리를 붙이는 방식이면 안전하게 출발할 수 있습니다.