· 박준성 (CEO / Junsung Park) · Technology · 12 min read
게이트 처리 비용을 정확하게 측정하는 법: 셰딩 효과와 오버헤드 분리하기
앞선 두 글에서는 체류 시간이 길어진 요청을 차단하는 '시간 상한 게이트'에 대해 이야기했습니다. 이제 남은 질문은 하나입니다. "그 게이트를 거치는 데 드는 연산 비용은 얼마인가?"

앞선 두 글에서는 체류 시간이 길어진 요청을 차단하는 ‘시간 상한 게이트’에 대해 이야기했습니다. 이제 남은 질문은 하나입니다. “그 게이트를 거치는 데 드는 연산 비용은 얼마인가?”
이 글은 그 비용을 측정하려다 함정에 빠지고, 다시 실수를 바로잡은 기록입니다. 제품의 성능 자랑이 아니라, 올바른 성능 측정 방법론에 관한 이야기입니다.
게이트를 켰는데 더 빨라졌다?
게이트의 오버헤드를 재는 방법은 단순해 보였습니다. 동일한 바이너리에서 기능 플래그를 이용해 게이트를 켠 쪽과 끈 쪽을 동일한 부하 조건에서 돌려 처리 시간을 비교하는 것이었죠. 그런데 결과가 이상했습니다. 게이트를 켠 쪽이 끈 쪽보다 처리 시간이 약 18%나 더 짧게 나온 것입니다. 1
얼핏 들으면 좋은 소식 같지만, 상식적으로 그럴 리가 없었습니다. 게이트를 켜면 코드를 한 줄이라도 더 실행하게 되므로, 순수한 오버헤드는 시스템을 미세하게라도 느려지게 만들어야 정상입니다. 켠 쪽이 빨라졌다는 것은 게이트의 비용이 마이너스라는 뜻이 아니라, 우리가 애초에 ‘비용’이 아닌 ‘다른 것’을 재고 있었다는 결정적인 신호였습니다.
빨라진 진짜 이유는 게이트가 가벼워서가 아니었다
원인은 ‘부하’ 조건에 있었습니다. 우리는 파이프라인을 완전히 포화시킨 상태로 테스트를 진행했고, 이 극한의 조건에서 게이트는 전체 요청의 약 65%를 만료 임박이라는 이유로 차단했습니다.1 게이트가 앞단에서 요청을 버리면, 그 뒤에 이어질 송신 작업 등 후속 시스템의 일감도 통째로 사라집니다. 즉, 켠 쪽이 더 빨랐던 이유는 게이트가 가벼워서가 아니라, 게이트가 앞단에서 트래픽을 덜어준 덕분에 뒷단 시스템이 할 일이 줄어들었기 때문입니다.
이것이 핵심입니다. 부하 셰딩 효과와 게이트 자체의 오버헤드는 완전히 다른 지표입니다. 셰딩은 일감을 줄여 시스템 전체를 쾌적하게 만들고, 오버헤드는 매 요청을 검사할 때마다 얹혀지는 순수 연산 비용입니다. 셰딩이 발생하는 상황에서 측정을 하면, 게이트의 오버헤드가 셰딩이 가져다준 거대한 성능 이득에 파묻혀 버리게 됩니다.
순수 오버헤드는 ‘드롭 0’ 상태에서만 측정할 수 있다
측정 방식을 교정하기 위한 원칙은 분명해졌습니다. 게이트의 순수 비용을 재려면, 게이트가 단 하나의 요청도 덜어내지 않아야 합니다. 그래서 우리는 부하량과 시간 상한선(T)을 여유 있게 조정하여 ‘어떤 요청도 버려지지 않는 상태(드롭 0)‘를 만든 후 비용을 재기로 했습니다. 이 조건에서는 게이트 로직이 매 요청마다 실행되긴 하지만 실제 차단은 일어나지 않으므로, 켠 쪽과 끈 쪽의 지연 시간 차이에는 오직 순수 연산 오버헤드만 남게 됩니다.
통계 기법이 아니라 ‘실험 조건’을 고치다
재측정을 위해 수정한 것은 통계 기법이 아니라 테스트 조건이었습니다. 동일한 인스턴스에서 켠 쪽과 끈 쪽을 번갈아 가며 측정해 장비 상태 변화를 상쇄하는 인터리브(Interleave) A/B 테스트, 첫 실행 시 발생하는 워밍업 노이즈 폐기, 다회 측정 후 중앙값 사용, 그리고 동일 바이너리를 반복 실행할 때 발생하는 자연 분산인 Noise Floor 기준점 설정까지. 이 철저한 통계적 방법론들은 첫 번째 측정 때도 이미 적용되어 있었습니다.
오히려 이 정교한 측정 장치들이 있었기 때문에, 처음에 “18% 빨라졌다”는 결과가 단순 측정 노이즈가 아니라 원인 규명이 필요한 ‘진짜 신호’라는 것을 알아챌 수 있었습니다. 우리가 바로잡은 것은 오직 ‘부하 조건’ 하나였습니다.
여기서 설정한 기저 노이즈는 중요한 판정 기준선이 됩니다. 켠 쪽과 끈 쪽의 차이가 이 기저 노이즈보다 작다면, 그것은 현재의 측정이 잡아낼 수 없는 미세한 차이라는 뜻입니다.
측정 결과, 그리고 다음 함정을 피하는 법
조건을 바로잡은 재실험에서, 켠 쪽과 끈 쪽의 차이는 기저 노이즈 아래로 떨어졌습니다.2 그래서 우리는 “비용이 0이다”라고 단정 지어 말하지 않습니다. 우리가 확언할 수 있는 것은 “게이트의 오버헤드가 측정 노이즈와 구분되지 않을 만큼 미미했다”는 것뿐이며, 엔지니어링 관점에서는 이것이 정확한 진술입니다.
이때 얻은 교훈은 이후의 측정 과정에 확고한 원칙으로 자리 잡았습니다. 뒤이은 오버헤드 측정에서는 무조건 ‘드롭 0’ 여부를 첫 관문으로 두었고, 단 하나의 요청이라도 차단되었다면 그 측정값은 무효 처리했습니다. 동일한 함정을 처음부터 피하기 위해서입니다. 엄격히 통제된 후속 실험에서도 게이트를 켠 연산 비용은 언제나 기저 노이즈 아래였으며, 부하 셰딩으로 인해 뒷단 일감이 줄어든 효과는 비용이 아니라 별도의 효능으로 분리하여 산정했습니다.
마무리
“0과 구분할 수 없다”는 표현은 “0입니다”라는 말보다 약하게 들릴 수 있습니다. 하지만 기술적으로는 훨씬 투명한 표현입니다. 우리 측정 환경의 분해능(Resolution)이 그 극미한 오버헤드를 분리해 낼 만큼 촘촘하지 않았다는 뜻이지, 마법처럼 연산 비용이 존재하지 않는다고 증명한 것이 아니기 때문입니다. 측정이 불가능한 영역을 억지로 해석하지 않고 한계를 명확히 밝히는 것, 성능 주장의 신뢰는 바로 이 정직함에서 나옵니다.
우리는 실시간 입찰 인프라에서 꼬리 지연을 구조적으로 통제하는 저지연 트래픽 필터링 시스템을 만들고 있습니다.
이 게이트를 실제 서비스 트래픽에 영향 없이 테스트해 보고 싶다면, 트래픽 미러링 기반의 섀도 모드 파일럿으로 시작해 보실 수 있습니다.
Footnotes
약 18%와 약 65%는 당사 파이프라인을 극한으로 포화시킨 특정 실험 환경에서 관측된 수치입니다. 해당 조건에서 게이트가 전체 요청의 약 65%를 지연(만료)되었다는 이유로 차단했고, 앞단에서 부하를 덜어준 덕분에 전체 처리 시간이 약 18% 단축되었습니다. 두 수치 모두 특정 트래픽과 환경에서 발생한 일화적 측정치이므로, 일반적인 성능 지표로 활용할 수는 없습니다. 이 글의 주장은 측정된 숫자가 아니라 ‘측정 방법론’에 있습니다. ↩ ↩2
게이트의 순수 오버헤드는 단 하나의 요청도 폐기되지 않는 조건에서만 정확히 도출할 수 있습니다. 재실험은 파이프라인에서 게이트 로직에 의한 드롭이 0이 되도록 부하량과 상한선을 조정한 뒤, 동일 인스턴스에서 켠 쪽과 끈 쪽을 번갈아 가며 재는 인터리브 방식을 사용했습니다. 인터리브 A/B 통제, 첫 실행 폐기, 중앙값 사용, 기저 노이즈 설정 등의 방법론은 첫 번째 실험에도 동일하게 적용된 고정 변수였으며, 유일하게 변경된 것은 ‘부하 및 상한 조건’입니다. 기저 노이즈는 동일 바이너리를 반복 실행했을 때 발생하는 자연 분산으로 정의했으며, 관측된 시간 차이는 이 분산의 한계를 넘지 못했습니다. (절대적인 수치는 테스트 환경에 종속되므로 생략합니다.) ↩