토스페이먼츠 결제 원장 시스템 전환 및 안정화 경험

레거시 결제 원장의 기술적 한계

• 기존 시스템은 20년 이상 운영된 Oracle DB 기반 레거시 구조로, 결제 원장이 핵심 과제였음.
• 일관성 없는 데이터 구조: 결제수단별 상이한 테이블 구조와 데이터 저장 방식으로 온보딩 및 유지보수 난이도가 높았음.
• 도메인 간 강한 결합: 결제, 정산, 취소 등 여러 도메인이 동일 원장 테이블을 공유하여 서비스 확장성과 유연성 저하.
• 확장성을 가로막는 구조: 결제와 결제수단이 1:1 관계로 묶여 복합결제, 더치페이 등 신규 비즈니스 모델 지원 불가.

MySQL 기반 신규 원장 시스템 구축 전략

• MySQL 선택 배경: 독립적인 DB 인프라 확보, JPA Entity 기반 개발 스택 일원화, 실험 및 확장의 자유로움을 목표.
• 데이터 구조의 일관성: 모든 승인 내역을 approve 공통 테이블에, 결제수단별 정보는 개별 테이블에 저장. INSERT-only 원칙을 통해 데이터 불변성 보장 및 데드락 방지.
• 도메인 간 결합도 완화: 각 도메인이 직접 DB를 조회하지 않고, Kafka 이벤트를 발행/구독하여 간접 통신 및 병렬 개발 가능.
• 결제와 승인(Approval) 분리: '결제'는 수단 미확정, '승인'은 수단 확정 상태로 구분하여 복합결제 및 더치페이 시나리오 유연하게 지원.

안전한 마이그레이션 및 대규모 데이터 이관

• 점진적 비동기 적재: 기존 원장 저장 후 신규 원장에 비동기 방식으로 데이터 적재, 실패 시 모니터링 및 알림 시스템으로 관리.
• 리소스 관리: ThreadPool 튜닝 및 트래픽 점진적 투입으로 CPU/메모리 부담 최소화, 누락 데이터는 별도 검증 배치로 보완.
• 데이터 정합성 검증: RO(Read Only) DB 기반 검증 배치를 매시 5분 간격으로 실행하여 데이터 누락 보정.
• 대규모 데이터 이관: 수억 건 마이그레이션을 위한 전용 서버 구성, Bulk Insert 도입, 로컬 캐시 적용, 네트워크 대역폭 관리로 안정적인 이관 수행.

운영 중 장애 대응 및 교훈

• DB 부하 급증 장애: 신규 기능 배포 후 옵티마이저의 잘못된 인덱스 선택으로 인한 Full Scan 발생, 즉시 롤백 및 쿼리 힌트 추가로 해결.
• 장애로 드러난 문제 해결: 두 원장 간 데이터 불일치는 구원장 기준 자동 보정 배치로, 원천사와의 불일치는 망취소(Network Cancellation) 로직으로 해소. MSA 서버 간 타임아웃 설정 불일치 및 결제 이벤트 누락/중복 문제는 타임아웃 일관화, Outbox 패턴, 로그 기반 복구, 멱등키 활용으로 보완.
• Lesson & Learn: 초기 설계만큼 중요한 운영 대응 능력과 시스템 자가 회복 구조의 필요성을 깨달았으며, 장애 복구 과정을 통해 안정성과 확장성을 갖춘 결제 인프라로 성장하는 계기가 됨.