드디어 Visual Studio 2010 이 출시가 되었습니다. Subscribe to MSDN 을 통해 다운로드 할 수 있습니다.

다운로드
https://msdn.microsoft.com/ko-kr/subscriptions/securedownloads/default.aspx

   

 

초기 Visual Studio CTP 와 Beta 버전에서 많은 논란이 있었습니다. 하지만 Visual Studio 개발팀의 많은 노력과 결실이 Visual Studio RC 에서 상당수가 개선이 되었습니다.    

이번 메이저 업그레이드 버전에서 많은 사용자의 피드백을 통해 많은 버그 들이 수정이 되었답니다. 얼마나 많은 사용자가 참여를 했고, Fixed 버전이 나왔는지 아래의 Microsoft Connect 사이트를 통해 확인할 수 있습니다.

https://connect.microsoft.com/VisualStudio

   

또한, 저희 Visual Studio 2010 에서 팀원을 추가로 모집하고 있습니다. 관심있는 분들은 아래의 링크를 참고하세요.

http://vsts2010.net/248

   

저희 팀 블로그는 트위터를 운영하고 있습니다. 빠른 소식을 전달해 드리고, 커뮤니케이션의 장을 열어드릴 것입니다.

자 그럼 Visual Studio 2010 의 세계로 떠나봅시다. 아직 잘 모르시겠다고요?? 그럼 아래의 저희 Visual Studio 2010 의 블로그 포스트를 차근 차근 살펴보시기 바랍니다.

 

Visual Studio 2010
Visual Studio 2010
Visual Studio 2010! 나랑 놀아보자 – 기본편 (4회) - Call Hierarchy
Visual Studio 2010! 나랑 놀아보자 – 기본편 (3회) - Box Selection
Visual Studio 2010! 나랑 놀아보자 – 기본편 (2회) - VS IDE
윈도우폰 7 개발환경 공개
실버라이트4 RC와 블렌드 4 베타 공개
똑똑한 검색을 지원하는 VSTS 2010의 "Navigate To" 검색
C#에서 IntelliSense가 동작하지 않을 때 문제 해결 방법
Visual Studio 2010 RC 공개
Visual Studio 2010 RC 공개 임박!
VS 2010 기능소개 05 - Visual C#&VB 개발자 IDE Tips & Tricks 두번째
VS 2010 기능소개 04 - Visual C#&VB 개발자 IDE Tips & Tricks 첫번째
VS 2010 기능 소개 03 - IDE의 변화
VS 2010 기능 소개 02 - IDE의 기능 추가
Visual Studio 2010 출시 일정
VS 2010 기능 소개 01 인텔리 센스 기능의 변화
Visual Studio 2010과 Blend Preview for .NET 4 통합 문제
VS2010 베타2의 WPF & Silverlight 디자이너 성능 향상 팁
VS 2010 Beta 2 설치 과정에서 Silverlight SDK 문제
Visual Studio 2010 Beta 2 설치 미리 보기
Visual Studio 2010 Beta 2 출시
멀티 모니터 사용
Visual Studio 2010 Beta 1 설치부터 살펴보기
Visual Studio 2010 & .NET 4.0 참고 자료들
Visual Studio 2010 내부 빌드 최신 동영상: C# 4.0 Language + IDE + WPF Shell + Editor
Visual Studio 2010 의 특징

Visual Studio Extensibility
Visual Studio 2010 확장 모델인 VSIX 버그
[VSX] 1. Visual Studio Extensibility,, 그 시작
MousePresentationTracker - MEF 세미나 예제
[VSIX] 2-2. How to start VSIX programming
[VSIX] 2-1. How to start VSIX programming
[VSIX] 1. What is different from before version?
Visual Studio 2010 Extension Manager
Visual Studio 2010 SDK 와 Readme
[Blueprints] S+S Blueprints

 

Language
C#
[C# 4.0] Generic Covariance And Contra Variance
[C# 4.0] New Extension Method "Zip"
[C# 4.0] Duck Typing
[C# 4.0] Named and Optional Parameters
Welcome to Dynamic C#(14) - 철지난 만우절에 낚여서 파닥파닥.
Welcome to Dynamic C#(13) - 아직도 가야할 길.
Welcome to Dynamic C#(12) - dynamic은 외로운 아이.
Welcome to Dynamic C#(11) - The Phantom of The Dynamic
Welcome to Dynamic C#(10) - Dynamic Returns Again.(2)
Welcome to Dynamic C#(9) - Dynamic Returns Again.
Welcome to Dynamic C#(8) - DLR이 나무를 사랑하는 이유
Welcome to Dynamic C#(7) - 아낌없이 표현해 주는 나무
Welcome to Dynamic C#(6) - Return to Dynamic (2)
Welcome to Dynamic C#(5) - Return to Dynamic.
Welcome to Dynamic C#(4) - 극과극 비교체험.
Welcome to Dynamic C#(3) - 마음이 넒어진 C#
Welcome to Dynamic C#(2) - Wanna be a polyglot.
Welcome to Dynamic C#(1) - 첫만남.
Welcome to dynamic C# 외전(3) - 감시하는 자와 감시당하는 자.
Welcome to dynamic C# 외전(2) - Generic Method.
Welcome to dynamic C# 외전(1) - Generate From Usage.

CLR (Common Language Runtime)
8. System.Object (2)
7. System.Object
6. Assembly - GAC(Global Assembly Cache)
5. Assembly - Strongly named assemblies
4. Assembly
3. MSCorLib & Metadata
2. CLR! CLR! CLR!
1. Hello 世界

F#
Welcome to F#(12) - 공동작업 좋치아니항가
Welcome to F#(11) - 차별을 권장하는 언어인거임?!?!
Welcome to F#(10) - 인도음식 카레.....?
Welcome to F#(9) - 메이져 데뷰.
Welcome to F#(8) - 은총알과 엄친아.
Welcome to F#(7) - 클리프 행어.
Welcome to F#(6) - 비교본능.
Welcome to F#(5) - 아주 조금씩 심화되는 탐색전.
Welcome to F#(4) - 과거와 배경을 좀 더 알고싶어.
Welcome to F#(3) - 사소한 탐색전.
Welcome to F#(2) - 두번째 만남.
Welcome to F#(1) - 첫만남.    

C++0x
[VC++] 14. decltype
[VC++] 13. Lambda - 네 번째
[VC++] 12. Lambda - 세 번째
[VC++] 11. Lambda - 두 번째
[VC++] 9. Lambda ( 람다 ) - 첫 번째
[VC++] 8. 우측 값 참조( RValue Reference ) – 다섯 번째
[VC++] 7. 우측 값 참조( RValue Reference ) - 네 번째
[VC++] 6. 우측 값 참조( RValue Reference ) - 세 번째
[VC++] 5. 우측 값 참조( RValue Reference ) – 두 번째
[VC++] 4. 우측 값 참조( RValue Reference ) - 첫 번째
[VC++] 3. static_assert
[VC++] 2. C++0x의 auto
[VC++] 1. 큰 변화가 기대되는 Visual C++( VC++ )
VC++ 10에 구현된 C++0x의 코어 언어 기능들
nullptr
대용량 파일 조작을 위한 C++0x의 변화

C++0x Parallel Programming
C++ 개발자를 위한 병렬 프로그래밍 동영상 [6/7] 완결!
C++ 개발자를 위한 병렬 프로그래밍 동영상 [5]
C++ 개발자를 위한 병렬 프로그래밍 동영상 [4]
C++ 개발자를 위한 병렬 프로그래밍 동영상 [3]
C++ 개발자를 위한 병렬 프로그래밍 동영상 [2]
C++ 개발자를 위한 병렬 프로그래밍 동영상 [1]
C++ 개발자를 위한 병렬 프로그래밍 동영상 [0]
양보할 줄 아는 Concurrency Runtime의 event
Parallel Patterns Library (PPL)
Concurrency Runtime
인사 및 Multi Core, Multi Thread...그리고 VC++ 10
PPL task를 이용한 피보나치 수 계산
Parallel Patterns Library(PPL) - concurrent_queue - 2
Parallel Patterns Library(PPL) - concurrent_queue - 1
Parallel Patterns Library(PPL) - concurrent_vector - 2
Parallel Patterns Library(PPL) - concurrent_vector - 1
Parallel Patterns Library(PPL) - parallel_for_each 알고리즘
Parallel Patterns Library(PPL) - parallel_for 알고리즘
Parallel Patterns Library(PPL) - 병렬 알고리즘
Parallel Patterns Library(PPL) - Task
Parallel Patterns Library(PPL) - combinable
Parallel Patterns Library(PPL) - parallel_invoke
Parallel Patterns Library(PPL) - task group에서의 병렬 작업 취소 - 2
Parallel Patterns Library(PPL) - task group에서의 병렬 작업 취소 - 1
Asynchronous Agents Library로 Dining Philosophers 문제 해결하기 - 마지막회
Asynchronous Agents Library로 Dining Philosophers 문제 해결하기 - 2
Asynchronous Agents Library로 Dining Philosophers 문제 해결하기 - 1 

Visual C++ 10
2010/02/04 디버깅 모드에서 역어셈블리 코드 보기
2009/10/15 About Visual C++ 10    

MFC
[MFC] 태스크 대화상자(Task Dialog) - 예제 코드 올립니다.
[MFC] 태스크 대화상자(Task Dialog) - (3/3) : 활용하기
[MFC] 태스크 대화상자(Task Dialog) - (2/3) : 사용하기
[MFC] 태스크 대화상자(Task Dialog) - (1/3) : 기능 소개
[MFC] 리스타트 매니저(Restart Manager) - (3/3) : 활용하기
[MFC] 리스타트 매니저(Restart Manager) - (2/3) : 사용하기
[MFC] 리스타트 매니저(Restart Manager) - (1/3) : 기능 소개

   

.NET Framework
Parallel Programming
Welcome to Parellel world(1) - Here comes a new challenger!
[C# 4.0] Parallel Extension - [3] TPL(Task Parallel Library)
[C# 4.0] Parallel Extension - [2] 병렬 처리 아키텍처
[C# 4.0] Parallel Extension - [1] 병렬 처리

Managed Extensibility Framework
MEFGeneric 코드 플랙스에 공개합니다.
MEF 에 Generic Type 을 지원하기 위해서..?
MEF 는 Generic Type 을 지원하지 않는다!
MEF Preview 6 공개
[MEF] 10. Querying the CompositionContainer
[MEF] 9. Recomposition
[MEF] 8. Strongly Typed Metadata
[MEF] 7. Exports and Metadata
[MEF] 6. Lazy Exports
[MEF] 5. Catalog 사용
[MEF] 4. Import 선언
[MEF] 3. Export 선언
[MEF] 2. Parts 와 Contracts 선언
[MEF] 1. Managed Extensibility Framework 이란?

WCF
WCF 서비스의 동시성(Concurrency) - 2
WCF 서비스의 동시성(Concurrency) - 1
WCF의 기본 <Contract> - Data Contract
WCF의 기본 <Contract> - Service Contract
기본 WCF 프로그래밍 - 첫 WCF 서비스 만들기 2
기본 WCF 프로그래밍 - 첫 WCF 서비스 만들기
WCF란 무엇인가?

 

Web Development
ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Web Forms(1)
ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - New Features in the Microsoft Ajax Library
ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Core Services
ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Web Designer & Deployment
ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Dynamic Data(2)
ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Dynamic Data(1)
[ASP.NET 4.0] 2. AJAX - Declarative Client Template Rendering
[ASP.NET 4.0] 1. Core Service - Extensible Output Caching    

M, V 그리고 C의 각방생활(3) - 초간단 사이트 만들기(1)
M, V 그리고 C의 각방생활(2) - ASP.NET MVC와 인사나누기
M, V 그리고 C의 각방생활(1) - ASP.NET MVC vs ASP.NET WEB FORM    

   

Cloud Development
[MS@클라우드컨퍼런스] MS 클라우드 기술과 플랫폼
SQL Azure 알아보기 (5)- SQL Azure 이점과 T-SQL 지원
SQL Azure 알아보기(4) – SQL Azure Cloud App
SQL Azure 알아보기(3) –SQL Server 2008 R2 Nov CTP
SQL Azure 사용 시 주의점(1) - 방화벽 설정
구름 속의 미래 : Windows® Azure™ Platform [2]
SQL Azure 알아보기(2) – 데이터베이스 스키마 마이그레이션, 데이터 전송
SQL Azure 알아보기 (1) - 데이터베이스 개체 생성
SQL Azure - CTP1
구름 속의 미래 : Windows® Azure™ Platform [1]

   

Windows 7 Development
[멀티터치]멀티터치 프로그래밍 환경 구축하기
사람이 기계와 만나는 진정한 방법 - 멀티터치
[Windows7] Win32를 이용해 윈도우7 멀티터치 프로그래밍하기
Windows 7을 위한 Windows XP 모드
Windows SDK 설치 후 XAML 인텔리센스 문제

 

Sharepoint 2010
SharePoint 2010 Server Object Model
SharePoint 2010 데이터 기술
SharePoint 2010 Event Receiver
SharePoint 2010 Feature
SharePoint 2010 Visual Web Part
SharePoint 2010 Web Part 생성
SharePoint 2010 개발 환경- Hello World 웹 파트 생성 및 배포하기
SharePoint 2010 개발 환경 구성
SharePoint 2010 Overview

   

Architecture Development
Windows Server AppFabric - Velocity 란?
몽당연필과 함께 하는 VSTS 2010 모델링 1/4
몽당연필과 함께하는 VSTS 2010 모델링 0/4
Architect Development ?

   

Agile Development
애자일에 대한 고찰
[Better Code]Visual Studio Code Analysis Enhancements - 3. Data Flow Rules and Phoenix Engine
[Testing] Moq.NET (T/B Driven Development)
[Testing] BDD (Behavior-Driven Development–행위 주도 개발)
[Testing] TDD (Test-Driven Development-테스트 주도 개발)
[Better Code]Visualize Code Relationships
[Better Code]PEX, Automated Whitebox Testing for .NET - 1. 개요
[Better Code]Visual Studio 2010 Code Analysis Enhancements - 2. Rule Sets Feature
[Better Code]Visual Studio 2010 Code Analysis Enhancements - 1.개요
[Better Code]TDD의 개념이 완벽히 녹아 들어간 VSTS 2010

   

Team Foundation Server
Team Foundation 트러블 슈팅 가이드
Visual Studio 2010을 활용한 ALM (1-5) - ALM 이란 무엇인가
TFS 2010 설치 과정 중에 TF255040 문제
TFS 2010 Build Service 설치
TFS 2010 설치 하기

Visual C++ 팀 블로그에 “C++0x Core Language Features In VC10: The Table”라는 이름으로 C++0x의 기능 중 코어 언어와 관련된 것 중에서 VC++ 10에 구현된 것들을 테이블 표로 정리되어 있습니다.

GCC의 C++0x 구현 항목 테이블 표 형식을 차용했다고 하네요.

 

 

위의 테이블 표에서는 C++0x가 처음 구현된 VC++9와 VC++ 10을 비교하고 있습니다.

 

그리고 글의 마지막에 작년에 Boost Con(Boost 라이브러리 관련 행사)에서 발표한 자료가 첨부 파일로 있습니다. 이 문서를 보면 VC++ 10에서 구현한 C++0x의 코어 언어 기능들을 설명하고 있습니다.

 

문서를 보니 큰 기능들은 제가 작년부터 공부하면서 저희 팀 블로그나 여러 장소에서 설명 하였지만 일부 기능은 저도 미쳐 파악 하지 못한 것들도 있더군요. 앞으로 이런 빠진 부분에 대해서 팀 블로그를 통해서 설명해 드리겠습니다.^^

 

Visual Studio 2010! 나랑 놀아보자 – 기본편 (4회)

Visual Studio 2010! 나랑 놀아보자 – 기본편 (3회)

Visual Studio 2010! 나랑 놀아보자 – 기본편 (2회)

- 뭔소리여

Eric Lippert가 만우절에 쓴 글에 아주 제대로 낚였습니다. C# 4.0이 정식으로 나오기 직전인데, 급하게 추가된 연산자가 있다더군요. 자바에 얼마전에 이런 기능이 추가되어서, C#의 우위를 유지하기 위해서 급하게 추가해서 가장 최근버전의 CTP버전에서 확인할 수 있다는 말이었습니다. 추가된 연산자는 '-->'랑 '<--'인데, 전자는  '~로 향해가는'이라는 의미이고, 후자는 '~로 접근하는'이라는 의미라고 합니다. 무슨 말인고 하니....

int x = 10; // this is read "while x goes to zero" while (x --> 0) {     Console.WriteLine("x = {0}", x); }

위의 코드에서 while문안의 식은 x가 0에 도달할때까지라는 의미를 갖습니다.

int x = 10; // this is read "while zero is approached by x" while (0 <-- x) {     Console.WriteLine("x = {0}", x); }

위의 코드에서는 0이 x에 의해서 접근되어질때까지(즉, x가 0으로 접근할 때까지)의 의미를 갖습니다.


제가 귀가 얇아서 일까요? 순간 '혹'해서, '좋은데? 낄낄낄'하고 생각하면서 글을 읽어나갈 무렵, 마지막 줄이 눈에 들어왔습니다. '만우절인데 얼레리꼴레리 속았지? 속았지? 우헤헤헤헤헤헤'. 저는 낚인줄도 모르고 신나게 파닥파닥 거린셈이죠. 호호호호호호. 글을 보니, C# QA팀의 테스터한명도 낚여서 파닥거렸다고 합니다. 그리고 참고로, '-->'이 연산자는 몇년 전부터 돌아다니는 쫌된 유머라고 하네요. 즉, 'x-- > 0'은 'x --> 0'과 동일하다는 거죠..... 아흙.

namespace Console1 {  class Program  {   public static void Main(string[] args)   {    int x = 10;        while(x --> 0)    {     Console.WriteLine("{0}",x);    }        Console.Read();   }  } }

위의 코드는 아래와 같은 결과가 나오고, while문 안의 조건을 'x-- > 0'으로 바꿔도 결과는 동일합니다.




- 마치면서

사실 저도 이글을 가지고 여러분을 낚아볼려는 생각을 가지고 글을 쓰기 시작했는데, 그랬다가 많은 분들의 호응(?)을 받아서 교훈을 얻을까봐, 소개해드리는 정도로 마쳤습니다. 제가 참 좋아하는 블로거이고, 또 배우러 자주가는 블로그에서 낚일줄은 생각도 못했네요-_- 


- 참고자료

1. http://blogs.msdn.com/ericlippert/archive/2010/04/01/SomeLastMinuteFeatures.aspx

Team Foundation Server 2010 은 많은 부분 획기적인 변화를 가져왔습니다. 기능적인 부분은 더할 나위 없거니와 관리적인 부분은 이전 버전을 운용해 보신 분이라면 과히 편해졌다고 할 수 있습니다. AT(Application Tier) 와 DT(Database Tier) 전반적인 부분에 걸쳐 한 자리에서 관리적인 부분을 모두 커버할 수 있기 때문입니다.

하지만, Team Foundation Server 2010 의 새로운 기능 중의 Test & Lab 부분이 상당히 강력해졌지만, 새로운 플랫폼과의 결합과 새로운 개념 등으로 환경 구축이 쉽지만은 않습니다. 필자도 이러한 부분에서 많은 부분 시행 착오를 겪으며 정리한 내용을 공유하고자 합니다.

Team Foundation 의 운용을 어렵게만 느끼지 마시고, 문제가 발생하면 바로 아래의 링크를 통해서 확인해 보는 것도 좋은 방법일 것 같습니다.^^

이 문서는 지속적으로 업데이트 될 예정입니다.

마지막 업데이트 : 2010-04-06

   

Test & Lab Manager

[HowTo] 가상 Lab 환경의 가상 머신 시작하기
[HowTo] Lab Manager 환경 구성 중 TF260078 오류 해결하기
[HowTo] 가상 Lab 배포 중 오류 해결하기 TF259115
[HowTo] Lab Manager 에서 가상 Lab 환경 만들기

   

Visual Studio 2010

[HowTo] Work Item 쿼리를 Excel 로 내보내기 할 수 없는 경우 TF80012 에러

   

Team Foundation Server 2010

[HowTo] Team Foundation Server 2010 FQDN 설정 방법
[HowTo] TFS 설치 중 Reporting Services 관련 오류 Error 28805
[HowTo] Team Project Collection 옮기거나 복원하기 TF246081
[HowTo] TFS 2005/2008 데이터베이스를 TFS 2010 으로 마이그레이션
[HowTo] Team Project Collection 이름 변경하기

   

System Center Virtual Machine Manager

[HowTo] SCVMM 에서 암호화된 파일 전송을 사용하지 않으려면?
[HowTo] SCVMM 라이브러리 템플릿 만들기
[HowTo] SCVMM 의 라이브러리 템플릿 배포 작업이 무한 대기할 경우

본 원고는 월간 마이크로소프트 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 을 수행하기 위해서는 어떠한 프로세스적인 요소를 강제하고 있었습니다. 마치 군대에서 기상->아침 구보->보고(점호)->아침 식사-> … -> 저녁 식사->청소->보고(점호)->취침 과 같이 매일 반복되는 프로세스와도 유사할 수 있습니다. 그리고 이런 프로세스가 잘 진행되는지의 여부를 알기 위해 상사에게 "보고" 하는데 소프트웨어 개발 측면에서는 각종 산출물이나 보고서가 필요합니다. 그리고 병사들이 야간 근무를 교대하고 활동을 추적하기 위해 교대 시간마다 기록을 하게 됩니다.

 

프로세스 강요(Process Enactment)	일관된 프로세스를 강요해야 함
가시화(Visibility)	모든 전반적인 활동에 대한 진행 상황을 볼 수 있어야 함
추적성(Traceability)	모든 활동이나 산출물 등 연관 관계를 추적할 수 있어야 함

표 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의 개발에 관심 있으신 분도 눈 여겨 보시는 게 좋을 듯 합니다.

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

안녕하세요. 추운날씨 잘 견디셨죠? 이제야 좀 어깨펴고 글좀 쓰겠네요. 자~ 오늘도 함께하시죠^^

이번에는 MVC로 사이트를 만드는 시간을 가져보려합니다. 간단하게 회원가입, 로그인, 게시판 정도로 해볼 생각입니다. 오늘은 첫번째로 회원가입을 해보도록 하겠습니다. 너무 썰렁하더라도 옷 단단히 더 껴입으시고 웃음으로 넘어가 주세요^^;

DB 생성하기

사용자 테이블을 만들어봐야죠^^ 테이블 컬럼은 다음과 같습니다.

컬럼명	데이터 타입
SEQ	int
ID	nvarchar(50)
NAME	nvarchar(50)
PWD	nvarchar(50)
EMAIL	nvarchar(100)
EMAIL_YN	char(1)
RGST_DT	datetime

다음의 순서대로 테이블을 생성하겠습니다.

1. SQL Server DataBase를 생성합니다. 솔루션 탐색기에서 마우스 우클릭하여 App_Data -> Add -> New Items을 선택하여 MvcDb.mdf라는 이름으로 데이터베이스를 생성합니다.
2. 서버 탐색기에서 생성된 MvcDb.mdf를 클릭하면 데이터베이스가 연결되면서 DB구조가 확장이됩니다. Tables 폴더에서 마우스 우클릭하여 Add New Table을 클릭하고, 위의 테이블 구조로 TB_USER 테이블을 만들겠습니다. 다 만든후 저장해주세요^^


DB와 테이블이 생성이 되었으면 이제 다음의 순서대로 모델을 생성하겠습니다.

1. 솔루션 탐색기에서 Models -> Add -> New Items을 선택합니다.
2. Data 카테고리를 선택하고 ADO.NET Entity Data Model 템플릿을 선택합니다.
3. 모델 이름을 UserDbModel.edmx라고 입력한후 다음버튼을 클릭합니다.
4. Entity Data Model 위자드 팝업이 뜨면 Generate from database를 선택하여 다음버튼을 클릭합니다.


5. 완료가 되면 엔티티 데이터 모델 디자인 창이 열립니다.


SQL Server DataBase의 생성과 모델 생성은 여기를 참고하세요.

초간단한 가입페이지 만들기

정말 간단하게 만듭니다. 위 모델 보시면 항목도 많지가 않죠^^

먼저, 컨트롤러를 하나 생성하겠습니다. 이름은 Member로 하겠습니다.
Controllers에서 Add -> Controller을 하시고 다음과 같이 Member 입력하시고 Add를 꼬옥 눌러줍니다.


다음으로 액션메쏘드를 만들도록 하겠습니다. 이름은 Join으로 하겠습니다.^^


네, 잘 만들었죠. 그러면 View 페이지도 생성하도록 하겠습니다. 메쏘드 안에서 오른쪽 버튼 클릭후 Add View 하시면 Member 폴더 밑에 Join.aspx 페이지가 생성이 됩니다. 소스는 다음과 같습니다.


여기서 확인해볼 것은, Html.BeginForm() 입니다. 브라우저를 열어서 소스보기를 해보시면


자연스럽게 <form>~</form>태그가 생성된 것을 확인하실 수 있습니다. 또, action 부분에 /Member/Join 이 매핑되는 것도 확인하실 수 있습니다.

페이지를 만들었으니 확인을 해봐야겠죠? F5를 꾸욱 눌러봅니다.(위에서 먼저 눌러서 확인했잖아~!! 소스보기는 하늘에서 뚝 떨어진 거니? 라고 물으신다면, 저는 할말이 ;;;)


^^ 바로 띄우기도 좀 거시기해서, 링크하나 걸었습니다;;


폼 내용을 입력하시고, 가입버튼을 클릭합니다.
그런데 이게 무슨 퐝당한 시츄에이션인지요. 뭔가 상태바를 보니 서버를 호출하는것은 같은데 제가 입력한 값들만 다 사라지고 아무 변화가 없습니다. 이유인 즉, 폼이 /Member/Join으로 전송되면 Join메쏘드를 호출합니다. 그런데 거기서 아무 처리를 안해줬으니 그냥 동일하게 뷰페이지만 새로 렌더링하는거죠. 그래서 제가 입력한 값들은... 과감히 버려졌습니다. 앍!
여기서 하나 알게된 것은, 아~ 그러면 값들을 처리하는 메쏘드가 하나 더 있어야겠구나 하는거죠^^;


소스를 보시면, Join 메쏘드가 두개인 것을 확인하실 수 있습니다. 하나는 /Member/Join이 호출되었을때의 메쏘드 이고, 다른 하나는 폼입력을 마친후에 submit시 호출되는 메쏘드 입니다.

Post로 받는 메쏘드를 보시면 EMAIL_YN이 하나 걸리긴 하는데요. Html.CheckBox() 헬퍼 메쏘드를 사용하면 hidden 필드값이 하나 더 생깁니다.(소스보기 참고) value 값은 false 로 되어있고요, 그래서 체크박스가 체크가 되어있으면 제가 value로 지정한 'Y'가 넘어오는데 체크해제때에는 'false'로 넘어옵니다. 그래서 저런 구문을 추가했긴했는데, 추후에 조금 더 알아보도록 하겠습니다.
_db.AddToUserSet(userInfo); 의 경우 엔티티 프레임워크에서 제공하는 프로퍼티로 저희가 생성한 User를 추가해준다는 거겠죠? 그리고 항상 디비작업을 완료하려면 SaveChanges(); 메쏘드를 호출해야합니다.

완료가 됐으니 JoinSuccess 페이지에 모델객체를 넘겨서 마무리를 짓도록 하겠습니다.
Views 폴더 밑 Member 폴더에서 Add -> View 를 하셔서 형식화된 뷰를 생성하도록 하겠습니다.


JoinSuccess.aspx 페이지의 소스는 아래와 같습니다.


다시, 실행을 시켜서 폼 입력을 마친 후 가입버튼을 클릭하면,


네, 디비에 값이 잘 인서트 되었는지도 확인해보세요^^;
여기서 잠깐! 우리가 여기까지 너무 쉽게 온 것 같네요. 다시 실행을 시켜보도록 하죠. 그리고 폼에 값을 입력하지 않고 가입버튼을 클릭하면 Excepton 발생!!!


역시, 너무 쉽게 됐다고 생각했습니다. View Datail을 클릭하니


'Cannot Insert the value NULL into column 'ID...'
아이디부터 걸리기 시작합니다.

급 마무리요

글이 너무 길어졌습니다. 간단한 것을 이리도 길게 글을 쓰는 저를 꾸짖진 말아주세요^^
암튼, 여기서 과제가 생겼습니다. 다음 포스팅에서는 유효성 검사 부분들을 다루도록 하겠습니다.

지난 포스팅에 이어서 WCF 서비스의 동시성에 대해 이야기 해보겠습니다.
다른 설명 하지 않고, 지난 포스팅에서 했던 것 처럼 예제를 우선 보고 얘기를 진행해볼까 합니다.

Implementing a Singleton

단 하나의 서비스 인스턴스만이 생성되며, 인스턴스에서 동작하는 스레드 역시, 단 하나만 생성되게 하는 경우에 대해 먼저 살펴보겠습니다.
저번 포스팅에서 사용했던 서비스 클래스의 코드를 다음과 같이 굵은 글씨체 부분만을 수정하여 서비스를 실행해 보시기 바랍니다.


이 코드를 실행하면 다음과 같은 결과를 확인할 수 있을 것입니다.

[서버]


[클라이언트]


결과가 여러분이 예상했던 것과 일치하나요?? ㅎ

이 경우 역시 서비스의 인스턴스는 서버 측 결과 화면을 통해 클라이언트의 요청의 수와는 관계없이 하나 만이 생성됨을 알 수 있습니다.
그리고, 클라이언트에서 서비스를 호출하는 방식으로 비동기 방식을 사용했던 것 기억하실겁니다. 결과 그림만을 봐서는 잘 모를 수도 있지만, 이 때문에 클라이언트 측 결과 화면을 보면, 지연시간 없이(각 호출에 대한 결과를 받지 않아도) 서비스를 연속적으로 세 번 호출함을 볼 수 있습니다.
하지만, 이 호출에 대한 결과는 각각 5초간의 지연시간을 두고 화면에 출력하는데, 이는 서버측 결과 화면을 보면 그 이유를 알 수 있습니다. 만약, 서비스 인스턴스가 여러 개의 스레드를 만들어 요청을 처리했다면, 클라이언트의 각 요청에 대한 결과를 거의 동시에 받을 수 있겠지만, 이 경우에는 하나의 스레드 만이 동작하기 때문에 각 요청을 한번에 하나씩 처리할 수 있어 이러한 결과를 얻을 수 있는 것이죠. 참고로, 각 요청에 대한 처리는 FIFO(First In First Out)의 순서로 동작합니다.

서비스 인스턴스에서 단 하나의 스레드 만이 동작한다는 것은 서버 측 결과에서 Thread ID 값이 3으로 동일한 것을 봐도 증명이 가능합니다. 가끔, 이 thread id의 값이 각 요청마다 다른 값이 나올 수도 있습니다. 그렇다고 잘못된 결과값은 아닙니다. ConcurrencyMode.Single 은 한번에 하나의 스레드만이 동작한다는 것을 명시하는 거지, 단 하나의 스레드만이 만들어진다라는 의미는 아니거든요~,, 약간 헷갈릴 수도 있는 부분인 것 같으니, 꼭 명심해주세요,, ㅎ

이 경우처럼 싱글 인스턴스, 싱글 스레드는 한번에 하나의 클라이언트 요청만을 처리할 수 있기 때문에 throughput을 감소시킨다는 단점이 있지만, 반면에 시스템 자원(resource)에 동시 접근 같은 문제가 일어나지 않아서, 이에 대한 추가적인 관리가 필요하지 않다는 장점도 있습니다.

Session-Level Instances

이번에는 세션 모드가 적용되었을 때, 서비스의 인스턴스가 어떻게 생성되는지 한번 살펴보도록 하겠습니다.

우선, 서비스에서 세션을 지원하도록 하기 위해 서비스 계약의 특성값을 다음과 같이 수정합니다.


SessionMode에 Required 값을 적용하여 이 서비스가 세션 모드를 지원해준다는 것을 명시해 줍니다.
다음은 ServiceBehavior 특성에서 InstanceContextMode의 값을 PerSession 으로, ConcurrencyMode의 값을 Multiple 로 수정을 해줍니다. 그리고 GetProduct 메서드가 한 인스턴스에서 몇 번 호출이 이루어지는지를 체크하기 위해 n_Calls 라는 이름의 필드를 추가해 주었습니다. lockThis 필드는 n_Calls 필드의 값을 증가시킬 때 다른 스레드에서 동시에 n_Calls의 값을 바꾸지 못하도록 하기 위한 목적으로 선언해주었습니다.


코드를 다 수정하셨으면, 결과를 확인해보도록 하겠습니다.

당연히, 서버 측 콘솔 어플리케이션을 실행 시키신 후에, 클라이언트 어플리케이션을 실행시켜야겠죠,,^^
아,, 이런~ 저와 같은 방법으로 수정을 한 후에 실행 시키면, 아마 예외가 발생하실겁니다.

예외의 이유는 간단합니다. Service Contract에서 세션 모드의 값을 Required로 설정을 해놓았는데, 실제 서비스를 호스팅할 때 세션을 지원하지 않는 BasicHttpBinding을 사용했기 때문입니다. 따라서, BasicHttpBinding을 WSHttpBinding 으로 수정해주시면 이 예외는 발생하지 않을 것입니다.

자~ 이 부분 수정을 다 하셨다면, 다시 실행을 해보도록 하겠습니다.

세션모드의 지원을 확인하기 위해서 클라이언트 어플리케이션을 두 개 연속해서 실행을 시킵니다.

다음은 서버 어플리케이션의 실행 화면입니다.


인스턴스가 두 개 생성된 것을 확인할 수 있네요,, 왜 인스턴스가 두 개 생성되었을까요?? 당연히 클라이언트 어플리케이션이 두 개 실행이 되었기 때문입니다. 세션을 지원하는 서비스이니깐요,,

자~ 다음은 두 클라이언트 어플리케이션의 실행화면입니다.





각 클라이언트는 호출한 횟수가 1~3인 것을 확인할 수 있습니다. 이것은 각 클라이언트 마다의 서비스 인스턴스가 따로 데이터를 유지한다는 것을 의미하는 것이죠. 이해 되셨죠?? ^^

이번 포스팅은 이것으로 마무리 하려 합니다.
이번에도 포스팅이 조금 늦었습니다. 바로 하려고 했는데 이게 마음처럼 쉽지가 않네요. ^^;;

어찌됐든, 다음 포스팅때 뵙도록 하겠습니다. ㅎ

안녕하세요. MFC 카테고리의 꽃집총각 입니다.
오늘은 Technical Article에 앞서서 멀티터치에 대한 개념적인 글을 하나 준비해 보았습니다.

이미지 출처 : http://farm3.static.flickr.com/2152/2547399057_f91154cb87_o.jpg

이제는 ‘멀티터치’라는 기술은 신기술이라고 부르기도 어색할 만큼 많이 일반화 되었습니다.
애플의 아이폰은 멀티터치의 대중화에 아주 본격적인 역할을 했습니다. 많은 사람들이 손바닥에 올려놓은 아이폰에서 사진을 멀티 터치로 zoom하고 slidng 합니다.

멀티터치 기술에서 우리가 기대할 수 있는 효과를 아래의 두 가지로 정리할 수 있다고 생각합니다.

1. 이전에 없었던 새로운 형태의 인터페이스 구현
2. 컴퓨팅 능력이 부족한 저연령/고연령 세대들의 학습 문턱 제거.

멀티터치는 좀 더 본능적이고, 직관적인 컴퓨팅을 가능하게 합니다. 굳이 하드웨어나 소프트웨어의 학습과정 없이, 매뉴얼도 없이 생각대로 조작하는 것을 가능하게 해주는 새로운 개념의 인터페이스 입니다.

멀티터치 기술의 상용화는 이제 겨우 걸음마 단계라고 볼 수 있습니다.
아직 우리가 상상하지 못한 놀라운 제스처들이 우리의 스크린에서 가능해 질 지도 모르는 일입니다.
제가 개인적으로 멀티터치라는 기술을 처음 접했던 것은 2006년 제프한 박사의 TED 강연을 통해서 였습니다. 저는 그가 말하는 내용 중, ‘멀티 터치는 사람이 기계와 만나는 진정한 방법이다’ 라는 말이 꽤나 인상적이군요. 강연에서 제프한 박사는 앞으로 멀티터치를 활용한 보다 다양한 분야의 응용이 이루어 질 것이고, 인터페이스의 큰 변화를 가져올 것이라는 메세지를 던지고 있습니다.

(한글 자막을 켜고 보세요)http://www.ted.com/talks/lang/eng/jeff_han_demos_his_breakthrough_touchscreen.html

애플은 이런 멀티터치 기술을 아주 발 빠르게 자사의 product에 적용해 나가고 있습니다. 아이팟 터치와 아이폰, 매직마우스 등에서 멀티터치 제스처를 인식하고 있고, 얼마 전에 새롭게 발표된 맥북에서도 터치패드가 멀티터치를 인식하도록 개선되었습니다.

마이크로소프트의 새로운 OS인 윈도우 7 역시도 멀티터치 인식 기능이 구현되어 있습니다. 하지만 생각 외로 많은 분들이 윈도우 7의 멀티터치 인식에 대해 잘 모르고 계시더군요. 아마도 애플의 제품군은 하드웨어와 소프트웨어가 함께 공급되어 바로 멀티터치를 체험해 볼 수 있는 것과는 달리, 윈도우 7은 멀티터치 인식 하드웨어가 없으면 직접 체험해 볼 수 없기 때문에 비교적 알려지지 않게 된 것이라고 추측해 봅니다.

저는 얼마 전 3월 9일에 마이크로소프트에서 주최한 Windows 7 Technical Briefing 이라는 기술 세미나에서 ‘Win32 API를 이용해 멀티터치 프로그래밍하기’라는 주제로 세션을 맡아 발표한 적이 있습니다. 그 때를 계기로 윈도우 7에서 동작하는 멀티터치 프로그램의 개발에 대해 많은 관심을 갖게 되었습니다. 발표에 앞서 ① 윈도우 7을 터치로 조작해 보신 분이 있느냐는 질문과 ② 윈도우 7이 멀티터치를 인식한다는 사실을 알고 계셨느냐는 두 가지 질문을 드려보았는데, 개발자 분들을 대상으로 하는 기술 세션이었는데도 불구하고 생각 외로 많은 분들이 처음 듣는다는 반응을 보이셔서 의외라고 생각했습니다.

아래의 동영상은 PDC 2008에서 윈도우 7의 멀티터치 인식 기능을 시연하는 장면입니다.

보시다시피 이미 2년 전인 PDC 2008에서 윈도우 7의 멀티터치 기능은 대중들에게 활짝 공개 되었습니다. 말 그대로 ‘새로운 기능이라고 부르기도 어색할 만한’, 새기능 아닌 새기능 – 윈도우 7 터치 인식 인터페이스 입니다.

앞서 잠깐 말씀 드렸던 것과 같이 윈도우 7 멀티터치의 가장 큰 장애요소는 ‘멀티터치 인식 하드웨어’가 아닌가 생각합니다. 하지만 이미 컴퓨터 시장에는 올인원 PC, 타블렛 PC, 터치 인식 노트북 등 다양한 멀티터치 인식 장치들이 쏟아져 나오고 있습니다. 유명한 d모 가격비교 사이트의 스샷을 올려드리고 싶지만, 특정 브랜드명이 다수 노출되어 그럴 수가 없네요 ^^;… 직접 한 번 검색해 보시기 바랍니다. 분명하게 말씀 드릴 수 있는 것은 향후 적지 않은 시간 동안 ‘멀티터치’ 분야는 하드웨어와 소프트웨어를 막론하고 컴퓨터 산업의 커다란 이슈가 될 것이라는 점 입니다. 아니, 이미 멀티터치는 커다란 이슈가 되었습니다.

앞으로 팀블로그나 여러가지 활동을 통해서, 윈도우 7의 멀티터치 기능을 소개하는 기회를 가지려고 합니다. 그리고 이러한 무궁한 가능성을 가진 멀티터치를 Visual Studio 2010을 통해 Windows 7의 응용프로그램에 적용하는 방법을 시리즈로 연재하고자 합니다. WPF와 같은 Managed 언어로도 구현 가능하지만 제가 진행할 시리즈들은 MFC와 Win32를 이용한 터치 프로그래밍 방법이 주요 내용이 될 것입니다.

그럼 앞으로 연재할 멀티터치 구현 포스팅에 많은 관심 부탁 드리면서
다음 포스팅에서 뵙도록 하겠습니다.

모두 오늘 좋은 하루 보내세요 ^^*

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

꽤나 오랜만에 글을 올리는군요 ^^;
그동안 팀 블로그에 올려 두었던 MFC의 기능 소개 글들을 한 번에 정리할 기회를 갖게 되어 예전 글들을 다시 살펴보며 정리하다가 CTaskDialog 클래스 사용법을 알아볼 수 있는 공개용 예제코드를 작성해 보았습니다. 포스팅을 할 때 사용했던 코드이기 때문에 주요코드들은 모두 블로그에 조각조각 올라와 있기는 하지만 다운받아서 직접 빌드하고 실행해보실 수 있도록 프로젝트 파일과 솔루션 파일 모두 함께 올립니다.

소스코드는 당연히 Visual Studio 2010 RC 버전에서 제작되었습니다 ^^;...
아래는 예제 코드를 켭쳐한 이미지 입니다.

프로그램을 빌드해서 실행하면 대화상자 중앙에 두 개의 버튼이 있습니다.
왼쪽 버튼을 누르면 간단한 출력 방식인 CTaskDialog::ShowDialog() 함수의 사용법을,
오른쪽 버튼을 누르면 좀 더 디테일한 방법인 CTaskDialog::DoModal() 함수의 사용법을
확인해 보실 수 있습니다.

아래 두 장의 이미지는 각각의 방법들로 띄운 예제 Task Dialog 의 모습입니다.


 CTaskDialog::ShowDialog()를 이용해 출력한 Task Dialog.

CTaskDialog::DoModal()을 이용해 출력한 Task Dialog.

학습하시는 데 도움이 되었으면 하는 마음으로 올립니다.

곧 MFC의 새롭고 재밌는 기능들을 주제로 다시 포스팅을 이어나가도록 하겠습니다.
조금만 기다려 주세요 ~

그럼 다음 포스팅에서 뵙겠습니다 ~
감사합니다 ^^*

오늘부터 3일 동안 미국 라스베가스에서 MIX10 컨퍼런스가 열리는데 알려진대로 첫날 키노트에서 윈도우폰7 관련 정보가 공개되었습니다.
실버라이트 기반으로 어플리케이션 개발이 가능하고 게임은 XNA Game Studio 4.0으로 가능합니다.
http://developer.windowsphone.com/windows-phone-7-series/ 에 가보시면 윈도우폰7 SDK를 포함한 다양한 정보에 접근이 가능합니다.
발표되자마자 빠르게 설치를 해보았는데 설치되는 요소는 다음과 같습니다.


기본적으로 윈도우폰 7 개발 관련 애드인과 기반이 되는 실버라이트 4와 SDK가 설치됩니다.
여기서 설치되는 실버라이트 4의 버전은 RC버전입니다.
그리고 XNA Game Studio 4.0과 윈도우폰 에뮬레이터 등이 설치되고 Visual Studio 2010 Express for Windows Phone도 함께 설치되는데 Visual Studio 2010 RC버전에서도 마찬가지로 개발 환경이 구성됩니다.

설치를 하고 Visual Studio 2010을 실행 해 보면 개발 환경에 윈도우폰과 XNA 4.0 템플릿이 추가된것을 볼 수 있습니다. 일반적인 어플리케이션을 개발 할 때는 실버라이트로 하면되고 게임은 XNA를 선택해서 개발하면 됩니다.


윈도우폰 어플리케이션을 선택하고 프로젝트를 생성하면 다음과 같은 작업창이 나타납니다.


기존의 익숙한 환경에 윈도우폰 UI의 모습과 실버라이트 기반이기 때문에 XAML 코드가 나타나는것을 알 수 있습니다. 개발 언어는 역시 C#으로 하면 되어서 기존의 지식을 살려서 따로 학습을 하지 않아도 바로 적용할 수 있습니다.

빌드를 하면 윈도우폰의 에뮬레이터가 실행되면서 윈도우폰의 경험을 그대로 살려 볼 수 있습니다.


윈도우 모바일의 에뮬레이터와는 다르게 아주 빠르게 실행되어 쾌적한 개발 환경을 제공합니다.
MIX10에서 발표가 되자마자 빠르게 설치하여 기본 개발 환경을 알아보았는데 앞으로 세세한 정보와 XNA에서의 개발환경도 알아보도록 하겠습니다. Microsoft의 윈도우폰 많이 기대해주세요 :)

MIX10에서 다양한 정보가 쏟아지고 있는데 실버라이트4 RC와 블렌드4 베타도 공개되었습니다.

Visual Studio 2010 RC에서 사용이 가능하도록 업데이트되었고 블렌드 4에서는 윈도우폰7 관련 지원도 추가되었습니다.

<프리뷰 버전과는 다르게 SketchFlow까지 포함된 완전한 버전입니다.>

<윈도우폰 애드인을 설치해야 윈도우폰 프로젝트가 추가됩니다.>

<윈도우폰 프로젝트를 만들면 다음과 같이 구성됩니다.>

다운로드 가능한 링크는 아래에 있으니 지금 바로 사용해보세요!

Silverlight 4 Tools for Visual Studio 2010 RC

Expression Blend 4 Beta

Blend Add-in Preview for Windows Phone

Blend SDK Preview for Windows Phone

최근에 많은 기술이 쏟아지고, .NET 의 생태계에도 새로운 국면을  맞이했습니다. 바로 Microsoft  에서 야심차게 준비하고 있는 .NET 4.0 플랫폼과 Team Foundation Server 기술은 상상과 생각을 현실로 이루어주는 강력한 밑거름이 되기 때문입니다.

 

지금이 아마 우리도 함께 변화할 수 있는 최고의 시점이며, 본 세미나는 그 길을 열어주는 가장 효과적인 세미나가 될 것입니다.

본 세미나는 프로젝트를 주도하는 관리자나 프로젝트 매니저를 위한  세미나입니다. 세미나 신청은 아래 "세미나 등록하기" 버튼을 클릭하십시오.

 

ALM 의 도입과 그 필요성

여러분의 조직은 효율적이라고 생각하나요? 바꾸어 보십시오. 효과적인 팀의 관리 방법과 한발 앞의 미래를 먼저 바라보는 노하우를 알려드립니다.

 

기업용 LOB 프로그램의 테스트 환경 구축
오늘날 소프트웨어 개발부터 운영까지 최신의 테스팅 기법과 기술을 직접 눈으로 확인하십시오. 테스트 자동화와 테스트 가상화는 분명 여러분들의 감탄과 탄성을 자아낼 것입니다.

 

WPF 기반 스마트클라이언트 적용 고객 사례
최신 프레젠테이션 기술인 WPF 를 이용하여 UX 와의 교감, 개발까지 아우르는 현장감있는 그들의 고민과 재미있는 경험을 들을 수 있을 것입니다.
  
 

애자일에 대한 고찰에 앞서 먼저 '정말 TDD 가 필요한가?' 에 대해 이야기 부터 시작해봅니다.

애자일에 대한 고찰

애자일 프로그래밍이 도마에 오르면서 단연 단위 테스트(Unit Test)와 TDD(Test Driven Development) 를 빼놓을 수 없습니다. 단위 테스트와 TDD는 상호 공생 관계에 놓이면서, 둘 중 어느하나 포기하기 쉽지 않습니다. 왜냐하면 TDD에 대한 이상론자들은 TDD의 중요성을 매우 높이 강조하고 있기 때문입니다.

필자는 이에 대해 정말 개발에 TDD가 얼마나 좋고 효과가 좋은지 사실 산술적으로 검증할 수는 없다고 생각합니다. 좋은 것이 있는 많큼 잃는 것도 있을테니까요.

TDD 를 해야한다는 관점

일반적으로 코드를 작성한 후에 그 기능을 테스트하는 코드를 작성하는 것을 단위 테스트라고 합니다. 단위 테스트를 작성함으로써 결함없는 소프트웨어를 만들기 위한 지속적인 통합(CI-Continuous Integration) 라는 관점에서 상당히 효과적인 방법입니다.

여기에서 TDD 는 단위 테스트를 작성하는 단계의 순서를 기존의 Last 에서 First 로 바꾸면서, 단위 테스트 코드를 먼저 작성하도록 하는 방법입니다. 처음 오류가 날 수 밖에 없는 코드를 테스트하면서 Red, Green, Refactor 단계로 옮겨가도록 하는 기법입니다.

사실 이런 저런 TDD 의 효과중에 단연, 코드가 매우 견고해진다는 큰 장점이 있습니다.    

 

처음부터 기능을 구현하는 코드를 작성하게 된다면, 클래스와 메서드를 잘 분리한다고 하더라도 한 클래스나 메서드는 생각지도 않게 기능의 크기가 커질 수 밖에 없습니다. 왜냐하면 코드 작성자는 코드를 만드는 목적이 기능이 정상적으로 작동해야 한다는 전제하에 코드를 만들기 때문에 오류 없는 코드가 목적이기 때문입니다.

또 한가지 TDD를 하지 않는다면 코드의 리팩토링을 코드가 완료된 이후에만 가능하다는 것입니다. 지속적으로 이런 문제는 소프트웨어의 디자인이 바뀌거나 오류가 발생하지 않을 경우 굳이 리팩토링을 하지 않게 되죠.

결국 어떤 이유에서든지 좋은 코드를 만들기 위해서는 TDD가 매우 좋은 기법이 될 수 있습니다. 쉽게 Database 를 예로 들자면, 초기에 테이블을 정규화할 것인지, 나중에 문제가 생길 경우 정규화를 할 것인지의 고민과 유사하기도 합니다. 하지만 절대 변하지 않는 진리는, 처음부터 갈귀갈귀 정규화를 한 것을 합치는 것은 쉬워도, 통짜를 분리하는 것은 사실 엄청난 리스크가 됩니다.

TDD 를 하지 말아야한다는 관점

개인적으로 필자는 이 부류에 속하기도 합니다. 누구든 TDD를 알게 되면 그것이 가지는 이상적인 효과를 이해할 수 있습니다. 하지만 살짝 TDD에 발가락을 담구어보면 금방 TDD에 대해 의심을 하게 됩니다. 바로 TDD를 해보면 너무 어렵다는 것입니다.

첫번째로 Red, Green, 그리고 최종적으로 Refactor 단계로 가는 과정이 오래 걸리고 어렵습니다. TDD코드를 만들기 시작하는 순간부터 리팩토링의 시작이며, 길지 않은 코드조차 굉장히 버겁다는 것을 알 수 있죠. 정말 지루하고도 기계적인 과정입니다.

두번째는 이미 언급했다시피 지루하고도 기계적인 과정입니다. 즉 TDD기법으로 생상되는 코드는 기존에 코드를 만들고 테스트하는 예상 시간이 +a 가 됩니다. 코드의 양에 비례하여, 'stub(코드의 양) * alpha(가중치) = TDD 수행시간' 이라는 대략적인 예측 소요 시간이 걸릴 것입니다.

 

TDD의 시작은 곧 리팩토링의 연속입니다. 아무리 개발 도구가 좋아진다고 하더라도 사람이 하던 리팩토링을 대신해줄 수는 없을 것입니다. 즉, TDD기법을 도입하기 위해서 기존 방식의 산술적인 계산법으로 더 이상 기간과 공수를 예측할 수 없습니다. 분명 시간과 비용이 터무니없이 증가할 것입니다.

아마도 우리나라에서는 TDD를 조직내에서 개발 방법으로 채택하는 곳은 없다고 봅니다. 우리나라에서는 소프트웨어의 생산 기간을 어떻게 줄일까에 집중하고 있기 때문에, TDD는 팀과 조직의 goal 에 방해 요소만 될 뿐입니다. 효용성 측면에서 TDD를 본다면 그저 빛 좋은 개살구로 보이기 쉽기 때문입니다.

애자일을 명목으로 스스로 족쇄를 차고있는 우리 조직

애자일이라는 이름과 이상적인 가이드를 이행하려는 조직에서 특히 불화음이 많을 것입니다. 그리고 그들은 애자일을 해 본 결과 애자일은 왜 실패하냐는 물음을 던집니다. 사실 애자일이 가지는 그 사상은 굉장히 높이 살만 합니다. 기존의 폐쇄적인 조직을 개방하려는 의지를 보인다는 것으로 시작하여 팀간의 커뮤니케이션을 향상시키도록 합니다.

그런데 애자일을 도입하려는 사람들은 큰 함정에 빠집니다. 팀을 위한다는 명목으로 너무 많은 것을 팀에게 강요합니다. 자신이 바라보기엔 좋은 기법들이 많고 팀에게 전파하려고 노력하겠지만, 팀은 이미 기존에도 잘 되고 있는 부분을 왜 뜯어고치려는지 이해할 수 없기 때문이죠. 팀에게 변화라는 명목으로 팀원들의 공감을 얻지 못한채로 강요를 시작하게 됩니다.

사실 애자일한 팀과 애자일한 프로그래밍을 위해 애자일은 아무것고 강요하지 않습니다. 그런데 누군가의 손에 애자일이 쥐어지면 은근히 강요로 변질되는 경우가 대부분입니다.

 

애자일 중에, 특히 XP(eXtreme Programming) 는 우리나라 실정이 전혀 반영되지 않았습니다. XP 의 여러가지 기법 중에 특히 코드 리뷰 와 짝 프로그래밍이 대표적이죠. 짝 프로그래밍은 짝이 되어 서로의 생각과 노하우를 전수해 주는 기법이지만, 필자로써는 '글쎄…'

필자는 오히려 짝 프로그래밍을 함으로써 개인 업무 시간을 너무 할애당한다는 생각이 듭니다. 필자가 메신저의 채팅보다 이메일을 좋아하는 이유도 여기에 있습니다. 업무 진행에 탄력을 받다가도 채팅으로 내 생각의 컨텍스트가 강제로 전환됩니다. 생각이 정리되지 않은 상대편이 타자를 치고있는 것을 멍하니 바라만 봅니다. 기술적인 것을 물어볼땐 답을 알려줘도 채팅이라는 특성상 한번에 한줄의 글로 모든 것을 표현하기가 힘듭니다. 만약 이메일이었다면 보낸 사람도 생각을 정리해서 보냈을테고, 또한 내가 보고싶을 때 보고, 명쾌한 MSDN 링크와 곁들여 오히려 짧은 시간에 높은 성과를 낼 수 있을텐데요...

결국 짝 프로그래밍은 그것을 성취한 후의 성과가 소비된 리소스에 비해 턱없이 낮으며, 짝 프로그래밍의 특성상 지속성을 유지하기에 한계가 있습니다.

 

또, 코드 리뷰를 진행하기 위해 다양한 기법들과 절차를 선보입니다. Self Review, Pair Review, Team Review 등 전혀 현실을 고려하지 않고 단지 그 기법들에 대해서만 매달리는 사람들이 많습니다. 특히 코드 리뷰는 도구를 이용한 자동화를 하지 않을 경우 있으나 마나한 기법입니다. 장기적으로 코드 리뷰는 형식적일 수 밖에 없습니다.

더 중요한 것은 코드 리뷰 기법이 아니라, 프로세스적으로 이것을 통제하여 코드 리뷰 책임자를 두는 것이 효과적일 수 있습니다. 보안이나 성능 등에 관련하여 코드 리뷰의 책임을 위임하고, 보안이나 성능 문제 발생시에 책임을 물을 수 있도록 체계화된 프로세스 말입니다.

사실 이런 면에서 기존의 애자일인 XP(eXtreme Programming) 이나 스크럼(Scrum) 보다 MSF(Microsoft Solution Framework) 가 기존 애자일 방법론을 현실적이고 수행가능하도록 체계화시킨 프로세스이기도 합니다.

   

입장이 서로 다른 애자일

대부분 현장에서 개발하시는 분들은 내 옆의 동료나 우리 팀보다 자기 개인이 더 중요할 것입니다. 개인 업무 성과가 팀과 조직이 나를 판단하는 기준이 대부분의 경우이기 때문입니다. 또 어떤 경우는 개발자의 특성상 발언권이 없는 경우도 있을 것입니다.

이에 반해 팀의 관리자의 평가는 자신이 관리하는 팀 전체의 성과가 조직이 관리자를 판단할 것입니다. 팀 프로젝트나 팀의 업무 성과가 낮다는 것은 관리자의 능력과 비례하기도 합니다.

 

결과적으로 애자일이라는 공통 분모로 애자일의 목표를 이루고자하는 시각이 전혀 다르다는 것이죠. 서투른 애자일은 팀원의 불만만 증가할 뿐, 팀원과 공감대를 이루기 힘듭니다. 관리자의 입장에서는 팀원간의 커뮤니케이션을 높이고 팀원 스스로 변화하길 기대하고 이것이 소리없는 강요가 될 수 있습니다.

   

애자일을 성공시키기 위해

앞서 이야기한 바와 같이 애자일이라는 목표와 사상은 굉장히 좋습니다. 그것이 팀과 조직뿐만 아니라, 개인, 가족, 단체, 사회, 국가적으로 비유해도 좋은 모델이 될 것입니다. 하지만 애자일, 특히 XP 가 이루는 그 구성 요소들은 조금은 허무맹랑한 것들이 많습니다. TDD나 짝 프로그래밍, 코드 리뷰 등 현실성이 부족한 것들을 이행하기를 권장합니다. 적어도 우리나라에서는 그것을 이행하기 위한 주변 여건이 좋지만은 않지요.

 

예전 트로이 목마라는 전쟁 이야기에서 나오듯이, 적진에게 해를 가하기 위해 트로이 목마를 적진에게 가져다 놓았습니다. 적진은 트로이 목마를 보며 마치 신이 주신 선물로 생각하겠지만 정작 트로이 목마는 적군에게 해가 되는 무시무시함을 가졌습니다.

과학에서 모든 물체는 현재 상태를 유지하려는 힘, 관성을 가지고 있듯이 우리의 팀과 조직도 마찬가지 입니다. 애자일도 마찬가지로, 그것이 좋아보인다고 자신의 팀과 조직에 구역구역 쑤셔넣다보면 상태를 유지하려는 관성을 가진 구성원과 바로 맞닿을 수 있습니다. (물론 애자일이 해를 가한다는 의미는 아닙니다)

   

 

애자일이 추구하는 여러 구성 요소는 짧은 반복으로 결과물의 품질을 높이고 결함을 줄이고자 합니다. 애자일의 대부분의 구성 요소는 짧은 반복으로 인한 높은 위험성을 줄이기 위한 보조적인 수단이라는 것입니다. 예를 들면, 스크럼(Scrum) 을 도입한다고 해서 대시보드와 붙이는 메모지를 준비하고, 매일 매일 스크림 미팅을 할 필요는 없습니다. 스크럼 미팅이라는 형식에 갇히는 순간부터 자멸의 길이라는것을 뒤늦게 깨닳게 될 것입니다. 즉 스크럼 미팅은 매일할 필요도 없으며 어떤 다른 모습으로 바뀔 수 있고, 동료와 담배를 피거나 커피를 먹으면서 알게 모르게 나타날 수도 있습니다. 어떤 경우는 상대편 알게 모르게 하는것이 자연스러운 참여에 도움이 되는 경우도 있지요.

결론적으로 팀과 조직, 구성원 개인의 차이를 인정하고, 팀과 조직의 문화를 최대한 존중하는 것이 성공하는 애자일이 되는 것입니다. 필자 또한 이것을 깨닿기까지 많은 시행 착오를 겪으며 애자일로 인한 물음표에 종지부를 찍을 수 있었습니다. 즉, 애자일로 스스로에게 족쇄를 차지 마십시오. 족쇄를 끊은 후에야 진정한 애자일이 당신의 곁에 있음을 느낄 수 있을 것입니다.

 

VSTS 2010에는 이전보다 더 지능적인 코드 검색을 위해 “Navigate To”라는 강력한 기능을 제공합니다.

 

“Navigate To”를 사용하려면 “Ctrl 키 + , 키”를 누르면 아래와 같은 다이얼로그 창이 나옵니다.

 

 

“Clear”을 입력하면 아래와 같은 결과가 나옵니다.

단순하게  “Clear”이 있는 위치만 알려주는 것이 아니고 Type, 메소드/프로퍼티 이름, 필드 선언, 파일 이름을 포함한 모든 것을 보여줍니다.

 

Result에서 표시된 항목에서 찾기를 원했던 것을 마우스 클릭을 하면(아니면 Tab 키로 이동하여 선택) 해당 코드를 보여줍니다.

 

 

 

 

기억이 안 나는 단어는 “fuzzy 검색”으로 찾기

 

“fuzzy 검색”이라는 것은 완전한 단어를 알지 못하지만 일부 단어만을 사용하여 검색 하는 것을 가리킵니다.

 

GetStreamID 라는 함수를 찾아야 하는데  “Stream” 이라는 단어만 생각난다면 이것을 입력하면 아래와 같이 출력됩니다.

 “Stream”이라는 단어를 사용한 모든 것을 다 보여줍니다.

 

 

 

“Pascal Casing” 규약으로 검색

 

닷넷 프레임워크에서는 type이나 메소드의 이름을 “Pascal Casing” 규약으로 짓기를 권유합니다. “Pascal Casing” 방식이라는 것은 여러 단어가 합쳐서 하나의 이름이 되는 것은 해당 단어의 첫 글자를 대문자로 하는 것입니다. “get”과 “stream”, “id”라는 단어를 붙여서 하나의 메소드 이름을 만든다면 “GetStreamID”로 됩니다.

 

“GetStreamID”라는 단어를 “Pascal Casing” 패턴으로 찾을 때는 “GSI”라는 단어만 입력하여 찾을 수 있습니다.

 

그런데 현재 RC 버전에서는 VC++의 경우는 제대로 지원되지 않습니다. VC++의 경우는 조금 더 입력을 해야 찾아집니다.

“GetStreamID”를 예를 들면 “GStrame”으로 검색을 하면 “GetStreamID”를 찾습니다.

안녕하세요. MFC 카테고리의 꽃집총각 입니다.
오늘은 MFC 카테고리가 아닌 'Windows 7 Development'에 포스팅을 하게 됐네요 :)

지난 3월 9일에 있었던 'Pro Developer를 위한 Windows 7 Technical Briefing' 행사에서 사용한
발표자료를 요청하시는 분들이 있어서 팀 블로그에 공개 합니다.
(주 : 웹에 게시한 위 자료는, 저작권에 관련한 문제가 있을 경우 삭제될 수도 있습니다.)

행사 당일의 모든 발표자료가 참석자 분들 전원에게 메일로 공유될 예정인 것으로 알고 있습니다.
이 점도 참고해 주시기 바랍니다 ^^

그리고, 세션 진행 시간 안에 마자 설명하지 못했던 부분 등을 보강해
멀티 터치 프로그래밍에 관한 포스팅을 팀블로그에 올릴 예정입니다.
많은 관심 부탁 드립니다.

감사합니다 ^^*