에러로그 하나에 깨던 새벽에서 벗어나기까지 — 상품 모니터링 진화기

올리브영 상품 메타 스쿼드가 새벽마다 울리는 에러 로그 알림에서 벗어나기까지의 모니터링 진화 기록이다. 상품이 등록·승인·노출·수정 과정 중 한 부분이라도 지체되면 사용자에게 바로 영향이 가고, 판매 종료된 상품의 상태 변경이 실패해 판매가 일어나면 결제·배송·정산까지 여러 조직에 양해를 구해야 한다. 초기 Slack 알림 체계에서 온콜과 DLQ 재처리를 거쳐 AI 자동 분석까지 이어진 과정을 다룬다.

핵심 포인트

상품 데이터가 00시 기준으로 변경되고 타 시스템이 새벽에 가져가기 때문에, 주간 업무시간에 확인하면 타이밍이 맞지 않았다.
CDC 동기화가 실패했을 때 계속 재시도하면 뒤에 업데이트되는 상품들의 병목이 생겨, 우선 에러 로그만 출력하고 수동으로 동기화했다.
에러 로그가 곧 알림이라 받는 즉시 처리해야 했고, 정합성 체크를 위한 API 호출이 실패하면 체크 자체가 불가능했다.
비교 대상 컬럼이 추가될 때마다 애플리케이션 수정과 배포가 필요했다.
QA팀 지원으로 소스 배포 없이 개발팀이 API 2개만 제공하면 시간대마다 호출해 응답 값을 비교하는 정합성 검증 프로세스를 구성했다.

상세 정리

배경 아키텍처: 여러 시스템에 흩어져 관리되던 상품 마스터 정보를 통합하는 프로젝트를 진행하며 기존 Oracle 데이터를 Aurora와 Opensearch로 옮기는 중이고, 순차 오픈을 위해 Oracle 데이터를 CDC로 동기화받고 있다.
배치가 아니라 CDC로 구축했다는 점 자체가 실시간성이 중요한 프로세스임을 보여준다고 짚는다.
초창기 방식: 로그로 Slack 알림을 받아 상황을 파악하는 것이 전부였고, 데이터 정합성이나 상품 건수 확인은 애플리케이션단 개발을 통해 배치로 체크했다.
문제 정리: 알림 도달이 보장되지 않고, 정합성 체크가 API 호출 성공에 의존하며, 컬럼 추가마다 배포가 필요하고, 에러 로그를 받는 즉시 사람이 처리해야 했다.
개선 1 온콜: 사내에서 협의된 프로세스에 따라 유관 담당자 그룹을 지정해 Google 사용자 그룹에 추가하고 담당자에게 맞는 온콜을 지정하는 방식으로 알림 도달을 보장했다.
개선 2 정합성 검증 위임: QA팀 지원으로 배포 없이 컬럼을 추가할 수 있는 구조가 되면서 실시간 정합성 체크가 가능해졌다.
남은 문제: 재처리 프로세스가 없어 재시도하면 풀리는 케이스도 사람이 수동으로 다시 처리해야 했고, 특정 날짜 재실행 같은 케이스의 수동 정합성 검증은 매번 QA팀 지원이 필요했다.
개선 3 DLQ: DLQ 프로세스로 재처리를 수행하고 최종 실패한 상품만 기록해 수동 동기화 프로세스를 간소화했다.
온콜 트리거를 Google 사용자 그룹 기반 이메일로 통합한 별도 사례와 Debezium 기반 CDC 구축 과정을 각각 다른 글로 안내한다.