서비스를 멈추지 않는 DB 스키마 변경: 확장 후 축소
운영 중인 DB에 새 컬럼을 만들고 앱 코드를 동시에 바꾸면 잠깐 다른 버전의 앱이 공존하는 동안 오류가 날 수 있습니다. 무중단 스키마 변경은 한 번에 바꾸는 일이 아니라 옛 코드와 새 코드가 함께 살아도 되는 기간을 설계하는 일입니다.
NOTES
데이터 아키텍처
모델을 만들고, 웹과 앱을 짓고, 업무를 자동화하며 확인한 것을 기록합니다. 통한 방법만이 아니라 통하지 않았던 시도까지 남깁니다.
TOTAL 11 · 데이터 아키텍처
이벤트 필드 하나 바꿨는데 구독자가 멈췄다면
이벤트에 필드를 하나 추가하거나 이름을 바꾸면 생산 서비스는 정상인데 구독 서비스가 멈출 수 있습니다. 이벤트는 보낸 뒤 여러 시스템이 각자의 속도로 읽는 계약입니다. 생산자만 보고 스키마를 바꾸지 않으려면 호환성과 전환 기간을 설계해야 합니다.
대시보드 숫자가 왜 바뀌었을까: 지표의 출처와 정의 이력
지표 카드에서 원천 데이터, 계산식, 담당자, 버전을 거슬러 올라갈 수 있는 데이터 계보 설계입니다.
같은 설비가 시스템마다 다른 이름이라면: 설비 마스터 ID 통합
ERP·MES·보전 시스템의 설비 식별자를 연결해 이력과 비용을 같은 자산에 모으는 방법입니다.
압력값 100이 같은 값이 아니라면: 센서 단위와 보정 이력 관리
설비 센서의 숫자를 모으기 전에 단위·스케일·보정 상태를 확인해야 합니다. 원본과 정규화 값을 함께 지키는 데이터 설계를 다룹니다.
대시보드 숫자는 언제 기준일까: 데이터 신선도를 보여주는 법
실시간처럼 보이는 화면의 숫자가 실제로는 지난 배치 결과일 수 있습니다. 이벤트 시각부터 화면 갱신까지의 지연을 구분하고 신선도를 표시하는 방법입니다.
운영 DB를 분석 시스템에 옮길 때 중간 변경을 놓치지 않으려면: CDC 시작과 복구
초기 전체 복사와 이후 변경 이벤트 사이에는 놓치기 쉬운 경계가 있습니다. 스냅샷 시점, 로그 위치, 삭제 이벤트, 재시작과 대사까지 CDC 구축의 핵심을 정리합니다.
어제 매출이 오늘 바뀌었다면: 늦게 도착한 데이터와 재계산 설계
이벤트 발생 시각과 수집 시각을 분리하고, 지연 데이터·중복·정정을 반영해 업무 지표를 안전하게 다시 계산하는 방법.
저장했는데 검색에 안 나온다면: DB와 검색 색인의 정합성 운영법
원본 DB에는 새 문서가 있는데 검색 결과는 옛 내용일 수 있습니다. 색인 반영 지연, 삭제 누락, 변경 순서 역전까지 다루는 검색 운영 설계를 정리했습니다.