Windows 11 .NET Framework 3.5 설치 방식 바뀐 이유 (27965 이후)

.NET Framework 3.5가 Windows 기본 옵션에서 빠지기 시작한 이유

Fast Technology 2월 9일 보도에서 언급된 내용처럼, 마이크로소프트는 향후 Windows 버전에서 오랫동안 선택적 기능으로 남아 있던 구형 구성 요소 .NET Framework 3.5의 배포 방식을 바꾸기 시작했습니다. 

요지는 “OS 이미지에 묶어두는 방식”에서 “필요한 환경만 별도로 설치하는 방식”으로 넘어간다는 뜻으로 이번변경은 2025년 10월, Canary 채널로 배포된 Windows 11 프리뷰 빌드 27965부터 적용되기 시작했습니다.

Windows 10/11에서 무엇이 달라지나

현재 Windows 11에는 기본적으로 .NET Framework 4.8 계열이 통합돼 있고, 3.5는 대부분 구형 앱 호환성 때문에 추가로 설치해 왔습니다. 

• [IT 리뷰/윈도우 Tip] - Microsoft .NET Framework 4.7 1 다운로드 및 오류
• [IT 리뷰/윈도우 Tip] - .NET Framework 4 설치 시 HRESULT 0xC8000222 오류
• [IT 리뷰/윈도우 Tip] - Microsoft Visual C++ 2010 런타임 다운로드 및 설치 오류 해결

그동안은 ‘Windows 기능 켜기/끄기’에서 체크만 하면 활성화됐지만, 빌드 27965 이후 환경에서는 이 체크 항목이 닫히고, 독립 설치 패키지를 직접 설치하는 방식으로 바뀝니다. 

이 변화는 ASP.NET 3.5, .NET Extensibility 3.5, WCF HTTP Activation, WCF non-HTTP Activation 같은 연관 구성 요소에도 같이 영향을 줍니다. 마이크로소프트는 제품 수명 주기 정책과 맞추기 위한 결정이라고 설명했고, .NET Framework 3.5의 공식 지원은 2029년 1월 9일 종료 예정으로 알려져 있습니다. 

다만 이 변경은 빌드 27965 이후의 Windows 11 버전과 향후 출시될 신규 시스템에만 적용됩니다. Windows 10과 기존 Windows 11 버전(25H2 포함)에서는 지금까지처럼 기능 체크로 계속 사용할 수 있습니다.

어떤 상황에서 3.5가 필요한가

가장 많이 마주치는 상황은 사내 환경에서 오래된 업무용 프로그램을 실행할 때입니다. 

설치 중에 “3.5가 없다”는 메시지가 뜨거나, 실행하자마자 바로 종료되는 증상이 나옵니다. 결론부터 말씀드리면, 앱이 정말로 3.5를 요구하는지부터 먼저 확인하시는 편이 시간 낭비가 줄어듭니다.

• 설치 프로그램이 .NET Framework 3.5 요구 팝업을 표시
• 실행 시 에러 로그에 CLR 2.0 또는 v2.0.50727 관련 문구가 등장
• 구형 ERP/그룹웨어 클라이언트, 내부 관리 도구, 레거시 장치 관리 유틸리티에서 반복

설치 방식 비교

운영 환경에서 헷갈림이 줄어들도록, 기존과 변경 방식을 한 눈에 비교해두면 편합니다. 

가장 중요한 건 “앞으로는 OS 설정 화면에서 체크로 끝나지 않을 수 있다”는 점입니다.

구분	기존 방식(대부분 Windows 10/기존 Windows 11)	변경 방식(Windows 11 빌드 27965 이후 계열)
설치 진입	‘Windows 기능 켜기/끄기’ 체크	독립 설치 패키지 직접 설치
네트워크 의존	환경에 따라 Windows Update 접근이 필요	패키지만 확보되면 오프라인도 가능
배포/이미징	기능 추가 정책으로 처리하는 경우가 많음	패키지 보관/배포 정책이 필요
관련 구성요소	체크 선택으로 같이 활성화	동일하게 체크 방식이 막힐 수 있음

사내 환경에서 막히는 지점

자주 막히는 지점입니다. 증상은 “설치가 안 된다”로 같아 보이지만, 원인 분리가 여기서 시작됩니다. 

아래 체크만 해도 대응 방향이 바로 갈립니다.

증상	먼저 볼 것	대응
설치 중 다운로드에서 멈춤	Windows Update/WSUS 접근 여부	오프라인 패키지 또는 설치 미디어(SxS) 활용
0x800F081F 등 구성요소 원본 없음	설치 원본 경로 누락	SxS 경로 지정 또는 패키지 재확보
설치는 되는데 앱이 계속 오류	앱이 정말로 3.5만 필요한지	앱 업데이트 또는 대체 버전 검토
서버/VDI에서 일부만 성공	이미지 버전/정책 차이	표준 이미지에 설치 방식 통일

오프라인 설치가 필요한 경우에 쓸 수 있는 명령

외부망이 막힌 서비스 환경에서는 온라인 설치가 처음부터 성공하기 어렵습니다. 

이럴 땐 Windows 설치 미디어(ISO)에 들어있는 SxS 원본을 지정해 설치하는 방식이 자주 쓰입니다. 연결이 필요한 동작을 줄이기 때문에 실패 확률이 낮아집니다.

DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /Source:D:\sources\sxs /LimitAccess

위 명령에서 D:\sources\sxs는 마운트한 ISO 드라이브 문자에 맞춰 바꿔주시면 됩니다.

보안/운영 관점에서 주의할 점

3.5는 레거시 호환성 때문에 남아 있는 구성요소라서, 무조건 깔아두는 방식은 권장하기 어렵습니다. 

필요한 PC에만 설치하고, 업무 앱 교체 일정을 함께 잡아두면 관리 부담이 눈에 띄게 줄어듭니다.

• 설치 대상 최소화: 전사 기본 이미지에 포함시키기보다, 요구 앱이 있는 부서/장비로 한정하는 편이 낫습니다.
• 패키지 보관 정책: 독립 설치 방식으로 바뀌면 “설치 파일을 어디에 두고 누가 배포하나”가 바로 이슈가 됩니다.
• 격리 운영: 가능하면 레거시 앱은 별도 VDI/가상머신 같은 분리된 영역에서 돌리면 리스크가 낮아집니다.

결론부터 말씀드리면, 3.5를 설치하는 행동은 “당장 앱이 돌아가게 만드는 응급처치”에 가깝습니다. 운영 환경에서는 아래 선택지를 같이 놓고 판단하시는 편이 안전합니다.

• 앱 업데이트/교체: 가능하면 .NET Framework 4.8 이상 또는 최신 .NET 기반으로 올리는 방향이 유지관리에서 유리합니다.
• 레거시 전용 실행 환경: 업무용 구형 클라이언트만 따로 실행할 PC/VM을 분리하면 예상치 못한 충돌이 줄어듭니다.
• 설치 자동화: 대상 장비가 많다면 스크립트/배포 도구로 설치 방식을 고정해두면 헷갈림이 줄어듭니다.

Q. Windows 11에서 ‘Windows 기능 켜기/끄기’에 .NET Framework 3.5가 안 보이는데 고장인가요?

A. 빌드 27965 이후 계열이면 정상 동작일 가능성이 큽니다. 이 환경에서는 체크로 추가하는 방식이 막힐 수 있습니다.

Q. .NET Framework 3.5를 설치했는데도 앱이 계속 에러가 납니다. 무엇부터 확인하나요?

A. 앱이 3.5만 요구하는지부터 확인하셔야 합니다. 설치 로그나 에러 메시지에 v2.0.50727 관련 문구가 없다면 다른 원인일 수 있습니다.

Q. 오프라인 PC에서 0x800F081F가 자주 나옵니다. 바로 해결할 방법이 있나요?

A. 설치 원본(SxS) 경로가 없는 경우가 많습니다. Windows 설치 ISO를 마운트한 뒤 DISM에 \sources\sxs 경로를 지정하면 해결되는 경우가 많습니다.

Q. Windows 업그레이드(차기 버전)하면 3.5가 유지되나요?

A. 환경에 따라 유지되지 않고 다시 요구되는 경우가 있습니다. 업그레이드 후 레거시 앱을 실행해 즉시 확인하시는 편이 안전합니다.

Q. 전사 표준 이미지에 3.5를 넣어두는 게 낫지 않나요?

A. 레거시 앱이 확실히 필요한 조직이 아니면 권장하기 어렵습니다. 필요 대상을 좁히는 편이 운영 리스크와 관리 비용이 같이 줄어듭니다.