태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

 

 

 

 
분류 전체.. (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/11   »
      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,951,283
+ Today : 717
+ Yesterday : 804
  

 

 

 

개발 _해당되는 글 12건
2010.06.07   아이폰 안드로이드 앱 개발자 정규 교육과정 개설 (1)
2010.06.07   실버라이트로 윈도우폰7 애플리케이션 개발하기 
2010.03.03   아이폰, 안드로이드폰, 모바일 앱 사업을 위한 발상 방법 (3)
2010.01.22   C++로 만든 코드 안드로이드로 마이그레이션 하기 
2010.01.19   소프트웨어 개발 생산성 팍팍 올리기 
2009.12.18   실전 아이폰 게임 개발 준비하기 
2009.12.14   애플 앱스토어 경험기, 드리밍 인 앱스토어-2 (1)
2009.11.27   소프트웨어 개발 방법론의 함정 
2009.08.11   Windows 7 Application 개발 - 2, Task Bar API 
2009.02.09   11월부터 보게 될 신형 저상버스 (8)

 

아이폰 안드로이드 앱 개발자 정규 교육과정 개설
+   [마이크로소프트웨어]   |  2010.06.07 09:49  


사용자 삽입 이미지


글로벌 IT 교육센터 패스트레인은 아이폰/안드로이드 앱 개발 과정을 개설한다.


주간과 주말 과정으로 나눠지는 이 과정은 각각 35시간과 32시간 동안 아이폰과 안드로이드 앱 개발 과정에 필요한 교육 필수조건을 모두 갖춘 정규 앱 개발자 과정이다.


교육 과정 중 다양한 예제를 직접 만들어 봄으로서 실무에 필요한 기술을 습득할 수 있으며, 아이폰 개발의 경우 개발에 필요한 맥북과 테스트용 장비 등을 교육기간 중 무료로 사용할 수 있다.


1인당 훈련비는 50만원이며 노동부 환급과정 혜택을 받을 경우 최고 15만원을 환급받을 수 있다.


기타 자세한 사항은 패스트레인(02-525-6191, info@flane.co.kr)에서 확인할 수 있다.


사용자 삽입 이미지

신고




     개발, 개발자, 교육, 노동부, 마이크로소프트웨어, 블로그, 스마트폰, 아이폰, 안드로이드, , 정규과정, 패스트레인, 환급
     0   1
BlogIcon north face fleece 2012.12.06 15:34 신고
not it truly is pass word safeguarded, you will find the possibility that will a person can "sniff"

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

 

 

실버라이트로 윈도우폰7 애플리케이션 개발하기
+   [마이크로소프트웨어]   |  2010.06.07 09:46  


www.imaso.co.kr에 웹 회원으로 가입하시면 매주 유익한 개발 정보를 메일로 받아볼 수 있습니다.


마이크로소프트웨어

데이터 매니지먼트

2010.06.01 (화)

홈페이지로 이동
마소가 만든 웹진
네트워크온
플레이폰

Cover Story

▲ 정보 인프라스트럭처의 관점에서 데이터 매니지먼트의 현실적인 의미와 품질과 속도 모든 면에서 더 효율적인 데이터 매니지먼트의 방향을 모색해 본다.

6월호 보기

마이크로소프트웨어

리버싱 관점에서 애플리케이션의 기능 추가 방법-Inline Code Patch

리버싱 관점에서 애플리케이션의 기능 추가 방법

리버싱 기술의 좋은 점 중에 하나는 이미 존재하는 애플리케이션을 리모델링 할 수 있다는 것이다. 지난 시간에 배웠던 ‘DLL Loading by PE Patch’ 방법은 사용자가 원하는 기능을 별도의 DLL 파일로 구현해 실행하기 때문에 복잡하고 큰 작업을 수행하는데 편리하다.

좀 더 간단한 패치작업을 수행할 때 편리한 Inline Code Patch(혹은 Inline Patch) 방법에 대해서 알아보자.

Dependency Walker는 무엇에 쓰는 물건일까?

Dependency Walker는 무엇에 쓰는 물건일까?

Dependency Walker는 모듈의 의존성 정보를 알아내는 도구다. 비주얼 스튜디오(Visual Studio) .NET 2003 버전을 사용한다면 설치 디렉터리 밑에 Common7ToolsBin 디렉터리에서 depends.exe를 실행하면 된다.

자주 사용하는 유틸리티이기 때문에 바탕화면이나 시작 메뉴 등에 등록해 놓고 사용하면 편리한 Dependency Walker는…

CopyrighⓒMaso Interactive Corp. All rights Reserved.

 
신고




     windows7, 개발, 개발자, 마소, 마이크로소프트, 마이크로소프트웨어, 블로그, 삼성전자, 스마트폰, 실버라이트4, 아이폰, 안드로이드, 윈도우폰7, 호랭이
     0   0

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

 

 

아이폰, 안드로이드폰, 모바일 앱 사업을 위한 발상 방법
+   [PlayPhone]   |  2010.03.03 18:46  


작년 한 해 마치 거대한 폭발이라도 일어나는 것처럼 응용물 시장(application market, App. store)이 여기 저기 생겨났다. 그리고 그것은 개발자들에게 마치 새로운 황금의 땅처럼 비춰졌고, 몇몇 개발자들은 노다지를 캐내어 큰 수익을 달성했다는 소식들도 들려온다. 그러나 열린 시장의 특성답게 벌써 응용물 간에 치열한 경쟁이 시작됐으며, 앞으로 그 경쟁은 더욱 심해질 것이다.

기존 게임 산업에서 출시하는 게임 중 몇 퍼센트에 해당하는 게임만이 의미 있는 소득을 올려 왔듯이 응용물 사업에서도 그렇게 될 것으로 보인다. 이럴 때일수록 정밀 유도폭탄처럼 정확히 노다지를 찾아내는 해법이 필요하며, 앞으로는 이런 해법의 필요성은 더욱 커질 것이다. 필자는 바로 이런 해법 한 가지를 제시하고자 한다. 필자가 제시하는 해법은 노다지를 찾아내는 탐사기와 같은 것이며, 필자는 그것을 발상 상자 또는 발상 기계라고 부른다.

노다지가 열렸다
기계적인 금광이 생겼다. 그것도 노다지다. 땅 속 깊숙이 숨어 있는 황금광산이 아니고, 땅에 노출돼 있는 황금광산이다. 노다지에는 누구나 들어갈 수 있다. 그리고 누구든 금을 캐올 수 있다.

지금 세계적으로 앱스토어에 대한 이야기가  한창이다. 새로운 노다지라고들 한다. 지금까지 배고팠던 프로그래머들이 이제는 배부르게 먹고 살 길이 열렸다고도 한다. 그러나 그 노다지에 들어간다고 해도 모든 사람이 황금을 캘 수 있는 것은 아니다. 황금을 캐는 방법을 아는 사람만이 그것을 얻어낼 수 있다.

응용물
애플리케이션(application)을 우리말로 응용(應用)이라고 번역할 수 있다. 그러나 나는 명사 또는 이름씨임을 알기 쉽게 하고, 또 문장을 매끄럽게 만들기 위해서 응용이라는 말 대신에 응용물(應用物)이라는 말을 만들어 쓰고는 한다. 어떤 것을 기반으로 삼아 그것을 응용해 편의를 더해주는 것들을 응용물이라고 할 수 있다. 그런 의미에서 컴퓨터를 기반으로 삼아 통계를 내기 쉽게 해 주는 통계 프로그램도 응용물이고, 워드 프로세서도, 엑셀과 같은 스프레드시트도 응용물의 하나다. 더불어 온라인 게임은 컴퓨터 통신망을 이용한 응용물이고, 영상 편집 프로그램이나 전자책 프로그램도 응용물이다. 물론 이런 응용물에는 영상, 음성, 음향, 전자책과 같은 문화물(콘텐츠) 자체도 포함된다고 할 수 있다.

점점 작은 컴퓨터가 돼 가는 휴대전화를 포함한 이동통신 단말 장치를 응용해 편리성을 더해주는 어떠한 것 또한 응용물의 일종이다.

요즘 앱스토어가 유행하고 있는데, 이때 쓰는 앱(App)이란 말이 응용물을 나타내는 영어 낱말인 애플리케이션의 준말이라는 것은 잘 알고 있을 것이다. 특히 휴대전화와 같은 이동통신 기기의 응용물에 대해서 앱이라는 말을 즐겨 사용하는 추세다.

앱스토어
애플은 아이팟과 아이폰을 기반으로 작동하는 응용물을 누구나 쉽게 판매할 수 있는 열린 시장을 만들었다. 그리고 그 시장에 ‘앱스토어’라는 이름을 붙였다. 아이폰을 쓰는 사람들은 앱스토어를 통해 응용물을 구입한다. 그 응용물에는 택시를 호출하는 프로그램도 있고, 간단한 게임도 있고, 업무에 쓸 일정관리 프로그램이나 사진을 예쁘게 꾸며주는 프로그램도 있다. 아이폰 사용자는 앱스토어에서 응용물을 구입한 후 그것을 자신의 아이폰에 설치하고 사용하면서 편리함을 느낀다. 그러다보니 앱스토어에서 앱을 내려 받는 횟수가 잦아졌다. 앱스토어를 개설한 지 채 3년도 안 된 현재 시점에서 30억 회 정도를 내려 받은 것으로 알려졌다.

이 앱스토어는 옥션이나 지마켓과 비슷한 방식으로 운영되는 열린 장터다. 누구나 팔고자 하는 응용물을 등록해 판매할 수 있으며, 약간의 수수료만 부담하면 된다.

나도 살고, 너도 사는 방법

누구나 앱스토어에서 자신이 만든 응용물을 판매할 수 있게 됐지만 모두가 돈을 버는 것은 아니다. 상위 몇 퍼센트 이내에 들 정도로 판매량이 많은 경우에만 꽤 괜찮은 소득을 올린다. 또 어떤 이는 갑작스럽게 거부되기도 하는데, 어떻게 갑자기 거부되기 시작한 것일까? 원리는 간단하다. 수익분배 비율에 있다. 응용물 제작자 70%, 그리고 애플과 통신사 30%. 이것이 앱스토어의 수익분배 비율이다. 만 원짜리 프로그램 하나를 팔면 그 중 7,000원을 응용물 제작자가 갖고, 3,000원은 애플과 통신사가 나눠 갖는다. 물론 세금을 포함한 금액이다.

이것은 대단한 변화다. 그전까지 콘텐츠 업체를 포함한 응용물 제작자들은 수익의 많은 부분을 통신사에 넘겨줘야 했다. 겉으로는 응용물 제작자 50%, 통신업체 50% 또는 응용물 제작자 90%,  통신업체 10% 정도의 수익분배를 규정하고 있더라도 이런 저런 이유로 응용물 제작자에게 돌아오는 수입이 적었다. 게다가 시장이 폐쇄적이어서 쉽게 응용물을 내놓고 판매하지도 못했다. 그러다보니 응용물 제작에 꿈을 품고 도전했던 이들이 포기하거나 아예 시장을 부정적으로 보며 꿈을 포기하고는 했다.



<그림 1> 휴대형 무선 통신 단말 응용물 시장의 악순환 구조

이런 악순환 구조를 만든 결정적인 이유 중의 하나로는 통신사가 자신들의 통신망을 통해서만 응용물을 판매할 수 있게 한 것을 들 수 있다. 비유하자면 통신사가 노다지로 가는 관문을 막고 서서, 그 노다지로 들고 나는 자들에게 자신들이 원하는 만큼의 통행료를 물린 것과 같다고 볼 수 있다. 그런데 실상 노다지 자체는 통신사의 것이 아니다. 휴대전화 사용자들이 기꺼이 지불하는 비용이 노다지의 황금을 이루고 있고, 그런 황금이 자라는 땅에 비유할 수 있는 무선 인터넷망 또한 개방된 것이다. 그런데도 불구하고 노다지로 들어가는 관문이라고 할 수 있는 통신 접속 방법을 통신사들이 틀어쥐고 있다 보니 응용물 제작자들은 ‘울며 겨자 먹기’식으로 많은 통행료를 지불할 수 밖에 없었다.

악순환 구조 속에 사용자들도 여러 모로 손해를 봤다. 3,000원짜리 게임 하나를 자신의 휴대 전화에 설치하기 위해서 1만 원 정도에 해당하는 통신 요금을 지불해야 하는 상황이 벌어진던 것이다. 그러다보니 사용자 또한 응용물 내려 받기를 꺼리게 됐고, 그럴수록 응용물 시장은 위축됐다. 그럼에도 불구하고 통신사들은 악순환 구조를 쉽게 깨뜨릴 수가 없었는데, 자신들이 독점하고 있는 통행료를 놓치기 싫었기 때문이다.

이런 추세에서 애플은 이 방식을 과감히 바꿨다. 그러면서도 수익을 낼 수 있음을 보여줬다. 애플이 바꾼 것은 크게 두 가지다.

첫 째, 휴대전화 사용자들이 노다지로 들어가는데 내는 통행료를 없애다시피 했다. 이제 사용자들은 더 이상 통신사에 비싼 통행료를 지불하지 않고도 응용물을 자신의 휴대전화에 설치할 수 있다. 그리고 더 쉽고 간편하고 저렴하게 응용물을 내려 받아 쓸 수 있게 됐다. 그러다보니 당연히 사용자들은 더 많은 응용물을 구입하게 됐다.

둘 째, 응용물을 만들어 공급하는 사람들에게 받는 통행료도 대폭 낮추고, 까다롭던 통과 과정을 없애다시피 했다. 그러면서 온갖 편의를 제공한다. 노다지를 캘 수 있는 곡괭이에 해당하는 개발 도구까지 공짜로 준다. 그리고 노다지를 어느 곳에서나 캘 수 있도록 방해하지도 않는다. 아무나 어떤 형태의 응용물이든 앱스토어에 올릴 수 있도록 한 것이다. 이에 따라 사용자, 애플 그리고 응용물 제작자가 서로를 살리는 상황이 됐다.



<그림 2> 휴대형 무선 통신 단말 응용물 시장의 선순환 구조

또 다른 노다지들 

이런 상황에서 또다른 노다지들이 만들어지고 있다. 첫 째, 안드로이드 마켓(http://www.android.com/market/)이 그것이다. 안드로이드란 세계적인 인터넷 검색 서비스 업체인 구글을 중심으로 만든 휴대전화용 운영체제 및 필수적 소프트웨어의 집합을 통틀어 일컫는 용어다. 일종의 기반(platform) 소프트웨어인 것이다. 안드로이드를 탑재한 휴대전화라면 안드로이드 기반의 프로그램이 무리 없이 작동한다. 구글은 애플의 앱스토어와 마찬가지인 열린 응용물 장터를 만들어 주고, 또 그 장터에서 판매할 응용물을 만드는데 필요한 도구까지 무료로 제공한다. 그러다보니 안드로이드 마켓이라는 노다지도 무섭게 성장하고 있다.

세계 각국의 휴대전화 제조업체와 통신사를 비롯해 여러 기업들이 애플 앱스토어의 성공을 기준으로 삼아 열린 응용물 시장을 만들기 시작했다. 2008년부터 2009년까지를 기점으로 폭발적으로, 경쟁하듯이 애플 앱스토어를 닮은 열린 응용물 시장들이 생겨났다. 애플 앱스토어와 안드로이드 마켓이라는 큰 노다지 외에도 여기저기서 노다지가 될 만한 광산들이 만들어지고 있는 것이다. 이제는 거의 모든 통신사나 휴대전화 제조업체들이 그런 열린 응용물 시장을 통해 사용자에게 많은 응용물을 공급해야만 경쟁에서 살아남을 수 있다는 것을 인식한다. 통신사들은 살아남기 위해서라도 자신들이 받던 통행료를 낮추고, 노다지로 드나드는 자들에게 온갖 편의를 제공해야만 한다. 그래서 이제 통신사들은 다소 뒤늦은 감이 있지만, 자신들이 지키고 있던 관문을 열겠다고 한다. 곡괭이에 비유할 수 있는 개발 도구와 각종 편의를 무상으로 제공하겠단다. 자신들도 이제는 애플처럼 판매 대금의 30% 정도만 갖겠다고도 한다. 심지어 어떤 회사는 20%만 받겠다고 한다.

고마워, 애플
필자는 수 년 전에 휴대전화 응용물 시장에 진출하고자 시도한 적이 있었다. 그러나 당시의 시장은 지금과는 너무도 달랐다. 노다지 자체가 적었을 뿐만 아니라 그 노다지로 들어가는 관문을 통신사들이 꽉 쥐고는 비싼 통행료를 받았기 때문이다. 심지어 노다지에서 황금이 나게 만들어주는 사용자들에게까지 통행료를 받았다. 그러다보니 노다지는 커지지 않았고, 심지어는 오히려 줄어든 노다지도 있었다. 하지만 지금은 상황이 거의 180도에 가깝게 변했다. 애플 덕분이다. 애플이 새로운 사업 방식을 보여줬다. 통행료를 적게 받고도 수익을 낼 수 있는 방법을 보여준 것이다. 애플의 앱스토어 출현 이전에도 ‘한단고(http://www. handango.com)’나 그밖에 휴대전화 통신회사들이 개설한 일부 응용물 시장이 있기는 했지만 애플처럼 선순환 구조를 만들고, 시장을 더욱 개방하면서도 그것이 휴대전화 제조업체와 통신사 그리고 사용자와 응용물 제작자까지 모두를 이롭게하는 선순환 구조로 정착하지는 못했다. 애플이 처음으로 선순환 구조를 보여준 것이다.

그러자 휴대전화 제조사, 통신사, 그 밖의 회사들도 애플을 따라하겠다고 나섰다. 70대 30이라는 수익배분이 세계적인 기준이 됐다. 어떤 열린 응용물 시장에서는 응용물 제작자에게 100 중에 80까지 수익 배분을 하기도 한다. 휴대전화 사용자들에게는 아예 통행료를 받지 않는 경우도 생겨서 사용자들이 더 많은 응용물을 구입한다. 그래서 노다지 안의 황금을 지속적으로 키워준다.

“애플, 정말 고맙다.”

애플 덕분에 나 같은 사람도 다시 한 번 응용물 사업을 해볼 의지를 갖게 됐다. 그리고 많은 응용물 제작자들, 예를 들면, 프로그램 제작자, 게임 제작자, 동영상 제작자, 출판사, 방송사들도 더 커진 시장을 얻게 됐다. 그리고 앞으로 더욱 큰 시장을 누릴 수 있게 됐다. 정말이지 고맙고 고맙다, 애플!

그러나 문제는 황금을 찾는 방법이다
이제 노다지가 생겼고, 그 곳에서 황금을 캐는 방법까지 널리 알려졌다. 황금을 캐는 방법은 간단하다. 애플이나 구글과 같은 응용물 시장 주도자가 제공하는 개발자용 도구를 무료로 내려 받아 그것으로 프로그램을 비롯한 여러 응용물을 만든 후 애플의 앱스토어나 안드로이드 마켓 또는 다른 열린 응용물 시장에 등록하면 된다. 그것으로 충분하다. 사용자가 그 응용물을 사면 판매 금액의 70%에서 많게는 80% 정도가 한 달쯤 뒤에 고스란히 통장으로 들어올 것이다. 정말 간단하지 않은가.

여기서 ‘프로그램을 만드는 제작 기술이 중요하지 않느냐?’는 질문을 할 수 있다. 물론 중요하다. 곡괭이질을 하지 못하는데 어떻게 황금을 캘 수 있겠는가. 그러니 매일 매일 곡괭이 다루는 법을 익히고, 더 익숙해지도록 훈련해야 한다. 그러나 더 중요한 점이 있다. 노다지에서 황금을 찾는 방법을 알아야 한다는 것이다.

곡괭이 기술자, 특히 장인 수준에 오른 기술자라고 할지라도 황금을 찾지 못한다면 자신의 기술은 쓸모가 없어진다. 아무리 프로그램 제작 능력이 뛰어나다고 해도 이용자들이 사주지 않는 응용물을 백 개, 천 개, 만 개 만들어서 무엇 하겠는가. 시간과 노력과 기술과 인력과 자금과 같은 자원만 낭비하는 셈이 될 뿐이다.

황금을 찾는다는 것은 무엇을 의미하는가. 휴대전화 사용자들이 기꺼이 돈을 지불하고라도 내려 받을 만한 독창적이면서도 가치 있는 응용물을 고안하는 것이다. 그런 응용물을 고안하지 않고 남들이 이미 다 만들어 놓은 응용물을 만든다거나 사용자들이 필요로 하지 않는 응용물을 만든다면, 노다지는 당신에게 돈을 안겨주는 곳이 아니라 당신의 신성한 노동력을 소모하게 하는 노예 공사장이 될 수도 있다.

애플 앱스토어나 안드로이드 마켓을 비롯한 열린 응용물 시장들의 진입 장벽은 낮다. 그러다보니 개발 도구를 사용해 프로그램을 만들 수 있기만 하면 누구나 시장에 참여할 수 있다. 게다가 누구나 곡괭이로 상징되는 개발 도구를 무료로 쥘 수 있으며, 그 곡괭이를 쥔 거대한 집단과 같은 대형 응용물 제작 기업들도 있다. 이들은 심지어 곡괭이를 사용하는 기술마저도 뛰어나며, 이미 이전의 폐쇄적 이동통신 응용물 시장 또는 PC 기반 응용물 시장에서도 뛰어난 응용물을 제작해 성공해 본 경험을 갖고 있다. 소스코드까지 갖고 있어서 곡괭이를 잠깐 휘두르는 것, 다시 말해서, 기존의 소스 코드를 이동통신 운영체제에 맞게 변환(conversion)하는 것만으로도 곧 황금을 캐내갈 수도 있다. 벌써 많은 기업들이 이런 식으로 응용물을 만들어서 판매하거나 무상으로 제공하고 있다.

이와 같이 시장이 열려 있는 만큼 경쟁도 치열하다. 무한 경쟁의 열린 시장인 셈이다. 이 시장에서의 경쟁력은 곡괭이를 다루는 기술에 달려있는 것이 아니라, 황금을 찾는 기술에 달려있다. 다시 말해서, 이동통신 환경과 휴대전화 단말기 특성을 고려해 경쟁 제품 대비 독창적이면서도 이용자가 기꺼이 돈을 지불하고라도 사고 싶어할 만한 응용물을 고안하는 것이 중요하다. 이는 앞으로 더욱 중요해질 것이다.

어떻게 황금을 찾을 것인가
황금을 찾는 방법. 그렇다. 바로 이것이 문제의 핵심이다. 어떻게 황금을 찾을 것인가

필자가 이 글을 통해 얘기하고자 하는 것은 이렇다. 황금을 찾는 방법, 황금을 찾는 기술, 황금을 찾는 도구를 독자들에게 전수해 주는 것. 이것이 이 글이 목적이다.
‘그런 방법을 알고 있다면 혼자만 쓰면 되지, 왜 알려주느냐’고 물어올 수도 있겠기에 여기에 대답을 적어 놓는다.

“혼자만 쓰기에는 너무 아깝다. 그리고 남이 부자가 되면 나도 부자가 된다.”

애플이 만든 선순환 구조를 생각해 보라. 나는 응용물 제작자들을 부자로 만들어 줌으로써 부자가 되는 방법을 택했다. 그 후에 함께 진보해 나가는 것이다. 많은 응용물 제작자들이 소비자에게 딱 필요한 좋은 응용물들을 공급해 주면, 휴대전화 사용자들은 더 많은 응용물을 구입하게 될 것이고, 그러면 노다지는 더 커질 것이다. 나 또한 더 커진 노다지에서 더 많은 황금을 캘 수 있지 않겠는가.

그래서 이제부터 황금을 찾는 방법을 설명하려고 한다. 지식은 진주보다 더 귀하다. 이 글에 담긴 지식이 당신에게 진주 여러 꿰미에 해당하는 값어치를 지닌 황금을 얻게 해 줄지도 모른다.

■ 응용물 개발 절차 

이동통신 응용물의 개발 절차를 간략하게 알아보자.



<표 1> 응용물 제작 절차 비유 및 비교

<표 1>에서 보듯이 응용물 제작 절차는 크게 보면 네 단계, 그리고 작게 보면 여덟 단계로 이뤄졌다. 물론 이 분류 방식은 사람마다 다를 수 있다. 무지개 색깔을 다섯가지 색으로 보기도 하고, 일곱가지 색으로 보기도 하는 것처럼 말이다. 색을 더 잘 구분할 줄 아는 사람은 무지개 색을 열가지 이상으로 구분하기도 하다. 그러나 나는 여기서 개발 절차에 대해서 논의하려고 하는 것이 아니다. 개발 절차 전체 중에서 응용물을 발상해 낸다는 것이 어떤 위치를 차지하는지를 알리려고 할 뿐이다. 그런 의미에서 개발 절차를 조금 더 부연 설명하면 <표 2>와 같다.



<표 2> 상세한 응용물 제작 절차

<표 2>가 나타내는 모든 개발 절차가 저마다 중요성을 지니고 있지만 그 중에서도 기안은 모든 업무의 시작이다. 기안 중에서도 발상은 더욱 그렇다. 발상이 없는 상태에서는 그 이후의 과정을 진행할 수가 없다. 그리고 발상의 양이 충분해야 그 이후에 이어지는 선별 작업을 통해 나름대로 시장성 있는 응용물을 추려 낼 수가 있다. 시장성 있는 응용물이어야 개발대상으로 선정된다. 그리고 개발이 돼야 판매도 할 수 있다. 이와 같은 과정을 고려해 발상의 양이 충분해야만 성공적인 판매가 가능하다는 것을 알 수 있다.

하나의 응용물을 제작하는 데에는 시간과 노력, 비용이 투입된다. 막연한 아이디어 하나만으로 응용물을 제작한다면, 그것의 성공 가능성을 가늠하기 어렵다. 때문에 아이디어를 선별하고 확정짓는 일이 필요하며, 그 일을 위해 충분한 발상이 선행돼야 한다.

흔히 프리 프로덕션이라고 불리는 기안과 선정 과정에서 실패하면, 프로덕션 과정이라고 불리는 개발 과정에서 아무리 뛰어난 기술을 동원해 봐야 실패하게 마련이고, 포스트 프로덕션이라고 할 수 있는 판매는 꿈도 꿀 수 없다. 그리고 프리 프로덕션은 발상에서부터 시작된다.

발상의 저변이 넓을수록 정상 부분에 해당하는 출시와 판촉 부분, 비유하자면 꽃 봉우리라고 할 만한 의미 있는 수익을 내는 응용물의 수량 또한 커진다. 이것은 피라미드 구조에 비유할 수 있다.



<표 3> 발상의 양에 따른 성과 표현 피라미드

<표 3>에서 피라미드 ①은 어떤 것을 발상하자마자 제작에 들어가는 것을 나타낸다. 이 경우에도 우연히 성공할 수는 있다. 특히 응용물 시장이 막 열린 상태라거나 발상 자체가 우연히 독창적인데다가 이용자들이 필요로 하는 것이라면 더욱 그렇다. 그러나 한 두 번 또는 두 세 번 우연히 성공할 수는 있을지 몰라도 지속적으로 의미 있는 수익을 내는 응용물을 만들어 내기는 어렵다.

피라미드 ②는 다소 체계적으로 접근하는 경우를 나타낸다. 제작에 들어가기 전에 꽤 많은 발상부터 하지만 발상의 양이 충분하지 못한 경우다. 이런 때에 수익을 내는 응용물을 비교적 지속적으로 만들어 낼 수는 있을 것이다. 다만 그 수익의 규모가 크지 않다는 것이 문제인데, 소위 말하는 대박 응용물이 나올 가능성이 낮다.
피라미드 ③은 대량으로 발상을 하는 경우를 표현한다. 이 경우 발상의 양으로 표현되는 피라미드의 저변이 넓어서 의미 있는 수익을 내는 응용물의 양을 나타내는 피라미드의 정상부 또한 크다. 그리고 정상부가 큰 만큼 소위 말하는 대박 응용물이 그 안에 섞여 있을 가능성도 크다.

시장 초기 상태라면 피라미드 ①이 보여주는 방식으로 접근하는 것이 가능하다. 그러나 열린 시장의 특성상 경쟁이 곧 치열해지기 때문에 곧 피라미드 ②의 방식으로 접근해야 한다. 그리고 지속적으로 의미 있는 수익을 원한다면 당연히 피라미드 ③의 방식으로 접근하는 것이 좋다. 때문에 필자는 발상이 전체 제작 공정 중에서 30% 정도의 중요성을 차지하고 있다고 본다. 그런데 응용물 개발 능력을 지닌 사람들, 특히 프로그래머와 같은 개발자들은 개발에 더 많은 노력을 투입하는 경향이 있다. 실상 개발이라고 하는 것은 응용물에 대한 생각을 표현하는 과정이다. 응용물 자체에 대한 기획이 제대로 돼 있지 않다면 아무리 뛰어나게 표현한다고 해도 시장에서 받아들여지지 않는다. 따라서 응용물 제작자들은 발상에 힘을 기울여야 한다. 황금을 캐기 전에 먼저 황금을 찾을 줄 알아야 하는 법이다.

■ 대량 발상의 필요성과 3퍼밀의 법칙

다시 한 번 강조하지만 발상의 양이 수익을 내는 응용물의 양을 결정한다. 그런데 어느 정도 발상을 해야 할까. 의미 있는 수익을 내는 응용물 3개를 만들고자 한다면 1,000개 정도의 발상이 필요하다. 필자의 이런 주장에는 근거가 있다. 필자는 그 근거로 ‘3퍼밀의 법칙’을 들고자 한다. 3퍼밀이란 1,000 분의 3에 해당하는 비율을 말한다. 3%의 십분의 일에 해당한다.

필자가 아르바이트 삼아서 컴퓨터 관련 강의를 하고 다니던 시절이었다. 필자는 광고 전단을 만들어 아파트 관리 주체와 계약을 맺고는 그것을 아파트 게시판에 붙이고 다녔다. 그때 어디서 읽었는지는 기억이 나지 않지만 이 3퍼밀의 법칙이라는 것을 알고 있었다. 마케팅 용어였는데, 1,000명의 사람에게 광고를 노출하면 그 중 3명 정도만이 상품에 관심을 갖는다는 것이었다. 나는 실제로 그런 법칙이 들어 맞는 것을 체험했다. 광고 전단지를 1,000명 정도에게 노출이 될 만큼 아파트 게시판에 붙이고 나면 실제로 강의를 하는 경우는 3번 정도에 불과했다. 때로는 4번, 때로는 10번 그리고 때로는 1번 정도만 성사되는 경우도 있기는 했지만 평균을 내어 보면 거의 3퍼밀의 법칙이 성립했다. 필자는 그렇게 전단지를 지속적으로 붙이고 다녔고, 내가 붙인 전단지는 1만 장도 넘었을 것이다. 그런데 신기하게도 1,000장을 붙이든 1만 장을 붙이든 강의로 연결되는 경우는 거의 언제나 3퍼밀 정도였다. 그래서 나는 강의를 3번 정도 하고 싶을 때면 1,000명 정도가 볼 수 있을 만큼 전단지를 붙였고, 10번 정도 강의를 하고 싶을 때는 5,000명 정도가 볼 수 있을 만큼 전단지를 붙였다. 당연히 더 많은 강의가 필요할 때는 더 많이 붙였다.

3퍼밀의 법칙을 거꾸로 생각해 보자. 전단지를 많이 붙일수록 성과도 좋다. 성과를 키우려면 그만큼 더 많은 전단지가 필요하다. 나는 이것을 ‘다수의 법칙’이라고 이름 붙였다. 다수의 법칙은 3퍼밀의 법칙의 짝이다.

이제 응용물을 발상하는 문제로 돌아가 보자. 열린 응용물 시장인 앱스토어나 안드로이드 마켓에는 벌써 수 만 혹은 수십 만 개의 응용물들이 등록돼 있다. 실상 휴대전화 사용자들이 필요로 하는 응용물들은 거의 다 있다고 봐도 무방하다. 필자가 다소 무리한 적용이라는 비판을 받을 줄 알면서도 3퍼밀의 법칙을 원용하는 이유가 바로 이것이다. 출시되는 많은 응용물 중에서 의미 있는 수익을 거두고 있는 응용물은 전체 응용물 중의 겨우 몇 %에 불과하며, 앞으로는 그 비율이 더욱 줄어들 것으로 예측된다. 그러나 이런 시장에도 반드시 틈새는 존재하게 마련이다. 그 틈새란 아직 누구도 발견하지 못한 황금 광석에 비유할 수 있다. 그 틈새를 어떻게 찾을 것인가. 아주 간단하다. 찾고 찾으면 된다. 많이 찾아다니면 된다. 다수의 법칙을 따라서 새로운 응용물들을 아주 많이 발상하다보면 그 중 3퍼밀 정도는 제대로 된 틈새, 아직 누구도 캐지 못한 황금일 가능성이 있다.

이 3퍼밀 또는 희박한 성공 확률을 어떻게 높일 수 있을까. 방법은 지능형 능동 유도 폭탄을 제조하는 데에 있다. 그저 여기 저기 폭탄을 떨어뜨려서 표적을 맞히려고 하기보다는 정확하게 표적을 찾아가는 지능형 폭탄 또는 정밀 유도 폭탄을 제조하면 되는 것이다. 정밀 유도 폭탄의 핵심 기술은 지형 탐지 기술이다. 이 기술의 기반 원리는 황금 광산을 탐사할 때 쓰는 것과 별반 다르지 않다. 필자는 바로 이런 지형 탐지 기술 또는 광산 탐사 기술을 알려주려 하는 것이다. 그리고 이 지형 탐지 기술 또는 광산 탐사 기술에는 필연적으로 세밀한 지도가 필요하다. 이런 세밀 지도에 해당하는 것이 바로 대량의 아이디어다. 바로 이런 대량의 아이디어를 만들어 내게 하는 것, 그것이 필자가 이번 연재에서 제공하는 지식의 핵심이다. 향후에 다시 연재할 기회가 있다면 그 때는 세밀 지도를 통해 표적을 골라내는 방법을 다룰 수도 있겠지만, 이번 연재에서는 세밀 지도를 작성하는 방법에만 집중하고자 한다.

요약하자면, 의미 있는 수익을 거두는 것, 곧 표적을 정확히 공격(pin point attack)하기 위해서는 먼저 세밀 지도를 만들어야 한다. 여기서 세밀 지도는 곧 대량의 아이디어를 의미하고, 대량의 아이디어는 많은 발상에서 비롯된다. 기억하자, 많이 발상해야 한다는 것을.

어떻게 많은 발상을 할 것인가
그렇다면 어떻게 해야 발상을 많이 할 수 있을까. 실상 강제로 아이디어를 짜내지 않는 한은 1,000개 혹은 2,000개를 넘어서 몇 만 개나 되는 발상을 하기는 쉽지 않다. 누군가에게 하루 정도의 시간을 주면서 100개 정도의 발상을 해오라고 한다면 선뜻 나서겠다는 사람이 있을까. 제 아무리 천재라고 해도 발상을 하루만에 100개 정도나 하는 것은 쉬운 일이 아니다. 그것도 거의 매일 또는 일주일에 5일 동안 꾸준히 100개씩 발상해야 한다면 더더욱 쉬운 일이 아니다.

하지만 방법은 있다. 필자는 그 중에서 가장 쉬우면서도 모바일 앱, 다시 말해서, 휴대전화를 포함한 이동통신 단말기용 응용물을 개발하기에 가장 적합한 방법 하나를 소개하고자 한다. 이 방법의 원안은 아주 오래전부터 쓰여왔던 것인데, 소프트뱅크의 창업자는 이 방법을 써서 특허를 취득하고는 특허를 팔아 사업에 필요한 자금을 쥐기도 했다. 이 방법은 ‘카드법’이라고 일컬을 수 있다. 조금 길게 표현하자면 ‘낱말 쪽지를 조합해 강제적으로 발상을 얻는 방법’이다.

이쯤에서 ‘에이, 난 또 뭐라고. 그까짓 것쯤이야 새로운 것도 아닌데. 또 그렇게 해서 좋은 발상이 나온다면 왜 지금까지 사람들이 사용하지 않았겠어?’라고 의문을 품는 사람이 있을 수도 있다. 그러나 다시 한 번 거듭 이야기하지만 이 방법은 아주 강력하며, 필자는 이 방법의 원안을 휴대전화를 포함한 이동통신 단말기용 응용물 개발에 잘 적용할 수 있도록 보강했다.

다음 호부터는 이 방법, 곧 열린 응용물 시장에서 틈새를 발견하는 법, 황금을 찾는 법, 독창적이면서도 가치 있는 응용물을 고안하는 방법에 대해 알아보자.

[필자] 박진수 arigaram@empal.com|오랫동안 소프트웨어를 개발하고 시스템을 구축을 경험했다. 『좋은 코딩 나쁜 코딩』 등의 컴퓨터 관련 도서를 다수 저술했고, ‘우제용(寓諸庸)’이라는 필명으로 『복리』 등의 이야기 책 저술에도 힘써 왔다. 현재 이동통신 응용물(mobile applications)을 포함한 문화물(contents)의 창안과 기획 그리고 제작에 관심을 갖고 있다.

신고




     개발, 개발자, 마소, 마이크로소프트웨어, 블로그, 스마트폰, 아이폰, 안드로이드, 애플리케이션, 플레이폰
     0   3
awrhvilaw;hvr 2010.03.03 22:06 신고
컴퓨터 본체 피난 갤러리 주소 : http://ref.comgal.info/
BlogIcon Cofcat 2010.03.05 02:03 신고
이번에 안드로이드 어플리케이션을 개발해 볼려고 하고 있습니다만... 어떤 아이템을 가지고 해야 할지가 가장 관건 인 것 같습니다. 이번에 안드로이드의 어플 공모전인 tac에 출품을 하려고 해도... 생각이 난 아이템들은 거의 애플 어플로 있는 것들이더군요,,,,,, 어플리케이션 개발.... 쉬운일이 아닌 것 같습니다.
BlogIcon grapher 2010.03.14 02:32 신고
여러분 아이폰 유저 뒤통수 친 케이티에 대응해야 합니다. http://espn.tistory.com/1458

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

 

 

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

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

 

 

실전 아이폰 게임 개발 준비하기
+   [마이크로소프트웨어]   |  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

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

 

 

애플 앱스토어 경험기, 드리밍 인 앱스토어-2
+   [마이크로소프트웨어]   |  2009.12.14 05:59  


지난 [애플 앱스토어 경험기, 드리밍 인 앱스토어-1]에 이어지는 글입니다. 총 3회로 나누어 옮기고 있습니다.

2단계 : 개발 과정

다시 필자의 경험으로 돌아오자. 책을 통해 공부하고 보니 어느 정도 감이 잡히기 시작했다. 이제 실제로 앱스토어에 올릴 프로그램을 만들어야 하는 단계다. 가장 먼저 프로그램 기획이 필요했다. 앱스토어는 약 20개의 카테고리로 프로그램들을 분류하는데, 프로그램을 올릴 때 이 중 한 분야를 선택하게 된다.

카테고리 선정, productivity

기획단계에서 우선 카테고리를 선정해야 한다. 여러 자료들을 조사하니 게임이나 엔터테인먼트 분야가 소위 ‘대박’ 기회가 많다는 것을 알았다. 하지만 필자는 게임 쪽으로는 경쟁력이 없을 것 같아 숙고 끝에 ‘productivity’ 분야를 택했다. 업무 효율성을 높여주는 유틸리티 분야다. 이 분야의 특징은 게임과 같이 대박은 나지 않지만 생명력이 긴 스테디셀러가 탄생할 수 있다는 것이다.

구체적 기획, 셀링포인트 확정
이렇게 분야는 productivity로 정했으니 구체적인 프로그램 기획을 해야 했다. 필자는 소위 ToDo 리스트라는, 해야 할 일들을 쭉 적어놓고 관리하는 프로그램을 개발하기로 결정했다.

여기서 시장 조사를 조금 해 봤다. 앱스토어에는 이미 많은 ToDo 리스트 관련 프로그램들이 있었고, 어떤 것은 상당히 많이 판매되는지 꽤 높은 순위를 차지하고 있었다. ‘이것 혹시 레드오션 아닌가?’. 하지만 이제 막 개발 역량을 갖추고 하루라도 빨리 앱스토어에 프로그램을 올리고 싶은 욕망 앞에 레드오션도 오션이었다. 그래서 그냥 ToDo 리스트 비슷한 것으로 정했다. 대신 본인만의 셀링포인트(광고나 마케팅 시 특별히 강조할 상품이나 서비스의 특징)가 없으면 안 됐다.

필자의 프로그램의 셀링포인트는 마크 트웨인의 말에서 영감을 얻었다. 톰 소여의 모험 등의 작품으로 우리나라 사춘기 청소년들로 하여금 한 번쯤 동네 뒷산에서 동굴 찾기를 시도하게 했던 그 분의 말이 있다. “왜 일을 당장 시작하지 못하고 계속 미루는지 아는가? 그건 일이 너무 복잡해 보여서야. 그 일을 아주 작은 일들로 쪼개고 나서 하나하나 해 가면 할 수 있지”.

예를 들어, 책을 읽고 독후감을 써야 하는 것이 나의 ToDo라고 하자. 그런데 할 일에 ‘독후감쓰기’라고 덩그러니 적어 놓으면, 이 핑계 저 핑계 대면서 미루기만 하고 당장 그 일을 시작하지는 못한다. ‘독후감 쓰기’가 되려면 책을 선택해 읽고 초안을 써야하는 것은 물론 고치기를 반복해야 하는 등 해야 할 일이 굉장히 많은 것처럼 느껴지기 때문에 선뜻 시작하지 못하는 것이다. 하지만 그것을 책 고르기, 10페이지 읽기, 그 다음 10페이지 읽기 등의 작은 일들로 쪼개 놓으면 최소한 시작은 할 수 있다. 책을 고르기만 하면 되니 말이다.

그래, 바로 이것이었다. 기존의 ToDo 리스트 개념에 ‘일 쪼개기’ 컨셉을 접목시켜 프로그램의 셀링포인트로 하기로 했다. 해야 할 일들을 리스트로 보여주되 각 일들 옆에 ‘망치’ 아이콘을 붙여  그 일을 좀 더 많은 일들로 쪼갤 수 있도록 하는 것이다.

설계·구현, 디자이너와 협업도…
본격적으로 프로그램의 설계 및 구현에 돌입했다. 이 과정에서 앞에서 언급한 서적 『Beginning iPhone Development』의 9장 <Navigation Controllers and Table Views>의 예제코드를 참조해 근간을 잡았다. 중간에 막히는 부분에서는 Addison-Wesley의 『The iPhone Developer’s Cookbook』의 예제들을 참조했다. 이 책은 초보자가 보기에는 무리가 있다. 하지만 어느 정도 아이폰 프로그램을 이해하고 있는 개발자라면 가끔씩 ‘이것을 어떻게 해야 하나’하고 막히는 부분에서 찾아보기엔 좋다(이 책 역시 필자와는 아무런 관계가 없다).

프로그램을 구현하며 가장 힘들었던 것은 아이콘을 손수 만들었던 부분이다. 사실 이 부분이 개발자들에게 아주 어려울 수 있다. 때문에 그래픽 디자이너들과 손잡고 일할 필요가 있을지도 모르겠다. 얼마 전 앱스토어에 탱크게임 비슷한 것을 제작해 크게 성공한 우리나라 개발자도 회사 동료 디자이너와 함께했다고 하지 않는가. 이런 면에서 앱스토어 프로그램 개발은 학생들에게 서로 다른 전공의 친구들과 협업하는 것을 배울 수 있는 좋은 기회이기도 하다

 

사용자 삽입 이미지

이렇게 필자의 첫 번째 프로그램인 ‘NextAction’을 완성했다(<화면 1> 참조). 일을 쪼개 다음 단계(Next)에 해야 할 일(Action)이 무엇인지 결정하도록 하겠다는 의도에서 그렇게 작명했다. 이제 앱스토어에 올려야 하는데, 프로그램의 설명글이 필요했다.

사람들이 앱스토어에 올려진 프로그램들을 볼 때 가장 먼저 보는 것이 스크린샷이고, 조금이라도 흥미가 있으면 설명글을 읽게 되는데, 여기서 구매여부가 결정날 것이다. 그러니 설명글을 최대한 매력적으로 작성하는 것이 중요하다. 즉, 기획과 개발이 끝나고 이제 마케팅 단계가 온 것이다. 앞서도 언급했지만 NextAction의 셀링포인트는 분명하다. 설명글을 작성할 때도 마크 트웨인이 직접 나서서 도와줬다. 뭐라고 썼는지 궁금하다면 앱스토어에서 NextAction으로 검색해 보면 된다(^^).

가격 책정, 대담한 결정
마지막 단계는 가격결정이었다. 앱스토어 프로그램들의 가격이 대부분 $0.99인 상황에서 필자는 소위 ‘명품’ 컨셉을 채택하기로 하고 NextAction의 가격을 $3.99로 정했다. 이렇게 비싼 축에 속하는 가격을 책정하면 판매가 되지 않을 위험이 있지만, 필자는 다음과 같은 세 가지를 염두에 뒀다.

● 하나만 팔아도 $0.99짜리 4개를 판 것과 같으니 얼마나 좋은가.
● 높은 가격에서 시작해야 가격을 내릴 여지가 있을 것 아닌가.
● NextAction과 같은 프로그램의 주 소비자층은 분명 자기관리에 관심이 많은 30~40대 일 것인데, 그들은 업무 효율성이 높아지고 자기관리에 유용하다면 가격에 크게 구애받지 않을 것이다.

‘만약 내 예상이 틀리다면?’이라는 걱정도 해 봤다. 하지만 그렇다고 해도 뭔가 배우는 게 있으니 좋지 아니한가?

신고




     개발, 개발자, 드리밍 인 앱스토어, 마소, 마이크로소프트웨어, 블로그, 아이팟, 아이폰, 앱스토어, 호랭이
     0   1
BlogIcon 우치타 2009.12.14 08:04 신고
멋지십니다! app store 에 나오면 알려주세요 ^^

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

 

 

소프트웨어 개발 방법론의 함정
+   [마이크로소프트웨어]   |  2009.11.27 10:36  


소프트웨어 개발 프로젝트에서는 최신 유행하는 헤어스타일이나 옷을 입는다고 나 자신이 유명 연예인처럼 보일 수 없는 것 만큼이나 당연한 법칙이있다. 아무리 유명하고 좋다는 소프트웨어 개발 방법론을 적용해 보아도 성공적인 도입이나 효과를 보기가 어렵다는 사실이다. 그렇다면 개발 방법론따위는 신경쓰지 않는 편이 옳은걸까? 헤어 스타일이나 옷을 입는데에도 본인과 적당한 코디를 해야 자신을 돋보이게 할 수 있는 것처럼, 개발 방법론도 자신이나 팀의 상황에 맞춰 잘 코디하면 더욱 좋은 효과를 거둘 수 있는 건 아닐까? 여기 자신의 오랜 컨설팅 경험을 통해 쌓은 노하우를 한 큐에 알려주겠다는 이가있다. 개발 방법론의 도입과 적용에 대한 고민을 하고 있는 개발자들에게 도움이 되길 바란다.

아이마소 | www.imaso.co.kr

체계화된 프로세스와 산출물들로 무장한 개발방법론은 회사에 필요한 이상적인 무기를 제공해줄 것 같지만, 개발방법론을 도입해 크게 효과를 본 회사를 찾기는 쉽지 않다. 개발방법론이 개발을 더 지연시키고 개발자들을 번거롭고 힘들게 한다고 하기도 하고 개발방법론을 도입해서 사용하다가 포기하고 다른 방법들을 기웃거리기도 한다. 왜 이렇게 성공적으로 개발방법론을 도입하는 것이 어렵고, 개발방법론을 효과적으로 소프트웨어 개발에 적용하기 위해서는 어떻게 해야 하는지 알아보자.

전규현 gracegyu@gmail.com|데스크톱, 네트워크, 시큐리티 등 다양한 소프트웨어 개발 분야에서 15년 이상의 경험을 쌓았다. 한글과컴퓨터, 안철수연구소 등에서 소프트웨어엔지니어 및 프로젝트관리자로 지냈다. 현재는 소프트웨어 경영/개발 컨설턴트로서 많은 소프트웨어 회사들에게 소프트웨어의 효율적인 개발 방법을 전파하고 있다. 직접 운영하고 있는 소프트웨어 공학 블로그(http://allofsoftware.net)를 통해 효과적이고 실전적인 소프트웨어 공학 경험을 블로거들에게 공유하고 있으며, 저서로 『소프트웨어 개발의 모든 것(페가수스, 2008)』이 있다.

독자들 중에서도 개발방법론들을 경험해 본 사람들이 꽤 있을 것이다. 실제로 개발방법론을 경험해 봤다면 그 개발방법론이 실제 소프트웨어를 개발하는 데 얼마나 도움이 되었는지 묻고 싶다. 즉, 이전에 나름대로의 방법으로 알아서 개발하던 때와 비교하면 얼마나 나아졌는지 묻고 싶다. 진짜 개발이 더 빨라지고 생산성이 높아졌는지? 아니면 개발은 오히려 느려졌고 과거보다 번거로울 뿐이지만 그래도 문서를 남겨야 나중에 정보 공유가 가능하니까 따르는 것인지 묻고 싶다.
필자는 소프트웨어 개발 컨설턴트로서 여러 개발자들이 이러한 질문에 답변하는 내용을 들을 기회가 많다. 그 중에 개발방법론은 고객이 요구하기 때문에 어쩔 수 없이 적용한 경우가 많았고, 실제로 개발하는 데는 필요도 없는 문서를 많이 만들어야 했으며, 그로 인해 개발에 더 많은 시간이 소요되었다는 얘기를 종종 듣게 된다. 하지만 회사에서 시키기 때문에 억지로 하곤 한다고 말한다. 시중에 개발방법론은 넘쳐나는데 왜 개발방법론을 적용해 큰 효과를 봤고 개발 생산성이 크게 향상되었던 경험을 접하기가 어려운 것일까?

개발방법론은 필요하다

회사가 작을 때는 소프트웨어를 개발하는 데 있어서 대부분 확실한 개발 체계 없이 시작한다. 대부분의 경우 이렇게 주먹구구식으로 또는 가내수공업 형태로 소프트웨어 개발을 시작해도 별 문제가 없다. 체계가 없다는 것은 소프트웨어를 개발하는 데 문서를 제대로 만들지도 않고, 정형화된 프로세스 없이 개발자들의 경험에 의해 주먹구구식의 절차를 통해 별도의 개발 시스템 없이 순전히 개발자들의 기억력과 약간의 기록만 가지고 개발하는 것을 의미한다. 그렇게 개발하더라도 대부분 큰 문제에 봉착하지 않는다. 대부분의 정보라는 것도 그리 방대하지도 않아서 개발자들의 머릿속에 잘 저장되어 있고, 시스템도 그리 복잡하지 않아서 몇몇 소수의 개발자들이 머리를 맞대고 개발해도 별 문제가 없다. 또 충성심 가득한 개발자들은 회사에 언제까지나 있을 것 같고, 문제가 발생하면 특공대처럼 문제를 빠르게 해결한다.

이러한 시기에는 오히려 주먹구구 방식이 훨씬 빠르고 비용이 적게 든다고 생각할 수 있다. 실제로 이런 개발 방법이 여타 개발방법론을 적용한 개발 방법보다 효율이 더 높은 경우도 있다. 소수의 개발자에게 너무 많은 부분을 의존하고 있는 이런 방식은 장점인 것처럼 보이지만, 사실은 대단히 큰 위협요소가 된다.

성장하는 회사는 조직이나 소프트웨어의 규모가 점점 커지고, 개발해야 하는 제품의 수와 개발자는 점점 늘어가고, 더 이상 주먹구구식으로는 개발이 어려워진다. 회사는 점점 성장하는데 여전히 주먹구구식으로 개발하고 있다면 개발 과정은 점점 혼란스러워지고 설상가상으로 대부분의 정보를 머릿속에 담고 있는 개발자가 퇴사를 하기도 한다.

개발방법론은 이렇게 소수의 개발자에 편중되어 있는 대부분의 리스크를 시스템적으로 커버할 수 있도록 한다. 문서도 만들어야 하고, 프로세스도 따라야 하기 때문에 당장에는 기존의 주먹구구식의 방식보다는 시간도 많이 들어가고 비용도 많이 들어가는 것처럼 보이지만, 그 대가로 리스크를 줄일 수 있다.

모험심이 가득한 벤처 회사라면 얼마든지 리스크를 감수할 수 있겠지만, 회사가 점점 커지면 리스크보다는 비용을 선택하게 되어 있다. 따라서 주먹구구식으로 시작한 소프트웨어 회사라도 규모가 커지면 자연스럽게 개발방법론에 눈을 돌리게 된다.

이렇게 개발방법론을 시도해보기 위해 개발방법론 도입을 도와주는 컨설팅회사에 의뢰를 하기도 하지만, 대부분은 인터넷이나 책을 통해 개발방법론을 배워보려고 시도한다.

개발방법론을 공짜로 배울 수 있을까?

개발자들은 인터넷에서 수많은 소스 코드 샘플을 보고 개발에 활용해 왔듯이, 개발방법론도 인터넷에서 특정 개발방법론의 템플릿과 샘플 그리고 프로세스를 가져와서 따라하면 개발방법론을 그럴싸하게 흉내 낼 수 있을 것으로 생각하기도 한다. 하지만 실제로 따라해보면 생각만큼 잘 되지 않는 것이 사실이다. 일단 기존에 주먹구구식으로 개발하던 개발자들은 개발방법론에서 제시하는 템플릿을 보게 되면 생전 처음 보는 내용도 많을 뿐더러 왜 그러한 것이 필요한지 진짜 의미를 이해하기 어렵고, 어떻게 작성해야 하는 것인지 파악이 잘 안 되는 것이 일반적이다. 그리고 이것이 정말로 자신의 회사에서 필요한 것인지 또는 필요 없는 것인지 판단이 안 되기도 한다.

그래서 일단 이것저것 시도를 해보고 효과가 신통치 않으면 나중에 “그거 해봤는데 별로더라”라는 자신만의 편협한 평가를 내리기도 한다. 이러한 서투른 시도는 개발방법론에 대한 나쁜 인식만 키워주기 때문에 아니 한 만 못하다.

여러 개발방법론에서 제시한 문서들이 작성하기 부담스럽다고 문서를 적게 작성해도 된다는 XP, 애자일(Agile) 등에 쉽게 눈을 돌리곤 하는데, 이 또한 너무 쉽게 접근해 실패하는 경우도 많다. XP 방법론이 모든 종류의 소프트웨어를 커버하는 것은 아니지만, 나름대로 적절하게 쓰이면 훌륭한 개발방법론인 것은 사실이다. 하지만, 왠지 간편해 보인다고 만만하게 접근하다간 큰 코 다칠 수 있다. 소프트웨어를 개발하는 데 있어서 가장 어려운 것 중에 하나가 무엇을 만드는지 결정하는 일이다. XP 방법론에서는 이러한 스펙 작성의 어려움을 덜고자 다른 접근을 하는데, 이것이 마치 스펙을 작성하지 않아도 되고, 문서를 적게 만들어도 되기 때문에 개발자들에게는 최고의 개발방법론인 것처럼 생각할 수도 있지만, 그리 만만한 것은 아니다. 스펙 대신 테스트를 이용하고 있지만, 이 또한 공짜로 되는 것은 아니다. 기존에 이미 분석 능력을 가지고 있고, 유닛 테스트(Unit test)에 능통한 경우라면 무리 없이 받아들일 수 있지만, 주먹구구 방식에 익숙한 경우라면 이 또한 어려운 도전이 될 수 있다.

즉, 그냥 쉽게 배우고 프로세스, 템플릿을 좀 익혀서 개발방법론을 제대로 적용해 보기는 어렵다. 공짜로 배워보기에는 개발방법론은 그리 만만하지 않다.

몸에 맞지 않은 개발방법론이 문제

그렇다고 컨설팅을 통해 개발방법론을 도입하는 경우도 그렇게 쉬운 것은 아니다. 여기에는 몇 가지 함정들이 도사리고 있다. 자칫하면 이론에 치우치기 쉽고 회사의 역량이나 규모에 걸맞지 않은 무거운 개발방법론을 도입하게 되기도 한다. 개발방법론을 도입하려는 회사는 어떤 개발방법론이 자신의 회사에 알맞은지 직접 판단하기 어려우므로 외부의 전문가의 판단에 의존하는데 외부의 전문가가 실전 경험이 부족한 경우 회사의 특징과 역량 수준을 고려하지 않고 거대 개발방법론을 기계적으로 도입할 수 있다. 이 경우 큰 Learning Curve를 겪게 되고 결국 이를 극복하지 못하고 실패할 가능성이 높다. 따라서 자신의 회사에 알맞은 수준의 개발방법론을 선택해야 하는데, 이렇게 몸에 딱 맞는 개발방법론을 선택하는 것도 쉬운 일은 아니다.

또, 개발방법론을 하나 정해 놓고 회사의 모든 프로젝트에서 그 개발방법론을 무조건 따르게 하는 것도 문제다. 모든 프로젝트는 그 성격이 다른데, 하나의 개발방법론을 무조건 따르게 되면 간단한 프로젝트에서도 과도한 비용을 지불해야 한다. 이는 개발방법론이 자칫 관료화되는 것을 조심해야 한다는 뜻이다. 애초에 개발방법론을 도입한 이유를 망각하고 관리자나 프로세스 부서에서는 무조건적인 강요로 효율성을 떨어뜨리는데, 애초에 개발방법론을 도입할 때 유연하게 적용을 할 수 있는 여지를 남겨 둬야 할 것이다.

방법론의 목적은 효과적인 개발

소프트웨어 개발방법론의 근본 목적은 소프트웨어를 빠른 시간 안에 적은 비용을 들여 요구되는 품질의 소프트웨어를 만들어내는 것이다. 이런 과정에서 개발자들이 혹사되어서는 안 되며 개발자들은 자연스럽게 소프트웨어 전문가로서의 능력이 향상되어야 한다. 즉 프로젝트도 성공하고 개발자에게도 도움이 되어야 진정한 방법론인 것이다. 그렇지 않고 단순히 절차를 지키기 위한 방법론, 개발자는 희생하면서 프로젝트만 어떻게든 성공하기 위한 방법론은 반쪽짜리일 뿐이다. 그럼에 불구하고 개발방법론은 왠지 무겁고 형식적이고 소프트웨어를 개발하는 데 진짜 도움은 되지 않는다는 생각들은 개발방법론 시도 실패에 대한 반작용으로 생겨난 경험담들 때문이다.

국내 현실은 도 아니면 모
국내 대부분의 소프트웨어 회사는 소프트웨어를 개발하는 방법에 있어서 아래 세 가지의 부류로 나눌 수 있다.

첫째, 주먹구구식으로 소프트웨어를 개발하는 회사. 특별한 프로세스 없이 개발자들의 경험에 의존해 자체적으로 약간의 문서를 만들면서 소프트웨어를 개발하고 있는 회사. 주로 작은 회사들이며 개발자가 100명 이상인 중견 기업들도 상당히 많은 회사들이 이 단계에 머물러 있다.

둘째, 거대 방법론을 도입해서 흉내 내는 회사. 이 경우도 상당수가 내부적으로는 주먹구구이나 형식적으로는 방법론을 따라하고 있다. 주로 대기업에 해당하며 이들 기업은 개발 효율성보다 리스크 감소에 더 관심이 많으며 개발자들보다 회사의 힘이 압도적으로 크므로 추진력 강하게 이러한 개발방법론을 도입할 수 있고, 이러한 무리한 도입 과정에서 벌어지는 비효율성은 개발자들이 요령껏 편법을 이용해 피해가는 경우가 많다. 즉, 내용보다는 형식에 치우친 경우라고 할 수 있다. 이 경우 리스크는 줄어드나 개발 효율성도 따라서 줄어들어 일정 수준 이상을 넘을 수가 없다.

셋째, 거대 방법론이 회사에 맞지 않음을 깨닫고, 다시 주먹구구 개발방법으로 되돌아 온 회사. 그러면서 다른 방법이 없을까 고민하고 있는 회사들이다. 이런 실패의 경험이 반복될수록 내부에 불신이 쌓여가므로 쉽게 새로운 시도를 못하고 주먹구구와 개발방법론 사이를 떠도는 경우이다.

물론 이 세 부류에 속하지 않은 회사들도 있다. 그런 회사들은 스스로를 잘 알고 있으므로 별도로 언급할 필요가 없을 것이다. 그리고 그런 회사는 그리 많지 않다. 첫째와 셋째는 ‘도’에 해당하고 둘째는 ‘모’에 해당하는 경우이다. ‘도’도 바람직하지 않고 ‘모’도 소프트웨어를 개발하는 데 비효율적이다. 가장 좋은 경우는 ‘개’나 ‘걸’처럼 회사의 규모와 개발자들의 역량이 같이 성장해 나가면서 그 단계에서 딱 필요한 것들을 차근차근 하나씩 도입해 나가면서 내재화시켜 나가는 것이다.

뭐든지 단계가 있는 법
뭐든지 배우려면 그 단계가 있고, 차근차근 배우고 익혀나가야 한다. 예를 들어서 골프를 배우고 싶다면 어떻게 될까? 소프트웨어를 취미로 개발하고 있는 것은 아니므로 골프로 프로 선수가 되는 것을 목표로 삼는 경우를 예로 들어보자.

골프를 처음 배워나가면서 타이거 우즈가 공을 치는 방법이 가장 완벽하다고 해서 그 방법을 그대로 따라하기란 불가능하다. 타이거 우즈가 그렇게 공을 치기까지는 십 수 년의 훈련이 필요했고, 타이거 우즈에 가장 알맞은 방법으로 진화해 온 것이다. 그런데 타이거 우즈가 그 방법으로 세계에서 가장 골프를 잘 치는 사람이 되었다고 그것을 그대로 흉내 내는 것은 어리석은 짓이다. 사실 그대로 흉내 내는 것 자체도 불가능하다. 타이거 우즈와 똑같이 치는 방법을 책을 쓰면 책 한 권은 넘을 것이다.

하지만 타이거 우즈는 그 방법을 일일이 생각하면서 공을 치지 않는다. 그 방법이 몸에 익었을 뿐이다. 그냥 공을 치면 저절로 되는 것이다. 이를 ‘내재화’가 되었다고 한다. 그 최고의 방법을 모델로 놓고 그대로 따라하고 훈련한다고 해서 그 방법을 익힐 수 있는 것은 아니다. 그러한 단계로 가기 위해서는 기초부터 배워나가는 방법이 따로 있을 것이다. 또 우리 몸에 맞는 모델은 타이거 우즈의 방법이 아닐 수도 있다. 그런데 최고의 방법이 타이거 우즈의 방법이라고 따라하는 것은 무리한 시도이며 대부분 포기하게 될 것이다.

진짜 프로골퍼를 목표로 하고 골프를 배우고 있다면 타이거 우즈가 골프를 치는 것을 그대로 따라하는 것이 좋은 방법이 아님을 누구나 알 수 있을 것이다. 재미로 마구 골프를 쳐보다가는 평생 프로선수가 되지 못할 것이다. 누구나 상식적으로 생각해도 아주 기초부터 차근차근 훈련을 받아나가야 한다는 것을 알 수 있을 것이다.

그런데 소프트웨어 세상에서는 이런 섣부른 시도들이 종종 발생한다. 개발자들의 역량은 아직 기초 수준인데 세계 최고의 방법론들을 도입해서 시도하면 개발자들도 저절로 세계 최고의 역량을 갖출 수 있을 것으로 착각하는 것 같다.

개발방법론이 가르쳐주지 않는 것
개발방법론은 소프트웨어 회사라면 당연히 갖추고 있어야 하는 것은 가르쳐주지 않는다. 즉, 소스 코드를 어떻게 관리하고, 버그는 어떻게 추적할 것이며, 빌드/릴리즈는 어떻게 할지는 크게 상관하지 않는다.

하지만, 이러한 것들이 아직 체계적으로 갖춰지지 않는 회사가 개발방법론을 도입한다고 하면 따라가기만 하는 것도 벅차고 성공적으로 내재화되기는 어려울 것이다. 축구팀이 기초 체력은 갖추지도 못하고 기본적인 드리블이나 슛 실력이 부족한 상태에서, 다양한 전술과 전략을 익혀봤자 말짱 허사일 것이다. 여기서 말하는 기초 역량은 개발자에게 있어서 설계, 코딩 능력을 말하는 것은 아니다. 우리나라 개발자들의 코딩 능력은 전 세계 어디 내놔도 손색이 없을 만큼 뛰어나다. 여기서 말하는 기초 역량은 소프트웨어 회사라만 기본적으로 갖춰야 할 요소들과 설계, 코딩을 제외한 소프트웨어 전문영역의 다양한 지식들을 말한다. 이러한 것들은 워낙 당연한 것들이기 때문에 개발방법론을 만든 사람들은 소프트웨어 회사라만 당연히 보유하고 있어야 하는 것으로 생각한다.

방법론에서는 그러한 것들은 너무나 당연한 것이라 어떤 방법을 사용하든 별 개의치 않는 경우가 많기 때문에, 그러한 기초조차 제대로 갖추고 있지 않은 소프트웨어 회사라면 현재의 수준을 자각하지 못하고 자칫 그럴듯하게 포장된 방법론만 눈에 들어올지도 모른다. 이런 경우 방법론은 공염불이 되기 십상이다. 방법론을 고민하기보다는 기초부터 다져야 하는 경우이다.

개발자들의 역량

기초란 회사에만 적용되는 것은 아니다. 개발자들도 개발방법론을 따라 개발하기 위해서는 필요한 역량이 있다. 가장 먼저 방법론 하면 산출물이 떠오르는데 대부분의 개발자들은 문서를 작성하는 데 익숙하지도 않고 그보다 먼저 문서 작성을 싫어한다. 이러한 상황에서 템플릿만 잔뜩 제공하고 이를 만들어내라고 하면 보통 괴로운 일이 아니다.

그럼 이쯤에서 의문이 생긴다. 과연 개발자가 문서를 잘 작성한다는 것은 무엇을 말하는 것인가? 개발자들 스스로도 본인이 문서를 잘 작성하고 또 잘 작성할 능력이 있는지 알지 못하는 경우도 많다. 개발자들의 문서 작성 능력을 한번에 알아내기는 어렵지만, 아래와 같은 질문을 해보고 싶다.

소프트웨어를 개발하면서 문서를 만드는 이유가 무엇이라고 생각하는가?

1. 고객이 원해서
2. 나중에 유지보수를 위해서
3. 개발 시간과 비용을 단축하려고

이 중에서 1이나 2라고 답하는 사람들은 아직 문서를 제대로 작성할 능력이 낮을 가능성이 높다. 그 동안 문서를 형식적으로 작성해 왔거나, 문서 작성을 거의 하지 않고 개발을 해오면서 문서는 거추장스러운 것이라고 생각하고 있는 경우가 많을 것이다. 이런 상태라면 개발방법론은 정말 거추장스러운 방해밖에 될 수 없다. 3번이라고 자신 있게 답할 수 있는 사람들은 개발하면서 문서들도 진정 필요한 시점에서 필요한 내용으로 작성했을 것이고, 그렇게 오랜 시간 훈련이 되어 필요한 문서 작성에 능숙할 것이다. 하지만 이렇게 3번이라고 자신 있게 답할 수 있는 개발자들이 많지 않은 것이 현실이다.

방법론에서 만들어내는 수많은 문서들은 문서 자체가 목적이 아니다. 모든 문서들은 다음 작업을 진행하는 데 필요하기 때문에 만드는 것이다. 따라서 다른 개발자들이 내가 만들어 놓은 문서들을 보고 그 다음 작업을 진행할 수 있어야 한다. 즉, 내가 작성한 스펙문서를 보고 설계를 담당한 개발자는 설계를 할 수 있어야 한다. 또 테스트팀은 테스트 계획과 테스트 케이스를 만들어낼 수 있어야 한다. 그리고 기술문서팀(Techpub)에서는 스펙문서만 보고도 매뉴얼을 작성할 수 있어야 한다. 또한 빌드/릴리즈팀에서는 빌드 준비를 할 수 있어야 한다. 하지만, 분석 역량이 부족한 개발자에게 템플릿만 제공해 스펙문서를 만들어 낸들 제대로 설계가 가능하고 테스트 케이스를 만들어 낼 수 없다.

그리고 방법론을 도입하고 약간의 교육으로 그런 수준까지 역량을 끌어올리기는 어렵다. 오히려 거대한 방법은 역량을 차근차근 끌어올리기에는 거추장스러운 옷처럼 방해 요소가 될 수 있다. 차라리 방법론 전체보다는 각 회사에 필요한 기초적인 부분을 추출해 조금씩 적용하는 것이 좋을 것이다. 그러한 과정을 거치면서 개발자들의 역량도 같이 키워나가야 한다. 여기서 필요한 것은 분석, 설계, 프로세스, 형상관리, 테스트 등 개발에 필요한 다양한 것들이다. 이러한 지식과 경험은 하루 아침에 배운다고 익힐 수 있는 것이 아니고, 회사에서 일하면서 조금씩 쌓아 나가는 것들이다. 또한 개발자 혼자서 스스로 익힐 수 있는 것도 아니고, 회사와 같이 개발 업무를 해나가면서 계속 배우고 익혀나가야 하는 것들이다.

잘못 사용되는 개발방법론

개발방법론을 사용하는 이유가 고객이 해당 개발방법론을 적용하기를 원해서인 경우가 종종 있다. 이러한 경우 고객들도 목적이 개발방법론은 아니지만, 소프트웨어 개발에 대한 전문지식이 모자라므로 회사의 규정에 의해서든 여러 연유로 인해 개발방법론 적용을 요구하게 된다. 이 과정에서 개발방법론을 효과적으로 추려내서 적용하지 못하고 전체를 그대로 적용해 달라고 요청하는 일이 발생한다.

고객은 개발방법론 교과서에 나온 대로 기계적으로 산출물과 프로세스를 요구하고 소프트웨어 개발사는 비효율적인 것을 알아도 고객이 원하므로 울며 겨자 먹기 식으로 무조건 따라야 하는 경우가 많다. 하지만 우리나라 개발자들이 어떤 개발자인가. 모든 난관은 헤쳐 나가는 방법이 있다. 방법론에서 요구하는 문서는 어쨌든 만들어내고 있다. 다양한 편법을 통해 문서를 만들어 내고 있고, 대부분의 경우 문서들이 실제 소프트웨어를 개발하는 데 도움이 되지 않더라도 고객이 요구하는 문서는 충족하고 있다. 이렇다 보니 문서 작업은 소프트웨어를 개발하는 데 도움이 되기는커녕 시간만 축내는 낭비요소가 되곤 한다. 하지만 고객의 요구사항이기 때문에 따르는 수밖에 없다.

그 결과, 이렇게 만들어 낸 산출물은 고객에게도 실제로는 아무런 쓸모없이 책꽂이만 차지하는 경우가 허다하고 개발자들은 방법론에 대한 부정적인 생각만 키워나가게 된다. 이렇게 잔뜩 만들어낸 산출물은 유지보수 시 매우 유용하게 사용될 것으로 홍보하지만, 막상 유지보수 때는 개발에 참여했던 개발자를 찾게 되고 문서보다도 소스 코드를 가지고 유지보수를 하게 된다. 이런 것들이 반복되면 개발자들은 개발방법론이란 형식적이고 실제 소프트웨어를 개발하는 데는 별 도움이 안 된다고 생각하게 되고 진짜 제대로 된 방법을 더욱 더 배우기 어렵게 만든다.

고객의 무리한 개발방법론 적용 요구

개발 회사는 아무리 개발방법론을 효과적으로 적용하려고 해도 이렇게 고객이 기계적으로 또는 규정에 의해 무리하게 개발방법론을 요구하는 경우에는 어쩔 도리가 없다. 실제로 고객이 개발방법론을 콕 찍어서  **CBD 또는**OOP 방법론을 요구하기도 하는데, 고객을 잘못 만나면 30~40종류 이상의 산출물을 에누리 없이 만들어 내야 하는 경우도 있다. 또 마일스톤마다 산출물을 검사하기도 하기 때문에 프로젝트가 끝나고 밤샘해서 산출물을 만들어 낼 수도 없는 노릇이다.
이러한 경우에는 진짜로 소프트웨어를 잘 개발하기 위해 필요한 문서와 고객의 요구 때문에 어쩔 수 없이 만들어야 하는 문서를 구별할 필요가 있다. 사실 웬만한 규모의 소프트웨어까지는 주요 문서 2, 3개로 충분히 프로젝트를 진행할 수 있고, 그 외의 문서들은 가능하면 최소한의 노력으로 고객의 요구를 만족시켜주는 수준으로만 만들어주는 것이 가장 효율적일 것이다.

이러한 상황에서 진짜 개발에 필요한 문서와 고객의 요구 때문에 어쩔 수 없이 만드는 문서의 구별이 없다면 자칫 모든 문서가 형식적으로 작성될 수도 있다. 이 과정에서 개발자들은 모든 문서에 대한 거부감만 커지고, 방법론을 제대로 적용한 것 같지만 실제 개발은 주먹구구와 다름없게 될 수도 있다. 아니 오히려 주먹구구에다가 문서를 잔뜩 만들어야 하므로 주먹구구만도 못한 경우가 될 수도 있다.

방법이 목적인 개발방법론
이쯤 되면 개발방법론이 진짜 필요한 것인지 오히려 개발을 방해하는 것인지 헷갈리기도 한다. 하지만 서두에서 말했다시피 개발방법론의 목적은 소프트웨어를 적은 비용으로 짧은 시간에 효과적으로 개발하는 데 있다. 하지만 개발방법론을 만든 사람들의 진짜 목적은 돈을 버는 것이다. 방법론을 팔아서 돈을 버는 회사들은 자신들의 개발방법론을 비싸게 많이 팔아야 한다. 그리고 누구나 쉽게 흉내 낼 수 없게 만들어야 한다.

그래서 자신들의 개발방법론을 다른 방법론들과 차별화하기 위해 노력하고 점점 복잡하게 만들게 된다. 그래야 아무나 따라할 수 없게 되고 또 더욱 비싼 값에 팔 수 있다. 이러다 보니 소프트웨어 업계에는 소프트웨어를 개발하는 수많은 개발방법론들이 넘쳐나고 점점 복잡해지고 있다. 그 반작용으로 간단하다고 어필하고 있는 개발방법론이 출현하기도 한다.

이렇게 되니 대부분의 개발방법론 자체가 잘못된 것은 아닐지라도 우리 회사에 알맞은 개발방법론을 찾기란 쉬운 일이 아니게 돼 버렸다. 오히려 잘못된 함정에 빠지기 쉬운 상황이 된 셈이다.

특히 이전에 어느 정도 경험과 기초가 되어 있는 회사들은 개발방법론을 바라볼 때 어느 정도의 판단 능력을 가지고 자신의 회사에 필요한지 그렇지 않은지 판단할 수 있겠지만, 주먹구구에서 시작한 대부분의 소프트웨어 회사들은 그저 혼란스럽기만 할 것이다.

어떻게 해야 하나?

필자의 경험에 의하면 국내의 많은 소프트웨어 회사들은 거대 개발방법론을 당장 도입하기에는 아직 적당한 상황이 아니다. 개발방법론을 거론하기 이전에 소프트웨어 회사라면 필수적으로 갖춰야 할 조직과 시스템을 먼저 갖추고 회사에 필수적인 프로세스를 만들어가면서 회사와 개발자 모두 필수 역량을 갖출 때쯤 그리고 회사가 좀 더 크고 복잡해지면 방법론을 생각해보는 것이 좋겠다.

또, ‘자전거’를 만드는 회사에서 ‘우주선’을 만드는 방법론을 사용해서는 안 된다. ‘자전거’ 정도의 소프트웨어를 만드는 수많은 국내 소프트웨어 회사들은 거대 개발방법론이 필요하지 않다. 고객이 요구해서 방법론을 꼭 적용해야 하는 경우가 아니고 자체적으로 소프트웨어를 잘 개발하는 것이 목적이라면, 회사에 알맞은 작고 가벼운 개발방법론이면 충분할 것이다.

럼 소프트웨어 회사가 갖춰야 할 필수 역량에는 무엇이 있는가? 가장 먼저 소스 코드 관리시스템, 버그 관리시스템, 빌드 자동화 등 기본적인 인프라스트럭처 시스템들은 갖춰야 한다. 물론 이것이 그렇게 쉬운 것은 아니다. 실제로 이들을 사용하는 많은 회사들이 기본적인 기능만 사용하고 있음에도, 전혀 이런 시스템들의 도움을 받지 않고 소프트웨어를 개발하고 있는 회사들보다는 훨씬 나은 형편이다. 이런 시스템들을 사용해 개발하다 보면 자연스레 그러한 시스템들에 묻어 있는 소프트웨어 개발 철학을 익히게 되고 기본적인 개발 프로세스도 배울 수 있게 된다.

또, 조직적인 측면으로는 소프트웨어 개발에 필수적인 전문 조직이 기본적으로 필요하다. 대부분의 소프트웨어 회사는 처음 시작하게 되면 개발자들이 전문성을 가리지 않고 온갖 일들을 다하게 된다. 개발도 하고 테스트도 하고 고객지원도 하고, 심지어는 영업을 하기도 한다. 하지만 회사의 규모가 커져 가는데 소수의 개발자들이 개발하던 방식과 똑같이 개발하고 있다면 효율성은 점점 떨어져 간다. 이럴 때는 꼭 필요한 부분부터 전문화된 팀으로 구분하고 전담자를 둬서 해당 분야의 전문성을 높이고 개발자는 개발에 집중할 수 있도록 해줘야 한다. 이러한 대표적인 분야는 테스트와 빌드/릴리즈다. 아직도 테스트를 전적으로 개발자들이 담당하고 있는 회사들이 많다. 개발자 10명만 있는 조직보다는 개발자 7명과 테스터 3명이 있는 조직이 더 효율적인 경우가 많다. 개발자들은 자신이 개발한 소프트웨어를 잘 테스트하지도 못하는데, 해당 소프트웨어의 스펙을 상세히 아는 사람이 개발자 밖에 없고 별도의 테스터를 뽑아도 개발자만큼 제품을 알아서 테스트하기 어렵다고 개발자에게 테스트를 계속 맡기는 것은 잘 하지도 못하는 일을 비싼 인건비를 주고 계속 맡기는 것과 같다.

테스트를 별도의 조직에 맡기는 것이 제품의 품질을 더 높여주고 비용 효율적이며 개발자는 개발에 더 집중할 수 있게 한다. 또 이와 더불어 빌드/릴리즈팀은 빌드/릴리즈 과정을 자동화하고 효율을 높임으로써 그 동안 보이지 않지만 많은 비용을 차지하던 것을 절약하면서도 개발을 더 원활하게 진행하도록 지원한다.
이런 회사의 기본 역량 확보와 더불어 개발자들은 문서를 작성하는 능력, 리뷰하는 능력, 분석 능력, 설계 능력 등 개발자들이 갖춰야 할 코딩 능력 외의 필수 능력들을 쌓아 나가야 한다. 이들은 학교에서 배울 수도 없고, 실무를 통해 오랜 시간에 걸쳐서 차근차근 쌓아 나가야 하는 것들이다.

이렇게 기본적인 조직, 프로세스, 시스템을 갖춰나가면 소프트웨어 회사가 내적으로나 외적으로 기본적인 역량을 갖추게 된다. 이쯤 되면 어떤 개발방법론을 접하더라도 이전보다는 조금 더 잘 이해할 수 있게 된다. <그림 1>과 같이 개발방법론을 성공적으로 도입하기 위해서는 소프트웨어 회사와 개발자들이 기초 역량을 갖추고 있어야 한다. 회사가 어느 정도 역량을 갖추고 판단력이 생기면 무작정 좋다고 하는 개발방법론을 도입하기보다는 회사의 수준에 알맞은 방법들을 취사선택해서 조금씩 받아들이는 방법을 택하게 될 것이다.

결국 개발방법론의 목적인 소프트웨어를 빠른 시간 내에 적은 비용으로 효율적으로 개발한다는 것에 좀 더 가까워질 수 있다.

신고




     개발, 개발자, 구글, 마소, 마이크로소프트, 마이크로소프트웨어, 방법론, 블로그, 소프트웨어, 아이마소, 컨설팅, 호랭이
     0   0

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

 

 

Windows 7 Application 개발 - 2, Task Bar API
+   [개발 이야기]   |  2009.08.11 19:43  


<정희재>

Windows 7 을 설치하고 나면 가장 먼저 눈에 띄는 것이 바로 화면의 가장 아래에 가로로 길게 뻗어있는 Taskbar일 것이다.

필자가 가장 먼저 알아차린 기존의 Windows들과의 차이점은 Taskbar가 차지하는 공간이 넓어진 것이었다. 하지만 사용을 하면 할수록 나도 모르게 Windows 7 의 Taskbar에 빠져들고 있음을 깨닫게 됨은 물론 Microsoft사의 사용자에 대한 배려를 옅볼 수 있게 되었다.


Windows 7 Taskbar에서 달라진 점들을 간단히 정리해 보면 다음과 같다.

  1. Thumbnail 기능



    해당 프로그램의 아이콘에 마우스를 위치시키면 해당 프로그램의 실행중인 화면의 Thumbnail을 추출하여 표시 해준다. 사용자는 Thumbnail을 확인하여 프로그램 활성화, 프로그램 종료 등의 작업을 일일이 프로그램을 열어보지 않고도 가능하게 해준다.

  2. Overlay Icons



    해당 프로그램의 상태에 따라 Taskbar에 표시되는 아이콘을 변경하여 사용자가 프로그램 창을 열어보지 않고도 한눈에 프로그램의 상태를 알아볼 수 있도록 해준다.

  3. Progress Bar



    Taskbar Icon에 Progress Bar를 적용할 수 있도록 지원하여 프로그램의 현재 진행상황을 다른 프로그램을 사용하면서도 확인이 가능하게끔 해준다.

  4. Thumbnail Toolbar



    Thumbnail 화면에 버튼을 추가하여 사용자가 프로그램을 띄우지 않고도 프로그램을 조작할 수 있도록 해준다.

  5. Jump List



    Taskbar 아이콘을 마우스 오른쪽 버튼으로 선택하면 Jump List를 화면에 출력하여 이전에 접근했던 파일들을 한번에 열어서 사용할 수 있도록 해준다.


ITaskBarList3
 

Windows7 Taskbar는 ITaskBarList3를 사용하여 접근이 가능하다.

ITaskBarList3 Instance를 생성하는 방법은 다음과 같다.  

ITaskbarList3* pTaskbarList;

HRESULT hr = CoCreateInstance(CLSID_TaskbarList, NULL, CLSCTX_INPROC_SERVER, IID_PPV_ARGS(&pTaskbarList));

if (SUCCEEDED(hr))

{

    //

}


SetOverlayIcon

 Overlay Icon을 적용하기 위해서는 ITaskBarList3의 멤버함수인 SetOverlayIcon 함수를 사용하면 된다.

Overlay Icon으로 사용할 icon을 만들어 놓은 후 다음과 같이 SetOverlayIcon 함수를 호출하면 Taskbar에 Overlay Icon이 나타나는 것을 바로 확인할 수 있다.  

HICON hIcon = NULL;

hIcon = AfxGetApp()->LoadIcon(IDI_ICON1);

pTaskbarList->SetOverlayIcon(m_hWnd, hIcon, NULL);

신고




     API, c++, Task Bar, 개발, 개발자, 블로그, 소프트웨어, 썸네일, 썸네일 툴바, 애플리케이션, 오버레이 아이콘, 윈도우7, 점프리스트, 테스크바, 프로그래스 바
     2   0

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

 

 

11월부터 보게 될 신형 저상버스
+   [아이티 이야기]   |  2009.02.09 07:52  





이 사진은 사진이라기 보단 그래픽 이미진데요.

그동안 저상버스가 운행되지 않던 광명과 안성, 구리, 동두천시에서 11월부터 이 버스가 운행될 예정이라고 합니다.

모양이 참 귀엽지 말입니다. ㅎ.ㅎ

경기도는 성남도 이 버스가 들어오면 좋겠네요.

한편 경기도는 기존의 저상버스가 너무 커서 도로 여건이 열악한 도심 주택 밀집 지역과 농어촌 지역에서는 운행하기 어렵다고 판단하고 이 지역에서도 사용할 수 있는 중형 저상버스도 개발중이라고 하네요.

근데 저상 버스의 기준은 뭘까요?

저상 버스는 바닥의 높이가 25~40cm로 버스 차체가 낮고 계단이 없는 버스를 말한답니다. 당연히 휠체어와 유모차 등으로 탑승할 수 있는 차로 정의하고 있답니다.
신고




     개발, 개발자, 경기도, 광명, 구리, 동두천시, 안성, 저상버스, 중형 저상버스
     0   8
BlogIcon 토와 2009.02.08 16:24 신고
빨리 이런 버스들이 많이 늘어야 할텐데 말입니다 ^^
BlogIcon 마소호랭이 2009.02.11 10:25 신고 
저런 귀여운 버스라면 끼어들기를 당해도 참아줄 만 하겠군요.
BlogIcon 즐거운하루이야기 2009.02.08 21:29 신고
모양이 귀여우면서도 산듯하네요!!
BlogIcon 마소호랭이 2009.02.11 10:26 신고 
일단 그래픽으로 만들어진 거라서... 실제로 나올 때는 막 접합부 있고 손때묻고 하면 어떨지...
BlogIcon 와이엇 2009.02.09 08:06 신고
모양이 예뻐서 인기 좋을것 같네요. 좋은 하루 보네세요.:)
BlogIcon 마소호랭이 2009.02.11 10:26 신고 
감사합니다.
BlogIcon ♥LovelyJeony 2009.02.10 00:58 신고
그래픽 이미지는 이미지일뿐..-ㅂ-;; 실물이 나오면 늘 판이하게 다르더라구효-;;
저상버스가 돌아다니기 전에 버스기사님들이 유모차나 휠체어를 기다려주는 매너와 쎈쓰를 갖는 프로의식이 생겨났음 좋겠습니당-ㅎ
BlogIcon 마소호랭이 2009.02.11 10:26 신고 
올쏘~~~~~~~~~~~~~~~

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

 

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

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

 

티스토리 툴바