마이크로소프트가 ASP.NET Core의 긴급 보안 업데이트 10.0.7을 배포했습니다. 문제는 Microsoft.AspNetCore.DataProtection 패키지의 회귀(regression)로, 10.0.0부터 10.0.6까지에서 인증 쿠키·토큰 검증이 깨질 수 있었고, 조건이 맞으면 권한 상승으로 이어질 수 있었습니다.12
이 소식이 중요한 이유는 단순히 "또 패치가 나왔다"가 아니기 때문입니다. 이번 건은 ASP.NET Core가 더 이상 프레임워크 선택만의 문제가 아니라, 패키지 추적·재빌드·토큰 폐기·키 회전까지 감당하는 운영 체계의 선택이라는 점을 드러냈습니다.3
"ASP.NET Core가 기본값"이라고 보기 전에 먼저 봐야 할 것
ASP.NET Core는 이미 오래된 실험적 선택지가 아닙니다. 2016년 등장 이후 크로스플랫폼 웹 프레임워크로 자리 잡았고, 지금은 .NET의 주력 웹 스택입니다.45 성능, 배포 유연성, Linux/macOS 지원, 장기 지원 버전 운영 측면에서 분명 강점이 있습니다.
그렇다고 모든 프로젝트의 자동 정답은 아닙니다.
짧은 수명의 내부 업무 앱, 거의 변경이 없는 관리 화면, 소규모 팀이 운영까지 떠안는 서비스라면 질문이 달라집니다. "ASP.NET Core가 최신인가?"가 아니라 "이 팀이 보안 업데이트와 의존성 관리를 지속적으로 따라갈 수 있는가?"가 먼저입니다.
이번 취약점은 그 판단 기준을 선명하게 만들었습니다. 취약한 버전을 설치한 뒤 패치만 적용하면 끝나는 문제가 아니었습니다. 이미 위조 페이로드로 발급된 정상 서명 토큰은 패치 후에도 남을 수 있어, Data Protection 키 링 회전이 추가로 필요했습니다.23 튜토리얼에는 잘 안 나오는 운영 비용이 실제 리스크로 드러난 셈입니다.
오래 가는 선택과 빨리 빚이 되는 선택은 다르다
확인된 사실부터 보겠습니다. 이번 문제의 직접 원인은 앱 코드 자체가 아니라, 인증과 보호 데이터를 맡는 공통 패키지의 암호 검증 회귀였습니다.23 즉, "보안은 프레임워크가 해주겠지"라는 기대가 얼마나 쉽게 깨질 수 있는지 보여줍니다.
여기서 실무적 해석이 나옵니다. ASP.NET Core를 쓴다면 오래 가는 설계는 대체로 단순한 쪽입니다. 인증 경계를 명확히 두고, 기본 동작을 크게 비틀지 않고, 배포 경로를 평범하게 유지하는 선택이 시간이 갈수록 유리합니다.
반대로 초기에 과하게 복잡한 인증 흐름을 얹거나, 토큰과 세션 체계를 여러 방식으로 섞거나, 컨테이너·패키지·런타임 버전을 느슨하게 관리하면 나중에 보안 이슈가 생겼을 때 복구 범위가 커집니다. 이번에도 서버 런타임만 올리면 끝나는 경우와, NuGet 패키지를 포함한 앱을 다시 빌드하고 재배포해야 하는 경우가 갈렸습니다.3
핵심은 최신 패턴 채택보다 "고장 났을 때 얼마나 빨리 이해하고 되돌릴 수 있는가"입니다.
보안 업데이트는 이제 기능이 아니라 팀 역량 테스트다
이번 CVE-2026-40372는 Linux와 macOS 환경에서 특히 영향을 받았고, Windows도 특정 관리형 알고리즘 구성을 쓴 경우 영향 가능성이 거론됐습니다.13 원 기사 제목만 보면 비Windows 이슈처럼 보이지만, 더 본질적인 문제는 운영 환경마다 영향 방식이 달랐다는 점입니다.
이 차이가 왜 중요할까요. ASP.NET Core는 크로스플랫폼이라는 장점 덕분에 선택되지만, 그만큼 패키지 경로도 다양합니다. VM 위 런타임, 컨테이너 이미지, 앱에 포함된 NuGet 의존성, 구버전 호환 타깃까지 추적해야 합니다.3 "한 번 업데이트하면 다 해결된다"는 Windows 서버 시대의 감각으로 보면 놓치기 쉽습니다.
그래서 ASP.NET Core를 고른다는 건 사실상 이런 팀 규율을 같이 고르는 일입니다.
어떤 패키지가 런타임에 실제 로드되는지 안다
OOB 보안 업데이트를 정기 릴리스와 별도로 추적한다
재빌드와 재배포를 당일 처리할 수 있다
인증 토큰 폐기와 키 회전을 운영 절차로 갖고 있다
이걸 과하다고 느낀다면, 그 감각 자체가 중요한 신호입니다. 프레임워크가 너무 무거운 게 아니라, 제품의 운영 모델과 팀 규모에 비해 선택이 앞서간 것일 수 있습니다.
레거시 ASP.NET에서 온 팀이라면, 덜 현대화하는 편이 더 안전할 수 있다
최근 마이크로소프트는 .NET Framework 위에서 돌아가던 ASP.NET Core 2.3 지원을 2027년 4월 종료한다고 밝혔습니다.6 이는 사실상 "임시 다리" 역할이 끝났다는 뜻에 가깝습니다. 앞으로는 현대 .NET과 현대 ASP.NET Core로 옮기라는 메시지가 더 분명해졌습니다.
하지만 여기서 흔한 실수는 전면 재작성입니다.
이전 ASP.NET에서 옮기는 팀이라면, 모든 것을 최신 스타일로 바꾸려 하기보다 비즈니스 로직 보존, 레거시 결합 제거, 인증/배포 경계 정리부터 하는 편이 낫습니다. 최소 API든, 새 호스팅 모델이든, Blazor든, 그 기능이 비용과 위험을 실제로 줄일 때만 받아들이는 게 맞습니다.
반론도 있습니다. "어차피 최신으로 갈 거면 한 번에 바꾸는 게 낫지 않나?" 일부 팀엔 맞는 말입니다. 다만 운영 인력과 테스트 체계가 약한 조직에서는 큰 리라이트가 오히려 보안 대응 속도를 늦춥니다. 이번 같은 긴급 패치 상황에서 중요한 건 코드의 현대성보다 변경 영향도를 좁게 유지하는 능력입니다.
결국 지금 신경 써야 할 사람은 두 부류입니다. 새 서비스를 시작하며 ASP.NET Core를 기본값처럼 고르려는 팀, 그리고 구형 ASP.NET에서 옮길 계획을 세우는 팀입니다. 전자는 "우리 팀이 이 운영 부담을 감당할 수 있는가"를 먼저 물어야 하고, 후자는 "얼마나 새로 쓸 것인가"보다 "얼마나 적게 흔들며 옮길 것인가"를 판단 기준으로 삼아야 합니다.
참고
1Microsoft issues emergency update for macOS and Linux ASP.NET threat
2Microsoft releases emergency patches for critical ASP.NET flaw
3Microsoft issues out-of-band patch for critical security flaw in update to ASP.NET Core
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.