OPEN Solaris 리포트

썬의 유닉스 운영체제인 솔라리스가 10 버전의 오픈소스화와 다양한 프로젝트 진행 등에 힘입어 다시금 힘찬 기지개를 켜고 있다. 여기에 다중 프로세서 지원과 가상화, 그리고 리눅스 애플리케이션지원이라는 믿음직한 날개까지 달아 2007년 이후의 활약을 기대케 하고 있다. 이처럼 오픈 솔라리스(Open Solaris)는 ‘또 하나의 리눅스’에 비유될 만큼 우리에게 친숙한 운영체제의 모습으로 변화하고 있지만, 그 진가를 정확히 이해하는 이들은 그다지 많지 않다. 따라서 마소는 어느덧 첫 돌을 넘기면서 저변 확대해 한층 힘 쏟고 있는 오픈 솔라리스의 이모저모를 개발자의 시각에서 분석해봤다.

1990년대 말, 이른바 닷컴(DOT.COM) 시대에 대부분의 백엔드 환경을 점유했던 썬의 솔라리스는 인터넷 환경을 주도하는 네트워크 환경에 가장 발전된 운영체제였다. 이러한 발전이 결국 썬의 자만심을 불러일으켰을까?

가정에서 사용되는 PC가 윈도우와 리눅스 등의 발달로 단순한 클라이언트의 역할에서 서버로서의 기능까지 수행 가능해지면서 IT 서비스의 세계는 새로운 변화의 물결을 맞이하게 되었다. 무엇보다 리눅스의 획기적인 성장은 x86 플랫폼에 신선한 바람을 불어넣기 시작했고, 이제는 비교적 덜 중요한 업무 환경에서 많이 쓰이게 되었다.

소스 공개의 힘
사람들은 리눅스가 성장하게 된 가장 기본적인 배경으로 특히 소스 공개에 주목했다. 임의의 불특정 사용자들이 이용 중에 느껴지는 불편함을 참다못해 스스로 수정하게 되다 보니, 지금은 엔터프라이즈 운영체제와 맞먹는 기능들을 가지게 되었고, 이 과정에 직접 참여한 사용자들은 그 자신의 공헌을 외부에 알리기 위해 노력하면서 리눅스의 세계가 크게 성장했다고 볼 수 있다.

썬은 바로 이 부분에 주목했다. 끊임없이 첨단 기술을 개발해 추가하려면 엄청난 개발 비용이 필요했고, 이렇게 만들어진 솔라리스를 팔기 위해서는 역시 적지 않은 마케팅 비용이 요구되었다. 또한 첨단 기술을 개발하는 속도가 오픈소스 계열에 점차 뒤쳐지기 시작했다는 점도 무시할 수 없었다. 물론, 오픈소스 세계에서는 쉽게 상상할 수 없는 기능을 개발하기도 하겠지만, 그러한 기능이 시장에서 경쟁력을 가지도록 하기 위해서는 또 다른 노력이 필요했다.

이런 고민 끝에 썬은 마침내 자사의 지적 재산권 목록에서 큰 부분을 차지하고 있던 솔라리스의 소스를 공개하기에 이르렀다. 이름하여 오픈 솔라리스(http://open solaris.org)가 등장한 것이다.

오픈 솔라리스는 기존의 유닉스 사용자들과 리눅스 사용자들에게 대단한 관심을 불러일으켰는데, 그 이유는 솔라리스를 보는 관점에 따라 다양했다. 유닉스의 고비용 때문에 리눅스로 옮겼던 사용자들은 오픈 솔라리스를 통해 다시금 유닉스(솔라리스)로 돌아갈 수 있게 된 점을 매우 크게 반겼다. 오픈된 솔라리스를 통해 저비용으로 엔터프라이즈 수준의 운영체제를  사용할 수 있게 되었기 때문이다. 또한 기존의 솔라리스를 사용하던 사용자들은 오픈된 솔라리스의 소스를 통해 솔라리스의 커널 구조, 디바이스 관리 구조 등을 완벽하게 이해함에 따라 보다 안정된 구조의 솔라리스 환경을 구축할 수 있게 되었다.



개발자를 위한 새로운 선택, 오픈 솔라리스
지금으로부터 약 1년 6개월 전인 2005년 6월에는 IT 업계에 무척 흥미로운 소식이 있었다. IT 인프라스트럭처(Infrastructure) 분야의 거대 기업 가운데 하나인 썬마이크로시스템즈(이하 썬)가 자사의 하드웨어 상에서 운용되고 있던 솔라리스 10(Solaris10)의 소스 코드를 대부분 공개해 이른바 ‘오픈 솔라리스’의 등장을 알린 것이었다. 이후 적지 않은 시간이 흘러 오픈 솔라리스는 개발자들에게 새로운 무대가 되었다. 1부에서는 그 진면모를 소개한다.

이는 취약한 보안성에 시달려온 리눅스 관리자들에게도 희소식이었다. 기존까지 미국방성으로부터 유일하게 인정받은 보안 기술을 가진 솔라리스를 무상으로 사용하게 됨에 따라 전체적으로 혹은 선택적으로 솔라리스 기반의 강력한 보안 환경을 구축할 수 있게 되었기 때문이다. 아울러 리눅스 및 유닉스용 보안 툴을 개발해 제공했던 보안 개발업체들도 솔라리스의 발전된 보안 기술을 참조할 수 있게 되었고, 이는 보다 향상된 보안 솔루션을 만들 수 있는 계기로 작용했다.

CDDL 기반의 오픈
더욱이 활발히 활동하는 리눅스 혹은 FreeBSD와 같은 오픈소스 개발자들은 솔라리스의 소스코드를 참조하여 한층 나아진 오픈소스를 작성할 수 있게 되었다. 특히, 솔라리스 10에 새롭게 추가된 독보적인 기능(Dtrace, ZFS)들은 오픈소스 계열의 운영체제 개발자들로 하여금 깊은 관심을 불러 일으켰고, 그 결과 MacOS나 FreeBSD에서는 새로 발표한 각자의 베타 버전에 솔라리스 10의 Dtrace와 ZFS를 이미 포팅했거나 현재 포팅하고 있다.

개발자들을 위한 오픈 솔라리스의 이런 특성 외에 법률적인 관점에서도 주목할 만한 특징이 하나 있다. 오픈 솔라리스는 기존의 오픈소스 라이센스인 BSD 라이센스의 변형이자 썬의 새로운 배포 라이센스인 CDDL(Commnon Development and Distri bution License)을 기반으로 소스를 공급한다. 이는 기존의 GPL 기반의 라이센스와는 매우 다르다. GPL은 GPL하의 소스 코드를 참고하여 작성된 모든 결과물은 오픈되어야 하는 반면에, CDDL은 오픈 솔라리스의 소스 코드를 참고해 작성된 결과물이라 하더라도 그 소스를 반드시 오픈할 필요가 없다. 이는 오픈소스를 기반으로 작성한 애플리케이션을 판매하는 업체들에게 매우 유리한 조건이 아닐 수 없다. 기존의 GPLv2 기반의 소스들을 참고해 만든 것을 수출했다가 GPL 위반 사유로 소송당한 업체들이 점점 증가하는 것으로 보아 오픈 솔라리스의 CDDL은 오픈소스를 참조해 새로운 솔루션을 개발하는 업체들에게 매우 매력적인 배포 라이센스가 아닐 수 없다.

결론적으로 오픈 솔라리스를 통해 기존의 개발자들은 무엇을 얻을 수 있을까? 비록 솔라리스가 일반 개발자들에게에게 그다지 친숙한 데스크탑용 운영체제가 아닌 터라 쉽게 다가가기는 어려울 것이다. 하지만 아주 오랜 기간 네트워크를 염두에 두고 만들어진 운영체제이므로, 네트워크를 바탕으로 하는 애플리케이션 개발자들은 가장 신뢰성 있는 참조 구현(reference implement ation)을 하나 얻은 셈이다.

때문에 일반 애플리케이션을 개발하는 이들에게는 신뢰성 있는 소스 코드를 제공함에 따라 보다 완성도 높은 애플리케이션의 제공이 가능해졌고, 커널 애플리케이션을 개발하는 개발자들은 대표적인 유닉스 운영체제에 이용된 커널의 모든 코드를 볼 수 있게 됨에 따라 유닉스의 내부 구조를 보다 잘 이해하게 되었다. 따라서 안정적인 커널 코드를 더 빠르게 구축할 수 있게 되었고, 임베딩이나 커널 드라이버 개발 등에도 많은 도움이 될 전망이다.

우수한 안정성
한편 리눅스 운영체제의 또 하나의 중요한 특징으로 다수의 자발적인 프로그래머들에 의해 구현 및 구성된다는 점을 꼽을 수 있다. 사실 이런 상황에서 코드의 안정성을 확보하는 것은 매우 어렵다. 따라서 리눅스는 다소 독특하게 ‘안정판(stable edit ion)’이라던가 ‘베타판(development release)’이라는 이름으로 다양한 릴리즈가 소개되고 있고, 이러한 릴리즈를 테스트해서 제공하는 배포판 업체들 역시 난립하고 있다.

이런 현실은 기술의 발전 측면에서는 좋을지 모르나, 특정 솔루션을 개발하는 개발자나 꾸준한 호환성을 필요로 하는 기업의 데이터센터 관리자의 입장에서는 결코 행복한 일일 수 없다. 어디에 기준을 두고 호환성을 유지할 것인지 난감하기 때문이다. 실행 파일 면에서는 모든 리눅스에서 실행되어야 함에도 불구하고, 패키지의 차이(패키징 방식, 포함된 라이브러리 등) 때문에 어떤 배포판에서는 수행될 수도 있고 안될 수도 있는 일이 발생한다.

이와 달리 솔라리스는 기존에 어느 정도 수준 이상으로 완성되어 있는 코드 위에서 확장하면서 호환성을 유지하도록 프로젝트 커뮤니티의 통제가 이뤄지기 때문에 매 릴리즈 사이에 새로운 기술을 추가하면서도 그 호환성을 충분히 유지할 수 있도록 운영되고 있다. 물론, 현재 3~4개 정도인 오픈 솔라리스 배포판의 종류가 더 늘어나면 지금의 리눅스에서와 같은 문제가 없으리라고는 보장하기가 힘들지만, 필자는 리눅스 계열보다는 적을 것으로 확신한다.

각 배포판의 특징
오픈 솔라리스는 썬에서 공급하는 3개의 배포판을 제외하고 현재 4개의 배포판이 제공되고 있다. 썬에서 제공하는 3가지는 각각 Solaris Express, Solaris Express Community Release, Sun Solaris이다. 이 가운데 Solaris Express Community Rel ease가 오픈 솔라리스를 바탕으로 만드는 가장 최신 빌드로, 이는 업데이트 서비스가 없는 무상 제품이다. 반면, 여기에 업데이트 서비스를 제공하는 배포판은 Solaris Express에 해당된다. 그리고 이 최신 빌드를 기반으로 썬의 추가 테스트와 별도 소프트웨어 패키지를 추가한 배포판이 바로 썬 솔라리스(Sun Solaris)가 되는 셈이다.

썬 솔라리스 이외에 현재 공급되고 있는 솔라리스 배포판 가운데 가장 왕성하게 활동하고 있는 배포판은 NexentaOS이다. 이는 오픈 솔라리스의 커널과 주요 실행 파일 및 필수 라이브러리만을 가지고, 그 외에는 완전히 GNU/오픈소스 기반의 유틸리티와 GUI, 데비안 패키징 시스템을 제공함으로써 기존에 데비안 패키징을 적용한 리눅스를 경험한 이용자들에게는 거의 차이가 없는 인터페이스를 제공한다. 이 때문에 사용하기가 편리하면서도, 리눅스 사용자들로 하여금 빠르게 솔라리스에 적응할 수 있도록 돕는 버전으로 평가된다. 또한 오픈 솔라리스 배포판중 가장 주목 받고 있는 릴리즈이기도 하다.

아쉽게도 현재 나와 있는 최신 배포판인 NexentaOS Alpha6는 OpenSolaris build 50에 기초하고 있으면서도, 한글이 지원되지 않아 국내에서 이용하기에는 다소 무리가 있다. 그러나 절제된 패키지와 가벼운 구조에 의한 빠른 속도, 완벽한 리눅스 인터페이스에 온전한 솔라리스 기능들은 충분히 매력적임에 틀림없다.
이처럼 기존 개발자들의 깊은 관심을 이끌어낸 오픈 솔라리스의 최신 기능을 지금부터 살펴보기로 하자.

SunOs 5.11 커널
오픈 솔라리스의 커널은 SunOS로 명명되어 있다. 레드햇이나 수세 리눅스의 커널이 Linux로 표시되는 것과 같은 개념이라고 할 수 있다. 현재 쓰이고 있는 SunOS 5.11은 최신 솔라리스 10의 기본이 되는 커널 버전으로 네트워크 서비스, 분산 컴퓨팅, SMP & NUMA, 멀티코어와 같은 최신 기술 모두에 최적화되어 있다. 이 버전은 유닉스 및 유사 유닉스 운영체제 가운데 가장 진보된 커널로 자타가 인정하고 있다. 특히 솔라리스는 아주 이른 시기부터 멀티코어에 최적화되어 있고, 심지어 AMD의 옵테론이 구성하는 유사 NUMA 구조에도 최적화되어 있다. 최신의 저가 하드웨어 기술에도 적합한 운영체제인 셈이다.

썬은 솔라리스에 컴퓨팅 이론을 구현하는 데 많은 공을 들였고 이러한 노력 덕분에 솔라리스의 명성이 유지될 수 있었다. 솔라리스 10의 등장과 오픈 솔라리스로 변신한 이후, 그러한 솔라리스의 사고와 기술은 다른 운영체제에도 지속적으로 영향을 주었다.

솔라리스의 커널은 특히 SMP 시스템에 가장 안정적이고 최적화된 것으로 알려져 있으며 실제로 썬은 업계에서 유일하게 최대 144개의 CPU 코어를 가지고 있는 단일 박스(SMP)를 솔라리스와 함께 제공하고 있다. 많은 CPU를 운영할 수 있다는 것은 커널 자체의 병렬화가 우수함을 의미하는 것이다. 때문에 솔라리스는 우수한 멀티스레드 하부 시스템을 제공하고 있다. 웹 서버와 같은 인터넷 서비스들은 대개 멀티 스레드를 이용해 작동하도록 구성되는 것이 최근의 흐름임을 감안하면, 솔라리스가 인터넷 서비스에 매우 적합하다는 점을 쉽게 예측할 수 있다. 솔라리스 커널의 특징을 간략하게 요약하면 다음과 같다.

● 시스템 콜 인터페이스
모든 유닉스 및 유사 유닉스 운영체제가 그렇듯이 모든 사용자 프로세스는 커널과 커뮤니케이션하기 위해 시스템 콜을 써야한다.

● 프로세스 관리와 스케줄링
프로세스의 생성, 실행, 관리, 종료 등과 같은 모든 프로세스/스레드 관련 행위를 관리하며, 스케줄러는 이러한 스레드에 대해 우선순위 기반의 스케줄링을 지원한다. 완벽한 우선순위 기반의 사전 스케줄링(preemption)을 지원함으로써 실시간 애플리케이션을 지원한다.

● 가상 메모리 시스템
가상메모리 시스템을 만들어 실제 메모리를 사용자 프로세스와 커널에 제공한다. 솔라리스 메모리 관리는 크게 2개의 계층으로 구분된다. 하나는 공통 메모리 관리 계층이고 다른 하나는 하드웨어 지원 계층이다.

● 파일시스템 인터페이스
솔라리스는 가상 파일시스템 프레임워크를 구현한다. 때문에 다양한 종류의 파일시스템(ufs, nfs, hsfs, specfs, procfs, sockfs 등)이 가상 파일시스템 내부에 장착되어 사용자가 모든 형태의 파일시스템을 일관된 방법으로 접근, 제어할 수 있도록 한다.

● 구조적 I/O 버스와 장치 관리
솔라리스 I/O 프레임워크는 버스를 중심으로 연계되어 있는 장치를 구조적으로 (hiercarchical) 관리하도록 되어있다.

● 네트워킹
TCP/IP 프로토콜 관련 기능을 지원한다. SunOS 5.10 이후부터는 이전 커널과 달리 TCP와 IP의 드라이버를 단일 드라이버로 통합함으로써 레이어간에 발생할 수 있는 지연시간을 단축했다.

오픈 솔라리스의 주요 기능
이와 같은 SunOS 5.10을 기반으로 작성된 Sun Solaris 최신 배포판은 다수의 새로운 기능을 가지고 있다. 그 중에 커널과 관련이 있는 주요 기능을 정리하면 다음과 같다.

- 자가 치유 기능
- 솔라리스 서비스 관리
- 솔라리스 장애 관리
- 솔라리스 존(가상서버)
- 동적 자원 풀
- 동적 트레이싱 툴(Dtrace)
- 프로세스 권한 관리
- 솔라리스 보안 확장셋(Trusted Extension)
- ZFS

그 외의 솔라리스 10에 추가된 기능들을 확인하고 싶다면  http://www.sun.com/software/solaris/whats_new.jsp를 참조하길 바란다.

솔라리스 장애 관리, 서비스 관리 기능과 자가 치유 기능
솔라리스의 자가 치유 기능은 기술적으로 솔라리스 서비스 관리 기능과 솔라리스 장애 관리 기능의 구현으로 인해 자동으로 생겨난 솔라리스의 기능이라고 볼 수 있다. 솔라리스 장애 관리자는 솔라리스 내에 구성된 장애 감시 대상 오브젝트들을 실시간으로 감시하다가 장애 발생시 이에 대한 통보와 조치를 취하게 되는데, 이때 부연으로 발생하는 서비스 장애에 대응할 수 있도록 생성된 것이 솔라리스 서비스 관리 기능이다. 예를 들어, 특정 CPU에 장애가 발생해서 운영체제가 그 CPU를 오프라인(offline)시켜야 하는 경우를 생각해보자.

이때 강제 오프라인을 하게 되면 그 CPU에서 동작하던 애플리케이션은 우선 정지(kill)된다. 이때 서비스 매니저는 정지된 해당 서비스를 새롭게 자동으로 시작할 수 있도록 지원해줌으로써 서비스는 자동으로 복구된다. 덕분에 기존의 시스템과 서비스의 가용성을 크게 늘릴 수 있다. 설사 서비스가 죽었다 하더라도 빠르게 서비스를 재가동할 수 있도록 지원함으로써 관리자는 서비스 중지에 따른 피해를 최소화할 수 있다는 얘기다. <화면 4>는 장애를 실시간 보고해주는 한 예이다.

솔라리스의 가상화와 존(솔라리스 컨테이너)
썬은 최신 경향에 걸맞게 다양한 형태의 가상화 기법을 하드웨어와 소프트웨어에 제시하고 있다. 썬의 최신 멀티코어를 이용한 SPARC 기반의 하드웨어에는 LDom이라는 논리적 기법의 파티션 기능이 추가되어 있다. 이는 하나의 박스를 여러 개의 박스가 있는 것처럼 분리해주고, 각각의 영역에 새로운 운영체제를 설치할 수 있도록 하는 기술이다. 기존 IBM의 LPAR과 매우 흡사한 기능을 제공하고 있는 것이다. 그러나 이 기능은 아직 썬의 SPA RC 하드웨어 제품에서만 구현할 수 있다. 

이와 함께 제공되는 솔라리스의 존은 최근 강력해진 하드웨어의 성능을 바탕으로 발전하고 있는 가상화 기술의 일종이다. 흔히 알려져 있는 가상화의 대표주자인 VMWARE의 방식과는 달리, 게스트 영역에 별도의 운영체제를 사용하지 않고 호스트 운영체제를 빌려 쓰는 기법을 사용한다. 기술적으로 하나의 운영체제를 마치 여러 개의 운영체제가 있는 것처럼 보이게 만드는데, 이는 자원관리 기능을 확장한 기술로 구현한 가상화 기법이라고 할 수 있다.

이 기법은 VMWARE류의 가상화 기술이 가지고 있는 오버헤드를 완전히 없앰으로써 동일 운영시스템, 혹은 다른 버전의 동일 운영 시스템에서 서비스할 수 있는 애플리케이션들을 가상화 영역으로 분리해 하드웨어 활용률을 극대화할 수 있다. 뿐만 아니라 각 가상화 영역별로 관리의 독립과 보안성 개선, 안정성 개선 등을 이뤄낼 수 있다. 기존에는 단일 솔라리스 영역에 웹 서버, DB 서버, 웹 애플리케이션 서버들을 모두 설치해 사용했다면, 여기서는 존을 이용해 각각을 분리함으로써 용도별 분할 관리가 가능해지고 더 쉬어졌다. 아울러 전체적인 관리의 효율성도 증가해 관리에 소요되는 시간도 줄일 수 있게 되었다.

또한, 오픈 솔라리스 build 49에는 x86 솔라리스만을 위한 존 기능이 추가되어 있는데, 존 영역에 솔라리스 버전뿐만 아니라 32비트 레드햇 계열의 리눅스도 설치할 수 있게 되었다. 이 기능 덕분에 인텔이나 AMD 프로세서 환경에 설치된 솔라리스 안에는 32비트 리눅스도 함께 설치해 운영할 수 있게 되어, 솔라리스로 이동하려는 관리자나 리눅스의 애플리케이션이 어떻게 동작하는 지를 솔라리스의 Dtrace로 추적해보고 싶은 개발자들이 흥미를 느끼기에 충분하다.

동적 자원 관리 풀
솔라리스는 풀(pool) 개념을 도입하여 자원을 관리할 수 있는 기능을 제공한다. 필요한 작업(project, task, zone)에 필요한 양만큼의 자원(CPU, 메모리)등을 동적으로 할당해 사용할 수 있게 해준다. 즉 특정 프로젝트나 업무를 만들어 그 영역에 필요한 만큼 할당해 사용하고, 필요가 사라지면 자원을 동적으로 조절할 수 있게 하는 것이다. 존도 기술적으로는 일련의 업무(project) 모임이므로 동적 자원 관리의 대상이다. 오픈 솔라리스에서는 이러한 동적 자원 관리가 한층 지능화되어 CPU 사용률에 따라 CPU의 자동 추가 등을 구성할 수 있다.

동적 시스템 추적 툴(Dtrace)
솔라리스 10에 처음으로 추가된 동적 추적 툴인 Dtrace는 그야말로 IT 업계에 커다란 충격을 줬다. 기존의 운영체제들이 제공해왔던 사후추적 방식의 툴이 지닌 한계를 벗어나서 실시간으로 이벤트 중심의 동적 추적을 업계에서 최초로 구현했기 때문이다. 

모든 시스템 및 운영체제에서 그렇듯이 정상적인 경우에는 문제될 것이 없다. 늘 비정상적인 경우에 문제가 발생하며, 그 대부분은 예측하지 못했을 때다. 따라서 주로 업무가 마비된 이후에 문제를 알게 되므로 그 비정상적인 경우를 재생, 추적하기란 결코 쉽지 않다. 이때 Dtrace는 예상된 영역에 덫(?)을 놓아 특정 이벤트가 실행되면 보고할 수 있게 한다. 이 기술을 이용하여 솔라리스 커널 자체의 버그, 시스템 튜닝, 애플리케이션의 메모리 릭(memory leak)이나 병목 등을 예전과 달리 훨씬 쉽게 추적할 수 있다.

Dtrace는 그 기능을 통해 이미 타 운영체제 개발자들에게 많은 영감을 주었다. 앞에서 언급한 바와 같이 애플이 Dtrace 기능을 MaxOSX의 차기 개발 버전(Machintosh OSX Leopard 버전)의 Xcode에 포팅해둔 것만 봐도 얼마나 유용한 기능인지를 짐작할 수 있다. 이처럼 Dtrace는 커널 중심이 아니라 프로세스 중심이면서 데이터와 사용자 중심의 관점으로 접근하는 객체 지향적인 기술을 이용해 처리의 흐름을 파악한다. 이를 통해 비정상 문제를 야기하는 근본적인 원인을 빠르게 추적할 수 있다.          

프로세스 권한 관리
전통적인 유닉스 계열에서는 root, 즉 슈퍼 유저이면 모든 것을 할 수 있었다. 실제로 슈퍼 유저는 특정 업무를 위해서만 사용되어야 함에도 불구하고, 많은 곳에서 root를 노출해 사용하거나 공유하고 있다. 이렇게 되면 자연스레 시스템은 보안에 매우 취약해질 수밖에 없다. 솔라리스는 기본적으로 root가 할 수 있는 모든 업무들을 일정한 범주의 역할로 구분하고 사용자들에게 역할을 할당한다.

이로써 root로 해야 하는 업무를 일반 사용자로 수행하면서도 root가 할 수 있는 실수를 원천적으로 방지할 수 있고, 동시에 이러한 시스템의 이용을 통해 실질적인 root 사용자를 완전히 없앨 수도 있다. 이 기능은 솔라리스 하부에 있는 RBAC와 함께 이용되어 특정 프로세스에 대한 권한을 조정할 수도 있다. 이처럼 특정 사용자나 특정 역할에 대해 권한을 조정할 수 있게 됨으로써 한층 강화된 보안과 관리가 가능하다. 

ZFS
썬이 솔라리스를 오픈하기 이전부터 해결하고자 했던 하나의 프로젝트가 있었는데, 그것은 바로 지난 30년간 솔라리스의 기본 파일시스템이었던 UFS를 대체할 만한 파일시스템을 만드는 것이었다. 이 프로젝트의 결과는 오랜 검토와 코딩, 그리고 테스트를 거쳐 등장하게 되었는데, 마침 솔라리스의 오픈화와 시기가 맞물려 오픈소스의 세계에 모습을 나타내게 되었다. 그것이 바로 ZFS이다.

이 파일시스템은 시스템 관리자의 디스크/스토리지 관리에 들어가는 수고를 대폭 줄여주면서도 서비스 장애 및 데이터 장애 발생률을 현격하게 낮춰준다. 24시간으로 일주일 내내 수행되어야 하는 인터넷 서비스나 중요 서비스 업무에 사용될 수 있도록 구성되어 있어 미션 크리티컬한 상황에서 최적의 파일시스템이라고 할 수 있다. 또한 ZFS는 솔라리스의 실시간 장애 관리 오브젝트로 등록되어 있어서, 관리자가 언제든지 파일시스템의 장애를 실시간으로 관측 및 관리할 수 있다. 이 ZFS도 Dtrace와 함께 애플에 채택되어 Mac OSX 버전에 적용될 전망이다. 

썬은 운영체제를 만드는 입장에서 관리자의 작업 종류와 난이도, 소요 시간 등을 분석했다. 그 결과, 시스템 관리자는 스토리지 관리와 파일시스템 구축 및 변경, 그리고 복구에 매우 많은 시간을 보내고 있다는 흥미로운 결과를 얻었다. ZFS 이전의 모든 파일시스템들은 스토리지(디스크)에 문제나 변화가 발생하면 시스템과 서비스가 모두 중지되어야 했기 때문이다. 기존 데이터는 모두 백업 및 복구되어야 하고 새로운 스토리지로 새로운 구성을 마치고 나서야 새로운 파일시스템을 구축할 수 있었던 것이다. 물론 대체 시스템으로 서비스를 제공하고 있는 기업도 있겠지만, 이는 곧 적지 않은 추가 투자를 의미하고, 나아가 사람과 서비스가 기계에 종속되어 있음을 반증하는 결과이다.

따라서 솔라리스의 파일시스템 개발자는 관점을 바꿔 디스크나 스토리지 중심이 아니라 사람과 서비스를 중심으로 하는 파일시스템에 초점을 맞췄다. 시스템에 디스크와 관련되어 어떠한 일이 발생해도 서비스는 절대 멈추지 말아야 하며, 서비스 가동 중에 디스크나 스토리지는 얼마든지 추가 및 제거할 수 있어야 한다. 또한 얼마든지 이전 구성으로도 되돌아갈 수 있는(filesystem undo), 그런 환상적인 파일시스템을 고려하게 된 것이다. 사실 이런 기능에 가장 근접한 기술은 이미 존재했는데, 그것은 바로 솔라리스의 메모리 관리 기술이었다. 시스템 사용자들은 메모리를 장착하면서 메모리를 어떻게 나누고 구성할지에 대해 전혀 신경 쓰지 않는다. 운영체제는 전체의 메모리를 하나의 커다란 풀로 운영하면서 필요한 요청에 대응한다. ZFS는 바로 이점에 착안해 만들어졌다.

ZFS역시 모든 스토리지를 하나의 거대한 풀로 구성 운영한다. 구성된 풀에서 필요한 만큼의 파일시스템을 만들고 변경하며 운영할 수 있도록 하는 것이다. 따라서 새로운 디스크를 추가할 때 어떻게 파일시스템을 나눌지, 혹은 파티션을 어떻게 나눌지에 대해 전혀 고민할 필요가 없다. 풀이 허용하는 한 파일시스템의 크기는 마음대로 바꿀 수 있고, 필요에 따라서는 특정 상태 저장(snapshot)을 다수 해두었다가 원하는 상태로 복구(undo)할 수 있게 되었다. 따라서 이론적으로 볼 때 풀의 용량이 허용하는 한다면 백업도 필요 없게 되었다.

또한 ZFS는 데이터뿐만 아니라 메타데이터에 대한 Checksum을 유지함으로써 데이터 장애시의 복구율을 혁신적으로 높였다. 즉, 데이터의 장애로 인한 데이터 분실을 고민할 필요가 사라진 것이다. 더불어, ZFS는 미러 방식으로 구성된 환경에서 한 디스크에 장애가 발생하면 문제없는 디스크로부터 정상적인 데이터를 가져와 장애가 발생한 디스크를 치료하는 기능까지 제공한다. 이런 점에 비춰볼 때 ZFS는 특히 용량은 크지만 관리의 수고로움이 많았던 저가의 스토리지에 유용하게 적용될 수 있다.

솔라리스 트러스티드 익스텐션최신 오픈 솔라리스 b54 및 썬 솔라리스 업데이트3(11/06)에는 ‘솔라리스 Trusted Extension(이하, TE)’이라는 솔라리스의 확장된 보안 기능이 추가되었다. 솔라리스 TE는 선택적으로 구현되는 규칙 기반의 다층구조와 데이터에 권한 표식을 붙여 보안을 고차원적으로 확장시킨 기술이다. 미 국방성과의 협력으로 만들어진 Trusted Solaris 8의 기능을 오픈 솔라리스에 구현한 셈이다. 이 솔라리스 TE가 활성화된 환경은 보안등급 B2에 준하는 등급으로 LSPP, RBAC를 준수할 뿐 아니라 기존에 DAC, MAC으로 알려져 있는 보안 정책들을 지원한다.

솔라리스 TE에서 제공되는 MAC를 구성하면, 모든 문서나 장치들을 접근자의 보안 등급에 따라 그 내용이 다르게 보이게 하거나, 보안 등급에 준하는 내용만 가져가도록 제한할 수 있다.
오픈 솔라리스는 이러한 강력한 기능을 제공하고 있어 종전의 ‘보안툴’을 굳이 추가할 필요가 없는 한편, 확장된 감사 및 보고 기능을 통해 시스템 보안에 위협이 되는 요소들을 검사할 수 있다.

솔라리스의 성능과 안정성
운영체제를 논하면서 성능을 논하지 않을 수는 없다. 솔라리스는 오랜 기간 서버용 운영 체제로 많이 사용되면서 안정된 서버로서 작동할 수 있도록 많은 부분에서 가감이 이뤄져왔다. 일반적으로 데스크탑 상의 작동을 우선시 하는 운영체제들은 사용자 동작(사용자와의 인터페이스)에 더 높은 우선 순위를 할당하면서 백그라운드 모드로 동작하는 서비스에는 신경을 덜 쓰는 구조를 지닌다. 하지만 솔라리스는 상대적으로 백그라운드 서비스에 더 많은 기회를 주도록 구성되어 있다(물론 이를 변경할 수는 있다). 이러한 특징은 솔라리스가 네트워크와 스레드 기반의 서비스에 최적화되어 있음을 감안할 때 쉽게 짐작할 수 있는 부분이다. 

또한, 서버로서 전원 장애나 시스템 장애가 발생했을 때 데이터의 손실을 최소화하기 위해 성능 감소에도 불구하고 쓰지 않는 기능들도 있다. 대개 마이크로소프트의 윈도우 계열 서버나 리눅스와 같은 운영체제는 SCSI 디스크를 이용할 경우 디스크 내에 내장된 캐시를 자동으로 활성화함으로써 디스크 쓰기가 좋아지도록 구성한다. 그러나 솔라리스는 기본 설정상 읽기에 한해서만 캐시를 구성하고, 쓰기에 대해서는 캐시를 사용하지 않도록 한다. 이로써 전원 이상이나 시스템 장애가 발생했을 때 데이터의 손실을 최소화하는 것이다. 물론 디스크 쓰기 성능을 향상시키고 싶다면 쓰기 캐시를 활성화 하는 게 좋다.

이처럼 운영체제를 설계하는 몇 가지 관점의 차이 탓에 솔라리스는 멀티스레드와 네트워크 부분의 우수성에도 불구하고, 리눅스나 윈도우 계열에 비해 특정 부분에서 성능이 뒤처지는 것으로 평가되기도 한다. 하지만 솔라리스는 시스템을 멈추게 할 만큼 서비스 부하가 걸릴 때 그 진가를 발휘한다. 감당하기 어려울 만한 엄청난 부하가 주어졌을 때 타 운영체제는 묵묵부답이겠지만, 솔라리스는 다소 느리더라도 응답을 할 것이다. 때문에 관리자들이 부하에 대응할 수 있는 시간을 벌 수 있다. 이처럼 안정된 서비스가 우선이라면 솔라리스를 염두에 둘 필요가 있다.

오픈 소스 번들
오픈 솔라리스는 다양한 오픈소스 프로젝트를 번들로 공급하고 있다. 어쩌면 이런 유용한 오픈소스 프로젝트와 함께 하기 위해서라도 썬은 솔라리스를 오픈해야 했을지 모른다. 오픈 솔라리스를 설치하면 볼 수 있는 오픈소스 프로젝트들은 <표 1>과 같다.
<표 1>에 제시된 것 외에도 다양한 오픈소스 유틸리티나 툴들이 /usr/sfw/bin에 포함되어 있다. gcc 관련 개발 툴 이외에도 그래픽 툴이라던가, 혹은 wget과 같은 인터넷 유틸리티들이 포함되어 있으므로 실행 경로에 이를 넣어 두는 게 좋다.

오픈 솔라리스 로드맵
오픈소스 프로젝트에 대한 로드맵이 어떻다고 말하기는 현실적으로 그다지 쉽지 않다. 오픈소스 프로젝트가 정해진 시간 내에 지속적으로 진행된다고는 보기 어렵기 때문이다. 그래서일까? 현재 오픈 솔라리스 사이트에는 2007년 1/4분기에 해당되는 내용만이 로드맵에 제시되어 있다.


아직도 100명 이상이 근무하는 엔터프라이즈 기업에서는 백엔드 시스템의 상당 부분을 썬의 하드웨어와 솔라리스에 의존해 사용하는 경우가 흔하다. 이처럼 기간 시스템의 주요 운영체제로 사용되어왔던 솔라리스의 소스가 공개되었다는 것은 개발자 입장에서 무척 고무적인 일이 아닐 수 없다. 사실 이러한 변화를 크게 실감하지 못하는 이들도 있겠지만, 필자는 솔라리스의 공개가 1995년