<div id="readability-page-1" class="page"><article id="post-trend-c10k" class="page" role="article"><header><p> C10K 문제에 대해 이야기해보고자 한다.</p></header><hr><ul id="markdown-toc"><li><a href="#1-서론" id="markdown-toc-1-서론">1. 서론</a><ul><li><a href="#11-1만명이-접속하는-서버-만들기-도전" id="markdown-toc-11-1만명이-접속하는-서버-만들기-도전">1.1. “1만명이 접속하는 서버 만들기” 도전</a></li><li><a href="#12-dan-kegel의-1999년-도전과-시대적-배경" id="markdown-toc-12-dan-kegel의-1999년-도전과-시대적-배경">1.2. Dan Kegel의 1999년 도전과 시대적 배경</a></li><li><a href="#13-왜-동시-연결-수가-웹-서버-설계에-중요한가" id="markdown-toc-13-왜-동시-연결-수가-웹-서버-설계에-중요한가">1.3. 왜 동시 연결 수가 웹 서버 설계에 중요한가?</a></li></ul></li><li><a href="#2-전통적인-서버-모델과-그-한계" id="markdown-toc-2-전통적인-서버-모델과-그-한계">2. 전통적인 서버 모델과 그 한계</a><ul><li><a href="#21-프로세스-기반-모델의-작동-방식" id="markdown-toc-21-프로세스-기반-모델의-작동-방식">2.1. 프로세스 기반 모델의 작동 방식</a><ul><li><a href="#211-fork와-파일-핸들러-제한-ulimit" id="markdown-toc-211-fork와-파일-핸들러-제한-ulimit">2.1.1. fork()와 파일 핸들러 제한 (ulimit)</a></li></ul></li></ul></li></ul><h2 id="1-서론">1. 서론</h2><h3 id="11-1만명이-접속하는-서버-만들기-도전">1.1. “1만명이 접속하는 서버 만들기” 도전</h3><p>필자는 오늘 웹 서버 기술 발전의 중요한 전환점이 된 ‘C10K 문제’에 대해 이야기해보고자 한다. C10K 문제란 간단히 말해 “하나의 서버에서 동시에 1만 명의 클라이언트(Concurrent 10K) 연결을 처리할 수 있는가?”라는 도전과제이다.</p><p>1999년, 이 문제가 처음 업계에 제기되었을 때는 상당히 도전적인 과제였다고 한다. 당시 웹 서버는 수백 명의 동시 사용자를 처리하는 것도 어려웠으며(실제로 이런 케이스가 흔치 않았을지도 모른다), 천 명이 넘는 접속자를 처리하는 것은 엄청난 도전이었다고 한다.</p><h3 id="12-dan-kegel의-1999년-도전과-시대적-배경">1.2. Dan Kegel의 1999년 도전과 시대적 배경</h3><p>C10K 문제는 1999년 Dan Kegel이라는 개발자가 웹사이트에 게시한 글에서 시작되었다. 그는 <a href="https://web.archive.org/web/19990508164301/http://www.kegel.com/c10k.html">“C10K Problem”</a>이라는 제목의 문서에서 당시 서버 기술의 한계와 이를 극복하기 위한 방안을 논의했다.</p><p>당시 인터넷은 폭발적으로 성장하는 단계였다. 1990년대 후반은 닷컴 붐<sup id="fnref:1" role="doc-noteref"><a href="#fn:1" rel="footnote">1</a></sup>의 시대로, 인터넷 사용자가 급증하면서 웹사이트들은 점점 더 많은 동시 접속자를 처리해야 했다. 하지만 서버 기술은 아직 이러한 요구를 효과적으로 충족시키지 못했다.</p><p>1990년대 후반 서버 환경은 오늘날과 비교하면 매우 제한적이었다.</p><ul><li>CPU: 대부분 단일 코어, 클럭 속도는 수백 MHz 정도</li><li>메모리: 수백 MB 정도가 일반적</li><li>네트워크: 100Mbps가 고속으로 간주되던 시대</li><li>운영체제: 동시성 처리에 최적화되지 않은 커널</li></ul><p>이러한 환경에서 1만 개의 동시 연결을 처리하는 것은 단순한 기술적 최적화가 아닌 근본적인 패러다임 전환을 필요로 하였다.</p><h3 id="13-왜-동시-연결-수가-웹-서버-설계에-중요한가">1.3. 왜 동시 연결 수가 웹 서버 설계에 중요한가?</h3><p>동시 연결 수는 웹 서버 성능의 핵심 지표 중 하나다. 특히 아래와 같은 상황에서 중요하다.</p><ol><li>대규모 웹사이트: 수많은 사용자가 동시에 접속하는 인기 있는 웹사이트 (네이버, 구글 등)</li><li>실시간 애플리케이션: 채팅, 게임, 스트리밍 등 지속적인 연결이 필요한 서비스 (카카오톡 등)</li><li>API 서버: 수많은 클라이언트와 연결을 유지해야 하는 백엔드 서비스</li></ol><p>동시 연결 수의 한계는 서비스 확장성을 직접적으로 제약한다. 사용자 경험, 서버 비용, 시스템 안정성 모두 서버의 동시 연결 처리 능력에 의존한다.</p><p>C10K 문제의 해결은 단순히 기술적 호기심을 넘어, 현대 인터넷 서비스의 기반을 마련하는 중요한 과제였다.</p><h2 id="2-전통적인-서버-모델과-그-한계">2. 전통적인 서버 모델과 그 한계</h2><h3 id="21-프로세스-기반-모델의-작동-방식">2.1. 프로세스 기반 모델의 작동 방식</h3><p>C10K 문제를 이해하려면 먼저 전통적인 서버 모델을 살펴봐야 한다. 초기 웹 서버는 주로 프로세스 기반 모델을 사용했다.</p><h4 id="211-fork와-파일-핸들러-제한-ulimit">2.1.1. fork()와 파일 핸들러 제한 (ulimit)</h4><p>프로세스 기반 모델에서 서버는 다음과 같은 패턴으로 동작한다:</p><div><pre><code>서버 시작
  -&gt; socket() 생성
  -&gt; bind()로 IP 주소와 포트 연결
  -&gt; listen()으로 연결 대기
  -&gt; 무한 루프:
       -&gt; accept()로 새 연결 수락
       -&gt; fork()로 새 프로세스 생성
       -&gt; 자식 프로세스가 클라이언트 요청 처리
</code></pre></div></article><div role="contentinfo"><hr><p><small>© 2021. All rights reserved. </small></p><nav><small> <a href="/LICENSE/">LICENSE</a> | <a href="/NOTICE/">NOTICE</a> | <a href="/CHANGELOG/">CHANGELOG</a> </small></nav><p><small>Powered by <a href="https://hydejack.com/">Hydejack</a> v<span id="_version">9.2.1</span></small></p><hr></div></div>

개발자 이진우

Jinwoo Lee

1. 서론    
1.1. “1만명이 접속하는 서버 만들기” 도전
1.2. Dan Kegel의 1999년 도전과 시대적 배경
1.3. 왜 동시 연결 수가 웹 서버 설계에 중요한가?
2. 전통적인 서버 모델과 그 한계    
2.1. 프로세스 기반 모델의 작동 방식        
2.1.1. fork()와 파일 핸들러 제한 (ulimit)
1. 서론
1.1. “1만명이 접속하는 서버 만들기” 도전
필자는 오늘 웹 서버 기술 발전의 중요한 전환점이 된 ‘C10K 문제’에 대해 이야기해보고자 한다. C10K 문제란 간단히 말해 “하나의 서버에서 동시에 1만 명의 클라이언트(Concurrent 10K) 연결을 처리할 수 있는가?”라는 도전과제이다.
1999년, 이 문제가 처음 업계에 제기되었을 때는 상당히 도전적인 과제였다고 한다. 당시 웹 서버는 수백 명의 동시 사용자를 처리하는 것도 어려웠으며(실제로 이런 케이스가 흔치 않았을지도 모른다), 천 명이 넘는 접속자를 처리하는 것은 엄청난 도전이었다고 한다.
1.2. Dan Kegel의 1999년 도전과 시대적 배경
C10K 문제는 1999년 Dan Kegel이라는 개발자가 웹사이트에 게시한 글에서 시작되었다. 그는 “C10K Problem”이라는 제목의 문서에서 당시 서버 기술의 한계와 이를 극복하기 위한 방안을 논의했다.
당시 인터넷은 폭발적으로 성장하는 단계였다. 1990년대 후반은 닷컴 붐1의 시대로, 인터넷 사용자가 급증하면서 웹사이트들은 점점 더 많은 동시 접속자를 처리해야 했다. 하지만 서버 기술은 아직 이러한 요구를 효과적으로 충족시키지 못했다.
1990년대 후반 서버 환경은 오늘날과 비교하면 매우 제한적이었다.
CPU: 대부분 단일 코어, 클럭 속도는 수백 MHz 정도
메모리: 수백 MB 정도가 일반적
네트워크: 100Mbps가 고속으로 간주되던 시대
운영체제: 동시성 처리에 최적화되지 않은 커널
이러한 환경에서 1만 개의 동시 연결을 처리하는 것은 단순한 기술적 최적화가 아닌 근본적인 패러다임 전환을 필요로 하였다.
1.3. 왜 동시 연결 수가 웹 서버 설계에 중요한가?
동시 연결 수는 웹 서버 성능의 핵심 지표 중 하나다. 특히 아래와 같은 상황에서 중요하다.
대규모 웹사이트: 수많은 사용자가 동시에 접속하는 인기 있는 웹사이트 (네이버, 구글 등)
실시간 애플리케이션: 채팅, 게임, 스트리밍 등 지속적인 연결이 필요한 서비스 (카카오톡 등)
API 서버: 수많은 클라이언트와 연결을 유지해야 하는 백엔드 서비스
동시 연결 수의 한계는 서비스 확장성을 직접적으로 제약한다. 사용자 경험, 서버 비용, 시스템 안정성 모두 서버의 동시 연결 처리 능력에 의존한다.
C10K 문제의 해결은 단순히 기술적 호기심을 넘어, 현대 인터넷 서비스의 기반을 마련하는 중요한 과제였다.
2. 전통적인 서버 모델과 그 한계
2.1. 프로세스 기반 모델의 작동 방식
C10K 문제를 이해하려면 먼저 전통적인 서버 모델을 살펴봐야 한다. 초기 웹 서버는 주로 프로세스 기반 모델을 사용했다.
2.1.1. fork()와 파일 핸들러 제한 (ulimit)
프로세스 기반 모델에서 서버는 다음과 같은 패턴으로 동작한다:
서버 시작
  -> socket() 생성
  -> bind()로 IP 주소와 포트 연결
  -> listen()으로 연결 대기
  -> 무한 루프:
       -> accept()로 새 연결 수락
       -> fork()로 새 프로세스 생성
       -> 자식 프로세스가 클라이언트 요청 처리
1990년대 후반에 인터넷과 관련 기업들이 급격하게 성장하면서 투자 열풍이 불었던 현상, 웹사이트 주소가 “.com”으로 끝나는 회사를 중심으로 수많은 스타트업과 IT 기업들이 등장하였음 ↩︎

C10K 및 C10M 문제

댓글