본문 바로가기
카테고리 없음

C10K Problem은 왜 서버 역사에서 중요할까

by by_merry 2026. 5. 24.

요즘은 수많은 사람이 동시에 접속하는 웹서비스를 너무 당연하게 사용한다. 유튜브 라이브 방송, 대형 게임 서버, 실시간 채팅 서비스까지 동시에 수십만 명이 연결되는 것도 이제는 특별한 일이 아니다. 그런데 예전 인터넷 초기 시절에는 서버가 동시에 1만 개 연결(Connection)조차 처리하기 어려웠던 시기가 있었다고 한다. 그리고 이 문제를 바로 C10K Problem이라고 부른다.

처음 이름을 봤을 때는 무슨 에러 코드 같은 느낌이었다. 그런데 의미를 알고 나니까 꽤 흥미로웠다. 여기서 C는 Connection, 10K는 10,000을 의미한다. 즉, “서버가 동시에 1만 개 연결을 효율적으로 처리할 수 있는가?”라는 문제였던 것이다.

나도 처음에는 “요즘 컴퓨터면 그냥 되지 않나?” 싶었는데, 당시 서버 구조를 찾아보니까 왜 이 문제가 서버 역사에서 엄청 중요한 전환점이었는지 조금 이해가 되기 시작했다.

 

예전 서버는 연결마다 스레드를 만드는 방식이 많았다

초기 서버 구조에서는 클라이언트 연결마다 스레드(Thread)나 프로세스(Process)를 하나씩 생성하는 방식이 자주 사용되었다.

예를 들어 사용자가 웹사이트에 접속하면:

  • 연결 생성
  • 스레드 하나 할당
  • 요청 처리
  • 응답 전송

같은 흐름으로 동작하는 방식이었다.

처음에는 나도 이 방식이 꽤 직관적으로 느껴졌다. 연결 하나당 작업 담당자 하나 붙이는 느낌이라 이해하기 쉬웠기 때문이다.

문제는 연결 수가 폭발적으로 늘어나기 시작하면서 발생했다.

예를 들어 동시에 수천~수만 명이 접속하면 서버는 엄청난 수의 스레드를 계속 관리해야 한다. 그런데 스레드는 생각보다 가벼운 존재가 아니었다.

각 스레드는:

  • 메모리 사용
  • CPU 상태 저장
  • 스케줄링 비용
  • Context Switching

같은 추가 비용을 계속 만든다.

나도 처음에는 “CPU가 그냥 알아서 돌리면 되는 거 아닌가?” 싶었는데, 실제로는 스레드 수가 너무 많아지는 순간 Context Switching 비용이 폭발적으로 증가하면서 CPU가 실제 작업보다 “작업 전환”에 더 많은 시간을 쓰게 되는 상황이 발생할 수 있다고 한다.

특히 대부분 연결은 실제 데이터를 계속 보내는 게 아니라 “대기 상태”인 경우가 많기 때문에, 서버는 아무 일도 안 하는 연결들을 관리하는 데 엄청난 자원을 낭비하게 되는 것이다.

C10K Problem은 현대 이벤트 기반 서버 구조를 탄생시켰다

C10K Problem이 중요한 이유는 단순히 “1만 연결 어렵네” 수준의 문제가 아니었기 때문이다. 이 문제를 해결하기 위해 서버 구조 자체가 완전히 바뀌기 시작했다.

대표적으로 등장한 개념이:

  • Epoll
  • 이벤트 루프(Event Loop)
  • 비동기 I/O
  • 논블로킹 소켓(Non-Blocking Socket)

같은 구조들이다.

즉, 서버가 연결마다 스레드를 하나씩 만드는 대신, “이벤트가 발생한 연결만 처리하자”라는 방식으로 바뀌기 시작한 것이다.

나도 Epoll 구조를 처음 봤을 때 꽤 신기했는데, C10K Problem 배경을 알고 나니까 왜 이런 구조가 등장했는지 훨씬 이해가 쉬워졌다.

예전 방식은 계속 모든 연결을 확인하는 느낌이었다면, 이벤트 기반 구조는 “필요할 때만 알려줘” 방식에 가까웠다.

덕분에 서버는 적은 수의 스레드만으로도 엄청 많은 연결을 효율적으로 처리할 수 있게 되었다.

특히 Nginx나 Node.js 같은 현대 서버들이 이벤트 기반 구조를 적극적으로 사용하는 이유도 결국 이 흐름과 연결되어 있었다.

그걸 보면서 처음으로 “현대 서버는 단순히 CPU 성능으로 버티는 게 아니구나”라는 걸 느끼게 됐다.

그래서 C10K Problem은 서버 최적화 역사에서 상징적인 사건이 되었다

지금은 클라우드 서버와 멀티코어 CPU가 워낙 발전해서 1만 연결 자체는 그렇게 특별한 숫자가 아닐 수도 있다. 하지만 당시에는 “대규모 동시 연결 처리” 자체가 엄청난 기술적 도전이었다.

그리고 그 문제를 해결하는 과정에서 현대 서버 구조가 크게 발전하게 되었다.

예를 들어 지금 우리가 사용하는:

  • 실시간 채팅
  • 스트리밍 서비스
  • 대형 게임 서버
  • 웹소켓 기반 서비스

같은 기술들도 결국은 “엄청 많은 연결을 효율적으로 유지하는 방법” 위에서 발전한 구조라고 볼 수 있다.

나도 예전에는 서버 성능이라는 게 그냥 비싼 CPU와 RAM 문제라고만 생각했는데, 실제로는 운영체제 이벤트 처리 구조와 스레드 관리 방식 자체가 훨씬 중요한 시대가 있었다는 걸 알고 꽤 흥미로웠다.

특히 C10K Problem은 단순 장애 사례가 아니라, “왜 현대 서버가 이벤트 기반 구조로 발전했는가”를 보여주는 대표적인 역사적 전환점처럼 느껴졌다.

이걸 공부하면서 가장 인상 깊었던 건 컴퓨터 성능 발전이 단순 하드웨어 스펙 경쟁만은 아니라는 점이었다. 결국 핵심은 얼마나 불필요한 작업을 줄이고, 제한된 자원을 효율적으로 활용할 수 있느냐에 가까웠다.

한 줄로 정리하면 C10K Problem은 서버가 동시에 1만 개 이상의 연결을 효율적으로 처리하기 어려웠던 문제를 의미하며, 현대 이벤트 기반 서버와 Epoll 구조가 발전하는 계기가 된 중요한 서버 역사적 전환점이다.