내가 이해한 Ionic Framework

Angular(2+) 기반의 Ionic에 대한 정보를 찾는다면 여기로.


Screenshot-from-2016-04-02-20-06-19.png출처: 아이오닉 메인 홈페이지


0.

아이오닉 개발을 시작한지 이제 한 달이 가까워져 간다.

주변에서 요즘 뭐하냐는 질문에 프론트랑 앱개발 한다고 하면 ‘또 안드로이드?‘ 라고 다시 한 번 질문 받는 경우가 많아서, (내가 이 글을 쓴다고 내 모든 지인들이 이걸 읽을 수 없다는 것을 알고 있지만,) 아이오닉이 무엇인가에 대한 궁금증을 간단하게 풀어볼 수 있는 포스팅을 써보고자 한다. 사실 나도 대단한 허접이라 글 쓰는게 무섭긴 하지만, 뭐 내가 돈 받고 포스팅하는 것도 아니고, 내 서버, 내 블로그에 하는건데 으훗?! 가벼운 마음으로 시작해본다.


1.

하이브리드앱? 웹앱?

일단 웹앱과 하이브리드앱의 가장 큰 차이점을 먼저 말하자면, 웹앱은 굳이 앱스토어에 출시하지 않고 적당히 주소만 잘 공개해도 모바일 환경에서 쓰기편한 UI를 제공해줄 수 있으며, 앱스토어를 경유하지 않고 사용자에게 제공되기 때문에 앱스토어 심사과정도 생략되는 장점이 있지만, 푸시기능을 사용할 수 없고, 사용자가 늘어나면 늘어날 수록 하이브리드앱에 비해 서버에 부담이 커지는 부분이 있다.

하이브리드앱은 HTML, CSS, JS 파일들을 앱에 집어넣어서 배포하는 형태라고 생각하면 절반정도 맞다. 따라서 앱이 최초 실행되는 부분과 이후 사용자와 상호작용하는 부분에 있어서 어지간한 렌더링 파일들은 이미 로컬에 있는 파일들을 가져오므로, 서버와의 네트워킹이 필요한 웹앱보다 상대적으로 빠른 반응성을 보여줄 수 있다.

여기에 더해지는 것이 바로 아파치 재단에서 만든 오픈소스 프로젝트, Cordova (이하 코르도바) 이다. 아이오닉은 이 ‘코르도바’를 기반으로 동작하며, 이 코르도바가 아이오닉에게 웹앱과 차별점을 주는, 웹 브라우저로는 불가능한 네이티브를 조작한다.


2.

이제 아이오닉을 살펴보자.

아이오닉은 하이브리드앱을 위한 대표적인 프레임워크다. 그리고 상당히 다양한 플랫폼을 하나의 코드로 관리할 수 있다고 주장한다. 그리고 써본 결과, 가능하긴 한데, iOS에서 잘 돌아가고 안드로이드에서도 정상적으로 동작은 하지만, 뭔가 살짝 이상하게 돌아가는 느낌을 받아서, 그 간극을 메꿔주기 위한 작업이 필요한 경우가 조금 있었다. 대부분 CSS 스타일링 조정으로 끝나는 일이지만 조금 아쉬운 부분.

위에서 잠깐 언급되었지만, HTML, CSS, JS로 코드짜서, 각 플랫폼의 웹뷰에서 앱을 돌리는 방식으로 구현되어있는데, 여기서 사용되는 것이 바로 AngularJS (이하 앵귤러) 이다. 서버와 통신 없이, 반응형 웹을 짜기에는 본-격 MVC/MVVM 프레임워크가 필요하다고 느낀 듯. 앵귤러 너무 느린거 아니냐는 말이 말이 종종 나오지만, 실제로 사용해본 결과 현재 G5가 출시된 지금(2016년)으로부터 3년 전에 공개된 Nexus 5 로도 같은 기종의 네이티브앱만큼 부드럽게 동작하는 것을 확인했다.

그럼, 이 앵귤러와 코르도바, 아이오닉은 어떻게 돌아가는 걸까?


3.

angular.module('myApp', ['ionic'])
.run(function($ionicPlatform, $rootScope) { 
// ...
})
// ...

앱의 시작점이라고 할 수 있는, app.js 파일은 보통 위와 같이 시작한다.

앵귤러 모듈 myApp 을 선언하고 초기화하는데, 이 모듈의 서브모듈로 ionic을 사용하는 코드를 볼 수 있다. 즉, 앵귤러를 모르고는 코딩이 불가능하다는 것. 거기에 더불어 이런저런 앵귤러 코어 모듈에 들어있지 않은 다른 모듈들도 사용하는데, 그 중에 대표적인 것이 화면 전환에 사용되는 ui-router.

그리고 다양한 $ionic* 모듈들을 사용해서 앱의 동작을 제어하게 된다. 사실 여기까지만 보면 도대체 코르도바는 어디서 쓰이는건가, 내가 과연 쓸 수는 있는건가.. 라는 생각이 드는데, 코르도바는 코드상의 window.cordova 객체에서 접근할 수 있다. 즉, 아이오닉이 적당히 코르도바를 앵귤러 스타일로 사용할 수 있도록 래퍼 역할을 해주는 것으로 보면 된다. 물론, 완벽한 대체제의 역할을 해내고 있진 않다.


더 이상 코드 얘기가 나오면 더 이상 아이오닉 소개가 아닌 아이오닉 강의 포스팅으로 변질될 것 같은 불안감에 내가 아이오닉을 선택한 이유와, 참고한 레퍼런스들과 그 레퍼런스를 선택한 이유, 그리고 아이오닉의 향후 방향에 대해서 짤막하게 정리하고 끝내는 것으로 하자.


a.

참고한 레퍼런스

처음에는 책을 구입하려고 했는데, 시중에 나와있는 아이오닉 책 중에 버전 1.2을 지원하는 책이 없었다. 그나마 있던 책들도 사무실 옆에 마침 교보문고가 있어서 확인해봤지만 그다지 끌리는 매력이 없었던 것. 그냥 공식 홈페이지 다큐먼트 정독, 또 정독했다.

그 외에 참고한 문서는, 사실 아이오닉 문서가 아니다.

위에서도 언급한 초기 장벽이 좀 있는, ui-router. 이 위키를 마구 읽자. 그것 외에도 코르도바 문서를 딱히 심도있게 파야할 이유는 아직 못느껴봤지만, 아이오닉과 다른 방향으로 코르도바와 앵귤러를 통합시키려고 하는 ngCordova 에도 꽤 재미있는 모듈이 많이 보였다.

그리고 아이오닉으로 검색하다가 나오지 않은 문제라면 보통 앵귤러 또는 코르도바로 검색하면 풀리는 경우가 많다. 현재 생긴 이슈가 과연 어떤 레이어에서 발생한 것인지 파악할 수 있는 센스가 있으면 정말 좋았을 것 같다.


b.

아이오닉을 선택한 이유

일단, 회사에서 앵귤러를 썼다. 웹으로 먼저 서비스를 시작하면서, 적당히 부트스트랩의 그리드 시스템을 이용해서 모바일에서도 ‘사용은 가능한’ 수준으로 만들면서 작업을 했다.

그 이후, 우리 서비스의 모바일 이용률이 데스크탑을 크게 상회한다는 GA 보고서를 보고, 일단 푸시가 있든 말든 모바일 앱을 만드는 것의 중요성이 대두되기 시작했다. 그리드 시스템으로 ‘readable’ 한 콘텐츠가 나온다고 하더라도, 그 콘텐츠가 모바일 기기에서의 사용에 최적화된 레이아웃인가에 대한 것과는 다른 문제라고 결론지었고, 결과적으로 다시 앱_개발.중요성++;

거기에 상당 부분 재사용한 모듈들을 이미 많이 가지고 있었다는 점도 아이오닉을 선택하게 한 큰 요인 중에 하나다. 기존의 웹서비스의 상당부분, 그리고 특히 프론트 코어부분이 앵귤러로 짜여져 있어서, 이 부분을 그대로 사용할 수 있게됐다는 점은 굉장한 메리트였다.

그 덕분에, 3월 11일 부터 본격적으로 개발을 시작했는데, 개발 착수 당일에 목업이 나오고, 3월 22일에 코어기능이 완벽히 동작하는 알파버전을 뽑아낼 수 있었다. 뭐, 일단 우리서비스가 페이지 수가 적은 편이기도 하지만, 앵귤러 중급자 (?) + 아이오닉 초보자가 뽑아낼 수 있는 아웃풋을 생각해봤을 때, 꽤 굉장한 생산성이라고 느꼈다. 가감없이, 프로토타입핑툴 또는 목업툴을 사용하느니 그냥 짜버리는게 더 빠르다고 느낄 정도였다.


c.

아이오닉의 미래

개인적인 의견이다. (제발 마음 편하게 읽어줘 라는 뜻ㅎ) 단편적인 것 부터 시작해보자면,

아이오닉의 수비범위는 꽤 넓다. 망할 것 같진 않다. 하지만 크게 성공할 것 같지도 않다. 여러가지 이유로 적당한 수작 프레임워크로 끝나지 않을까 싶은데, 일단 그 첫 번째 이유로는 이미 너무 많은 앱들이 네이티브하게 짜여져있다는 것을 꼽고 싶다. 이것들을 아이오닉으로 새로 개발하는 모험을 하기 보다는 기존의 앱을 유지보수하는 선택을 하는 회사가 많지 않을까?

또 다른 이유로는 아이오닉 2.0부터 앵귤러 2.0으로 갈아탄다는 소식이다. 그리고 이 정보가 함축하는 것은 아이오닉 2.0을 하려면 타입스크립트를 배워야 한다는 것이다. 물론, 타입스크립트가 없이도 앵귤러 2.0을 사용할 수 있다고 하지만, 상당히 더러운 코드를 접하게 된다고 하니, 앵귤러의 러닝커브 + 타입스크립트의 러닝커브 + 아이오닉/코르도바의 러닝커브 등이 합쳐진 더 높은 진입장벽을 생성하게 되는 것.

그럼 여기서, 앵귤러 2.0의 미래까지 살펴보아야 더 올바른 판단을 내릴 수 있을 것이다. 앵귤러 2.0은 과연 성공할 수 있을까?


성공을 장담할 순 없지만, 지금 앵귤러 2.0의 길이 맞다고는 느낀다. 개발에는 타입이 필요하다고, 정확히는, 컴파일 타임에 에러를 잡아낼 수 있는 것이 필요하다고 생각하니까, 타입스크립트로 갈아타는 것은 정말 올바른 일이라고 생각한다. 타입스크립트의 다양한 기능은 차치하고, 타입 체크와 더불어 하나의 앱을 만드는 프레임워크에서 자바의 annotation과 같은 decorator가 있다는건 꽤 편리하더라고, 메타프로그래밍이 지원되는 언어는 (조금 무섭긴 하지만) 생산성을 꽤 올려준다는 것을 안드로이드에서 느꼈다.

거기에 (특히 프론트엔드에서) 다양한 브라우저를 지원하는 것이 짜증나는데, 그런 마음의 짐들을 타입스크립트 컴파일러가 조금이나마 덜어주지 않을까 라는 막연한 희망도 가지고 있다. 리액트가 뜨거운 감자인 것은 맞지만, 엄청나게 많이 쓰이는 프레임워크는 또 의외로 아닌 것 같더라고. 다들 써봐야지, 배워봐야지, 하면서 정작 실무에 적용시키기에 부담을 느끼는 걸까? 의외로 사용률이 높지 않은걸 보고 놀랐다.

리액트 네이티브의 방향성도 내가 앵귤러를 선택하게 만들었는데, 리액트 네이티브는 정말 네이티브앱을 짜면서 네이티브 컴포넌트 (특히 UI) 간의 비지니스 로직을 자바스크립트로 다루겠다는 방향성으로 이해했고, 이는 곧 각각의 플랫폼에 대한 지식을 필요로 한다는 것을 뜻하니, 하나의 소스로 iOS와 안드로이드를 커버하려는 목표를 가진 아이오닉과 꽤 다르더라고.

스타트업에서 일해서 그런가, 일단 커버리지가 넓은 아이오닉에 끌리는 것이 사실이고, 타입스크립트도 넘나 멋져보이는 것. 앵귤러 2.0이 어떻게 변할지는 아직 모르겠다. 일단 베타임에도 불구하고 이를 기반으로 아이오닉이 만들어지고 있다는 게 사실 좀 놀랍긴한데, 앵귤러 2.0은 2016년 중반에 릴리즈될 것이라 하며, 그럼 이를 기반으로 하는 아이오닉은 2016년 말이나 2017년 초에 릴리즈되지 않을까? 아직 고민할 시간은 충분하다.

근데 난 재밌어보이더라고 ㅎㅎ. 노드도 책 두 권정도 돌렸는데, 안정성이 중요한 서버 프레임워크인 노드에서 타입스크립트를 쓰기 시작하는 곳도 늘어나는 추세라고 하니, 이러나 저러나 타입스크립트를 공부해서 나쁠 것은 없는 상황이 되버렸다. 거기에 끌린다고? 그럼 뭐 공부해보는거지. 내가 선발대로 출발해보고, 중간보고를 올리면 되는거 아닌가? 본부와 통신이 끊어졌습니다. 뭐, 서두에도 썼지만, 가벼운 마음이다. 새로운 레고세트를 발견한 느낌으로~

잡설이 길었네. 흠

Thanks for reading!

p.s. manually imported from previous blog.

One thought on “내가 이해한 Ionic Framework”

Leave a Reply