안녕하세요! KCD 마켓팀의 백엔드 엔지니어 Jose(김호현)입니다.
KCD의 합류해 맡게 된 제 첫 프로젝트는 실시간으로 변하던 데이터를 배치(Batch) 정산으로 전환해 안정적인 정산 시스템을 만드는 일이었습니다. 이번 글에서는 신입 개발자의 시선에서 이 중요한 프로젝트를 어떻게 해결해 나갔는지 그 과정에서 무엇을 배웠는지 공유해 보려고 합니다.
이런 내용을 담았어요
- 실시간으로 쌓이는 정산 데이터에는 어떤 문제가 있었는지
- 안정적인 데이터 구축을 위해 '배치' 시스템을 설계하고 구현한 과정
- 신입 엔지니어로서 '정산'이라는 복잡한 도메인을 처음 마주하며 배운 점
이런 분들에게 도움이 될 것 같아요
- 데이터 처리 방식(실시간 vs 배치)의 장단점을 고민하는 백엔드 엔지니어
- 금융이나 정산처럼 복잡한 도메인을 처음 맡게 된 주니어 개발자
- 신입으로서 첫 프로젝트를 어떻게 시작하고 헤쳐나가야 할지 막막한 분
배경: 신뢰할 수 없었던 데이터와의 싸움
제가 프로젝트를 맡기 전, 마켓의 정산 데이터는 요청이 들어올 때마다 주문, 취소, 배송 등 여러 데이터를 실시간으로 조회해서 만들어졌습니다. 이 방식은 두 가지 고질적인 문제를 안고 있었죠.
첫째, 운영상의 혼란이 컸습니다. 데이터가 실시간으로 변하다 보니 어제 확인했던 정산 금액이 오늘 다시 조회하면 달라져 있는 일이 비일비재했습니다. 이건 입점사 문의에 대응하는 운영팀에 큰 혼란을 주었고 월별 최종 대사 시점에 숫자가 맞지 않는 문제로 이어지기도 했습니다.
둘째, 데이터의 신뢰도 문제였습니다. 간헐적으로 발생하는 버그로 인해 정산 기준일(배송완료 또는 환불 시점)이 의도치 않게 변경되는 경우가 있었는데요. 특히 이 변경이 월을 넘어가게 되면 입점사에 지급되어야 할 정산 금액과 실제 데이터가 달라지는 심각한 이슈가 발생했지만 복잡한 실시간 조회 로직 속에서 정확한 원인을 찾는 건 정말이지 쉽지 않았습니다.
해결 과정: 실시간 대신 '스냅샷'이라는 기준을 세우다
이 문제를 해결하기 위해 "정산 데이터는 실시간으로 정확할 필요가 없다"는 생각의 전환에서 출발했습니다. 매일 새벽, 전날까지의 모든 데이터를 기준으로 변하지 않는 '스냅샷'을 만들어 둔다면 신뢰도와 성능을 모두 잡을 수 있을 거라 확신했죠.
AS-IS(좌): 요청 시마다 여러 DB를 복잡하게 조회하여 신뢰도 확보가 어려웠습니다.
TO-BE(우): 매일 한 번의 배치 작업으로 신뢰할 수 있는 데이터를 미리 생성하여 단순하고 명확한 구조를 만들었습니다.
신입인 제게 '정산'이라는 도메인은 거대한 벽처럼 느껴졌습니다.😅 어디서부터 시작해야 할지 막막해서 처음 며칠은 기존 API의 응답(response) 값을 하나하나 뜯어보며 정산에 필요한 데이터 조각들을 역으로 추적하는 것이었어요.
분석 과정에서 중요한 사실을 하나 발견했습니다. 문제 해결의 핵심은 단순히 조회 로직을 개선하는 것이 아니라 누가 언제 조회하든 동일한 결과를 보장하는 '신뢰도 높은 정산 데이터 구조'를 목표로 재설계해야 한다는 걸요. (이 목표를 생각하도록 이끌어주신 마켓팀 BE Black 감사합니다!).
이 목표를 달성하기 위해 몇 가지 중요한 원칙을 세우고 설계를 진행했습니다.
첫째, 데이터의 추적성을 확보하는 것이었습니다. 모든 정산 데이터에 주문, 취소 등 원본 데이터의 고유 ID를 함께 저장하도록 스키마를 설계했습니다. 예를 들어, SETTLEMENT라는 테이블에 기존 금액 데이터 외에도 정산의 근거가 되는 order_id, refund_id, payment_date, created_at(스냅샷 생성 시점) 등의 컬럼을 추가하여 데이터가 어떤 원본으로부터 언제 생성되었는지 명확히 추적할 수 있도록 했습니다. 이 설계를 통해 데이터 불일치 문제가 발생했을 때, 그 원인을 찾는 과정을 획기적으로 단축하고 명확한 근거를 가지고 데이터를 검증할 수 있게 되었습니다.
둘째, 시스템의 유연성과 안정적인 운영을 고려하는 것이었죠. 저희 팀에서는 Spring Batch를 활용하여 매일 새벽, 특정 시간에 안정적으로 데이터를 처리하는 배치 잡(Job)을 구성했습니다. 이 매일 실행되는 배치 작업에 '시작일'과 '종료일'을 파라미터로 전달할 수 있게 설계했습니다. 덕분에 전체 데이터를 재처리하는 무거운 작업 없이도 특정 기간의 데이터만 선별하여 검증하거나 재실행하는 것이 가능해졌습니다.
마지막으로, 데이터의 무결성을 지키는 로직을 추가했습니다. 만약 특정 기간의 데이터가 이미 스냅샷으로 존재한다면 새로운 배치 작업은 이를 무조건 덮어쓰는 대신 기존 데이터와 새로 만든 데이터를 항목별로 비교하며 대사를 진행합니다. 이 과정을 통해 데이터 정합성을 꾸준히 유지하고 예기치 못한 오류를 방지할 수 있었습니다.
결과: 단순한 개선을 넘어, 업무 방식의 혁신으로
새로운 배치 정산 시스템의 도입은 단순히 속도가 빨라지고 데이터가 정확한 것 이상의 변화를 가져왔습니다. 이는 정산을 담당하는 운영팀의 업무 방식 자체를 혁신하는 계기가 되었습니다.
1. 유연한 정산 주기 설정으로 비즈니스 기회를 만들다 이전에는 정산 주기를 설정하는 기능이 없어 모든 입점사를 동일한 기준으로 관리해야 했습니다. 하지만 이번 프로젝트를 통해 정산 주기를 일/주/월 단위로 유연하게 설정할 수 있게 되면서 입점사별 맞춤형 관리가 가능해졌습니다. 이는 새로운 입점사를 유치할 때 매력적인 조건이 되었고 비즈니스 확장에도 직접적으로 기여했습니다.
2. 알림봇 연동으로 '문제 해결사'가 된 운영팀 "정산이 이상해요!" 더 이상 개발자를 찾을 필요가 없어졌습니다. 정산 성공/실패 여부를 슬랙 알림봇이 실시간으로 알려주게 되면서 정산 담당자가 문제를 직접 인지하고 선제적으로 대응할 수 있게 되었습니다. 개발팀에 대한 의존도가 낮아지고 운영팀의 문제 해결 속도가 눈에 띄게 빨라졌습니다.
3. 명확한 거래 유형 구분으로 '데이터 분석'의 문을 열다 직매입인지, 판매대행인지 섞여 있던 거래 유형을 체계적으로 관리하게 되면서 마켓 비즈니스 모델별 성과 분석과 전략 수립이 용이해졌습니다. 이제 우리는 데이터를 기반으로 "어떤 비즈니스 모델이 더 성장 가능성이 높은가?"에 대한 답을 찾아갈 수 있게 되었습니다.
4. 데이터 고정(Fix)으로 '신뢰'라는 자산을 얻다 무엇보다 가장 큰 성과는 배치로 생성된 정산 데이터는 더 이상 변경되지 않는다는 '신뢰'를 얻은 것입니다. 이는 "숫자가 왜 안 맞죠?"와 같은 소모적인 논쟁을 끝내고, 모두가 데이터의 '검증'이 아닌 '활용'에 집중할 수 있는 문화를 만드는 가장 큰 원동력이 되었습니다.
이러한 변화를 실제로 현업에서 가장 크게 체감하고 있는 사업운영팀의 Daisy는 이번 프로젝트가 가져온 변화를 '업무 방식의 근본적인 혁신'이라고 평가해 주셨습니다. 이전에는 월말마다 파트너사와 정산 금액을 맞추는 대사 작업 시 '데이터의 불확실성'이 가장 큰 고충이었습니다. 양쪽의 숫자가 다를 때, 이것이 단순 시점의 차이인지 실제 데이터 누락인지 원인 파악에만 며칠씩 걸리는 일이 비일비재했습니다. 하지만 '어제 자 데이터는 이 스냅샷이 무조건 맞다'는 절대적인 기준점이 생긴 후, 대사 작업은 '두 데이터셋의 틀린 그림 찾기'처럼 명확한 과제로 바뀌었습니다. 원인 분석 시간이 획기적으로 줄어든 것은 물론, 새롭게 추가된 정산 주기 설정 기능 덕분에 새로운 파트너사를 유치할 때 훨씬 유연하게 협상할 수 있는 비즈니스적인 성과로도 이어졌습니다.
결론: 문제를 푸는 것보다 중요한 것
이번 정산 시스템 개선 프로젝트는 단순히 낡은 시스템을 교체한 것을 넘어 팀의 데이터 활용 방식과 일하는 방식에 영향을 미쳤습니다.
가장 핵심적인 변화는 'Single Source of Truth(SSoT, 단일 진실 공급원)'의 확립이었습니다. 이것이 가져온 가장 실질적인 변화는 매일 반복되던 대사(Reconciliation) 작업에서 나타났습니다. 결국 '어디서부터 잘못됐는지'를 찾는 막막함이 '무엇이 잘못됐는지'를 찾는 명확한 과제로 전환된 것 이것이 이번 프로젝트가 이뤄낸 가장 중요한 업무 방식의 변화입니다.
이런 변화를 겪으면서 신입 엔지니어인 저도 기술 외적으로 정말 많은 걸 배웠습니다. 바로 잘 정제된 데이터 기준점 하나가 팀의 문제 해결 방식을 얼마나 효율적으로 만들 수 있는지 직접 목격한 것입니다. 기술로 복잡한 문제를 해결하는 것만큼, 그 문제의 원인을 명확히 정의하고 모두가 동의할 수 있는 기준점을 만드는 과정이 중요하다는 것을 깨달았습니다.
KCD의 첫 신입으로서 이 프로젝트를 완수한 경험은, 앞으로 제가 어떤 엔지니어가 되어야 할지 방향을 알려준 소중한 나침반이 되었습니다. 첫 프로젝트를 통해 '기준'의 중요성을 배운 것처럼 앞으로도 단단한 기준을 세우는 엔지니어로 성장하고 싶습니다.
지금, KCD는 사장님의 더 나은 내일을 위해 함께할 동료를 찾고 있어요.
✨영입 중인 포지션 확인하기
✨KCD가 더 궁금하다면?
안녕하세요! KCD 마켓팀의 백엔드 엔지니어 Jose(김호현)입니다.
KCD의 합류해 맡게 된 제 첫 프로젝트는 실시간으로 변하던 데이터를 배치(Batch) 정산으로 전환해 안정적인 정산 시스템을 만드는 일이었습니다. 이번 글에서는 신입 개발자의 시선에서 이 중요한 프로젝트를 어떻게 해결해 나갔는지 그 과정에서 무엇을 배웠는지 공유해 보려고 합니다.
이런 내용을 담았어요
이런 분들에게 도움이 될 것 같아요
배경: 신뢰할 수 없었던 데이터와의 싸움
제가 프로젝트를 맡기 전, 마켓의 정산 데이터는 요청이 들어올 때마다 주문, 취소, 배송 등 여러 데이터를 실시간으로 조회해서 만들어졌습니다. 이 방식은 두 가지 고질적인 문제를 안고 있었죠.
첫째, 운영상의 혼란이 컸습니다. 데이터가 실시간으로 변하다 보니 어제 확인했던 정산 금액이 오늘 다시 조회하면 달라져 있는 일이 비일비재했습니다. 이건 입점사 문의에 대응하는 운영팀에 큰 혼란을 주었고 월별 최종 대사 시점에 숫자가 맞지 않는 문제로 이어지기도 했습니다.
둘째, 데이터의 신뢰도 문제였습니다. 간헐적으로 발생하는 버그로 인해 정산 기준일(배송완료 또는 환불 시점)이 의도치 않게 변경되는 경우가 있었는데요. 특히 이 변경이 월을 넘어가게 되면 입점사에 지급되어야 할 정산 금액과 실제 데이터가 달라지는 심각한 이슈가 발생했지만 복잡한 실시간 조회 로직 속에서 정확한 원인을 찾는 건 정말이지 쉽지 않았습니다.
해결 과정: 실시간 대신 '스냅샷'이라는 기준을 세우다
이 문제를 해결하기 위해 "정산 데이터는 실시간으로 정확할 필요가 없다"는 생각의 전환에서 출발했습니다. 매일 새벽, 전날까지의 모든 데이터를 기준으로 변하지 않는 '스냅샷'을 만들어 둔다면 신뢰도와 성능을 모두 잡을 수 있을 거라 확신했죠.
AS-IS(좌): 요청 시마다 여러 DB를 복잡하게 조회하여 신뢰도 확보가 어려웠습니다.
TO-BE(우): 매일 한 번의 배치 작업으로 신뢰할 수 있는 데이터를 미리 생성하여 단순하고 명확한 구조를 만들었습니다.
신입인 제게 '정산'이라는 도메인은 거대한 벽처럼 느껴졌습니다.😅 어디서부터 시작해야 할지 막막해서 처음 며칠은 기존 API의 응답(response) 값을 하나하나 뜯어보며 정산에 필요한 데이터 조각들을 역으로 추적하는 것이었어요.
분석 과정에서 중요한 사실을 하나 발견했습니다. 문제 해결의 핵심은 단순히 조회 로직을 개선하는 것이 아니라 누가 언제 조회하든 동일한 결과를 보장하는 '신뢰도 높은 정산 데이터 구조'를 목표로 재설계해야 한다는 걸요. (이 목표를 생각하도록 이끌어주신 마켓팀 BE Black 감사합니다!).
이 목표를 달성하기 위해 몇 가지 중요한 원칙을 세우고 설계를 진행했습니다.
첫째, 데이터의 추적성을 확보하는 것이었습니다. 모든 정산 데이터에 주문, 취소 등 원본 데이터의 고유 ID를 함께 저장하도록 스키마를 설계했습니다. 예를 들어, SETTLEMENT라는 테이블에 기존 금액 데이터 외에도 정산의 근거가 되는 order_id, refund_id, payment_date, created_at(스냅샷 생성 시점) 등의 컬럼을 추가하여 데이터가 어떤 원본으로부터 언제 생성되었는지 명확히 추적할 수 있도록 했습니다. 이 설계를 통해 데이터 불일치 문제가 발생했을 때, 그 원인을 찾는 과정을 획기적으로 단축하고 명확한 근거를 가지고 데이터를 검증할 수 있게 되었습니다.
둘째, 시스템의 유연성과 안정적인 운영을 고려하는 것이었죠. 저희 팀에서는 Spring Batch를 활용하여 매일 새벽, 특정 시간에 안정적으로 데이터를 처리하는 배치 잡(Job)을 구성했습니다. 이 매일 실행되는 배치 작업에 '시작일'과 '종료일'을 파라미터로 전달할 수 있게 설계했습니다. 덕분에 전체 데이터를 재처리하는 무거운 작업 없이도 특정 기간의 데이터만 선별하여 검증하거나 재실행하는 것이 가능해졌습니다.
마지막으로, 데이터의 무결성을 지키는 로직을 추가했습니다. 만약 특정 기간의 데이터가 이미 스냅샷으로 존재한다면 새로운 배치 작업은 이를 무조건 덮어쓰는 대신 기존 데이터와 새로 만든 데이터를 항목별로 비교하며 대사를 진행합니다. 이 과정을 통해 데이터 정합성을 꾸준히 유지하고 예기치 못한 오류를 방지할 수 있었습니다.
결과: 단순한 개선을 넘어, 업무 방식의 혁신으로
새로운 배치 정산 시스템의 도입은 단순히 속도가 빨라지고 데이터가 정확한 것 이상의 변화를 가져왔습니다. 이는 정산을 담당하는 운영팀의 업무 방식 자체를 혁신하는 계기가 되었습니다.
1. 유연한 정산 주기 설정으로 비즈니스 기회를 만들다 이전에는 정산 주기를 설정하는 기능이 없어 모든 입점사를 동일한 기준으로 관리해야 했습니다. 하지만 이번 프로젝트를 통해 정산 주기를 일/주/월 단위로 유연하게 설정할 수 있게 되면서 입점사별 맞춤형 관리가 가능해졌습니다. 이는 새로운 입점사를 유치할 때 매력적인 조건이 되었고 비즈니스 확장에도 직접적으로 기여했습니다.
2. 알림봇 연동으로 '문제 해결사'가 된 운영팀 "정산이 이상해요!" 더 이상 개발자를 찾을 필요가 없어졌습니다. 정산 성공/실패 여부를 슬랙 알림봇이 실시간으로 알려주게 되면서 정산 담당자가 문제를 직접 인지하고 선제적으로 대응할 수 있게 되었습니다. 개발팀에 대한 의존도가 낮아지고 운영팀의 문제 해결 속도가 눈에 띄게 빨라졌습니다.
3. 명확한 거래 유형 구분으로 '데이터 분석'의 문을 열다 직매입인지, 판매대행인지 섞여 있던 거래 유형을 체계적으로 관리하게 되면서 마켓 비즈니스 모델별 성과 분석과 전략 수립이 용이해졌습니다. 이제 우리는 데이터를 기반으로 "어떤 비즈니스 모델이 더 성장 가능성이 높은가?"에 대한 답을 찾아갈 수 있게 되었습니다.
4. 데이터 고정(Fix)으로 '신뢰'라는 자산을 얻다 무엇보다 가장 큰 성과는 배치로 생성된 정산 데이터는 더 이상 변경되지 않는다는 '신뢰'를 얻은 것입니다. 이는 "숫자가 왜 안 맞죠?"와 같은 소모적인 논쟁을 끝내고, 모두가 데이터의 '검증'이 아닌 '활용'에 집중할 수 있는 문화를 만드는 가장 큰 원동력이 되었습니다.
이러한 변화를 실제로 현업에서 가장 크게 체감하고 있는 사업운영팀의 Daisy는 이번 프로젝트가 가져온 변화를 '업무 방식의 근본적인 혁신'이라고 평가해 주셨습니다. 이전에는 월말마다 파트너사와 정산 금액을 맞추는 대사 작업 시 '데이터의 불확실성'이 가장 큰 고충이었습니다. 양쪽의 숫자가 다를 때, 이것이 단순 시점의 차이인지 실제 데이터 누락인지 원인 파악에만 며칠씩 걸리는 일이 비일비재했습니다. 하지만 '어제 자 데이터는 이 스냅샷이 무조건 맞다'는 절대적인 기준점이 생긴 후, 대사 작업은 '두 데이터셋의 틀린 그림 찾기'처럼 명확한 과제로 바뀌었습니다. 원인 분석 시간이 획기적으로 줄어든 것은 물론, 새롭게 추가된 정산 주기 설정 기능 덕분에 새로운 파트너사를 유치할 때 훨씬 유연하게 협상할 수 있는 비즈니스적인 성과로도 이어졌습니다.
결론: 문제를 푸는 것보다 중요한 것
이번 정산 시스템 개선 프로젝트는 단순히 낡은 시스템을 교체한 것을 넘어 팀의 데이터 활용 방식과 일하는 방식에 영향을 미쳤습니다.
가장 핵심적인 변화는 'Single Source of Truth(SSoT, 단일 진실 공급원)'의 확립이었습니다. 이것이 가져온 가장 실질적인 변화는 매일 반복되던 대사(Reconciliation) 작업에서 나타났습니다. 결국 '어디서부터 잘못됐는지'를 찾는 막막함이 '무엇이 잘못됐는지'를 찾는 명확한 과제로 전환된 것 이것이 이번 프로젝트가 이뤄낸 가장 중요한 업무 방식의 변화입니다.
이런 변화를 겪으면서 신입 엔지니어인 저도 기술 외적으로 정말 많은 걸 배웠습니다. 바로 잘 정제된 데이터 기준점 하나가 팀의 문제 해결 방식을 얼마나 효율적으로 만들 수 있는지 직접 목격한 것입니다. 기술로 복잡한 문제를 해결하는 것만큼, 그 문제의 원인을 명확히 정의하고 모두가 동의할 수 있는 기준점을 만드는 과정이 중요하다는 것을 깨달았습니다.
KCD의 첫 신입으로서 이 프로젝트를 완수한 경험은, 앞으로 제가 어떤 엔지니어가 되어야 할지 방향을 알려준 소중한 나침반이 되었습니다. 첫 프로젝트를 통해 '기준'의 중요성을 배운 것처럼 앞으로도 단단한 기준을 세우는 엔지니어로 성장하고 싶습니다.
지금, KCD는 사장님의 더 나은 내일을 위해 함께할 동료를 찾고 있어요.
✨영입 중인 포지션 확인하기
✨KCD가 더 궁금하다면?