Let's Encrypt rate limit은 어떻게 계산될까? 2026 기준 발급 제한과 재시도 방법 정리

Let's Encrypt rate limit은 어떻게 계산될까? 2026 기준 발급 제한과 재시도 방법 정리

Let's Encrypt를 운영하다 보면 "왜 갑자기 발급이 막혔지?"라는 상황을 겪을 수 있다. 하지만 대부분의 제한은 임의로 막히는 것이 아니라 문서에 공개된 규칙대로 계산된다. 새 인증서 발급, 동일 도메인 반복 발급, 검증 실패 누적, 테스트 환경 사용 여부를 구분해서 보면 원인을 비교적 빠르게 좁힐 수 있다.

이 글은 2026년 5월 8일 기준 Let's Encrypt 공식 문서와 Certbot 공식 안내를 바탕으로, 자주 부딪히는 rate limit 수치와 renewal 예외, 재시도 방법을 객관적으로 정리한 초안이다.

가장 먼저 알아야 할 핵심은 무엇인가?

Let's Encrypt의 rate limit은 요청마다 적용되는 토큰 버킷 방식으로 계산된다. 그래서 짧은 시간에 몰아서 요청하면 제한에 빨리 닿을 수 있고, 시간을 두고 나누면 같은 총량이어도 더 안정적으로 처리될 수 있다. 또한 인증서를 취소해도 이미 사용한 발급 자원은 되돌아오지 않으므로, revoke가 limit 초기화 수단은 아니다.

• 새 계정 생성 제한과 인증서 발급 제한은 서로 다르다.
• 갱신은 신규 발급과 동일하게 취급되지 않는다.
• 테스트나 장애 분석은 production보다 staging에서 먼저 하는 것이 안전하다.
• 에러 메시지와 Retry-After 헤더를 보면 언제 다시 시도할지 판단할 수 있다.

2026년 기준으로 자주 보는 주요 발급 제한 수치는?

Let's Encrypt의 2025년 6월 12일자 rate limits 문서 기준으로, 실무에서 가장 자주 확인하는 수치는 다음과 같다.

• 계정당 새 order: 3시간에 최대 300개
• 등록 도메인당 새 인증서: 7일에 최대 50개
• 정확히 같은 식별자 집합: 7일에 최대 5개
• 계정당 식별자별 authorization 실패: 1시간에 최대 5회

여기서 registered domain은 단순히 최상위 도메인 문자열이 아니라 Public Suffix List 기준으로 계산된다. 예를 들어 www.example.com은 example.com, new.blog.example.co.uk는 example.co.uk 기준으로 묶인다. IPv4는 개별 주소, IPv6는 /64 범위를 기준으로 본다고 문서에 적혀 있다.

왜 같은 도메인을 반복 발급하면 더 빨리 막힐까?

운영 중 많이 헷갈리는 부분이 exact set of identifiers 제한이다. 같은 호스트명 조합으로 인증서를 반복 발급하면 7일 동안 최대 5개까지만 허용된다. 예를 들어 example.com과 www.example.com 조합으로 짧은 시간 안에 인증서를 여러 번 다시 만들면, 다른 limit보다 먼저 여기에 걸릴 수 있다.

Let's Encrypt 문서는 ACME 클라이언트를 반복 재설치하거나, 배포 때마다 클라이언트 설정을 지우고 새로 발급하는 패턴을 대표 원인으로 든다. 따라서 운영 환경에서는 기존 계정과 기존 인증서 계보를 유지한 채 갱신 흐름을 쓰는 편이 안전하다. 단순 재배포를 신규 발급처럼 만들면 limit을 불필요하게 소모한다.

renewal은 정말 rate limit에서 자유로운가?

완전히 같은 방식은 아니지만, 공식 문서는 renewal을 두 가지 방식으로 예외 처리한다고 설명한다. 가장 우선되는 방식은 ACME Renewal Info, 즉 ARI 기반 renewal이다. ARI로 조정되는 renewal은 모든 rate limit에서 면제된다.

ARI를 아직 쓰지 않는 클라이언트나 호스팅 환경이라도, 같은 식별자 집합으로 갱신하면 renewal로 인정될 수 있다. 이 경우에도 새 order per account와 registered domain per 7 days 제한에서는 제외되지만, authorization 실패 제한과 exact set of identifiers 제한에서는 완전히 자유롭지 않다. 그래서 "renewal이면 무조건 아무 제한도 없다"라고 단정하면 틀릴 수 있다.

또한 Let's Encrypt는 2026년 2월 24일 공지에서 향후 2년 동안 기본 인증서 수명을 90일에서 64일, 다시 45일로 줄여 가겠다고 설명했다. 동시에 renewal은 계속 rate limit 예외로 취급되므로, 기존 인증서를 정상적으로 갱신하는 운영이라면 수명 단축 자체가 limit 확대를 의미하지는 않는다고 밝혔다.

검증 실패 limit은 어떤 상황에서 잘 발생할까?

authorization 실패는 발급 수보다 더 빨리 장애를 키우는 항목이다. 식별자별로 계정당 1시간에 5회까지만 실패할 수 있기 때문이다. HTTP-01과 TLS-ALPN-01은 외부 검증 서버가 실제 서비스에 도달하지 못할 때, DNS-01은 CNAME 또는 TXT 레코드 설정 실수 때 자주 실패한다는 점을 Let's Encrypt 문서가 명시하고 있다.

연속 실패에 대한 별도 limit도 있다. 같은 식별자에 대해 연속 authorization 실패가 누적되면 발급이 일시 정지될 수 있으며, 문서에는 최대 1,152회의 연속 실패 한도와 self-service portal을 통한 해제 절차가 설명돼 있다. 즉 단순히 재시도 루프를 돌리는 것은 복구 전략이 아니라 문제를 더 오래 끄는 패턴일 수 있다.

테스트와 장애 분석은 어떻게 해야 안전할까?

Let's Encrypt는 production API 대신 staging environment를 먼저 쓰라고 명확하게 권장한다. staging은 production과 같은 종류의 limit을 가지지만 값이 훨씬 크다. 예를 들어 계정당 새 order는 3시간에 1,500개, exact set of identifiers는 주당 30,000개까지 허용된다.

Certbot을 쓴다면 공식 안내에 따라 sudo certbot renew --dry-run으로 자동 갱신을 점검할 수 있다. Let's Encrypt 문서는 Certbot에서 staging 테스트를 위해 --test-cert 또는 --dry-run을 사용할 수 있다고 설명한다. 또한 staging과 production의 ACME 계정은 서로 분리되므로 별도 계정이 필요하지만, Certbot이 이 부분을 처리한다고 문서에 적혀 있다.

실무에서는 어떤 예방책이 효과적인가?

1. 배포마다 새 인증서를 발급하지 말고 기존 renewal 흐름을 유지한다.
2. 장애 분석은 먼저 staging에서 재현한다.
3. 검증 실패가 나면 무한 재시도보다 HTTP, DNS, 방화벽, 프록시 구성을 먼저 확인한다.
4. 동일 식별자 집합으로 짧은 시간에 인증서를 반복 생성하지 않는다.
5. 자동 갱신 점검은 Certbot의 renew --dry-run이나 사용 중인 ACME 클라이언트의 테스트 절차로 확인한다.

여기에 더해 계정을 쓸데없이 여러 개로 나누지 않는 것도 중요하다. Let's Encrypt는 대규모 통합 환경에서 하나의 계정을 여러 고객에 재사용하는 설계를 권장한다. 반대로 발급 로직이 분산돼 매번 새 계정을 만들면 계정 생성 limit과 운영 복잡도가 함께 커질 수 있다.

FAQ

Q. rate limit에 걸렸다면 인증서를 revoke하면 바로 다시 발급할 수 있나?

아니다. Let's Encrypt 문서는 인증서 취소가 이미 소비된 발급 자원을 되돌리지 못한다고 설명한다. 따라서 revoke는 보안 대응 수단이지, rate limit 초기화 수단이 아니다.

Q. exact set of identifiers 제한을 피하려고 호스트명을 하나 더 넣으면 되나?

문서상으로는 식별자 집합이 바뀌면 exact set limit은 달라질 수 있다. 다만 이렇게 만든 order는 renewal이 아니라 새 발급으로 취급될 수 있어, account당 새 order 제한과 registered domain 제한을 다시 소모할 수 있다. 임시 우회는 가능해도 기본 운영 전략으로 삼기에는 위험하다.

Q. Certbot 자동 갱신이 설정돼 있는지 어떻게 확인하나?

Certbot 공식 안내는 자동 갱신 명령이 /etc/crontab, /etc/cron.*/*, 또는 systemctl list-timers에 있을 수 있다고 설명한다. 그리고 실제 갱신 동작 테스트는 sudo certbot renew --dry-run으로 확인하라고 안내한다.

정리

Let's Encrypt rate limit은 막연한 정책이 아니라 공개된 수치와 규칙으로 동작한다. 2026년 기준으로 핵심은 새 order 3시간 300개, 등록 도메인 7일 50개, 동일 식별자 집합 7일 5개, 식별자별 authorization 실패 1시간 5회다. 운영에서 중요한 점은 신규 발급과 renewal을 구분하고, 장애 분석은 staging에서 먼저 하며, 반복 재발급과 무한 재시도 루프를 피하는 것이다.

참고 자료

• Let's Encrypt Documentation - Rate Limits
• Let's Encrypt Documentation - Staging Environment
• Let's Encrypt Blog - Shorter Certificate Lifetimes and Rate Limits
• Certbot Instructions for Ubuntu + Nginx