제 작년부터 겨울이 되면 지대로~ 프로젝트를 한다. 지대로~ 프로젝트를 한다는것은 우리나라만이 할수있는 고강도 일정 압축 프로젝트를 진행한다는 말과 같다. 고강도 일정 압축 프로젝트 더하기 겨울 추위가 겹쳐 면역력은 떨어지고 스트레스도 있고...그리고 식탐 때문에 그런지 새해 첫날부터 장염에 걸렸다.

그래도 모처럼 블로그가 생각났다. 마음만은 매일 쓰고 싶다. 작심삼일일지라도 오늘은 내맘대로 포스팅 하자.

올해 주목할만한 IT 이슈들이 눈에 보였다. 

- 박근혜 당선 후 IT 정책의 변화

보통 대통령 당선 후 공공 프로젝트가 여러건 발주된다고 한다. 공무원 IT 현업이 저무는 대통령에게 이런 좋은 프로젝트 있습니다~ 라고 광고하진 않기 때문이다. 박근혜가 대통령이 되면서 공무원 IT 현업들은 미뤄뒀던 여러 프로젝트를 발주할 것이다. 

이런 기본적인 대통령 인수인계 시점과는 별도로 박근혜가 IT 정책을 어떻게 추진할지 궁금하다.

박근혜는 전자공학을 전공했다. 당선 공약으로 IT 정책 강화를 내세웠다고 한다. 무엇보다 전자공학을 전공했다는 점은 박근혜가 IT를 먼나라 얘기 하듯 하는것이 아닌, 박근혜가 가까이 경험한 일을 다루는 것으로 매우 중요한 사실이다.  

미래 창조 과학부를 신설한다고 하는데 적어도 이명박 보다는 나아질것 같다. 지켜보자.

- 애플의 고군분투

잡스가 죽고 그의 영향력은 희미해져간다. 올해정도면 애플이 잡스 없이 잘하는지 어려운지 좀더 확실히 가늠하는 해가 될 것 같다.

애플의 주가가 폭락하고 있다. 주변에서 특히 우리나라에서 애플은 이제 죽었다~는 기사를 올린다.

그러나 나는 아이폰5이나 아이패드미니등의 제품을 보고 향후 애플의 정책등을 짐작해보면 잡스 전성기 때처럼 특출나게 잘하지는 않지만 그래도 잘하고 있다.

문제는 아이폰이나 아이패드처럼 새로운 시장을 창출하고 새로운 제품을 창조하는 창의적인 면이 예전과 같지 않고, 그런 모습들이 잡스가 죽은 후 애플의 허점 같을 것이므로 주변에서 맹공격을 한다.

나는 나 또한 창의적이지 못해서 그런지 스마트폰 나오고 테블릿 나온 그 다음.. 더이상 어떤 또 창의적인 제품이 나올지 상상이 되지 않는다 이미 사용자들은 스마트폰, 테블릿, 피시를 통해 최고의 디지털 라이프를 즐긴다. 과거 내가 상상했던 디지털 제품들은 지금 모두 구현이 되었다.

미래 영화에서 보는 최첨단 제품들이 저 3 제품군을 통해 구현되고 있다. 이제는 이미 나온 제품군의 안정화 고성능을 지향해야 할때이다.

애플은 이미 나온 제품그룹들의 안정화 고성능을 지향하는 면에서 잘하고 있다.  아이폰5.. 하도 욕을 해서 자세히 살펴보니 이정도는 아닌데... 꽤 괜찮았다. 아이패드 미니는 레티나만 장착되면 우리나라에서 킬러 테블릿이 될것 같다.

그래도 주변에서 하도 위기~라 말하고 실제로도 주가가 떨어지고 있다. 애플이 어떻게 고군분투 하는지 지켜볼만 하다.

- 아이폰과 안드로이드의 점유율 차이 그리고 윈도우8

우리나라는 안드로이드가 대세고 해외는 아이폰과 안드로이드가 비슷하기도 하고 미국은 아이폰이 앞선다.

위의 애플의 고군분투 이슈와 같이 연결되어 올해 스마트폰 점유율 추이가 어떻게 그려질지 궁금하다. 올해 이어서 그려지는 점유율은 앞으로도 계속 이어질 것이다.

우리나라는 안드로이드 점유율은 계속 올라가고 아이폰은 계속 내려갈것인가? 아이폰5가 얼마나 선전해줄것인가에 달렸다. 

아이패드 미니가 안드로이드 테블릿과 겔럭시노트2의 점유율로부터 방어하는 역할을 할까?

윈도우8은 성공할것인가? 피시는 고군분투 하는것 같은데 윈도우8폰은 아직 들어보지 못했다. 

전세계의 사용자들은 아이폰 안드로이드 두 플랫폼을 알기에도 버겁기 때문에 또 하나의 플랫폼이 들어설 자리는 아예 없다고 본다. 차라리 윈도우폰8은 스마트폰이 보급되지 않은 제3세계를 노리는것이 어떨까.  

- HTML5의 반격

작년 나는 눈에 불을 키고 (국산) 하이브리드 프레임워크 공격글을 썼다. 

페이스북 주커버그도 말했듯 HTML5가 네이티브를 못 쫓아가고 개발자들도 그 성능과 생산성에 의문을 표시했다. 그래도 HTML5는 나름대로 발전할것이고 언젠가 내가 이만큼 성장했어~ 라고 자랑할지 모른다.

올해 HTML5와 비슷한 개념들인 하이브리드 프레임워크들도 발전할수 있을까.  

만약 그렇게 된다면 네이티브 주병론자인 나도 기꺼이 HTML5를 써보겠다.

- 모바일 게임시장의 진화

요즘 나는 더이상 게임을 PC로 하지 않는다. 스마트폰이나 아이패드 테블릿으로 게임한다.

스마트폰이나 테블릿은 언제든 들고다니면서 게임을 할수있다는 장점이 있다.

이제는 PC와 같은 고성능의 멋진 게임성을 보여준다.

사용자는 피시 게임처럼 불법이나 비싼돈을 들이지 않고 피시 보다는 훨씬 적은 비용을 들일수 있기 때문에 게임을 사게 된다. (안드로이드 해킹 유저 제외)

이 사실은 게임 개발사들이 모바일 게임에 더 투자하는 동기부여가 될 것이다.

이 외에도 여러가지 IT 이슈들이 있지만 넓게 깊게 쓰지는 못하고 생각나는 대로 이 정도 써본다. 쓰고보니 IT에 관심이 있는 사람이라면 다 알만한 내용이다. 

요즘 블로그를 보면 정말 내공이 뛰어난 분들이 몇분 눈에 뛴다. 오늘 내 글처럼 '얕은 글' 이 아닌 이 분들의 노력이 깃든 깊고 넓은 멋진 글들도 추천한다.

덧) 새해 복 많이 받으세요~ ^ ^ 지금은 블로그 지인 연락하진 않지만 심샛별님 블루팡오님 최근 마지막으로 연락 주신 하루님등 잘지내고 계시는지요~ 문득 생각납니다. ~ 모두 건강하세요~

1. 아기가 고사리손으로 박수를 친다. 박수를 치는 모습이 신기했다. 귀엽다. 형수님은 분홍빛 화려한 한복을 입고 윤기나는 화장을 하셨다. 예쁜아기의 엄마 다웠다. 과장님은 피부가 다소 푸석한 느낌은 들었지만 멋진 수트를 입어 세련된 느낌이 들었다. 돌잔치 음식은 맛있다.

돌잔치 이벤트가 시작된다. 돌잡이 이벤트 순서가 왔다. 아기가 무엇을 집을까 참석객들의 이목이 집중된다. 사회자의 진행으로 돌잡이 그릇에는 참석객들로부터 모은 돈이 가득찼다.

사회자가 엄마 아빠에게 무엇을 뽑을것이냐고 물어봤다. 아빠는 돈, 엄마도 돈이라고 말했다. 아빠 엄마는 웃으면서 말했지만 뭔가 간절함도 느껴지는것 같다.

드디어 돌잡이가 시작됐다. 아기가 다른걸 집으려고 하자 엄마가 못집게 유도한다. 그 모습에 참석객들이 웃는다. 아기는 결국 돈을 집는다. 이렇게 돌잔치는 웃음과 맛있는 음식과 아기의 밝은 미래에 대한 기원이 가득했다.

문득 아기 아빠의 현재 상황이 떠올랐다. 꾸며입었음에도 어딘가 힘들어 보였던 아기 아빠는 계속 되는 매일밤 주말밤도 새벽에 들어가 지칠대로 지쳐 있었다. 그 모습을 지켜보는 엄마도 같이 힘들어 했을것이다. 엄마가 돌잔치를 다 준비했다고 한다. 행복한 돌잔치 뒤에는 힘든 업무 환경에 녹초가 된 아빠 엄마가 버티고 있었다. 아마도 그래서 아기가 돈을 집길 바랬을 것이라는 지레짐작을 한다.

아빠가 그렇게 진 빠지도록 고생한것은 갑의 무자비한 일정 압박이 컸다. 그러나 아빠는 유독 이런말을 하면서 푸념하곤 했다.

"이 프레임워크 정말 싫어요." 이 프레임워크는 어느 업체가 개발한 모바일 하이브리드 프레임워크다.

아빠는 갑도 갑이지만 문제의 프레임워크에 대해 푸념하곤 했다.

아빠가 프레임워크에 대해 푸념하는 이유는 무엇일까.

사냥을 하는데 총으로 사냥하는게 아니라 새총으로 사냥하는 느낌.

총들고 적과 싸워야 하는데 돌맹이 들고 육탄 돌격하는 느낌.

멋지게 차려입고 아가씨랑 소개팅 해야 하는데, 싸구려 면티 입고 나갈때의 느낌.

설악산을 등반해야 하는데 쓰레빠 신고 올라가는 느낌.

제주도에 가야 하는데 비행기가 아니라 땟목 타고 가야하는 좌절감.

사람의 역량이 아무리 뛰어나도 도구가 너무 받쳐주지 않으면 그 사람의 역량은 발휘되지 못한다.

아빠가 푸념하는 이유도 위와 같다. 프로그램 짜다가 문제가 발생하면 내가 직접 해결하고 싶어도 엉터리 하이브리드 프레임워크 때문에 해결하지 못하고 하이브리드 프레임워크에서 해결할때까지 기다리거나 우회 경로를 뚫어야 한다.

만약 아빠의 주력인 안드로이드로 개발했다면 문제가 생겼을때 빠르게 대처할수 있을것이다.

안드로이드 자체가 파편화된 모바일 개발의 생산성을 높이기 위해 연합으로 출범한 표준화된 프레임워크인데 이 표준중의 하나를 엉터리 국산 돈독 오른 프레임워크가 물을 흐리고 있으니 아빠는 이중 삼중으로 힘들다.

2. 우리나라 모바일 생태계가 과거 웹생태계 처럼 액티브엑스 같은 암적인 존재의 파편화에 오염되지 않기 위해 제가 썼던 모바일 하이브리드 공격(!) 글들을 모아 '국산 하이브리드 퇴출' 이라는 카테고리를 개설했습니다. 지금 국산 모바일 하이브리드 프레임워크는 액티브엑스와 똑같이 안좋은 영향을 끼치고 있습니다. 암과 같습니다. 차라리 액티브엑스는 MS라는 내노라하는 플랫폼 회사가 내놓은 것이라 일관성과 통일성이라도 있었지만 모바일 하이브리드는 국산 작은 업체가 우후죽순 만들어서 더 위험합니다. 하나의 암만 치료하는게 아니라 다른 약으로 치료 해야하는 유전자 변이 암이 우후죽순 생긴것과 같습니다. 크게 경각심을 가져야 합니다.

제가 무작정 하이브리드 프레임워크를 안좋게 보는 것은 아니고 영업력 90% 기술력 10%로 사기치는 국산 하이브리드 솔루션들을 대상으로 하고 있습니다. HTML5/Javascript 는 전에 제글에도 썼듯이 사내 업무용등의 고객을 위한 화려한 작업이 필요없는 경우 유익하게 쓰고, 하이브리드도 발달되고 표준화된 스프링같은 프레임워크가 활성화되면 좋을것이라고 생각하고 있습니다.

저는 퇴출되야할 국산 하이브리드 솔루션 두개를 알고 있습니다. 오픈은 못하지만 댓글로 심하게 당했던 솔루션 댓글 남겨주시면 어떻게든 도움이 될것 같습니다. 

제 글에 반대하시는 분의 댓글/포스팅도 환영합니다. 제가 바라는 것은 이 글들이 이슈화되어 널리 퍼져 하이브리드의 달콤한 말들을 경계하는데 기여하길 바라기 때문입니다.

3. 참고하세요.

앱 개발 플랫폼 경쟁, iOS 뜨고 HTML5 진다

http://www.itworld.co.kr/news/78057

후드티 벗은 저커버그 "페이스북 최대 실수는..."

http://media.daum.net/digital/newsview?newsid=20120912123206494

하이브리드 앱 때문에 멘붕 온 이야기. 

http://www.outofplan.co.kr/?p=16

hybrid app을 하다 보니 겸손해지네요

http://www.androidpub.com/2043590

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

http://mckdh.net/500 

살면서 인생은 새옹지마라는 고사성어가 떠오르며 무릎을 친적이 종종 있었습니다. 하나 예로 들면 힘들고 고되게 어떤 어플을 하나 개발했더니 다음에 두고두고 써먹을 레퍼런스가 되었던 경험을 했습니다. 한번 심하게 고생했지만 결국 나에게 도움이 되었던 경우였습니다.

작년 저희는 모바일 하이브리드 프레임워크를 써서 어플을 개발했던 경험이 있습니다. 그때 우리는 한마디로 국산 하이브리드 프레임워크에 대해 거품을 물게 되었습니다. 삽도 없이 손바닥으로 흙을 파는 듯 극심한 고생을 했던것이죠.

다시는 그런 최악의 프로젝트를 하고 싶지 않았습니다. 몇달 전 저희는 회사 차원을 넘어 소속 그룹사의 전체 표준 모바일 프레임워크 선정 관련 타당성 분석 작업을 진행했습니다.

그런데 이때 작년 거품 물며 했던 모바일 웹 프로젝트가 이번 모바일 프레임워크 선정 작업에 큰 도움이 되었습니다. 관리자 입장이라면 원 소스 멀티 디바이스라는 관리상의 어마어마한 매력에 귀가 솔깃 할수 밖에 없어 제안서만 보고 무조건 모바일 프레임워크를 도입하자고 얘기 했을 것입니다.

그러나 우리가 거품물며 고생 했던 경험으로 무작정 도입은 안된다고 얘기도 하면서 그동안 수많은 토론을 겪었습니다. 만약 우리가 거품물며 생고생을 하지 않았더라면 이런 중대한 선택에 모바일 하이브리드 프레임워크 도입하자는 한쪽의 의견이 우세하여 잘못된 선택을 할 수 있습니다.

그러나 우리가 생고생 한 덕분에 냉철하고 바람직한 선택을 하는데 큰 경험이 되고 있습니다.

저도 지금 무작정 하이브리드를 반대하는것이 아니라, 

- 회사 입장에서 메인이 되는 중요하고 성능이 좋아야 하는 대 고객 어플은 네이티브,

- 직원 내부용, 조회성 어플등은 하이브리드 또는 모바일 웹

가 좋은것 같습니다.

그때 당시 모바일 프레임워크 도입과 관련하여 정말이지 회사의 핵심 두뇌들이 모여 엄청난 고민을

하고 있는 것을 보며 좋은 결과가 나올것이라 기대했습니다.

만약 그 생고생 거품 프로젝트로 백신을 맞지 않았다면 앞으로 거대한 재앙을 만났을 것입니다.

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

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

- 이전 줄거리

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

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

해결방법은 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.국산의 문제

2006년도 모 프로젝트에는 BPMS란 신개념의 국산 프레임워크가 쓰였다. 이 프레임워크는 비즈니스 컴포넌트를 만들고 이 컴포넌트들의 프로세스를 연결하는데, 한번 만들어지는 비즈니스 컴포넌트는 재사용할 수 있는 신개념의 프레임워크 였다.

그러나 적어도 내가 사용한 BPMS는 현장 경험이 풍부한 설계자가 아닌, 책상머리에만 앉아 본 그 누군가가 만들지 않았나 싶을정도로 개발 생산성이 형편 없었다.

하나의 업무 개발하는데 관련 편집 파일이 5개 이상이나 되었다. 비즈니스 컴포넌트 그림파일, JSP파일, 자바 파일, XML파일1,2,3..., 기타 리소스 파일 등 관련 파일을 여러개 오픈해야 하는데 창을 정신없이 왔다갔다하면 그 창을 쫓아 가는 내 두뇌가 추적을 포기하고 비명을 지르는것 같았다. 화장실 가서 토하고 싶을 정도였다. 

이렇게 힘들게 만들어진 컴포넌트는 재사용 하기도 쉽지 않았다. 이론적으로는 생각하지 못했던 여러가지 실무적인 문제가 재사용을 어렵게 했다.  다시 생각하기 싫은 프레임워크 사용 경험이었다.

2007년도 잘나가는 어느 국산 UI 프레임워크 컨퍼런스에 참석했다. 그 업체 사람들은 끊임없이 자신들의 제품이 '명품 제품' 이라며 자랑했다. 이 자랑만 한참 듣다가 집에 간것 같다. 실제로 이 제품을 썼을때 나는 일반 웹에 비하여 뚜렷한 장점이나 개발생산성이 와닿지 않았다. 외국 제품에 비해 개발 툴이 헐거워진 거미줄처럼 많이 엉성했다.

위의 두가지 경험은 우리나라에서 만든 프레임워크를 사용한 후기이다. 나는 우리나라에서 개발한 솔루션/프레임워크에 대하여 극단적인 불신을 가지고 있다. 이 불신은 보통 우리나라 솔루션/프레임워크 개발사들이 다음의 모습을 가지고 있기 때문이다.

- 영업력 90%, 기술력 10%의 뻥튀기 제품

전문 연구 개발 인력이 심도있게 개발을 진행하기 전에 일단 무조건적으로 이때까지 개발을 끝내라고 하고는, 영업은 이미 다 만들어진 제품이라고 제안서를 꾸미고 갑 업체에게 찔러본다. 결국 한 업체가 걸리면 그때부터 연구 개발인력도 SI에 같이 투입하여 같이 개발한다. 솔루션/프레임워크 완제품을 프로젝트에 납품하는 것이 아니라 SI 뛰면서 같이 솔루션/프레임워크 프로젝트도 같이 시작 하는 것이다. 

이걸 사용하는 개발자는 죽어라고 베타테스터만 무료로 해준다.

- 오픈소스 짜깁기

제안서에 화려한 수식어로 홍보를 한 대부분의 내용은 결국 오픈소스에서 제공하는 기능을 자기들의 독자적인 기술력으로 만든것 처럼 뻥튀기 포장 하는 경우가 대부분이다. 멋진 차트를 자체 제공한다고 보면 결국 제이쿼리 차트이고, 하이브리드 연동 핵심 엔진도 결국 폰갭이고, 옛날 써봤던 BPMS 툴도 오픈소스 툴을 이용했다.

- 외국 제품의 압도적인 기술력을 따라잡기 힘들다.

위의 두가지 내용에 대하여 크게 양보를 하여, 전문 기술 인력이 전문적으로 연구 개발에만 몰입하고 자체적으로 엔진을 개발한다고 하더라도 만들어진 제품이 구글, 애플, MS의 쟁쟁한 회사의 솔루션보다 낫기는 힘들다. 

구글, 애플, MS의 프레임워크는 엄청난 천재들이 엄청난 비용을 지원받아 만든 최고의 작품들이다. 예를들어 애플의 코코아 프레임워크는 그 객체지향적인 견고함이 아름답다고 말할 정도로 튼튼하고, xcode의 개발 편의성과 위에 언급한 국산 UI 프레임워크와 비교하면 수준차가 5년 이상이나 된다.

외국 제품이 압도적으로 뛰어나다고 해서 국산 개발을 하지 않아야 한다는 것은 BMW가 뛰어나다고 해서 국산 차를 만들지 않아야 한다는 것과 비슷하기 때문에 문제가 있는 논리지만, 내가 하고 싶은 말은 국산 개발 하는 업체들이 외국 제품을 능가할 정도는 아니더라도 기본적인 상도의는 지켰으면 하는 것이다.

외국 오픈소스 짜깁기 하면서 자기네 기술력이라고 우기는 거나, 다 만들지도 않는 유령 제품으로 프로젝트 따서 프로젝트 뛰면서 솔루션화 시키고 그걸 사용하는 개발자는 무료 베타테스터로 만드는 '양아치' 짓은 하지 않았으면 하는 바람이다. 

그리고 이 업체들이 예를들어 애플의 코코아 프레임워크 처럼 프레임워크에 대해 깊이있게 생각 하지는 않기 때문에 당장 티는 안나지만 객체지향적으로 잘 짜여졌을 가능성은 거의 없다. 객체지향적으로 만들어져야 개발자들이 유연하고 확장성 높은 개발을 할 수 있도록 유도할수 있고, 객체지향적으로 잘 설계되었다는 것은 프레임워크의 내공을 판단하는 중요한 기준이 된다.

그러나 국산 업체들은 이런 깊이있는 내공이 담긴 프레임워크를 만들다기 보다는 일종의 라이브러리/API

제공 형식의 성격이 강하다. 

한편으로는 표준화에 대한 고민도 필요한데, 이 업체들이 급하게 개발하다보면 표준화에 신경을 쓰기 어렵다. 그래서 저절로 액티브엑스 처럼 파편화가 된다. 여기에 '갑'의 극성 요구는 액티브엑스 같은 암의 '촉매제' 와 '영양분'이 된다. 

모바일 하이브리드 프레임워크가 제2의 액티브엑스가 될수 있는 이유는, 보편적으로 국산 솔루션/프레임워크 업체들이.. 사기꾼 성격이 강하기 때문이다. 깊이있는 연구와 고민끝에 개발하기 보다는 '트랜드'에 발 맞춰 돈 벌기 위해 부실공사로 개발하는 경향이 강하기 때문이고, 이 부실공사 결과물은 모바일 개발자의 개발 생산성을 위협하고, 개발 플랫폼의 파편화를 만들기 때문이다. 

* 연재 계획

0.탐욕

1.시대적인 배경

2.국산의 문제

3.자바스크립트 개발 환경

4.goto문의 악몽 비동기 프로그래밍

5.퍼블리셔 의존 문제

6.개발자의 질적저하

7.애플/구글사의 보증 제외 문제

* 영업력 90% 기술력 10%의 설익은 모바일 하이브리드 프레임워크를 쓰는 바람에 고생한 개발자들의 제보를 받습니다. 또는 반대 댓글도 환영합니다. 논쟁을 환영합니다. 

모바일 하이브리드 프레임워크는 제2의 액티브엑스라는 제목은 두가지 뜻을 담고 있다. 하나는 모바일 하이브리드 프레임워크가 문장 그대로 웹에서 액티브엑스가 하는 역할을 고스란히 대신한다는 뜻이다. 하나는 액티브엑스가 우리나라 IT의 발전을 막았듯이 모바일 하이브리드 프레임워크도 우리나라 모바일 IT의 발전도 막을 수 있다는 뜻이다.

2009년말 아이폰의 전격 출시는 마치 2차세계대전 독일의 전격전을 떠올리게 한다. 독일의 전격전으로 프랑스를 비롯한 연합군은 초토화 되고 독일의 손안으로 들어간다. 연합군은 당황스러웠고 어떻게 대항 할지 난감했다. 그러나 곧 장병들을 모집했고 병기기술 개발을 앞당겨 시작했다. 처음에는 독일에게 일방적으로 밀렸지만 서서히 정신을 차리고 독일에 대항하게 된다. 너무도 강력한 독일이었지만 연합군도 독일군의 수준에 맞게 병력을 운용할수 있게 되었고 몇년 뒤 전쟁의 향방을 연합군쪽으로 가져왔다. 

2009년말 아이폰의 전격전으로 삼성과 SK를 비롯한 우리나라 독과점 기업은 초토화 되었다. 우리나라 독과점 기업은 당황스러웠고 어떻게 할지 난감해 했다. 곧 안드로이드 개발자를 급조했고 안드로이드 폰 개발을 앞당겨 시작했다. 

금융권을 비롯한 우리나라 일반 기업도 당황스럽기는 마찬가지였다. 다른 경쟁사가 아이폰, 안드로이드 어플을 개발하니 그들도 얼떨결에 억대 비용 쏟아 부어 어플을 개발하기 시작했다. 그러나 투자 비용대비 사용자도 적을것 같은데 그들은 왜 비싼돈을 들여 이런 어플을 개발해야 하는지 무척 난감해 했다. 

일단 다른 경쟁사 처럼 부랴부랴 기본적인 어플을 만들어놓고 그들은 깊게 생각했다. 어플을 저렴한 값으로 개발할수는 없는가. 하나의 언어로만 개발하여 아이폰, 안드로이드에 동시에 포팅할수 없을까~ 라는 고민을 시작 했다.

이런 요구사항은 전세계적인 이슈였고, 이 요구사항을 해결하는 방법은 C로 개발하거나 웹으로 개발하거나

둘중에 하나였다. C로 개발하는 것은 난이도가 높다. 그럼 웹으로 개발하겠다.

웹으로 개발할 경우의 문제는 네이티브 어플(순수 아이폰/안드로이드로 개발한 어플)과 웹 어플의 수준차가 많이 난다는 것이다. 웹으로 개발한 어플의 수준은 네이티브에 비교할때 많이 떨어진다.

모바일 웹 관련 프레임워크는 네이티브 어플과 웹 어플의 수준차를 줄이기 위해 여러 회사, 여러 오픈소스에서 다양한 솔루션을 출시하게 되었다. 

모바일 웹 관련 프레임워크는 한마디로 네이티브 어플과의 수준차를 줄이기 위한 솔루션이다.

모바일 웹 관련 프레임워크는 최대한 네이티브 어플과 비슷하게 보이기 위한 솔루션이다. 

모바일 웹과 네이티브 어플간의 수준차는 3가지 영역으로 나눌 수있다.

- UI

- 개발자 도구

- 모바일 디바이스의 자원 활용등

UI는 네이티브 어플과 비슷한 모양과 애니메이션을 보여주는 오픈소스/솔루션들이 나와 있다. JQuery Mobile, 센차터치, HTML5등이 존재한다. 기타 우리나라에서 만든 솔루션들도 있다.

개발자 도구는 모바일 하이브리드 프레임워크 솔루션에서 개발자 IDE, 애뮬레이터 등을 별도 지원하여 아이폰 xcode, 안드로이드 개발환경의 수준차를 극복하려는 노력이다. 그러나 막상 겪어보면 일반 자바스크립트 개발환경에서 개발하면 되고 애뮬레이터는 아이폰 시뮬레이터 안드로이드 애뮬레이터에서 각각 구동하면 되기 때문에 굳이 거창한 개발자 도구까지는 필요 없고, 그냥 이클립스에서 자바스크립트로 개발하면 된다. 만약 개발자 도구를 직접 개발했고 강력하다고 강조하는 우리나라 솔루션이 있다면 대부분 뻥튀기이다. 그들의 솔루션도 이클립스에 Aptana 에디터.. 그런 오픈소스 들을 적당히 짜깁기 했기 때문이다.

문제는 모바일 디바이스의 자원 활용과 보안, 네트워크 통신등의 웹이 해결하지 못하는 이슈의 해결이다.

이 부분을 해결하는것이 바로 모바일 하이브리드 프레임워크의 메인 영역이다.

모바일 하이브리드 프레임워크/토탈 솔루션이 UI, 개발자 도구도 처리한다고 하지만 사실 UI는 제이쿼리

모바일등의 오픈소스 쓰면 해결하거나 그냥 웹에서 제공하는 태그를 퍼블리셔가 잘 가다듬으면 해결된다. (이 퍼블리셔 문제도 있는데 나중에 연재..)

개발자 도구도 그냥 이클립스에서 개발하면 된다. (그러나 자바스크립트 기반 개발 생산성은 형편없다. 이부분은 나중에 연재..)

그러나 웹 어플에서 보안 처리, 모바일 디바이스의 GPS, 중력센서등의 자원 접근, 네트워크 처리등의 

고난이도 처리는 모바일 하이브리드 프레임워크에서 인터페이스를 제공하여 네이티브에서 처리해야 한다.

기업에서 요구하는 어플의 조건은 웹으로 저렴하게 개발해야 하지만 웹으로 할수 없는 부분까지 해주기를 요구하기 때문에 네이티브에서만 처리해야하는 부분을 별도 개발하고 네이티브와 연동하는 API를 개발하여 웹에서 호출할수 있게 해주는 모바일 하이브리드 프레임워크가 필요하게 되었다.

그래서 금융쪽이던 그 어느 쪽이던 모바일 웹으로 개발할 경우 가장 이슈가 되는 부분이 모바일 디바이스의 자원 활용과 관련된 네이티브 연동하는 기술적인 문제를 모바일 하이브리드 프레임워크가 얼마나 잘 해결해주느냐가 중요하다.

우리나라의 여러 업체들이 '폰갭'이란 오픈소스 하이브리드 프레임워크를 짜깁기하여 솔루션들을 출시했다. 이 하이브리드 프레임워크가 잘 작동하려면 최우선 조건이 웹에서 네이티브 API를 호출하는 방식이 간결하고 안정성이 보장되야 한다. 그러나 내가 나중에 설명하려는 어떤 이유로 현재 하이브리드 프레임워크는 웹에서 네이티브 API를 호출하는 방식이 매우 지저분하고 안정성도 떨어진다.

그리고 각 업체들이 자기들 마음대로 API문법을 정하기도 하여 표준화가 안되어 있고 파편화가 진행되고 있다. 이런 각 업체들의 프레임워크를 우리나라 기업 환경에서 마구잡이로 도입한다면 예전에 우리나라 IT 발전을 막았던 액티브엑스처럼 이 프레임워크들도 마치 돌연변이 암처럼 우리나라 모바일 IT 환경을 괴롭힐지 모른다.

모바일 웹 관련 프레임워크의 정의를 네이티브 어플간의 수준차를 줄이기 위한 솔루션이라고 정의했다. 이말은 모바일 웹 관련 프레임워크가 아무리 뛰어나도 네이티브 어플을 따라잡긴 불가능 하다는 것이다. 마치 마티즈를 아무리 잘 튜닝해도 K5중형차 '깡통'을 따라잡기도 불가능한것과 마찬가지다. 더구나 지금의 우리나라 모바일 하이브리드 프레임워크는 고장잘나는 마티즈와 같다. K5몰던 모바일 개발자들은 울며 겨자먹기식으로 털털 거리는 마티즈를 운전하고 있다.

그러나 양치기 소년 '을'들이 마티즈를 '갑'에게 설명할때는 K5와 비슷하거나 어느면은 더 나을수 있다고 뻥튀기를 하고 있다.

당신이라면 K5 폼나게 몰다가 마티즈를 몰겠는가. 아이폰/안드로이드 모바일 개발자들이 열심히 노력한 끝에 K5 수준의 플랫폼에서 즐겁게 일하다가 요즘 프로젝트 잘못 걸리면 형편없는 마티즈를 몰게 되었다. 모바일 IT 현장에서 현재 이런일이 벌어지고 있다. 나는 와신상담끝에 이런 일들을 세상에 알리고자 한다.

[모바일 하이브리드 프레임워크가 아무리 뛰어나도 결코 네이티브 플랫폼을 능가할수 없다. 모바일 하이브리드 프레임워크 태생이 네이티브 플랫폼과의 수준차를 극복하기 위함이다. 하이브리드 프레임워크 용어 자체가 꼭 필요한 핵심 모듈은 네이티브를 쓰겠다는 것이다. 모바일 하이브리드 프레임워크는 마치 고속도로를 달리는 똥차와 같다. 예전 마티즈 김여사의 인천대교 대참사와 같은일이 IT 현장에서도 벌어질수 있다. 비용절감 노리다가 대형사고 나는 것보다는 차라리 본래 들여야할 비용을 투자하여 폼나게 K5 모는것이 낫지 않을까.]

* 연재 계획

0.탐욕

1.시대적인 배경

2.국산의 문제

3.자바스크립트 개발 환경

4.goto문의 악몽 비동기 프로그래밍

5.퍼블리셔 의존 문제

6.개발자의 질적저하

7.애플/구글사의 보증 제외 문제

* 영업력 90% 기술력 10%의 설익은 모바일 하이브리드 프레임워크를 쓰는 바람에 고생한 개발자들의 제보를 받습니다. 또는 반대 댓글도 환영합니다. 논쟁을 환영합니다.