인상적인 성능 향상이 중요하지 않을 때

18 hours ago 4

성능 최적화는 복잡한 시스템을 이해하고 제품을 개선하는 강력한 수단이지만, 10배 빠른 결과도 실제 업무 방식이나 처리량을 바꾸지 못할 수 있음
쿼리 응답을 5~10분에서 30초~1분으로 줄여도, 사람이 기다리며 주의를 유지하는 약 10초 임계값을 넘으면 체감 효과가 제한됨
작업이 하루 1건·2건처럼 정수 단위로 묶이면 25~50% 개선만으로는 부족하며, 이동 시간을 포함해 각 작업이 4시간 이하가 되어야 하루 2건이 가능함
데이터 파이프라인에서는 느린 단계가 상류에 백프레셔를 걸기 때문에, 단일 단계가 크게 빨라져도 모든 병목이 풀리기 전까지 종단 간 처리량이 늘지 않을 수 있음
성능 개선은 개별 벤치마크가 아니라 원하는 결과를 기준으로 평가해야 하며, 주의 유지·작업 단위 증가·전체 처리량 같은 제약을 넘지 못하면 큰 개선도 실질 효과가 작음

성능 수치와 실제 결과가 어긋나는 이유

성능 작업은 시스템을 더 효율적으로 만들고 고객에게 새로운 가능성을 열 수 있어 보람 있는 작업임
규모와 부하가 걸린 복잡한 시스템이 어떻게 상호작용하는지 경험적으로 이해하는 데도 도움이 됨
시스템을 가까이 다루는 과정에서 제품과 서비스를 개선할 아이디어가 나오며, 그중 일부는 성능 최적화와 직접 관련이 없음
다만 “10배 빠름”, “리소스 50% 감소”처럼 보기 좋은 성과도 숨은 제약을 넘지 못하면 기대한 변화를 만들기 어려움

10초를 넘으면 사용자의 주의가 끊김

새 데이터베이스의 쿼리 성능을 개선해, 기존 데이터베이스에서 가장 비싼 쿼리가 5~10분 걸리던 것을 30초~1분으로 줄인 사례가 있음
이 결과는 10배 수준의 개선이었지만, 사용자 경험을 바꾸려면 또 한 번의 큰 개선이 필요했음
인간-컴퓨터 상호작용 연구에서는 사람이 전체 작업에 주의를 유지하는 한계를 약 10초로 봄
- 0.1초는 즉각적인 피드백으로 인식되는 임계값
- 약 1초는 작업 흐름이 이어지는 임계값
- 약 10초는 전체 작업에 대한 주의를 유지하는 임계값
- 진행 표시기나 예상 시간 같은 피드백은 주의 유지에 도움을 줄 수 있음
30초와 5분은 모두 10초를 넘기 때문에 사용자는 메시지를 확인하거나, 커피를 마시러 가거나, 대화를 시작하거나, 다른 작업으로 전환함
사용자가 몇 분 또는 몇 시간 뒤 돌아왔을 때 UI가 이미 로드되어 있다면, 실제 대기 시간이 30초였는지 5분이었는지는 업무 방식에 큰 차이를 만들지 않음
해당 프로젝트에서는 결국 다수의 쿼리를 10초 이하로 줄였고, 이전에는 타임아웃 때문에 불가능했던 일부 쿼리도 가능해짐
- 데이터 쿼리 지연뿐 아니라 메타데이터 쿼리 지연과 웹페이지 렌더링 시간도 전체 성능 개선에 중요했음
- 비동기 IO와 데이터 집계 개선으로 또 한 번의 10배 개선 가능성이 남아 있으며, 그렇게 되면 예전에는 몇 분 걸리던 쿼리가 1초 이하로 돌아올 수 있음

하루 1건에서 2건으로 넘어가는 임계값

한 프로젝트에서는 수동 작업 자동화, 불필요한 단계 제거, 일부 병렬화, 나중에 비동기로 처리할 수 있는 단계 지연을 통해 전체 프로세스를 몇 시간에서 안정적으로 1시간 미만으로 줄임
개선 폭은 대략 25~50% 였지만, 전체 프로세스는 물류 제약 때문에 바뀌지 않았음
배관공, 전기공, 목수처럼 장소를 예약하고 이동한 뒤 작업을 완료해야 하는 경우를 생각할 수 있음
- 하루 8시간 일하고 한 장소의 작업에 8시간이 걸리면, 2~3시간을 아껴도 새 장소로 이동해 새 작업을 끝낼 시간이 없음
- 이동 시간을 포함해 각 작업이 4시간 이하가 되지 않으면 하루 2건을 완료할 수 없음
이런 임계값을 넘기 전까지는 중간 단계의 효율 개선이 생산량 증가로 이어지지 않음
성능에 집중한 덕분에 고객 경험에 직접 영향을 주는 품질과 안정성 개선도 함께 이뤄질 수 있음
- 프로덕션에서 돌파구가 되지 못한 작은 성능 개선도 테스트 환경의 반복 속도를 높여 기능 개발과 결함 해결을 빠르게 만들 수 있음

백프레셔가 있는 파이프라인의 병목

많은 비즈니스 소프트웨어 인프라는 차량, 공장 장비, 모바일폰, 금융 거래 같은 여러 소스의 이벤트를 처리하는 데이터 파이프라인을 포함함
이벤트는 보통 내구성 있는 로그에 저장되고, 하류 서비스가 이를 소비해 처리함
대규모 고처리량을 위해 로그는 파티션되어야 하며, 하류 서비스는 배치, 파이프라이닝, 병렬성, 효율적인 메모리 할당, 동적 확장 같은 기법을 사용함
데이터 파이프라인의 병목은 시스템 동작이 서로 연관되어 있어 찾기 어려움
- 느린 단계는 의도적으로 상류 단계에 백프레셔를 검
- 병목이 여러 개 있으면 마지막 병목까지 제거되기 전에는 전체 처리량이 늘지 않음
파이프라인을 단계로 나누고 각 단계의 성능 특성과 한계를 이해하는 것은 좋은 엔지니어링 관행임
하지만 단일 단계를 여러 자릿수 규모로 개선해도 전체 처리량에는 영향이 없을 수 있음
처리량 개선에서 중요한 수치는 개별 단계의 벤치마크가 아니라 종단 간 처리량임

병목을 찾는 경험적 접근

이런 시스템의 동역학과 병목을 이해하려면 파이프라인의 시작점부터 경험적으로 확인하는 방식이 유용함
예를 들어 분산 로그에서 이벤트를 읽고 버리는 단계부터 시작함
- 이 단계만으로 목표 처리량에 도달하지 못하면 하류 단계를 최적화해도 시간 낭비가 됨
데이터베이스에 초당 몇 행을 삽입할 수 있는지 같은 하류 벤치마크도 중요할 수 있지만, 분석은 상류부터 시작해야 함
복잡한 시스템과 성능을 이해하는 데는 시뮬레이션도 가치 있는 방법임
- Marc Brooker의 Simple Simulations for System Builders
- Try again: The tools and techniques behind resilient systems