1~2년 이상 운영된 거의 모든 데이터 자동화 코드베이스에는 특정한 패턴이 나타납니다. 바로 구현 세부 사항(implementation details)과 밀접하게 결합된 알림(alerts)입니다. 이 알림들은 누군가 하위 코드를 리팩터링하는 순간, 조용히 작동을 멈추거나 잘못된 시점에 발생하기 시작합니다. 사고를 포착했어야 할 알림이 침묵을 지키기 전까지는 아무도 이를 알아차리지 못합니다.

이는 드문 예외적인 사례가 아닙니다. 시간이 흐르며 변화하는 모든 시스템, 즉 유지 관리할 가치가 있는 모든 시스템에서 거의 불가피하게 발생하는 현상입니다. 문제는 이 현상이 당신의 알림에 결국 발생할 것인가가 아니라, 통제된 감사(audit)를 통해 발견할 것인가, 아니면 놓쳐버린 사고를 통해 발견할 것인가 하는 점입니다.

원인 기반 알림(Cause-Based Alert)의 실제 모습

원인 기반 알림(cause-based alert)은 특정 실패 모드(failure mode)에 따라 트리거됩니다: "이 API 호출이 500 에러를 반환했다", "이 특정 재시도 카운터(retry counter)가 최대치에 도달했다", "이 특정 예외(exception) 유형이 발생했다"와 같은 방식입니다. 이러한 알림은 작성 당시에는 매우 정밀하고 유용하게 느껴집니다. 왜냐하면 알림을 발생시킨 근본적인 버그나 사고에 직접적으로 연결되어 있기 때문입니다.

문제는 나중에 나타납니다. 누군가 재시도(retries) 구현 방식을 변경하거나, HTTP 클라이언트 라이브러리를 교체하거나, 다른 예외 계층 구조(exception hierarchy)를 사용하도록 에러 핸들링(error handling)을 재구성하는 순간, 알림의 근본적인 트리거 조건은 더 이상 현실과 일치하지 않게 됩니다. 이런 일이 발생해도 알림 자체는 에러를 발생시키지 않습니다. 그저 조용히 작동을 멈추거나 잘못된 조건에서 작동하기 시작하며, 다음 사고가 감지되지 않은 채 지나갈 때까지 아무도 이를 알지 못합니다.

이것을 놓치기 쉬운 이유

코드 리팩터링 (Refactoring)과 알림 로직 리팩터링 (Refactoring)은 동일한 사람이, 동일한 시점에, 동일한 맥락에서 수행되는 경우가 거의 없습니다. 재시도 로직 (Retry logic)을 개선하는 엔지니어는 재시도 동작 자체에 합리적으로 집중할 뿐, 기존 구현을 참조하고 있는 모든 알림 규칙 (Alert rule)을 일일이 감사 (Auditing)하는 데 집중하지 않습니다. 알림 설정 (Alert configuration)은 종종 코드 리뷰 프로세스와 단절된 채, 모니터링 플랫폼의 UI나 다른 리포지토리 (Repo)에 있는 YAML 파일과 같은 완전히 별개의 시스템에 존재하며, 이로 인해 이러한 괴리 (Drift)를 포착하기 어렵습니다.

증상 기반의 대안 (The Symptom-Based Alternative)

증상 기반 알림 (Symptom-based alert)은 구현 세부 사항 (Implementation detail) 대신 관찰 가능한 결과 (Observable outcome)를 감시합니다: "이 테이블이 예상된 시간 내에 업데이트되지 않았음", "이 파이프라인이 X시간 동안 성공적으로 완료되지 않았음", "이 데이터 품질 체크 (Data quality check)가 Y회 연속으로 실패했음" 등이 그 예입니다. 이러한 조건들은 비즈니스나 다운스트림 소비자 (Downstream consumers)에게 실제로 중요한 것이 무엇인지를 설명하며, 기반 코드가 재시도 (Retries), 에러 처리 (Error handling), 또는 작업 오케스트레이션 (Job orchestration)을 어떻게 구현하느냐에 관계없이 유효하게 유지됩니다.

재시도 로직을 완전히 다시 작성하거나, 다른 오케스트레이션 도구로 마이그레이션하거나, 기반 데이터베이스를 교체하더라도 증상 기반 알림은 계속 작동합니다. 애초에 구현 방식과 결합 (Coupled)되어 있지 않았기 때문입니다.

구체적인 전과 후 (A Concrete Before and After)

전 (Before): "벤더 API 호출이 연속으로 3회 이상 200이 아닌 상태 코드 (Non-200 status code)를 반환하면 알림을 보냄." 이 방식은 누군가가 원시 상태 코드를 동일한 방식으로 노출하지 않고 해당 실패를 우아하게 처리하는 서킷 브레이커 (Circuit breaker)를 추가하거나, 에러 의미론 (Error semantics)이 다른 HTTP 라이브러리로 교체하는 순간 깨집니다.

후 (After): "벤더 데이터 테이블이 예상된 일일 시간 범위 내에 새로운 배치 (Batch)를 수신하지 못하면 알림을 보냄." 이 방식은 인제스션 작업 (Ingestion job)이 내부적으로 API를 호출하는 방식이 어떻게 변경되더라도 생존합니다. 메커니즘 (Mechanism)이 아닌, 중요한 결과 (Outcome)를 감시하고 있기 때문입니다.

코드 리뷰에서 이러한 파손을 포착하기 어려운 이유 (Why the Breakage Is So Hard to Catch in Code Review)

알림 설정(Alert configuration)은 대개 코드베이스 외부, 즉 모니터링 플랫폼의 UI나 파이프라인 자체의 일반적인 풀 리퀘스트(Pull Request) 흐름에 포함되지 않는 별도의 YAML 설정 저장소(config repo)에 존재합니다. 이러한 분리는 재시도 로직(retry logic) 리팩터링을 검토하는 리뷰어가 변경되는 코드를 참조하는 알림 규칙이 있는지 확인하도록 유도하는 자연스러운 계기가 없음을 의미합니다. 두 시스템은 독립적으로 드리프트(drift)하며, 장애(incident)가 발생하여 그 간극이 드러나기 전까지는 두 시스템을 다시 동기화하도록 강제하는 장치가 아무것도 없습니다.

일부 팀은 이를 해결하기 위해 알림 정의를 모니터링 대상인 파이프라인 코드와 함께 코드형 인프라(Infrastructure-as-Code, IaC)로 배치합니다. 이렇게 하면 에러 핸들링(error handling)을 변경하는 풀 리퀘스트가 발생했을 때, 리뷰어가 동일한 로직을 참조하는 인근의 알림 규칙을 인지할 가능성이 최소한이라도 생깁니다. 이것이 완전한 해결책은 아니지만, 두 시스템 사이의 거리를 좁혀줍니다.

이것은 보편적인 규칙이 아닙니다

원인 기반 알림(Cause-based alerts) 자체가 본질적으로 잘못된 것은 아닙니다. 원인 기반 알림은 특정하고 잘 이해된 실패 모드(failure modes)가 감지하는 데 더 오래 걸리는 증상(symptom)으로 전이되기 전에 조기에 포착하는 데 진정으로 유용합니다. 실수는 특정 파이프라인에 대한 유일한 안전망으로 원인 기반 알림에만 의존하는 것입니다. 소수의 타겟팅된 원인 기반 알림을 더 넓은 범위의 증상 기반 알림(symptom-based alert)과 결합하여 백스톱(backstop)으로 활용하면, 특정되고 알려진 실패 모드와 아무도 예상하지 못한 실패 모드를 모두 포착할 수 있습니다.

이러한 패턴에 대해 기존 알림을 감사(Audit)하는 방법

현재의 알림 규칙을 검토하며 각 규칙에 대해 다음과 같이 질문해 보십시오. "이 규칙이 특정 구현 세부 사항(implementation detail), 함수 이름, 예외 유형(exception type), 재시도 횟수(retry count)를 참조하고 있는가, 아니면 관찰 가능한 결과(observable outcome)를 참조하고 있는가?" 첫 번째 범주에 속하는 모든 항목은 리팩터링 취약성 감사(refactor-fragility audit) 대상입니다. 즉, 이 알림이 작성된 이후에 기반 코드가 변경되었는지, 변경되었다면 그 알림이 여전히 올바르게 작동하는지 아는 사람이 있는지 확인해야 합니다.

이러한 감사는 처음 수행할 때는 지루하지만, 특히 몇 달 동안 한 번도 발생하지 않은 알림들에 대해서는 진정으로 수행할 가치가 있습니다. 조용히 고장 난 알림은 알림이 아예 없는 것보다 더 나쁩니다. 팀이 실제로는 보호받지 못하고 있음에도 불구하고 보호받고 있다고 믿게 만들기 때문입니다. 이는 알람 피로 (alarm fatigue) 문제의 한 변형으로, 실패 모드가 소음(noise)이 아닌 잘못된 확신(false confidence)으로 나타나는 경우입니다.

이것이 광범위한 알림 전략에서 차지하는 위치

원인 대 증상 (Cause-versus-symptom) 설계는 심각도 계층 (severity tiers), 중복 제거 (deduplication), 그리고 시간이 지나도 신뢰성을 유지하기 위한 정기적인 오탐 (false-positive) 검토가 필요한 더 큰 알림 전략의 한 부분입니다. 만약 개별 규칙을 패치하는 것이 아니라 알림 시스템을 처음부터 다시 구축하고 있다면, 신뢰를 저하시키지 않는 파이프라인 알림 설계에 대한 더 자세한 분석에서 해당 전략의 나머지 부분을 다루고 있습니다.

증상 기반 알림을 더 쉽게 만드는 도구들

계측 (instrumentation)을 위한 OpenTelemetry와 같은 표준화된 관측성 (observability) 도구, 그리고 일관된 메트릭 (metrics)을 기반으로 대시보드와 알림 규칙을 구축하는 Grafana와 같은 플랫폼은 증상 기반 알림을 정의하는 것을 실질적으로 더 쉽게 만들어 줍니다. 이러한 알림들은 가공되지 않은 애플리케이션 로그 (raw application logs)가 아닌 표준화된 비즈니스 수준의 메트릭을 기반으로 구축되기 때문에, 애초에 구현 세부 사항을 알 필요가 없습니다.

이것이 표면화되는 데 보통 걸리는 시간

우리의 경험에 따르면, 원인 기반 알림(cause-based alert)이 깨지면 리팩터링이 발생한 후 몇 주에서 몇 달 동안 아무도 이를 알아차리지 못하는 경우가 일반적입니다. 왜냐하면 이 실패 모드의 핵심은 아무런 에러도 발생하지 않으며, 단지 알림이 현실과 조용히 일치하지 않게 될 뿐이기 때문입니다. 이 격차는 보통 두 가지 방식 중 하나로 해소됩니다. 증상 기반의 백스톱 알림(symptom-based backstop alert)이 근본적인 문제를 포착하여 누군가가 역추적을 통해 특정 알림이 침묵하고 있었다는 사실을 발견하거나, 혹은 알림이 전혀 울리지 않는 상태에서 실제 장애(incident)가 발생하고 사후 검토(post-incident review)를 통해 비로소 드리프트(drift)가 드러나는 방식입니다. 첫 번째 경로가 분명히 더 바람직하며, 이것이 바로 원인 기반 알림을 단독으로 의존하기보다 증상 기반의 백스톱과 함께 쌍으로 구성해야 한다는 논거입니다.

새로운 팀원이 상황을 개선하기는커녕 악화시키는 이유

코드베이스를 바라보는 새로운 시각이 온보딩(onboarding) 과정에서 오래된 원인 기반 알림을 잡아낼 것이라고 생각하기 쉽지만, 실제로는 그 반대인 경우가 많습니다. 새로운 팀원들은 일반적으로 기존의 알림 설정이 현재의 현실을 반영하고 있다고 신뢰합니다. 그렇지하다고 의심할 명백한 이유가 없기 때문이며, 모든 알림 규칙을 현재 코드베이스와 대조하며 감사(auditing)하는 것은 일반적인 온보딩 작업이 아닙니다. 조용히 깨졌을 가능성이 가장 높은 알림은 바로 신입 사원이 의문을 제기하기 가장 어려운 바로 그 알림들입니다.

실질적인 시사점

만약 알림 규칙이 엔지니어가 현재의 구현 사항, 특정 함수, 예외 유형(exception type) 또는 재시도 메커니즘(retry mechanism)을 직접 읽어봐야만 알 수 있는 요소를 참조하고 있다면, 그것은 설계상 취약하며 결국 아무도 모르게 침묵하게 될 것입니다. 관찰 가능하고 비즈니스와 관련된 결과(outcomes)를 중심으로 구축하는 것은 초기에 약간의 고민이 더 필요하지만, 나중에 조용히, 그리고 감지되지 않은 채 발생하는 알림의 퇴보(alerting decay)를 크게 줄여줍니다. 137Foundry는 데이터 팀을 위한 알림 시스템을 재구축하면서 정확히 이러한 패턴을 여러 번 경험했으며, 일단 문제가 식별되고 나면 거의 항상 쉽게 해결할 수 있는 문제였습니다.