부스·전시 배정 시스템 개발 시 운영자·심사자·참가사 등 권한별 화면·메뉴·데이터 노출 범위를 정하는 설계 기준을 롤 정의, 권한 매트릭스, 행 수준 보안, 감사 로그 4단계로 정리했습니다.
- 결론 요약: 권한 설계는 '롤 정의 → 매트릭스 → 행 수준 보안 → 감사 로그' 순서로
- 준비물·전제조건: 롤 정의와 권한 매트릭스 설계법
결론 요약: 권한 설계는 '롤 정의 → 매트릭스 → 행 수준 보안 → 감사 로그' 순서로
지금까지 내용을 한 문장으로 압축하면 이렇다. 권한 설계는 화면을 그리기 전에 끝내야 하는 구조 결정이고, 순서는 롤 정의 → 매트릭스 → 행 수준 보안 → 감사 로그로 고정하는 편이 안전하다.
순서를 지켜야 하는 이유
매트릭스 없이 화면부터 만들면 두 번 일한다. "이 버튼을 심사자에게도 보여줘야 하는데"라는 요청이 개발 후반에 들어오면, 화면만 고치는 게 아니라 데이터 조회 단위를 다시 짜야 하기 때문이다.
4단계 요약표
| 단계 | 할 일 | 완료 판단 기준 |
|---|---|---|
| 1. 롤 정의 | 최고 관리자·운영자·심사자·참가사·일반 조회자 확정 | 각 롤의 담당자가 실명으로 지정됨 |
| 2. 매트릭스 | 배정 현황·신청 목록·결제 정보·부스맵 × 롤 교차표 작성 | 모든 교차 셀에 보임/숨김이 표시됨 |
| 3. 행 수준 보안 | 참가사는 자기 신청·자기 부스 데이터만 조회 | 타 참가사 데이터 조회 경로가 원천 차단됨 |
| 4. 감사 로그 | 열람·수정 이력 기록 설계 | 누가 언제 무엇을 봤는지 추적 가능 |
현장 장면으로 검증하는 법
준비물·전제조건: 롤 정의와 권한 매트릭스 설계법
권한 설계가 꼬이는 순간은 대부분 개발 중간이 아니라 발주서를 쓰기 전입니다. "운영자는 뭐까지 볼 수 있죠?"라는 질문이 나왔을 때 이미 롤이 흐려진 상태라면, 화면 설계가 다시 짜여야 하니 시간도 비용도 두 배로 듭니다. 그래서 이 섹션에서는 개발 착수 전에 반드시 정리해야 할 두 가지, 롤 정의와 권한 매트릭스 문서를 다룹니다.
롤을 나누는 기준은 두 축이면 충분합니다
"직급"이나 "부서"로 롤을 나누면 종류만 늘어나고 관리가 안 됩니다. 실무에서 통하는 기준은 두 축입니다.
- 데이터 열람 범위: 이 롤이 어떤 데이터를 볼 수 있는가
- 상태 변경 권한: 이 롤이 어떤 상태(신청→심사→배정→확정)를 움직일 수 있는가
이 두 축을 겹쳐 보면 다섯 개의 롤로 정리됩니다.
- 최고 관리자: 전체 설정 변경, 롤 생성·권한 부여까지 포함
- 운영자: 부스 배정 실행, 전체 신청 현황 열람
- 심사자: 신청 심사 화면만 노출. 결제 정보는 미노출
- 참가사: 자기 부스 정보와 신청 현황만
- 일반 조회자: 확정된 부스맵만 보기
단계별 구현: 행 수준 보안, 임시 배정 상태 관리, 배정 확정 프로세스 통제
단계별 구현: 행 수준 보안, 임시 배정 상태 관리, 배정 확정 프로세스 통제
부스 배정 시스템에서 가장 자주 터지는 사고는 해킹이 아니라 '보면 안 되는 화면을 먼저 보여주는 것'입니다. 임시 배정표가 담당자 화면에서 새어 나가 참가사가 자기 자리도 아닌 배정 현황을 미리 봐버리는 순간, "왜 우리는 코너입니까" 문의 전화가 사무국을 덮칩니다. 권한 설계는 이 사고를 원천 차단하는 일입니다.
1단계: 참가사는 '내 신청 건'만 보이게 — 행 수준 보안
참가사 계정으로 로그인하면 전체 배정 현황이 아니라 자기 신청 건만 조회되는 마이페이지 형태로 화면을 제한하는 게 첫 단계입니다. 같은 '참가사' 롤이라도 접근 권한은 화면 단위가 아니라 데이터 행 단위로 걸어야 합니다.
- 참가사: 신청 내역, 상태 안내, 결제 내역만 조회
- 운영자: 전체 신청·배정 현황, 임시 배정 화면 접근
- 최고 관리자: 배정 확정 승인, 권한 설정 변경
이 구조는 실제로 e-Regi가 학회 포털에서 운영하는 방식과 통합니다. 학회원 DB와 마이페이지가 분리되어 있고, 협찬사(파트너) 포털도 참가사가 QR 스캔으로 방문자 정보를 수집하는 자기 부스 중심 화면으로만 구성됩니다. 즉, 롤별 화면 분리는 검증된 운영 패턴이지 과한 보안이 아닙니다.
흔한 실수 vs 권장 기준: 민감 데이터 열람 제한과 보안 설계 (비교 표)
협찬사 담당자가 부스에서 태블릿으로 참가자의 QR을 스캔하는 장면을 떠올려 보자. 이 화면에서 연락처가 동의 체크 없이 보이는지, 동의를 전제로만 보이는지가 시스템 전체의 신뢰도를 가른다. 실제로 e-Regi 협찬사 포털은 QR 스캔만으로 개인정보 동의 기반의 방문자 연락처를 즉시 수집하는 구조다. 수집 속도보다 "동의를 통과해야 보이는 화면"이냐가 설계의 분수령이다.
발주 시 확인사항과 예방 체크리스트, 맺음말
발주 시 확인사항과 예방 체크리스트, 맺음말
권한 설계에서 가장 비싼 실수는 대부분 발주 단계에서 발생합니다. "관리자 화면이요, 적당히 나눠 주세요"라고 견적을 요청하면 개발사는 가장 넓은 범위를 잡아 견적을 책정할 수밖에 없고, 이후 요구사항이 구체화되며 범위 다툼이 생기기 쉽죠.
왜 견적 오차로 이어지는가
부스 배정 시스템의 개발량은 크게 세 변수에 묶여 있습니다.
- 롤 개수: 총괄 운영자, 부스 담당자, 협찬사 담당자, 일반 참관객 — 롤이 하나 늘 때마다 화면·검증 로직이 함께 늘어난다
- 롤별 화면 수: 한 롤이 보는 목록 화면, 상세 화면, 수정 화면의 조합
- 행 수준 보안 적용 범위: "협찬사는 자기 부스 방문자만 본다" 같은 규칙을 어느 데이터까지 걸 것인가
특히 행 수준 보안은 화면을 나누는 것보다 구현 난도가 훨씬 높아, 발주서에 "보안" 한 단어로만 적혀 있으면 견적이 크게 갈립니다. 감사 로그 필요 여부(누가 언제 배정을 바꿨는지 기록)도 같은 맥락에서 미리 확정해 두는 게 좋습니다.