안녕하십니까? Visual C# MVP / Windows Azure Cafe SYSOP / DEVPIA C# Forum SYSOP / Visual Studio 2010 한국 공식 팀 블로그 멤버 남정현입니다.
2010년 9월 13일부터 15일까지 열리는 Korea Games Conference (KGC) 2010에서 13일 오전 10시 30분에 오디토리움 101에서 진행되는 세션을 맡게 되었습니다. Windows Azure Platform과 소셜 게임이라는 주제를 바탕으로, 클라우드 컴퓨팅, Rich Internet Application 기술의 결합과 발전 방향성을 한 시간 동안 설명할 예정입니다. 또한, 이날 오전 세션은 Visual Studio 2010 한국 공식 팀 블로그의 DirectX 및 Agile Development 부문 전문가분들의 세션이 연속으로 진행되므로 관심있으신 분들께서는 함께 해주시면 감사하겠습니다. :-)
관심있으신 분들의 많은 참석을 부탁드리며, 여러모로 의미있는 시간이 되었으면 합니다. 감사합니다. :-)
Microsoft PDC (Professional Developer Conference)는 매년 Microsoft의 주최로 열리는 세계적인 규모의 개발자 컨퍼런스 행사로, Microsoft의 최신 기술들을 가장 완벽한 형태의 내용으로 접할 수 있는 최고의 리소스입니다. 올해도 어김없이 열립니다. :-D
Microsoft 본사가 있는 미국 레드먼드에서 2010년 10월 28일부터 10월 29일 이틀간 열리는 이번 PDC10 행사에서는 크게 세 가지 주제를 바탕으로 세션들이 배치되고 트랙이 나뉘어지게 됩니다. Windows Azure Platform에 대한 새로운 업데이트와 고급 응용프로그램 개발 전략을 소개할 Cloud Track, 곧 베타 버전 발표를 앞두고 있는 Windows Internet Explorer 9과 여기에 맞추어 지원될 HTML 5, 그리고 조만간 정식 출시를 눈앞에 두고 있는 Windows Phone 7 Series에 대한 다양한 내용을 소개할 Client Track, 그리고 작년 PDC09 행사에 이어서 ASP.NET MVC 3, Razor, Web Matrix, Visual Studio LightSwitch와 같이 새롭게 소개되는 Framework에 연관되어있는 다양한 기술들을 소개할 Framework Track으로 구성될 예정입니다. 아래는 미국 현지 시간 기준 전체적인 행사 Agenda입니다.
Wednesday, October 27, 2010
7:00pm – 9:00pm: Welcome Reception - Microsoft Visitor's Center, Bldg 92
아쉽게도, 이미 행사 좌석이 모두 가득찬 상태라서 오프라인 행사를 직접 즐기실 수는 없겠지만, 온라인 생중계 서비스와 향후 PDC10이 종료된 이후에라도 주문형으로 비디오를 시청할 수 있도록 스트리밍 서비스를 계속 이어 나갈 예정이라고합니다. 생중계 서비스는 키노트 세션이 열리는 2010년 10월 28일 오전 9시부터 시작될 예정이며, 한국 시간으로는 2010년 10월 29일 오전 1시부터 PDC10 웹 사이트에서 보실 수 있습니다.
반복문을 사용할 수 있다는 점은 상당히 중요한 부분입니다. 배치 파일의 경우도, 열거할 수 있는 대상이 있고, 이를 정확하게 열거하고 제어할 수 있으려면 반복문이 당연히 필요합니다. 이를 돕는 명령어가 바로 for 문인데 간단히 다음의 예시를 살펴보기로 하겠습니다. 아래는 한데 묶여있지 않고 각각 분리된 build.xml 파일을 한꺼번에 컴파일하기 위한 목적으로 작성된 배치 파일의 예시입니다. W 은행의 전산 시스템을 자동화하기 위하여 1년전 처음 작성하였으며, 최근 C 은행의 닷넷 프레임워크 기반 프로젝트 (이 때는 msbuild를 호출하기 위함이었습니다.) 에서도 비슷한 이유로 재사용한 적이 있는 저만의 snippet입니다. :-)
@rem Java Source 컴파일 도구
@rem 작성일 - 2010년 8월 14일
@rem 작성자 - 남정현
@rem 명령줄 입력을 숨깁니다.
@echo off
@rem 화면을 초기화합니다.
@cls
@echo Java Source 컴파일 작업 시작
@echo.
@rem /d 스위치는 디렉터리 반복 시 사용합니다.
@rem 배치 파일 내에서 변수 선언을 전달하려면 이스케이프 처리를 해야 합니다.
@rem if 문은 아래 명령과 같이 여러 줄 입력이 가능합니다.
@rem ant 명령이 실패하는 경우 Jakarta Ant Build System이 PATH에 등록되어
@rem 있는 상태인지 확인해야 합니다.
@for /d %%i in (*.*) do @if exist "%%i\build.xml". (
@echo 처리 중: "%%i"
@ant -buildfile "%%i\build.xml"
@echo.
)
@echo on
위의 부분에서 굵게 표시한 부분이 배치 파일 상에서의 for 문의 사용 예시입니다. 배치 파일 안에서 for 문을 사용하기 때문에 조금 변수명에 이스케이프 처리를 위해서 % 지시자를 한번 더 사용한다는 특이 사항만 제외하면 무난한 문법구조를 나타내고 있습니다.
for 문 바로 뒤에 오는 /d 스위치는 열거할 파일 시스템 대상 객체를 디렉터리만으로 한정하는 것으로 이 스위치를 생략할 경우 파일명이 해당 경로상에 존재할 때 같이 열거됩니다. 그 다음, 변수명, 검색할 객체 이름의 패턴 (DOS 방식이므로 전형적인 와일드 카드 패턴을 따릅니다)과 수행할 명령을 do 지시자 다음에 지정합니다. 배치 파일 안이므로 당연히 여러줄의 명령을 한번에 그룹으로 묶을 수 있습니다. 만약 /d 스위치 대신 /f 스위치를 사용할 경우 파일만이 열거될 수 있습니다. 그 외에 /r 스위치를 사용하여 재귀 탐색을 할 수 있고, /l 스위치를 사용하면 우리가 일반적인 프로그래밍 언어에서 사용하는 인덱스 기반 탐색을 위한 카운트 증감 (증가 및 감소 모두 포함됩니다.)을 수행할 수도 있습니다.
@rem 아래 명령은 시작값 1 부터 종료값 5까지 1씩 더하며 반복됩니다.
@rem C 언어로 번역한다면 for (int i = 1; i <= 5; i += 1) 과 같은 의미입니다.
@for /l %%i in (1,1,5) do @echo %%i
@rem 아래 명령은 시작값 5 부터 종료값 1까지 1씩 빼면서 반복됩니다.
@rem C 언어로 번역한다면 for (int i = 5; i >= 1; i -= 1) 과 같은 의미입니다.
@for /l %%i in (5,-1,1) do @echo %%i
보너스: Unix 및 Linux Build Script에서 흔히 사용하는 Stack 기반 Directory 탐색 구현하기
일반적으로 cd 명령 - 혹은 - chdir 명령은 forward only 탐색으로 드라이브를 바꾸거나, 전혀 다른 위치로 갑자기 이동하게 되는 경우 과거로 되돌아갈 근거가 없습니다. 그리고 DOS 기반의 명령이므로 UNIX와 같은 기능은 제공하지 않을 것이라는 일반적인 선입견까지 더해지면서 이런 기능이 "없는 것"으로 분류되기도 합니다만 실제로는 이런 기능이 NT 인터프리터에 존재합니다.
다음의 명령어를 한 번씩 실행해보면 Stack 기반의 탐색이 어떤 의미를 지니는지 아실 수 있습니다.
@rem 참고로 아래에 \ 기호가 더 붙은 이유는 %systemdrive%가 C: 까지이므로 경로임을 표시하기 위해 \를 붙여 C:\로 인지시키기 위함이었습니다.
@pushd %systemdrive%\
@pushd %windir%
@pushd %programfiles%
@popd
@popd
@popd
현재 위치가 어디이든 관계없이 첫 번째 pushd 명령으로 인해서 %systemdrive%\ 경로로 이동하고 내부 스택에 주어진 경로가 Push됩니다. 두 번째 pushd 명령으로 %windir%가 그 뒤를 이어서 내부 스택에 Push되며, 마지막으로 %programfiles% 경로가 내부 스택에 Push됩니다. 여기까지는 출력 결과만으로 놓고 보았을 때 cd 명령과 차이가 없어 보입니다. 그러나 popd 명령을 사용하면 차이가 나타납니다.
popd 명령을 처음 실행하면, 가장 마지막에 내부 스택에 들어갔던 %windir%가 Pop되고 현재 디렉터리로 변경됩니다. 그리고 다시 popd 명령을 실행하면 이번엔 %systemdrive%\로 현재 디렉터리가 변경됩니다. 그리고 다시 popd 명령을 실행하면 원래 위치로 되돌아가는 것을 볼 수 있습니다.
여기서 중요한 점은, 지금 스택에 집어넣고 빼낸 디렉터리들이 원래 위치했던 디렉터리 기준으로는 제각기 독립적인 노드들이었다는 점이며, 디렉터리를 스택 구조에 넣고 관리할 수 있으므로 배치 파일에서 탐색이 자유로워질 수 있다는 이점을 확인할 수 있습니다.
문법: for /r "검색할 디렉터리" %v in (*.확장자) do find /N /I "검색할 키워드" "%~fv" >> "결과를 저장할 파일 혹은 장치"
예시: for /r "C:\Windows" %v in (*.txt) do find /n /i "Windows" "%~fv" >> "%userprofile%\result.txt"
마무리
보잘것 없어보이는 수단이지만, 때로는 PowerShell을 검토하는 것보다, VBScript를 검토하는 것보다, 그리고 우리 프로그래머 입장에서는 C++이나 C#을 검토하는 것보다 배치 파일에 기대는 것이 더 편할 수 있습니다. 파리를 잡기 위하여 패트리어트 미사일을 날리지 말고, 가까이 있고 쉽게 사용할 수 있는 도구를 여러분의 친구로 만들기를 바라며 소소하게 써내려간 시리즈를 뒤늦게나마 마무리합니다.
Jetty (http://jetty.codehaus.org/) 프로젝트는 자바 기반의 오픈 소스 웹 서버로, HTTP 서버로서의 역할과 서블릿 컨테이너의 기능을 제공합니다. 정적, 동적 컨텐츠를 모두 지원하고, 독립적으로 실행할 수도 있고, 다른 프로세스에 부착되어 실행되는 기능 또한 제공됩니다. 이러한 특성을 바탕으로, Apache Project의 ActiveMQ, Cocoon, Hadoop, Maven Project, BEA Web Logic Event Server, Eucalyptus, FioranoMQ Java Messaging Server, Google AppEngine 및 안드로이드, Eclipse용 웹 툴킷 플러그인, 레드햇 J보스, Sonic MQ, 스프링 프레임워크, 사이베이스 EA서버, 짐브라 데스크톱 등 광범위하게 Jetty가 채택되고 있습니다.
Jetty 프로젝트는 아래와 같은 기능들을 제공합니다.
비동기 HTTP 서버
표준 지향의 서블릿 컨테이너
웹 소켓 서버
비동기 HTTP 클라이언트
OSGi, JNDI, JMX, JASPI, AJP 지원
응용프로그램 컨테이너의 관점에서 보면, Jetty는 전통적인 Java 기반의 Web Application Server들 (Tomcat과 같은)을 대치하는 배포 방법으로 사용될 수 있으며, 스프링 프레임워크 및 관련된 모든 파생 프로젝트들, EJB 컨테이너 등 대부분의 일반적인 웹 기반 자바 어플리케이션을 손쉽게 제공할 수 있는 것이 특징입니다.
그러나 위에서 언급하는 Tomcat만이 Windows Azure 환경에서 사용할 수 있는 유일한 Web Application Server의 종류는 아닙니다. 사실, 위의 접근 방법들은 모두 Windows Azure Role에 함께 첨부되어 배포되는 Java 실행 환경 (JRE)를 기초로 하는 것이고, 그러므로 어떤 종류의 Java 패키지이든 관계없이 명령줄을 통하여 Classpath를 명시하는 방식으로 실행될 수 있습니다. 대개의 경우, 작업자 역할 (Worker Role) 패키지 위에서 실행되도록 디자인되고, Windows Azure 환경으로 배포될 수 있습니다. 그리고, 당연한 이야기이지만 Java와 Fast CGI를 결합하고, IIS 7.x를 기반으로 Fast CGI를 지원하는 Web Role을 이용할 수도 있습니다. 이 부분은 나중에 좀 더 자세히 소개하도록 하겠습니다.
Windows Azure 환경에서 Jetty 실행
아래는 실제 Windows Azure 환경에서 Jetty를 기반으로 실행하는 Windows Azure Worker Role의 구동 예시입니다.
위와 같이 구현하기 위한 방법을 지금부터 차례대로 따라해보기로 하겠습니다.
1. Windows Azure Worker Role 프로젝트를 만들고, Worker Role 진입점 메서드인 Run 메서드의 중심부에 다음과 같이 프로그래밍합니다.
제가 이전에 게시한 글 "[Software Development/Windows Azure] - Windows Azure 들여다보기"에서 언급한 내용들을 참조하여 위의 코드를 보시면 이해하기 쉽습니다. 몇 가지 Windows Azure 환경에서 기본으로 제공되는 환경 변수, 디렉터리 설정 등을 바탕으로 Jetty 프로세스를 Java VM (java.exe)를 통하여 실행하도록 명령어를 구성하고 실행한 다음, 표준 출력의 내용을 Windows Azure Worker Role Process로 가져오도록 만드는 것을 볼 수 있습니다.
2. Jetty 프로젝트와 Java VM의 최신 버전을 Windows Azure Worker Role 프로젝트에 추가합니다.
다음 그림과 같이 폴더를 구성하면 되겠습니다. jetty7 폴더와 jre6 폴더 아래에 직접 해당 프레임워크 및 시스템의 실제 디렉터리 구조가 오도록 맞추면 문제 없습니다. 참고로, 확실하게 동작할 수 있도록 만들기 위하여 Java VM의 경우는 특별히 Windows Platform을 기반으로하는 x64 아키텍처 버전을 다운로드하여 아래 그림과 같이 넣어두어야 합니다. (중요)
3. ServiceDefinition.csdef 파일 수정하기
1단계에서 사용한 HttpIn이라는 설정을 Worker Role에 추가해야 하므로, ServiceDefinition.csdef 파일을 찾아 "WorkerRole" 요소 아래에 다음과 같이 내용을 추가하고 저장합니다. 참고로 이 설정은 Windows Azure Worker Role이 80번 TCP 포트 통신이 필요함을 Windows Azure 환경 내의 방화벽에게 통지하기 위한 목적으로 사용됩니다.
Jetty가 사용되거나 환경 설정을 만드는 방법은 Windows Azure 환경에서 여러 가지가 있을 수 있지만, 특별히 이와 같이 Worker Role 위에서 Standalone Server로 동작하기 위하여 필요한 환경 설정이 있어서 이를 소개합니다. Windows Azure 환경에서는 Jetty가 기본으로 사용하는 NIO ChannelConnector 대신 BIO SocketConnector를 사용하도록 구성해야 합니다. NIO ChannelConnector에서는 내부적으로 루프백 연결을 기초로 하지만 Windows Azure 환경에서는 이것이 가로막혀있기 때문이라는 것이 David Chou의 설명입니다.
이러한 설정을 수정하기 위해서는 Jetty 패키지 디렉터리 아래의 etc 디렉터리의 jetty.xml 파일을 수정해야 하며, <New> 태그의 class attribute를 org.eclipse.jetty.server.nio.SelectChannelConnector 대신 org.eclipse.jetty.server.bio.SocketConnector로 변경하고, NIO ChannelConnector에만 한정되는 몇 가지 옵션을 제거하는 방법으로 변경이 가능하며 정리하면 다음과 같습니다.
그리고 좀 더 최적화된 설정을 위하여, Jetty가 자체 로그를 기록하지 않도록, etc 디렉터리의 jetty.xml 파일에서 RequestLog 핸들러 부분을 주석으로 처리하고, 확장자가 war인 패키지의 압축을 풀지 않도록 etc 디렉터리의 jetty.xml 파일에서 addBean "org.eclipse.jetty.deploy.WebAppDeployer"의 "extract" 프로퍼티의 값을 "false"로 지정하고, contexts 디렉터리의 test.xml 파일에서 <Set name="extractWAR"> 부분의 프로퍼티 값을 "false"로 지정하였다는 것이 저자의 설명입니다.
Windows Azure Platform이 Microsoft의 기술이므로 철저히 .NET Framework 기반의 응용프로그램 개발만을 지원할 것이라는 편견은 종합적으로 "잘못된 것입니다." Windows Server 2008 R2의 기술을 기반으로 하고 있기 때문에, 여러분의 응용프로그램이 Windows Server 2008 R2, 그리고 64비트 환경에서 성공적으로 수행될 수 있는 조건을 갖추고 있다면 Windows Azure Platform은 성공적으로 여러분들의 클라우드 컴퓨팅으로의 계획을 이끌어 줄 수 있을 것입니다.
최근에 VS2010 Live에서 소개된 Visual Studio LightSwitch라는 신 제품에 대해서 블로그 포스팅을 조촐하게 해봅니다. Visual Studio LightSwitch는 기존의 Visual Studio Express Edition과는 별도로 구분되는 제품으로 매우 신속하고 빠르게 새로운 형태의 소규모 데이터베이스 시스템과 통합하거나, 기존의 WCF RIA Service, SQL Server Database 등과 상호 작용하면서 C/R/U/D (Create/Read/Update/Delete) 및 검색 기능, Office 연동 기능을 지원하는 Rich Application의 생산을 가능하게 해주는 개발 도구입니다. Visual Studio LightSwitch는 2010년 8월 23일 이후부터 베타 버전으로 처음 http://www.microsoft.com/visualstudio/en-us/lightswitch 에서 공개될 예정에 있습니다.
가장 많은 웹 사이트와 가장 많은 도서에서 보여주는 C/R/U/D 기반의 응용프로그램들의 패턴을 Visual Studio LightSwitch는 최신의 UI 기술을 사용하여 그 어떤 도구들보다도 더 쉽게 프로그램이 제작될 수 있도록 도와줍니다. 단순히 Grid Control에서 데이터를 추가, 편집, 삭제할 수 있는 UI가 아니라, 여러분이 원하는 화면의 디자인을 미리 제공되는 데이터 바인딩과 함께 손쉽게 프로그래밍할 수 있도록 돕습니다.
위의 그림에서 보시는것과 같이, Visual Studio LightSwitch는 데이터 가공 방법과 범주에 따라 일반적으로 결정되는 화면의 패턴을 템플릿으로 제공하고 있습니다. 대부분의 경우, 이러한 요구 사항과 부합하는 화면들 내에서 선택이 가능하므로 단순한 데이터 조회 및 검색 화면에 들어가는 작업 소요 기간을 획기적으로 단축시킬 수 있습니다. 뿐만 아니라, 데이터 모델링에서는 단순한 시스템 데이터 형식 뿐만 아니라, 유효성 검사를 염두에 둔 모델링과 UI 연동이 가능하여 세세한 검사를 위한 코드 작성은 하지 않아도 되며, 기본으로 제공되는 Grid Control의 경우 필터링, 열의 재 배치, 행 정렬, 검색, 페이징이 Built-in 기능입니다. 그리고, 요즈음 Microsoft Application UI의 핵심적인 Trademark인 Ribbon Interface도 빠지지 않습니다. :-)
기존에 Windows Forms, Windows Presentation Foundation 기반의 개발 도구를 이용하여 Desktop 및 Office Application을 개발하는 동안 고객으로부터 가장 많이 받게 되는 요구 사항 중 하나인 Excel Export 기능이 Visual Studio LightSwitch를 기반으로 만들어지는 응용프로그램에서는 미리 제공되는 Built-in 기능 중의 하나입니다. 더 이상 Excel 상호운용성 코드나 Primary Interop Assembly를 찾아서 방황하지 않아도 됩니다. :-)
그리고 Visual Studio LightSwitch는 앞으로도 다양한 확장 패키지를 지원해 나갈 수 있으며, 이러한 확장 패키지를 기반으로하여 가까이는 시각 상의 심미적인 효과를 위한 확장, 하드웨어와의 연동 기능 뿐만 아니라 향후에는 Cloud Computing을 위한 응용프로그램 디자인까지도 염두에 둘 수 있습니다.
Visual Studio LightSwitch는 System Integration 개발 부문, Business Intelligence 확장 부문 등 기존에 특별한 기술적 이득 없이 기계적인 반복 작업을 바탕으로 하는 대부분의 소프트웨어 개발 작업에서 더 큰 진가를 발휘할 수 있을 것으로 예상됩니다. 향후에는 Chart, Graph, HTML Editing Control, Built-in Web Browser와 같이 일반적인 Desktop 및 Office Application에서 많이 사용되는 기능에 대한 Extension Pack이 추가될 것도 염두에 두어본다면 반복적인 작업으로부터 많은 일손을 덜어내어줄 수 있는 멋진 도구가 될 수 있을 것 같이 미래가 기대됩니다.
Cloud Computing과의 연계성에 있어서도 Visual Studio LightSwitch의 역할은 매우 클 것으로 보이며, 향후에 Cloud Computing과의 연계 기능에 대해서도 본격적으로 Topic을 다룰 수 있을 때, 상세하게 정보를 전달할 수 있도록 하겠습니다.