Caddy 설정 그대로 쓰면서 처리량 3배? 새 웹서버 zeroserve 이야기

웹서버 갈아타기의 가장 큰 장벽

웹서버를 더 빠른 걸로 바꾸고 싶어도 쉽게 못 바꾸는 이유가 있어요. 바로 설정 파일이거든요. 지금까지 쌓아온 라우팅 규칙, 리버스 프록시 설정, TLS 인증서 관리를 새 서버 문법으로 전부 다시 짜야 한다고 생각하면 엄두가 안 나죠. 그런데 zeroserve라는 프로젝트가 「Caddy 설정을 그대로 읽을 수 있게 만들었고, 성능은 처리량 3배에 지연시간 70% 감소」라는 결과를 들고 나왔어요. 무슨 의미인지 풀어볼게요.

먼저 Caddy를 모르는 분들을 위해 설명하면, Caddy는 Go로 만든 웹서버인데 가장 큰 매력이 자동 HTTPS예요. 별다른 설정 없이도 Let's Encrypt에서 인증서를 자동으로 받아오고 갱신까지 해줘서, 복잡하기로 악명 높은 Nginx의 TLS 설정에 질린 사람들에게 인기가 많거든요. 설정 파일(Caddyfile)도 사람이 읽기 쉽게 간단하고요.

‘호환’이 왜 중요한 전략인가

zeroserve의 핵심 전략은 바로 이 Caddyfile을 그대로 알아듣게 만든 거예요. 이게 왜 영리하냐면, 사용자 입장에서 마이그레이션 비용이 거의 0에 가까워지거든요. 기존 Caddy 쓰던 사람이 설정은 한 글자도 안 고치고 실행 파일만 바꿔 끼우면 성능이 올라가는 그림이에요. 새 기술이 아무리 빨라도 갈아타는 게 귀찮으면 안 쓰는데, 그 장벽을 없앤 거죠.

성능 수치는 처리량(throughput, 초당 처리하는 요청 수) 3배, 지연시간(latency, 요청 하나가 처리되는 데 걸리는 시간) 70% 감소라고 밝히고 있어요. 다만 이건 프로젝트 측이 자체 벤치마크로 낸 수치라서, 내 환경에서도 똑같이 나온다고 보장할 순 없어요. 벤치마크라는 게 정적 파일 서빙이냐, 동적 프록시냐, 동시 접속 수가 얼마냐에 따라 결과가 크게 갈리거든요. 그래서 이런 수치를 볼 때는 「어떤 조건에서 측정했나」를 꼭 확인하는 습관이 중요해요.

이런 성능 차이는 어디서 올까

일반적으로 웹서버 성능 차이는 몇 군데에서 갈려요. 우선 요청을 처리하는 동시성 모델이에요. 운영체제의 비동기 I/O(논블로킹 입출력)를 얼마나 효율적으로 쓰는지, 스레드와 이벤트 루프를 어떻게 굴리는지에 따라 같은 하드웨어에서도 처리량이 크게 달라져요. 또 메모리 할당을 얼마나 아끼는지, 가비지 컬렉션(GC, 자동 메모리 회수)이 지연시간을 얼마나 튀게 하는지도 영향을 줘요. Go 기반인 Caddy는 GC 때문에 가끔 지연시간이 튀는 특성이 있는데, 만약 zeroserve가 GC 부담이 적은 구조라면 지연시간 개선이 어느 정도 설명이 되긴 해요.

업계 맥락

웹서버 판은 생각보다 경쟁이 치열해요. 전통의 강자 Nginx, 자동 HTTPS의 Caddy, 컨테이너·쿠버네티스 환경에서 강한 Traefik, 그리고 고성능 로드밸런서 HAProxy가 각자 영역을 갖고 있어요. 여기에 Rust로 만든 차세대 서버들도 속속 등장하는 중이고요. zeroserve처럼 「기존 강자의 설정을 그대로 받아주면서 성능으로 승부한다」는 전략은, 바닥부터 새로 배우게 하는 것보다 훨씬 현실적인 침투 방식이에요. 과거 MariaDB가 MySQL과 호환성을 유지하면서 갈아타기 쉽게 만든 것과 비슷한 그림이죠.

한국 개발자에게

당장 운영 서버를 갈아타라는 얘기는 아니에요. 신생 프로젝트는 안정성과 커뮤니티, 자료가 검증되기 전이라 리스크가 있거든요. 다만 사이드 프로젝트나 개인 서버에서 한번 테스트 삼아 돌려보고, 직접 벤치마크를 떠보는 건 충분히 의미 있어요. 그 과정에서 「내 서비스의 병목이 진짜 웹서버인가, 아니면 애플리케이션이나 DB인가」를 따져보게 되는데, 그 고민 자체가 성능 감각을 길러줘요. 호환성을 무기로 삼는 전략도 제품 만드는 사람이라면 배울 만하고요.

핵심 한 줄: 빠른 것보다 ‘갈아타기 쉬운 빠른 것’이 이긴다. 여러분은 새 인프라 도구를 고를 때 성능과 안정성 중 무엇을 더 보시나요?