태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

 

 

 

 
분류 전체.. (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,931
+ Today : 1
+ Yesterday : 6
  

 

 

 

월간 마소 _해당되는 글 13건
2010.01.26   아이폰과 RIA 2010 
2009.11.23   개발 방법론에 생명 불어넣기 (3)
2009.01.08   2009년 돌파를 위한 개발자 필수 2종 세트 (7)
2009.01.03   2009년에 임하는 당신의 사자성어는? (8)
2008.12.23   마소의 생일은 1년에 두 번!! (15)
2008.12.06   그대 내게 행복을 주는 사람~ (4)
2008.12.03   한눈에 보는 대한민국 IT 25년... (6)
2008.10.13   열정을 코딩하는 개발자 '권용휘' (5)
2008.10.05   '전망' 그것은 아무것도 아니다 (11)
2008.10.04   [만화] 개발의 달인!!! (4)

 

아이폰과 RIA 2010
+   [마이크로소프트웨어]   |  2010. 1. 26. 05:37  


아이팟 터치만 꺼내놓아도 레어아이템이던 떄가 채 두 달 도 지나지 않았습니다. 하지만 요즘 제 아이팟 터치는 얼리어댑터들이 모이는 자리에서는 주머니 속에 숨어 있어야 할만큼 아이폰이 많이 보급되었네요. OTL=3=3

아이폰의 국내 출시는 RIA 시장에도 많은 변화를 주고 있는 듯합니다. 아이폰 출시와 함께 다양하고 새로운 경험을 하게된 사용자들을 만족시키려면 그에 걸맞는 경험을 제공해 줘야 하기 때문일텐데요. 월간 마이크로소프트웨어에 실린 글 중 이와 관련된 글이 있어 옮겨봅니다.

출처 | 아이마소


2010년을 준비하는 RIA 이야기

이제는 출퇴근길에도 어렵지 않게 아이폰을 들고 버스도착 시간을 확인하거나 음악을 듣고 메일을 확인하는 사람을 볼 수 있다.

 이미 앱스토어의 성공신화는 개발자의 로망을 다시금 꺼내게 했고 개발서뿐 아니라 아이폰 활용서도 다양하게 선을 보이고 있다.

아마존에서 오랜 기간 베스트셀러로 자리 잡고 있는 아이폰북(스콧켈비, 에이콘)은 다양한 아이폰의 기능만큼이나 많은 내용인 300여 페이지에 달하는 내용을 담고 있다.

그리고 이미 아이폰을 접한 사람들은 이제는 하나의 기기에서 모든 것을 만족스럽게 할 수 있다는 것에 감탄하고 매일 매일 새로움을 경험하고 있다.

이준하 koko8829@naver.com|열이아빠의 RIA 이야기(http://koko8829.tistory.com)라는 블로그를 통해 다양한 시각에서 새로운 RIA에 대한 이야기하고 있으며 새로운 경험을 중심으로 나타나는 여러 가지 현상을 탐구하며 지식을 공유하고 있다.

최근의 뉴스를 검색해보면 아이폰이라는 단어가 하루도 빠지는 날이 없을 정도이다.

뉴스자료를 내지 않아도 아이폰이 들어간 이야기는 커다란 이슈가 되고 무언가를 변화시키고 있다.

고등학생이 만든 무료 버스 도착 정보 앱이 인기를 얻으면서 법적인 문제 때문에 정보 제공을 차단했던 경기도가 하루만에 공개적으로 사과하고 정보를 제공하는 모습까지 보여주고 있다.

경쟁업체의 이슈가 나오더라도 아이폰에 맞선다던지 대적할 만한이라는 수식어를 자연스럽게 달고 나오며 공공의 적으로 취급하려 하지만 여의치 않은 상황이다.

인기 연예인들도 협찬이 아님에도(사실 여부는 확인하지 못했지만) 마치 유명 패션 상품을 협찬 받는 것처럼 아이폰을 구매하고 이를 다른 사람과 공유하고 있다.

아이폰은 단순한 스마트폰이라는 이름을 넘어 ‘엣지 있는’ 시대의 아이콘으로 다가오고 있다. 예상했던 것보다 그리고 예상과 다른 방향으로 대한민국은 달라지고 있다.

5년 전을 되돌아보자.

마소 2004년 5월호에 소개된 알티오라이브에 대한 특집 기고에는 X인터넷을 성인용 인터넷이라고 생각하는 주변의 사람들 때문에 곤란한 적이 있었다는 필자의 에피소드가 소개되고 있다.

국내에서는 X인터넷이 주로 기업용 시장에서 급성장했으며 아직도 적지 않은 영역을 차지하고 있음을 생각하면 격세지감이라는 말이 절로 나오게 된다.

그리고 매크로미디어에서 플래시 MX 2004와 플렉스를 선보이면서 RIA를 이야기하기 시작한 시기이기도 하다.

필자가 처음 플렉스를 접했을 때만 해도 주변에서는 얼마 가지 않아 피어 보지도 못하고 지고 말 기술이라 생각하는 사람들이 대부분이었다.

하지만 어도비에서 매크로미디어를 인수하고 마이크로소프트에서 실버라이트를 발표하면서 웹의 새로운 판도를 크게 만들어내고 있다.

X인터넷 환경도 다양한 형식으로 변화를 시도하고 있으며 리포팅 도구로만 알려져 있던 벤더들도 외부 RIA 플랫폼을 받아들여 새로운 가치를 만들어내고 있다.

그리고 웹은 브라우저를 벗어나 데스크톱으로 옮겨가 강력한 시스템 자원을 활용하기도 하고 모바일 환경에서도 동일한 사용자 경험을 할 수 있는 환경을 만들어 주기도 한다.

일상을 둘러싸고 있는 모든 장치들과도 연동이 가능하고 이러한 경험은 하나의 방향으로 나아가게 된다.

RIA는 세상을 바꾸고 있을까?

그렇다. 아직도 변해가고 있는 중이며 많은 가능성을 제시하고 있다.

지난 한 해 동안 생각했던 RIA의 트렌드를 여섯 가지 주제로 정리해 보고 올 한해는 어떤 이슈가 있을지 예측해 보자.

내 손안에 스크린 - 오픈 스크린

연말에는 새로운 프로젝트에 나가지 않는 것이 좋겠지만 요즘 일하는 곳은 다행스럽게도 무선 네트워크를 복도까지 무리 없이 사용할 수 있어서 사무실에서 확인하기 곤란한 트위터나 미투데이에 새로 올라온 글은 휴게실이나 화장실에서 시간이 날 때마다 살펴보곤 한다.

얼마 전까지는 신문을 들고 들어가던 풍경이 점점 달라지고 있다.

애플의 아이팟 터치를 사용하고 있는데 데스크톱 환경과 크게 다르지 않으면서 모바일에 적합한 UI가 적용되어 사용하는 것이 전혀 불편하지 않고 요즘은 더 익숙해진 것도 같다.

별도의 비용을 들이지 않고도 무선 인터넷이 가능한 단말 장치만 있다면 쉽게 이용할 수 있는 환경이 점차 많아지고 있다.

얼마 전까지 모바일 장치를 통해 정보를 조회하려면 마치 예전 PC 통신처럼 숫자로 구성된 메뉴를 선택하고 그림 하나를 보기 위해 계속 빙글빙글 거리는 대기화면을 보고 있어야 했다.

기존의 RIA 시장이 웹을 중심으로 하는 시장을 새롭게 발견하게 했다면 다음 타깃은 모니터를 넘어서 모바일 장치와 가정용 디바이스에 이르기까지 다양한 매체를 통해 사용자와 만나는 것을 목적으로 한다.

가장 다양한 뉴스거리를 몰고 다니는 기업은 어도비이다. 오픈스크린 프로젝트를 통해 일찍이 다양한 벤더와 연합체를 구성해 기술을 공유하고 있다.

‘다양한 플랫폼상의 동일한 환경과 더 많은 오픈 플랫폼을 통해 개발자들은 보다 빠른 아이디어 창출과 사용자 환경이 개선될 것이다’라는 샨타누 나라얀 어도비 CEO의 이야기는 시장에서 플랫폼의 중요성을 단적으로 보여주고 있다.

이를 위해 그동안 제한되었던 다양한 스펙과 소스를 공개했으며 이를 통해 다양한 오픈소스 프로젝트가 만들어질 수 있도록 하고 있다.

 

사용자 삽입 이미지

플랫폼이라면 구글도 어느새 모바일에 한걸음 다가온 상태이다.

이미 안드로이드폰을 통해 시장의 예측을 뒤엎고 시장 점유율이 급속도로 증가하고 있으며 최근에는 직접 ‘넥서스원’이라는 이름으로 휴대폰 시장에 진출하겠다고 발표하고 올해 판매를 시작할 것이라고 했다.

구글의 다양한 웹 애플리케이션은 모바일 환경에서도 활용이 가능한 애플리케이션이기 때문에 아이폰처럼 화려하고 독창적인 UI는 가지고 있지 않지만 실용적인 면에서 강력함을 보여주고 있다.

마이크로소프트는 이미 ‘life without walls’라는 캠페인을 진행했었고 이를 통해 강한 인상을 심어주었다.

윈도우 모바일의 실적이 부진하긴 하지만 윈도우 모바일 7이 모든 것을 해결해주리라 기대하고 있으며 일부 노출된 사진만으로도 많은 기대를 모으고 있다.

여기에 2010년 6월 출시 예정인 오피스 웹 앱스(Office Web Apps)라는 웹기반 오피스는 모바일 위에서 기존 사용자를 끌어들일 수 있는 강력한 도구가 될 것이다. PC 월드에 소개된 2010년에 대한 예측기사에서도 모바일 오피스가 확산되는 시기를 2010년으로 보고 있다.

구글의 안드로이드폰과 기업시장에서 업무용 스마트폰의 도입 확대를 예상하면서 기업 모바일 환경에서는 편의성도 중요하지만 보안 위험에 대한 대안이 더 중요한 이슈가 될 것이라고 예측하고 있다.

국내 기업에서는 엔터프라이즈 시장에 전문화된 도구들을 출시하면서 기존 RIA 벤더와 차별화된 강점을 가져가고 있다.

투비소프트의 엑스플랫폼은 플래시 플레이어나 실버라이트 런타임과 같은 독자적인 런타임을 제공하면서 Ajax 기반으로 운영을 병행할 수 있어 유연한 플랫폼을 제공하며 이를 기반으로 모바일이나 다른 장비에서도 쉽게 적용할 수 있는 장점을 가지고 있다.

스크린마다 각각 특성이 있기 때문에 모바일에서 제공하는 포토샵에서 데스크톱과 동일한 기능을 요구하기는 힘들다.

때문에 기획 단계에서 차별화된 개념을 준비하고 들어가야지 그렇지 않고 기술적으로 데스크톱의 환경을 그대로 옮길 수 있다고 해서 같은 화면을 담아내는 것이 사용자를 위한 배려가 아니다.

트위터 애플리케이션인 TweetDeck도 데스크톱과 모바일용이 동일한 화면 구성을 가지고 있지만 터치만으로 최적화된 움직임이 가능하게 배려하고 있다.

브라우저보다 데스크톱 - 데스크톱 애플리케이션

뉴욕타임스는 콘텐츠를 쉽게 검색하고 구독할 수 있는 타임스리더 2.0을 어도비 에어 애플리케이션으로 공개했다.

얼마 전부터는 온라인으로 신문 구독을 신청하면 삼성 넷북을 할인해주는 이벤트를 진행하고 있다(타임스리더는 다운로드와 일부 콘텐츠는 무료로 제공되지만 전체 내용은 구독자만 볼 수 있다).

타임스리더의 가장 큰 특징은 인터넷 연결 없이 1주일간의 뉴스를 저장하고 조회할 수 있다는 것이다.

넷북을 마치 이북리더처럼 활용할 수 있도록 한다는 아이디어가 저렴한 비용으로 다양한 콘텐츠를 이용하려는 사용자에게 얼마나 다가갈지는 모르겠다.

기존 웹에서 적용하기 곤란했거나 브라우저의 한계 때문에 불편했던 기능이 다시 데스크톱 환경으로 옮겨오고 있다.

최근 개봉한 제임스 카메룬 감독의 ‘아바타’ 트레일러는 인터랙티브한 형식으로 데스크톱에 설치해서 즐길 수 있도록 제공하고 있다.

트레일러를 즐기기 위해서 별도의 프로그램을 설치해야 하는가에 대한 불만도 없지는 않지만 브라우저보다 좀 더 쾌적한 환경에서 고해상도의 영상을 흥미로운 요소와 함께 즐길 수 있다.

웹 기술을 다루는 사이트인 리드라이트웹에서 선정한 2009년 10대 웹 플랫폼에도 트위터, 페이스북, Azure와 함께 어도비 에어를 점점 완벽해지는 플랫폼으로 묘사했다.

 

사용자 삽입 이미지

그리고 국내 포털사이트뿐 아니라 많은 사이트에서 기존 ActiveX를 이용한 파일 업로드 대신에 멀티플랫폼이 지원되는 플랫폼으로 대체하는 움직임을 보이고 있다.

아직은 파일을 다루는 부분에서 보안적인 제약 때문에 일부만 지원이 가능하지만 로컬의 자원을 이전 C/S 환경처럼 활용할 수 있는 수준에 올라가게 되면 다양한 분야에서 기존 RIA 플랫폼을 활용할 수 있을 것이다.

국내 기업시장에서도 RIA 기반 시스템 구축에 가장 걸림돌이 되는 부분이 세션, 보안 처리, 기존 장치 연계 등의 문제였으며 이러한 요구사항은 지속적으로 반영되어 데스크톱 환경을 점차 변화시켜 나갈 것이다.

올해 상반기에 공개될 예정인 어도비 에어 2는 네이티브 코드와 연동이 기본적이지만 가능하게 되어 좀 더 시스템 자원을 활용한 다양한 아이디어를 만들어낼 수 있게 된다.

실버라이트의 OOB 기능은 이보다 더욱 강력해진다.

어도비가 CS 제품군과 RIA 애플리케이션간의 상호 지원을 강조하고 있다면 마이크로소프트는 오피스 제품군과의 호환을 통해 더욱 강력한 오피스 환경을 구축할 수 있다는 장점을 내세우고 있다.

또한 데스크톱 애플리케이션은 기존 패키지 제품과 같은 성격을 가지고 있어 솔루션 판매 쪽에도 많은 관심을 가지고 있다.

어도비의 경우에는 시부야(SHIBUYA)라는 프로젝트를 통해 개발자나 업체에서 손쉽게 판매와 결제 과정을 지원해주는 작업을 진행하고 있다.

특성화된 부분이나 웹에서 처리하기 힘들었던 일들은 유료 서비스로도 살아남을 수 있는 강점을 가지고 있다.

직관적인 사용자 환경 - 멀티터치

2009년 가장 큰 이슈 중 하나를 꼽으라고 한다면 역시 윈도우 7의 출시가 아닌가 싶다.

단지 마이크로소프트의 제품군 하나가 버전이 올라간 것이 아니라 이를 둘러싼 모든 시장이 한꺼번에 움직이는 굉장한 이벤트를 경험하고 있다.

특히 지원되는 기능 중 멀티터치와 외부 센서와의 연결은 많은 가능성을 보여주고 있는데 때문에 하드웨어 업체뿐 아니라 어도비와 같은 소프트웨어 업체도 멀티터치와 센서 이벤트를 둘러싸고 다양한 제품군에서 신속한 움직임을 보여주고 있다.

닌텐도DS와 같은 게임기를 어린 아이들도 쉽게 다루는 것을 보면 터치 인터페이스가 얼마나 직관적인가를 알 수 있다.

지난해 성남시에서 주최한 ‘경기 기능성 게임 페스티벌’에 소개된 많은 게임들은 터치 기반의 인터페이스를 기본 틀로 하고 있었다.

어린 아이들이 마우스를 다루는 것은 익숙해지기까지 상당한 노력이 필요하지만 터치는 그렇지가 않다.

마우스를 기본으로 애플리케이션을 작성하는 것과 터치 기반의 이벤트는 차이를 가지고 있기 때문에 서로 호환될 수 있는 구조를 만들어가는 것도 중요한 이슈가 될 수 있다.

마우스를 기반으로 하는 이벤트는 사용자의 행동을 모방하려는 노력에 거대한 장애물을 만들어내고 있는 것이다.

하지만 마우스와 키보드에 익숙해진 사람들이 어떻게 터치 기반으로 쉽게 돌아올 수 있을까라는 우려는 요즘 학생들은 키보드 자판을 이용하는 타수보다 문자메시지를 보내는 속도가 더 빠르다고 하니 걱정할 일은 아닌 듯싶다.

아직은 지원되는 하드웨어가 충분치 않아 다양한 환경에 대한 지원이 부족하긴 하다.

자유로운 가치의 만남 - 오픈소스

어도비 플렉스가 성장할 수 있었던 배경 중 하나는 다양한 컴포넌트를 별도의 비용을 지불하지 않아도 사용할 수 있었다는 것이다.

기본적인 비주얼 컴포넌트가 빈약한 것은 아니었지만 국내 사용자를 만족시켜주기에는 부족한 부분이 있었는데 그러한 눈높이를 만족시켜줄 수 있었던 것이 다양한 시각적 효과와 디자인을 갖춘 컴포넌트의 소스 공개로 인해 가능했었다.

물론 상용 컴포넌트가 아니었기 때문에 알 수 없는 버그들이 숨겨져 있었고 이로 인해 개발자를 더욱 힘들게 만들었지만 그런 소스를 기반으로 다양한 시도를 했었고 그만큼 사용자의 요구에 맞는 다양한 경험을 가져갈 수 있었다.

여러 가지 방향으로 컴포넌트 시장을 키우려고 하고 있지만 전문적인 컴포넌트 외에는 쉽게 시장을 만들지 못하고 있다. 애플 아이폰의 성공 요인 중 하나로 앱스토어를 꼽는다면 RIA의 성공 요인 중 하나는 오픈소스와 공개된 커뮤니티 소스라고 할 수 있겠다.

이에 비해 확장이 제한적인 리포팅 도구나 X인터넷 툴의 경우는 영업을 통해 시장은 키워왔지만 커뮤니티 자체적인 활동을 만들어내고 의견과 정보를 공유하는 움직임이 부족했다.

다양한 벤더에서 개발자를 위한 API를 다양하게 만들어내고 지원하는 것은 개발자 생태계를 만들어내는 것이 자사의 제품을 판매하고 운영하는 데 얼마나 큰 도움이 될지를 예측하기 때문이다.

제품설명회를 할 때 영업 담당자에게 자리를 배정했었다면 요즘은 커뮤니티 운영진을 더 대우해주고 있다. 어떤 시각을 가졌던 간에 제품에 대한 쓴 소리도 마다하지 않고 지속적인 피드백을 받을 수 있기 때문이다.

 

사용자 삽입 이미지

시각적인 컴포넌트가 예전에는 플래시 플랫폼을 다른 플랫폼에서 따라가기 힘들었지만 요즘에는 눈으로만 봐서 어떤 기술을 사용했는지 쉽게 분간하지 못할 정도의 고품질 컴포넌트가 많이 소개되고 있다.

얼마 전 소개된 28가지 데이터 시각화 도구에 대한 기사에서는 기본 컴포넌트만 비교해 보았을 때 어도비 플렉스가 가장 초라해 보이기까지 할 정도이다.

초기 RIA 시장은 화려한 컴포넌트에 이끌렸다고 하면 이제는 프레임워크의 안정된 서비스와 협업 프로세스에 주목하게 되었다.

그리고 화려한 UI는 커뮤니티와 개발 업체의 몫이 되었다.

기술문서도 예전처럼 작성되거나 출판된 지식을 소유하는 것이 아니라 자유롭게 번역하고 전파할 수 있도록 오픈하는 경우가 많아지고 있다.

물론 저작권과 관련해서 민감한 자료가 있을 수도 있지만 개발자에게는 좀 더 많은 기회가 주어지고 있는 것이다.

나를 위한 배려 - 웹 표준과 접근성

장차법(장애인 차별금지 및 권리 구제에 관한 법률) 시행으로 웹 접근성에 대한 관심은 높아지고 있으나 아직은 어떻게 대처를 해야 하는지 잘 모르는 실정이다.

RIA 영역에서도 이에 대한 대안으로 접근성 관련 API를 지원하고 관련기관과 RIA 관련 가이드를 만드는 등의 참여를 하고 있다.

하지만 아직 공공 프로젝트에서도 명확한 기준이 제시되지 않고 있으며 RIA 프레임워크를 적용한 영역은 예외로 처리하는 식의 접근을 하고 있다.

애플리케이션 개발 과정에서 일단 시각적으로 보았을 때 문제 없을 만큼의 구현을 목표로 진행하기 때문에 프로그램 상으로는 동작이 어떻게든 가능한 구조로 만들어졌을지 모르지만 스크린리더와 같은 외부 접근성 도구가 해당 내용을 인식할 수 없는 코드가 만들어지기도 한다.

해외의 유명한 RIA 컨설팅 업체에서도 접근성과 관련된 가이드와 대안을 제시하고 있으며 국내 포털 사이트에서도 다양한 형식으로 가이드를 제시하고 있다.

특히 NHN에서는 널리(NULI)라는 이름으로 내부에서 사용하는 웹 표준화 가이드를 공개해놓고 있다.

또한 대부분의 RIA 프레임워크가 브라우저 위에 플러그인 형식으로 구성되다 보니 소프트웨어 자체에 대한 접근성에도 제한이 있을 수 있다.

이에 대한 논의도 지속적으로 진행되고 있다. ‘장애가 있어서 접근하지 못하는 것이 아니라 사용할 수 없어서 장애가 됩니다’라는 소프트웨어 접근성 홈페이지에 표기된 말은 다시 한 번 생각해보게 한다.

올해는 RIA에서 접근성에 대한 고민을 좀 더 가시화해야 할 시기가 될 것이다.

커뮤니티

최근 개발자 커뮤니티에서 바뀐 모습 중 대표적인 것은 트위터이다. 새로운 이슈나 소식을 가장 먼저 들을 수 있었던 곳이 메일링 리스트나 개발자 블로그, 커뮤니티에서 트위터로 우선순위가 넘어가고 있다.

작년 어도비 MAX 행사를 비롯한 대형 이벤트에서도 트위터나 페이스북같은 서비스를 통해 그때그때 필요한 정보를 공유하고 질문과 답변이 즉석에서 이뤄진다.

 예전처럼 발표가 끝나면 줄을 서서 질문을 하려 기다리는 것이 아니라(물론 유명 개발자에게는 여전히 팬들이 몰리긴 한다) 해당 세션을 태그로 질문을 트위터에 남기면 발표자뿐 아니라 세션에 참석했던 모든 참가자가 의견을 공유하게 된다.

기술, 엔터테인먼트, 디자인 등 다양한 주제를 공유하는 행사인 TED의 독립적인 행사로 TEDxSEOUL이 지난해 12월 신촌에서 진행되었는데 유료행사로 별다른 홍보 없이 진행했음에도 불구하고 트위터를 통한 입소문으로 단시간에 접수가 마감되는 현상을 보여줬다.

그리고 현장에서 모바일 단말기를 통해 실시간으로 계속 의견을 주고받았다.

다른 행사에 비해 외국인 참석의 비율도 높아서 행사의 뒷이야기가 트위터 태그를 타고 전 세계적으로 퍼지는 현상도 경험할 수 있었다.

물론 이와 같은 현상이 국내에서는 아직 낯선 풍경이긴 하지만 아이폰을 필두로 스마트폰이 점점 대중 속으로 다가오면서 이러한 커뮤니케이션이 기존 카페나 커뮤니티를 통한 네트워크보다 손쉽게 다가설 수 있게 되고 있다.

유명 개발자들과 쉽게 친구가 될 수 있는 방법이기도 하며 부담 없이 의견을 주고받을 수 있는 통로가 되기도 한다.

 아이폰을 둘러싼 데이터 환경의 변화는 이런 변화를 새로운 방향으로 이끌어내고 있다.

동네 문구점이나 작은 가게에서 인형 뽑기 기계를 볼 수 있다. 내용물은 조금 달라졌으며 다른 형식의 기계들이 늘어나긴 했지만 10년 전과 마찬가지로 자리를 지키고 있는 것은 노란색 금속박스이다.

게임의 특성상 사용자를 배려해서는 안 되는 묘한 위치에 놓여 있지만 잡힐 듯 잡히지 않는 묘한 매력을 가지고 있는 것이다.

간혹 인형 뽑기의 고수들 이야기가 나오는데 대부분 특별한 비법이 있는 것보다는 노력에 의한 결과라고 한다(이러한 생각을 하면서 인형 뽑기의 사용성은 어떻게 개선할 수 있을지 잠시 고민해 보았다).

어떤 일이든 노력 없는 성과는 기대하기 힘들다.

설령 결과를 얻는다 하더라도 다음 단계에 이르기가 힘들다.

한 단계 한 단계 차근차근 밟고 올라가는 것이 앞일을 준비하는 데 자신을 살릴 수 있는 길이다.

올 한해도 멋지게 파이팅하는 개발자가 되어 보자.





     ria, 개발자, 마소, 마이크로소프트웨어, 블로그, 스마트폰, 아이폰, 열이아빠, 월간 마소
     0   

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

 

 

개발 방법론에 생명 불어넣기
+   [마이크로소프트웨어]   |  2009. 11. 23. 08:32  


대체로 그렇기는 하지만 꼭 잘생기거나 예쁜 사람이 이성 친구가 많은 것은 아닙니다.

성실하고 일을 열심히 하는 사람이 꼭 성공하게 되는 것도 아니지요.

이처럼 세상의 이치는 참으로 오묘해서 정답이란 걸 찾기가 여간 어렵지 않습니다.

이번 글은 월간 마이크로소프트웨어에 실린 글인데요.

맹목적인 방법론의 적용이나 배타 대신 보다 제대로 개발 방법론을 활용하는데 도움이 될 듯하여 옮겨봅니다.

좋은 제품과 잘 팔리는 제품은 다르듯, 잘 만들어진 개발방법론과 널리 쓰이는 개발방법론은 반드시 같지 않을 수 있다. 개발방법론이 널리 쓰이지 않는다면, 그리고 상황에 맞게 변화하지 않는다면 과연 가치 있는 것이라 할 수 있을까? 이런 고민은 방법론 무용론으로도 이어질 수 있다. 그러므로 방법론이 쓸모가 없다고 생각된다면 그 방법론을 의심하기 전에 제대로 활용하고 있는 건지를 먼저 의심할 필요가 있다. 이 컬럼은 이런 전제에서 시작한다.

안영회 ahnyounghoe@gmail.com|(주)아이티와이즈 컨설팅 SE 그룹에서 컨설턴트로 일하고 있으며, 국내 대규모 프로젝트에서 다년간 방법론, 모델링, 아키텍처 수립, 프로젝트 관리 등의 다양한 역할을 수행하고 있다. 현재는 보험사 시스템 구축 프로젝트에서 소프트웨어 아키텍트로 일하고 있으며 한국스프링사용자모임(KSUG)의 대표를 맡고 있기도 하다. 본인의 블로그인 Younghoe.info를 통해 현장 경험 나누기를 즐기고 있으니 교류를 원하는 분은 언제라도 환영한다.

여러분이 어떤 조직의 IT 운영팀장이라고 가정해보자. 우리 회사는 이미 오래 전에 선진 사례라고 알려진 RU P(Rational Unified Process)를 받아들였다(http://en.wiki pedia.org/wiki/RUP). 예산을 편성해서 프로젝트를 발주했고, 유명 컨설팅 회사가 우리 회사에 맞도록 RUP를 테일러링(tailoring)했다. 결과물은 우리 회사 표준 개발방법론으로 지정했다. 표준 개발방법론은 시스템 개발 과정에서 필요한 역할, 작업 진행을 위한 프로세스를 설명하고 있다. 또한, 각 작업마다 참조할 수 있는 지침과 표준 양식 그리고 점검표 등을 포함하고 있다. 표준 방법론을 만든 이후에 시행하는 모든 시스템 개발 프로젝트에 적용해 보았지만 반응은 기대 이하다. 성과가 없다 보니 자조적인 평가도 나왔다. UML 표기법을 썼다는 점이나 유스케이스(use case) 단위로 산출물을 다룬 형식적인 측면을 빼면 예전보다 나아진 점이 없다고 불평하는 직원도 있었다. 더구나 UML 표기법이나 유스케이스 개념은 조직 내에서 널리 쓰이고 있지도 않다.

방법론은 표준 산출물 양식집?
필자가 최근 3년에 걸쳐 진행한 프로젝트 중에서 두 번은 방법론 담당자로 일했다. 두 차례 모두 표준 방법론을 갖고 있는 회사였다. 하지만, 흥미롭게도 가능하면 그대로 지키는 일은 피해달라고 했다. 현실과 맞지 않기 때문에 자사 표준이지만 가능하면 유연하게 해석해 달라고 했다. 시간과 노력을 들여 만든 방법론을 지키지 말라니 아이러니한 주문 아닌가? 하지만, 프로젝트 경험이 많은 베테랑이라면 입가에 미소를 머금으며 충분히 수긍할 수 있는 부분이다. 모든 상황에는 원인이 있는 법이다. 방법론을 거추장스러운 절차나 복잡한 문서양식 따위로 취급하는 경우는 왜 발생할까? 우선 방법론을 만든 후에 문자 그대로 고지식하게 적용하려고 했던 아픈 기억(?)탓일 수 있다. 개발방법론 도입 초창기에는 사용자가 방법론을 충분히 이해하지 못한 상태에서 곧이곧대로 따르던 시절이 있었다(필자 경력상 주로 객체지향 분석설계에 바탕을 둔 개발방법론 도입 시기에 국한한다). 시스템 개발과 동시에 팀원 다수가 방법론 훈련을 병행해 상당한 스트레스를 받았다고 할 수 있다.

개발방법론이 숨 쉬게 하기

개발방법론을 답답한 문서 안에서 숨도 못 쉬게 놓아두지 말고 현실과 만나게 하라. 현실과 만나야만 방법론이 숨을 쉰다. 현실은 방법론에 변화를 요구하는 다양한 변수를 갖고 있다. 어떤 변수가 있을까? 참여하는 사람만 놓고 봐도 일하는 방식을 바꿀 소지는 쉽게 찾을 수 있다. 일단 사람이 많아지면 모든 의사 소통을 구두로 할 수는 없다. 더구나 참여 기간이 달라지거나, 물리적으로 떨어진 공간에서 일하는 경우에 똑같이 일할 수 있을까? 또한, 숙련된 개발자와 그렇지 않은 개발자 모두에게 같은 방법을 고수하면 결과는 어떨까? 사람을 기준으로 얼핏 살펴보았지만, 개발하는 기능 개수, 사용하는 기술 플랫폼 종류, 계약이나 납품 절차 등을 하나하나 꺼내보면 변수는 매우 다양하다. 방법론을 프로젝트에 효과적으로 사용하기 위한 방법은 매우 간단하게도 정리할 수 있다. 방법론이 현실을 만나게 하라. 다시 말해, 널리 써라. 그리고 불편한 부분을 그냥 지나치지 말고 지속적으로 개선하라. 번거로운 부분은 과감하게 제거하거나 단순하게 하고, 모호한 부분은 분명하게 해둬라. 이 글의 이후 분량은 두 줄 남짓 정리한 비법을 실천할 수 있도록 경험을 담은 부연이다.

첫 단추는 개발 케이스 만들기

필자가 가장 익숙한 RUP에는 세 개의 케이스(Case)가 있다. 비즈니스 케이스(Business Case), 유스케이스(Use Case) 그리고 개발 케이스(Development Case)다. 비즈니스 케이스는 사업 수행을 다루고, 유스케이스는 시스템 사용 시나리오를 다루지만 모두 “어떻게 하겠다”는 내용을 정형화한다. 개발 케이스도 마찬가지로 어떻게 개발하겠다는 시나리오를 정의한다. 개발에 관한 모든 사항을 처음부터 모두 세세하게 정의하기는 힘들다. 기존에 정의한 방법론 내용이 있다면 큰 노력이 들지 않는 부분만 초기에 수정하고, 문제에 봉착했을 때 해당 부분을 수정한다. 개발 케이스를 어떤 형식으로 얼마나 상세하게 하느냐는 프로젝트마다 달리해야 한다. 하지만 개발 케이스를 집약해서 모두에게 누가 무슨 일을 하는지 알려야 한다. 그래야만 역할이 분명해지고, 필요한 사람을 찾을 수 있다. <그림1>에서 빈칸에 담당자를 명기하면 각 단계별로 산출물 작업 기준이 드러나고, 특정 업무에 따라 산출물 작성자를 한 눈에 볼 수 있다. 이러한 표를 만들어 공유하면 모호했던 역할과 서로 다르게 생각하고 있는 부분이 드러난다. 자연스레 이어지는 협의 과정에서 점차 역할과 책임이 명확해진다. 한 가지 팁이라면 프로젝트 규모가 커서 여러 장의 표를 작성해야 할 정도라면, 프로젝트 관리자는 대표자를 명기한 표만 활용하고, 상세 내용은 각 업무 단위로 관리를 위임한다.


방법론의 핵심은 R&R

예전에 어떤 개발자가 R&R이란 표현이 폼나게 여겨졌는지, 문맥에 관계없이 R&R이란 표현을 남발했다. 옆에서 보면서 드는 생각이 R&R이 폼나는 표현이 아니란 사실을 알기 전까지는 그 의미를 전혀 모르겠구나 싶었다. 그리고 어떤 관리자는 틈만 나면 R&R 따지지 말고 서로 도와가며 일하라고 말했다. 우습게도 그 말에 반박했던 필자 역시 얼마 후 다른 이에게 비슷한 말을 했다. 올해로 8년째 방법론과 직간접적으로 인연을 맺어왔다. 누군가에겐 우습게 들릴 수 있지만, 방법론에 대한 애증이 쌓였다. 요즘 누가 필자에게 방법론이 무어냐고 물으면, ‘방법론은 R&R이다.’라고 말해주고 싶다. R&R은 ‘Role and Responsibility’의 약자다. 우리말로 역할과 책임이다. 역할과 책임을 규정하지 않고 일하는 조직이 어디 있을까? 하지만, 방법론이 효과를 발휘하려면 R&R이 더 명확해야 한다. 마치 오랫동안 잘 돌아가는 프로그램을 만들려면, 함수 시그니처가 명확해야 하고, 컴포넌트 인터페이스 규약이 명확해야 하고, 계층(layer)간 주고받는 항목과 제약사항이 명확해야 하는 것과 같은 이치다. 산출물(deliverable)이라는 명확한 ‘부가가치’의 연쇄구조(chain)를 통해 최종 제품을 만든다. 마치 컨베이어 벨트처럼 방법론을 기계화 수준의 시스템으로 만들면 효율성은 극대화한다. 하지만 아쉽게도 아직 소프트웨어 개발에 있어서는 제조업의 노하우를 그대로 쓸 수는 없다. 개념적으로는 이미 오래 전에 소프트웨어 공장을 논했다. 하지만 산업 경계를 넘어가면 재해석을 해서 새로운 행동 계획(action plan)이 필요하다. 물리적으로는 하나의 산출물이라도 여기에 부여한 부가가치의 생산자는 다르다. 이를 명확하게 해야 효과를 내는 R&R 정립이다. 소프트웨어 설계를 고민하면서 동시에 혹은 번갈아 방법론을 고민하다 보면 무척 닮았음을 알 수 있다. R&R 정립이 가져오는 팀 협업 구도는 loosely-coupled로 불리는 시스템 연동 방식과 원리가 같다.


모호한 부분 구석구석 밝혀내기

규모를 막론하고 개발 프로젝트 초기에는 단계별 산출물을 기준으로 책임자를 명기해두고 합의를 이끄는 과정을 반드시 수행해야 한다. <그림1>의 표는 만들고 나면 매우 명확하지만, 앉은 자리에서 그냥 작성할 수 있는 내용이 아니다. 필자는 주로 외주 계약 기반인 SI 프로젝트에 컨설턴트로 참여하는데, 복잡한 하도급 계약을 고려하면 어떤 역할을 수행하는지 세부 사항은 매번 새로 정의해야한다. 대부분 기존에 해오던 방식을 선호하는 경향이 있어 필연적으로 갈등이 빚어지고, 노련한 개발자가 많으면 서로 자신에게 유리하게 협상하려 해서 설득과 조정 과정이 필요하다. 한편, 여러 업무나 여러 단위 시스템으로 구성된 프로젝트의 경우 역할이 상충하게 마련이다. 주고 받는 데이터가 발생하면 누가 전송을 책임지느냐 여부가 관건이다. 함께 쓰는 기능이 있다면 공통 기능 개발 주체가 초미의 관심사다. 항상 분명한 사실은 오래 끌어봐야 갈등만 커진다는 점이다. 가능한 빨리 문제를 이슈화해서 초반에 정리해야 한다.


프로젝트 초반에 이슈화하기

내포된 위험을 전혀 혹은 거의 모르고 있는 프로젝트 시작 초기에 노련한 프로젝트 관리자라면 마치 상처의 고름을 짜내듯 문제를 미연에 파헤치는 시도가 필요하다. RUP를 보면 프로젝트 관리자는 위험요소 목록(Risk List)을 도입단계(Inception Phase)부터 생성하고 관리한다. 보다 구체적으로는 비전문(Vision)으로부터 바로 위험을 식별하고 확인하라고 한다. 즉, 사업 계획서(Business Case) 작성 과정에서 이미 만들어져야 하는 것이다. 어찌 보면 당연한 이야기다. 프로젝트를 실패로 끌고 갈 수 있는 위험을 조기에 파악해 위험 관리 계획(Risk Management Plan)을 세우라는 것은 문자 그대로 너무나 당연한 말이다. 그러나 문제는 생각처럼 쉽게 그 모습을 드러내지 않는다. 명확해 보이는 문제는 누구나 이를 알고 있기 때문에 설사 프로젝트에 미치는 영향력이 지대하다고 하더라도 덜 위험하다. 오히려 진짜 큰 위험요소들은 쉽게 눈에 띄지 않는 것들이다. 삼국지류의 책에서 대패하는 경우는 뜻하지 않던 습격에 당하는 경우가 많다. 너무나 당연하게 수행되리라고 믿었던 일들이 되지 않을 때, 이를 고칠 수 있을 시점이 훨씬 지나서 문제를 알게 된다면 경우에 따라서는 그간의 산출물이 모두 쓸모 없어진다.

예를 들어 요구사항의 원천인 고객과 분석가가 서로 다르게 인식하고 있다고 해보자. 또한, 고객 입장에서 아직 결정되지 않은 요소가 너무 많아서 분석가에게 충분한 흐름을 제시할 수 없다. 언제 결정될지 모르는 사항을 무작정 기다리는 대신에 분석가가 나름의 시나리오를 기술해 고객에게 의견을 제시했다. 이때, 고객이 요구사항 기술 방식이 생소해 가령, 기본 흐름과 대안 흐름으로 시나리오를 기술하는 유스케이스 명세가 익숙지 않아서 내용 파악을 어려워한다거나 검토를 꺼린다. 고객은 요구사항 정의 내역을 검토해야 하는 것을 알지만 위와 같은 문제로 검토를 차일피일 미루고 또한 본연의 업무가 있기 때문에 요구사항에 대한 검증이 이뤄지지 않은 채 시간은 계속 흘러간다. 이보다 더 심한 문제는 고객이 마치 검토를 충분히 한 것처럼 인지될 때이다. 사실 이런 문제는 모든 프로젝트가 갖고 있는 가장 큰 위험요소 중에 하나이다. 다만, 이렇게 명백해 보이는 문제마저 실제 프로젝트에서는 다양한 양상으로 벌어지기 때문에 이를 잡아내서 의사소통 경로나 방식의 문제를 해결하기 쉽지는 않다. 적어도 필자가 경험한 모든 프로젝트에서 가장 큰 문제는 의사소통 경로나 방식에서 나왔다. 프로젝트 초기에 의사소통을 원활히 할 수 있는 환경을 만들어내는 일은 무척 중요하다. 그렇게 하기 위해서 프로젝트에 영향력이 큰 인물을 찾아내고 그 힘을 적절히 활용하라. 주요 실무자를 확실한 우군(?)으로 만드는 일과 정보가 물 흐르듯 소통할 수 있게 하는 일은 너무나 중요하다. 예전에 PM만 8년 하셨다는 분이 프로젝트 관리는 한 마디로 ‘정치’라고 단언했던 말이 떠오른다.


실행 능력 키우기 

단조로움을 피하기 위해 잠시 다른 이야기를 해보겠다. 한일월드컵 4강 신화를 이뤄낸 거스 히딩크 등장 이전에 국가대표는 4(four)백을 잘 쓰지 않았다. 4백이란 수비수 네 명이 일렬로 서서 수비 라인을 구축하는 전형을 말한다. 4백 대신 중앙 수비수 세 명을 두는 3(three)백 시스템을 썼다. 당시 선진 축구 흐름은 전원공격과 전원수비를 함께 하는 이른바 ‘토탈사커’였다. 토탈사커를 구사할 때 4백을 구성하는 측면 수비수 2명은 특히 중요한 역할을 했다. 기본적인 위치는 좌우 측면 수비이지만, 공격할 때는 공을 갖고 상대편 깊숙이 침투해 크로스를 올리는 역할을 맡았다. 따라서, 공수 양면에서 탁월한 능력과 함께 기동력, 그리고 강한 체력을 요구했다. 동시에 중앙 수비수는 역습 상황에서 둘이서 최후방을 책임져야 하기 때문에 강력한 대인 마크 능력을 요구했다. 당시 우리나라는 홍명보와 짝을 이룰 중앙 수비수 재목이 약했고, 측면 침투와 수비를 책임질 측면 수비수 재목이 없었다. 히딩크는 어떻게 4백을 도입할 수 있었을까? 히딩크 역시 처음부터 4백을 고집하지 않았다. 월드컵 본선 직전까지 3백과 4백을 함께 사용하다가 끝내 본선에서 주요 경기에 4백을 사용했다. 이를 가능하게 한 힘은 극한에 이르는 체력훈련이다. 히딩크가 수행한 체력훈련을 빼고 4백(4-3-3) 도입을 논하는 일은 무의미하다.

필자가 히딩크의 접근방식을 꺼내놓은 이유는 방법론 적용에 대해서도 마찬가지의 노력이 필요하기 때문이다.

실행 능력을 키우는 코치
지난 해 바쁜 시간을 쪼개서 ‘소트웍스 앤솔러지: 소프트웨어 기술과 혁신에 관한 에세이’ 번역에 참여했다. 번역 작업은 처음이었지만, 7장 ‘반복 관리자’ 내용이 무척 실무적인 터라 번역 요청에 응했다. 때마침 프로젝트 관리를 하고 있었고, 소수의 팀원에 비해 개발 물량이 무척 많아 애자일 방법론을 채택한 상황이기도 했다. 책 내용 일부를 소개하면, 반복 관리자가 팀이 일정을 지키게 하기 위해 다음과 같은 질문을 하라고 한다.

- 개발자가 자신이 맡은 스토리 범위를 이해하고 있는가?
- 애초 예측 이후 스토리 작업에 변경이 있었는가? 그렇다면, 어떻게 변했는가?
- 개발자가 해당 스토리가 목표로 하는 상태에 대해 더 잘 이해하기 위해 업무 분석가나 고객 도움이 필요한가?
- 개발자에게 선임 개발자 도움이 필요한가?
- 개발자의 스토리 완수에 장애가 있는가? 가령 하드웨어, 소프트웨어 또는 기반구조 문제가 있는가?
- 개발자가 다른 프로젝트에도 참여하고 있거나 스토리 완수를 위해 지나치게 많은 잡다한 회의까지 참석하고 있지 않는가?

필자는 번역을 수행할 당시, 스스로 뽑은 최고의 팀원으로 프로젝트 관리를 수행하고 있었다. 하지만, 기대만큼 좋은 결과를 내지 못했다. 얼마간의 시행착오를 겪은 이후에 필자는 팀원의 작업 내용에 직접 개입하기보다는 위 질문과 같은 내용으로 도움을 주려고 노력했다. 스스로 해결할 수 없는 문제는 빨리 도움을 요청하도록 유도했고, 회의는 주로 관리자인 내가 전담하면서 검토를 수행할 경우에 한해서 개발 담당자를 참여시켰다. 또 가장 중요한 점은 스스로 자신의 작업 계획을 수립하게 한 것이다. 약 4개월 동안은 주마다 계획을 하고, 매일 아침 진척을 보고하게 했다. 주단위로 보면 늘 조금은 지연(기능을 완료한 경우에도 주석이나 도움말이 빠졌거나 단위 테스트가 없었다)이 있었고, 매일 아침 물어봐야 며칠 동안 같은 작업을 진행 중이라고 답했다. 속으로 답답했지만, 인내심을 가지고 기다렸다. 매번 반복해서 가능한 일을 잘게 나누어 보고하라고만 요청했다. 놀랍게도 4개월 이후부터는 하루 단위 작업 추정이 가능했다. 주 단위로는 거의 모든 팀원이 자신의 말을 지켰다. 처음에는 상상도 못할 작업 측정과 관리가 가능했다.

거스 히딩크가 했던 일도 이와 비슷한 일종의 코치가 아니었을까? 반복 관리자는 애자일 코치(agile coach)라고 부르기도 한다. 갑자기 방법론 이야기하다 말고 왜 애자일 코치 이야기를 꺼냈을까? 앞서 이야기했지만, 기초체력훈련 없이 4백은 불가능하다. 최소한의 체력이나 개인기가 없는데 마법 같은 부분전술이나 훌륭한 전략을 소화할 수는 없다. 마찬가지로 효과적인 방법론 적용을 위해 팀원의 기본 역량 강화는 필수다(아쉽게도 프로젝트 동안만 만나는 팀원이라면 ROI는 장담할 수 없겠다).

팀워크 빌딩

축구팀이나 개발팀이나 팀워크는 중요하다. 축구는 11명이 하지만, 개발팀 구성원 숫자는 이보다 많을 수 있다. 특히, 방법론을 도입하는 프로젝트는 수 십, 수 백명인 경우가 많다. 숫자가 늘면 팀워크를 갖추기는 더욱 어렵다. 더구나 서로 다른 회사에 속한 팀원을 모아놓았을 때 이들을 진정한 팀으로 만드는 일은 과연 가능할까 싶을 정도로 힘들다. 대규모 프로젝트에서는 팀워크를 위해 워크샵을 가기도 하고 몇 차례 회식을 한다. 얼마나 효과가 있을지는 의문이다. 함께 일하는 빈도가 높은 팀원 사이에서라면 필자가 했던 다음과 같은 시도를 한번쯤 권해보고 싶다. 필자는 함께 일하는 팀원을 불러다 놓고 자신과 관계된 담당자와 산출물을 표기한 후 관계를 그려보라고 했다. 훈련된 팀이어서 산출물을 빠뜨리는 경우는 없었지만, 다른 사람과의 관계는 팀원 대부분이 빠뜨리고 그렸다. 놀라운 점은 서로가 그린 그림을 공유하는 정도만으로도 팀워크 개선이 있었다는 점이다. 보지 못하던 부분이 드러난 이후에는 굳이 계속해서 지적하지 않아도 새로 인지한 부분을 고려해서 작업했다.
획일화의 함정에 빠지지 말라

지금까지는 사람에 초점을 맞췄는데 세부적으로 들어가면 방법론은 각종 산출물 작성법을 포함한다. 종종 방법론과 표준 양식을 대등하게 생각하는 사람도 있다. 올바른 판단은 아니지만, 그만큼 표준 양식은 모두가 명확히 인지하고 필요로 한다. 문서 작성 방식이 명확하다면 작성도 편하지만, 읽기에도 좋다. 그러나, 프로젝트가 커지면 지나치게 관리 편의성을 내세우기도 한다. 지나치게 일관성을 강조하면 획일화의 함정에 빠질 수 있다. 대규모 프로젝트에서 프로그램 식별자(ID)는 여러 가지 용도로 쓰인다. 사업 관리 측면에서 진척 관리 기준으로 쓰이기도 하고, 설계자, 개발자 및 테스트 담당자가 작업 항목을 식별하고 서로 추적할 용도로 쓰기도 한다. 수많은 프로그램 가운데서 일관성을 부여하기 위해 대개는 다양한 약어와 일련번호를 조합한 이름을 지정한다. 그러나, 프로그램 내부의 변수에까지 모두 동일한 체계를 부여해 프로그램을 암호처럼 만드는 경우를 종종 목격할 수 있다. 산출물 특성을 무시하고 모두 똑같이 처리하려고 시도한 탓이다. 엑셀 문서에서 특정 프로그램을 지칭하기 위해 ‘IF-CMD-001’과 같은 식별자를 쓰는 일은 긴 이름에 비해 효율적일 수 있다. 하지만 프로그램 이름을 ‘IF-CMD-001.java’ 혹은 ‘IF-CMD-001.jsp’ 라고 만드는 일은 과연 적절할까(물론, 암호와 같은 작명 체계를 고객의 기존 시스템에서 오랫동안 사용했다면, 이미 의미 있는 관행이기 때문에 준수해야 할 수도 있다)? 비슷한 획일화 함정의 예로 ‘유스케이스 크기 기준’을 들 수 있다.


유스케이스 크기 기준

유스케이스 크기에 대한 이슈(http://cavin.egloos.com/4869054)는 억지로 유스케이스를 콘트롤(control)이나 설계요소와 일정규칙으로 연관 지으려는 경향에서 발생한다. 이는 유스케이스를 소프트웨어 설계원리로 오인하면서 발생하는 대표적인 오해이다. 유스케이스 모델링 책에서 동일한 크기를 강조한 데에서 비롯된 잘못된 양상이라 할 수 있다. 실제로 일정한 크기를 갖고 한 사람이 모델링하는 것을 베스트로 추천하곤 한다. 유스케이스는 전달자와 수집자간에 요구사항에 대한 본인들의 관심사를 담아 다른 사람과 소통하기 위한 ‘스케치’다. 비즈니스 특성이 다르고 각각의 관심사가 다르기 때문에 일정 크기로 수렴하는 것은 전혀 의미가 없다. 일정한 크기로 강제하다 보니 유스케이스가 1,000개 단위로 나오는 어이없는 사태가 발생하기도 한다. 요구사항이 조밀한 수준에서 높은 가치를 갖는 비즈니스가 있고 반대로 큰 수준에서 가치를 갖는 비즈니스도 있다. 전자와 같은 비즈니스에 대해 유스케이스 크기 기준을 들이미는 것은 입도가 조밀한 수준의 관심사를 더 큰 크기로 나타내고 소통하라는 얘기가 된다. 원자에 대한 커뮤니케이션이 필요한데 분자크기로 요건을 작성하라는 얘기이다. 말도 안 된다. 비즈니스 특성도, 개개인의 관심사도 다르니 크기에 대한 ‘정답’도 없는 것이 당연하다. <중략> 유스케이스는 커뮤니케이션 도구다. 고객과 협업하는 사람들, 그리고 자신을 포함한 모두의 커뮤니케이션이 가장 큰 목적이다.


프로세스 최적화와 도구의 적용
산출물 형식뿐 아니라 용도와 상황에 부합하게 산출물 작성 프로세스를 최적화한다. 산출물 작성 프로세스의 경우에도 <그림 4와> 같이 시각화해 공유해야 한다. 누가 무엇을 하고, 이어지는 작업은 무엇인지, 관련자나 관련 시스템은 무엇인지 명확하게 해서 혼선을 없애야 한다.

프로세스가 복잡해지면, 단순화를 위해 시스템 도입을 고려해야 한다. 최근에 다양한 협업 도구가 오픈소스로 개발하고 쓰여지고 있다. 필자가 수행하는 최근 프로젝트에서는 사용하는 형상관리 도구(Subversion, Subversive), 작업관리 도구(Redmine, Eclipse Mylyn), 결함관리 도구(Redmine), 빌드 및 테스트 자동화 도구(Ant, Hudson) 등은 모두 무료로 사용할 수 있는 오픈소스 도구이다.

의사소통을 문서로만 관리할 때보다 도구를 도입하면 효율적이지만, 소수 관리자의 관리 편의성이나 도구에 대한 거부감으로 문서를 고집하는 경우도 있다. 명심하라. 개발 프로젝트에서 최종 산출물은 소스 코드다. 그 이전에 만들어지는 수많은 문서는 결국 중간 결과를 담는 그릇이다. 의사결정 사항을 알려 오류를 찾아내고, 누락시킨 요구사항을 다시 수렴하고, 다음 단계로 진화하고, 필요하다면 변경을 수행하기 위한 정보 전달에 사용한다. 목적에 부합하는 수단과 방법을 쓰고 있는지 항상 고민해야 한다.

생생하게 유지하기
얼마 전 모회사에서 꽤 잘 만든 조직 표준 체계를 열람했다. 2년 전에 만든 것인데, 내용이 그대로였다. 만들기는 잘했지만, 널리 쓰이지는 않았구나 짐작했다. 널리 쓰이지 않는다면, 그리고 상황에 맞게 옷을 갈아입지 않는다면 가치가 있을까? 방법론 무용론도 같은 맥락이 아닐까? 아무리 욕을 해도 마구잡이 개발보다 나쁜 방법론은 없다. 방법론이 쓸모가 없다고 생각한다면 자신이 제대로 활용하고 있는가 돌아보자.





     개발 방법론, 개발자, 마소, 마이크로소프트웨어, 블로그, 안영회, 월간 마소, 히딩크
     0   
BlogIcon 소리바람 2009.11.23 11:53 신고
IT개발에 지대한 영향을 끼친 것은 건축공학이라는고 알고 있습니다. 그 영향으로 용어가 그대로 차용되고 있지요. 그러나, 용어가 같다고 그것을 받아들이는 사람에게 IT의 개발이라는 것이 건축과 같이 단계단계 바로 눈으로 확인이 되는 것이 아니라는 것이 IT개발방법론이 무수히 변형/생성되는 원인이라고 봅니다.(건축공학에서도 새로운 시도를 많이 하고 있지만.)
결론적으로 말씀을 드리면, IT개발뿐만 아니지만 개발 그 자체가 중심이 아닌 그것을 주도하고 사용하는 사람이 중심이라는 겁니다. 그 많은 방법론의 목적은 원하는 결과물이 잘 나오느가에 따라 생명 연장를 받는다고 봅니다.

저의 경험으로,
1. 갑과 을의 입장을 없애라. 다만, 공동의 목표를 향한 파트너만 있을 뿐이다.
2. 정치가 아닌, 정직히 확실히 커뮤니케이션을 원활히 하라.
3. 에러 발생과 원인도 공유할 수 있도록 시스템을 도입하라.
4. 마일스톤을 지켜라. 그리고 요구사항 추가나 변경이 필요하면 기간연장과 비용발생에 대해서 확실히 정하라.
5. 초기에 위의 사항들을 반영한 개발계획서과 계약서를 작성하라.
BlogIcon 소리바람 2009.11.23 12:02 신고
위에 조금은 이상적인 내용을 적었지만, 사람 사는 세상아니겠습니까. 아깐의 의사소통이 있어도 영향을 받을 수 밖에 없지요.

커뮤니케이션을 잘하는 것도 PM만의 몫이 아닌, 개발자들도 잘 해야 한다고 봅니다.
특히, SI쪽은 새로운 기술의 시도보다는 기존의 안전하고 검증된 시스템을 구성하는 것이 프로젝트의 목표가 되는 것이 많았다고 봅니다. 그리고, 기존 애플리케이션 개발자들이 SI에 적응 못하는 경우도 많이 보아왔습니다.(나름 기술에 집착 아니 아집에 가까운 장인정신?)
그런 문제에 대해서 PM이 잘 조절하고 개발자의 재능도 함께 키워나가는 것이 필요하다고 봅니다.
(PM은 발바닥에 무좀도 생기지 않을 정도로 열심히 뛰어다녀야 한다는...것이 되겠지요.)
BlogIcon 소리바람 2009.11.23 12:19 신고
참고로,
저의 경우는 소스명은 개발자들을 위한 코딩규약을 정해서 임의의 숫자 조함이 아닌, 개발자 전체가 이해할 수 있는 이름으로 정합니다. 물론, 들여쓰기, 주석양식, doxygen를 위한 주석, 클래스명명 등등.
위에 'IF-CMD-001.java'는 지양해야 할 명명이라고 생각이 듭니다. 담당 개발자가 봐서 바로 알 수 없는 것은 관리 이외에 의미가 없다고 봅니다.(ex. CCmdServerToClent.java 서버에서 클라이언트으로 명령어를 보내는 클래스: 알기 쉽지요. 길어도 바로 알 수 있는 이름이 좋습니다.)

이와 반대로 개발문서는 화일명을 중앙집중 관리를 하는 편이 좋다고 봅니다.
예로, 하나의 엑세스 화일에서 열람해서 접근 가능하도록 구성하거나, 웹페이지에서 바로 볼 수 있도록 한다든지.
고객뿐만 아니라 개발자들도 바로 사양을 확인할 수 있는 시스템의 도입이 반드시 필요로 합니다. 그리고, 변경/수정된 내용을 메일등으로 알려 주어서 사양반영에 누락이 없도록 해야 합니다. 또한 책임소재를 분명이 할 수 있는 문서마다 로그 페이지를 넣는 것도 빠질 수 없지요.

이 모든 것이 의사소통의 원할함을 위한 것임을 언제나 상기해야 성공적인 프로젝트가 되겠지요.

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

 

 

2009년 돌파를 위한 개발자 필수 2종 세트
+   [마이크로소프트웨어]   |  2009. 1. 8. 13:37  


경고 | 이 포스트는 지극히 광고 성향이 강하니 노약자와 심신이 약하신 분들은 정신 건강을 위해 더 이상 읽지 않으시길 권합니다.

2009년도 어느덧 일주일이나 훌쩍 지나보낸 지금!!!

연초에 세웠던 계획은 작심삼일의 먹이로 던져줘 버리진 않으셨는지요!


많은 사람들이 2009년은 IT의 빙하기가 될 거라고들 말합니다.


이 어려운 시기를 돌파할 수 있는 방법은 뭐가 있을까요?

당신이 개발자라면...

이 고민은 더더욱 커질 수밖에 없습니다.

며칠 전 만난 한 광고 대행사의 이사님은 이제 IT 광고는 취급하질 않는답니다.

광고를 하는 회사들도 많이 줄어든 건 기본이고 광고를 하더라도 돈을 받을 수 있을거란 확신이 서지 않기 때문이라고합니다.

그만큼 다른 분야보다 IT쪽 경기가 더욱 나쁘다고 이해할 수 있겠습니다.


그럼 우린 이 어려운 시기를 어떻게 극복해야 할까요?

이럴 때일수록 경쟁력을 높이는 게 중요할 것입니다.

그래서!!! 준비했습니다.

이크로프트웨어와 음의리를 한 번에 Get 할 수 있는 이벤트!!!

마이크로소프트웨어로 개발의 내공도 팍팍 쌓고

마음의 소리로 마음의 휴식도 얻어보세요!!!

>>>이벤트 자세히 보러 가기<<<








     개발노하우, 개발자, 마소, 마음의소리, 마이크로소프트웨어, 월간 마소, 정기구독이벤트
     1   
BlogIcon 열이아빠 2009.01.08 15:20 신고
역시 이런 이벤트를 기다려왔어요. 마소 짱...ㅎㅎ
BlogIcon 호랭이 2009.01.08 16:44 
ㅎ.ㅎ 정기구독 신청 결정?!?!?
BlogIcon 철산초속 2009.01.08 16:13 신고
마음의소리 원츄..ㅋㅋ
BlogIcon 호랭이 2009.01.08 16:45 
철산초속님이 정기구독하면 두 권 보내 드리는 걸로 결정?
ooti 2009.01.08 23:18
제 옆 여사님 왈 : 그래도 내 여자에겐 따뜻하겠지.
BlogIcon 호랭이 2009.01.09 07:45 
우하하하하하하하하하하핳 왜케 우껴!!! 깰꾸닥ㅋ
BlogIcon Jelly君 2009.02.02 15:10 신고
재밌겠담

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

 

 

2009년에 임하는 당신의 사자성어는?
+   [마이크로소프트웨어]   |  2009. 1. 3. 13:42  




한 취업 포털이 2008년 한 해를 축약하는 사자성어에 대해 설문조사를 했다고 합니다.


그 결과 1위는 24%가 선택한 은인자중(隱忍自重). 


마음속의 괴로움을 참고 견디며 몸가짐을 조심한다는 뜻입니다. 요즘 우리 내 상황을 아주 잘 표현한 말인 듯합니다.


2위는 18.6%가 선택한 새옹지마(塞翁之馬), 3위와 4위는 각각 동상이몽(同床異夢)과 좌불안석(坐不安席) 그 이후의 순위들도 대부분 부정적인 사자성어들뿐입니다.


상상해 본적도 없는 거대한 어려움이 현실로 나타나고 있고, 또 그보다 훨씬 더 큰 역경이 예견되고 있으니 어쩌면 당연한 일인지도 모르겠습니다.


다행스러운 일은 새해의 소망이나 결심을 묻는 질문에 대한 답변들입니다. 27%가 선택한 1위는 만사형통(萬事亨通), 2위와 3위는 일취월장(日就月將)과 수불석권(手不釋卷) 등으로 대부분 희망적인 것들입니다.


얼마 전 한 TV 프로그램에서 외국인이 한국인들에 대해 얘기하는 걸 듣게 되었습니다. 


한국에서 십 수 년을 살았다는 그는 “내가 한국에 살면서 한국인들이 경기가 좋다고 얘기하는 걸 들어 본 적이 없습니다. 


늘 한 결 같이 힘들다고 말하지만(또 실제로 힘겨운 상황들이지만) 신기하게도 시간이 지날수록 한국은 발전하고 있습니다. 한국인에게는 역경을 이겨내는 특별한 유전자가 있는 것처럼 느껴질 정도입니다”라고 말했습니다. 


그 말을 듣고 보니 정말 그랬습니다. 우리는 이 어려운 상황을 이겨낼 수 있을 거란 희망이야말로 어떤 어려움도 극복해내는 원동력이 아닐까 생각해 봅니다.

꼭 1년 전인 2008년 마소 1월호 데스크칼럼의 제목은 ‘해봤어?’였습니다. 편집장이 되고 처음 쓰는 데스크칼럼이었습니다. 힘차게 떠오른 2008년의 태양처럼 우리도 뜨겁게 도전하는 한 해를 만들어 보자는 내용이었습니다. 


이제 다시 묻겠습니다. 지난 한 해 해보셨습니까? 


저는 나름대로의 계획을 가지고 여러 가지 시도를 해봤습니다. 물론, 성과를 내지 못한 일들도 많습니다.


하지만 중요한 건 시도와 경험을 얻어 냈느냐에 있다는 생각이 듭니다. 


지난해의 경험은 새해의 밑거름이 될 것이기 때문입니다.


그래서 제 2009년의 결심을 나타내는 네 글자를 무한도전(無限挑戰)으로 정했습니다. 


여러 가지 외부적인 상황들 때문이기도 하지만, 더 큰 이유는 편집장이 되고나서 미처 그 자리에 적응하기도 전인 1년 만에 마소의 대표이사가 돼버린 탓입니다.

마소 25년의 전통과 대한민국 개발자들의 기대, 대한민국 SW 산업의 미래가 어깨에 얹어졌다고 생각하니 다리가 절로 풀립니다. 


전통매체의 입지는 점점 좁아져만 간다고들 말합니다.


하지만, 전문가들의 전망이나 예상이란 건 언제나 맞아 떨어지지는 않습니다. 


2008년 1월의 경제 전망 기사들을 찾아봤습니다. 


경제성장률 5.8%를 전망했지만 결과는 맞지 않았습니다. 


처음 서태지와 아이들의 춤과 노래를 본 음악 전문가들은 그들에게 최하 점수를 주며 성공하지 못할 거라고 단언했습니다.


다른 전망들도 맞지 않는 경우가 부지기수입니다. 


맞서보기도 전에 맞을지 맞지 않을지도 모를 전망에 발목이 잡힐 수는 없는 노릇입니다.


2009년은 마소나 대한민국 개발자들에게 다양한 기회의 시간이 될 듯합니다. 


그래서 저는 올 한해 무한도전이란 네 글자를 가슴에 달고 뛰어보려고 합니다.


당신의 가슴에 새길 네 글자는 무엇인가요? 


부디 그 네 글자에는 희망이 가득 담겨 있기를 바라겠습니다. 


그리고 또다시 1년이 지난 후에 그 글자들이 눈부시게 빛나고 있기를 바라겠습니다.


무에서 유를 창조하는 개발자들, 그들과 함께하는 마소이기에 우리는 어떤 어려움도 극복해 낼 수 있는 저력이 있을 거라고 믿습니다.


대한민국 IT 파이팅!!!







     2009, 개발자, 경제 전망, 마소, 마이크로소프트웨어, 새해, 월간 마소, 은인자중, 전망, 호랭이
     0   
BlogIcon 학주니 2009.01.03 15:45 신고
과연 올해 IT 시장의 전망은?
좀 우울할 수도 있겠구나 하는 생각이 먼저.. -.-;
BlogIcon 호랭이 2009.01.05 16:31 
ㅎ.ㅎ 학주니 님 답지 않게 왠 엄살임미꽈!
학주니 파이팅!!!
대한민국 IT도 파파파파파이팅!!!
BlogIcon 오랜친구 2009.01.04 21:32
음... 굳이 하나 찍으라시면 저는... '일박이일'... -.-;;

하루나 이틀에 끝낼 일이면 그 시간 안에 해치우기랄까요, 미루지 말자. 흐흐흐.
BlogIcon 호랭이 2009.01.05 16:29 
오~ 1박2일 좋은데요!!!
나도 하나 추가!!!
BlogIcon 정주Go 2009.01.05 07:56
으음 저는 뭘루 할까염?

일단 '마소구독'하겠습니다.ㅎ
BlogIcon 호랭이 2009.01.05 16:30 
좋아~좋아!!!
역시 정주Go님!!! ㅎㅎ
BlogIcon 트렌드온 2009.01.26 22:27
무한도전.

좋아~~~ 가는 거야..... 윤도현 노래가 생각나는데요. ^^

은인자중 너무 가슴팍에 사무치는 말입니다.
BlogIcon 호랭이 2009.01.28 08:04 
파이팅!!!

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

 

 

마소의 생일은 1년에 두 번!!
+   [마이크로소프트웨어]   |  2008. 12. 23. 11:08  



마이크로소프트웨어의 생일은 1년에 두 번입니다.

마소 창간일인 1983년 11월 1일이 첫 번째 생일이고요.

마소를 발간하고 있는 (주)마소인터렉티브의 창립 기념일인 12월 22이 두 번째 생일입니다.

마소는 25년간 발행되어 오고 있지만 그사이 회사가 네 번 바뀌었습니다.

1983년 정보시대에서 출간된 마소는

17년 뒤인 2000년 1월부터는 소프트뱅크에서 출간하게 됩니다.

다시 3년 뒤인 2003년에 CNET으로 보금자리를 옮긴 마소는

채 2년을 버티지 못하고 다시 분사...

2004년 12월 22일에 지금 회사인 마소인터렉티브로 옮기게 됩니다.

그러고 보면 마소도 참 많은 고난과 역경을 딛고 일어선 잡지라고 할 수 있겠습니다.

25년이란 세월 동안 어려움이 없었다면 그게 더 이상한 일이겠지요.

특히 CNET에서 분사할 때에는 마소의 매출이 굉장히 떨어져서 힘겹던 시기였던 모양입니다.

당시에 직원으로 있지는 않았지만 인터넷에 당시의 절박한 상황에 대한 설명과 정기구독으로 마소를 살리자는 움직임들도 여전히 남아 있으니 말입니다.

그 후 개발자들의 성원과 마소의 눈물나는 다이어트 덕분에 안정을 찾게 됩니다.

그리고 호랭이가 마소에 혜성처럼 등장 =_=;

뭐 아무튼 그렇습니다.

그래서!!!

어제가 바로 마소의 생일이었단 말쑴!!!

축하와 격려의 메시지 하나 날려주시는 쎈쑤를 발휘해 주시면 좋으련만...

이건 어제 아침 직원들끼리 조촐하게 생일 파뤼할 때 찍은 케익 사진!!!

이건...

덜덜덜

우리 회사 막내 직원이 독창으로 생일 축하 노래를 부르는 장면입니다...

동영상도 있지만 여러분의 정신 건강을 위해 생략!!!


마소 파이팅!!!




     Cnet, 개발자, 마소, 마소 생일, 마소인터렉티브, 마이크로소프트웨어, 생일, 생일파티, 소프트뱅크, 월간 마소, 정보시대
     1   
BlogIcon 호야지기 2008.12.23 08:21
마소의 역사는 외우기도 힘들군요ㄷㄷㄷ

생일 축하해요ㅋㅋ
BlogIcon 마소호랭이 2008.12.23 08:27 신고 
^-^; 뭐 외우실 필요 까지야...
감사합니다.
내년 생일에는 개발자와 도움주신 분들 초대해서 파티를 하고 싶네요!!! 돈 좀 벌어서요. ㅎㅎ
BlogIcon 하이컨셉 2008.12.23 08:47
어려운 시기에도 꿋꿋하게 잘 버티시고 있네요. 저는 마소 창간호부터 독자이자 글도 많이 썼던 사람이라 애정이 많아요. 과거 홍동선 편집장 시절부터, 위윤희 기자가 기억에 남는데 잠깐 마소 기자 이름을 보니까 이제는 아는 사람이 없는 것 같아요 ^^; 온라인 부분을 강화하면서 나름 잘 포지셔닝 했으면 좋겠어요 ...
BlogIcon 호랭이 2008.12.23 09:32 
네 말씀하신 것처럼 2009년에는 온라인 쪽을 많이 강화해 볼 예정입니다. 앞으로도 많은 관심과 조언 부탁드리겠습니다. 감사합니다.
REN 2008.12.23 09:25
와~~ 마소의 생일을 늦었지만 축하합니다!!
BlogIcon 호랭이 2008.12.23 09:33 
오늘 미친년말송년회 잘 다녀 오시구요... 미투데이는 꼭 마소 마감때 모임하더라... ㅠ_ㅠ 만박 형이 절 미워하나봐요!!!
BlogIcon archmond 2008.12.23 13:20 신고
happy birthday to 마소~
BlogIcon 호랭이 2008.12.23 15:48 
감사합니다. ㅎㅎ
BlogIcon kkamagui 2008.12.23 13:47
와우~ 마소 파이팅입니다. ;)
2009년에도 멋진 잡지가 되기를 기원합니다. ^^
BlogIcon 호랭이 2008.12.23 15:48 
많은 분들이 도와주고 계시니 2009년에는 더 좋은 모습 보여드릴 수 있을 듯합니다. 감사합니다.
BlogIcon 미노 2008.12.23 17:01
추카추카.. 마소의 생일이라..
정말 예전에는 책장한켠에 가지런히 놓여 있는 마소만 봐도 배가 불렀었는데..

추카하고, 한살한살 더 먹을 수록 더 발전하는 마소가 되길...
호랭이 2008.12.24 01:21 
미노 형 오랜만이삼... 메뤼크리스마스~
BlogIcon 학주니 2008.12.24 11:33 신고
생일 축하해요 ^^;
BlogIcon 마소호랭이 2008.12.28 16:20 신고 
감사합니다. 새 회사에서도 파이팅!!!
BlogIcon StudioEgo 2008.12.31 13:36 신고
생일 축하합니다 :)

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

 

 

그대 내게 행복을 주는 사람~
+   [호랭이 사는 이야기]   |  2008. 12. 6. 11:21  




호랭이는 오늘 다들 어려울 거라고 입을 모으는 2009년을 돌파할 사업계획을 구상하느라

추운 바람을 뚫고 출근을 했습니다.

남들 다(?) 하는 주말 출근에 혼자 유난떤다 하실지 모르지만

날씨 탓인지 이상하게 요즘은 쓸쓸함이 많이 느껴집니다. ^-^;

그런데 사무실에 도착해 보니 책상에 소포 하나가 와 있지 뭡니까?


'어 주문한 게 없는데... 뭐지?'하며 주소를 잘 읽어보니 보내는 사람과 받는 사람이 모두 호랭이인 겁니다. =_=;

다행히 배송 메모에 보내신 분 성함이 써 있더라구요.

보내 주신 분은 떡이떡이 서명덕 기자님...

이 이름을 보는 순간 두 가지 생각이 먼저 떠올랐습니다.

늘 도움만 받으면서 선물까지 받게 되다니 죄송하다는 생각이고

또 하나는 아 요즘 괜히 오버하느라 호랭이 혼자 외로움 타는 척 힘든 척 하고 사는 게 아닌가 하는 거였습니다.

서기자님과 몇몇 훌륭하신 분들이 제 곁에 있음을

호랭이를 응원해 주시는 분들이 있음을 잠시 있고 지낸게 아닌가 하는 생각이 들고나니 다시 힘이 불끈 솟았습니다.

네... 호랭이 기운이 솟아났습니다. ^-^;;;


상자 안에는 감말랭이라는 낯선 이름의 선물이 들어있습니다.

곶감은 곶감인데 반건조 곶감이라고 생각하면 대략 맞을 듯합니다.

호랭이는 곶감은 약간 묵은내 같은 게 나서 별로 안 좋아하는데

이건 아주 그냥 입 안에서 살살 녹습니다.

맛이 기똥차군요!!!

잘은 몰라도 서기자님 또한 현재 여러가지 일 탓에 남을 배려할 수 있는 상황이 아닐텐데...

그 마음이 감사하여 더욱 달고 맛이 있는 모양입니다.

호랭이도 작은 선물을 하나 준비해 봐야겠습니다.

서기자님 감사합니다.

그리고 호랭이의 승진을 축하해 주고 격려해 주시는 모든 분들에게 보답할 수 있기 위해서라도

2009년 멋드러지게 극복하고 더 큰 마소로 만들어 보겠습니다.

호랭이 파이팅!!!

떡이떡이 파이팅!!!

대한민국 개발자 파파파파이팅!!!

마소 파파라파파파이팅!!!




     감말랭이, 개발자, 떡이떡이, 마소, 마이크로소프트웨어, 서명덕, 서명덕 기자, 선물, 소포, 월간 마소, 청도
     3   
BlogIcon Jelly's 2008.12.06 16:29 신고
서명덕기자님 멋지심
BlogIcon 철산초속 2008.12.06 16:37
와...감동이네요....근데원래 호랑이가 젤 무서워하는건 곶감임...ㅋ
BlogIcon 호야지기 2008.12.06 16:55
부럽네요

전 서기자님에게 아직 인사도 못했는데ㅠ
BlogIcon 미노 2008.12.08 18:23
오호.. 사회생활 잘하나본데.. 선물도 받고..
부럽네.. 나도 곶감 잘먹는데.. 안남았나?
남았음 좀 나눠먹고 사세.. 친구.. ㅋㅋ

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

 

 

한눈에 보는 대한민국 IT 25년...
+   [마이크로소프트웨어]   |  2008. 12. 3. 20:45  



마이크로소프트웨어는 지난 11월 19일에

창간 25주년을 기념하고 RIA 기술을 재조명하는 의미에서

RIA to RxA라는 주제의 세미나를 했는데요.

그때, 세미나 내용 만큼이나 관심을 받은 게 있습니다.

바로 25년간 만들어진 마소의 표지와 각 표지에 해당하는 당시의 이슈들을

정리해서 한 작은 전시회인데요.

그 전시 내용을 간단히 모아봤습니다.

월간 마소 12월호에 실린 내용을 발췌한 것이니 이미지가 잘 안 보이시는 분들은 12월호 구입을... 굽슨굽슨~

스크롤의 압뷁이 심하니 마음의 준비를 단단히 하시고...

자 그럼 25년의 역사 여행을 떠나 볼까요~


ㅋㅋㅋㅋㅋㅋ 아이고~~~~~~~~~~

제가 이걸 25편까지 다 만들었는데...

만든 파일의 이미지 크기를 잘 못 수정해 버려서 =_=;

일단 한 번에 너무 많이 보면 지루하니 1편은 여기서 끝! =_=;;;;;;;;

덜덜덜

다시 하려니 너무 귀찮삼....




     IT 역사, 개발자, 마소, 마소 히스토리, 마이크로소프트웨어, 월간 마소, 호랭이
     0   
BlogIcon archmond 2008.12.04 01:03 신고
마소 12월호 기대되는군요..
BlogIcon 호랭이 2008.12.04 14:04 
12월호를 아직 못 받으신 건가요 아니면 안 사신 거??? =_=+
BlogIcon archmond 2008.12.04 14:42 신고 
둘 다 맞습니다. 마소에서 보내 주는 것을 기다리고 있지요.
BlogIcon 학주니 2008.12.04 10:35 신고
ㅎㅎㅎ
지금 옆에 마소 2004년 2월호가 있는데 특집 제목이 64비트 시대를 준비하는 차세대 운영체제군요 ^^;
BlogIcon 호랭이 2008.12.04 14:03
헉!!! 이 뒤에 그 내용도 나오는데... 덜덜덜
BlogIcon 미노 2008.12.08 18:29
나도 예전엔 마소 매달 사보는 재미로 살았었는데,
언젠가부터 마소에서 보내주는걸 기다리게 되더니
이젠 조금씩 소홀해 지는것 같네..

친구가 하니 신경써서 한권한권 사봐야겠구만..
아님.. 또 마소에서 오는걸 기둘리던가..
(연재 하나 할까? ㅋㅋ)

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

 

 

열정을 코딩하는 개발자 '권용휘'
+   [마이크로소프트웨어]   |  2008. 10. 13. 08:30  


가끔 사람들이 호랭이에게 개발자들에 대해 물을 때가 있습니다.

그 중 '개발자들은 어떤 사람들이냐'라는 질문에 대한 대답은 늘 한결 같습니다.

"정상인은 아니다"가 제 답변입니다.

사실 좀 더 과격한 표현도 있긴 하지만...

하지만 이 말 만큼 개발자를 잘 표현하는 말이 또 있을까 싶기도 합니다.

개발자들을 만나며 느끼는 감정이란 참으로 미묘하고도 흥분됩니다.

'뭐 이런 사람들이 다 있나'싶기도 합니다.

그리고 여기에 또 한 명의 별로 정상인 같지 않은 개발자가 한 명 있습니다.

악성코드 제거 프로그램인 '울타리(오늘 설치해서 돌려보니 호랭이 컴퓨터엔 악성 코드가 168개 OTL... 감사한 마음에 애드센스 광고 꾸욱 눌러드리고 왔습니다요)'와

윈도우 최적화 프로그램인 '클릭 투 트윅'을 개발해서

무료로 팍팍 뿌리고 있는 권용휘 씨의 이야기입니다.

앞서 소개 됐던 16살 CEO 오규석 군이나 14살 천재 소년 윤희수 군 보다는 나이가 많지만

개꿈닷넷이란 사이트에서 자신이 만든 8개의 프로그램을 배포하며

하루 약 3만명의 방문자와 누적 방문자가 4천만이 넘는 사이트를 운영하는 권용휘 씨의 나이는 이제 겨우 스물 넷입니다.

마소와 함께 개발자의 꿈을 키웠다는 그 이기에 더욱 관심이 가는 그의 이야기를 들어보시죠. ^-^*

악성코드 잡는 ‘울타리’ 만든 개발자 권용휘
‘realization of dream!’ 꿈은 이루어진다

“잘 돌아가던 PC가 갑자기 느려졌다면...” 악성코드 침입을 의심해 볼 필요가 있다. 침입 형태도 다양해 무료백신을 가장한 악성코드가 넘쳐난다. 실수로 설치라도 하는 날엔 시스템 전체에 영향을 미친다. 제거에 들어가는 비용도 만만치 않다. 이런 사용자를 위해 무료 악성코드 제거기를 만들어 배포하는 개발자가 있다
글 | 문경수 기자 objectfinder@imaso.co.kr . 사진.동영상 | 한국마이크로소프트 황선영

오픈소스 개념이 출현한 뒤로 소프트웨어 환경에 큰 변화가 생겼다. 소스포지를 잘만 검색하면 원하는 기능을 갖춘 프로그램을 공짜로 얻는다. 단 오픈소스 특성상 여럿이 개발하다 보니 릴리즈나 피드백이 지연되게 마련이다. 악성코드를 제거하는 ‘울타리’, 시스템 최적화 프로그램인 ‘클릭투트윅’을 만들어 배포한 권용휘 씨(24)는 ‘업데이트 좀 그만’해달라는 다소 황당한 피드백을 받는다. 혼자서 공개 프로그램을 만들다 보니 협업에 들어가는 자원이 필요 없다. ‘realization of dream(http://rodream.net)'사이트로 사용 반응을 체크했다가 릴리즈에 반영한다. 많게는 한 달에 일곱 번이나 릴리즈를 했다.            

<자알 생겼다!!! 근데 어디 보시나???>

경북 문경이 고향인 그는 중학생 때부터 공개 프로그램을 개발했다. 우연한 기회에 서점에서 발견한 마소지가 발단이 됐다.

1998년 4월호에 비주얼 베이직 5.0 체험판을 부록으로 준다는말에 주저 없이 구입했다.

한번은 개발도구 3~4종을 5천원에 판다는 줄 광고를 보고 송금했다가 CD를 못 받은 적도 있다.

그만큼 CD 구하기가 힘든 시절이었다.

“마소를 사놓고 몇 개월간 잊고 지냈어요. 6개월 쯤 지나서 방학을 이용해 집중해서 읽었어요. 딱 한번 마소 신간을 사러간 일 외에는 대문밖에 나가질 않았죠. 샘플 프로그램을 만들기 위해 죽기 살기로 매달렸습니다.” 프로그램을 완성했을 땐 세상을 다 얻은 기분이었다.

동굴에서 ‘한 줄기 빛을 본 느낌’이었다고 당시 소감을 대신했다.

그 후로 프로그래밍에 재미가 붙어 뭐든 계속 만들어 보고 싶었다.

뚜렷한 목표가 없던 차에 정보올림피아드가 눈에 띄었다.

코딩엔 자신이 있었지만 정보올림피아드는 별도로 알고리즘 지식이 필요했다.

대신 공모전 응모로 목표를 수정했다.

학업과 공모전 준비를 병행해 정보올림피아드 공모전에서 입상을 했다.

공모전에 대한 열정은 대학까지 이어졌다.

건국대학교 컴퓨터공학과에 입학하자마자 소프트웨어 공모전에 응모했다.

심사위원단 앞에서 발표를 하던 중 한 심사위원의 안색이 안 좋아 보였다.

“순간, 저 사람만 설득하면 승산이 있겠다고 판단했어요. 그 사람만 뚫어져라 쳐다보고 발표했죠. 나중에 알게 된 사실이지만 졸음이 와서 그랬다고 하더라고요.(웃음)” 그에게 있어 프로그램 개발이란 매순간 모든 것을 던질 만큼 양보할 수 없는 가치였다.      

<호랭이 컴퓨터에서 나온 168가지 악성코드... 어쩐지 너무 느리더라는 OTL 컴터 관리 좀 하쟈~!>

현실과 이상

대학에 입학한 그는 항공대에 다니는 한 살 터울인 형과 함께 일산에서 자취를 했다. 하지만 독립하고 싶은 마음에 부모님이 납득할 만한 알리바이를 고민했다.

소프트웨어멤버십에 합격해 멤버십 공간을 쓰거나 학교 기숙사에 들어가는 것.

둘 다 안 되면 몰래 집을 구하려던 차에 멤버십 합격을 통보 받았다.

초보자를 위한 프로그램 개발도구로 지원을 했다.

기존 방식과 달리 사용자가 필요한 명령을 찾아서 선택하는 방식으로 고등학교 시절부터 만들어 오던 프로그램이다.

그는 한 줄씩 직접 코딩하며 머릿속 생각을 만들어 보는 스타일이다.

같은 과제라도 2~3달씩 몰입해서 푸는 일이 많아 남들보다 작업 속도가 느린 편이라고 했다.

알고 싶은 분야가 생기면 직접 공부하거나 물어보는 스타일이다.

“교양 프로그래밍 시간에 연산자 우선순위 문제를 풀었는데 오답으로 나온 적이 있어요. 직접 돌려보니 문제가 없었어요. 곧바로 교수님을 찾아가 주말 내내 문제에 대해 대화를 나눴죠.”

요즘은 휴학하고 병역특례 중이지만 프로그램 개발은 멈추지 않았다.

실무경험이 쌓이면서 사용자 니즈가 명확한 프로그램을 만들어 보기로 했다.

클릭투트윅 이후로 나온 울타리나 ‘개꿈라디오’ 같은 프로그램은 사용자 요청으로 탄생했다.

초기엔 함께 개발할 사람을 찾기 위해 배포할 때 코드를 공개했지만 생각만큼 피드백이 많지 않았다.

혼자서 개발하는 것도 이런 이유에서다.

직접 회사 생활을 해보니 업무가 과중해 현실과 이상 간의 거리감이 큰 것 같단다.

  
프로그래밍, 그 본질에 대한 탐구

그는 주로 시스템 쪽이나 애플리케이션 프로그램을 개발한다.

굳이 한쪽을 고집하는 이유를 묻자, 본질에 대한 탐구정신이라고 답했다.

“아키텍트가 말하는 설계 방법론을 보면 좋은 아키텍처 서적을 보고 설계 기법을 익히라고 하지만, 과연 제대로 된 방식인지 의구심이 들었어요. 내가 만들 줄 안 다음에 설계하는 게 합리적라고 생각했어요. 물론 다 만들어 볼 순 없겠죠.”

무조건 애플리케이션 프로그램만 고집하는 건 아니다.

변화 추이를 외면하지 않는 혜안을 제시했다. 웹 기반 애플리케이션의 경우 콘텐트 제공자가 최적화되지 않은 콘텐트를 제공해 속도가 느려지거나 원하는 정보를 정확히 전달하지 못해 문제라고 했다.

애플리케이션 프로그램들이 이런 웹 기반 정보들을 재가공하고 최적화해주는 보완재 역할을 해준다고 했다.

그의 꿈은 프로그램을 개발하는 교수가 되는 것이다. 

MSDN POPCON(http://blogs.msdn.com/popcon)에서 동영상을 보실 수 있습니다.




     개꿈닷넷, 개발자, 권용휘, 마소, 마이크로소프트웨어, 악성코드, 오규석, 오픈소스, 울타리, 월간 마소, 윈도우최적화, 윤희수, 클릭투트윅
     0   
BlogIcon 지저깨비 2008.10.13 12:59
오래전부터 사용하던 프로그램입니다.
개발자 이름은 알았지만 이렇게 사진과 인터뷰를 보니 좋습니다. 참 대단해요. 시간과 열정을 쏟아서 만든 것을 값없이 배포하니 그저 감사할 따름입니다.





그리고 호랭이님.... 피씨관리 쫌! =3=3=3
BlogIcon 마소호랭이 2008.10.13 13:03 신고 
ㅋㅋㅋ 그래서 했다니까요.
그나저나 저는 생각보다 권용휘 씨가 너무 젊어서 깐딱 놀랐다는...
BlogIcon archmond 2008.10.15 20:48 신고 
ㅋㅋㅋㅋ
PC를 대충 써줘야 저러한 프로그램이 살지 않을까요.
2008.11.14 09:27
비밀댓글입니다
BlogIcon 마소호랭이 2008.11.16 01:25 신고 
아이고 이거 참 오랜만이네요!!! ^-^*
어뜨케 잘 지내고 계신지...
추워지는 날씨에 감기 조심하시고
건강하고 행복한 겨울 나시길 바라겠습니다.
행복하세요~!

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

 

 

'전망' 그것은 아무것도 아니다
+   [개발 이야기]   |  2008. 10. 5. 00:26  


며칠 전에 쓴 안철수 박사님의 발표 내용과 이어지는 포스트입니다.

박사님은 자신의 사례를 통해 개발자 후배들에게 메시지를 전하고자 했습니다.

그 예가 바로 의사들의 이야기입니다.

독특한 자신의 경력에 걸맞는 사례지요.  ㅎㅎ

대부분의 사람들이 가장 좋은 직업의 하나로 꼽는 의사.

하지만 대한민국 의사의 50%가 직업에 만족하지 못하고 있으며, 20%는 도산하거나 해외로 도피한다고 합니다.

또, 적성에 맞지 않는다면 좋은 의사란 되기 어렵다는 사실도 강조했습니다.

앞서 자신의 직업에 만족하지 못하는 50%의 의사 앞에 자신의 건강 심지어는 생명을 맏겨야 하는 환자는 얼마나 불행한가요.

그리고 이제부터가 전망에 대한 이야기입니다.

의대생들은 성적이 우수한 학생부터 과를 선택할 수 있는 권한이 주어진다는데요.

그래서 성적이 좋은 학생들은 전망이 좋은 과를 지원하게 된다고 합니다.

박사님이 학생이었을 당시에는 내과가 유망했던 모양입니다.

그래서 공부를 잘 하는 학생들은 '내과'를 성적이 가장 나쁜 학생들은 '피부과'를 선택했다고 합니다.

하지만 요즘은 이 전망이 정 반대로 뒤집혔다네요.

이처럼 전망이란 그다지 중요하지 않은 것이며

언제든 뒤바뀔 수 있는 거라는 게 박사님의 조언입니다.

어떤 직업을 택했든 그 직업이 언젠가는 전망 좋은 직업이 될테니

전망을 보고 직업을 선택하거나 자신이 현재 몸담고 있는 직업의 전망이 그다지 좋지 않다고

의기소침할 필요가 없다는 얘기입니다.

하지만 여기에서 가장 중요한 건...

현재 전망이 좋은 직업을 택하든 그렇지 않은 직업을 택하든 그건 중요하지 않지만

반드시 자신이 좋아하고 즐길 수 있는 일을 해야 한다는 점입니다.

여기서 다시 자신의 직업에 만족하지 못하는 50%의 의사 이야기가 나옵니다.

남들에게는 전망 좋은 직업일지 모르지만 자신은 적성이 맞지 않는 직업이라면

자신과 환자 모두를 불행하게 만들게 될 거라는 사실입니다.

개발자도 마찬가지입니다.

자신이 즐길 수 있다면 현재 눈앞에 닥친 일이 어렵고 힘들 지언정 즐겁게 극복해 낼 수 있을 것입니다.

그리고 그렇게 즐기는 사이 지금은 비유망직종으로 꼽히는 개발자란 직업이

어느새 다시 시대를 풍미하는 직업이 되어 있을지도 모를 일입니다.

이 날 허광남 님이 또 한가지 좋은 얘기를 해 주었는데요.

바로 이겁니다.

"여러분 미국이 IT 정책을 아주 잘 펼쳐준 덕분에 구글이 구글 맵을 만들고, 애플이 아이팟을 만든 건 아닙니다. 모든 건 우리 하기에 달렸습니다"

물론, 약간의 억지가 있는 말이지만 저는 이 말을 믿고 싶네요.

요즘 개발자 뿐만 아니라 기자와 매체들도 상당히 힘든 시기를 보내고 있습니다.

상상 못할 연봉과 그나마도 몇 달씩 체불되는 상황에서도 자신의 미디어를 지킬 수 있는 건

자신의 일에 대한 가치를 잘 알고 또한 그 일을 소중히 하고 있기 때문일 것입니다.

지난 달과 지지난 달 마소의 형제와도 같은 매체가 하나씩 운명을 달리했습니다.

호랭이에게는 최근 스스로 세상을 등진 한 연예인의 사건 이상으로 가슴아프고 슬픈 일입니다.

혹시 이제 종이 매체는 생명력을 다한 게 아닌가 하는 의구심이 들기도 합니다.

하지만, 여전히 종이 매체는 독자들에게 필요한 존재입니다.

또한 개발자들의 이야기를 하나로 모아 큰 목소리를 내 줄 매체 또한 여전히 필요합니다.

마소가 대체 언제 그리도 큰 목소리를 내 주었느냐고 반문하신다면

사실 할 말이 없습니다.

아마 무언가 말을 한다면 그건 핑계가 될 것이기 때문입니다.

그저 저희 스스로도 적지 않은 어려움들을 해결해 나가고 있다는 것만은 알아 주었으면 합니다.

그리고 이제 조금씩 더 마소의 이름에 걸맞는 모습을 갖춰나가는 걸 지켜봐 주시길 바랍니다.

'전망' 그것은 아무것도 아닙니다.

그렇기에 호랭이도 이 어려운 시기를 극복해 내리라 다짐해 봅니다.

개발자 여러분도 각자의 자리에서 멋드러지게 성공해 내시길 바라겠습니다.

대한민국 개발자 파이팅!!!

호랭이의 개발자 동생은 몇달째 얼굴조차 보기 힘이 듭니다. 휴일인 오늘도 밤 11시가 넘어서야 슬슬 일을 마무리하고 있는 모양입니다. 며칠 전 사무실로 찾아온 한 개발자는 자신이 다니는 회사의 사정이 너무 나빠져 월급조차 제대로 받기 어려움을 하소연했습니다. 또 한 개발자 친구는 바쁜 업무 탓에 결혼 2년을 채우지 못하고 파경을 맞이하게 되었습니다.
정말 이러한 현실 속에서도 희망의 씨앗을 찾을 수 있는 것인지 스스로 반문을 해 봅니다.
하지만 그렇다고 해도 포기할 수는 없는 노릇입니다.
다시 한번 두 주먹을 꼬옥 쥐어봅니다. 파이팅!!!




     IT 정책, 개발자, 마소, 안철수, 월간 마소, 의대, 의사, 의사 만족율, 전망 그것은 아무것도 아니다, 직업 만족율, 허광남, 호랭이
     2   
BlogIcon 오랜친구 2008.10.05 01:05
다다음 주 강 건너 잠실 갑니다.
시간 내주시면 오후에 사무실 근처로 따끈한 커피라도 사서 갈게요.
주먹 불끈! (아니 개발 바닥 현실에 불끈해야지 먹는 거(?)에 이리 집착을 하다니 저도 참...)
BlogIcon 마소호랭이 2008.10.05 01:07 신고 
ㅎ.ㅎ 오친님을 만나게 되다니...
저도 주먹 불끈!!! ^-^*
무조건 오십쇼!!!
BlogIcon 아크몬드 2008.10.05 11:48
좋은 직장에 좋은 조건으로 들어가는 것, 참 힘든 일입니다.
하지만, 아직 포기하기엔 이르죠.
BlogIcon 호랭이 2008.10.05 12:12 
맞습니다. 아직 포기하기엔 일러도 너무 이릅니다. 파이팅입니다요.
BlogIcon 이정주 2008.10.05 19:39
100번 옳은 말씀이네요. 학교에서는 선배들이나 심지어 교수님들까지 자바가 전망이 좋다고들 말을 합니다. 그래서 자바를 개인적으로 하고 배우고들 있는 형편이구요. 선배들 학교에 오셔서까지 C와 C++을 하면 취업잘된다는 이런 말뿐이고, 그래서 학생들은 그저 꿈은 뒷전이고 전망만을 보는 것같아 안타깝네요. 글이 길어지는데 나중에 트랙백을 걸어야겠네요. 아무튼 파이팅입니다!
BlogIcon 마소호랭이 2008.10.05 21:41 신고 
ㅎ.ㅎ 이정주 님처럼 자신의 일에 열정적이고 늘 최선을 다하고 있는 분이라면 분명 좋은 때가 올 거라고 믿습니다. 이정주 님도 남들 다 피해가려는 개발자의 삶을 준비하는 여러 학생들도 모두 파이팅입니다요.
BlogIcon kkamagui 2008.10.05 20:34
파경이라니... 깜짝 놀랐습니다. ㅠㅠ
어서 빨리 개발자가 대우받는 세상이 왔으면 좋겠습니다. 그전에 물론 저희가 많이 노력해야하겠지만요. ㅠㅠ
좋은 글 잘 보고 갑니다.
BlogIcon 마소호랭이 2008.10.05 21:45 신고 
까마귀 님 오랜만입니다. 개발자 뿐만 아니라 자신의 일에 열정을 불태우는 모든 사람들이 잔 머리나 굴리며 남의 공을 가로채는 사람들보다 대우받는 바른 세상이 되면 참 좋겠습니다.
아마 그래서 호랭이는 나이에 걸맞지 않게 그렇게도 애니메이션을 좋아하는지도 모르겠습니다. ㅠ_ㅠ
BlogIcon kkamagui(까마귀, 한승훈) 2008.10.06 18:30 신고 
쿠.. 쿨럭..;;; 그런거군요. ㅠㅠ
뭔가 굉장한 인과관계가 있는 듯합니다. ㅋㅋ
BlogIcon Namz 2008.11.11 12:31 신고
맞는말같네요... it의 시대가 갔다고 한들 다시 오지 말란 법은 없지요..
그리고 개발자란 직업이 황금 직업이 되지 말란 법도 없지요...
그리고 무엇보다더 얼마를 버느냐보단 자기 적성에 맞는 일을 하는게 맞지요...^^
BlogIcon 마소호랭이 2008.11.11 12:46 신고 
^-^*
그 마음 변치 않으시길... 파이팅!!!

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

 

 

[만화] 개발의 달인!!!
+   [마이크로소프트웨어]   |  2008. 10. 4. 16:57  



이 만화는 월간 마이크로소프트웨어 2008년 10월호에 개제된 만화입니다.

Mr.D는 개발자들의 일상이나 각종 재미난 에피소드들을 개발자의 눈으로 패러디하는 만화입니다.

좋은 아이디어가 있으면 flytgr@imaso.co.kr로 [만화 아이디어]란 말머리를 달아 보내 주세요.

주제가 선정된 분께는 소정의 기념품을 드립니다.




     Mr.D, 개발의 달인, 개발자, 개발자 만화, 달인, 마소, 마이크로소프트웨어, 만화, 오리군, 월간 마소
     3   
BlogIcon 오랜친구 2008.10.04 17:54
문득 모 통신사 CF의 '공대 아름이'가 생각나면서,
수많은 개발 사마들 사이의 덜 수많은 개발 히메님들이 오버랩 됩니다.
뜬금없이요.
BlogIcon 마소호랭이 2008.10.04 18:08 신고 
오호 그 거 괜찮겠구려!!! 히메사마!!!
BlogIcon 울프데일 2008.10.12 12:06 신고
하하하 재밌는 만화입니다.
진짜 달인시리즈는 어떤 분야에서도 재밌네요~ ^^
BlogIcon 마소호랭이 2008.10.12 12:22 신고 
ㅎ.ㅎ 감사합니다. 달인-2를 준비중이니 기대해 주삼!!!

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

 

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

열이아빠's Blog is powered by Daum