C10K 문제(C10k Problem)란 무엇인가?

태하팍 2025. 8. 16. 19:20

1. C10K 문제의 배경

1990년대까지만 해도 웹 서버가 수백 개의 동시 연결만 처리해도 충분했습니다.
하지만 인터넷 보급과 함께 수천~수만 명이 동시에 접속하는 상황이 생기면서 기존 방식으로는 서버가 감당하기 어려운 한계에 부딪히게 되었고, 이를 C10K 문제라고 부릅니다.
여기서 "C10K"는 Concurrent 10,000 connections의 줄임말입니다.

2. 기존 방식의 한계

초기 서버는 연결마다 스레드나 프로세스를 생성하는 구조였습니다.

연결이 늘어날수록 스레드 수가 기하급수적으로 증가
컨텍스트 스위칭 비용 증가
메모리 낭비와 동기화 오버헤드 발생

또한 Blocking I/O를 사용했기 때문에, 한 연결이 I/O 대기 상태라면 해당 스레드는 CPU를 제대로 활용하지 못했습니다.

3. 해결 방법

Non-blocking I/O
- epoll, kqueue, IOCP 같은 커널 레벨 이벤트 통지 활용
- 하나의 스레드/프로세스가 수천~수만 개의 연결을 동시에 관리
이벤트 기반 아키텍처
- 이벤트 루프(Event Loop) 기반으로 요청 처리
- 대표 사례: Nginx, Node.js, Netty
- 이벤트 루프(Event Loop) 기반으로 요청 처리 → 불필요한 스레드 생성 방지,리소스 효율 극대화
스레드풀 + 비동기 처리
- I/O 이벤트는 이벤트 루프가 받고
- CPU 연산(압축, 암호화, DB 쿼리 등)만 스레드풀에서 처리
네트워크 프로토콜 최적화
- HTTP/1.1 keep-alive, HTTP/2 multiplexing, HTTP/3(QUIC)
  - 연결 수 자체를 줄이거나 전송 효율 극대화
메시지 큐 & 스트리밍 플랫폼 활용
- Apache Kafka, RabbitMQ, Pulsar 등
- 대량의 이벤트/메시지를 비동기 스트리밍으로 처리 → 서버의 직접 연결 부하 완화
  - 예: 채팅 서버에서 클라이언트 연결은 이벤트 루프 기반으로 처리, 메시지는 Kafka를 통해 다른 서버로 분산
마이크로서비스 & 수평 확장(Scale-out)
- 하나의 거대한 서버 대신, 서비스 단위로 쪼개서 컨테이너 + 오케스트레이션(Kubernetes, Istio) 환경에서 확장
- 연결이 늘어나면 인스턴스를 자동으로 늘려서 대응
서버리스 아키텍처 (FaaS)
- AWS Lambda, Google Cloud Functions 등
- 특정 요청을 서버리스 함수로 던져서 처리 → 항상 열려있는 연결 수를 줄이고 필요할 때만 자원 사용
멀티코어 & NUMA 최적화
- 현대 서버는 코어 수가 많으므로, I/O 이벤트 루프를 코어별로 분산
- Netty, Akka, Go 런타임은 이런 구조를 적극 활용
BPF/eBPF 기반 네트워크 최적화
- 최근 리눅스에서는 eBPF를 활용해 커널 레벨에서 네트워크 성능 최적화
- 연결 추적, 로드밸런싱, 패킷 필터링을 유저 공간이 아닌 커널에서 처리

4. 현재와 그 이후

오늘날 C10K 문제는 상당 부분 해결된 상태입니다.
대부분의 최신 서버(예: Nginx, Netty, Akka, Node.js)는 비동기 이벤트 기반 모델을 채택하고 있습니다.

이제는 C10M(천만 연결), C100M(억 단위 연결) 문제로 확장되고 있으며, 이는 실시간 메신저, IoT, 초대규모 스트리밍 서비스 등에서 중요한 이슈가 되고 있습니다.

정리
C10K 문제는 단순히 “10,000개 연결 처리”의 문제가 아니라,
동시성을 효율적으로 다루는 서버 아키텍처의 전환점이었습니다.
Blocking 기반의 "스레드 per connection" 모델에서 → Non-blocking + 이벤트 루프 기반의 아키텍처로 진화하게 된 배경을 설명하는 대표적인 사례입니다.

또한, 과거: epoll + 이벤트 루프 기반 I/O 모델 → C10K 해결을 했는데 근래에는 메시지 큐(Kafka), 마이크로서비스 + 쿠버네티스, 서버리스, HTTP/3, eBPF 최적화 같은 기술이 합쳐져서 사실상 C10M, C100M 문제에 도전하고 있습니다.