2020년 IntelliJ 플랫폼 로드맵
IntelliJ IDEA 및 IntelliJ 플랫폼 기반의 다른 IDE를 개선하기 위해 현재 진행하고 있는 작업 중 일부를 공개합니다. 이러한 작업의 결과물은 내년에 출시될 예정이며, 일부는 봄에 2020.1 릴리스에서 곧 제공됩니다. 작업의 두 가지 주요 테마는 최신 개발 워크플로에 대한 성능 및 지원에 중심을 두고 있습니다.
성능
인덱싱 성능
IDE 성능과 관련된 두 가지 주요 문제점은 시작 성능(시작하는 데 시간이 오래 걸리는 도구가 무거운 것으로 파악됨)과 색인 구성 속도입니다. 올해는 시작 속도를 높이기 위해 많은 노력을 기울였으며 내년에는 색인 생성 성능에 주력할 예정입니다.
JetBrains는 이 문제를 다각적으로 접근하고 있습니다. 먼저, 사전 구축된 색인 청크를 사용할 수 있도록 하여 지구상의 모든 IntelliJ 인스턴스가 동일한 java.lang.String 클래스의 색인 생성 작업을 수행할 필요가 없도록 하려 합니다. 이 지원은 JDK부터 시작하여 Maven Central 라이브러리와 다른 IDE의 인터프리터 및 패키지까지 1년 내내 계속 확장할 계획입니다. 팀 또는 기업 내에서 프로젝트 소스 코드에 대한 색인 청크 공유를 지원하는 방법도 찾아보고 있지만 현재 구체적인 계획은 없습니다.
둘째, 색인 생성 중에 더 다양한 IDE 작업을 할 수 있도록 만들어 색인 생성이 덜 방해되게 할 계획입니다.
셋째, 색인을 생성하는 데 시간이 오래 걸리는 파일, 색인 생성이 너무 자주 반복되는 파일, 예외로 인한 색인 재구성 등, 비정상적인 색인 생성을 파악하여 알릴 예정입니다. 목표는 이러한 문제를 해결하고 프로젝트에서 IDE의 성능을 향상할 수 있는 명확한 단계를 제시하는 것입니다.
물론 색인 생성 시스템이 불필요한 작업을 수행하지 않고 불가피한 오버헤드가 발생하지 않도록, 성능 최적화에도 계속 투자할 것입니다.
읽기/쓰기 잠금 스레딩(Threading) 모델 재설계
사용자를 괴롭히는 또 다른 주요 문제는 UI 멈춤 현상입니다. 올해는 이러한 멈춤 현상을 보고하기 위한 인프라를 구축하고 파일 시스템 이벤트에 대한 비동기 리스너와 같은 다양한 문제를 해결하기 위해 아키텍처를 변경했습니다. 내년부터는 좀 더 진보해서 쓰기 잠금이 필요한 작업을 UI 스레드에서 옮기려고 합니다.
초창기 IntelliJ IDEA에서는 IDE의 내부 데이터 구조를 수정하는 대부분의 작업이 UI 스레드에서 실행되어야 한다는 아키텍처적인 결정을 내렸습니다. 작업에는 기본 작업(예: 문자를 문서에 삽입)과 대규모 작업(예: 사용 위치가 수천 개인 메소드의 이름 변경)이 모두 포함됩니다. 이 아키텍처의 이점은 프로그래밍 모델이 간단하다는 것이지만 많은 시나리오에서 UI 응답 속도가 저하되는 문제가 있습니다.
수년 동안 이 아키텍처의 한계를 극복할 방법을 찾아왔습니다. 주로 대규모 작업을 백그라운드에서 실행하게 하고, UI 스레드에 적용되는 부분으로 분할하는 방법을 취했습니다. 더 근본적인 해결책은 UI 스레드의 요구 사항을 완전히 없애는 것이었지만 자체 코드 및 타사 플러그인을 대대적으로 재작성하지 않고 이 작업을 수행하는 방법을 최근까지 알지 못했습니다. 하지만 이제 단계별 마이그레이션을 수행할 수 있는 아키텍처 솔루션이 마련되어 이를 구현하는 작업을 시작할 예정입니다.
2020년에는 IntelliJ 플랫폼의 필수 UI 구성 요소 및 API를 리팩토링하여 새로운 스레딩 모델을 도입할 것입니다. 새 모델이 안정되고 개선 효과가 눈에 보이면 모든 IDE에서 새 모델로 전환하여 UI가 원활하게 지연 없이 작동하도록 만들계획입니다.
재시작할 필요 없이 플러그인을 로드 및 언로드
이 기능의 경우 IntelliJ IDEA 2019.3에서 미리 체험해 보셨겠지만 재시작하지 않고도 테마 및 단축키 플러그인을 설치할 수 있습니다. 2020.1에서는 이 지원 기능을 모든 유형의 플러그인으로 확장할 계획입니다. 번들로 제공되는 수많은 플러그인을 재시작할 필요 없이 로드 및 언로드할 수 있도록 지원할 것이며 제3자 플러그인 개발자를 위한 지원 지침도 제공할 예정입니다. 이 단계에서 사용자에게 있어 가장 중요한 이점은 IDE를 다시 시작할 필요 없이 플러그인을 원활하게 업그레이드할 수 있다는 것입니다.
2020.1 버전 이상에서 진행되는 이 작업의 최종 목표는 IDE에서 여는 프로젝트 각각에 맞게 IDE 크기가 조정되도록 하는 것입니다. Spring 플러그인은 Spring을 사용하는 프로젝트에만 로드되고 Angular 플러그인은 Angular 프로젝트에만 로드되게 될 예정입니다. 기술을 사용하지 않으면 관련 UI 요소가 표시되지 않으며 해당 기술을 지원하는 플러그인의 성능 또는 메모리 사용량에 영향을 미치지 않습니다.
워크플로 지원
공동 편집
공동 편집 작업은 이슈 트래커에서 가장 많이 득표한 요청으로, 현재 작업이 진행되고 있음을 알려 드리게 되어 기쁩니다. 현재 지향하는 접근 방식에서는 소스 코드가 있는 시스템에서 실행되는 기본 IDE가 하나 있으면 다른 사용자가 기본 IDE를 “씬 클라이언트”로 삼아, 다이렉트 소스 코드 액세스 없이 자신의 IDE와 직접 연결할 수 있게 됩니다. 연결된 모든 사용자는 원하는 경우 다른 사용자를 “팔로우”할 수 있는 옵션을 비롯해 자체 상태(열린 파일 모음, 캐럿 위치, 다양한 코드 완성 목록 등)를 갖을 수 있습니다.
“씬 클라이언트” 사용자는 탐색, 코드 완성, 디버그와 같은 핵심 IDE 기능에는 액세스할 수 있지만 전체 기능 모음은 이용할 수 없습니다. 예를 들어 초기 버전에서는 씬 클라이언트가 버전 관리 작업을 수행하지 못할 수 있습니다. 현재 씬 클라이언트에 제공될 전체 기능 모음은 결정되지 않았으므로 특정 기능이 지원될지 여부나 시기에 관한 질문에는 답변할 수 없습니다.
공동 편집 지원 기능은 Rider 프로토콜을 기반으로 하므로 Rider에서 처음 출시된 다음 다른 IDE로 확장될 가능성이 높습니다. 하지만 이 방향의 작업은 오랜 시간이 걸리므로 IntelliJ IDEA 2020.1에서 출시되기는 힘들것 같습니다.
또한 공동 편집에 대한 현재 접근 방식은 JetBrains 자체 프로토콜을 기반으로 하며 비 JetBrains IDE와의 상호 운용성을 지원하지 않습니다.
공동 편집 이외에, 클라우드에서 IDE 백엔드를 실행하는 등 다른 시나리오에도 “씬 클라이언트” 접근 방식을 확장할 수 있을지 고려하고 있지만 해당 영역의 특정 계획을 아직 발표할 준비는 되지 않았습니다.
클라우드 실행 지원
꽤 오랜 시간 동안 여러 JetBrains 제품이 사용자 시스템 이외의 시스템 또는 컨테이너 내부에서 코드 실행 및 디버그를 수행할 수 있도록 지원해왔습니다. 그러나 서로 다른 제품에서 이러한 기능의 구현 방식은 공유된 부분이 많지 않았으며 Docker 지원과 같은 기본 기능조차도 UI가 일치하지 않습니다.
그러나 이제 대상 환경이라는 일반 개념이 도입되어 대상 환경에서 파일을 복사하고 프로세스를 시작할 수 있습니다. IntelliJ IDEA 2020.1에서 지원되는 환경에는 로컬 시스템, Docker 컨테이너 또는 ssh를 통해 연결된 시스템이 포함됩니다. 대상 환경의 선택은 처음에 Java 및 Go 실행 구성에서 가능합니다.
이후 릴리스에서는 기존 Docker 및 원격 인터프리터 지원 기능이 새로운 아키텍처에 통합될 예정입니다. 또한 더 심층적인 클라우드 통합을 제공하므로 연결할 특정 시스템의 세부 정보를 지정할 필요 없이 클라우드의 새 VM에서 해당 프로세스를 실행할 수 있게 됩니다.
프로젝트 모델 재설계
프로젝트 모델은 IDE가 프로젝트의 구조를 나타내는 방식(프로젝트에 속한 파일, 파일의 종속 관계, 사용되는 라이브러리 등)입니다. IntelliJ IDEA의 프로젝트 모델은 여러 해 동안 유용하게 사용되고 있지만 특정 제한이 있습니다. 첫째, 다른 유형의 프로젝트를 임의로 혼합하는 것을 지원하지 않습니다. 예를 들어 AppCode는 Xcode 프로젝트를 열 수 있고 Rider는 Visual Studio 솔루션을 열 수 있지만 Gradle 프로젝트와 Xcode 프로젝트를 동일한 IDE 프레임에서 열 수 있는 방법은 없습니다. 둘째, 프로젝트 모델은 파일이 아닌 디렉터리 수준에서 작동하므로 동일한 디렉터리에 있지만 종속 요소가 다른 파일들을 표시할 수 없습니다. 이로 인해 Bazel과 같은 빌드 시스템을 IDE에 통합하기가 어렵고 다른 시나리오에서 문제가 발생합니다.
내부적으로 “작업 공간 모델”이라고 하는 재설계된 프로젝트 모델에서는 이러한 제한이 사라집니다. 또한 프로젝트를 열 때의 성능이 개선되고 Maven 및 Gradle과 원활하게 동기화되며 프로그래밍 모델이 향상되는 등, 추가 이점이 있습니다. 이 작업은 우선 JetBrains 내부에 구현된 설계를 작업 공간 모델로 변경하는 것으로 시작하여, 모델이 안정되면 임의 유형의 프로젝트를 동일한 IDE 프레임에 결합하는 등, 사용자가 볼 수 있는 기능을 추가할 계획입니다.
요약
이 글에 설명된 작업들은 JetBrains 팀이 진행 중인 내용의 일부에 지나지 않으며 계획에 대한 자세한 정보는 향후에 게시될 것입니다. 물론 이 모든 내용은 변경될 수 있으며 위에 설명 된 작업 중 일부는 출시되지 않을 수 있지만 대신 다른 멋진 기능을 제공할 것입니다.
의견이 있으시면 아래에 자유롭게 남겨주세요. 그리고 이러한 작업 중 일부를 체험할 수 있는 시기가 게시되는 얼리 액세스 프로그램(EAP) 공지도 계속 확인해 주세요.
Happy Developing!
본문은 Dmitry Jemerov의 IntelliJ Platform Roadmap for 2020를 번역한 글입니다.
Subscribe to JetBrains Blog updates
