학회·학술대회 등록비 결제 시스템 개발 시 관리자·운영자·심사위원·참가자 등 역할별 화면 노출 범위를 정하는 기준, 권한-화면 매트릭스 작성법과 최소권한 원칙 적용 방법을 정리했습니다.
- 왜 권한별 화면 노출 설계가 등록비 결제 시스템의 출발점인가
- 권한 설계의 전제 조건: 역할 정의와 최소권한 원칙
왜 권한별 화면 노출 설계가 등록비 결제 시스템의 출발점인가
학회 당일 아침 접수처를 떠올려 보자. 참가자는 스마트폰으로 등록비를 결제하고, 운영자는 태블릿으로 QR을 찍고 명찰을 뽑는다. 같은 시스템 안에서 벌어지는 일인데 화면은 전혀 다르다. 권한별 화면 노출 설계는 정확히 이 지점에서 출발한다.
결제 금액이 권한에서 갈리는 구조
e-Regi를 보면 참가자는 행사 확인·등록·결제 화면을, 운영자는 QR 출결·명찰·학회 관리 화면을 쓰도록 역할별 화면이 분리되어 있다. 단순히 '보기 편하게' 하려는 게 아니다. 정회원·준회원·학생회원별 요금 자동 계산과 회원증번호 검증이 참가자 화면 안에서 이뤄지기 때문에, 누가 어느 화면에 들어오는지가 곧 결제 금액과 개인정보 범위로 직결된다.
| 역할 | 주로 쓰는 화면 | 시스템이 제어하는 것 |
|---|---|---|
| 참가자 | 행사 확인·등록·결제 | 등급별 요금 자동 계산, 회원증번호 검증 |
| 운영자 | QR 출결·명찰·학회 관리 | 구역(세션·홀)별 출결 설정, 운영 중 구역 전환 |
| 심사위원·편집자 | 전자초록집 | 편집자·심사자 권한 분리 |
| 협찬사 | 파트너 포털 | QR 스캔 기반 동의 절차의 방문자 연락처 수집 |
권한 설계의 전제 조건: 역할 정의와 최소권한 원칙
권한 설계를 시작하기 전에 가장 먼저 해야 할 일은 화면 목록을 짜는 게 아니라 "이 행사에 실제로 존재하는 역할이 무엇인가"를 전부 적어내는 것입니다. 실무에서 권한 문제가 터지는 지점을 보면 대부분 역할을 빠뜨려서 생기는 경우가 많아요. 관리자, 참가자만 떠올리고 심사위원이나 협찬사를 나중에 끼워 넣다 보면, 화면 구조 자체를 다시 뜯어야 하는 상황이 옵니다.
비오케이솔루션이 프로젝트 착수 시 화면 구성, 기능 목록, 관리자 권한과 연동 범위를 먼저 확인하는 것을 1단계 작업 기준으로 삼는 이유가 여기에 있습니다. 순서가 반대로 가면 안 되는 거죐.
1단계: 행사에 존재하는 역할부터 전부 나열하기
학술대회 운영을 기준으로 보통 이 다섯 가지가 나옵니다.
- 관리자: 학회 관리, 등급·할인 규칙, 화면 노출 범위 설정까지 최상위 권한
- 운영자: QR 출결, 명찰 출력 등 현장 실행 중심 화면 (관리자 화면 전체는 불필요)
- 심사위원(심사자): 초록 심사 관련 화면만, 편집자 권한과 분리
- 참가자: 행사 확인·등록·결제 화면
- 협찬사 파트너: 리드 수집용 파트너 포털만, 내부 관리 화면은 완전히 차단
단계별 절차: 권한-화면 매트릭스 작성부터 화면·API 이중 제어까지
권한 설계는 머릿속으로만 정하면 반드시 새는 곳이 생깁니다. 비오케이솔루션도 프로젝트 착수 시 화면 구성·기능 목록·관리자 권한·연동 범위를 문서로 먼저 확인하는 걸 작업 기준 1단계로 제시할 정도로, "누가 어느 화면을 보는가"를 문서로 못 박는 게 출발점이에요.
1단계: 역할 × 화면 매트릭스부터 만든다
행에는 역할, 열에는 화면(메뉴)을 놓고 보기/편집/없음 세 가지로만 표시하세요. 실제 학술대사에서 나오는 역할로 그려보면 이렇습니다.
| 화면 | 운영자 | 참가자 | 심사위원 | 협찬사(파트너) |
|---|---|---|---|---|
| 결제·환불 내역 | 보기/편집 | 본인 등록내역·결제만 | 없음 | 없음 |
| QR 출결 관리(구역별) | 보기/편집 | 없음 | 없음 | 없음 |
| 명찰·학회 관리 | 보기/편집 | 없음 | 없음 | 없음 |
| 비공개 생중계 링크 | 관리 | 등록 참가자만 접속 | 등급에 따라 | 없음 |
| 전자초록집 | 편집자 권한 | 열람 | 심사자 권한(분리) | 없음 |
| 리드 수집(QR 스캔) | 관리 | 동의 후 노출 | 없음 | 보기/수집 |
이 표 한 장이면 개발사와의 상의가 절반으로 줄어듭니다. e-Regi처럼 QR 출결을 세션·홀별 독립 구역으로 운영하는 경우, "출결 구역 전환 권한은 누구"까지 표에 한 줄 추가해 두세요.
흔한 실수와 법적 확인사항: 개인정보보호법·전자금융거래법 관점
권한 설계에서 가장 위험한 순간은 시스템을 만들 때가 아니라 행사 현장에서 운영 중입니다. "이 사람 오늘부터 명찰 출력도 좀 봐주세요" 하고 자리에서 권한을 하나씩 추가하다 보면, 어느새 결제 내역 전체를 볼 수 있는 계정이 열려 있는 상황이 생깁니다.
운영 중에 벌어지는 대표 사고 유형
- 화면 숨김으로 권한 제어를 끝낸 경우 — 메뉴를 안 보여줄 뿐, 뒤에서 데이터에 접근되면 숨김은 권한이 아닙니다. URL이나 연동 화면으로 그대로 노출될 수 있어요.
- 승인 젝차 없는 임시 권한 변경 — 당일 인력 충원으로 접수·출결 담당을 늘리며 노출 범위가 계속 바뀌는 경우. 누가 언제 무엇을 바꿨는지 기록이 없으면 사고가 나도 원인 추적이 안 됩니다.
- 역할 간 화면 혼용 — 참가자용 등록·결제 화면과 운영자용 QR 출결·명찰 관리 화면이 섞여 있으면, 임시 인력이 참가자 결제 정보까지 들여다보게 됩니다. 역할별 화면 분리가 먼저입니다.
실제로 학술대회 플랫폼들을 보면 이 문제를 구조로 풀어놓았어요. e-Regi는 참가자는 등록·결제 화면을, 운영자는 QR 출결·명찰·학회 관리 화면을 쓰도록 역할별 화면 자체를 분리하고, 전자초록집은 편집자·심사자 권한 분리를 조정 가능 항목으로 제공합니다. "숨기는" 게 아니라 "보여줄 화면을 아예 나누는" 것이죠.
운영 중 권한 변경 절차와 최종 체크리스트
행사 당일 아침, 세션 홀이 바뀌었다는 연락과 협찬사 부스의 운영자 추가 요청이 동시에 들어오는 순간이 권한 관리의 위험 구간입니다. e-Regi처럼 구역(세션·홀)별 독립 출결 설정과 운영 중 구역 전환을 지원하는 플랫폼이라도, 누가 언제 무엇을 바꿨는지 기록이 남지 않으면 문제가 생겨도 원인을 되짚기 어렵습니다.
변경은 4단계로 끊어서 처리한다
AI·업무 자동화 설계와 같은 원리로, 사람이 확인할 단계와 자동으로 처리할 범위를 미리 나눠 두면 당일 혼란이 줄어듭니다.
1. 요청 — 변경 내용·사유