본문 바로가기

짧게 쓰기/칼럼

모바일 하이브리드 프레임워크를 경계하며 (총정리)

(모바일 하이브리드 프레임워크 관련 글에 관하여, 프로젝트에 캐나다 사는 동생 결혼식에 개인적인 몇가지 큰일들이 겹쳐서 이제야 글을 덧붙입니다. 두어달동안 글을 못썼습니다. 포스팅 하려는 내용을 요약하여 올리겠습니다. ^.ㅠ)


- 이전 줄거리

작년 초 모바일 하이브리드 프레임워크 엔진을 직접 개발해 보면서 하이브리드 프레임워크가 생각만큼 효과 있지는 않을것이다~ 라는 회의가 들었다. 그뒤 이게 무슨 숙명인지 국산 모바일 하이브리드 프레임워크를 쓰는 프로젝트에 참여했다. 이때 엉터리 국산 솔루션을 쓰면서 지독하게 베타테스트 한 나는 모바일 하이브리드 프레임워크의 열혈 안티팬이 되었다.


벼르다가 모바일 하이브리드 프레임워크의 단점을 전파하는 연재글을 기획했다. 모바일 하이브리드 프레임워크가 탄생하게된 시대적인 배경을 설명했다. 아이폰, 안드로이드등 여러 모바일 플랫폼을 각각 개발하면 개발비용의 증가 유지보수의 어려움으로 하나만 개발하면 여러 플랫폼에 포팅할수 있는 새로운 언어/프레임워크/플랫폼이 요구되었다.

해결방법은 C언어나 웹으로 개발하는 방법이다. 좀더 대중적인 웹이 대세이긴 한데, 웹으로 개발하면 기능,성능의 한계 때문에 액티브엑스처럼 웹의 기능을 확장하고 중력, GPS처럼 네이티브API에 핸들링 할수 있는 인터페이스 제공이 필요하다. 이것이 모바일 하이브리드 프레임워크의 주된 역할이다. 


그러나 우리나라 특이한 회사 문화와 막상 써보니 엉터리 국산 솔루션때문에 모바일 하이브리드 프레임워크 개발 환경은 고생길이었다... 그뒤 오늘은 이어서 모바일 하이브리드 프레임워크의 단점을 정리한다.



1. 개발 결과물이 좋지 않다.

모바일 하이브리드 프레임워크를 도입하려는 갑이 분명히 확인하고 넘어갈 것은 모바일 하이브리드 웹으로 개발한 결과물이 아무리 좋아도, 네이티브 개발 결과물을 따라갈수는 없다는 사실이다. 네이티브가 중형차라면 모바일 웹은 마티즈와 같다. 마티즈를 아무리 튜닝해도 중형차를 따랄수는 없는것과 마찬가지이다. 빠른 성능, 터치감, 안정성면에서 네이티브를 따라갈수 없다. 특히 내가 답답한것은 터치감이나 안정성이다. 모바일웹에서 틈틈이 디바이스의 네이티브 언어로 핸들링을 요청하는데 이 핸들링 과정이 속도가 느릴수 있고 안정적이지 않아 '뻑' 날 가능성도 존재한다.



2. 개발생산성이 안 좋다.

내가 강하게 주장하고 싶은것은 '프레임워크'의 주인은 '갑'이 아니라 '개발자'여야 한다는 것이다. 프레임워크는 개발자의 놀이터와 같다. 놀이터에 재미있고 안정적인 놀이기구가 많고 주변이 깨끗하다면 개발자는 스스로 창의적이고 버그 없는 훌륭한 소프트웨어를 창출해낸다. 그러나 놀이터가 엉망이라면 개발자는 수동적이고 버그가 우글거리는 힘든 업무 환경에 찌든 소프트웨어를 짜낸다.


가장 훌륭한 프레임워크중 하나인 JQuery를 예로 들어보면, JQuery는 document.all.account.value 의 긴문장을 $("#account").val()의 간단한 문장으로 개발할수 있게 해주었다. 이 간단한 혁신에서 웹 개발의 혁신이 일어났다. 이렇게 개발자가 프로그래밍 하기 수월한 환경을 만들면 개발자는 스스로 멋진 소프트웨어를 창출한다. 그래서 프레임워크를 도입할때는 개발자 관점의 개발 편의성, 개발 생산성을 따져야 하는 것이다. 그러나 보통 도입하려는 업체들의 갑은 개발 비용 절감 차원의 개발 생산성만 생각한다.


모바일 하이브리드 프레임워크의 생산성은 다음의 점에서 좋지 않다. 

1. 이클립스에 숟가락 얹혀가는 국산 솔루션 업체의 개발자 도구가 그렇게 좋지 않다.

이클립스에서 기본 제공하는 자바스크립트 플러그인의 한계를 넘어서는 일반 네이티브 개발자도구같은 강력한 개발자 도구가 있었으면 좋겠다. 자바스크립트 플러그인의 한계를 넘어서야 자기네 솔루션이라고 주장할수 있지 않을까. 그렇게 하지 못하면 이클립스 플러그인까지 자기네 솔루션이라고 주장하지 않아야 한다.


2. 자바스크립트 개발환경이 아직 좋지 않다.

자바스크립트는 한군대에서 에러가 나면 어디서 에러가 나는지 찾기가 힘들기 때문에 디버깅이 아직 힘들다. 처음 모바일 하이브리드 프레임워크로 개발할때 어디가 문제 있어서 에러가 나는지 찾는데 엄청나게 고생했다. 그러나 사실 이런 디버깅적인 측면은 앞으로 개선되어 나가긴 할것이고 좋은 디버깅 도구를 내가 못찾았을 수도 있다.


3. goto문 같은 비동기/콜백 방식의 개발

이말이 무슨말이냐면 순차적으로 편하게 개발할것도 네이티브 연동할때는 비동기/콜백방식으로 개발해야 한다는 것이다. 웹<->네이티브 연동할때 비동기로 호출하여 콜백으로 받아야 한다. 이렇게 해야하는 기술적인 이유는 아이폰 웹킷이 동기로 호출할수 있는 웹킷 API를 막았기 때문이다. (이 사항은 나중에 따로 설명할수 있음) 


네트워크 통신 같은 경우 비동기 방식으로 개발해야 성능 향상을 볼수 있다. 그러나 굳이 비동기로 개발하지 않아도 되는 것은 동기로 개발해야 개발 생선성, 유지보수 편의성이 높다. 예를 들어 중력 API의 x, y, z 값을 가져오는 코딩을 해본다면.


> 동기식

...

var accel_x = Widget.Device.DeviceStateInfo.xAxis;

var accel_y = Widget.Device.DeviceStateInfo.yAxis;

var accel_z = Widget.Device.DeviceStateInfo.zAxis;

...


으로 코딩하면 일반적으로 코딩하듯이 편리하고 깔끔하게 개발할수 있다.

그러나..


> 비동기식

...

var aceel_x;

var accel_y;

var accel_z;

Widget.Device.DeviceStateInfo.xAxis(function(resultString1) {

aceel_x = resultString1;

Widget.Device.DeviceStateInfo.xAxis(function(resultString2) {

aceel_y = resultString2;

Widget.Device.DeviceStateInfo.xAxis(function(resultString3) {

aceel_z = resultString2;

}

});

});

...

식으로 API 호출후 콜백 받을때까지 기다렸다가 변수에 담는 처리등을 해야 하는데 위는 그래도 그나마 간단하게 표현이 된것이다. 보통 코딩을 하다보면 더욱 더 복잡하게 중첩 코딩이 되어 마치 goto 문처럼 코딩이 뒤죽박죽 가독성이 엄청나게 떨어지는 경우가 많아진다.


가독성문제 말고도 비동기식으로 개발하면, 개발자가 비동기 처리를 잘 못하는 경우등의 이유로, 시간차 문제가 생긴다. 예를 들면 꼭 중력의 x값을 구하고 그다음 y 값을 구하고 다음 z값을 구해야 하는데 비동기로 x,y,z 값을 동시에 구하는 경우 개발자가 의도하지 않는 시간차 갭이 생겨 예를들어 z값의 결과가 가장 먼저 리턴이 됐다.. 이런 경우 엉뚱한 버그가 생기는 것이다. 이런 경우가 실제 프로젝트에서 상당히 많이 발생했다. 


비동기/콜백 개발에서 내가 말하고 싶은 것은 네트웍 통신등의 성능 향상을 이유로 비동기/콜백으로 개발하는것은 이해가 되는데, 동기로 개발해야 버그 없이 안정적으로 개발하는 것들도 비동기로 개발하면 가독성이 떨어지고 그래서 버그가 증가되는 것이다. 


또한 중요한 결함 한가지는 비동기/콜백을 쓰면 중요 기능을 함수화 하기 어려워 코드가 중복되기도 한다. 함수화 할 수 없다는 것은 같은 코드가 도처에 중복될 수 있다는 뜻이다.


만약 집에서 학교까지 지름길이 있는데 이 길이 막혀서 15분 더 돌아서 가야한다면 얼마나 불편한 일인가. 성능향상 때문에 비동기/콜백을 쓰는것이 아니고 동기식으로 코딩을 할수가 없어서 어쩔수 없이 비동기/콜백을 쓴다는 것은, 마치 집에서 학교까지 가는 지름길이 막히고 15분 돌아서 학교에 도착하는 불편함과 같다. 그리고 그 길은 버그 발생 확률이 높은 곳 처럼 교통 사고도 높은 길일것이다. 

 


3. 구글, 애플 기술 보증이 안된다.

구글, 애플이 OS 업그레이드를 할때마다 자기네 플랫폼은 OS업그레이드 해도 문제가 없도록 보증을 해준다. 그러나 모바일 하이브리드 프레임워크는 알아서 대처를 해야 한다. 만약 솔루션 업체에서 업그레이드 대응을 제때 하지 못하면 기존 상용화된 어플에 장애가 발생한다.


최근 예로 폰갭에서 변수를 영속적으로 저장하는 localStorage라는 저장소 API가 있었는데 ios5로 업그레이드 하면서 이 localStorage가 더이상 제대로 작동 안하는 문제가 발생했다. 그래서 어플에 장애가 터져 대응책을 찾느라고 난리가 난적이 있다. 


액티브엑스를 쓰다가 예를들어 윈도우8부터 지원을 안하면 난리가 나는 경우와 비슷하다. 구글, 애플등에서 보증되지 않는 프레임워크를 쓰는 것은 액티브엑스처럼 표준화되지 않은 프레임워크에 종속되어 이 프레임워크가 OS업그레이드를 제때 지원하지 않을 경우 낙동강 오리알 신세가 되는 경우와 같다.



4. 퍼블리셔 의존 문제

모바일 웹으로 개발할 경우 개발자는 자바스크립트로 개발하고 퍼블리셔가 표준 HTML로 코딩한다. 퍼블리셔가 따로 있어야 한다. 


문제는 퍼블리셔 의존도가 꽤 높고 이 의존도가 높아짐에 따른 위험이 존재한다. 퍼블리셔는 훌륭한 퍼블리셔도 있지만 수준 낮은 퍼블리셔도 있다. 이 퍼블리셔에 따라 프로젝트가 좌우되기 때문에 퍼블리셔의 수준에 따라 프로젝트가 잘 진행될수도 흔들릴수도 있다.


경험해 보니 퍼블리셔 의존도가 생각보다 컸다. 내가 프로젝트를 했을때의 퍼블리셔는 굉장히 훌륭한 퍼블리셔 였다. 덕분에 프로젝트를 잘 진행할수 있었다. 그러나 이 퍼블리셔가 철수한 후 중요한 문제가 터질때마다 제때 처리가 안되 발을 동동 굴렀던 문제가 있다. 


아이폰 개발환경 같은 경우 마치 자동화된 퍼블리셔를 쓰는것과 같다. UI빌더등으로 편하게 작업할 수 있다. 갑의 관점에서 퍼블리셔가 1의 효율로 작업한다면 개발자는 네이티브로 개발할 경우 자신의 일을 하면서도 플러스 알파로

0.5~0.7의 효율로 UI작업을 진행할 수 있다. (아이폰의 경우)


모바일 웹으로 개발할때 개발자 입장에서는 퍼블리셔가 일을 덜어줘서 당장은 편하지만 퍼블리셔의 수준이 낮거나 퍼블리셔가 계약 만료등의 이유로 떠날 경우 퍼블리셔 의존도에 따른 문제에 부딪칠 것이다.



5. (내가 아는) 국산 솔루션이 엉망이다.

사실 내가 이런 글을 쓴것도 국산 솔루션에 워낙 크게 데어서 쓴것이다. 모바일 하이브리드 컨셉에 맞게 제대로

개발되었으면 나름 그 장점에 고개를 끄덕이며 썼을 것이다. 그런데 내가 전편의 글에 언급한것처럼 영업력 90% 기술력 10% 의 껍데기 솔루션을 갖고 프로젝트를 진행하면서 솔루션을 완성시키고 다른 개발자는 베타테스터로 만드는걸 보고 열렬한 안티 팬이 되었고 이 글을 쓰게된 계기가 되었다.



- 대안

그럼에도 모바일 하이브리드 프레임워크를 써야 한다면 어떤 프로젝트에 어떤 제품을 써야 하는가 고민한적이 있다. 일단 고성능을 요구하고, 네이티브 개발자 자원이 충분한 경우 네이티브로 개발하는 것이 좋다. 디바이스 연동이 필요 없는 순수 조회성 어플 같은 경우, 순수 모바일 웹으로 개발한다. 이 두가지 경우는 행복한 경우이다.


그러나 만약 위의 두가지 사이에 끼어 모바일 하이브리드 프레임워크가 꼭 필요한 경우, 그나마 최대한 많이 써서 범용적이고 최대한 표준화된 하이브리드 프레임워크를 써야 한다. 전세계적으로 많이 써서 거의 표준화된 제품을 써야 개발자도 구하기 쉽고 개발자들도 수월하게 플젝에 참여할수 있다. 전세계적으로 많이 쓰기 대문에 레퍼런스도 많고, 안정성도 보장된다. 표준화의 관점에서 생각해야 한다. 표준화되지 않은 많이 쓰이지 않는 제품을 쓸 경우 개발자도 구하기 힘들고 레퍼런스가 부족해 개발하다가 안되는 것은 지원을 받아야 하는데 그 지원이 제대로 될수 있을까 생각해봐야 한다.


전세계적으로 많이 쓰이는 제품은 일단 오픈소스일것이다. 상용이 많이 쓰이긴 힘들다. 소스를 공개하고 여러명이 협업하여 소스를 개선할수 있는 오픈소스화 했다는 것이 기술력을 이미 인정 받는 것이다.


반대의 국산+상용 솔루션 같은 경우 상용에다가 믿음직하게 개발되었다고 보기 힘들기 때문에 많이 전파되어 표준화 되기 힘들다.


나는 전자 정부 모바일 프레임워크에서 하이브리드 프레임워크도 지원하면 혹시 쓸만하지 않을까 기대하고 있다.


단순하게 생각하면 모바일 하이브리드 프레임워크가 원소스 멀티유저 개념으로 몹시 매력적인 장점을 가지고 있고, 나도 이렇게 되기만 하면 좋은데 실제로는 이렇게 되지 않고 온갖 문제에 시달렸던 경험을 했다.


순수 웹개발자만으로 하이브리드 프로젝트 진행하기 힘들고 네이티브 지식도 필요한 경우가 많다. 왜냐면, 모바일 하이브리드 라는 개념이 웹+네이티브 이기 때문이다. 


그래서 '원소스 멀티유저'+'웹개발자만 필요'의 매력에 혹했다가는 모바일 프로젝트가 산으로 가고 훅 가는 경우가 분명히 생길 수 있다.


* 이전글

0.탐욕

1.시대적인 배경

2.국산의 문제