딜리버리 프로덕트 개발팀의 개발문화 - 로그 & 알람편

컬리 딜리버리 프로덕트 개발팀이 무분별한 에러 로그와 가짜 알람으로 무뎌지는 문제를 없애기 위해, 로그 레벨 기준과 알람 임계치를 다시 정한 운영 실천기를 다룬다. 진짜 문제일 때만 에러로 남기고 알람이 울리도록 규칙을 세워, 사용자보다 먼저 문제를 인지하는 체계를 만들었다.

핵심 포인트

로그 레벨 규칙이 없어 가짜 에러가 넘쳤고, 잦은 알람이 경계심을 무디게 하는 게 근본 문제였다.
ERROR는 즉각 대응할 것, WARN은 당장은 괜찮지만 빈도가 많으면 문제인 것으로 기준을 재정의했다.
ERROR는 발생 즉시 알람, WARN은 기간 내 임계치를 넘으면 알람 오도록 분리했다.
패턴을 모르는 경고는 공통 범위 알람(5분 내 100회)에 먼저 넣고, 특성이 다른 것만 별도 알람으로 뗀다.
재정비 결과 최근 3일간 에러 4건·경고 355건으로, 사용자보다 먼저 문제를 인지하게 됐다.

상세 정리

문제 인식: 로깅 시스템에서 에러 로그만 봤더니 대응할 게 없는 가짜 에러가 대부분이었고, 이런 알람이 반응하면 점점 무뎌졌다.
기준 정의: 회의를 거쳐 ERROR=즉각 대응, WARN=빈도 많으면 문제로 레벨 기준을 명문화했다.
알람 분리: 즉시 대응 대상은 에러 로그와 즉각 알람으로, 빈도형은 경고 로그와 임계치 초과 시 알람으로 구성했다.
모니터링 주기: 같은 외부 호출도 시스템 상태·빈도에 따라 1분 또는 10분 간격으로 확인하며 운영하면서 조정한다.
공통 범위 알람: 패턴을 모르는 경고는 5분 내 100회 기준의 공통 알람에 등록한 뒤 필요 시 별도 알람으로 분리한다.
사례 처리: 의도된 예외는 경고로 낮춰 공통 알람, 실제 에러는 핫픽스·티켓, 외부 타임아웃은 재처리되니 임계치 알람, 서킷브레이커 열림 시 알람을 건다.
제어 불가 로그: MSK 등 앱에서 제어 못 하는 인프라 로그는 정기 업데이트 때 대량 경고가 떠, 패턴을 보고 알람 대상에서 제외한다.
지속 관리: 로그도 코드처럼 계속 관리해야 하며, 자주 울리면 느슨하게·안 울리면 타이트하게 임계치를 조정한다.