OK캐쉬백 복지 포인트 서비스 개발기: 보안, 대용량 처리, 그리고 현실적인 선택들

OK캐쉬백 복지 포인트는 제휴사가 임직원에게 지급한 복지 포인트를 관리하는 서비스로, 하나카드 기반 카드 발급, 간편 결제 등록, 소득공제 혜택, OK캐쉬백 프로모션과 오키 클럽 혜택까지 함께 제공했다. 기본적으로는 허용 업종에서만 결제되지만, OK캐쉬백 포인트와 합산 사용을 설정하면 업종 제약을 우회해 결제할 수 있었다.

구성은 코어 시스템, OK캐쉬백 앱, 관리자 어드민으로 나뉘었다. 코어 시스템은 제휴 계약, 카드 상태, 가맹점 계약, 허용 업종, 실시간 결제 처리, 포인트 적립·사용·조회까지 맡았고, 앱은 카드 등록과 사용자 기능을 제공했으며, 어드민은 임직원 관리와 포인트 지급·차감을 담당했다.

카드 등록은 앱에서 신분증 인증과 계좌 인증을 거친 뒤 이뤄졌고, 등록 정보는 코어와 어드민으로 전달됐다. 어드민은 임직원 정보만 먼저 등록해둘 수 있지만, 실제 포인트는 카드 등록 이후에만 사용할 수 있었기 때문에 그 전까지의 배정/차감 요청은 저장만 해두는 구조였다.

사용자 앱에서는 다음 기능을 제공했다.

• 복지 포인트 조회와 사용 이력 조회
• 간편 결제 등록 및 이후 설정 변경
• 카드 분실 시 복지 카드 상태 변경
• OK캐쉬백 합산 사용 설정
• 온라인 사용을 위한 결제 비밀번호 변경
• 허용 업종 결제를 현금이나 다른 카드로 했을 때 쓰는 영수증 승인 요청

영수증 승인 요청에서는 첨부 이미지에서 승인번호, 가맹점명, 사업자번호를 정확히 읽어야 했고, 이를 위해 OpenAI 기반 영수증 인식 기능을 도입했다. 비교 결과 GPT-4o는 응답 시간이 길고 비용이 높았으며 일부 요청에서 승인번호 인식 오류가 있었고, GPT-4.1-mini는 3회 모두 성공하면서 응답 시간과 비용이 가장 균형적이었다. 반면 GPT-4.1-nano는 결제일, 거래금액, 카드사 인식 오류가 반복됐다. 결국 인식률, 응답 시간, 비용을 종합해 gpt-4.1-mini를 채택했다.

어드민 보안은 가장 먼저 풀어야 할 문제였다. 금융 성격의 서비스라 법무 검토 단계에서부터 보안성 심의 대상이었고, 마스터 관리자와 제휴사 관리자는 기능은 비슷하지만 접근 통제 요건이 달랐다. 이상적이라면 서로 다른 코드와 서버로 분리했겠지만, 일정과 인력이 부족해 하나의 코드베이스 안에서 접속 경로를 분리하는 방식으로 현실적인 해법을 택했다.

보안 구조는 다음처럼 정리됐다.

• 마스터 관리자: 사설 도메인, VDI 필수, 고정 IP, 방화벽 정책 적용, ID/PW와 권한 체크
• 제휴사 관리자: 공인 도메인, 인터넷 직접 접속, 2FA, 휴대폰 OTP, 제휴사 ID 단위 접근 제어

이 구조 덕분에 마스터 관리자는 폐쇄망 수준의 강한 보안을 확보했고, 제휴사 관리자는 내부 권한 시스템을 쓰지 못하는 대신 2차 인증과 데이터 단위 차단으로 보완했다. 활동 로그도 주기적으로 수집해 모니터링 체계를 붙였다.

대용량 처리에서는 요청과 실행을 분리했다. 전사 임직원 등록이나 전체 대상 포인트 지급처럼 한 번에 수백~수천 건이 발생하는 요청은 먼저 DB에 저장하고, 동시에 Redis Queue에 넣어 즉시 응답했다. Worker는 큐를 폴링해 작업을 가져온 뒤, 예를 들어 700명에게 100만 포인트 지급 요청을 700개의 개별 작업으로 쪼개 다시 저장하고 처리했다.

실제 지급/차감은 10분 단위 배치로 수행됐고, 각 작업의 성공·실패를 집계해 초기 요청 데이터에 반영했다. 운영자는 진행률과 남은 작업 수를 확인할 수 있었고, 이 구조로 응답성과 안정성을 함께 확보했다.

일정 문제는 또 다른 제약이었다. 복지 포인트 서비스는 연초 배정을 위해 연내 오픈이 필수였고, 개발 시작 시점은 9월 초였다. 원래는 코어 시스템이 포인트 배정/차감 이력, 카드 사용 내역, 영수증 처리 이력을 API로 제공하는 구조가 이상적이었지만, API를 새로 정의하고 개발·테스트·안정화까지 끝내기엔 시간이 부족했다.

그래서 방향을 바꿔 DB 기반 데이터 연동을 선택했다. DBA와 협의한 결과 OGG(Oracle GoldenGate) 로 필요한 핵심 데이터 6개 테이블을 연동할 수 있었고, 이를 통해 일정 내 구현과 오픈 가능성을 확보했다. 완벽한 아키텍처보다, 주어진 제약 속에서 실제로 동작하는 시스템을 만드는 것이 더 중요하다는 판단이었다.

결국 이 프로젝트는 보안, 대용량 처리, 촉박한 일정이라는 세 가지 제약을 각각 정면으로 다루며, 이상과 현실 사이에서 가장 실행 가능한 설계를 골라낸 사례로 정리된다.