MUSINSA tech - Medium

안녕하세요, 29CM Purchase & Post Purchase 팀 백엔드 엔지니어 강세종입니다.
저희 팀은 고객이 상품을 장바구니에 담아 주문하는 단계(Purchase)부터, 주문 이후의 배송, 클레임, 정산 등 후속 프로세스(Post Purchase)까지 전반적인 기능을 개발하고 있습니다.
오늘은 Post Purchase 영역 중 하나인 네이버쇼핑 수수료 정산 시스템에 대해 소개 드리려 합니다.
특히 기존 시스템의 기술 부채를 해소하고, 보다 유연하고 확장 가능한 구조로 재설계하게 된 배경과 그 과정을 중심으로 공유드리고자 합니다.
네이버쇼핑 수수료 정산 시스템이란?
29CM는 네이버 쇼핑과의 제휴를 통해 고객 접점을 넓혀가고 있으며, 위처럼 네이버 쇼핑에서 노출된 상품이 주문으로 이어질 경우 별도의 정산 체계를 운영하고 있습니다.
네이버 쇼핑을 통한 주문은 일반적인 29CM 입점 파트너 매출 정산 외에도, 네이버 측에 수수료를 정산해야 하는 이중 정산 구조이기 때문에, 이를 처리하기 위한 전용 정산 시스템이 별도로 필요합니다.
레거시 정산 시스템
네이버쇼핑 수수료 정산 시스템은 네이버쇼핑으로 발생한 주문을 대상으로 정산 데이터를 생성하고, 관리자가 이를 조회·다운로드할 수 있는 API를 제공합니다.
시스템은 크게 Batch 와 API 로 구성되어 있으며, 모두 Django(Python) 기반으로 구축되어 있습니다.
[정산 데이터]
네이버 정산 주문 상세 테이블 : 정산 대상 주문 정보를 저장합니다.
네이버 정산 월간 집계 테이블 : 해당 월의 주문 상세 데이터를 집계한 금액을 저장합니다.
[정산 Batch]
레거시 시스템은 Python 기반 Django 배치 스크립트로 정산 데이터를 생성합니다. 스크립트는 일 단위로 스케줄링되어 실행되며, 실제 데이터 조회와 계산 작업은 PostgreSQL에 정의된 2개의 프로시저를 호출하는 방식으로 구성되어 있습니다.
출고 완료 주문의 정산 상세 데이터 생성 프로시저
반품 완료 주문의 정산 상세 데이터 생성 프로시저
두 프로시저는 주문·클레임·배송 등 원천 테이블에서 데이터를 조회해 금액을 계산한 뒤 네이버 정산 주문 상세 테이블에 적재합니다.
이후 PostgreSQL 트리거를 통해 자동으로 “네이버 정산 월간 집계 테이블”에 월 단위 집계 데이터가 생성됩니다.
즉, 전체 구조는 다음과 같은 순서로 구성되어 있습니다:
Django 배치 : PostgreSQL 정산 프로시저 2개를 순서대로 호출
PostgreSQL 프로시저 : 원천 테이블에서 데이터 조회 후 상세 테이블에 적재
PostgreSQL 트리거 : 상세 테이블의 데이터를 기반으로 월간 집계 테이블에 적재
[정산 API]
Django 기반의 REST API 형태로 제공되며, 아래 세 가지 기능을 지원합니다.
월간 상세 내역 조회 : 페이징 방식으로 특정 월의 정산 상세 데이터를 조회합니다.
월간 상세 내역 다운로드 : 특정 월의 상세 데이터 전체를 CSV 파일로 다운로드합니다.
월간 집계 내역 조회 : 페이징 방식으로 월간 집계 데이터를 조회합니다.
레거시 정산 시스템의 문제는?
7년 전 도입된 정산 시스템은 단순한 구조였기에 당시의 적은 데이터를 처리하는데 문제가 없었습니다.
하지만 비즈니스의 급성장으로 정산 데이터가 폭증하면서, 성능 한계와 함께 로직 변경의 어려움도 점차 드러났습니다.
특히 프로시저 중심 아키텍처는 새로운 요구 사항을 반영하기 어려워, 전면 개편이 불가피했습니다.
[문제1. 비즈니스 성장을 감당할 수 있을까?]
29CM의 매출은 해마다 높은 성장률을 보이며, 이에 따라 네이버쇼핑 정산 데이터 역시 비례하게 증가하고 있습니다. 레거시 시스템이 처음 설계된 2018년 당시에는 월 평균 정산 건수가 약 6천 건 수준이었지만, 현재는 약 4만 7천 건으로 8배 가까이 증가한 상황입니다.
데이터가 기하급수적으로 증가하면서 가장 먼저 한계를 드러낸 것은 “상세 내역 다운로드 API” 였습니다.
기존 Django 기반의 API 서비스는 블로킹 I/O와 단일 스레드 구조 탓에 대용량 CSV 생성 시 처리 지연이 불가피했습니다
특히, 정산 대상 데이터의 양이 많아질수록 응답 시간이 길어졌고, 결국 게이트웨이 타임아웃 제한 시간에 도달하는 문제가 빈번하게 발생했습니다.
[문제2. 변경이 작아도, 비용은 크다.]
레거시 시스템에서는 정산 대상 조회 → 데이터 생성 전 과정이 PostgreSQL 프로시저·트리거에 구현되어 있었습니다. 이는 과거 대용량 데이터를 효율적으로 처리하기 위해, 애플리케이션이 아닌 데이터베이스에서 직접 연산을 수행하도록 설계된 구조입니다.
문제는 2개의 프로시저가 시간이 지남에 따라 점점 거대해졌다는 점입니다. 현재는 각 프로시저가 약 1,000줄 이상의 SQL 코드로 구성되어 있으며, 2개의 대형 INSERT 쿼리, 50개 이상의 CASE/IF 조건 분기, 12개 이상의 테이블 조인이 얽혀 있어 전체 로직의 흐름을 파악하기 매우 어려웠습니다.
구조적으로 복잡할 뿐만 아니라, 로직 대부분이 특정 도메인 지식에 의존하고 있어 새로운 팀원에게 온보딩하기도 쉽지 않았습니다.
특히 쿠폰 할인, 마일리지 사용, 수수료 및 VAT 계산 등 20개 이상의 계산 컬럼이 존재하며, 이들 각각은 CASE, ROUND, TRUNC, COALESCE, SUBSELECT 등 다양한 SQL 내장 함수를 복합적으로 사용한 계산식으로 구성되어 있었습니다.
그 결과, 단순한 정책 변경도 다단계 로직을 분석하고 수정해야 하는 고비용 작업이 되어버렸습니다. 이처럼 변경에 취약할 뿐만 아니라, 다음과 같은 문제점들도 함께 드러나고 있었습니다.
[테스트와 버전 관리의 부재]
정산 로직에 대한 테스트 코드가 없어, 모든 검증을 사람이 직접 수행
Git으로 SQL 프로시저를 관리하는 데 어려움이 많아 변경 이력을 추적 불가
로직이 크고 복잡하다 보니 협업 중 충돌이 자주 발생하여 작은 변경에도 리스크 존재
[트리거 기반의 암묵적 실행 흐름]
정산 데이터 생성 로직 중 일부가 PostgreSQL 트리거에 포함
이로 인해 실행 흐름을 명확히 파악하기 어렵고, 디버깅이나 영향 범위 확인 어려움
트리거는 동작을 암묵적으로 유발하므로 시스템의 예측 가능성과 변경 안정성을 떨어뜨리는 주요 원인
무엇보다도, 이러한 문제는 여전히 현재 진행형이었습니다. 정산 정책 변경 요구는 계속해서 발생하고 있었고, 기존 시스템으로는 이를 빠르고 안정적으로 반영하기 어려웠습니다.
예를 들어, 최근에는 정산 기준 시점을 ‘배송 완료’에서 ‘결제 완료’로 변경해야 하는 요구가 있었는데, 이는 단순히 조건 하나를 바꾸는 수준이 아니었습니다. 정산 대상 필터링 로직, 조인 테이블 구조 등 시스템 전반을 수정해야 했습니다.
이처럼
높은 복잡도
유지보수 부담
검증 난이도
라는 세 가지 한계가 누적되며 더 이상 무시할 수 없는 수준에 이르렀고, 결국 이번 기회를 통해 정산 시스템 전반을 보다 유연하고 명확하게 개선하게 되었습니다.
그래서 이렇게 바꿨습니다. 신규 정산 시스템
새로운 정산 시스템은 Spring Boot 기반의 API와 배치 모듈로 구성되며, 정산 로직을 명확히 분리하고 확장 가능하게 설계했습니다.
[데이터 구조 개편]
레거시 시스템의 비즈니스 로직은 시간이 흐르며 여러 차례 수정되어 왔고, 그 과정에서 현재 사용되지 않는 컬럼이 생기거나, 새로운 요구사항이 반영되지 못한 경우도 많았습니다.
이에 따라 신규 시스템에서는 정산 목적에 맞게 필요한 정보만 담은 테이블을 새로 설계하였고, 일부 데이터는 기존 테이블과 병행해 사용하는 방식으로 구성했습니다.
(신) 네이버 정산 주문 상세 테이블 : 정산 대상 주문의 상세 정보를 저장합니다.
(신) 네이버 정산 일간 집계 테이블 : 일 단위 정산 금액을 집계하여 저장합니다.
(신) 네이버 정산 월간 집계 테이블 : 월 단위 정산 금액을 집계하여 저장합니다.
[데이터 마이그레이션은 꼭 해야 할까?]
결론적으로, 정산 주문 상세 데이터는 마이그레이션하지 않았습니다. 그 이유는 신규 시스템 전환이 특정 ‘정산 월’을 기준으로 진행되고, 정산 상세 내역 조회 API 는 월 단위로만 조회되기 때문입니다.
따라서 조회 요청이 들어오면 해당 월이 시스템 전환 시점 이전인지 이후인지를 판단하여, (구) 테이블 또는 (신) 테이블을 선택적으로 조회하는 구조로 설계했습니다. 이 방식으로 중복 없이도 일관된 조회가 가능해 데이터 마이그레이션이 필요하지 않았습니다.
기존에 적재된 230만 건의 정산 주문 상세 데이터가 안정적으로 운영되고 있고, API 의 조건 분기만으로 충분히 호환이 가능했기 때문에 마이그레이션 비용과 리스크를 최소화하는 전략을 택하였습니다.
반면, 월간 집계 데이터(7년치 약 160 건)는 신규 테이블로 이관했습니다. 데이터 규모가 작고, 페이징 조회 기능 구현에 신규 스키마가 더 적합했기 때문입니다.
[정산 Batch]
신규 시스템은 프로시저·트리거에 흩어져 있던 정산 로직을 제거하고 Spring Batch 기반으로 일원화했습니다. 배치 프로세스는 세 단계로 구성됩니다.
1. 정산 주문 상세 생성
정산 배치의 첫 번째 단계는 실제 정산 대상이 되는 주문 데이터를 수집하고, 정산 기준에 따라 계산된 상세 데이터를 생성하는 과정입니다.
이 과정의 핵심은 정산 기준별로 Step을 완전히 분리했다는 점입니다. 결제 완료, 취소 완료, 반품 완료 등 각 상태를 독립 Step으로 구현한 덕분에 다음과 같은 세 가지 이점을 얻었습니다.
첫 번째 장점은, Jenkins 파이프라인 등과 연계하여 병렬 실행이 가능하다는 점입니다.
정산 데이터가 많아질수록 각 Step의 실행 시간이 증가할 수밖에 없지만, 서로 간에 의존성이 없는 독립적인 Step을 병렬로 실행함으로써 전체 배치 수행 시간을 효과적으로 단축할 수 있습니다.
두 번째 장점은 정산 기준의 추가·변경에 대한 유연성입니다.
기존 구조에서는 조건 분기나 내부 로직을 직접 수정해야 했지만, 이제는 새로운 기준이 생기면 해당 기준에 맞는 Step만 추가하면 됩니다.
예를 들어, ‘교환 완료’ 상태가 정산 기준으로 새롭게 추가되더라도, 기존 Step에 영향을 주지 않고 새로운 Step만 정의하면 손쉽게 반영할 수 있습니다.
이는 정산 기준 간 사이드이펙트가 없고, 각 Step이 단일 기준만을 처리하기 때문에 SRP(Single Responsibility Principle, 단일 책임 원칙) 에도 부합하는 구조입니다.
세 번째 장점은, Reader 는 정산 기준별로 분리하되, 이후 처리 과정인 Processor 와 Writer 는 공통으로 재사용함으로써 얻는 구조적 이점입니다.
이 방식은 정산 기준별로 다른 데이터 소스와 조회 조건을 유연하게 수용하면서도, 계산 로직과 저장 방식은 일관성 있게 유지할 수 있어 중복 구현 없이 확장 가능하며, 유지보수성과 테스트 효율 측면에서도 매우 유리합니다.
즉, 각 기준의 비즈니스 특성은 Reader에서 분리하고, 공통 로직은 Processor와 Writer에서 재사용함으로써 구조의 응집도는 높이고 결합도는 낮추는 효과를 기대할 수 있습니다.
2. 일간 집계 생성
정산 기준별 주문 상세 데이터를 모아 일 단위 집계를 만듭니다.
현재 정산 주기는 ‘한 달’ 단위지만, 앞으로는 1일, 1주, 2주 등 다양한 주기의 정산 요구가 생길 가능성이 있습니다. 이러한 확장성을 고려하여, 일 단위의 통계 데이터를 미리 생성하는 방식으로 설계했습니다.
3. 월간 집계 생성
앞서 만든 일간 집계를 모아 월 단위 통계를 만듭니다.
기존 시스템에서는 상세 → 월간으로 바로 집계해 주기 확장이 어려웠다면, 일간 단계를 추가한 덕분에, 새로운 주기를 탄력적으로 지원할 수 있습니다.
[정산 API]
기존 Django 기반 정산 API는 게이트웨이 타임아웃과 I/O 병목으로 성능 한계가 뚜렷했습니다. 타임아웃 조정·내부 튜닝 같은 일시적 처방을 검토했지만, 근본적인 해결을 위해 Spring Boot 기반 REST API로 전환했습니다.
멀티스레드 기반의 고성능 처리 구조
팀 내 운영 기술 스택과의 높은 정합성
운영 및 장애 대응 측면에서의 유연한 확장성
Spring Boot 전환 이후에도 기존과 동일한 API를 안정적으로 제공하고 있습니다.
월간 상세 내역 조회 : 페이징 방식으로 특정 월의 정산 상세 데이터를 조회합니다.
월간 상세 내역 다운로드 : 특정 월의 상세 데이터 전체를 엑셀 파일로 다운로드합니다.
월간 집계 내역 조회 : 페이징 방식으로 월간 집계 데이터를 조회합니다.
[정산 기준 변경]
신규 정산 시스템으로 전환하게 된 이유는 여러 구조적 한계도 있었지만, 정산 기준 변경이 결정적 요인이었습니다.
As-Is : 출고 완료, 반품 완료
To-Be : 결제 완료, 취소 완료, 반품 완료
신규 정산 기준은 정산 월 시작일에 ‘결제 완료’된 주문부터 적용됩니다. 이때 두 날짜(결제 완료, 출고 완료)가 기준일을 걸쳐 있는 주문은 정산에서 누락될 수 있으므로 사전에 체크가 필요합니다.
결제 완료 시점이 신규 정산 기준 적용일 이전 → 기존 정산 기준(출고 완료)에 부합하지 않으므로 정산 누락
출고 완료 시점이 신규 정산 기준 적용일 이후 → 신규 정산 기준(결제 완료)에 부합하지 않으므로 정산 누락
이러한 주문들은 예외적으로 신규 정산 기준 적용일 이후에도 기존 정산 기준(출고 완료)에 따라 정산 대상에 포함되도록 처리하였습니다.
이와 같이 정산 기준 전환에 따른 정산 시나리오를 명확히 정의하고, 테스트 코드에 반영하여 정산 누락 없이 안정적으로 전환할 수 있도록 구현할 수 있었습니다.
마무리하며..
이번 정산 시스템 개편은 단순한 기능 개선을 넘어, 지난 7년간 축적된 기술 부채를 해소하고 앞으로의 성장을 위한 정산 시스템의 근본적인 체질 개선을 목표로 한 프로젝트였습니다.
정산 영역은 단순 계산을 넘어 다양한 비즈니스 정책이 교차하는 복합 도메인입니다. 우리는 그 복잡함을 품으면서도 더 단순하고 유연하게 작동하는 시스템을 만들어 냈습니다.
무엇보다도, 오랜 시간 레거시 시스템 위에서 묵묵히 정산을 지켜내며, 이제는 고통이 아닌 변화로 나아갈 수 있도록 레거시 청산을 함께 이끌어준 우리 팀원들께 깊은 감사의 마음을 전합니다.
그리고 만약 여러분이 이런 문제 해결에 흥미를 느끼셨다면, 또 아직 남아 있는 레거시 시스템을 함께 개편하고, 더 나은 방향을 제안해보고 싶은 마음이 드셨다면 29CM는 그런 여러분을 언제든지 환영합니다.
29CM CAREER
함께할 동료를 찾습니다.
29CM는 ‘고객의 더 나은 선택을 돕는다’라는 미션으로 출발했습니다. 우리는 우리만의 방식으로 콘텐츠를 제공하며, 브랜드와 고객 모두에게 대체 불가능한 커머스 플랫폼을 만들어가고 있습니다. 이 미션을 이루기 위해 우리는 흥미로우면서도 복잡한 문제들을 해결하고 있습니다. 만약 우리와 함께 이 문제들을 해결해 보고 싶다면, 주저하지 말고 29CM에 합류하세요!
🚀 29CM 채용 페이지 : https://corp.musinsa.com/ko/
📌채용이 완료되면 공고가 닫힐 수 있으니 빠르게 지원해 주세요!
구관이 꼭 명관은 아니다: 정산 시스템의 세대교체 was originally published in MUSINSA tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

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

댓글