<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: park suhyun</title>
    <description>The latest articles on DEV Community by park suhyun (@park_suhyun_44708616b3a00).</description>
    <link>https://dev.to/park_suhyun_44708616b3a00</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4229516%2Ff8ddc479-2f79-4295-95e9-25505916582b.png</url>
      <title>DEV Community: park suhyun</title>
      <link>https://dev.to/park_suhyun_44708616b3a00</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/park_suhyun_44708616b3a00"/>
    <language>en</language>
    <item>
      <title>“어디서 틀렸는지 모르겠습니다.” — 예치금 정합성 배치를 주문 1건 단위로 다시 설계한 이야기</title>
      <dc:creator>park suhyun</dc:creator>
      <pubDate>Sat, 07 Nov 2026 01:20:57 +0000</pubDate>
      <link>https://dev.to/park_suhyun_44708616b3a00/eodiseo-teulryeossneunji-moreugessseubnida-yecigeum-jeonghabseong-baecireul-jumun-1geon-danwiro-dasi-seolgyehan-iyagi-4h87</link>
      <guid>https://dev.to/park_suhyun_44708616b3a00/eodiseo-teulryeossneunji-moreugessseubnida-yecigeum-jeonghabseong-baecireul-jumun-1geon-danwiro-dasi-seolgyehan-iyagi-4h87</guid>
      <description>&lt;h2&gt;
  
  
  들어가며
&lt;/h2&gt;

&lt;p&gt;예치금을 다루는 시스템에서 금액의 오차는 작더라도 그냥 넘길 수 없습니다.&lt;br&gt;
그런데 금액이 틀렸다는 사실을 아는 것과, 왜 틀렸는지를 아는 것은 전혀 다른 문제였습니다.&lt;/p&gt;

&lt;p&gt;이번 글에서는 하루치 합계를 비교하던 예치금 정합성 배치를, 주문 1건의 기대값에서 출발하는 구조로 바꾼 과정을 이야기합니다.&lt;/p&gt;
&lt;h2&gt;
  
  
  기존 구조: 하루치 합계를 비교하는 양식
&lt;/h2&gt;

&lt;p&gt;예치금의 정합성을 보여주는 템플릿이 있습니다. 핵심은 다음 한 줄로 정리됩니다.&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;오늘자 거래 집계 금액 = 오늘과 어제 사이의 거래금액 차이
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;결제금액, 수수료 등 여러 항목의 하루치 데이터를 집계하고, 그 합을 비교해 오차를 확인하는 방식이었습니다.&lt;/p&gt;

&lt;h2&gt;
  
  
  문제: 오차는 보이는데 원인은 보이지 않는다
&lt;/h2&gt;

&lt;p&gt;이 구조에는 두 가지 문제가 있었습니다.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;1. 계산이 오래 걸렸습니다&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;하루치 거래금액, 즉 오늘까지의 거래금액과 어제까지의 거래금액의 차이를 각각 계산하기 위해 DB 전체를 뒤져야 했습니다.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;2. 오차의 원인을 추적하기 어려웠습니다&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;오늘자 거래 합계만으로는 어떤 주문에 문제가 있는지 알 수 없었습니다.&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;주문 1건이 잘못된 것인지&lt;/li&gt;
&lt;li&gt;여러 건이 잘못되어 그 합으로 오차가 발생한 것인지&lt;/li&gt;
&lt;li&gt;서로 다른 항목의 이슈가 상쇄되어 드러나지 않은 것은 없는지&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;합계는 이상 여부를 확인하는 데는 유용합니다. 하지만 합산 과정에서 건별 정보가 사라지기 때문에, 원인을 찾는 데는 도움이 되지 않았습니다.&lt;/p&gt;

&lt;p&gt;오차 하나를 찾아내는 데 꼬박 하루가 걸리기도 했습니다.&lt;/p&gt;

&lt;h2&gt;
  
  
  전환점: 주문이 단 1건뿐이라면?
&lt;/h2&gt;

&lt;p&gt;일단 하나씩, 거래 집계부터 풀어보기로 했습니다. 출발점은 단순한 질문이었습니다.&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;여러 주문이 아니라 주문이 1건만 있다면, 템플릿에는 어떻게 보여야 할까?&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;이 질문이 곧 답이었습니다. 주문 1건, 거래상태 1건마다 템플릿에 나타나야 할 값은 정해져 있기 때문입니다.&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;주문 1건, 거래상태 1건에 대한 기대값을 정의&lt;/li&gt;
&lt;li&gt;기대값을 규칙으로 만들어 배치에 적용&lt;/li&gt;
&lt;li&gt;규칙을 통과하지 못한 건을 점검하고 수정&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;이렇게 검증을 통과한 건들이 쌓이면, 하루치 거래 합계도 신뢰할 수 있는 값이 됩니다.&lt;br&gt;
합계를 먼저 보고 원인을 거슬러 찾던 흐름이, 건별로 검증한 값을 쌓아 신뢰할 수 있는 합계를 만드는 흐름으로 바뀌었습니다.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2F4jy6sizqo2tn3a0g9vu0.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2F4jy6sizqo2tn3a0g9vu0.png" alt=" " width="799" height="231"&gt;&lt;/a&gt;&lt;/p&gt;
&lt;h2&gt;
  
  
  정산에 의미 있는 상태만 남기기
&lt;/h2&gt;

&lt;p&gt;주문상태별로 규칙을 만들다 보니 발견한 사실이 있습니다.&lt;br&gt;
주문상태 중에는 Hold처럼 정산 관점에서 의미가 없는 상태도 있었습니다.&lt;/p&gt;

&lt;p&gt;이런 상태는 과감히 제외하고, 정산에 의미 있는 상태만 남겼습니다.&lt;/p&gt;
&lt;h2&gt;
  
  
  중복을 막는 거래상태별 기준일 테이블
&lt;/h2&gt;

&lt;p&gt;의미 있는 상태만 골라도 문제는 남아 있었습니다.&lt;br&gt;
지금 계산하는 상태가 어쩌면 중복일지도 모릅니다. 과거 데이터를 다시 조회해 동일한 상태가 또 있는지 확인하고, 있으면 이번 계산에서 제외해야 했습니다.&lt;/p&gt;

&lt;p&gt;이 문제는 별도의 테이블을 만들어 해결했습니다.&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;주문번호별로 거래상태의 날짜를 정의&lt;/li&gt;
&lt;li&gt;집계는 이 테이블에 적힌 날짜를 기준으로 수행&lt;/li&gt;
&lt;li&gt;중복 내역이 들어와도 기준 날짜는 변경되지 않음&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;같은 내역이 몇 번 들어오더라도 집계 결과는 달라지지 않습니다.&lt;br&gt;
필요한 거래상태만, 정확한 날짜로 정의하니 조회 범위도 줄었고 실행 시간도 크게 단축되었습니다.&lt;/p&gt;
&lt;h2&gt;
  
  
  3개의 검증축
&lt;/h2&gt;

&lt;p&gt;신뢰할 수 있는 거래 합계가 생기자, 이 값을 기준으로 삼을 수 있었습니다.&lt;br&gt;
거래 합계를 바탕으로 거래외 데이터를 계산하고, 이를 하루치 거래금액과 비교합니다.&lt;/p&gt;

&lt;p&gt;이렇게 세 개의 검증축이 완성되었습니다.&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;
&lt;strong&gt;거래&lt;/strong&gt;: 건별 규칙을 통과한 값을 쌓은 합계&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;거래외&lt;/strong&gt;: 거래 합계를 기준으로 계산한 거래외 데이터&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;전체 거래금액&lt;/strong&gt;: 위 값들과 대조하는 하루치 거래금액&lt;/li&gt;
&lt;/ul&gt;
&lt;h2&gt;
  
  
  Rule을 쌓아 만든 정합성 체크 툴
&lt;/h2&gt;

&lt;p&gt;신뢰할 수 있는 값이 갖춰지자, 그 위에 필요한 Rule을 하나씩 정의할 수 있었습니다.&lt;br&gt;
예를 들면 다음과 같은 규칙입니다.&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;구매자의 예치금 사용액 + 판매자의 정산금 + 거래외 예치금 변동 = 회원 전체의 예치금 변동액
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;필요한 규칙을 채워 넣고, 어긋나는 값은 표시합니다.&lt;br&gt;
여기에 집계 결과를 보기 좋게 배치하면, 예치금 정합성을 한눈에 확인할 수 있는 체크 툴이 완성됩니다.&lt;/p&gt;

&lt;h2&gt;
  
  
  마치며
&lt;/h2&gt;

&lt;p&gt;정합성 구조를 바꾸며 얻은 가장 큰 교훈은, 합계의 신뢰도는 그 합계를 이루는 가장 작은 단위에서 나온다는 점입니다.&lt;br&gt;
오차가 발생했을 때 DB 전체를 뒤지는 대신, 규칙을 통과하지 못한 건부터 살펴보면 됩니다.&lt;/p&gt;

&lt;p&gt;복잡해 보이던 문제도 “주문이 1건뿐이라면?”이라는 간단한 질문으로 풀리기 시작했습니다.&lt;/p&gt;

</description>
      <category>architecture</category>
      <category>backend</category>
      <category>debugging</category>
      <category>systemdesign</category>
    </item>
  </channel>
</rss>
