Queue 적체율 KPI를 만들며 배운 점

큐 적체율 KPI를 정의하며 깨달은 데이터의 본질

Queue 적체율 KPI를 만들며 배운 점

운영 초기에 저는 Queue를 매우 단순하게 생각했습니다.

Queue가 짧으면 정상.

Queue가 길면 문제.

이 정도의 기준만 가지고 시스템을 바라봤습니다.

하지만 실제 운영 환경에서는 생각보다 많은 장애가 이런 단순한 판단 때문에 발생했습니다.

어떤 날은 Queue가 수천 건까지 증가했는데도 서비스는 안정적으로 동작했습니다.

반대로 Queue 길이는 거의 변하지 않았지만 사용자 불만이 급증한 적도 있었습니다.

그 경험 이후 단순한 Queue 길이가 아니라 Queue의 상태를 설명할 수 있는 KPI가 필요하다고 느꼈습니다.

그렇게 만들어진 것이 Queue 적체율 KPI였습니다.

흥미로운 점은 KPI를 설계하는 과정에서 Queue보다 더 중요한 것이 Queue 자체가 아니라 시스템의 흐름이라는 사실을 깨달았다는 것입니다.

Queue 길이는 생각보다 좋은 지표가 아니다

처음에는 Queue 길이를 KPI로 사용하려고 했습니다.

가장 직관적이기 때문입니다.

예를 들어 Queue에 10,000건이 쌓여 있다면 위험해 보입니다.

반대로 Queue에 100건만 있다면 정상처럼 보입니다.

하지만 실제 운영 환경에서는 그렇지 않았습니다.

예를 들어 야간 배치 작업이 시작되는 시간에는 Queue가 50,000건까지 증가하기도 했습니다.

그러나 Consumer가 충분한 처리 능력을 가지고 있었기 때문에 몇 분 안에 모두 처리되었습니다.

반대로 Queue 길이는 500건 수준이었지만 Consumer 처리 속도가 급격히 감소하면서 장애로 이어진 적도 있었습니다.

결국 Queue 길이 자체는 상황을 설명하지 못했습니다.

중요한 것은 Queue에 얼마나 쌓여 있는가가 아니라 얼마나 빠르게 쌓이고 얼마나 빠르게 처리되는가였습니다.

KPI를 만들면서 가장 먼저 버린 지표

처음 KPI 설계안을 만들 때 포함했던 항목은 다음과 같았습니다.

• Queue Length
• Consumer Count
• Throughput
• Error Rate

얼핏 보면 충분해 보였습니다.

하지만 실제 운영 데이터와 비교해 보니 문제가 있었습니다.

장애가 발생하기 전부터 이상 징후가 나타나는데 KPI는 아무런 신호를 주지 못했던 것입니다.

원인을 분석해 보니 Queue Length는 너무 늦게 반응하는 후행 지표였습니다.

실제로 장애는 다음 순서로 진행되었습니다.

1. Consumer 처리 속도 감소
2. Message Latency 증가
3. Retry 증가
4. Queue 증가
5. 사용자 장애 발생

Queue Length는 이미 문제가 상당히 진행된 뒤에야 변하기 시작했습니다.

그 이후 KPI 설계 방향이 완전히 바뀌었습니다.

적체율 KPI를 정의하면서 깨달은 점

적체율 KPI를 만들면서 가장 어려웠던 부분은 “적체”를 어떻게 정의할 것인가였습니다.

단순히 Queue 길이를 사용할 수도 있었습니다.

하지만 그것만으로는 부족했습니다.

그래서 다음과 같은 개념을 사용했습니다.

적체율 = 현재 Queue 유입량 ÷ 현재 처리량 × 100

예를 들어

• 분당 유입량 1,000건
• 분당 처리량 1,000건

이라면 적체율은 100%입니다.

시스템은 균형 상태입니다.

반면

• 분당 유입량 1,500건
• 분당 처리량 1,000건

이라면 적체율은 150%입니다.

이 경우 Queue는 반드시 증가하게 됩니다.

이 수치가 중요한 이유는 Queue 길이가 아니라 미래를 보여주기 때문입니다.

Queue 길이는 현재 상태를 보여주지만 적체율은 앞으로 Queue가 어떻게 될지를 보여줍니다.

데이터의 본질은 현재가 아니라 방향성이다

적체율 KPI를 운영하면서 가장 크게 느낀 점은 데이터의 본질이 숫자 자체에 있지 않다는 것이었습니다.

운영자가 봐야 하는 것은 현재 값이 아니라 변화 방향입니다.

예를 들어 Queue가 5,000건이라고 가정해 보겠습니다.

이 숫자만으로는 아무 의미가 없습니다.

하지만 다음과 같은 정보가 추가되면 이야기가 달라집니다.

• 10분 전: 10,000건
• 현재: 5,000건

이 경우 Queue는 감소 중입니다.

반대로

• 10분 전: 500건
• 현재: 5,000건

이라면 매우 위험한 상황입니다.

숫자는 동일하지만 의미는 완전히 다릅니다.

그 이후 KPI 설계에서 가장 중요하게 생각한 것은 절대값보다 변화율이었습니다.

적체율 100%를 목표로 하면 안 되는 이유

초기에는 적체율 100%를 이상적인 상태로 생각했습니다.

자원을 낭비하지 않으면서 최대 효율을 내는 상태처럼 보였기 때문입니다.

하지만 실제 운영 환경에서는 오히려 위험했습니다.

시스템은 항상 변동성을 가지고 있습니다.

트래픽은 예측대로 들어오지 않습니다.

외부 API 응답 시간도 일정하지 않습니다.

데이터베이스 성능도 순간적으로 저하될 수 있습니다.

따라서 적체율이 항상 100%라면 작은 변화만 발생해도 Queue가 급격히 증가하기 시작합니다.

결국 운영 환경에서는 여유 용량이 필요합니다.

실제로 제가 운영했던 시스템에서는 적체율 70~80% 수준을 가장 안정적인 구간으로 판단했습니다.

적체율보다 더 중요했던 지표

흥미롭게도 KPI를 운영하면서 적체율보다 더 강력한 지표를 발견했습니다.

바로 Message Latency였습니다.

적체율은 미래 위험을 알려줬지만 Message Latency는 사용자가 실제로 경험하는 품질을 보여줬습니다.

실제로 사용자 문의가 증가하기 시작하는 시점은 Queue 증가보다 Latency 증가와 더 강한 상관관계를 보였습니다.

그래서 최종 대시보드에는 다음 항목을 함께 배치했습니다.

• Queue Saturation Rate
• Message Latency
• Throughput Gap
• Retry Rate
• Consumer Utilization
• DLQ Rate

이 조합이 단순 Queue Length보다 훨씬 높은 예측력을 보여주었습니다.

KPI 설계에서 가장 중요했던 교훈

Queue 적체율 KPI를 만들면서 얻은 가장 큰 교훈은 KPI는 숫자를 만드는 작업이 아니라 행동을 유도하는 작업이라는 점이었습니다.

좋은 KPI는 숫자가 예쁜 상태를 만드는 것이 아닙니다.

운영자가 무엇을 해야 하는지 알려줘야 합니다.

예를 들어 적체율이 120%가 되었다면 운영자는 즉시 질문할 수 있어야 합니다.

• 유입량이 증가했는가?
• 처리량이 감소했는가?
• Consumer가 병목인가?
• Database가 병목인가?
• 외부 API가 느려졌는가?

이 질문을 만들어내지 못하는 KPI는 아무리 정교해도 의미가 없습니다.

결론

처음에는 Queue 적체율 KPI를 만들면서 단순히 Queue 상태를 측정하려고 했습니다.

하지만 운영을 계속할수록 Queue보다 중요한 것은 시스템의 흐름이라는 사실을 배우게 되었습니다.

Queue 길이는 결과였습니다.

적체율은 미래를 보여주는 신호였습니다.

그리고 Message Latency는 사용자가 실제로 경험하는 품질이었습니다.

결국 좋은 KPI는 현재 상태를 설명하는 숫자가 아니라 앞으로 어떤 일이 발생할지를 예측하게 만드는 도구입니다.

Queue 적체율 KPI를 만들며 얻은 가장 큰 깨달음은 데이터의 본질은 숫자 그 자체가 아니라 변화의 방향성과 맥락에 있다는 점이었습니다. 운영자가 이 흐름을 이해하는 순간 데이터는 단순한 모니터링 수치가 아니라 시스템의 미래를 읽는 언어가 됩니다.