Let's Encrypt 45일 인증서: 기업 팀이 알아야 할 사항

소개#

SSL 인증서 환경이 수년 만에 가장 큰 변화를 앞두고 있습니다. 세계 최대 인증 기관인 Let's Encrypt가 인증서 유효 기간을 90일에서 45일로 전환합니다. 수백~수천 개 도메인을 관리하는 엔터프라이즈 팀에게 이는 사소한 조정이 아니라, SSL 인증서 관리가 작동해야 하는 방식 자체의 근본적인 전환입니다.

팀이 아직도 SSL 갱신을 수동으로 처리하고 있다면, 곧 그 압박을 체감하게 될 것입니다. 연 4회의 갱신이 연 8회로 늘어납니다. 분기별로 감당 가능한 작업이 끊임없는 운영 부담이 됩니다. 전환 시점은 이미 진행 중이며, 지금 준비하는 인프라 팀은 전환을 순조롭게 헤쳐 나갈 수 있습니다. 준비하지 않는 팀은 장애(중단) 위험이 커지고 운영 오버헤드가 계속 증가할 것입니다.

이 글에서는 해당 발표 내용, 그 배경(이유), 전환 일정이 어떻게 보이는지, 그리고 엔터프라이즈 팀이 준비하기 위해 무엇을 해야 하는지 정리합니다.

발표: Let's Encrypt가 90일에서 45일로 인증서 유효 기간을 전환#

Let's Encrypt는 2026년 중반에 최대 인증서 유효 기간을 90일에서 45일로 줄이려는 의도를 발표했습니다. 이 변경은 전환일 이후 발급되는 모든 신규 인증서에 영향을 미칩니다. 기존 인증서는 자연 만료 시까지 계속 유효하지만, 갱신은 새 45일 유효 기간의 적용을 받게 됩니다.

갑작스러운 결정은 아닙니다. Let's Encrypt는 출시 이후 인증서 유효 기간을 점진적으로 단축해 왔습니다. 대부분의 상용 CA가 1년 인증서를 제공하던 시기에 90일로 시작했으며, 45일로의 전환은 업계 전반이 함께 움직여 온 ‘더 짧은 수명의 인증서’로의 흐름을 이어갑니다.

실질적인 영향은 간단합니다. Let's Encrypt로 보안이 적용되는 모든 도메인은 인증서 갱신을 두 배 더 자주 해야 합니다. 이미 갱신 프로세스를 자동화한 조직이라면 전환이 매끄럽게 진행될 수 있습니다. 반면 수동 프로세스나 반자동 워크플로에 의존하는 팀이라면 운영 영향이 상당할 것입니다.

왜 이런 일이 일어나나: 보안 모범 사례 — 노출(침해) 가능 기간을 제한#

인증서 유효 기간을 더 짧게 하는 것은 근본적으로 보안 향상입니다. 모든 TLS 인증서는 잠재적인 공격 경로를 의미합니다. 인증서의 개인 키가 유출되면, 공격자는 인증서가 만료되거나 폐기될 때까지 해당 도메인인 것처럼 가장할 수 있습니다. 인증서 유효 기간이 길수록, 그 ‘침해 가능 창’이 더 오래 열려 있게 됩니다.

45일짜리 인증서는 현재의 90일 표준과 비교해 그 기간을 절반으로 줄입니다. 만약 1일차에 핵심 키가 유출되었다면, 최대 노출 기간은 90일이 아니라 45일이 됩니다. 실제로는 노출이 보통 더 짧지만, 상한선이 중요합니다. 특히 침해를 즉시 감지하지 못할 수 있는 조직에서는 더욱 그렇습니다.

해지(폐기)와 관련된 논리도 있습니다. CRL과 OCSP를 통한 인증서 해지는 역사적으로 신뢰성이 떨어졌습니다. 브라우저가 해지 상태를 항상 일관되게 확인하는 것은 아니며, 해지된 인증서가 계속 신뢰되는 경우도 있습니다. 인증서의 수명이 짧아지면 해지 인프라에 대한 의존도가 줄어듭니다. 인증서가 45일만 유효하다면, 해지의 중요성은 상대적으로 낮아집니다. 어차피 곧 만료되기 때문입니다.

보안 커뮤니티는 오랫동안 인증서 수명을 더 짧게 가져가야 한다고 주장해 왔습니다. Let's Encrypt의 이번 변화는 보안 연구자들이 수년간 권고해 온 내용을 운영 관점에서 현실화한 것입니다.

구글의 병렬 CA/브라우저 포럼 제안 — 이건 단지 Let's Encrypt만의 일이 아닙니다#

Let's Encrypt만 움직이는 것은 아닙니다. 구글은 CA/브라우저 포럼을 통해 업계 전반의 인증서 최대 수명을 45일로 낮추는 병렬 제안을 추진해 왔습니다. 이는 Let's Encrypt만이 아니라 DigiCert, Sectigo, GlobalSign 같은 상용 CA를 포함한 모든 인증 기관에 영향을 미칩니다.

CA/B 포럼의 제안은 아직 논의 중이지만, 구글의 참여는 45일 수명이 단지 Let's Encrypt의 정책에 그치지 않고 업계 표준이 될 가능성을 시사합니다. 가장 큰 브라우저 벤더와 가장 큰 인증 기관이 보안 정책에 함께한다면, 그에 따른 채택은 대체로 이어집니다.

엔터프라이즈 팀의 관점에서는, 45일 인증서 시대가 Let's Encrypt만의 문제가 아니라는 뜻입니다. 오늘날 1년 수명의 상용 인증서를 사용 중이라면, 그 수명도 함께 줄어들 것으로 예상해야 합니다. 전체 SSL 인증서 생태계가 단명(짧은 수명) 인증서로 이동하고 있으며, 전환은 이미 진행 중입니다.

타임라인: 변경이 언제 일어나고, 전환 기간은 어떤 모습인가#

Let's Encrypt는 단계적 롤아웃을 예고했습니다. 정확한 날짜는 아직 확정 중이지만, 예상 타임라인은 이전의 수명 단축과 유사한 패턴을 따를 것으로 보입니다:

**발표 단계(현재):** 공개 커뮤니케이션, 문서 업데이트, 도구 준비. Certbot과 같은 클라이언트 소프트웨어 및 ACME 라이브러리는 새로운 수명을 처리할 수 있도록 업데이트를 받습니다.

**단계적 배포:** 45일의 유효 기간은 먼저 신규 인증서 발급의 일부에 적용되며, Let's Encrypt가 문제를 모니터링하고 갱신 패턴에 대한 데이터를 수집할 수 있도록 합니다.

**완전한 시행:** Let's Encrypt가 발급하는 모든 신규 인증서는 45일의 최대 유효 기간을 따릅니다. 기존의 90일 인증서는 자연 만료 시까지 계속 유효합니다.

기업 팀의 경우, 실질적인 마감 시점은 전환 이후 현재 자동화가 갱신 주기에 도달하는 때입니다. 오늘날 인증서가 60일마다 갱신된다면, 정책 변경 후 45일 인증서를 발급하기 전까지 대략 한 번의 갱신 주기가 남아 있는 셈입니다.

45일이 실제로 의미하는 것: 연 4회에서 8회로 늘어나는 갱신#

계산은 간단하지만 운영상의 영향은 그렇지 않습니다. 90일 인증서에서 45일 인증서로 전환하면 다음과 같습니다:

**갱신 빈도가 2배가 됩니다.** 도메인당 연 4회의 갱신 주기 대신 연 8회를 처리해야 합니다. 100개 도메인을 관리하는 팀이라면 연간 400회가 아닌 800회의 갱신 이벤트를 처리하게 됩니다. 수천 개 도메인을 관리하는 팀은 완전한 자동화 없이는 수치가 감당되지 않습니다.

**갱신 창이 줄어듭니다.** 90일 인증서에서는 대부분의 자동 갱신 시스템이 만료 30일 전에 갱신을 시도하기 시작해, 30일의 여유 버퍼가 남습니다. 45일 인증서에서는 동일한 30일의 선행 시간이 15일의 버퍼로만 남습니다. 갱신 로직은 더 공격적이고 더 신뢰할 수 있어야 합니다.

**실패 허용 범위가 감소합니다.** 90일 인증서에서는 갱신 실패가 발생해도 만료 전까지 몇 주의 시간을 두고 원인을 조사하고 해결할 수 있습니다. 45일 인증서에서는 며칠밖에 없습니다. 모든 갱신 실패는 더 긴급하며, 모니터링은 더 즉각적으로 대응해야 합니다.

**요율 제한이 문제가 될 수 있습니다.** Let's Encrypt는 인증서 발급에 대해 요율 제한을 적용합니다. 갱신 빈도를 2배로 늘리면 요율 제한 예산을 2배로 소모하게 됩니다. 90일 인증서에서 한계에 가까운 팀은 45일 인증서에서 한계에 도달할 수 있으므로 발급 패턴을 조정해야 합니다.

결론은 이렇습니다. 90일에서 간신히 작동하던 수동 또는 반자동 갱신 프로세스는 45일에서는 실패할 것입니다. 완전한 자동화는 더 이상 선택 사항이 아닙니다.

가장 큰 영향을 받는 대상: 수백 개 이상의 도메인을 수동 SSL 프로세스로 관리하는 팀#

45일짜리 인증서 시대는 모두에게 똑같이 영향을 주지 않습니다. 가장 큰 영향을 체감하는 대상은 다음과 같습니다:

**도메인 투자자 및 포트폴리오 관리자.** 수백~수천 개의 주차(parked), 리다이렉트(redirected), 또는 수익화된 도메인을 관리하는 팀은 가장 큰 운영 부담을 떠안습니다. 각 도메인마다 고유한 인증서가 필요합니다. 이 규모에서의 수동 갱신은 이미 90일 기준에서도 고통스러웠습니다. 45일로 줄어들면 현실적으로 불가능합니다.

**고객사 도메인을 관리하는 에이전시.** 디지털 에이전시는 종종 수십~수백 개의 고객사 도메인에 대해 SSL을 관리합니다. 각 고객사는 서로 다른 인프라, 서로 다른 갱신 프로세스, 그리고 서로 다른 수준의 자동화를 사용합니다. 45일 일정은 이러한 갱신 워크플로우의 모든 불일치를 더 크게 증폭시킵니다.

**여러 매장을 운영하는 이커머스 플랫폼.** 멀티 브랜드 이커머스 운영은 브랜드마다, 지역마다, 그리고 캠페인마다 별도의 도메인을 사용해 별도로 운영합니다. 인증서 개수는 빠르게 늘어나고, 그만큼 갱신 부담도 함께 커집니다.

**커스텀 도메인을 사용하는 SaaS 플랫폼.** 고객이 자신의 도메인을 가져올 수 있는 SaaS 제품은 보통 온보딩 과정에서 SSL 프로비저닝을 처리합니다. 45일짜리 인증서에서는 갱신 인프라가 완벽해야 합니다. 고객 도메인의 갱신 실패는 곧 고객 사이트에 보안 경고가 표시된다는 뜻이기 때문입니다.

완전히 자동화된 ACME 기반 갱신을 사용하는 팀은 변화가 거의 느껴지지 않을 수 있습니다. 인증서 수명은 자동으로 갱신하는 인프라에 의해 추상화되어 있기 때문입니다. 경계선은 자동화입니다. 갱신 과정에 사람이 대시보드를 확인하거나 스크립트를 실행하는 단계가 포함되어 있다면, 이미 그 경계선의 반대편에 있는 것입니다.

엔터프라이즈 준비도 격차#

업계 설문조사에서는 우려스러운 그림이 나타납니다. Let's Encrypt 사용 가능 기간과 ACME 자동화 성숙도가 수년간 축적되었음에도 불구하고, 상당수 조직은 여전히 SSL 갱신을 수동 또는 반자동 방식으로 처리하고 있습니다.

일반적인 격차는 다음과 같습니다. 자동화된 모니터링 대신 스프레드시트로 관리되는 인증서, 수동으로 트리거해야 하는 갱신 스크립트, 모니터링되지 않는 인박스로 가는 만료 알림, 그리고 중앙 집중형 갱신 조율 없이 인프라 전반에 배포되는 와일드카드 인증서입니다.

준비도 격차는 Let's Encrypt를 일찍 도입했지만 갱신 파이프라인을 완전히 자동화하지 않은 조직에서 가장 큽니다. 그들은 5년 전 몇 대의 서버에 Certbot을 설치하고 크론 작업을 추가했지만, 그 이후로는 설정을 다시 점검하지 않았습니다. 해당 크론 작업이 60일마다 실행될 수 있는데, 이는 45일짜리 인증서에 비해 충분히 자주 실행되지 않습니다.

이미 전환을 완료한 인프라 팀의 권고는 일관됩니다. 지금 갱신 프로세스를 점검하세요. 인프라에 있는 모든 인증서를 파악하고, 갱신이 자동화되어 있으며 모니터링되고 있는지 확인한 뒤, 장애 복구 절차를 테스트하십시오. 45일 시대는 갱신 파이프라인의 모든 공백을 드러낼 것입니다.

결론#

45일짜리 인증서 시대가 다가오고 있으며, 이는 단지 Let's Encrypt의 정책 변경이 아니라 보안 모범 사례에 의해 촉발되는 인증서 수명 단축으로의 업계 전반적인 전환입니다. 엔터프라이즈 팀의 경우, 영향을 느끼는 팀과 그렇지 않은 팀을 가르는 기준은 간단합니다. 바로 자동화입니다.

SSL 갱신 파이프라인이 ACME를 통해 완전히 자동화되어 있다면(인증서가 갱신되고 설치 및 검증이 사람의 개입 없이 이뤄진다면), 설정 파라미터를 업데이트하는 것 외에는 변화가 전혀 느껴지지 않을 수 있습니다. 반대로 갱신 과정에 수동 단계, 스프레드시트, 사람이 실행하는 스크립트가 포함되어 있다면, 45일 일정은 인프라의 모든 공백을 드러낼 것입니다.

실질적인 단계는 간단합니다. 인증서 인벤토리를 점검하고, 자동화 적용 범위를 확인하며, 갱신 실패 시나리오를 테스트하고, 모니터링이 사용자에게 브라우저 경고가 나타나기 전에 만료를 감지하도록 하십시오. 타임라인이 줄어들기 전에 지금 이를 해두는 팀은 사고 없이 전환을 진행할 수 있습니다.

지금 SSL 갱신 프로세스를 점검하세요. 45일 시대가 다가옵니다. 자동화된 SSL 관리가 어떻게 작동하는지 확인해 보세요.