FastAPI 지원 종료(EOL)와 서두르지 않고도 보안을 유지하는 방법

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

주요 내용

FastAPI는 LTS(장기 지원) 브랜치를 제공하지 않으므로, 이전 릴리스에 대해서는 유지보수나 보안 패치 적용 기간이 보장되지 않습니다.
실제 노출의 대부분은 FastAPI 자체가 아니라 고정된 Starlette 및 Pydantic 버전에 집중되어 있습니다.
한 번에 여러 개의 마이너 버전을 건너뛰면 직렬화, 유효성 검사 및 종속성 동작이 눈에 띄지 않게 변경될 수 있습니다.
‘무한 라이프사이클 지원’을 통해 업그레이드를 체계적으로 계획하는 동안, 현재 사용 중인 버전에 대한 패치 적용이 지속적으로 이루어집니다.

그래서 0.9x 버전대, 혹은 0.104 버전을 사용하는 FastAPI 앱이 프로덕션 환경에 가동 중인데, 모든 라우트에 Pydantic v1 모델이 적용되어 있습니다. 그런데 스캐너가 대시보드에 ‘지원 종료’로 표시된 패키지가 있다고 경고했습니다. 시스템에 오류는 없습니다. 지연 시간도 정상이고, 트래픽도 문제없습니다. 그런데 보안 담당자 중 한 명이 어쨌든 일정 날짜를 정해달라고 요구하고 있습니다.

이 주제에 관한 대부분의 기사들이 이 점을 은근히 잘못 다루고 있기 때문에, 무엇보다 먼저 한 가지 오해를 바로잡을 필요가 있습니다. FastAPI는 지원 종료(EOL) 날짜를 공개하지 않습니다. LTS(장기 지원) 브랜치도, 보안 유지보수 전용 라인도 없으며, 특정 릴리스에 대한 지원이 중단될 때 별도의 공지 사항도 없습니다. 이 프로젝트는 0.x.x 버전을 유지하며, 마이너 릴리스에는 호환성을 깨는 변경 사항이 포함될 수 있습니다. 또한 공식 지침은 문제가 없는 것으로 확인된 버전을 고정해 두고 신중하게 업그레이드하도록 권장하고 있습니다. 따라서 이 글에서 ‘FastAPI EOL’이라고 언급할 때는, FastAPI 팀에서 공식적으로 지정한 것이 아니라 프로젝트 측에서 더 이상 업데이트를 제공하지 않는 구버전의 FastAPI를 의미합니다.

그런 차이는 상황을 더 나아지게 하기보다는 오히려 악화시킵니다. 라이프사이클을 공개하는 프레임워크라면 적어도 시간이 언제 다 되는지 알 수 있습니다. 하지만 여기에는 그런 시한이 없습니다. 프로젝트가 다음 단계로 넘어가면, 이전 릴리스가 얼마나 오랫동안 수정 패치를 받을 수 있는지 알려주는 공식적인 유지보수 기간도 없고, 이에 대해 이메일을 보내주는 사람도 없습니다.

다음에서는 이것이 프로덕션 API에 있어 실제로 어떤 의미를 갖는지, 의존성 체인 때문에 상황이 겉보기보다 더 복잡해지는 이유, 그리고 현재로서는 로드맵상 업그레이드가 불가능한 경우 TuxCare의 ‘무기한 라이프사이클 지원(Endless Lifecycle Support)’을 포함한 현실적인 대안들이 무엇인지 살펴보겠습니다.

FastAPI 릴리스의 실제 작동 방식

버전 관리 방식에 대해 잠시 설명해 두는 것이 좋겠습니다. 이렇게 빠르게 변화하는 기록 속에서 특정 릴리스가 어디에 위치하는지 파악하기 어려울 수 있기 때문입니다.

FastAPI는 시맨틱 버저닝(SemVer)을 따르며, 1.0.0 미만을 유지하는 것은 이를 벗어난 것이 아니라 그 원칙의 일부입니다. SemVer에 따르면, 0.x.x 단계의 프로젝트는 마이너 릴리스에서 호환성 문제를 일으킬 수 있으며, FastAPI는 이러한 여지를 활용하고 있습니다. 세바스티안 라미레스(tiangolo)는 이에 대해 솔직하게 밝힌 바 있습니다. 버전을 고정하고, 릴리스 노트를 확인한 뒤, 의도적으로 업그레이드하세요. 이 프레임워크는 수천 개의 기업에서 프로덕션 환경에서 운영되고 있음에도 불구하고, 마이너 버전 간에 동작을 변경할 권리를 여전히 보유합니다.

자주 릴리스됩니다. Node.js처럼 6개월마다 정기적으로 릴리스되는 고정된 주기는 없습니다. 새로운 마이너 버전이 어느 달이든 출시될 수 있으며, 때로는 JSON 직렬화 방식, yield가 포함된 종속성의 동작 방식, 또는 요청 본문의 유효성 검사 방식에 실질적인 변경 사항이 포함되기도 합니다.

보안 측면에서 중요한 진행 과정은 다음과 같습니다.

0.100.0 이전 버전의 FastAPI는 Pydantic v1만 지원했습니다. 해당 버전은 더 이상 활발히 개발되지 않고 있어, 여전히 이 버전을 고정해 사용하는 애플리케이션은 개발이 아닌 유지보수만 이루어지는 유효성 검사 라이브러리에 의존하게 됩니다.

FastAPI 0.100.x ~ 0.125.x Pydantic v1과 v2를 모두 지원했습니다. 버전 0.119.0에서는 다음을 지원하도록 추가되었습니다. from pydantic.v1 import BaseModel, v1 및 v2 모델을 동일한 앱 내에서 공존하게 하고, 팀에 점진적인 마이그레이션 경로를 제공합니다.

FastAPI 0.125.0에서는 2024년 10월 7일에 지원 종료된 Python 3.8을 더 이상 지원하지 않습니다. 버전 0.124.4는 3.8에 설치할 수 있는 마지막 릴리스이므로, 해당 런타임 환경의 pip 리졸버는 더 이상 업데이트되지 않습니다.

FastAPI 0.126.0 Pydantic v1을 제거하고 최소 버전을 pydantic >= 2.7.0, 한편으로는 에 대한 임시 지원을 유지하면서 pydantic.v1 네임스페이스. 버전 0.127.0부터 해당 네임스페이스에 대해 사용 중단 경고가 표시되기 시작했고, 0.128.0에서 해당 네임스페이스가 제거되었습니다. 그 이후로는 Pydantic v2만 작동합니다.

FastAPI 0.129.0에서는 Python 3.9 지원이 중단되어, 현재 버전을 사용하려면 최소 Python 3.10이 필요합니다.

FastAPI의 릴리스 주기는 매우 빠르기 때문에, 이와 같은 기사에 언급된 버전 번호는 며칠 만에 구식이 되어버립니다. 업그레이드를 계획하기 전에 PyPI를 확인해 보세요. 중요한 것은 여러분이 고정해 둔 버전과 최신 릴리스 간의 차이이기 때문입니다.

뒤처져 있어도 별다른 일은 일어나지 않습니다. 코드는 계속 실행됩니다. 단지 버전 번호의 증가가 멈출 뿐이며, 그 시점 이후로 해당 버전에 대해 공개된 문제점들에 대해서는 더 이상 이전 브랜치에서 수정 사항이 제공될 것이라고 기대할 수 없습니다.

FastAPI의 EOL이 운영 환경에 실제로 어떤 의미를 갖는가

패치 작업은 중단되었지만, 엔드포인트는 계속 응답하고 있습니다. 대시보드는 여전히 녹색을 유지하고 있습니다. 그렇다면 실제 문제는 무엇일까요?

릴리스에 대한 유지보수가 중단되었다고 해서 취약점이 더 이상 발견되지 않는 것은 아닙니다. 연구자들은 성과가 기대되는 분야인 널리 배포된 소프트웨어를 계속해서 조사하고 있으며, 현재 FastAPI는 핀테크, 헬스케어, AI 인프라, 그리고 수많은 기업 내부 도구 전반에 걸쳐 API를 구동하며 광범위하게 배포되어 있습니다.

FastAPI의 과거 사례 중 두 가지 CVE가 이 문제의 양상을 잘 보여줍니다.

CVE-2024-24762 (CVSS 7.5, 높음) 은 FastAPI가 폼 데이터를 파싱하는 데 사용하는 라이브러리인 python-multipart에서 발생하는 정규식 기반 서비스 거부(DoS) 취약점입니다. 특수하게 조작된 Content-Type 헤더는 파서를 2차 방정식 수준의 백트래킹 상태로 몰아넣고 이벤트 루프를 고착시키며, 이를 전송하는 데 인증이 필요하지 않습니다. 단 하나의 요청만으로도 워커가 묶이게 되며, 충분한 수의 동시 요청이 발생하면 서비스를 사용할 수 없게 될 수 있습니다. 이 취약점에 대한 수정 사항은 python-multipart 0.0.7에 반영되었으며, FastAPI 0.109.1은 해당 버전을 포함하기 위해 의존성 요구 사항을 상향 조정했습니다. 이 점은 취약성 분류에 영향을 미치므로 알아두어야 합니다. 즉, 사용 중인 python-multipart에 이미 패치가 적용된 경우, 구버전 FastAPI가 자동으로 취약해지는 것은 아니며, 해당 패키지 하나만 업그레이드하는 것이 대개 가장 빠른 해결 방법입니다.

CVE-2021-32677 (CVSS 8.1, 높음)은 0.65.2 이전 버전의 FastAPI에서 발생한 크로스사이트 요청 위조(CSRF) 취약점입니다. FastAPI는 Content-Type 헤더가 text/plain으로 지정된 경우에도 요청 본문을 JSON으로 파싱했습니다. text/plain 요청은 CORS 단순 요청으로 간주되므로, 브라우저는 프리플라이트(preflight) 없이 쿠키를 첨부하여 해당 요청을 전송합니다. 따라서 악의적인 페이지는 일반 텍스트로 위장한 JSON 페이로드를 POST하여, 이를 인증된 사용자의 요청으로 인식되도록 할 수 있습니다. 이 취약점은 JSON 본문을 허용하는 브라우저 접근 가능한 경로 작업에서 쿠키 기반 인증을 사용하는 애플리케이션에 영향을 미쳤습니다. 버전 0.65.2에서는 콘텐츠 유형이 application/json 또는 호환 가능한 미디어 유형일 때만 JSON을 파싱하도록 수정하여 이 문제를 해결했습니다.

이 두 가지 모두 특별한 경우는 아닙니다. 둘 다 완전히 평범한 배포 환경에서 원격으로 트리거될 수 있으며, 이 두 가지가 결합되어 바로 여기서 의존성 버전이 왜 그토록 중요한지 보여줍니다. 때로는 문제 해결을 위해 FastAPI 자체를 업그레이드해야 할 때도 있습니다. 또 때로는 독립적으로 업그레이드 가능한 의존성이 그 자체로 문제를 해결하기도 합니다.

이를 통해 오래된 코드베이스에 대한 대략적인 우선순위 분류가 가능합니다. 0.109.1 미만의 버전에서는 다른 작업을 진행하기 전에 먼저 lockfile에서 python-multipart가 실제로 무엇을 가리키는지 확인하십시오. 이 문제만 해결해도 취약점을 해소할 수 있을 수 있기 때문입니다. 0.65.2 미만의 버전에서는, 브라우저와 연동되는 JSON 엔드포인트에서 쿠키 기반 인증을 사용하는 애플리케이션이 수년 동안 취약점에 노출되어 왔으므로, 실질적인 업그레이드나 이를 보완할 수 있는 미들웨어 검사가 필요합니다. 또한, 만약 내일 여러분이 고정해 둔 릴리스 버전에 대해 동일한 프로필을 가진 취약점이 공개된다면, 이를 백포트할 수 있는 업스트림 브랜치는 존재하지 않습니다.

의존성 트리에 숨겨진 위험

팀들이 FastAPI의 지원 종료(EOL) 위험을 고려할 때, 보통 FastAPI 자체를 떠올립니다. 하지만 더 주목할 만한 위험 요소는 대개 한 단계 아래에 있습니다.

FastAPI의 핵심 의존성 세트는 Starlette와 Pydantic, 그리고 몇 가지 타입 지정 보조 라이브러리를 중심으로 구성되어 있으며, 프로젝트가 발전함에 따라 이 세트는 시간이 지남에 따라 변화해 왔습니다. 설치 fastapi[standard] 또한 양식 파싱을 위한 python-multipart나 애플리케이션 제공을 위한 Uvicorn과 같은 선택적 추가 구성 요소도 함께 사용하게 됩니다. 이 모든 구성 요소는 각각 고유한 릴리스 주기, 관리자, 그리고 보안 이력을 가지고 있습니다.

Starlette가 가장 대표적인 예입니다. GHSA-7f5h-v6xp-fcq8로 공개된 CVE-2025-62727은 FileResponse의 Range 헤더 구문 분석 과정에서 발생하는 2차 시간 복잡도 문제로, 인증되지 않은 요청으로 인해 CPU 자원을 과도하게 소모하게 만듭니다. 이 취약점은 Starlette 0.39.0부터 0.49.0까지의 버전에 영향을 미치며, 0.49.1에서 수정되었고, FileResponse나 StaticFiles를 통해 파일을 제공하는 모든 애플리케이션에 영향을 미칩니다. 수많은 FastAPI 애플리케이션이 별다른 고민 없이 정확히 이러한 방식을 사용하고 있습니다.

그리고 여전히 구형 스택을 고수하고 있는 사람이라면 누구나 진정으로 우려해야 할 문제가 하나 더 있습니다. 2026년 5월, X41 D-Sec은 OSTIF가 후원한 vLLM 감사 과정에서 발견된 ‘BadHost’라는 별명을 가진 CVE-2026-48710을 공개했습니다. Starlette는 HTTP Host 헤더를 재구성하는 데 사용하기 전에 이를 검증하지 않았습니다. request.url. 라우팅은 원시 경로를 기반으로 작동하며, request.url Host 헤더를 바탕으로 재구성되었으며, 단 하나의 잘못된 문자만으로도 request.url.path 실제로 요청된 경로와 다른 내용을 반환합니다. 다음 경로를 기준으로 인증 결정을 내리는 모든 미들웨어는 request.url.path 간과하기 쉬운 취약점입니다. GitHub은 CVSS 3.1 기준 이 취약점에 6.5점을 부여했으며, 인증 정보나 사용자 상호작용 없이도 악용 가능하며, Starlette 0.8.3부터 1.0.0까지의 버전에 영향을 미치며, 수정 사항은 1.0.1 버전에 반영되었습니다. 다음을 기반으로 결정을 내리지 않는 엔드포인트 수준의 FastAPI 인증은 request.url.path 영향을 받지 않습니다. 다음에서 권한 부여 결정을 내리는 사용자 정의 미들웨어는 request.url 또는 request.url.path 즉, MCP 서버, LLM 프록시 및 기타 FastAPI 기반 인프라 전반에서 발견되는 패턴입니다.

바로 이 지점에서 의존성 함정이 더 이상 이론적인 문제가 아니게 됩니다. 해결책은 Starlette 1.0.1이지만, Starlette는 2026년 3월에야 1.0.0 버전에 도달했습니다. 이전 버전의 FastAPI는 그보다 훨씬 낮은 상한값을 선언하고 있습니다. 예를 들어, FastAPI 0.120.1은 Starlette의 상한을 0.50.0 미만으로 제한합니다. 패치된 Starlette가 사용 중인 FastAPI 릴리스에서 선언한 범위 밖으로 벗어나는 경우, Starlette만 단독으로 업그레이드하면 FastAPI가 테스트한 적도 없고 지원하지도 않는 조합이 되어버립니다. 따라서 수정 사항을 적용하려면 먼저 FastAPI를 업그레이드해야 하는데, 이는 강제로 진행해야 하는 상황이 아니라 여러분이 계획하고 있던 바로 그 업그레이드입니다.

Pydantic 일반적으로 다루어지는 것보다 더 세심한 설명이 필요합니다. V1은 더 이상 활발하게 개발되고 있지 않지만, Pydantic이 발표한 버전 정책에 따르면 V3가 출시될 때까지 V1에 대한 중대한 버그 수정 및 보안 패치를 계속 제공할 것으로 약속하고 있으며, V3는 아직 출시되지 않았습니다. V1에 가해지는 압박은 버려짐이 아니라 호환성 범위가 좁아지는 것입니다. FastAPI는 0.126.0 버전에서 V1에 대한 네이티브 지원을 제거했으며, pydantic.v1 0.128.0 버전의 shim이 포함되어 있으므로, v1 핀을 계속 사용한다면 Pydantic 팀이 어떤 조치를 취하든 상관없이 FastAPI 0.126 이하 버전을 사용하게 됩니다. 기술적으로는 보안 약속이 여전히 유효하더라도, 시간이 지날수록 업그레이드 경로는 점점 더 제한될 것입니다.

Starlette는 이 이야기의 또 다른 측면입니다. FastAPI는 라우팅, 미들웨어, WebSocket 처리 및 응답 로직을 Starlette를 기반으로 직접 구축하기 때문에, 앱이 영향을 받는 버전을 실행하고 취약한 코드 경로를 처리할 때마다 Starlette의 결함은 FastAPI의 문제가 됩니다. BadHost가 바로 그러한 사례입니다.

이 모든 것을 종합해 보면, 상황은 단순히 “지원이 중단된 패키지 하나”라기보다는 “지원 정책과 업그레이드 요구 사항이 제각각이며, 서로를 제약하는 버전 범위를 가진, 노후화되고 밀접하게 결합된 여러 라이브러리”에 가깝습니다. 이는 파악하기 더 어렵고, 부분적으로 패치를 적용하기에는 훨씬 더 까다로운 문제입니다.

제품 수명 종료(EOL) 시 선택할 수 있는 옵션

그러니까 버전이 오래된 것이거나, 곧 그렇게 될 전망입니다. 현실적인 세 가지 방안과 그에 따른 실제 비용이 제시되어 있습니다.

다른 프레임워크로 마이그레이션하기

일부 팀은 이 기회를 삼아 프레임워크에 대한 논의를 완전히 다시 시작하고, Flask, Django REST Framework, Litestar 또는 그 밖의 다른 프레임워크를 검토하기도 합니다.

이러한 아키텍처적 주장은 특정 사례에서 타당성을 띠는데, 특히 FastAPI의 비동기 우선 설계가 대체로 동기식인 코드베이스와 끊임없이 충돌하는 경우나, 팀 외부에서는 아무도 호출하지 않는 내부 서비스의 경우 자동 OpenAPI 생성이 그 가치를 제대로 발휘하지 못하는 경우가 대표적이다.

문제는 비용입니다. 라우트 핸들러, 의존성 주입 구조, 미들웨어, 인증, 응답 모델 등이 모두 FastAPI의 형태를 띠고 있습니다. 요청 및 응답의 라이프사이클이 다릅니다. 테스트 패턴도 다릅니다. 배포 구성도 달라집니다. 성숙한 운영 환경의 애플리케이션의 경우, 이는 쉽게 여러 스프린트에 걸친 프로젝트가 될 수 있으며, 실제 가동 시간 의무가 있는 대규모 코드베이스의 경우 주말 단위가 아닌 분기 단위로 측정됩니다. 이는 타당한 선택이지만, 보안 문제 해결책은 아닙니다.

TuxCare의 끝없는 라이프사이클 지원을 경험해 보세요

세 번째 옵션은 목적지가 아닌 타이밍을 변경하는 것으로, 이는 대개 팀이 필요로 하는 사항입니다.

TuxCare는 지난 15년 동안 오픈소스 패치 작업에 매진해 왔으며, 14,000건 이상의 취약점을 수정하고 지원 대상 패키지에 걸쳐 420,000건 이상의 패치를 제공해 왔습니다. 이러한 실적은 단순한 성과로 보기보다는 업무가 어떻게 구조화되어 있는지를 보여주는 지표로서 더 큰 의미가 있습니다. 왜냐하면 업스트림 프로젝트가 더 이상 지원하지 않는 버전에 수정 사항을 역이식하는 것은 그 자체로 특별한 전문성이 요구되는 분야이기 때문입니다.

지원 범위는 FastAPI 자체를 넘어섭니다. 직접 및 전이적 종속성이 추가 비용 없이 포함되는데, 앞서 Starlette와 Pydantic에 대해 설명한 모든 내용을 고려할 때 이 점이 특히 중요합니다. 예를 들어, BadHost와 같은 오류가 import 문에서 세 단계 아래에 위치한 컴포넌트에서 발생할 경우, 프레임워크를 업그레이드하라는 안내보다 실제로 실행 중인 버전에 대한 패치의 가치가 훨씬 더 큽니다.

이 프로세스는 자동화 방식으로 진행되지만, 중간중간 사람이 직접 점검합니다. TuxCare는 NVD, 벤더 권고 사항 및 GitHub 보안 권고 사항을 모니터링하고, 알고리즘 및 AI 지원 도구를 사용하여 수정 사항을 백포트한 뒤, 릴리스 전에 보안 엔지니어가 각 패치를 검증합니다. 모든 패치는 무결성, 기능 및 회귀 테스트를 거친 후 서명되어 TuxCare가 호스팅하는 저장소에 반영됩니다. 배포는 pip를 통해 이루어지므로, FastAPI를 직접 설치하든 내부 패키지 미러를 통해 설치하든 상관없이 다른 소스를 지정하기만 하면 계속 작업할 수 있습니다.

패치는 SLA에 기반한 일정에 따라 제공되며 연중무휴 지원이 뒷받침되고, 릴리스에는 감사관이 요청하는 공급망 관련 문서가 함께 제공됩니다. 여기에는 SBOM 출력물과 해당 SBOM 내의 어떤 취약점이 이미 해결되었는지를 보여주는 VEX 컨텍스트가 포함됩니다. TuxCare는 현재 FastAPI 0.63.0 및 0.104.1에 대한 ELS 커버리지를 공개하고 있으며, 의존성 노출이 주로 집중되는 EOL(지원 종료) 상태의 Starlette에 대한 별도의 커버리지도 제공하고 있습니다.

비용 측면에서 솔직히 말하자면, 이는 귀사의 구체적인 수치에 따라 달라집니다. 실제 단가로 산정한 엔지니어링 작업 시간, 테스트 주기, 외부 업체 투입 시간, 가동 중단 위험, 그리고 핵심 인력이 종속성 해결 문제를 디버깅하는 동안 출시되지 못하는 기능 등을 모두 합산해 보면, 연장 지원 비용이 가속화된 마이그레이션 비용보다 훨씬 저렴하게 책정되는 경우가 많습니다. 다른 사람의 말만 믿지 말고, 직접 산출한 수치를 바탕으로 비교해 보시기 바랍니다.

이 장단점은 분명히 짚어둘 필요가 있습니다. 이 글을 여기까지 읽을 만큼 회의적인 분이라면 이미 그 점을 생각해 보셨을 테니까요. ELS는 구버전에 보안 패치를 계속 적용해 줍니다. 하지만 이를 최신 버전으로 업그레이드하지는 않습니다. 사용자는 동일한 API 인터페이스, 동일한 Pydantic 자동 생성 기능, 그리고 코드를 작성할 당시와 동일한 동작 방식을 계속 유지하게 되는데, 이것이 바로 핵심이며, 결국에는 업그레이드를 원하게 될 것입니다. 달라지는 점은 업그레이드가 다음 CVE를 등록한 사람이 정한 일정에 따라 이루어지는 것이 아니라, 팀이 준비가 되었을 때 진행된다는 것입니다.

업그레이드를 서두를 때 발생하는 진정한 비용

보안 대시보드의 경고등이 깜빡이기 시작하고 상급자가 마감 기한을 물어보면, 본능적으로 가능한 시간 내에 작업을 욱여넣으려 하게 됩니다. 대개 바로 그 순간부터 문제가 시작됩니다.

FastAPI 버전 업그레이드는 실제로 어떤 과정을 거치는가

requirements.txt 파일에서 버전 핀을 변경하는 것은 본 작업이 아닙니다. 본 작업은 그 이후에 시작됩니다.

코드는 변화에 맞춰 조정되어야 합니다. 사소해 보이는 변경 사항조차도 Pydantic 모델의 동작을 바꾸거나, 응답 직렬화 방식을 변경하거나, 예전에는 용인되던 의존성 주입 패턴을 오류로 만들 수 있습니다. 2년 동안 손도 대지 않은 채 무난하게 작동해 오던 코드가 갑자기 수정이 필요해지는데, 아무도 그 코드를 살펴보지 않았기 때문에 이에 대한 예산을 편성해 둔 사람은 아무도 없습니다.

호환성은 의도적으로 선택한 패키지뿐만 아니라 전체 트리 전반에 걸쳐 확인해야 합니다. 전이적 의존성은 해결 단계에서야 비로소 드러나는 방식으로 서로를 제약하며, 4단계 아래에 숨겨진 호환되지 않는 패키지 하나만으로도 누군가가 그 문제를 해결할 때까지 전체 업그레이드 과정이 차단될 수 있습니다.

미들웨어와 인증 시스템은 철저한 검토가 필요합니다. FastAPI의 보안 유틸리티, OAuth2 흐름, JWT 처리 방식이 발전함에 따라, 이전 릴리스에서는 정상적으로 작동하던 미들웨어가 최신 릴리스에서는 미묘하게 다르게 동작할 수 있습니다. 이러한 오류는 범위가 좁은 단위 테스트에서는 놓칠 수 있으며, 통합 테스트나 실제 운영 환경에서야 비로소 드러날 수 있습니다. 예를 들어, 금요일 어느 순간 사용자 세션이 예기치 않게 만료되는 경우가 바로 그 예입니다.

테스트에 실질적인 부하가 발생합니다. 단위 테스트, 통합 테스트, 종단 간 테스트, 성능 테스트 등 모든 테스트 스위트를 새 버전에서 실행하여 트래픽이 유입되기 전에 회귀 현상을 포착해야 합니다. 테스트 커버리지가 부족한 팀은 업그레이드 과정에서 그 부족함이 얼마나 심각한지 뼈저리게 깨닫게 되는데, 이는 이를 알게 되는 데 있어 최악의 시기입니다.

서두르면 어떻게 될까

이 모든 것을 규정 준수 기한에 맞춰 타임라인에 압축해 넣다 보면, 흔히 볼 수 있는 방식으로 실패하기 마련입니다.

지원 요청이 먼저 늘어납니다. 테스트 과정에서 포착되지 못한 버그들은 API의 이상한 동작에 대한 티켓 형태로 나타나는데, 처음에는 아무도 이 두 가지를 연관 짓지 못하더라도 상당수는 결국 업그레이드에서 비롯된 것으로 밝혀집니다.

그 결과 안정성이 뒤따릅니다. 미묘한 의존성 변경은 실제 운영 환경의 부하가 가해졌을 때만 나타나는 극단적인 경우의 버그를 유발하며, 3계층 아래에서 발생한 동작 변화로 인해 발생하는 간헐적인 오류는 새벽 3시에 디버깅하기에는 정말 골치 아픈 일입니다.

기술적 부채는 눈치채지 못하는 사이에 쌓입니다. 규정 준수를 서두르다 보니 리팩토링은 생략되고 임시방편이 쌓이기만 하며, “나중에 제대로 고치자”는 생각이 코드베이스의 영구적인 상태가 되어 버립니다.

예산 문제는 마지막에 가장 크게 대두됩니다. 예상치 못한 업그레이드 문제가 발생하면, 긴급한 계약업체 작업 시간, 릴리스 지연, 그리고 가장 유능한 엔지니어들이 고객이 요청한 작업 대신 3주 동안 종속성 해결에만 매달려야 하는 기회 비용 등으로 인해 예산 초과 가능성이 훨씬 더 높아집니다.

시작하는 방법

구버전의 FastAPI를 사용 중이고, 공급업체의 말만 믿기보다는 어떤 보안 대응 조치가 마련되어 있는지 직접 확인하고 싶다면, TuxCare에서 제공하는 CVE 트래커를 활용해 보세요. 이곳에서는 지원되는 버전과 그 의존성 라이브러리에 대해 이미 배포된 취약점 및 수정 사항을 조회할 수 있습니다. 이는 사용 중인 스택의 보안 대응 현황을 파악하는 합리적인 방법입니다.

지원되는 버전, 제공 세부 사항 및 가격에 대해서는 ‘FastAPI용 Endless 라이프사이클 지원 ’ 페이지에서 실제 구현 방식에 대해 자세히 설명하고 있습니다.

FastAPI의 지원 종료로 인해 API가 위험에 처하지 않도록 하세요

FastAPI는 상당한 발전을 이루었습니다. Pydantic v2 지원, 더 빨라진 JSON 직렬화, 개선된 스트리밍 동작, 그리고 훨씬 더 풍부한 주변 도구 세트 등 덕분에, 팀과 운영 환경의 상황이 허락하는 대로라면 이번 릴리스를 도입해 볼 가치가 충분합니다.

하지만 심각한 운영 차질 없이 구버전에서 벗어나기 어려운 애플리케이션을 유지 관리하고 있는 경우라 하더라도, 그렇다고 해서 당장 당황하거나 보안 예외를 영구적으로 허용해야 하는 것은 아닙니다.

선택지는 분명히 있으며, 이는 실질적인 대안들입니다. 비즈니스 측면에서 타당할 때를 대비해 신중한 업그레이드 계획을 세울 수 있습니다. 아키텍처상 타당한 이유가 있다면 다른 프레임워크를 검토해 볼 수도 있습니다. 또는, 타사의 공개 일정에 얽매이지 않고 본인의 일정에 맞춰 결정을 내리는 동안 보안 라인을 유지하기 위해 연장 지원 서비스를 도입할 수도 있습니다.

이 문제를 잘 해결하는 팀은 대개 예산이 가장 많거나 코드베이스가 가장 최신인 팀이 아닙니다. 그들은 위험을 정확히 파악하고, 각 선택지에 드는 비용을 이해한 뒤, 의도적으로 결정을 내린 팀들입니다.

지금 FastAPI의 지원 종료(EOL)가 관심사라면, 일정이 준비되지 않은 상태에서 업그레이드를 결정하기 전에 어떤 지원이 제공되는지 확인해 볼 가치가 있습니다. 『 오픈소스 소프트웨어를 위한 끝없는 라이프사이클 지원 』에서는 필요한 기간 동안 해당 보호가 스택의 나머지 부분에 얼마나 광범위하게 적용되는지 설명합니다.

요약