2026.2 버전부터 IntelliJ IDEA, WebStorm, PhpStorm에서 Windows Subsystem for Linux, 즉 WSL 내부에 있는 프로젝트를 열면 JetBrains가 Native 모드라고 부르는 방식으로 실행된다. 이 모드에서 IDE는 Windows에서 실행되는 애플리케이션으로 유지되며, WSL 내부의 작은 에이전트가 IDE를 대신해 파일 및 프로세스 작업을 수행한다. 회사는 현재 이 방식을 권장되는 진입점이라고 설명한다. Remote Development 옵션은 시작 화면에서 계속 사용할 수 있지만, 더 이상 WSL 프로젝트를 여는 선호 방식은 아니다.
이는 단순히 사용자 인터페이스의 이름을 바꾸는 문제가 아니다. WSL 내부에 있는 Linux 프로젝트를 지원하려면 개발 환경이 파일에 접근하고, 올바른 경로에서 도구를 실행하며, 환경 변수를 관리하고, 빌드·디버깅·프로파일링 프로세스를 실행하면서도 지연 시간을 충분히 낮게 유지해 자연스러운 사용 경험을 제공해야 한다. JetBrains는 기존 방식이 진입 지점에 따라 서로 다른 아키텍처를 사용했으며, 이로 인해 제품과 시나리오별 성능 및 동작에 차이가 발생했다고 설명한다.
9P 경로가 더 이상 충분하지 않은 이유
기존 방식에서는 Windows의 JetBrains 애플리케이션이 9P 파일 시스템 프로토콜을 통해 WSL 파일에 접근했고, GeneralCommandLine 클래스가 Linux 환경에서 실행되는 명령을 정규화했다. 이를 통해 WSL 프로젝트를 대상으로 IDE를 실행할 수 있었지만, 읽기 및 인덱싱 작업의 상당 부분이 Windows와 WSL을 호스팅하는 가상 머신 사이의 경계를 넘어 수행되었다.
JetBrains에 따르면 세 가지 주요 문제가 나타났다. 첫째, 9P는 \\wsl$ 경로를 통해 Linux 심볼릭 링크를 올바르게 표시하지 않으므로 IDE가 일부 트리를 확인하거나 인덱싱하지 못할 수 있다. 이 문제는 pnpm 작업 영역, Python 가상 환경, 경로에 의존하는 Composer 저장소처럼 심볼릭 링크를 사용하는 환경에 영향을 준다. 둘째, 접근 시 Microsoft Defender 검사가 WSL 파일 읽기 시간을 수십 초까지 늘릴 수 있다. 셋째, 인덱싱처럼 많은 작은 파일을 처리하는 작업에서는 이 프로토콜이 상당한 지연을 추가한다.
또한 명령 실행 계층 때문에 플랫폼 개발자는 코드베이스의 여러 부분에서 WSL 전용 의미론을 처리해야 했다. JetBrains는 이로 인해 해당 방식이 비로컬 작업 환경을 위한 통합된 기반이 되기보다 확장 및 유지 관리가 더 어려워졌다고 본다.
Remote Development가 추가한 것
Remote Development는 문제를 반대 방향에서 해결했다. IDE의 전체 backend가 WSL로 이동하고, Windows에는 인터페이스를 표시하며 사용자 입력을 받는 클라이언트가 남는다. 양쪽은 JetBrains RD 프로토콜을 통해 통신하며, 이벤트 모델과 편집기 및 프로젝트 상태를 양방향으로 전송한다. 인덱싱, 분석, 빌드, 디버깅, 버전 관리 작업 같은 무거운 작업은 파일과 가까운 WSL 내부에서 실행된다.
이 설계는 파일 접근에서 9P에 직접 의존하지 않게 했지만, 다른 비용을 추가했다. JetBrains에 따르면 backend에는 약 2GB의 디스크 공간이 추가로 필요하며, WSL 내부에서 이를 다운로드하고 설치하는 시간도 필요하다. 또한 클라이언트와 backend 사이의 지속적인 상호작용은 인터페이스 상태와 사용자 입력을 계속 전송해야 하므로 응답성에 영향을 줄 수 있다. 제품 개발 자체도 코드를 클라이언트와 서버 부분으로 분리해야 하므로, 일부 모듈이 분리되지 않은 상태로 남아 있으면 동적인 인터페이스에서 지연이나 멈춤이 발생할 수 있다.
Native 모드는 어떻게 작동하는가?
새로운 방식은 IJent라는 에이전트를 기반으로 한다. 이 에이전트는 9P나 일반 실행 계층을 통해 전달하는 대신 대상 환경 내부에서 파일 및 프로세스 작업을 수행한다. JetBrains는 IJent를 Rust로 작성된 작은 구성 요소라고 설명하며, 이를 통해 WSL이나 컨테이너 내부에 Java 또는 Kotlin과 같은 추가 실행 의존성을 설치할 필요를 줄일 수 있다고 말한다.
IJent는 Stdio 기반 전송 계층을 사용한다. 이 방식은 이식성이 있고 방화벽 포트를 열 필요가 없으며, WSL의 Hyper-V 소켓은 특히 많은 수의 파일을 전송할 때 더 빠른 경로를 제공한다. 파일 시스템 작업이 Linux 환경 자체에서 실행되므로 경로와 심볼릭 링크 처리가 Linux 본래의 의미론에 더 가까워진다. 외부 플러그인도 해당 플러그인의 파일 작업이 IJent를 통해 전달될 때 이러한 이점을 활용한다.
IJent는 JetBrains가 플랫폼 개발자와 플러그인 작성자에게 로컬 환경과 원격 환경의 차이를 숨기기 위해 설계한 EelApi 인터페이스와 연결된다. 이 모델에 따르면 동일한 코드가 각 환경에 맞는 별도 로직을 추가하지 않고도 로컬, WSL, Docker 또는 Dev Container 환경을 처리할 수 있다. 회사는 IJent가 EelApi 인터페이스를 구현하고 실제 기능을 제공한다고 설명한다.
테스트 결과는 무엇을 보여주는가?
JetBrains는 23개의 하위 프로젝트와 8,191개의 소스 파일로 구성된 spring-framework 프로젝트를 콜드 오픈하는 테스트에서 9P 모드와 IJent 모드를 비교했다. 측정은 WSL 2와 Ubuntu 24.04가 설치된 Windows 11에서 IntelliJ IDEA Ultimate 263.SNAPSHOT 버전을 사용해 수행했으며, 결과는 5회 실행의 중앙값을 기준으로 했다.
- 작업 준비: 18.5초에서 11.5초로 줄어 38% 개선되었다.
- 프로젝트 트리 검사: 8.1초에서 3.7초로 줄어 54% 감소했다.
- 파일 인덱싱: 10.8초에서 8.4초로 줄어 22% 개선되었다.
- 파일 내용 읽기: 12.2초에서 5.7초로 줄어 53% 감소했다.
회사는 파일 수가 적은 소규모 프로젝트에서는 동일한 테스트에서 측정 가능한 차이가 나타나지 않았다고 덧붙인다. 따라서 실질적인 이점은 대규모 프로젝트나 많은 파일에 반복적으로 접근하는 작업 흐름에서 가장 크게 나타난다.
개발자에게 이것은 무엇을 의미하는가?
가장 중요한 변화는 기존의 모든 옵션을 즉시 없애는 것이 아니라, 권장되는 진입점과 아키텍처를 통합하는 것이다. 지원되는 제품에서 WSL 프로젝트를 직접 여는 사용자는 Native 모드를 사용하게 되며, Remote Development는 이 경로를 선택하거나 클라이언트와 backend를 분리한 모델이 필요한 사용자에게 계속 유용하다. WSLg를 통해 IDE 자체를 실행하는 방식은 기술적으로 가능하지만, JetBrains는 그래픽, 창 관리, 입력과 관련된 제약 및 Windows 내부의 Linux 표시 계층에 대한 애플리케이션의 의존성 때문에 이를 우선 지원되는 작업 흐름으로 보지 않는다고 설명한다.
공개된 결과는 일부 작업에서 뚜렷한 개선을 보여주지만, 테스트 범위는 특정 프로젝트, 환경, 버전으로 제한되어 있다. 따라서 이 수치만으로 모든 프로젝트나 플러그인에서 일관되게 우수하다고 입증할 수는 없다. 또한 새로운 아키텍처를 더 많은 JetBrains 제품에 적용하는 작업은 아직 진행 중이므로, 다양한 환경에서의 플러그인 호환성과 동작은 계속 지켜볼 필요가 있다.