등록비 결제 시스템 개발, PG 연동 전 검색과 필터를 먼저 설계해야 하는 이유

결제 연동 전, 검색·필터를 선설계 해야 하는 구조적 이유와 DB 스키마

"결제 모듈부터 빨리 붙여버리죠." 개발 초기에 가장 많이 하는 놓치는 포인트다. 신용카드, 카카오페이, 네이버페이까지 쭉 연동해두면 끝날 것 같지만, 학술대회의 등록비는 단일 가격이 아니다.

정회원, 준회원, 학생회원 등 회원 등급에 따라 요금이 다르고, 조기등록 기간이 지나면 자동으로 할인이 풀려야 한다. 이 조건들을 결제창이 뜨는 순간에 일일이 계산하려고 하면 참가자 데이터가 어긋나고, 결제가 완료된 뒤에야 요금 오류를 발견하는 참사로 이어진다.

데이터 파편화를 막는 결정적 분기점

PG 연동 화면을 열기 전에, 참가자의 상태를 식별하는 검색·필터 로직과 DB 스키마가 먼저 세팅되어야 한다. e-Regi 같은 학술대회 통합 운영 플랫폼이 등록·결제 단계에서 등급별 요금과 조기등록 할인을 자동으로 계산하는 이유도 바로 이 선행 구조 덕분이다.

결제 누락 및 중복 방지를 위한 사전 필터링 로직과 검증 단계

결제 누락 및 중복 결제를 막는 사전 필터, 어디까지 짚어야 할까

현장에서 가장 당황스러운 순간은 결제 오류 신고가 들어올 때다. "결제했는데 등록이 안 됐다고요?", "같은 금액이 두 번 빠졌어요" — 이런 문제의 대부분은 결제창을 띄우기 전 검증 단계가 빠져 있어서 발생한다.

PG 연동은 NICEPAY·토스페이먼츠를 통해 신용카드, 카카오페이, 네이버페이, 가상계좌까지 실시간으로 처리된다. 하지만 결제 수단이 많을수록 중복과 누락의 변곡점도 늘어난다. 특히 글로벌 컨퍼런스 외국인 참가자나 법인 다수 결제 건이 겹치면, 사후 정정에 드는 시간과 인력이 결제 자체보다 큰 비용이 된다.

결제창 호출 전, 반드시 거쳐야 할 3단계 사전 필터

첫째, 이메일·식별번호 기준 중복 확인이다. 같은 참가자가 조기등록 마감 직전 두 번 결제를 시도하거나, 동료가 대리 결제를 진행하는 경우가 잦다. 결제창이 열리기 전에 동일 이메일·식별번호로 미결제 내역이 존재하는지 먼저 걸러야 한다.

둘째, 회원 등급별 요금 자동 계산 검증이다. 정회원·준회원·학생회원 등급에 따라 요금이 다르고, 조기등록 할인까지 자동 적용된다. 하지만 등급 데이터가 어긋나거나 할인 구간이 중첩되면, 결제 금액 자체가 틀린 채로 결제가 진행된다. 결제창 호출 전 노출 금액과 등급 기준표가 일치하는지를 확인하는 조건문이 필요하다.

현장 운영 리스크 최소화: 흔한 실수(결제 위주) vs 권장 기준(필터 위주 설계)

행사 당일 접수대 앞에 긴 대기줄이 생기는 가장 흔한 원인은 바로 "결제는 됐는데 명단에는 없다"는 상황입니다. 참가자는 카카오페이나 가상계좌로 결제를 끝냈는데, 현장 검색 화면에서는 해당 내역이 보이지 않아 막판까지 확인해야 하는 혼란이 벌어지죠. 이런 문제는 결제 수단 연동만 서두르고, 결제 내역과 참가자 명단을 매칭할 검색·필터 설계를 뒤로 미뤘기 때문에 발생합니다. ### 결제가 끝났는데 왜 명단이 없을까? 학술대회나 행사에서는 정회원, 준회원, 학생회원처럼 회원 등급별로 요금이 다르고 조기등록 할인까지 겹칩니다. 이 복잡한 조건을 시스템이 정확히 계산해서 보여줄 필터가 세팅되어 있지 않으면, 결제 게이트웨이(PG)사로 들어온 입금 데이터와 행사 등록 명단이 제각각 엮이게 됩니다. 단순히 신용카드나 계좌이체 결제 창만 열어두는 것보다, 참가자의 상태를 조건별로 걸러내는 명단 관리 체계를 먼저 세워야 현장 리스크를 막을 수 있습니다.

흔한 실수와 권장 기준을 비교해보면, 개발의 무게중심이 어디에 있어야 하는지 명확해집니다.

학회·MICE 관리자 페이지 필수 조회 조건과 시스템 비용 평가 기준

관리자 화면에서 가장 많이 헷갈리는 순간은 "이 사람 돈 냈나, 안 냈나?"를 확인할 때다. 신용카드로 결제했는데 시스템엔 '미결제'로 떠 있거나, 가상계좌 입금이 완료됐는데 접수 번호가 안 붙어 있으면 현장 접수대가 곧바로 멈춘다. PG 연동을 먼저 고민하기 전에, 사무국이 어떤 조건으로 참가자 명단과 결제 내역을 조회할지를 정의하지 않으면 이런 문제가 반복된다.

필수 조회 조건 — 사무국 체크리스트

결제 상태를 기준으로 명단을 불러오려면, 최소한 아래 항목이 관리자 페이지에서 독립적으로 검색·필터링되어야 한다.

• 결제 상태별 조회 — 대기·완료·취소·환불을 한 번에 구분
• 접수 번호 기준 검색 — 결제 내역과 등록 데이터를 1:1로 매칭
• 결제 수단별 필터 — 신용카드·가상계좌·카카오페이·네이버페이를 구분해서 정산
• 회원 등급별 요금 확인 — 정회원·준회원·학생회원 요금이 자동 계산된 결과가 조회 화면에 노출되는지
• 조기등록 할인 반영 여부 — 기간 만료 전후 금액 변동이 로그로 남는지

이 항목들이 단순히 "있다"가 아니라 하나의 화면에서 동시 필터링되어야 한다. 결제 수단까지 바꿔가며 화면을 오가면, 행사 당일 사무국의 응답 속도가 현저히 느려진다.

결론: 요약 체크리스트와 등록 결제 시스템의 올바른 구축 방향

현장 접수대 앞에서 참가자의 결제 완료 여부와 회원 등급을 일일이 확인하느라 대기 줄이 길어지는 것은 누구도 원하지 않는다. 이런 운영 병목을 막으려면 결제 게이트웨이(PG)를 연동하기 전에 요금 구조와 필터링 로직을 데이터베이스(DB) 단에서 완벽하게 설계해 둬야 한다.

단순히 결제창만 띄우는 것을 시스템 구축으로 착각하면, 행사 규모가 커질수록 정산 누락과 현장 혼란이라는 똑같은 실수를 반복하게 된다. 성공적인 등록 결제 구축을 위해 결제 연동 전 반드시 점검해야 할 핵심 요소를 요약했다.

• 회원 등급별 요금 자동 계산 로직: 정회원, 준회원, 학생회원 등 조건에 따라 결제 금액이 시스템에서 자동으로 분기되는가? - [ ] 조기등록 할인 적용 필터: 기간 만료에 따라 할인이 자동 해제되고 정가로 전환되는 검증 필터가 작동하는가?