JetBrains는 Windows에서 Rider와 ReSharper 사용자들이 보고한 시작 지연이 전적으로 두 도구의 아키텍처 때문은 아니며, 두 도구를 실행할 때 Microsoft Defender가 수행하는 검사와 상당한 관련이 있다고 밝혔습니다. 회사의 결과에 따르면 ReSharper가 Visual Studio 외부에서 별도의 프로세스로 실행될 때 Defender는 첫 실행에 수십 초를 추가했지만, 다른 도구들의 검사는 1초 이내에 완료되었습니다.
이 결과는 ReSharper가 프로세스 외 실행(Out-of-Process 또는 OOP) 아키텍처를 채택한 이후에 나왔습니다. JetBrains는 Visual Studio의 응답성에 미치는 ReSharper의 영향을 해결하기 위해 이 아키텍처를 개발했습니다. 회사는 전년도에 OOP 모드를 공개적으로 출시했으며, ReSharper 2026.2.1에서는 기본적으로 활성화되었습니다. 내부 측정에서 전반적인 성능 향상이 나타났지만, 사용자 보고에서는 시작 속도 저하가 나타나기 시작했고, 이에 따라 JetBrains는 더욱 상세한 분석을 수행했습니다.
지연은 어디에서 발생했는가?
JetBrains는 ETW(Event Tracing for Windows)를 통한 Microsoft Defender의 추적 로그와 직접적인 프로세서 시간 측정에 초점을 맞췄습니다. 회사는 Microsoft-Antimalware-Engine 제공자의 이벤트, 특히 각 검사 작업의 시작과 종료를 기록하는 StreamScanRequestTask 이벤트를 사용했습니다.
데이터에 따르면 쓰기 보호 경로에 있는 파일에는 신뢰 규칙이 적용되어 Defender가 시작 과정에서 해당 파일을 더 가볍게 처리했습니다. 그러나 ReSharper가 별도의 프로세스로 작동하기 시작하자 사용자 설치 폴더에서 로드되는 DLL 라이브러리를 포함해 전체 검사를 받았습니다. 그 결과 검사 시간은 약 몇 초에서 일부 경우 수십 초로 증가했습니다.
JetBrains는 수십 개의 개발 도구를 분석했으며, 도구 사이에 큰 차이가 있음을 확인했습니다. JetBrains 환경과 다른 편집기 계열 도구의 콜드 검사 시간은 대략 10~40초였지만, 같은 테스트에서 Microsoft 환경과 다른 편집 도구는 1초 미만을 유지했습니다. 명령줄 기반 도구는 대략 2초 미만이 걸렸으며, 회사는 이를 작은 실행 파일과 제한된 DLL 라이브러리 수 때문인 것으로 추정했습니다.
테스트와 Microsoft와의 협력
측정은 16코어 Intel Core Ultra 9 285H 프로세서와 64GB DDR5 메모리를 탑재한 Dell Pro Max 16 (MA16250) 컴퓨터에서 Windows 11 Pro를 사용해 진행되었습니다. 도구는 8개의 vCPU와 8GB의 고정 메모리가 할당된 Hyper-V 가상 머신에서 실행되었습니다. JetBrains는 각 도구를 10회 측정했으며, 파일 및 메모리 캐시의 영향을 줄이고 콜드 시작을 모의하기 위해 각 시도 전에 가상 머신을 재부팅했습니다.
JetBrains는 이용 가능한 문서를 검토한 뒤에도 처음에는 모든 검사 규칙을 해석할 수 없었기 때문에 Microsoft 팀에 연락했습니다. 협력을 통해 Defender가 더 많은 작업을 수행하게 만드는 요인을 파악하고, Rider가 IntelliJ IDEA와 ReSharper를 합친 것보다 더 집중적인 검사를 받는 이유를 설명하는 데 도움을 얻었습니다.
Microsoft는 쓰기 보호 폴더 안에 설치된 Rider 및 ReSharper OOP의 특수한 상황을 해결하기 위해 1.449.454.0 버전에서 Defender를 수정했습니다. 그러나 JetBrains Toolbox는 기본적으로 %LOCALAPPDATA%\Programs 경로에 설치되며, 이 경로는 권한 상승 없이 쓰기가 가능하므로 보호 폴더와 관련된 개선의 혜택을 받지 못합니다. JetBrains는 Toolbox를 통한 Rider 설치와 Microsoft Defender 제외를 처리하는 최선의 방법을 계속 평가하고 있다고 밝혔습니다.
Defender 영향을 측정하는 도구
JetBrains는 개발자와 게시자가 동일한 조사를 수행할 수 있도록 Defender Performance Tool을 출시했습니다. 이 도구를 사용하면 애플리케이션 시작, 플러그인 로드 또는 컴파일 작업 수행 중 검사 활동을 실시간으로 모니터링할 수 있습니다. 또한 New-MpPerformanceRecording을 사용해 사전에 기록한 캡처를 열고 나중에 분석할 수 있으며, 여러 캡처를 처리할 때 CSV 데이터를 내보낼 수도 있습니다.
JetBrains는 관리형 환경에서 Microsoft Defender에 로컬 제외를 추가하는 작업이 시스템 관리자로 인해 차단될 수 있다고 지적합니다. 따라서 이 단계를 항상 이용할 수 있는 해결책으로 제시하지 않으며, 느려진 원인을 파악하거나 기업 보안 정책을 따르는 대신 자동으로 적용해서도 안 됩니다.
개발자에게 실제로 달라지는 점은 무엇인가?
이 사례는 개발 환경의 성능 측정이 애플리케이션 실행 시간이나 도구 자체의 메모리 사용량에만 국한되지 않는다는 점을 보여줍니다. 지연은 프로그램과 병렬로 작동하는 보안 계층에서 나타날 수 있으며, 그 영향은 설치 방식, 파일 위치, 시작 시 로드되는 라이브러리 수에 따라 달라집니다.
JetBrains는 Microsoft Defender 정의를 최신 상태로 유지하고, Defender 성능 조사에 사용하는 PowerShell 모듈을 활용하며, 설명되지 않는 지연이 관찰될 때 새 측정 도구를 사용해 볼 것을 권장합니다. 또한 쓰기 보호 폴더에 프로그램을 설치하고, 필요한 경우 Add-MpPreference 명령을 사용해 제외를 설정하며, 저장소와 패키지 캐시를 보관하기 위해 Dev Drive를 생성하는 방법도 언급합니다.
편집자 해설: 가장 중요한 변화는 Rider나 ReSharper의 단순한 내부 개선이 아니라, 개발 도구 설계와 보안 검사 메커니즘 사이의 명확하지 않았던 상호작용이 드러났다는 점입니다. 다만 결과는 특정 테스트 환경, 가상 머신, 제한된 측정 횟수에 기반하므로 모든 Windows 사용자가 동일한 차이를 겪는다는 것을 입증하지는 않습니다. 이 글의 실질적인 가치는 보안 설정을 변경하기 전에 원인을 확인할 수 있는 방법과 도구를 제공한다는 데 있으며, JetBrains Toolbox 설치 지원 문제와 시스템 관리자가 부과하는 제한은 여전히 해결되지 않은 상태로 남아 있습니다.