6월 1일 REMIX10 행사를 기점으로 Visual Studio 2010 한글판이 대중에 공개가 되었습니다. Visual Studio 2010 의 영문 버전은 그 이전에 출시가 되었지만 한글판이 출시된 이후에 더 많은 관심을 받게 되었습니다.
Visual Studio 2010 으로 개발 환경을 업그레이드를 진행하는 곳이 특히 해외에서 많습니다. 제가 그걸 어떻게 다 아냐구요? 항상 트위터 검색을 통해 해외에서 Visual Studio 2010 를 어떻게 사용하고 있는지 매일 매일 관심 있게 보고 있답니다. ^^
어쨌든 Visual Studio 2008 을 쓰고 있지만, Microsoft MVP 이거나 회사에서 MSDN Subscription 라이선스가 있다면 Visual Studio 2008, Visual Studio 2010 개발 도구가 혼합해서 사용될 경우가 있습니다. 이런 경우 두 개발 도구에서 쌍방 개발 가능하게 구성을 할 수 있습니다.
이 방법은 제니퍼소프트의 정성태 과장님의 블로그에서 예전에 소개했던 VS2005, VS2008 혼합해서 사용하는 방법과 동일합니다.
1. 간단한 예제로 Console Application 을 Visual Studio 2008 에서 생성했습니다.
2. 기존의 솔루션 파일의 복사본을 하나 만듭니다.
3. 솔루션 파일을 노트패드로 ConsoleApplication - VS2010.sln 파일을 열어 다음의 항목을 수정합니다.
4. 프로젝트 파일을 열어 ToolsVersion 의 '3.5' 를 '4.0' 으로 수정합니다. 'ConsoleApplication1.csproj'
만약 다수의 프로젝트일 경우, 위의 3번에서 수정한 솔루션 파일을 열면 프로젝트를 변환하는 마법사로 진행하면 쉽게 변경이 됩니다.
5. 모두 완료 되었습니다. Visual Studio 2010 와 Visual Studio 2008 에서 각각의 솔루션 파일로 동시에 작업을 할 수 있습니다.
위의 방법을 이용하여 Visual Studio 2008 과 Visual Studio 2010 에도 모두 개발이 가능합니다. 하지만 만약 테스트 프로젝트가 포함이 되어 있다면 두 개발 도구에서 사용할 수 없습니다. 왜냐하면 .NET Framework 4.0 에서는 테스트와 관련된 Microsoft.VisualStudio.Quality 프레임워크가 개선되고, Microsoft.VisualStudio.TestTools 프레임워크가 추가되면서 이전 Visual Studio 2008 과 프로젝트가 호환이 되지 않습니다.
하지만 불가능할 것 같은 테스트 프로젝트도 Visual Studio 2008과 Visual Studio 2010에서 동시에 사용할 수 있는 방법이 있습니다. 이것은 다음에 알아보도록 하겠습니다.
DreamSpark는 Microsoft의 Spark 프로그램 시리즈 중 하나이며, 웹 비지니스 활성화를 위한 WebSiteSpark 프로그램, 초기 창업 지원 및 기업 활성화를 위한 BizSpark 프로그램이 있습니다. 그리고 DreamSpark는 학생들의 IT 기술력 향상을 위하여, 기존에 제공되어오던 MSDN Academic Alliance (http://msdn.microsoft.com/ko-kr/academic/default.aspx)와는 별도로 전역적으로 일반화하고 확대한 프로그램입니다.
DreamSpark를 통해서 2010년 6월 현재 제공받을 수 있는 소프트웨어 솔루션 및 혜택들은 다음과 같습니다. 다음은 한글판까지 같이 제공되는 소프트웨어 솔루션들의 목록입니다.
Visual Studio 2010 Professional Edition (* 한글판 제공됨)
Windows Server 2008 R2 Server Standard Edition (* 한글판 제공됨)
Expression Studio 3 (* 한글판 제공됨)
Visual Studio 2008 Professional Edition (* 한글판 제공됨)
Windows Server 2008 Server Standard Edition (* 한글판 제공됨)
SQL Server 2008 Developer Edition (* 한글판 제공됨)
SQL Server 2008 Express Edition (* 한글판 제공됨)
Visual Basic 2008 Express Edition (* 한글판 제공됨)
Visual C# 2008 Express Edition (* 한글판 제공됨)
Visual C++ 2008 Express Edition (* 한글판 제공됨)
Visual Web Developer 2008 Express Edition (* 한글판 제공됨)
Visual Studio 2005 Professional Edition (* 한글판 제공됨)
그 외에 추가적으로 제공되는 소프트웨어들은 다음과 같습니다.
Visual Studio 2010 Express Edition
Windows Mobile 6.5 SDK
Windows Phones Developer Tools CTP
XNA Game Studio 3.1
Robotics Developer Studio 2008 R3
Windows Embedded CE 6.0
Virtual PC 2007
Concurrency and Coordination Runtime and Decentralized Software Services Toolkit 2008 R2
Windows Server 2003 Standard Edition
DreamSpark를 통하여 기본적인 운영 체제와 개발 도구를 다운로드받아서, 여러분이 원하는 소프트웨어나 웹 사이트를 손쉽게 개발하고 디자인할 수 있습니다. Microsoft Imagine Cup 대회에 참가하기 위하여 필요한 소프트웨어를 모두 이곳에서 가져오실 수 있으며, 학생 벤처를 시작하고자 하시는 분들께도 충분한 기술적인 리소스들을 모두 이곳에서 가져오실 수 있습니다.
DreamSpark 등록하는 방법
DreamSpark에 등록하는 방법은 크게 세 가지가 있습니다. DreamSpark 무료 쿠폰을 받으신 경우 (1), 국제학생증 (International Student Identification Card - ISIC)을 소지하고 계신 경우 (2), DreamSpark에 관리자가 기관을 등록한 경우 (3)로 나눌 수 있습니다. 이 세 가지 중 하나로 해당이 되시는 경우, Windows Live ID를 통하여 로그인을 하신 후, Verification 과정을 거치면 됩니다. 각 다운로드 항목 별로 페이지에 Verify 버튼을 클릭하신 후, 국가를 Korea로 선택하시고, 학생 인증으로 접속하기 위하여 Verify as a Student 라디오 버튼 항목을 클릭합니다.
(1) DreamSpark 무료 쿠폰을 받으신 경우: 아래 그림에서처럼 "I have an Activation Code" 라디오 버튼 항목을 클릭하고, Activation Code 입력란에 쿠폰에 적힌 Activation Code를 입력하고 Verify 버튼을 클릭하면 인증이 완료됩니다. 단, 중복 사용이 제한되거나 유효 기간, 유효 횟수가 있는 쿠폰의 경우 Activation Code를 재 사용할 수 없을 수도 있습니다.
(2) 국제 학생증을 가지고 계신 경우: 국제 학생증을 취급하는 대학 교육 기관의 경우 이 옵션을 사용할 수 있습니다. 국제 학생증을 취급하지 않더라도 국내외 여러 국제 학생증 발급 기관 (예: 하나은행, 한국씨티은행 등)을 통하여 약간의 수수료를 지불하고 다양한 목적으로 국제 학생증을 발급받아 혜택을 누리실 수도 있습니다.
참고: ISIC 코드를 입력할 때에, 일부 ISIC 카드의 경우 제일 마지막 자릿수를 제외하고 입력해야 하는 규칙이 따를 수 있습니다. 저의 경우, 인하대학교 학생증과 겸용해서 발급되는 ISIC 카드의 경우 이러한 규칙이 적용됩니다.
(3) DreamSpark 서비스에 등록된 기관에서 재학중이신 경우: 이 경우 해당 기관 내의 재학생임을 증명할 수 있는 수단을 사용하여 접속할 수 있습니다. 해당 기관 내에서 자체적으로 SSO (Single Sign On) 서비스를 Windows Live ID 기반으로 구현하였을 경우 이를 이용하시면 됩니다. 만약 별도의 SSO 서비스가 없을 경우 해당 기관에서 제공하는 메일 서비스를 경유하여 인증을 완료하실 수 있습니다.
Continue 버튼을 클릭하여 계속 진행하면 다음과 같은 페이지가 나타납니다.
위의 화면에서 해당하는 기관을 선택하고, Continue 버튼을 클릭합니다. 아래의 링크를 클릭하시면 2010년 7월 현재 DreamSpark에 등재된 기관들의 목록을 보실 수 있고, Ctrl + F 키를 이용하여 해당 기관명을 검색하실 수 있습니다.
해당 기관 내의 구성원 - 또는 - 학생임을 인증하기 위하여, 해당 기관에서 운영 중인 전자 메일 서비스의 계정과 주소를 이곳에 기재해야 합니다. 예를 들어, 메일 서비스의 도메인이 rkttu.com 일 경우, E-mail Address에 anonymous@rkttu.com 과 같이 기재할 수 있으며, Confirm E-mail Address에 다시 한번 같은 메일 주소를 기재하면 됩니다. 기재가 끝나면 Verify 버튼을 클릭하여 추가 절차를 진행합니다.
DreamSpark는 대학생 여러분들을 위한 솔루션입니다.
Verification 과정을 완료하고 다운로드를 할 때에는 Internet Explorer 뿐만 아니라 Firefox, Chrome 등 여러분이 원하는 브라우저를 이용하여, 별도의 Download Manager를 이용하거나, 직접 웹 브라우저를 이용하여 다운로드하거나 자유롭게 이용하실 수 있습니다. 참고로, Internet Explorer를 이용하여 직접 브라우저로 다운로드하게 되는 경우, 단일 파일의 크기가 4GB 이상인 파일을 다운로드받을 수 없다는 점만 유의하시면 되겠습니다.
소프트웨어 개발이나, IT 기술을 개발하기 위하여 더 이상 불법 다운로드 서비스를 이용하지 마세요. DreamSpark를 통하여 최신 기술을 항상 편리하게 이용하고, 손쉽게 다운로드받으실 수 있습니다. 그리고, DreamSpark와 더불어서 비 정기적으로 진행되는 Windows 및 Office의 대학생 할인 프로모션 프로그램도 자주 있으니 최신 소프트웨어와 IT 기술의 혜택을 편리하게 가져가실 수 있으면 좋겠습니다.
애자일(Agile) 프로그래밍 기법 등이 대중화 되면서, 특히 XP(eXtreme Programming) 에서는 단위 테스트의 코드를 먼저 작성하라고 합니다. 그것이 바로 TDD(Test Driven Development) 입니다.! 그 이유는 다들 아시다시피 간단합니다. 바로 코드를 작성할 때 설계부터 하라는 것입니다. 좀 직설적으로 얘기하자면, 생각 좀 하고 만들라는 것이죠. 생각 없이 만들 코드를 나중에 리팩토링(Refectoring) 할 바에는 처음부터 리팩토링 비용을 줄이고, 좀 더 세련된 디자인으로 코드를 작성하라는 의미입니다.
단위 테스트(Unit Test) 라는 의미에서도 사실 개발자와 테스터, 고객과는 굉장히 괴리감이 있는 단어이기도 합니다. "단위 테스트" 라는 똑같은 단어를 사용하지만 그것을 받아들이는 사람의 직책이나 파트(Job) 이 어디냐에 따라 틀리기도 합니다. 아마도 애자일(Agile) 이라는 트랜드를 아느냐 모르느냐의 기준이 될 수 도 있습니다.
개발자 - "테스트 코드를 만들라는 의미군!"
테스터 - "나더러 테스트 코드를 만들라거야? 아니면 각 기능별로 테스트를 하라는거야?"
고객 - "기능별 테스트를 어떻게?"
단위 테스트에 대한 개발자의 입장
우선 개발자를 봅시다. 필자는 개발자에게 TDD 를 강요하기란 굉장히 어려운 문제라고 생각합니다. 테스트 코드를 작성하는 것은 만들어진 코드의 양에 비례하여 추가적인 테스트 코드를 작성해야 합니다. 테스트 코드를 만드는 것이 문제가 아니라, 시간이 아깝다는 것이죠. 테스트 코드를 만들 시간에 더 생산성 있는(폼-Form 빼는 작업) 이 훨씬 더 나을 것입니다. 사실 우리나라 SI 프로젝트의 문제가 일단 소프트웨어를 만들고 난 다음에, 유지 보수 계약으로 버그를 잡아 치웁니다.
이런 구조는 실제 개발했던 사람과 유지 보수 하는 사람이 교체되면서, 유지 보수 인력은 이미 떠난 개발 인력들에게 "뭐 이런 쓰레기 코드를..!" 이라는 말을 할 수 밖에 없죠. 다시 개발했던 당사자의 입장으로 돌아가 보면, 빨리 빨리 대충 돌아가는 기능을 만드느냐, 느릿 느릿하지만 완벽한 기능을 만드느냐라는 기로에 설 수 밖에 없습니다. 여기서 고객은 언제나 쉽게 맘이 변합니다. 기존의 기능이 추가되거나 변경되면서 이미 완성된 기능에 지속적으로 덧칠을 할 수 밖에 없습니다.
그럼 TDD 를 왜 해야 하는가에 대한 의문점을 가질 수 밖에 없습니다. 단위 테스트조차 여유로운 작업이 아님이 분명한데, 테스트를 먼저하라니!!! 만약 누군가가 그것을 저에게 강요한다면 충분히 해명하거나 변경의 근거가 다분할 것입니다. 아마도 필사적으로 반대 입장에서 논의를 할 지도 모릅니다. 잘 차려놓은 테스트 코드를 돌려보는 관리자의 입장에서는 완벽한 프로세스일지 몰라도 적어도 개발자의 입장에서는 테스트 코드, 아니 TDD 마저 그저 먼 산일 뿐입니다.
단위 테스트에 대한 테스터의 입장
일반적으로 엔터프라이즈 어플리케이션(Enterprise Application) 은 기반이 되는 어플리케이션 프레임워크(Application Framework) 를 구축합니다. 범용 프레임워크를 이용하여 개발자가 사용하거나 소프트웨어나 업무 구조에 맞도록 도메인 집약적인 프레임워크로 파생하거나 전환됩니다. 이 과정은 진정한 기반 프레임워크에서 파생될 수 도 있고, 단순한 라이브러리 형태로 파생될 수 도 있습니다.
일단 팀의 구성원은, 개발 팀, 테스트 팀으로 구분합니다. 개발 팀은 오직 기능을 구현하고, 테스트 팀은 구현된 기능을 수동 테스트(Manual Test) 를 하거나 단위 테스트 코드를 작성하여 테스트를 수행합니다. 즉, 역할이 완벽히 분리되어 개발 인력은 개발에만, 테스트 인력은 원칙에 따른 테스트만 수행하는 형태입니다. 테스터가 테스트를 진행하면서 개발자가 구현해 놓은 기능에 결함이 발견되면, 개발자에게 이것을 알리고 반복적으로 테스트만 전담합니다. 이 프로세스에서 팀 간의 커뮤니케이션은 문서가 될 수 도 있고, 메신저가 될 수 도 있고, 메일이 될 수도 있습니다. 그것은 테스터에게 그리 중요한 것이 아닙니다.
하지만, 점점 더 고객은 특정 프레임워크나 아키텍처에 종속되길 원하지 않습니다. 그 이유는 과거의 잘못된 방법론이나 Non OOP(Object Oriented Programming) 의 확장성에 매우 민감합니다. 즉 기존에 어떤 아키텍처를, 어떤 프레임워크를 쓰던지 간에 현재와 미래가 더 중요할 수 밖에 없습니다. 이러한 과도기에서 과연 테스터는 무엇을 할 수 있을까요?
OOP 기반 프로그래밍은 추상화입니다. 그리고 추상화를 하다 보면 다형성을 따라가게 됩니다. 개발자나 아키텍처에게는 박수를 쳐줘야 하겠지만, 테스터의 입장에서는 전혀 그렇지 않을 수 있습니다. 즉, 테스터는 테스트 코드를 작성하기 위해 전체적인 아키텍처까지 이해해야 하는 어처구니 없는 상황이 발생할 것입니다. 아마도 잘 나가는 개발자들은 Mockup 을 이야기 할 것입니다. 그런데 누가 Mockup 을 할 겁니까? 아무것도 모르는 테스터? 아니면 코드를 작성한 개발자?
얼마 전에 엔터프라이즈 시스템의 확장성과 안정성에 대해서 고객과 미팅을 한 적이 있습니다. 고객은 현재의 프레임워크는 특정 프레임워크에 종속되어 확장이 불가능하며, 다른 프레임워크로 교체마저 불가능하다고 합니다. 그리고 과거의 기술을 사용하기 때문에 특정 벤더의 지원이 부족하고 그것을 이해하는 내부 직원도 없을 뿐더러, 시스템이 간혈적으로 다운되기도 한다고 합니다. 시스템이 돈(Money) 과 직결되는 문제라면 어느 누구도 나서서 고치겠다고 할 사람 없지 않겠습니까?
차세대 시스템에 대한 목표를 언급하면서 SOA(Service Oriented Architecture) 의 구현 산출물인 ESB(Enterprise Services Bus) 에 대해서 열심히 설명하면서, 단위 테스트에 대해서 언급을 한적이 있습니다. 그리고 대부분 고객의 관리자가 젊은 개발자가 아니기에, 이러한 최신 트랜드의 아키텍처와 방법론(?) 을 설명하면 기대 반, 의심 반으로 기대 심리를 갖기도 합니다.
하지만, 고객에게 단위 테스트에 대한 이야기를 언급할 때는 전형적인 과거의 산출물을 상상합니다. 바로 테스트의 이력을 볼 수 있는 문서이죠. 하지만 현재는 이미 그런 단위 테스트의 자동화와 산출물은 자동화가 되었음에도 불구하고 오히려 고객은 과거의 자신의 경험이 비추어 이해합니다. 이미 현재 시스템도 단위 테스트를 수행했고, 철저히 감사했음에도 불구하고 현재 이지경에 이르렀다는 것이죠.
즉, "단위 테스트" 라는 똑같이 형용하는 문자임에도 불구하고, 서로의 이해가 너무나도 부족합니다. 아마도 단위 테스트의 개념조차 없었던 코볼(Cobol), 포트란(Fortran) 의 원시 언어로 돌아가는 기분이 들었습니다. (학문적으로 고급 언어에 속하지만 과연 현재도 고급 언어일까?…) 즉, 그들과 눈높이를 맞출 수 있는 방법은 목표대로 보여주던가, 아니면 우리를 믿지 못하고 과거의 경험에 빗대어 비교할 것인가…
그렇다면 누가 단위 테스트를 수행해야 하는가?
아마도 이 섹션은 특히 필자의 개인적인 생각이기도 합니다. 어쨌든 "단위 테스트"에 대해 이렇게 이해 관계가 얽히는 풀기 힘든 문제이기도 합니다.
그럼 결론적으로 과연 누가 테스트를 수행해야 하는가 입니다. 아마도 필자의 개인적이고 경험적인 부분이므로, 다른 의견이 있다면 조언 부탁 드립니다.
우선 개발 팀과 테스터 팀의 조직적인 분할이 필요합니다. 즉, 팀 별로 역할 범위를 정확하게 명시함으로써 프로세스적인 측면에서 해결해야 할 문제라고 생각합니다. 이러한 문제는 Microsoft Solution Framework(MSF) 에서 잘 설명을 하고 있습니다.
아래의 필자의 분류는 우리나라의 전형적인 프로젝트 진행 구조를 고려하였습니다.
개발 팀
코드 개발, 단위 테스트 코드 개발
테스트 팀
매뉴얼 테스트(Manual Test), 테스트 인프라 관리
관리자
코드 및 테스트 조율 및 소프트웨어 품질 조율
고객
소프트웨어 품질에 대한 논의 및 제안
즉, 필자가 이렇게 구분한 의도는 어느 누군가에게 책임을 소프트웨어의 품질에 대해 소위 몰빵(?) 할 수 없다는 것입니다. 결국 가장 유연해야 할 책임과 역할의 구분이 명확하지 않는다는 것은 스스로의 무덤을 파는 것과 다를 바가 없습니다.
단위 테스트에 대한 적절한 대안은 있는가?
필자는 위와 같은 이유로 팀과 역할을 구분하여 단위 테스트를 수행하는 것을 권장합니다. 물론 위의 팀별 역할은 정답은 아니고, 조직의 형태에 따라 유연하고 적절하게 배분이 되어야 할 것입니다.
필자는 "단위 테스트" 라는 주제로 개인적인 견해를 이야기했지만, 더 나아가 소프트웨어를 개발하기 위한 방법론(SDLC-Software Development LifeCycle) 과 고객이나 기업의 거버먼스와 비즈니즈 가치가 결합되지 않으면, 좋은 소프트웨어를 절대 나올 수 없다고 생각합니다. 즉, 절대적인 방법론이 있고, 방법론을 적용한 경험이 있다고 해서 좋은 소프트웨어가 나올 수 없습니다. 극단적으로, 전산화가 제대로 되지 않은 업무 부처가 있음에도 불구하고 SOA 를 적용한다고 해서 절대 통합과 공유라는 컨셉을 가질 수 없는 것과 마찬가지 입니다.
애자일(Agile)의 대가인 켄트 백(Kent Back)은 아래와 같은 이야기를 한 바 있습니다.
Individuals and interactions over processes and tools
프로세스와 도구보다는 개인과 상호작용을
대부분은 애자일 선언의 이러한 용어로 인해, 매우 혼란스러워하거나 기존의 프로세스를 갈아치우려고 합니다. 마치 애자일의 XP 에서 이야기하는 원칙에서 하나라도 빠트리면 애자일이 아닌 것처럼 말입니다. 애자일의 주요 키워드는 "변화" 이지, 절대 강요가 아닙니다. 만약, 고객은 철저한 기간 엄수를 요구하는 폭포수 모델(Waterfall Model) 을 강요하지만, 개발 팀은 애자일(Agile) 만 고집한다면 그것은 서로 파멸로 가는 길이며, 애자일의 진정한 의미를 이해하지 않았다고 볼 수 있습니다.
켄트 백(Kent Back) 은 아래의 링크를 통해 위의 원칙에 대한 오해를 풀어내고 있습니다.
Tools for Agility - A White paper by Kent Beck, Three Rivers Institute
