IELTS 플랫폼 전면 개편과 신규 상품 출시

같은 사람인지 어떻게 판정할 것인가

구 사이트는 가입 시 별도 인증 절차가 없어 중복 번호와 유효하지 않은 이메일 계정을 가진 회원이 다수였습니다. 기존 회원은 유효한 고유값으로 특정하고, 신규 회원은 간편 가입으로 이탈을 줄여야 하는 상황이었습니다.

소셜 로그인을 붙이는 일은 화면 작업처럼 보이지만, 실제로 정해야 하는 건 동일인 판정 규칙입니다. 이걸 안 정하면 한 사람이 계정 N개를 갖게 되고, 수강 이력과 결제 이력이 흩어집니다. 휴대폰 번호와 이메일 주소를 고유값으로 특정하고, 기존 회원의 소셜 로그인·같은 메일 주소의 다중 소셜 로그인 등 다양한 케이스에서 정합성이 틀어지지 않도록 Flow chart와 정책을 설계했습니다.

• 판정 기준을 두 값으로 고정: 동명이인은 이메일 계정 + 연락처로 구분. 한 번호로 여러 계정을 만들 수 없게 막고, 중복 시 기존 계정 로그인만 허용
• 연동 방향을 비대칭으로 설계 - 동일 이메일 기준 일반가입 후 소셜 연동은 허용, 소셜로 먼저 가입한 뒤 일반가입은 불가. 채널마다 신원 확인 강도가 다르기 때문 (구글·카카오는 닉네임을 이름으로 쓸 수 있어 특정이 어려움)
• 인증 강도를 상황별로 조정: 소셜 가입 시 입력한 이메일이 일반가입(구 회원) 계정과 중복이면 기존 계정 1회 로그인으로 본인 확인. 다른 소셜 계정과 중복이면 추가 소셜 연동으로 처리 (카카오 지메일로 가입한 뒤 구글 지메일로 로그인하는 경우)

기존 중복 번호는 병합하지 않았습니다

리뉴얼 이전에 이미 같은 번호로 만들어진 A·B 계정이 존재. 여기서도 억지로 합치지 않는 쪽을 선택

• 기존 계정은 통합하지 않고 각각 수강 이력 유지: 잘못 합치면 수강권이 사라지거나 남의 이력이 붙음
• 대신 번호 변경 유도 캠페인을 2차 과제로 분리: 대상자 로그인 시 본인 번호 인증 팝업을 띄우고, 인증이 완료될 때까지 노출을 유지
• 신규 가입은 그 시점부터 번호를 고유값으로 강제

관리자 · 결제: 정산 정합성을 입력 시점에 지키기

어학원 결제는 대부분 PG 연동 없이 단말기로 이뤄져 엑셀 수기 관리에 의존하고 있었습니다. 회원정보와 수강·결제 정보가 시스템에 연결돼 있지 않아 전년도 매출과 수강생 현황을 비교 분석할 수단 자체가 없는 상태였습니다.

• 어학원: 엑셀 수기 관리를 관리자에서 매출 DB를 관리하는 구조로 전환. 등록 화면에 검증을 걸어 들어오는 데이터부터 맞춤
• 인강: PG사 사이트에서만 보던 결제 데이터를 API로 연동해 관리자에서 모니터링하고, 결제상태(부분취소·환불)까지 처리 가능하도록 수정

어학원 등록 화면에 적용한 검증 규칙

• 원 결제 없는 환불 차단: 매입금액이 (-)인 행 중 승인번호·거래일자가 일치하는 (+) 행이 없으면 등록 거부. "결제취소건 중 최초 결제내역이 존재하지 않는 건이 있습니다"
• 중복 등록 차단: 승인번호와 매입금액이 모두 일치하는 기존 건이 있으면 거부
• 온라인 결제건 삭제 차단: PG 연동 데이터는 수정·삭제 불가, 수기 등록건만 삭제 가능
• 결제 데이터와 수강 정보를 매핑: 회원정보·실결제금액·결제수단·결제일자·결제상태 등 결제 메타데이터와 수강상품·옵션·수강기간 등 수강 메타데이터를 연결. 가입, 수강신청, 수강까지 하나의 데이터 흐름으로 모니터링할 수 있는 시스템으로 설계

관리자 · 배송: 결제와 배송 상태를 자동으로 묶기

배송은 결제가 취소되면 따라서 멈춰야 함. 그런데 언제 취소됐느냐에 따라 해야 할 일이 다름. 시점을 셋으로 나눠 자동 연동 규칙을 수립. 유료 플러그인으로 운영하던 송장 관리도 자체 구축해 연동을 자동화

• 비가역 상태를 고정: 배송완료 상태에서는 상태값 변경 불가
• 상태와 필드를 연동: '해당없음(배송불필요)' 선택 시 송장번호 입력 필드 비활성화
• 매칭 키를 고유값으로 교체: 송장 일괄 업로드 매칭을 회원명+주문번호로 운영. 동명이인과 번호 변경에 취약한 이슈를 해소

어학원 결제는 PG 연동이 아니라 학원 현장 단말기 결제가 대부분(약 95%)입니다. 결제 후 관리자 결제 입력폼은 회원의 수강상품·실결제액·결제일자·결제상태를 저장하는 구조인데, 정산은 이것과 다른 구조를 띠고 있었습니다.

• 인센티브가 두 조직으로 안분됨: 신규 결제·전액 환불은 사업팀, 재등록·부분 취소는 TNC 강사팀으로 귀속. 정산은 곧 두 팀의 실적을 가르는 일이었음
• 매출 귀속이 결제일로 정해지지 않음: 수강시작월 · 수강기간 · 수강취소시점에 따라 달라짐
• 기타 결제는 매칭할 상품 값이 없음: 응시료·모의고사·교재 등은 관리자에 대응하는 결제상품이 없어 별도 입력폼으로 관리 중이었음

이 구조를 매달 엑셀에 수기로 옮겨 안분했고, 사업팀과 TNC팀의 매출을 사람이 대조하는 데만 4.5~5시간이 들었습니다. 반 변경과 부분 환불이 월 경계에 걸리면 어느 팀 실적으로 잡을지 판단도 갈렸습니다. 관리자에서 가능한 만큼 자동화하는 정산 시스템이 필요한 상황이었습니다.

첫 설계(v1.0)가 안 되는 이유

v1.0은 결제 상태를 기준축으로 놓았습니다. 결제 시점에 이미 기록이 남는 값이기 때문입니다. 그런데 결제 시점 기준이면 9월에 결제하고 10~12월에 수강하는 회원이 9월 매출에만 잡힙니다. 월별 수강생 수와 매출이 서로 어긋나고, 환불은 발생 월이 또 달라 같은 경로에 두면 월별 정산이 틀어집니다. 이미 마감한 월의 정산은 소급해서 되돌릴 수 없고, 기준이 어긋났다는 사실은 몇 달 치가 쌓인 뒤에 드러납니다.

v2.0에서 바꾼 것

• 기준축 전환: 정산은 "언제 결제했나"가 아니라 "언제 수강 중이었나" 기준이어야 월별 귀속이 맞음. 결제상태 → 수강기간(수강시작월·종료월)을 출발 노드로 변경
• 매출·환불 경로 분리: 매출월과 환불월에 각각 매출귀속(사업팀/TNC)을 붙여 이원화. v1.0에서 8개가 한 덩어리였던 매출구분을 정상 매출과 환불로 갈라냄
• 수강기간의 독립성 고정: 매출귀속·매출구분·결제상태값에 영향받지 않도록 규정. 다운그레이드로 환불월에 -금액이 생겨도 수강기간은 변하지 않음

엣지 케이스 6종 정의

같은 "반 변경 200만원"인데 월이 같은지 다른지에 따라 처리가 갈림. 개발 착수 전에 6개 케이스를 정의해 전달

(6개 케이스 중 3개 발췌)

자동화하지 않기로 한 구간

기존 플랫폼에는 상품, 옵션, 강좌, 강의로 이어지는 구조 체계가 없었습니다. 옵션·강좌·강의·결제가 서로 연결되지 않고 각각의 테이블로 흩어져 있었으며, 코드도 꼬여 있어 따로 발라낼 수 없는 상황이었습니다. 상품 데이터는 구조상 존재하지도 않았습니다. 신규 플랫폼은 이 계층을 전제로 설계돼 있으니, 옮길 대상과 받을 그릇의 모양이 애초에 달랐습니다. 게다가 릴리즈까지 3개월밖에 남지 않아 현실적인 해결책을 찾아야 했습니다.

선제 설계: 매핑 필드 입력란 활성화

어드민 상품·옵션 관리 화면에 구 사이트 옵션 ID를 매핑하는 필드를 추가. 이관 시점에 신·구 데이터를 대조할 연결고리를 미리 만들어 상당 부분 싱크 확보

이관하지 못한 데이터

• 수강이력 · 결제이력 · 모의고사 첨삭 응시권: 원본이 구조화돼 있지 않아 신규 구조에 매핑 불가
• 잘못 이관되면 기존 수강생의 이용권·수강 상태가 어긋나 대규모 CS와 신뢰도 하락으로 직결되는 항목

억지 매핑 대신 한 선택

• 범위 재정의: 운영자들과 마이그레이션 데이터 범위를 다시 그음. 무엇을 옮기고 무엇을 안 옮길지부터 확정
• 정책으로 보상: 매핑 불가 항목은 기존 이용권 리셋 후 신규 이용권 재부여로 합의. 데이터를 옮기는 대신 사용자가 가진 권리를 보전하는 쪽으로 방향 설정
• 선제 안내: 리뉴얼 공지사항으로 변경 사항을 오픈 전에 고지
• 대응 표준화: FAQ·응대 가이드를 미리 정리해 CS 편차 제거

결과

• 기존 수강생의 혼란·불만 리스크를 정책과 사전 커뮤니케이션으로 흡수
• 이관 관련 대규모 CS 없이 오픈: 신뢰도 하락 없이 전환 완료

여기서 배운 것