서버개발자 그리고 아이폰 개발자

Project 2011.12.05 23:50
서버사이드 개발자에서 전문적인 아이폰 개발자로서 약 7개월정도가 지난것같다.
물론 이전에도 주말에 취미로 또는 회사에서 프로토타입정도로 아이폰 및 OSX에서 개발을 한적은 있지만
이렇게 풀타임으로 개발한적은 이번이 처음이기 때문에 기점을 올해로 잡는다.

 그동안 아이폰 개발을 하면서 느낀것을 몇개 정리하면


1. 쉽지 않은 Objective-C개발
자바로 웹페이지를 개발하는데 있어서 소스 코드의 완성도는 뒤로 두고서라도
화면에 원하는 데이터를 표시하는데까지는 그다지 시간이 걸리지 않지만,
아이폰에서 원하는 화면을 만들기 위해서 선택할수 있는 방법은 많지가 않다.
뷰를 구성하는 컴포넌트들의 특성과 구조를 이해한다음에야 각각의 뷰를 화면에 붙일수가 있는데
애플이 제공하지 않는 뷰의 디자인을 수정하기 위해서는 더욱더 굉장히 많은 학습시간이 필요하다.
(물론 전부 이해한뒤에는 쉽게 수정이 가능할정도로 뷰의 프레임워크는 정말 정말 잘 짜여저 있다.)

개인적으로는 자바보다 3배는 시간을 들여야 비슷한 퍼포먼스를 낼수 있을거라 생각한다.
물론 그뒤에는 자바보다 3배이상 빠르게 개발이 가능할듯하다.


2. 디자인이 90%이다.
어느정도의 불폄함은 감수해가며 사용하는 웹사이트와는 달리
항상 손에 들고 다니며 사용하는 앱의 특성상 아름다운 디자인은 유저의 손을 붙들어 놓는데 가장 큰
요인이라고 말할수 있다. 또 앱의 전환이 홈버튼과 클릭 길어야 2초밖에 걸리지 않기 때문에,
다른 앱과의 경쟁에서 이기려면 기능도 중요하지만 사용자 UI 및 UX가 더욱더 중요한 부분을 차지하게 된다.


3. 테스트 그리고 테스트
아이폰의 앱은 뷰와 데이터와 콘트롤러를 가진 내부적으로 하나의 완결된 어플리케이션으로서 존재하기 때문에
그만큼 많은 테스트를 필요로 하게 된다.
서버 개발 할때는 기능 및 시나리오 테스트정도로 상대적으로 뷰의 테스트가 간단했다면
아이폰의 테스트는 대부분이 뷰와 관련된 테스트라고 할정도로 뷰관련 테스트가 많다.
디자인이 그만큼 중요하기 때문에 1PX 하나하나 체크하고 수정해야하는 부분이 생각보다 시간이 많이 걸렸다.


4. 많은 사용자의 피드백
쉽게 다운로드 받아 매일 사용하는 만큼 유저로부터의 피드백은 상상을 초월할정도로 많이 온다.
한번 개발한 서버쪽 프로젝트의 피드백은 거의 관계자에게서 받아 그렇게 양이 많지 않지만(볼륨이 큰만큼)
앱에서는 엔드유저의 폭발적인 피드백을 볼수 있다는 점에서 보람과 부담을 동시에 느끼게된다.
하루 twitter로 RT되는 양이 상상 초월하기 때문에 앱을 버젼업 할때마다 버그가 없는 제품을 내기위해 엄청난
압박을 받기도한다. 
한번은 유저의 클레임으로 앱스토어에서 삭제된 적이 있는데, 복구하는데 약 2주정도 걸렸던 기억이 있다.
그 이후로는 잘못된 정보가 퍼지지 않도록 회사 CS(customer service)를 강화하고 앱내에도 문의페이지를 넣는등 많은 신경을 썼었다.


5. 애플의 심사
앱의 심사는 보통 일주일 정도 걸린다. 긴급심사의 경우 하루나 이틀정도로 통과시켜주기도 급한 경우가 아니면 자주 이용하지 않는 편이 좋다.
이번 앱의 경우 리젝트도 여러번 당했었다. 한번은 private api를 이용했다는 이유로 리젝트 당하기도 했었고
앱의 기능에 대해 오해해서 리젝트 당하기도 했었다.
때문에 예상대로 심사가 통과하지 않았을경우의 스케쥴링 , 충분한 여유를 두고 심사를 넣는것이 좋다.


 결론을 이야기하자면 아이폰앱의 개발은 전혀 다른 도메인에 집중해야할 부분이 틀리기 때문에
서버개발과는 전혀 틀린 개발 프로세서와 지식이 필요하다. 하지만 한번 공부해서 개발해볼 가치가 있을정도로
개발이 즐겁다. XCODE도 쓰다보면 상당히 편리하고, Cocoa Framework 또한 아름답게 짜여진 프레임워크라
많은 공부가 된다.

 현재 만들고 있는 앱의 유저는 약 700만명으로 올해 목표를 이미 7배나 지나 초고속으로 성장중이다.
열심히 만든 보람도 있지만 릴리즈 때마다 그만큼의 신중함이 요구되는 유저수이기도하다.
 하지만 아직 구현해야할 기능들이 많이 있는데다 이 많은 유저들과 앱을 발전시킬 생각을 하면 
내년 또한 상당히 기대가 된다.
 

 
Trackback 0 : Comment 0

이 바닥에서 살기 힘들어요?

Diary 2011.03.21 11:32
정말 오랜만에 OKJSP , javaservicenet 를 들어가봤다.
정말 내가 신입으로 들어와서 보던 이야기들이 몇년째 되풀이 되는걸 보곤
재미있기도하고 웃기기도하고  그렇다.

정리하면 이런 이야기인데 
"꾸준히 공부하지 않으면 IT바닥에서 살아남기가 힘들고  그렇다고 다른 직업을 찾아도 힘든건 매한가지 일것같아서 배운게 도둑질이라고 이 일을 하긴 하는데 너무 힘들다"

난 이 힘들일을 왜 계속하는지 모르겠다.  다른바닥도 물론 힘들긴하겠지만 상위 10%만 잘먹고사는 여기보다야 
편하지않을까?  90%를 착취해서 먹고사는 피라미드에서 왜 계속 일하는지?

상위 10%에 뜯어먹히지 않는 이바닥 안에서의 다른 방향을 찾던가
(새로운 비지니스?새로운 언어?)
하위 20%는 힘들어도 상위 80%는 그럭저럭 살아남는 곳으로 가든가.
(어딜가든 잘난놈은 잘살기 마련..)

몇년째 저런곳에서 넋두리나 하고 있어도 또 움직이지 않으면 상황은 변하지 않는다는거. 

Trackback 0 : Comment 0

소프트웨어 개발과 IT아키텍트의 미래 - ( 羽生田 栄一 )

번역 2009.10.11 12:22
 오랜만의 번역입니다. 자주 사서 보는 잡지중 하나인 IT 아키텍트가 이번호를 마지막으로 휴간하게 되었네요.
시중에 범람해있는 기술 테크닉서가 아닌 수준높은 내용이 담겨있어 재미있게 읽고 있었는데 아쉽게 되었습니다.

이번호 마지막 특집중 하나는 "지금부터의 IT아키텍트/개발자의 나아갈 길" 입니다.
휴간을 하는 잡지의 특집으로는 아이러니 하지만 유명한 여러 아키텍트의 견해가 담겨있어서 즐겁게 읽고있습니다.

 그 중 재미있게 읽은 하뉴다 에이이치씨(豆蔵 마메조 CTO)의 인터뷰를 번역해보았습니다.
혹 나중에 저작권에 문제가 되어 언제 삭제할지 모릅니다^^;






소프트웨어 개발의 복잡성을 4개의 부분으로 파악한다.

현대의 소프트웨어 개발은 다양한 "복잡성"을 안고있지만 , 그것을 큰 틀구조로 파악하면,
다음의 2항목을 기준선으로 4구역으로 나눌수가 있습니다.



세로축으로 소프트웨어 개발에 관한 요소를 [ 사물 , 사람]으로 표시, 가로축으로는 [소프트웨어 개발에 관한 문제가 그것의 문제인가 , 아니면 그 해결책인가]를 표시하는 문제해결의 축으로 두었습니다.

  이 두축으로부터, 4개의 구역이 만들어집니다.
첫번째 구역은 [설계/구축대상이되는 소프트웨어 시스템의 복잡성] , 
두번째 구역은 [업무영역과 문제공간의 복잡성],
세번째 구역은 [고객과 스테이크홀더, 및 개발자와의 커뮤니케이션의 복잡성] , 
네번째는 [소프트웨어 시스템을 만드는 개발팀 내부의 커뮤니케이션의 복잡성]을 표시하는 영역입니다.

 그리고 오늘날에는 이 4 영역에 잘 발란스를 주어 경영환경과 기술의 변동/진화에 더욱 기민히 대응하는 능력이 요구되기 때문에, 그것을 +1 로 그림의 중심부에 표시하고 있습니다.

 또, 소프트웨어 엔지니어링에 중요한 "4개의 P"로서 Product,Process,People,Project 를 말하고 있습니다.
그것들 각각은 위의 4 영역에 대한 것들이라고 생각할수 있습니다.

 각 영역에 요구되는 IT아키텍트의 역할

  아마도, IT아키텍트의 다수는 첫번째 구역의 [설계/구축대상이되는 소프트웨어 시스템의 복잡성] 만 주목하고 있습니다만, 앞으로는 클라우드 컴퓨팅등의 보급에 따라 , 이 영역의 중요한 부분의 다수는 캡슐화될것입니다.

 그러므로 , IT아키텍트의 역할은 , [최종적으로 세계에 몇회사 남는정도]라고도 할수있는 클라우드 인프라의 제공기업에 소속, 그 안에서 스케일아웃(scale out)하는 분산 병렬 아키텍쳐의 구조를 구측하는 [인프라 아키텍트]와 , 그것들의 환경을 제공하고 , 유저와 업무의 요구를 얼마나 적절한 서비스의 조합으로 현실화하는가를 생각하는 [서비스 아키텍트]로 2극화되지 않을까 라고 전 생각하고 있습니다.

 또, 네번째 구역의 [소프트웨어 시스템을 만드는 개발팀 내부의 커뮤니케이션의 복잡성]의 영역, 요컨데 개발프로젝트 관리의 영역에 관해서도 , 단순하게 PMBOK과 CMMI등의 지식을 베이스로 메니지먼트하면 끝날일이 아니게 됩니다. 여기서는 [고객에 있어 얼마나 가치가 있는 서비스를 기획/설계/실현/개량할것인가]라는 관점에서 PDCA사이클을 돌려 , 애자일형태의 메니지먼트를 수행할수 있는 사람이 인정받게 됩니다.

두번째 구역의 [업무영역과 문제공간의 복잡성]에 관해서도 , 클라우드 컴퓨팅과 연계, 모바일과 유비쿼터스의 기술과 조합된 업무와 밀착된 리치한 인터페이스, 문제영역의 의미를 적확히 모바일화하는 위에 온톨로지등의 룰를 베이스로 세련되게 서비스를 제공하는등 , 클라이언트 측의 정보를 잘 관리할수 있게 됩니다. 여기에서 활약하는 IT아키텍트는 , 현장과 업무의 니즈를 필드워크로 파악해 적확한 모델로의 형태를 내는 "필드 IT 아키텍트"로로도 불려질 존재일지도 모릅니다.

세번째 구역의 [고객과 스테이크홀더, 및 개발자와의 커뮤니케이션의 복잡성]에 대해서는 , 앞으로 여러 조직과 커뮤니티의 속한 다양한 클라이언트/스테이크홀더가 횡단적으로 관계하는 일이 늘어날것이라 생각됩니다. 따라서, 출신지와 이력, 인종등이 혼재한 멤버의 이해와 관심사를 잘 조정해 적확한 골을 설정해, 프로젝트로서 정리해가는 코라보레이션 형의 워크 스타일과 , 그 퍼실리테이션을 행하는 인재가 중요하게 될것입니다. 이것을 행할 IT아키텍트는 "프로듀서형의 IT아키텍트"로 불려질지도 모릅니다.

 4개의 영역의 무엇에 강한지에 따라  IT아키텍트의 개성이 나온다.

그리고 앞으로, 이 4개의 영역은 IT의 공공 인프라화의 진전에 따라서 점점 융합이 진행. 그러는와중 상황의 변화에 신속한 대응이라는 요구에 응하는 한편, 전체의 발란스를 생각해 [사물/사람],[문제/해결]의 사이를 브릿지해,IT의 유효성을 최대한으로 발휘할수있도록 일을 나누는 인재,즉 IT아키텍트의 필요성이 늘어날것입니다.

  아마도 , 이런 환경에서는 업무와 기술은 거의 모르는 관리 중심의 타입인 프로젝트 메니져가 활동하는 여지는 적어지게 됩니다. IT 아키텍트는 1,2구역을 중심으로 제품의 품질에 최종책임을 갖는 인재, 프로젝트 메니져는 3,4영역을 중심으로 프로젝트의 납기/코스트에 최종책임을 갖는 인재로 대략적인 구분을 남겨두고, 서로 경쟁하며 절차탁마해 나가게 됩니다. 그리고 각각의 IT아키텍트의 개성은, 4구역 안에서도 어느 영역의 스킬/경험이 보다 강하느냐에 따라 다양해지게됩니다.

 클라우드시대에 따른 IT인재의 활동영역

 클라우드 시대에있어, IT인재가 활약하는 장소는 , [클라우드의 이용국면] , [클라우드의 제공국면] , [현재시스템과 클라우드의 결합국면]이라고 하는 3개의 영역으로 나눠져 갈것입니다.
 언제가 되든 , [저코스트로 신속히 아이디어를 형태로 만드는 수단]으로서 사용되는 것이 클라우드의 유효성을 가장 살리는 활용법으로 존재, 이것은 클라우드와 애자일한 경영/애자일 개발의 친화성이 높음을 의미합니다.

 앞으로는 경영자도 프로젝트 메니져도 ,[업무와 IT],[아이디어와 실현수단]의 양방에 관해, PDCA사이클을 돌리며 가설검증형으로 스피디하게 기획/실시해 가는 것 뿐의 기량이 요구됩니다. 그리고 , 그활동을 지지하는 IT아키텍트,IT인재는 다음의 세가지 영역에 따른 활동의 중심이 되어, 유저와 경영자에게 비지니스 가치를 가져오지않으면 안됩니다.

-언제라도/어디서라도 , 현장에서 쾌적한 환경을 제공한다.
-"비지니스상의 효과의 애자일한 검증"이라고 하는 PDCA사이클을 돌리며, 서비스의 기획/설계/개발을 행함.
-효율성/신뢰성/스케일아웃의 요건을 만족,SLA를 담보가능한 인프라 아키텍쳐를 제공한다

반대로, 이런 것이 가능하지 않으면, IT아키텍트라고 해도 단순한 코스트경쟁으로부터 벗어나는것은 어려워 IT프로페셔널로서 살아가는 길은 닫혀져 버릴 가능성이 있습니다.
 지금의 IT는 "경영의 무기"로 존재합니다.
IT아키텍트를 시작하는 IT인재는, 지금보다도 , 더욱 경영과 업무에 함께해 활동하는 스탠스로 바꾸어 나가지 않으면 안됩니다.



Trackback 0 : Comments 2