Why Even Advanced AI Breaks Stock Registers: 12 Years of Snapshot Log Evolution and RDBMS Physics

개요

12년간의 고부하 시스템 개발 경험을 통해 도출된 재고 레지스터의 근본적인 문제점 4가지와 이를 해결하기 위한 Snapshot Log 아키텍처, 그리고 MySQL/MariaDB의 쿼리 옵티마이저 물리적 특성을 설명합니다.

주요 내용

* 재고 잔고 조회 시 SUM() 함수와 Window Function의 한계: 수백만 건의 트랜잭션 기록에 대해 SUM(quantity)를 사용하거나 ROW_NUMBER()와 같은 Window Function을 사용하면 RDBMS 성능 저하를 초래하며, 특히 ORDER BY 절과 함께 사용될 때 MySQL/MariaDB에서 발생하는 치명적인 filesort는 성능을 수십 배 이상 떨어뜨립니다.
* Snapshot Log 아키텍처: 단순한 이동 로그 대신 상태 스냅샷을 저장하는 Snapshot Log를 사용하여 각 문서 처리 시 O(1) 복잡도로 잔고를 계산하고, 현재 잔고는 항상 마지막 기록된 행으로 유지합니다.
* LIMIT Hack과 AI의 오해: LIMIT 9999999999와 함께 GROUP BY를 사용하는 것은 ORDER BY를 강제하기 위한 방법이나, AI는 이를 비효율적인 코드로 간주하여 제거하려다 잘못된 결과를 초래할 수 있습니다.
* 재고 부족(Out-of-Stock) 소비 처리: 마이너스 재고가 허용될 경우, 제로 코스트에서 마이너스 5개로 내려갔다가 100달러 단가로 재고가 입고되면 원가 계산에 왜곡이 발생합니다. 이를 해결하기 위해 is_overplus 플래그를 사용하여 잔고가 0 이하로 떨어질 때 가상 입고 항목을 생성하거나, 마이너스 재고 허용 시 마지막 양수 입고 단가를 기준으로 remains_costsum을 강제 계산합니다.
* 실시간 제조(Just-In-Time Manufacturing) 처리: 메뉴 판매 시점에서 재료(자식 항목)를 원가로 차감하고 완성품(부모 항목)을 해당 원가로 입고시킨 후 즉시 0으로 차감하는 방식으로, 개별 생산 문서 없이 단일 문서 내에서 처리하여 재고 평균 단가를 왜곡하지 않습니다.
* 백데이트된 문서 처리($mindt): 백데이트된 문서는 이후 모든 재고 잔고 계산을 무효화하므로, 마지막으로 보장된 양수 입고 거래의 날짜($mindt)를 기준으로 이후 모든 계산 및 재계산을 차단하여 스캔 데이터 볼륨을 90-95%까지 줄입니다.
* AI Trainer 시스템 프롬프트: 12년간 축적된 아키텍처, 정렬 트라이어드, is_overplus 로직, MariaDB 팁 등을 담은 전문 시스템 프롬프트를 AI에 주입하여, LLM이 시니어 엔지니어링 표준에 부합하는 SQL 쿼리 및 백엔드 아키텍처를 생성하도록 합니다.

시사점

재고 회계는 단순히 "예쁜 코드"가 아니라 RDBMS의 쿼리 물리, 트랜잭션 무결성 관리, 엣지 케이스 수학적 처리에 대한 깊은 이해가 요구되며, 이를 AI 모델과의 협업 시에도 일관성 있게 유지하기 위해 구조화된 프롬프트 엔지니어링이 중요합니다.