초록 접수 시스템 권한별 화면 노출 범위 설정 기준 총정리

결론 먼저: 권한 설계는 '누가 무엇을 어디까지 보는가'를 표로 정하는 것부터

결론부터 말하면, 권한 설계에서 가장 어려운 건 코드가 아니라 정의다. "심사위원 화면"이라고 말하는 순간, 그 화면에 저자 연락처가 들어가는지, 결제 상태가 보이는지가 정해져 있지 않으면 개발은 매번 갈림길에 선다. 그래서 권한 설계의 출발점은 기능 목록이 아니라 역할 × 화면 × 데이터 필드의 3축을 표 하나로 못 박는 작업이다. 참고로 공개된 솔루션 자료 어디에도 역할별 화면 노출 범위의 구체적 기준은 명시돼 있지 않다. 다시 말해 이 표는 벤더가 주는 게 아니라 학회가 직접 만들어야 하는 문서다.

학회 홈페이지·논문 투고·심사·사전등록·결제를 단일 플랫폼에서 통합 운영하는 구조에서는 데이터가 한곳에 모이는 만큼, 권한 경계가 한 번 흐려지면 설정 실수 하나가 곧 개인정보 유출로 이어진다. e-Regi의 협찬사 포털이 참가자 QR 스캔으로 개인정보 동의 기반 방문자 연락처를 수집하는 e방명록을 제공하는 것도 같은 맥락이다. 그 연락처는 동의를 받은 주체에게만 보여야 하고, 그 경계는 개발 중에 정하는 게 아니라 착수 전에 정하는 것이다.

준비물과 전제조건: 역할 정의서와 권한 매핑 테이블 만들기

학회 사무국에서 가장 잦은 실수는 회원 등급을 권한처럼 쓰는 것입니다. e-Regi가 정회원·준회원·학생회원을 구분해 요금을 자동 계산하고 회원증번호를 검증하는 건 접수 자격과 요금 판단용이지, 심사위원이 어떤 화면을 볼지를 정하는 역할이 아닙니다.

단계별 절차: 화면 설계 → 개인정보 마스킹 → 상태 변경 권한과 감사 로그

단계별 절차: 화면 설계 → 개인정보 마스킹 → 상태 변경 권한과 감사 로그

권한 설계를 한 번에 다 하려면 반드시 꼬입니다. 역할 정의, 개인정보 처리, 상태 변경 권한이 한 테이블에서 뒤엉키기 때문이죠. 그래서 실무에서는 순서를 정해 놓고 한 단계씩 확정하는 게 정답에 가깝습니다. 아래 3단계 순서로 진행해 보세요.

1단계: 역할별 첫 화면을 먼저 못 박는다

시스템 설계에서 가장 먼저 정할 것은 "이 사람이 로그인했을 때 무엇이 보이는가"입니다. 첫 화면이 곧 권한의 경계가 되니까요.

• 참가자(저자): 마이페이지 — 내 초록, 등록·결제 상태 중심
• 심사위원: 배정된 초록 목록만 — 전체 접수 현황은 미노출
• 운영자: 대시보드 — 참가 현황·출결률·결제 통계 라이브 모니터링

여기서 한 가지 더 나눠야 합니다. e-Regi처럼 실시간 대시보드가 참가 현황과 결제 통계를 라이브로 보여 주고 엑셀 보고서 내보내기까지 되는 구조라면, 운영자 권한을 현장 운영용(당일 모니터링)과 사후 리포트용(보고서 추출)으로 분리하는 게 안전합니다. 결제 통계를 현장 스태프 전원이 볼 이유는 없으니까요.

2단계: 심사위원 화면은 필드 단위로 마스킹한다

흔한 실수 vs 권장 기준: 권한 오설정으로 인한 초록 유출·심사 오류 막기

심사위원 계정으로 로그인한 뒤 브라우저 주소창에 운영자용 URL을 직접 입력했는데 초록 목록이 쭉 펼쳐진다면, 그 시스템은 이미 사고를 예고하고 있는 셈입니다. 화면에서 메뉴를 지운 것과 데이터를 지킨 것은 전혀 다른 문제거든요.

• 메뉴·버튼만 감추고 URL 직접 접근은 그대로 허용된 구조
• 프론트에서 버튼을 숨겼을 뿐 API는 누구나 호출 가능
• 심사위원 화면에 전체 저자 목록이 그대로 노출돼 블라인드 심사가 무너지는 경우
• 초록 상태 변경 권한이 운영자 전원에게 열려 있어 누가 바꿨는지 추적 불가

판단 기준은 하나로 압축됩니다. "이 사용자가 이 데이터를 받아도 되는가"를 서버가 검증하는가. 화면은 개발자 도구 하나로 얼마든지 우회할 수 있어서, 데이터 반환 자체를 제한하지 않는 숨김 처리는 심리적 안심일 뿐입니다.

요약 체크리스트와 구현 방향: 권한 설계 검증 후 시스템 구축 들어가기

설계를 마쳤다면 이제 확인의 시간입니다. 권한 설계는 문서로 정리해두지 않으면 구현 단계에서 어긋나도 알아채기 어렵습니다. 개발자와 운영자가 서로 다른 기억으로 일하다 보면, 심사위원 화면에 저자 이름이 노출되는 사고는 대부분 이 시점에서 시작되죠.

최종 검증 체크리스트

권한 설계 문서를 다시 펴고 아래 항목을 하나씩 체크해보세요.

• 표준 4~5개 역할 정의 완료 — 저자, 심사위원, 운영자, 관리자(+필요시 분과 관리자)
• 화면·버튼·필드 단위 노출 범위 문서화 — "보이느냐/보이지 않느냐"를 버튼 하나까지 표로 정리
• 심사위원 저자 정보 마스킹 규칙 확정 — 이름, 소속, 이메일 중 무엇을 가릴지
• 채택/거절 권한 이관 경로와 감사 로그 설계 — 누가 언제 상태를 바꿨는지 흔적 남기기
• 분과별 중간 관리자 권한 위임 규칙 — 위임 범위와 상한을 미리 못 박기
• 서버 단 인가·API 보안 테스트 항목 통과 — 화면만 가리는 게 아니라 데이터 접근 자체를 차단
• 배포 후 역할별 화면 재검증 — 실제 계정으로 로그인해 눈으로 확인

실행 전 점검표