오랜만에 코딩 좀 하려고 봤더니, 아이오닉의 변화가 상당하네

방치했던 주식 앱도 손을 좀 보고 싶고, 추가하고 싶은 기능이 생겼다. 그리고 만들고 싶은 앱이 몇개 생겼다. 그래서 오랜만에 취미삼아 개인 프로젝트를 좀 해볼까 싶었다. 

근래 익숙했던 아이오닉을 사용할지 아니면 플러터를 사용할지 아주 잠시 고민에 빠졌다.

플러터와 아이오닉은 모두 원소스 멀티유즈가 가능한 개발 플랫폼이다. 1인 개발자가 사용하기엔 정말 좋은 도구다. 하나의 코드베이스로 안드로이드, iOS, 웹(+pwa) 등 다양한 플랫폼에 대응 가능한 결과물을 빌드할 수 있는 것이 큰 장점이다.

다만 미묘한 차이가 있다. 플러터는 코드를 컴파일 하면 앱이 네이티브 수준에서 작동한다. 반면에 아이오닉은 웹뷰 기반이다. 당연히, 앱의 성능은 물론이고 미묘한 화면 처리는 플러터가 월등히 우월하다. 그렇다고 해서 코르도바를 기반으로 한 아이오닉의 성능이 못 쓸 정도도 아니다.

아이오닉은 기존에 HTML, CSS, JS를 잘 사용했던 사람이라면 비교적 금방 익숙해 질 수 있다. 물론 앵귤러를 써 보지 않은 사람에겐 러닝커브가 없진 않다.

나는 오래전부터 꾸준히 아이오닉을 사용해 왔기 때문에 아이오닉을 사용하는 편이 편하다. 플러터를 쓰려면 Dart라는 언어를 새로 배워야 하고 플러터 프로젝트의 구성에 대해서도 공부를 해야하는 등 비교적 가파른 러닝 커브가 발생하기 때문이었다.

아이오닉은 다 좋은데 Angular 베이스라서 약간 마음에 안 드는 부분이 있었다. 그래서 이참에 플러터를 한번 공부해볼까 싶었다. 플러터와 아이오닉 사이에서 마음의 결정을 못 하고 있다가, 우연히 아이오닉 공식 사이트를 보고 깜짝 놀랐다.

기존에 아이오닉으로 만들어뒀던 아이오닉 기반의 레거시 코드를 업데이트 정도는 해야겠다 싶어서 아이오닉 사이트에 들어간 것이었다. 한동안 못 봤던 사이에 아이오닉은 버전이 많이 업그레이드 되어 있었다. 네이티브 기능들도 과거보다 조금 더 잘 지원하고, UI컴포넌트의 갯수도 훨씬 더 많이 늘어났고, 품질도 높아져 있었다.

무엇보다 놀랐던 것은 아이오닉이 이제 더는 앵귤러 베이스의 도구가 아니라는 점이었다.

이제는 아이오닉 프로젝트를 시작하기 전에 리액트, 앵귤러, 뷰 중에서 원하는 자바스크립트 프레임워크나 라이브러리를 선택할 수 있는 기능이 생겼다. 아이오닉 프레임워크도 전면 재개발 되었다.

아이오닉에서 지원하는 프론트엔드 자바스크립트 프레임워크와 라이브러리들

앞으로 아이오닉은 기존의 앵귤러 + 코르도바 기반이 아니라 앵귤러, 리액트, 뷰 중에서 하나를 고를 수 있고 코르도바와 캐파시터를 이용해서 앱을 빌드할 수 있다.

아이오닉은 훌륭한 도구임에도 불구하고 온리 앵귤러 베이스여서 외면 받고 저평가를 받아 온 측면이 없지 않다. 이제 원하는 프론트엔드 프레임워크를 입맛대로 고를 수 있는데다, 빌드 후 성능도 더욱 네이티브에 근접하게 좋아졌다. 

아이오닉 팀에서 누가 이런 생각을 했는지 몰라도 정말 대단하다. 제갈량급 인재라 할만하다. 프론트엔드 프레임워크를 다 쓸 수 있게 고쳐버릴지는 몰랐다. 어쨌든 개인적으로 즐겨쓰는 도구가 사장될까 걱정하던 이용자 입장에서는 날로 진화하는 프레임워크를 보니 안심도 되고 신나기도 한다.

플러터를 좀 배워볼까 하던 나는 플러터 배우기를 조금 뒤로 미뤄뒀다. 당분간은 아이오닉을 이용해서 앱 개발 작업을 조금 더 진행할 예정이다. 어차피 뒷단은 DB에 값을 넣었다 뺐다 하는 단순 웹서비스 베이스의 작업이니 아이오닉을 써도 성능에 크게 무리가 없을 것이고 러닝커브가 없어서 개인적으로 나에게는 유리할 것이다.

하지만 메타버스 시대를 맞아서 조금 더 기기 친화적인 서비스를 만들려면 플러터 공부도 하루 빨리 시작해야 할 것이다.

플랫폼별로 최적화 된 개발을 하는 게 가장 좋겠지만 그건 훗날 혹시라도 팀을 만들게 되면 고려할 사항이다. 혼자서 자바와 스위프트로 플랫폼별 대응을 해 본적이 있는데 일단 딱 하나의 서비스에 인생을 올인할 게 아니면 1인 개발자에겐 리소스 장벽이 있었다. 물론 혼자서 안드로이드, iOS, 웹 플랫폼에 고퀄을 내며 각기 대응하는 능력자 형님들도 계시긴 하지만.