안녕하세요. 상품 메타 스쿼드에서 오프라인 상품 관련 개발을 진행하고 있는 길만자 입니다.
이번 글에서는 24시간 빙글빙글 바쁘게 돌아가는 커머스 서비스의 모니터링 체계에 대해 이야기해볼 건데요, 초창기 알림 체계부터 많은 시행착오를 거쳐서 현재의 모니터링 프로세스를 갖추게 된 그 과정을 상세히 공유해보려고 합니다!
들어가며
올리브영의 온·오프라인 상품은 등록-승인-노출-수정 과정 중 한 부분이라도 지체된다면 사용자에게 바로 영향이 가는 영역인데요, 그렇기 때문에 오류가 발생했을 때 빠르게 확인하고 필요한 조치를 하는 것이 필수적입니다. 만일 어떠한 상품이 판매 종료가 되었는데 상태 변경이 실패하고 판매가 일어난 후에 조치를 취한다면 어떻게 될까요? 결제, 배송, 정산 등 많은 유관조직 및 담당자에게 양해를 구해야 하는 상황이 오게 됩니다. (내 무릎은 늘 가볍지 ...)
또한, 현재 올리브영의 여러 시스템에서 별도로 운영·관리되고 있던 상품 마스터 정보를 통합하는 프로젝트(이하 '상품통합프로젝트')를 진행하면서 기존 Oracle DB에 산재되어 있던 상품 데이터를 Aurora 및 Opensearch로 옮기는 중인데요, 순차 오픈을 위해 Oracle 데이터를 CDC(Change Data Capture, DB의 변경 이벤트를 실시간 스트리밍으로 다른 저장소에 흘려보내는 방식)를 통해 동기화 받고 있는 상황입니다. 배치가 아닌 CDC로 구축된 이 아키텍처를 보시면 실시간성이 얼마나 중요한 프로세스인지 감이 살짝 오시죠?!
💡 참고: 상품 데이터 파이프라인에 사용된 Debezium 기반 CDC 구축 과정은 "상품데이터 Pipeline을 위한 Debezium MSK Connect"에서 자세히 확인하실 수 있습니다.
Phase 1. 초기 알림 시스템
초창기 모니터링에서의 Datadog은 로그를 이용해서 Slack 알림을 받고 해당 상황을 파악하는 것으로만 진행하였습니다. 이외의 데이터 정합성이나 상품 건수 확인은 애플리케이션단의 개발을 통해 배치로 체크하였습니다. 상품 데이터는 00시 기준으로 변경되었고, 타 시스템에서 새벽시간에 데이터를 가져가기 때문에 주간 업무시간에 확인하면 타이밍이 맞지 않았습니다. 또한, CDC를 통한 데이터 동기화가 실패할 경우 계속해서 시도하면 뒤에 업데이트되는 상품들의 병목현상이 일어나기 때문에 우선 에러 로그만 출력하고 수동으로 동기화를 진행하였습니다.
1-1. 기존 방식의 주요 문제점
저희는 아래와 같은 사항을 주요 문제점으로 파악하였고 이를 개선 및 고도화하여 더 안정적인 시스템을 만들어보기로 했습니다.
- 데이터 정합성 체크를 위한 API 호출이 실패하면 체크 자체가 불가능 → 정합성 깨진 사실을 인지조차 못 함
- 비교 대상 컬럼이 추가될 때마다 애플리케이션 수정·배포 필요 → 정책 변경에 큰 작업 비용 발생
- 에러 로그가 곧 알림이므로 받는 즉시 처리해야 함 → 새벽 호출 누적 및 담당자 피로도 상승 (할 수 있다, 할 수 있다, 할 수 없...다)
Phase 2. 진화하는 알림 시스템
가장 먼저 빠른 대응이 필요한 에러를 인지할 수 있도록 온콜을 등록하였습니다. 사내에서 협의된 프로세스에 따라 유관 담당자들의 그룹을 지정하여 Google 사용자 그룹에 추가한 후 담당자들에게 맞는 온콜을 지정하는 방식이었습니다. 또한, QA팀의 지원으로 소스 배포가 필요 없는 정합성 검증 프로세스를 구성하였습니다. 개발팀에서 데이터 비교할 API 2개를 전달하면 시간대마다 해당 API를 호출하는 동시에 응답 값을 비교할 수 있었습니다. 덕분에 실시간으로 데이터 정합성 체크가 가능했습니다.
💡 참고: 올리브영이 Google 사용자 그룹 기반 이메일로 온콜 트리거를 통합하고 관리하는 이야기는 "운영 비용을 95% 절감한 서버리스 온콜 시스템 구축기"에서 자세히 확인하실 수 있습니다.
2-1. Phase 1에서 개선된 점
- 에러 로그가 곧 알림이라 새벽 호출 누적 → 담당자 그룹 매핑으로 온콜 등록하여 알림 도달 보장
- 비교 대상 컬럼 추가 시마다 배포 필요 → QA팀 정합성 검증 프로세스로 위임, 개발팀이 API 2개만 제공하면 배포 없이 컬럼 추가 가능
2-2. Phase 2의 문제점
- 알림이 그룹에 도달 → 누가 처리할지 불명확
- 재처리 프로세스 부재 → 재시도하면 풀리는 케이스도 사람이 수동으로 다시 처리
- 특정 날짜 재실행 등의 케이스 → 수동 정합성 검증은 매번 QA팀 지원 필요
Phase 3. 현재의 알림 시스템
3-1. DLQ 프로세스로 재처리 자동화
가장 먼저 DLQ 프로세스를 통해 재처리 작업을 수행하고, 최종 실패한 상품에 대해 기록하여 수동 동기화 프로세스를 간소화하였습니다. 2-2. Phase 2의 문제점에서 언급한 바와 같이, 재시도하면 정상 처리되는 건들도 수동으로 재처리해야 한다는 문제가 있었는데요, 사실 동기화 실패의 상당수는 일시적인 네트워크 및 순서 문제라서, 잠시 후에 다시 시도하면 멀쩡히 들어가는 경우가 대부분이었습니다.
그래서 저희는 DLQ(Dead Letter Queue) 프로세스를 도입했습니다. 기존엔 Oracle → Aurora → Opensearch 동기화가 실패하면 별도 처리 없이 그냥 커밋되고, 매시 15분마다 도는 정합성 체크에서 "어라라 안 맞네?"하고 검출된 걸 사람이 수동으로 업데이트했습니다. 실시간 처리도 안 되고, 사람 손을 타니 휴먼 에러 위험도 있었고요. 이에 시스템을 수정했고, 지금은 아래와 같이 동작합니다.
- 메시지 처리가 실패하면 3회 재시도 (일시 오류 대부분이 짧은 시간 내 회복되는 패턴이라, 후속 메시지 병목을 최소화하는 선에서 설정)
- 그래도 실패할 경우 DLQ로 보내고 실패 로그 적재
- 로그를 상세하게 남겨서, 최종 실패 건만 추적·수동 동기화
실제로 해당 프로세스를 추가한 이후로는 수동 재처리 케이스가 거의 발생하지 않을 정도로 사람이 직접 처리해야 하는 건수가 줄었습니다. 당연히 수동 처리 시 대기하는 시간이 짧아지기도 했습니다. (나이스!!!)
3-2. Datadog Workflow + AI 자동 분석
더 나아가 Datadog Workflow를 통해 온콜 발생 시 AI가 Datadog APM, 로그 분석 결과를 팀 채널로 전송하는 자동화 시스템을 구축하였습니다. 사실 DLQ 재처리로 재시도하면 되는 건들은 자동으로 걸러졌지만, 진짜 온콜이 울렸을 때의 피로는 그대로였는데요. 새벽에 알림 받고 → Datadog 켜고 → APM 뒤지고 → 로그 뒤지고 → 원인을 추측하는 이 과정을 비몽사몽 상태로 진행해야 했습니다. 그래서 '알림이 울리는 순간, 분석까지 끝나 있으면 안 될까?'라는 생각에서 이번 작업에 착수했습니다.
Q. 왜 Datadog Workflow였을까? (Bits AI를 두고 Workflow를 택한 이유)
처음에는 Datadog에서 제공하는 Bits AI를 검토했습니다. AI랑 대화하듯 장애 분석을 맡길 수 있어서 매력적이긴 했지만, 두 가지 장벽이 존재했습니다. 결정적으로 권한 이슈가 있었고, 외부 AI를 붙이려면 MCP/API Key 연동이 필요했습니다. 게다가 분석 완료까지 수 분이 걸리는 비동기 동작이라 언제 작업이 끝났는지를 잡아내기가 까다로웠어요. 그래서 가장 빠르게, 주어진 권한 안에서, 원하는 포맷으로 운영할 수 있는 Workflow를 택하게 되었습니다.
| 도구 | 설명 | 권한 요구 | 장점 | 단점 | 채택 |
|---|---|---|---|---|---|
|
Datadog Workflow
|
모니터 이벤트 기반 노코드 자동화 도구
|
기존 Datadog 권한으로 운영 가능
|
포맷·채널·조건 100% 커스텀
|
워크플로우·스크립트 직접 설계·유지 필요
|
✅ 채택
|
| Bits AI | 자연어 대화형 AI SRE 어시스턴트 | SRE팀 별도 권한 필요 | 자연어로 장애 분석·런북 실행 위임 | 비동기 처리로 완료 시점 불확실, MCP/API Key 연동 필요 | ❌ |
Q. Workflow는 어떻게 동작할까?
- 모니터 → 서비스 매핑 : Monitor ID로 서비스명·환경·Slack 채널을 결정 (catalog-hub, lavender 등)
- 데이터 수집 (병렬) : 최근 15분 APM 지표 + 최근 7일 평시 기준값(baseline) + 에러 로그 집계 + 샘플 로그
- 자동 진단 : 평시 대비 에러 급증 배수, 에러율, 특정 리소스/에러 타입 집중도, p99 지연 등을 계산해 어떤 부분이 이상한지 분석
- Slack 전송 : 진단 요약 + APM 요약 + Top 에러/리소스 + 로그 샘플 + 바로가기 링크를 담당 채널로 발송
온콜 모니터가 울리면 Workflow가 위 내용을 자동으로 수행합니다. 저는 특히 3번을 핵심으로 꼽고 싶은데요, Workflow는 단순히 수치만 던져주는 것이 아니라 "에러가 평시 대비 3.2x 급증 (심각)", "단일 리소스에 에러 50% 집중 → 해당 엔드포인트 의심"과 같은 형태로 사람이 읽고 즉각 판단할 수 있는 형태로 가공해줍니다.
Q. 그래서, 딸깍 한 번에 끝나나요? 🖱️
네! 이제 온콜이 울리면 Slack에 위와 같은 퀵 리포트가 먼저 도착해 있습니다. 담당자는 간략하게 분석된 리포트를 읽고 즉각 조치에 임하면 됩니다. Datadog 화면 어디서든 Bits AI와 대화하며 Workflow를 구성할 수 있어서, 구축도 딸깍 한 번에 완성할 수 있습니다.
3-3. 정합성 수동 검출 자동화
마지막으로 QA팀의 지원으로, 기간·상품 등 조건별 정합성을 개발자가 직접 온디맨드로 실행할 수 있는 웹 페이지를 구축하였습니다. 저희의 경우 기존 정합성 체크 시 셋팅이 모두 코드로 되어 있어 어떤 컬럼이 모니터링되고 있는지 알기 위해서는 QA팀에 문의해야 했었는데요, 이런 시각화된 페이지를 통해서 별도의 요청 없이 개발자가 Data Flow를 확인할 수 있고, 정합성을 수기로 돌릴 수 있는 체계가 완성되었습니다. (데이터 정합성 이상시 함께 정합성 돌려주시던 QA팀 항상 감사드립니다.🥰)
마치며
처음엔 그저 에러 로그를 Slack으로 받으려는 요구사항에서 시작했던 모니터링이, 지금은 재시도는 알아서(DLQ), 분석은 미리(Datadog Workflow), 검증은 자동으로(QA 자동화) 돌아가는 체계가 되었습니다. 돌이켜보면 "이번엔 이게 너무 불편한데?"하는 작은 불편함들을 하나씩 해결해 나간 과정의 연속이었던 것 같아요.
이 여정에서 가장 크게 느낀 건, 모니터링의 목표는 "알림을 더 많이 받는 것"이 아니라, "사람이 개입할 일을 줄이는 것"이라는 점이었습니다. 알림이 와도 재처리로 해결될 건 알아서 해결되고, 정말 사람이 봐야 할 때는 이미 분석이 끝나 있어야 담당자도 진짜 중요한 문제에 집중할 수 있으니까요. (모니터링 하기 싫어서는 정말 아닙니다. 😴)
오늘 이렇게 저희의 시행착오 이야기를 전달드리긴 했지만, 당연하게도 아직 끝이 아닙니다. DLQ 프로세스는 온라인 상품까지 확대 적용을 앞두고 있고, Datadog Bits AI처럼 더 똑똑하게 장애를 분석해 줄 도구들을 계속 검토 및 실험하고 있습니다. 상품통합프로젝트가 마무리되고 더 많은 데이터가 실시간으로 흐르게 될수록, 모니터링 체계도 그에 맞춰 계속 진화시킬 예정입니다. 부디 비슷한 고민을 하고 계신 분들께 작은 힌트가 되었으면 좋겠고, 또 다른 방식을 시도해본 분이 계시다면 댓글로 공유해주시면 기쁘게 배우겠습니다.
아무쪼록 긴 글 읽어주셔서 감사합니다. 저희는 또 다음 개선을 향해 딸깍~ 하러 가보겠습니다! 🖱️
