현장 체크인 시스템 개발 시 관리자·운영자·스태프 등 권한별 화면 노출 범위를 정하는 기준과 RBAC 롤-권한-화면 매핑 설계 방법을 단계별로 안내합니다. 데이터 민감도와 현장 동선 기준으로 안전한 권한 설계를 완성하세요.
- 결론 먼저: 권한 설계는 '데이터 민감도 × 현장 동선'으로 정한다
- 1단계 – 역할 정의와 데이터 분류: 무엇을 보여줄지 먼저 나눈다
결론 먼저: 권한 설계는 '데이터 민감도 × 현장 동선'으로 정한다
결론부터 말하면, 권한 설계의 기준은 직함이 아닙니다. 그 역할이 접근하는 데이터의 민감도(개인식별정보 → 결제 → 통계)와, 행사 당일 그 사람의 현장 동선(입구 → 홀·부스 → 사무국), 이 두 축의 교차점에서 정해야 합니다.
동선이 다르면 화면도 달라야 한다
입구 스태프의 최우선 과제는 QR 스캔으로 3초 이내 입장 처리를 끝내는 것입니다. 결제 통계나 참가자 명단이 같은 화면에 떠 있으면 스캔이 늦어지고, 동일 QR 재사용 차단 알림을 흘려보내기 쉽습니다. 반대로 사무국은 참가 현황·세션별 출결률·결제 통계를 행사 중 라이브로 봐야 하니 통합 대시보드 전체 권한이 필요하고요.
| 구분 | 입구 스태프 | 홀·부스 스태프 | 사무국·운영자 |
|---|---|---|---|
| 동선상 위치 | 입장 게이트 | 세션홀·부스 | 운영 본부 |
| 접근 데이터 | QR 유효 판정 결과 | 세션 출입 이력, e방명록 동의 연락처 | 결제 통계, 전체 참가 현황, 개인정보 |
| 필요 화면 | 스캔 결과 중심의 최소 화면 | 해당 세션 출결·방문자 목록 | 통합 콘솔 전체 |
| 노출하지 않을 것 | 결제·개인정보 목록 | 타 홀 현황, 결제 데이터 | — |
1단계 – 역할 정의와 데이터 분류: 무엇을 보여줄지 먼저 나눈다
체크인 시스템에서 사고는 대부분 "권한"이 아니라 "권한을 먼저 정하지 않은 것"에서 시작해요. 스태프가 결제 내역을 들춰보게 되거나, 운영자가 환불 버튼을 누르거나, 명찰 출력 화면에 연락처가 그대로 노출되는 식이죠. 그래서 첫 단계는 화면 설계가 아니라 역할 정의와 데이터 분류입니다.
역할은 '일하는 위치'로 나눈다
- 관리자: 학회 사무국처럼 전체를 쥔 사람. 요금 정책, 결제·환불, 통계 리포트까지 다 봅니다.
- 운영자: 홀·세션 단위로 움직이는 사람. 실시간 출결 대시보드(참가 현황, 세션별 출결률)를 보되 결제 원장은 열지 않게 합니다.
- 현장 스태프: 입구에서 QR 스캔, 키오스크에서 명찰·바우처 출력만. 참가자 목록 전체를 내려받을 권한은 주지 않습니다.
데이터는 민감도 등급으로 묶는다
역할을 정했으면 화면이 아닌 데이터 기준으로 노출 범위를 매핑하세요.
| 데이터 | 관리자 | 운영자 | 스태프 |
|---|---|---|---|
| 연락처·회원증번호 (개인식별) | 보기 | 마스킹 | 미노출 |
| 결제·환불 내역 | 보기·처리 | 미노출 | 미노출 |
| 입·퇴장 시간·세션별 출결률 | 보기 | 보기 | 해당 구역만 |
| 명찰·바우처 출력 데이터 | 보기 | 보기 | 출력만 |
2단계 – RBAC 구조화: 롤-권한-화면 매핑 테이블 설계
2단계 – RBAC 구조화: 롤-권한-화면 매핑 테이블 설계
"스태프한테 관리자 화면을 그냥 다 보여줬더니 참가자 정보를 잘못 수정했다" — 학회 현장에서 가장 흔한 사고가 여기서 시작됩니다. 1단계에서 정리한 역할 목록을 이제 시스템이 이해할 수 있는 구조로 바꿔야 합니다. 핵심은 롤 → 권한 → 화면을 각각 별도 테이블로 쪼개는 것**입니다.
권한은 화면이 아니라 '기능 단위'로 쪼갠다
메뉴 단위로 권한을 주면 "체크인 화면은 보여도 되는데 참가자 연락처는 보이면 안 된다" 같은 요구를 표현할 수 없습니다. 그래서 권한 코드는 기능 단위로 분리합니다.
CHECKIN_SCAN— QR 스캔으로 입장 처리 (동일 QR 재사용 차단 로직 포함)PII_VIEW— 참가자 개인정보(연락처·소속) 조회REFUND_EXEC— 결제 취소·환불 실행DASHBOARD_VIEW— 실시간 참가 현황·세션별 출결률 모니터링
같은 체크인 화면이라도 CHECKIN_SCAN만 가진 스태프는 이름·연락처가 마스킹된 형태로 보고, 사무국은 PII_VIEW까지 갖는 식으로 분리가 됩니다. e-Regi가 QR 스캔 3초 입장 처리와 동시에 회원증번호 검증까지 시스템 안에서 처리하는 것도 결국 "스캔하는 사람"과 "검증 규칙을 관리하는 사람"을 코드 단위로 나눴기 때문에 가능한 구조입니다.
3단계 – 사전 점검: 당일 체크인 지연을 막는 시뮬레이션과 오프라인 대응
행사 당일 지연을 만드는 건 대개 시스템이 아니라 계정이다. QR 스캔 한 번으로 3초 이내 입장 처리가 되도록 설계된 체크인도, 스태프 계정이 없거나 권한이 낮으면 접수대에서 그대로 멈춘다. 그래서 사전 점검은 '시스템 점검'이 아니라 역할별 계정으로 직접 해보는 리허설이어야 한다.
리허설은 역할 그대로 로그인해서
관리자 계정으로만 테스트하면 현장이 보이지 않는다. 체크인 스태프가 마주하는 화면 그대로 점검해야 진짜 걸리는 게 보인다.
- 관리자·체크인 스태프·홀 운영자 계정을 각각 만들어 실제 로그인
- 체크인 계정으로 QR 스캔 → 입장 처리 → 키오스크 명찰 출력까지 한 사이클 실행
- 동일 QR 재사용이 실제로 차단 안내로 이어지는지 확인
- 홀 운영자 계정은 세션 QR 입장 관리 화면과 대시보드만 노출되는지 확인
- 권한 오류 화면을 일부러 띄워보고, 상승 요청 → 승인 담당자 지정
판단 기준은 하나면 충분하다. 각 역할의 화면에서 필요한 동작이 막힘없이 되는가. 참가 현황과 세션별 출결률을 봐야 하는 사람에게 실시간 대시보드가 안 보이거나, 보면 안 되는 사람에게 보이면 권한 설계를 다시 짜야 한다.
4단계 – 권한 변경 이력 로그와 마무리 체크리스트
권한 설계의 마지막 관문은 '만든 것'이 아니라 '기록을 남기는 것'입니다. 아무리 화면 노출 범위를 정교하게 나눠도, 누가 어느 권한을 언제 바꿨는지 추적할 수 없으면 사후 감사나 분쟁 대응에서 힘을 잃습니다.
권한 변경 이력 로그, 무엇을 남길까
행사 직전에 "접수 담당자가 결제 내역까지 보인다"는 문의가 들어와 권한을 급하게 회수하는 일은 실제로 자주 벌어집니다. 이때 필요한 기록 단위는 다음 네 가지입니다.
- 변경 시점: 언제 부여·회수·수정됐는지 (행사 D-3인지, 당일 아침인지)
- 변경자: 누가 그 권한을 바꿨는지 (본인이 신청했는지, 관리자가 지정했는지)
- 대상 계정: 어느 운영 계정의 권한이 바뀌었는지
- 변경 전후 권한: 예컨대 '접수 조회만' → '접수 조회 + 현금 결제 처리'처럼 전·후 범위
이렇게 남겨두면 "행사 당일 오전에 누가 결제 취소를 했는지" 같은 추적이 화면 캡처나 증언 없이도 로그 한 줄로 끝납니다.