JavaFX 리뷰
JavaFX는 AWT - Swing 에 이은 Java GUI 프레임워크입니다. Java의 특성상 크로스플랫폼을 지원하는 데스크탑 앱 및 안드로이드 앱까지 제작할 수 있으며, AWT나 Swing에 비해 풍부한 UI를 제공할 수 있습니다. 이 글에서는 JavaFX의 사용경험을 토대로 리뷰해 보겠습니다.
👍 1. 장점
1-1. 크로스플랫폼
Java의 특성상 JVM이 올라갈 수 있는 모든 플랫폼에서 작동할 수 있습니다. 모든 OS에서 작동하는 추상화된 API들이 제공됩니다. 물론 너무 특정 OS 종속적인 기능은 제공되지 않습니다.
1-2. 다양한 유틸리티 제공
JavaFX는 MVVM 패턴사용을 지원하는 다양한 바인딩 유틸리티를 제공합니다. 또한 렌더링을 담당하는 JavaFX Application Thread와 로직처리를 하는 Worker ThreadPool를 제공합니다. 유틸리티 API들은 두 스레드간의 연동을 매끄럽게 지원합니다.
1-3. Scene Builder
Scene Builder가 제공되어, 드래그 & 드롭으로 화면을 구성하고 확인할 수 있습니다. 다만 이를 위해 FXML 사용이 강제됩니다.
Scene Builder screenshot from Gluon
1-4. 라이센스
JavaFX는 오픈소스입니다. 따라서 Java 그 자체와 더불어 라이센스 문제가 없습니다.
1-5. Java 사용가능
조금은 웃길 수 있지만, Java를 좋아하는 사람들에게는 다른언어를 추가로 학습하지 않고 GUI를 만들 수 있습니다. 그리고 Java 맥락 안에서는 AWT, Swing 에 비해 풍부한 UI를 제공할 수 있습니다.
👎 2. 단점
2-1. FXML과 CSS
HTML/CSS 만큼 레이아웃을 자유롭게 구성할 수 없습니다.
우선 FXML 측면에서 이야기 해보겠습니다.
기존 HTML/CSS는 div와 css만으로 레이아웃을 구성할 수 있습니다. 하지만 JavaFX는 랜더링 로직이 살짝 다릅니다. 그래서 레이아웃 전략 별 특별한 div들이 제공됩니다. (AnchorPane, BorderPane 등을 의미합니다.) 하지만 기본제공 Pane 들로 구성할 수 없는 레이아웃도 있고, 결국에는 Pane 클래스를 확장해야 하는 경우가 생깁니다. 이 경우 FXML의 장점이었던 SceneBuilder 연동이 불가능합니다.
FXML의 주요 목적은 레이아웃 논리의 분리입니다.
하지만 해당 목적 달성을 위해 불필요하게 복잡성이 증가하며, 레이아웃 이외의 것들은, 그리고 레이아웃의 일부 마저 고스란히 코드로 흘러들어오게 됩니다. 대부분 대규모 프로젝트에서 FXML을 거의 사용하지 않습니다.
JavaFX에서 Controller로 표현하는 레이어는 사실 MVC의 Controller가 아니라, View에 더 가깝습니다.
FXML로 View의 일부분만을 분리한다는 것을 더 여실히 알 수 있으며, 해당 표현으로 인해 혼란이 더 심해지는 경향이 있습니다.
이번엔 CSS 측면을 보겠습니다.
width: 50%는 사용할 수 없습니다. JavaFX 렌더링 아키텍처에 의해%는 지원되지 않기 때문입니다.width: 50px는 어떤 컴포넌트는 사용할 수 없습니다. resizable하지 않기 때문입니다.
대부분의 css 프로퍼티들은 -fx- 접두사가 붙은 특화 프로퍼티를 사용해야 합니다. 위에서 본 것 처럼 JavaFX의 랜더링 로직과 밀접한 연관이 있기 때문입니다.
추가적으로 Transition도 사용할 수 없기 때문에 직접 코드에서 작성해야 합니다. 따라서 기존 Web 개발자들의 CSS 경험과도 온전히 연결되지는 않습니다.
차라리 확장자를 .css 대신 .fxss 같은 걸로 했다면 오해가 줄어들지 않았을까요? 애초에 CSS Parser도 전용파서를 사용하는데 말입니다…
2-2. 학습곡선
출시할 때 기본 Java 개발자들의 학습곡선을 많이 줄였다고 했었지만, 실제로는 그렇지 않습니다.
간단한 프로그램이라도 제대로 만들기 위해서는 JavaFX 아키텍처에 대한 이해가 동반되어야 합니다. 핵심적인 부분은 Application Thread와 Worker Thread의 연동을 API들이 어떻게 지원하고 있는지를 알아야 합니다.
- 예를 들어, 바인딩된 Property의 ChangeListener는 별다른 작업 없이도 Application Thread에서 실행됩니다.
- Service의 콜백이나 AnimationTimer, EventHandler, Initializable::initialize, 그 외 @FXML 바인딩 핸들러들 또한 마찬가지입니다.
- 따라서 실제로
Platform.runLater를 사용할 일이 거의 없습니다. 자주 사용했다면 프레임워크를 잘못 이해하고 있을 가능성이 높습니다.
이런 동작들은 JavaFX가 어떤 맥락에서 유틸리티들을 제공했는지를 이해해야 합니다. 바인딩 개념은 특히 MVVM 패턴과 관련이 있습니다. 즉, 핵심구조인 MVVM을 제대로 사용할 수 있어야 코드가 더러워지지 않습니다. 하지만 깔끔하게 종속성을 관리하고 코드영역을 분리하는 것이 쉬운 일은 아닙니다. 디자인패턴과 같은 선수지식도 필요하며, 실제로 계층을 나누기 애매한 경우도 많습니다. 또한 JavaFX는 굳이 MVVM을 강제하지는 않습니다. 하지만 자유도가 높을수록 초보자에게는 훨씬 힘듭니다.
JavaFX 커뮤니티를 보면 JavaFX로 만들 수 있는 프로그램에는 한계가 없습니다. Trinity 같은 멋진 프로젝트를 보세요. 하지만 코드를 보면 알 수 있듯, 그만큼 노련해야만 가능함을 알 수 있습니다.
2-3. 커뮤니티
JavaFX는 인기있는 기술이 아니기 때문에 생태계가 작은 편입니다. 하지만 그만큼 대부분 고인물들로 구성되어 있습니다. 인터넷에서 좋은 정보의 양이 굉장히 적은 편이지만, StackOverflow 같은 커뮤니티에서 도움은 확실하게 받을 수 있습니다.
🤔 3. 고려해 볼 문제들
3-1. JRE 제공
Java 어플리케이션은 JVM 위에서 동작하기에 사용자는 JRE가 설치되어 있어야 합니다. 하지만 jlink 툴을 이용해서 custom JRE를 제작할 수 있습니다. JavaFX 어플리케이션 배포 포스팅을 참고해 주세요. 이를 통해 간단한 프로그램의 경우 JRE 포함하여 30MB 정도의 용량만으로 배포할 수 있습니다. 따로 JRE를 설치할 필요가 없는것은 덤입니다.
3-2. VM 튜닝
JavaFX는 최적화하지 않으면 Hello World! 띄우는데에 200MB 정도까지도 메모리를 잡아먹습니다. 이는 성능관점에서 Heap을 미리 할당해두기 때문입니다.
요즘 컴퓨터 사양들을 보면 크게 부담될 용량은 아니지만 가벼운 프로그램을 만들고 싶은 입장에서는 신경이 쓰일 수 있습니다. VM Option을 통해 적절하게 옵티마이징할 수 있지만, 이는 또 하나의 학습곡선이 되어 버립니다.
📝 4. 총평
분명히 나쁘진 않습니다. 저는 Java를 좋아하는 편이고, 프레임워크이기 때문에 JavaFX 또한 익숙해질수록 편해지기 때문입니다. 하지만 분명히 인력을 구하기는 쉽지 않습니다. 저는 어느정도 JavaFX에 정이 들었지만, 쉽게 추천하기는 힘들 것 같습니다. 프로덕션에 도입한다면 특히 인력문제를 진지하게 생각해보아야 합니다. 취미로 사용해본다면 숨겨진 학습곡선이 꽤 있다는 것을 인지해야 합니다.