Starlette 지원 종료: 서두르지 않고도 보안을 유지하세요

이 블로그 글의 AI 요약으로 바로 가기

주요 내용

Starlette는 지원 주기를 공개하지 않으며 구버전 릴리스 브랜치를 유지 관리하지 않기 때문에, 보안 수정 사항은 백포트되지 않고 최신 릴리스에 반영됩니다. 따라서 여전히 구버전에 고정된 모든 ASGI 애플리케이션은 프로덕션 환경에서도 해당 보안 취약점에 노출된 상태로 운영됩니다.
공황에 휩싸여 서둘러 이전을 진행하면 미들웨어 스택이 파손되고, 비동기 호환성 문제가 발생하며, 시스템이 불안정해지고, 예산이 초과되는 결과를 초래할 수 있어, 이 경우 임시 연장 지원이 더 예측 가능한 선택지가 될 수 있습니다.
TuxCare의 ‘Endless Lifecycle Support’와 같은 확장 지원 옵션을 이용하면, 취약점 스캐너가 정한 일정이 아닌 사용자가 직접 정한 일정에 따라 업그레이드를 계획하는 동안에도 지원 종료된 Starlette 버전에 대한 지속적인 보안 지원을 받을 수 있습니다.

비동기 Python 서비스를 구축하고 있다면, 여러분이 인지하고 있든 아니든 Starlette가 스택 어딘가에 포함되어 있을 가능성이 높습니다. ASGI 프레임워크로 직접 실행되고 있을 수도 있습니다. 하지만 더 가능성이 높은 것은, Starlette가 2년 전 팀이 구축한 FastAPI 애플리케이션을 뒤에서 조용히 뒷받침하고 있을 것이라는 점입니다. 이 애플리케이션은 인증, 파일 업로드, 혹은 내부 툴의 절반을 처리하고 있을 것입니다. 어느 쪽이든, Starlette의 지원이 종료되면 그 영향은 이론적인 차원을 넘어 현실이 될 것입니다.

많은 팀이 Starlette가 자사의 의존성 트리에 포함되어 있다는 사실조차 인지하지 못하고 있습니다. 직접 설치되었든 FastAPI를 통해 간접적으로 포함되었든, Starlette는 너무나도 조용히 제 역할을 수행하기 때문에 CVE 공개나 보안 감사가 이루어지기 전까지는 배경으로 사라져 버립니다.

그럼 스타렛(Starlette)의 0.x 계열이 종료되는 것이 여러분의 운영 환경에 어떤 의미를 갖는지, 그리고 무엇보다도 엔지니어링 로드맵을 뒤엎지 않으면서 현실적으로 어떤 조치를 취할 수 있는지에 대해 이야기해 봅시다.

스타렛 출시 방식은 실제로 어떻게 이루어지는가

“자, 그럼 이제 어떻게 해야 할까”라는 부분으로 넘어가기 전에, Starlette가 버전 라이프사이클을 어떻게 관리하는지 이해해 두는 것이 도움이 됩니다. 여러분이 예상하는 방식과는 약간 다르기 때문입니다.

Starlette는 2018년 6월 Kim Christie에 의해 개발되었으며, 커뮤니티에서 흔히 “ZeroVer”라고 부르는 0.x 버전 계열로 수년간 유지되었습니다. 현재 이 라이브러리는 하루에 1,000만 회 가까이 다운로드되고 있으며, FastAPI의 기반이 되고 있고, Python MCP SDK의 의존성으로도 사용되고 있습니다. 하지만 거의 8년 동안 이 라이브러리는 0.x.y 버전으로 배포되었는데, 이는 공식적인 비추천 주기나 LTS(장기 지원) 지정, 버전 번호와 연계된 지원 종료 정책이 공개되지 않았음을 의미했습니다. 프로젝트는 계속 업데이트되었지만, 오래된 릴리스들은 단순히 더 이상 관심을 받지 못하게 되었습니다.

2026년 3월 22일, 2월에 릴리스 후보 버전을 거친 후 Starlette가 1.0.0에 도달하면서 상황이 바뀌었습니다. 이는 진정한 이정표였습니다. 수년 동안 사용이 중단된 API가 제거되고, 프로젝트의 방향성이 공식화되었으며, 마침내 시맨틱 버저닝이 도입되었습니다. 그 이후 1.x 계열은 1.0.1, 1.1.0, 1.2.x를 거쳐 2026년 6월 1.3.1까지 꾸준히 업데이트되어 왔으므로, 현재 업그레이드 대상은 1.0.0 자체가 아니라 최신 1.x 릴리스입니다.

아직 0.x 버전을 사용 중인 분들에게 중요한 점은 다음과 같습니다. Starlette는 지원 주기를 공개하지 않으며, 구버전 릴리스 브랜치를 유지 관리하지 않습니다. 수정 사항은 최신 릴리스를 통해 제공됩니다. 따라서 더 이상 지원되지 않는 0.x 버전을 사용 중이라면, 실질적인 문제는 공식 지원 종료(EOL) 날짜가 지났는지 여부가 아니라, 고정해 둔 버전으로 보안 수정 사항이 역포트될 것으로 기대할 수 있는지 여부입니다. 기대해서는 안 됩니다.

또한 수많은 프로덕션 애플리케이션이 FastAPI의 호환 버전 범위를 통해, 종종 간접적으로 특정 0.x 버전에 고정되어 있습니다. 한동안 종속성 파일을 검토하지 않은 팀들은 상당히 뒤처져 있을 수 있습니다. 구버전 FastAPI 릴리스에서 매우 흔히 볼 수 있는 Starlette 0.27.0에 고정된 애플리케이션은 0.50.0보다 20개 이상의 마이너 릴리스가 뒤처져 있으며, 문서화된 두 건의 보안 수정 사항이 적용되기 전 버전에 해당합니다.

LTS(장기 지원) 버전을 제공하는 Node.js나, 5년간의 지원 기간이 공식적으로 명시된 CPython과 달리, Starlette에는 의존할 수 있는 유지보수 브랜치가 없습니다. 실제로 수정 사항은 사용자가 실행 중인 버전을 통해서가 아니라, 새로운 릴리스를 통해 제공됩니다.

Starlette EOL이 귀하의 생산 환경에 실제로 어떤 의미를 갖는지

좋아요, 어떤 버전이 더 이상 주목을 받지 못하고 있다고 가정해 봅시다. ASGI 앱은 여전히 실행 중이고, 요청도 들어오고 있으며, 모든 것이 정상으로 보입니다. 굳이 걱정할 필요가 있을까요?

업스트림의 관심이 다른 곳으로 옮겨가더라도 취약점이 계속 발견되기 때문입니다. 공격자들은 사용자의 엔드포인트를 탐색하기 전에 Starlette 변경 내역을 일일이 대조해 보지 않으며, 보안 연구원들은 널리 배포된 버전, 특히 대다수의 파이썬 웹 애플리케이션에서 기반이 되는 버전에서 계속해서 문제를 발견하고 있습니다.

이전 버전의 Starlette는 이미 여러 건의 심각도가 높은 문제들로 인해 타격을 입었으며, 이러한 패턴이 충분히 일관되게 나타나고 있어 여전히 해당 버전을 사용 중인 사용자라면 누구나 우려할 만합니다.

CVE-2024-47874 (CVSS 4.0: 8.7, 높음): 0.40.0 이전의 모든 Starlette 버전에 영향을 미치는 서비스 거부(DoS) 취약점입니다. 이 문제는 Starlette가 multipart/form-data 파일명이 포함되지 않은 부분을 처리하는 방식에 있습니다. 이러한 부분은 텍스트 필드로 간주되어 크기 제한 없이 메모리에 버퍼링됩니다. 공격자는 임의로 큰 양식의 필드를 전송하여 Starlette가 과도한 할당 및 복사 작업으로 인해 메모리를 소진하도록 만들 수 있습니다. 이러한 요청을 여러 개 동시에 전송하면, 리버스 프록시가 전체 요청 크기 제한을 적용하고 있는 경우에도 서비스를 사실상 사용할 수 없게 만들 수 있습니다. 이 취약점은 Starlette 또는 FastAPI를 기반으로 구축되어 폼 요청을 수락하는 모든 애플리케이션에 영향을 미치며, 그 영향 범위가 매우 광범위합니다. 0.40.0 버전에서 수정되었습니다.

CVE-2025-62727 (CVSS 3.1: 7.5, 높음): Starlette 0.39.0부터 0.49.0까지에 영향을 미치는 서비스 거부(DoS) 취약점입니다. 인증되지 않은 공격자는 Starlette의 FileResponse 범위 구문 분석 및 병합 로직에서 2차 시간 복잡도의 처리를 유발하는 조작된 HTTP Range 헤더를 전송할 수 있습니다. 각 악의적인 요청은 비정상적으로 많은 CPU 시간을 소모하며, 반복적이거나 동시적인 요청은 StaticFiles 또는 FileResponse를 사용하는 모든 엔드포인트를 포함하여 파일을 제공하는 모든 엔드포인트의 가용성을 저하시킬 수 있습니다. 0.49. 를 직접 사용하는 경우를 포함하여, 파일을 제공하는 모든 엔드포인트의 가용성을 저하시킬 수 있습니다. 0.49.1 버전에서 수정되었습니다.

이 두 가지가 전부는 아닙니다. Starlette 0.27.0에서는 StaticFiles에서 경로 트래버설 취약점을 수정했으며, 0.25.0 버전에서는 요청에 포함될 수 있는 멀티파트(multipart) 파트 수에 제한을 추가했습니다. 해당 릴리스보다 이전 버전으로 고정된 경우, 오늘날에도 여전히 이러한 문제가 남아 있습니다.

이는 극히 드문 사례나 이론상의 취약점이 아니며, Starlette에만 국한된 문제도 아닙니다. IBM은 Maximo Application Suite, App Connect Enterprise Certified Container, Planning Analytics Workspace 등 취약한 Starlette 버전이 포함된 제품에 대한 보안 공지를 발표했습니다. vLLM의 경우, 기여자들은 프로젝트가 CVE-2025-62727의 영향을 받는 범위 내에 있는 0.46.2 버전으로 고정되어 있음을 발견한 후, 긴급한 종속성 버전을 업데이트할 것을 요청하는 이슈를 제기했습니다.

자, 이 두 CVE에 대한 솔직한 해석은 이렇습니다. 두 문제 모두 0.x 버전이 아직 활성 버전이던 시절에 업스트림에서 수정되었습니다. 바로 그게 핵심입니다. 이 수정 사항은 사용자가 고정해 둔 버전으로 백포트된 것이 아니라, 더 새로운 0.x 릴리스에 포함되어 제공되었으며, 이제 개발이 1.x로 넘어간 만큼 다음 취약점 공개 시에는 1.x에서 수정될 것입니다. 더 이상 지원되지 않는 릴리스의 경우, 새로 공개된 취약점은 사용자가 업그레이드하거나, 직접 수정 사항을 백포트하거나, 다른 곳에서 패치를 적용받을 때까지 계속 노출된 상태로 남아 있습니다.

준수 프레임워크는 이러한 격차에 대해 명확한 입장을 제시하고 있습니다. PCI DSS v4.0.1(요구사항 6.3.3)은 중요한 보안 패치를 출시 후 1개월 이내에 설치할 것을 요구하며, 그 외의 취약점은 문서화된 위험 등급 평가 절차에 따라 정해진 일정에 따라 처리해야 합니다. 또한, 지원이 중단된 구성 요소는 SOC 2 심사 과정에서 취약점 관리 및 통제 조치의 효과성에 대한 의문을 제기할 수 있으며, 이에 대해 명확한 답변보다는 문서화된 위험 대응 방안과 보완 통제 조치가 요구될 수 있습니다.

숨겨진 위험: 의존성 스택

이 문제는 Starlette의 자체 코드에만 국한되지 않습니다. 가장 주의를 기울여야 할 종속성은 python-multipart입니다. Starlette의 양식 파싱은 실제로 이 라이브러리를 기반으로 실행됩니다. 이 라이브러리 자체에도 서비스 거부(DoS) 취약점인 CVE-2024-53981(CVSS 4.0: 8.7, 고위험)이 있었으며, 이는 0.0.18 버전에서 수정되었습니다. 반면 Starlette는 0.42.0 릴리스에서야 최소 요구 버전을 0.0.18로 상향 조정했습니다. 만약 사용 중인 버전이 이보다 낮다면, 해결된 파서 버전이 수정 사항이 적용되기 전 버전일 가능성이 높습니다. 템플릿용 Jinja2와 세션 쿠키 서명용 itsdangerous도 같은 범주에 속합니다. 이들은 각각 자체 보안 권고 사항을 가지고 있는 선택적 추가 구성 요소이지만, 많은 팀이 이를 별도로 점검하지 않는 경우가 많습니다.

AnyIO와 typing-extensions는 별개의 문제입니다. 두 가지 모두 CVE에서 큰 비중을 차지하지 않으며, typing-extensions는 최근 릴리스에서 파이썬 3.10 이전 버전에서만 사용됩니다. 구버전 Starlette 릴리스는 사용자가 해결할 수 있는 해당 패키지의 버전을 제한합니다. 이로 인해 취약점이 발생하는 것은 아니지만, 문제 해결 과정을 복잡하게 만듭니다. 즉, 프로젝트 트리 내의 다른 문제를 수정하기 위해 더 새로운 릴리스가 필요한데, 고정된 Starlette가 이를 허용하지 않는 경우, 결국 다른 사람의 일정에 맞춰 어쩔 수 없이 Starlette를 업그레이드하게 됩니다.

이 작업은 10분이 소요됩니다. 다음 명령을 실행하세요. pip list 를 실행하거나(또는 lockfile을 확인하여) python-multipart, jinja2, 그리고 itsdangerous의 해결된 버전을 확인하십시오.를 포함하며, 단순히 Starlette 자체의 버전만 해당되는 것은 아닙니다.

스타렛의 수명이 다했을 때의 선택지

그러니까 귀하의 ‘스타렛’ 버전은 이미 구식이 되었거나, 그 방향으로 가고 있는 셈이군요. 현실적으로 어떤 대안이 있을까요?

세 가지 옵션이 있으며, 어떤 옵션을 선택할지는 애플리케이션 규모, 테스트 커버리지, 파이썬 버전, 마이그레이션 일정, 그리고 위험 수용 수준에 따라 달라집니다. 그중 두 가지는 실질적인 계획 수립, 비용, 그리고 위험을 수반합니다. 세 번째 옵션인 ‘확장 지원’은 즉각적인 업그레이드가 현실적으로 어려운 경우, 당분간 보안 범위를 확보할 수 있게 해줍니다.

옵션 1: 지원되는 Starlette 1.x 릴리스로 업그레이드

업스트림에서 권장하는 해결책은 현재 지원되는 Starlette 1.x 릴리스로 업그레이드하고, 적극적인 보안 지원을 받으며, 향후 적절한 버전 관리 체계를 통해 혜택을 누리는 것입니다.

그리고 Starlette 1.x는 확실히 더 나아졌습니다. 이 프로젝트는 수년에 걸쳐 쌓인 더 이상 사용되지 않는 API를 제거하고, 안정적인 의미론적 버전 관리 체계를 도입했으며, 그 이후로도 지속적으로 수정 사항을 제공해 왔습니다. 1.0.1 버전은 형식이 잘못된 Host 헤더를 올바르게 처리합니다. request.url을 생성할 때 형식이 잘못된Host헤더를 처리하며, 1.1.0은 StaticFiles.lookup_path에서 절대 경로를 허용하지 않으며, 1.3.1 버전에서는 max_fields 및 max_part_size를 적용합니다. 를 적용합니다. 새로 시작하는 팀이든 기존 코드베이스를 유지 관리하는 팀이든, 이는 분명히 장기적으로 나아가야 할 올바른 방향입니다.

하지만 구버전인 0.x 릴리스에 고정된 운영 환경 애플리케이션을 업그레이드하려면 다음과 같은 모든 문제를 해결해야 합니다:

제거된 데코레이터: the @app.route(), @app.websocket_route(), @app.exception_handler(), 그리고 @app.middleware() 데코레이터는 더 이상 사용되지 않습니다. 라우트는 Route 및 WebSocketRoute 항목으로 이동했습니다. routes 매개변수 내의 Route 및 WebSocketRoute 항목은 exception_handlers 및 middleware 매개변수로 이동합니다. 경로와 미들웨어 등록이 많은 대규모 애플리케이션의 경우, 이로 인해 많은 파일에 영향을 미치게 됩니다.

제거된 라이프사이클 API: 다음 on_startup 및 on_shutdown 매개변수, @app.on_event() 데코레이터, add_event_handler(), 그리고 Router.startup()/Router.shutdown() 가 모두 제거되었습니다. 이 함수들을 사용하던 애플리케이션은 lifespan 인터페이스로 마이그레이션해야 합니다.

템플릿 변경 사항: Jinja2Templates 는 더 이상 **env_options 를 더 이상 허용하지 않습니다( env 를 통해 전달), 기존의 TemplateResponse(name, context) 서명이 사라졌으며, 이제 클래스를 임포트하려면 를 설치해야만 해당 클래스를 임포트할 수 있으며, 자동 이스케이프 기능이 기본적으로 활성화되어 있습니다.

세션 처리 관련 변경 사항: Starlette 1.0에서는 SessionMiddleware에서 세션 액세스 및 수정 추적 기능을 추가했습니다. 이로 인해 반드시 문제가 발생한다고 보장할 수는 없지만, 애플리케이션에 민감한 세션 동작이 포함되어 있다면, 단순히 가정하지 말고 세션 흐름을 회귀 테스트 계획에 포함시키십시오.

실행 환경 요구 사항: Starlette 1.x는 Python 3.10 이상이 필요합니다. Python 3.9 지원은 0.50.0 버전에서, 3.8 지원은 0.45.0 버전에서 중단되었습니다. 현재 이 두 버전 중 하나를 사용 중이라면, 먼저 런타임 업그레이드를 진행해야 하며, 이는 더 광범위한 의존성 구조에 대한 호환성 문제를 수반합니다. 게다가 이 두 Python 버전은 이미 지원 종료(EOL) 상태이므로, 이는 하나의 문제가 아닌 두 가지 문제가 중첩된 상황입니다.

FastAPI 호환성 문제: FastAPI를 사용 중이라면, 업그레이드 과정이 단순히 requirements 파일에서 Starlette 버전을 올리는 것만큼 간단하지 않습니다. FastAPI는 호환되는 Starlette 버전 범위를 명시하고 있으므로, 대개 두 라이브러리를 동시에 업그레이드하고 애플리케이션 코드에서 두 라이브러리가 모두 예상대로 작동하는지 확인해야 합니다.

작고 충분히 검증된 애플리케이션의 경우, 이는 집중적인 스프린트가 될 것입니다. 반면, 방대한 미들웨어와 복잡한 세션 처리, 수년에 걸쳐 축적된 패턴을 갖춘 대규모 시스템의 경우, 신중한 계획과 철저한 테스트가 필요하며, 실제 운영 부하 하에서 미묘한 회귀 현상이 발생할 위험이 실제로 존재합니다.

옵션 2: 다른 프레임워크로 마이그레이션

일부 팀은 단종된 스타렛 모델을 보며 “어쩌면 지금이 재고해 볼 때일지도 모른다”고 생각합니다.

Starlette만 단독으로 사용 중이라면 FastAPI를 고려해 볼 만합니다. FastAPI는 이미 의존하고 있는 동일한 기반 위에 유효성 검사 및 직렬화 기능을 추가해 줍니다. Litestar는 설계 철학이 다른 또 다른 최신 ASGI 프레임워크입니다. 더 광범위한 아키텍처 전환을 검토 중인 팀에게는 실질적인 선택지가 있습니다.

하지만 프레임워크 마이그레이션이 무엇을 수반하는지 과소평가해서는 안 됩니다. 새로운 프레임워크의 API에 맞춰 라우트 핸들러를 다시 작성해야 할 수도 있고, 미들웨어와 예외 처리(프레임워크마다 차이가 매우 큽니다)를 리팩토링해야 하며, 테스트 인프라를 업데이트하고, ASGI 서버 구성이 여전히 정상적으로 작동하는지 확인해야 할 뿐만 아니라, 대체 시스템이 구축되는 동안 기존 시스템을 계속 가동해야 할 수도 있습니다.

장기적인 아키텍처적 이점은 그 투자 비용을 정당화할 수 있습니다. 하지만 특히 애플리케이션에 프레임워크 특유의 동작이 많이 포함되어 있는 경우, 소요 기간과 비용이 초기 예상치를 훨씬 초과할 수 있습니다. 또한 마이그레이션이 진행되는 동안 프로덕션 환경이 여전히 구버전을 사용하는 기간은, 바로 여러분이 해소하고자 했던 보안 취약 기간과 정확히 일치합니다.

옵션 3: 타사 연장 지원

이 문제에 대해 충분히 주목받지 못하고 있는 세 번째 방법이 있습니다. 바로 이 문제를 전문으로 다루는 기업들이 제공하는 확장 보안 지원입니다.

TuxCare는 지원이 종료된 Starlette 버전에 대해 ‘무기한 라이프사이클 지원’을 제공합니다. 준비가 되지 않은 상태에서 강제로 마이그레이션을 진행하거나, 마이그레이션을 계획하는 동안 애플리케이션을 보안 취약점에 노출시키는 대신, 지속적인 보안 패치 지원을 받으며 현재 버전을 계속 운영할 수 있습니다.

이 논리는 간단합니다. 바로 ‘시간’과 ‘주도권’을 확보할 수 있다는 점입니다. 로드맵에 맞춰 신중하게 업그레이드를 계획할 시간을 확보할 수 있습니다. 또한, 최악의 시점에 어쩔 수 없이 조치를 취해야 하는 CVE 공개에 휘둘리지 않고, 마이그레이션 일정을 스스로 주도할 수 있습니다.

그러니까 구체적으로 말하자면:

만약 0.4x 버전을 사용 중이고, 이미 Python 3.10 이상을 사용하며, 테스트 커버리지가 양호하고 사용자 정의 미들웨어가 소수에 불과하다면, 그렇다면 지금 바로 최신 1.x 버전으로 업그레이드하세요. 이는 프로젝트가 아니라 단숨에 끝낼 수 있는 작업입니다.

만약 Python 3.8 또는 3.9를 기반으로 하는 0.2x 또는 0.3x 릴리스를 사용 중이라면, 그 경우 먼저 런타임 업그레이드를 진행한 후, 그 과정에서 보안 취약점을 해결하기 위해 확장 지원 기능을 활용하십시오.

만약 이미 다른 프레임워크로 플랫폼을 전환하기로 결정했다면, 그렇다면 두 분기 동안 보안 취약점에 노출된 상태로 운영하기보다는, 확장 지원 서비스를 활용하여 마이그레이션 기간을 커버하십시오.

만약 규정 준수 마감일이 몇 주 남았고 마이그레이션은 몇 달 뒤라면, 그렇다면 연장 지원이 두 가지 조건을 모두 충족하는 유일한 선택지이며, 이후에는 본인의 일정에 맞춰 업그레이드하면 됩니다.

스타렛(Starlette) EOL 업그레이드를 서두를 때 발생하는 실제 비용

보안 대시보드에서 지원 종료 경고가 마침내 임계치에 도달하자, 팀들이 생산 환경의 ASGI 애플리케이션을 당황한 나머지 서둘러 마이그레이션할 때 어떤 일이 벌어지는지 이야기해 봅시다.

FastAPI 0.95와 Starlette 0.36을 사용하며, 기반 언어는 Python 3.9이고, 180개의 라우트와 4개의 사용자 정의 미들웨어를 갖춘 40명 규모의 SaaS 팀이 3주 안에 규정 준수 기한을 맞춰야 하는 상황을 상상해 보세요. 업그레이드 일정이 이 짧은 기간으로 압축되면, 예상 가능한 문제들이 발생하기 마련입니다:

지원 부담 증가: 테스트 단계에서는 드러나지 않았던 미묘한 동작 변화가 실제 운영 환경에서 나타나기 시작합니다. 마침내 제거된 비추천 API, 이제 다르게 동작하는 세션 처리의 극단적인 사례, 테스트 스위트에서 다루지 않았던 미들웨어 상호작용 등이 그 예입니다. 지원 팀은 티켓으로 넘쳐나게 되고, 그중 절반은 마이그레이션과 관련이 있는 것으로 밝혀집니다.

시스템 불안정성: 비동기 호환성 문제는 디버깅하기가 정말 까다롭습니다. 이전 AnyIO 버전에서는 문제없이 작동하던 의존성이 부하가 걸리면 미묘한 타이밍 차이를 보일 수도 있습니다. 요청 라이프사이클이 변경되면 미들웨어 체인의 동작이 달라질 수도 있습니다. 바로 이러한 문제들이 한밤중 경보를 유발하고, 당직 엔지니어들을 매우 불쾌하게 만드는 원인이 됩니다.

기술적 부채의 누적: 규정 준수를 서두르다 보니, 제대로 된 리팩토링은 미뤄지게 됩니다. “나중에 정리하자”는 코멘트와 함께 호환성 쉴드가 추가됩니다. 마이그레이션 6개월 후, 기술적으로는 1.x 버전을 사용 중이지만, 아무도 해결할 시간이 없는 우회 조치로 가득 찬 코드베이스를 운영하게 됩니다.

예산 초과: 당초 예상 기간은 2주였습니다. 5주가 지났지만 여전히 회귀 버그를 추적하고 있습니다. 지원을 위해 투입된 외주 업체는 여전히 비용을 청구하고 있습니다. 기능 구현 일정은 연기되었습니다. 시니어 엔지니어들이 새로운 기능을 개발하는 대신 비동기 미들웨어 상호작용의 디버깅에 매달리는 데 따른 기회 비용은 빠르게 누적되고 있습니다.

업그레이드는 올바른 장기적 해결책입니다. 규정 준수 압박에 쫓겨 서둘러 진행하는 업그레이드는 명백하고 전적으로 예측 가능한 실패 사례입니다. 이 두 가지는 전혀 다른 것입니다.

업그레이드를 계획하는 동안 Starlette의 안정성 유지: TuxCare의 무한 라이프사이클 지원

바로 이 점에서 TuxCare의 Starlette용 ‘무한 라이프사이클 지원(ELS)’이 판도를 바꾸는 것입니다.

TuxCare는 10년이 훨씬 넘는 기간 동안 기업 생산 환경 전반에 걸쳐 지원이 종료된 운영 체제, 런타임, 라이브러리 및 애플리케이션 프레임워크에 대한 보안 패치를 제공해 왔습니다.

TuxCare의 접근 방식이 다른 점은 무엇인가요?

의존성 스택 지원 범위: TuxCare는 Starlette에만 패치를 적용하는 것이 아닙니다. 추가 비용 없이 Starlette의 직접 및 전이적 종속성까지 지원 범위가 확장되는데, ASGI 스택에서 문제가 발생할 가능성이 더 높은 원인은 여러 계층 아래에 위치한 폼 파서나 템플릿 엔진인 점을 고려할 때 이는 매우 중요한 사항입니다.

전문가의 검증을 거친 자동 패치 적용: TuxCare는 NVD, 벤더 보안 권고문 및 GitHub 보안 권고문을 통해 24시간 내내 CVE를 추적합니다. 관련 CVE가 발견되면, 알고리즘 및 AI 기반 자동화 기술을 활용하여 수정 사항을 백포트하고 전문가의 검증을 거친 후, 무결성, 기능 및 회귀 현상에 대한 테스트를 수행한 뒤 서명하여 TuxCare 저장소에 게시합니다. 자세한 내용을 확인하시려면 TuxCare의 오픈 소스 패치 프로세스에 관한 기술 백서를 참조하십시오.

기존 워크플로우에 자연스럽게 통합됩니다: Starlette용 ELS 패키지는 TuxCare가 호스팅하는 저장소에서 pip를 통해 제공되므로, 이미 운영 중인 패키징 및 CI/CD 워크플로우를 통해 설치할 수 있습니다. 파이프라인을 전면 개편하거나 팀을 재교육할 필요가 없습니다.

SLA에 기반한 답변: 패치 제공 및 지원 관련 약정은 해당 서비스 수준 계약(SLA)에 명시되어 있으므로, 누군가가 언젠가 백포트를 공개해 주기를 기대하기보다는 계약된 일정에 따라 계획을 수립하게 됩니다.

비용 예측 가능성: 실제 요율로 산정한 엔지니어링 시간, 테스트 주기, 외주 비용, 잠재적인 가동 중단 시간, 기능 출시 지연 등을 모두 고려하면, 연장된 지원 서비스를 이용하는 것이 복잡한 마이그레이션을 서둘러 진행하는 것보다 비용이 더 저렴할 수 있습니다. 또한 이는 기간이 정해진 확정된 금액이므로, 기간이 불확실한 마이그레이션 견적보다 예산 논의 시 정당화하기가 더 쉽습니다. 견적을 받아보시고 귀사의 예상 비용과 비교해 보십시오.

규정 준수 및 투명성: 모든 릴리스에는 어떤 구성 요소에 패치가 적용되었고 어떤 CVE가 해결되었는지에 대한 정보가 포함되어 있으므로, 소프트웨어 BOM(Bill of Materials) 중 어떤 부분이 이미 처리되었는지 확인할 수 있습니다. 이러한 문서는 PCI DSS 평가, SOC 2 검토 및 내부 취약점 관리 프로세스를 위한 증거 수집을 뒷받침합니다.

시작하는 방법

지원 종료된 Starlette 버전을 사용 중이며 현재 어떤 커버리지가 제공되는지 알고 싶다면, TuxCare에서 실시간 CVE 추적기 를 운영하고 있으며, 이곳에서 어떤 취약점이 이미 패치되었는지 확인할 수 있습니다.

지원되는 버전, 가격 및 구현에 대한 자세한 정보를 원하시나요? 다음을 방문해 주세요. TuxCare의 Starlette용 Endless 라이프사이클 지원 페이지를 방문하여 현재 지원되는 Starlette 버전과 아직 목록에 포함되지 않은 버전을 요청하는 방법 등 자세한 내용을 확인해 보세요.

Starlette의 지원 종료로 인해 시스템이 위험에 처하지 않도록 하세요

Starlette는 놀라운 성장세를 보여왔습니다. 이 라이브러리는 현대적인 비동기 파이썬 웹 개발의 토대를 마련했으며, FastAPI의 기반이 되고, 파이썬 MCP SDK에서도 사용되고 있으며, 하루에 1,000만 회 가까이 다운로드되고 있습니다. 약 8년 만에 1.0.0 버전에 도달한 것은 이 프로젝트에 있어 진정한 이정표이며, 1.x 계열은 현재 활발하게 유지보수되고 있습니다.

하지만 0.30~0.39 범위의 핀(pin) 버전이든, 그 이후의 0.40~0.49 릴리스이든, 운영 환경에서 구버전을 사용 중이라면 “아직 작동한다”는 것이 “아직 안전하다”는 뜻과는 다릅니다.

그렇다고 해서 서둘러 대응해야만 하는 것은 아닙니다. 여러분에게는 실질적인 선택지가 있습니다. 팀의 로드맵에 맞춰 현재 사용 중인 Starlette 1.x를 신중하게 업그레이드할 계획을 세울 수 있습니다. 다른 프레임워크를 도입하는 것이 아키텍처 측면에서 타당한지 검토해 볼 수도 있습니다. 또는 확장 지원 서비스를 활용하여 보안 및 규정 준수 상태를 안정적으로 유지하면서, 보안 감사의 일정에 쫓기지 않고 본인의 일정에 맞춰 이러한 결정을 내릴 수도 있습니다.

이를 잘 처리하는 팀은 위험을 조기에 파악하고, 활용 가능한 자원을 파악하며, 아키텍처와 가용 자원, 규정 준수 기한을 바탕으로 사후 대응적인 선택이 아닌 신중한 결정을 내립니다.

지금 단종 예정인 Starlette 버전을 고려 중이라면, TuxCare가 제공하는 서비스를 확인해 볼 가치가 있습니다. 실제로 원하는 업그레이드 계획을 세우는 동안, 이미 구축한 시스템을 안정적으로 유지하는 것이 준비가 되지 않은 상태에서 서둘러 마이그레이션을 진행하는 것보다 더 나은 다음 단계라는 것을 알게 될 수도 있습니다.

방문하기 TuxCare의 오픈소스 소프트웨어를 위한 ‘Endless Lifecycle Support’ 를 방문하여, 확장 지원이 오픈소스 스택 전반에 걸쳐 지원 대상 구성 요소를 필요한 기간 동안 어떻게 보호할 수 있는지 확인해 보세요.

요약