2005년 이후로 줄곧 Microsoft를 깊이있게 심층취재하는 기자들 사이에서 Microsoft의 차세대 운영 체제에 대한 이야기가 자주 회자되고 있습니다. 그 중 가장 많은 화제거리를 제공하는 소재는 단연 MIDORI 였습니다. 클라우드 컴퓨팅 기술과도 엮이면서 한층 더 궁금증을 증폭시키기도 했었지요. 그러나, 오늘 글에서는 MIDORI에 대한 이야기는 잠시 뒤로 미루고, 지금 볼 수 있는, 한창 개발 중인 운영 체제 두 종류를 대신 이야기해보기로 하겠습니다. Singularity는 현재 Codeplex에 게시되어있는 RDK를 실행하고 분석해본 후 제 나름대로 경험해본 특이한 사항들을 요약해서 적어놓은 것입니다.

Singularity는 2008년경에 Microsoft Research (이하 MSR)에서 Research Development Kit (이하 RDK)의 형태로 Codeplex 홈페이지에 올렸습니다. Singularity는 하드 디스크의 MBR 영역에 설치되는 작은 크기의 부트 로더 프로그램을 제외하고 모든 것이 관리 영역 안에 속하는 독특한 운영 체제입니다. 컴퓨터 과학에서 표현하는 3단계 Ring Protection Layer로 말할 것 같으면, 가장 핵심 부분인 Ring 0부터 가장 외부적인 부분인 Ring 3까지 전부 가비지 컬렉터와 관리되는 런타임 아래에서 관리되는 셈입니다.

Singularity RDK에는 OS의 소스 코드 외에도, Singularity에서 사용할 수 있는 응용프로그램을 제작할 수 있는 Bartok 컴파일러와 Singularity OS에 최적화된 CLR/CLI 라이브러리가 포함되어있습니다. Singularity 기반으로 실행되는 응용프로그램을 만들기 원한다면, C# 1.0의 문법을 기초로 하는 Spec#을 확장한 Singularity의 시스템 프로그래밍 언어인 Sing#을 사용할 수 있으며, Sing#으로 작성된 소스 코드를 Bartok 컴파일러로 컴파일하면 해당 프로세서 아키텍처에 맞는 직접적인 응용프로그램 코드가 생성되는 형태입니다. C/C++ 컴파일러와 다른점이 있다면, Bartok 컴파일러가 생성하는 코드에는 D 언어와 마찬가지로, 그러나 Java나 우리가 기존에 알고 있던 .NET Framework와는 달리, 자체적인 가비지 컬렉터를 내장하고 있다는 점입니다.

Sing# 언어의 경우는, 모든 경우를 다 살펴볼 수 없지만, Rotor Framework를 통해서 실체가 밝혀진 C#의 hidden keyword 중 하나인 __arglist와 같이 ECMA 규격 상에 포함되지 않은 특수 키워드들이 다수 포함되어있습니다. __arglist는 C/C++의 varargs와 대응되는 의미로 사용되었지만, Singularity 환경 아래에서는 관리 형식의 배열보다 좀 더 최적화된 (어떤 의미에서는 불안정한) 배열 타입을 제공하기 위한 것으로 보입니다.

Singularity는 연구 목적으로 활용되는 것 이상으로는 이용할 수 없는 라이선스 제약이 있습니다. 상용으로 채택할 경우 라이선스 위반이 됨을 유의해야 합니다. 이러한 제약 사항 아래에서, 자유롭게 소스 코드를 살펴보고, ISO 이미지를 다운로드받아서 VMware나 Windows Virtual PC에서 부팅시켜보시려면, http://singularity.codeplex.com/ 페이지에 제공된 소스 코드나 ISO 이미지를 다운로드받으시면 되겠습니다. :-)

그리고 오늘 아티클에서는 Singularity 외에 MSR과 관련되어있는 또 다른 연구형 운영 체제 한 종류를 더 짚어보기로 하겠습니다. 바로 Barrelfish입니다. Barrelfish는 캠브릿지 MSR과 스위스 취리히의 취리히 연방 공과대학교 산하 Systems가 공동으로 2007년 10월부터 진행 중인 오픈 소스 프로젝트이며, 변형된 BSD 라이선스인 3-clause-BSD 라이선스를 제시합니다. 기본 BSD 라이선스와는 달리, 소스 코드 / 바이너리와 관계없이 원저자의 이름을 명시해야 하고, 원저자의 이름을 Barrelfish 기반의 소프트웨어에 관하여 사용할 수 없다는 제약이 붙습니다.

Barrelfish OS는 C 언어와 어셈블리를 주로 사용하며, 현재 스냅샷 기준으로 x64 (AMD64) 모드를 대상으로 하며, 멀티 코어 프로세서에 최적화된 OS를 만드는 것에 관한 다양한 기술적 이론이 집약된 고성능 운영체제이지만, 리눅스나 윈도우와는 전혀 별개의 브랜치를 가집니다. 어떤 형태로 발전하게 될지는 알 수 없지만, 향후 출시될 Windows Server Family에도 영향을 줄 수 있는 부분처럼 보입니다. 그리고 Barrelfish 자체로도 연구 목적에 맞는 고성능 서버OS로 업그레이드할 계획이 있다는 것이 프로젝트 설명 페이지에 제시된 내용입니다.

Barrelfish의 홈페이지 (http://www.barrelfish.org)는 Barrelfish OS를 기반으로 운영되는 웹 서버에서 서비스 중이라는 특징적인 문구가 홈페이지 하단의 footer에 붙어있습니다. Public Domain에서 서비스할 수 있을만큼 OS가 고성능이고 안정적이라는 뜻으로 받아들여도 될 것입니다.

Barrelfish의 소스 코드를 구경하고 싶으시다면, http://www.barrelfish.org/barrelfish-20091219.tar.bz2 에서 다운로드하실 수도 있습니다.

앞으로 어떤 형태로 새로운 운영 체제들이 나타날지 아직은 아무도 알 수 없습니다만, 미래를 조심스럽게 예측해 보는 것은 참 의미있는 일이라고 생각합니다. 짧은 글이었지만, 클라우드 컴퓨팅, 그리드 컴퓨팅, 멀티코어 컴퓨팅 등 새로운 컴퓨팅 패러다임에 걸맞는 새 시대의 운영 체제를 미리 탐험해 보았습니다.

저작자 표시 비영리 동일 조건 변경 허락
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by Windows Azure MVP 남정현 (rkttu.com)

The Code Project Open License (CPOL)

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 아니오
* 명시적 특허권 행사 가능 여부: 예
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오

The Common Development and Distribution License (CDDL)

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 예**
* 명시적 특허권 행사 가능 여부: 예
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오

The Microsoft Public License (Ms-PL)

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 아니오
* 명시적 특허권 행사 가능 여부: 예
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오

The Mozilla Public License 1.1 (MPL 1.1)

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 예**
* 명시적 특허권 행사 가능 여부: 예
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오

The Common Public License Version 1.0 (CPL)

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 예**
* 명시적 특허권 행사 가능 여부: 예
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오

The Eclipse Public License 1.0

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 예**
* 명시적 특허권 행사 가능 여부: 예
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오

The MIT License

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 아니오
* 명시적 특허권 행사 가능 여부: 아니오**
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오

The BSD License

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 아니오
* 명시적 특허권 행사 가능 여부: 아니오**
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오

The Apache License, Version 2.0

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 아니오
* 명시적 특허권 행사 가능 여부: 예
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오

The Creative Commons Attribution-ShareAlike 2.5 License

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 아니오
* 명시적 특허권 행사 가능 여부: 아니오**
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 아니오**
* 라이센스 전파 여부: 예**

The zlib/libpng License

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 아니오
* 명시적 특허권 행사 가능 여부: 아니오**
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오

공개 커뮤니티에 대한 공헌 (라이센스 아님)

* 저작권 보호: 아니오**
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 아니오
* 명시적 특허권 행사 가능 여부: 아니오**
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오

The GNU Lesser General Public License (LGPL)

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 예**
* 명시적 특허권 행사 가능 여부: 아니오**

* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 예**

The GNU General Public License (GPL)

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 예**
* 명시적 특허권 행사 가능 여부: 아니오**
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 아니오**

* 라이센스 전파 여부: 예**

노트: ** 기호가 붙은 항목은 라이센스 선택 시 고려해야 할 주의 사항입니다.
출처: http://www.codeproject.com/info/Licenses.aspx

크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by Windows Azure MVP 남정현 (rkttu.com)

C와 C++에서 사용하는 버클리 소켓은 데이터를 주거나 받을 때 char 형식의 배열을 이용한다. .NET Framework에서도 char 형식과 가장 근접한 데이터 형식인 byte 형식의 배열을 이용한다. 하지만 약간의 호기심이 생겼다. 생각없이 사용하는 이들 소켓 API의 두 데이터 타입은 과연 숫자 범위까지 같은것일까?

C와 C++의 char 데이터 형식은 -128 ~ +127까지를 표현할 수 있다. 반면 .NET Framework의 byte는 0 ~ +255까지 표현이 가능하다. 정작 C와 C++과 호환성을 유지하기 위해서는 byte가 아닌 sbyte여야 했는데 왜 byte를 사용하게 된 것일까? sbyte는 char와 완전히 같은 데이터 범위를 보장함과 동시에 크기도 같다. 하지만 CLSCompliant(false) 플래그가 붙어있고 sbyte를 기반으로 구현된 소켓 API는 닷넷에 없다.

그래서 간단히 실험을 해보았다.

우선 .NET Framework의 소켓에서 BSD 소켓으로 데이터를 보내보았다. 물론 두 데이터 타입이 특별한 처리를 하지 않고도 표현할 수 있는 범위의 수인 0 ~ 127까지는 특이한 점이 없었다. 하지만 128 ~ 255의 값은 BSD 소켓에서 어떻게 받아들여질까? 대강 예상하고 있었고 실제로도 그렇게 되었는데, 음수로 뒤집어서 전달되었다. 순환 오버플로우와 유사하다는 생각이 들었다.

이번엔 반대로 BSD 소켓에서 .NET Framework의 소켓으로 데이터를 보내보았다. 위와 마찬가지로 0 ~ 127까지는 있는 그대로 전달되었다. 하지만 -128 ~ -1까지의 값은 음수로 전송되었지만 .NET Framework의 입장에서는 127 이후부터 255 사이의 양수값으로 바뀌어 들어갔다. 이 역시 순환 오버플로우와 유사한 동작이었다.

영양가 없는 실험이었지만 나름 궁금함은 풀어볼 수 있어서 좋았던것 같다. 그리고 결론을 하나 더 얻었는데, 실질적으로 우리가 네트워크를 통해서 전송하고자 하는 데이터의 범위는 0 ~ 127 안일 확률이 매우 높다. 2바이트 문자열과 유니코드 문자열도 결국은 이 범위 안에서 처리하도록 만들어지게 된다고 생각할 수 있겠다.

크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by Windows Azure MVP 남정현 (rkttu.com)