42 Seoul - 014_webserv | Paul’s Archives

🌐 webserv: 비동기 이벤트 기반 서버 아키텍처의 구현 - HTTP/1.1의 재구성

Inception이 Docker를 통해 여러 서비스를 조립하는 ‘인프라 아키텍트’의 관점을 제공했다면, webserv는 그 인프라의 가장 핵심적인 구성 요소인 웹 서버의 내부를 C++98만으로 직접 설계하고 구현하는 ‘시스템 아키텍트’의 역할을 요구하는 과제이다.

이 프로젝트는 소켓 프로그래밍을 넘어서, 현대 고성능 웹 서버(NGINX 등)가 채택하고 있는 비동기 이벤트 기반(Asynchronous Event-driven) 아키텍처를 직접 구축하는 것을 목표로 한다.

webserv는 사용자의 브라우저에서 출발한 HTTP 요청이라는 순수한 텍스트가 어떻게 서버의 문을 통과하고, 내부 로직을 거쳐 의미 있는 응답으로 변환되어 돌아가는지, 그 보이지 않는 통신의 전 과정을 밑바닥부터 재구성하고 그 이해도를 넓히는 데 핵심적인 역할을 한다.

특히나 마지막 과제와 더불어 최소 3인, 최대 5명이 함께하는 프로젝트인 만큼, 가장 난이도가 있으며, 얼마나 체계적인 계획을 세울줄 알고 협업할 태도가 있는지에 따라 그 결과물의 수준과 성공 여부를 가리는 그런 프로젝트라 할 수 있겠다.

📜 1. 아키텍처 설계: C10K 문제와 이벤트 기반 접근법

전통적인 ‘요청 당 스레드/프로세스 생성’ 모델, 이를 기반한 서버 프로그램들은 수천, 수만 개의 동시 접속(C10K Problem)을 처리하기에 컨텍스트 스위칭 비용과 메모리 사용량 측면에서 한계가 명확하다고 알려져 있다. 그리고 이러한 상황을 놀랍게 해결하고, 현재는 프록시, 혹은 정적 배포를 위해 아주 기초적으로 활용될 정도로 되중화된 케이스가 바로 Nginx다.

그러한 Nginx 는 단일 스레드를 기반으로 동작한다. 물론 현재의 그것은 그럼에도 ‘요청 당 스레드/프로세스 생성’의 이점을 흡수하여 보다 섬세한 프로그램화 되었으나, 그 기본 철학은 여전하고, webserv는 이 철학을 Non-blocking I/O + I/O 멀티플렉싱이란 개념을 기반으로 하는 이벤트 루프(Event Loop) 모델로 모사해낸다.

이 아키텍처는 단일 (또는 소수의) 스레드만으로 수많은 클라이언트의 연결을 효율적으로 처리할 수 있으며, I/O 작업이 진행되는 동안 CPU를 다른 작업에 할당하여 시스템 자원을 극대화한다. 서버의 모든 동작은 시스템 커널에서 제공해주는 ‘이벤트’가 발생했을 때의 시그널에 맞추어 비동기적으로 처리된다.

🛠️ 2. 핵심 구현 요소: 시스템 콜과 프로토콜의 조립

가. 소켓 프로그래밍: 통신의 관문

소켓은 운영체제의 TCP/IP 스택을 제어하기 위한 프로그래밍 인터페이스(API)이다. 서버의 생명주기는 다음 시스템 콜들을 통해 관리된다.

socket(): 통신을 위한 엔드포인트를 생성한다.
fcntl(): 생성된 소켓을 Non-blocking 모드로 설정한다. 이는 accept(), read(), write() 등의 I/O 함수가 데이터가 준비되지 않았을 때 즉시 반환되도록 하여, 이벤트 루프 전체가 멈추는 것을 방지하는 핵심적인 단계이다.
setsockopt(): SO_REUSEADDR 옵션을 통해 서버가 비정상 종료된 후 즉시 재시작해도 동일한 포트를 바인딩할 수 있도록 설정한다.
bind(): 소켓에 특정 IP 주소와 포트 번호를 할당한다.
listen(): 소켓이 클라이언트의 연결 요청을 수신 대기하도록 설정한다.
accept(): 연결 요청 큐에서 새로운 클라이언트 연결을 가져와, 통신을 위한 새로운 소켓(커넥션 소켓)을 생성한다.

나. I/O 멀티플렉싱 (`kqueue`): 이벤트 루프의 심장

본래 I/O 멀티플랙싱을 위한 아주 기본적인 방식은 select 와 poll 을 활용하는 방식의 POSIX 표준 모델이 있다. 특히 poll의 구현은 생각보다 복잡하지 않으며, 오히려 직관적인데, 감시 대상을 배열로 만들고, 이 배열을 주기적으로 스캔하여 측정하는 구조이다.

하지만 이 방식은 선형적 구조이므로, O(N) 의 시간 복잡도 문제를 가지고, 이식성은 좋고, 무엇보다 직관적 장점을 가지나, 현재는 고서능 서버에서 쓰이지 않는다. 이후 리눅스 커널 2.5.44 버전 이후부터는 epoll 이라는 거의 표준화된 라이브러리가 있고, Linux 5.1 커널에서 도입된 가장 고성능 비동기 I/O 인터페이스는 io_uring 이 존재한다.

이러한 리눅스 커널에 따른 버전과 유사하게 FreeBSD 계열 OS에서 epoll과 비슷하게 사용되는 것이 바로 kqueue 이다. 참고로 FreeBSD 기반의 OS 의 사용은 매우 흔한 일은 아니기에 익숙하지 않을 수 있으나, 소스 코드를 사용하고도, 소스 공개를 하지 않아도 되는 라이센스 덕분에 기업용 OS 플랫폼에 FreeBSD가 많이 쓰인다고 한다(Mac OS, iOS, Sony PS 계열, Nintendo의 Switch OS 등…)

kqueue는 소수의 스레드로 다수의 I/O 이벤트를 효율적으로 관리하기 위한 BSD 계열 운영체제의 고성능 API이다. 특징을 그래도 다소 요약해보면 다음과 같다.

이벤트 기반의 동작 원리: 서버는 kqueue()로 커널에 새로운 이벤트 큐를 생성한다. 이후 kevent() 함수를 사용하여 감시하고자 하는 이벤트(예: ‘서버 소켓에 새로운 연결 요청이 도착함’, ‘커넥션 소켓에서 읽을 데이터가 있음’)를 큐에 등록(Register)한다.
이벤트 루프: 서버의 메인 로직은 무한 루프 내에서 kevent()를 호출하여 대기하는 것이다. kevent()는 등록된 이벤트 중 하나라도 발생할 때까지 프로세스를 대기시키며, 이벤트 발생 시 발생한 이벤트 목록을 반환한다. 루프는 반환된 이벤트들을 순회하며 각각에 맞는 핸들러(새 연결 수락, 데이터 수신 등)를 호출하여 처리한다. 이 구조 덕분에 서버는 실제 작업이 필요할 때만 깨어나 동작하게 된다.
높은 성능과 확장성: 감시해야할 대상이 늘어나도, 성능 저하는 거의 없다.
다양한 이벤트 통합 관리: 개인적으로 가장 훌륭한 장점이라고 생각되는 부분으로 단순 소켓의 읽기, 쓰기 가능 상태 뿐 아니라 시그널, 파일 변경 여부, 프로세스 상태 변화나 타이머 등 다양한 시스템 레벨의 이벤트를 발생시키거나, 감지 가능하고 이를 단일 인터페이스에서 통합관리가 된다는 점은 매우 유의미하다.

다. 설정 파일 파서: 유연성과 가상 호스팅

nginx.conf와 유사한 형식의 설정 파일을 해석하는 파서를 구현해야 한다. 이 파서는 서버의 동작을 코드 변경 없이 제어할 수 있는 유연성을 제공한다.

핵심 기능: 포트 바인딩, 서버 이름 지정, 기본 에러 페이지 경로, 허용 HTTP 메서드, location 블록별 라우팅 규칙(루트 디렉토리, CGI 설정 등)을 파싱하여 C++ 객체(예: ServerConfig)로 구조화한다.
가상 호스팅 (Virtual Hosting): 파싱된 설정을 기반으로, 서버는 HTTP 요청 헤더의 Host 필드를 확인하여 동일한 IP와 포트로 들어온 요청이라도 각각 다른 server 블록 설정에 따라 다른 웹사이트를 서빙할 수 있어야 한다. 이는 내부적으로 추상화 될 뿐 실질 단일 처리긴 하다.

라. HTTP/1.1 프로토콜 파서 및 응답 생성기

요청(Request) 파싱: 클라이언트 소켓으로부터 읽어들인 순수한 바이트 스트림을 HTTP/1.1 명세에 따라 파싱한다. REST 원칙에 따라 HTTP/1.1 의 개념들을 분석하여 파서를 구축한다. 첫 줄인 Start-Line에서 Method (GET, POST, DELETE), Request-URI, HTTP-Version을 추출하고, 이후 빈 줄(\r\n\r\n)이 나올 때까지 헤더들을 파싱하여 map과 같은 자료구조에 저장한다. Content-Length가 명시된 POST 요청의 경우, 명시된 길이만큼의 Body 데이터를 수신해야 한다.
응답(Response) 생성: 파싱된 요청을 처리한 후, 서버는 다시 명세에 맞춰 응답 메시지를 생성한다. Status-Line(HTTP/1.1 200 OK), Headers(Content-Type, Content-Length 등), 그리고 Body(HTML 파일 내용 등)를 조합하여 클라이언트 소켓에 전송한다.
부차 적인 요소들: chunk 단위로 다운로드가 필요한 케이스 등을 고려하여, 큰 데이터들이 들어올 때는 이에 맞춰 지속적으로 데이터를 받고, 이를 합쳐서 제공하거나 수신하는 등의 HTTP /1.1 기준에 맞춘 기능들을 구현해야한다.

마. CGI (Common Gateway Interface): 동적 콘텐츠 생성

CGI는 웹 서버가 외부 스크립트(Python, PHP 등)를 실행시켜 동적인 콘텐츠를 생성하기 위한 표준 프로토콜이다. 필요시 되는 이유는 웹 서버가 수행하기에는 연산 집약적이거나, 특수한 목적성을 가지는 경우 신규 프로세스로 구현하는 구조를 가진다. 물론, 현재는 이러한 기능들을 다양한 방식으로 구현이 가능하며, CGI 라는 기준으로 구현 방식은 ‘올드’ 하고 ‘무겁다’ 고 이야기 되기도 한다.

구현: fork()로 자식 프로세스를 생성한 후, pipe()로 부모-자식 간 통신 채널을 만든다. 부모 프로세스(서버)는 HTTP 요청 정보를 환경 변수(REQUEST_METHOD, QUERY_STRING 등)로 설정하고, POST 요청의 경우 Body 데이터를 자식 프로세스의 stdin으로 파이프를 통해 전달한다. 자식 프로세스는 dup2()로 자신의 표준 입출력을 파이프에 연결한 뒤, execve()로 CGI 스크립트를 실행한다. 스크립트의 실행 결과(표준 출력)는 다시 파이프를 통해 부모 프로세스로 전달되어, 최종 HTTP 응답의 Body로 클라이언트에게 전송된다.

바. 협업 도구들 및 전략

해당 과제에서는 가장 어려웠던 영역이 바로, 서로의 kqueue 에 대한 이해도가 다르다는 점, 그리고 그런 상태에서 에러 핸들링을 어떻게 해야할지 쉽게 접근하기 어려웠다는 점이다. 설계를 하더라도 구조를 정확하기 인지하지 못하고, 특히나 소통 문제를 포함하여 여러 이슈들이 생겨났다.

이러한 점을 고려하지 못한 1차 개발 팀은 상당한 곤란, 어려움에 있었고 결과적으로 실패하고 팀이 와해되었었다.

이후 이를 어떻게 개선하면 되는가? 진지한 고민을 이어갔다. 그렇게 했던 노력과 보안책은 다음과 같다.

kqueue 지식에 대한 공유: kqueue 를 이해하는 과정은 매우 어려운데다, 이러한 구조를 모두 비슷하게 공유한 다는 것은 어려웠지만, 이후 학습을 통해 kqueue 를 이용한 echo 서버 구축, 멀티 채널, 멀티 유저 기반의 echo 서버를 구현하는 것을 미리 해보면서 기능에 대한 이해도를 얻을 수 있었다. 이러한 점을 고려하여 모두가 클론 코딩을 통해 이해하기 쉽도록 유도하였다.
다형성을 갖춘 통합 작업 체계 고안: C++ 의 다형성, 상속을 활용하고, 결국 논블록킹 비동기 구조를 기반으로 각 역할(클라이언트, 요청 읽기, 파일 읽기, CGI, 프로세스 종료 등)에 따라 하위 작업을 수행하는 하부 클래스들을 만들었다. 이 클래스들은 동일한 메서드를 오버로딩하므로, 메서드들의 역할은 규격화하고, 그 상황을 유도하여 쳬계의 동질성을 높여서, 개발자들 사이의 논의가 용이할 수 있게 구현되었다.
자체적인 로깅 시스템 구현: 비동기, 이벤트 기반의 가장 어려운 지점은 디버깅 시, 어떤 시점에 어떤 일들이 문제가 발생하는지 모른다는 점이였다. 이에, 작업에 대한 상위 클래스, 하부 클래스들로 만들었다는 것을 활용하여 로깅을 수행하는 클래스까지 포함하여, 언제 어떤 작업 도중에 에러가 난 것인지를 볼 수 있는 기능을 미리 간단하게 구현하여 제공하였다.
심플하지만 명확한 컨벤션 지정: 복잡하고 어려운 컨벤션을 지정하는 식으로는, 이를 지키다 효율성이 사라지는 문제가 있었다. 이에 심플하게 컨벤션을 미리 합의하도록 유도하였고, PR 시에도 지정된 리뷰 방식을 수행만 하면 문제 없다는 식으로 합의를 통해, 팀 전체가 복잡하지 않지만, 강력한 기준 하에 PR 을 수행하고, 코드 리뷰를 하는 등의 형태를 이어 나가도록 만들었다.

이러한 내용들을 통해 최초 팀에서 생겼던 문제들은 극적으로 완화 되었고, 기존의 두달의 시간이 걸려 작업이 진행조차 되지 않던 상황에서, 2차 팀은 몇 주만에 얼개가 짜여졌고, 1달 정도로 거의 완성 단계까지 개발을 마무리 할 수 있었다.

✨ 성찰 및 배운 점

webserv는 인터넷의 근간을 이루는 클라이언트-서버 모델과 HTTP 통신의 실체를 코드로 증명해내는 과정이다. 또한 이만큼의 구조를 팀으로 해나가는 것을 경험하면서 소통과 어떤 체계를 구축하여 함께 해나가냐에 따라 얼마나 차이가 나는지를 알 수 있었다.

시스템 아키텍처의 이해: 고성능 서버가 왜 비동기 이벤트 기반으로 설계되어야 하는지에 대한 깊은 공학적 이해를 얻었다. 이는 단순한 코딩을 넘어 시스템 전체의 성능과 확장성을 고려하는 아키텍트의 시각을 길러주었다.
프로토콜의 중요성: HTTP와 CGI라는 엄격한 ‘약속(Protocol)’ 위에서 브라우저와 서버, 서버와 외부 프로그램이 어떻게 질서정연하게 상호작용하는지를 체감했다. 모든 현대 기술은 잘 정의된 프로토콜 위에 서 있음을 깨달았다.
저수준 제어의 힘: C++와 시스템 콜만으로 네트워크 스택의 애플리케이션 계층을 직접 제어하는 경험은, 프레임워크 뒤에 숨겨진 원리를 이해하고 문제의 근본 원인을 진단할 수 있는 강력한 무기가 되었다.
협업의 중요성, 방식의 이해: 협업 과정에서 컨벤션은 명확해야하며, 특히나 조심해야 할 것은 커뮤니케이션을 방해하는 지식의 수준, 소통 방식의 부재 등이 얼마나 팀 개발에서 문제를 야기할 수 있는지를 알 수 있었다.

webserv를 완성했다는 것은, 브라우저의 URL 입력창 뒤에서 벌어지는 거대한 통신의 오케스트라를 직접 지휘할 수 있는 역량을 갖추었음을 의미하는, 개발자로서의 중요한 이정표였다. 동시에 비록 실전, 실제 라이브 서버를 개발해보거나 하는 것은 아니었지만, 그럼에도 매우 훌륭한 협업의 경험이자, 아프지만 성장 가능성을 다시 한 번 맛 볼 수 있던 기회라 할 수 있겠다.