구관이 꼭 명관은 아니다: 정산 시스템의 세대교체

카테고리

프로그래밍/소프트웨어 개발

서브카테고리

DevOps

대상자

백엔드 엔지니어, DevOps 엔지니어, 시스템 아키텍트

핵심 요약

• 레거시 시스템의 한계: PostgreSQL 프로시저 중심 아키텍처로 인한 성능 저하(게이트웨이 타임아웃), 유지보수 어려움(1,000줄 이상의 복잡한 SQL), 확장성 부족(정산 기준 변경 시 전반적 수정 필요)
• 신규 시스템의 핵심 설계: Spring Boot + Spring Batch 기반의 모듈화된 배치 프로세스, 정산 기준별 독립 Step 설계, 일간 집계를 통한 주기 확장성 구현
• 성능 개선: 멀티스레드 처리 및 병렬 실행으로 배치 시간 단축, API 성능 향상(타임아웃 문제 해결)

섹션별 세부 요약

1. 기존 시스템의 문제점

• 데이터 규모 증가: 2018년 월 평균 6,000건 → 현재 47,000건(8배 증가)
• 성능 한계: Django 기반 API의 블로킹 I/O 및 단일 스레드 구조로 인한 대용량 CSV 다운로드 지연
• 코드 복잡도: 1,000줄 이상의 SQL 프로시저, 12개 이상의 테이블 조인, 50개 이상의 CASE 조건
• 유지보수성 저하: 트리거 기반 암묵적 실행 흐름, 테스트 코드 부재, Git 관리 어려움

2. 신규 시스템 아키텍처

• Spring Boot 기반 REST API: 멀티스레드 처리 및 고성능 처리 구조
• Spring Batch 기반 배치 프로세스:

- 3단계 구조: 정산 주문 상세 생성 → 일간 집계 생성 → 월간 집계 생성

- 정산 기준별 독립 Step 설계(예: 결제 완료, 취소 완료, 반품 완료)

- Reader-Processor-Writer 분리로 재사용성 향상 및 SRP 원칙 준수

• 데이터 마이그레이션 전략:

- 정산 주문 상세 데이터: 기존 테이블 유지, 월 단위 조회 API 기반 중복 없는 일관성 유지

- 월간 집계 데이터: 신규 테이블로 이관(7년치 160건)

3. 정산 기준 변경 대응

• 기존 기준: 출고 완료 → 신규 기준: 결제 완료, 취소 완료, 반품 완료
• 전환 시나리오:

- 결제 완료 시점이 신규 기준 적용일 전 → 기존 기준(출고 완료) 적용

- 출고 완료 시점이 신규 기준 적용일 후 → 신규 기준(결제 완료) 적용

• 테스트 코드 통합: 정산 누락 방지를 위한 시나리오 반영

결론

• 핵심 팁: Spring Batch를 활용한 모듈화된 배치 프로세스 설계로 유연성과 확장성 확보, 일간 집계를 통해 주기별 정산 요구 대응 가능
• 실무 적용 권장: 정산 기준 변경 시 독립 Step 추가로 SRP 원칙 준수, API 성능 개선을 위한 멀티스레드 구조 도입
• 결론: 7년간 축적된 기술 부채를 해소하고, 정산 시스템의 근본적 체질 개선을 통해 성장성 확보 성공