Nginx냐 Caddy냐…2코어 속도와 자동 HTTPS가 선택을 가른다

새 서비스를 배포하면서 인증서 관리를 줄이고 싶다면 Caddy가 편하다. 작은 정적 파일을 대량으로 제공하거나 같은 부하에서 CPU 사용량과 느린 요청의 지연을 낮춰야 한다면 Nginx가 더 유리하다. 리버스 프록시의 성능과 실패율은 어느 제품을 고르느냐뿐 아니라 백엔드 연결을 어떻게 재사용하느냐에도 달려 있다.

2026년 10월 5일 공개된 동일 장비의 2코어 측정에서는 1KB HTTPS 파일의 성공 요청이 Nginx 초당 79,169건, Caddy 29,449건이었고, 매 요청에 새 TLS 연결을 만드는 시험은 각각 3,531건과 4,274건이었으며, 초당 5,000건의 고정 부하에서 백엔드 연결을 재사용한 Nginx와 기본 Caddy 구성의 p99 지연은 각각 0.68ms와 2.52ms였다. 앞선 수치는 정적 파일 전송, 새 연결 수립, 프록시 응답 시간을 서로 다른 작업으로 봐야 하는 이유를 보여준다.

같은 장비에서도 작업에 따라 속도가 달랐다

작은 정적 파일을 기존 HTTPS 연결로 계속 보내는 작업에서는 Nginx의 처리량 우위가 뚜렷했다. 파일이 커진 시험에서는 두 제품의 차이가 좁아졌다. 따라서 파일을 주로 제공하는 서비스라도 응답 크기를 빼고 최고 요청 수만 비교하면 필요한 서버 용량을 잘못 가늠할 수 있다.

새 TLS 연결을 반복해서 만드는 작업은 다른 결과를 냈다. 이 시험에서 Caddy가 앞섰다는 사실은 인증서 자동 발급이 더 빠르다는 뜻이 아니다. 핸드셰이크는 클라이언트와 서버가 연결을 맺는 과정이고, 인증서 발급과 갱신은 그 연결에 사용할 자격 증명을 관리하는 과정이다. 방문자가 연결을 오래 유지하는지에 따라 어느 측정이 실제 트래픽에 가까운지도 달라진다.

고정된 요청 속도에서 본 p99는 최대 처리량과 또 다른 질문에 답한다. 대다수 요청이 빨라도 일부 요청이 늦어지면 지연에 민감한 서비스의 체감은 달라진다. 측정에서는 백엔드 연결을 재사용한 Nginx의 꼬리 지연과 CPU 사용량이 더 낮았지만, Caddy의 p99는 실행 사이에 흔들렸다. 한 번의 수치를 어느 배포 환경에나 적용할 수 없는 이유다.

유휴 상태와 시험 중 최고 메모리 사용량도 Nginx 쪽이 낮았다. 다만 해당 수치는 컨테이너의 페이지 캐시를 포함한다. 메모리가 제한된 장비에서는 참고할 만하지만, 실제 배포에서는 애플리케이션과 캐시가 함께 차지하는 용량이 더 큰 판단 요소일 수 있다. 서버 프로그램의 메모리 차이만으로 전체 서비스의 비용 차이를 계산해서는 안 된다.

시험에는 한 대의 노트북이 쓰였고, 서버에는 물리 코어 두 개가 배정됐다. 부하 생성기와 프록시 백엔드는 별도 코어를 사용했지만 운영체제의 네트워크 경로와 메모리는 공유했다. Docker 브리지 네트워크에서 HTTP/1.1로 측정했고 압축과 접근 로그를 껐다. 실제 네트워크 카드, 다른 프로토콜, 기본 로그 설정이 더해진 배포의 성능 순위까지 확정하는 결과는 아니다.

Caddy의 자동 HTTPS는 어떤 운영을 줄이나

Caddy 자동 HTTPS 문서에 따르면 조건에 맞는 공개 도메인은 인증서를 자동으로 발급·갱신하고 HTTP 요청을 HTTPS로 전환한다. 사이트를 추가할 때마다 인증서 파일 경로와 별도의 갱신 절차를 연결하는 일을 줄일 수 있다. 트래픽이 크지 않은 개인 서비스나 여러 도메인을 운영하는 작은 배포에서 이 편의가 선택의 핵심이 된다.

자동화가 작동하려면 도메인의 DNS가 서버를 가리키고 인증서 발급에 필요한 포트에 외부에서 접근할 수 있어야 한다. Caddy가 사용할 포트에 바인딩할 수 있어야 하며, 인증서가 보관되는 데이터 디렉터리는 쓰기 가능하고 지속적으로 유지돼야 한다. 설정에 도메인 이름을 넣어도 이러한 네트워크와 저장소 조건이 저절로 충족되지는 않는다.

로컬 호스트나 내부 이름에도 HTTPS를 사용할 수 있지만 공개 도메인과 신뢰 방식이 다르다. Caddy는 내부 용도의 자체 인증 기관으로 인증서를 만들 수 있으며, 접속하는 기기가 그 기관의 루트 인증서를 신뢰하지 않으면 보안 경고가 나타날 수 있다. 내부 서비스에서 HTTPS가 켜졌다는 사실만으로 모든 외부 사용자가 경고 없이 접속할 수 있다고 가정하면 안 된다.

설정에 호스트 이름이 없거나 HTTP 주소를 명시하거나 인증서를 직접 불러오면 자동 HTTPS의 활성화 방식도 달라진다. 앞의 성능 시험은 두 서버에 같은 자체 서명 인증서를 지정하고 Caddy의 자동 HTTPS를 꺼둔 상태로 진행됐다. 그 결과는 요청 처리 성능을 비교하는 데 쓰이고, 운영 중 인증서 발급·갱신에 드는 노력은 별도로 판단해야 한다.

리버스 프록시는 백엔드 연결이 성패를 바꾼다

리버스 프록시에는 클라이언트에서 프록시까지의 연결과 프록시에서 애플리케이션까지의 연결이 있다. 클라이언트 쪽 TLS 연결을 유지하더라도 프록시가 요청마다 백엔드와 새 TCP 연결을 만들면 그 비용은 남는다. 짧은 시험에서 처리량이 높았던 설정도 지속 부하에서는 연결 종료 후 남는 소켓 때문에 실패 응답을 낼 수 있다.

측정에서 백엔드 주소를 직접 가리킨 Nginx의 proxy_pass 구성은 연결을 재사용하지 못했다. 같은 백엔드를 upstream으로 정의한 구성에서는 재사용이 작동했고, 지속 부하 시험의 실패 응답이 사라지며 처리량이 크게 올랐다. 이는 그 시험의 Nginx 버전과 설정에서 나온 결과다. 모든 Nginx 프록시가 기본적으로 실패한다는 뜻으로 읽으면 설정 차이라는 핵심을 놓친다.

Caddy는 기본 reverse_proxy에서도 백엔드 연결을 재사용한다. 다만 Caddy reverse_proxy 문서는 백엔드 호스트마다 보관할 유휴 연결의 기본 상한을 32개로 설명한다. 지속적인 동시 요청이 그 풀을 압박하면 연결을 반복해서 닫고 다시 여는 일이 늘 수 있다. 측정에서는 풀을 늘린 구성이 기본 구성보다 더 많은 성공 요청을 처리하고 실패 응답도 없앴다.

유휴 연결 수를 무조건 키우는 것도 해법은 아니다. 같은 문서가 설명하듯 프록시의 연결 유지 시간이 백엔드 서버의 제한보다 길면 재사용하려던 연결이 이미 닫혀 요청이 실패할 수 있다. 백엔드가 허용하는 연결 시간과 실제 동시 요청을 함께 고려해야 한다. 여기서 다루는 풀은 애플리케이션으로 향하는 연결이며, 방문자와 프록시 사이의 TLS 세션 재사용과는 별개다.

Nginx는 버전에 따라 upstream의 기본 연결 유지 동작이 다르다. 최신 동작을 기대하며 오래된 배포판의 설정을 그대로 두면 백엔드와 통신하는 HTTP 버전이나 Connection 헤더 때문에 재사용이 되지 않을 수 있다. 반대로 연결 유지가 기본인 버전이라도 시험처럼 백엔드를 직접 지정한 경로에서는 기대한 결과가 나오지 않았다. 기존 Nginx 운영자는 제품을 교체하기 전에 실제 proxy_pass 경로와 upstream 구성을 구분할 필요가 있다.

Nginx의 인증서 설정과 자동화 범위

Nginx HTTPS 설정 문서는 HTTPS 수신 설정에 서버 인증서와 개인키의 경로를 지정하는 방식을 안내한다. 같은 문서는 클라이언트 연결을 유지하고 TLS 세션 매개변수를 재사용하면 반복적인 핸드셰이크 부담을 줄일 수 있다고 설명한다. 인증서를 어디에 두는지와 연결 비용을 어떻게 낮추는지는 설정에서 서로 다른 항목이다.

Nginx에서 인증서 자동화가 불가능한 것은 아니다. Nginx ACME 모듈 문서는 자동 인증서 관리를 구현하는 별도 모듈과 패키지, 발급 기관과 상태 저장 경로를 지정하는 구성을 설명한다. 따라서 비교할 대상은 단순히 ‘수동 Nginx’와 ‘자동 Caddy’가 아니라, 기본 HTTPS 설정으로 운영하는 Nginx와 추가 자동화 구성을 마련한 Nginx까지 포함한다.

이미 조직 안에 인증서 발급과 갱신 절차가 있다면 Nginx에 파일을 제공하는 방식이 큰 부담이 아닐 수 있다. 처음 서비스를 공개하는 운영자라면 자동화 모듈의 설치와 발급 기관 설정, 상태 저장, 갱신 결과를 살피는 일까지 고려해야 한다. Caddy의 기본 자동화가 절약하는 시간은 서버가 처리하는 요청 수보다 이런 운영 조건에 좌우된다.

TLS 세션 캐시와 클라이언트 연결 유지 역시 백엔드 연결 풀을 대신하지 않는다. 앞쪽 연결을 재사용하면 새 핸드셰이크를 줄일 수 있고, 뒤쪽 연결을 재사용하면 프록시가 애플리케이션에 반복해서 접속하는 비용을 줄인다. 어느 구간이 병목인지에 따라 같은 설정 변경도 다른 결과를 낸다. 처리량 수치와 인증서 운영의 편의를 하나의 성능 점수로 합치기 어려운 이유다.

배포 조건에 맞춘 선택

트래픽이 적은 개인 서비스나 소규모 웹 앱을 처음 공개한다면 Caddy가 합리적인 출발점이다. 공개 도메인의 인증서 수명 주기와 HTTPS 전환을 서버가 맡아 주기 때문이다. 서비스가 늘어도 DNS, 외부 접근, 영속 저장소라는 조건은 유지돼야 한다. 이 경우 높은 최대 처리량보다 인증서 운영에 드는 반복 작업이 더 직접적인 비용이다.

작은 정적 응답이 많고 코어당 처리량이나 지연의 긴 꼬리가 중요한 서비스라면 Nginx 쪽 근거가 강하다. 다만 측정에서 좋은 결과를 낸 프록시는 백엔드 연결을 재사용하는 구성이었다. 직접 지정한 백엔드 주소를 그대로 둔 채 서버 이름만 바꾸거나 최대 요청 수만 인용하면 실패율을 좌우한 조건을 빠뜨리게 된다.

메모리 차이는 자원이 빠듯할 때 살피되, 애플리케이션과 함께 쓰는 총량 속에서 판단하는 편이 정확하다. 새 TLS 연결이 많은지, 기존 연결로 정적 파일을 반복해서 보내는지, 한 백엔드에 요청이 오래 집중되는지도 서로 다른 비용을 만든다. 결국 저트래픽 배포에서는 Caddy의 기본 인증서 자동화가, 높은 정적 파일 부하와 지연 목표가 뚜렷한 배포에서는 연결 재사용을 제대로 설정한 Nginx의 처리 성능이 선택을 가른다.

함께 읽기:

• AI 추론은 왜 메모리에 막히나, 속도와 처리량을 헷갈리면 생기는 일
• Granola냐 Fathom이냐…회의 봇보다 메모 습관이 선택을 가른다
• 1Password냐 Bitwarden이냐…쉬운 관리와 자체 호스팅이 선택을 가른다