남정현의 Windows Azure 블로그

오늘 소개하려는 Visual Studio 확장 기능은 멀티 타기팅 팩의 기능을 매우 적극적으로 활용하는 똑똑한 확장 기능이다. 실무에서 3.5세대 혹은 4세대 닷넷 프레임워크를 적극적으로 사용 중인 개발자들이 국내에도 많이 있을텐데 이 경우 숟한 고민에 부딪히게 되는 것 중에 하나는 다중 플랫폼을 지원해야 한다는 점이다. 대충 열거해봐도 세 가지 이상은 된다. ASP.NET, Windows Presentation Foundation, Silverlight, 경우에 따라서는 XNA Game Studio나 Windows Phone 7.1까지 생각해야 하는 셈이다.

물론 신경써서 세심하게 잘 프로그래밍할 수 있을만큼 노련하다면야 이런 도구가 굳이 필요하지는 않겠지만 사람이 하는 일인지라 신경쓸 것이 많아지면 자연스레 귀찮을 수 밖에 없고 실수도 어디선가는 꼭 나온다. 이런 불분명하고 애매한 상황을 도구를 통하여 정확하게 잡아낼 수 있다면 괜찮지 않을까? Microsoft 개발 팀이 이런 문제를 해결해 줄 명쾌한 답을 Visual Studio Gallery에 올려놓았으니 참고하기 바란다. 아래의 URL에서 다운로드할 수 있다.

http://visualstudiogallery.msdn.microsoft.com/b0e0b5e9-e138-410b-ad10-00cb3caf4981/

Portable Library Tools를 설치하면 Visual Studio에 새로운 프로젝트 템플릿이 C#과 Visual Basic .NET에 대하여 Windows 카테고리 아래에 아래 그림과 같이 나타날 것이다.

목표로 하는 프레임워크를 이전처럼 하나만 선택하는 것이 아니라 하나 이상을 동시에 지정할 수 있다. 이는 다시 말해서 이들 프레임워크의 공통 분모만을 사용하여 클래스 라이브러리를 정확히 프로그래밍할 수 있도록 보증한다는 의미이다. 그리고 Change 버튼을 클릭하면 더 유용한 쓰임새를 찾을 수 있다.

Visual Studio와 함께 설치된 다른 멀티 타기팅 팩이 있을 경우 여기에 모두 열거되어 여러분이 선택할 수 있도록 할 수 있다. 프로젝트의 종류가 많고 정말 일반적이면서도 널리 쓰여야 할 클래스 라이브러리를 만들어야 한다면 여기서 선택을 어떻게 하는가에 따라서 사용할 수 있는 API가 자동으로 필터링된다. 만약 위에서 선택한 플랫폼에서 사용할 수 없는 API에 대한 내용이 발견되면 곧바로 빌드 오류로 나타나기 때문에 문제를 쉽게 찾아낼 수 있다. 그리고 여기서 선택한 대로 해당 프로젝트에서 레퍼런스로 추가할 수 있으므로 생산성도 높일 수 있다. 즉, 솔루션이나 프로젝트를 여러벌로 나눠 관리할 필요 없이 한 곳에서 모두 관리할 수 있다.

이 도구를 사용하기 위해서는 Visual Studio 2010 전체 버전이 필요하며 SP1이 설치되어있어야 한다. 그리고 다른 타기팅 팩이 필요하다면 아래 URL에서 추가적으로 설치할 수 있다. 타기팅 팩은 그 자체로 설치할 수 있는 것은 아니고 보통은 해당 플랫폼에 대한 SDK 안에 같이 수록된다는 점에 유의해야 한다.

http://go.microsoft.com/fwlink/?LinkID=153626

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

요즈음 클라우드 서비스들을 이용하다보면, Windows 서버 운영체제를 통해서 확장성있는 클라우드를 만들고자 하는 경우가 자주 있습니다. 일반적인 웹 사이트를 구축할 때에도 마찬가지이고, 당연히 KT UCLOUD나 Amazon과 같은 환경에서도 같은 노력이 뒷받침이 되어야 하지요. 그리고 제가 주 전공으로 하고 있는 Windows Azure 역시, 첫 배포 때에는 간과하기 쉬운 점이 바로 로드 밸런싱 환경이라는 점입니다.

이러한 로드밸런싱 환경을 만들때에는, 이전에 구축해본 경험이 없는 관리자가 개발자 입장에서는 상당히 어려운 문제에 봉착하게 될 가능성이 많습니다. 특히 요즈음 웹 환경에서는 당연하게 사용하는 세션이나 쿠키에 관련된 설정들이 로드밸런싱 환경에서 기대했던 것과 다르게 동작해서 좌절하는 경험을 많이들 하실텐데요, 제가 오늘 블로그에 올리는 것은 ASP.NET에 관한, 그리고 IIS 7에 관한 내용입니다. (PHP나 JSP 개발자분들께서도 공감하실 수 있는 부분이 있을 것입니다.)

로드밸런싱 환경을 잘 알고 구축할 수 있다면, 앞으로 나오게될 어떤 종류의 클라우드 서비스이든 관계없이 문제를 정확하게 해결할 수 있을 것입니다. 사실 클라우드 기반의 웹 서비스는 달리 표현하면, 기본 골자는 로드밸런싱에 기반을 두고 있는 것이고, 그 이후의 확장성 전략을 클라우드 솔루션으로 채우는 것과 같다고 말할 수 있습니다. (어떤 뼈대를 사용할 것인지는 전적으로 여러분들의 선택에 달린 것입니다.)

로드 밸런싱 환경이란?

로드 밸런싱 기술 자체는 상당히 오래된 것입니다. 이름에서 알 수 있듯이, 몰려오는 트래픽을 내부적으로 분산하여 특정 서버 컴퓨터로 연결이 몰려 서비스가 사용 불가 상태로 빠지는 것을 "지연"시키거나 "완화"시키는 것에 목적이 있습니다. 로드 밸런싱의 기술적 개념도는 다음과 같습니다. (이미지 출처: http://msdn.microsoft.com/en-us/library/ff650667.aspx)

다양한 상황에서 로드밸런싱이 쓰이겠지만 가장 일반적으로는 웹 환경에서 많이 쓰입니다. 연결을 오래 유지할 필요가 없으면서도, 짧은 시간 내에 빠른 연결 회전을 보이는 웹 프로토콜에서 가장 중요한 것은 바로 신속성인데, 분산 처리를 하지 않는 경우에는 필연적으로 서버 컴퓨터가 받아들일 수 있는 동시 연결 한계치에 금방 치닫게 됩니다. 그러나 로드 밸런싱을 정확히 사용하면 이러한 한계치에 치닫게 되는 속도가 로드 밸런싱에 참가하는 컴퓨터의 댓수만큼 반비례하게 됩니다. 그리고 이 때 하나의 웹 사이트를 위한 로드 밸런싱 서비스에 멤버로 참여하는 서버 컴퓨터들을 묶어서 "웹 팜"이라고 정의를 하는 것이지요. 더 일반적으로는 "서버 팜"이라고도 합니다.

잠시 다른 이야기로 넘어가자면, 요즈음 대두되는 클라우드 컴퓨팅은 관리 측면에서 봤을 때, 충분한 대역폭을 보장하는 연결과 매우 뛰어난 성능을 가진 로드 밸런서를 이용하여 연결을 분산하는 작업을 수행하는 것입니다. 그리고 웹 팜 안에 참여하는 컴퓨터의 유형에 있어서는 이전과 다른 점이 하나 있는데, 마치 구름과 같이 수축과 팽창을 자유자재로 한다는 것입니다. 물론 이런 수축과 팽창이 가능함은 내부적으로 가상화 솔루션을 이용했다거나 여기에 대응할 수 있는 알고리즘을 사용했다는 가정이 깔려있는 것입니다.

정말 완벽하고 정확하게 구축했다면, 적은 전원이나 자원 공급으로도 충분히 웹 팜이 유지가 될 수도 있고, 필요하다면 웹 팜의 크기가 엄청나게 커질 수도 있겠지요. 이걸 여러분이 관리하신다면 프라이빗 클라우드, 신뢰할 수 있는 IT 기업이 관리한다면 퍼블릭 클라우드가 된다고 보실 수 있겠습니다. 그러나, 클라우드 컴퓨팅이 만능약처럼 들릴 수 있는 부분이 있지만 정확히 알아야 할 것은 클라우드 컴퓨팅 역시 이 로드 밸런싱을 기초로 만들어지는 것이고, 여러분이 운영할 수 있는 한계에까지 트래픽이 몰리거나, 이런 일을 하는 IT 업체에게 지불할 수 있는 재정의 한계에까지 트래픽이 몰린다면 이것이 여러분이 생각할 수 있는 클라우드의 한계입니다. 무제한이라고 해서 값이 저렴하거나 무료에 수렴하는게 아님을 명확히 이해하고 있어야 합니다.

웹 로드 밸런싱을 위한 이야기

다시 본론으로 돌아와서, 웹을 로드 밸런싱할 수 있으려면 무엇을 검토해야 할까요? 가장 중요한 것은 웹 서버에 참여하는 각각의 컴퓨터 자체에는 "절대로" 컴퓨터의 고유한 정보를 가지고 있으면 안된다는 점입니다. 매우 단순한 이야기같지만 이러한 원칙을 지키지 않도록 설계되어있는 것이 지금 이 시점까지의 서버 컴퓨팅 기술들의 대다수의 원칙입니다. 간단한 예를 들어볼까요?

여러분이 일상적으로 사용하는, 웹을 통한 파일 업로드 기능을 담당하는 간단한 웹 앱이 있다고 가정해 보겠습니다. 이 웹 앱은 서버가 한 대 일때에는 참 쉽고 빠르게 설치해서 쓸 수 있었습니다. 당연히, 설치를 잘 했다면, 사용자가 웹 페이지를 방문해서 파일을 업로드하면 웹 서버가 그것을 알아보고 파일을 회수해서 하드 디스크 어딘가에 저장하겠지요. 그러나 시간이 지나서 이 웹 앱의 기능을 업그레이드하고 좀 더 많은 사용자들이 파일을 저장하고 다운로드할 수 있도록 만들어보고자 해서 로드 밸런싱 환경을 구축하여 베타 테스트를 시작했습니다. 그런데 어떤 문제들이 생겼을까요?

앞서 이야기한 기술적인 특성때문에, 사용자들은 분명히 조금전까지 파일을 업로드했었는데 페이지를 다시 와서보니 파일이 업로드되지 않은 상태로 페이지가 나와서 혼란스러워합니다. 혹은 파일을 어디로 빼돌린거냐며 분노하는 사람들도 있구요. 그래서 몇 번 F5키를 누르다보면 "어라?"하고 놀라게 됩니다. 조금 전에 업로드했던 파일이 다시 나타나니까요. 그러고나서 그 파일을 다운로드하려고 링크를 클릭하면 이번엔 또 다시 404 오류를 만납니다. 이제 사용자들은 이 서비스에 대해서 대단한 분노와 원성을 쏟아낼 것입니다. 서비스 상태에도 일관성이 없을 뿐 아니라 불안정한것 같다. 믿을 수 없다면서요.

이것이 일선 IT 현장에서 로드 밸런싱이나 클라우드를 처음 접목했을 때 겪는 "가장 흔하고 일반적인 장애"입니다. 더 안타까운 것은, 이것을 신 기술에 의한 책임으로 회피하고 문제시하는 것입니다. 문제의 본질을 정확히 알고 있다면 이렇게 말하는 것이 왜 잘못인지도 금방 알 수 있을 것입니다.

여기서 든 예제처럼, 이 웹 앱의 문제는 단순히 업로드한 파일을 자신의 컴퓨터에 저장하려고 했다는 데에 문제가 있습니다. 로드 밸런싱 멤버로 참여하는 컴퓨터가 자신의 상태를 중요하게 여기면, 다음번에 이어받는 다른 서버 컴퓨터의 입장에서는 이전에 그 컴퓨터가 무엇을 했는지 알 길이 없습니다. 그저, 찾고자 하는 내용이 없음을 이야기하는 수 밖에 없습니다. 이런 상황이 반복되면서 서비스 전체는 들어올때와 나갈때가 전혀 다른, 일관성이 없고 이상한 서비스가 되는 것입니다.

이 문제를 해결하기 위하여 어떻게 수정해야 할까요? 답은 간단합니다. 파일 저장소를 로드 밸런싱 멤버 컴퓨터 내부가 아닌, 여러 멤버 컴퓨터들이 같이 이용할 수 있는 공용 저장소로 바꾸는 것입니다. 가장 간단한 방법은 네트워크 UNC 경로로 이용할 수 있는 스토리지가 있을 수 있습니다.

여기서 궁금한 점이 하나 더 있는데, 그렇다면 로드 밸런싱에 의하여 애써 분산한 서비스가 다시 모이는 것이 아니냐고 반문할 수도 있습니다. 그런데 사실, 생각외로 사용자들이나 웹 크롤러와 같이 인터넷 상에서 발생하는 별 뜻없이 바쁘게 만드는 다양한 유형의 트래픽을 웹 팜 수준에서 한 번은 로드 밸런싱을 해주는 것 만으로도 실제 스토리지에 대한 요구 사항은 획기적으로 감소한다는 점입니다. 거기다, 역할 분담도 정확히 할 수 있으며 스토리지 자체에 대한 요구 사항이 폭증하는 것을 방지하기 위하여 기술적으로는 좀 더 복잡해질 수 있지만 캐싱 기능을 사용할 수도 있습니다. 이렇게 함으로서, 우리가 흔히 잘 아는 클라우드 서비스의 시작을 뗄 수 있게 됩니다.

기술적인 이야기 1 - 세션 처리 방법 바꾸기

그렇다면 IIS와 ASP.NET에서는 이런 이상한 상황을 예방하고 신뢰할 수 있는 서비스를 만들기 위해서 어떤 수정 사항을 반영해야 하는 것일까요? 제가 이제까지 인터넷 상으로 자료 조사를 해왔던 것은 모두 제각기 흩어져있는 정보들이었고 이것을 한 번에 취합할 수 있는 방법을 오늘 블로그 포스팅을 통하여 소개할까 합니다.

기본적으로 ASP.NET은 세션 처리를 IIS 프로세스 안에서 수행하도록 되어있습니다. 가장 동선도 짧고, 신속하게 반응하기 때문입니다. 그러나 로드 밸런싱 환경에서 이는 당연히 "채택하면 안되는" 기법입니다. 이 방법은 web.config 파일 안의 <sessionState> 요소에서 변경할 수 있는 부분으로, <configuration> 요소 아래의 <system.web> 요소 아래에서 없는 경우 새로 지정할 수 있습니다. <sessionState> 요소의 mode 속성의 값을 변경하면 됩니다. 지금 이야기한 부분은 mode 속성이 InProc으로 지정되어있거나, 아무것도 지정되어있지 않을 때 .NET Framework의 글로벌 web.config 설정을 바꾸지 않은 경우 기본으로 지정되는 설정입니다.

IIS 7에서 볼 수 있는 아래 그림과 같은 설정도 이 XML 파일의 수정을 텍스트 에디터 없이 수정하는 것입니다.

로드 밸런싱 환경에서 정상적으로 동작하는 웹 사이트를 만들기 위해서는 mode의 설정 값을 InProc 대신 StateServer나 SQLServer로 바꾸어야 하는데, 양쪽 값 모두 장단점이 있습니다. StateServer의 경우 기본적으로는 꺼져있는 ASP.NET State Service라는 NT 서비스가 제공하는 별도의 서버를 이용하는 방식이고, SQLServer는 이름에서 알 수 있듯이 실제 SQL Server를 사용하여 세션을 구현하는 방식입니다. 데이터베이스 서버의 성능이 세션을 모두 수용할 수 있을만큼 획기적으로 뛰어나거나, 세션 서버가 죽었다가 살아나도 로그아웃 처리가 안되게 한다던가, 혹은 여러 로드 밸런싱 사이트 사이에서 세션 공유를 안전하게 할 방법이 필요하다면 이 모드를 사용할 수 있습니다. 이에 비하여 StateServer는 별도의 SQL 서버 없이도 간편하게 구축할 수 있는 방법을 제공하긴 하지만, 세션 서버가 죽었다 살아날 경우 내용이 없어지는 휘발성 세션입니다.

양쪽 모드 모두 중요한 것은 멤버로 참여하는 웹 서버 컴퓨터 밖에 상태를 보관해야 한다는 것이 키 포인트로, 이것을 지키지 않고 멤버 컴퓨터 안에 이런 설정을 구축하면 전혀 나아지는 것이 없습니다. 그리고 당연한 이야기이지만 멤버 컴퓨터로 참여하는 모든 웹 서버가 같은 설정을 가지고 있어야 합니다.

StateServer와 SQLServer 모드를 구현하는 방법에 대한 자세한 내용은 아래 아티클을 참고하시면 되겠습니다.

http://msdn.microsoft.com/ko-kr/library/ms178586.aspx

기술적인 이야기 2 - ASP.NET 사이트 간에 립싱크 맞추기

세션을 공유하는 것 이외에, ASP.NET은 내부적으로 Machine Key라는 것을 사용합니다. Machine Key의 용도는 ASP.NET 안에서 참 다양한데, 가장 대표적으로는 클라이언트와 서버 사이에 쿠키 정보를 주고 받을 때 암호화하기 위한 수단으로 이용하는 것이 유명한 사례입니다. 쿠키를 이용한 취약점 공격은 웹 세계에서 너무나 당연한 공격 방식 중 하나이기 때문에 ASP.NET은 처음부터 이를 보완하기 위한 전략을 구현하고 있었습니다. 그러나 이것이 지금 와서 로드 밸런싱 환경이 되면서는 또 다른 어려운 문제로 바뀐 것입니다.

이 Machine Key라는 것 역시 서버 컴퓨터마다 고유하게 생성할 뿐 아니라, 매번 연결할 때 마다 다른 값을 생성하여 암호화에 사용합니다. 클라이언트 입장에서야, 서버가 "ABC"라는 쿠키를 주니까 "아 그렇구나. 나중에 돌려주면 서버가 날 알아보겠지?"하며 성실하게 반납합니다. 그런데 로드 밸런싱에 참여하는 A라는 서버 대신 C라는 서버가 이 쿠키를 받아들었을 때는 "이거 내것 아님" 하며 클라이언트에게 퇴짜를 놓습니다. 이것이 문제의 핵심인 것이죠.

이 문제를 해결하기 위해서는 아까전에 이야기한 주제보다 좀 더 많은 노력이 필요합니다. 생각보다, 보안을 완벽하게 유지하기 위하여 ASP.NET이 관리자들에게 요구하는 사항이 까다롭기 때문입니다. 이 Machine Key를 만들기 위해서는 별도의 생성 도구를 사용해야 합니다. 그러나 안타깝게도 이 도구를 구한다거나 만들 수 있으려면 개발자들의 조력이 좀 필요합니다. 그리고 개발자 본인들도 이런 방법을 찾아야 하기때문에 꽤나 귀찮습니다. Codeproject에 가면 이러한 방법을 자세히 설명한 아티클도 있습니다만 간단한 도구도 드리고, 코드 조각도 드리니 프로그램에 넣어 활용하시면 더 편리할 것입니다.

MachineKeyGenerator.zip

using System;
using System.Text;
using System.Security.Cryptography;

/* 중략 */

        public static string getRandomKey(int bytelength)
        {
            byte[] buff = new byte[bytelength];
            RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();
            rng.GetBytes(buff);
            StringBuilder sb = new StringBuilder(bytelength * 2);
            for (int i = 0; i < buff.Length; i++)
                sb.Append(string.Format("{0:X2}", buff[i]));
            return sb.ToString();
        }

        public static string getASPNET20machinekey()
        {
            StringBuilder aspnet20machinekey = new StringBuilder();
            string key64byte = getRandomKey(64);
            string key32byte = getRandomKey(32);
            aspnet20machinekey.Append("<machineKey\n");
            aspnet20machinekey.Append(" validationKey=\"" + key64byte + "\"\n");
            aspnet20machinekey.Append(" decryptionKey=\"" + key32byte + "\"\n");
            aspnet20machinekey.Append(" validation=\"SHA1\" decryption=\"AES\"\n");
            aspnet20machinekey.Append("/>\n");
            return aspnet20machinekey.ToString();
        }

        public static string getASPNET11machinekey()
        {
            StringBuilder aspnet11machinekey = new StringBuilder();
            string key64byte = getRandomKey(64);
            string key24byte = getRandomKey(24);

            aspnet11machinekey.Append("<machineKey");
            aspnet11machinekey.Append(" validationKey=\"" + key64byte + "\"\n");
            aspnet11machinekey.Append(" decryptionKey=\"" + key24byte + "\"\n");
            aspnet11machinekey.Append(" validation=\"SHA1\"\n");
            aspnet11machinekey.Append("/>\n");
            return aspnet11machinekey.ToString();
        }

위의 코드를 사용하여 프로그램을 만들거나 ZIP 파일 안의 프로그램을 이용하여 값을 만들도록 하면 아래와 같은 XML 코드 조각을 얻을 수 있을 것입니다. 이 코드 조각을 각각의 서버에 들어있는 web.config에 지정하거나, 특정한 값만 인용하여 아래의 IIS 7 설정 아이콘에서 볼 수 있는 설정 도구를 통해서 직접 설정할 수도 있습니다.

<machineKey
 validationKey="FACBB6C89C44CB8BB7165FC4639BAA7267B...EF297D815E1BDD40E883E3451628CB95D34309"
 decryptionKey="4E95057676CC8DBA9AB...AACC1121B6B962E5AFA7849B0C82"
 validation="SHA1" decryption="AES"
/>

기술적인 이야기 3 - IIS에서 놓치면 안되는 것

ASP.NET을 가장 먼저 사용할 수 있게 된 웹 서버가 IIS이다보니 발생한 일종의 특성입니다만 여러 포럼에 걸쳐서 잘 언급되지 않는 문제점이 하나 있습니다. 바로 IIS에서 사용하는 사이트 ID 값을 통해서 정해지는 Application Path를 Machine Key와 같이 활용된다는 사실입니다. 웹 사이트 관리를 하다보면 로드 밸런싱에 참여하는 컴퓨터들을 다음과 같이 관리하게 되는 경우가 있습니다.

• 서버 A에서는 기본 웹 사이트를 먼저 지우고 새 웹 사이트를 만들었다.
• 서버 B에서는 새 웹 사이트를 먼저 만들고 기본 웹 사이트를 지웠다.

혹은 아래와 같은 경우도 있을 수 있습니다.

• 서버 C에서는 사이트 A를 만들고 사이트 B를 만들었다.
• 서버 D에서는 사이트 B를 만들고 사이트 A를 만들었다.

별 차이 없이 생각할 수 있지만, IIS에서는 이 경우 각각의 사이트들에 다른 ID 값을 부과하게 됩니다. 이 경우, 분명히 Machine Key를 동일하게 지정했음에도 불구하고 로드 밸런싱 환경에서 세션 상태가 일관성없게 변하는 문제를 만나게 됩니다. 제가 이번에 고민하게 된 부분도 바로 이 부분이었는데요, 이 문제를 해결하기 위해서는 IIS 7에서 전체 웹 사이트 목록에 나타나는 내용 중 다음의 ID 값이 멤버로 참여하는 웹 서버마다 차이가 있지 않은지 우선 검토해야 합니다.

위에있는 그림에서 빨간색으로 그린 부분이 서버 컴퓨터마다 차이가 있다면 이 값을 수정해주어야 합니다. 이 값을 수정하기 위해서는 수정할 사이트를 클릭하고, 고급 설정 링크를 아래 그림과 같이 클릭합니다.

이제 아래와 같은 팝업 대화 상자가 나타나면 강조 표시한 속성인 ID 값이 멤버로 참여하는 웹 서버 모두 같은 값을 가질 수 있도록 통일시켜줍니다.

확인 버튼을 누른 다음, ID 값이 바뀐 서버 컴퓨터에 한해서 IIS 전체를 재시작해주시거나 사이트 재시작을 시켜주시면 정상적으로 작동하게 될 것입니다.

Windows Azure 환경에서의 고려 사항

오늘 살펴본 내용은 IIS 7과 ASP.NET에 관한 부분이었지만, Windows Azure Platform의 경우에도 비슷한 문제가 있습니다. Windows Azure Platform에 VM Role로 웹 사이트를 게시를 하든, Web Role로 웹 사이트를 게시하든 세션을 사용하게 될 경우 비슷한 문제가 있을 수 있습니다.

다행히, Web Role을 이용한다면 내부적으로 사용하는 IIS에서 여러분이 몇 개의 웹 사이트를 추가적으로 구성하든 관계없이 같은 순서로 같은 ID를 사용하는 웹 사이트를 만들 것이므로 세 번째로 이야기한 ID 값 수정과 같은 작업은 할 필요가 없을 것입니다. 그러나 Machine Key에 대한 설정이나 세션 공유를 위한 설정은 SQL Azure를 이용한다거나, Worker Role에서 ASP.NET State Service 혹은 써드파티의 Session State Server를 이용해야 할 수 있습니다.

물론, 최근에 Windows Azure Platform의 일부로 Windows Azure AppFabric Cache가 새로 출시되기는 하였습니다만 상당히 이용 가격이 비싼 편입니다. (비싼만큼 확실한 성능을 제공합니다.) 로드 밸런싱 환경에서 특별한 문제를 일으키지 않는 일반적인 세션 공유가 필요하시다면 오늘 이야기한 주제를 응용한 Azure Project를 구축해보는 것도 의미가 있을 것입니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

요즈음은 회사의 분야나 크기, 규모를 막론하고 누구나 자체적인 전산망을 구축하기 원하고, 자체적인 협업 사이트를 구축하기 원하며, 자체적인 통합 커뮤니케이션 시스템을 구현하기를 원합니다. 제대로만 구축된다면 참 편리하게 쓸 수 있고 회사가 빠르게 성장하는데 많은 도움을 줄 것이라는 것을 익히 보고 들어왔기 때문이죠. 하지만 생각만큼 쉬운 일이 결코 아닙니다. 경우에 따라서는, 회사가 원래 목표로 세웠던 대외적인 활동보다도 더 큰 역량이 들어가서 배보다 배꼽이 더 큰 일로 빠지는 경우도 많으니까요.

이번에 제가 다녀온 Office 365 MVP Day에서는 많은 이야기들이 있었지만 개인적으로는 Windows Azure Platform이나 기타 클라우드 컴퓨팅 플랫폼과 연결될 수 있는 Office 365만의 고유한 기능들에 대해서 가능성을 조사해보고 타진하는 것을 저만의 즐거움으로 삼을 수 있었습니다.

Exchange Web Service Managed API

다른 Microsoft 서비스들과 마찬가지로 Office 365 역시 독창적인 API를 제공합니다. EWS Managed API를 사용하여 조직 내 E-MAIL 계정 사용자의 작업을 대행하거나, 개인의 일정 정보를 검색하거나, 메일 내용을 검색하는 등의 서비스를 기존의 Windows Application에서는 물론, 여러분이 만들 고유한 웹 서비스 및 모바일 애플리케이션에서도 구현할 수 있습니다. 아래는 Epience에서 근무하시는 최정우 차장님께서 Demo로 보여주신 EWS를 이용하여 만든 Web Mail 시스템의 실행 예시입니다.

EWS Managed API 자체는 Exchange Server에서 제공하는 API를 기반으로 만들어진 것이기 때문에, 정확한 서비스 위치만 알고 있다면 XML Web Service를 처리할 수 있는 프로그래밍 언어에서는 EWS를 이용하여 필요한 작업을 수행할 수도 있습니다. http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=17947 에 게시된 문서를 통하여 다양한 프로그래밍 언어와 환경에서 EWS Online API를 사용하는 예시를 살펴보실 수 있습니다. :-)

SharePoint Portal Development with Office 365

SharePoint는 기본적으로 협업을 위한 위키 페이지 작성, 문서 공유 등의 작업을 수행할 수 있도록 디자인된 기업용 맞춤형 포털 서비스를 제공합니다. 그렇지만 클라우드 버전의 SharePoint Online에서는 이 외에도 클라우드 기반 시스템으로 갖추어야 할 기본적인 소양으로 많이 꼽히는 Claim-based Authentication이나 Data Conversion/Migration 등의 기능도 제공하고 있습니다.

그리고 종전의 Standalone 버전의 SharePoint와는 달리, 클라우드 환경에서는 타 고객들에게 금전적, 시간적 손해를 끼칠 가능성을 사전에 차단하기 위하여 클라우드 서비스에 대해서 영향을 주지 않을것이라고 확신할 수 있는 컨텐츠만을 제작할 수 있는 SharePoint Designer 이외의 모든 코드들이 샌드박스 환경 안에서 수행됩니다.

전적으로 개발자의 재량에 따른 것이지만 간단한 전자결재 시스템 역시 SharePoint를 통하여 구축하는 것이 가능합니다. 좀 더 자세한 내용은 http://msdn.microsoft.com/en-us/sharepoint/gg153540.aspx 에서 확인해보실 것을 권합니다.

Microsoft표 온라인 서비스의 이점

클라우드 서비스를 제공하겠다고 나서는 업체들은 매우 많습니다. 그렇지만 이러한 클라우드 서비스를 단순히 제공한다는 사실만을 너무 강조한 나머지 기본에 충실하지 못한 경우를 자주 보게 되는데, 이는 달리 표현하면, "바퀴를 붙여 잘 굴러가게 만들었으니 자동차로서의 기능을 지원한다"고 설명하는 것과 같은 오류가 될 수 있습니다. Microsoft가 제공하는 온라인 서비스들은 이러한 오류에 빠지지 않도록 지속적으로 기능을 개선하고, 기본에 충실하면서도, 신뢰성이 높은 서비스들로 구성되어있다는 점에서 이번 Office 365의 런칭은 개인적으로 Windows Azure Platform이 런칭될 때 못지 않은 기대감을 가지게 합니다.

조만간 국내에서도 KT를 통하여 Office 365 서비스를 신청할 수 있게 될 것으로 보입니다. Office 365의 기본 기능들만 사용해도 훌륭하지만 이제 클라우드 시대에 맞추어 여러분도 다른 업체에 여러분의 시스템을 맡기는 일 없이 여러분의 입맛에 맞게 회사 내 인트라넷 시스템과 인프라를 DIY할 수 있습니다. :-)

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

안녕하세요. 오랫만에 블로그에 글을 올립니다. 지난번 Visual Studio Camp에서 옴니버스 형식의 세미나로 Visual Studio 2010 Service Pack 1에 대하여 말씀을 드렸던 세션이 있는데, 발표 자료와 더불어서 Visual Studio 2010 SP1에 대한 간략한 소개를 위하여 글을 씁니다.

Visual Studio의 새 도움말 시스템

Visual Studio 2010 RTM 버전부터는 새로운 형태의 도움말 시스템이 도입되는데, 로컬 웹 서버를 통하여 도움말 컨텐츠가 제공되는 방식으로 이전의 Visual Studio 2005와 Visual Studio 2008에서 제공되던 방식과 다르게 제공됩니다. Visual Studio 2005와 Visual Studio 2008의 경우 자체 URI Scheme을 Windows Registry에 등록하고 이를 Internet Explorer를 통하여 탐색할 수 있도록 확장하는 방식이었습니다. 그러나 새로운 도움말 컬렉션을 추가하거나 삭제하는 과정에서 시스템 성능에 따라 재배열 시간이 상당히 오래 걸리는 문제가 있어 불편한 점도 있었습니다. 이러한 방식 대신 더 단순하지만 더 유연한 방식으로 바꾸게 된 듯 합니다.

그렇지만 이전 버전에서 제공되던 색인, 검색 기능 등이 웹 사이트 형식으로 바뀌면서 이전에 사용했던 기능들이 사라져서 아쉬운 점도 있었는데 이번 Service Pack 1에서는 다시 Help Browser Software가 부활했습니다. 그래서 로컬 웹 서버로 컨텐츠를 보여주는 것은 동일하지만 Visual Studio를 통해서 컨텐츠를 탐색하면 Help Browser가 별도로 나타납니다.

그리고 이번 도움말 시스템에서의 백미는 인터넷을 통한 업데이트가 가능해졌다는 점입니다. 실제로 설치한 적이 없는 제품이라 할지라도, 그리고 DVD를 통해서만 설치할 수 있는 전체 버전의 MSDN 안에서만 제공되던 컨텐츠까지도 인터넷을 통하여 항상 최신 버전을 다운로드받아 로컬 도움말 컬렉션에 추가하거나 필요하지 않으면 삭제할 수 있습니다.

private void UpdateFileList()
{
    string targetPath = Environment.GetFolderPath(
        Environment.SpecialFolder.MyPictures);
 
    List<object> content = new List<object>();
    foreach (string eachFile in Directory.EnumerateFiles(targetPath))
    {
        switch (System.IO.Path.GetExtension(eachFile).ToLower())
        {
            case ".jpg":
            case ".jpeg":
            case ".png":
                break;
 
            default:
                continue;
        }
 
        content.Add(eachFile);
    }
    this.fileList.ItemsSource = content;
}

• ASP.NET Development Server와는 달리 FastCGI 모듈을 호스팅할 수 있으므로 PHP와 같은 FastCGI 지원 웹 언어들을 같은 환경에서 동시에 테스트할 수 있습니다.
• 웹 프로젝트에서 IIS를 사용하도록 지정한 경우, 관리자 권한을 얻을 수 없는 다른 컴퓨터에서는 웹 프로젝트를 열 수 없는 문제점이 있었으나 IIS Express를 사용하도록 하면 이런 제약이 없습니다.
• IIS Hosted Core를 사용하므로 전체 버전의 IIS가 없어도 상관이 없으며, IIS Express가 설치되어있지 않은 경우 Visual Studio가 자동으로 이를 감지하여 Web Platform Installer를 호출하여 IIS Express가 설치될 수 있도록 해줍니다.
• 개별 프로세스 형태로 실행되므로 여러 사람이 사용하는 컴퓨터에서도 시스템 설정을 편집하는 일 없이 안전하게 실행할 수 있습니다.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <title>HTML5 Test</title>
    <link type="text/css" rel="Stylesheet" href="http://ajax.aspnetcdn.com/ajax/jquery.ui/1.8.10/themes/redmond/jquery-ui.css" /> 
    <script type="text/javascript" src="http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.5.1.js"></script>
    <script type="text/javascript" src="http://ajax.aspnetcdn.com/ajax/jquery.ui/1.8.10/jquery-ui.js"></script>
    <script type="text/javascript">
        $(document).ready(function () {
            $('#test').dialog({ show: "drop", hide: "drop", width: "auto", height: "auto", title: "html 5 rocks!" }).show();
        });
    </script>
</head>
<body>
    <div id="test">
        <video src="demo.mp4" width="700" height="500" id="testVideo" autoplay="autoplay">
            <strong>Your web browser does not support video element.</strong>
        </video>
    </div>
</body>
</html>

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

[Internet Explorer에 대한 내용을 정정하였습니다.]

이전부터 포터블 응용프로그램을 만들기 위한 시도는 많이 있었고 최근들어서는 이러한 시도들이 가상화 기술의 한 장르로 발전하게 되었습니다. 대표적으로 Thinstall이 과거에 있었는데 이 솔루션은 VMware ThinApp으로 재탄생했지요. 그리고 Microsoft 역시 App-V 기술을 제공하고 있습니다. 그런데 오늘은 이러한 응용프로그램 가상화 솔루션에 클라우드 기술, 그리고 적절한 사용자 인터페이스까지 결합한 해외 서비스 하나를 소개해볼까 합니다. 바로 roozz입니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

C#과 Visual Basic .NET의 다음 버전에 대한 이야기가 C# 4.0과 VB.NET 10.0이 출시된지 1년이 채 안된 지금 많은 화두가 되고 있습니다. 그러나 다음 버전에 대한 이야기가 아주 낯설은 이야기만은 아닌 것이 바로 비동기 프로그래밍에 대한 것이 뜨거운 이슈가 되고 있습니다. 일반적으로 비동기 프로그래밍은 전문가들만의 전유물로 잘 알려져 있습니다.

그러나 클라이언트이든 서버이든 더 나은 형태의, 더 유지보수하기 쉬운 형태의 비동기 메커니즘을 찾으려는 시도를 많이 수행해왔으며 그 결과가 이번 Visual Studio Async와 함께 공개될 듯 합니다. Visual Studio Async와 함께 공개되는 업데이트된 버전의 C# 컴파일러와 VB.NET 컴파일러는 아래와 같은 코드를 컴파일하여 비동기로 실행할 수 있도록 번역해줍니다.

async 키워드와 await 키워드가 사용된 것을 잘 관찰하면 상당히 재미있습니다. 위와 같은 코드를 Visual Studio Async 없이 작성하려면 많은 것을 이해하고 알아야 합니다. 비동기 흐름 제어를 언제 완료할 것이고, 비동기 스레드에서 UI로 데이터를 전달하기 위해서 문맥 전환을 어떻게 해야 할 것이며, 스레드의 순서를 어떻게 제어할 것인가 등등 매우 어려운 이야기를 늘어놓아야 합니다. 그리고 이런 식으로 이야기를 풀어나가다보면 전체적인 그림을 보지 못하고 세부적인 흐름에 집중하게 되어 프로그래밍 효율이 떨어진다는 것도 경험하신 분들이 많으실 것입니다.

위의 코드는 동기 방식 코드와 유사하지만 성격이 다릅니다. async 키워드를 사용하여 선언된 메서드는 컴파일 이후 자동으로 비동기 메서드와 비동기 메서드의 실행 끝에 불리울 이벤트 통지 메커니즘과 한 쌍이되어 멤버로 표현됩니다. 그리고 이러한 한쌍의 멤버를 부르는 방법이 await 지시자입니다. await 지시자 없이 부를 경우 우리가 원래 알던 비동기의 성질을 그대로 지니게 되어 스레드를 분할하고 작업이 끝나면 결과를 통지하는 방식을 사용합니다. 그러나 이를 한번에 관리하고 코드 문맥 안에서 비동기 상태를 제어할 수 있도록 하는 것이 await 지시자의 역할입니다.

이 프레임워크는 실버라이트나 WPF와 같이 빠른 화면 전환을 요구로 하는 환경에서 특히 그 활용성이 높을 것입니다. 좀 더 자세한 내용을 전달하기 위하여 공식 Whitepaper를 첨부하였습니다. Visual Studio Async는 http://go.microsoft.com/fwlink/?LinkId=203690 에서 다운로드 가능합니다. :-)

(Whitepaper) Asynchrony in .NET.docx

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

이 글은 http://www.boutell.com/newfaq/misc/urllength.html 의 내용을 인용하여 서술한 것으로 2006년 이후로 바뀐 내용들이 반영되어있지 않은 것들이 많습니다. 덧붙일 의견이 있으시면 언제든 말씀해주시면 반영하겠습니다. :-)

http://www.w3.org/Protocols/rfc2616/rfc2616.html 에서 설명하는 사양에도 최대 URL 길이에 대한 내용은 언급이 되어있지 않습니다. 하지만 웹 개발을 하면서 누구나 한번즈음은 이런 부분에 대해서 고민을 하게 될 때가 있는데, 그러한 고민을 풀어줄만한 아티클이 있어 소개해 봅니다.

Browser Case No. 1: Microsoft Internet Explorer

http://support.microsoft.com/kb/q208427/ 에서 언급한 것 처럼 Microsoft Internet Explorer는 내부 WININET 헤더 파일 상의 정의를 충실히 따릅니다. URL이 가질 수 있는 최대 길이는 2083자이고, 이 중 프로토콜, 서버 이름 등을 제외한 순수 경로가 2048자까지 허용이 됩니다. 이 글을 작성했던 분의 테스트 결과에 따르면 URL 길이가 긴 경우 브라우저 차원에서 오류 페이지를 띄운다는 것으로 결과가 나왔다고 합니다.

Browser Case No. 2: Firefox

버전 1.5.x의 경우 시각적으로 주소 표시줄은 65536번째 글자 이후로는 주소를 더 표시하지 못한다고 합니다. 그러나 논리적으로 십만글자 이상의 URL도 정상적으로 처리하는 것으로 보이며, 현재 출시되는 Firefox의 경우 이러한 제약이 거의 없지 않겠는가 하는 예상을 해봅니다.

Browser Case No. 3: Safari

적어도 8만자까지는 잘 동작한다고 합니다. :-)

Browser Case No. 4: Opera

긴 URL에 관해서는 종결자라고 해도 틀림없겠네요. 무려 19만자까지, 그것도 인라인 편집이 아닌 여러 행 편집이 가능한 컨트롤로 확장까지 가능하다고 합니다. >_<

Web Server Case No. 1: Apache

기본적으로 약 4000자까지는 허용하지만 그 이후부터는 413 Entity too large 오류가 발생한다고 합니다. 그러나 근래 개발되는 RHEL 기반에서의 Apache는 문서 상으로 약 8000자 이상까지 지원한다고 합니다.

Web Server Case No. 2: Microsoft Internet Information Services (IIS)

기본적으로 16384자까지 지원하며 이는 Microsoft Internet Explorer의 경우와는 상반되는 동작입니다. 게다가 설정도 가능합니다. 특별한 제약은 없겠지만 너무 긴 URL을 받아들이는건 상식적이지 않겠지요.

Web Server Case No. 2-1: ASP.NET

웹 서버 이야기는 아닙니다만 IIS에서 독자적인 처리 규정을 가지고 있는 서버 기반 처리 엔진에 대한 이야기를 하나 하자면, ASP.NET의 이야기를 해야 할 것 같습니다. ASP.NET 3.5 SP1 (내부 ASP.NET 2.0) 까지는 Windows의 시스템 상수 _MAX_PATH가 정의하는 범위 만큼의 URL만을 IIS의 설정과는 관계없이 받아들일 수 있었지만 ASP.NET 4.0부터는 Web.config 파일의 httpRuntime 요소의 maxQueryStringLength 속성에 의하여 확장이 가능합니다.

Web Server Case No. 3: Perl의 HTTP::Daemon

기본적으로 8000자까지 지원합니다. POST 메서드로 수신하게 되는 데이터를 제외하고 순수 HTTP 헤더는 16384바이트까지 지원하며 이 중 헤더에 들어있을 URL에도 이러한 제약이 적용됩니다. 즉, 헤더에 전달되는 내용과의 상관관계도 감안해야하므로 헤더의 양이 많은 경우 8000자보다 안되게 지원이 될 수도 있습니다. 보통은 8000자 이상의 URL로 요청을 하는 경우 413 오류가 발생합니다. 이러한 제약을 넘기위해서 Daemon.pm 파일 내의 16x1024라는 모든 표현식을 더 큰 값으로 수정하면 됩니다. 물론, 이런 동작을 하는 경우 당연한 이야기이지만 Denial of Service (DoS) 공격에 취약해질 수 밖에 없겠지요.

결론

이 글에서는 단순히 fact에 대해서만 살펴보았습니다. 기본적으로 URL이 필요 이상으로 길다고 하는 것 (그 기준이 정확하지는 않지만 상식적인 범위를 벗어나는, 가령 100글자 이상)은 정상적인 상황이 아닐 것입니다. 이 정도로 긴 URL을 보내야 한다면, 대개는 Query String이 그 원인일 것이므로, GET 방식 대신 POST 방식의 전송을 고려해보실 수 있습니다. 하지만 긴 URL을 유지해야 할 필요가 있다면 제가 원본으로 참조한 글의 끝자락에 있는 "The Bookmark Problem" 섹션을 참고하시기 바랍니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Microsoft 서버 및 도구 사업부의 관리 및 보안 총괄 책임자인 Garth Fort가 IT 전문가의 역할을 혁신적으로 바꿔주는 Windows의 관리 도구에 대해 설명합니다. 이 동영상에서는 Microsoft 관점에서의 클라우드 컴퓨팅의 발전상에 대한 이야기도 들어보실 수 있습니다. Private Cloud에 대한 검토 단계에 있으신 분들께 권해드리는 동영상입니다.

자세한 내용 보기: http://www.microsoft.com/showcase/ko/kr/details/ba75c25f-c9ca-400d-ac19-8978c512f300

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

오늘 도착한 ZDNET 코리아 메일링 리스트를 통해 아주 흥미로운 웹 캐스트가 하나 게시되었습니다. Delphi Prism은 Embacadero의 최신 Rapid Application Development Tool로서 종전의 Delphi .NET에 대한 업그레이드 제품이자, RemObjects사의 Object Pascal 제품의 최신 버전입니다. Visual Studio Shell을 통하여 이전 버전의 Delphi IDE에서 사용헀던 .NET 개발 환경때 보다 더 풍부하고 확장된 기능을 제공하기도 하고, 특히 이번 XE 버전에서는 MonoDevelop 기반의 IDE도 동시에 지원하고 있어서 기능성이 매우 돋보이기도 합니다.

이 동영상에서 소개하는 기술들에 대해 간단히 요약하면, 리눅스, 솔라리스, 맥 OS X에서 데스크 탑 및 서버 닷넷 프레임워크 대체 구현을 제공하는 Mono 프레임워크 (http://mono-project.com/Downloads), 상용 제품군으로 판매되는 MonoTouch (http://monotouch.net/) SDK, 맥 OS X 환경에서 구동 가능한 iPhone 및 iPad SDK (http://developer.apple.com/iphone/), 그리고 Embacadero Delphi Prism XE (http://www.embarcadero.com/products/delphi-prism)를 활용하여 iPhone과 iPad에서 실행 가능한 응용프로그램을 디자인하는 것입니다. 이 중에서 상용 라이선스가 필요한 것은 MonoTouch와 Delphi Prism XE가 되겠습니다.

만약 Delphi가 아닌 C#을 이용하여 응용프로그램을 개발하기 원한다면 Delphi Prism XE 대신 MonoTouch와 함께 제공되는 기본 IDE인 MonoDevelop 만으로도 충분한 개발이 가능합니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

응용프로그램 작성 도중 C#의 소수점 반올림 관련 코드에서 몇몇 자주 사용되는 기능들을 보완하는 코드를 작성하여 올려봅니다. 이 코드는 http://www.latiumsoftware.com/en/delphi/00033.php 의 코드를 바탕으로 작성된 것입니다.

namespace System
{
    // Original Source: http://www.latiumsoftware.com/en/delphi/00033.php
    public static class MathExtension
    {
        public static int Sign(
#if CS3
            this
#endif // CS3
            decimal x)
        {
            return Math.Sign(x);
        }

        public static int Sign(
#if CS3
            this
#endif // CS3
            double x)
        {
            return Math.Sign(x);
        }

        public static int Integer(
#if CS3
            this
#endif // CS3
            decimal x)
        {
            return (int)Math.Truncate(x);
        }

        public static int Integer(
#if CS3
            this
#endif // CS3
            double x)
        {
            return (int)Math.Truncate(x);
        }

        public static decimal Fraction(
#if CS3
            this
#endif // CS3
            decimal x)
        {
            return x - Math.Truncate(x);
        }

        public static double Fraction(
#if CS3
            this
#endif // CS3
            double x)
        {
            return x - Math.Truncate(x);
        }

        public static decimal RoundUp(
#if CS3
            this
#endif // CS3
            decimal x)
        {
            return Integer(x) + Sign(Fraction(x));
        }

        public static double RoundUp(
#if CS3
            this
#endif // CS3
            double x)
        {
            return Integer(x) + Sign(Fraction(x));
        }

        public static decimal RoundDown(
#if CS3
            this
#endif // CS3
            decimal x)
        {
            return Integer(x);
        }

        public static double RoundDown(
#if CS3
            this
#endif // CS3
            double x)
        {
            return Integer(x);
        }

        public static decimal Round(
#if CS3
            this
#endif // CS3
            decimal x)
        {
            return Integer(x) + Integer(Fraction(x) * 2m);
        }

        public static double Round(
#if CS3
            this
#endif // CS3
            double x)
        {
            return Integer(x) + Integer(Fraction(x) * 2d);
        }

        public static decimal Fix(
#if CS3
            this
#endif // CS3
            decimal x)
        {
            if (x >= 0m || Fraction(x) == 0m)
                return Integer(x);
            else
                return Integer(x) - 1;
        }

        public static double Fix(
#if CS3
            this
#endif // CS3
            double x)
        {
            if (x >= 0d || Fraction(x) == 0d)
                return Integer(x);
            else
                return Integer(x) - 1;
        }

        public static decimal RoundDownFix(
#if CS3
            this
#endif // CS3
            decimal x)
        {
            return Fix(x);
        }

        public static double RoundDownFix(
#if CS3
            this
#endif // CS3
            double x)
        {
            return Fix(x);
        }

        public static int Absolute(
#if CS3
            this
#endif // CS3
            int x)
        {
            return Math.Abs(x);
        }

        public static decimal RoundUpFix(
#if CS3
            this
#endif // CS3
            decimal x)
        {
            return Fix(x) + Absolute(Sign(Fraction(x)));
        }

        public static double RoundUpFix(
#if CS3
            this
#endif // CS3
            double x)
        {
            return Fix(x) + Absolute(Sign(Fraction(x)));
        }

        public static decimal RoundFix(
#if CS3
            this
#endif // CS3
            decimal x)
        {
            return Fix(x + 0.5m);
        }

        public static double RoundFix(
#if CS3
            this
#endif // CS3
            double x)
        {
            return Fix(x + 0.5d);
        }

        public static decimal RoundTo(
#if CS3
            this
#endif // CS3
            decimal x, int d)
        {
            decimal n = (decimal)Math.Pow(10, d);
            x *= n;
            return (Integer(x) + Integer(Fraction(x) * 2m)) / n;
        }

        public static double RoundTo(
#if CS3
            this
#endif // CS3
            double x, int d)
        {
            double n = Math.Pow(10, d);
            x *= n;
            return (Integer(x) + Integer(Fraction(x) * 2d)) / n;
        }
    }
}

사용 예시는 다음과 같습니다.

using System;

namespace ConsoleApplication1
{
    public static class Program
    {
        [STAThread]
        public static void Main(string[] args)
        {
#if CS3
            Console.WriteLine("{0}", (3.3m).RoundUp() == 4m);
            Console.WriteLine("{0}", (-3.3m).RoundUp() == -4m);
            Console.WriteLine("{0}", (3.7m).RoundDown() == 3m);
            Console.WriteLine("{0}", (-3.7m).RoundDown() == -3m);
            Console.WriteLine("{0}", (3.5m).Round() == 4m);
            Console.WriteLine("{0}", (-3.5m).Round() == -4m);
            Console.WriteLine("{0}", (3.1m).Round() == 3m);
            Console.WriteLine("{0}", (-3.1m).Round() == -3m);
            Console.WriteLine("{0}", (3.7m).Integer() == 3);
            Console.WriteLine("{0}", (-3.7m).Integer() == -3);
            Console.WriteLine("{0}", (3.7m).Fix() == 3m);
            Console.WriteLine("{0}", (-3.7m).Fix() == -4m);
            Console.WriteLine("{0}", (3.7m).RoundDownFix() == 3m);
            Console.WriteLine("{0}", (-3.7m).RoundDownFix() == -4m);
            Console.WriteLine("{0}", (3.1m).RoundDownFix() == 3m);
            Console.WriteLine("{0}", (-3.1m).RoundDownFix() == -4m);
            Console.WriteLine("{0}", (3.1m).RoundUpFix() == 4m);
            Console.WriteLine("{0}", (-3.7m).RoundUpFix() == -3m);
            Console.WriteLine("{0}", (3.5m).RoundFix() == 4m);
            Console.WriteLine("{0}", (-3.5m).RoundFix() == -3m);
            Console.WriteLine("{0}", (123.456m).RoundTo(0) == 123.00m);
            Console.WriteLine("{0}", (123.456m).RoundTo(2) == 123.46m);
            Console.WriteLine("{0}", (123456m).RoundTo(-3) == 123000m);

            Console.WriteLine("{0}", (3.3d).RoundUp() == 4d);
            Console.WriteLine("{0}", (-3.3d).RoundUp() == -4d);
            Console.WriteLine("{0}", (3.7d).RoundDown() == 3d);
            Console.WriteLine("{0}", (-3.7d).RoundDown() == -3d);
            Console.WriteLine("{0}", (3.5d).Round() == 4d);
            Console.WriteLine("{0}", (-3.5d).Round() == -4d);
            Console.WriteLine("{0}", (3.1d).Round() == 3d);
            Console.WriteLine("{0}", (-3.1d).Round() == -3d);
            Console.WriteLine("{0}", (3.7d).Integer() == 3);
            Console.WriteLine("{0}", (-3.7d).Integer() == -3);
            Console.WriteLine("{0}", (3.7d).Fix() == 3d);
            Console.WriteLine("{0}", (-3.7d).Fix() == -4d);
            Console.WriteLine("{0}", (3.7d).RoundDownFix() == 3d);
            Console.WriteLine("{0}", (-3.7d).RoundDownFix() == -4d);
            Console.WriteLine("{0}", (3.1d).RoundDownFix() == 3d);
            Console.WriteLine("{0}", (-3.1d).RoundDownFix() == -4d);
            Console.WriteLine("{0}", (3.1d).RoundUpFix() == 4d);
            Console.WriteLine("{0}", (-3.7d).RoundUpFix() == -3d);
            Console.WriteLine("{0}", (3.5d).RoundFix() == 4d);
            Console.WriteLine("{0}", (-3.5d).RoundFix() == -3d);
            Console.WriteLine("{0}", (123.456d).RoundTo(0) == 123.00d);
            Console.WriteLine("{0}", (123.456d).RoundTo(2) == 123.46d);
            Console.WriteLine("{0}", (123456d).RoundTo(-3) == 123000d);
#else // !CS3
            Console.WriteLine("{0}", MathExtension.RoundUp(3.3m) == 4m);
            Console.WriteLine("{0}", MathExtension.RoundUp(-3.3m) == -4m);
            Console.WriteLine("{0}", MathExtension.RoundDown(3.7m) == 3m);
            Console.WriteLine("{0}", MathExtension.RoundDown(-3.7m) == -3m);
            Console.WriteLine("{0}", MathExtension.Round(3.5m) == 4m);
            Console.WriteLine("{0}", MathExtension.Round(-3.5m) == -4m);
            Console.WriteLine("{0}", MathExtension.Round(3.1m) == 3m);
            Console.WriteLine("{0}", MathExtension.Round(-3.1m) == -3m);
            Console.WriteLine("{0}", MathExtension.Integer(3.7m) == 3);
            Console.WriteLine("{0}", MathExtension.Integer(-3.7m) == -3);
            Console.WriteLine("{0}", MathExtension.Fix(3.7m) == 3);
            Console.WriteLine("{0}", MathExtension.Fix(-3.7m) == -4);
            Console.WriteLine("{0}", MathExtension.RoundDownFix(3.7m) == 3m);
            Console.WriteLine("{0}", MathExtension.RoundDownFix(-3.7m) == -4m);
            Console.WriteLine("{0}", MathExtension.RoundDownFix(3.1m) == 3m);
            Console.WriteLine("{0}", MathExtension.RoundDownFix(-3.1m) == -4m);
            Console.WriteLine("{0}", MathExtension.RoundUpFix(3.1m) == 4m);
            Console.WriteLine("{0}", MathExtension.RoundUpFix(-3.7m) == -3m);
            Console.WriteLine("{0}", MathExtension.RoundFix(3.5m) == 4m);
            Console.WriteLine("{0}", MathExtension.RoundFix(-3.5m) == -3m);
            Console.WriteLine("{0}", MathExtension.RoundTo(123.456m, 0) == 123.00m);
            Console.WriteLine("{0}", MathExtension.RoundTo(123.456m, 2) == 123.46m);
            Console.WriteLine("{0}", MathExtension.RoundTo(123456m, -3) == 123000m);

            Console.WriteLine("{0}", MathExtension.RoundUp(3.3d) == 4d);
            Console.WriteLine("{0}", MathExtension.RoundUp(-3.3d) == -4d);
            Console.WriteLine("{0}", MathExtension.RoundDown(3.7d) == 3d);
            Console.WriteLine("{0}", MathExtension.RoundDown(-3.7d) == -3d);
            Console.WriteLine("{0}", MathExtension.Round(3.5d) == 4d);
            Console.WriteLine("{0}", MathExtension.Round(-3.5d) == -4d);
            Console.WriteLine("{0}", MathExtension.Round(3.1d) == 3d);
            Console.WriteLine("{0}", MathExtension.Round(-3.1d) == -3d);
            Console.WriteLine("{0}", MathExtension.Integer(3.7d) == 3);
            Console.WriteLine("{0}", MathExtension.Integer(-3.7d) == -3);
            Console.WriteLine("{0}", MathExtension.Fix(3.7d) == 3);
            Console.WriteLine("{0}", MathExtension.Fix(-3.7d) == -4);
            Console.WriteLine("{0}", MathExtension.RoundDownFix(3.7d) == 3d);
            Console.WriteLine("{0}", MathExtension.RoundDownFix(-3.7d) == -4d);
            Console.WriteLine("{0}", MathExtension.RoundDownFix(3.1d) == 3d);
            Console.WriteLine("{0}", MathExtension.RoundDownFix(-3.1d) == -4d);
            Console.WriteLine("{0}", MathExtension.RoundUpFix(3.1d) == 4d);
            Console.WriteLine("{0}", MathExtension.RoundUpFix(-3.7d) == -3d);
            Console.WriteLine("{0}", MathExtension.RoundFix(3.5d) == 4d);
            Console.WriteLine("{0}", MathExtension.RoundFix(-3.5d) == -3d);
            Console.WriteLine("{0}", MathExtension.RoundTo(123.456d, 0) == 123.00d);
            Console.WriteLine("{0}", MathExtension.RoundTo(123.456d, 2) == 123.46d);
            Console.WriteLine("{0}", MathExtension.RoundTo(123456d, -3) == 123000d);
#endif // CS3
        }
    }
}

위의 코드에서 CS3 라는 매크로를 프로젝트 내에 설정하면 Extension Method로 사용할 수 있으며, 이 매크로의 선언을 해제하면 일반 정적 메서드로 변경하여 사용할 수 있습니다. 여러 메서드들이 있지만 그 중에서도 RoundTo 메서드는 사용 빈도가 매우 많은 함수일 듯 합니다. :-)

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.