태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

 

 

 

 
분류 전체.. (1308)
마이크로소.. (132)
민수네 가족 (17)
호랭이 사.. (141)
열이아빠의.. (7)
PlayPhone (98)
NetworkON (1)
ratharn의.. (10)
큐브 해법 (10)
사람들 (6)
개발 이야기 (94)
아이티 이.. (539)
영어 이야기 (2)
좋은책 이.. (8)
대기중인.. (1)
발명 이야기 (2)
건강하게.. (15)
구글  블로그  마소  LG전자  아이폰  마이크로소프트  개발자  마이크로소프트웨어  삼성전자  호랭이 
 free offers
└>free offers
 online pharma..
└>online pharma..
 Go here
└>Go here
 visit my webp..
└>visit my webp..
 Go Source
└>Go Source
«   2017/09   »
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
+ ITViewpoint
+ 도이모이
+ with okgosu
+ 학주니닷컴
+ 열이아빠의 RI..
+ Gsong.s Blog
+ 비주얼스튜디..
+ 광파리의 글로..
+ LovedWeb
+ 블루오션의 터..
+ 울지 않는 벌새
+ PC 지존
+ 디지털통
+ 아크비스타
+ 고독한 프로그..
+ Total : 1,926,122
+ Today : 1,143
+ Yesterday : 1,700
  

 

 

 

소프트웨어 _해당되는 글 19건
2010.06.17   C++ 개발자들의 엣지있는 선택, Visual C++ 실전 프로젝트 가이드 (1)
2010.02.12   제 2의 소프트웨어 혁명을 이끄는 스마트폰 
2010.01.26   실버라이트를 이용한 포토 줌 테스트 (2)
2010.01.22   C++로 만든 코드 안드로이드로 마이그레이션 하기 
2010.01.19   소프트웨어 개발 생산성 팍팍 올리기 
2010.01.14   큰물에서 놀고 싶은 개발자를 위한, 해외 진출 방법론 
2010.01.14   모바일에서 찾는 개발자의 미래 
2009.12.18   실전 아이폰 게임 개발 준비하기 
2009.12.18   앱스토어&바다 앞세운 삼성전자 스마트폰 전략 (2)
2009.12.04   흥미로운 예제로 배우는 아이폰 & 아이팟 프로그래밍 (1)

 

C++ 개발자들의 엣지있는 선택, Visual C++ 실전 프로젝트 가이드
+   [마이크로소프트웨어]   |  2010.06.17 11:39  


대한민국 축구의 수준이 히딩크 감독을 만나면서 급상승 한 것처럼


아주 어려운 일이라도 좋은 지도자 혹은 훌륭한 동반자나 조력자를 만나게 된다면


놀라울 정도로 빠르게 성장하는 사례를 많이 보게 됩니다.


소프트웨어 개발도 마찬가지인데요.


혼자 아무리 끙끙거려봐도 해결되지 않던 문제가 한 권의 책, 단 한 시간의 세미나를 통해 해결되는 경우도 종종 있죠.


특히 C++에 관련된 개발 노하우는 흔치 않은 탓에 고민들 많으셨죠!


자 이제 며칠 남지 않은 예약판매에 참여하여 효과적이면서도 좋은 정보를 얻어가시길 바라겠습니다.


바로 지금 마이크로소프트웨어에서 진행하고 있는 C++ 단행본 예약판매 얘긴데요.

 

사용자 삽입 이미지


마소 필자로도 잘 알려진 이스트소프트 김용현 팀장을 포함하여 Visual C++ MVP 3명이 자신들의 개발 노하우를 꾹꾹 밟아 담은 C++ 단행본을 출간했습니다.


제목은 'Visual C++ 실전 프로젝트 가이드'고요.


444페이지에 필자들의 노하우를 꽉꽉 밟은 책의 가격을 더 많은 개발자들에게 도움이 될 수 있도록 파격적인 가격 2만원에 책정하게 되었는데요.


여기서 다시 30% 할인!


게다가 택배비까지 무료로 받아보실 수 있는 날짜가 이제 정말로 며칠 남지 않았습니다.


다음 링크를 클릭하시면 책에 대한 자세한 소개와 구매 페이지를 볼 수 있습니다(로그인 필요).

------------------------------------------------------------------

'Visual C++ 파워풀 개발 테크닉' 예약 할인 판매


30% 할인| 20,000 -> 14,000

이벤트 기간| 6월 9일 ~ 6월 16일

문의 : Subscribe@imaso.co.kr

------------------------------------------------------------------


>>> 자세한 정보 보기/책 사러 가기 <<<


 

사용자 삽입 이미지


'Visual C++ 파워풀 개발 테크닉' C++ 개발자들에게 차암 좋은데!!!


C++ 개발자한테 정말 좋은데...


어떻게 말로 표현할 방법이 없네!


직접 책을 사서 보여줄 수도 없고...


대신 코딩을 해 줄 수도 없고...


>>> 자세한 정보 보기/책 사러 가기 <<<

신고




     c++, IT, Visual C++, 개발서, 개발자, 김용현, 단행본, 마소, 마이크로소프트웨어, 블로그, 소프트웨어, 알약, 알집, 예약판매, 웅진, 웰북, 할인판매, 호랭이
     0   1
BlogIcon north face vest 2012.12.06 15:32 신고
directory listing which models by itself aside from comparable websites by providing each expert testimonials as well as customer testimonials within the Internet's

아이디 
비밀번호 
홈페이지 
비밀글   

 

 

제 2의 소프트웨어 혁명을 이끄는 스마트폰
+   [PlayPhone]   |  2010.02.12 18:39  


이 글은 아이마소(www.imaso.co.kr)에 게재된 것입니다. 게재 시기로 인해 내용에 다소 지난 이야기가 포함될 수 있습니다.

<아이마소 가기>

 

<필자소개>

신종호 jonghoshin@hotmail.com|사용자 모델링 분야 리서치를 하고 있으며 멀티모달(Multimodal)을 사용하는 휴먼-머신 인터랙션의 최적화 및 사용자 모델과 머신러닝(Machine Learning)을 활용한 서치(Search)/리코멘데이션(Recom mendation) 시스템이 주 관심 분야이다.

제 1의 소프트웨어 혁명을 PC가 이끌었다면, 스마트폰은 두 번째 단계로의 소프트웨어 발전을 이끈다. 유비쿼터스 컴퓨터로 대변되는, 다가오는 모바일 컴퓨팅 환경의 중심에 스마트폰이 있다. 이에 국내 출시 예정인 아이폰과 모토롤라의 드로이드폰을 중심으로 스마트폰의 현황과 IT 산업으로의 파급효과를 살펴본다. 개발 환경으로서의 애플 SDK와 구글 안드로이드, 또 앱 스토어, 안드로이드 마켓, 그리고 삼성의 바다 등과 같은 스마트폰 소프트웨어 마켓을 알아본다.

애플 아이폰의 한국 출시로 휴대폰 업계가 떠들썩하다. 지난 9월 23일 방송통신위원회가 44차 회의를 열어 이를 결정한 것이다. 국내 통신, IT 기술의 발전, 더 나아가 소프트웨어 업계의 글로벌 스탠다드로의 발전을 위해 좋은 발판을 마련한 것으로 본다.

미국은 반면 모토롤라의 ‘드로이드’ 출시로 스마트폰 업계가 술렁이고 있다. 11월 6일 출시 후 주말에만 무려 10만 개나 팔렸다고 증권가에 보고되어 모토롤라의 주가가 폭등하고 있다고 한다. 드로이드는 구글의 휴대폰 오픈 운영체제인 ‘안드로이드’를 기반으로 개발되었다. 모토롤라-구글-버라이즌(북미 1등 통신업체)의 삼각편대를 기반으로 애플-AT&T(2등 통신업체)의 스마트폰 비즈니스 독주를 막겠다는 것이다.

바야흐로 소프트웨어 발전을 위한 제 2의 도약기가 도래했다. 제 1의 도약기가 PC의 등장으로 마련되었다면 아이폰이나 드로이드 같은 스마트폰은 제 2의 도약기를 촉발시킨 것이다. 지난 몇 년 간 회자되던 ‘클라우드 컴퓨팅’, ‘유비쿼터스 컴퓨팅’, 그리고 ‘심리스 컴퓨팅’ 등을 이끌 중심기기로서의 스마트폰이 우리 주위에 이미 들어서고 있다. 이제 이 플랫폼 위에 얼마나 유용하고 편리한 소프트웨어를 개발하느냐가 관건이다. 애플의 앱 스토어, 구글의 안드로이드 마켓이 다양한 애플리케이션 개발을 이끌고 있으며, 국내에서는 삼성이 소프트웨어 온라인 마켓인 ‘바다’를 오픈한다.

스마트폰의 대명사가 된 아이폰
가히 혁명적이라 할 수 있을 만한 수익구조이다. 세계 1, 2위 업체인 노키아와 삼성을 제치고 올 3분기 영업이익에서 애플이 아이폰 하나로 더 많은 영업이익을 거두었다고 한다(Strategy An alytics). 그 성공의 원인으로 크게 두 가지를 꼽는다. 수많은 응용 소프트웨어를 통해 유틸리티를 높인 점, 그리고 혁신적인 디자인과 편리한 조작방법으로 사용자들의 감성을 자극한 점이 그것이다.

아이폰의 사용자들은 매일매일 쏟아지는 소프트웨어 애플리케이션에 열광한다. 돈을 절약할 수 있는 소프트웨어로부터 개학을 맞이해 사용할 수 있는 유용한 소프트웨어, 엄마/아빠를 위한 최고의 소프트웨어 등, 그 영역이 광활할 뿐 아니라 쓰임새가 매우 구체적이다. 타임지에 의해 선택된 최고의 아이폰용 소프트웨어 중 하나인 판도라(Pandora)는 대표적인 애플리케이션으로서 사용자의 취향 패턴에 따라 최적화된 라디오 스테이션을 선별해 스트리밍으로 음악을 들려주는 소프트웨어이다. 직관적이고 깔끔한 인터페이스, 그리고 음악을 구입하기 용이하게 정리한 북마크와 링크는 사용성 측면에서 사용자들에게 높은 점수를 얻고 또 무료라는 점이 그 가치를 더욱 높이고 있다. 어라운드미(AroundMe)는 또 다른 베스트 애플리케이션으로서 심플한 측면이 강조된, 사용자의 현재 위치에서의 주요한 서비스 업체(병원, 호텔, 영화관 등)의 정보를 알려주는 애플리케이션으로 역시 좋은 평가를 받고 있다.

다른 성공 요인인 디자인 측면에서 본 아이폰은 애플의 작품답게 완성도가 매우 높다. 특히 작은 화면에 나타낼 수 있는 인포메이션의 양을 최대한 활용한 UI는 사용자에게 최적의 사용성을 제공해준다. 인체공학적인 측면을 고려한 버튼의 크기, 터치의 감을 살리는 움직이는 그래픽, 그리고 자동에러 교정을 통한 사용자 만족도를 높이는 UI 시나리오 등 디테일한 것들이 고려되어 디자인되었다. 한편, 화려하고 눈길을 끄는 그래픽 효과를 최대한 살린 UI가 아이폰을 더욱 빛나게 한다. 기상예보 소프트웨어인 웨더 채널(The Weather Channel)은 인터렉티브한 환경 하에 날씨가 주는 그래픽한 효과, 즉 천둥 치고 비가 오는 움직이는 그래픽을 제공해 더욱 실감나는 날씨에 대한 느낌을 가질 수 있게 해준다. 즉, 유저 익스피리언스(User Experience)를 독특하게 또 재미있게 만든다.

아이폰은 스마트폰의 스탠다드로 자리 잡고 첨단 모바일 기기로서의 기술력을 인정받는 디바이스이지만 폐쇄적인 소프트웨어 제공으로 인해 많은 프로그래머들이 개방성을 요구하기도 한다. 몇몇 프로그래머들은 제일브레이커(Jailbreaker)로서 AT&T 서비스에 묶여 있는 아이폰을 오픈해 다른 네트워크 사용자들도 아이폰을 사용할 수 있게 해준다. 또 구글의 지메일(Gmail)에 푸쉬 기능을 사용해 이메일을 받아볼 수 있도록 했으며, 여러 컴퓨터와 싱크(Synch)가 가능하기도 하다. 비공식적 앱 스토어를 연 씨디아(Cydia)는 씨디아 스토어를 통해 앱 스토어에 정식 등록되지 못한 소프트웨어들이나 다른 네트워크 상에서 최적인 소프트웨어, 또는 정식등록을 거부한 소프트웨어들을 공급하고 있다. 제일브래이크를 하여 씨디아 스토어를 사용하는 사용자들은 애플의 정식 지원(업그레이드)을 받을 수 없으므로 주의를 요한다.

산업간 영역구분이 없어지는 스마트폰 비즈니스 
현재 스마트폰 비즈니스에는 애플과 같은 컴퓨터 회사들이 더 많은 기회를 바라며 속속들이 참여하고 있다. 대만의 에이서는 넷북과 랩톱을 앞세워 델을 제치고 전 세계 2위의 컴퓨터 제조업체로 올라섰다. 흥미로운 뉴스는 에이서가 올해 스마트폰 시장으로 진입하고 2012년까지 1,000만 개의 스마트폰을 판매할 전략을 세웠다고 한다. 또 전 세계 컴퓨터 판매 3위인 델도 스마트폰 시장으로의 진입을 선언한 상태이다.

중국이나 떠오르는 제 3세계의 스마트폰 마켓은 이제 막 스마트폰 시장 진입을 시도하는 에이서와 델에게는 이미 성숙한 서방의 마켓보다 더 매력적일 것이다. 메이저 하드웨어 제조업체인 에이서와 델은 컴퓨터 마켓에서의 경험을 바탕으로 낮은 가격과 스타일리쉬하고 혁신적인 핸드셋을 무기로 시장 진입을 서두르고 있다고 한다.

위기를 느낀 한국 휴대폰 메이커들도 스마트폰 비즈니스 경쟁에 재빨리 뛰어들고 있다. 삼성전자와 LG전자는 휴대폰 메이커로서의 위상이 매우 높아진 것은 사실이나 스마트폰 마켓은 겨우 4% 정도만 차지할 뿐이다. 삼성전자는 2010년을 ‘스마트폰 원년’으로 선언하고 출시 모델을 40여 종으로 계획했으며 이미 지난 달 ‘옴니아 패밀리’ 5종의 스마트폰을 출시하기도 했다.

이렇듯 컴퓨터 제조업체들의 스마트폰 비즈니스 진입이 무리 없이 진행되는 이유 중 하나는 핸드셋에 설치하기 용이하도록 최적화된 구글의 안드로이드와 같은 운영체제가 준비되어 있기 때문이다. 기존의 핸드셋 메이커들을 비롯해 새로이 스마트폰 비즈니스에 진입하는 회사들은 안드로이드처럼 로열티가 없으면서 믿을 수 있는 운영체제를 설치해 제품을 출시한다. <화면 2>에서 보는 바와 같이 안드로이드의 약진이 아이폰의 운영체제와 함께 두드러진다.

다양한 환경에 맞는 스마트폰을 위한 운영체제와 애플리케이션
앞으로의 스마트폰 운영체제 시장은 아이폰과 안드로이드가 양분할 것으로 예상된다. 아직은 아이폰과 심비안이 각각 40%와 34%의 비율로 스마트폰 운영체제 마켓을 양분하고 있다. 하지만 최근 모토롤라의 ‘드로이드’와 같이 메이저 휴대폰 메이커들이 ‘안드로이드’를 내장한 스마트폰을 개발하고 있어서 안드로이드의 성장은 지속되는 반면, 오픈소스로 탈바꿈했지만, 노키아에 종속되는 느낌의 심비안 마켓쉐어는 줄어들 것으로 예상된다.

핸드셋 메이커로서 운영체제를 선택하는 또 다른 중요한 이유는 얼마나 다양한 킬러 애플리케이션들이 존재하느냐에 있다. 즉, 스마트폰 운영체제 선택에 있어서의 중요성은 운영체제에 맞는 거대 소프트웨어 마켓, 즉 애플의 ‘앱 스토어’ 또 구글의 ‘안드로이드 마켓’과 같은 오픈 마켓에 있다고 할 수 있다. 더 많은 애플리케이션을 보유한 마켓을 지원하는 운영체제가 이기는 게임이 되는 것이다. 현재 안드로이드는 1만 개 정도의 애플리케이션을, 앱 스토어는 이보다 10배 많은 10만 개 정도의 애플리케이션을 보유하고 있다.

이러한 다양한 애플리케이션들은 각각의 하드웨어, 네트워크 또 통신 프로토콜 환경 하에 구현된다. CDMA, GSM, HSDPA, 와이브로, Wi-Fi, 블루투스 등과 같은 네트워크, 그리고 쿼티(Querty) 또는 터치 키패드 등과 같은 다양한 하드웨어에 맞는 스마트폰을 위한 소프트웨어적 환경 구축이 선행되어야 다양한 애플리케이션들이 손쉽게 만들어질 수 있다.

전 세계적인 스마트폰 테크놀러지 흐름에 비춰볼 때 국내의 스마트폰 시장은 아직 시작 단계이다. 이 단계에서는 반드시 극복해야 할 부분들이 있다. 현재는 WAP와 같은 모바일 위에서 구동하는 모바일 웹이 주류를 이루고 있는데(비용 대비 효용 면에서 유리), 하루 빨리 애플리케이션들이 손쉽게 구동될 수 있는 환경을 만들어야 한다. 이와 같은 흐름에 맞춰 나가는 듯, 국내 통신 3개사(SKT, KT, LGT)들은 무선통합(FMC)을 위해 신규 휴대폰 절반 가까이에 무선 랜을 탑재할 예정으로 알려져 있다. 또 내년 출시 제품의 20% 정도를 스마트폰으로 내놓는다는 방침을 세웠다고 한다.

애플의 아이폰 SDK와 앱 스토어
아이폰 SDK(http://developer.apple.com/iphone/)는 애플의 아이폰과 아이팟을 위한 애플리케이션 개발 환경 툴 킷이다. 이는 기본적으로 Xcode IDE, 아이폰 시뮬레이터, 최적화를 위한 퍼포먼스 데이터 툴킷, 그리고 인터페이스 빌더를 포함하고 있다. ADC(Apple Developer Connection)는 무료로 가입할 수 있으며 가입 후에 아이폰 SDK를 다운로드할 수 있다. 아이폰 SDK 사이트에는 코딩을 쉽게 시작할 수 있도록 돕는 리소스들이 정리되어 있다. 코딩 시작을 위한 비디오와 문서 튜토리얼, 아이폰 레퍼런스 라이브러리, 그리고 샘플 코드와 노하우 등이 제공된다.

구글의 안드로이드와 안드로이드 마켓
구글은 2005년 안드로이드사를 인수해 내부 개발을 거쳐 2007년 모바일 운영체제인 안드로이드를 발표했다. 이와 병행해 모바일 디바이스 표준 제정을 위한 모임인 오픈 핸드셋 얼라이언스(Open Handset Alliance) 구성을 공표한다(이는 전 세계 50개 하드웨어, 소프트웨어, 통신 회사들을 망라한다).

안드로이드는 리눅스 커널 위에서 돌아가는 모바일 운영체제이다. 오픈소스 라이선스인 아파치 라이선스 하에 안드로이드 코드를 릴리즈했고 2008년 10월 이후에 전면 공개를 했다.

자바 언어로 구현된 안드로이드는 달빅 버추얼 머신(Dalvik Virtual Machine)에서 컴파일되고 실행된다. 웹 브라우저와 같은 하이레벨 소프트웨어들은 오픈소스인 웹킷 애플리케이션 프레임워크(WebKit Application Framework) 상에서 운영된다. 디바이스 에뮬레이터가 주어져 가상 디바이스와 디버거를 통한 디버깅이 가능하고 라이브러리, 샘플 코드, 튜토리얼, 그리고 이클립스 IDE를 위한 플러그인을 제공한다. 애플과는 달리 리눅스, 맥OS, 윈도우 모두를 지원하는 개발환경을 지닌다. 현재 버전 2.0이 출시되었으며, 이를 적용한 첫 번째 디바이스가 최근 각광받는 모토롤라의 드로이드이다.

안드로이드를 활용한 스마트폰들은 윈도우 폰이나 아이폰에 비해 상대적으로 빠른 프로그램 실행 속도를 얻을 수 있다. 또, 객체 지향 오픈소스는 프로그램 개발, 이용 시 높은 확장성이 가능하도록 해준다. 국내외의 많은 핸드셋 메이커들은 재빨리 안드로이드 소스를 적용한 모바일 인터넷 환경을 구축하고 있다.

안드로이드는 무료 오픈소스이다. 따라서 개방형 성격을 띤 안드로이드는 많은 핸드셋 메이커들에게 환영받는 운영체제이다. 그 세력을 넓혀 현재 5.1%의 스마트폰 마켓 점유율이 2012년에는 노키아의 심비안에 이어 2위로 올라설 것으로 전망된다(가트너 2009). 타이완의 MIC(Market Intelligence & Consulting Institute)는 2013년에 이르면 3,000만 개 정도의 안드로이드 폰이, 또 1억2,000만 개 정도의 안드로이드를 탑재한 디바이스가 존재할 것이라고 예측한다.
안드로이드를 적용한 폰들을 위한 애플리케이션은 안드로이드 마켓에서 배포, 판매 가능하다(http://www.android.com/ market/). 한편, 컴퓨터를 사용하지 않고 무선으로 응용프로그램 설치가 가능한 특징을 지닌다.

초반 경쟁 우위의 중요성, 그리고 전략
‘쿼티(Qwerty) 경제학’이란 말에서와 같이 과거로의 진행 방향에 의존하게 되는 인간들의 심리가 있다. 초반의 우위가 평생을 좌우하게 되는 것이다. 쿼티 자판의 비효율성을 극복한 드보락(DVORAK) 키보드가 나오기도 했지만, 쿼티 자판에 익숙한 사람들의 습관을 바꾸는 데 실패했다는 기록에서 교훈을 얻을 수 있을 것이다. 각 분야의 부동의 1위를 끌어내리는 것은 이러한 인간들의 경로 의존성(path dependency)에 반하는 것이어서 실현하기 꽤 힘든 일이다. 네이버의 사용자들에게 왜 사용하느냐는 질문을 했을 때 조사결과의 답은 “그동안 사용해 와서 익숙해졌기 때문”이란 것을 상기하자. 스마트폰 비즈니스에서의 아이폰과 앱 스토어도 이러한 경로 의존성 이론이 적용 가능하다.

하지만, 스마트폰 비즈니스에서 초반 우위를 유지하는 아이폰에 도전장을 내민 구글 안드로이드 진영의 약진이 두드러진다. 아이폰에 대립각을 세운 전 세계 스마트폰 메이커들은 구글 진영에서 세력을 결집하고 있는 것이다. 국내에서는 SKT, LGT가 구글 안드로이드를 활용한 스마트폰을 도입한다고 하며, 삼성전자와 LG전자는 안드로이드를 탑재한 안드로이드 폰을 내놓고 있다.

한편, 애플의 아이폰이 배타적인 경영 스타일로 인해 매킨토시의 전철을 밟는다는 전망이 미국 시사주간지 뉴스위크에서 제기되었다. 애플의 하드웨어와 소프트웨어를 묶고 통제하는 집착이 제조사들과 엔지니어들의 참여를 가로막는다는 것이다. 결국 애플에게는 거대한 시장 형성의 대가로 낮아지는 가격과 높은 퀄러티, 그리고 다양한 애플리케이션의 등장이 상대적으로 더뎌지게 되는 것이다. 가트너는 이를 뒷받침하듯이 2012년에는 안드로이드가 시장 점유율에서 애플의 아이폰을 앞지를 것이란 예상을 했다. 앞으로 어떻게 전개될지 꽤나 흥미로운 볼거리가 될 것 같다.

소프트웨어 개발자의, 개발자에 의한, 개발자들을 위한

앞다퉈 확산되는 스마트폰 경쟁은 결국 소프트웨어 개발자들에게 이전과는 다른 개발 환경, 그리고 기회를 던져준다. 썬과 IBM으로 대변되는 메인프레임급 이상의 서버 소프트웨어들, 또 마이크로소프트가 지배하던 퍼스널 컴퓨터의 다양한 소프트웨어들을 개발하던 시대가 더 이상 아닌 것이다. 애플의 주도하에 생겨나는 아이폰을 위한 소프트웨어, 불특정 다수가 지원하는 오픈소스에 기반하고 구글이 주도하는 웹 기반의 클라우드 컴퓨팅 소프트웨어, 그리고 다양한 네트워크 위에서의 임베디드 디바이스를 지원하는 소프트웨어 개발이 소프트웨어 개발자들에게 펼쳐지고 있는 것이다.

국내만을 보자면, 73만 명 수준의 스마트폰 인구가 내년이면 두 배 이상으로 증가한다고 한다. 또 현재의 스마트폰 시장은 1.5%에 불과하지만 내년은 3.7%로 증가될 것으로 예상된다. 한편, 삼성 휴대폰에서 사용할 수 있는 애플리케이션의 온라인 장터인 바다(http://www.bada.com/)가 12월에 공개될 예정이라고 한다. 애플리케이션 다운로드 기능, 인터넷 서비스 연동 기능, 혁신적인 스마트폰 UI 지원이 그 골자이다. 국내에 개방되는 애플리케이션 마켓에서는 국내 이용자 특성에 맞는 가치를 제공할 수 있는 애플리케이션들이 등장할 것이다. 결국, 이러한 일련의 모든 상황들은 다양하고 독특한 소프트웨어 개발에 대한 요청으로 귀결된다.

그야말로 ‘물 만난 고기’에 비유될 수 있는 환경이 소프트웨어 개발자들에게 펼쳐지고 있다. 소프트웨어에 대한 열정이 있는 개발자들에게 더없이 많고, 좋은 기회가 주어진다. 또, 어디엔가 적을 두어야 고정 수입이 보장되던 과거/현재의 소프트웨어 개발환경은 변혁의 시기를 맞이하고 있다. 앞으로는 소프트웨어 개발자들에게 프리랜서로의 자유로움과 안정적인 수입이 보장되는 환경이 제공될 것이다. 이런 스마트폰 비즈니스 성공의 열쇠는 소프트웨어 개발자들이 쥐고 있다. 사용자의 눈길을 끄는 독특하고 유용한 킬러 애플리케이션의 구현은 스마트폰 관련 산업을 좌지우지하게 된다. 또, 그로 인한 성공의 열매를 맛보게 되는 자도 소프트웨어 개발자가 될 것이다.

신고




     개발자, 블로그, 소프트웨어, 스마트폰, 아이폰
     0   0

아이디 
비밀번호 
홈페이지 
비밀글   

 

 

실버라이트를 이용한 포토 줌 테스트
+   [아이티 이야기]   |  2010.01.26 22:26  


실버라이트를 이용한 딥줌 이미지 테스트 포스팅입니다.

보통 기자 간담회를 가거나 인터뷰를 할 때 촬영하는 사진은 엄청나게 크지만 블로그에 올릴 때에는 작은 사이즈로 올리게 마련입니다.

또 보도자료에 딸려 오는 사진도 여간해서는 원본 사이즈로 올리기 어려운데요.

오늘 재미있는 기능을 얻게 되었습니다.

아래의 사진 위에 마우스 포인터를 위치시키고 마우스 휠을 위로 휙 굴려보세요. ㅎ.ㅎ

원본 사이즈 이상의 사진을 볼 수 있으실 거예요.

특히 이런 사진처럼 제품의 세부 이미지나 모델을 더 자세히 보고 싶어지는 사진에서는 더욱 빛을 할하게 될 기능이네요.

">

실버라이트로 구현한 기능이구요.

이렇게 상자 하나에 여러 장의 사진을 넣는 것도 가능합니다.

타일 형식으로 사진이 들어가 있지만, 확대해 보시면 모든 사진을 원본 사이즈로

심지어는 사진 한 장을 화면에 가득 채워 볼 수도 있습니다.

앞으로 종종 블로그에 이 기능을 써 봐야겠습니다.

오~ 신기해신기해

신고




     Microsoft, ms, 개발자, 딥줌, 마이크로소프트, 소프트웨어, 실버라이트, 포토줌
     0   2
BlogIcon 열이아빠 2010.01.27 09:34 신고
이런사진은 HD급으로 올려주셔야죠. ^^
호랭이 2010.01.27 10:19 신고 
양질의 서비스를 위해 HD급 사진도 확보할 예정입니다. ㅎㅎ

아이디 
비밀번호 
홈페이지 
비밀글   

 

 

C++로 만든 코드 안드로이드로 마이그레이션 하기
+   [마이크로소프트웨어]   |  2010.01.22 09:12  


요즘 소프트웨어 개발하는 사람치고 아이폰이나 안드로이드 개발과 전혀 무관할 수 있는 분이 드물텐데요. 그런데 갑좌~기 회사에서 떨어진 프로젝트가 기존에 만들어서 사용중인 C++ 코드를 안드로이드로 마이그레이션 하는 일이라면? 아 이거 참 만만찮게 난감한 일일텐데요. 월간 마이크로소프트웨어의 필자 이상욱 님이 이런 난감한 상황에 대처할 수 있는 방법을 재미있게 설명한 글이 있어 옮겨봅니다. 아직 정식으로 인사 드리진 못했는데 조만간 한번 꼭 뵙고 싶어지는 분이네요. 좋은 글 주신 상욱 님께 감사드립니다. 그리고 이 글이 많은 개발자분들께 도움이 되길 바라겠습니다.

출처| 아이마소

안드로이드 네이티브 라이브러리Ⅰ

이번 컬럼에서는 기존에 C/C++ 로 개발한 코드가 안드로이드 플랫폼에서 어떻게 동작하는지 안드로이드 플랫폼 구조를 통해 알아보고, Java 응용프로그램과 연동하기 위한 다양한 방법을 소개한다. 또 C/C++ 코드를 안드로이드 플랫폼에서 동작하는 바이너리로 빌드할 수 있는 툴체인 안드로이드 NDK에 대해 알아보고 간단한 사용법에 대해 알아보도록 하겠다.

이상욱 bumwoogi@gmail.com|새로운 기술을 배우는 것을 좋아하고 다방면에 관심이 많은 오지랍쟁이 개발자. 얼마전까지 무인잠수함을 만드는 것을 계획하였으나 도중하차 하였고, 지금은 전 인류에 공헌할 대단한 소프트웨어를 만드는 것을 꿈꾸고 있다.

이번 컬럼은 가상의 시나리오를 통해 실제 프로젝트 진행 중에 벌어질 수 있는 문제상황을 제시하고 동시에 이 문제를 해결해나가는 과정을 알아보도록 하겠다.


등장인물

  • 허우대 대리 : 몇달전 경력사원 공채로 새로 입사한 인물로 Java를 사용해봤다는 이유만으로 난생 처음으로 안드로이드 플랫폼에 기존에 C++로 작성한 소스를 마이그레이션 하는 업무를 맞는다. 허우대는 멀쩡 하지만 성과가 없다고 일정만 차장으로 부터 허우대라는 별명을 얻었다.
  • 신익한 선배 : 허우대 대리의 학교 선배로 모바일 분야에서 안해본게 없는 대단한 실력자 이지만, 일을 너무 사랑하는 나머지 인간관계는 별로 소질이 없어 보이는 시니컬한 성격의 소유자, 허우대 대리의 질문에 매번 퉁명스럽게 대답 하지만 그 속마음에는 후배를 스스로 깨우치게 하려는 나름의 철학을 가지고 있다.
  • 일정만 차장 : 이번 프로젝트의 책임자로, 일에 대한 책임감이 투철하지만 상냥한 성격은 아니다. 특히 일정을 어기는 사람을 무척 싫어한다.

허우대 대리는 얼마전 일정만 차장으로 부터 1주일간의 시간동안 이전 누군가가 C++ 로 작성한 방대한 양의 xml 문서 parser를 이번 프로젝트에 재사용 할 수 있도록 안드로이드 플랫폼에 마이그레이션 하라는 지시를 받았다. 허우대 대리에게 주어진 시간은 고작 7일. 7일 동안 허우대 대리가 어떻게 이 프로젝트를 진행하는지 함께 지켜보도록 하자.

선배, 안드로이드 애플리케이션 개발은 Java로 하는거지?

생전 처음 안드로이드 플랫폼에서 개발을 시작하는 허우대 대리는 신익한 선배를 찾아가서 조언을 구하게 되었다.

“선배, 차장님께 안드로이드 플랫폼에 기존에 c++로 작성한 엄청난 양의 parser 소스를 마이그레이션 하라는 지시를 받았는데, 나 이거 다 java로 다시 만들어야 하는건가?”

선배는 한심하다는 반응으로 특유의 시니컬한 한숨을 내쉬며 이렇게 얘기한다.

“안드로이드= java의 공식은 아니야. 안드로이드 플랫폼이 어떻게 구성돼있는지 먼저 확인해 보는게 어때?”


안드로이드 플랫폼은 크게 리눅스 커널과, C/C++로 작성한 라이브러리(보통 네이티브 라이브러리라 부른다), 안드로이드 응용프로그램의 뼈대를 제공하는 애플리케이션 프레임워크와 기본 애플리케이션으로 구성돼 있다.

리눅스 커널은 OS의 기본 기능인 태스크간의 스케줄링과 메모리, 디스크, 네트워크 등의 자원을 사용할 수 있도록 시스템 콜을 제공한다. 이는 리눅스 커널 윗부분에 초록색으로 표시된 네이티브 라이브러리를 통해 응용프로그램이 편하게 사용 할 수 있는 형태로 제공된다.

안드로이드 응용프로그램은 애플리케이션 프레임워크(응용프로그램의 구조를 제공하고 제작에 도움을 주는 Java class로 구성)을 이용하고 역시 Java언어로 작성한다.

이 Java파일을 안드로이드 SDK를 이용해 빌드하면 내부적으로 Java컴파일러와 dex converter를 거쳐 Dalvik VM(안드로이드 응용프로그램을 동작시키는 VM으로 일반적인 Java VM과는 다르다.) 위에서 동작하는 byte 코드로 변환하게 된다.

결론적으로 안드로이드 응용프로그램(Java로 작성)은 애플리케이션 프레임워크(.jar형태의 Java class.)를 이용해 VM에서 제공하는 코어 라이브러리(core library) 기능을 사용하게 되고, 이 코어 라이브러리는 리눅스 커널 위에서 동작하는 다양한 C/C++ 라이브러리(c/c++)를 호출하게 된다. 이 라이브러리는 필요에 따라 리눅스 커널의 system call을 호출하게 된다. 위 그림에서 화살표 방향을 따라 가면서 확인하자.

위 그림에서 안드로이드 런타임 계층과 라이브러리 계층을 연결하는 왼쪽 화살표로 표현된 부분에서 일반적인 함수호출 관계 외에 추가적으로 C/C++ ↔ java 호출 사이의 ‘glue’가 존재한다. 결국 이 덕분에 안드로이드 프레임워크는 자연스럽게 OS의 복잡한 기능을 리눅스 커널로부터 빌려 쓸 수 있는 것이다.

허우대 대리는 결국 C/C++ ↔ Java사이의 ‘glue’를 만들면 기존 소스를 리눅스 상에 포팅 하는 정도의 노력으로 재사용 할 수 있겠다는 결론을 내리고, 곧바로 Java ↔ C/C++ 를 호출 할 수 있는 방법을 찾아보기 시작했다.

Java ↔ C/C++ 사이의 glue는 어떤것을 사용할까?

일반적으로 Java에서 C/C++ 모듈을 사용하기 위해서는 다음과 같은 방법을 사용한다.

1. Java Native Access (JNA) 

자바 코드에서 네이티브 코드와 같은 형태로 네이티브 함수를 호출하는 방식으로 기존 코드의 최소한의 수정으로 응용이 가능해, 최상의 방법으로 생각되나 현재 안드로이드 Dalvik VM에서 지원하지 않는 방법이다.

2. Java Native Interface (JNI)
Java 초창기부터 존재한 Java/Native interface 방법으로 안드로이드 Dalvik VM에서 지원하는 방법으로 실제 안드로이드 플랫폼 소스 여러 부분에서 사용되고 있다. 그러나 이 방식은 raw form을 다루는 형태로 개발해야 하기 때문에 개발 시간이 많이 소요되고 에러를 발생 시킬만한 요소가 많다.

3. Simplified Wrapper and Interface Generator (SWIG)
JNI를 좀 더 쉽게 사용 할수 있도록 해주는 도구로 C/C++ 인터페이스를 정의한 파일을 입력 받아 C/C++ JNI wrapper 코드를 생성한다. 이 방법 역시 Dalvik VM과는 호환성 문제가 존재한다.


Native library(C/C++) 로 개발할 것 인지에 대한 선택 기준

안드로이드에서는 J2SE의 대부분의 기능과, 애플리케이션 프레임워크를 통해 다양한 API 셋을 제공하고, Java를 사용하여 대부분의 응용프로그램을 제작 하는데 부족함이 없도록 배려하고 있다.

신규 개발시 애플리케이션 프레임워크를 통해 제공받을 수 없는 일부 기능(대부분 외부 기기 나 디바이스 종속적인) 부분과 성능이 아주 중요한 일부 기능을 제외하고는 Java를 사용하여 개발하는 것이 프로젝트 장기적인 관점에서는 나은 판단이라 생각된다.

C/C++로 코드로 개발은 유지보수와 디버깅 측면에서 번거롭고 불편한 부분이 있으며 JNI를 이용하여 Java 쪽으로 glue를 만드는 일이 예상하는 것만큼 간단한 일은 아니기 때문이다. 여기서 제시하는 가상의 시나리오 역시 주제를 이끌어 가기 위해 단순화시킨 예일 뿐이지 실제로 기존에 C/C++로 작성한 코드를 마이그레이션 하는 작업이 주어질 경우 얼마나 인터페이스가 단순한지, 기존코드에서 플랫폼 종속적인 부분이 얼마나 있으며 이것을 안드로이드(Linux kernel)에 포팅하기 위해서 얼마나 노력이 필요한지, 혹은 HTTP나 STL등 안드로이드 Native library단에서 충분히 제공하지 않는 기능을 사용한 부분이 있어서 재작업이나 추가 포팅 작업이 필요한지 충분히 고려하여 기존 모듈을 재활용할 것인지, Java코드로 다시 작업할 것인지 결정해야 할 것 이다.


허우대 대리는 Dalvik VM과의 호환성 문제와 보편적으로 사용하는 기술이라는 점을 감안해 JNI를 이용해 프로젝트를 진행하기로 했다.

점심시간에 허우대 대리는 자신이 JNI를 이용하여 기존 parser소스를 거의 재활용 할수있는 방법을 생각해 냈다고 신익한 선배에게 자랑을 늘어놓았다. 이때, 밥을 먹던 신익한 선배는 이런 이야기를 남긴 뒤, 아무일도 없었다는 듯 식사를 계속 했다. 신익한 선배가 남긴 말은 이렇다.

“그럼 안드로이드 시스템에 포함해서 빌드 하겠다는 얘기야? 배포는 어떻게 할건데?”

그렇다. 그림에서 보는 C/C++ 라이브러리는 안드로이드 시스템의 영역으로 허우대 대리는 배포방법에 대해 고려하지 못한 것이다. 안드로이드 에뮬레이터를 실행하고 <화면 1>에서 초록색으로 표시한 C/C++ 라이브러리 파일의 실제 위치를 확인해보자. 아래와 같이 커맨드 창에서 emulator를 실행하거나 이클립스 IDE를 통해 emulator를 실행한다.

에뮬레이터가 정상적으로 실행되면 위와 같이 에뮬레이터 화면을 확인할 수 있는데, 이때 콘솔에서는 <리스트 1>과 같이 adb 명령을 이용하여 shell을 실행한다.

     <리스트 1> adb shell을 이용하여 네이티브 라이브러리 확인하기
    ----------------------------------------------------------------------------------------------------------
    >adb shell
    adb shell 이 실행되면 아래와 같이 library path를 확인해보자
    #echo $LD_LIBRARY_PATH
    #/system/lib
    system/lib가 library path로 잡혀있는 것을 확인하고 /system/lib directory로 이동한다.
    #cd /system/lib
    ----------------------------------------------------------------------------------------------------------

<리스트 1>의 내용을 <화면 3>를 통해 확인해보자.

<화면 3>에서는 안드로이드 플랫폼에서 제공하는 네이티브 라이브러리가 위치하는 것을 확인할 수 있다.

허우대 대리가 준비하는 프로젝트의 결과물은 다운로드 가능한 형태로 배포되어야 하는데 /system 디렉토리는 다운로드한 애플리케이션이 설치할 수 있는 영역이 아니기 때문에 /system 디렉토리 대신 /data 디렉토리에서 동작 할 수 있는 방법을 찾아야 한다.

안드로이드 시스템 이미지
안드로이드 시스템 이미지는 리눅스 운영체제에서 파일시스템은 단순히 자료의 저장기능 뿐 아니라 운영체제 동작에 필요한 필수 정보를 포함하고 장치 관리 등의 특별한 용도로도 사용하므로 선택항목이 아니라 필수 항목이다. 시스템 이미지는 안드로이드 프레임워크를 구동하기 위해 필수적인 항목으로 <안드로이드 SDK설치 디렉토리>/platforms/<플랫폼버전>/images/system. img 에서 확인 할 수 있다.

이 이미지파일은 실제 에뮬레이터가 구동될 때 /system directory에 마운트하게 되는데, 이내용은 adb shell을 실행시킨 후 최상위 디렉토리의 init.rc파일에서 확인 할 수 있다.

/system 디렉토리는 임베디드하여 탑재할 기본 응용프로그램을 포함해 안드로이드 프레임워크에 필요한 라이브러리 설정파일 등이 들어있는 영역으로 추가로 다운로드받은 응용프로그램과는 구별된다. 다운로드 받은 응용프로그램은 /data 디렉토리에 위치하게 된다.

안드로이드 SDK 설치
앞서 설명된 부분들을 실습하기 위해서는 안드로이드 SDK를 설치하고 버추얼 디바이스를 생성해야 하는데, 이 부분은 이번 컬럼의 주제와는 벗어나므로 아래 URL을 참고해 설치하기 바란다.

http://developer.android.com/sdk/index.html

허우대 대리, NDK와 만나다

다음날 배포문제로 고민하던 허우대 대리는 아래의 안드로이드 개발자 웹사이트를 통해 NDK에 대한 내용을 접했다.
 
http://developer.android.com/sdk/ndk/1.6_r1/index.html

NDK는 C/C++로 작성한 코드로 리눅스 OS 기반의 ARM binary를 생성하기 위한 크로스 툴체인을 제공한다. 여기서 ‘크로스 툴체인’이란 타깃머신과는 다른 환경에서 타깃 머신용으로 바이너리를 생성할 수 있도록 제공되는 툴인데 컴파일러 링커 그리고 기타 컴파일에 필요한 유틸리티를 포함하고 있다.

   <리스트 2> Application.mk 파일 

   --------------------------------------------------------------
   APP_PROJECT_PATH := $(call my-dir)/project
   APP_MODULES      := hello-jni
   --------------------------------------------------------------

일반적인 x86호환 CPU의 윈도우나 리눅스 PC기반 환경에서 ARM이나 MIPS등 임베디드 머신의 CPU에서 동작하는 바이너리를 컴파일 할 수 있도록 해준다.

그리고 아래와 같은 라이브러리를 사용할 수 있도록 header file을 제공하는데, 이 내용은 앞서 제시된 adb 쉘에서 확인한 /system/lib 디렉토리에 있는 라이브러리의 일부임을 확인할 수 있다.

  • libc(C library)
  • libm(math library)
  • JNI interface
  • libz (zip 압축 library)
  • liblog(Android logging library)
  • OpenGL ES library (3D graphic library, NDK 1.6버전부터)
추가적으로 안드로이드 응용프로그램 패키지 파일(.apk)에 native library를 포함할 수 있는 방법을 제공한다. 허우대 대리가 찾던 바로 그 방법이다. 그럼 이제 허우대 대리와 함께 NDK를 설치해 보도록 하자.
 
(1) http://developer.android.com/sdk/ndk/1.6_r1/index.html 에서 윈도우용 패키지를 다운로드 받는다.
(2) 적당한 위치에 (1)에서 다운로드 받은 압축파일을 푼다.
(3) www.cygwin.com에서 최신 cygwin 을 설치한다.
(4) 설치한 Cygwin bash shell을 실행하고 bash shell에서 /cygdrive/<NDK 설치 경로> 로 이동해 ‘Build/host-setup.sh’ 라고 명령을 수행한다.

이처럼 순차적으로 따라하고 나면, <화면 4>와 같이 ‘Host setup complete…’라는 문구가 나타나는데, 이럴 경우 셋업이 성공한 것이다.

이제 설치가 끝났으니 먼저 NDK에 샘플로 제공되는 hello-jni 예제를 빌드해 보자. 빌드시에는 $make APP=hello-jni라고 명령을 수행한다. 재빌드시에는 -B 옵션을 사용하고 실제 build command를 모두 확인하고 싶은 경우 V=1 옵션을 사용한다.

빌드결과로 apps/hello-jni/project/libs/areabi/libhello-jni.so가 생성되었는지 확인하자.

어떻게 NDK에서 제공하는 툴을 이용하여 예제가 빌드 되는지 알고 싶다면, apps/hello-jni/Application.mk 와 sources/ hello-jni/Android.mk 파일을 열어보자.
일반적인 make 파일과 같은 형태이며 빌드를 위한 변수를 설정하는 부분을 확인 할 수 있다. 또한 Application.mk 파일에는 응용프로그램 에서 어떤 네이티브 라이브러리 모듈을 사용할 것인지에 대해 기술해야 한다. 이 부분은 네이티브 라이브러리를 빌드하는 것과는 직접적인 관계가 없으나 이 파일을 참조해 빌드할 타깃 모듈을 결정하기 때문에 필수적으로 작성해야 한다.

     <리스트 3> Android.mk 파일
     ----------------------------------------------------
     … 중략…
 
     LOCAL_MODULE    := hello-jni
     LOCAL_SRC_FILES   := hello-jni.c
 
     include $(BUILD_SHARED_LIBRARY)
     ----------------------------------------------------

Android.mk 파일에는 실제 shared library로 빌드할 c/c++ 파일 목록 과 사용하는 라이브러리 목록, compile/link option 등을 기술해야 하는데, 이때 변수 LOCAL_MODULE 에 모듈이름을 기술하게 된다. 이어 변수 LOCAL_SRC_FILES 에 빌드하려고 하는 소스 파일명을 기술하고, 파일명 사이는 스페이스로 구별한다.

마지막 줄이 shared library, 즉 .so 파일로 빌드 하겠다는 뜻이다. 이렇게 기술하면 자동으로 lib+모듈명+.so 형태의 파일을 빌드하게 된다.

추가로 특정 라이브러리를 사용하기 위해서는 아래와 같이 LOCAL_LDLIBS 변수에 내용을 기술한다. 아래는 안드로이드 로그 라이브러리를 사용하기 위한 예이다. 또한 이에 대한 추가적인 내용은 NDK document 폴더의 ‘ANDROID-MK.TXT’,’APPLICATION-MK.TXT’,’HOWTO.TXT’ 문서를 참고하기 바란다.

LOCAL_LDLIBS     :=-L$(SYSROOT)/usr/lib/ -llog

이제 네이티브 라이브러리 빌드가 끝났으니 네이티브 라이브러리를 사용하는 Java 코드를 살펴보자. <화면 6>과 같이 apps/hello-jni 프로젝트를 이클립스에서 열어보도록 하자. 왼쪽 패키지 익스플로러 창에서 마우스 오른쪽 버튼을 클릭한 뒤 Import 메뉴를 선택한다.

이어 Existing Projects into Workspace를 선택한후 app/hello-jni/ 디렉토리를 선택한다. 이를 실행하면 <화면 7>과 같이 Package Explorer에  HelloJni 프로젝트가 로딩되면 성공한것이다.

이클립스 메뉴에서 Run->Run을 선택하거나 단축키로 Ctrl+F11을 선택하면 에뮬레이터에서 Hello-jni 프로젝트의 결과를 확인할수 있다.

에뮬레이터가 실행되는데 제법 시간이 걸리므로 인내심을 가지고 기다리기 바란다. 에뮬레이터를 동작하기 위해서는 플랫폼 버전에 맞는 AVD 파일을 미리 생성해야 하는데 이 내용은 http://developer.android.com/guide/developing/eclipse-adt.html을 참고하길 바란다.

더불어 이전에 adb shell 명령을 이용한 안드로이드 파일시스템을 살펴보았는데, 이번에는 이클립스 IDE에서 DDMS툴을 이용하여 손쉽게 파일시스템을 확인해보자. 이때 이클립스 툴바 오른편에서 DDMS perspective 버튼을 선택한다. 오른편에 File Explorer 창을 이용하여 data/data/com.example.hellojni 폴더의 내용을 확인할 수 있으며, lib폴더아래에 libhello-jni.so 파일이 있는 것 또한 확인할 수 있다.

<화면 9>에서 보여지듯, 결국 안드로이드 응용프로그램은 system/lib 폴더의 라이브러리 이외에 /data/data/<자신의 package이름>/lib 아래 네이티브 라이브러리를 추가로 참고하는 것을 확인할 수 있다.

네이티브 라이브러리를 사용하는 Java 코드 맛보기

허우대 대리는 Java코드 에서 어떻게 C로 작성한 네이티브 코드를 참고하는지 궁금해졌다. 이번에는 허우대 대리와 함께 src/com/example/HelloJni.java 코드를 살펴보자.

    <리스트 4> HelloJni.java 파일
    -----------------------------------------------------------------
    … 중략…
    public class HelloJni extends Activity
    {
        @Override
        public void onCreate(Bundle savedInstanceState)
        {
            super.onCreate(savedInstanceState);
            TextView  tv = new TextView(this);
           tv.setText( stringFromJNI() ); //-- (3)
            setContentView(tv);
        }
     
    public native String  stringFromJNI(); //-- (1)
     
    … 중략…
       static {
        System.loadLibrary("hello-jni"); //-(2)
        }
    }
    -----------------------------------------------------------------

<리스트 4>는 stringFromJNI 함수를 호출하여 얻은 문자열을 textView에 내용으로 넣어주는 간단한 소스로, 3가지 의미로 이용된다.

1) native 키워드를 붙혀서 선언부만 작성한다. 네이티브 라이브러리에 구현부가 있음을 알려준다.

2) static {..} 부분은 이 class가 로딩될 때 호출되는 되는데 이때 ‘hello-jni’ 라는 이름의 네이티브 라이브러리를 로딩하라는 의미이다.

3) 네이티브 라이브러리 함수라도 보통의 Java 메소드와 같은 방식으로 사용한다.
 
이어 Source/samples/hello-jni.c 파일을 열어서 네이티브 라이브러리 구현부도 함께 살펴보도록 하자.

<리스트 5> 네이티브 라이브러리 구현부 코드 
----------------------------------------------------------------------------------------------
Jstring Java_com_example_hellojni_HelloJni_stringFromJNI( JNIEnv* env,
                                            jobject thiz )
{
    return (*env)->NewStringUTF(env, "Hello from JNI !")
}
----------------------------------------------------------------------------------------------

<리스트 5>를 보면 함수이름 앞에 ‘Java_com_example_ hellojni_HelloJni_’ 가 붙어 있는데, 이 부분은 JNI 함수이름 규칙에 의해 package명_클래스명이 Java에서 선언한 함수 이름 앞에 붙게 된다. 함수의 내용은 단순히 “Hello from JNI!” 라는 문자열을 Java에서 사용하는 String 타입으로 변환하여 반환하는 내용이다.

참고자료
1. http://java.sun.com/javase/6/docs/technotes/guides/jni/spec/jniTOC.html
2. http://developer.android.com/sdk/ndk/1.6_r1/index.html
3. http://www.aton.com/android-native-libraries-for-java-applications/
4. http://www.swig.org/

신고




     c++ 코드, Google, 개발, 개발자, 마소, 마이그레이션, 마이크로소프트웨어, 블로그, 소프트웨어, 아이폰, 안드로이드, 앱스토어, 이상욱, 호랭이
     0   0

아이디 
비밀번호 
홈페이지 
비밀글   

 

 

소프트웨어 개발 생산성 팍팍 올리기
+   [마이크로소프트웨어]   |  2010.01.19 05:51  


모든 일에는 몇 가지 법칙이 있습니다. 사장으로서 할 말은 아니지만 뭐 대략 정리해 보면 이렇습니다. "열심히 일한다고 월급 빨리 오르는 거 아니다" "무슨 일이든 입사할 때의 연봉이 중요하다(암만 시간 지나봐라 두 배, 세 배는 꿈도 꾸지마라. 회사는 늘 어렵고 심지어 시간이 지날 수록 연봉이 줄어들 수도 있다)" 그리고 마지막으로 아주아주 중요한 법칙이 바로 "일은 처리하는 속도보다 쌓이는 속도가 훨씬 빠르다"입니다.

그게 가장 큰 핵심 포인트입니다!

출처: 덧글짤방 - Google 이미지

그것 참 희안한 일입니다. 아무리 바지런을 떨어도 도무지 이놈의 일은 추리해 내는 것보다 쌓이는 게 점점 더 많아지니 말입니다.

돈이 이렇게 쓰는 속도보다 쌓이는 속도가 훨씬 빠르다면 차암 행복하겠지만, 현실에선 희안하게도 일만 죽어라 쌓입니다.

이건 소프트웨어 개발에서도 예외가 아닌데요.

소프트웨어의 개발 생산성을 높이기 위해 필요한 주요 포인트들을 다룬 기고 내용이 있어 옮겨봅니다.

이 글을 읽는 분이 개발자가 아니라면 또 나름 자신의 상황에 맞춰 이해하시면 업무를 효과적으로 처리하는데 도움이 될 듯합니다.


생산성 높은 소프트웨어 개발

제조업의 경우 생산 현장의 생산성을 높이기 위해 인력을 추가하고 생산시설을 확충하면 그 만큼의 생산성은 향상된다. 그러나 소프트웨어 개발에서는 개발 지연이 되어 개발자를 더 투입하면 개발 일정이 더 길어져 소프트웨어 인력 충원에 따른 생산성 향상을 기대하기 힘들다. 그 이유는 결과물인 소프트웨어는 개발자의 지적 활동이 많은 부분을 차지하기 때문이다. 그러므로 프로세스를 통해 통제해 보려고 하지만 쉽게 통제되지 않는다. 생산성 향상을 위해 통제가 아닌 소프트웨어 개발에 필요한 몇 가지 중요한 점을 이야기해 보고자 한다.

김성 sung21.kim@samsung.com|삼성소프트웨어멤버십 회원으로 활동한 바 있고, 현재는 삼성전자에서 근무하고 있다.  Enterprise Architecture 개발과 관련된 실무 경험을 갖고 있으며 소프트웨어 공학 분야에 관심이 많다.

팀을 만들 때 자신의 의견을 강하게 주장하는 유능한 팀원으로만 구성된 팀과 유능하지는 않지만 경청하고 소통하는 팀원만으로 구성된 팀 중 어느 팀이 프로젝트를 성공할 확률이 높을까?

의사소통

정답은 후자이다. 전자의 경우 팀원 개개인의 능력은 우수하지만 서로 자신의 의견을 굽히지 않고 협업하지 않아 팀원 간의 불협화음이 일어나고 결국 의사소통 단절로 이어진다.

자신들의 의견이 의사결정에 반영될 수 있도록 자신의 목소리를 높이다 보니 의사결정이 되지 않고 계속 지연되는 일이 발생하고 의사 결정에 자신의 의견이 반영되지 않으면 팀에 대한 부정적인 입장으로 프로젝트에 참여하게 된다.

후자의 경우는 문제에 대해 서로 협의하고 해결점을 찾는 과정에서 의사결정이 이뤄지며, 이 과정에서 서로의 신뢰와 업무능력 향상이 함께 이뤄진다.

서로의 의견에 대해 계속적인 피드백을 서로에게 주며 모든 팀원이 공감하고 합의하는 결과에 도달해 서로간의 관계는 더욱 두터워져 의사소통이 원활하게 이뤄진다.

그러므로 결과에 대해 누구도 불만을 품지 않으며 모두 적극적인 자세로 프로젝트에 임하게 된다. 이처럼 프로젝트의 성패는 개개인의 능력이 아니라 원활한 의사소통을 통한 협업에 있음을 기억해야 한다.

정확한 의사소통이 이뤄지지 않으면 Integration되는 소프트웨어의 많은 부분에서 오류가 발생하고 이를 해결하기 위해 많은 시간이 소요된다.

이는 다시 말해 의사소통의 중요성을 의미하지만 다른 각도에서 생각해보면 의사소통에 어려움 있다는 의미다.

의사소통의 어려움을 줄이기 위해 최대한 개발하는 모듈에 대한 연관성을 줄인다면 생산성을 더 높일 수 있을 것이다.

소프트웨어 설계 시 Feature 단위의 정의로 소프트웨어 모듈간의 의존성을 낮추고 계층구조의 소프트웨어를 만들어 최소한의 인터페이스 규약만을 정확히 정의한다면 의사소통의 불협화음을 최소화할 수 있을 것이다.

코드 리뷰

Pair 프로그래밍을 해본 경험이 있는가?

Pair 프로그래밍은 하나의 모니터 앞에 두 사람이 앉아 한 사람은 코드를 작성하고 한 사람은 코드를 보면서 함께 고민하는 방식으로 이뤄진다.

장기에서 훈수를 할 때 장기판의 말이 잘 보이는 것과 같이 코드를 지켜보는 사람은 코딩하는 사람의 오류를 잘 찾아낼 수 있다는 장점이 있고 자동적으로 백업된다.

그래서 처음에는 두 사람이 하나의 작업을 같이 하므로 생산성이 떨어지는 것 같이 느끼지만 품질 향상을 통해 프로젝트 후반부에서는 생산성이 좋아진다.

그러나 효율적인 Pair 프로그래밍을 하기 위해서는 몇 가지 조건이 만족되어야 한다.

첫째, 작업을 함께 할 수 있는 시간적, 환경적 배려가 필요하다.

개발자는 현재 프로젝트의 개발만을 하지 않는다.

자신에게 할당된 여러 가지 업무가 있으며, 그 업무를 모두 처리하기 위해 자신만의 스케줄로 업무를 진행해 나간다. 개인이 맡은 업무가 서로 상이하고 공통된 업무의 범위가 작으면 서로 만날 수 있는 시간조차 없다.

그리고 좁은 작업 공간에서 그리고 작은 모니터에서 두 사람이 앉아서 개발하는 것도 함께 개발하는 것을 힘들게 한다.

미국 유타대에서 문서 편집 등의 작업을 할 때 모니터 크기가 바뀌면 생산성이 어떻게 달라지는지 측정하는 연구를 했다.

24인치 모니터를 쓰는 사람이 18인치 모니터를 쓰는 사람보다 52% 빠르게 작업을 끝마쳤고, 20인치 듀얼 모니터를 쓰는 사람이 18인치 모니터 한 개만을 쓰는 사람보다 44% 빠르게 업무를 끝냈다고 한다.

이러한 연구 결과와 같이 개발환경 문제는 생산성에 영향을 주므로 생산성을 높일 수 있는 환경을 마련하는 것 또한 중요한 일중의 하나이다.

둘째, 서로 친해야 한다. 개발자는 자신의 코드에 대해 제3자가 비판하는 것을 아주 싫어한다.

그러므로 함께 일하는 사람이 친해서 소스 코드의 잘못된 점 등을 부담 없이 이야기할 수 있고 받아들일 수 있어야 한다.

그렇지 않아도 보기 싫은데 같이 앉아서 작업하라고 한다면 서로 입을 다물고 아무런 대화가 없어 함께 작업하는 의미가 사라진다.

셋째, 개인의 능력 차를 고려해야 한다.

개인의 능력 차가 너무 많이 나면 능력이 낮은 사람은 무조건 배우는 자세로 임하게 되고 어떠한 지적이나 조언을 할 수 없게 된다.

넷째, 개발 인력이 충분해야 한다. 프로젝트가 작아 개발자가 한 두 명이 개발하는 소프트웨어도 많다. 그럴 경우는 Pair 프로그램이 불가능하다.

이러한 제약사항들이 있으니 현 상황을 잘 파악해 적용 유무를 결정해야 한다.

서로 백업되고 소프트웨어 품질을 향상시켜 생산성을 높인다는 목적을 달성하기 위해서는 코드 리뷰도 좋은 방법이다.

코드 리뷰를 통해 서로의 코드를 공유하고 선임자에 의해 코드의 잘못된 부분의 지적과 조언을 할 수 있어 소프트웨어 품질을 향상시킬 수 있다.

또한 다 작성된 코드로 코드 리뷰하는 것은 시간적으로도 많이 절약된다.

또한 혼자 개발하는 경우에도 자신이 작성한 코드를 직접 리뷰하는 방법으로 진행할 수 있으며 이 방법으로 자신이 작성한 코드의 오류를 미리 발견해 수정하는 것이 가능하다.

상황이 여의치 않아 Pair 프로그래밍을 할 수 없더라도 코드 리뷰를 한다면 충분히 생산성 향상을 가져올 수 있다.

교육

수행 능력은 개인에 따라 3배에서 10배까지 차이가 날 수 있다고 하듯이 소프트웨어 개발에서의 개인 생산성은 많은 차이를 보이고 있다.

그러나 이러한 수행능력을 판단하기가 어렵다는 게 문제이다.

그 결과, 정확한 수행능력치를 기준으로 일정에 반영하기가 어렵다.  

똑같은 일을 A라는 사람은 1시간 만에 해결하는데 반해 B라는 사람은 5시간이 걸려야 처리할 수 있다.

그렇다고 해서 A라는 사람이 무조건 수행능력이 낮다고 할 수는 없다.

각 사람마다 잘하는 분야가 있기 때문에 다른 일에 대해서는 더 나은 성과를 보일 수 있기 때문이다.

이러한 개개인의 능력을 잘 파악하고 적재적소에 인력을 잘 할당하는 것은 개인의 생산성을 최대한 높일 수 있는 방법이다.

그러기 위해서 개인의 능력을 향상시키기 위한 교육이 지속적으로 이뤄져서 교육을 통해 얻은 지식을 업무에 활용해 더욱 높은 성과를 얻도록 해야 한다.

그러나 교육도 무조건 진행하는 것이 아니라 개인마다의 업무에 필요한 전문 분야를 선택하도록 하고 전문 분야에 대한 지속적인 교육과 업무를 통해 전문가로 양성해 가야 한다.

방향 없는 교육은 단순히 자신의 지식을 늘릴 뿐 업무에 도움은 되지 않으며 시간이 지나면 모두 잊어버리게 된다.

업무의 테두리 안에서 전문 분야를 선정하고 전문 분야의 담당자에 대한 지속적인 교육이 이뤄질 때 개발자에 대한 생산성 향상으로 개발자와 기업 모두가 윈-윈 할 수 있다.

리더의 자세

팀을 이끌기 위해서는 리더의 역할이 무엇보다도 중요하다.

팀의 리더는 조직 구성원의 능력을 최대한 끌어 낼 수 있어야 한다.

지시나 통제가 아닌 조언하고 지원하는 자세로 팀을 이끌어야 한다.

지식사회가 되면서 이제는 수직적인 조직에서 수평적인 조직으로 되어가고 있다.

이는 업무가 전문화되어 감에 따라 업무담당자가 맡은 일에 대해 가장 많이 알고 잘 할 수 있기 때문이다.

이는 점점 지시와 통제를 통해 조직을 이끌어 가기 힘들다는 뜻이 된다.

이제 진정한 리더는 지시와 통제로 팀을 이끄는 것이 아니라 mento와 Supporter로서 조언하고 지원하는 자세로 바뀌어야 할 것이다.

그러나 아직 수직적인 조직체계 뿐만 아니라 강한 리더십을 위해 더욱 강한 지시와 통제를 가하는 경향이 있고, 그렇다고 개발자가 쉽게 지시와 통제에 따르지도 않는다.

그러므로 개발자에게 책임과 권한을 적절하게 부여함으로써 개발자의 주인의식을 높여 능동적 자세를 이끌어 내는 것이 더 중요하다.

또한 리더는 비전 제시자가 되어야 한다. 무조건 ‘나를 따르라’는 시대는 지났다.

팀원에게 정확한 비전을 제시하고 비전을 공유해 그 비전이 팀원 개개인에 맞을 수 있도록 조정하며 비전을 향해 한 방향으로 힘이 결집될 수 있도록 해야 할 것이다.

비전을 공유하고, 비전을 바라보고, 팀이 한 방향으로 한 몸같이 움직일 때 진정한 팀의 파워가 생겨나게 된다.

또한 중요한 것 중의 하나는 경청이다. 담당자는 해당 업무에 관해 많은 고민을 하고 시행착오를 겪으면서 많은 것을 경험하며 현장의 소리를 가장 가까이에서 들을 수 있다.

그래서 그 의견은 보석보다도 더 귀히 여겨져야 하지만 의사결정자는 자신의 의견과 맞지 않을 때 바로 무시하게 된다.

반복적으로 의견이 무시되면 팀원은 수동적인 태도로 바뀌게 되고, 결국에는 개선과 혁신에 대한 생각도 행동도 하지 않게 된다.

팀원이 마음껏 생각하고 마음껏 뛰어 놀 수 있게 만들어 주는 것이 진정한 리더의 임무가 아닐까 생각해 본다.

재사용

소프트웨어의 생산성과 품질을 향상시키기 위해 모듈화, 유연하고 확장 가능한 구조로 개발하려는 노력이 계속되어 왔으며, 최근에는 소프트웨어 재사용을 위한 노력 또한 활발하게 진행되고 있다.

소프트웨어 재사용은 최종 산출물에 대한 재사용이므로 요구사항 분석에서부터 테스트에 이르기까지 모든 결과물에 대한 재사용을 의미한다.

모든 결과물에 대한 재사용은 생산성 및 품질 향상에 많은 영향을 미치게 된다. 재사용 가능 컴포넌트와 변경 가능 컴포넌트를 분류해 설계하고, 아울러 추가나 수정에 의해 최소한의 영향만을 받도록 컴포넌트를 설계해야 한다.

보통 재사용을 위해 자신이 필요한 소스 코드를 이른바 ‘Copy & Paste’해서 다시 사용하는데, 이를 재사용이라고 보기에는 무리가 있다.

‘Copy & Paste’는 단순 일부 소스만을 재사용할 뿐이고 추가되는 소스에 맞게 수정이 이뤄지는 경우가 많다. 그러므로 요구사항 분석부터 테스트에 이르는 모든 결과물에 대한 재사용이 될 수 없다.

소프트웨어에서 공통적으로 많이 사용되는 부분이 재사용되는 대상이 된다.

그러므로 재사용하기 위해 모듈화하게 되는데, 모듈화는 공통적으로 사용하는 모듈과 시스템에 가변적으로 사용하는 부분으로 나눠 정의해야 한다.

공통적으로 사용하는 모듈의 경우는 사용자의 요구사항 변화에 많은 영향을 받지 않으므로 재사용 대상으로 선정해 모듈화하고 재사용할 수 있도록 한다.

데이터를 송신하고 수신하는 기능을 재사용하겠다고 해서 Sender와 Receiver 모듈을 재사용한다면 Sender와 Receiver는 다른 모듈과의 의존성을 가질 수 있으며, 이에 대한 정보를 알아야 사용이 가능하게 된다.

따라서 이러한 의존성이 관리되어야 하므로 오픈되어야 한다. 그러나 이를 하나의 프레임워크 단위로 만들고 재사용한다면 이러한 의존성을 사용하는 측에서는 고려할 필요가 없으므로 더욱 추상화시킬 수 있다.

모듈화된 컴포넌트를 다른 연동 시스템에서 사용한다면 소프트웨어 재사용으로 인해 개발시간을 단축시킬 뿐만 아니라 재사용하는 코드는 재사용 컴포넌트가 갖는 품질의 수준을 그대로 얻을 수 있게 된다.

소프트웨어 재사용은 소프트웨어를 조립 가능하게 하는 것이다. 메인 프레임워크를 만들고 메인 프레임워크에 추가되는 기능을 소스의 수정 없이 플러그인 형태로 꼽아서 쓸 수 있도록 설계되고 개발되어야 한다. 메일 프레임워크에 기능이 추가될 때마다 기능 단위 모듈을 꼽아 Integration되어야 하는데, Integration은 configuration file 내에 명령과 호출되어야 할 컴포넌트의 매핑을 통해 가능하다.

재사용되는 모듈은 내부 또는 외부에서 활용 가능하므로 재사용 모듈에 대한 정확한 설명과 인터페이스 정의가 필요하며 이에 대한 매뉴얼이 필요하다. 재사용 모듈을 효율적으로 관리하기 위해서는 모든 구성원이 공유할 수 있는 저장소를 만들어 재사용 모듈에 대한 정보와 함께 관리하고 쉽게 검색해 사용할 수 있도록 하는 것 또한 중요하다

Complexity

소프트웨어 복잡성(Complexity)을 갖게 하는 것에는 무엇이 있을까?

Complexity는 다양한 각도에서 생각해 볼 수 있다. 소프트웨어의 복잡성이 높아지면 개발 단계뿐만 아니라 유지보수 단계에서 많은 비효율성을 갖게 된다. 소프트웨어 복잡성을 높이는 이유로 다음 몇 가지를 들 수 있다.

첫째, 조건문의 증가이다. 조건에 따른 서로 다른 처리를 위해 조건문을 사용한다.

처음에는 한 두가지 조건에서 시작한다. 그러나 시간이 갈수록 기능이 추가되고, 그에 따른 조건문도 추가된다.

조건의 항목이 추가되면서 계속적으로 추가하다 보면 어느새 조건문이 많아진다.  이는 소프트웨어의 복잡성을 높이는 것이며, 이로 인해 시스템의 성능을 떨어뜨리는 원인이 된다.

계속해서 추가할 수밖에 없다고 생각할 수 있지만 이는 분명 여러 개의 조건문으로 분리할 수 있다.

불필요한 조건문을 최소화하고 분리해 간단한 구조를 만들어야 한다.

한 클래스 안에 수많은 조건문의 반복을 없애야 한다. 하나의 모듈 내에 조건문이 많다는 것은 모듈 안에 서로 분리 가능한 기능이 함께 있을 가능성이 높다는 것이고, 이는 기능 분리를 통해 모듈로 분리한다면 자연스럽게 조건문이 분리된다.

소프트웨어 개발 중 반복적인 추가와 변경을 통해 모듈이 비대해지고 복잡해지면서 여러 기능이 혼합되고 추가되어 조건문이 많아지고 복잡해진다. 기능별 모듈을 적정하게 분리해 가면서 추가해 나간다면 소프트웨어 복잡성이 높아지는 일은 미리 막을 수 있다.

둘째, depth의 증가 및 역 참조 구조이다.

오래전 소프트웨어 개발 시 한 시대를 풍미했던 GOTO 문을 기억하는가?

GOTO 문의 편리함으로 많이 사용되었지만 GOTO 문의 사용이 많을 경우 호출이 복잡해져서 소스의 복잡성이 가중된다는 큰 단점이 있었으며, 이로 인해 GOTO 문은 사라진 지 오래이다.

소프트웨어의 소스 코드는 프레임워크에서 지원하는 함수와 개발자 자신이 필요에 의해 만든 수많은 함수를 호출하는 코드로 이뤄져 있다.

소프트웨어의 call depth가 증가한다는 것은 호출된 함수에서 또 다시 다른 함수로, 그리고 또 다시 다른 함수로 계속적으로 호출하는 것을 의미한다.

이러한 복잡한 호출은 GOTO 문을 쓰는 것과 다를 바 없다. 소스 코드 분석을 위해 추적해 보면 느끼겠지만 이렇게 되면 상당히 복잡하고 소스를 읽기 어렵게 된다.

또한 단위 테스트 시에도 오류가 어느 지점에서 발생했는지 확인하기 어려우며, 확인을 위해서는 호출되는 마지막 함수부터 추적해야만 문제를 찾을 수 있게 된다. 이렇듯 call depth의 증가는 소스를 복잡하게 해 읽기 어렵게 할 뿐만 아니라 테스트 코드를 만들기 힘들며 디버깅도 힘들게 한다.

소프트웨어 계층별로 Layer를 나누어 개발하는 Layered Architecture는 계층 간의 의존성을 최소화해 변경에 유연하게 대응하고자 하는 목적이 있다. 계층에서의 참조는 같은 계층 간 또는 하위 계층으로의 참조로만 이뤄져야 한다. I3에서 M2를 참조하는 것과 같이 하위 계층에서 상위 계층으로의 역참조가 일어나서는 안 된다. I2에서 I3으로 같은 계층에서의 참조는 문제가 되지 않는다.

상위 계층으로 갈수록 추가 및 변경이 자주 일어나며 하위 계층은 다른 모듈에 의해 여러 참조를 갖기 때문이다. 역참조가 일어날 경우 상위 계층이 바뀌면 역 참조를 한 하위 계층이 바뀌게 되며 이를 참조한 다른 계층의 모듈까지 연쇄적으로 변경되어야 한다. 이는 유연성을 떨어뜨리며 복잡성을 가중시킨다.

셋째, Unused 코드 증가이다. 개발된 코드를 받고 분석했던 경험이 다 있을 것이다. 코드를 보다 보면 이걸 사용하는지 사용하지 않는지 모를 때가 많다. 심지어는 자신이 작성한 코드 또한 사용하는지 사용하지 않는지 모를 때가 많다. 코드를 한참 따라가며 분석하다 보면 어느 순간 사용하지 않는 코드임을 알게 된다. 그래서 사용하지 않는 소스로 인해 많은 복잡함을 느낄 수 있다. 개발하면서 사용하지 않는 코드가 있더라고 왠지 지우면 무슨 일이 벌어질 것 같고, 다음에 또 사용할 수도 있을 것 같으며 ‘굳이 지울 필요가 있을까’라는 이유로 사용하지 않는 코드를 그대로 방치하게 된다. 이렇게 사용하지 않는 코드는 레거시 코드를 분석하다 보면 상당히 많은 것을 확인할 수 있다. 사용하지 않는 코드를 방치해 소프트웨어의 복잡성을 높이지 말고 사용하지 않는 코드는 과감히 삭제한다든지 전체를 주석 처리해 사용하지 않는다는 것을 확실히 표시함으로써 소프트웨어 복잡성을 낮출 수 있다. 코드 분석 툴을 사용해 사용하지 않는 코드를 주기적으로 분석하고 관리해 Unused 코드의 비율을 낮추어야 한다.

넷째, 소스의 크기와 소스간의 의존성이다. 소스의 크기가 작을수록 단순해 보일 뿐 아니라 유연성이 높고 변경하기 쉬워진다. 소스의 크기가 크면 복잡해 보이는 것이 사실이다. 그러나 소스 크기만을 가지고 복잡성이 높고 낮음을 얘기할 수는 없다. 소스의 크기가 작더라도 소스간의 의존성이 높다면 하나의 기능을 추가하거나 변경하는 것이 여러 개의 소스에 걸쳐 영향을 주어 추적해가며 수정이나 변경이 이뤄진다. 그리고 패키징과 릴리즈하는 컴포넌트의 수가 많아져 이 또한 복잡성을 가중시키게 된다. 소스의 크기가 크더라도 의존성을 갖지 않고 내부적으로 잘 분리되어 있다면 수정이나 변경이 용이할 수 있고 패키징과 릴리즈를 할 때 하나의 컴포넌트만 하면 되므로 복잡성이 줄어들게 된다. 소스 크기를 무조건 줄이려고 하는 것이 아니라 소스간의 의존성을 최대한 줄이면서 소스의 크기를 줄여나갈 때 복잡성을 낮출 수 있게 된다.

다섯째, 예상하지 않은 코드의 증가이다. 예상하지 않은 기능의 추가와 예상하지 않은 기능의 변경은 기존 설계 및 구현된 소스에 변경을 가져온다. 예상치 않은 요구사항을 반영하기 위해 소프트웨어 변경이 불가피하게 되고, 이러한 상황에서는 일정 또한 급박하게 돌아간다.  그렇게 되면 다급해진 개발자는 기존 소스에 끼워 넣기 식으로 개발을 진행하게 된다.  Feature별로 구분해 개발했는데 적합한 Feature도 없으니 아무 것이나 적당한 Feature를 선택해 추가하기 시작한다. 이렇게 추가된 소스는 기존의 잘 정리된 소스를 복잡하게 만들게 된다. 소프트웨어를 설계하는 데 있어서 모듈을 나누고 소프트웨어 의존성을 낮추는 등의 설계는 변화에 유연하게 대응할 수 있어 수정 시 드는 비용을 낮추기 위한 방안이지 실제적으로 변화에 대응하기 위한 방법은 아니다. 변화에 대응하기 위해서는 요구사항의 변화 시 소프트웨어 수정의 최소화에 초점이 맞춰져야 하고 변경 가능성 있는 부분을 미리 고려해 소스 수정을 최소화하면서 확장 가능해야 한다.

그럼 소프트웨어 변경 유형에는 무엇이 있을까? 기능의 추가, 기능의 삭제, 기능의 변경, 설계 미흡이 있는데, 기능의 추가나 삭제는 기존의 소스 구조의 변경 없이 가능하지만 기능의 변경은 많은 문제를 유발한다. 그리고 기능의 추가가 독립된 기능 추가가 아닌 기존의 기능에 더해지는 경우에 문제가 될 수 있다.

기능의 변경과 기존 기능에 기능이 더해지는 경우의 예는 처리 로직의 Rule을 변경하는 것에서 많이 찾아볼 수 있다. 이러한 Rule의 변화가 소프트웨어 변경의 원인이 되므로 요구사항 분석 및 설계 시점에 Rule에 대한 정확한 정의가 필요하고 Rule의 변경이 발생하더라도 쉽게 소스 코드를 변경하거나 변경을 수용할 수 있는 구조로 만들어야 한다. 그럼 Rule의 변경은 왜 발생하는 것일까? Rule은 요구사항으로부터 나오고 요구사항으로부터 변경되는 만큼 요구사항 분석 시 충분한 리뷰를 통해 요구사항이 정확하게 반영된 Rule을 정의하고 이해당사자 모두와 공유해야 한다.

참고자료
1. Addison Wesley, UML Distilled Third Edition, 2003
2. Addison Wesley, Designing Software Product Lines With UML, 2004
3. WILEY, Architecting Enterprise Solutions, 2004
4. 영진닷컴, 객체지향 CBD 개발 방법론, 2004
5. 위키북스, 똑똑하고 100배 일 잘하는 개발자 모시기, 2007
6. 인사이트, 익스트림 프로그래밍 2판, 2006

신고




     개발, 개발자, 노하우, 방법론, 블로그, 생산성, 소프트웨어
     1   0

아이디 
비밀번호 
홈페이지 
비밀글   

 

 

큰물에서 놀고 싶은 개발자를 위한, 해외 진출 방법론
+   [마이크로소프트웨어]   |  2010.01.14 11:27  


대한민국 개발자들의 우수성을 의심하는 사람은 없습니다(최소한 지금까지 제가 만난 사람들은 그렇습니다). 그럼에도 불구하고 한국 개발자들의 처우나 근무 환경은 척박하기 그지없는데요. 이런 탓에 더 큰 세상으로의 진출을 꿈꾸는 개발자들이 점차 늘고 있는 듯합니다. 월간 마이크로소프트웨어에 기고된 다음 글이 이런 분들께 도움이 될 수 있을 듯하여 옮겨봅니다.

필자는 2000년에 미국으로 건너가 소프트웨어 개발자로 일하고 있는데요.

미국 기업에 인도 개발자는 많은데 왜 뛰어난 한국 개발자들은 찾아보기 힘들까란 의문을 품고

자기 나름의 원인을 분석하여 기고하게 되었다고합니다.

좋은 원고를 제공해 주신 김정 님께 다시 한번 감사드립니다.

마이크로소프트웨어 홈페이지( www.imaso.c.kr )에 오시면 개발자에게 필요한 다양하고 유익한 정보를 얻을 수 있습니다.


한국 개발자의 해외진출을 위한 방법론

필자는 현 직장에 오기 전, 1년반 정도 인도계 회사에서 근무한 바 있고, 이직을 생각하고 수락한 인터뷰는 아니지만, 최근 인도계 회사에서 인터뷰 제의를 받은 바 있다. 미국의 여러회사를 경험하면서 ‘미국에 상주하는 인도개발자의 수는 많지만, 정작 우수한 우리나라 개발자는 왜 찾기가 쉽지 않을까?’ 라는 의구심이 들었고, 필자 나름대로의 원인을 분석해 보게 되었다. 필자가 생각하는 문제는 길을 찾기 쉽지 않다는 점과 먼저 개척해놓은 사람이 많지 않다는 것이었다.

김 정  jkim0121@gmail.com |포항공대를 졸업하고 2000년에 도미, 현재 UBS Investment Bank의 IT division에서 개발자로 근무중이다. Essex County College에서 adjunctfaculty member로 1,2학년 대상 전산과 과목을 강의중이다.

필자는 한국에서 평범한 4년제 대학을 졸업한 이후, 2000년 도미해 현재까지 개발자로 일하고 있다. 마소를 통해 이번 컬럼을 기고하게 된 이유는, 우리나라의 훌륭한 개발자들, 그들이 누릴 수 있는 근무환경이나 혜택을 누릴 기회를 간과하고 있지 않았는가 라는 생각에서다.

이민자 사회에서 우리나라 사람들을 찾는 것은 그리 어렵지 않은 일이다. 하지만 이들의 대부분은 자영업을 통해 정착한 경우이며, 우리나라 이민 1세대가 전문직에 진출하는 경우를 잘 찾지 못한 것이 현실이다. 이러한 현실에서 해외 진출의 계획을 갖고 있는 많은 우리나라 개발자들에게 간략하게 현지환경과 보편적인 방법론을 설명 하고싶어 이렇게 컬럼을 쓰게 되었다. 필자가 미국에서 정착해 살고 있는 만큼, 대부분의 설명이 미국의 경험을 바탕으로 이야기되는 것에 대해 독자들의 많은 이해 부탁드린다.

외국 기업의 직장생활은 어떠한가

 

사용자 삽입 이미지

외국의 직장생활은 굉장히 규칙적으로 이뤄지고 있다고 이해해도 무리가 없을 듯하다. 정시출근, 정시퇴근을 원칙으로 하는 회사가 대부분이며, 또한 자유 출퇴근을 한다고 하더라도 하루에 8시간 이상의 근무를 하는 경우는 굉장히 드문 경우다.

개발자들의 급여수준은 다른 직종에 비해 높은 편이다. 소수의 외국계 회사 (예를 들면 한국계 내지 인도, 중국계)들은 취업비자를 미끼로 낮은 임금과 초과근무를 자주 시키는 경우를 보았으나, 보편적인 미국회사들의 경우는 직원의 업무 외 시간에 대해서는 전혀 관여하지 않는다. 한국에서 흔히 있는 회식이나 음주문화는 매우 찾기 어렵다. 회식의 경우에는 1년에 두세번 하면 많은 편이며, 보통 연말을 이용한 회식자리가 마련되는 경우가 많다.

여가시간에는 주변의 대학원에 가서 공부를 하거나, 주말을 이용한 골프 등 기타 여가생활을 하는 것이 보편화 되어있다.

 

사용자 삽입 이미지

한국의 경우, 대부분의 샐러리맨들이 사원, 대리, 과장, 부장, 임원으로 대표되는 경력의 진행으로 인해 일정 연령이 되면 관리자가 되어야 하고, 또 정년이 되면 조직에서 타의에 의한 퇴출이 이뤄지는 환경임에 비해 미국이나 캐나다의 경우, 자신이 원한다면 은퇴할 때가지 계속 개발자의 길을 걸을 수 있다. 더불어 한국에서는 흔하지 않은 나이의 어린 관리자가 나이 많은 개발자를 관리하는 경우도 심심찮게 볼 수 있다.

특히 해외의 경우, 정년이라는 개념 자체가 없다는 것이 특징이다. 이는 나이에 따른 정년을 지정하는 것이 외국에서는 차별에 해당되기 때문이며, 자신의 능력이 된다면 일하고 싶을 때까지 일을 지속적으로 할 수 있다는 것이 특징이다.

사실 필자는 우리나라 직장의 급여체계가 어떻게 바뀌었는지는 잘 알지 못해 비교를 한다는 것이 쉽지는 않다. 하지만 굳이 비교를 하자면 해외기업의 급여체계는 한국에 비해 매우 단순하게 책정된다는 것 또한 특징이라고 할 수 있겠다. 급여의 수준은 타인과의 비교가 아닌, 오로지 자신의 능력과 조직에 대한 기여도에 의해 결정되며, 그 결정의 대부분은 자신의 직속 관리자가 하게 된다. 대부분의 관리자들은 부하직원의 업적을 평가하는데 있어서 객관적이라고 생각하며 또한 자신과 의 개인적인 친목관계는 배제한 평가를 진행하고 있다.

지난해와 금년같이 경제상황이 좋지 않은 경우에는 연봉의 인상을 기대할 수 없겠지만, 평소의 경우에는 보통 물가인상이 어느정도 되느냐에 따른 연봉인상을 기대할 수 있고, 능력이 뛰어난 개발자의 경우, 약 20%가량의 연봉인상을 해준 경우도 많이 보았다. 다시 말하면 자신의 연봉을 결정하는 요인을 자신의 능력일 것이며, 이에 대해 좋은 관리자는 플러스 요소로 작용할 수 있겠다.

최근 개발인력의 고용추세는 비용문제로 인해 외주형식으로 변화해 가고 있음에도 불구하고 개발자의 수요는 꾸준히 증가하고 있다. 개발자들이 취급하는 정보의 내용은 회사의 기밀에 해당하는 것들이나 비중이 높은 자료들이 많다. 때문에 기본적인 기능들의 구현은 외국(주로 인도에 외주를 주는 회사들이 많다)의 값싼 인력을 활용한다 하더라도 핵심기술에 대한 부분은 자국 내 개발자들을 고용하는 사례가 많다. 또한 하드웨어의 발전과 소프트웨어 신기술들의 지속적인 등장으로 인해 회사들은 최신기술을 사용해 사용하기 좋은 소프트웨어 제품을 개발하기를 원하며, 또한 기존 시스템의 경우에는 최신기술을 적용해 시스템 이전을 진행하는 등의 경우를 많이 볼 수 있었다. 이러한 최신기술의 경우에는 수요도 많을 뿐더러, 그에 상응하는 공급이 충분하지 않은 경우가 많은 것 또한 사실이다.

필자의 경우, 마이크로소프트의 기반기술을 사용한 개발을 진행하는 개발자 이다보니, 그 분야에 대해서만 알고 있는데, WPF나 .NET, F#의 경우에는 아직도 공급이 수요를 따라가지 못하고 있다. WPF나 F#의 공통점은 시장에 나온지 3~4년밖에 되지않은 신기술에 속하는 분야들이라는 점이다. 대부분 기존의 시스템을 이미 가지고 있는 경우가 많으므로 기존의 기술과 위에 열거한 기술들에 대한 경험을 모두 가지고 있는 개발자들은 훌륭한 대접을 받으며 취업을 할 수 있을 것이다.

다른 주목할만한 기술개발 분야는 스마트폰 개발 분야다. 한국에서도 그렇겠지만, 외국 또한 스마트폰의 인기는 대단하며 아이폰, 안드로이드, 그리고 윈도우모바일이 경쟁구도를 갖추고 있다. 이러한 점 때문에 스마트폰 플랫폼의 개발이 굉장히 특화된 만큼 공급 또한 부족한 것도 사실이다.

국내 개발자의 외국진출, 무엇이 문제인가

우리나라 개발자들이 외국인으로서 북미 직업시장에 진입하는데는 많은 장벽이 있는것이 사실이다. 그 중 핵심적인 것 몇가지만 나열하면 다음과 같다.

첫 번째는 누가 뭐라고 해도 언어의 문제다. 우리나라에서 수업시간에 배우는 영어로는 절대 살아남을 수 없다. 또한 시험준비를 위한 영어도 마찬가지다. 이들의 공통점은 실생활을 전혀 반영하지 않은 입시 및 기타 시험에서 고득점을 위한 방법론을 배우는 것이라는 점이다. 우리나라 사람들이 영어에 있어서 취약한 분야는 다들 알겠지만 말하기와 듣기 부분이다. 그렇다고 현지인들과 마찬가지로 말하는 것을 100% 이해할 만큼 이라거나, 현지인들과 마찬가지의 유창한 말하기 실력과 같은 고난도의 영어가 꼭 필요한 것인가 라는 점은 또 아니다.

개발자라는 직업은 영어를 가지고 문학을 한다거나, 혹은 고객을 상대로 영업을 하는 사람들이 아니다. 현지인들이 하는 만큼의 유창함을 발휘할 수 있으면 좋긴 하겠지만, 기술적인 내용을 다른 사람에게 표현할 정도의 능력을 가지고 있다면 충분하다고 생각한다. 우리나라 개발자들이 비영어권 출신의 타국 개발자들과 다르게 가진 언어에 대한 문제점을 찾는다면 자신감이 부족하다는 점을 꼽을 수 있겠다. 필자 또한 처음에는 그랬었지만, 틀리더라도 자신감을 가지고 말을 할 수 있는 자신감이 꼭 필요하다는 것을 강조하고 싶다.

두 번째 장벽은 인맥이 부족하다는 점이다. 필자가 크고 작은 회사에 인터뷰를 다니고, 혹은 일을 하면서 느낀 점은 인도 출신의 개발자들이 참 많다는 것이었다. 우리나라 사람들의 고학력 취업이민의 역사는 그리 길지가 않다. 그래서 우리나라 사람들을 이곳의 IT직종에서 쉽지 않다는 것은 수긍할 수 있는 문제이긴 하다. 하지만 그에 비해 인도 출신 개발자는 너무도 넘쳐나고 있다는 것이 현실이다. 필자가 보기에는 우리나라의 개발자들의 문제해결 능력이나 기타 프로그래밍 기술은 인도 개발자들에 비해 결코 떨어지지 않는다. 하지만 인도 개발자들은 이미 자신들의 인맥을 동원해 끊임없이 현지취업을 시도하고 있으며, 고용주 역시 자국민들을 자신이 있는 곳으로 불러들이기 위해 많은 노력을 하는 듯이 보인다. 또한 이곳에서 한국인들이 경영하거나, 혹은 관리자의 위치에서 일하는 기업이 몇군데 있지만, 그들은 한국의 인력에 대해서는 크게 관심을 가지지 않고 있는 듯하다는 점도 아쉬운 점이다.

그렇다고 해서 해외취업을 영원히 불가능한 꿈으로 여길 필요는 없다. 처음 진입하는 것이 어려운 것일 뿐, 한번 진입하면 다른 곳으로 뻗쳐 나가는 것은 그리 어려운 일이 아니기 때문이다.

인맥이나 헤드헌터를 잘 활용하는 다른 이유는, 실제 직원을 고용하는 사람(영어로는 Hiring Manager라고 한다)과 직접 접촉을 하거나, 혹은 인력부서의 담당자와 접촉을 할 수 있는 확률이 높아지기 때문이다. 한 회사의 인력부서에서 하루에 받는 이메일 이력서의 수는 엄청날 것이며, 사람의 능력으로는 이 많은 이력서들을 처음부터 끝까지 모두 읽어본다는 것은 시간과 비용의 낭비라는 점이다. 큰 기업의 경우, 자동검색 프로그램을 통해 특정 검색어를 가진 이력서만을 추출해 이력서를 검토하기도 하며, 소규모 기업의 경우에는 skillset만을 대충 훑어보는 것을 통해 이력서를 걸러내곤 한다. 이러한 고용 환경에서 인력부서에 직접 이력서를 건넬 수 있다는 환경을 가진다는 것은 첫 번째 관문을 쉽게 통과하는 것과 다를게 없어 유리할 것이며, 그리고 헤드헌터를 이용하는 데에 대한 비용은 통상 전액 고용하는 회사에서 부담하게 된다는 점이 장점으로 작용한다. 때문에 헤드헌터를 이용하는 데 있어서 전혀 부담을 느낄 필요가 없다는 것을 알려둔다.

 

사용자 삽입 이미지

대한민국 개발자의 외국기업 취업을 위한 전략

많은 장벽이 있다고 해서 아예 방법이 없는 것은 아니다. 물론 현지의 구직자들보다 쉽지 않겠지만, 뜻이 있다면 반드시 길이 있다는 것을 유념하길 바란다.
미국 내 기업의 100%는 최소 학사학위를 요구한다. 간혹 전산 비전공자가 학원 등을 거쳐 취업을 하는 경우가 있지만, 이러한 경우에도 역시 학사학위를 가진 경우에 한해서였다. 해외취업에 관심이 있지만, 자신이 학사학위가 없다면 어떤 방식을 사용하든 학위를 꼭 취득하는 것이 좋다.

외국인들은 우리나라의 대학 수준에 대해 잘 알지 못한다. 때문에 졸업하는 학교가 반드시 명문대일 필요도 없다. 하나의 방법을 제시한다면, 방송통신대에서 학사학위를 받는 것도 괜찮은 방법 중 하나라고 볼 수 있겠다.

석사학위 유학을 통해 취업을 하는 경우 또한 좋은 예가 되겠다. 북미의 예를 들자면, 공부에 뜻을 두지 않은 현지인들은 대부분 학사학위를 끝으로 진학을 하지 않는다. 때문에 대부분의 전산과 대학원의 학생들을 분석해보면, 유학생의 비율이 굉장히 높다는 것을 알 수 있다. 그러나 현지의 회사들은 현지의 경력이나 학력을 매우 중요하게 여긴다는 것을 유념하길 바란다. 미국의 경우, 미국회사의 경험을 매우 중요하게 인정하며, 캐나다의 경우 또한 역시 실질적으로 미국이나 캐나다에서 얻은 경력에 대해 실제 경력으로 인정하고 있다. 만약 직접 취업이 여의치 않다면 대학원에서 공부를 한 후, 취업을 하는 것도 좋은 방법 중 하나다. 실제로 인도와 중국 등지에서 온 많은 유학생들이 석사과정을 마치고 현지에서 취업하는 경우는 셀 수 없이 많다.

또 하나의 좋은 방법은 다국적 기업의 한국법인을 통한 현지진출이다. 한국에 상주하는 지사 내지 법인을 두고 있는 오라클, 마이크로소프트 등이 이에 해당되는 기업이라고 할 수 있겠다. 이 기업들은 통상 제품의 한글화를 위해 현지의 개발자를 활용하는데, 이러한 활동을 통해서 자연스럽게 본사직원관의 인맥을 쌓아갈 수 있다. 필자의 경우, 마이크로소프트 한국지사를 통해 미국 본사에 취업한 경우를 본 적이 있다.

외국 영화를 보다보면, 대사 중에 “You're Fired!"라는 표현을 간혹 보았을 것이다. 이를 직역하면 ”당신은 해고되었다“라는 표현인데, 필자 또한 이런 상황을 주위에서 좀 경험해 보았다. 미국 직장에서 일하게 된 지 2년쯤 되었을 때, 필자의 관리자가 필자의 옆자리로 가더니 거기에 앉아있는 사람에게 갑자기 ”Today is your last day here"라고 한마디 하고 가더니 그 다음주 월요일부터 그 직원이 보이지 않았던 경험이 있다. 관리자가 갑자기 나타나서 위의 이러한 한마디를 부하직원에게 던지는 순간, 부하직원의 ‘현’직장이 ‘전’직장이 되는 순간인 것이다.

미국의 고용관계는 매우 유연하다. 채용도 수시로 이뤄지고 있으며, 그와 마찬가지로 해고도 수시로 이뤄지고 있다고 보면 된다. 그렇다고 해서 해고에 대해 두려워할 필요는 없다. 회사의 입장에서는 새로운 사람을 뽑아서 어느정도 궤도에 올려서 일을 시키는데 많은 시간과 비용을 요구하기 때문에, 기존의 직원을 해고하는 경우는 근무태도에 심각한 문제가 있거나 회사 혹은 정부기관의 규정을 심각하게 어긴 경우(예를 들어 성희롱과 같은 경우), 혹은 경제적으로 심각한 문제가 있는 경우가 아니라면 해고를 시키는 경우는 많지 않다. 필자의 생각으로는 우리나라의 개발자들은 지금까지 해 온 대로 열심히 일한다면 위와같은 상황에 부딛칠 위험은 없다고 생각한다.

더불어 현지의 실정을 사전에 조사하는 것 또한 무엇보다 중요하다. 간혹 한국의 이민알선업체를 통해 취업비자를 받기로 하고 미국에 들어오거나, 혹은 미국의 회사에서 관광비자로 입국한 후, 현지에서 취업비자로의 전환을 약속하는 경우가 있다. 하지만 제대로된 미국기업의 경우, 이민알선업체를 농해 외국인을 고용하는 경우는 극히 드문 경우이고(그러한 경우가 있긴 하기에 아예 없다고 여기서 단정짓지는 못하겠다), 또 통상 이런 알선업체들은 높은 수수료를 중간에서 챙겨 잠적하거나 혹은 뒷일을 책임지지 않는 경우가 많다.

또한 현지의 외국인 취업 및 이민에 관한 법률을 무시해서는 안된다는 것을 말하고 싶다. 특히 이민에 관련된 법률은 외국인의 일상생활을 지배하는 전반이기 때문에 사소한 실수로 인해 합법적인 체류자격을 잃는 경우가 많이 발생하고는 한다. 전문 변호사에게 의뢰를 하는 것도 좋은 방법중 하나이지만, 변호사는 잘못된 결과에 대해 책임을 질 수 없다는 점을 잊지않길 바란다. 가장 현명한 방법은 자기 자신이 기본적인 법률을 이해하고 따르는 것임을 유념하길 바란다.

필자의 현지경험을 토대로 본 우리나라 개발자들은 정말 유능하다고 생각한다. 이 컬럼을 보는 모든 개발자들이 꿈을 가지고 도전한다면 반드시 길은 있을 것이며, 뜻하는 바를 모두 이뤄낼 수 있을 것이라고 생각한다. 다만 처음부터 쉬운 일은 없는 만큼, 부단한 노력이 필요할 것이며, 노력에 보상하는 댓가는 반드시 주어질 것이라는 것 또한 잊지않길 바란다.

참고자료
1. 미국 이민변호사 협회, www.aila.org
2. 위키백과, www.wikipedia.org
3. Salary.com, www.salary.com

필자 메모

미국 내 구인·구직 사이트 Monster - www.monster.com
Dice - www.dice.com
CareerBuilder - www.careerbuilder.com
HotJobs - www.hotjobs.com

취업정보 참고 사이트
US Citizenship and Immigration Services - www.uscis.gov
Citizenship and Immigration Canada - www.cic.gc.ca
한국 취업이민/단기취업자들의 모임 - www.workingus.com 

신고




     개발자, 마소, 마이크로소프트웨어, 소프트웨어, 해외취업, 호랭이
     0   0

아이디 
비밀번호 
홈페이지 
비밀글   

 

 

모바일에서 찾는 개발자의 미래
+   [마이크로소프트웨어]   |  2010.01.14 11:23  


요즘 아이폰과 안드로이드폰 등 다양한 스마트폰의 발표와 함께 개발자들의 크고작은 성공담을 듣는 일이 호랭이의 큰 기쁨 중에 하나입니다. 소프트웨어 개발자들의 열악한 처우와 개발자 등록제 등 우울한 이야기들로 가득하던 분위기에 그나마 작은 희망의 빛처럼 느껴지기도 합니다. 다음의 글은 월간 마소에 기고된 글인데요. 다소 윈도우 모바일에 치중된 내용이기는 하지만 큰 틀에서 보면 좋을 듯하여 옮겨봅니다.


개발자의 미래, 윈도우 폰과 마켓플레이스

요즘 커뮤니티나 트위터를 통해 알게 된 개발자들은 ‘국내 소프트웨어 산업이 붕괴될 만큼 침체되었다’고 하소연한다. 다소 극단적인 표현이긴 하지만 모 회사의 대규모 인원 감축으로 시작해 이제 더 이상 대학교의 컴퓨터 관련 학과에 학생들이 몰리지 않는다는 얘기도 쉽게 들려온다.

서진호 jinho.Seo@microsoft.com|한국마이크로소프트에서 모바일/임베디드 개발자 전도사로 일하고 있다. 서진호의 윈도우 폰 이야기(http://blogs.msdn.com/jinhoseo) 블로그와 윈도우폰 개발자 그룹(http://www.winmodev.net)에 참여하고 있다.

암울하게만 느껴지는 여러 상황 속에서 개발자들이 탈출구로 생각할 수 있는 것은 많지 않다. 그러한 의미에서 애플의 아이폰과 앱스토어는 국내뿐만 아니라 전 세계 개발자들의 가슴을 뛰게 하는 이슈라고 할 만하다. 마이크로소프트는 10월 7일, 전 세계에 30종의 윈도우 폰을 선보이며, ‘윈도우 마켓플레이스 포 모바일’ 이름으로 마켓 플레이스를 오픈하기 시작했다. 이번 글에서는 왜 수많은 개발자들이 이 마켓플레이스에 참여하고 있고, 이러한 마켓 플레이스에 참여하기 위해 어떤 것을 준비해야 하는지에 대해 알아본다.

왜 모바일 마켓플레이스인가?

앱스토어라고 불리기도 하고 마켓플레이스라고도 불리는 모바일 장터에 대해 알아보기에 앞서 일반 휴대폰과 스마트폰의 차이점에 대해 알아보자. 가장 큰 차이점은 PC나 웹으로 애플리케이션을 다운로드해서 직접 사용자가 설치할 수 있는가로 구분할 수 있다. 이런 것이 가능하다면 스마트폰이고 그렇지 않다면 일반 휴대폰이라고 보면 된다.

 

사용자 삽입 이미지

그렇다면 일반 휴대폰과 스마트폰 비율은 얼마나 될까? <그림 1>에서 보듯이 넬슨사가 조사한 바에 의하면 이번 2009년 3사분기에 스마트폰의 트래픽 점유율이 일반 휴대폰을 4% 앞섰다.

이렇게 된 원인으로 음성 중심의 일반 휴대폰에 비해 다양한 데이터와 인터넷을 자유롭게 활용할 수 있는 스마트폰의 장점을 들 수 있다. 뿐만 아니라 애플리케이션을 다운로드해서 사용할 수 있다는 사실도 큰 장점이다. 현재 애플 아이폰의 경우 10만 개 이상의 애플리케이션이 앱 스토어에 등록되어 있고, 전 세계에 1억만 번 이상이나 다운로드해서 대형 마켓플레이스로 자리 잡고 있다.

마이크로소프트 윈도우폰?

윈도우폰이란 윈도우 모바일 운영체제를 탑재한 모든 스마트폰을 말한다. 윈도우폰은 윈도우 모바일 6.5와 6.1 그리고 6.0 버전에서 동작한다. 현재 국내에서 유통되는 스마트폰의 약 99%가 윈도우 폰(T옴니아2 아몰레드, 다이아몬드폰, X1폰 등)이다.

윈도우폰이 발표되자 국내의 많은 기자들이 ‘윈도우폰을 마이크로소프트에서 직접 개발하는 것이냐’라는 질문을 했다. 그러나 공식적으로 마이크로소프트는 마우스/키보드나 XBOX360, Zune HD와 같이 특별한 경우가 아니면 장치를 만들지 않는다.

마이크로소프트는 하드웨어 보다는 소프트웨어가 훨씬 잠재적인 시장 가치를 지니고 있다고 생각하기 때문이다.

새로운 윈도우 모바일 6.5와 IE6 모바일

윈도우 모바일 6.5는 지난 2월 모바일 월드 콩그레이스(MWC) 회의 때 소개된 이후로 10월 7일 전 세계적으로 출시되었다. 국내의 경우에 윈도우 모바일 6.5가 탑재된 폰은 오즈 옴니아 아몰레드와 LG ‘라일라’라는 코드명을 사용한 폰이다. 참고로 T옴니아2 아몰레드와 SHOW 옴니아 아몰레드, 옴니아 팝 등은 윈도우 모바일 6.1 운영체제가 탑재되어 있다.

윈도우 모바일 6.5는 윈도우 모바일 6.0과 6.1 같은 윈도우 CE 5.0 운영체제 커널 기반에 개발된 윈도우 폰 운영체제지만 시스템 안쪽을 볼 때 폰 하드웨어 디자인이나 개발 비용을 축소시켰고 부팅 속도를 약 25% 정도 향상시켰다.

또한 똑같은 하드웨어 사양에서 이틀 정도 더 사용할 수 있도록 배터리 관리 장치 드라이버 아키텍처를 재설계했으며, 현재 윈도우 모바일 6.1 애플리케이션을 그대로 호환 가능하도록 했다. 사용자 입장에서 가장 눈에 띄는 점은 스타일러스로 조작하는 인터페이스에서 한 손으로 조작이 쉽게끔 개선되었다는 사실이다. 이른바 풀 터치의 제스처를 이용해 모바일 사용자 경험을 향상시켰고 이러한 점을 반영해 시작, 투데이 그리고 잠금 화면이 <화면 1>과 같이 변화되었다.

 

사용자 삽입 이미지

또한 윈도우 모바일 6.5에서 변화된 점 중 하나가 IE6 모바일이다. 그 동안 오픈소스의 웹킷에 기반을 두고 있는 경쟁사 스마트폰의 브라우저보다 기존의 윈도우 모바일 6.1에서 인터넷 익스플로러 모바일 버전은 기능이 떨어졌다. 그러나 이번 윈도우 모바일 6.5에 탑재된 IE6 모바일은 데스크톱 PC의 인터넷 익스플로러 7을 스마트 폰에 최적화시켜 놓은 버전이다.

특히, 모바일 브라우저를 풀 스크린으로 볼 수 있도록 지원하고 새로운 주소 바와 아이콘 바를 통해 즐겨찾기와 화면 확대와 축소를 통해 문서의 내용을 볼 수 있다. 또한 확대/축소를 연속적으로 사용자가 원하는 만큼 슬라이더를 통해 조작할 수 있다.

그 외에 돋보기 기능이나 가로/세로 화면이 자동으로 전환되는 기능, 한 손가락으로 위/아래로 스크롤링을 하는 팬 락킹 기능들을 제공함으로써 사용자 편의성을 높이기 위해 노력했다(화면 2> 참조).

 

사용자 삽입 이미지

어떻게 윈도우 모바일 마켓플레이스를 준비할까?

전통적으로 모바일/임베디드 개발자들은 하드웨어 이식성 때문에 C/C++ 언어를 선호한다. 그러나 마이크로소프트는 다양함을 추구하기 위해 C/C++ 언어 이외에도 C#과 VB.NET 언어를 .NET 콤팩트 프레임워크 기반 하에서 지원한다.

C# 언어는 가장 근래에 개발된 언어로서 관리형 환경(Managed Enviro nment)에서 메모리를 시스템이  관리해 줌으로써 메모리나 리소스 누수 현상을 막을 수 있다. 뿐만 아니라, 데스크톱 PC의 WPF나 웹의 실버라이트를 개발한 웹 개발자들도 모바일이나 임베디드 애플리케이션을 쉽게 만들 수 있다. 나아가서는 Zune HD나 XBOX와 같은 게임 개발도 C# 언어를 지원하고 있기 때문에 그 쓰임새가 다양해질 수 있는 것이 큰 장점이다.

이와 더불어 또 하나의 시너지를 낼 수 있는 것이 바로 개발에 편리한 비주얼 스튜디오라는 개발도구다. 개발자가 윈도우 모바일의 마켓플레이스를 준비하려면 애플리케이션 개발을 할 수 있는 개발도구와 SDK만 있으면 된다. 윈도우 모바일 6 SDK와 윈도우 모바일 6.5 DTK를 마이크로소프트에서 다운로드해 설치하면 된다. 주요 특징을 살펴보면 다음과 같다.

첫째, 윈도우 모바일 6 SDK에서 기본적으로 윈도우 폰 애플리케이션을 개발할 수 있는 6만여 가지 이상의 Windows CE API와 .NET 콤팩트 프레임워크를 이용한 C# 언어의 네임스페이스를 이용할 수 있도록 제공해 준다. 또한 모바일 이동성을 위한 2G/3G 모뎀 제어나 블루투스, WiFi, 카메라, GPS, 아웃룩의 SMS나 전자 메일 기능들을 개발할 수 있도록 네트워킹 및 분산 미들웨어 컴포넌트 등도 제공한다.

둘째, 윈도우 모바일 6.5 DTK는 실제 장치 없이도 애플리케이션을 개발할 수 있도록 장치 에뮬레이터와 스킨, 그리고 싱글 터치의 제스처 API를 제공한다. 그 뿐만 아니라 이번 윈도우 모바일 6.5부터는 모바일 위젯이라는 작고 가벼운 웹의 기능을 장치에서 구현할 수 있도록 도와준다.

 

사용자 삽입 이미지

이 위젯의 아키텍처는 <화면 3>에 잘 설명되어 있다. 데스크톱 PC에서 사용하던 웹 브라우저와 동일한 수준의 AJAX를 지원하며, 액티브X 컨트롤이나 플래시와 같은 플러그인 등을 지원한다. 또한 장치 데이터들은 샌드박스 위에 접근하므로 웹에서 발생한 문제들을 안전하게 지켜주며 시작 화면에 숏컷(Shortcut)으로 쉽게 실행할 수 있도록 지원한다.

셋째, 윈도우 모바일 SDK 이외에 옴니아 폰이나 HTC 다이아몬드 폰, 소니 에릭슨 X1 폰의 장치 특성을 살린 API들은 OEM 제조사들이 확장 SDK를 따로 배포하고 있다. 최근에 옴니아II 폰을 국내외에 출시한 삼성전자는 삼성 모바일 이노베이터를 통해 SDK 버전 2.0용을 발표했는데, G-Sensor와 같은 액셀러메이터, 옴니아용 카메라 및 카메라 플래시 제어, FM 라디오, 햅틱, LED 및 라이트 센서, 옵티컬 마우스, 오리엔테이션 및 나침반 지자기 센서, R2VS 사운드 및 슬라이드 등의 API가 업그레이드되어 지원하고 있다.

개발자들의 미래와 윈도우 모바일

최근에 윈도우 마켓플레이스 포 모바일(Windows Mobile for Mobile)은 업그레이드되었다. 그 동안 윈도우 모바일 6.5용 윈도우폰에서만 접속할 수 있었던 것이 데스크톱 PC를 통해 웹(http://marketplace.windowsphone.com)에서도 접속할 수 있도록 제공해 준다. 또한 윈도우 모바일 6.5뿐만 아니라 이제 윈도우 모바일 6.1과 6.0에서도 마켓플레이스를 <화면 4>와 같이 쓸 수 있도록 해준다.

 

사용자 삽입 이미지

10월 7일 오픈 이후 지금까지의 성적을 보면, 애플 아이폰의 앱스토어보다는 적지만 2개월 전보다 5배 증가한 수치로 1천 여 개 애플리케이션이 올라온 상태이고 ISV 소프트웨어 업체도 1천여 개 이상 참여하고 있다.

또한 Live ID를 가진 이용자들은 윈도우 마켓 플레이스를 바로 사용할 수 있는데, 현재까지 약 10만 명 이상이 윈도우 마켓 플레이스를 사용하고 있다. 또한 그 중에 현재까지 약 40만 번 이상 애플리케이션을 다운로드했다고 한다. 그렇다면 유료 애플리케이션의 구입 통계는 어떠할까? 40만 번 중에 30% 이상이 유료 애플리케이션을 구입했다는 통계가 나왔다. 이제 윈도우 모바일 6.1과 6.0 애플리케이션도 마켓 플레이스를 사용할 수 있는 만큼 애플리케이션 업로드 수는 더 증가할 것이다.

현재 국내에서는 무료 애플리케이션만 다운로드할 수 있으나 내년 초 쯤이면 유료화 결제를 제공할 예정이며, 국내뿐만 아니라 전세계 30개국 이상의 이용자들이 개발한 애플리케이션을 다운로드할 수 있다.

또한 사용자는 구입한 애플리케이션을 24시간 내에 환불할 수 있도록 제공해 준다. 반면에 개발자들은 애플리케이션 업로드를 위해 운영비 99달러를 내야 한다. 개발자의 수익은 판매액의 70%다. 또한 윈도우 마켓플레이스는 전 세계의 이통사 앱스토어와도 체결해 운영비의 30% 중 10%를 이통사에게 전달함으로써 개발자와 사용자에게 애플리케이션이 더 많이 다운로드될 수 있도록 해준다.

모바일 애플리케이션은 시시 때때로 업데이트에 민감할 때가 많다. 사용자가 업데이트를 자주 하지 않을 때를 고려해야 하는 탓이다. 따라서 이러한 배포 장벽을 철회할 수 있도록 해주는 역할도 마켓 플레이스가 담당한다.

아이디어 꿈을 펼치는 무대

작년에 이어 올해에도 로스앤젤레스에서는 ‘마이크로소프트 PDC 2009’ 컨퍼런스가 열렸다. 작년에는 모든 것을 서비스화하겠다면서 서비스 경험을 강조하는 비전의 포문을 열었다면 올해는 그것을 구체화시키는 행사로 마치 학술대회 토론회처럼 진행되었다.

모바일과 임베디드 같은 소규모 장치뿐만 아니라 클라이언트 PC에서의 가상화부터 클라우드까지 마이크로소프트는 토털 서비스 업체로 다시 한 번 거듭나려고 하고 있다. 이와 관련해 요즘 ‘3스크린’이니 ‘4스크린’이니 멀티스크린에 대응하는 많은 전략들이 흘러나오고 있다. 이는 마이크로소프트의 모바일 애플리케이션 전략과 일맥상통한다.

바로 투명하고 신뢰할 수 있는 애플리케이션을 기반으로 글로벌하게 소비자와 소비자가 직접 연결될 수 있도록 궁극의 모바일 애플리케이션 생태계를 생성하는 데 그 목적이 있다. 다시 말해, 모바일 소프트웨어 생태계에서 데스크톱 PC처럼 많은 애플리케이션이 탄생하며 개발자들이 비즈니스를 할 수 있도록 돕는 데 있다.

다시 원점으로 돌아가서 왜 개발자들이 윈도우 마켓 플레이스 포 모바일에 참여해야 하느냐고 묻는다면, 여러분들의 아이디어와 꿈을 펼칠 수 있는 무대이기 때문이라고 한마디로 대답할 수 있다. 또한 데스크톱 PC에서 보듯이 윈도우 마켓 플레이스 포 모바일은 스마트폰에서 가장 넓은 지역에 직판으로 판매할 수 있기 때문이다.


아이마소 홈페이지에 오시면 더욱 다양하고 유익한 정보들을 만나볼 수 있습니다.

>>> 아이마소 가기 <<<

신고




     개발자, 모바일, 소프트웨어, 아이폰, 앱스토어, 윈도우
     0   0

아이디 
비밀번호 
홈페이지 
비밀글   

 

 

실전 아이폰 게임 개발 준비하기
+   [마이크로소프트웨어]   |  2009.12.18 10:32  


드디어 한국에도 불기 시작한 아이폰 광풍은 개발자들의 관심을 끌기에도 충분합니다. 이에따라 주변 개발자들 중 전혀 다른 분야에 근무하던 분들까지 아이폰 개발에 관심을 가지거나 직접 아이폰 애플리케이션 개발을 시작하게 되는 경우들을 많이 접하게 되는데요. 그중에는 여러가지 시행 착오를 겪는 분들도 많습니다. 이번 글은 월간 마소에 실린 글 중 이창신 님이 쓰신 글이며, 아이폰 게임 개발을 하기 위해 알아두어야 할 내용들이 잘 정리되어 있습니다. 아이폰 게임 개발을 준비하는 분들께 도움이 되면 좋겠네요. 참고로 이창신 님은 월간 마소 연재를 통해 아이폰 게발과 관련된 노하우들을 독자들에게 제공할 예정입니다.

아이마소 : http://www.imaso.co.kr

최근 한 한국 개발팀이 만든 아이폰 게임이 앱스토어 상위에 올라 화제가 된 적이 있고 아이폰 애플리케이션의 여러 종류 중 가장 인기 있는 것은 단연 게임이기도 하다. 그동안 잘 된다는 말은 많이 들었지만, 막상 가까운 같은 나라에서 히트작이, 그것도 본업(회사원)이 있으면서 개발자와 디자이너 2명의 힘으로 일궈낸 성과라 많은 사람들에게 희망과 자극이 되지 않았나 싶다.

이창신 iasandcb@gmail.com, http://ias.myid.net|현재 아이폰 애플리케이션 개발에 몰두하고 있다.

그래서 막상 아이폰 게임 제작에 뛰어 들어보면 꽤나 난관이 많음을 알게 된다. 일단 개발과 관련된 것만 추려 보면 다음과 같다.

● 아이폰 애플리케이션 개발 기반 마련: 크게 두 가지 문제가 있다.
   - 하드웨어: 일단 맥 컴퓨터가 있어야 한다. 게다가 국내에 아이폰이 들어오지 않아 아이팟 터치를 대신 써야 하는데, 고환율 덕분에 맥과 아이팟 터치 둘 다 매우 비싸다.
   - 소프트웨어: 개발 환경이 매우 낯설다. 개발 언어도 무척 생소한 Objective-C이고, IDE도 Xcode를 쓴다. 이전부터 맥 애플리케이션 개발에 관심이 없었던 경우는 그야말로 ‘듣보잡’ 수준일 수도 있다.
● 아이폰 애플리케이션 개발 기본 습득: 전에는 우리말로 된 책조차도 없어 학습에 애로가 많았지만, 최근 입문 번역서가 나와 한숨 돌릴 수 있게 되었다.
● 아이폰 게임 개발에 필요한 기술 습득: 입문서에서는 자세히 다루지 않은 그래픽스와 사운드 처리 쪽을 더 파야 한다.

그리고 다음과 같은 배경을 가졌다면 앱스토어에 있는 높은 수준의 게임을 보며 갈 길이 먼 것을 깨달을 것이다.

● 전에 게임을 개발해 본 적이 (별로) 없다.
● (자바나 스크립트 언어 같은 환경에 비해) C 언어에 익숙하지 않다.

그러던 차, 게임에도 프레임워크가 있을 터, 우연히 발견하게 된 것이 바로 이 글을 통해 소개할 cocos2d iPhone(이하 cocos2d, 참고로 cocos2d는 파이썬으로 되어 있는 게임 엔진이고, 기본 개념을 따와 Objective-C로 응용해 아이폰에서도 쓸 수 있게 한 것이 cocos2d iPhone이다)이다. 이름에서 알 수 있듯이 이 게임 엔진은 2차원을 대상으로 하고 있다. 혹 3차원 게임 개발에 관심이 있는 독자는 SIO2(http://sio2interactive.com/HO ME/HOME.html)가 3D 엔진으로 cocos2d 격이므로 참고해 보길 바란다.

Hello cocos2d

cocos2d는 2D 게임을 위한 엔진이지만, 흥미롭게도 기반은 OpenGL, 즉 3D 기술이다. 이는 근본적으로 아이폰(아이팟 터치도 동일)에 PowerVR이라는 3D 가속 칩이 들어 있어 3D 처리가 무척 강력하기 때문에, 2D조차도 3D로(즉 3차원에서 한 차원 줄이면 되므로) 처리하는 방식인데, 3D 기능이 강력한 PC나 가정용 게임기에서도 쓰인다. 하지만 그렇게 cocos2d를 쓰기 위해 OpenGL을 알아야 필요는 없다. 되레 게임 개발을 쉽고 편하게 하기 위해 OpenGL과 같은 하부 기술은 상당히 감춰 놓았다. cocos2d의 또 하나의 장점은 코코아 스타일의 API이다. 객체 지향 프로그래밍에 익숙하다면 Objective-C의 기본 감각으로도 충분히 이해할 수 있는 구조여서 자바나 C#과 같은 플랫폼에서 작성하는 기분을 느낄 수 있다. cocos2d는 오픈소스 프로젝트로 http://code.google.com/p/ cocos2d-iphone/에서 진행되고 있으며, 2009년 3월 현재 0.7 버전이 릴리즈되어 있고 곧 0.8과 1.0을 출시할 계획이다.

흥미로운 것은 이 cocos2d 엔진을 만든 사람 자신도 이 엔진을 써서 Sapus Tongue이라는 게임을 만들었다는 사실이다. 엔진이 오픈소스에 무료라서 수익 모델이 없어 보이는데, 아직 관련 자료가 많지 않아 실제 게임 개발에 참고할 만한 예제가 충분치 않다.

cocos2d 준비

cocos2d를 배워보려고 하는 데 있어서 가장 큰 장애라면 역시 문서의 부족이다. 특히 공식 문서라 할 수 있는 프로젝트 문서가 거의 없다(이점은 Ricardo도 인정하고 있다). 그나마 있는 문서들은 많이 흩어져 있는데, cocos2d의 공식 블로그(http:// blog.sapusmedia.com/)에서 문서에 대한 안내 포스트(http:// blog.sapusmedia.com/2009/03/documentation-in-cocos2d. html)에도 가장 먼저 소개된 문서인 cocos2d whitepaper (http://monoclestudios.com/cocos2d_whitepaper.html, 이 문서는 cocos2d를 이용해 게임을 만드는 회사에서 작성한 것)를 참고로 cocos2d 준비를 설명해 보려 한다.
cocos2d는 일종의 라이브러리이므로 쉽게 가져다 쓸 수 있을 것 같지만, 실은 소스를 자신의 프로젝트에 넣어야 한다. 그래서 아예 cocos2d를 이용한 애플리케이션을 만들 때에는 다음과 같은 과정으로 프로젝트를 생성하고 설정해야 한다.

먼저 Xcode를 실행하여 File -> New Project를 선택한 다음, 오른쪽에서 Window-Based Application을 선택하고 Choose 버튼을 누른다. 프로젝트 이름은 HelloCocos2d라고 해보자.

cocos2d 통합

먼저 cocos2d를 받아 적당한 곳에 압축을 푼다. 그리고 앞으로 파일을 추가할 때는 Copy items into destination group’s folder (if needed)는 선택해도 좋지만 압축을 푼 파일의 사본이 프로젝트에 추가되는 것이므로 만약 cocos2d 코드를 한 곳에서 관리하고 싶다면 선택하지 않는 것도 방법이다.

첫 번째, HelloCocos2d 프로젝트로 돌아가 Project -> Add to Project...를 선택하여 cocos2d를 푼 디렉토리로 가서 그 밑의 external 디렉토리를 선택한다. 그러면 팝업 메뉴가 하나 뜨는데 Add 버튼을 누른다. 그러면 프로젝트 뷰의 왼쪽에 external이라는 그룹(폴더 모양)이 생긴 것을 볼 수 있는데, 이 그룹을 펼쳐서 Chipmunk 디렉토리 밑으로 Demo라는 디렉토리가 보이는데 이것을 지운다(지울 때, 위의 Copy items into destionation... 옵션을 선택했다면 Also Move to Trash, 아니면 Delete References를 선택한다).

두 번째, 또 다시 Project -> Add to Project를 선택하여 cocos2d를 푼 디렉토리 밑의 cocos2d 디렉토리를 선택한다(혼동하지 말도록. cocos2d를 푼 디렉토리를 선택하는 것이 아니라 그 밑의 cocos2d 디렉토리를 선택하는 것이다).

세 번째, 이번에는 프로젝트 뷰의 왼쪽 Groups & Files에서 Resources 그룹을 선택하여 컨텍스트 메뉴로 Add -> Existing Files...를 선택한 다음, cocos2d를 푼 디렉토리 밑의 Resources 아래의 Images 디렉토리에 있는 fps_images.png을 선택하여 추가한다.

마지막으로 네 번째, Groups & Files에 Frameworks라는 그룹이 있는데 이것을 선택하여 컨텍스트 메뉴로 Add -> Existing Frameworks...를 선택한 다음 OpenGLES.framework와 QuartzCore.framework을 선택하여 추가한다.

이로써 cocos2d를 사용하는 애플리케이션을 만들 준비가 다 되었다. 그럼 어떤 새로운 기술을 배우더라도 꼭 처음에 등장하는 예제인 ‘Hello World’를 바로 만들어 보자.

Hello cocos2d

<리스트 1>은 지금까지 작업한 결과로 생성되는 HelloCocos2 dAppDelegate.m 파일이다.


<리스트 1>  HelloCocos2dAppDelegate.m의 내용

    //
    //  HelloCocos2dAppDelegate.m
    //  HelloCocos2d
    //
    //  Created by Changshin Lee on 09. 03. 19.
    //  Copyright __MyCompanyName__ 2009. All rights reserved.
    //
    #import "HelloCocos2dAppDelegate.h"
    @implementation HelloCocos2dAppDelegate
    @synthesize window;

    - (void)applicationDidFinishLaunching:(UIApplication *)application {    
        // Override point for customization after application launch
        [window makeKeyAndVisible];
    }

    - (void)dealloc {
        [window release];
        [super dealloc];
    }
    @end


이 파일에 추가해야 할 것은 크게 세 가지다.

첫째, cocos2d를 쓰기 위해 #import “cocos2d.h”를 맨 위에 넣는다.
둘째, cocos2d 엔진의 초기화 코드를 // Override point for ... 부분에 넣는다.
셋째, Hello cocos2d를 출력하는 로직을 구현한다.

<리스트 2>의 코드는 앞서 언급한 세 가지 작업을 마친 것이다. 엔진 초기화는 간단히 주화면인 window를 Director 싱글턴([Director sharedDirector]의 반환값)에 붙이면(attachIn Window) 된다. 이후 코드는 아직 배우지 않은 것들이 많이 나와 생경하지만, 간단히 <그림 1>과 같은 흐름이라 할 수 있다.

 

사용자 삽입 이미지


<리스트 2> 세 가지 작업을 마친 결과

    //
    //  HelloCocos2dAppDelegate.m
    //  HelloCocos2d
    //
    //  Created by Changshin Lee on 09. 03. 19.
    //  Copyright __MyCompanyName__ 2009. All rights reserved.
    //

    #import "HelloCocos2dAppDelegate.h"
    #import "cocos2d.h"
    @implementation HelloCocos2dAppDelegate
    @synthesize window;

    - (void)applicationDidFinishLaunching:(UIApplication *)application {    
    [[Director sharedDirector] attachInWindow:window];   
    Scene *helloScene = [Scene node];
    Label *helloLabel = [Label labelWithString:@"Hello cocos2d" fontName:@"TrebuchetMS" fontSize:40.0f];
    helloLabel.position = cpv(150, 100);
    [helloScene add:helloLabel];
    [[Director sharedDirector] runWithScene:helloScene];
    [window makeKeyAndVisible];
    }

    - (void)dealloc {
        [window release];
        [super dealloc];
    }
    @end


cocos2d의 특징

가장 먼저 눈에 띄는 것은 아이폰 애플리케이션의 기본 구조인 Model-View-Controller의 표준 클래스인 UIView와 UIView Controller를 쓰지 않는 cocos2d 고유의 모델이다. 물론 기존 UIView·UIViewController와 같이 써도 되지만, 쓰지 않고도 완결된 애플리케이션 작성이 가능하다는 점이 독특하다. 그래서 아마 처음 이 모델을 보면 꽤나 적응이 안 될 수도 있는데, 자주 쓰게 되면 자연스럽게 차츰 적응이 된다(필자의 경험상).

또 하나는 좌표계다. UIView의 기본 좌표계는 왼쪽 위 모서리가 (0, 0)이고 오른쪽으로 갈수록 x 좌표가, 아래로 갈수록 y 좌표가 증가한다. cocos2d는 OpenGL 기반의 좌표계를 채용하여 왼쪽 아래 모서리가 (0, 0)이고 위로 갈수록 y 좌표가 증가한다.

좌표계와 더불어 독특한 것이 뷰의 위치 지정인데, 앞의 코드에서 나온 position은 UIView의 frame.origin이 아닌 center, 즉 뷰의 중심을 뜻한다. 뷰의 위치를 좌표로 지정하다 보면 왼쪽 위 모서리에 해당하는 origin이 편할 경우가 있는데, 항상 중심을 지정해야 하므로 계산이 필요할 수 있다.

cocos2d API의 기본 구조

cocos2d 아이폰 버전의 API는 cocos2d 원조(파이썬 버전) API로부터 기본 개념을 가져왔다. 따라서 cocos2d의 개념 파악을 위해서라면 파이썬 버전 기반의 프로그래밍 가이드인 http://www.cocos2d.org/doc/programming_guide/도 충분히 도움이 된다. 이 글에서는 cocos2d API의 핵심 클래스들을 나열하며 소개해 보려 한다.

CocosNode

엔진의 이름과 겹치는 만큼, CocosNode 클래스는 핵심 중의 핵심이다. 이후 나오는 Scene, Layer, Sprite 등 cocos2d 엔진을 바탕으로 돌아가는 그래픽 오브젝트의 뿌리가 되는 클래스이다. 이 클래스에는 position이나 visible과 같은 공통 프로퍼티와 그래픽 오브젝트의 계층 구조를 구성하게 해주는 add, remove와 같은 메소드, 그리고 액션과 스케줄링을 위한 기능까지 들어 있다.

특히 그래픽 오브젝트의 계층 구조는 UIView의 그것과 마찬가지라고 이해하면 쉽다. 따라서 화면을 구성함에 있어 이 계층 구조를 잘 활용하는 것이 관건이기도 하다. 액션에 대해서는 Action 클래스에서 언급하기로 하고 스케줄링에 대해 말하자면, NSTimer와 같이 중앙 집중적인 스케줄링 기능을 이용하는 것이 아니라, 오브젝트마다 분산된 자신만의 스케줄링이 가능하다는 점에서 매력적이다.

Scene과 Director

하지만 앞의 예제에서는 CocosNode 클래스는 나오지 않는다. 대신 Scene과 Director가 나오는데, 클래스 이름이 영화에서 온 것 같아 이해가 쉽다. 먼저 Director는 말 그대로 cocos2d 엔진에 있어 감독 같은 존재이다. 영화에 감독은 보통 한 명이듯이, Director 오브젝트도 하나, 즉 싱글턴(singleton)으로 되어 있어서 항상 [Director sharedDirector] 클래스 메소드 호출로 싱글턴을 얻어 낸다.

감독이 영화 제작에 있어 단위로 삼는 것은 씬(Scene), 즉 장면이다. cocos2d에서도 Scene은 가장 큰 화면 구성 단위이며 Director는 이 Scene 오브젝트 단위로 화면을 표시한다.

Layer

Scene이 게임에 있어 전체 화면을 가리킨다면, Layer는 그 화면을 구성하는 요소요소를 나타낸다. Scene이 영화에서 배경화면이라면, Layer는 배우나 소품에 해당하는 셈이다.

 

사용자 삽입 이미지

Scene과 Layer의 기능상의 가장 큰 차이점은 사용자 입력을 받을 수 있는가이다. 따라서 사용자 입력이 필요 없는 정적인 요소는 Scene에 바로 추가하는 방식을 취하며, Layer는 주로 사용자 입력이 필요한 동적인 요소를 구성하는 바탕이 된다. Layer가 터치 이벤트나 액셀로미터 이벤트를 받으려면 TouchEvents Delegate 프로토콜을 구현해야 한다.

 

사용자 삽입 이미지

Sprite

스프라이트는 게임 개발에 있어 화면상에 움직임이 있는 물체의 단위이며, Sprite 클래스도 바로 그런 의미이다. 스프라이트를 생성하는 방법에는 몇 가지가 있는데, 가장 쉽게 이미지 파일(아이폰에서는 PNG를 주로 쓴다)로부터 생성하며 애니메이션을 위해 하나의 스프라이트에 복수 개의 이미지를 넣을 수 있다. 부가적으로, 앞서 소개했던 PowerVR 3D 가속칩에 최적화된 PVRTC 이미지 파일도 사용할 수 있다.

 

사용자 삽입 이미지

Action

Action은 기본적으로 CocosNode에 액션을 취하게 하는 클래스이긴 하지만, 보통은 게임에서 주로 움직이는 대상인 Sprite에 많이 적용하게 된다. Action에는 크게 InstantAction, IntervalAction, 그리고 RepeatForever가 있는데

- InstantAction은 즉시 실행되고 바로 끝나는 단발성의 액션
- IntervalAction은 일정 시간동안 지속되는 액션
- RepeatForever은 특정 IntervalAction을 무한 반복하는 액션

각 종류별로 무척 다양한 액션들이 제공되어 있어 스프라이트의 움직임을 프로그램으로 작성할 때 무척 편리하다.

cocos2d 기반 게임의 기본 구성

앞서 cocos2d의 핵심 API를 배웠다고 해도, 게임 자체의 개발과 직결되는 것은 아니다. Director - Scene - Layer - Sprite - Action을 개별적으로 사용하여 아주 간단한 게임을 구성할 수 있겠지만(또는 게임의 핵심 부분을 빠르게 구현하는 프로토타이핑도 가능할 것이다), 제품 수준의 게임이라면 <그림 2>와 같은 구도를 갖게 마련이다.

 

사용자 삽입 이미지

<그림 2>를 이루는 요소 하나하나가 Scene이 되는데, 그럼 차례대로 살펴보자.

TitleScene과 MenuScene

게임을 시작하면 보통 화려한 오프닝이 시선을 집중시킨다. 타이틀 화면은 동영상으로 간단하게 처리할 수도 있지만, 여기서부터 인터렉션과 애니메이션이 필요할 경우는 TitleScene의 별도 작성도 요구된다.

타이틀 화면을 마치면 게임의 준비 화면인 메뉴가 나오게 된다. MenuScene은 모든 게임에 필수이므로, 따라서 cocos2d는 Menu와 MenuItem이라는 클래스를 제공하여 메뉴 구성의 편의성을 높이고 있다. Menu는 Layer를 상속하고 있어 당연히 사용자 입력을 받을 수 있는데, MenuItem을 이미지나 텍스트로 추가만 하면 알아서 터치 이벤트를 해당 MenuItem과 연결된 셀렉터(selector)로 이어준다. <그림 2>에서와 같이 메뉴 아이템에는 본 게임, 도움말, 스코어, 설정 등이 있으며 해당 아이템을 터치하면 Director의 replaceScene으로 화면 전환을 해주는 식으로 작성한다. 타이틀과 메뉴를 제외하고 모든 화면은 언제고 메뉴 화면으로 돌아올 수 있어야 하는 점도 간과해서는 안 된다.

GameScene

GameScene은 게임 본편에 해당한다. 여기에 게임 로직이 들어가게 되는데, 게임 오버가 되면 보통 ScoreScene으로 이어진다.

ScoreScene

ScoreScene은 그동안의 점수와 하이 스코어일 경우 이름을 받는 등의 작업이 일어난다.

HelpScene과 OptionScene

HelpScene은 게임을 처음 하는 사람을 위한 안내를 하며, 간단히 그림이나 동영상으로 설명할 수도 있다. OptionScene은 게임의 콘트롤이나 난이도, 사운드 등을 설정하게 해주는 화면이다.

아직 cocos2d에 대한 문서가 많지 않아 배우기가 만만치 않지만, 그래도 뜻이 있는 곳에 길이 있는 법이다. 가장 좋은 학습방법은 실제 cocos2d로 만든 게임 코드를 보는 것이다. 마침 오픈소스로 되어 있는 cocos2d 기반 게임인 Gorillas(http:// gorillas.lyndir.com/trac/wiki/TheSource)가 있어(게임 자체도 꽤 재밌다) cocos2d로 게임을 만들어 보려는 이들에게 최고의 도우미 역할을 해주리라 본다.

더불어 이번 특집에서의 cocos2d 소개에 이어 다음 달부터는 마소의 연재 코너를 통해 cocos2d와 함께 아이폰 게임을 만드는 과정을 좀 더 깊게 살펴보려 하니 아무쪼록 cocos2d의 기초를 잘 닦는 시간으로 4월을 보내고 5월호에서 다시 만나기를 소망한다.


cocos2d의 새 버전 0.7.1

원고를 마소 편집부로 넘기고 난 다음 날 아침, cocos2d의 새 버전인 0.7.1이 나온 것을 알고 받아보니 중요한 변경 사항이 있어 서둘러 추가했다. 본문에도 소개된 CocosNode의 멤버 메소드들 중 코드 표기법에 맞지 않는 메소드들을 대거 교체했다.

[self add:node];        // OLD
[self addChild:node];   // NEW

[self add:node z:0];          // OLD
[self addChild:node z:0];     // NEW

[self add:node z:0 tag:t];          // OLD
[self addChild:node z:0 tag:t];     // NEW

[self add:node z:0 tag:t parallaxRatio];        // OLD
[self addChild:node z:0 tag:t parallaxRatio];   // NEW

[self getByTag:tag];        // OLD
[self getChildByTag:tag];   // NEW

[self remove:node];                    // OLD
[self removeChild:node cleanup:NO];    // NEW

[self removeAndStop:node];                  // OLD
[self removeChild:node cleanup:YES];        // NEW

[self removeByTag:tag];                    // OLD
[self removeChildByTag:tag cleanup:NO];    // NEW

[self removeAndStopByTag:tag];              // OLD
[self removeChildByTag:tag cleanup:YES];    // NEW

[self removeAll];                           // OLD
[self removeAllChildrenWithCleanup: NO];    // NEW

[self removeAndStopAll];                    // OLD
[self removeAllChildrenWithCleanup: YES];    // NEW

[self do: action];          // OLD
[self runAction: action];   // NEW

[self absolutePosition];                   // OLD
[self convertToWorldSpace:CGPointZero];    // NEW

0.7.1에서도 // OLD에 해당하는 옛 메소드를 사용할 수 있지만 비추천(deprecated) 상태이며 0.8부터는 아예 사라진다고 하니 지금부터 0.7.1을 쓰더라도 // NEW에 해당하는 메소드를 쓰기 시작하자. 따라서 본문의 HelloCocos2d 예제 코드에서 [helloScene add:helloLabel];도 [helloScene addChild:helloLabel];와 같이 바꾸는 것이 좋다.


신고




     cocos2d, 개발, 개발자, 게임, 블로그, 소프트웨어, 아이팟, 아이폰, 애플리케이션, 앱스토어, 이창신
     0   0

아이디 
비밀번호 
홈페이지 
비밀글   

 

 

앱스토어&바다 앞세운 삼성전자 스마트폰 전략
+   [마이크로소프트웨어]   |  2009.12.18 09:39  


다들 오늘 삼성전자가 자사의 앱스토어를 한국에도 공개한다는 소식 들으셨지요! 자사 스마트폰용 OS 바다와 앱스토어를 통해 삼성전자는 어떤 전략을 펼쳐 나가려는 걸까요? 아래에 붙여드리는 마소 이미선 기자의 기사에 따르면 삼성전자는 바다 공개와 함께 개발자 사이트 오픈. 게다가 270만 달러라는 어마어마한 상금을 건 개발자 콘테스트도 시행할 예정이라고 합니다. 270불이 아닙니다. 270만원도 아니고 270만 달러! ㄷㄷㄷㄷㄷ 역시 대인배 다운 간지나는 콘테스트가 될 듯한데요. 마소와 블로그를 통해 이 소식들을 계속 전해드릴 수 있으면 좋겠네요. 유후~ 2010년. 모바일 세계의 뜨거운 열풍이 대한민국 소프트웨어 개발자들에게도 순풍이 되어 주면 좋겠습니다. 대한민국 개발자 파이팅!!!


이미선 기자 init@imaso.co.kr

삼성전자가 스마트폰의 활성화를 위해 앞장서고 나섰다.

삼성전자는 자사 앱스토어의 국내 서비스를 시작한데 이어 독자적인 스마트폰 플랫폼을 공개하며 본격적인 스마트폰 대중화 시대를 위한 행보에 나선다고 18일 밝혔다.

삼성전자는 SK텔레콤을 통해 자사의 스마트폰용 애플리케이션 장터인 ‘삼성 애플리케이션 스토어’의 국내 서비스를 시작했다.

 

삼성 애플리케이션 스토어는 SK텔레콤의 ‘T스토어’에 입점하는 ‘숍인숍(Shop in Shop)’방식으로 운영되며, 오는 2010년 1월에는 휴대폰 메뉴를 통해 바로 다운로드할 수 있는 서비스도 제공될 방침이다.

현재 삼성 애플리케이션 스토어에서는 ‘다이어트 댄스’, ‘퍼즐 맞추기’, ‘브레인 퍼즐’, ‘옥스포드 영어사전’ 등 FUN/생활위치/어학·교육 등 3가지 카테고리리의 애플리케이션이 제공되며, 2010년 벤쿠퍼 동계 올림픽 정도 프로그램인 ‘WOW(Wireless Olympic Works)’도 지원된다.

오는 2010년 2월에는 시뮬레이션 게임 ‘심시티’, 레이싱 게임 ‘페라리 GT’, 보드 게임 ‘모노폴리’ 등의 유명 게임을 즐길 수 있는 게임 카테고리도 추가될 예정이다.

이와 함께 옴니아2 고객을 대상으로 네이버의 웹툰·미투데이·윙버스·블로그·지도·뉴스캐스터, 다음의 지도·TV팟·싱크 등의 애플리케이션을 제공하고 있으며, 싸이월드 미니홈피·UCC 업로드·네이트 커넥트 등도 추가로 제공할 계획이라고 회사측은 설명했다.

 

더불어 삼성전자는 영국 런던에서 독자적인 스마트폰 플랫폼 ‘바다(bada)’와 소프트웨어 개발 도구인 ‘바다SDK’도 공개했다.

삼성전자측에 따르면 바다는 최신 스마트폰 기능이 집약된 플랫폼으로, SNS, LBS, 커머스(Commerce) 등의 다양한 서비스를 접목해 새로운 서비스의 개발이 가능하다는 것이 가장 큰 특징이다.

휴대폰에 탑재된 지도를 통해 친구의 위치를 찾은 후 주변 정보를 볼 수 있는 것은 물론 게임 중 아이템 구매가 가능하며, 통화, 메시지 전송 등의 다양한 기능을 쉽게 사용할 수 있도록 개발돼 휴대폰 UI와 밀접하게 연동되는 애플리케이션 개발이 가능하다.

또한 웹 및 플래시 기반의 애플리케이션을 지원하고, 삼성 풀터치폰 UI인 터치위즈 기반의 차세대 스마트폰 UI가 탑재돼 쉽고 직관적인 사용 환경을 제공하며, 햅틱, 가속센서 등 각종 센서의 지원과 얼굴인식 및 동작인식 등 다양한 입력 인터페이스를 활용할 수 있다.

삼성전자는 바다의 공개에 맞춰 개발자 사이트(developer.bada.com)를 통해 지속적으로 개발자 지원 정책을 펼치는 것은 물론 총상금 270만 달러의 개발자 콘테스트를 진행한다는 계획이다.

삼성전자 미디어솔루션센터 이호수 부사장은 “바다를 통해 보다 많은 전세계 휴대폰 사용자들에게 스마트폰 경험을 제공할 수 있게 됐다”며 “향후 바다 개발자를 위한 다양한 지원책을 아낌없이 펼쳐 나갈 것”이라고 말했다.


신고




     개발자, 바다, 삼성전자, 소프트웨어, 스마트폰, 아이폰, 앱스토어, 콘테스트
     1   2
ALAL 2009.12.20 19:46 신고
뒤늦게 따라가보지만 스마트폰 시장은 이미 뺏긴 것 같은 삼성
BlogIcon 마소호랭이 2009.12.21 13:16 신고 
에이 설마요... 열심히 하면 잘 되지 않을까요?

아이디 
비밀번호 
홈페이지 
비밀글   

 

 

흥미로운 예제로 배우는 아이폰 & 아이팟 프로그래밍
+   [좋은책 이야기]   |  2009.12.04 07:01  


아이폰과 아이팟은 애플리케이션 개발에 익숙한 개발자들에게 많은 관심을 받고 있다. 이 책은 아이폰 애플리케이션 개발을 처음 시도하는 개발자들에게 애플리케이션 개발의 기본 문법을 익히도록 하는 것은 물론 재밌고 유용한 애플리케이션을 개발할 수 있는 응용력도 길러준다. 처음 아이폰 애플리케이션을 개발하고자 하는 C, C++, 자바 개발자와 학생, 아이폰 애플리케이션 개발에 새롭게 진입하고자 하는 기존 모바일 개발자들에게 더욱 유익하다.

유동근 저/ 한빛미디어/ 464쪽/ 2만 5,000원


신고




     개발자, 마소, 마이크로소프트웨어, 소프트웨어, 아이팟, 아이폰, 앱스토어, 월간마소, 프로그래밍
     0   1
BlogIcon ASH84 2009.12.04 11:19 신고
저도 이책을 보며 공부하고 있습니다요 ㅋㅋ

아이디 
비밀번호 
홈페이지 
비밀글   

 

<<이전 | 1 | 2 | 다음>>

마소호랭이's Blog is powered by Daum

 

티스토리 툴바