학회 홈페이지 논문투고 결제 관리자 권한 설계 기준과 단계별 적용 가이드

결론 요약: 논문 투고 결제 권한은 '보는 권한'과 '움직이는 권한'을 나눠서 시작한다

논문 투고 마감 오후, 사무국으로 전화가 걸려 옵니다. "등록비를 결제했는데 취소하고 싶어요. " 전화를 받은 간사가 관리자 화면을 열었더니 조회 버튼 옆에 결제 취소 버튼이 나란히 보입니다. 권한 설계의 출발점은 바로 이 화면입니다. 비오케이솔루션 Society Website와 홍커뮤니케이션 통합 플랫폼은 논문 투고·결제·관리자 대시보드를 한 곳에 담아 주지만, 공개 자료 어디에도 관리자 권한 등급이나 역할 분리 기준은 명시되어 있지 않습니다. 즉, 이 영역만큼은 학회가 직접 설계해야 합니다.

판단 기준은 하나입니다. 그 버튼을 잘못 눌렀을 때 되돌릴 수 있는가. 되돌릴 수 없다면 움직이는 권한이고, 거기엔 이중 승인과 감사 로그를 붙입니다.

1. 최소 권한 원칙으로 역할별 매트릭스를 먼저 만든다 2. 결제 취소·환불·내역 수정은 이중 승인 + 감사 로그로 묶는다 3.

1단계: 역할별 권한 매트릭스 설계 - 최소 권한 원칙 적용하기

1단계: 역할별 권한 매트릭스 설계 - 최소 권한 원칙 적용하기

권한 설계를 이야기하기 전에 먼저 확인할 게 있습니다. 참고한 솔루션 레퍼런스 어디에도 논문 투고 결제의 관리자 권한 등급 기준이 명시돼 있지 않습니다. 즉, 이 부분은 솔루션이 아니라 학회가 직접 설계해야 하는 영역입니다. 대신 설계가 가능한 전제는 갖춰져 있는데, 비오케이솔루션의 학회 홈페이지 솔루션이 회원·행사·결제·논문 투고를 관리자 대시보드로 통합하고 있고, e-Regi처럼 정회원·준회원·학생회원 등급별 요금 자동 계산과 회원증번호 검증까지 지원하는 플랫폼이라면 역할별 위임의 기반은 이미 있다는 뜻이죠.

흔한 장면입니다. 사무국 실장이 투고료 결제 취소 요청을 받고, 총무도, 편집간사도 같은 관리자 계정에 들어가 확인하다가 누가 뭘 수정했는지 추적이 안 되는 상황이 생깁니다. 최소 권한 원칙은 이런 사고를 막는 장치로, "그 사람의 업무에 필요한 최소한의 동작만 허용한다"는 판단 기준입니다.

2단계: 환불 승인과 결제 내역 수정 권한 분리 - 이중 승인·감사 로그 설계

투고비를 카드로 두 번 결제했다는 회원의 전화, 이 전화 한 통이 권한 설계가 제대로 됐는지 드러내는 순간이에요. 흔한 구조는 사무국이 결제 내역 화면에서 취소 버튼까지 바로 누르는 것인데, 요청부터 실행까지 한 사람 손에서 끝나면 나중에 "이 건은 왜 취소됐죠?"라는 질문에 아무도 대답하지 못하게 됩니다.

요청 → 승인 → 실행, 3단계로 쪼개기

판단 기준은 하나입니다. PG사 취소 API를 호출할 수 있는 권한은 사무국 계정에 두지 않는 것. e-Regi처럼 NICEPAY·토스페이먼츠를 연동해 신용카드·카카오페이·네이버페이·가상계좌를 받는 환경일수록, 취소는 승인 완료 건에만 자동으로 열리는 구조여야 해요. 특히 가상계좌 건은 요청 접수 시점에 입금 완료 여부부터 화면에 표시되도록 하는 게 안전합니다.

감사 로그는 append-only

3단계: 개발사 유지보수 권한 위임과 정기 권한 검토 프로세스

3단계: 개발사 유지보수 권한 위임과 정기 권한 검토 프로세스

"홈페이지가 갑자기 결제 오류를 일으켰는데, 개발사 계정이 막혀 있어서 대응이 늦었다" — 이런 경험을 겪은 사무국이라면 반사적으로 개발사에 최고 관리자 권한을 상시로 넘기고 싶은 유혹을 느끼게 됩니다. 하지만 이게 바로 권한 관리에서 가장 흔히 빠지는 함정이에요.

학회 홈페이지 솔루션은 회원 DB, 논문 투고 내역, 결제 원본 데이터가 한 대시보드에 모여 있는 구조입니다. 홍커뮤니케이션이나 비오케이솔루션처럼 회원·행사·결제·논문 투고를 단일 플랫폼에서 통합 운영하는 만큼, 개발사 계정 하나가 모든 개인정보와 결제 이력에 닿게 됩니다. 문제는 이 상태가 몇 년씩 유지되면서 아무도 쓰지 않는 계정이 살아 있는 '권한 크리프'로 굳어진다는 점이에요. 계약이 끝난 뒤에도 계정이 남아 있으면, 사실상 통제 밖의 뒷문을 열어둔 것과 같습니다.

개발사 권한은 "상시 소유"가 아니라 "장애 대응 시에만 빌려주는 것"으로 설계하세요.

견적 요청 시 권한 설계 요구사항 명시 체크리스트와 요약

견적 요청서에 "관리자 권한 설계 잘 해주세요" 한 줄 적어 보낸다고 해서 원하는 결과가 나오진 않습니다. 개발사는 명시되지 않은 요구는 기본값으로 처리하거나, 후에 유지보수 항목으로 분류하기 쉽거든요. 그래서 이 섹션에서는 견적 단계에서 문서로 넘겨야 할 여섯 가지 권한 요구사항을 완료 기준과 함께 정리해 드릴게요.

참고로, 공개된 레퍼런스 자료만으로는 논문 투고 결제 권한의 공식 설계 기준(권한 등급, 역할 분리 규칙)이 명시된 곳은 없습니다. 그래서 아래 항목들은 학회 운영 관점에서 직접 정의해서 요구사항에 넣는 수밖에 없습니다. - [ ] ① 역할별 권한 매트릭스 문서화 지원 — 총무(결제 확인), 사무국(등록·명찰), 심사위원장(심사 배정) 등 역할별로 어떤 메뉴에 접근 가능한지 표 형태 문서를 인수인계 자료로 요구. 완료 기준: 역할 × 화면 × 가능한 작업이 한 장의 표로 정리되어 있을 것

• ② 이중 승인 워크플로우 — 환불·결제 취소 같은 민감 처리는 담당자 실행 + 별도 관리자 승인 2단계로. 완료 기준: 한 사람이 로그인만으로 환불을 끝까지 완료할 수 없는 구조일 것
• ③ append-only 감사 로그 — 누가, 언제, 무엇을 바꿨는지 기록이 수정·삭제 불가능하게.