본 원고는 월간 마이크로소프트 2010년 3월호에 기고한 원문입니다.

Visual Studio 2010을 활용한 ALM(Application Lifecycle Management)

작성자: 엄준일 선임/ Microsoft MVP

감수자:안재우 수석/Microsoft MVP

ALM(Application Lifecycle Management) 의 개요

최근 몇 해 사이에 ALM(Application Lifecycle Management)라는 용어를 자주 듣게 되었고, ALM에 대해 논의를 하게 되고, ALM 을 해야 한다라는 말을 자주 듣게 됩니다. 최근 들어, 실제로 많은 기업이나 조직에서 ALM 도입을 검토하고 있고, 왜 ALM에 대해 열광하는지에 대해서도 궁금한 부분이 아닐 수 없습니다. 그렇다면 우리는 이제 ALM이 무엇이고, 왜 등장하였으며, ALM에 대한 오해와 진실에 대해서 충분히 이야기를 나눌 가치가 있다고 생각합니다.

ALM 이란?

ALM(Application Lifecycle Management, 이하 ALM)을 한글로 번역하면 "응용프로그램 수명주기 관리" 라고 합니다. 현대 사회는 문화, 언어, 가치관, 기술 등이 빠르게 발전하고 있습니다. 문명의 발전이 없다면 죽은 문명이고, 마찬가지로 소프트웨어가 변화하고 발전하지 않으면 죽은 소프트웨어나 마찬가지 입니다. ALM 을 쉽게 말하면 바로 이런 소프트웨어가 생산되고 릴리즈, 유지, 관리하기 위한 기술을 총칭합니다.

ALM 등장배경

예전부터 소프트웨어를 개발하는 방법이 꾸준히 연구되었으며, 그 중 가장 대표적인 방식이 SDLC(Software Development Lifecycle) 입니다.

SDLC 의 대표적인 개발 방법론 중에 폭포수 모델(Waterfall Model)이 있는데, 로이스(Royce) 라는 사람에 의해 정의된 폭포수 모델은 요구사항, 디자인, 구현, 통합, 테스트, 릴리즈, 유지보수라는 단계로 구분이 되며, 각 단계는 순차적으로 진행되게 됩니다. 요구 사항이 없으면, 디자인을 할 수 없고, 디자인을 하지 않으면 구현을 할 수 없는 형태의 개발 방법으로 현 단계에 문제나 오류가 발생하게 반드시 위험 요소를 제거한 후에 다음 단계로 이동하게 됩니다. 이러한 개발 방법은 각 단계별로 상하 연관성이 없고 명확하게 구분되어 있으며, 최근에도 이러한 개발 방법으로 많은 프로젝트가 진행됩니다.

그림 1 일반적인 폭포수(Waterfall) 모델

하지만 최근 이러한 Top-Down 방식의 수직적인 개발 방식에 많은 비판을 받고 있습니다. 초기 계획이 완벽하지 않으면 전체 일정 또는 계획이 완벽하지 않다는 의미이기 때문입니다. 고객도 자신의 정확한 요구 사항을 알지 못합니다. 이런 과정에서 프로토타입(Prototype) 을 고객에게 시연하고 고객의 정확한 요구 사항을 도출해야 합니다. 하지만 고객의 요구 사항은 언제나 변할 수 있습니다. 즉, 완벽한 요구 사항을 정의한 후에, 다음 단계로 넘어간 이후에도 고객의 요구 사항은 변할 수 있고, 그렇다면 어찌되었건 초기 계획이 잘못될 수 밖에 없습니다. 이미 구현과 테스트로 검증이 끝난 기능에도 기능적인 기능의 추가 및 변경, 디자인 요소의 변경 등을 이유로 고객의 요구 사항은 변할 수 있고, 그렇다면 다시 원점으로 돌아가 이전의 계획은 수정이 되어야 하며, 이미 이러한 경우는 최초 계획이 잘못되었다고 생각할 수 밖에 없습니다.

그 이외에도 초기 계획을 얼마나 정확하게 수립할 것인지는 굉장히 민감한 문제이기도 합니다. 초기 계획 단계를 지나치게 명확하게 강조할 경우 그만큼의 비용이나 시간이 추가되는데, 전체 프로젝트의 일정과 대비하여 그것이 지나칠 경우 실제로 구현이나 테스트를 해야 할 시간은 촉박해 질 수 밖에 없습니다. 프로젝트의 기간은 6개월인데 정확한 프로젝트의 계획 수립을 위해 3개월의 시간을 소비한다면 분명 구현이나 테스트를 여유 있게 할 수 없을 것입니다. 고객을 이해시킬 수 있는 신뢰된 계획안을 보여줄 수 있겠지만, 오히려 불필요한 문서의 양산할 수 있을 가능성이 충분합니다. 이런 경우 프로젝트의 단계별로 거꾸로 기간을 산정하는 역산법 등을 이용하기도 합니다.

폭포수 모델(Waterfall Model)은 여러 가지의 문제 제기를 통해 다양하게 변형된 모델로 발전해 왔습니다. 여기에서는 설명하지 않을 예정이지만, 소프트웨어 개발 방법론은 여러 가지 변형된 형태로 발전해왔음을 알 수 있습니다.

• Spiral model
• Iterative and incremental development
• Iterfall development
• V-Model
• Agile software development

그렇다면, ALM 의 등장 배경을 얘기 하기 위해 왜 이렇게 긴 SDLC(Software Development Lifecycle) 이야기를 했을까요? 위의 이야기에서 볼 때 SDLC 는 바로 소프트웨어를 개발하기 위한 방법론이라는 것입니다. SDLC 는 소프트웨어 공학에서 정의하는 용어로써, 소프트웨어를 효과적으로 개발하기 위한 다양한 방법을 이야기 한다는 것입니다. 즉, SDLC 은 소프트웨어를 개발하는 기술적인 관점을 이야기 합니다.

ALM 은 바로 소프트웨어를 개발하기 위한 기술적인 관점과 더불어 비즈니스적인 가치를 융합하도록 합니다. 소프트웨어의 개발은 기술적이거나 방법적인 문제와 더불어, 실제로 조직 간의 이해 관계, 그리고 비즈니즈 관계의 영역까지 확대됩니다. 소프트웨어를 개발하기 위해 프로젝트의 비전이나 목표 그리고 이것을 이행하기 위한 여러 방법론적인 단계는 통합되고 유기적인 관계입니다. 단지 기술적인 관점에서 바라보는 것이 아닌, 비즈니스 관점에서의 이해 관계나 조직의 측면도 ALM 에서 포괄하고 있습니다.

그렇다면 ALM 은 전혀 새로운 기술이 아님을 알 수 있습니다. ALM 은 이미 오래 전부터 조직적으로 알게 모르게 수행하였고, ALM 을 수행하기 위해서는 어떠한 프로세스적인 요소를 강제하고 있었습니다. 마치 군대에서 기상->아침 구보->보고(점호)->아침 식사-> … -> 저녁 식사->청소->보고(점호)->취침 과 같이 매일 반복되는 프로세스와도 유사할 수 있습니다. 그리고 이런 프로세스가 잘 진행되는지의 여부를 알기 위해 상사에게 "보고" 하는데 소프트웨어 개발 측면에서는 각종 산출물이나 보고서가 필요합니다. 그리고 병사들이 야간 근무를 교대하고 활동을 추적하기 위해 교대 시간마다 기록을 하게 됩니다.

표 1 ALM 의 3대 구성 요소

하지만, 이러한 일련의 통일되고 융합된 활동을 한다는 것은 쉽지 않습니다. 문서화나 정형화된 프로세스조차 없는 팀이나 조직이 있는 경우도 있고, 암묵적인 프로세스가 존재하지만 어쨌든 이런 프로세스를 강요한다는 것은 쉽지 않습니다. 또한 팀의 매니저 또는 PM(Project Manager) 나 그 위의 상부 조직은 일이 잘 진행되는지 궁금해 하기 때문에, 이러한 이유로 개발자는 팀장 또는 상사에게 일일 보고서나 주간 보고서를 작성하고, 이것을 다시 취합하여 최종 보고서로 작성합니다. 프로젝트의 단계가 진행될수록 보고서의 양은 늘어나고, 그 종류도 다양해질 것입니다. 어찌 보면, 프로젝트를 위한 프로젝트가 아닌, 보고서를 위한 프로젝트가 되어버리는 셈입니다.

이젠 활동이나 작업을 추적하는 것도 어려울 것입니다. 수십 수백의 여러 가지 종류의 보고서는 이제 버전 관리 하기 조차 버거워질 수 있습니다. 또한 각 역할 담당자들은 결과물, 인도적 차원, 유지보수 차원에서 다양한 산출물을 양산해 냅니다. 필요에 의해 과거의 산출물을 찾는 것도 어렵고, 산출물 자체를 유지 보수 하는 것도 어려워 집니다. 그 외에도 변화하는 모든 활동들은 어떻게 변화했는지조차 알 길이 없습니다. 다양한 산출물과 활동, 그리고 변화에 대한 추적이 불가능 하다면 이미 양산된 문서를 관리하는 것은 결국 의미 없는 활동일 수 있습니다. 실제로 컨설팅 의뢰로 기업을 방문하여 문제를 진단하기 위해 몇 가지 산출물을 요청하여 받은 적이 있으나, 아키텍처가 실제 시스템과 너무 달랐고, 언제, 어떻게 달라졌는지 아는 사람은 아무도 없었던 적도 다반사이기도 합니다.

ALM 의 3대 구성 요소를 조직 전반적으로 융합하기 위해서는 ALM 솔루션이 필요합니다. 관리가 어렵고 정확성을 요구하는 ALM 을 좀 더 쉽게 실현할 수 있는 도구가 필요하다는 것입니다. 초기의 ALM 은 마케팅적인 용어로 사용되면서 초기 ALM 솔루션도 매우 난해했습니다. 단순히 이슈 추적 기능과 소스 제어 기능을 합하여 ALM 이라고 하였으며, 어떤 ALM 솔루션은 테스팅 도구만을 통합하여 ALM 솔루션이라고 하기도 하였습니다.

그림 2 ALM 의 전체적인 컨셉

최근에 ALM 이 정착하는 단계에 들어서면서, 현재의 ALM 과 미래의 ALM 을 분류하기도 합니다. 그리고 아직 이러한 분류 단계는 미성숙한 단계이므로 여러 방면으로 각기 해석을 하고 있습니다. 내용을 정리해 보면 아래와 같이 요약할 수 있습니다.

표 2 ALM 의 단계별 정의

위의 내용으로 볼 때, 앞으로 알아볼 Visual Studio 2010 과 Team Foundation Server 2010 은 이미 ALM 2.0 에 매우 근접해 있습니다. 기본적인 ALM 1.0 요소를 충분히 충족하고 있으며, 각 제품은 확장성이 뛰어나고 다양한 클라이언트를 지원하기 위한 크로스 플랫폼을 실현하였습니다.

ALM 의 오해와 진실

ALM 은 아직까지도 많은 오해와 진실 속에 자주 언급되는 용어입니다. 사실 ALM 을 알고 보면 SDLC(Software Development Lifecycle) 처럼 정형화된 어떤 유형의, 또는 무형의 지식으로 갑자기 나타난 기술이 아닙니다. 그리고 무언가를 해결하기 위한 완벽한 솔루션도 아닙니다. 아직도 마치 ALM 에 대해 뜬 구름 잡는 듯한 느낌이 든다면 아래의 몇 가지 질문 답변 형식으로 좀 더 ALM 에 대해 오해와 진실을 이야기 해보도록 하겠습니다.

Q: 그럼 도대체 ALM 은 무엇인가요?

A: 마치 Web 1.0 과 Web 2.0 을 비교하는 것과 같습니다. 기존 Web 1.0 은 기업이나 서비스 제공자에 의해 제공되고 그 주체가 바로 기업이나 서비스 제공자였습니다. 하지만 Web 2.0 의 컨셉은 개방, 협력, 참여, 공유라는 요소를 중심으로 차츰 주체가 사용자에게로 이동하는 트랜드화된 용어이기도 합니다. Web 2.0 의 대표적인 것이 바로 UCC 나 위키피디아(Wikipedia) 와 같은 것들이 있습니다.

ALM 도 이런 트랜드에 크게 벗어나지 않는 용어입니다 ALM 은 궁극적으로 3대 구성 요소를 쉽게 실현할 수 있도록 하였지만, 이것을 실현하기 위해 설계, 개발, 테스트, 유지 보수 등 개발 조직, 운영 조직, 비즈니스 조직 등 여러 조직간에 의사 소통이나 각 단계별로 독립적인 활동을 유기적으로 통합하고 신뢰할 수 있는 데이터를 제공할 수 있도록 ALM 솔루션은 여러 가지 도구와 연동하거나 통합하고 자동화하였습니다.

최종 소프트웨어를 사용할 고객은 품질 좋은 소프트웨어를 사용하길 기대합니다. 요구 사항, 아키텍처, 개발, 테스트, 릴리즈, 유지 및 관리, 추적 등 모든 과정을 ALM 솔루션 안에서 이루어 집니다. 이후에 설명한 Visual Studio 2010 과 Team Foundation Server 2010 을 이용하여 개발 프로세스가 어떻게 개선되고 편리해지며, 어떻게 ALM 을 실현하는지에 대해 천천히 짚고 넘어갈 예정입니다.

Q: 그럼 ALM 을 실현하려면 ALM 솔루션이 필요한가요?
A: 아닙니다. ALM 을 실현하기 위해서 반드시 ALM 솔루션이 필요하지 않습니다. 위에서 군대를 예로 든 ALM 의 3대 구성 요소를 설명한 바 있습니다.

실제로 여러 프로젝트를 경험하면서 ALM 과 유사한 경험을 많이 해 보았을 것입니다. UML 도구를 사용하고 엑셀로 요구 사항이나 개발 진행 관리, 그리고 엑셀의 함수나 스크립트를 이용하여 보고서를 만들고, 테스트와 테스트 문서 및 코드 리뷰 과정을 수동적으로 한 바 있습니다. 사실 관리적인 부분만 본다면 엑셀만큼 뛰어난 도구도 없을 것입니다.

하지만 실제로 수동적인 ALM 실현은 많은 어려움이 따릅니다. 가장 먼저 문서를 매번 업데이트해야 하는 시간적인 문제와 문서의 버저닝(Versioning), 변화에 따른 계획의 수정 및 문서 수정, 테스트를 위한 테스트 케이스 관리 및 테스트 결과 문서화, 그리고 수동적인 코드 리뷰는 사실상 있으나 마나 한 단계이기도 합니다. 특히 반복적인 짧은 릴리즈는 밤을 새게 하는 주요 원인 중의 하나이기도 합니다. 릴리즈 계획도 문제였지만, 버그의 발생은 곧바로 버그의 상황을 문서로 만들어져야 하는 산출물이 되기도 하기 때문입니다.

분명 ALM 솔루션은 여러 가지 어려웠던 요소들을 통합하고 자동화하였습니다. 결과적으로 ALM 은 도구가 없이도 가능하지만, 실현하기 위해서 훨씬 많은 노력이 필요하다는 것입니다.

Q: 우리 팀은 형상 관리(소스 제어) 만으로도 프로젝트가 잘 됩니다. 과연 ALM 솔루션이 필요한가요?

A: 맞습니다. 현재 자신의 팀이나 조직에서 정형화된 프로세스나 암묵적인 프로세스가 존재하고, 개별적인 문서 관리와 소스 제어만으로 ALM 을 실현할 수 있습니다. 그렇다면 현재 자신의 조직이나 팀은 ALM 레벨은 ALM 0.5 세대에 있다고 보시면 됩니다.

소프트웨어의 품질을 높이기 위해서는 많은 노력이 필요합니다. 소스 코드나 문서의 버전 관리, 테스트, 보고서, 빌드, 이슈나 작업의 추적은 한 두 명의 개인이 수행하기는 매우 힘듭니다. 그렇기 때문에 보다 도구를 통합하고 자동화된 솔루션을 통해 ALM 을 수행한다면 훨씬 많은 이점이 있습니다.

Q: 그럼 ALM 을 원활하게 수행하기 위해서는 통합된 ALM 솔루션이 필요한가요?

A: 그렇지 않습니다. 현재 소프트웨어를 개발에 필요한 많은 도구들이 오픈 소스 또는 무료로 제공이 되고 있습니다.

아래는 오픈 소스 중에 .NET 환경에서 사용할 수 있는 도구들을 정리한 표입니다.

표 3 Team Foundation Server 와 오픈 소스 기반의 도구를 통한 ALM 도구 비교

하지만 오픈 소스를 사용하는 것은 저렴하게 ALM 환경을 갖출 수 있지만, 이음매 없는 매끈한 끈과도 같습니다. 도구들 간에 서로 연관성이 없거나 업그레이드가 되지 않는 것들도 상당히 존재하기 때문입니다. 통합되지 않은 각 도구들은 누가 관리를 할 것이며, 연관성이 없는 각 도구들 간의 프로세스를 어떻게 강요할 것인가도 고민해 보아야 할 부분입니다.

안녕하세요. Visual Studio 2010 팀입니다.
이제 다가오는 2010년 4월 12일은 Visual Studio 2010 정식 버전이 출시되는 날입니다.
이에 맞추어 저희 팀과 함께 활동하실 에너지 충만한 분들을 모집하고자 합니다.

지원 분야

• Visual Studio 2010
• .NET Framework 4.0
• Cloud Development
• Parallel Development
• Web Development
• Windows 7 Development
• RIA Development
• Architecture Development
• Agile Development
• Office Business Application Development
• Team Foundation
• Windows Mobile 7
• User Experience (UX)
• 기타 .NET 과 관련된 모든 분야

활동 영역

온라인 활동 영역

오프라인 활동 영역

지원 방법

umc골벵이dotnetxpert.com 으로 아래의 양식으로 메일 보내주세요.

Intro

안녕하세요. MFC 카테고리의 꽃집총각입니다.

앞으로 한동안은 멀티터치에 관한 포스팅을 올리려고 합니다. 지난주에 올렸던 사람이 기계와 만나는 진정한 방법 – 멀티터치 편에서는 멀티터치에 대한 개념적인 부분과 비전에 대해 설명 드린바 있습니다. 오늘은 본격적인 프로그래밍 방법에 대해 알아보기 전에 마지막으로 한가지 더 이야기해야 할 내용이 남았습니다. 바로 멀티터치 개발환경 구축에 관한 이야기 입니다 :)

일단은 당연한 말이지만 윈도우 7 운영체제가 필요합니다. 그리고 개발환경인 Visual Studio와, 멀티터치 입력이 가능한 하드웨어가 필요합니다. 오늘은 이 세 개의 준비물에 대해 각각 알아보도록 하겠습니다.

첫 번째 준비물 : Microsoft WIndows 7 ®

가장 당연한 첫 번째 준비물은 윈도우 7 운영체제 입니다. 윈도우 7은 기본적으로 멀티터치 입력에 대한 준비를 모두 마치고 태어난 녀석입니다. 터치 입력을 통해서 가벼운 엔터테인 수준의 컴퓨팅은 키보드와 마우스 없이도 모두 해결할 수 있습니다. 하지만 우리 블로그는 윈도우 7을 소개하는 자리가 아니니 여기서 길게 설명하지는 않겠습니다 ^^; 검색을 통해 손쉽게 윈도우 7의 터치 인식 환경에 대한 정보를 얻으실 수 있습니다.

위에 보이는 스크린샷은 윈도우7의 제어판에 기본적으로 들어있는 ‘펜 및 터치’ 항목입니다. 터치 입력에 대한 설정들을 제어하는 곳이지요. 근데, 윈도우 7을 여태 몇 달이나 사용 중이지만 저런 항목은 제어판에서 보신적이 없으신가요? 그렇다면 아마 현재 사용하시는 PC 혹은 노트북이 터치 인식을 지원하지 않기 때문 일겁니다 ㅜㅠ… 이 부분은 좀 있다 하드웨어를 이야기 할 때 다시 말씀 드리도록 하겠습니다.

다만 윈도우7의 터치 인식 지원에 대해 혼동하기 쉬운 점은 ‘멀티터치’의 인식이라는 점입니다. 비스타나 윈도우 XP도 타블렛 PC에 설치하면 터치로 조작할 수 있습니다. 하지만 그저 마우스 커서를 손으로 조작할 뿐이지요(싱글터치). 나중에 이야기 되겠지만 윈도우7의 멀티터치는 WM_MOUSE… 계열의 마우스 메세지를 처리하는 게 아니라 WM_GESTURE / WM_TOUCH라는 새로운 윈도우 메세지를 통해 처리됩니다. 이들 메세지는 윈도우7에서 새롭게 제공되는 메세지이며, 이전 OS에서는 당연한 말이지만 발생하지 않습니다. 저런… 안타까워라!

두 번째 준비물 : VIsual Studio 2010

두 번째 준비물은 통합 개발환경인 Visual Studio 입니다. 며칠 뒤 정식 출시될 vs2010이 있다면 추가적인 다른 준비 없이 바로 터치 프로그래밍을 할 수 있습니다. 하지만 꼭 vs2010에서만 가능한 것은 아닙니다. vs2005 / 2008 등 이전 버전에서도 터치 프로그래밍을 해 볼 수 있습니다. 단, 이 때는 별도로 Windows 7 SDK를 다운받아서 설치해 주어야 합니다.
그러니 사실 멀티터치 프로그래밍을 하는 데에는 어느 버전의 비주얼 스튜디오라도 굳이 상관은 없는 셈이지요. 하지만 vs2010 블로그인 만큼 vs2010을 기준으로 강의를 진행하겠습니다. 여러분들도 vs2010을 사용하시겠다고 한다면 Windows 7 SDK를 반드시 깔아야 할 필요는 없습니다. 하지만 이 SDK 에는 제공되는 API들을 이용한 프로그래밍 샘플 코드들도 함께 포함되어 있는데, 이중에는 몇 개의 멀티터치 예제도 들어있습니다. 샘플을 먼저 구동해 확인해 보고 싶으신 분들은 SDK를 설치해 보시는 것도 좋을 거라는 생각이 듭니다.

세 번째 준비물 : 멀티터치 인식 하드웨어

자, 아마도 제 생각엔 가장 많은 이들의 원성을 살 세 번째 준비물, 하드웨어에 대해 이야기해 볼 시간입니다. 터치 디바이스는 점차 꾸준히 보급되고 결국은 일반화 될 테지만(아… 혹시 뭐 안될 수도 있겠지만요! ㅎ), 아직은 초기단계이기 때문에 이 글을 보시는 대다수의 프로그래머 분들은 터치 디바이스를 보유하고 있지 않으실 거라는 생각이 듭니다. 사실은 당장 저만 같아도 터치를 인식하는 시스템을 아직 장만하지 못했답니다 ㅜㅠ …

하지만 우선 아쉬운 대로 이를 보완할 차선책이 있습니다. 마우스를 가지고 터치 입력을 시뮬레이션 해주는 방법이 있거든요. 재미있는 점은 마우스를 여러 개 연결하면 연결하는 만큼 독립적인 터치로 인식하게 해주기 때문에, 멀티터치 입력도 시뮬레이션 해볼 수가 있답니다. 책상 서랍 안에 잠자고 있는 마우스가 있다면 지금 얼른 꺼내세요! 그리고 이제 양손으로 마우스를 붙잡고 신기한 체험을 해 볼 시간입니다! “내 PC는 안될거야…”라는 패배의식을 한 방에 날려버릴 방법을 지금 소개해 드립니다 ^^

codeplex에 가보면 Multi-Touch Vista라는 프로젝트가 있습니다. ( http://multitouchvista.codeplex.com/ ) 윈도우 7이 아닌 비스타에서도 멀티터치 인식이 되게 만드는 프로젝트 입니다. 유트브에 보면 이 프로젝트의 데모를 보실 수 있는데, 동작이 꽤나 신기합니다. 그냥 기존의 일반적인 윈도우가  자연스럽게 회전이 되네요.

아… 잠시 이야기가 샐 뻔 했네요. 아무튼 이 프로젝트에서는 마우스 입력을 터치로 대신 인식하게 하는 디바이스도 함께 제공하고 있습니다. 오픈소스이기 때문에 사용에 별다른 제한도 없습니다. 터치 UX는 직관성 혹은 감성적인 측면에서도 의미하는 바가 크기 때문에 직접 느껴보는 것이 중요하겠지만, 개발을 하면서 아쉬운 대로 시뮬레이션 해보기엔 꽤나 적절한 방법입니다.

 
멀티터치를 시뮬레이션 해주는 ‘Multi-Touch Vista’ 프로젝트의 device 설치 중 팝업.

디바이스를 설치하고, 활성화하는 방법은 아래 동영상에 잘 나와있습니다. 프로젝트 주인장님이 참 깔끔히도 정리를 잘 해놓으셨네요 :) 그대로 따라 하시면 어렵지 않게 설치를 끝내실 수 있습니다.

터치 인식 장치가 준비되지 않은 윈도우 7 시스템에서는 컴퓨터의 시스템 정보 확인 창에 아래와 같이 표시될 겁니다.

아아 너무나도 슬픈 소식입니다. ‘디스플레이에 사용할 수 있는 펜 및 터치식 입력이 없다’라고 너무나도 분명하게 확인시켜 주는군요. 자기가 하나 사줄 것도 아니면서 말입니다. 터치식 입력을 가진 장치를 사용하는 경우, 시스템에서 인식된 터치식 입력의 개수를 확인해 보고 싶으면 시스템 정보창의 해당 부분을 보면 알 수 있습니다.

그런데 Multi-Touch Vista에서 제공하는 인터페이스 디바이스를 설치한 후 시스템 정보를 확인해 볼까요?

이번엔 너무나도 훈훈한 메세지가 떴습니다. 무려 255개의 터치 포인트를 사용할 수 있다고 하는군요!! 장치를 활성화하면 갖다 붙인 마우스 수만큼 터치를 인식하게 되는데, 최대 255개 까지 인식을 하나 봅니다. 마우스를 255개 꽂으려면 usb 허브가 몇 개나 필요할까… 하는 생각은 저 혼자만 해 본건가요… +_+ 아무튼 이제부턴 최신식 터치 노트북을 장만한 옆집 철수를 부러워 하지 않아도 되는 순간입니다.

Outro

자, 이젠 정말 터치 프로그래밍을 하기 위한 모든 준비가 끝났습니다. 하드웨어를 마련할 길이 막막해 보여서 공부를 시작해야 할지 말지 망설이고 있으셨다면 우선은 마우스로 터치를 시뮬레이션하면서 공부를 먼저 시작하시면 됩니다. 네이버 검색을 잠시 해보았더니 오늘 소개해 드린 터치 인식 드라이버는 윈도우 모바일 7의 개발환경에도 유용하게 쓰이는 듯 하군요. ( 실버라이트 코리아 라는 네이버 카페 - http://slkorea.net/ – 에서 인디(inde83)님이 작성하신 동일한 디바이스 안내 및 설정법 글을 보았습니다. ) 윈모바일7의 개발에 관심 있으신 분도 눈 여겨 보시는 게 좋을 듯 합니다.

다음 글부터는 본격적인 개발 이야기를 해보도록 하겠습니다. 재미있는 내용을 가지고 돌아올 테니 조금만 기다려 주세요 ^^
그럼 다음 글에서 뵙겠습니다. 오늘도 좋은 하루 보내세요 ^^*
감사합니다 @