SSL 인증서 유효 기간이 절반으로 줄어들 예정입니다. 웹 인증서의 60%를 지원하는 Let’s Encrypt는 최대 인증서 유효 기간을 90일에서 45일로 전환하고 있습니다. 구글의 CA/브라우저 포럼 제안도 이 방향을 그대로 따릅니다. 전체 인증서 산업은 보안 표준으로서 더 짧은 유효 기간을 향해 나아가고 있으며, 타임라인은 더 이상 이론이 아닙니다.
수백~수천 개 도메인에 걸친 리다이렉트 인프라를 관리하는 팀에게 이는 사소한 조정이 아닙니다. 운영 효율을 배로 늘리는 문제입니다. 도메인당 연 4회의 갱신이 필요했던 작업이 곧 연 8회가 필요해집니다. 90일 기준으로도 겨우 작동하던 수동 프로세스는 45일에서는 완전히 실패할 것입니다.
이 체크리스트는 인프라 팀이 여섯 가지 핵심 영역에서 준비 상태를 점검할 수 있도록 설계되었습니다: 자동화, 모니터링, 갱신 타이밍, 알림, 와일드카드 전략, 재해 복구. 각 섹션에는 자체 평가 질문과 목표 상태가 포함되어 있습니다. 마무리되면 인프라가 현재 어디에 서 있는지 — 그리고 45일 시대가 오기 전에 무엇을 바꿔야 하는지 — 명확한 그림을 갖게 될 것입니다.
1. 자동화: 무인(Zero-Touch) 인증서 라이프사이클#
준비도 평가에서 가장 중요한 단 하나의 질문: 발급되고 갱신되는 모든 인증서가 사람의 개입 없이 이루어지나요?
답이 ‘예’라고 단정할 수 있는 경우가 아니라면 문제가 있습니다. 45일 유효 기간에서는 수동 인증서 운영이 놀라울 정도로 작은 규모에서도 지속 불가능해집니다. 도메인 50개만으로도 연간 400회의 인증서 작업이 필요합니다. 즉, 매일(주말과 공휴일 포함) 하루에 한 번 이상입니다.
현재 상태 자체 평가: 팀은 오늘날 인증서 프로비저닝을 어떻게 처리하나요? 답이 달력 알림, 스프레드시트, 수동 CSR 생성, 또는 ‘누군가 보통 처리해’ 같은 방식이라면 수동 단계에 해당합니다. 워크플로의 일부를 스크립트로 자동화했더라도, 그 스크립트가 모든 도메인을 커버하는지, 모든 예외 상황을 처리하는지, 그리고 사람의 에스컬레이션 없이도 모든 실패에서 복구하는지 여부를 확인하세요.
목표 상태: 리다이렉트 인프라의 모든 호스트명이 DNS가 구성되는 즉시 ACME를 통해 자동으로 SSL을 프로비저닝합니다. 인증서 발급, 설치, 갱신은 어떤 사람의 작업 없이 이루어집니다. 시스템은 새 도메인을 감지하고 DNS-01 챌린지로 소유권을 검증한 뒤 인증서를 요청하고, 엣지 노드 전반에 설치하며, 다음 갱신 일정을 호스트명이 추가된 지 수 초 안에 잡습니다.
서버별로 인증서를 관리하도록 요구하는 대신, 호스트명 단위로 SSL을 관리하는 리다이렉트 플랫폼은 자동화 격차를 완전히 제거합니다. DNS가 플랫폼에 위임되면 SSL은 누군가의 할 일 목록에 있는 작업이 아니라 인프라의 속성이 됩니다.
2. 모니터링: 깨지기 전에 알기#
스스로에게 물어보세요. 모든 도메인에 대해 만료 인증서 만료일을 활성으로 모니터링하고 있나요?
모니터링은 자동화 아래에 있는 안전망입니다. ACME 기반 갱신이 있더라도 문제가 생길 수 있습니다. DNS 레코드가 변경되거나, 레이트 리밋이 트리거되거나, CA가 장애를 겪을 수 있습니다. 모니터링이 없으면 만료된 인증서를 사용자들이 겪는 것과 똑같이 — 브라우저 경고를 통해 — 발견하게 됩니다.
하지만 모니터링은 만료 날짜 확인만을 의미하지는 않습니다. 리다이렉트 인프라에 대한 효과적인 모니터링은 여러 글로벌 위치에서의 헬스 체크를 포함해야 합니다. 사무실에서는 유효해 보이는 인증서도, 엣지 전파 지연이나 CDN 캐싱 때문에 사용자의 위치에서는 실패할 수 있기 때문입니다.
현재 상태 자체 점검: 모든 도메인의 인증서 만료일을 보여주는 대시보드나 알림 시스템이 있나요? 인증서가 갱신될 때 실시간으로 업데이트되나요? 만료가 임박한 도메인과 이미 실패한 도메인을 한눈에 확인할 수 있나요?
목표 상태: 여러 글로벌 엣지 위치에서의 지속적인 인증서 헬스 모니터링. 시스템은 만료일 조회만이 아니라, 모든 인증서가 유효하고 신뢰되며 올바르게 제공되고 있는지 확인하기 위해 활성 TLS 핸드셰이크 점검을 수행합니다. 대시보드는 모든 도메인에 대해 실시간 상태를 표시합니다. 모니터링은 자동입니다. 새 호스트명이 추가되면 별도 설정 없이 모니터링이 시작됩니다.
3. 갱신 타이밍: 버퍼 존#
질문: 다일(여러 날) 장애를 견딜 만큼 갱신을 충분히 일찍 시도하고 있나요?
90일 인증서에서는 만료 7~14일 전에 갱신하면 충분한 버퍼가 확보되었습니다. 하지만 45일 인증서에서는 동일한 버퍼가 인증서의 총 사용 가능 수명에서 15~30%를 소모합니다. 계산 결과는 선택의 문제를 강제합니다. 너무 일찍 갱신하면 인증서를 계속 교체하게 되고, 너무 늦게 갱신하면 일시적인 CA 장애가 운영 사고로 이어질 수 있습니다.
Let’s Encrypt 레이트 리밋은 또 다른 차원을 추가합니다. ‘중복 인증서(Duplicate Certificate)’ 한도는 동일한 호스트명 집합에 대해 주당 5개 인증서를 허용하고, ‘등록된 도메인당 인증서(Certificates per Registered Domain)’ 한도는 주당 50개로 제한합니다. 45일 갱신 주기에서는 대규모 도메인 포트폴리오가 예상보다 빨리 이러한 한도에 근접할 수 있습니다. 특히 새 도메인을 위해 인증서를 프로비저닝하고 있다면 더욱 그렇습니다.
현재 상태 자체 점검: 갱신 윈도우는 어떻게 되나요? 팀이 인증서를 수동으로 갱신한다면, 만료 최소 15일 전에 갱신이 시작되나요? 어떤 인증서도 만료되지 않도록 5일간의 CA 장애를 견딜 수 있나요? 갱신 시도가 실패하면 어떻게 되는지 테스트해 보셨나요. 시스템이 자동으로 재시도하나요, 아니면 사람이 개입할 때까지 기다리나요?
목표 상태: 자동 갱신은 만료 30일 전에 시작되며, 지수 백오프(Exponential backoff) 재시도 로직을 사용합니다. 첫 번째 시도가 실패하면 갱신이 성공할 때까지 점점 더 긴 간격으로 재시도합니다 — 1시간, 4시간, 12시간, 24시간. 레이트 리밋은 자동으로 추적되고 준수됩니다. 시스템은 여러 날에 걸친 CA 장애를 견딜 수 있으며, 어떤 도메인도 만료일에 도달하지 않습니다. 갱신을 충분히 일찍 시작하기 때문에 항상 최소 15일의 버퍼가 남아 있기 때문입니다.
4. 알림: 제때, 늦지 않게#
질문: 올바른 사람들이 인증서 만료 ‘후’가 아니라 ‘전에’ 통보받나요?
알림은 ‘사건이 아닌 것’과 ‘사고’를 가르는 차이입니다. 인증서 갱신이 실패하면 두 가지가 일어나야 합니다. 시스템이 자동으로 재시도해야 하고(3절 참조), 올바른 사람이 그 사실을 알아야 합니다. 모니터링이 만료된 인증서를 감지했는데도 아무에게도 알리지 않는다면, 여전히 공백이 있습니다. 그저 더 빨리 알아차릴 뿐입니다.
알림은 심각도와 대상에 따라 계층화되어야 합니다. 30분 후에 재시도해 성공한 갱신 실패는 새벽 2시 페이지를 받을 필요가 없습니다. 하지만 일일 다이제스트에는 반드시 포함되어야 합니다. 성공적인 갱신 없이 최종 72시간에 가까워진 인증서는 즉시 온콜 엔지니어에게 도달해야 하는 치명적 알림입니다.
현재 상태 자체 점검: 인증서가 만료되기 직전에 누가 통보받나요? 서로 다른 심각도 수준을 가진 계층형 알림 시스템이 있나요? 긴급도에 따라 알림이 올바른 채널(슬랙, 이메일, PagerDuty)로 전달되나요? 기본 온콜 담당자가 사용 불가능하면 알림이 에스컬레이션되나요?
목표 상태: 3단계 알림 — 정보 (갱신 시도됨, 일일 다이제스트), 경고 (갱신 실패, 7일 창, 슬랙/이메일), 치명적 (갱신이 반복적으로 실패, 72시간 창, PagerDuty/온콜 에스컬레이션). 알림에는 도메인 이름, 인증서 만료일, 마지막 갱신 시도 시간, 실패 사유가 포함됩니다. 포트폴리오의 모든 도메인이 커버됩니다 — 예외 없음, ‘그건 수동으로 모니터링하자’ 같은 경우 없음.
5. 와일드카드 인증서: 편의 vs. 위험#
질문: 와일드카드 인증서는 올바르게 처리되나요, 아니면 단일 장애 지점(SPOF)을 만들고 있나요?
와일드카드 인증서는 매력적입니다. *.example.com 하나의 인증서로 모든 서브도메인을 커버합니다. 갱신도 한 번. 만료일도 하나. 관리할 것도 하나. 하지만 ‘관리할 것 하나’는 동시에 ‘실패할 수 있는 것 하나’이기도 합니다. 그리고 그것이 실패하면, 모든 서브도메인이 동시에 어두워집니다.
리다이렉트 인프라에 한정해 보면, 와일드카드는 또 다른 문제를 만듭니다. DNS-01 챌린지는 와일드카드 인증서의 경우, 정점(apex) 도메인의 DNS 존에 대한 접근이 필요합니다. 리다이렉트 도메인이 여러 레지스트라와 DNS 제공업체에 분산되어 있다면(대규모 포트폴트에서 흔함), 단일 와일드카드에 대한 DNS-01 챌린지 관리는 호스트별 인증서 관리보다 훨씬 더 복잡해집니다.
현재 상태 자가 진단: 리다이렉트 도메드에 와일드카드 인증서를 사용하고 있나요? 와일드카드 인증서 갱신에 실패하면, 영향을 받는 도메인은 몇 개입니까? 검증된 롤백(복구) 계획이 있나요? 와일드카드는 도메드별 인증서를 관리하는 동일한 팀에서 관리하나요, 아니면 서로 다른 소유자를 가진 별도의 프로세스인가요?
목표 상태: 호스트(도메드)별 인증서가 기본입니다. 각 도메드는 자체 인증서를 부여받고 독립적으로 갱신됩니다. 이는 격리 효과를 제공합니다. 한 도메드의 갱신 실패가 다른 어떤 도메드에도 영향을 주지 않습니다. 와일드카드는 명시적으로 필요한 경우에만 사용합니다(예: 공유 서브도메드 뒤의 내부 서비스). 이때는 별도의 모니터링과 알림을 적용하며, 문서화되고 테스트된 복구 절차도 마련합니다.
6. 재해 복구: CA가 다운되면#
질문: 인증 기관(Certificate Authority, CA)이 5일 동안 사용 불가능하다면, 인증서는 계속 유지됩니까?
Let’s Encrypt는 과거에 수 시간 단위의 장애를 겪은 적이 있습니다. 90일 인증서 수명에서는 2~3일 장애가 감당 가능했는데, 인증서에 남은 유효 기간이 충분해 그 기간을 버틸 수 있었기 때문입니다. 하지만 45일에서는 동일한 장애가 인증서를 갱신 창을 지나게 만들어, CA가 다시 온라인으로 돌아오기 전에 만료될 수 있습니다.
SSL 재해 복구는 CA만의 문제가 아닙니다. DNS 문제입니다. DNS 제공업체에 DNS-01 챌린지 창 동안 장애가 발생하면 챌린지가 실패하고 갱신이 차단됩니다. 엣지 전파 문제이기도 합니다. 갱신된 인증서가 기존 인증서 만료 전에 모든 엣지 노드로 전파되지 않으면 일부 사용자는 오류를 보게 됩니다. 그리고 갱신 파이프라인 자체의 문제입니다. 자동화 플랫폼에 장애가 생기면 갱신이 대기열에 쌓이거나, 아니면 드롭(유실)되나요?
현재 상태 자가 진단: 5일간 CA 장애가 발생했을 때 어떤 일이 일어나는지 모델링해 보셨나요? 포트폴트에서 가장 짧은 인증서 유효 기간이 얼마입니까? 대체 CA(fallback CA)를 구성해 두었나요, 아니면 모든 인증서가 단일 제공업체에 묶여 있나요? 챌린지 창 동안 DNS 인프라가 장애를 견딜 수 있나요?
목표 상태: 모든 도메드가 최소 15일의 버퍼를 유지할 수 있을 만큼 충분히 일찍 인증서를 갱신합니다. 이는 현실적인 CA 장애를 견딜 만큼의 시간입니다. 갱신 파이프라인은 회복력이 있습니다. CA 사용 불가능으로 인해 갱신이 실패하면, CA가 복구되는 즉시 시스템이 자동으로 재시도합니다. 모니터링은 인증서 만료일만이 아니라 의존성 전체 체인(DNS, CA, 엣지 전파)을 포괄합니다. 중요 도메드에는 대체 CA가 구성되어 있으며, 팀은 CA가 장기간 장애를 겪는 동안 수동으로 인증서를 프로비저닝하기 위한 문서화되고 테스트된 런북(runbook)을 보유하고 있습니다.
자가 진단: 준비 상태를 점수로 매겨보세요#
아래 6개 도메인 각각의 인프라 수준을 평가해 보세요. 솔직하게 답하세요. 낮은 점수는 실패가 아니라 로드맵입니다.
채점 기준: 1 = 수동 / 기능 없음, 2 = 부분 자동화 / 공백 존재, 3 = 대부분 자동화 / 사소한 공백, 4 = 완전 자동화 / 공백 없음, 5 = 완전 자동화 + 테스트 완료 / 복원력 있음
| Domain | 점수(1~5) | Priority if < 4 | 첫 번째 조치 |
|---|---|---|---|
| ① Automation | __ | Critical | 현재의 수동 단계를 감사하세요 — 한 도메인을 골라 완전히 자동화하세요 |
| ② Monitoring | __ | High | 모든 도메인에 대해 만료 모니터링을 구현하고, 30일 경고 임계값을 설정하세요 |
| ③ 갱신 시점 | __ | Critical | 모든 갱신이 만료 최소 30일 전에 트리거되도록 설정하세요 |
| ④ Alerts | __ | High | 최소 두 단계의 알림을 구성하세요: 경고(7일)와 치명적(72시간) |
| ⑤ Wildcards | __ | Medium | 모든 와일드카드 인증서를 인벤토리로 정리하고, 인증서별 폭발 반경(영향 범위)을 문서화하세요 |
| ⑥ 재해 복구(Disaster Recovery) | __ | Medium | 5일 간의 CA 장애 시나리오를 모델링하고 생존 격차를 문서화하세요 |
총 결과 해석:
24-30: 준비가 되었습니다. 인프라는 자동화되어 있고 모니터링되며 회복 탄력성이 있습니다. 이 상태를 유지하고 복구 절차를 정기적으로 테스트하는 데 집중하세요.
18-23: 탄탄한 기반이 있지만 격차가 남아 있습니다. ‘Critical(중요)’ 도메인을 먼저 우선순위로 두세요 — 자동화와 갱신 타이밍이 가장 높은 ROI 개선입니다. 45일 타임라인은 현재 설정에 큰 부담을 줄 것입니다.
12-17: 인프라는 45일 인증서에 대비되어 있지 않습니다. 90일에서 작동하던 수동 프로세스는 45일에서는 깨집니다. 자동화부터 시작하세요(도메인 ①) — 한 가지만 고친다면 자동 인증서 발급 및 갱신을 자동화하세요.
6-11: 위험이 매우 높습니다. 포트폴리오의 모든 도메인은 단 한 번의 캘린더 알림 누락이나 CA 장애에도 취약합니다. 격차를 빠르게 메우기 위해 SSL 자동화를 인프라로 처리하는 리디렉트 플랫폼으로 전환하는 방안을 고려하세요 — 작업이 아니라 인프라로요.
격차는 더 벌어집니다#
45일 인증서 시대는 미래의 가능성이 아닙니다. 정해진 일정이 있는 업계의 흐름입니다. 3억 6천만 개가 넘는 도메인에 대해 인증서를 발급하는 Let's Encrypt가 이 변화를 주도하고 있습니다. Google의 CA/Browser Forum 제안도 같은 방향을 반영합니다. 표준은 이동 중이며, 인증서 유효기간이 짧아질수록 자동화된 인프라와 수동 인프라 사이의 격차는 더욱 커집니다.
지금 자동화를 구축하는 팀들은 이 변화를 체감하지 못할 것입니다. 대시보드에 갱신이 매번 일정대로 완료되는 것을 보게 될 테니까요. 모든 도메인에서 30일 일찍, 매번 완료됩니다. 반면 다른 팀들은 스프레드시트를 업데이트하느라 허둥댈 것입니다. 위의 체크리스트는 단순한 평가 도구가 아닙니다. 업계가 정착할 인증서 유효기간이 45일이든 30일이든 더 짧든, 무엇이든 대비할 수 있는 인프라를 위한 로드맵입니다.
인프라를 점수로 확인하세요. 격차를 수정하세요. 45일 인증서 시대가 다가옵니다. 리디렉션 도메인은 마지막으로 걱정할 일입니다.
자주 묻는 질문
Let's Encrypt는 최대 인증서 수명을 90일에서 45일로 줄일 계획을 발표했으며, 이 전환은 2026년에 시작될 것으로 예상됩니다. Google의 CA/브라우저 포럼도 유사한 제안을 추진하고 있어, 짧은 수명이 업계 표준이 될 것임을 알리고 있습니다 — 단순한 Let's Encrypt 정책이 아닙니다.
45일 인증서 수명으로 각 도메인은 연간 약 8회의 갱신 주기가 필요합니다 — 90일 인증서의 4회에서 증가한 수치입니다. 500개의 리디렉션 도메인을 관리하는 팀의 경우, 이는 연간 2,000회 대신 4,000회의 인증서 작업을 의미합니다.
가장 신뢰할 수 있는 접근 방식은 ACME 기반 자동화입니다. 여기서 리디렉션 인프라는 DNS-01 챌린지를 자동으로 완료하고, 인증서를 프로비저닝하며, 갱신을 예약합니다. 호스트 이름별로 SSL을 처리하는 리디렉션 플랫폼은 개별 도메인에서 인증서를 수동으로 관리할 필요를 없애줍니다.
리디렉션 도메인의 인증서가 만료되면, 브라우저는 페이지를 로드하기 전에 보안 경고 인터스티셜을 표시합니다. 이는 리디렉션을 완전히 차단하여 방문자가 목적지에 도달하지 못하게 합니다. 마케팅 캠페인에 있어 이는 클릭 손실, 추적 중단 및 신뢰 감소를 의미합니다. 복구는 CA 전파 속도에 따라 몇 시간에서 며칠이 걸릴 수 있습니다.
와일드카드 인증서는 단일 정점 도메인 아래의 하위 도메인 관리를 단순화하지만, 단일 실패 지점을 생성합니다 — 와일드카드가 만료되면 모든 하위 도메인에 영향을 미칩니다. 도메인별 인증서는 더 나은 격리를 제공하지만 더 많은 관리 오버헤드가 필요합니다. 대규모 포트폴리오의 경우, ACME를 통해 호스트 이름별 인증서를 자동으로 프로비저닝하는 리디렉션 플랫폼이 두 가지의 장점을 제공합니다: 관리 부담 없이 격리.
최고의 관행은 만료 15일 전에 갱신을 시작하는 것입니다 — 그리고 중요한 인프라의 경우 30일 전입니다. 이 버퍼는 DNS 전파 지연, CA 중단(여러 일이 걸릴 수 있음) 및 재시도 로직을 고려합니다. 45일 인증서의 경우, 30일 사전 갱신은 인증서가 발급되자마자 거의 갱신하는 것을 의미하며 — 자동화는 필수입니다.
ACME(자동 인증서 관리 환경)는 인증서의 전체 생애 주기를 자동화하는 프로토콜입니다: 도메인 검증, 인증서 발급, 설치 및 갱신. 이는 DNS-01 또는 HTTP-01 챌린지를 사용하여 도메인 소유권을 검증한 후, 인증 기관과의 암호화 교환을 자동으로 처리합니다. ACME는 Let's Encrypt를 지원하며 제로 터치 SSL 자동화를 가능하게 합니다.
네. RedirHub는 플랫폼에 추가된 모든 호스트 이름에 대해 Let's Encrypt를 통해 SSL 인증서를 자동으로 프로비저닝합니다. DNS가 RedirHub의 엣지로 지정되면, 시스템은 호스트 이름을 감지하고 ACME DNS-01 챌린지를 완료하며, 인증서를 발급하고 자동 갱신을 예약합니다 — 모두 수동 개입 없이 이루어집니다. 갱신은 만료 30일 전에 시작되며 자동 재시도 로직과 실패 알림이 포함됩니다.
Linh handles the backend systems that keep RedirHub fast and reliable. Her work revolves around performance, scalability, and making sure redirects happen instantly, no matter where users are. She likes solving complex problems quietly.
