초당 요청 수, 이제는 kHz나 MHz로 표현해보면 어떨까

"우리 서비스가 초당 요청 50만 개를 처리할 수 있어요"라는 말, 익숙하시죠. 그런데 이걸 읽을 때마다 머릿속에서 "어... 50만 곱하기 60은 3천만이고, 시간당은..." 이런 식으로 계산해본 경험 있으실 거예요. 특히 500 req/s 인지 5000 req/s 인지 단위가 헷갈려서 한참 다시 들여다보는 경우도 많고요. 이 문제를 근본적으로 풀자는 재미있는 제안이 있어요. "그냥 헤르츠(Hz)를 쓰자" 는 거예요.

req/s 대신 Hz?

주파수의 단위인 헤르츠는 "초당 몇 번"을 뜻하잖아요. 라디오 주파수 100MHz는 1초에 1억 번 진동한다는 뜻이고요. 그런데 서버의 초당 요청 수도 본질적으로 같은 개념이에요. "어떤 이벤트가 1초에 몇 번 발생하는가"를 재는 거니까요.

필자는 여기서 SI 접두어(kilo, mega, giga) 를 쓰자고 주장해요. 예를 들면 이런 식이죠. 초당 1500개의 요청은 1.5 kHz, 초당 200만 개면 2 MHz, 구글 검색이 하루에 수십억 건 처리한다면 그걸 초로 환산해서 수십 kHz 정도라고 표현할 수 있는 거예요.

이게 왜 좋은가

일단 숫자가 훨씬 읽기 편해요. "Our system handles 1,500,000 req/s" 와 "Our system handles 1.5 MHz" 중에 어느 게 한 눈에 들어오세요? 쉼표 위치 세느라 눈이 피곤해지는 전자보다, 접두어 하나로 규모가 확 와닿는 후자가 훨씬 직관적이죠.

두 번째로, 전기/전자 엔지니어들이 이미 수십 년 동안 쓰고 있는 표기법이에요. 프로세서 클럭 속도 3.5GHz, 오실로스코프 대역폭 500MHz 같은 표현에 우리는 이미 익숙하잖아요. 소프트웨어 업계만 "req/s", "RPS", "TPS", "QPS" 등등으로 따로 놀고 있는 거예요. TPS가 Transactions Per Second인지 Transmissions Per Second인지도 문맥에 따라 다르고요.

세 번째로는 계산이 쉬워져요. 1ms 레이턴시와 1 kHz 처리량이 붙어 있으면 바로 "아, 한 번 처리하는 데 1ms니까 초당 1000개구나" 하고 머리에 들어오잖아요. 시간의 역수가 주파수라는 물리학의 기본 관계를 그대로 쓸 수 있는 거예요.

반론도 있어요

물론 반대 의견도 만만치 않은데요. 가장 큰 반론은 "Hz는 주기적 이벤트에 쓰는 단위" 라는 거예요. 라디오파는 정확히 일정한 간격으로 진동하지만, 웹 서버 요청은 불규칙적으로 몰려 들어오는 버스트(burst) 성격이 강하죠. 평균 1kHz라고 해도 어떤 순간에는 10kHz가 한꺼번에 몰려올 수 있어요. 그래서 "평균"이라는 조건을 명시하지 않으면 오해를 부를 수 있다는 지적이에요.

또 기존 도구들과의 호환성 문제도 있어요. 프로메테우스나 그라파나에서 기본으로 req/s 로 찍히는데, 여기에 Hz 라벨을 붙이면 오히려 혼란스러울 수 있거든요. 현장 표준을 바꾸는 건 생각보다 관성이 크니까요.

한국 개발자 관점에서

사실 우리도 백엔드 설계 회의에서 처리량 이야기할 때 단위 때문에 답답한 순간 많잖아요. 특히 해외 팀이나 오픈소스 커뮤니티와 소통할 때 RPS, TPS, QPS 가 섞여 나오면 정리하기 힘들어요. 이번 기회에 팀 내 문서라도 Hz 기반으로 써보는 실험을 해볼 만해요. 최소한 성능 벤치마크 리포트 쓸 때 "우리 API는 평균 850 Hz 처리한다" 같은 식으로 써보면 굉장히 깔끔하거든요.

물론 업계 표준이 하루아침에 바뀌지는 않을 거예요. 하지만 개념을 다시 생각해보는 계기로는 충분한 제안이라고 봐요. "이벤트 발생률은 주파수다"라는 관점 하나만 머릿속에 심어도, 시스템을 보는 눈이 조금은 달라질 거예요. 여러분은 req/s 대신 Hz 쓰는 거, 실제로 도입할 의향이 있으세요?