태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

 

 

 

 
분류 전체.. (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/09   »
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    
+ ITViewpoint
+ 도이모이
+ with okgosu
+ 학주니닷컴
+ 열이아빠의 R⋯
+ Gsong.s Blog
+ 비주얼스튜디⋯
+ 광파리의 글⋯
+ LovedWeb
+ 블루오션의⋯
+ 울지 않는 벌새
+ PC 지존
+ 디지털통
+ 아크비스타
+ 고독한 프로⋯
+ Total : 2,100,735
+ Today : 4
+ Yesterday : 11
  

 

 

 

아이마소 _해당되는 글 5건
2009.11.27   소프트웨어 개발 방법론의 함정 
2009.10.09   모바일 게임의 어제와 오늘, 그리고 내일 
2009.09.28   비즈니스 애플리케이션의 UX 실현 가이드 
2009.09.17   윈도우7이 여는 새로운 개발자 세상 (2)
2009.02.18   애자일 프랙티스의 실제 활용사례 (2)

 

소프트웨어 개발 방법론의 함정
+   [마이크로소프트웨어]   |  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   

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

 

 

모바일 게임의 어제와 오늘, 그리고 내일
+   [마이크로소프트웨어]   |  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   

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

 

 

비즈니스 애플리케이션의 UX 실현 가이드
+   [마이크로소프트웨어]   |  2009. 9. 28. 21:05  


최근 기업 내·외부의 화두 중 하나가 ‘사용자 경험(UX : User eXperience, 이하 UX)’이다. 현존하는 모든 산업(그것은 비단 우리가 종사하는 IT에 국한되지 않는다.)은 사용자 경험을 간과할 수 없다. 왜 그럴까? 감히 현대기술의 첨병이라 말할 수 있는 우리(개발자와 기업)들에게 UX는 어떤 의미를 갖고 있으며, 어떤 전략을 펼칠 수 있을 것인지 함께 얘기해 보자.

고석률 varchar74@paran.com|코딩 한 줄, 한 줄에 묻어있는 프로그래머의 열정에 박수를 보내야 마땅하다고 굳게 믿고 있다. 항상 향기가 있는 사람이 되기를 노력하며 살고 있으며, 현재 ㈜투비소프트에서 선임컨설턴트로 재직 중이다.

응용프로그램을 개발하거나, 웹 사이트를 개발하거나, 우리는 끊임없이 무언가를 만들어서 누군가에게 그 결과물을 제공하고 있다.

우리가 그것을 만드는 기준은 무엇이고, 어떤 가치를 내재하며, 그것을 사용하는 사람들은 우리의 결과물에 만족해 할까?

우리가 다루는 것들을 깊이 들여다 보면 무수히 길게 늘어져 있는 나름의 체계를 지닌 0과 1이라는 숫자로 분석될 수도 있겠지만, 우리의 고객들에게 그것은 엄연히 ‘제품’이다. 비싼 돈을 지불하든, 무료로 제공되든 모든 제품은 그것을 사용하는 고객에게 선택되기를 갈망하고, 그 선택에 의해 당신이 만든 프로그램의 가치가 매겨진다. 그러므로 그 제품을 통해서 이윤을 추구해야 하는 기업에서 제품을 기획, 설계, 개발하는 당신은 끊임없이 사용자를 배려하고, 더 다가가기 위해 노력해야만 한다.

마치 다시 굴러 떨어질 것을 뻔히 알면서도 산 위로 바위를 밀어 올려야 하는 그리스 신화의 ‘시지프스’처럼. 이것은 우리의 끝없는 숙제일 것이다.

 

들어가며

누구나 마찬가지겠지만 이 글을 읽고 있는 독자들은 가끔 생필품 등을 사기 위해 대형마트에 가서 쇼핑을 할 것이다.

각자의 마트 선정 기준은 무엇인지 곰곰히 생각해 보자. 집과 가까운 거리, 저렴한 가격, 신선한 고기나 야채, 다양한 품목, 친절한 점원, 시원한 매장, 넓은 주차장, 세련된 인테리어, 쇼핑 동선의 편안함 등등 개인별로 그 이유가 정말 다양할 것이다.

물론 합리적인 부분, 특히 가격이나 제품의 질만 고려한다면 넓은 주차장이나 세련된 인테리어, 점원의 친절 등은 선택의 이유 중 그 순서가 뒤로 밀려날 것이다. 하지만 필자뿐 아니라 대부분 사람들은 비단 가격과 품질, 거리만으로 마트를 선택하지는 않는 것으로 보인다.

운전이 서툰 사람에게는 넓고 밝은 주차장이 선택의 이유일 수도 있고, 불필요하게 많이 걷는 것이 싫은 사람은 소비자를 더 고려한 동선(일부 마트에서는 소비심리를 자극할 수 있는 쇼핑 동선을 만들어 낸다.)으로 쇼핑할 수 있는 곳을 찾을 수도 있다.

또는 주말에 꿈같은 낮잠을 포기하고 아내와 아이들을 따라 나온 남편들에게는 아이들 놀이터나 자신의 휴식공간을 제공하는 곳이 좋을 수도 있다.

집 가까이에 마트가 있는 필자의 친구는 저렴한 가격 때문에 마트를 찾기는 하지만 자신이 계속 마트를 찾도록 유도하는 이유는 저렴한 가격이 아니라 소량 계산대 때문이라고 한다.

그 친구는 동네 슈퍼마켓에 갈 거리에 마트가 있으니, 집에서 필요한 물건이 생길 때마다 자주 들를 수 있는데, 만약 이 친구처럼 물건 한 두 개만 사러 온 사람들이 1주일에 한 번 장보러 나온 사람들과 같은 줄에 서서 엄청나게 많은 물건을 계산하는 시간동안 기다려야 한다면 당연히 다음부터 가격은 좀 더 비싸더라도 동네슈퍼마켓을 이용할 것이 뻔하다.

이런 사실은 대형마트를 운영하는 사람들이라면 모두 알 정도의 내용이지만 일반인들에게 시사하는 바가 크다. 마트가 질 좋은 물건을 싸게 파는 곳이라는 점은 분명하지만 그 마트를 찾아 물건을 사는 고객들은 그 이상의 다른 요소들에 의해 해당 마트 방문을 결정짓는다는 것이다.

Rich vs Poor

TV, DVD 플레이어, IPTV, 오디오 등 나날이 가전의 종류가 늘어나고 있으며, 이 가전들과 필수적으로 함께 제공되는 아이템인 리모콘도 복잡하고 다양해지고 있다.

이 리모콘 얘기 먼저 시작해 볼까 한다. 보편적으로 대부분 TV를 보기 위해 하루에 한 번씩은 리모콘을 사용할 것이다.


<화면 1>의 두 가지 리모콘을 보고 어떤 느낌을 받았냐고 질문하고 싶다.

분명 두 리모콘은 다르게 디자인 되어 있다.

우측 리모콘에는 수많은 버튼이 있어 메뉴를 찾고, 특정 기능을 수행하는 데 어려움이 있어 보인다.

혹시라도 연세가 있으신 분들은 글씨가 작고, 버튼별로 기능이 직관적으로 구별되지 않아 돋보기 안경을 써야 할지도 모르겠다.

반면에 왼쪽의 티보 리모콘(TiVo Inc: 디지털 비디오 레코더 분야의 선구그룹 제품)은 그 제작과정에서 사용자를 배려한 고민이 드러난다.

큼직한 버튼과 깨끗한 라벨링, 사용자 동선을 고려한 버튼 배치 등으로 인해 여러 가지 작동에 편리하며, 형태적으로도 사람의 손에 착 들어올 수 있도록 땅콩 모양의 외관으로 디자인 돼 있다.

필요에 따라 사용된 색, 재미있는 카툰 아이콘을 통한 집중도 개선뿐만 아니라 검은색 바디를 사용해 돋보기 없이도 내부 버튼 인식에 도움이 되도록 디자인 되었다.

어떻게 이 작은 리모콘에 이렇게 큰 차이가 생길 수 있었을까?

답은 의외로 아주 간단하다.

시간과 노력을 들여 사용자 중심적으로 사고한 결과이다. 가장 필요한 버튼만을 남겨두면서 추가적인 메뉴는 화면에 나타나는 메뉴를 통해서 선택하도록 디자인 했다.

그 결과 이 리모콘은 아주 쓸모 있는 물건인 동시에 사용자에게 즐거움을 선사하는 물건으로 거듭났다.

참고로 이 리모콘은 여러 디자인 어워드에서 수상하기도 했다. 이 이야기는 제품을 디자인할 때 ‘사용자 중심적 사고’가 얼마나 중요한지를 잘 보여주는 예이다.


또 다른 사례를 살펴보자.


<화면 2>에서 볼 수 있는 자동판매기는 우리가 음료수나 과자를 사 먹기 위해 아주 흔히 사용하는 것들이다. 두 자동판매기를 비교해 보자.

오른쪽의 자판기는 실제 과자봉지를 보여주며 사람들의 구미를 당기려는 노력이 보이는 반면, 왼쪽 음료수 자판기는 실제 자판기 캔을 보여주는 대신 커다란 버튼에 이미지를 사용했다는 점이 가장 두드러지는 차이점이다.

눈을 감고 두 자판기에서 각각 콜라와 과자를 하나씩 사는 장면을 상상해 보기 바란다.

왼쪽의 자판기는 사용법이 아주 쉽다.

아마도 다섯 살 난 필자의 딸아이도 돈만 있다면 마시고 싶은 음료수를 금방 뽑아서 마실 수 있을 것처럼 보인다.

좀 더 상세히 과정을 요약해 보면

1) 돈을 넣는다.

2) 먹고 싶은 음료 그림이 그려진 커다란 버튼을 누른다.

3) 아래의 투출구로 나온 음료캔을 꺼낸다.

이렇게 3가지 동작만으로 원하는 음료수를 얻게 된다.

반면 오른쪽의 자판기는 과자를 뽑기 위해서 어떤 과정을 거쳐야 할까?

1) 먹고 싶은 과자를 정하고 과자 봉지 아래에 적혀있는 코드를 읽는다(예를 들어 C12).

2) 자판기 오른쪽에 있는 키패드에서 C12를 누른다.

3) 액정에 표시된 해당 과자의 가격을 확인한 후 돈을 넣는다.

4) 확인 버튼을 누른다.

5) 과자 봉지를 꺼낸다.

위 음료자판기보다 2단계(코드를 확인하고 외워서 번호를 눌러야 하는 상당히 집중도 있는 작업) 정도 단계가 늘어났다.

게다가 과자를 뽑고 나서 보니 내가 먹고 싶은 과자가 아니다.

이럴 수가. C12라는 코드는 잘 확인했는데 키패드를 누르다가 C13을 눌러버렸다.

혹시라도 이런 실수를 직접 해 본 독자라면 그 기분을 더 잘 느낄 듯하다.

오른쪽 자판기의 제작자는 아마도 실제 과자 봉지를 잔뜩 보여줌으로 사람들의 구매 욕구를 강화하고자 한 것처럼 보이지만 사실 자판기를 이용하는 사용자는 복잡해진 사용법에 어리둥절하거나, 혹시나 실수로 과자의 번호를 잘못 눌러 다른 것을 먹어야 하는 좋지 않은 결과를 초래한다.

고객 경험 개선 사례 - 에이비스

고객 경험을 높이기 위해 현재의 문제를 정확히 알고 이를 개선하는 좋은 방법론 중 하나가 일명 ‘프로세스 쪼개기’이다.

세계적인 렌터카 업체인 에이비스에서는 고객경험을 향상시켜 충성도를 확보하기 위해 자동차 렌트 경험 전체를 조각조각 분석한 것으로 유명하다.

외부 컨설턴트의 도움을 받아 행해진 이 작업에서는 자동차를 렌트하는 프로세스를 100단계로 세분화하여 쪼개고, 각 단계별로 개선할 점이 발견되면 이를 집중적으로 개선하는 노력을 기울였다.

이런 노력을 통해 브랜드 키(Brand key: 미국의 브랜드 조사기관)가 30개 산업분야 총 158개 회사를 대상으로 행한 ‘2002년 브랜드 충성도 순위 조사’에서 에이비스는 당당히 1위를 차지했다. 이 이야기는 고객 경험 관리가 기업에게 어떤 성공을 가져다 줄 수 있는지를 여실히 보여주는 사례다.


● 출처: 토마스 무차 Thomas Mucha, 고된 노력에 대한 보상(The payoff for Trying Harder) <비즈니스 2.0> 2002년 7월

이 자판기를 만든 제작자는 자신이 팔고 싶었던 수많은 종류의 과자, 구매 욕구를 높이기 위한 예쁜 디자인의 과자 봉지 디스플레이, 지금 살 수 있는지 다 팔렸는지 여부를 보여주고자 했던 노력들은 아마도 왼쪽의 자판기처럼 단순화하는 과정에서 희생해야 하는 trade-off(트레이드 오프: 두 개의 목표 가운데 하나를 달성하려고 하면 다른 목표의 달성이 지연되거나 희생되어야 하는 경우 양자간의 관계)였을 것이다.

하지만 실제로는 자신들의 과자를 사는 소비자들은 전혀 예상하지 못한 경험을 하게 될 수도 있다.

사용자가 제품을 실제 사용하는 과정을 세분화하고, 그 가운데 발생할 수 있는 문제점이나 불편한 점을 파악해야 하며, 판매자의 의도와 구매자의 경험 사이에서 상충되는 요소들을 적절히 다루었다면 어땠을까하는 아쉬움이 든다. 우리도 주변에서 종종 프로그램이나 웹 사이트 제작자가 그것을 사용하게 될 사용자를 간과하고 기술 자체에 치중한 사례를 보곤 한다.

User Experience(사용자 경험: UX)

살펴본 사례를 통해 우리가 그동안 사용자를 얼마나 배려해 왔는지, 혹은 스스로가 소비자로서 얼마나 배려되지 못했는지 생각해 봤을 것이다.

사용자가 제품 또는 시스템을 사용하면서 느끼게 되는 모든 감각을 우리는 사용자 경험이라고 부른다.

물론 이것을 정량화하거나 실체를 제시하기 힘든 것이 사실이다. 하지만 분명히 그것은 존재한다.

마치 우리가 숨을 쉬고 살 수 있도록 해 주는 공기가 눈에 보이지는 않지만 우리를 감싸고 있는 것과 마찬가지로 말이다.

그렇다면 힘들기는 하지만 사용자 경험이라는 것이 어떤 것들로 이루어져 있는지, 어떤 작용을 하는지 좀 더 명확하게 규정할 필요가 있을 것이다.

왜냐하면 그로 인해 우리가 제공하는 제품이나 서비스의 가치가 결정되고 있으므로. 그러면 사람들이 갖게 되는 경험은 어떤 요소들로 나누어 볼 수 있을까?

번트 슈미트는 자신의 책 ‘체험 마케팅’에서 경험의 유형을 다음의 다섯 가지로 분류해 놓고 있다.

● 감각경험(sense experience) : 인간의 오감에 호소하는 요소. 고객의 가치는 시각, 청각, 촉각, 미각, 후각을 통해 만들어진다.

● 감정경험(feel experience) : 고객의 내적인 느낌과 정서에 호소하는 요소로서 감정적 경험을 통해 고객 가치가 형성된다.

● 인지경험(think experience) : 지성에 호소함으로써 고객의 마음을 창의적으로 이끌고, 이를 통해 고객을 위한 가치를 창출한다.

● 행동경험(act experience) : 소비자에게는 다른 방식의 라이프스타일을, B2B 시장이나 산업용품 시장에서는 다른 비즈니스 방식을 보여줌으로써 고객을 위한 가치를 창출한다

● 관계경험(relate experience) : 고객에게 사회적 정체성과 소속감을 제공함으로써 고객을 위한 가치를 창출한다.

이런 요소들은 별개의 존재가 아닌 상호 보완적인 관계를 이루며 제품 저마다의 독특한 경험을 만들어내게 되는 것이라 생각된다.

오늘 아침 출근길을 떠올려 보자. 아침 출근길에 올라 탄 만원버스에 들어설 때의 시큼한 땀 냄새를 먼저 기억하는 사람도 있겠지만, 시원한 지하철에서 쾌적함을 느낀 사람도 있을 것이다.

좀 더 구체적으로 들어가 보자. 필자의 옆자리 동료는 매일 출근길에 스타벅스에 들러 그가 좋아하는 커피를 들고 흐뭇한 미소를 지으며 출근한다.

그에게 있어 아침에 그 매장에 들러 커피를 사고, 사무실까지 걸어오는 그 행동양식은 마치 어떤 의식과도 같다.

한 손에 커피 잔을 들고 걷는 동안 만원버스의 짜증스러움은 사라지고 즐겁게 업무를 시작할 수 있는 상태가 되는 것이다.

스타벅스는 자신의 매장을 찾는 사람들에게 특별한 경험을 주도록 노력하고 있는 것이 틀림없다. ‘바쁜 일상 속 커피 한잔의 여유’ 이것이 전략적이라면 스타벅스는 분명 우리가 다루고자 하는 UX를 정확히 이해하고 있는 것이다.

세상의 모든 물건은 당신에게 경험을 주고 있다


‘The Elements of User Experience’의 저자인 Jesse Garret은 다음과 같이 말한다.


신문, 케첩병, 안락의자, 가디건 스웨터에 이르기까지 사람을 통해 사용되는 제품은 모두 저마다의 사용자 경험을 가지고 있다.

“every product that is used by someone has a user experience: newpapers, ketchup bottles, reclining armchairs, cadigan sweaters” 

 

왜 사용자 경험이 중요한가?

지난 세기까지 기업들은 경영 전략에 효율성이나 최적화같은 것들을 최우선 과제로 했다.

또한 제품 생산에 있어서는 최신의 기술, 최고의 성능에 초점을 맞추어 왔다. 그런데 다음과 같은 고민에 봉착하게 되면서 딜레마에 빠지게 된다.

‘아무리 쥐어짜도 기업 효율성을 향상시킬 빌미나 조직이나 제품에서 더 이상 제거해야 할 결함도 없다면?’ ‘자사의 신기술이 더 이상 신기술이 아니고 성능은 평준화되어 버렸다면?’ 어디에서 그 조직은 생존의 실마리를 찾을 수 있을까? UX에 대한 많은 연구는 바로 그것을 사용하는 사람(고객)이 문제의 중심에 있다고 말하고 있다. 고객들은 이제 더 이상 기술에 집착하지 않는다.

그들은 그것을 사용하는 과정에서 오는 만족감을 통해 제품에 대한 가치를 매긴다. 이제 고객의 경험이 곧 제품인 시대인 것이다.

2001년과 2002년에 걸쳐 ADK라는 통신업체에서 행해진 연구조사 결과를 보면 실제 고객의 경험과 제품 매출 또는 웹 사이트의 효과에 대한 상관관계를 좀 더 현실적으로 볼 수 있다.

이 표를 보면 광고나 매장, 웹 사이트가 경험적일수록 호감도가 높아지고 더 높은 구매 욕구를 불러일으킨다는 것을 확인할 수 있다.

특히 우리는 웹 사이트의 고객 호감도와 구매 욕구 사이의 상관관계에 좀 더 주목해볼 필요가 있다. 이제 우리는 고객(우리의 프로그램, 웹 사이트를 사용하는 사용자)에게 경험을 제공해야 한다. 최근 나오고 있는 ‘경험 전략’에서는 ‘경험이 곧 제품’이라고 말하고 있다. 사용자 경험이야 말로 기업의 최고, 최대의 가치로 인식되고 있는 오늘이다.

맺으며

지금까지 현실세계를 기반으로 한 사용자 경험에 대해 함께 얘기해 봤다.

다음 호에서는 우리의 일, 즉 응용 프로그램이나 웹 사이트를 대상으로 좀 더 실천적으로 살펴보고, 우리 자신과 기업들에게 주어진 숙제를 함께 고민하고 풀어나가 보자.

 

참고 자료

1. Interaction Design ? John Wiley & Sons LTD. 2007

2. CEM(Customer Experience Management) ? Bernd H. Schmitt

3. Experiential Marketing ? Bernd H. Schmitt

4. Subject to Change(사용자 경험에 미쳐라) ? Peter Merholz, Brandon Schauer, David Verba, Todd Wilkens

※ 글에서 인용된 이미지는 모두 Interaction Design 인용하였음


>>출처 | 아이마소





     UX, 개발자, 고석률, 마이크로소프트웨어, 비즈니스애플리케이션, 사용자 경험, 소프트웨어, 아이마소, 애플리케이션, 투비소프트
     0   

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

 

 

윈도우7이 여는 새로운 개발자 세상
+   [마이크로소프트웨어]   |  2009. 9. 17. 16:34  


윈도우7(Windows7)은 개발자들에게 어떤 의미일까. 개발자들은 사용하기 쉽고 시각적으로도 매력적이며, 뛰어난 성능을 갖춘 애플리케이션을 만들기 원한다.

윈도우7은 그 해답이 될 수 있다.

멀티터치는 물론이고 다이렉트X11, 센서API 등을 통해 애플리케이션을 하드웨어 환경과 긴밀하게 연동시킬 수 있다.

특히 짧은 기간 동안에 고급 기능을 구현하기 위해 개발자들을 위한 전폭적인 지원이 다채롭다.

유래 없는 다양한 API 지원과 단순화된 SDK로 “개발이라고 보기 민망하다”는 농담까지 오갈 정도다. 그럼 윈도우7에서 펼칠 수 있는 여러분의 상상력은 어느 정도일까.

서명덕 smashhit@naver.com|세계일보 및 조선일보 등을 거쳐 주요 언론사에서 IT 업계 취재를 해왔다. 개발자들 사이에서는 ITView point 공동 편집자로 아이디 ‘떡이떡이’로 더 잘 알려져 있다. 한국MS의 데스크톱 익스피리언스 부문 MVP로 3년 째 활동하고 있다. 윈도우 클라이언트 OS 기술에 관심이 많다.

이제 개발자들은 사용자 경험과 콘텐츠 형태를 예단할 수 없다.

모든 윈도우 사용자들은 서로 연결되고 있다.

많은 사람들이 모바일 환경에서 콘텐츠 소비를 원하고 있을 뿐만 아니라, 자연 친화적인 인터페이스를 갈망하고 있다.

각종 미디어들의 그래픽 화면은 개발자들의 욕구를 자극한다. 성능과 유연성, 그리고 상호운용성 확보도 화두다.


왜 윈도우7인가 - 개발자들을 위한 장점들

결국 개발자들은 더 많은 시간과 리소스가 필요하고 다양한 예상 시나리오와 구현 모델을 고려해야 한다.

윈도우7 플랫폼과 윈도우7 API가 개발자들에게 매력적인 환경을 제공해줄 수 있을 것인가는 올 하반기 최대 이슈가 될 가능성이 높다.


HW 및 SW 호환성 강화

공식 자료에 따르면 윈도우7은 윈도우 비스타를 기반으로 한 업그레이드 플랫폼이다. 따라서 지난 3년의 과정을 거쳐 애플리케이션 호환성 문제를 해결해 왔다.

개발자는 프로그램 호환성 문제는 최소화하면서도 양쪽 환경에서 적절히 동작하도록 구현할 수 있다.

하드웨어 호환성도 개선됐다. 윈도우 비스타에서 동작하는 드라이버라면 사실상 윈도우7 환경에서도 문제가 없다.

MS는 윈도우7 기반 하드웨어 개발자를 위해 윈도우 드라이버 키트 3.0(Windows Driver Kit 3.0)을 마련, 개발에 필요한 빌드 환경, 도구, 문서 및 샘플을 제공한다.

PREfast를 사용해 특정 클래스의 C/C++ 코딩 오류를 검색할 수 있다.

파워쉘 및 인스톨러 업그레이드

윈도우 파워쉘 2.0(Windows PowerShell 2.0)은 일반 커맨드 라인과 그래픽 통합 스크립트 양쪽에서 사용할 수 있는 닷넷(.NET) 관리 스크립트 환경이다.

이를 통해 분기, 루프, 함수, 디버그, 예외 처리는 물론이고 국제화 기준에도 적합한 작업을 유지할 수 있다. 또한 윈도우 진단 기능, 액티브 디렉토리, IIS 등을 위한 기능도 대폭 강화됐다.

윈도우 인스톨러(Windows Installer)도 눈길을 끈다.

신형 인스톨러는 설치 패키지를 생성하기 위한 사용자 지정 코드 총량을 줄여 개발자들이 불필요한 작업을 최소화할 수 있도록 했다.

다중 패키지 트랜잭션 기능을 통해 설치 패키지 중에서 적절히 설치되지 않았던 패키지가 단 하나라도 있으면 설치가 되돌아가도록 했다.

이 밖에도 사용자마다 각각 다른 프로그램 파일을 설치하는 기능도 있으며, 개별 권한을 승격하는 기능 등 진정한 의미에서 사용자 단위의 설치가 가능해졌다는 평가다.


입맛대로 조절 가능한 보안

보안 기능은 윈도우 비스타에 이어 윈도우7에도 강조된 부분 중 하나다. 애플리케이션의 보안을 손쉽게 개선할 수 있고, 공격을 당했다 하더라도 피해를 최소화할 수 있다.

특히 윈도우 필터링 플랫폼이 강화되어 개발자들은 OS의 네트워킹 스택 패킷 처리부와 상호작용을 하는 애플리케이션을 생성할 수 있다.

개발자가 방화벽 기능을 보다 세밀하게 제어할 수 있으며, 방화벽 개발자는 윈도우 방화벽의 일부분을 선택적으로 유효 또는 무효화할 수 있다.

사용자 계정 콘트롤(UAC)은 윈도우 비스타에 이어 윈도우7에 적용된 대표적인 보안 구성요소다.

사용자 수준은 표준사용자와 관리자 두 가지가 있다.

애플리케이션 개발자는 이 기능을 이용해 일반 작업을 관리자 대신 표준사용자로 실행시킬 수 있다.

로컬 관리자 그룹에 속한 사용자 계정의 애플리케이션은 대부분 표준사용자로서 실행하게 된다.

소프트웨어 보호 영역에 대해서 사용자가 가지는 접근권한을 세밀하게 제어할 수 있다.

절전

절전 및 성능 향상은 윈도우 비스타에 비해 두드러지는 윈도우7의 장점이다. 퍼포먼스를 유지하면서도 하드웨어 에너지 효율 및 확장성을 극대화했다.


예를 들어 에너지 효율을 높이기 위해 OS의 백그라운드 활동을 줄이고, 시스템 서비스가 시작될 때 트리거를 새롭게 구현했다.

특정 서비스가 부팅에 반드시 필요한 것이 아니면 시작되어서는 안 되고, 특정 조건에서 동작토록 하는 트리거가 존재한다.

또한 특정 종류의 장치가 시스템 위에 존재하거나 접속했을 때만 서비스를 시작하도록 하거나 시스템이 윈도우 도메인에 있을 때만 서비스를 시작할 수 있도록 했다.

이 밖에도 윈도우7은 프로세서가 유휴 상태로 변하는 빈도와 시간을 최대한 많이 확보해 전력 소비를 억제하며, 네트워크 어댑터, 저장장치, 그래픽 카드 등 에너지 효율 기능이 있는 최신 기능을 반영했다.

이를 통해 MS는 절전모드를 부팅의 대체 수단으로 권장한다.


XPS 문서규약

문서와 문서 주변기기에 대한 지원도 개발자들이 눈여겨 볼만한 부분이다.

윈도우 비스타에서는 문서규약 및 저장을 위해 오픈 패키징 변환(Open Packaging Conventions)과 XML 문서 양식(XPS)이 구현됐다.

오픈 패키징 변환은 MS뿐만 아니라 경쟁사의 모든 오픈 패키징 변환 파일 형식을 지원하도록 한 것이다.

이는 ISO·ECMA에서 국제 표준으로 합의된 OOXML 규약이다.

특히 ZIP 파일 형식 기반이기 때문에 애플리케이션에서 다양한 데이터 항목을 단일 파일 패키지에 담을 수 있다.

개발자들은 윈도우7 패키징 API만 사용할 수 있으면 된다.

XPS 문서도 윈도우 비스타에 이어 윈도우7에서 크게 달라진 부분 중 하나다.

윈도우7에서는 애플리케이션 개발자가 XML 문서 규격의 생성에 대응하는 애플리케이션을 고안할 수 있다.

윈도우XP 등 구형 OS에서는 XPS를 이용하기 위한 Win32 API가 지원되지 않았다.

윈도우 비스타에서는 XPS가 처음 도입됐지만 API가 매니지드 코드를 사용한 닷넷 개발자로 한정됐었다.

윈도우7에서는 Win32 개발자가 더 쉽게 XPS를 다룰 수 있는 XPS 문서 API를 제공한다.

멀티터치, 제스처, 문자인식

일반 사용자들 사이에서도 관심거리인 멀티터치 API는 손가락의 움직임만으로 인간 친화적인 사용 환경을 구축할 수 있도록 했다.

윈도우 시리즈가 화면을 직접 만지는 ‘멀티터치’를 이용해 컴퓨터를 제어하는 것은 이번이 처음이다.

개발자를 위해서는 상위 레벨의 제스처 API와 하위 레벨의 터치 메시지 API 및 터치입력 API가 내장되어 있다.

또한 윈도우 주요 UI 역시 마우스 대신 손가락으로 선택하기 쉽도록 재설계됐다.

윈도우 탐색기나 IE8 등 주요 애플리케이션 역시 터치 사용 환경에 맞춰져 있다.

특히 터치와 제스처 기능이 강화되어 마우스 클릭이나 드래그로만으로 할 수 없었던 독특한 애플리케이션 제어를 정의할 수 있다.

개발자들은 멀티터치 API를 통해 확대·축소·회전 등 다양한 제스처를 기본 지원한다.

이 밖에도 윈도우7에 적용된 관성 API는 조작 API와 함께 물체 이동에 사용되는 물리적 관성을 시물레이션 해준다.

또한 확장된 터치 API를 이용하면 애플리케이션에 드래그 대신 패닝을 채택할 수 있다.

애플 아이폰과 마찬가지로 사용자가 손가락 끝을 살짝 움직이는 것만으로도 연속 동작이 가능하도록 설계할 수 있다는 의미다.

태블릿 PC를 위해 화면에 직접 쓰는 기능도 대폭 강화됐다.

자필 입력시 속도를 개선했고, 언어와 관계없이 개인화 및 사용자 지정 사전에 따라 정확도를 높였다.

이렇게 되면 한국어 등 동아시아 언어의 인식 기능이 획기적으로 향상된다. 수식인식 엔진(Math Recognizer) 기능을 통해 사용자는 애플리케이션에서 수식을 자필로 입력할 수 있다.

잉크 분석(Ink Analysis) API는 잉크 애플리케이션을 개발할 때 작업이 한층 쉬워진다. 하드웨어 환경이 급격히 진화하면서 이러한 API를 활용한 주변기기들도 잇달아 쏟아질 것이다.


작업표시줄, 점프리스트

데스크톱 사용 환경도 확 달라졌다. 아이콘 형태의 작업 표시줄은 윈도우7 시험판의 상징처럼 자리 잡았다.

마치 애플 맥 OSX 바탕화면의 독 기능을 연상케 하는 새 디자인은 일반 사용자들 사이에서 화제가 됐었다.

예를 들어 각 프로그램 단추들은 점프리스트 클릭 한번만으로 사용 빈도가 높은 작업에 한 번에 옮겨갈 수 있다.

점프리스트에는 애플리케이션에서 열리는 파일, URL, 사용자 지정 아이템 등이 표시된다.

점프리스트 메뉴에는 사용 빈도와 최종 접속 정보에 따라 자동적으로 항목이 표시되며, 개발자들은 독자적인 의미 체계에 따라 사용자 패턴에 최적화된 점프리스트를 제공할 수 있다.

이 밖에도 새 작업 표시줄은 애플리케이션의 진행상황 막대를 직접 표시할 수 있게 됐다.

파일의 복사, 다운로드, 설치 등 시간이 걸리는 작업을 일반 사용자들이 직관적으로 모니터링할 수 있도록 해준다.

또한 개발자들은 미리보기 API를 이용해 애플리케이션의 하위 작업창을 별도로 두는 방식으로 미리보기 이미지를 정의할 수 있다.

게다가 단순히 ‘미리보기’만 구현되는 것이 아니라 미리보기 창속의 도구막대에 미디어 재생·정지 등 활용 빈도가 높은 액션을 넣을 수 있다.

리본, 가젯

메뉴 개발도 쉬워졌다. 리본 인터페이스를 위한 컨트롤과 API를 이용하면 오피스 2007에서 선보인 UI를 애플리케이션 개발에 활용할 수 있다.

그 동안 개발자들을 괴롭혔던 천편일률적인 Win32 메뉴 UI에서 벗어나 마크업 기반의 UI와 고성능 네이티브 코드 런타임을 사용해 색다른 인터페이스를 구현하게 된다.

개발자들은 리본 컨트롤을 활용, 접근 빈도가 높은 기능에 최종 사용자가 직접 클릭할 수 있도록 해서 사용성을 높일 수 있다.

애니메이션 프레임워크 및 가젯 플랫폼 기능도 다채로워, 애플리케이션 개발시 고급 기능으로 채택·연동할 수 있다.

예를 들어 프로그램을 설치하거나 처음 실행할 때 OOBE(Out-Of-The-Box Experience)에 체크 박스를 하나 추가하는 것만으로도 최종 사용자들이 가젯을 설치하도록 유도할 수 있다.


라이브러리, 페더레이션 검색

윈도우7에서는 개발자들이 파일 및 데이터 관리 기능과 연동하기가 더 쉬워진다.

새 API를 통해 파일의 메타정보를 이용할 수 있고, 라이브러리 모델을 통해 독창적인 정보를 윈도우 탐색기에 전달할 수 있다.

‘라이브러리’란 사용자의 저장소 공간을 폴더보다 한층 더 추상화된 형태로 표현한 것이다.

한마디로 표현하면, 폴더에 대한 중앙 출입구라고 생각하면 쉽다. 정보가 집약된 가상 장소로서 개발자나 최종 사용자가 각종 미디어 데이터를 정리할 수 있다.

그러나 공간적인 경계는 없기 때문에 파일을 한 곳에 모아 둘 필요가 없다. 라이브러리 API를 사용하면, 라이브러리를 생성, 상호작용하는 애플리케이션을 쉽게 만들 수 있다.

윈도우 비스타에 이어 검색 기능이 강화된 것은 주목해야 할 부분이다. 윈도우7에서는 PC라는 경계선을 넘어 횡단으로 문서 자료를 검색(페더레이션 서치)할 수 있다.

개발자들은 윈도우7에서 검색되는 범위에 자체 검색엔진이나 문서 저장소(repository), 웹 애플리케이션, 독자적인 데이터 저장소 등을 넣을 수 있다.

이를 통해 사용자는 기업 인트라넷이나 웹으로부터 로컬 파일을 검색하는 것처럼 통합된 검색 결과를 도출할 수 있다.

다이렉트X 11

다이렉트X 11을 통한 고해상도 그래픽 구현도 윈도우7의 핵심 중 하나다.

윈도우 애플리케이션 개발자들은 하드웨어 가속 기능과 다이렉트X 기술을 통해 고급 3D 그래픽을 구현할 수 있었다.

다이렉트X는 지난 1995년 처음 발표된 후 발전을 거듭한 끝에 윈도우 비스타에서 애플리케이션이나 서비스에 GPU 리소스를 공유하는 윈도우 디스플레이 드라이버 모델(Windows Display Driver Model)을 도입했다.

데스크톱 윈도우 매니저(DWM)는 이 기술을 이용해 애플리케이션의 동적 작업을 도와주거나, 윈도우 에어로글래스 효과를 구현했다.

버전 11의 API에서는 신형 LCD 모니터에서 8 bpcc(bits per color component) 해상도로 콘텐츠를 표시할 수 있다.

이미지 처리 등 일반 연산에도 GPU 병렬처리를 사용하며, GDI 및 GDI+와도 상호운용을 할 수 있도록 설계됐다.

예를 들어 다이렉트X와 GDI를 모두 사용하여 렌더링을 시도하는 경우 DWM을 무효로 처리하지 않아도 자유롭게 양 쪽 기술을 사용할 수 있다.

다이렉트X의 새 구성요소인 다이렉트라이트(DirectWrite) API는 ‘모든 폰트를 모든 장소에서’ 사용 가능하게 하는 폰트 시스템이다.

GDI나 다이렉트2D 또는 애플리케이션 고유의 렌더링 기술을 사용한 고품질 클리어타입(ClearType) 텍스트 렌더링을 지원한다.

일반 사용자들이 글꼴들을 더 예쁘게 사용할 수 있다는 의미다.


미디어 파운데이션

윈도우 비스타에서 처음 도입된 미디어 파운데이션과 다이렉트 쇼(DirectShow) 기술의 변화도 크다. 특히 미디어 파운데이션의 경우 비디오 갈무리 장치나 하드웨어 코덱 지원을 비롯해, MPEG-4·H.264·MJPEG·MP3 코덱 등 지원되는 규격이 크게 늘어났다.

또한 다이렉트쇼와 미디어 파운데이션을 중개해주는 새 소스도 추가됐다. 이를 이용하면 미디어 파운데이션 대응 애플리케이션으로서 네이티브 환경에 대응하지 않는 기존 미디어 형식들을 재생할 수도 있다.

또한 윈도우 비스타에서 공개된 미디어 파운데이션 API보다 한층 더 나아가 C++ 기반 미디어 애플리케이션 제작을 손쉽게 하는 고급 수준의 API가 추가됐다.

예를 들어 비디오 및 오디오 재생을 위한 MFPlay, 미디어 파일 데이터 취득을 위한 Source Reader, 비디오 파일 재인코딩 등이 손쉬운 Sink Writer, 인코딩 시나리오 구현을 위한 Transcode 등이다.

센서 플랫폼

센서 플랫폼은 멀티터치와 함께 윈도우7 API 중에서 가장 흥미로운 영역이 아닌가 싶다.

특히 센서 플랫폼은 센서 장치의 검색과 통신에 필요한 API들을, 로케이션 플랫폼은 GPS 수신기 등의 서비스에서 얻은 위치 데이터를 이용하기 위한 API로 구성되어 있다.

윈도우7에서는 센서가 네이티브 수준에서 지원되어, 위치센서·광센서·온도계 등 각종 센서를 제어하기 위한 새로운 개발 플랫폼이 도입됐다.

윈도우 로케이션 API를 통해 개발자들은 사용자의 물리적인 위치 정보에 직접 접근할 수 있다.


브랜치캐시, 인터넷 익스플로러8

윈도우7에는 웹을 구현하기 위한 기술이 긴밀하게 녹아있다는 점도 주목할 만하다.

네트워크에 접속하거나 유지하는 과정이 쉬워지며, 네트워크 진단 정보 등을 애플리케이션 개발자들이 제어할 수 있다.

윈도우 웹 서비스는 SOAP의 네이티브 코드를 구현했다. 다양한 웹 서비스 프로토콜을 지원해 네트워크 통신이 가능하다.

특히 윈도우 클라이언트·서버의 네이티브 코드 웹 서비스를 C/C++로 구축할 수 있다. 또한 WCF(Windows Commun ication Foundation) 서비스와의 폭넓은 제휴가 가능하다.

윈도우 브랜치캐시(Windows BranchCache)를 통해 서버와 클라이언트 사이의 애플리케이션 응답이 강화됐다.

네트워크 교신과 지연을 줄일 수 있다는 의미다.

또한 윈도우7에는 인터넷 익스플로러8이 기본 탑재되어 있다.

EU 지역에 출시될 제품에는 IE8이 선택사양으로 바뀔 예정이지만, 여전히 IE는 윈도우 운영체제의 웹 관문 역할을 수행하고 있다.

이번에 바뀐 IE8은 웹 표준 및 상호운용성이 강조되어 개발자가 렌더링 모드를 페이지 단위로 선택할 수 있다.

또한 개발자 도구를 기본 내장하고 있어 웹 개발을 보다 빨리 진행할 수 있다.


윈도우7, 성공할 수 있을까

윈도우7 개발환경은 윈도우XP나 윈도우 비스타에 비해 장점이 많다.

그러나 윈도우7 개발 플랫폼에 대한 전망만큼이나 3년 만에 재기를 노리는 MS 클라이언트 OS가 시장에 안착할 수 있을 것인가에 관심이 쏠릴 것이다.

윈도우7이 성공하지 못한다면 개발 플랫폼으로서의 의미도 퇴색될 수밖에 없다.

새 플랫폼에 대한 우려는 크게 아톰 기반 저성능 넷북 제품군의 성공적 세대교체와 XP 호환성 위주로 고착화되어 있는 비즈니스 시장 진입이 가능할지 여부 두 가지로 나뉜다.

윈도우7은 넷북 기반의 테스트에서 성능이 어느 정도 검증된 상태다.

또한 윈도우XP 가상화 모드를 제공해 윈도우7에 호환되지 않는 구형 하드웨어를 보유했거나 구형 소프트웨어를 운용하는 기업들이 옮겨갈 길이 트였다.

다만 가상화 모드의 경우 가상화 기술을 지원하는 중앙처리장치를 사용해야 한다. 가격 경쟁력만 갖춘다면 윈도우7에서 윈도우XP로 다운그레이드하는 움직임은 크게 줄어들 것으로 보인다.

1만7,777달러 내건 윈도우7 개발자 행사

코드7콘테스트(Code7Contest, http://www.code7contest.com) 행사가 지난 7월 13일부터 공식 시작됐다.

MS 본사가 주최하는 이 행사는 윈도우7에 최적화된 애플리케이션을 개발하는 경진대회다.

이벤트에 참여하기 위해서는 윈도우7 네이티브 환경에서 MS가 제시한 윈도우7 주요 기술(Libraries, Windows Touch, Shell Integration, DirectX 11, Sensor and Location Platform) 중 일부를 사용해 독창적인 소프트웨어를 제작해야 한다.

단순한 사이드바 가젯이나 에어 애플리케이션은 참여할 수 없다.

결과물은 영어를 사용해야 하고, 일찍 제출하면 단계별로 추가 보너스도 주어진다.

미국, 유럽, 중국, 일본 등 전 세계 7개 지역에서 7개 결선 진출팀을 가린다.

최종 우승자에게는 1만7,777달러의 상금과 오는 11월 로스앤젤레스에서 개최되는 PDC 2009 행사에 무료 초청을 받게 된다.

예심 마감시한은 10월 10일이다.

참고자료

1. MSDN Windows 7 개발자 가이드 (2009년 1월)

2. Windows 7 RC Training Kit for Developers (2009년 6월)

3. Windows Developer Jumpstart Kit v 1.1 DVD

4. Developer for Windows 7 on MSDN

http://msdn.microsoft.com/en-us/windows/dd433113.aspx 

5. Windows 7 Application Compatibility

http://msdn.microsoft.com/en-us/windows/aa904987.aspx 

6. Windows7 API Code Pack for Microsoft .NET Framework

http://code.msdn.microsoft.com/WindowsAPICodePack

7. Windows7 for Developer Official Blog

http://windowsteamblog.com/blogs/developers/default.aspx

8. MSDN Inside Windows 7 - Introducing Libraries

http://msdn.microsoft.com/ko-kr/magazine/dd861346(en-us).aspx

9. MSDN Inside Windows 7 - Windows 7 Taskbar APIs

http://msdn.microsoft.com/ko-kr/magazine/dd942846(en-us).aspx

10. Engineering Windows 7 Blog (한글 번역)

http://blogs.msdn.com/e7kr/

11. Engineering Windows 7 Blog (영문)

http://blogs.msdn.com/e7

12. Windows on Channel 9

http://channel9.msdn.com/windows/

13. 한국MS 에반젤리스트 IT 팀블로그

http://blogs.msdn.com/eva


>>출처 | 아이마소





     windows7, 개발자, 다이렉트X11, 마소, 마이크로소프트웨어, 멀티터치, 아이마소, 월간마소, 윈7, 윈도우7
     0   
BlogIcon Case by Case 2009.09.17 18:23 신고
좋은 정보 얻고 갑니다.
출시는 언제쯤 될까요??
BlogIcon Mr.공돌이 2009.09.23 15:05 신고 
10월 22일인가 출시된다던데...

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

 

 

애자일 프랙티스의 실제 활용사례
+   [마이크로소프트웨어]   |  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 
으하하하하하하하하하하하
프로젝트보다 더 애자일 한 고객 요구사항이라니...
아이고 깰꾸닥!!!

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

 

<<이전 | 1 | 다음>>

열이아빠's Blog is powered by Daum