Django 지원 종료 가이드: 2026년의 일정, 위험 요소 및 해결 방안

주요 내용

• Django 3.2, 4.0, 4.1, 5.0 및 5.1은 모두 이미 지원 종료(EOL) 상태이며, Django 4.2가 가장 최근에 지원 종료(EOL) 상태에 도달했습니다.
• 지원 종료(EOL)된 Django 버전을 사용한다고 해서 당장 문제가 발생하는 것은 아니지만, 패치되지 않은 CVE 취약점과 규정 준수 위반 사항이 빠르게 쌓이게 됩니다.
• 조직은 서둘러 마이그레이션을 진행할 것인지, 아니면 보안 위험에 노출될 것인지 둘 중 하나를 선택할 필요가 없습니다. TuxCare는 귀사의 마이그레이션 일정에 맞춰 해당 EOL(지원 종료) Django 버전에 대한 지속적인 취약점 패치 서비스를 제공합니다.

2026년 4월 7일 Django 4.2의 지원 종료( EOL) 시점이 도래했을 때, 많은 운영 환경의 애플리케이션은 아무런 차질 없이 계속 실행되었습니다. 바로 이것이 문제입니다. 지원 종료(EOL)는 기능 자체를 중단시키지는 않지만, Django 프로젝트 측에서 공식적으로 보안 패치 제공을 중단했다는 것을 의미합니다. 이로 인해 4.2 버전은 3.2(2024년 4월 EOL), 4.0(2023년 4월 EOL), 4.1(2023년 12월 EOL), 5.0(2025년 4월 EOL), 5.1(2025년 12월 EOL) 등 다른 버전들과 마찬가지로 취약한 범주에 속하게 됩니다. 이제부터 이 버전들에서 발견되는 취약점은 사용자가 직접 조치를 취하지 않는 한 패치되지 않은 상태로 남게 됩니다.

이 가이드에서는 Django의 지원 종료(EOL)에 대해 알아야 할 모든 사항, 이것이 보안 및 규정 준수에 실제로 어떤 의미를 갖는지, 그리고 모든 업무를 중단하고 주요 버전 업그레이드를 진행할 수 없는 팀을 위한 현실적인 해결 방안을 다룹니다.

Django의 지원 종료(EOL)란 무엇인가요?

모든 Django 버전에는 지원 종료일이 있으며, 이 시점이 지나면 Django 유지보수 팀은 더 이상 해당 버전에 대한 작업을 중단합니다. 보안 업데이트도, 버그 수정도, 그 어떤 지원도 제공되지 않습니다. 이것이 바로 지원 종료입니다.

버전이 EOL(지원 종료) 단계에 도달한다고 해서 애플리케이션이 갑자기 중단되지는 않겠지만, 공급업체의 패치가 제공되지 않으면 보안 위험이 커지고 시간이 지남에 따라 누적됩니다. 예를 들어, 내일 보안 연구원이 Django 4.2에서 SQL 인젝션 취약점을 발견하더라도 패치는 제공되지 않습니다. 이 취약점은 문서화되고 CVE 번호가 할당되지만, 귀하의 버전은 여전히 노출된 상태로 남게 됩니다. 규정 준수 의무가 있는 조직의 경우, 알려진 CVE가 존재함에도 패치가 적용되지 않은 소프트웨어를 환경 내에서 실행하고 있다는 사실 자체가 자동으로 감사 지적 사항으로 기록됩니다.

장고 릴리스 주기 및 지원 종료 일정

Django는 예측 가능한 릴리스 주기를 따르며, 대략 8개월마다 기능 릴리스가 이루어집니다. 각 릴리스는 최종적으로 지원이 종료되기 전까지 두 단계의 보안 지원 기간을 거칩니다.

표준 릴리스(LTS 제외) 8개월간의 활성 지원이 제공되며, 그 후 8개월간은 보안 지원만 제공됩니다. 총 16개월입니다. 그 이후에는 EOL(지원 종료) 상태가 됩니다.

LTS(장기 지원) 릴리스 작동 방식이 다릅니다. 활성 지원 기간은 8개월로 동일하지만, 보안 지원 전용 단계가 28개월로 연장되어 총 지원 기간은 약 3년입니다.

LTS 버전이 아닌 버전을 사용 중이라면, LTS 버전에 비해 업그레이드 기간이 매우 짧습니다. 예를 들어, 2024년 8월에 출시된 Django 5.1은 불과 약 16개월 후인 2025년 12월에 이미 지원 종료(EOL)되었습니다. 이 기간 내에 업그레이드를 진행하지 않은 팀들은 현재 지원이 중단된 소프트웨어를 사용하고 있는 셈입니다.

전문가 팁: 메이저 버전의 마지막 기능 릴리스는 LTS 릴리스가 됩니다. Django 버전 선택 시에는 항상 LTS 릴리스를 기준으로 삼으세요. 3년이라는 기간은 계획된 업그레이드를 위한 실질적인 여유를 제공합니다.

다음은 최근 Django 프로젝트 버전의 현재 현황입니다:

귀사에 미치는 Django 지원 종료(EOL)의 위험

지원 종료(EOL)된 Django 버전을 사용하는 것은 실제 보안 침해 사고처럼 즉각적인 위기는 아닙니다. 하지만 업스트림 지원이 종료되는 순간 위험 수준은 근본적으로 달라지며, 구버전을 계속 사용할수록 상황은 점점 더 악화됩니다.

패치되지 않은 보안 취약점

이건 너무나도 당연한 이야기지만, 실제로 어떤 형태로 나타나는지 구체적으로 살펴볼 필요가 있습니다.
Django는 일관된 CVE 이력을 가지고 있습니다. QuerySet 메서드를 통한 SQL 인젝션, 조작된 XML 입력을 통한 서비스 거부(DoS ), 템플릿 명령어 내의 디렉터리 트래버설, 검증되지 않은 요청 경로를 통한 로그 인젝션 등—이것들은 결코 이론상의 공격 유형이 아닙니다. 이들은 Django의 자체 보안 권고문에 등장한 취약점 패턴들로, 일부는 최근인 2025년에 보고되기도 했습니다. 예를 들어, CVE-2025-57833, CVE-2025-64460, CVE-2025-59682, 그리고 CVE-2025-48432 등이 있습니다.

사용 중인 버전이 지원 종료(EOL) 상태가 되더라도 해당 보안 권고 사항은 여전히 공개됩니다. CVE 번호는 여전히 할당되지만, 수정 패치는 지원 대상 버전에만 제공됩니다. 사용 중인 버전에는 해당 패치가 제공되지 않습니다.

2024년과 2025년만 해도 지원되는 버전 전반에 걸쳐 여러 건의 심각한 보안 문제가 패치된 반면, 3.2.x 및 5.0.x와 같은 지원 종료(EOL) 브랜치는 최근 발표된 여러 보안 권고문에서 영향을 받는 것으로 명시되었으나, 아직 평가되지 않은 상태입니다.

규정 준수 및 감사 실패

EOL 소프트웨어는 규정 준수 측면에서 특정한 문제를 야기합니다. 애플리케이션이 구축된 기반 플랫폼에 보안 업데이트가 제공되지 않는다면, 보안 통제 조치가 적절하다고 주장하기 어렵기 때문입니다.

PCI DSS 6.3.3 조항은 모든 시스템 구성 요소에 해당 보안 패치를 적용하여 알려진 취약점으로부터 보호할 것을 요구합니다. SOC 2 감사관들은 지원 종료(EOL)된 종속성을 점점 더 통제 미비 사항으로 간주하고 있습니다. ISO 27001은 조직이 기술적 취약점을 관리할 것을 요구하며, 지원이 종료된 소프트웨어를 실행하는 것은 해당 요구 사항을 명백히 위반하는 사례입니다.

생태계의 변화와 호환성 격차

지원 종료된 Django 버전은 독립적으로 존재하는 것이 아니라, 전체 기술 스택의 일부로 자리 잡고 있습니다. 그리고 그 스택은 끊임없이 변화합니다. Python 자체에도 릴리스 주기가 있습니다. Django 3.2와 4.0의 기반이 되었던 Python 3.8과 3.9는 이미 지원이 종료되었습니다. Python 3.10에 대한 지원은 2026년 10월에 종료됩니다. 데이터베이스 드라이버, 인증 라이브러리, 클라우드 SDK 등 모든 구성 요소는 결국 구버전 Python과 Django에 대한 지원을 중단하게 됩니다. 그 결과, 스택을 유지 관리하기가 점점 더 어려워집니다. 이는 모든 것이 한꺼번에 고장 나기 때문이 아니라, 현재 위치와 생태계가 이동한 지점 사이의 격차가 계속 벌어지기 때문입니다.

오늘날 사소해 보이는 종속성 충돌은 시간이 지날수록 누적되어 결국 시스템 유지보수를 악몽 같은 상황으로 만들곤 합니다. 어떤 라이브러리가 다음 주요 릴리스에서 Django 4.2 지원을 중단할 수도 있고, 보안 패치를 적용하려면 지원 종료(EOL)된 Django 버전이 지원하지 않는 Python 버전이 필요할 수도 있습니다. 이는 극단적인 사례가 아닙니다. 종속성을 제때 업데이트하지 않는 모든 애플리케이션이 겪게 되는 일반적인 과정일 뿐입니다.

증가하는 유지보수 부담

위협 모델에는 나타나지 않지만 엔지니어링 작업 시간에는 매우 명확하게 드러나는 사실이 하나 있습니다. 바로 EOL(지원 종료) 버전을 계속 사용할수록 유지 비용이 점점 더 많이 든다는 점입니다.

업스트림 패치가 없다면, 팀은 보안 취약점에 노출되는 위험을 감수하거나 직접 패치 작업을 수행해야 합니다. 즉, CVE 피드를 모니터링하고, 각 취약점이 특정 구성에 영향을 미치는지 평가하며, 지원되는 브랜치에서 수정 사항을 백포트하고, 테스트를 거쳐 배포해야 합니다. 이는 상당한 업무 부담이며, 사용 중인 버전과 최신 릴리스 간의 격차가 커질수록 시간이 지남에 따라 더욱 가중됩니다. 버전 간에 호환성 문제가 누적되기 때문입니다. 원래는 관리 가능한 마이그레이션이었을 수도 있는 작업이, 실질적인 위험이 따르는 대규모 프로젝트로 변모하게 됩니다.

Django 버전이 지원 종료(EOL)된 경우 어떻게 해야 할까요?

Django의 지원 종료(EOL) 버전을 사용한다고 해서 선택의 여지가 없는 것은 아닙니다. 이는 신중하게 하나를 선택해야 한다는 뜻입니다. 아무것도 하지 않는 것 또한 하나의 선택이지만, 이는 가장 큰 위험을 수반하는 선택이기 때문입니다.

현실적으로 고려할 수 있는 세 가지 방법이 있습니다. 어떤 방법이 타당한지는 코드베이스, 팀의 역량, 그리고 규정 준수나 보안상의 압박으로 인해 이 문제가 시급해지기 전까지 얼마나 시간이 남아 있는지에 따라 달라집니다.

지원되는 버전으로 업그레이드

가장 깔끔한 방법이자 대부분의 팀에게 적합한 장기적인 해결책은 지원되는 Django 릴리스로 업그레이드하는 것입니다. 현재로서는 2028년 4월까지 지원되는 Django 5.2 LTS나, 2027년 4월까지 지원되는 최신 버전인 Django 6.0 중 하나를 선택하는 것을 의미합니다.

말로는 쉽죠. 하지만 어려운 점은, 수많은 운영 환경, 특히 수년 동안 3.2나 4.2 버전을 사용해 온 환경의 경우, 업그레이드가 주말에 끝낼 수 있는 일이 아니라는 점입니다.

사용 중단된 API는 메이저 버전 간에 제거됩니다. 타사 패키지는 호환성을 유지하지 않았을 수도 있습니다. 이전 버전에서는 충분해 보였던 테스트 커버리지도, 버전 이동을 시작하면 때때로 누락된 부분이 드러나기도 합니다. 또한 여러 버전을 건너뛰어 업그레이드하는 경우(예를 들어 3.2에서 바로 5.2로 이동하는 경우)에는 한 번에 여러 번의 사용 중단 주기를 겪게 됩니다.

확장 보안 지원 사용

갑작스러운 업그레이드 대응이 어려운 팀들(그럴 만한 타당한 이유가 많겠지만)에게, TuxCare의 Django용 Endless Lifecycle Support(ELS)는 필수적인 보안 가교 역할을 합니다.

TuxCare 팀은 지원 종료(EOL)된 Django 버전에 영향을 미치는 CVE를 추적하고, 업스트림의 수정 사항을 백포트하여 패치를 테스트 및 검증한 후, TuxCare 저장소를 통해 제공합니다. 고객 측에서는 코드 변경, 마이그레이션 작업, 수동 CVE 분류 작업이 전혀 필요하지 않습니다.

TuxCare는 현재 지원 종료(EOL)된 다수의 Django 버전(3.2.25, 4.0, 4.2.22, 5.0, 5.0.1, 5.0.2, 5.1, 5.1.4, 5.1.9 및 5.1.10 포함)을 광범위하게 지원하며, 공식 EOL 날짜 이후에도 필요한 기간 동안 지원을 계속 제공합니다. ELS는 지원 기간 만료라는 강제적인 일정에 얽매이지 않고, 팀에 적합한 일정에 맞춰 업그레이드를 진행하는 동안에도 패치를 적용하고 규정 준수를 유지할 수 있는 실용적인 방법을 제공합니다.

CVE 트래커를 방문하시면 지원되는 모든 EOL 버전에서 어떤 취약점이 확인되었는지 살펴볼 수 있으며, TuxCare의 ELS 패치가 제공되고 배포 준비가 완료되었는지 확인할 수 있습니다.

임시 위험 완화 조치 적용

일부 팀은 대개 매우 촉박한 일정 압박 속에서 취약점 패치 대신 보완적 통제 조치를 통해 EOL(제품 수명 주기 종료) 관련 위험을 관리하려 합니다. 예를 들어:

• 알려진 공격 경로를 차단하기 위한 WAF 규칙
• 노출을 제한하기 위한 네트워크 분할
• 모니터링 및 이상 탐지 기능 강화
• 애플리케이션 계층에서의 더 엄격한 입력 검증

이러한 조치들은 공격 표면을 줄일 수 있습니다. 하지만 이를 완전히 제거할 수는 없으며, 이 조치들만으로는 대부분의 규정 준수 요건을 충족시키지 못합니다. 특정 CVE 악용 패턴을 차단하도록 작성된 WAF 규칙은 공격이 해당 패턴을 따를 때만 효과가 있는데, 공격자들이 항상 그 패턴을 따르는 것은 아닙니다.

전문가 팁: 이 옵션을 몇 달이 아닌 몇 주 단위의 '가교'로 생각하십시오. 적절한 업그레이드를 위한 시간을 벌거나 ELS를 구현하기 위해 완화 조치를 사용하는 것이라면, 이는 합리적인 단기 대응책입니다. 하지만 논의를 아예 피하기 위해 이를 이용한다면, 위험은 그저 계속 쌓여갈 뿐입니다.

Django 지원 종료(EOL) 이후 아무런 조치를 취하지 않으면 어떻게 될까요?

이건 엄밀히 말해 선택지가 아니지만, 팀이 적극적인 결정을 내리지 않을 때 기본적으로 일어나는 일입니다.

애플리케이션은 계속 가동됩니다. 아무도 업그레이드를 계획하지 않습니다. CVE는 조용히 쌓여만 갑니다. 그리고 눈에 띄는 오류가 발생하지 않기 때문에, 감사 실패나 보안 사고, 혹은 갑자기 엄격하게 적용되는 규정 준수 요건과 같은 외부 요인이 개입하기 전까지는 그 시급성이 제대로 실감되지 않습니다.

여기서 문제점은 보안 취약점이 눈에 띄지 않게 점차 누적된다는 점입니다. 패치가 적용되지 않은 지원 종료(EOL) 버전을 한 달 더 사용할 때마다, 애플리케이션이 노출되는 CVE(공통 취약점 및 노출)는 한 달 더 늘어나고, 소프트웨어 자산 목록이 리스크 요인이 되는 감사 주기도 한 번 더 반복되며, 현재 버전과 향후 마이그레이션해야 할 버전 사이에서 발생하는 호환성 문제도 한 달 더 쌓이게 됩니다. 즉, 단순히 업그레이드를 미루는 것이 아니라, 결국 피할 수 없이 강제로 진행해야 할 마이그레이션의 난이도와 비용을 자신도 모르게 높여가고 있는 셈입니다.

TuxCare와 함께 Django 지원 종료 후에도 보안과 규정 준수를 유지하세요

실전 환경의 Django 애플리케이션을 업그레이드하는 데는 시간이 걸리며, 때로는 상당한 시간이 소요되기도 합니다. 그동안 보안 취약점은 개발 주기가 따라잡을 때까지 기다려주지 않습니다.

TuxCare의 Django ‘Endless Lifecycle Support’는 한 가지 실질적인 문제를 해결하기 위해 마련되었습니다. 바로 지원 종료(EOL)된 Django 버전을 운영 중인 조직들이, 단순히 일정이 그렇게 정해져 있어서가 아니라 코드베이스 자체의 요구 사항 때문에 마이그레이션 계획을 수립하는 동안에도 패치를 적용하고 규정 준수를 유지해야 하는 상황입니다.

현재 TuxCare의 ELS에서 지원하는 Django 버전에는 3.2.25, 4.0, 4.2.22, 5.0, 5.0.1, 5.0.2, 5.1, 5.1.4, 5.1.9 및 5.1.10이 포함됩니다.

또한, 스택 내에서 Django가 EOL( 지원 종료) 상태인 유일한 구성 요소인 경우는 거의 없습니다. EOL 상태인 Django 애플리케이션이 EOL 상태인 Python 런타임 위에서 구축되거나, 지원이 종료된 Linux 배포판에서 호스팅되는 경우가 흔합니다. TuxCare는 ‘Endless Lifecycle Support’를 통해 EOL 상태인 Python 런타임, 오픈소스 라이브러리 및 Linux 배포판에 대한 지원도 제공합니다.

Django 지원 종료(EOL)에 관한 자주 묻는 질문

요약

기사 이름

Django 지원 종료 가이드: 2026년의 일정, 위험 요소 및 해결 방안

설명

Django의 지원 종료(EOL) 일정, 지원되는 버전, 라이프사이클 정책, 보안 위험 요소를 확인하고, 현재 사용 중인 버전이 지원 종료되기 전에 안전하게 업그레이드하는 방법을 알아보세요.

작성자

로한 티말시나

게시자 이름

TuxCare

게시자 로고