Workflow 처리량보다 Latency를 관리해야 하는 이유

워크플로우에서 처리량보다 지연 시간을 먼저 챙겨야 하는 이유

Workflow 처리량보다 Latency를 관리해야 하는 이유

자동화 플랫폼이나 워크플로우 엔진을 운영하다 보면 가장 먼저 보게 되는 숫자가 있습니다.

바로 처리량(Throughput)입니다.

“초당 몇 개의 작업을 처리하는가?”

“하루에 몇 만 건의 Workflow를 실행하는가?”

“현재 Queue에 몇 개의 작업이 쌓여 있는가?”

이러한 지표는 시스템 규모를 보여주기 때문에 자연스럽게 관심을 받습니다.

실제로 많은 운영팀이 처리량 증가를 성능 향상의 기준으로 생각합니다.

하지만 운영 경험이 쌓일수록 한 가지 사실을 깨닫게 됩니다.

사용자는 처리량을 체감하지 않습니다.

사용자가 체감하는 것은 Latency입니다.

Workflow 엔진이 하루에 100만 건을 처리하더라도 자신이 실행한 작업이 30초 뒤에 완료된다면 사용자는 시스템이 느리다고 판단합니다.

반대로 하루 처리량이 적더라도 요청 즉시 결과를 받을 수 있다면 서비스 품질은 높게 평가됩니다.

그래서 실제 운영 환경에서는 처리량보다 Latency를 먼저 관리해야 합니다.

처리량은 시스템 관점의 지표다

처리량은 일정 시간 동안 얼마나 많은 작업을 처리했는지를 의미합니다.

예를 들어 다음과 같은 수치가 처리량에 해당합니다.

• 초당 1,000건 처리
• 분당 5만 건 처리
• 하루 100만 건 처리

처리량은 시스템이 얼마나 많은 업무를 수행할 수 있는지를 보여줍니다.

문제는 처리량만으로는 사용자 경험을 설명할 수 없다는 것입니다.

예를 들어 두 개의 Workflow Engine이 있다고 가정해 보겠습니다.

A 시스템

• 초당 처리량 5,000건
• 평균 실행 시간 15초

B 시스템

• 초당 처리량 3,000건
• 평균 실행 시간 1초

운영자 입장에서는 A가 더 뛰어난 시스템처럼 보일 수 있습니다.

하지만 실제 사용자는 대부분 B를 더 빠르고 안정적인 서비스로 인식합니다.

왜냐하면 사용자는 처리량이 아니라 대기 시간을 경험하기 때문입니다.

Workflow에서는 Latency가 더욱 중요하다

일반적인 배치 시스템과 달리 Workflow 엔진은 여러 단계를 순차적으로 수행합니다.

예를 들어 다음과 같은 자동화 프로세스를 생각해 볼 수 있습니다.

1. API 호출
2. 데이터 변환
3. 데이터베이스 저장
4. 외부 시스템 연동
5. 알림 발송

각 단계가 500ms씩만 지연되어도 전체 Workflow는 2.5초 이상 느려집니다.

문제는 이러한 지연이 누적된다는 점입니다.

특히 외부 API 호출이 많은 Workflow에서는 작은 Latency 증가도 전체 처리 시간을 크게 늘릴 수 있습니다.

실제로 제가 운영했던 자동화 환경에서도 처리량은 충분했지만 사용자의 불만이 발생한 적이 있었습니다.

원인을 분석해 보니 Queue는 비어 있었고 CPU도 여유가 있었습니다.

하지만 외부 API 응답 시간이 평소보다 300ms 정도 증가하면서 Workflow 전체 실행 시간이 두 배 이상 길어졌던 것입니다.

이 사례를 통해 처리량보다 Latency가 사용자 경험에 더 직접적인 영향을 준다는 사실을 확인할 수 있었습니다.

Latency는 장애의 조기 경고 신호다

Latency가 중요한 또 다른 이유는 장애를 가장 먼저 알려주는 지표이기 때문입니다.

대부분의 장애는 다음과 같은 순서로 진행됩니다.

1. Latency 증가
2. 처리량 감소
3. Queue 증가
4. Error Rate 증가
5. 사용자 장애 발생

많은 운영팀이 Queue가 증가한 뒤에 대응합니다.

하지만 그 시점은 이미 늦은 경우가 많습니다.

실제로는 Latency 그래프가 가장 먼저 이상 신호를 보내고 있습니다.

특히 P95 또는 P99 Latency가 증가하기 시작한다면 시스템 내부 어딘가에서 병목이 발생하고 있을 가능성이 높습니다.

따라서 장애를 예방하려면 처리량보다 Latency를 먼저 관찰해야 합니다.

평균 Latency보다 P99가 중요한 이유

운영 초기에 자주 하는 실수 중 하나는 평균 응답시간만 보는 것입니다.

하지만 평균값은 현실을 숨길 수 있습니다.

예를 들어 100개의 Workflow가 있다고 가정해 보겠습니다.

99개는 1초 안에 완료됩니다.

1개는 30초가 걸립니다.

평균값은 크게 나쁘지 않아 보일 수 있습니다.

그러나 실제로 30초를 기다린 사용자는 서비스가 멈췄다고 생각할 가능성이 높습니다.

그래서 운영 환경에서는 다음 지표를 함께 확인합니다.

• Average Latency
• P95 Latency
• P99 Latency
• Max Latency

특히 P99 Latency는 가장 느린 사용자 경험을 보여주기 때문에 매우 중요한 운영 지표입니다.

Throughput 최적화가 오히려 문제를 만드는 경우

많은 엔지니어가 처리량 향상을 목표로 시스템을 개선합니다.

하지만 Throughput 중심 최적화는 예상치 못한 문제를 만들 수 있습니다.

대표적인 사례가 Batch 처리입니다.

작업을 하나씩 처리하는 대신 100개씩 묶어서 처리하면 처리량은 크게 증가합니다.

그러나 개별 작업은 Batch가 채워질 때까지 기다려야 합니다.

결국 사용자는 더 긴 대기 시간을 경험하게 됩니다.

실제로 처리량만 보면 성능이 좋아졌지만 사용자 경험은 오히려 나빠진 것입니다.

이러한 이유로 처리량 향상과 Latency 감소는 별개의 목표로 관리해야 합니다.

Workflow 운영자가 반드시 모니터링해야 할 지표

Latency 중심 운영을 위해서는 다음 항목을 지속적으로 확인해야 합니다.

• Workflow Execution Time
• Queue Waiting Time
• P95 Latency
• P99 Latency
• External API Latency
• Database Query Time
• Retry Rate
• Error Rate
• Consumer Lag
• Throughput Gap

특히 Queue Waiting Time은 많은 운영팀이 놓치는 지표입니다.

실행 시간은 짧지만 Queue에서 오래 기다리는 경우 사용자는 동일하게 느린 서비스를 경험하게 됩니다.

비용을 늘리지 않고 Latency를 줄이는 방법

많은 사람들이 Latency 문제를 발견하면 서버 증설부터 생각합니다.

하지만 실제 원인은 다른 곳에 있는 경우가 많습니다.

대표적인 개선 방법은 다음과 같습니다.

• 데이터베이스 쿼리 최적화
• 캐시 활용
• 외부 API 호출 횟수 감소
• 불필요한 Workflow 단계 제거
• 병렬 처리 적용
• Queue 구조 개선

실제 운영 환경에서는 서버를 두 배로 늘리는 것보다 비효율적인 API 호출 하나를 제거하는 것이 더 큰 효과를 내는 경우도 많습니다.

결론

처리량은 시스템이 얼마나 많은 일을 할 수 있는지를 보여줍니다.

하지만 Latency는 사용자가 실제로 경험하는 서비스 품질을 보여줍니다.

Workflow 엔진 운영에서 중요한 것은 “얼마나 많이 처리했는가”가 아니라 “얼마나 빨리 결과를 전달했는가”입니다.

대부분의 장애 역시 Latency 증가에서 시작됩니다.

Queue 증가, 처리량 감소, 에러 발생은 그 이후에 나타나는 결과일 뿐입니다.

따라서 안정적인 Workflow 플랫폼을 운영하고 싶다면 처리량 그래프보다 먼저 Latency 그래프를 확인하는 습관을 만드는 것이 좋습니다.

결국 뛰어난 운영자는 처리량을 자랑하는 사람이 아니라, 사용자가 기다리는 시간을 줄이는 사람입니다.