대시보드 외부 채널 매출 집계 오류 수정

대시보드에서 외부 채널 매출 집계가 모달과 달랐다. 같은 데이터를 두 화면에서 다르게 보여주고 있었는데, 매출 수치가 화면마다 다르면 어느 쪽이 맞는지 판단할 수가 없다. 외부 채널 정산처럼 내부 시스템과 외부 채널 간 금액을 맞춰야 하는 도메인에서는 오차가 신뢰 문제로 직결된다.

변경 파일은 SQL 매퍼 1개. 파일 하나라고 해서 가볍게 볼 작업은 아니었다. 오히려 "파일 하나 고쳤다"는 게 겉으로 보이는 전부고, 왜 그 조건이 틀렸는지, 같은 패턴이 다른 쿼리에도 있는지, 수정이 기존 동작을 깨뜨리지는 않는지 확인하는 게 실제 작업 시간의 대부분을 차지했다. 흔히 버그 픽스를 가볍게 보는 경향이 있는데, 원인 추적과 검증을 제대로 하면 절대 가볍지 않다.

원인 파악

SQL 쿼리 조건이 잘못돼 있었다. 정확히는 WHERE 필터나 JOIN 조건이 모달 기준과 달라서 집계에 포함되어야 할 행이 빠지거나, 반대로 포함되지 말아야 할 행이 들어오고 있었다. 기대값과 실제값을 쿼리 단위로 끊어가며 비교하는 방식으로 원인을 좁혔다. DB에서 직접 쿼리를 돌려보면서 어느 조건에서 숫자가 달라지는지 확인하는 게 이런 집계 오류를 찾는 가장 확실한 방법이다.

집계 쿼리에서 화면 간 불일치가 생기는 원인은 대개 몇 가지 유형으로 압축된다.

이번은 마지막 유형에 가까웠다. 같은 "외부 채널 매출"이라는 개념을 두 쿼리가 서로 다른 조건으로 계산하고 있었던 것.

-- 대시보드 쿼리 (수정 전 형태, 예시)
SELECT
  channel,
  SUM(amount) AS revenue
FROM orders
WHERE status = 'completed'
GROUP BY channel;

-- 모달에서 사용하던 산식 기준 (예시)
SELECT
  channel,
  SUM(amount) AS revenue
FROM orders
WHERE status = 'completed'
  AND channel_type = 'external'
  AND settled_at IS NOT NULL
GROUP BY channel;

어느 쪽이 틀렸냐의 문제라기보다, 어느 쪽이 도메인 정의에 맞는지 먼저 정리해야 했다. 외부 채널 매출의 집계 기준을 명확히 하고, 모달 산식을 단일 기준으로 삼아 대시보드를 맞췄다. 이 과정에서 "외부 채널 정산 완료 건"이라는 조건이 두 화면에서 다르게 해석되고 있었다는 것도 확인됐다. 집계 기준이 어딘가에 명문화되어 있지 않으면 쿼리를 작성할 때마다 작성자가 나름대로 해석하게 되고, 이런 불일치가 쌓인다.

수정과 검증

조건을 모달 기준으로 맞추는 수정 자체는 어렵지 않았다. 하지만 수정 전후 검증에 시간을 꽤 썼다. 단순히 증상만 잡는 게 아니라 원인을 파악하고, 비슷한 패턴이 다른 집계 쿼리에도 있는지 확인했다. 위험한 케이스는 함께 수정했고, 당장 문제가 없어 보이는 것도 플래그 남겨뒀다.

버그 수정할 때 습관적으로 체크하는 항목들이다.

• 같은 로직이 다른 경로에도 있는지 (중복 코드 체크)
• 수정이 기존 정상 케이스를 망가뜨리지 않는지 (회귀 방지)
• 해당 화면 또는 API에서 실제 동작 확인
• 관련 숫자를 다른 화면과 cross-check

수정 후에는 버그를 직접 재현해서 정상 동작 확인, 외부 채널 관련 다른 화면의 수치도 비교했다. 숫자 일치 확인.

엣지 케이스를 꼼꼼히 따지는 게 귀찮아 보여도, 같은 버그로 다시 오는 시간 비용이 훨씬 크다. 몇 번 겪고 나면 꼼꼼히 확인하는 게 오히려 빠른 길이라는 걸 몸으로 알게 된다. 특히 버그를 직접 재현해서 수정 전후를 확인하는 루틴은 빼먹기 쉬운데, 이게 없으면 "수정한 것 같은데 맞는지 모르겠다"는 상태로 배포하게 된다.

집계 산식 불일치가 만드는 신뢰 문제

사내 서비스를 만들다 보면 기능 하나가 단순히 화면에 버튼 하나 추가하는 것으로 끝나지 않는다는 걸 계속 체감한다. SQL 집계, 상태 머신, 예외 처리, 화면 렌더링, 권한 체크가 모두 엮여 있어서 어느 하나만 빠뜨려도 숫자가 맞지 않거나 특정 사용자에게 이상한 화면이 나타난다.

특히 금융/결제 도메인은 숫자 하나가 틀리면 신뢰가 무너질 수 있어서 꼼꼼함이 기본값이어야 한다. "대충 맞는 것 같다"로 넘어가면 나중에 반드시 다시 돌아온다.

이번처럼 집계 산식이 화면마다 다를 때 생기는 가장 큰 문제는, 사용자가 어느 숫자를 믿어야 할지 모른다는 것이다. 데이터는 같은데 화면마다 달리 보이면 시스템 전체에 대한 신뢰가 흔들린다. 화면 간 숫자 일관성은 기능의 일부라고 생각한다.

이런 불일치를 구조적으로 방지하는 방법도 있다. 집계 산식을 DB 뷰나 공통 쿼리 단위로 뽑아두면, 한쪽이 바뀔 때 다른 쪽이 따라가지 못하는 문제를 줄일 수 있다. 각 화면이 독립적인 쿼리를 갖고 있으면 기준이 바뀔 때 모든 쿼리를 일일이 찾아서 맞춰야 하고, 그 과정에서 하나라도 빠뜨리면 또 불일치가 생긴다. 완벽하게 해결하려면 집계 기준의 단일 진실 소스가 필요하고, 그게 여의치 않은 상황이라면 최소한 집계 기준 변경 시 관련 쿼리 전체를 체크하는 프로세스라도 있어야 한다.

개발 방식 면에서는 변경 전 현재 동작 수치를 메모하고, 수정 후 같은 케이스로 확인하는 루틴을 유지하고 있다. 커밋 메시지는 "무엇을"보다 "왜"를 담으려 한다. 나중에 git blame 찍었을 때 의도가 보이는 커밋이 훨씬 도움이 된다. 작은 커밋을 자주 하면 문제가 생겼을 때 어느 변경에서 깨졌는지 찾기 쉽고, 논리적으로 독립된 단위로 쪼개는 습관을 유지하는 게 그래서다.