Hacker News 2026.04.27 25

"req/s"는 맞고 "Hz"는 틀린 이유 — 단위가 알려주는 시스템의 본질

사소해 보이지만 사소하지 않은 이야기

어떤 분이 모니터링 대시보드를 보다가 "웹 요청 처리량을 Hz(헤르츠)로 표시한 그래프" 를 발견하고 한마디 남긴 게 작은 화제가 됐어요. 보기엔 별일 아닌 것 같죠? "초당 횟수"라는 의미니까 RPS든 Hz든 결국 같은 단위 아니냐고 생각할 수 있는데, 사실 이게 시스템을 바라보는 관점 자체를 바꾸는 꽤 중요한 지적이에요. 단위 하나 잘못 쓰면 그래프를 해석하는 사람의 머릿속에 엉뚱한 모델이 자리 잡거든요.

Hz가 뭐였는지 다시 보기

헤르츠(Hz) 는 "1초에 몇 번 반복되는가"를 나타내는 단위예요. 차원으로 보면 1/s, 즉 "초의 역수"죠. 수학적으로는 RPS(Requests Per Second)와 똑같습니다. 그래서 누가 "내 서버는 5,000Hz 처리해"라고 해도 산수만 보면 틀린 말이 아니에요.

그런데 Hz는 주기적이고 규칙적인 진동·반복 을 가리킬 때 쓰는 단위예요. CPU 클럭 3GHz는 1초에 정확히 30억 번, 정확한 간격으로 톡톡톡 떨어지는 신호고, 60Hz 모니터는 1/60초마다 칼같이 화면을 갱신하죠. 음파 440Hz도 마찬가지로 균일한 사인파의 진동수예요. "같은 일이 일정한 간격으로 반복된다" 는 뉘앙스가 단위 자체에 박혀 있어요.

반면 웹 요청은 어떻게 들어오나요? 완전히 무작위로, 폭발적으로, 묶음으로 들어옵니다. 평균 5,000RPS인 서비스도 100ms 동안 1만 건이 몰렸다가 다음 100ms는 텅 비기도 해요. 사용자 트래픽은 푸아송 분포(Poisson distribution)에 가까운 분포를 따르는 게 보통이고, 광고 캠페인이나 푸시 알림이 터지면 짧은 시간에 평소의 10배 이상이 폭주하기도 합니다. 즉 요청은 진동이 아니라 사건(event) 이에요.

왜 단위 선택이 중요한가

같은 "1초에 5,000번"이라도 단위에 따라 머릿속 그림이 달라져요. 5,000Hz라고 하면 무의식적으로 "0.2ms마다 한 건씩 똑똑 떨어지겠구나" 같은 균등 분포 모델이 떠올라요. 그러면 용량 계획을 세울 때도 "평균만 버티면 되겠네"라는 결론이 나오기 쉽죠.

그런데 현실의 트래픽은 P50(중앙값)과 P99(상위 1%)가 5배, 10배씩 차이 나는 게 보통이에요. 5,000RPS라고 하면 "이건 평균값이고, 실제로는 들쭉날쭉할 텐데 피크는 어디까지 갈까?" 같은 질문이 자연스럽게 따라붙어요. 같은 숫자라도 단위가 어떤 멘탈 모델을 끌어오느냐에 따라 다음 질문이 달라지는 거죠.

좀 더 기술적으로 보면, 큐잉 이론(queuing theory)에서 균일한 도착률 을 가정하느냐 확률적 도착률(arrival rate) 을 가정하느냐에 따라 필요한 버퍼 크기, 워커 수, 타임아웃 설정이 다 달라져요. 실무에서 "왜 평균 부하는 낮은데 가끔씩 응답 시간이 튀지?"라는 미스터리의 답이 대부분 여기 있거든요. 도착이 균일하지 않다는 사실을 잊으면 P99가 무너지는 시스템이 만들어집니다.

업계의 관행은 어떻게 정착했나

그래서 모니터링 도구들은 대부분 RPS, req/s, QPS(Queries Per Second), TPS(Transactions Per Second) 같은 표현을 써요. Prometheus의 rate() 함수도 결과를 "per second"로 부르지 Hz라고 부르지 않죠. Grafana 대시보드 템플릿이나 Datadog의 기본 메트릭도 마찬가지예요. "per"라는 단어가 들어가면서 "단위 시간당 발생 건수" 라는 사건 기반 의미가 명확해져요.

반대로 Hz가 적절한 곳도 분명히 있어요. 폴링 주기, 게임 루프의 틱 레이트, 센서 샘플링 주파수, GC 사이클 처럼 우리가 "고정된 간격으로 반복하도록 설계한" 동작들은 Hz가 정확한 단위예요. tick 60Hz, sampling 1kHz는 의미가 분명하죠. 즉 단위는 "숫자가 같은가"가 아니라 "이 현상이 주기적인가, 사건적인가"로 골라야 한다는 거예요.

한국 개발자에게 주는 시사점

작은 디테일이지만 팀 내 용어 통일 에 한 번쯤 점검해볼 가치가 있어요. 사내 위키에 "성능 지표 표기 가이드"가 있다면 RPS, QPS, IOPS, TPS 같은 표현을 권장하는 게 좋고, Grafana 패널 제목이나 SLO 문서에서도 일관되게 가는 편이 협업에 도움이 됩니다. 특히 부하 테스트 결과를 공유할 때 단위 표기가 흔들리면 의사결정이 미묘하게 어긋나요.

또 하나, 사용자 행동을 다루는 모든 메트릭 — 클릭, 로그인, 주문, 결제 — 도 Hz가 아니라 "per second/minute/hour"로 부르는 습관을 들이면 분포에 대한 감각이 자연스럽게 따라옵니다. 평균만 보지 않고 분포와 피크를 함께 보는 시야가 생기거든요.