서브도메인별 SSL 관리 효율적인 방법 궁금합니다

---

요즘 개인 프로젝트 몇 개 돌리다 보니, 하나의 메인 도메인 아래서 여러 서비스(블로그, 포폴, 테스트 페이지 등)를 Nginx 리버스 프록시로 묶어서 운영하려고 합니다.

문제는 SSL 인증서 관리 부분인데, 서브도메인이 여러 개면 인증서 갱신이나 관리가 만만치 않을 것 같아서요.
Let's Encrypt 같은 걸 사용한다고 해도, 개별 서브도메인마다 매번 인증서 발급/갱신 스크립트를 짜는 게 효율적일지 모르겠습니다.

혹시 Nginx 환경에서 여러 서브도메인에 대한 SSL을 가장 깔끔하고 자동화된 방식으로 관리했던 경험 있으신 분 계신가요?
Certbot 같은 툴로도 충분한지, 아니면 다른 접근법이 있을지 궁금합니다.
실제 운영하면서 체감상 가장 편했던 방법을 공유해주시면 큰 도움 될 것 같습니다.

와, 프로젝트 여러 개 돌리시느라 바쁘시겠네요.
서브도메인별 SSL 관리 이거 진짜 골치 아픈 부분 중 하나 맞습니다.
저도 예전에 여러 서비스를 묶어서 운영할 때 이 부분에서 시간 꽤 많이 썼던 기억이 납니다.
Nginx 리버스 프록시 구조라면, 관리 포인트가 명확해서 오히려 자동화할 여지가 큰 편이긴 해요.
질문 주신 내용에 대해 제가 경험했던 것들 위주로 몇 가지 옵션이랑 실질적인 팁들을 정리해서 말씀드릴게요.
우선 결론부터 말씀드리자면, Certbot과 Nginx 설정을 잘 조합하고, 인증서 발급/갱신 스크립트를 중앙 집중화하는 방식이 현재 가장 표준적이고 효율적인 방법입니다.
하지만 '가장 깔끔하고 자동화된 방식'이라는 건 사용하시는 인프라(클라우드 환경인지, VM인지, 도커 쓰는지 등)와 운영팀의 숙련도에 따라 체감하는 난이도가 다를 수 있어서, 몇 가지 시나리오별로 나눠서 설명드릴게요.

1.

Certbot + Nginx (가장 일반적이고 추천하는 방법) 대부분의 분들이 이 경로를 거치시게 될 겁니다.
Certbot은 Let's Encrypt 인증서를 가장 쉽고 안정적으로 받아오는 툴이죠.
이게 핵심은 **'와일드카드 인증서(Wildcard Certificate)'**를 사용하느냐, 아니면 'SAN(Subject Alternative Name)'을 활용하여 여러 도메인을 묶느냐에 달려있습니다.
와일드카드 인증서 (*.yourdomain.com) 사용 시: 만약 모든 서브도메인이 *.yourdomain.com 형태라면, 와일드카드 인증서가 가장 강력합니다.
와일드카드는 *.yourdomain.com에 대한 인증서를 한 번에 받아서, Nginx 설정 파일에서 server_name에 해당 패턴을 지정해주면 됩니다.
갱신 스크립트도 이 하나의 인증서만 갱신하면 되니까 관리 포인트가 하나로 줄어들죠.
️ 주의점: Let's Encrypt가 와일드카드 인증서 발급 시, DNS 레벨의 검증(DNS-01 Challenge)을 요구하는 경우가 많습니다.
이 경우, 도메인 레지스트리나 DNS 서비스 제공사에서 API를 호출할 수 있는 환경이 필요할 수 있어요.
이게 가장 까다로울 수 있습니다.
SAN (Subject Alternative Name) 활용 시: 서브도메인이 blog.yourdomain.com, portfolio.yourdomain.com, test.yourdomain.com 처럼 이름이 제각각이고 와일드카드로 묶기 애매할 때 유용합니다.
이 경우, 인증서 발급 시 하나의 인증서 안에 이 모든 호스트 이름을 명시(blog.yourdomain.com, portfolio.yourdomain.com, test.yourdomain.com)해서 받습니다.
Certbot을 사용할 때, 옵션으로 여러 도메인 목록을 넘겨주면 됩니다.
갱신할 때도 이 인증서 덩어리 하나만 갱신하면 되니, 개별적으로 갱신할 필요가 없어집니다.
실무 팁: Certbot이 Nginx 플러그인을 제공하는 경우, certbot --nginx 명령어를 실행하면 Nginx 설정을 읽어서 필요한 server_name과 SSL 설정을 알아서 추가해주기 때문에, 수동으로 Nginx 설정을 건드리는 실수를 크게 줄일 수 있습니다.
이 기능이 가장 편리합니다.

2.

중앙 집중식 갱신 스크립트 구축 (가장 추천하는 자동화 방법) 아무리 좋은 툴이 있어도, 배포 환경이 복잡하거나 나중에 서비스가 추가될 때마다 수동으로 건드리면 결국 실수가 생깁니다.
가장 안정적인 방법은 **'인증서 발급 및 적용을 담당하는 전용 스크립트'**를 만드는 겁니다.
이 스크립트는 다음과 같은 로직을 가져야 합니다: 1.
도메인 목록 로드: 관리해야 할 모든 서브도메인 목록이 적힌 파일(예: subdomains.txt)을 읽어옵니다.
2.
인증서 발급 요청: 이 목록을 기반으로 Certbot(또는 ACME 클라이언트)을 실행하여 인증서를 요청합니다.
(여기서 와일드카드 또는 SAN 전략을 결정하고 실행) 3.
Nginx 설정 업데이트: 발급받은 새 인증서 경로를 확인하고, Nginx 설정 파일(sites-available 같은 곳)을 찾아 해당 경로를 업데이트하는 로직을 실행합니다.
4.
Nginx 재로드: sudo nginx -t (테스트) 후, sudo systemctl reload nginx를 실행하여 변경 사항을 적용합니다.
장점: 새로운 서브도메인이 생겨도, subdomains.txt 파일에 추가하고 스크립트만 돌리면 끝납니다.
단점: 이 스크립트를 작성하고, 시스템의 권한 문제(sudo, 파일 시스템 접근 등)를 모두 고려해야 하므로, 초기 구축 난이도가 높습니다.

3.

컨테이너 환경 고려 (Docker/Docker Compose) 만약 프로젝트들이 Docker 컨테이너로 격리되어 있다면, SSL 관리가 오히려 더 깔끔해질 수 있습니다.
이 경우, 보통은 **'인그레스(Ingress Controller)'**를 사용하는 것이 업계 표준 접근법입니다.

• Ingress Controller 사용: Nginx나 Traefik 같은 Ingress Controller를 메인으로 두고, 이 컨트롤러가 모든 트래픽을 받아 처리하게 합니다.
• Cert-Manager (Kubernetes 환경일 경우): 만약 쿠버네티스 환경이라면, Cert-Manager라는 툴을 사용하면 이 과정이 거의 '자동'으로 처리됩니다.
  Ingress 리소스에 도메인만 명시해주면, 이 컨트롤러가 알아서 인증서를 가져오고, Nginx(또는 사용된 컨트롤러) 설정을 업데이트해줍니다.
  만약 Docker Compose만 사용하시고 쿠버네티스까지는 부담되신다면, Nginx 컨테이너 자체에 Certbot 볼륨 마운트를 하거나, 초기화 시점에만 SSL 인증서 파일을 받아와서 영구 볼륨에 저장하고, Nginx 설정 파일도 함께 볼륨으로 마운트하는 방식으로 관리하면 비교적 분리된 환경에서 관리가 가능합니다.

요약 및 추천 가이드라인 질문자님의 상황이 **"Nginx 리버스 프록시로 묶어서 운영"**하는 것이라면, 저는 **"Certbot + Nginx 플러그인 활용 후, 스크립트화"**하는 방향을 추천합니다.

우선 시도: certbot 설치 후, sudo certbot --nginx -d sub1.domain.com -d sub2.domain.com ... 와 같이 모든 도메인을 한 번에 시도해보세요.
2.
성공 시: Certbot이 Nginx 설정을 건드리고 SSL을 적용해줄 겁니다.
이게 가장 빠르게 원하는 상태에 도달할 수 있는 방법이에요.
3.
장기 운영 시: 이 성공 경험을 바탕으로, **"도메인 목록 -> Certbot 실행 -> Nginx 설정 파일 덮어쓰기 -> Nginx 재로드"**의 3단계를 묶는 셸 스크립트를 만드시는 것을 목표로 삼으세요.
️ 흔한 실수/주의사항: * 파일 권한 문제: 스크립트가 실행될 때 Nginx 설정 파일이나 인증서 파일에 대한 쓰기 권한이 부족해서 실패하는 경우가 정말 많습니다.
스크립트 실행 계정의 권한을 꼭 확인해주세요.

• 재부팅 vs.
  리로드: SSL 인증서 갱신만 할 때는 systemctl reload nginx가 안전하고 빠릅니다.
  만약 Nginx 설정 파일 자체를 건드리는 큰 변경이 있다면, 테스트(nginx -t) 후 재시작(systemctl restart nginx)을 고려해야 할 수도 있습니다.
• HTTPS 체인: 인증서 발급 시, 중간 인증서(Intermediate Certificate)까지 제대로 포함되어 Nginx가 읽을 수 있는 형태로 저장되었는지 최종적으로 확인하는 습관을 들이셔야 합니다.
  이게 누락되면 브라우저에서 '보안 연결이 아닙니다' 같은 경고가 뜰 수 있어요.
  너무 복잡하게 생각하지 마시고, 일단 Certbot의 Nginx 플러그인 기능으로 여러 도메인을 묶어서 한 번의 인증 시도로 성공시켜보시는 것부터 시작해보시면 감이 오실 거예요.
  궁금한 점 있으면 언제든지 다시 질문주세요!