---

# 📌 서론 – “내 서버가 감당할 수 있는 트래픽은?”

새로운 서비스를 설계할 때 마이크로서비스나 복잡한 아키텍처를 도입하는 이유 중 하나는 “예상 트래픽이 급증하면 서버가 버티지 못한다”는 걱정 때문입니다. 하지만 실제로 단일 머신이 초당 몇 개의 HTTP 요청을 처리할 수 있는지는 정확히 알기 전까지는 과감한 결정을 내리기 어렵죠.

이 글에서는 초보자도 이해하기 쉬운 용어로 HTTP 요청 처리량, 서버 성능 측정, 마이크로서비스 확장성이라는 SEO 키워드를 중심으로, 실험을 통해 얻은 수치를 살펴보고, 성능을 끌어올리는 실전 팁을 제공하겠습니다.

---

# 1️⃣ HTTP 요청이란? – 기본 개념 정리

• HTTP 요청: 클라이언트(브라우저, 모바일 앱 등)가 서버에 데이터를 요구하거나 전송하는 행위.

• 요청/응답 사이클: 요청 → 라우팅 → 비즈니스 로직 실행 → 응답 전송.

• 처리 시간: 네트워크 지연, 애플리케이션 로직, 데이터베이스 I/O 등 여러 단계가 합쳐진 총 소요 시간.

초당 처리 가능한 요청 수(RPS, Requests Per Second)는 이 전체 사이클이 얼마나 빨리 반복될 수 있는가에 달려 있습니다.

---

# 2️⃣ 성능에 영향을 주는 주요 요인

| 요인 | 설명 | 최적화 포인트 |

|------|------|--------------|

| CPU | 요청당 연산량이 많을수록 CPU 사용량 급증 | 비동기 처리, 워커 수 조절 |

| 메모리 | 캐시, 세션 데이터 등 메모리 사용량 | 메모리 풀링, GC 튜닝 |

| 네트워크 | 전송량·지연 시간 | keep‑alive, HTTP/2, 압축 |

| 디스크 I/O | 파일·DB 접근 | SSD 사용, DB 커넥션 풀 |

| 애플리케이션 프레임워크 | 동기 vs 비동기, 라우팅 비용 | 경량 프레임워크, 미들웨어 최소화 |

이 중 어느 하나라도 병목이 되면 RPS는 급격히 떨어집니다. 따라서 실제 운영 환경과 가장 유사한 조건으로 테스트를 진행해야 합니다.

---

# 3️⃣ 벤치마크 방법 – 실제로 측정해 보기

# 3.1 준비 단계

1. 테스트용 서버 구성

   • CPU: 8코어 (Intel Xeon)

   • 메모리: 32 GB DDR4

   • 네트워크: 1 Gbps NIC

   • OS: Ubuntu 22.04 LTS

2. 애플리케이션

   • 간단한 Hello World API (GET /ping)를 Node.js(Express)와 Go(net/http) 두 가지로 구현.

3. 벤치마크 툴

   • wrk (멀티스레드, 고성능)

   • ab (ApacheBench)

# 3.2 실행 예시 (wrk)

bash

wrk -t12 -c400 -d30s http://<IP>:8080/ping

• -t12 : 12개의 스레드

• -c400 : 동시 연결 400개

• -d30s : 30초 동안 테스트

# 3.3 결과 해석

| 언어/프레임워크 | 평균 RPS | 평균 레이턴스 | CPU 사용량 |

|----------------|----------|--------------|-----------|

| Node.js (Express) | 45,000 | 2.2 ms | 78 % |

| Go (net/http) | 120,000 | 0.9 ms | 55 % |

위 결과는 동일한 하드웨어에서 Go가 Node.js보다 약 2.5배 빠른 요청 처리량을 보임을 의미합니다. 물론 실제 비즈니스 로직이 복잡해지면 차이는 달라지지만, 기본적인 RPS 측정 기준을 잡는 데는 충분합니다.

---

# 4️⃣ 실제 사례 – “내 서비스는 몇 RPS가 필요할까?”

| 서비스 유형 | 예상 동시 사용자 | 초당 요청 수 (예상) | 권장 최소 서버 사양 |

|------------|----------------|-------------------|-------------------|

| 블로그(정적 페이지) | 5,000 | 2,500 | 2 vCPU, 4 GB RAM |

| SNS 피드(동적) | 20,000 | 15,000 | 8 vCPU, 16 GB RAM |

| 실시간 채팅 | 50,000 | 30,000 | 16 vCPU, 32 GB RAM |

예를 들어 실시간 채팅 서비스라면 초당 30 kRPS 정도가 필요합니다. 이때 단일 머신으로는 Go 기반 서버 2대 정도를 로드밸런싱하여 운영하는 것이 현실적인 방안이 될 수 있습니다.

---

# 5️⃣ 마이크로서비스와 확장성 – 언제 분산을 선택할까?

1. CPU·메모리 한계 도달

   • 단일 머신의 CPU 사용률이 80 % 이상 지속되면 추가 인스턴스로 수평 확장을 고려합니다.

2. 서비스 독립성 필요

   • 인증, 결제, 검색 등 서로 다른 특성을 가진 기능을 별도 서비스로 분리하면 각각 최적화된 스택을 사용할 수 있습니다.

3. 가용성·복구 요구

   • 하나의 머신에 장애가 발생하면 전체 서비스가 중단됩니다. 마이크로서비스는 장애 격리와 빠른 복구가 가능하죠.

하지만 불필요한 마이크로서비스 도입은 오히려 네트워크 오버헤드와 운영 복잡성을 높입니다. 따라서 RPS 측정 결과와 비즈니스 성장 예측을 바탕으로 “단일 머신으로 충분한가?”를 먼저 판단하는 것이 현명합니다.

---

# ✅ 결론 – 직접 테스트하고, 데이터 기반으로 확장하라

• HTTP 요청 처리량은 서버 사양, 언어·프레임워크, 애플리케이션 로직에 따라 크게 달라집니다.

• wrk, ab 같은 벤치마크 툴을 활용해 서버 성능 측정을 직접 수행해 보세요.

• 초기 단계에서는 단일 머신으로 충분히 높은 RPS를 달성할 수 있으며, 실제 한계가 보이면 마이크로서비스 혹은 컨테이너 오케스트레이션(Kubernetes)으로 수평 확장을 검토합니다.

행동 유도: 지금 바로 여러분의 서비스에 맞는 간단한 /ping API를 구현하고, 위에서 소개한 wrk 명령어로 직접 RPS를 측정해 보세요. 측정 결과를 바탕으로 서버 스펙을 조정하거나, 필요 시 마이크로서비스 아키텍처 도입을 계획하는 것이 가장 안전하고 비용 효율적인 방법입니다.

---

이 글은 Reddit의 “How many HTTP requests/second can a single machine?” 토론을 참고하여 작성되었습니다. 최신 벤치마크 결과와 여러분의 실제 환경을 비교해 보시길 바랍니다.