본 글을 월간 마이크로소프트 2012년 5월호 특집 기사로 다루어진 내용입니다. Visual Studio 11이 Visual Studio 2012로 변경됨에 따라 본문의 내용을 일부 수정하였습니다. 그리고 현재 필자는 NCSOFT에 재직하지 않음을 참고하기 바랍니다.


 

엄준일 – 현재 NCSOFT에 재직 중이며, Microsoft ALM MVP와 한국 Visual Studio 팀과 블로그를 운영하고 있다.. 주로 .NET 기술을 전파하고 있고, 마이크로소프트가 지향하는 소프트웨어 개발 프로세스와 통합 및 테스팅 분야를 4년 동안 공부해왔다. 그 외에 CodePlex 오픈 소스 사이트를 통해 프레임워크, 툴 그리고 라이브러리 등을 공개하여 운영 중이다.




 

성큼 다가온 Visual Studio 2012

Microsoft의 대표적인 통합 개발 도구인 Visual Studio 2012의 성장세가 무척 빠르다. 지난 10년전 .NET 플랫폼과 함께 대표적인 개발 도구인 Visual Studio.NET (2003버전)를 내놓았다. 그 때의 시간이 바로 엊그제 같은데 그 이후 Visual Studio 2005, 2008, 2010을 지나 Visual Studio 2012베타 버전을 필자가 사용하고 있으니, 짧은 10년동안 Microsoft를 비롯하여 개발 언어, 개발 툴, 이 모든 것이 굉장히 많이 변해 왔음을 새삼 다시 느껴진다. 이제 Windows 8라는 새로운 운영체제가 기다리고 있다. 그리고 이를 빛내줄 Visual Studio 2012.

 

성큼 다가온 Visual Studio 2012과 그 발자취

Visual Studio 2012를 먼저 논하기 전에 Visual Studio가 어떤 발자취를 남기며 발전해 왔는지 간단하게 살펴보는 것도 독자들이 Visual Studio 2012를 이해할 수 있는 좋은 방법이라고 생각한다. 물론 짧고 간단하게 모든 것을 설명할 수는 없지만, 전반적인 특징만으로 그 동안 개발 트랜드가 어떻게 바뀌었고, 시장의 요구 사항이 어떻게 변화하여 왔는지 한 눈에 알 수 있는 가장 좋은 방법이라고 생각한다.

 

Microsoft의 첫 번째 진정한 통합 제품으로 평가 받는 제품이 Visual Studio.NET (2003버전)이다. Microsoft의 전략적인 언어인 C# 1.0과 VB.NET(v7.0)이 .NET 개발의 대표적인 언어가 되었다. 기존의 VB를 세련된 객체지향 언어로 탈바꿈하면서 이전의 VB개발자들에게 .NET 개발의 문턱을 낮출 수 있는 매우 좋은 사례이기도 하다. (단, Visual Studio 2002는 논외로 하겠다)

이 이전의 개발도구는 하나의 도구에서는 하나의 언어로만 개발을 할 수 있었고, 개발 툴 역시 그 언어에 매우 종속적이고, 다른 언어로 전환하려면 이전의 개발 도구와 개발 경험 역시 많은 부분을 새로 습득해야 했다. 특히 J# 이라고 하는 Java 언어와 라이브러리를 제공하였는데, Java 개발자들을 .NET 플랫폼 안으로 끌어안기 위한 매우 독특한 사례이기도 하다. 실제로 J#은 웬만한 Java 소스 코드를 변경 없이 .NET 목적 파일로 컴파일 할 수 있었다.

Visual Studio는 하나의 개발 도구를 통해 여러 가지 언어를 선택하여 웹 응용 프로그램, 윈도우 응용 프로그램, 모바일 개발, XML, XML 웹 서비스를 개발을 통합하고, 여기에 포함되는 .NET Framework 1.0은 응용 프로그램을 빌드하고 실행하는 구성요소로서, ADO.NET, ASP.NET, Windows Forms 등을 포함하는 .NET Framework 클래스 라이브러리와 CLR(Common Language Runtime-공용 언어 런타임)을 제공, 이 CLR 을 통해 공통된 API 집합을 만들어 다양한 언어간의 상속, 오류 처리, 디버깅이 가능하며 개발자들은 사용하려는 언어를 자유롭게 선택할 수 있게 되었다.

이 후, Windows Server 2003 제품에 표준으로 탑재하여 .NET Framework의 확산에 큰 공을 이루게 되었고, 실제로 엔터프라이즈 시장에서 이 버전을 기준으로 많은 기업용 시스템에 도입이 되었다. 현재까지도 이 버전을 기준으로 운영이 되는 기업용 시스템이 상당수 존재하고 있을 정도이다.


 

때는 2005년. Visual Studio 2005버전은 파격 그 자체다. 여기에 포함된 런타임인 ..NET Framework 2.0은 이전 .NET Framework 1.x에 사용된 코드를 대부분 갈아 엎었을 정도이다. .NET Framework의 뼛속까지 변신한 것이다. ASP.NET 2.0, ADO.NET 2.0, Windows Forms 2.0, C# 2.0 과 같이 '~2.0' 이라는 버전 번호를 붙였고, 많은 기능이 보완되고 확장되었다. .NET Framework 2.0 의 주요 컴포넌트들은 더 이상 .NET Framework 1.1 에 의존하지 않게 되었으며, .NET Framework 2.0 은 .NET Framework 3.5 SP1 까지 .NET Framework의 모태가 된다.

모든 것이 생소할 정도로 많은 변신이 있었는데, 그 중에서 C#과 VB.NET 언어가 대표적이다. Boxing(박싱), Unboxing(언박싱)의 반복적인 캐스팅(Casting) 의 비효율을 개선하고, 보다 객체지향적인 코드 품질을 생산할 수 있는 제네릭(Generic)이 등장하였다. 이와 함께 .NET Framework 클래스 라이브러리에 다수의 제네릭(Generic) 클래스가 추가되었다. 개발 툴도 많은 변화가 있었는데, IDE 자체의 외관도 많이 변했고, 개발 툴의 내부적인 코드에서 변화가 왔고 다양한 내부 인터페이스가 추가되었다. Visual Studio의 솔루션 탐색기에서 흔히 사용하는 '솔루션 폴더'도 이때 등장하였다.

그리고, 이 제품의 버전부터 Visual Studio Team Suite + Team Foundation Server 의 제품을 조합하여 Visual Studio Team System(VSTS) 라는 새로운 개발 패러다임을 .NET 에서도 지원하게 되었다. VSTS 를 통해 ALM(Application Lifecycle Management-애플케이션 수명 주기 관리) 을 수행할 수 있게 되었으며, IT 조직의 비지니스 전반의 생산성을 향상 시키고, 사람과 개발 조직의 변화를 가져다 주는 시초가 되었다.


 

.NET Framework 3.0은 새로운 개발 도구와 출시되지 않았다. 2005년 중순 Windows Vista 운영체제가 출시되면서 이에 대응하는 라이브러리가 포함이 되었다. 함께 새로운 기술도 대거 포함이 되었는데, 그 중에서 대표적으로 꼽으라고 하면 WPF와 WCF이다. XAML(Extensible Application Markup Language) 과 함께 WPF 의 출연으로 UX(User Experience) 의 시대 흐름에 진입하게 되었다. 또한, WCF는 여러 가지의 분산 통신 기술이 통합되었다. 이전의 Remoting, XML Web Services, MSMQ 등이 하나의 WCF 컴포넌트에서 제공하게 됨으로써 Messaging Model 기반으로 통합할 수 있게 되었다.


 

 

 

때는 2007년, 또 한번의 메이저 급 업데이트였다 언어적으로 LINQ라는 새로운 녀석 때문이다. LINQ(Language Integrated Query) 라는 이름에서 알 수 있듯이 익숙한 SQL Query 문법과 유사하여 객체 탐색에 있어 효율성이 매우 높아졌고, 그 성능도 일일이 손으로 짠 코드보다 더 빠른 경우가 있다. 이 LINQ의 기반이 되는 람다식(Lambda Expression), 익명 타입(Anonymous Type), 확장 메서드(Extension Methods)의 언어적인 새로운 스팩이 한데 아우러져 LINQ를 구성한다. XML객체, DataSet, 파일 시스템, 컬렉션 등 모든 대상이 LINQ 쿼리식의 대상이 된다. 이에 영향을 받아 JavaScript와 Java 언어에 영향을 주어 LINQ와 유사한 프레임워크가 등장하였지만, .NET 과 같이 언어적으로 통합이 되지 않았다. 마치 Method Chaining 패턴을 이용한 라이브러리로 분류된다.

이 밖에 정말 헤아릴 수 없을 정도의 많은 진보가 있었다. 개발 도구와 개발 언어, 그리고 .NET 플랫폼의 기술이 발전한다는 것은 분명 매우 좋은 일이겠지만 아마 이 시기부터 많은 .NET 개발자들이 Microsoft의 기술 발전을 따라가기 벅차했었다.

 

2010년에 이르러, Visual Studio 2010버전이 출시되었다. 너무 빠른 .NET 기술의 발전의 탓일까, 이 때는 언어와 .NET Framework보다는 Visual Studio라는 개발 툴에 가장 초점이 맞추어졌다. 그 중 핵심 키워드라고 할 수 있는 것 3가지는 "시각화", "디버깅", "프로세스" 일 것이다. (필자의 의견이므로 Microsoft가 추구했던 것과는 다를 수 있다.) 이 세 가지의 핵심 키워드는 시각화, 협업에 있어 코드의 이해를 좀 더 쉽게, 그리고 복잡한 데이터를 한 눈에 알 기 쉽게… 디버깅-디버깅 시 데이터의 수집이 혁신적으로 발전하였고, 물리적으로 분리된 티어(Tier)간에 데이터 수집… 프로세스, 애자일을 강조하고 애자일한 통합 프로세스를 개발 툴에 제공.

.NET Framework 4.0은 .NET Framework 2.0기반이 아닌 새로운 프레임워크로 구성되었고, 멀티코어 처리를 위해 강력한 병렬 처리 라이브러리(Parallel Libraries)가 있다. 또, 동적 언어 런타임(Dynamic Language Runtime)으로 정적 형식과 동적 형식의 경계를 허물었으며, 루비(Ruby), Lisp, JavaScript, 파이썬(Phython), PHP와 같은 동적 언어와 상호 운용이 가능하다. 예를 들자면, C# 언어로 파이썬 개체와 상호 연동이 가능하다는 것이다.

 

  

제품의 버전 / 특징

2002년

  • Visual Studio .NET 2002 / .NET Framework 1.0 
    첫 통합 개발 환경 
    발매 당초의 제품명은 ' Visual Studio .NET 
  • C# 1.0 / Visual Basic .NET (7.0) 
    C# 은 마이크로소프트의 새로운 객체 지향 언어 
    Visual Basic 도 객체지향 언어

2003년

  • Visual Studio .NET 2003 / .NET Framework 1.1 (5월) 
  • C# 1.1 / Visual Basic .NET (7.1) 
    모두 버전 업 
  • Windows Server 2003 
    .NET Framework 1.1 표준 탑재

2005년

  • Visual Studio 2005 / .NET Framework 2.0 (12월) 
    ClickOnce 배포 
    제네릭 클래스 도입 
    ASP.NET 2.0, ADO.NET 2.0, Windows Form 2.0 
    리팩토링 기능 / 코드 스니펫 
    무료 Express Edition (C#, VB, C++) 
  • C# 2.0 / Visual Basic 2005 (8.0) 
    제네릭 대응 
  • Visual Studio 2005 Team System 
  • SQL Server 2005 지원

2006년

  • .NET Framework 3.0 (11월) 
    코어 부분은 .NET Framework 2.0 그대로 
    WPF(Windows Presentation Foundation) 
    WCF(Windows Communication Foundation) 
    WF(Windows Workflow Foundation) 
    CardSpace 
  • Windows Vista 
    .NET Framework 3.0 기본 탑재

2007년

  • Visual Studio 2005 Service Pack 1 (6월) 
  • ASP.NET AJAX 1.0 (추가 모듈) 
    AJAX Web Application 개발이 용이 
  • Expression Blend 
    Expression Studio 첫 제품 
    WPF 어플케이션의 GUI 구축
  • Visual Studio 2008 / .NET Framework 3.5 (11월 경) 
    개발 코드명 'Orcas' 
    WPF 의 GUI 설계 가능 
    Javascript 디버그 기능 및 IntelliSense 
    ASP.NET AJAX 표준 탑재 
    .NET Framework 2.0, 3.0, 3.5 선택 가능 
  • C# 3.0 / Visual Basic 2008 (9.0) 
    LINQ 기능 
  • SQL Server 2008 
  • Windows Server 2008 
  • Visual Studio Team System 2008

2008년

  • Visual Studio 2008 SP1 / .NET Framework SP1 
    ASP.NET Dynamic Data 
    ADO.NET Entity Framework / Data Services (Astoria) 
    WCF Atom Pub Services 
    클라이언트 프로파일(Client Profile) 
  • VSTS 
    Windows Server 2008 지원 
    SQL Server 2008 지원 
    성능 향상 및 개선 
  • Visual Studio SDK 1.1 (SP1) 
    Visual Studio Shell 재배포 패키지 경량화 
    DSL 출력 미리보기 등… 
  • Visual C++ 2008 
    오피스 리본 스타일 Interface 
    고급 GUI 컨트롤 등…

2010년

  • 사용자 친화적인 Visual Studio IDE
  • 코드 탐색 강화
  • 개발 툴에서 다양한 .NET Framework 개발 환경 제공
  • JavaScript 언어 개발 환경 강화
  • 다양한 플랫폼 지원
    • 64 Bit Mixed-Mode 디버깅
    • Managed 와 Mixed-Mode 의 Minidump 디버깅
  • Historical Debugger
    • 디버그 내용을 기록, 재생
  • 프로젝트 관리 및 프로세스 통합

 

 

Visual Studio 2012과 함께 매트로 앱 개발

Visual Studio 2012의 가장 큰 핵심은 바로 Windows 8 운영체제이다. Windows 8은 매트로 응용프로그램이라는 새로운 환경과 WinRT(Windows Runtime)인 새로운 런타임을 제공한다 그리고 Visual Studio 2012는 Windows 8 운영체제에 가장 최적화된 개발 툴이다. 독자들은 또 새로운 것을 배워야 하나라고 한숨을 쉴 수도 있을 것이다. 하지만 섣부른 독자들의 판단은 잠시 후에 하기 바란다. 왜냐하면 Windows 8 개발은 새로운 환경이면서도 새로운 환경이 아닐 수도 있다. Windows 8 운영체제를 사용하고 WinRT APIs 집합을 사용하는 것 이외에는 아무것도 변한 것이 없기 때문이다. 단지 바뀐 것은 여기에서 개발된 응용 프로그램은 데스크탑 컴퓨터, 테블릿, 모바일 환경 모두 실행되고 배포할 수 있다는 것이다.


최근 개발 환경을 엿보자면 C++을 사용하는 네이티브 개발과, NET에서 지원하는 C#과 같은 관리 언어, 그리고 웹 개발에 필요한 HTML과 JavaScript, 이 중에 단 한가지 기술 영역만 있으면 Windows 8 매트로 응용 프로그램 개발 준비는 끝이라는 것이다. 우리가 흔히 사용하는 스마트 폰을 보면 알 수 있듯이, 개발자는 단지 '위치 정보', '화면의 표현 방법', '데이터 연동', 그리고 스마트 폰을 가로로 볼 때와 세로로 볼 때와 같은 일상적인 기능을 제공하는 APIs를 익히기만 하면 된다. 기존에 Visual Studio를 사용하여 개발해 본 독자라면 그 만큼 진입 장벽이 낮다.


윈도우 폰7 개발처럼 테블릿 시뮬레이터가 제공이 된다. Windows 8 테블릿이 지원하는 대부분의 모든 기능을 이 시뮬레이터에서 테스트를 해 볼 수 있다. 윈도우 폰7 개발처럼 반드시 시뮬레이터가 필요한 것은 아니다. 실제 시뮬레이션이 필요 없다면 곧바로 로컬 데스크 탑에서 매트로 앱을 실행해 볼 수 있다.

Figure 1 Visual Studio 2012 매트로 앱 실행 및 디버깅

 

Figure 2 시뮬레이터 실행 환경

 

더불어 Visual Studio에서 제공하던 성능 측정 도구와 코드 정적 검사를 매트로 앱 개발 환경에서도 그대로 이용할 수 있다. 이는 곧 Visual Studio 2012이 Windows 8 개발에 가장 최적화가 되었다는 의미가 된다.

 

Figure 3 매트로 앱 성능 측정 및 진단

 

간략하게 나마 Visual Studio 2012과 Windows 8 개발에 대해 살펴보았다. 필자가 얘기한 것처럼 개발자에게 있어 새로운 환경이지만, 반대로 전혀 새롭지 않기도 하다. Visual Studio로 간단한 앱을 만들 수 있는 실력이라면 곧바로 Windows 8 매트로 앱을 개발할 수 있을 정도로 진입 장벽이 낮다. 물론, 좀 더 기술적이거나 독창적이고 예쁜 앱을 만드는 것은 더 많은 노력이 필요하다. 단지, 앱 개발자는 자신만의 앱 개발에만 집중하면 된다.

 

Figure 4 Windows 8 개발에서 배포까지

 

Visual Studio 2012과 함께 매트로 환경의 게임 개발

데스크 탑과 테블릿, 그리고 모바일 앱 중에서 단연 게임이 빠질 수 없다. 매트로 환경에서 게임 개발은 아직 시장이 포화되지 않은 장르이다. 그 만큼 게임 개발자에게 있어 매트로 환경에서 게임 개발은 매우 유혹적이기도 하다. 더 반가운 소식은 매트로 게임 개발에 필요한 지식은 게임 개발자에게 익숙한 C++언어와 DirectX다. DirectX를 이용하여 2D, 3D 게임을 개발할 수 있다.


얼마 전까지만 해도 Microsoft가 전략적으로 게임 개발을 지원하던 프레임워크인 XNA를 매트로 게임 개발에 지원하지 않는다. 대신 기존 게임 개발자에게 기존 개발 환경을 그대로 이어갈 수 있는 DirectX를 선택한 것이다.

Figure 5 DirectX 3D 샘플

Visual Studio 31 (1) - 시작, 그리고 Intellisense

Visual Studio 2010 2010. 11. 11. 09:00 Posted by 알 수 없는 사용자


안녕하세요~ 워너비입니다. 이번에 새로운 시리즈를 하나 시작하게 되었습니다. 이 시리즈는 이름하여 'Visual Studio 31'! 골라먹는 재미가 있는 아이스크림처럼, 비주얼 스튜디오 2010도 엄청나게 다양한 기능 속에서 필요한 기능을 골라쓰는 재미가 있습니다. 몰라서, 어려워서 못 썼던 기능이 있으시다면, 이 시리즈를 통해서 좀 더 친숙해지셨으면 하는게 이 시리즈의 목표입니다. 목표가 달성될지는 살짝 의문이네요 :)


- 오늘은 그 첫 시간.

자, 오늘은 Visual Studio 31의 첫 번째 시간으로 인텔리센스에 대해서 알아보겠습니다. 인텔리센스는 비주얼 스튜디오의 얼굴이라고도 할 수 있죠. 모든 개발자가 가장 많이 활용하며, 코딩에서 가장 편리함을 제공하는 기능이기 때문이죠. 이 인텔리 센스가 비주얼 스튜디오 2010에서 어떻게 달라졌을까요? 비주얼 스튜디오 2008의 인텔리센스와 Before/After를 비교해보도록 하죠 :)


- 관련있는 것들만 보여주는 쎈쓰!



차이점을 발견하셨나요? VS2008에서는 'Console'을 입력하면, 전체목록에서 'Console'과 정확히 일치하는 곳에 포커스를 둡니다. 그런데 포커스를 두기만 할 뿐, 아무런 것도 도와주지 않았습니다. 그런데 VS2010에서는 'Console'을 입력하면, 'Console'이 포함되는 것들만 추려서 인텔리센스에 보여줍니다. 인텔리센스가 많이 똑똑해졌죠? 이제 사용자에게 필요한 정보만 최대한 추려서 보여주는 거죠. 자, 그럼 인텔리센스의 쎈쓰! 가 여기까지 일까요?


- 이름의 일부로도 찾아주는 쎈쓰!


이번에는 어떤 차이점이 있을까요? 기존에는 정확하게 찾으려는 항목과 입력하는 항목의 시작이 같아야만 인텔리센스에서 해당항목을 찾아줬습니다. 그런데 저 처럼 기억력이 저주받은 사람들은 참 슬픈 코딩을 해야했죠. 다른 방법이 있을지도 모르겠지만, 초짜인 제가 했던 방법은 MSDN에 들어가서 얼추비슷한 키워드로 검색을 해서 찾는 방법이었습니다. 그런데 이제 VS2010은 저 같은 초짜&저주받은 기억력 세트를 가진 사람들을 위해서 사용자가 입력하는 문자를 포함하는 항목을 모두 보여주도록 향상되었습니다. 'Color'만 입력하더라도 VS2010은 'Color'가 포함되어있는 'ConsoleColor'를 찾아서 보여주는 거죠 :) 점점 마음에 듭니다.


- 파스칼 케이스로도 찾아주는 쎈쓰!

파스칼 케이스는 뭘까요? 일종의 네이밍 규칙인데요, 서로 다른 단어를 조합해서 메서드 이름을 만들거나 할때, 각 단어의 맨앞글자를 대문자로 표기하는 방법입니다. Console과 Color를 조합해서 'ConsoleColor'를 만드는 것 처럼 말이죠.


기존에는 위에서 설명드렸듯이 시작부터 정확하게 같아야지만 인텔리센스에서 항목을 찾을 수 있었습니다. 하지만 똑똑해진 VS2010에서는 파스칼 케이스의 각 대문자만 입력해도 찾아준다는 거죠. 'CC'를 입력했다면, 'CC'가 직접 포함되는 항목부터, 'C'가 파스칼 케이스로 연속 두번 포함되는 항목도 모두 찾아서 보여줍니다. 이름이 긴 항목을 자주 찾는다면 매우 편리하겠죠 :)


- 없는 클래스도 보여주는 쎈쓰!

TDD를 하려고 할때나, 먼저 코드의 윤곽을 짜놓고 필요한 클래스를 생성하는 식의 프로그래밍을 할때는 존재하지 않는 타입의 객체를 생성해서 사용하게 됩니다. 이런 방식은 어느정도 장점도 가지고 있는데요, 우선 생성하고 하는 클래스의 구체적인 부분에 대해서 생각하는 대신에, 지금 짜려고 하는 코드의 흐름에 우선적으로 집중할 수 있기 때문입니다. 코드의 흐름에 집중하다가, 클래스를 정의하려고 하면 집중의 전환이 일어나기 때문에 그만큼 비효율적인 작업이 될 수도 있습니다.


존재하지 않는 App라는 클래스의 객체를 생성하려고 하면, 기존 버전에서는 전혀 인텔리센스의 지원을 받을 수 없었습니다. 그래서 일일이 쌩코딩을 해야 했었죠. 하지만, VS2010이 출동한다면? 존재하지 않는 타입이라고 하더라도 일단 new를 만나면 존재하는 타입인 것 처럼 인텔리센스에서 보여줍니다. 많이 편리해졌죠~? :)


- 개발자의 취향에 따라 맞춰가는 쎈쓰!



위 Before/After는 모두 VS2010의 캡쳐입니다. 무슨 차이점이 있을까요? Before에서는 입력하는 것과 일치하는 항목에 강조가 되어있고, After에서는 맨위에 별도의 칸이 한칸 추가되어 있으며, 인텔리센스에 강조가 약하게 되어있다는 점이 차이점입니다. After에서 볼 수 있는 것이 VS2010의 인텔리센스에서 제공하는 '서제스천 모드'를 사용한 것입니다. 바로 검색 사이트의 검색창을 떠올리시면 됩니다. 거기서 검색어를 입력하면, 입력하는 검색어와 가장 비슷한 항목을 보여주지만 그 항목이 검색어를 입력하는데 아무런 영향을 주지는 않습니다. 선택하지 않으면 그만이라는 거죠. 그러면, 둘은 어떤 차이가 있을 까요? 기본적인 인텔리센스와 서체스천 모드를 사용한 인텔리센스에서 'App'를 입력하고 Space키를 눌러보면 그 결과를 확인할 수 있습니다.

App라는 클래스는 존재하지 않기 때문에, 기본 모드에서는 가장 비슷한 AppDomain을 선택해버립니다. 하지만, 서제스천 모드에서는 추천항목을 보여줄 뿐, 사용자의 입력에 관여하지 않기 때문에 그냥 App그대로 남은 걸 보실 수 있습니다. 서제스천 모드를 사용하려면, 코드 편집창에서 'Ctrl + Alt + Space'를 누르면 됩니다. 그리고 서제스천 모드에서 기본 모드처럼 추천 항목을 입력하고 싶으면 'Tab'키를 누르면 됩니다 :)


- See you next time :)

오늘은 첫 시작으로 인텔리센스에 대해서 알아봤습니다. 앞으로도 계속해서 골라먹을 수 있는 비주얼 스튜디오 2010의 기능에 대해서 소개해 드릴예정이오니~, 기대해주시기 바랍니다. :)

Visual Studio 2010 RC 공개

Visual Studio 2010 2010. 2. 9. 11:41 Posted by POWERUMC

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

Visual Studio 2010 RC(Release Candidate) 공개
http://msdn.microsoft.com/en-us/vstudio/dd582936.aspx

 

이전 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월달 정식 제품이 더욱 기대가 되는 하루입니다. ^^

Architect Development ?

Architect Development 2009. 7. 21. 18:04 Posted by 알 수 없는 사용자


Architect Development 을 위하여 무엇을 해야 할가요?
아니 Architect Development 이란 영역은?

우리가 흔히 개발을 한다고 하면 보통 요구사항 분석, 설계, 개발, 테스트 및 디버깅, 배포를 끝으로 그 다음 유지보수를 합니다. 유지보수에서는 개발, 테스트 및 디버깅 재배포 등의 단계를 거치게 됩니다.
그렇다면 여기서 앞 부분은 요구사항 분석, 설계 부분은 유지보수에서 빠지는 것일까요?

답은 " 아닙니다 " 겠죠? 그렇다면 요구사항 분석, 설계 부분이 빠지는 이유는 개발이 완료되고 배포되어 사용자가 사용하고 있는 중에 문제가 오류가 발생하여 개발자 분들이 수정하고 다시 테스팅 및 디버깅 후 배포하는 것입니다. 프로그램이 사용중에 오류가 발생하지 않고 고객 또는 사용자가 새로운 기능을 요구하였을 경우에는 어떻게 할까요?

여기서 옛날에 했던 요구사항 분석, 설계 부분을 돌아보게 됩니다. 그러면, 제가 지금까지 보아온 회사 중에서는 설계가 잘되어 있고, 요구사항 분석도 잘 되어 있어 모든 것이 일사 천리로 일이 진행 된것을 볼 수 있었습니다. 그렇지 않은 회사를 보면 어떻게 될지는 이 글을 읽는 개발자 분들이 더 잘 아실거라 생각합니다. 그럼 아키텍쳐 개발은?

아키텍처란 용어는 영한 사전에서보면  일반적으로 "건축, 천축술, 천축 양식, 구조"라고 번역합니다. 그렇다면국어사전은? 기능 면에서 본 컴퓨터의 구성방식이라고 설명합니다.(네이버 국어사전 참조) 여기서 아키텍쳐란 구조, 구성이라는 용어로 한번 보겠습니다.

구조, 저희가 개발하는 시스템에 대한 정확인 요구사항에 맞는 분석과 이를 기반으로 정확한 구조, 구성이 된 설계가 있다면 어떨까요? 이 설계의 기본적인 구조는 Windows 플랫폼에 PHP 개발, 아니면 ASP.NET 개발등으로 예를 들어 보고, 기본적인 구조를 정확히 정의하고 이를 표현할 수 있으며, 많이 사용하는 방법으로 표시하여 개발자들과 협업, 의사 소통이 이루어 질 수 있다면 어떨까요?

전 이 해답을 Visual Studio Team System(VSTS) 에서 찾았다고 생각합니다. 제가 MS 쪽 제품 중에 VSTS를 좋아하는 이유 중에 바로 Architect Development이 가능하게 해준다는 것입니다. 다른 제품 쪽도 있고 저 역시 다른 사이트에서 많은 자료를 봅니다.(다른 사이트의 Meet the Experts등 여러 사이트가 있습니다. 단 영어 입니다 ㅠ.ㅠ)

옛날 VSTS는 업계가 많이 사용하는 UML를 지원하지 않고 다른 모델링 도구등을 이용한 설계를 할 수 있도록 했습니다. 기능은 매우 훌륭했지만... 많은 사용자가 이것을 사용했을까 하는 것입니다. 지금은?

VSTS 에서도 이제 UML도 지원한다..

그럼? 네 Visio 같은 도구로 그림을 그리는 것이 줄어들었다는 것입니다. 그리고 VSTS에 통합되므로써 개발자들과의 의사소통, 협업이 가능하다는 것이 매우 좋아졌다는 겁니다. 프로젝트에서 대부분 아키텍쳐는 무시되고 요구사항이 수시로 바뀌는 등등 매우 많은 일들이 생겨나는데 이것을 대응할 수 있다는 것입니다.
업계에서 많이 사용하는 UML은 학교에서 S/W를 전공한 사람은 모두 한번씩 배웠던 것이고, 이를 이용하여 개발자들과 협업을 통해 고객의 요구사항을 능동적으로 대처할 수 있고, 실제 설계에 반영할 수 있습니다.

이런 매우 좋아진 이 VSTS 2010에 대하여 이제 부터 제가 하나씩 하나씩 알아보고 여러 분들에게 소개를 하겠습니다. ^^ 다음 은 그럼?? VSTS 2010의 모델링 개발에 대하여 이야기 하겠습니다.

지난 번 포스팅에서 말씀 드렸던 것처럼 Visual Studio Team System 2010에서 이루어진 Code Analysis 기능 개선에 대해서 더 깊게 다뤄 보겠습니다. 그 첫 번째로 새롭게 추가된 Rule Sets 개념에 대해서 알아보도록 하겠습니다.


Visual Studio 2005, 2008에서의 코드 분석 설정

Visual Studio의 코드 분석 시스템에는 약 200개 정도의 규칙이 있습니다. 하지만, 사실 이 규칙들을 모두 준수를 해야 하는 것은 아닙니다. 모든 규칙이 나름의 이유와 정당성을 갖고 있다고 해도, 프로젝트의 성격에 따라, 모듈의 성격에 따라서 꼭 지켜야 할 규칙, 그렇지 않은 규칙, 심지어는 어쩔 수 없이 위반해야 하는 규칙도 있을 수 있습니다.

그래서 코드 리뷰를 할 때, 대부분의 경우 모든 규칙을 다 검사하지는 않습니다. 각각 케이스 바이 케이스로 규칙을 적절하게 조절하게 됩니다.

Visual Studio Team System 2005와 2008 버전에서는, 이런 설정을 Visual Studio Project Configuration에서 각 프로젝트 별로 할 수가 있습니다.

이 규칙 설정은 프로젝트 파일(.vbproj 혹은 .csproj)에 CodeAnalysisRules라는 Property 이름으로 아래와 같이 저장되게 됩니다. 내용을 보면 아시겠지만, “-“ 기호와 규칙 ID를 붙여 놓은 모양으로 되어있습니다. 즉, 거기에 열거된 규칙 ID를 Analysis Rules에서 빼는 형태로 저장이 되는 것입니다. 아래 샘플은 그래서 이 프로젝트는 코드 리뷰를 할 때에 Design Rule의 CA1000번 규칙을 검사하지 않는다라는 의미가 됩니다.

<CodeAnalysisRules>-Microsoft.Design#CA1000</CodeAnalysisRules>

이런 형태로 Visual Studio 프로젝트마다 다른 규칙을 적용할 수 있다는 것은 대단히 유연한 디자인이긴 하지만, 많은 수의 Visual Studio Project가 존재한다면, 관리가 참으로 어렵습니다. 그래서 예전에 Visual Studio Team System 2005 를 사용했던 프로젝트에서 전체 Visual Studio 프로젝트의 분석 규칙들을 통일하기 위해서, 개별 개발자들에게 위임하지 않고 제가 직접 모든 프로젝트를 텍스트 에디터로 열어서 저 부분만 Copy & Paste로 넣어서 Check-In하는 엄청난 단순 반복 작업을 한 적도 있습니다.

 

Visual Studio Team System 2010의 Rule Sets Feature

그래서 새롭게 출시될 Visual Studio Team System 2010에서는 Rule Sets라는 개념이 도입되었습니다. 이 Rule Sets 기능은 이름에서도 알 수 있듯이 Rule들을 미리 정해진 Set으로 관리할 수 있는 기능입니다. 이제 Visual Studio 프로젝트 별로 Rule을 하나 하나 빼는 수고를 할 필요가 없이 Visual Studio 프로젝트에 Rule Set을 지정하는 것으로 Code analysis를 커스터마이징할 수 있게 된 것입니다. 아래 그림에서 볼 수 있듯이, 하나 이상의 Rule Set을 선택하는 것도 가능합니다. (가장 아래의 Choose Multiple Rule sets를 선택하면 됩니다.)


Visual Studio Solution 전체에 Rule Set을 적용하는 것도 가능합니다. Solution Property에서 아래와 같이 설정할 수 있습니다.

 

위 그림에서 보시는 것처럼 마이크로소프트는 기본적으로 7개의 기본 Rule Set을 제공합니다. 이 기본 Rule Set의 목록은 다음과 같습니다.

  • Microsoft All Rules – 전체 Rule이 모두 포함된 Rule Set입니다.
  • Microsoft Basic Correctness Rules – 로직 에러와 자주 저지르는 실수를 예방하는 규칙들로 이루어진 Rule Set입니다.
  • Microsoft Basic Design Guideline Rules – Framework API 작성 상의 Best Practice에 집중된 Rule Set입니다.
  • Microsoft Extended Correctness Rules – Basic Correctness Rules를 확장하여, COM Interop이나 Mobile Application에도 사용 가능하도록 만들어진 Rule Set입니다.
  • Microsoft Extended Design Guideline Rules – Basic Design Guideline Rules를 확장해서, 사용성이나 유지 보수성도 체크할 수 있도록 만들어진 Rule Set입니다.
  • Microsoft Globalization Rules – Application의 Globalization에 있어서 문제가 있는지 검증하는데 집중된 Rule Set입니다.
  • Microsoft Minimum Recommended Rules - MS가 제안하는 최소한의 Rule Set입니다. 50개 정도의 규칙으로 이루어져 있습니다. 다른 대부분의 Rule Set들이 이 Rule Set을 포함하고 있습니다.
  • Microsoft Security Rules – 이름 그대로 보안에 집중된 Rule Set으로, 모든 Security 관련 규칙들이 모두 포함되어 있습니다.

 

물론 이 외에도 사용자가 직접 Rule Set을 편집할 수 있습니다. Rule Set은 .ruleset이라는 확장자를 가지는 XML 파일 포맷으로 되어 있습니다. 기본적으로 Visual Studio 2010에서 아래와 같은 UI를 통해서 편집할 수 있도록 되어 있습니다.


 

아래는 Rule Set 파일을 직접 Notepad로 열어본 것입니다.

<?xml version="1.0" encoding="utf-8"?>
<RuleSet Name="Microsoft Basic Correctness Rules" Description="These rules focus on logic errors and common mistakes made in the usage of framework APIs. Include this rule set to expand on the list of warnings reported by the minimum recommended rules." ToolsVersion="10.0">
  <Localization ResourceAssembly="Microsoft.VisualStudio.CodeAnalysis.RuleSets.Strings.dll" ResourceBaseName="Microsoft.VisualStudio.CodeAnalysis.RuleSets.Strings.Localized">
    <Name Resource="BasicCorrectnessRules_Name" />
    <Description Resource="BasicCorrectnessRules_Description" />
  </Localization>
  <Include Path="minimumrecommendedrules.ruleset" Action="Default" />
  <Rules AnalyzerId="Microsoft.Analyzers.ManagedCodeAnalysis" RuleNamespace="Microsoft.Rules.Managed">
    <Rule Id="CA1008" Action="Warn" />
    <Rule Id="CA1013" Action="Warn" />
    <Rule Id="CA1303" Action="Warn" />
    <Rule Id="CA1308" Action="Warn" />
    <Rule Id="CA1806" Action="Warn" />
    <Rule Id="CA1816" Action="Warn" />
    <Rule Id="CA1819" Action="Warn" />
    <Rule Id="CA1820" Action="Warn" />
    <Rule Id="CA1903" Action="Warn" />
    <Rule Id="CA2004" Action="Warn" />
    <Rule Id="CA2006" Action="Warn" />
  </Rules>
</RuleSet>

 

Team Foundation Server Check-In Policy

이 Rule Set 기능은 Team Foundation Server의 Check-In Policy에도 쓰이게 됩니다.

 

맺으며..

이번 Rule Set Feature를 통해서 확실히 이전 버전보다는 Code Analysis를 사용하는 것이 쉬워지고 편리해진 것 같습니다. 하지만, Code Analysis에서 중요한 것은 편의성보다는, Rule의 문제라고 생각됩니다. 그런 면에서 아직 FxCop이 처음 나왔을 때의 200개 정도의 Rule에서 많은 추가가 없다는 것은 굉장히 아쉽습니다. 특히 직접적인 경쟁 제품이라고 볼 수 있는 Compuware의 DevPartner Code Review가 처음 버전부터 600개 이상의 Rule을 가지고 있다는 점에 비교해 본다면 더욱 그렇습니다.

이어지는 포스팅에서는 새롭게 Code Analysis에 추가된 Phoenix 엔진과 그에 따라 다시 복귀한 Data Flow 관련 규칙들에 대해서 한 번 알아보겠습니다.

Visual Studio Team System 2005 에서 코드 분석(Static Code Analysis) 기능이 처음 소개된 바가 있습니다. 이 코드 분석은 Microsoft에서 제안하는 닷넷 프레임워크에서의 디자인 가이드라인과 성능이나 보안, 신뢰성 등의 요소에 대한 Best Practice 등으로 이루어진 200개 이상의 Rule을 기반으로 Code를 검사하고 결함을 발견해 줍니다.

 

원래 이 Code Analysis는 FxCop이란 이름의 독립된 툴로써 세상에 먼저 선을 보인 바 있습니다.

이 FxCop이 Visual Studio 2005 Team System에서 통합되면서 현재의 코드 분석 기능이 나오게 된 것입니다. 실제로 비주얼 스튜디오에서 코드 분석 기능을 담당하는 실행 파일의 이름은 아직도 FxCopCmd.exe입니다.

앞으로 나오게 될 Visual Studio Team System 2010에서는 현재까지 알려진 바로는 다음 세 가지 부분에서 코드 분석의 기능 향상이 이루어 졌습니다. (출처: http://blogs.msdn.com/fxcop/archive/2008/10/30/new-code-analysis-features-in-visual-studio-2010-september-08-ctp.aspx)

  1. Rule Sets – 드디어, 규칙을 프로젝트 별로 하나 하나 빼던 수고스러움을 덜 수 있게 된 것 같습니다. DevPartner Code Review와 같은 상용 툴에서는 진작에 제공되던 기능이었지만, 이제 드디어 Visual Studio 2010에서는 Rule들을 Set으로 만들고 그 Rule Set 기반으로 코드 리뷰를 할 수 있게 되었습니다.
  2. Check-In Policy – 당연한 말이겠지만, 바로 위에서 소개한 Rule Sets 기능이 Team Foundation Server의 Check-In 정책에도 적용할 수 있게 됩니다.
  3. 8개의 새로운 Data-Flow 규칙MSDN Code Gallery의 VS2005와 VS2008 코드 분석 비교 문서를 보시면 아시겠지만, VS2008에서 7개의 규칙이 빠진 바 있습니다. Data-Flow Analysis Engine의 각종 버그와 낮은 성능으로 말미암은 결과라고 하는데, 이번 Visual Studio Team System 2010에서는 Phoenix라는 새로운 분석 엔진의 탑재와 함께 다시 7개의 규칙들이 복귀했고, 새롭게 추가된 하나를 합쳐서 총 8개의 새로운 규칙이 추가되었습니다. 그리고 이번에 추가된 Phoenix 분석 엔진은 당연히 기존 엔진이 가지고 있었던 버그나 성능 문제를 해결한 새롭고 강력한 엔진입니다.

그러면 다음 포스팅을 통해서 이 세 가지 개선점들에 대해서 더 자세히 다뤄보도록 하겠습니다.

안녕하세요. 이번에 Visual Studio Team System 2010 공식 블로그에 새롭게 참여하게 된 LazyDeveloper.Net의 kkongchi라고 합니다. Better Code 시리즈를 통해서 Code Analysis, Unit Test 등에 대한 포스팅을 해보도록 하겠습니다. 부족한 부분 많이 지적해 주시길 바랍니다.

 

TDD?

eXtreme Programming의 창시자 중 하나인 Kent Beck의 eXtreme Programming explained라는 책을 보면 Test를 작성하는 방법에 대해서 이렇게 기술하고 있습니다.

  • If the interface for a method is at all unclear, you write a test before you write the method. (메서드의 인터페이스가 클리어하지 않다면, 메서드를 작성하기 전에 테스트를 먼저 작성해라)

  • If the interface is clear, but you imagine that the implementation will be the least bit complicated, you write a test before you write the method. (메서드의 인터페이스가 클리어하더라도 당신이 생각하기에 구현이 조금 복잡할 것 같다면, 메서드를 작성하기 전에 먼저 테스트를 작성해라)

  • 이런 eXtreme Programming의 Test-Before-Writing 전략을 개발 프로세스에 전면적으로 도입하는 것을 Test Driven Development, 즉 TDD라고 합니다. TDD에 관한 위키피디아 페이지에서 소개하는 TDD의 개발 사이클은 다음과 같습니다. “Red, Green, Refactor”라고 표현하기도 합니다.

    다들 아시다시피, Visual Studio에서는 2005 버전에서부터 Team System의 일부로써 Testing Framework을 제공하고 지원해왔습니다. 그리고 드디어 이번 Visual Studio Team System 2010에서는 완벽하게 TDD의 개념이 Visual Studio Team System안으로 녹아 들어가게 된 것 같습니다. 바로 새롭게 추가된 기능 “Generate” 기능을 통해서, Test를 먼저 작성한 후에 그 Test로부터 코드를 자동으로 Generate해주는 기능이 추가된 것입니다.

     

    TDD Development in VSTS 2010 by “Generate”

    지난 11월에 나온 Visual Studio 2010 and .NET Framework 4.0 Training Kit의 Lab을 통해서 이 기능에 대해서 좀 더 자세히 알아보도록 하겠습니다.

     

    당연히 먼저 테스트를 작성하는 것부터 시작합니다. 하지만, 아직 만들어지지 않은 클래스이기 때문에 아래 그림처럼 빨간색 물결 라인으로 경고가 뜹니다. 여기서 마우스 오른쪽 버튼을 눌러보면, 새로운 “Generate” 기능을 볼 수가 있습니다.

    Generate class를 선택하면 같은 프로젝트에 Class가 추가됩니다. 하지만 Generate other..를 선택하면 아래와 같은 팝업 윈도우가 나옵니다. 클래스를 만들 수 있는 Wizard 개념이라고 보시면 되겠습니다.

    이 Wizard를 통해서 클래스의 Access 한정자, Type, 그리고 파일을 만들 프로젝트까지 설정을 할 수가 있습니다. 이 과정을 통해서 우리는 완벽하게 Test로부터 시작해서 뼈대 코드를 만들어 낼 수가 있습니다. 아래 그림처럼 말이죠..

    이제 이 자동으로 만들어진 뼈대 코드에 구현을 추가하게 되면 여러분들은 다음과 같이 Test를 통과했다는 기분 좋은 화면을 보실 수 있으실 것입니다.


    위에서 보신 Demo Code의 시연은 http://channel9.msdn.com/shows/10-4/10-4-Episode-5-Code-Focused-in-Visual-Studio-2010/#Page=4 에서 Video로도 감상하실 수 있고, http://www.microsoft.com/downloads/details.aspx?FamilyID=752CB725-969B-4732-A383-ED5740F02E93&displaylang=en 에서 Lab Document와 소스 코드도 얻으실 수 있습니다.
     

    지금까지 보신 것처럼 앞으로 출시될 VSTS 2010에서는 IDE 자체에서 완벽한 TDD 지원 기능이 통합되었습니다. TDD가 만능의 도구는 아닙니다. 하지만, 적어도 개발자가 자신의 코드에 대한 이해도가 통상적인 개발 방법보다는 훨씬 크고 깊을 것이라 기대합니다. 어설픈 문서보다는 잘 만들어진 테스트 코드들이 오히려 실제 구현 코드를 이해하는 데 더 도움이 되는 경우도 많습니다. Visual Studio Team System 2010은 효율적인 Test Driven Development를 가능하게 해주는 최고의 도구가 될 것 같습니다.

    부족한 글 읽어주셔서 감사하고, 많은 의견 부탁 드립니다.

    Welcome to F#(2) - 두번째 만남.

    F# 2009. 4. 8. 23:40 Posted by 알 수 없는 사용자

    -애프터
    첫번째 만남이 끝난뒤에, 어떻게 애프터를 이어나가야 할지 무처이나 고민했습니다. 첫만남이야 가볍게 서로의 얼굴도 보고, 성격도 맛보는 정도에서 끝난다지만 애프터에서는 서로에 대해서 천천히 자세히 알아가야 할텐데, 갑자기 참여중인 프로젝트의 상황이 악화되서 시간이 잘 나지 않고, 이해부족과 실력부족이 겹쳐서 어떻게 글을 계속 써나가야할지 고민이 많았습니다. 그러다가 직장동료에게 물어봤습니다.

    "만약에 튜토리얼을 쓴다면, 어떻게 쓰는게 좋을까?"
    "글쎄, 나는 그런게 좋던데. 왜 작은 예제에서 시작해서 하나씩 추가되어 가면서 설명해주는 그런거 있잖아."

    이거다 싶었습니다. 그래서 제 내공이 받쳐줄지는 모르겠지만, 최대한 예제를 통해서 F#과의 애프터를 진행해볼까 합니다. 언제나 그렇듯이 제 글에 어색하거나 잘못된 내용이 있을수 있으니 언제나 따뜻한 피드백으로 격려해주시기 바랍니다.(말씀드렸듯이 차가운 피드백은 바로 반사-_-) 그럼 일단 애프터 장소로 가서 F#을 좀 더 만나보도록 하죠~.

    -F#에서는 타입을 안쓰는거 같더라?
    일단 F#에서 타입을 결정하는데 쓰이는 타입유추(Type Inference)에 대해서 알아보겠습니다. 타입유추는 F#에서만 쓰이는 개념은 아닙니다만, 저 같이 함수형언어에 친숙하지 않은 경우에는 생소함을 느끼게 됩니다. 우선 아래와 같은 예제를 작성해서 아래 두줄을 드래그 해서 F# Interactive로 보내보죠. F# Interactive를 띄우는 방법과 F# Interactive로 보내는 방법은 잊지 않으셨죠? 잊으셨다면, 이전 포스트를 참조해주세요~.

    #light

    let count = 1
    printfn "%d" count


    실행결과에 대해서 이야기 하기전에 #light에 대한 설명을 조금 드리자면, 지난 포스트에서 말씀드린 것 같이 이 지시어는 F#에서 좀더 간략한 문법을 사용할 수 있도록 해줍니다. 그런데, 이런 키워드를 명시적으로 꼭 선언해야 하는 이유는 다음과 같습니다. F#은 OCaml으로 부터 영감을 받아서 설계되고 핵심적인 부분중에 일부분을 공유하고 있씁니다. 그리고 OCaml의 코드를 컴파일할 수 있는 기능을 갖추고 있는데, 간단한 OCaml코드의 경우는 수정없이 컴파일 가능하게 되어있습니다. 그래서 그 경우를 위해서 #light라고 명시해줘야만 F#의 간단한 문법이 적용되는 것입니다.

    그러면, 다시 소스코드로 넘어가서 그 소스의 결과는 아래와 같습니다.

    val count : int
    1
     
    즉, 한줄씩 평가 돼서 그 결과가 나오는 건데요, 첫번째 줄은 count라는 value를 선언했고 그 타입은 int라는 말입니다. 그리고 그 다음줄은 count의 값을 출력한 결과인거죠. 눈치 빠른 분이라면, 아마 여기서 뭔가를 눈치채셨을 겁니다. 타입을 정해주지 않았는데, count의 타입이 int라는걸 문맥을 통해 유추해냈습니다. 그리고 아래의 printfn의 출력패턴을 보면 "%d", 즉 C와 동일하게 정수형값을 출력하겠다는 말인데요, 앞의 평가식에서 count가 정수형이라는 걸 유추해냈기 때문에 에러없이 1을 출력하고 프로그램을 종료합니다. 이런걸 타입 유추라고 부릅니다.(원문으로는 Type Inference인데, inference에 대한 딱히 다른 용어를 찾지 못해서 일단 유추라고 하겠습니다.-_-)

    타입유추는 코드를 분석해서 제약사항들을 모아서 이루어집니다. 여기서 제약사항이란, 매개변수가 가질 수 있는 타입을 명시해줌으로써 제약을 가하는 개념인데요, 문맥에서 타입을 유추할때 +,-,*,/같은 경우는 기본적으로 매개변수를 int타입으로 유추됩니다. 그리고 아래의 예제들을 F# Interative에 평가해보죠.

    let printInt x = printfn "%d" x

    let printString x = printfn "%s" x

    그러면, 아래와 같은 결과가 나오죠.

    val printInt : int -> unit

    val printString : string -> unit

    즉, 문맥상 정수형을 출력하니까 x는 int형이 된거고, 문맥상 스트링을 출력하니깐 x는 스트링으로 유추된 거죠. 그리고 아래의 예제를 더 보시죠.(그리고 참고로 unit은 많은 분들이 기대하시는 것 처럼 unsigned int는 아니구요, 정확하게 같진 않지만 void를 나타내는 F#의 타입입니다.-_-)

    let plusplus x = (x + x)
    let plusplus2Times (x) = plusplus x + plusplus x
    -----결과----
    val plusplus : int -> int
    val plusplus2Times : int -> int

    그리고 아래와 같이 바꿔서 다시 평가해보죠.

    let plusplus x = (x + x)
    let plusplus2Times (x:float) = plusplus x + plusplus x
    -----결과----
    val plusplus : float -> float
    val plusplus2Times : float -> float

    역시 사용되는 문액에 따라 plusplus를 호출하는 plusplus2Times에서 int형 x를 넘겨주면, plusplus의 매개변수도 int타입이 되고, float을 사용하겠다고 타입에 제약을 정해주면(즉, 매개변수 x가 될 수 있는 타입에 명시적으로 제약을 주는 것) 그에 따라서 plusplus에 넘어가는 매개변수와 리턴타입역시 그에 따라 float타입으로 유추되는 것을 볼 수 있죠. 즉, F#에서는 타입을 명시해줄 수도 있지만, 이런 작업을 직접 해주지 않으면 기본적으로는 타입유추를 통해 타입을 알아내고 적용한다는 겁니다.

    -타입유추라는거 왠지 불안해보이는데?
    이런 생각을 해볼 수 있습니다. '과연 이렇게 컴파일러가 타입을 추측해주는게 무슨 장점이 있는거냐?' 이 포스트에서 관련된 내용을 많이 찾아볼 수 있었습니다. 저자는 타입유추의 광팬이로군요. 언제든지 C#같은 언어에서 제공하는 var타입이나 익명메서드등을 사용해서 자기 대신 컴파일러가 타입에 대한 문제를 다루도록 한답니다. 즉, '타입유추는 타입안정성을 해치지 않고 그저 컴파일러가 대신 타입을 찾을뿐이다', '타입을 일일이 적지 안아도 되니깐 리팩토링시에도 편리하다', '타이핑을 줄일 수 있다'랍니다. 그리고 반론도 만만치 않습니다. 아주 긴 댓글로 서로 의견을 주고 받고 있군요. 즉, 한마디로 좋다 나쁘다를 정할 수 없는 취향의 문제인것 같기도 합니다.(우주 끝날때까지도 결론이 안 날문제들이 바로 취향에 관련된 문제죠-_-)

    -F#은 어떤 타입이야?
    그리고 타입이야기가 어쩌다 새어나왔으니, 타입을 한번 적어보겠습니다.
     타입  예  설명
     int  int  그냥 32비트 정수입니다.
     type option  int option, option<int>  선언된 타입의 값이 있거나, 혹은 값이 없는 걸 의미하는 None을 가집니다. Optional parameter와 비슷한 개념입니다.
     type list  int list, list<int>  선언된 타입의 immutable한 값들의 linked list입니다. 리스트의 각 값들은 [5;2;88]처럼 같은 타입을 가져야 합니다.
     type1 -> type2  int -> string  함수타입입니다. 즉, type1을 받아서 결과값으로 type2를 리턴한다는 거죠.
     type1 * ... * typeN  int * string  한쌍(a pair), 두쌍 그리고 그 이상의 타입들의 조합이 가능한 튜플타입입니다. (1, "3")같은 경우 말이죠.
     type []  int[]  배열타입이죠. 1차원이고, 고정된 크기의 mutable한 값들의 모음입니다.
     unit  unit  하나의 값을 나타내는 ()을 나타내는데, 명령형 언어의 void와 비슷한 의미입니다.
     'a, 'b  'a, 'b, 'Key, 'Value  제네릭하게 어떤 타입이든지 올 수 있는 변수타입입니다.

    Expert F#에 나오는 예제를 마지막으로 보겠습니다.

     String.split [' '] "hello world"

     String.split ['a';'e';'i';'o';'u'] "hello world"

    일단 위의 코드를 F# Interactive에 보내서 평가해보면 "The value, constructor, namespace or type 'split' is not defined. A construct with this name was found in FSharp.PowerPack.dll,......"이런 에러가 뜹니다. 즉, String클래스에 split이라는 값이나, 생성자, 네임스페이스 혹은 타입이 존재하지 않는데, FSharp.PowerPack.dll에서 발견이 되었다는 친절한 메세지 입니다. CTP버전으로 오면서 많은 기능이 FSharp.PowerPack.dll로 옮겨졌기 때문입니다. String은 Microsoft.FSharp.Core.String을 참조하는데요 Microsoft.FSharp안에 있는 Core,Collection,Text,String같은 네임스페이스는 String.split이나 open String같이 한 단어로 참조가 가능하고 합니다. 이럴땐, FSharp.PowerPack을 참조추가해줘야겠죠. 참조추가후에 open 지시어를 통해서 해당 네임스페이스의 내용을 알아내야 하는데, F# Code에선 기본적인 Core나, Operators, Collections같은 네임스페이스는 암시적으로 open을 한다고 합니다. 그리고 비주얼 스튜디오가 아닌 F# Interactive에서 참조추가를 하려면, 아래 처럼하면 됩니다.

     > #r "FSharp.PowerPack.dll";;

    --> Referenced 'C:\Program Files\FSharp-1.9.6.2\bin\FSharp.PowerPack.dll'


    그리고 다시 F# Interactive로 보내서 평가해보면 아래와 같은 결과나 나옵니다.

     val it : string list = ["hello"; "world"]
    >
    val it : string list = ["h"; "ll"; " w"; "rld"]

    이 예제에서 ' ', 'a'는 그냥 문자고, "hello world"같은건 문자열, ['a';'e';'i';'o';'u']는 문자의 리스트, ["hello"; "world"]는 문자열의 리스트라는 걸 알 수 있습니다.

    -애프터의 만족도는?
    변명이지만, 시간도 조금은 부족했고, 아는것도 부족하다보니 포스트의 내용이 썩 만족스럽지는 못한 것 같습니다. 애프터가 만족스럽지 못하셨다면, 제탓이 가장크겠군요-_-. 그래도 마음에 드신분이 있다면, 몇번 애프터를 더 해보고 손이라도 잡아봐야 겠죠. 다음번엔 이어서 기본적인 타입에 대해서 좀 더 알아보고, .NET공원에서 놀이기구를 몇개 타보는 걸로 해볼 생각입니다. 그리고 이번포스트에서 제대로 조사하지 못한 부분역시 조사해볼 생각입니다. 데이트장소는 고전적이긴 하지만 놀이공원도 괜찮죠. 그럼 도움이 되는 분들이 있길 바라면서 다음 포스트에서 뵙겠습니다.

    -참고자료
    1. Expert F#, Don Syme, Adam Granicz, Antonio Cisternino, APRESS.
    2. http://research.microsoft.com/en-us/um/cambridge/projects/fsharp/manual/spec2.aspx#_Toc207785764
    3. http://blogs.msdn.com/jaredpar/archive/2008/09/09/when-to-use-type-inference.aspx

    Welcome to F#(1) - 첫만남.

    F# 2009. 4. 5. 20:58 Posted by 알 수 없는 사용자

    What is F#?
    F#에 대해서 들어본 적이 있으신가요? 아니면, Functional programming language 혹은 함수형 언어라고는 들어본적이 있으신가요? 아마도 최근에 부각되었었던 Erlang이나 기존의 Lisp, Scheme등을 들어보셨거나, 공부해보신 분이라면 알고계시리라 생각합니다. F#은 닷넷에서 돌아가는 함수형언어이고 현재 CTP(Community Technical Preview)버전이 공개된 상태입니다. 차후에 VSTS 2010에 포함되어서 나올 예정이구요. 


    함수형 언어는 왜 배워야 하는데?
    C#이나 Java와 같이 입력을 받아서 어떻게 그걸 처리할지 주저리주저리 이야기 해줘야 하는 언어는 명령형 언어(Imperative programming language)라고 합니다. 하지만, 그와 반대로 어떻게 할건지 보다는 무엇을 처리할지에 더 관심을 두는 형태를 선언형 언어(Declarative programming language)라고 합니다. 정규식이나 함수형언어 같은 언어가 포함되지요. 예를 들어보면 정규식같은 경우는 어떤 패턴을 잡을지에 관심이 집중되어 있습니다. 하지만, 어떻게에 대해서는 관심이 없지요. 즉, 명령형 언어와 선언형 언어는 서로 관점이 틀리기 때문에 서로 유용하게 쓸 수 있는 분야도 틀릴 수 있다는 것입니다.

    물론, Anders Hejlsberg가 JAOO의 강연에서 이야기 한것처럼 함수형언어와 기존의 명령형언어(Imperative programming language)는 서로 다른 장점이 있기 때문에, 어떤 상황에서 어떤 언어를 선택하는 것이 옳은지 명확하게 이야기 할 수 는 없습니다. 하지만, 함수형언어는 나중에 더 자세히 다룰 수 있겠지만 Immutable, 즉 한번 값을 입력하면 다시는 값이 변경될 수 없는(C#에서 readonly를 생각하면 되겠죠.)걸 이야기 하는데, 이때문에 병렬적으로 실행되는 환경에서 흔히 문제가 되는 여러 스레드가 하나의 값에 접근할때 값이 잘못변경될 위험이 없습니다. 그래서 병렬 프로그래밍에서 가장 유용한 프로그래밍 모델로 생각되고 있으며 실제로 얼마전에 Erlang이 이슈가 되었던 것도 그런이유 때문이었던 것 같습니다.

    근데 왜 F#을 공부해야 하는데?
    개인적으로는 점차 플랫폼의 영향력이 커진다는 느낌을 받습니다. 그리고 기존의 플랫폼에 워낙 많은 기능이 이미 구현되어 있고, 그런 언어의 실행환경에 대해서는 신경을 쓰지 않고, 자신의 언어가 가질 특징들에 집중해서 새로운 언어를 만드는 것도 점차 중요해지는 것 같구요. 꽤나 히트했던 Ruby가 JRuby와 IronRuby로 자바와 닷넷에 각각 편입되는 것을 보더라도 그런 것 같습니다. 단순히 플랫폼의 덕만 보는게 아니라, 그 플랫폼에서 사용되는 다른 언어들과도 교차적으로 사용될 수 있다는 점도 꽤나 큰 이익이 아닌가 생각합니다. 이 주제에 대해서 잘 설명을 해주신 장성진님의 글을 읽어보시면 더 좋을 것 같습니다.

    F#을 배워야 하는 이유는 하나의 어플리케이션을 개발할때, C#을 메인언어로 놓고 개발하면서 F#으로 개발했을때 이익이 되는 부분이라면, F#으로 개발해서 조합을 할 수 있겠죠. 저 역시도 그런 가능성을 가장 기대하고 있습니다.

    앞으로의 방향은 어떻게 되니?
    개인적으로 기존에 Scheme을 공부해본적이 있긴하지만, 워낙 잠깐이라 딱히 많이 아는건 없습니다. 그래서 공부해가면서 고민해가면서 여기에 적어볼 생각입니다. 그래서 내용이 엄밀하지 못하거나 심도가 없을 수도 있는데, 그런부분은 피드백으로 잘 훈계해주시면 완전 감사하겠습니다.

    F#을 설치해보자
    시작이 반이라고 했으니, F#을 설치하면서 빨리 반을 끝내보도록 하죠. F#은 현재 CTP버전이 나와있고, 비주얼 스튜디오 2008에서도 사용할 수 있습니다. 그리고 비주얼 스튜디오가 없더라도 명령행툴이 있기 때문에, 거기서 작업을 하면서 공부하실 수 있습니다. 물론 비주얼 스튜디오가 있음 더 편하겠죠. 일단 여기에서 F# CTP버전을 받을 수 있습니다. msi파일을 받아서 실행하시면 되구요, zip파일은 윈도우가 아닌 운영체제에서 압축을 풀어서 readme를 보라고 하는데, 별로 보고싶지 않아서 확인은 안 해봤습니다.(역시 글로쓰면 농담이 안살아나는 군요-_-)

    F#과 만나서 Hello를 외쳐보자
    Hello를 외치려면 일단 만나야 겠죠. 그럼, F# Interative를 실행해보죠. 그러면 아래와 같은 창이 하나 뜹니다.


    궁금한게 있으면 #help;;를 쳐보라는 친절한 말까지 남겨주시죠. 여기서 우리는 F# Interative에게 뭔가 부탁하려면 '# + 부탁할내용 + ;;'을 해야 한다는 사실을 알 수 있죠. 참고로 F# Interactive에서 나가게 해달라고 부탁하는 말은 "#quit;;"입니다. 그러면, 언제나 처음 언어를 접하면 서로 인사를 나누어야 하니 Hello World를 한번 외쳐보도록 하죠.



    위와 같이 한번 쳐보시죠. let HelloWorld~~;;는 선언부이고, 그 아래는 함수호출 결과입니다. 언어가 다르다 보니 모양도 좀 틀립니다. 우선 F# Interative에서는 하나의 의미를 갖는 문장이 끝난다는걸 ';;'을 통해 알립니다. 그래서 위문장은 ';;'를 만날때 까지 하나의 단위로 인식해서 함수를 선언해주는 것이고, 아래 문장은 호출이라는 것을 파악하는 것이죠. 그러면 이제 나가게 해달라고 부탁하시고 비주얼 스튜디오에서도 Hello World를 외쳐보도록 하겠습니다.


    새프로젝트를 눌러보시면 윗 그림과 같이 Visual F#이 추가된걸 보실 수 있습니다. 그럼 프로젝트를 생성해서 아래그림 처럼 코드를 쳐보시죠.



    그리고 정말 친숙한 명령 Ctrl+F5를 누르면, 정말 친숙한 콘솔창에 아래 그림과 같이 결과가 나옵니다.(너무 친숙해서 마치 집에 있는거 같군요. 이래서 집나가면 개고생이라나 봅니다.)



    그리고 비주얼스튜디오에서 F# Interative창을 띄워서 평가하고 싶을때는 아래 그림과 같이 "보기 -> 다른 창 -> F# Interactive"를 눌러줍니다.



    그러면, 아래 그림과 같이 하단부에 F# Interactive가 뜨게됩니다.



    그리고 이제 비주얼 스튜디오에서 작업한 내용을 F# Interactive에서 확인해볼 수 있습니다. F#같은 함수형 언어에서는 모든 코드가 컴파일되는 것이 아니고 한줄 한줄 평가(Evaluation, 혹은 그냥 Eval)하게 되는데요, 작업 부분중에 평가 해보고 싶은 부분만 드래그해서 F# Interative에서 결과를 확인해볼 수 있습니다. 평가하는 방법은 우선 평가하고 싶은 부분을 정확하게 드래그 해서 마우스 오른쪽 버튼을 누르고 "Send to F# Interative"를 누르거나 "Alt + Enter"를 누르시면 됩니다. 아래 그림은 함수선언부를 먼저 F# Interactive로 보내서 평가하고 그 다음에 함수호출부분을 다시 평가해서 얻은 결과물입니다.



    이제는 우리가 헤어져야 할시간, 다음에 다시 만나요
    자 이제, F#과의 첫 인사를 마쳤습니다. 어떠셨나요? 제가 실력이 부족하고 글솜씨가 딸려서 좀 설명이 부족한 부분이나, 틀린 부분이 있을 수도 있습니다. 그럴땐 따뜻한 피드백으로 화답해주셨으면 좋겠습니다.(차가운 피드백은 반사하겠습니다-_-) 저 역시 아직 함수형언어 자체에 대한 이해도 부족하고, F#도 잘 아는 상태가 아니라서 인지 앞으로 어떻게 계속 글을 이어나가야 겠다는 명확한 생각은 없는 상태고 그저 글을 계속 쓰면서 정해나갈 생각입니다. 다음번 포스트에서는 간단한 예제를 통해 F#에 대해서 좀 더 자세한 설명을 드리고 명령형언어와 함수형언어의 차이에 대해서 좀 더 알기 쉽게 설명해볼까 하는 생각을 갖고 있습니다.(말이 길어지면, 둘중 하나만 하고요-_-) 이 글이 도움이 되는 분들이 있길 바라고, 다음 포스트로 뵙겠습니다.

    참고자료
    1. Expert F#, Don Syme, Adam Granicz, Antonio Cisternino, APRESS.
    2. http://blog.java2game.com/229
    3. http://jaoo.blip.tv/file/1317881/
    4. http://en.wikipedia.org/wiki/Functional_programming
    5. http://en.wikipedia.org/wiki/Imperative_programming
    6. http://en.wikipedia.org/wiki/Declarative_programming