태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

 

 

 

 
분류 전체.. (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
«   2021/10   »
          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
31            
+ ITViewpoint
+ 도이모이
+ with okgosu
+ 학주니닷컴
+ 열이아빠의 R⋯
+ Gsong.s Blog
+ 비주얼스튜디⋯
+ 광파리의 글⋯
+ LovedWeb
+ 블루오션의⋯
+ 울지 않는 벌새
+ PC 지존
+ 디지털통
+ 아크비스타
+ 고독한 프로⋯
+ Total : 2,100,930
+ Today : 0
+ Yesterday : 6
  

 

 

 

MSW _해당되는 글 13건
2009.10.09   모바일 게임의 어제와 오늘, 그리고 내일 
2009.09.30   개발자도 며느리도 모르는, 개발자 심리학 (10)
2009.04.21   로또 명당 마이크로소프트웨어??? (10)
2009.03.20   개발자가 행복해지는 세 가지 비법 (3)
2009.03.03   실패하는 프로젝트 만들기 (4)
2009.02.18   애자일 프랙티스의 실제 활용사례 (2)
2009.02.05   2009년에 주목할 IT 테크놀로지-3 [U-커머스] 
2009.02.03   2009년에 주목할 IT 테크놀로지-2 [모바일 애플리케이션] 
2009.02.02   2009년에 주목할 IT 테크놀로지-1 [로보틱스] (4)
2008.10.15   [개발자 영어-3] Trustworthy Computing에 대하여-2 

 

모바일 게임의 어제와 오늘, 그리고 내일
+   [마이크로소프트웨어]   |  2009. 10. 9. 09:34  


모바일 게임이 활성화되고 있다. 특히 아이폰 및 스마트폰과 풀터치폰이 대세인 요즘은 더욱 다양한 게임들이 개발되고 있는 추세. 이와 함께 애플의 앱스토어로 대표되는 모바일 콘텐츠 오픈마켓의 출현은 모바일 게임 시장에 또 한 번 불을 지핀 계기가 됐다. 그렇다면 모바일 게임은 언제부터 어떻게 시작됐을까? 관련 시장의 대표적인 개발사들을 통해 국내 모바일 게임 시장의 변천사를 알아보자. 취재 | 이미선 기자 init@imaso.co.kr

모바일 게임 산업의 초기에는 진입 장벽이 낮아 수 백개의 모바일 게임 개발사가 난립해 있었다. 하지만 산업이 고도화된 요즘은 수 년간의 자연스러운 구조 조정을 통해 상위 몇 개의 개발사가 대부분의 시장을 점유하고 있다. 업계 관계자들에 따르면 게임빌, 넥슨모바일, 컴투스가 시장의 95% 이상을 점유하고 있다.


모바일 게임의 시작은 WAP 기반으로 무선 인터넷을 할 수 있던 시기로 거슬러 올라간다. 이후 VM(Virtual Machine) 방식의 스탠드 얼론 게임이 등장하고, 컬러 휴대폰이 개발됨에 따라 다시 한 번의 고속 성장을 이뤘다. 최근에는 휴대폰 성능 향상과 스마트폰 및 앱스토어의 등장으로 다시 한 번 만개하고 있는 상황이다(여기서 언급하는 모바일 게임은 휴대폰용 게임으로 제한한다). 


모바일 게임의 태동…가능성 의심

1999년 휴대폰 시장에는 WAP(Wireless Application Protocol) 기반의 무선 인터넷이라는 생소한 서비스가 등장했다. 그리고 이 서비스는 1999년 말 경 LG텔레콤을 필두로 국내 주요 이동통신사(이하 이통사)들에게 빠르게 확산됐다. 하지만 세계적으로 이 서비스가 시작되는 시점이었기 때문에 서비스망은 열렸지만 실제로 제공할 만한 콘텐츠는 마땅치 않았던 것이 현실. 그 중 초창기 WAP 게임의 대표적인 것으로는 컴투스의 <춘추열국지>를 꼽을 수 있다.

무선 인터넷 서비스와 함께 등장한 콘텐츠는 게임, 뉴스, 증권정보 등이었는데, 그 중 유독 게임의 성공 가능성에 의문을 갖는 이들이 많았다. 흑백의 작은 화면에 구현할 수 있는 게임의 수준이 높지 않았고, 그 때 그 때 네트워크를 통해 다음 내용을 받으며 진행하는 형식이나 처리 속도 등으로 통신요금의 부담이 컸기 때문이다. 하지만 초기 우려와는 달리 모바일 게임은 많은 인기를 모았고, 이를 계기로 초기 무료로 시범 서비스되던 것들이 차례로 유료화됐다.

 

‘이지-자바’ 기반 신 시장 개화

2000년, 모바일 게임 시장에는 새로운 변화가 생겼다. 휴대폰에 게임을 다운로드 받아 저장해놓고 무선 인터넷에 접속하지 않은 상황에서도 게임을 즐길 수 있는 VM 방식의 스탠드 얼론 게임이 등장한 것. 이는 LG텔레콤이 미국 썬마이크로시스템즈와 제휴해 CDMA 휴대폰용 모바일 자바 기술 ‘이지자바(ez-java)’를 최초 개발하면서 가능해졌다. 이어 2000년 9월 LG전자의 아이북(I-BOOK) 단말기에 이지자바가 탑재되면서 자바 기반으로 흑백을 4단계 음영으로 표현하는 게임이 서비스됐다. 이를 계기로 모바일 게임의 활성화가 시작됐다. 당시의 게임은 흑백의 작은 화면과 20KB 용량에 불과했지만 이후 많은 개발사들에 의해 다양한 게임들이 개발됐다. 이 시기의 대표 게임으로는 게임빌의 <사목쌓기> 등이 있다.

 

컬러 휴대폰…새로운 도전의 시작

모바일 게임 시장은 빠른 발전을 이뤘지만 막상 게임을 즐길 휴대폰 단말기는 더디게 보급됐다. 교체 비용이 비싼 휴대폰 라이프 사이클의 특성상 게임이 가능한 최신 휴대폰의 점유율이 빠르게 증가되지 못한 것. 이와 같은 시기, 2001년 국내에 처음으로 컬러 액정 표시 장치(LCD)가 장착된 단말기가 출시됐다. 이에 따라 컬러 그래픽을 활용한 128KB 이상의 모바일 게임도 등장해 초기와 달리 제약 조건이 적었고, 게임 콘텐츠의 구동도 용이해졌다. 이와 함께 다양한 기능을 가진 휴대폰들이 등장하며 소비자들의 휴대폰 교체 시기가 대폭 감소됐는데, 향상된 기기 변화에 따라 게임성은 더욱 높아졌다. 특히 2002~2003년 사이 모바일 게임 시장은 가파르게 성장했다. 개발사는 400~600여 곳에 달했고, 매출 규모도 높아졌다. 개발사가 많기 때문에 경쟁 또한 치열했다.

당시에는 일본 아케이드(오락실) 게임이나 유명 TV 프로그램, 콘솔 게임기 등의 라이선스를 받아 모바일 환경에 맞게 변형시킨 것들의 인기가 높았다. 휴대폰으로 게임을 즐기는 것 자체가 생소했기에 익숙한 게임들로 소비자들을 유치해야 할 필요가 있었고, 개발 기간의 단축과 게임 성공 가능성이 높다는 장점도 있었다. 이와 같은 상황에서 모바일 게임에 최적화된 국산 창작 브랜드가 대중화되기 시작했는데, 컴투스의 <붕어빵 타이쿤2>와 게임빌의 <놈> 등이 대표적이다.


스탠드 얼론 게임이 주류를 이루면서 휴대폰 요금을 염려하는 소비자들이 추가적인 사용료가 청구되는 네트워크 게임을 기피하게 된 것은 당연한 일. 때문에 모바일 네트워크 게임의 서비스는 어렵다는 인식이 번져나갔다. 이와 같은 상황에서 2003년 12월 엔텔리전트(현 넥슨모바일)의 모바일 액션 RPG <삼국지 무한대전>이 등장해 큰 인기를 얻었다. 


<삼국지 무한대전>은 제한적인 네트워크를 사용, 적은 비용으로 다른 게이머와 1:1 대결을 할 수 있도록 구성됐다. 상대방이 키운 캐릭터의 정보만을 받아와 자신의 휴대폰에서 대결하는 ‘세미 네트워크’라는 방식이었는데, 이는 이후 모바일 네트워크 게임의 공식처럼 자리잡게 됐다. 특히 다운로드 수 100만을 넘어서는 등 큰 성공을 거둠에 따라 엔텔리전트는 국내 주요 모바일 게임 개발사로 성장할 수 있었다. 세미 네트워크 방식이 모바일 네트워크 게임의 표준으로 자리잡으면서 실시간 모바일 MMO RPG 장르의 게임들이 등장해 대표적인 모바일 게임으로 성장했다. 컴투스의 <아이모:The World Of Magic>이 대표적이다.

 

휴대폰 성능 ‘업’, 대작 게임 개발

휴대폰이 다양한 부가 기능을 갖춘 디지털 기기로 변모하며 CPU인 ARM7 칩도 업그레이드됐다. 특히 2004년 전후로 MP3 플레이어 등 멀티미디어 기능이 강조된 휴대폰들이 등장하며 국내에서도 고속 CPU인 ARM9칩이 탑재된 대용량 메모리의 휴대폰들이 선보여졌다. LCD 화면도 QVGA(240×320)의 해상도로 높아져 모바일 게임 시장은 또 한 번의 변화를 맞았다. 500KB 이하의 2D 그래픽 게임 일색이던 것이 1MB 전후의 3D 게임으로 업그레이드 된 것. ARM9의 고속 처리 속도를 이용하면 일반 휴대폰에서도 모바일 3D 게임의 구현이 가능해 휴대폰의 변화를 재촉할 수 있는 기회였다. 하지만 ARM9으로의 교체 속도는 기대 이하였고, 휴대폰용 3D 게임이 유저들의 게임 선택의 기준이 될 수준도 아니었다. 하지만 이후로 고품질의 대작 게임 출시의 시초가 된 것은 분명하다. 위피 탑재도 게임의 수준을 크게 향상시켜 지속적인 성장세를 이어가고 있다.

이와 함께 특정 모바일 게임의 인기는 후속작으로까지 이어지는 등 점차 모바일 게임 자체의 브랜드가 강화되기 시작했다. 이에 따라 각 개발사들도 게임 브랜드 강화를 위해 지속적인 마케팅과 후속작 출시에 힘쓰고 있다. 대표적인 게임은 게임빌의 <놈>, 넥슨모바일의 <메이플스토리>, 컴투스의 <미니게임천국> 등이다.

 

스마트폰·터치폰…성장의 ‘기폭제

2001~2002년 PDA 폰이 출시됐지만 투박한 디자인과 활용 가능한 콘텐츠가 부족해 큰 빛을 보지 못했다. 특히 PDA용 게임은 무료 애플리케이션이 많았고 불법 카피가 일반화 돼 콘텐츠 제작 업체들도 쉽게 뛰어들 수 없었다.


넥슨모바일 김용석 실장도 “PDA용 게임은 ‘복제’로 인해 성공하지 못했다”고 분석했다.


하지만 2008년을 전후해 미국, 유럽을 중심으로 한 글로벌 시장에서 애플의 아이폰, 구글의 안드로이드 폰 등의 스마트폰이 큰 성공을 거두며 스마트폰에서 서비스되는 모바일 게임에 대한 수요가 크게 증가했다. 특히 이들 스마트폰과 애플의 앱스토어를 계기로 킬러콘텐츠라 할 수 있는 게임에 대한 관심이 급증했다. 또한 삼성, KT, SKT 등도 저마다의 모바일 콘텐츠 오픈마켓 서비스를 함에 따라 모바일 게임 시장 활성화에 힘을 싣어주고 있는 상황이다.


이처럼 스마트폰과 앱스토어의 등장은 모바일 게임 산업의 성장에 기폭제 역할을 할 것으로 기대되고 있지만 한편으로는 앱스토어가 오히려 모바일 게임 산업의 발전에 악영향을 끼친다는 우려의 목소리도 나오고 있어 향후 추이는 조금 더 지켜봐야 할 필요가 있다. 풀터치폰도 새로운 개념의 모바일 게임을 등장시켰다.

 

발전 가능성 무궁무진…기대감 ↑

모바일 게임은 전체적인 휴대폰 시장의 흐름과 밀접한 연관이 있다. 현재 휴대폰 단말기는 급속도로 변화하고 있다. PC 못지 않은 고사양을 발휘해 구현되는 게임의 종류는 다양하고, 앞으로도 그 수는 더욱 늘어날 것으로 전망된다. 또한 이통사의 데이터 통화료 정책 역시 모바일 게임의 성장과 긴밀한 관계에 있으니 어떤 게임들이 어떻게 서비스될 지 기대해보는 것도 좋겠다.


출처 | 아이마소





     MSW, 개발자, 게임, 마소, 마이크로소프트웨어, 모바일 게임, 소프트웨어, 아이마소, 월간마소, 호랭이
     0   

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

 

 

개발자도 며느리도 모르는, 개발자 심리학
+   [마이크로소프트웨어]   |  2009. 9. 30. 08:43  


개발자는 어떤 사람일까? 개발자는 과학자에 속한다는 사람도 있고, 엔지니어에 속한다는 사람도 있고, 예술가에 속한다는 사람도 있다. 개발자는 지적인 작업으로 새로운 것을 창조하기 때문에 예술가에 가깝다. 그럼 이러한 예술가들을 어떻게 이해해야만 잘 관리할 수 있을까? 지금부터 그에 대한 내용을 알아보자.

한용희 woom33@korea.com|현재 Microsoft Visual C# MVP이며, 여러 SW 개발 프로젝트에 참여했다. 다양한 SW 개발 프로젝트에 참여해 오면서 항상 더 나은 개발 방법에 대해 고민하고 있다.

개발이라는 작업은 고도의 집중력을 필요로 한다. 개발자가 개발하기 위해서는 명명규칙, 공통 API, 디자인 패턴, DB 테이블 구조, 성능, 상호 인터페이스 등등 많은 내용들을 머릿속에 장전하고 개발을 시작해야 한다.

 

개발자의 직업병

이러한 내용이 머릿속에 제대로 장전되지 않으면, 오류가 생기거나 개발 속도가 떨어진다. 한 가지 일에 집중해야 하는 직업 특성상 개발자를 주변에서는 내성적인 사람이라고 오해하기도 한다. 하지만 그들 성격이 내성적이기 때문에 그런 것이 아니라, 정신의 에너지를 내부에 집중해야 하기 때문에 다른 사람이 볼 때 그렇게 보이는 것이다.

개발자들은 숲을 보기보다는 나무를 보는 경향이 있으며, 작은 것에 민감하게 반응한다. 또한 자기 관심 분야에는 굉장한 열정을 보이지만 다른 분야에는 관심을 보이지 않는다. 모든 개발자가 그런 것은 아니지만, 외부에서 개발자를 보는 인식은 대체로 위와 같다.

개발자는 자기 자신과 일을 가장 많이 한다. 타인과 같이 일하는 시간보다, 자기 자신과 대화하면서 일하는 시간이 많다. 그러다 보니 다른 사람과의 커뮤니케이션 기술이 부족한 경우가 많아서 함께 일하는 데 원활하지 못한 경우가 있다. 그런데 개발자라고 처음부터 내성적이고, 커뮤니케이션이 부족한 사람은 아니었을 것이다. 직업 특성상 자기 자신과의 싸움을 오랫동안 외롭게 하다 보니 그렇게 된 것이다. 개발자와 함께 일하는 관리자와 이해 관계자들은 이러한 개발자의 특성을 잘 이해해야만 프로젝트를 성공적으로 수행하는 데 유리하다.

 

개발자의 무아지경

개발자가 고도의 집중 상태에 빠져드는 것은 마치 ‘무아지경’과도 같다(영어로는 ‘in the zone’ 또는 ‘flow’라고 한다). 한번 이런 상태에 빠지면 굉장한 속도로 개발을 해 나간다.

개발자의 생산성이 최대가 되는 순간이다. 그런데 한 가지 안타까운 것은 이 상태가 너무나도 쉽게 깨져 버린다는 것이다. 한 예를 들어보자.

개발자가 열심히 무아지경에 빠져서 개발하고 있는데, 갑자기 고객으로부터 전화가 왔다. 개발자는 전화를 받자마자 고객으로부터 짜증 섞인 목소리를 들었다.

고객은 온갖 짜증을 내면서 이따위 시스템 못 써먹겠다고 불평불만을 쏟아낸다. 이 순간 개발자의 무아지경 상태는 깨졌고, 이를 다시 회복하는 데에는 많은 시간이 소요될 것이다.

머릿속에 장전해 놓은 각종 명명규칙, 공통 API, 디자인 패턴, DB 테이블 구조, 성능, 상호 인터페이스 등등 많은 내용이 순식간에 언로드(unload)되고 고객의 짜증섞인 불만 내용이 머릿속에 로딩(loading)된다. 이를 다시 끄집어내고(unload) 다시 무아지경에 빠지기 위해 명명규칙, 공통 API, 디자인 패턴, DB 테이블 구조, 성능, 상호 인터페이스 등의 내용을 다시 장전하기 위해서는 정신 상태부터 치유해야 한다.

갑자기 고객으로부터 온갖 욕을 얻어먹은 개발자는 정신 치유를 위해 담배를 피우던지, 음악을 듣던지 하는 휴식 시간이 필요하다.

그런데 프로젝트 막바지에 다다라서 시간이 촉박하고 깐깐한 관리자를 만났다면 그나마도 못한다. 정신적인 쇼크 상태에서 개발을 지속하다 보면 많은 오류를 양산하게 되고, 향후 고객으로부터 다시 한 번, 이 시스템 못 써먹겠다는 소리를 듣는 악순환이 이어진다.

낮에는 이해 관계자들의 전화에 시달려 일을 하지 못한 개발자는 드디어 모두 퇴근한 밤이 되어서야 자기 자신만의 시간을 가질 수 있었다. 밤새 무아지경에 빠져서 수정사항을 다 고친 후에야 퇴근했다.

그런데 다음날 아침 9시에는 관리자가 프로젝트 진행 상태를 점검하기 위해 이해 관계자와 함께 하는 회의 시간을 잡아 놓았었다.

관리자와 이해 관계자는 아침 9시에 모여서 회의가 시작되기를 기다리는데, 개발자는 아직 출근도 안 했다.

관리자는 개발자가 어제 몇 시에 퇴근했는지 모르는 채, 그리고 왜 야근을 해야 하는지도 모르는 채, 매일 지각 출근한다고 이미 불만이 많았다.

고객은 아침 9시부터 불러놓고 회의도 안 한다면서 관리자를 독촉하기 시작했고, 관리자는 연신 휴대폰을 부여잡고 개발자에게 전화를 한다.

드디어 아침 10시가 되어 개발자가 나타나자, 관리자는 그동안 참았던 모든 불만을 다 쏟아냈다. 이를 묵묵히 듣고 있던 개발자는 끊었던 담배를 다시 피워야만 했다. 그렇게 프로젝트는 진행이 되었고, 그래도 끝을 보게 되었다.

드디어 프로젝트 종료보고를 하던 어느 날 그 개발자는 홀연히 사라져 버렸다. 그가 어디로 갔는지 아는 사람은 없었다. 혹자는 그가 머리를 깎고 중이 되었다는 사람도 있고, 그가 공사장에서 트럭 몰고 있는 모습을 봤다는 사람도 있고, 이민을 갔다는 사람도 있고, 다들 추측만 난무했다.

위는 실제 사례는 아니지만, 현장에서 얼마든지 있을 수 있는 사례다. 개발자는 고도의 집중상태에 한번 빠지면 엄청난 생산성을 낼 수 있지만, 아쉽게도 이 상태는 외부의 충격에 의해 쉽게 깨져버린다. 그런데 이 무아지경 상태는 context switching(문맥 변화)이 일어나는 상태에서만 깨진다.

컴퓨터에서 프로세스나 스레드가 바뀔 때 context switching이 일어난다. 하나의 CPU는 한 번에 하나의 작업만 할 수 있기 때문에, 여러 작업을 동시에 하기 위해서는 작업이 바뀔 때마다 context switching을 해서 작업을 진행하기 위한 기본적인 내용을 CPU 레지스터에 로딩해야만 한다.

사람의 두뇌도 이와 유사해 비슷한 일을 계속하는 경우에는 context switching이 일어나지 않는다.

개발자가 개발하는 중간에 지금 무슨 일을 하고 있는지 묻는 질문은 context switching을 일으키지 않는다. 하지만 위의 사례처럼 고객의 전화를 받는 작업은 context switching을 일으킬 수 있는 작업이다. 개발자는 과학자도 엔지니어도 아니다.

자기 자신과의 싸움에서 새로운 것을 창조해 내야 하는 예술가인 것이다.

그런 예술가를 마치 하나의 기계 부속품인 것처럼 고장나면 교환하면 된다고 간주하거나, 통제를 많이 하면 할수록 더 일을 잘 한다고 생각한다면, 개발자의 업무 특성을 잘 이해하지 못한 것이다.

 

무아지경에 빠지기 위한 환경

유명한 개발자 사이트인 DevX(www.devx.com)에 보면 Bryan Dollery가 2003년에 쓴 ‘개발의 심리학 이해’라는 글이 있다(www.devx.com/DevX/Article/11659). 이 글에 보면 개발자가 무아지경에 빠지는 것을 돕는 세 가지 방법이 나와 있다.

- 적절한 정신적 격리 상태를 제공할 것

- 창의적인 에너지를 재충전할 수 있는 적절한 시간을 제공할 것

- 이치에 맞는 특별한 요구를 수용해줄 것

개발자가 정신적으로 집중할 수 있도록 방해되는 주변 환경을 차단해야 한다. 한 예로 수정사항이나 요구사항은 개발자가 직접 듣는 것이 아니라 관리자가 일괄 취합해서 우선순위를 정해 개발자에게 전달하는 것이 전체 프로젝트의 생산성을 높이는 데 도움이 된다.

개발자가 개발에 집중할 수 있도록 주변 환경을 조성해 주는 것이 관리자로서 해야할 첫 번째 임무인 것이다. 두 번째는 개발자가 중복된 실수를 하지 않도록 그들에게 적절한 휴식시간을 제공해 주어야 한다는 것이다.

무아지경 상태에 다시 빠질 수 있도록 적절한 휴식이 필요하기 때문이다. 세 번째는 개발자들이 원하는 특별한 요구사항이 있다면 수용해주라는 것이다.

긍정 심리학 분야의 세계적인 대가인 시카고 대학의 칙센미하이(Csikszentmihalyi) 교수는 노벨상 수상자 또는 뛰어난 과학자들의 심리 상태를 연구해 몰입(flow)에 대한 많은 책을 썼다.

특히 우리나라에도 소개된 ‘몰입의 즐거움’, ‘몰입의 경영’ 등을 통해 ‘몰입 이론’으로 세계적인 명성을 얻었다. 그가 인용한 한 유명 컴퓨터 과학자는 자신이 샤워를 할 때 가장 많은 아이디어가 떠올랐다고 한다. 그러던 그가 한 회사에 취직을 했는데, 그 회사는 샤워 부스를 제공하지 않았다. 그 이후 그는 새로운 아이디어가 떠오르지 않아서 그만 두었고 샤워부스를 제공해 주는 다른 회사로 옮겼다. 그랬더니 거기에서는 많은 아이디어가 떠올라서 일을 계속 할 수 있었다고 한다.

여기에서 샤워부스는 개발자의 특별한 요구사항에 속하는데, 아마 우리나라의 환경에서는 개발자 1명을 위해 샤워부스까지 만들어 주기는 어려울 것이다. 그것보다는 개발자들이 무아지경(몰입)에 다시 쉽게 빠질 수 있도록 적절한 휴식 공간을 제공해 주는 것이 더 좋은 방법이다.

개발자는 멀티태스킹 기계가 아니다

조엘은 그의 블로그의 ‘개발자는 멀티태스킹 기계가 아닙니다(Human Task Switches Considered Harmful)’라는 글에서 개발자에게 두 가지 일을 동시에 시키지 말라고 했다. 위에서 언급했듯이 개발자가 개발을 하기 위해서는 한 가지 일에 집중해야 한다.

그런데 두 가지 일을 한꺼번에 시키면 개발자는 두 가지 일 사이에서 문맥교환(context swtching)을 하느라고 오히려 전체 개발 시간이 더 늦어지게 된다.

<그림 1>은 조엘이 제시한 예제이다. A라는 작업과 B라는 작업이 있는데, 각각 10초씩 걸린다. 이를 순서대로 처리하면 아래와 같다.


이를 멀티태스킹으로 처리하면 <그림 2>와 같다.


순서대로 처리하면 A를 처리하는 데 10초, B를 처리하는 데 20초가 걸렸다. 평균으로 하면 15초이다. 그런데 멀티태스킹으로 하면 A를 처리하는 데 19초, B를 처리하는 데 20초 걸렸다. 평균 19.5초이다. 오히려 멀티태스킹의 평균 시간이 더 큰 것을 알 수 있다.


문맥을 교환하는 데 비용이 드는 경우도 따져봐야 한다. 실제 개발자가 멀티태스킹을 하기 위해서는 문맥 교환 비용이 들어간다. 문맥을 교환하는 데 0.5초가 걸린다고 가정하고 계산하면 <그림 4>와 같다.


평균적으로 보면 멀티태스킹이 28초나 걸린다는 것을 확인할 수 있다. 이렇듯 개발자에게 두 가지 일을 동시에 시키는 것은 결국 생산성만 악화시키는 결과를 초래한다.

개발자들이 한 가지 일에 집중할 수 있도록 관리자는 일을 적절히 배분하는 기술과 요령을 익혀야 한다. 가장 최악의 케이스는 관리자가 개발자에게 할 일을 모두 던져주고 알아서 하라는 식으로 두는 경우이다. 그렇게 일을 주면 개발자는 한 가지 일에 집중할 수 없다.

관리자는 근본적으로 일에 대한 관리를 하는 사람이다. 자신이 작업에 대한 관리를 하지 않고 개발자에게 일임한다면 그 팀의 생산성은 좋지 않을 것이다.

 

비자아적 프로그래밍(egoless programming)

비자아적 프로그래밍은 『컴퓨터 프로그래밍의 심리학』(The Psychology of Computer Programming, Weinberg 1971)이라는 책에서 처음 언급됐다.

그 책의 요지는 개발자는 자신이 만든 프로그램에 자아를 투영해서는 안 된다는 것이다. 프로그램을 마치 자신의 작품인 것처럼 생각한다면 남들의 비판에 방어적이 되기 때문이다.

오류보고서는 인신공격으로, 검토는 위협으로, 작업에 대한 질문은 비생산적으로 생각해 오히려 제품의 품질을 떨어뜨릴 수 있다. 팀으로 작업하는 프로젝트에서는 이러한 상황을 내버려 둬서는 안 된다.

누군가가 자신의 코드에 대해 오류를 지적하면 개발자는 감정적으로 대응하게 되고, 나중에는 오류가 있더라도 지적을 하지 않는 사태가 발생해 결국에는 프로젝트의 품질이 떨어질 수 있다. 따라서 개발자는 프로그램을 자신의 작품처럼 생각해서는 안 되며, 팀 작업의 결과물로 인식해야 한다는 것이다.

이러한 ‘비자아적 프로그래밍을 위해 개발자가 갖춰야 할 10가지 지침(Ten Commandments of Egoless Programming)’이라는 것을 TechRepublic이라는 사이트에서 Lamont Adams라는 사람이 주장했다.

1. 당신은 실수할 수 있다는 것을 받아들이고 이해하라

실수는 일찍 발견할수록 좋은 것이다. 일찍 발견할수록 수정 비용도 적게 든다.


2. 당신의 코드는 당신의 작품이 아니다


코드 리뷰의 목적은 문제를 발견해서 치료하는 것이다. 그것을 개인적인 감정으로 받아들이지 마라


3. 장기도 훈수 두는 사람이 더 잘 안다


장기를 두다 보면 장기에 몰입해서 장기를 두는 사람보다도 주변에서 훈수를 두는 사람이 더 잘 알 수도 있다. 따라서 주변에서 하는 가르침에 겸손해야 한다.


4. 조언 없이 코드를 다시 쓰지 마라


혼자서 독단적으로 판단해서 코드를 다시 작성하지 말고, 코드 리뷰를 통해 코드를 다시 작성해라


5. 잘 알지 못하는 사람들을 존경하고, 복종하고, 참아라.

비기술자들은 개발자들을 좋을 때는 오페라의 프리마돈나처럼 생각하지만, 안 좋을 때는 울보로 간주한다. 여기에 휘둘리지 마라.


6. 세상에서 변하지 않는 진리는 변한다는 것이다.


변화에 대해 열린 마음으로 웃으면서 받아들여라. 요구사항의 변화, 플랫폼의 변화, 기술의 변화 이 모든 것에 대해 열린 마음으로 받아 들여라.


7. 진정한 권위는 직위가 아닌 지식으로부터 나온다.

지식은 권위를 낳고, 권위는 존경을 낳는다. 그러므로 비자아적 프로그래밍 환경에서 존경을 받고 싶다면 지식을 쌓아라.


8. 당신이 알고 있는 지식을 고수하며 싸워라. 그러나 패배는 겸허히 받아 들여라.

때로는 당신의 아이디어가 채택되지 않을 수 있다. 심지어 나중에 그것이 더 낫다고 밝혀지더라도 “내가 말한 게 맞죠?”라면서 복수할 필요는 없다.


9. 독방의 개발자는 되지 마라

어두운 사무실에 홀로 앉아서 콜라 살 때만 나타나는 은둔형 개발자는 되지 마라.


10. 사람이 아닌 코드를 비판하고, 코드가 아닌 사람에게 친절해라

코드에 대한 코멘트는 긍정적이며, 개선하는 방향으로 해야 하며, 기존 코드에 대한 비판적인 방향은 좋지 않다.


이러한 비자아적 프로그래밍이 정착되기 위해서는 프로젝트 팀 내에서도 노력이 필요하다.

가령 “이 프로그램은 누가 짜서 이렇게 오류가 많아”라는 식으로 말하게 되면 이는 결국 말하는 사람 스스로가 개발자와 코드를 하나로 인식한 셈이 된다.

이러한 언급을 용인하고 묵인해 주는 환경에서는 비자아적 프로그래밍을 할 수 없다. 또한 개발자가 한번 개발한 코드에 대해서는 영구적인 오류 수정 권한을 부여하는 환경에서도 비자아적 프로그래밍을 할 수 없다.

비자아적 프로그래밍은 특히 오픈소스 환경에서도 잘 적용되는 개념이다.

한 명의 독창적인 작품이 아닌 공동의 작품으로 간주하는 오픈소스 환경에서는 누구든지 오류를 수정하고 개선해 가면서 함께 개발해 나갈 수 있다.

이러한 비자아적 프로그래밍은 여러 명이 작업하는 팀 환경에서는 어느정도 필요한 부분이다. 그런데 위의 10가지 지침을 다 지키려면 개발자는 소인이 아닌 군자가 되어야 한다.

남의 비판도 겸허히 받아들여야 하고, 자신이 공들여 애써 만든 작품을 남들이 무너뜨리더라도 웃으면서 받아들여야 한다.

개발자는 자존심을 다 버리고 군자가 되어야 한다. 현실적으로 쉽지 않은 일이다. 필자는 현재도 개발을 하지만, 필자가 개발하는 프로그램에는 최대한의 정성을 다 쏟으려고 노력한다.

하나의 작품을 만든다는 생각으로 내 자신의 자아를 투영한다.

그래야만 정성을 가지고 애착을 가지고 만든다. 만약 개발자가 프로그램에 자아를 심지 않는다면 어떤 정성과 애착을 가지고 잘 만들 수 있을까? 자아 없이 잘 통제하고 잘 감시하면 좋은 프로그램이 나올 수 있을까?


정도의 차이는 있겠지만, 극단적인 비자아적 프로그래밍도 좋지 않으며, 그렇다고 프로그램에 자신의 자아를 너무 투영한 나머지 주변의 충고를 무시하는 것도 좋지 않다.

필자는 앞으로도 내 ‘작품’에는 자아를 투영할 것이다. 자신의 작품에는 항상 최선을 다 하고 싶은 것이 예술가들의 자존심이다.

이를 무시한 채, 자아를 버리라고 강요하는 것은 이 또한 현실을 무시한 생각이다. 열린 마음으로 자신의 작품을 향한 주변의 비판을 받아들이는 예술가야말로 진정으로 좋은 작품을 만드는 예술가다.


참고자료


1. 소프트웨어 공학의 사실과 오해, 로버트 L. 글래스, 2003

2. 조엘 온 소프트웨어, 조엘 스폴스키, 2004

3. Professional 소프트웨어 개발, 스티브 맥코넬, 2004

4. 똑똑하고 100배 일 잘하는 개발자 모시기, 조엘 스폴스키, 2007

5. 스크럼-팀의 생산성을 극대화시키는 애자일 방법론, 켄 슈와버, 마이크 비들, 2002

6. 피플웨어, 톰 디마르코, 2003

7. 개발의 심리학 이해, http://www.devx.com/DevX/Article/11659

8. 개발자는 멀티태스킹 기계가 아닙니다, http://www.joelonsoftware.com/articles/fog0000000022.html

9. 비자아적 프로그래밍을 위한 10가지 지침, http://articles.techrepublic.com.com/5100-10878_11-1045782.html

>> 출처 | 아이마소





     MSW, 개발자, 개발자심리학, 마소, 마이크로소프트웨어, 소프트웨어, 심리학, 월간마소, 한용희
     3   
BlogIcon yiabb 2009.09.30 09:33 신고
오랜만에 정독한 포스팅이네요. 마구 추천합니다^^
BlogIcon 마소호랭이 2009.10.04 14:39 신고 
ㅎ.ㅎ 감사합니다. 저도 마구 추천입니다.
lookit 2009.09.30 11:15
관리자들이 많이 읽어줘야 할듯하네요.. ^^;
BlogIcon 마소호랭이 2009.10.04 14:40 신고 
관리자뿐만 아니라 프로젝트에 참여하는 사람들이 서로 이해하기 위해 필요한 내용이란 생각이듭니다.
BlogIcon sheon 2009.09.30 12:12 신고
포스팅 잘 보았습니다. 개발자(엔지니어측면)는 업무 특성상 폐쇄적으로 빠질 수 있는 경우가 많은 것 같아요.
언급 하셨던 것처럼 마치 작품을 빚어내는 예술가 처럼 말이죠. 저역시 최근 개발자와 프로그래머라는 입장에
대해 좀 생각해본 계기가 있어 트랙백 걸고 갑니다.
좋은 하루 되세요~
BlogIcon 마소호랭이 2009.10.04 14:40 신고 
감사합니다.
BlogIcon 도이모이 2009.10.01 17:58
정독해야 할 거 같아.. 프린터 했습니다 ~
BlogIcon 마소호랭이 2009.10.04 14:41 신고 
^-^*
추석 연휴는 잘 보내고 계신지요? 늘 감사합니다.
BlogIcon 도이모이 2009.10.05 08:07 
제가 감사하죠 ^^
taxhon 2009.10.12 17:50
이 글이 절실히 느껴져 퍼갑니다. 감사해요~

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

 

 

로또 명당 마이크로소프트웨어???
+   [마이크로소프트웨어]   |  2009. 4. 21. 14:22  




1사분기 판매 집계 결과 로또의 판매금액이 지난 해보다 13% 정도 늘었다고 합니다.

그만큼 어려워진 경기 속에서 작은 희망을 찾는 사람들이 많아졌다는 뜻일텐데요.

사실 호랭이는 로또와 인연이 참 많습니다.

호랭이가 다니던 출판사가 경영난을 겪고 있을 당시 호랭이에게 로또는 용돈(?) 벌이의

수단이 되어 주기도 했고

이런 책도 내서 한동안 재미(?)도 좀 봤으니 말입니다.

물론 1등에 당첨되어 보진 못했습니다.

1등에 당첨되면 받게 될 당첨금을 만원짜리로 바꾸면 이정도쯤 될까요?

사용자 삽입 이미지

 한 신문사에서 촬영한 이 사진은 많이 보셨을 텐데요.

사용자 삽입 이미지

이 촬영을 하느라 사용한 만원 권 지폐가 2억원이 넘는다고 하는군요.

저 모델 차암~ 좋았겠다는 거!!!

아 어쩌다가 말이 이렇게 줄줄 샜나요 =_=;

많은 사람들에게 희망이 필요한 요즘

다음 달 정기구독 선물로 로또를 드리면 어떨지 고민하고 있습니다.

사행성 조장이라고 하실 분들도 있을지 모르겠지만

서민들에게 로또 한두 게임은 당첨 결과를 확인해 보기 전까지는

큰 희망과 자신감이 되어 주기도 하니까요.

정기구독 하신 분들 중에 1등 당첨자가 막막 나오면

로또 명당 마소에서 로또를 얻기 위해 정기구독을 신청하는 분들도 생길까요? =_=;

개발자들이 막 1등 당첨되면 우리나라 소프트웨어 발전에도 도움이 되겠지요!

아! 그냥 개발이고 뭐고 때려 치우고 이민 가시려나? =_=;





     MSW, 개발자, 로또, 로또 당첨, 로또 선물, 마소, 마소웨어, 마이크로소프트웨어
     0   
BlogIcon 라디오키즈 2009.04.21 14:37 신고
이미 해외의 개발자들은 소프트웨어 로또를 터트리고 여생을 편안히~ 즐기는 것 같아 부러운 터지요.
쩝 전 개발자가 아니라 그런 꿈을 꿔보긴 어렵겠지만요.

글구 로또를 구독자에게 주는 건 어떨지...~_~;;; 저도 잘~~ㅎ
BlogIcon 마소호랭이 2009.04.21 17:32 신고 
대한민국 개발자들도 소프트웨어 로또가 펑펑 터지길 바라면서 일단 저희는 나눔 로또로... =_=+
BlogIcon 그린B 2009.04.21 15:19 신고
절대 찬성입니다! ㅎㅎㅎ
BlogIcon 마소호랭이 2009.04.21 17:31 신고 
캄사합니다.
BlogIcon 열이아빠 2009.04.21 16:46
로또책은 진짜인가요. ㄷㄷ
엑셀전문가라...의심이 간다는..ㅎㅎ
BlogIcon 마소호랭이 2009.04.21 17:31 신고 
이 양반이 때놈 반쓰를 얻어 입었나 뭔 의심이 이리 많아!!! 교보 4위까지 올랐던 책이랍니다. 난 저런 재미있는 책이 좋더라!!!
BlogIcon 학주니 2009.04.21 20:01
갱재가 어려우니 그냥 로또밖에는 생각이.. -.-;
BlogIcon 호랭이 2009.04.21 20:26 
저는 며칠 전에 선물받은 로또가 5등에 당첨되었던데...
다음에는 번호 딱 두 개만 더 맞으면 좋겠습니다. ㅎ.,ㅎ
BlogIcon 지저깨비 2009.04.27 17:18
글읽다가 구글광고가 멋있어서 클릭했답니다. 쿨럭!
BlogIcon 마소호랭이 2009.04.28 09:48 신고 
오예~ 구글 만쉐이~

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

 

 

개발자가 행복해지는 세 가지 비법
+   [마이크로소프트웨어]   |  2009. 3. 20. 10:35  




흉흉한 소식에 참 기운이 빠지는 요즘입니다.

이럴때 일수록 자기 자신을 다지고 올바른 방향성을 확보하는 게 참 중요할텐데요.

그래서 마소와 OKJSP가 함께 '개발자가 행복해지는 세 가지 비법'이란 제목으로

세미나를 준비했습니다.

유료 세미나고 초쿰 비쌉니다.

하지만 국내 최고의 선배들이 전하는 협업과 예외처리, 개발생산성 노하우들을

한 자리에서 들을 수 있는 좋은 시간이 될 거란 걸 약속드립니다.

자세한 내용은 아래 링크를 참조해 주세요.

세미나 안내 페이지 | http://new.imaso.co.kr/seminars/introduce/1

이벤트 상품도 잔뜩 준비해 뒀습니다.

어쩌면 참가자보다 상품이 많들지도 덜덜덜...





     kenu, MSW, okjsp, 개발자, 마소, 마이크로소프트웨어, 세미나, 월간마소, 행복, 허광남
     1   
BlogIcon okgosu 2009.03.21 01:25 신고
25일이면 며칠 안남았네요....?

진작에 말하시지....

트랙백 넣습니다.

with okgosu
BlogIcon dudas 2009.03.21 15:29
훗날에 저도 이런 세미나 같은데 꼭 참여해보고 싶군요..
아직은 고등학생의 신분인지라 ㅎㅎ..
오랜친구 2009.03.21 21:59
세미나 정보 보고는 곧 좌절했습죠.
25일 수요일은 8주 동안 진행한 수업 마지막 날이거든요.
저희 똥강아지들 잘 자라서 마소 정기구독하는 업계 새 일꾼이 되길 기대해 주세요~.

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

 

 

실패하는 프로젝트 만들기
+   [마이크로소프트웨어]   |  2009. 3. 3. 11:16  





계획이나 예상대로 일이 진행되기만 한다면 그보다 좋은 일이 없을 것입니다.

그런데, 실상은 전혀 그렇지 않지요.

계획이 지연되는 건 기본이고 프로젝트 자체가 실폐로 끝나게 되는 경우도 다반사...

월간 마소에 소개된 내용 중 이와 관련된 재미있는 글이 있어 옮겨봅니다.

프로젝트를 수행하는 조직은 다양한 사람들로 구성되어 있다.

시스템 구축을 위해 프로젝트를 만든 고객이 있고, 프로젝트의 원활한 개발을 총괄하는 프로젝트 매니저, 기술적인 이슈 혹은 수행 조직 내부의 업무, 이슈를 조율하는 프로젝트 리더, 아키텍처를 설계하고 개발하는 설계 및 개발자들로 구성되어 있다. 프로젝트 실패의 배경을 살펴보면 다양한 이유들이 복합적으로 작용하는 경우가 대부분이지만, 그 중에서도 프로젝트 매니저나 리더의 잘못된 방향설정이나 조직 운영상의 문제로 실패하는 경우가 가장 흔하다.

프로젝트 매니저의 역할
사전적인 의미로 프로젝트 조직을 관리하며 완료에 차질이 없도록 일정을 조율하며 고객 및 조직원간의 인터페이스 접점에서 의사소통을 담당하는 역할을 가진 사람을 우리는 프로젝트 매니저라고 한다. 역할의 경중을 따지는 것 자체가 의미 없다고 생각하는 사람도 있겠지만, 가장 중요한 역할 하나를 뽑으라면‘의사 소통 담당’이 아닐까? 고객의 요구사항을 정확하게 분석하여 조직원들에게 전달하고 필터링하는 것. 조직원들로부터 접수 받은 문제점 및 이슈들에 대하여 정리하고 고객과 협의하는 것. 이것만큼 중요한 역할이 또 있을까?

고객과 싸우는 PM
고객은 자신에게 (혹은 회사에) 필요한 기능의 구현을 위해 시스템 구축을 요청하고 프로젝트를 추진한다. 시스템 구축을 추진하면서 현장의 요구사항이 정확하게 요구 정의서에 기술되면 좋겠지만 사람이 하는 일이 어떻게 완벽할 수 있겠는가? 당연히 빠진 내용이 나중에 발견되고 초기 요구 정의서와 사뭇 다른 요구가 다시 도출되는 경우도 비일비재하다. 요구사항이 변경되는 것은 시스템 구축 일정에 중대한 차질을 가져올 수 있는 사안이므로 프로젝트 매니저로서는 요구사항 변경이 여간 신경 쓰이는 것이 아니다. 애초부터 정의되지 않은 생뚱맞은 요구사항이 아니라면 일정에 반영하고 고객과 일정 변경에 대한 협의를 진행해야한다. 그런데 일부 PM은 이러한 일정 변경에 대하여 과도하게 반응하며 고객과 싸우는 경우가 있다. 완벽을 추구하는 스타일의 사람들에게서 종종 보이는 현상인데, 고객은 절대 싸워야 할 대상이 아니다. 끊임없이 협상과 협의를 해야 하는 대상인 것이다.

대화가 없는 사무실
시스템을 만드는 목적이 무엇일까? 지나친 추상화일지도 모르겠지만, 사용자와 운영자가 의사소통할 수 있는 도구를 만드는 것이라고 보면 맞을 것이다. 수작업으로 진행되던 작업들을 시스템을 통해 자동화하는 것은 시스템을 통해 의사소통 과정의 오류를 줄이겠다는 것이고 대중을 위한 웹사이트를 만드는 것은 대중과의 의사소통 채널을 만들겠다는 의도이다. 그런데 이런 시스템을 만드는 팀원들이 의사소통이 없는 경우가 참 많다. 원인을 가
만히 찾아보면 우습게도 프로젝트가 진행되는 사무실의 분위기에 맞추다 보니 그렇게 된 경우가 태반이다. 머릿속에 사무실의 풍경을 상상해 보면 십중팔구는 구글의 사무실과 같은 자유로운 분위기가 아닌, 파티션으로 사각형 구획을 나눈 전형적인 경직된 사무실이 떠올랐을 것이다. 이런 곳에서 왁자지껄 떠들면서 일하는 모습을 그냥 보지 못하는 PM들이 있다. 할 말이 있으면 회의를 소집해서 회의실에 들어가서 하라고 등을 떠밀고, 사무실에서
는 업무 관련 통화조차도 조용히 해야 한다는 무언의 암시를 전달해 주기도 한다. 대화는 사람들을 친하게 만들어 주고 보고서, 이메일, 메신저의 글자 몇 개가 줄 수 없는 다양한 의미를 전달해 주는 훌륭한 의사소통 방법이다. 사무실 분위기를 위해 논의거리가 있을 때마다 회의실을 찾는 것은 비효율적일 뿐 아니라 팀원들의 의사소통을 정면으로 해치는 행동임을 알아야 한다.

프로젝트 매니저란?
프로젝트 매니저는 많은 선원과 함께 배를 이끄는 프로젝트 팀의 선장이다. 늘 선원들에게 관심을 가지고 애정을 보여줘야 한다. 본인에게 피해가 올지라도 선원을 보호해 주는 것이 바로 선장이 해야 할 일이다. 그러한 희생이 없다면 선원들은 선장을 믿고 따르지 못할 것이다. 언제든 믿고 의지할 수 있는‘큰 형’같은 존재가 된다면 실패할 프로젝트도 성공시킬 수 있는 힘을 프로젝트 조직이 갖게 되지 않을까? 프로젝트라는 것은 기술, 능력으로도 안 된다고 판단되던 것들이 사람의 힘으로 이뤄지는 멋진 모습을 보여주기도 하니까 말이다.

노승헌 | odumak@empal.com, http://ondemand.tistory.com







     MSW, pm, 개발자, 고객, 노승헌, 마소, 마이크로소프트웨어, 매니저, 월간마소, 프로젝트 매니저
     0   
BlogIcon okgosu 2009.03.03 14:10 신고
프로젝트 시작하면서부터 문제가 발생하기 마련이죠....제가 쓴 글과도 일맥상통하네요
http://www.ibm.com/developerworks/kr/library/dwclm/20080122_1/
BlogIcon LovelyJoeny 2009.03.09 21:53 신고
And, 능력없는 개발자..ㅠㅠ
접니다..
미칠꺼가태효..ㅠㅠ
내길이 아닌가..백만번 생각합니당..ㅠㅠ
BlogIcon 호랭이 2009.03.10 09:21 
설마효 ㅎ.,ㅎ
BlogIcon 한세희 2009.04.20 15:38
음..사무실은 조용해야 하는거 아닌가요? 조엘도 조용한 사무실을 말하던거

같던데요..^^; 집중력이 분산되는 사무실은 별로 좋지 못한거 같아요.

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

 

 

애자일 프랙티스의 실제 활용사례
+   [마이크로소프트웨어]   |  2009. 2. 18. 09:38  




애자일 방법론을 공부하거나 실무에 적용하려고 노력하는 분들은 많지만

막상 우리나라의 정서나 실무 환경에서 적용해서 성공을 거두기란 참 어려운 일입니다.

오늘은 한국 스프링 유저 그룹 KSUG 와 블로그 http://www.younghoe.info/를 운영하고 있는

안영회 님이 자실의 활용 사례를 기반으로 마이크로소프트웨어에 기고해 주신 내용을 옮겨봅니다.

애자일 방법론에 관심있는 개발자 분들께 도움 되시길 바라며

아이마소 홈페이지에 더 유익하고 재미있는 자료들이 많다는 점 참고해 주시길... ^-^*

국내 SI 프로젝트 현장에서는 문화적인 요소 때문에 애자일 방법론 보급이 힘들다는 얘기를 종종 듣는다. 애자일 방법론 도입을 통해 이미 구축한 기존의 방법론을 대치하거나 지금까지 해오던 방식을 완전히 바꿔버리겠다는 발상은 오히려 애자일(?)하지 못하다. 필자는 애자일 방법론이나 프랙티스 전문가는 아니지만, 현장에서 애자일 프랙티스(Agile Practices)를 적절히 적용하여 효과를 보았다. 실제 사례를 널리 알려 현장에서 소프트웨어 구축에 힘쓰는 이들에게 작은 영감이라도 주고자 이 글을 쓴다.


안 영 회 ahnyounghoe@gmail.com | ㈜ITwise 컨설팅에서 소프트웨어 공학 컨설턴트로 일하고 있다. 지난 2005년 국내 대규모 프로젝트에 스프링 프레임워크 적용을 성공한 이후 한국스프링사용자모임(KSUG)을 만들어 운영하고 있기도 하다. Younghoe.info 블로그를 통해 자신의 경험을 공유하고 있다.

프로젝트 제안 단계에서 애자일 방법론을 채택한 이유는 프로젝트 특성 때문이다. 프로젝트 팀원의 숫자는 적은데 반해, 개발 범위는 다소 무리가 아닌가 싶은 수준이었다. 이런 가운데 국내 SI에서 주류로 채택하는 CBD 방법론은 많은 산출물을 요구하기 때문에, 애자일 방법론의 하나인 스크럼(Scrum)을 선정했다. 다만, 산출물 명칭과 양식만 기존 SI 프로젝트의 형식과 유사하게 수정하여, 새로운 방법론 도입에 따른 거부감을 최소화하려고 노력했다. 프로젝트 착수 이후 3.5개월여 시간이 흐른 지금 프로젝트 양상은 애초에 예상했던 것보다 바람직한 모습으로 진행되고 있다.

아직 두 달여 시간이 남은 시점에서 성공을 운운하는 것은 성급한 일이지만, 애자일 소프트웨어 개발(Agile Software Development) 적용만 놓고 보면 분명 성공적이었다. 이 글에서는 성공적이었다고 스스로 평하는 내용들에 대해서 살펴보고자 한다. 그러나 다른 프로젝트에서도 보편적으로 적용하기 위한 일반화를 시도하는 것은 아니며, 애자일 소프트웨어 개발이 지향하는 원칙에 입각해서 어떻게 해법을 찾았는지 그 과정을 공유하려는 것이 이 글의 목적이다.

애자일 선언

이 글에서는 애자일 소프트웨어 개발 혹은 애자일 방법론 자체에 대해 설명하지는 않을 것이다. 실제로 스크럼(Scrum)을 채택했다고는 하나, 이미 필자는 RUP(Rational Unified Process) 류의 방법론에 익숙해 있고, 스크럼 자체에 대한 필요 이상의 학습비용을 지불할 생각이 없다. 그보다는 과거의 프로젝트 수행 경험에 비춰볼 때 애자일 선언(Agile Manifesto, http://www.agilemanifesto.org/)은 매우 공감하는 가치 기준을 제시해 주었고, 이를 현장에서 활용하고자 했다. 애자일 선언에서는 소프트웨어 개발 방식에 있어 대비되는 가치를 기준으로 추구하는 바를 정의한다.

- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan

각 항목에 대한 내용을 여기서 설명하기보다 사례와 함께 이야기하도록 하겠다.

프로젝트 단계

프로젝트는 도입, 구축 및 이행의 3단계로 나누어 진행하고 있다. 아직 이행 단계를 수행하지 않은 시점이라 도입과 구축 단계에 대해 사례를 짚어본다. 각 단계별로 애자일 선언의 가치 기준을 기초로 애자일 프랙티스 적용이 종래의 경험에 비해 어떠한 개선을 가져왔는지 살펴보자. 사전 정의 없이 애자일 프랙티스라는 말을 사용했는데, 앞으로 ‘애자일 선언의 가치에 준하는 문제 해결책’을 애자일 프랙티스라고 지칭하겠다. 

도입 단계에서의 애자일 프랙티스

도입 단계는 전체 26주의 기간 중에서 초반 4주에 해당한다. 프로젝트 범위를 결정하는 기간인데, 이때 가장 초점을 맞춘 부분은 실현 가능한 계획 수립과 요구사항의 확정이다. 여기까지는 사실 애자일 소프트웨어 개발이 어떤 도움을 주었는지 살펴보자. 자, 이제 애자일 선언의 가치 기준이 등장할 시간이다.

● 변화를 수용할 수 있는 계획을 세운다 - Responding to change over following a plan

애자일 선언에서는 계획을 따르는 것도 가치가 있지만, 그보다는 변화에 대한 적응에 더 높은 가치를 부여한다고 강조한다. 필자가 앞서 참여한 대부분의 프로젝트에서는 WBS를 작성하는 데 많은 공수를 소요했다. 고객과 개발팀은 WBS를 PMS 등을 이용하여 공유하고, WBS 상의 계획을 기준으로 진척을 산정했다. 프로젝트가 새로운 업무나 기술을 다룰수록,  그리고 규모가 클수록 더 많은 변화의 가능성을 내포하고 있다. 하지만 대개의 경우 조기에 수립한 계획을 변경하는 일은 무척 번거로운 과정을 거쳐야 했다.

우리 프로젝트의 경우도 단위 시스템 개발이 아닌 플랫폼 성격의 제품 개발이기 때문에 전략적 결정에 의해 요구사항 변경의 여지가 많다. 또한 고객 스스로도 필요한지 확신을 갖지 못하는 요구사항에 대해서도 유리한 고지를 점하기 위해 계약에 명시하고 있었다. 이와 같이 변경 가능성을 내포하고 있는 항목을 기준으로 계획을 수립한다면, 계획 변경의 여지가 많아진다. 이런 경우 먼저 변경할 수 있는 것과 할 수 없는 것을 구분해야 한다. 가장 먼저 고객사의 WBS 양식과 샘플을 구했다. 계획 사항 중에서 내규에 따라 진척 평가가 어떻게 이루어지는지 파악했다. 이를 기준으로 특정 단계까지는 가중치를 고정하고, 해당 단계 하위의 작업 항목에 대해서는 변경하여도 진척 평가에 영향을 미치지는 않게 했다.


<화면 1>에서 우측 음영 처리가 있는 부분의 글은 WBS 변경에 대한 메모다. 프로젝트 중반 이후부터는 변경이 발생했다는 이야기다. 만일 이 부분에 대해 도입 단계에서 고정해 두었다면, 고객의 이해를 구하기 위한 설득 작업이 필요했을 것이다. 경우에 따라서는 고객이 계층적으로 존재하여 많은 보고 절차가 빈번하게 필요하기도 하다. 다행히 우리는 이러한 번거로운 절차를 피할 수 있었다. 이로써 얻은 교훈은 필연적으로 바뀔 가능성이 있는 부분을 인정하고 여지를 두라는 것이다. 

● 소프트웨어에 집중하라 - Working software over comprehensive documentation

현장에서 종종 지나치게 상세한 명세 작업 혹은 표준화 및 기법에만 초점을 맞춘 요구사항 모델링으로 비생산적인 분석 작업을 하는 것을 경험한다. 종국의 결과물은 작동하는 소프트웨어란 사실을 잊지 말아야 한다. 도입 단계에서 모호한 요구사항을 밝혀내는 일은 쉽지 않았다. 고객들마저 정확하게 무엇이 필요한지 모르는 상황이기 때문이다. 조기에 확정하기 어려운 것을 정하는 데 지나치게 시간을 투여할 우려가 있어 명세 자체보다는 요구사항 충족 기준이 되는 검증 기준 수립에 초점을 두었고 이는 <표 1>에서 보는 바와 같다. 이로써 약 10주 후에 소프트웨어를 구현했을 때 사용할 지표를 2주 만에 만들 수 있었다. 앞서 말했던 것처럼 무리한 듯 보이는 개발 범위에도 불구하고, 10주 후 70개의 모든 기준을 충족시킬 수 있었던 요인 중에 하나는 ‘5대1’ 비율, 즉 ‘요구사항 정의 2주 대 소프트웨어 개발10주’에 있다.




구축단계에서의 애자일 프랙티스

도입 단계는 전체 26주의 기간 중에서 중반 15주에 해당한다. 실제 제품 개발의 대부분을 수행하는 단계이다. 애자일 프랙티스를 도입했을 때 구축 단계의 가장 두드러진 특징 중 하나는 조기에 통합이 이뤄진다는 점이다. 이는 이행 단계의 부담을 한결 줄여준다. 결론부터 말하자면 조기 통합 및 상시 통합 수행은 구축단계에서 빠른 피드백과 팀 협력을 가속화하는 효과를 가져왔고, 이행 단계로 연착륙할 수 있게 하는 데 큰 공헌을 했다. 

● CI 적용 과정에서 배운 협업의 가치 - Individuals and interactions over processes and tools

프로젝트 초기에 필자는 툴과 프로세스에 초점을 맞춰 환경을 잘 구비하고 단위테스트만 잘 실시하면 CI(Continuous Integration), 다시 말해 지속적인 통합이 가능할 것이라고 보았다. 그러나 툴의 이점은 분명히 한계가 있었고, 프로세스 실현은 그리 간단하지 않았다. 우리는 이번 프로젝트 처음으로 손발을 맞춘 팀이었고, 당연히 프로세스가 몸에 밴 팀은 아니었다. 또한 프로젝트 일정 역시 프로세스를 익힐 만큼 여유 있지는 않았다. 여기서 필자는 해결책이 필요했다. 결국 개개인의 특성 파악으로 들어갔다. 프로젝트를 하면서 종종 그 사실을 잊어버리지만, 우린 모두 개성을 지닌 존재이다.


우선 각자 자신이 만들어야 할 산출물을, 그리고 해당 산출물을 통한 다른 사람과의 관계를 표현하게 했다. 작업자와 산출물 사이에 선을 그으면 행위가 나타난다. 필자는 이를 문맥도(context diagram)라 칭하고 모두에게 편한 방식으로 그려오게 했다. 흥미롭게도 관리자인 필자와는 달리, 대부분의 사람들이 주변 개발자와의 관계를 완벽하게 알지 못했다. 필자는 그 부분을 찾아서 그려주었다. 이후에 팀원 개인과 서로가 맺고 있는 관계(Individuals and interactions)가 정형화된 부분에 대해서만, 이를 프로세스로 정의해 공유했다.
문맥도를 그려보기 이전에는 팀원들이 자신의 작업에만 관심을 둔다고 오해했다. 팀원들은 다른 팀원의 일에 관심이 없었던 것이 아니었다. 전체를 볼 수 있는 사람이 서로 협력이 필요함을 알게만 해준다면 문제는 스스로 해결되었다.

● 고객과 마치 하나의 팀처럼 협력하라 - Customer collaboration over contract negotiation

프로젝트에 잔뼈가 굵은 사람이라면 ‘계약서’, ‘날인한 회의록’, ‘명세서’ 등을 중요하게 취급한다. 하지만 분쟁이 발생했을 때 이들이 개발팀을 유리한 입장에 놓을 수 있을지 몰라도, 그 이상의 가치는 없다. 구축 기간 초반에 앞서 언급한 것처럼, 70개의 기준을 충족했을 때 고객과 개발팀 사이에 신뢰 관계가 형성됐다. 신뢰 관계는 고객과 사전 협의한 사항에 대한 변경이 용이해졌음을 의미한다. 개발팀은 애초부터 지나치게 기술적인 어려움을 의식해서 요구사항 수용을 거부할 필요가 사라졌다. 고객은 언제든지 개발팀의 입장을 이해할 준비가 되어 있었다. 개발팀은 신뢰를 깨뜨리는 우를 범하지 않는 이상 계약관계에 입각해 서로를 인식하는 데 에너지를 쏟는 대신에 본연의 활동 즉, 개발에 대해 집중할 수 있었다. 자신감을 얻은 우리는 고객의 요구사항 수집에 있어서도 장벽을 제거했다.

우리는 <화면 3>과 같이 개발도구에서 작업목록을 볼 수 있는 환경을 구축하고 있는데, 고객이 직접 올린 요청사항을 작업목록에 포함시켰다. 고객 요청의 즉각적인 수렴과 기민한 커뮤니케이션은 고객의 개발팀에 대한 신뢰감을 더욱 높여주었다. 종국에 고객과 개발팀의 협력은 마치 오랫동안 함께 해온 조직 구성원의 일상적인 협력을 보는 듯했다. 물론 이러한 협력을 모든 프로젝트에서 실현할 수 있다고 할 순 없을 것이다. 착수 보고 때 프로젝트 스폰서인 임원이 ‘고객’이라는 말에 대해 거부감을 표시하며, ‘어차피 같이 일하는 사람인데 고객은 무슨’이라며 호칭을 나무랐다. 고객들은 향후 인수인계와 기술 이전을 받는 데 매우 적극적이었기 때문에 고객과 마치 한 조직 내에 속한 다른 팀처럼 일할 수 있었다.




경험의 산물, 애자일 프랙티스

애자일 프랙티스는 SI 개발 환경에서 오랜 논의 끝에 나온 경험의 산물이다. 연구소나 학계에서 나온 것이 아니란 점에서 ‘새로운 방법론의 하나’로 취급하는 것은 실용적이지 않다. 오히려 현재 사용하는 혹은 익숙한 방법론이나 개발 프로세스를 사용하면서도 단계적으로 애자일 프렉티스를 충분히 적용할 수 있다. 이 글은 이에 대한 하나의 사례를 제공함으로 해서 현장에 응용하기 위한 논의의 단초를 제공하는 데 의미를 지닌다.

 

<프로젝트 수행 과정에서의 갈등 그리고 조화>

나이가 들수록 조화와 균형을 배운다. 어릴 때는 ‘이것이 옳다’ 싶은 것에 대해선 물러서지 않았다. 다른 사람과 어울림을 통해 다른 생각이 있다는 것을 배우고, 점차 나를 둘러싼 주변과의 어울림을 받아들인다. 어떤 이는 이를 세상과 타협하는 것이라 하지만, 조화를 이루기 위해 나와 생각이 다른 사람과 타협할 뿐이다. 프로젝트를 수행하다 보면 필연적으로 많은 변수를 맞이한다. 참여하기로 했던 개발자가 불가피한 이유로 참여를 못할 수도 있다. 다른 업체나 부서의 사정으로 장비 구매가 늦을 수도 있다. 더러는 가장 중요한 협업 담당자가 장기 출장을 가버리기도 한다. 어디 이런 일이 한 두 가지뿐이겠는가? 흔히 발생하는 경우는 아니지만, 개발 도중에 법이 바뀌거나 고객 조직의 대대적인 인사이동으로 인해 프로젝트 자체가 위기에 몰리기도 한다. 만일 프로젝트 초반에 구체적으로 일정을 수립했다고 했을 때, 앞서 언급한 일이 벌어져도 이를 완벽하게 맞출 수가 있을까?

또뜨웍스(ThoughtWorks)사의 직원들이 출간한 책 “The Thought Works Anthology: Essays on Software Technology and Innovation (Pragmatic Programmers)”의 7장에서 의사결정의 적기에 대해 이야기하는 부분은 이 문제에 대해 훌륭한 영감을 준다.

많은 사람들이 불확실한 것을 미리 분명하게 계획해 두려는 경향이 있다. 하지만 예측이 힘든 일은 너무나도 많을 뿐더러 판단에 필요한 정보를 충분히 수집한 후에 결정해야 실행에 옮기기 쉽다. 필자는 일년 단위로 업무 성과를 측정하는 기업에서 발주한 프로젝트에 참여한 바 있다. 담당 부서에서는 프로젝트 진척을 자신들이 해오던 식으로 파악하고자 했다. 그래서 매 2주마다 진척 산정이 가능한 작업을 계획해주길 원했고, 가능하다면 모든 작업은 고유한 산출물을 제출해주길 원했다. 그런데 우리 프로젝트는 요구사항에 대한 가변성이 너무 높았다. 우리는 이미 수십여 개의 기능 목록을 달성한 프로젝트를 수행한 이후였다. 고객은 우리가 만든 제품을 특정 프로젝트마다 필요한 다양한 기능을 추가하기 위해 좀 더 튜닝해주길 원했다. 하지만 우리 제품을 채택한 프로젝트의 요구에 따라 작업 내용은 달라질 수밖에 없었다. 물론 사전에 요구사항을 정하면 되겠지만, 고객들은 해당 시점에 결정하길 원했다. 이런 경우 우리는 어떻게 가변적인 요소를 수용하면서 해당 기업의 평가 방식에 부합하는 계획을 만들 수 있을까?

우리는 나름의 답을 찾았다. 그것은 어디에나 적용할 수 있는 답은 아니고, 만들어낸 과정조차 명확하지 않다. 필자는 개발팀을 대표하여, 해당 부서 책임자와 함께 평가조직 담당자를 만나 머리를 싸매 협의했다. 그리고 또 다른 실무자들과 머리를 맞대어 논의한 후, 부족하게라도 합의한 것을 메모로 정리했다. 이를 기초로 초안을 계획하고, 다시 해당 부서 책임자와 검토했다. 그는 다시 스스로 이를 정제한 후에 검토를 요청했고, 수일 후에는 앞서 협의에 참여한 이해관계자가 고개를 끄덕일만한 계획표를 만들어냈다. ‘조화’라는 말은 듣기에 좋다. 하지만 조화를 이뤄낸 과정을 들어다 보면, 이와 같이 끈질긴 갈등과 타협으로 이루어진다.





     KSUG, MSW, SI프로젝트, 개발자, 마소, 마이크로소프트웨어, 스프링, 스프링프레임워크, 아이마소, 안영회, 애자일, 애자일 프랙티스, 월간마소, 한국스프링사용자모임, 호랭이
     1   
BlogIcon okgosu 2009.02.20 11:40 신고
잘 보고갑니다
실제는 방법론보다는 고객의 요구사항이 더 애자일해서리...
개발자들이 늘 밤새며 고생하지요....
BlogIcon 호랭이 2009.02.26 01:52 
으하하하하하하하하하하하
프로젝트보다 더 애자일 한 고객 요구사항이라니...
아이고 깰꾸닥!!!

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

 

 

2009년에 주목할 IT 테크놀로지-3 [U-커머스]
+   [마이크로소프트웨어]   |  2009. 2. 5. 14:04  






온라인 전자상거래는 현대인들에게 있어서 이미 철지난 IT 키워드일지도 모르겠다.

특히 국내의 경우처럼 전자상거래 시장이 사실상 포화 상태에 다다른 상황이라면 전자상거래라는 용어 자체가 마음에 크게 와 닿을 리 없다.

그만큼 우리 대다수는 옥션과 지마켓으로 대표되는 각종 온라인 쇼핑몰에 익숙해져 있을 뿐 아니라, 심지어 정도의 차이는 있겠지만 디바이스 구분에 따라 파생된 E-커머스(PC 인터넷), M-커머스(모바일), T-커머스(인터넷 TV)라는 개념과 이 세 가지 모두를 아우르는 U-커머스(유비쿼터스)를 충분히 이해하고 있다.

이런 현실에서 기자는 왜 전자상거래와 U-커머스에 주목해 이번 커버스토리의 한 가지 소재로 선정했을까?



몇 가지 관점에서 설명할 수 있다. 먼저 오래도록 쓰였던 전자상거래 시스템의 교체 시기가 마침내 도래했다는 산업적인 근거를 들 수 있다.

지금까지의 전자상거래 시스템이 거래를 성립시키는 기능 구축에만 초점을 맞춰 왔다면 U-커머스로 대표되는 이후의 전자상거래 시스템은 질적 향상과 더불어 이용자들의 감성적인 만족도를 꾀하는 데 목표를 둘 것으로 예상된다.

따라서 지난 수 년 간의 핵심 트렌드였던 SOA와 웹2.0 등의 가치를 실제로 실현해 비즈니스 지원 역량과 편의성, 그리고 심미적인 완성도를 모두 강화하는 쪽으로 전자상거래 시장이 변화할 전망이다.

RIA(X 인터넷)나 SNS(Social Network Service) 같은 요소가 U-커머스 시장에서 크게 부각되고 있는 것도 이 때문이다.

전자상거래에 특화된 글로벌 소프트웨어 기업의 패키지 제품군이 등장해 주로 인하우스 개발에 의존해 온 기업들에게 대안을 제시하고 있는 것도 이 분야의 관심을 증폭시키는 한 가지 변수다.

지금껏 비용적인 측면에서 인하우스 개발이 선호되었던 게 사실이지만, 지나치게 잦은 변경과 유지보수의 어려움으로 인해 소프트웨어 패키지 제품군으로 안정적인 전자상거래 시스템을 구축하려는 움직임도 서서히 감지되고 있다.
 
IBM이 2008년 선보인 웹스피어 커머스(WebSphere Commerce)가 대표적인 예로, 이 제품은 제조업체의 자체 유통망 구축에 유용한 웹스피어 프로페셔널과 다양한 커머스 분석 기능을 갖춘 웹스피어 엔터프라이즈 두 가지 패키지로 국내에 소개됐다.

한국IBM에서 소프트웨어 마케팅을 맡고 있는 이상민 차장의 얘기를 들어봤다.



“흔히 전자상거래 시장을 기본이 되는 단말 디바이스에 따라 구분하곤 하는데, IBM은 이런 디바이스 차원이 아니라 비즈니스 모델 자체에 중점을 두고 U-커머스 비즈니스를 해나갈 것입니다.

디바이스는 인프라가 구축된 이후 사용자 관점에서 고려할 문제이므로, 한국IBM은 국내의 모든 온라인 전자상거래 시장을 동일한 인프라를 쓰는 하나의 커머스 환경으로 보고 시장에 접근할 계획입니다.” 



아울러 그는 2007년까지 그다지 상황이 좋지 않았던 전자상거래 시장이 2008년을 거치며 다소 정리된 모습을 보이는 만큼, 새로운 타깃을 노리는 마케팅 전략을 바탕으로 새로운 수요를 이끌어낼 수 있을 것으로 기대했다.

특히 그가 주목한 곳은 종전의 리테일 영역이 아니라 일반적인 제조업체군. 대내외적인 이유로 판로 확보에 어려움을 겪는 제조업체들이 웹페이지를 활용한 직접 비즈니스 모델 구축에 큰 관심을 나타내고 있는 만큼, 전자상거래 시장에 새로운 활력을 불어넣을 수 있다는 분석이다.

이처럼 전자상거래에서의 비즈니스 모델이 종전의 B2C에서 B2B와 B2B2C로 다양해지면서 유연성에 대한 업계의 요구사항이 한층 뚜렷해지고 있고, 그에 따라 커머스 아키텍처 자체를 다양화함으로써 유연성을 확보하는 것이 시급한 과제로 떠오르고 있다.



온라인 전자상거래 시스템에서 최근 빼놓을 수 없는 이슈는 바로 보안이다.

일부 쇼핑몰의 고객정보 유출 사고에서 확인했다시피 커머스의 기본은 신뢰와 안전에 있는 만큼, 보안적인 요수사항은 글로벌 소프트웨어 벤더뿐 아니라 U-커머스에 직간접적으로 연관된 다수의 개발자들에게 극복해야 할 도전 과제와 기회를 함께 제공하고 있다.

오랜 기술적 흐름을 이어온 전자상거래 시스템이 이런 시대적 요구를 해결하고 2009년 이후의 주요 테크놀러지이자 인더스트리로 다시금 정착할지 지켜볼 일이다.

월간 마이크로소프트웨어에 실린 글을 발췌한 글입니다.
원분은 아이마소홈페이지에서 볼 수 있습니다.





     MSW, U-커머스, 개발자, 마소, 마이크로소프트웨어, 온라인상거래, 월간마소, 유비쿼터스, 이상민차장, 커머스, 한국IBM
     0   

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

 

 

2009년에 주목할 IT 테크놀로지-2 [모바일 애플리케이션]
+   [마이크로소프트웨어]   |  2009. 2. 3. 10:06  





‘공개’와 ‘공유’를 표방했던 개발 패러다임은 기술의 질적 향상과 확산에는 크게 기여했지만 개발의 가치와 수익 보호라는 측면에서는 문제점을 나타냈다.

이런 한계는 부분적으로 개발자의 동기 약화로도 이어져 이런 상황을 극복할 새로운 대안을 요구하는 목소리가 끊이질 않았다.


이런 상황에서 폐쇄적인 개발 인프라와 소프트웨어 배포 환경을 표방하는 애플 아이폰은 적어도 개발자의 수익 보호라는 측면에서는 매력적인 환경을 갖추고 있다.

아이폰 애플리케이션을 등록 및 판매할 수 있는 루트는 오로지 앱스토어(AppStore)뿐이고, 제한된 인터페이스 외에는 애플리케이션을 얹을 운영체제의 정보도 전혀 알 수 없을 만큼 아이폰은 폐쇄적인 플랫폼이다.

그럼에도 아이폰 애플리케이션 개발에 많은 개발자들이 흥미를 느끼고 있다. 왜 그럴까? 최근 아이폰 애플리케이션 개발에 몰두하고 있는 개발자 이창신 씨는 그 매력을 다음과 같이 설명한다.


“아이폰은 창의적인 아이디어를 직접 실현해 볼 좋은 플랫폼입니다.

좋은 아이디어로 실질적인 수익을 기대할 수 있어 개발자 입장에서는 무척 안전한 시장이라는 의미죠.

사실 PC로 상징되는 지금까지의 컴퓨팅 환경에서는 노력의 대가가 충분히 보호되지 않아 극한의 창의력이 발휘되기 어려웠습니다.

이미 애플리케이션 이용자들이 소프트웨어의 가치에 무감각해진 탓이죠. 하지만 아이폰은 달랐습니다.

소프트웨어를 만드는 이와 사용하는 이들이  더 실질적인 관계를 만들어 훨씬 가치 있는 애플리케이션이 제공될 바탕을 마련하는 데 성공한 것입니다.”



그러나 이창신 씨는 아이폰 애플리케이션의 이런 특성이 국내에서도 유효할지에 대해서는 의문부호를 남겨뒀다.

아이폰이 국내에 출시되더라도 그다지 큰 시장을 형성하지 못할 가능성이 높은데다, 국내 이용자들의 소프트웨어 가치에 대한 인식이 유독 더 낮기 때문.

그가 현재 글로벌 시장을 지향하는 애플리케이션 개발에 주력하고 있는 것도 이런 이유로 풀이된다. 



아이폰은 하드웨어, 소프트웨어, 애플리케이션, 배포 방식 등 거의 모든 면에서 현존하는 가장 우수한 플랫폼 가운데 하나로 꼽힌다.

특히 글로벌 시장에 직접 배포할 수 있다는 점에서 좁은 무대를 아쉬워했던 국내 개발자들에게 더 매력적인 환경이다.

비슷한 시기에 등장한 구글 안드로이드가 아직은 디바이스 시장 볼륨이 크지 않아 국내 애플리케이션 개발자들에게 좋은 기회가 될지 미지수라는 점에서도 아이폰 애플리케이션의 인기는 당분간 이어질 전망이다.

즉 현 시점에서는 모바일 애플리케이션 전체의 강세라기보다는 아이폰 애플리케이션에 국한된 개발만이 화두가 되고 있다고 보는 게 정확할 것이다.




“플랫폼 소스나 애플리케이션 배포 정책에서 비롯되는 여러 가지 폐쇄성에 대해 일반적인 아이폰 이용자들은 관심조차 없고 굳이 알 필요도 없습니다.

오히려 아이폰 하드웨어에 대한 이용자들의 높은 기대감과 만족도가 소프트웨어의 만족도를 덩달아 높여주는 일종의 ‘후광 효과’를 기대할 수 있는데, 이것이 아이폰 개발자에겐 든든한 밑천이 되고 있죠.”



각 지역(국가)의 모바일 플랫폼 시장에서 아이폰의 성패는 해당 지역의 ‘킬러 앱’을 얼마나 확보하는지에 달려 있다는 게 이창신 씨의 설명.

아이폰의 경쟁 상대는 단지 다른 스마트폰이 아니라 PC를 비롯한 모든 디바이스이기 때문이다.

이용자들이 PC에서 즐기던 게임이나 손에 익은 애플리케이션이 인터페이스 방식이나 비용 등을 이유로 아이폰에 흡수되지 않는다면 아이폰은 단지 일부 마니아들을 위한 ‘고급 폰’에 머무를 수도 있다.



애플은 현재 아이폰 애플리케이션의 개발 인프라를 키우는 데 그다지 적극적인 모습을 보이진 않고 있다.

과거 썬이 자바 개발자의 볼륨을 늘리기 위해 다양한 교류를 시도했던 것과 비교하면 전혀 다른 양상이다.

그래서일까?

아이폰 애플리케이션 개발은 여전히 진입 장벽이 높고 그로 인해 빠른 시간 내에 기술 격차가 커질 가능성이 많다.

분명 폐쇄적이다.

그러나 이를 뒤집어 생각하면 먼저 진입해 개발 노하우를 쌓은 이들에게는 매우 좋은 기회가 될 것이다.

‘창의적인 생각을 실현할 플랫폼’이라는 평가를 충분히 되새겨 봐야 할 지금이다.

월간 마이크로소프트웨어에 실린 글을 발췌한 글입니다.
원분은 아이마소홈페이지에서 볼 수 있습니다.




     MSW, 개발자, 마소, 마이크로소프트웨어, 모바일애플리케이션, 아이팟, 아이폰, 아이폰 애플리케이션, 애플, 앱스토어, 월간마소, 이창신
     0   

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

 

 

2009년에 주목할 IT 테크놀로지-1 [로보틱스]
+   [마이크로소프트웨어]   |  2009. 2. 2. 14:14  





호랭이는 "요즘에 뭐 재미있는 일 업나요?"나 "어떤 기술들이 뜨게 될까요?"라는 질문을 자주 받게 됩니다.

마침 마소 신년호 특집에 이와 관련된 내용이 있어 옮겨봅니다.

이 글은 너무 길어서 세 번으로 나눠 쓰게 될 텐데요.

여기에 클라우드 컴퓨팅과 소셜네트워크에 대한 내용은 없습니다.

이는 기존에 다른 특집과 스페셜리포트에서 다뤄진 탓에 논외로 했기 때문이고요.

이 부분들에 대해서는 요즘 호랭이도 관심이 많으니 나중에 좀 더 정리해서 올려보도록 하겠습니다.

자 그럼 첫번째 주제인 로보틱스 올라갑니다요.

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

로보틱스 이야기를 하기 위해서는 먼저 로보틱스에 대한 명쾌한 이해가 필요할 것 같다. 

어린 시절 봤던 이른바 ‘공상과학만화’의 영향 때문일까? 로보틱스라는 용어를 들었을 때 가장 먼저 떠올린 이미지는 우습게도 팔다리가 달린 ‘태권 V’나 ‘마징가 Z’와 같은 만화 속의 인간형 로봇이었다.

이런 선입견(?)은 마이크로소프트의 로보틱스 그룹에 몸담고 있는 김영준 수석을 만난 후에야 비로소 사라졌다.



“로봇산업은 완전한 형태를 갖춘 완성품(패키지) 시장을 의미하지만, 로보틱스는 로봇과 관련된 기술 개발 툴을 비롯해 소프트웨어, 하드웨어 부품 연구를 모두 포함하는 총체적인 개념으로 정의됩니다.

아직 로봇시장은 존재하지 않지만, 로보틱스는 이미 오래전부터 시장을 형성하고 있습니다.

결국 로보틱스를 거쳐야만 로봇산업으로 발전하게 되는 데, 아직 로봇산업이 꽃을 피울 시기는 도래하지 않은 셈입니다.”



마이크로소프트를 비롯한 대부분의 글로벌 기업들은 로보틱스 시장이 지금의 PC산업처럼 활성화되려면 적어도 5년의 시간이 더 필요하고, 그것이 밑거름이 되어 로봇이 대중화될 것으로 예상한다.

우리 산업계도 이런 흐름과 크게 다르지 않다. 2000년대부터 서서히 로보틱스에 관심을 가져오다가, 3년 전부터 정부 차원에서 본격적인 투자가 이뤄지기 시작했다.

아직은 로봇 관련 TV 프로그램을 제작해 로봇을 알리는 데 중점을 두는 수준이지만, 머지않아 이런 행보에 가속도가 붙을 것으로 기대되고 있다.



현 시점에서 로보틱스의 중요한 변화는 무엇일까?

지금까지는 하드웨어 중심으로 로보틱스가 발전해 왔지만, 앞으로는 소프트웨어 중심으로 로보틱스 산업이 발전할 것이란 점이 가장 먼저 눈에 띈다.
 
따라서 로보틱스를 겨냥한 소프트웨어 개발 툴을 제공하려는 움직임이 점차 뚜렷해지고 있고, 이식성과 호환성이 약점으로 지적되는 로보틱스를 위한 우수한 애플리케이션의 개발이 로보틱스 산업의 당면 과제로 부각되고 있다.



PC 산업과 마찬가지로 호환성과 이식성이 지원되는 소프트웨어를 만드는 것이 중요하다고 강조하는 김영준 수석은 개선된 형태의 스마트 PC, 그것이야말로 로보틱스의 미래일 것이라고 설명한다.

즉 로보틱스를 PC 영역이 확장된 형태로 생각해야 한다는 것이다.

로봇에 필요한 메카닉적인 요소는 이미 수십 년 전부터 연구되어 왔으므로, 지금 이 순간에는 소프트웨어 개발에 필요한 툴과 각종 라이브러리 및 컴포넌트, 그리고 샘플 프레임과 같은 개발 인프라가 요구되고 있다.



로봇 산업에서 요구되는 소프트웨어는 크게 애플리케이션과 솔루션으로 나뉜다.

종전까지는 펌웨어로 대표되는 내장 프로그램만이 로봇에 존재했지만, 앞으로는 개발 툴과 라이브러리, 컴포넌트에 의해 만들어진 진정한 애플리케이션이 요구된다. 그럼 솔루션은 무엇일까?

솔루션은 다수의 애플리케이션이 결합해 특정한 목표를 수행하는 기능적 실체를 의미하는 것으로 이는 곧 로봇의 역할과 용도를 규정하는 기준이 된다.

김영준 수석은 다음과 같이 덧붙인다.

“지금의 젊은 세대들은 PC를 쓰면서 일상의 모든 것을 해결할 수 있지만 유아나 노인들은 그렇지 못합니다.

로봇산업은 이런 디지털 약자들을 일차적인 잠재 고객으로 보고 있습니다.”



아쉽지만 우리가 상상 속에 그려오던 대화가 가능한 인공지능형 로봇은 적어도 10년은 더 지나야 실현될 만한 기술이다.

게다가 인공지능은 단지 로봇만을 위한 연구라기보다는 소프트웨어 전반을 아우르는 이슈이므로, 일단은 애플리케이션과 솔루션에 초점이 맞춰져 있다.

그럼에도 로보틱스에 대한 소프트웨어 개발자들의 인식과 이해도는 여전히 낮다.

로보틱스 소프트웨어 개발은 로봇 관련 전공자들이 아니라 소프트웨어 개발자들이 맡아야 할 일임에도 전체 소프트웨어 개발자의 1% 이하만이 이 분야에 관심을 보이고 있다.

진화된 PC의 한 형태로 접근한다면 로봇에 대한 이해가 그다지 필요 없음에도 불구하고 여전히 ‘자신과는 무관한 영역’으로 여기고 있는 탓이다.

김 수석은 아마도 적은 취업 기회 때문일 것이라고 원인을 분석하면서도, 머지않아 로보틱스가 많은 이들에게 기술 혁신과 비즈니스 기회를 안겨줄 블루오션이 될 것임을 끊임없이 강조한다.



“기업들은 앞으로도 로봇 자체를 만들고 생산하는 일에 충실하겠지만, 그 실질적인 활용 형태는 꿈을 가진 개발자들과 학생들의 적극적인 참여로써만 발굴할 수 있습니다.

그런 만큼 남들보다 앞서 이 분야에 도전해 경험을 쌓는다면 미래의 산업적인 변화에서 우수한 경쟁력을 가지게 될 것입니다.

마이크로소프트는 전통적인 영역의 개발자들이 이런 흐름에 관심을 가질 수 있도록 국제 규모의 로봇 챔스(Robot Champs) 대회를 개최하고 있고, 최근에는 이매진컵(Imagine Cup)에 로보틱스 분야를 추가해 현재 예선을 치르는 등 다양한 노력을 펼치고 있습니다.”



마이크로소프트가 출시한 MS 로보틱스 개발자 스튜디오(MS Robotics Developer Stuido, MSRDS)도 로보틱스를 타깃으로 하는 소프트웨어 업계의 움직임을 상징적으로 보여주는 개발 도구로, 하드웨어에 얽매이지 않는 이식성과 호환성을 제공하는 데 중점을 두고 있다.

메카닉 이외의 영역에서 이뤄지는 크고 작은 시도들이 모여 결국 우리가 미래에 접할 로봇의 모습을 규정하는 만큼, 그 개발 과정에 직접 참여해 보는 것도 시대를 앞서는 매우 의미 있는 도전으로 기록될 것이다.

월간 마이크로소프트웨어에 실린 글을 발췌한 글입니다.
원분은 아이마소홈페이지에서 볼 수 있습니다.





     MSW, 개발자, 김영준 수석, 로보트, 로보틱스, 로봇, 로봇산업, 마소, 마이크로소프트, 마이크로소프트웨어, 소프트웨어 개발 툴, 월간마소
     0   
BlogIcon Jelly君 2009.02.02 15:01 신고
태권브이는 왜나오지..ㅋ
BlogIcon 마소호랭이 2009.02.02 15:05 신고 
태권브이는 짤방입니다. ㅎ.ㅎ
BlogIcon 학주니 2009.02.02 17:32 신고
짤방이 더 끌리는군요 ^^
BlogIcon 마소호랭이 2009.02.02 20:09 신고 
ㅎ.,ㅎ

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

 

 

[개발자 영어-3] Trustworthy Computing에 대하여-2
+   [마이크로소프트웨어]   |  2008. 10. 15. 15:46  



이 글에 이어지는 글입니다. 

5. Automate! (자동화하라)
At the outset of a security improvement regimen, there is a great deal of manual work?manual code review, manual design reviews, and so on. To really elevate your work, you need to automate as much of the process as possible.
보안 개선 계획의 시작 부분에는 수동 코드 검토, 수동 설계 검토 등 많은 양의 수작업이 필요합니다. 작업의 능률을 높이려면 가능한 한 많은 프로세스를 자동화해야 합니다.

처음의 at~regimen 은 부사구이므로 그대로 해석해 주고, there is 는 ‘~이다’로 해석해 준다.

‘and so on’은 ‘등등’이고, 전치사 ‘to’ 뒤에 명사가 오면 ‘~에게’이고 동사가 오면 ’~를 위하여’로 해석한다.

The prime motivators for automation are scalability and constant use. If you have a great deal of code, you need to automate.And if you want parts of a process to be repeated constantly, then automation is obviously the way to go.
자동화에 대한 가장 주요한 동기 부여 요소는 확장성과 지속적인 사용입니다. 코드의 양이 많다면 자동화가 필요합니다. 또한 프로세스의 일부를 계속해서 반복하려는 경우에도 확실히 자동화를 채택해야 합니다.


6. You’ll Never Reach Zero Security Vulnerabilities
(보안 취약점을 완전히 없애기란 불가능하다)

 

‘너는/할 것이다/결코~않다/도달하다/0/보안/취약점들’이므로 재배열하면 ‘너는 보안 취약점이 ‘0’인 지점에는 결코 도달할 수 없다’인데, 문맥 상 ‘너 You’가 ‘바로 당신’이 아닌 ‘일반적인 사람’ 혹은 ‘보안 취약점을 없애려는 사람’을 의미하여 여기는 해석할 필요가 없고 중요한 내용은 ‘0에 도달하기가 결코 쉽지 않다’는 의미다.


7. Security Is a Never-Ending Battle
(보안은 끝없는 전쟁이다)


 

8. There Is No Security Silver Bullet
(보안에 완벽한 방법은 없다)

 

여기서 ‘there’는 의미를 굳이 해석할 필요가 없다.

Silver Bullet은 ‘묘책/완벽한 방법’의 의미로, 뱀파이어를 죽게 만드는 방법에서 유래된 말이다. 


9. The “Many Eyeballs” Mantra Is Right!
(많은 검토자 이론은 옳다)


 

10. Today’s Denial of Service Is Tomorrow’s Exploit
(현재의 서비스 거부는 미래의 코드 실행 취약점이다)


개발자 영어 1탄 끝!!!

개발자 영어 1탄-1 보기
개발자 영어 1탄-2 보기





     IT 영어, MSW, 개발자, 개발자 영어, 기영모, 마소, 마이크로소프트웨어, 영어, 영어로 여는 세상, 영어로 읽는 세상
     0   

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

 

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

열이아빠's Blog is powered by Daum