CJ올리브영의 AI 기반 운영 이슈 분석과 일일 점검 자동화

Amazon Bedrock과 Strands Agents SDK를 활용한 운영 에이전트 구축기

글로벌 프로모션 운영 중 장애가 발생하면, 운영자는 장애의 기술적 원인과 실제 고객 영향도를 동시에 파악해야 하는 복잡한 과제에 직면합니다. 시스템 로그에서 에러를 감지하는 것만으로는 부족합니다. 어떤 고객이 혜택을 받지 못했는지, 고객별 피해 수준과 보상 기준은 무엇인지 판별하려면 서비스 로그와 함께 주문, 쿠폰, 가격 데이터 등 다양한 비즈니스 도메인 데이터를 연계해 분석해야 하기 때문입니다.

CJ올리브영은 이러한 운영 분석 업무를 자동화하기 위해 두 가지 AI 에이전트를 구축했습니다. 인시던트 분석 에이전트는 장애 발생 시 원인과 고객 영향도를 분석하여 맞춤형 보상안 후보까지 정리해 줍니다. 데일리 헬스 체크 에이전트는 매일 축적되는 운영 데이터를 정기적으로 모니터링하여 이상 징후를 선제적으로 감지하고 점검 리포트를 전달합니다.

구현에는 Amazon Bedrock의 Claude와 Strands Agents SDK를 사용하고, 에이전트는 Amazon Bedrock AgentCore Runtime에서 실행합니다. 개발 과정에서는 AI-DLC(AI-Driven Development Lifecycle)를 활용해 업무 요구를 구현 단위와 검증 항목으로 정리했습니다.

이 글에서는 두 에이전트를 구축하며 계산·판정(코드)과 해석(AI 추론) 단계를 분리한 아키텍처와 그 이유, 실제 운영 점검에서 겪은 오탐을 해결한 과정, 그리고 이러한 변화가 운영 방식을 어떻게 바꿨는지 공유합니다.

CJ올리브영 소개와 글로벌 사업 확대

2026년 5월, CJ올리브영은 미국 전용 온라인몰과 패서디나에 첫 매장을 열었습니다. 개점 후 3일 동안 관련 SNS 콘텐츠가 1,000건 이상 생성되고 800만 회 이상 조회됐습니다(CJ Newsroom 공식 발표). 온라인과 오프라인에서 고객 접점이 확대되면서 글로벌 프로모션 시스템의 안정적인 운영도 중요해졌습니다.

미국 진출로 운영 시간대도 넓어졌습니다. 현지 프로모션 시간과 한국 담당자의 근무 시간이 겹치지 않는 구간에서는 오류를 바로 확인하기 어려웠습니다. 기존에는 장애가 발견되면 운영 담당자가 상황을 확인하고, 개발 담당자를 찾아 분석을 요청한 뒤, 그 결과로 보상안을 산정하고 실행했습니다. 원인과 고객 영향 분석이 개발 담당자에게 달려 있어, 시차 구간에 장애가 나면 한국의 개발자를 깨워 확인을 요청할 수밖에 없었습니다.

그래서 담당자가 여러 도구를 열어 데이터를 모으는 작업을 줄이고, 점검 결과를 지속적으로 확인할 방법이 필요했습니다. 무엇보다 개발자의 분석을 기다리지 않고도 운영 담당자가 근거를 확인해 바로 보상안을 결정할 수 있어야 했습니다.

로그에서 고객 영향까지 연결하기

기존 인시던트 분석은 담당자가 Datadog에서 로그와 애플리케이션 성능 모니터링(APM) 정보를 확인한 뒤, 관련 업무 데이터를 조회하고 분석 근거를 문서나 스프레드시트에 정리하는 방식이었습니다.

MCP(Model Context Protocol)로 Datadog에 연결한 AWS DevOps 에이전트는 로그와 모니터링 데이터를 활용해 장애 분석을 지원할 수 있습니다. 다만 프로모션 업무에서는 고객이 실제로 혜택을 받지 못했는지, 그 금액은 얼마인지까지 확인해야 합니다. 이를 위해 쿠폰, 주문, 가격 데이터를 업무 규칙에 따라 대조해 고객 영향을 산정하고, 운영자의 보상안 검토를 지원할 수 있어야 했습니다.

예를 들어 쿠폰 사용 실패를 분석한다면 다음 질문에 답할 수 있어야 합니다.

• 실제로 오류가 발생한 시간은 언제인가?
• 해당 이슈는 네트워크나 서버 자원 같은 인프라 영역인가? 코드와 데이터 같은 로직 영역인가?
• 실제로 혜택을 받지 못한 고객은 누구이며, 고객별 영향 금액은 얼마인가?
• 운영자가 보상안을 검토하려면 어떤 근거가 필요한가?

CJ올리브영은 프로모션 담당자와 함께 할인율과 최대 할인 금액, 상품 가격 등 계산에 필요한 기준을 구체화하고 이를 에이전트의 고객 영향 분석에 반영했습니다.

에이전트의 작업 범위와 개발팀의 검증 기준 정하기

“장애를 분석해 달라”는 요청만으로는 구현 범위가 정해지지 않습니다. 어떤 데이터를 조회할지, 고객 영향을 어떤 기준으로 계산할지, 결과를 어디까지 자동으로 처리할지 먼저 구체화해야 했습니다.

이 프로젝트에서 직접 구현한 핵심은 Datadog의 관측 데이터와 프로모션 업무 규칙을 연결하는 부분입니다. 로그 조회에 고객 영향 계산을 더하고, 운영자가 보상안을 검토하는 데 필요한 근거까지 정리하도록 범위를 정했습니다.

개발팀은 이 범위를 구체화하고 에이전트를 개발하는 과정에 AI-DLC를 적용했습니다.

먼저 요구사항과 작업 범위를 정하는 Inception 단계에서 프로모션 담당자와 함께 조회할 데이터, 예외 조건, 검증 기준을 구체화했습니다. 이후 설계와 구현, 테스트를 수행하는 Construction 단계에서 데이터 조회와 분석 기능을 개발하고, 앞서 정한 기준에 따라 결과를 검증했습니다.

1. 인시던트 분석 에이전트: 인시던트가 발생한 시간대의 Datadog 로그와 APM, 프로모션 데이터를 연결해 원인과 고객 영향을 분석하고, 운영자가 검토할 보상안 후보를 정리하는 에이전트
2. 데일리 헬스 체크 에이전트: 정해진 시간에 다섯 개 수집기로 운영 데이터를 수집해 여덟 개 점검 영역으로 정리하고, 반복 점검 결과를 저장해 운영자에게 제공하며, 실제 장애로 커지기 전 이상 징후를 확인할 수 있는 에이전트

두 에이전트의 목적과 실행 방식, 조회 데이터, 주요 결과는 다음과 같습니다.

초기에 범위를 정리해도 모든 예외를 미리 알 수는 없었습니다. 개발팀은 구현 결과를 검증하면서 계산 방식과 점검 기준을 조정했습니다.

시스템 아키텍처

Admin Backend와 에이전트 실행 환경 분리

시스템은 운영 화면, Admin Backend, 에이전트 실행 환경으로 나뉩니다. Amazon S3에서 제공하는 정적 운영 화면을 브라우저에서 실행하고, 화면에서 입력한 분석 요청은 Application Load Balancer(ALB)를 거쳐 Admin Backend로 전달됩니다.

Admin Backend는 Amazon ECS의 AWS Fargate 태스크에서 실행합니다. 분석 요청을 에이전트에 전달하고, 반환된 결과를 운영 화면으로 연결합니다.

에이전트는 MCP를 통해 Datadog의 로그, APM, Trace를 조회합니다. 주문, 쿠폰, 가격 등 프로모션 업무 데이터는 기존 프로모션 시스템과 공유하는 Amazon OpenSearch Service에서 읽기 전용으로 조회합니다. Datadog 연결에 필요한 API 키는 AWS Secrets Manager에서 관리합니다.

개발팀은 Strands Agents SDK로 모델 호출과 도구 실행을 연결하는 에이전트를 구현했습니다. 이 에이전트는 Amazon Bedrock AgentCore Runtime에서 실행되며, SDK의 Amazon Bedrock 연동 기능을 통해 LLM을 호출합니다.

코드와 LLM의 역할 분리

“정해진 계산과 판정은 코드가 수행하고, LLM은 근거를 해석해 운영자의 검토를 도와줍니다.”

초기 구현에서는 응답이 느리고, 같은 조건으로 다시 분석해도 설명이나 결론이 달라지는 경우가 있었습니다. 특히 고객 영향 금액의 계산과 운영 지표의 상태 판정에는 일관된 기준이 필요했습니다.

개발팀은 에이전트가 도구를 호출해 필요한 데이터를 조회하고, 정해진 계산과 상태 판정은 코드로 처리하도록 구성했습니다. 고객 영향 금액에는 쿠폰 할인율과 최대 할인 금액 등 업무 규칙을 적용하고, 운영 지표의 상태는 임계치와 기준선에 따라 판정합니다.

LLM은 조회한 데이터와 코드의 처리 결과를 바탕으로 장애 원인을 분석하고, 운영자가 결과를 검토할 수 있도록 근거와 후속 점검 사항을 정리합니다. 운영자는 제시된 근거와 보상안 후보를 검토하며, 보상안의 최종 승인과 실행을 담당합니다. 시차 구간에서 대응이 늦어진 원인은 운영 담당자의 보상 결정 자체가 아니었습니다. 그 결정에 앞서 개발 담당자가 맡던 원인 분석과 영향 계산이 병목이었습니다. 에이전트가 이 분석을 대신하면서, 운영 담당자는 개발자를 기다리지 않고 바로 판단할 수 있게 됐습니다.

1. 인시던트 분석과 보상안 제안

인시던트 분석 에이전트는 장애 원인 분석에서 고객별 피해 금액 계산, 보상안 제안까지 이어지는 업무를 지원합니다. 운영자가 장애 시간대와 상황을 입력하면 Datadog 로그와 APM을 조회하고, 관련 프로모션 데이터를 연결합니다. 로그에서 확인한 오류가 실제 고객 혜택에 어떤 영향을 주었는지 분석하는 것이 이 기능의 핵심입니다.

장애 유형별 분석과 고객 영향 산정

수집한 로그와 APM을 바탕으로 문제를 인프라, 로직과 데이터, 복합 유형으로 1차 분류합니다. 이후 유형별로 확인할 데이터를 구분해 원인을 분석합니다.

• 인프라 문제는 네트워크와 서버 리소스를 중심으로 원인을 확인합니다.
• 로직과 데이터 문제는 쿠폰과 가격 데이터를 조회해 업무 규칙과 관련된 원인을 살펴봅니다.
• 복합 문제는 영향을 받은 서비스와 원인을 연결해 분석합니다.

어느 경로로 분석하더라도 로그의 오류 건수를 그대로 영향 고객 수로 사용하지 않습니다. 고객에게 실제로 어떤 영향이 있었는지 확인하려면 프로모션, 쿠폰, 주문 데이터를 함께 대조해야 합니다.

고객 보상안 검토

영향 고객 수와 피해 금액은 코드로 계산합니다. 쿠폰 할인율, 최대 할인 금액, 상품 가격 등 업무 규칙을 적용하고, 에이전트는 계산 결과를 로그와 APM의 분석 근거와 연결해 설명합니다. 앞서 설명한 역할 분리에 따라, LLM이 피해 금액을 추정하거나 계산값을 임의로 변경하지 못하도록 역할을 제한했습니다.

에이전트가 보상안 후보를 제시하면, 운영자가 고객 영향과 분석 근거를 확인하고 업무 정책에 맞게 최종 승인하고 실행합니다.

분석 과정에서 중요한 이상 패턴이 발견되면 Datadog Monitor와 Composite Monitor 설정 가이드도 제안합니다. 제안에는 쿼리와 JSON이 포함되며, 운영자가 검토한 뒤 실제 환경에 반영합니다. 장애 분석에서 발견한 패턴을 이후 모니터링 기준으로 활용하기 위한 기능입니다.

운영 화면에서는 장애 분석 보고서의 요약과 심각도, 영향 고객 수, 총 피해 금액, 장애 기간을 확인할 수 있습니다. 상세 결과에는 원인 분류의 근거와 로그 해석이 제공됩니다.

2. 데일리 헬스 체크

데일리 헬스 체크는 운영 데이터를 정기적으로 점검해 장애로 확대되기 전의 이상 징후를 확인하는 기능입니다. 자동 실행과 수동 재실행을 지원하며, 데이터 수집, 코드 기반 상태 판정, LLM 분석, 리포트 저장과 알림 순서로 동작합니다.

운영 데이터 병렬 수집과 예외 처리

수집 대상은 리소스 메트릭, API 응답 시간, 오류와 경고 로그, APM과 Trace의 호출 정보, 비즈니스 지표입니다. 데이터 조회는 다섯 개 수집기(collector)가 담당합니다. 수집 작업을 병렬로 실행하고, 가져온 데이터를 점검 목적에 맞게 나눠 최종 리포트의 여덟 개 영역에 정리합니다.

각 수집기는 전용 MCP 클라이언트를 사용합니다. ThreadPoolExecutor로 수집 작업을 병렬 실행하고, as_completed로 완료된 작업의 결과를 취합합니다. 순차 조회의 대기 시간을 줄이면서도 MCP 동시 호출 한도를 고려해 일부 수집 작업은 별도 단계에서 실행하도록 구성했습니다.

조회 중 발생한 예외는 수집 작업별로 처리합니다. 특정 작업에서 예외가 발생하면 해당 결과에 오류를 기록하고, 다른 작업에서 정상적으로 수집한 결과는 유지합니다. 운영자는 데이터 조회에 실패한 영역과 실제 이상 징후가 발견된 영역을 구분해 확인할 수 있습니다.

코드 기반 상태 판정과 LLM 분석

수집 이후에는 코드가 전일 데이터와 7일 기준선을 비교하고, 임계치 초과 여부와 증감 폭, 새로운 이상 징후를 확인해 점검 영역별 상태를 정상/주의/긴급으로 분류합니다. CPU와 메모리 사용량, P99 응답 시간, 오류 건수처럼 기준이 정해진 지표는 코드가 판정합니다.

LLM은 코드의 판정 결과와 관련 데이터를 바탕으로 두 단계의 분석을 수행합니다. 첫 번째 단계에서는 여러 지표의 변화가 함께 나타나는 양상과 시간대별 특이 패턴을 분석합니다. 두 번째 단계에서는 코드 판정과 추가 분석을 종합해 운영자에게 전달할 의견을 작성합니다.

여기서도 역할 분리 원칙을 그대로 적용해, 수치 판정은 코드에 맡기고 LLM은 해석에 집중하도록 역할을 제한했습니다. 입력에 없는 수치나 사실을 만들지 않고, 이미 판정된 내용을 중복해서 나열하지 않도록 프롬프트에 제한을 명시했습니다.

판정 기준에는 지표별 임계치와 함께 소량 트래픽에서의 오탐을 막기 위한 최소 트래픽 기준이 포함됩니다. 아래는 health_collector.py에 정의한 판정 기준의 일부입니다.

# 3-1 리소스 — 7일 평균 대비 배수
"resource_ratio": {"warn": 2.0, "crit": 5.0},
# 3-2 레이턴시 — 절대 등급
"p99_grade": {"warn_ms": 200.0, "crit_ms": 1000.0},
# 3-3 로그 — 7일 평균 대비 배수
"error_ratio": {"warn": 3.0, "crit": 10.0},
# 3-4 트래픽/IP — 7일 평균 대비 배수
"traffic_ratio": {"warn": 3.0, "crit": 10.0},
"traffic_min_count": 50,  # 소량 호출 오탐 방지
"ip_ratio": {"warn": 3.0, "crit": 10.0},
"ip_min_count": 100,  # 소량 트래픽 오탐 방지
# ... (중략)

# 절대 임계 적용 대상 리소스 메트릭
_ABS_METRICS = {
    "rds_cpu": "cpu_util",
    "ecs_cpu": "cpu_util",
    # ... (나머지 항목 생략)
}

_SEV_ORDER = {"OK": 0, "WARN": 1, "CRIT": 2}

def _ratio_sev(ratio: float, kind: str) -> str | None:
    t = HEALTH_THRESHOLDS[kind]
    if ratio >= t["crit"]:
        return "CRIT"
    if ratio >= t["warn"]:
        return "WARN"
    return None

# 3-1 리소스
def check_resources(today: dict, baseline: dict) -> list[dict]:
    """절대 임계 + 7일 평균 대비 배수."""
    # ... (이하 생략)

소량 트래픽과 미완료 집계로 인한 오탐 개선

초기에는 전일 데이터만으로 상태를 판정해, 트래픽이 적은 구간이나 집계가 끝나지 않은 날짜의 부분 데이터에서 오탐이 발생했습니다. 판정 로직을 코드로 고정해도, 비교 대상 데이터의 양과 집계 범위가 적절하지 않으면 정상적인 운영 상태를 이상으로 판단할 수 있었습니다.

이에 7일 기준선과 최소 트래픽 기준을 추가하고, 집계가 완료되지 않은 날짜는 분석 대상에서 제외했습니다.

리포트 저장과 운영 화면 및 Slack 알림

점검 결과는 헬스 리포트로 생성해 저장합니다. 운영 화면에는 종합 의견과 긴급, 주의, 정상 건수를 먼저 표시하고, 영역별 상세 지표를 확인할 수 있도록 구성했습니다. 운영자는 문제가 있는 영역을 확인한 뒤 필요하면 Datadog 원본으로 이동해 분석 근거를 살펴볼 수 있습니다.

자동 실행 결과는 Slack으로도 전송합니다. 담당자는 알림에서 점검 결과와 종합 의견을 확인하고, 저장된 리포트를 통해 상세 지표와 이전 점검 결과를 살펴볼 수 있습니다.

검증 결과와 운영 방식의 변화

6분 동안 약 32만 건의 오류가 발생한 장애 사례에 인시던트 분석 에이전트를 적용했습니다. 에이전트는 장애 원인과 고객에게 미친 영향을 분석하고 피해 규모를 산정했습니다. 원인 파악부터 피해 규모 산정까지 1분 이내에 완료해, 운영자가 보상안을 검토하는 데 필요한 근거를 제공했습니다.

운영자가 결과에 도달하는 과정도 달라졌습니다. 인시던트 분석에서는 로그와 업무 데이터를 각각 조회해 다시 정리하던 작업을 하나의 흐름으로 연결했습니다. 데일리 점검에서는 여러 화면에 접속해 상태를 확인하던 작업을 정기 수집과 결과 저장, 알림으로 이어지게 했습니다.

운영자는 에이전트가 정리한 수치와 근거를 바탕으로 확인을 시작할 수 있게 됐습니다. 고객에게 어떤 영향이 있었는지, 제안된 보상이 적절한지와 같은 업무 판단에 집중할 수 있도록 반복적인 조회와 정리 작업을 줄인 것입니다.

운영 에이전트를 도입하며 배운 점

이 글에서는 CJ올리브영이 글로벌 프로모션 운영을 위해 인시던트 분석 에이전트와 데일리 헬스 체크 에이전트를 구축한 과정을 소개했습니다. 계산과 판정은 코드로 고정하고 해석은 LLM에 맡기도록 역할을 분리했고, 실제 운영 데이터로 검증하며 소량 트래픽과 미완료 집계로 인한 오탐을 줄였습니다. 그 결과 인시던트 분석에 1~2일이 걸리던 작업을 수분으로 단축하고, 운영 담당자가 개발자의 분석을 기다리지 않고 보상 판단에 집중할 수 있게 됐습니다. 이 과정에서 배운 점을 정리합니다.

운영 업무를 에이전트에 맡기려면 먼저 그 업무의 판단 기준을 설명할 수 있어야 했습니다. 쿠폰 오류를 찾은 뒤 고객 영향을 계산하려면 어떤 주문과 쿠폰 내역을 연결하고 어떤 할인 규칙을 적용할지 정해야 했습니다. 운영 담당자가 경험으로 판단하던 조회 기간과 예외 조건을 명시하고, 결과를 확인할 근거까지 정의하는 일이 에이전트 구현의 출발점이었습니다.

이 기준을 정리하는 데 AI-DLC가 도움이 됐습니다. Inception 단계에서 프로모션 운영 담당자와 함께 분석 시나리오, 판단 조건, 검증 기준을 정리했고, Construction 단계에서는 이 기준을 그대로 설계와 테스트의 기준으로 삼았습니다. 운영 담당자와 개발팀이 처음부터 같은 기준을 공유하니, 기능을 정의하는 일과 결과를 확인하는 일이 하나의 흐름으로 이어졌습니다.

정리한 기준은 실제 데이터로 다시 검증해야 합니다. 계산과 상태 판정을 코드로 분리한 뒤에도, 트래픽이 적은 구간이나 집계가 끝나지 않은 날짜의 데이터에서는 오탐이 발생했습니다. 같은 계산을 일관되게 수행하는 것과 운영 상황을 올바르게 판단하는 것은 별도로 검증해야 하며, 검증용 로그와 예외 사례를 구현 초기부터 준비해 두는 것이 중요한 이유도 여기에 있습니다.

마지막으로, 에이전트를 도입하면 사람의 역할도 다시 설계해야 합니다. 여러 화면에서 데이터를 찾아 모으는 반복 작업은 에이전트가 맡고, 운영 담당자는 제시된 근거를 확인해 고객 영향과 보상의 적절성을 판단하는 데 집중하게 됐습니다. 개발팀도 이후 새로운 기능을 설계할 때는 반복 업무를 찾는 것과 함께, 결과를 어떻게 검증하고 어떤 결정을 사람이 내릴지를 먼저 정리하고 있습니다. 비슷한 업무에 에이전트를 적용한다면, 분석 시나리오 하나를 골라 이 기준부터 운영 담당자와 함께 정리해 보시기 바랍니다.

참고 자료

• AI-DLC 소개
• CJ올리브영의 AI 협업 개발 프로세스 구축, AI-DLC 실전 도입 사례
• Strands Agents SDK Python 빠른 시작
• Amazon Bedrock AgentCore Runtime 개발자 가이드
• Amazon Bedrock Runtime API 참조