금일 2010년 2월 9일이 MSDN Subscription 을 통해 공개가 되었습니다. (미국 시간 2월 8일)

이전 Visual Studio 2010 Beta 2 에서 발생하는 가상 메모리와 성능 관련된 문제에 대해서 이번 RC(Release Candidate) 버전에서는 상당히 개선이 되었다는 인터넷 블로거들의 반응이 보입니다.

이미 Visual Studio 2010 RC 버전을 설치한 외국의 블로거의 말에 의하면, Microsoft 는 이런 문제를 해결하는 것에 대해 용기있고 현명함에 칭찬을 아끼지 않고 있네요. 필자 또한 이번 RC 버전에 대해 Microsoft 대한 찬사를 아끼지 않습니다.

일반적으로 RC(Release Candidate) 버전은 더 이상의 기능이나 사용자의 피드백의 반영이 없고, RC 에 안정성을 확보하여 RTM(Release to Manufacture) 버전으로 정식 제품이 공개가 됩니다. 이전의 Beta 버전을 설치하기 꺼려하셨던 분들도 크리티컬한 이슈가 해결된 RC 버전을 설치하셔서 미리 공부하시면 될 것 같습니다.

앞으로 다가오는 4월달 정식 제품이 더욱 기대가 되는 하루입니다. ^^

이올린에 북마크하기(0) 이올린에 추천하기(0)

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

※ 아래의 글은 필자의 경험과 필자 나름대로 분류하고 정리한 자료이므로 잘못된 부분은 조언 부탁드립니다. 그리고 필자의 개인적인 견해와 자료는 상업/비상업적인 용도로 인용할 수 없습니다.

얼마 전 UX 에 대해 이야기를 나눌 수 있는 기회가 생겼습니다. 그의 이야기를 정리하면 저 또한 아래와 같은 의문이 생기네요.

'같은 UX 일을 하는 사람끼리도 괴리감이 생긴다'    

그럼 이런 의문에서 출발해서 UX 에 대해 다시 한번 고민해 보고, 문제를 분석해 보도록 합시다.

UX 란 무엇인가?

많은 사람들은 UX 에 대해 많은 오해가 있는 것 같습니다. UX(User eXperience) 는 직역대로 "사용자 경험"을 향상하기 위함입니다. UX 는 바로 디자인(Design) 요소만의 추구가 아닌, 접근성, 편의성, 사용성 등의 구성 요소가 포함이 됩니다.

하지만, UX 를 접근하려고 시도하는 많은 UX 전문가는 이미 공통된 UX 라는 의미에서 이미 시작점을 잘 찍지 못하기도 합니다. UX 라는 단어는 이렇게 굉장히 많은 요소와 포괄적인 의미를 포함하고 있습니다. 즉, UX 와 관련된 전문적인 일을 하고 있지만, UX 전문가 사이에서도 굉장히 괴리감이 있다는 것입니다.

UX 의 잘못된 출발. RIA=UX ?

과연 RIA=UX 인가? 일부 실버라이트(Silverlight) 나 플래시(Flash) 와 관련된 일을 하고 계신다면, 충분히 오해의 소지가 발생할 수 있는 등호식입니다. 이와 유사하게 오해의 소지가 있는 것이 RIA=Silverlight 라는 것이죠. RIA 를 하기 위해서는 실버라이트 또는 플래시 등의 기술이 필요하다는 잘못된 관념을 가지고 있습니다.

다시 질문하자면 RIA(Rich Internet Application) 은 무엇인가.? RIA 를 묻는 다면 필자는 트랜드한 용어라고 하고 싶습니다. 이미 예전에 X-Internet 이라는 용어로 인터넷의 접근성, 사용성, 그리고 다양한 디바이스(Device) 를 확장시키기 위한 기술이며, Fat Application 또는 Thin Application 이라고 부르기도 하였습니다. 그리고 .NET 플랫폼의 기술로써 스마트클라이언트(Smartclient) 가 이러한 X-Internet 기술에 포함이 됩니다. 타 플랫폼에서는 X-Internet 기술로 투비소프트(Tobesoft) 의 마이플랫폼(MiFlatform) 과 어도비의 플랙스(Flex) 등이 있지요.

X-Internet 과 RIA 는 무엇이 다를까란 생각을 해보면, 그다지 다른게 없다는 것입니다. 이러한 용어는 시대적인 배경이 따른 것 뿐이지, 추구하고자 하는 목표와 이상은 큰 차이를 보이지 않습니다. 즉, X-Internet 은 기능적인 요소를 초점으로 마케팅했다는 것이고, RIA 는 UX 를 초점으로 마케팅했다는 것 뿐입니다. 새로운 기술을 대중에게 얘기할 때, 무엇을 1번으로 말하느냐는 그 시대와 그 시대의 시장에서 요구하는 것이 달랐다는 것을 알 수 있습니다.

하지만, X-Internet 의 시작은 좋았으나 유행을 일으키지는 못했습니다. 그 대안으로 실버라이트와 어도비(Adobe) 의 기술들은 RIA 와 UX 를 이용하여 마케팅을 함으로써 많은 사용자와 전문가 층에서 각광받고 있습니다. 하지만, X-Internet, RIA, UX 등 이미 범람하는 용어들 속에서 제대로 개념을 찾기란 참 힘들기도 합니다.

UX 는 개발과 디자인의 공통 영역?

특히 일부 UX 를 전문적으로 하시는 분의 말을 빌리면, UX 는 개발 영역과 디자인 영역의 공통 분모라고 말을 합니다. 하지만 정말 그럴까요? UX 를 하려면 개발과 다자인을 둘 다 알아야 하는 걸까요? 그리고 UX 를 하려면 개발과 디자인의 올바른 협업이 필요한 걸까요? 다시 한번 UX 에 대해 고민해 볼 필요가 있습니다.

하지만, 필자는 왼쪽 그림과 같은 말을 하는 것부터가 이미 잘못된 UX 개념에 사로잡힌 사람들이라고 말하고 싶습니다. (그렇다고 오른쪽이 정답이라는 말은 아닙니다) 다시 얘기하면, 개발과 디자인 영역간의 협업은 UX 를 수행하는 과정일 뿐이지, UX 자체가 개발과 디자인의 공통 분모가 될 수 없다는 것입니다. 거꾸로, 웹 디자이너가 웹 개발 프로젝트에 투입되었다면 어쩔 수 없이 개발자와 조율하고 협업하는 과정이 불가피 할 테니까요. 

결국, UX 는 너무도 많은 의미를 포괄하고 있고, 자신이 생각하는 UX 에 대해 시작점을 잘못 찍음으로써 UX 의 본질에 대해 다시 원점으로 돌아간다는 겁니다. RIA=UX, UX=RIA 라는 잘못된 개념은 결국 자신의 제한적인 생각의 범위와 제한적인 경험에서 나온 오해일 여지가 큽니다.

UX 가 개발과 디자인의 공통 영역이란 것은 좋은 UX 를 위한 과정일 뿐이지(필요할 수도, 필요 없을 수도), 절대 목표나 의미가 아니라는 의미입니다. 아마도 개발과 다지안의 공통 영역이란 것은 자신의 UX 는 그만큼의 범위 밖에 안된다는 의미겠지요?

일부 UX 세미나를 듣고 있자면, 마치 UX 전문가는 개발 영역과 디자인을 조율해야 하는 선도적이고, 개발 영역 기술까지 알아야 한다는, 다소 권위적인 얘기로까지 들리기도 합니다. 아마도 그런 UX 전문가는 XAML 과 Expression Blend 도구를 이용해서 디자인 해봤다는 말로만 들립니다. XAML(Extensible Application Markup Language) 이 프로그래밍적인 요소의 OOP 와 표현 요소인 Presentation 을 포함하는 기술이니, UX = XAML 로 혼돈하는 것이 아닐까란 생각도 듭니다.

UX 도 분석이 필요하다.

일단, 현재 통용되고 있는 UX 라는 의미가 너무 광범위합니다. 좀 더 UX 에 가까이 가기 위해 좀 더 분석이 필요할 것 같네요. 그렇다면 UX 를 좀 더 잘게 쪼개기 위해 우리가 실제로 겪을 수 있는 UX 로 나누어 봅시다.

Web Service UX
쟁점 : 데이터의 효율적 배치, 검색, 직관성
아마도 인터넷을 통해 가장 먼저 접할 수 있는 UX 일 것입니다. 공통된 관심을 집중할 수 있는 방법이나 데이터의 효율적인 배치와 검색 등이 관건일 것입니다. 더불어 서비스에 대해 사용자의 재방문을 유도하기 위해 사용자의 지속적인 좋은 콘텐트와 접근성이 가장 중요할 것입니다.    

Desktop UX
쟁점 : 안정성, 시스템 리소스의 가시성
컴퓨터의 전원을 켜기 시작하면서 경험할 수 있는 UX 입니다. 기본적으로 운영체제(OS) 가 포함이 될 것이고, 운영체제 안에서 돌아가는 브라우저나 보조 응용 프로그램 등, 모든 응용 프로그램이 이 범주에 포함이 될 것입니다.

Mobile UX
쟁점 : 단순함, 직관성, 데이터의 중요도 분리 및 표현
최근 아이폰(iPhone) 의 국내 발매로 불붙기 시작한 UX 입니다. 특히 단순하면서도 복잡하지 않는 UX 가 필요로 할 것입니다. 아마도 필자가 Windows Mobile 6.1 을 쓸 때의 느낌은, "이거 데스크탑 OS 와 비슷한데?" 라는 복잡함을 느꼈다면 적어도 필자에게는 좋은 Mobile UX 가 아니었다는 것입니다.   

RIA UX
쟁점 : 가볍고 빠른 응답성, 상호작용 향상, 표현력
최근 각광 받고 있는 UX 입니다. HTML 로 표현하기 힘은 콘텐트나 데이터, 그리고 화려함을 더해줄 수 있는, 진정한 Rich 함이 필요로 하는 UX 입니다. 잘 알고 있는 Microsoft 의 실버라이트(Silverlight) 와 Adboe 의 플래시(Flash) 가 대표적인 RIA 기술입니다.    

Surface UX
쟁점 : 제한된 입력장치로 사용자 접근성, 효율성
아직은 크게 주목 받고 있지는 않지만, 장차 큰 범주의 UX 가 될 것입니다. 제한적인 입력장치로 인해 특히 사용자의 사용성을 크게 고려해야 할 것입니다. 아마도 필자는 일부 Surface UX 를 경험하면서 '이게 누르는 버튼인건가?', '어떻게 쓰는 거지?' 라는 괴리감을 줄이는 것도 좋은 UX 가 될 수 있는 길일 것입니다.    

Enterprise UX
쟁점 : 데이터의 배치, 복잡성을 단순화할 방안, 데이터 표현의 표준적인 방안
아마도 좋은 UX 를 만들기 가장 힘든 환경이 아닐까 합니다. 특히 데이터 중심의 복잡한 환경에서 데이터를 어떻게 배치할 것인지, 특히 복잡성을 어떻게 줄일 것인지의 고민이 필요합니다. 그리고 데이터와 표현의 올바른 정의가 절실하기도 합니다.

올바른 UX 향상을 위하여

위의 여러 가지 UX 의 장르로 구분하였지만, 각각의 UX 는 독립적인 UX 는 아닙니다. 예를 들어, Web Service UX 를 향상하기 위해 RIA UX 가 필요할 수 도 있다는 것입니다. Enterprise UX 에서 복잡한 데이터를 단순화 하기 위해 RIA UX 가 필요한, 즉, 각 UX 는 각 장단점을 보완할 수 있는 UX 라는 겁니다.

아래는 각각의 UX 의 단점을 보완할 수 있는 예 입니다.

그리고 자신의 UX 장르가 무엇을 필요로 하냐는 것입니다. 즉, 각 UX 장르별로 무엇이 UX 를 떨어뜨리는 요인이 되냐는 것입니다. 그 문제의 요인을 제거하는 것이 근본적인 문제이며, 다른 장르의 UX 의 사례를 적용하여 UX 를 향상한다면 더할나위 없을 것입니다.

결론적으로, 현재 자신의 UX 위치를 잘 알고 그 UX 를 향상시키기 위해 무엇이 필요하냐는 것이 UX 향상의 쟁점이 될 것입니다. 필자 나름대로, Web Service UX, RIA UX, Enterprise UX 등으로 분류하였지만 자기 나름대로의 큰 범위의 UX 를 정립하기 위해서는 그것을 이루는 구성 요소를 정리, 정의해야만 올바른 UX 향상의 지름길이 될 것입니다.

개발자 출신인 필자도 개발에 필요한 구성 요소의 기반 기술의 이해가 부족할 때는, 스스로의 시야를 자신의 경험에 가려버렸던 적이 많습니다.

많은 UX 전문가에게도 말하고 싶은 것은, 당신이 실버라이트와 플래시를 해서 UX 디자이너, UX 전문가 인가요? 그렇다면 다시 묻겠습니다.

위의 물음에 자신만의 올바른 정의가 없다면, UX 가 아닌 당신은 단지 디자이너(Degisner) 일 뿐입니다. 저는 개발자를 분류하길 핵심 개발자(Core Dev), 일반 개발자(Dev) 로 분류합니다.  개발자인 필자의 눈에는 마찬가지로, UX 디자이너와 일반 디자이너 두 가지 밖에 없습니다. 

하지만 다행인 것은, 마치 .NET 기술이 처음 나왔을 때 처럼, UX 또한 아직 많은 정보를 접하기 힘든 황량한 사막과도 같다는 것입니다. 끊임 없는 고민과 노력은 분명 UX 성숙기 시대에 접어들 때, 빛을 발하리라 의심치 않습니다.

이올린에 북마크하기(0) 이올린에 추천하기(0)

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

이전 글
[Software Development/Agile] - [ALM-Test] 왜 단위 테스트를 해야 하는가? [1]


이미 이전 포스트에서 얘기 했듯이, 똑같은 "단위 테스트"라는 단어를 가지고 개발자, 테스터, 고객은 각자 그 의미를 전혀 다르게 생각하고 있습니다. 이런 단어의 해석 조차 각자 틀린데, 애자일(Agility)하게 어떻게 소프트웨어를 만들 수 있을까요. 이미 "단위 테스트" 라는 작은 주제를 가지고 벌써부터 고객과 개발 조직간의 불화음이 발생합니다.

아니, 이미 개발 팀 내부에서부터 어디서 부터 시작해야 할지 어디둥절 할 수 있습니다. 그렇다면 과연 "단위 테스트" 가 결함의 발생을 줄이는 약이 될지, 팀 간의 커뮤니케이션 장애를 발생시키는 독이 될지, 그것은 아마 이 글을 읽는 독자 분들의 실천에서부터 시작될 것입니다.

이렇게 말도 많고 탈도 많은 단위 테스트를 왜 꼭 해야 하는지부터 짚고 넘어가 봅니다. 단위 테스트는 기능 또는 단위 별로 결함을 조기에 발견하기 위한 테스트 방법입니다. 하지만 "단위 테스트" 라는 단어만으로는 그 이해는 너무나도 상이하게 틀리다는 것입니다.

• 개발자 - 단위 테스트 코드를 만드는 것
• 테스터 - 개발중인 웹 어플리케이션 또는 클라이언트 어플리케이션 등을 만져보면서 기능 결함을 발견 하는 것
• 고객 - 문서!! 기능에 대한 산출물 또는 보고서

일단 "단위 테스트" 에 대한 이해가 달라도 현재까지는 상관이 없습니다. 왜냐하면 단위 테스트가 가지는 의미를 제대로 이해하고, 공감대를 형성하는 것이지 어떻게 수행할 지는 적어도 지금은 중요하지 않습니다.

단위 테스트에 대해, 국내에는 번역본이 대부분이라 사실 우리 나라 실정에 정말 맞는지에 대해 많은 고민을 하였고, 적어도 필자는 이런 고민을 방관하고 싶지는 않습니다. "NO" 를 외치고 싶을 때는 외쳐야 하지 않겠습니까?

왜 버그가 발생하는가?

일반적으로 버그나 소프트웨어의 결함은 어떻게든 발생할 수 밖에 없습니다. 아무리 기계적이고 단순한 코드를 개발한다고 하더라도, 코드 간의 상호 연동, 클래스 간의 연동, 컴포넌트(Components) 간의 연동, 레이어(Layer) 간의 연동, 더 나아가 시스템 간의 연동.. 즉, 연동 또는 상호 종속적인 관계가 발생하는 시점부터 버그는 이미 예견될 수 밖에 없습니다. 쉽게 얘기하면, A 란 코드와 B 란 코드가 있습니다. 이 두 개의 코드는 분명히 다른 목적에 의해 개발이 되었지만, 목적 자체가 틀린 코드가 상호 연동 또는 종속적인 관계가 발생하게 된다면, 과연 어떨까요? 이것은 코드 자체에서 발생되는 결함이라기 보다 상호 연관 관계에 놓이면서 발생하는 결함이라고 볼 수 있습니다. 그리고 대부분의 중요한 또는 큰 버그는 이러한 얽히고 설키게 되는 연동/종속 이란 문제로 발생됩니다.

만약 버그가 발생되지 않는 상황이라도 A와 B 코드는 언제든지 업그레이드가 될 수 있습니다. 기능이 변경될 수 도 있고, 기능이 추가될 수 도 있습니다. 아무것도 모르는 최종 사용자(End user) 는 잘 되던 기능이 갑자기 안된다면 좀 어이없어 할 것입니다. 일부 이러한 코드가 최종 사용자의 요구에 의해, 그리고 최종 사용자를 위해 변경되지만, 최종 사용자는 결함을 발생시킨 원인을 알고 싶지도 않고, 단지 개발 팀을 신뢰할 수 없을 뿐입니다.

즉, 이러한 버그가 조기에 발견되지 않는다면 버그는 지속적으로 증식을 하게 됩니다. 가장 대표적인 예라면, 월별, 년별 정산해 주는 기능이겠죠. 이곳에서 만약 버그가 발생한다면 몇 일, 아니 몇 주를 이 버그를 해결하기 위해 많은 시간을 소비해야 할 것입니다. 실제로도 필자는 주변에서 이와 유사한 버그로 인해 고생하는 동료 개발자들을 많이 보아왔습니다. 결과적으로 모든 코드에는 버그가 발생할 가능성이 있고, 그것은 바로 연동/종속적인 관계가 시작되면서 집중적으로 발생하게 됩니다. 그리고 잠재적인 모든 코드가 버그의 대상이 되고, 잠재적인 버그가 가장 위험하다는 것입니다. 잠재적인 버그는 지금의 나도, 너도, 우리 모두가 모르는, 언제 발생할 지 모르는 버그이기 때문입니다.

이러한 주제로 필자는 이미 Techday 2009 에서 온라인 세미나를 한 적이 있습니다. 아래의 링크를 통해 간략한 단위 테스트 기술에 대해 미리 익히는 것도 좋습니다.

http://www.techdays.co.kr/Sessions/View.aspx?Id=40&mSeq=43

단위 테스트가 주는 의미

단위 테스트는 많은 곳에서 장점을 이야기 합니다. 예를 들어, "결함을 줄이고, 잠재적인 버그를 줄이고, 코드를 리팩토링 하게 하며…." 등등… 단위 테스트가 실제로 이러한 많은 장점이 있는 것은 필자 또한 강력하게 권장하고 싶습니다. 하지만, 아시다시피 "단위 테스트" 에 대해 개발자, 테스터, 고객과의 공감대가 형성되지 않은 이 마당에, 저런 소리를 하면 정말 비즈니스적인 가치가 있을까요? 아마도 고객은 단위 테스트를 한답시고 비용과 시간이 늘어난다는 것을 절대 용납하지 않을 것입니다.

그렇다면 단위 테스트가 우리에게 주는 의미는 무엇일까요? 단위 테스트를 형용할 수 있는 모든 단어를 떠올려 보십시오. 참 많습니다. 하지만 고객과 개발 조직, 그리고 비즈니스 측면에서 어떤 단어가 가장 잘 어울릴까요.

바로 단위 테스트는 "신뢰" 입니다. 개발 조직에서 개발자와 개발자간의 코드에 대한 신뢰! 개발 조직과 테스트 팀간의 신뢰! 그리고 단위 테스트의 결과는 매우 명확해서 고객과의 신뢰로 이어질 수 있습니다. 이러한 단위 테스트로 인해 장기적인 비용이나 리소스 절감 효과 등은 잠재적인 비즈니스적인 신뢰로 이어질 수도 있습니다. 만약, 개발 팀 내의 단위 테스트는 다른 개발자가 만든 코드와 연동해야 할 때 대한 최소한의 신뢰를 가지는 매우 신사적인 행위입니다.

즉, 개발자, 테스터, 고객과의 단위 테스트에 대한 이해가 틀리다고 하더라도, 최소한 단위 테스트라는 것을 했고, 그 결과가 명확했을 때 그 관계에서 "신뢰" 가 형성될 수 있습니다. 젊은 개발자가 아닌 고객은 자신의 과거의 경험에 빗대로 단위 테스트라는 것이 어떤 것인지 잘 모르더라도, 매번 명확하게 결과를 보여준다면 비록 버그가 발생하였더라도, 버그의 발생 시점이 명확하고 이 버그의 해결 결과 또한 명확하다면 "버그" 라는 단어로 절대 날뛰는 일은 없을 테니까요.

애자일(Agile) 한 팀 모델! 무엇이 문제인가...

자! 이제 단위 테스트에 대해 어느 정도 확신을 갖게 되었다면, 이것을 수행하기 위한 팀 모델이 필요합니다. 하지만 이러한 팀 모델을 구축하기 위한 시도는 매우 말이 많고 신중해야 할 부분입니다. 애자일을 도입하여 실패했다는 많은 히스토리와 사례들이 범람하면서 과연 애자일이 좋은 것일까라는 고민을 해 보아야 할 시기인 것입니다.

애자일이라고 하면 일반적으로 통용되는 XP(eXtreme Programming) 의 팀 모델과 스크럼(Scrum) 의 팀 모델은 현저하게 차이가 납니다. 그리고 글로벌 소프트웨어 개발 업체 중 단연 1위인 Microsoft 의 정보 기술 솔루션인 MSF(Microsoft Solution Framework) 의 팀 모델은 모두 다 다르다는 것입니다.

일단 현재 우리나라의 팀 모델의 특색은 매우 다양하고 변칙적이며, 상하 수직적인 관계입니다. 예를 들어, 개발자를 동일 선상의 개발자가 아닌 "대리급", "과장급", 일부 "부장급" 도 코딩을 하기도 합니다. 그리고 단순히 "개발 조직"이라는 단어 조차 어색하게 사수, 부사수 달랑 두 명이 개발을 하기도 합니다. 편의상 아래와 같은 형태가 되는군요. (이 부분은 조직마다 매우 다른 형태를 띌 수 있습니다)

어떤 모델에서는 개발자, 아키텍처, 테스터로 구분하지만 필자는 이러한 팀 모델이 전혀 한국적이지 않다고 생각합니다. 애자일과 MSF(Microsoft Solution Framework) 에서도 언급하지만 개발 팀에서는 우두머리, 즉 대장을 두지 말라고 조언합니다. 위의 그림에서 PL(Project Leader) 는 바로 개발 팀의 우두머리이며, 가장 테크니컬 하거나 경력, 또는 업무 도메인 지식이 뛰어나야 합니다. 그리고 한국형 조직이나 문화 특성상, 윗사람 또는 상사에게 코드나 아키텍처적인 문제를 언급하는 것은 매우 조직력이 부족한 사람으로 비추어지기도 합니다.

예를 들어, 한국의 개발자는 코드에 굉장히 민감하고, 곧 코드가 자신의 자존심이라고 생각하는 경향이 짙습니다. 적어도 필자 또한 마찬가지 입니다. 개발자는 자신의 사수에게 코드적인 문제를 언급한다면 충분히 문제의 소지가 발생할 수 있습니다. 데이터베이스 개발자일 경우 자신의 사수에서 SQL 쿼리에 대한 성능적인 문제를 지적한다면 자신의 부사수가 잘난 체 한다거나, "경력도 얼마 안되는 놈이 좀 안다고 까부네" 라고 생각하기도 합니다. 상사와의 관계가 아닌, 동등한 개발자 간에서도 다른 사람이 자신의 코드에 대해 지적하는 것은 '거의 인간 관계를 포기한 것'과 다름이 없다고 봐도 무리는 아닐 것입니다. (물론 어떻게 얘기를 잘 하느냐는 문제도 있겠지만요)

결론적으로 애자일 또는 MSF 가 언급한 팀 모델은 굉장히 이상적이지만, 전혀 우리나라의 특성을 적용하기가 힘이 들 수 있습니다. 위에서 예를 든, 단편적인 예만 봐도 애자일 또는 MSF 의 자유분방한 팀 모델은 우리나라 현실에 도입되기는 매우 힘이 듭니다. 작은 조직이라면 모를까, 거대한 엔터프라이즈 프로젝트의 경우 많은 점점 더 큰 팀과 또는 다른 업체와 함께 일을 하는 경우가 발생하기 때문에, 팀 내부가 아닌 팀 외부로 까지 애자일한 행위는 절대 금물입니다.

한국적인 애자일(Agile) 한 팀 모델

많은 사람들이 오해하는 것 중에 하나가 애자일의 XP 와 스크럼을 도입하기 위해 그것이 요구 또는 원칙, 권장하는 방법들을 반드시 따라야만 한다고 생각합니다. 이미 지난 포스트에서도 언급했듯이 고객은 명확한 일정을 요구하는 폭포수 모델(Waterfall Model) 을 요구하는데, 팀 내외부적으로 애자일(Agile) 을 외치고 있다가는 고객이 원하는 어떠한 일정과 조건에도 맞출 수가 없습니다. 우리는 이 시점에서, 애자일이라는 단어가 주는 의미를 다시 한번 상기해 볼 필요가 있습니다. 어떠한 애자일, MSF 에서도 그것을 반드시 이행하라고 명시하지 않습니다. 다만, '이렇게 이렇게 해보니 좋으니 너희들도 이런 방법을 써봐라' 라는 권장의 의미이지 강요가 아니라는 것입니다.

어쨌든, 개발자라고 하면 아래와 같이 두 가지 형태의 개발자가 있을 것입니다. 유지보수 인력인 SM(System Management) 이 있겠고, 개발 인력이 있습니다. 두 형태는 같은 개발은 하는 것이 맞지만, 깊은 내막은 전혀 다른 개발을 하고 있습니다. 일반적으로 개발 인력은 개발이 마치면 유지 보수 팀 또는 인력에게 인수가 됩니다. 그리고 인도적인 차원에서 각종 산출물을 뽑아내어 유지 보수 인력에게 모든 추후 버그나 추가적인 기능 개발이 떠넘겨지게 됩니다. 즉, 유지 보수 인력은 1년 365일 전산 시스템이 잘 운영되고, 지속적인 국가 정책이나 기업 정책, 그리고 고객의 요구를 시스템에 반영하는 역할을 하게 됩니다. 이 과정에서 일부 개발 인력이 유지 보수 인력으로 자연스럽게 전환되기도 합니다.

하지만, 좀 더 큰 기업에서는 개발 팀만해도 매우 복잡한 형태를 띄게 됩니다. 일단 내부 개발자, 외부 개발자가 분리가 되며 기업의 내부적인 정보를 공유할 수 있는 권한이 있느냐 없느냐로 볼 수 있습니다. 뭐 이러한 경우 사적인 자리에 까지 이어져, 점심을 함께 먹는 동료가 정해지기도 합니다. ^^; 외부 개발자는 일반적으로 프리랜서나 개인 사업자를 등록한 사람들이 됩니다. 하지만 대부분 프리랜서나 개인 사업자는 기업의 하청 업체를 통해 계약이 되는 경우다 더 많죠.

필자 또한 이러한 팀 모델과 현실과의 많은 고민을 하면서, 과연 어떠한 것이 한국적인 팀 모델이 될 것인가에 대한 고민을 끝없이 하고 있습니다. 마찬가지로, 필자가 좀 더 성숙해 지면 아래에 언급하는 팀 모델에 대한 생각이 바뀔 수 도 있습니다. 어쨌든 필자의 경험상 아래와 같이 팀 모델을 권장합니다.

위의 선은 직접적으로 커뮤니케이션 할 수 있는 범위입니다. 자세한 롤 모델(Role Model) 까지는 언급하지 않겠지만, 대충 커뮤니케이션의 통로와 작은 하위 팀을 보면 이해가 갈 것입니다. 특히 핵심 개발자 팀은 그 관리자나 일반 개발자와만 커뮤니케이션이 이루어지며, 이 핵심 개발자 팀은 외부 또는 타 업체가 될 수 도 있습니다. 일반 개발자에서 파생되는 여러 종류의 개발자는 모두 일반 개발자로 들어갑니다. 그리고 고객은 오직 관리자와 직접적으로 커뮤니케이션이 이루어지며, 경우에 따라서 품질 유지 팀에 의해 보고를 받을 수 도 있습니다. 애자일의 자유분방한 커뮤니케이션의 트랜잭션(Transaction) 을 넓은 범위에서 최소한으로 우리나라의 실정에 맞도록 줄이는 것이고, 관리자가 권한을 일부 위임해 주는 형태가 되는 것입니다.

또 하나, 필자가 애자일(Agile) 에 대해 공부를 시작하면서, 가장 답답했던 것이 바로 "고객의 자발적인 참여"를 기대한다는 것입니다. 일반적으로 개발 팀 입장에서 느끼는 고객은 굉장히 권위적이며, 상하 수직적인 관계입니다. 과연 애자일하게 프로젝트를 하면서 점진적인 릴리즈(Release) 를 통해 1달에 한번의 반복(Iteration) 으로 총 1년 동안 12번의 반복을 통해 점진적으로 최종 릴리즈에 도달한다고 가정해 봅시다. 이 릴리즈마다 고객의 자발적인 참여와 의견을 교류하는 이상을 생각하며, 첫 번째 릴리즈를 보여줬을 때, 과연 고객은 소프트웨어 개선을 위해 적극적인 참여를 할까 아니면 "내가 원하는 소프트웨어는 이게 아닌데?" 라고 할까요.

과연 그렇다면 여러분은 애자일의 의미에 대해 고객에게 세미나를 할 것인가요, 아니면 어떻게든 설득을 할 것인가요? 이미 고객의 경향을 알고 있는데, 그러한 고객을 설득하고 이해시키는 계몽(啓蒙)을 할 수 있을지 의문입니다. 그렇다면 이미 답은 나왔습니다. 고객을 변화시키지 못할 바엔, 차라리 우리가 변하는 것입니다. 즉, 개발 조직 내에서 불필요한 소음을 줄이기 위해, 어디에서 문제가 발생하는지, 그리고 소통이 어떻게 이루어지는지에 대한 트랜잭션(Transaction) 에 대한 관찰이 필요하다는 것입니다.

그리고 위의 그림과 같이 필자는 최종적인 트랜잭션의 소통이 현재 한국적인 가장 이상적인 애자일이 아닐까 생각합니다.

각 역할 별로 간단히 정리하자면, 아래와 같은 마음 가짐과 자세가 필요하겠군요. 물론 모든 조건을 완벽하게 갖추기보다는 최소한의 자세와 지식이 갖는 것이 유리할 듯 합니다. 자신이 부족한 부분이 있다면, 팀 동료가 이것을 뒷받침 해 주어야 겠지요. (유지 보수 팀은 복잡성을 줄이기 위해 여기에서 제외합니다)

품질 좋은 소프트웨어를 위한 단위 테스트

필자가 단위 테스트에 대한 필요성을 얘기하다가 뜬금없이 버그와 팀 모델에 대해서 이야기 하는 것이 의문일 수 있을 것입니다. 하지만 이 내용 또한 이전 포스트에서 이야기 했듯이, 소프트웨어 품질이 떨어지는 것에 대해 어느 누구에게 몰빵(?)할 수도 없는 문제이며, 단위 테스트에 대한 공감대가 없다면 절대 할 수 없는 것이기 때문입니다. 애자일이 우리에게 많은 자율성(Autonomy) 와 타이트함(Tightly) 를 주는 것은 매우 환영할 일이지만, 일부 정책적인 강제가 없다면 애자일은 우리나라에서 이미 실패한 방법론 또는 프로세스일 뿐입니다. 왜냐하면 우리나라의 고객은 아직까지는 변하지 않을 테니까요.

어쨌든, 단위 테스트를 위한 팀 모델의 세팅을 이쯤에서 마칩니다.

이올린에 북마크하기(0) 이올린에 추천하기(0)

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.