정산을 하다보면 생각보다 데이터를 보정해야 할 일이 많이 있습니다. 사용자 행동을 완전히 예측할 수 없기 때문 입니다. 최근 대규모 데이터 보정을 옆에서 보면서 생각이 바뀌게 되었는데, 변화된 생각을 정리하고 싶어 글을 작성하게 되었습니다.
1. 어떤 문제가 발생했을까?
최근 계약서의 수수료율을 변경하면서, 이와 연관된 데이터를 보정해야 하는 이슈가 발생했습니다. 판매자가 커머스에서 상품을 판매하는 과정에서 회사와 다음과 같은 계약 관계를 맺고 있다고 가정해 보겠습니다.
2026.01.01 ~ 2026.02.01 기간 동안 판매된 상품마다 1.5%의 수수료를 지불한다.
그런데 1월 1일부터 15일까지 이미 300개의 상품이 판매된 이후, 수수료율이 잘못 설정된 것을 발견해 1.5%가 아니라 2%로 변경해야 하는 상황이 발생했습니다. 이 경우 단순히 앞으로 적용될 수수료율만 변경하는 것으로 끝나지 않고, 이미 판매된 300건에 대해서도 수수료를 다시 계산해 데이터를 수정해야 합니다. 정산이 발생했다면 정산 데이터도 전부 보정해야 하고요.
- 판매자는 일정 기간 동안 판매 건마다 일정 수수료를 지불하는 플랫폼 이용료 계약을 회사와 맺을 수 있습니다.
- 계약된 수수료율이 잘못 설정된 것을 뒤늦게 발견할 수 있습니다.
- 이 경우 이미 판매된 건들까지 포함해 수수료를 다시 계산하고 데이터를 수정해야 합니다.
- 정산이 발생한 경우, 주문/결제 뿐 아니라 정산 데이터도 함께 재생성 해야 합니다.
몇 건의 데이터를 보정 하는 것은 간단하지만, 데이터가 많다면 이를 모두 보정하는 것은 생각보다 힘듭니다. 주문/결제에 쿠폰, 포인트, 혜택 등과 같은 다양한 도메인이 엮인 경우라면 더욱이요.
- 단순 주문/결제의 경우에는 간단
- 쿠폰, 포인트, 혜택 등이 연관돼 있다면 문제가 심각
2. 데이터 보정에 대한 생각 변화
사실 이전에는 운영 중 문제가 생기면 데이터베이스의 특정 로우를 직접 수정해서 데이터를 보정하는 것이 크게 위험하지 않다고 생각했습니다. 단순히 잘못된 값을 올바른 값으로 바꾸는 것이라고 생각했고, 실제로 빠르게 문제를 해결할 수 있기 때문입니다. 하지만 회사에서 데이터 보정에 대해 사수와 이야기를 나누면서 생각이 많이 바뀌었습니다.
2-1. 정상적인 사용자 플로우를 완전히 벗어난 작업
가장 크게 느낀 부분은 데이터 보정은 정상적인 사용자 플로우를 완전히 벗어난 작업 이라는 점입니다. 서비스는 보통 특정한 비즈니스 로직과 검증 과정을 거쳐 데이터를 생성하거나 수정하도록 설계되어 있습니다. 그런데 운영자가 직접 데이터를 수정하게 되면 이러한 검증 과정이나 트랜잭션 흐름을 모두 우회하게 됩니다. 그 순간부터 데이터는 애플리케이션이 의도한 방식이 아니라 사람의 판단에 의해 바뀐 상태가 됩니다.
2-2. 예측이 어렵다
문제는 이렇게 변경된 데이터가 어떤 사이드 이펙트를 만들지 예측하기 어렵다 는 점입니다. 하나의 테이블만 수정한다고 생각했지만 실제로는 여러 테이블 간의 관계나 캐시, 통계 데이터, 배치 작업 등 다양한 시스템이 얽혀 있을 수 있습니다. 예를 들어, 특정 상태 값을 변경했을 때, 원래는 이벤트가 발생하거나 로그가 남거나 다른 데이터가 함께 생성되어야 할 수도 있습니다. 하지만 DB에서 직접 값을 수정하면 이러한 과정이 전혀 실행되지 않습니다. 결국 데이터는 겉보기에는 정상처럼 보이지만 내부적으로는 시스템의 상태와 맞지 않는 형태가 될 가능성이 있습니다.
2-3. 추적이 어렵다
또 하나 문제는 추적이 어렵다 는 점입니다. 코드로 실행된 로직이라면 로그나 히스토리를 통해 언제 어떤 이유로 데이터가 변경되었는지 확인할 수 있습니다. 하지만 운영자가 직접 데이터를 수정하면 그 변경 이력이 명확하게 남지 않는 경우가 많습니다. 시간이 지나서 문제가 다시 발생했을 때, “이 데이터가 왜 이런 상태가 되었는지”를 파악하기 어려워집니다. 결국 원인을 찾기 위해 더 많은 시간을 쓰게 되고, 같은 문제를 반복할 가능성도 높아집니다.
그래서 데이터를 보정해야 하는 상황이라면 단순히 데이터베이스 값을 바꾸는 방식보다는 가능하면 애플리케이션 로직을 통해 수정하거나, 최소한 보정용 스크립트나 배치를 만들어 재현 가능한 방식으로 처리하는 것이 더 안전하다는 생각을 하게 되었습니다. 이렇게 하면 어떤 로직으로 데이터가 변경되었는지 코드로 남기고, 동일한 문제가 발생했을 때 다시 실행하거나 검증할 수 있기 때문입니다.
3. 어떻게 해야 할까?
사실 아직 뚜렷한 정답은 찾지 못했습니다. 서비스마다 데이터 구조와 도메인이 다르고, 보정이 필요한 상황도 매번 다르게 발생하기 때문입니다. 어떤 경우에는 단순 UPDATE로 해결되기도 하고, 어떤 경우에는 여러 테이블과 도메인이 얽혀 있어 보정 자체가 하나의 사이드 프로젝트 처럼 진행되기도 합니다.
운영팀의 요청은 가급적이면 최대한 반영하려고 합니다. 실제 운영 환경에서는 데이터 보정이 필요한 상황이 생각보다 자주 발생하기 때문입니다. 다른 팀의 고충도 있고요.다만 시스템적으로 영향 범위가 너무 크거나 사이드 이펙트가 발생할 가능성이 높은 경우에는, 단순히 데이터를 수정하기보다는 재무팀과 협의해 수기로 별도 처리하는 방법을 제안할 것 같습니다.
4. 정리
아직 완벽한 방법을 찾은 것은 아니지만, 이번 일을 통해 데이터 보정을 훨씬 조심스럽게 바라보게 되었습니다. 앞으로도 이런 상황이 생길 때마다 생각을 좀 정리해야 겠습니다.