AI 요약
많은 업무 시스템에서 order_status(1:접수~5:정지), payment_status(1:미청구~4:실패)와 같은 다수의 상태 컬럼이 하나의 테이블(예: orders)에 공존하는 '안티 패턴'이 발견됩니다. 이는 설계를 '무엇을 저장할지(컬럼)'에서 시작하거나, 모든 데이터를 현재 상태를 나타내는 '리소스'로만 간주하기 때문에 발생합니다. 기사는 이러한 설계를 방지하기 위해 시스템에서 발생하는 '이벤트(주문 생성, 심사 결과 수신 등)'를 먼저 정의하고, 현재의 상태를 관리하는 리소스 테이블과 발생 사실을 기록하는 이벤트 테이블(Insert 전용)을 분리할 것을 권장합니다. 특히 외부 API 연동 시 external_status와 같은 원시 코드를 내부 비즈니스 로직과 분리하여 관리함으로써 시스템의 유연성을 확보할 수 있다고 설명합니다.
핵심 인사이트
- 리소스와 이벤트의 명확한 구분: 현재의 상태를 나타내는 '리소스'는 UPDATE가 발생하지만, 사실을 기록하는 '이벤트'는 INSERT만 발생하는 구조로 설계하여 데이터의 무결성을 확보해야 합니다.
- 외부 코드의 오염 방지: 외부 시스템이 제공하는 불규칙한 코드(예: 1~4 다음 9가 오는 비연속적 번호)를 내부 리소스 테이블에 직접 저장하지 말고, 애플리케이션 계층에서 내부 상태로 변환하여 저장해야 합니다.
- 설계 순서의 역전: '저장할 컬럼 정의'부터 시작하는 것이 아니라, '시스템에서 발생하는 이벤트 나열' → '이벤트 결과로 남을 리소스 결정' → '상태 전이도 작성' 순으로 진행해야 합니다.
주요 디테일
- 안티 패턴 예시:
orders테이블에order_status(1:접수, 2:심사중, 3:처리중, 4:완료, 5:정지)와payment_status(1:미청구, 2:청구적, 3:수납완료, 4:실패) 등 성격이 다른 상태값이 복합적으로 존재하는 사례를 제시했습니다. - 데이터 포맷의 문제: 처리 날짜를
processed_at(VARCHAR 8자, YYYYMMDD), 처리 시간을processed_time(VARCHAR 6자, HHMMSS)과 같이 비효율적인 문자열 형식으로 관리하는 관행을 지적했습니다. - 외부 시스템 연동 주의점: 외부 기관마다 다른 코드 체계와 '특정 상태일 때 0을 입력'하는 등의 특수한 비즈니스 규칙이 내부 DB 스키마에 직접 반영되면 코드 리뷰와 유지보수가 극도로 어려워집니다.
- 해결을 위한 4단계: 1) 이벤트 열거, 2) 리소스와 이벤트 기록 테이블 분리, 3) 상태 전이도(State Transition Diagram) 선행 정의, 4) 외부 코드와 내부 상태의 매핑 계층 구축을 제안합니다.
향후 전망
- 유지보수성 향상: 리소스와 이벤트를 분리하면 외부 시스템의 스키마 변경이 내부 비즈니스 로직에 미치는 영향을 최소화할 수 있습니다.
- 데이터 분석 용이성: 이벤트 기반 설계(Event Sourcing의 기초)를 도입함으로써 과거 특정 시점의 상태를 추적하는 히스토리 관리가 정교해질 것으로 예상됩니다.