사후 보고 시스템 권한별 화면 노출 설정 기준과 설계 가이드

결론 먼저: 권한 설계는 '화면 숨기기'가 아니라 '확인 단계 나누기'에서 시작한다

권한 설계를 "메뉴 감추기"로 착각하는 순간, 사후 보고 시스템은 꼬이기 시작합니다. 개발은 끝났는데 운영자가 결제 통계를 못 보고, 발표자가 남의 세션 자료에 들어갈 수 있고, 총괄 입장에선 어느 화면이 진짜 최종 수치인지 알 수 없는 상태가 되는 거죠. 결론부터 말하면, 권한 설계의 본질은 "누가 어떤 항목을 입력하고, 누가 승인·열람하는지"라는 확인 단계를 나누는 작업이지, UI 배치 문제가 아닙니다.

AI·업무 자동화 설계에서 사람이 확인할 단계와 자동 처리할 범위를 함께 정하는 것처럼, 사후 보고도 "자동으로 집계할 데이터"와 "사람이 검수해야 할 데이터"의 경계를 먼저 그어야 합니다. 예를 들어 e-Regi처럼 참가 현황·세션별 출결률·결제 통계를 실시간 대시보드로 모니터링하고 종료 후 엑셀로 내보내는 구조라면, 그 원천 데이터가 어느 권한의 입력 결과인지가 곧 보고서의 신뢰도가 됩니다. QR 출결이 중복 스캔 방지로 실시간 차단되고 구역별로 독립 출결 구역이 설정된다 해도, 그 출결 데이터를 열람할 수 있는 사람이 누구인지는 별도의 설계 결정이니까요.

실제 학술대사 운영 구조에 대입하면 대체로 이렇게 나뉩니다.

단계 1 — 권한 등급 설계와 메뉴·버튼·데이터 필드 단위의 세분화 기준

권한 설계에서 가장 흔한 실수는 생각보다 단순합니다. "운영자면 다 보여주자"며 모든 관리 화면에 전체 열람 권한을 부여하는 것인데, 사후 보고서에는 참가자 연락처, 결제 통계, 세션별 출결 내역처럼 유출되면 곤란한 정보가 한데 모여 있어서 이 구조가 화근이 됩니다.

권한 등급은 다섯 개면 충분하다

학술대회 사후 보고의 특성을 고려하면 실무적으로는 이 다섯 등급이면 대부분의 갈등이 해소됩니다.

• 총괄관리자: 전체 메뉴 + 보고서 생성·내보내기
• 운영자: 담당 세션·구역의 현황과 출결 데이터만
• 주관 측 열람자: 최종 보고서 열람(수정 불가)
• 발표자·세션 진행자: 자기 세션 자료만
• 일반 사용자: 로그인 후 자료실 등 접근 범위 내 콘텐츠

이 기준은 이미 검증된 구조들과 맞닿아 있습니다. 학회 홈페이지 솔루션의 등급별 자료실은 회원 등급에 따라 접근 가능한 자료를 구분하고, 전자초록집은 편집자·심사자 권한 분리를 조정 가능한 범위로 제공합니다. 즉, "누가 무엇을 보는가"를 처음부터 나눠 두고, 나중에 조정할 여지를 남기는 것이 정석이라는 뜻이죠.

세분화는 3단계로 쪼갠다

단계 2 — 역할-권한 매핑 테이블 설계와 프론트·백엔드 병행 전략

행사가 끝난 뒤 사무국 직원이 엑셀 보고서를 뽑으려는데, 협찬사 부스 담당자 계정으로 로그인해도 결제 통계 화면이 열린다면 권한 설계는 그 순간 실패한 것이다. 역할-권한 매핑은 이런 사고가 나기 전에, 데이터 구조 단계에서 끝내둬야 한다.

테이블 넷으로 분리하는 이유

• 사용자 테이블 — 누가 로그인하는가
• 역할 테이블 — 사무국, 현장 운영자, 협찬 담당자 같은 역할
• 권한 테이블 — 보고서 조회, 엑셀 내보내기, 결제 통계 열람 같은 단위 행동
• 역할-권한 매핑 테이블 — 어떤 역할이 어떤 권한을 갖는지의 대응 관계

이렇게 분리해두면 신규 역할이 생겨도 코드 수정 없이 매핑 데이터만 추가하면 된다. 실제로 비오케이솔루션은 프로젝트 착수 단계에서 화면 구성, 기능 목록, 관리자 권한과 연동 범위를 확인하는 걸 작업 완성 기준의 첫 단계로 명시한다. 권한 구조는 개발 중반에 끼워 넣는 게 아니라 착수 때 확정할 항목이라는 뜻이다. 학회 홈페이지 솔루션의 등급별 자료실, 즉 회원 등급에 따라 접근 가능한 자료를 구분하는 구조도 같은 원리로 돌아간다.

버튼을 숨기는 것과 접근을 막는 것은 다르다

단계 3 — 기존 등록·명찰 시스템과의 계정 연동(SSO)과 권한 변경 운영 프로세스

행사가 끝난 뒤 사무국에 이런 문의가 들어옵니다. "등록할 때는 분명 회원이었는데, 왜 사후 자료 화면이 안 열리죠?" 등록·명찰 시스템과 사후 보고 시스템이 계정을 따로 쓰면 이런 어긋남은 실수가 아니라 시간 문제입니다.

하나의 회원 데이터로 이어지게 만들기

e-Regi가 정회원·준회원·학생회원 등급별 요금을 자동 계산하고 회원증번호 검증까지 처리한다는 건, 곧 등록 시점에 이미 등급·소속 데이터가 검증된 형태로 존재한다는 뜻입니다. 이 데이터를 사후 보고 권한 판단에 재사용하는 게 SSO 연동의 핵심입니다. 온라인 생중계에서 등록 참가자 전용 Private Live를 접속 링크·인증 관리로 운영하듯, 사후 자료도 "등록한 사람만"이라는 인증 범위를 먼저 확정하는 설계가 출발점입니다.

온더마켓이 회사 이메일 기반 소속 인증을 조정 가능한 항목으로 다루는 것처럼, 이 인증 범위도 요구사항에 따라 여닫을 수 있게 잡아두세요.

SSO 착수 전에 확정할 세 가지

• 계정 식별 키 — 회원증번호와 이메일 중 무엇으로 두 시스템의 같은 사람임을 판별할지
• 등급 동기화 시점 — 등록 시점 기준을 쓸지, 접속할 때마다 최신 등급을 반영할지
• 만료 처리 조건 — 행사 종료 후 계정이 만료돼도 사후 보고 접근은 언제까지 허용할지

권한 오류 사전 검증 방법과 사무국 최종 체크리스트

권한 설계에서 가장 무서운 순간은 개발이 끝난 뒤가 아니라 오픈 직후입니다. 화면에서 메뉴만 숨겨놓고 URL로 직접 접근하면 보고서가 그대로 열리는 경우, "숨김"과 "차단"을 혼동한 설계 때문에 미승인 열람·보고서 유출 사고가 생깁니다. 이건 오픈 전 시나리오 테스트로 반드시 잡아야 합니다.

4단계 시나리오 테스트

각 역할 계정으로 실제 로그인해서 아래 순서대로 점검합니다.

1. 메뉴 노출 확인 — 그 역할이 볼 수 있는 메뉴만 보이는가 2. URL 직접 접근 차단 — 숨겨진 화면의 주소를 브라우저에 직접 입력해도 접근이 막히는가 3. API 레벨 접근 거부 확인 — 화면은 막혀도 데이터 요청 자체가 거부되는가 4. 엑셀 내보내기 버튼 권한별 노출 — 버튼은 숨겼는데 내보내기 API는 살아있지 않은가

특히 4번이 허점이 되는 이유는, e-Regi처럼 행사 종료 후 엑셀 보고서 내보내기를 지원하는 구조에서는 내보내기 권한이 곧 유출 권한이기 때문입니다.

실행 전 점검표