우아한 성능 저하(Graceful degradation)는 건전한 엔지니어링 패턴이다. 의존성이 다운되면 안전한 기본값으로 폴백하고, 이벤트를 로깅하고, 파이프라인을 계속 진행시킨다. 인프라에서는 올바른 선택이다.
그런데 전혀 우아하지 않은 형태의 graceful degradation이 존재한다. 잘못된 데이터, 오래된 캐시, 또는 현실을 반영하도록 설계된 적 없는 기본값으로 조용히 동작하면서 정상적으로 보이는 출력을 계속 생산하는 시스템이다. 파이프라인은 녹색을 유지한다. 운영자는 아무것도 보지 못한다. 출력은 틀렸다.
그것은 폴백이 아니다. 거짓말이다.
중요한 구분
진정한 graceful degradation은 세 가지 속성을 갖는다:
- 실패가 진단 가능한 충분한 컨텍스트와 함께 로깅된다.
- 폴백 동작이 명시적이다 — 우연히 선택된 기본값이 아니라 의도적으로 선택된 기본값이다.
- 사람이 개입 여부를 결정할 수 있도록 알림이 발생한다.
무음 실패는 이 중 어느 것도 없다. 시스템은 계속 동작한다. 출력은 그럴듯해 보인다. 알림은 발생하지 않는다. 운영자는 20분 전에 의사결정에 사용된 데이터가 손상되었다는 사실을 전혀 모른다.
차이는 출력에 있지 않다. 출력을 둘러싼 관찰 가능성(observability)에 있다.
'우아함'이 '비가시성'이 되는 세 가지 프로덕션 패턴
1. 기본값을 반환하는 스코어링
리드 스코어링 모델이 enrichment API를 호출한다. API가 타임아웃된다. 모델은 사용할 점수가 없으므로 필드의 초기화된 값 — 예를 들어 100점 만점에 50점 — 을 반환한다. 이것은 스키마가 설정될 때의 기본값이다.
리드는 50점을 가지고 파이프라인을 통과한다. 중간 우선순위 큐로 라우팅된다. 담당자는 1일차가 아닌 3일차에 처리한다.
오류는 발생하지 않았다. 알림도 없었다. 50이라는 점수는 모델 출력이 아니었다 — 숫자처럼 보이는 null이었다.
하루에 200개의 리드를 처리하고 15%가 이 타임아웃 구간에 걸린다면, 하루 30개의 리드가 유령 점수로 라우팅되는 것이다.
2. 큐로 기본 라우팅
라우팅 에이전트가 인바운드 요청을 분류하고 적절한 워크플로에 할당한다. 분류 모델이 사용 불가 상태다 — 콜드 스타트, 레이트 리밋, 일시적 오류. 에이전트는 기본 큐로 폴백한다.
기본 큐가 잘못된 것은 아니다. 합리적인 catch-all이다. 그러나 분류 실패의 전체 볼륨이 아니라 미분류 엣지 케이스를 위해 설계된 것이다. 모델이 40분 동안 다운되면 모든 요청이 그 큐에 쌓인다. 큐가 밀린다. SLA가 어긋난다.
아무도 모델이 다운되었다는 사실을 모른다. 그들은 그저 느린 큐를 보고 볼륨 급증이라고 가정한다.
3. 오래된 캐시를 반환하는 enrichment
enrichment 단계가 firmographic 데이터 — 회사 규모, 업종, 최근 펀딩 — 를 가져온다. 업스트림 소스가 사용 불가 상태라 시스템은 마지막으로 캐시된 값을 반환한다. 캐시는 11일 된 것이다.
그 회사는 9일 전에 Series B를 완료했다. enrichment 레코드는 여전히 시드 단계로 표시된다. 아웃리치 문구, 가격 티어, 담당자 배정 — 모두 잘못된 회사 정보를 기준으로 조정된다.
캐시 히트는 라이브 데이터 히트와 동일하게 보인다. 레코드에 플래그가 없다. 운영자는 모든 enrichment 필드의 타임스탬프를 감사하지 않는 한 알 방법이 없다.
크게 실패하는 것이 운영상 더 안전한 이유
크게 실패하면 — 알림, 파이프라인 중단, 플래그된 레코드 — 결정을 강제한다. 사람이 확인한다. 의존성을 수정하거나, 폴백을 명시적으로 승인하거나, 데이터 품질이 복구될 때까지 레코드를 보류한다.
그 순간에는 더 많은 작업이 필요하다. 하지만 분기 단위로 보면 더 적은 작업이다. 스코어링 모델이 3주 동안 쓰레기를 생산해온 이유를 디버깅하지 않아도 되기 때문이다.
운영 원칙은 단순하다: 크게 실패하는 시스템은 자신이 할 수 없는 것을 알려준다. 조용히 실패하는 시스템은 괜찮다고 말한다.
크게 실패하면 피드백 루프도 생긴다. 같은 의존성이 일주일에 세 번 알림을 발생시키면, 더 나은 폴백이나 더 탄력적인 통합에 투자해야 한다는 것을 알 수 있다. 무음 실패는 그 신호를 완전히 숨긴다.
대신 무엇을 구축해야 하는가
파이프라인의 각 폴백 경로에 대해 배포 전에 세 가지를 정의하라:
- 트리거 조건. 어떤 특정 실패가 폴백을 활성화하는가?
- 폴백 동작. 시스템이 무엇을 하는가, 그리고 그 동작은 명시적으로 선택된 것인가 아니면 그냥 기본값인가?
- 알림. 누가, 어떤 채널을 통해, 어떤 컨텍스트와 함께 통보받는가?
세 가지 모두 답할 수 없다면, 폴백은 완성되지 않은 것이다. 적절한 조건을 기다리는 무음 실패다.
이것은 시스템을 취약하게 만드는 것이 아니다. 모든 일시적 오류에서 멈추는 파이프라인은 유용하지 않다. 목표는 정상 동작과 저하된 동작 사이의 경계를 가시적으로 만드는 것이다 — 운영자가 분기별 데이터 감사에서 문제를 발견하는 대신 정보에 기반한 결정을 내릴 수 있도록.
지루한 시스템은 조용히 동작한다. 그러나 그것이 조용한 이유는 누군가가 올바른 위치에 소음을 만들어 넣었기 때문이다.
AI 파이프라인을 구축하거나 감사하면서 프로덕션에 드러나기 전에 실패 모드를 파악하고 싶다면, 대화를 시작하세요 →