정부는 2004년 이후 공개 소프트웨어 활성화 지원 정책을 강력히 추진하고 있다. 우리나라 뿐 아니라 여러 유럽 국가들도 30여개 이상의 공개 소프트웨어 기술 개발 프로젝트와 활용 촉진을 위한 프로젝트를 수행하고 있으며, 중국은 국가안보 확립과 기술 자립국 실현이라는 정책적 목표 아래 공개 소프트웨어 개발과 도입 확산에 적극적으로 정책을 마련하고 있다. 일본 역시 공개 소프트웨어를 소프트웨어 분야의 핵심기술로 인식하고 중앙정부와 지방자체단체, 특히 홋가이도, 나하시, 기후현, 스모토시가 가장 활발한 정책을 펼치고 있다. 이처럼 정부 차원의 공개 소프트웨어 활성화 지원 정책이 계속되고 있음에도 불구하고 국내 리눅스 시장은 여전히 정체되고 있다. 그 이유는 무엇일까.
리눅스로 대표되는 공개 소프트웨어 산업이 우리나라에서 활성화되지 않는 이유는 다음 세 가지이다. 첫째, 이미 개발되어 공개된 8만 여개의 공개 소프트웨어와 개발 중인 10여만 개의 공개 소프트웨어 가운데 어떤 것을 골라 써야 하는지, 그 고른 것이 과연 제대로 쓸 수 있는지를 알 수 없기 때문이다. 또 다양한 공개 소프트웨어의 조합으로 이루어진 최종 솔루션 사이에 호환성이 문제가 된다. 둘째, 공개 소프트웨어 사용자에 대한 효과적인 기술지원이 없기 때문이다. 국내 리눅스 업체의 규모가 작아서 전국적인 지원이 불가능하고 무엇보다도 주인 없는 공개 소프트웨어에 대한 사용자들의 불안감이 여전히 존재하여 사용하기를 주저하고 있다. 마지막으로 공개 소프트웨어를 사용하더라도 외국 리눅스 업체의 제품을 사용하는 것이다.
이상의 문제점인 호환성 결여, 신뢰성·안정성 미흡을 해결하기 위해 국내 관련 기업과 소프트웨어진흥원 그리고 한국전자통신연구원(ETRI)가 협력체를 이뤘다. 먼저 국내 표준 규격을 제정하고 그 규격에 맞고 외국 제품에 비해 성능과 기능이 떨어지지 않는 표준 공개 소프트웨어 컴퓨팅 플랫폼(Booyo, 부요로 명명함)을 개발하는 것이 목표이다. 그리고 부요를 기반으로 만든 국내 제품을 공인인증기관이 철저한 검사를 통해 인증하여 국산 제품 간의 호환성을 유지하며, 공공기관 사용자를 위해 전국적인 기술지원 네트워크를 구성하여 부요에서 발생하는 고객지원 업무체제를 구축하는 것이다.
부요 규격 개발을 위한 추진체계로는 관련 기업 협력체, 공개 소프트웨어 기반의 솔루션 발굴을 위한 국내 대학, 부요 표준화를 위한 TTA 및 OSDL(Open Source Development Lab.), 한중일 OSS (CJK Open Source SW) 활성화 포럼 단체 등으로 구성된다.
이러한 부요 규격인 자국의 표준 운영체제 플랫폼 기술을 확보함으로써 국내 ISV 솔루션 개발의 용이성과 특정 SW 사용에 의한 독과점 방지를 통한 공정경쟁 환경 조성 및 소비자 선택권 확대 등의 효과를 기대하며, 최근 논의되고 있는 한중일 3국의 기술협력으로 제3의 글로벌 제품 개발에 있어 우리나라도 주도적인 역할을 수행할 수 있다는 점이다.
날아오르는 펭귄을 상징
공개 소프트웨어 활성화 장애 요인을 제거하기 위해 국제산업 표준을 근간으로 하는 국내 표준 컴퓨팅 규격인 부요의 등장은 이처럼 남다른 의미를 가졌다. 부요라는 단어 역시 그러한 의미를 살리기 위해 결정된 이름이다. 우리나라 민요 가운데 까투리 사냥에서 중간에 까투리를 풀 섶에서 나와 날아오르도록 놀라게 하는 소리가 있다. 남쪽 지방에서는 ‘훠이여’ 북쪽 지방에서는 ‘우여’ 중부 지방에서는 ‘부요’라고 외친다. 즉 부요라는 이름은 리눅스의 희망과 도전 정신을 나타내는 펭귄을 날아오르게 하자는 의성어이다. 부요를 통해 펭귄을 날아오르게 해 리눅스 산업도 크게 일어날 것이라는 희망을 담고 있다. 그래서 부요의 로고도 펭귄이 날아오르는 모습이다. 또한 부요란 말은 한자로 풍요롭다는 의미인 ‘富饒’와 발음이 같아 소프트웨어 산업을 부유하고 넉넉하게 하겠다는 의도도 담겨져 있다.
부요 규격 발전 방향
부요는 데스크탑 규격과 서버 규격으로 구분된다. <그림 1>은 부요의 규격 로드맵이며 이는 <그림 2>의 리눅스 Hype Cycle를 기반으로 계획된 것이다. 리눅스 기술이 지난 몇 년 동안은 1~4 프로세서 환경인 엔트리급 서버 환경에서 발전해 왔지만, 향후에는 성능·기능 개선, 보안 기능 강화로 64비트 프로세서, 8프로세서 이상의 엔터프라이즈급 서버로 중요업무 솔루션을 수행하는 환경에서 발전하게 될 것이다.
기능·성능 향상을 위해서는 OSDL의 CGL(Carrier Grade Linux), DCL(Data Center Linux) 표준 규격을 따라야 한다. 데스크탑의 경우는 제한적인 업무 사용자를 우선적으로 목표하고 점차적으로 윈도우 환경과 같이 일반 사용자를 지원하는 방향으로 설정한다.
부요 개발에 관련되는 국제표준, 워킹그룹과 프로젝트들
부요 규격 개발에 관련되는 국제 표준은 다음과 같다.
◆ LSB(Linux Standard Base) : 프리 스탠다드 그룹 주도하의 리눅스 운영체제와 유틸리티 기능에 대한 표준. 현재 2.0 버전 진행
◆ FHS(Filesystem Hierarchy Standard): 디렉토리 구조나 파일의 위치에 대한 표준으로 애플리케이션 호환성을 보장하기 위함. 현재 2.3 버전 진행
◆ Open I18N(Open Internationalization) : 제품이나 서비스를 특정 지역의 언어나 문화에 맞추는, 즉 현지화 과정을 쉽게 할 수 있도록 규격을 제정
◆ CGL 규격 : OSDL 주도하의 다수의 컴퓨터 및 통신업체가 리눅스를 엔트리/엔터프라이즈급 시스템 등에 활용할 수 있도록 사실상 표준(de-facts standard)으로 리눅스 기능 규격. 버전 3.0까지 제정
◆ DCL 규격 : 리눅스를 중대형 시스템에 적용할 수 있도록 정의한 리눅스 규격으로 2004년 초부터 DCL 1.0 제정을 위해 회원사 모집 및 진행
◆ DTL(DeskTop Linux) 규격 : 데스크탑 기능 규격을 제정하기 위해 2004년 하반기부터 활동 시작
◆ DMTF(Distributed Management Task Force) CIM(Common Information Model)/WBEM 표준 : 시스템 관리의 정보 표준모델 및 기능, 구조에 표준 제정, 2001년부터 활동 본격화
◆ DMTF-UC(Utility Computing) 표준 : DMTF CIM/WBEM 표준 기반으로 유틸리티 컴퓨팅 환경을 구현하기 위한 표준 제정
◆ SA(Service Availability) AIS(Application Interface Spec.) : 차세대 HA 클러스터 기능 규격 제정
◆ SA(Service Availability) HPI(Hardware Platform Interface) : 서버 하드웨어 진단, 관리 규격 제정
또한 부요 규격 개발에 있어 페도라(Fedora) 프로젝트, source forge.net 사이트의 공개 프로젝트들, OSDL의 SIG(Special Interest Group) 프로젝트, KLDP 용어 한글화 프로젝트를 참조하고 있으며, OSDL CGL, DCL, DTL 워킹그룹과 CJK OSS 기술개발 워킹그룹과 표준화 워킹그룹 활동을 병행하고 있다.
부요 데스크탑 개발은 이렇게
부요 데스크탑은 <그림 3>과 같이 오피스, 인터넷 뱅킹과 같은 기업업무용 응용, 멀티미디어 장치 지원, 게임, 개발환경과 같이 일반 사용자를 위한 윈도우 환경을 제공하며, 순수 커널 버전 2.6.10과 시스템 서비스를 구성하는 패키지들로 구성된다. 특히 부요 데스크탑 1.0에서는 기업업무 환경에 초점을 두었는데, 특히 다음과 같은 주된 사항을 고려했다.
◆ LSB(Linux Standard Base) 등 산업 표준 규격을 기반으로 하는 개방형 구조 제공
◆ 기존 대중적인 데스크탑 운영체제 대비 리눅스의 부족 기능 해결
◆ 국내 사용자 환경을 위해 표준 한글 사용 환경과 한글처리 기능을 제공
◆ 설치가 용이하고, 원격 업데이트 지원체제 제공
◆ 데스크탑 환경 개선과 주변 장치 지원
◆ GNOME 기반의 사용자 친화적인 데스크탑 환경 제공
◆ 서버 중심의 리눅스를 데스크탑용으로 가볍고 빠른 데스크탑 환경 제공
◆ 오피스, 인터넷 뱅킹과 같은 기업업무용 환경 제공
사용자에게 친화적인 환경 제공
기존의 대중적인 데스크탑 OS 사용자에게 부요 데스크탑 사용시 사용자 친화적인 환경을 제공하기 위해 아이콘, 색감, 메뉴 구성 트리 등 사용 습관 호환성을 제공하고자 한다. 부요 데스크탑 환경은 GNOME 2.10을 기반으로 한다. 복잡하고 정리되지 않은 메뉴 구조를 개선하기 위해 데스크탑 리눅스 표준이라고 할 수 있는 freedesk top. org의 표준 중에 menu-0.9 스펙을 기반으로 구현했다. 메뉴는 하위 3단계로 구성했으며, 중복되는 메뉴를 줄이고 적절하지 않은 위치의 메뉴를 이동시켜 사용자가 원하는 프로그램을 쉽게 찾을 수 있도록 했다. 프로그램 아이콘 이름도 도구 이름과 설명 문구, 예를 들어 GIMP를 GIMP 이미지 편집기로 명명하여 어떤 종류의 응용 프로그램인지를 쉽게 알 수 있도록 했다.
테마와 바탕화면 디자인에서도 사용자에게 친근함을 제공할 수 있는 다양한 부요 전용 테마 패키지 등 전체적으로 통일성을 주었고, 아이콘 역시 친근하고 GNOME과 KDE에서 공동으로 사용할 수 있는 포맷의 아이콘 테마 집합을 제공한다. 또한 Truetype 폰트 환경에서 한글의 경우 작은 크기 문자의 경우 흐리게 출력되는 문제를 해결하기 위해 비트맵 폰트를 내장했다. <화면 1>은 부요 데스크탑 환경을 나타낸다.
부요 데스크탑 기본 문자셋트는 ko_KR이며, 인코딩 환경은 UTF-8이다. UTF-8로의 전환은 세계적인 추세이며 다국어 환경에 최상의 인코딩 환경이기 때문이다. 이 때문에 부요 데스크탑은 대중적인 OS 환경의 CP949 및 이와 호환되는 유닉스, 리눅스 환경에서 EUC-KR 인코딩과 호환되지 않는 문제가 있다.
이러한 문제점을 해결하기 위해 인코딩 변환 작업이 파일 전송 및 파일 편집시 필요하다. FTP로 데이터 이동, 파일 롤러 압축 프로그램을 이용한 경우, Samba(SMB)를 통해 대중적인 데스크탑 OS 네트워크 환경을 통한 데이터 이동 및 웹 브라우저를 통한 데이터 이동 시 파일 호환성 문제를 해결했다. 또한 GNOME 데스크탑 환경에서는 별도의 배터리 관리 프로그램을 통해 전원을 관리한다. 화면보호기 경우는 화면보호기 메뉴를 선택하게 되면 현재 로그인한 사용자의 정보를 파악 후 로그인한 사용자가 루트(root)일 경우 에러 메시지를 보여주고, 루트가 아닌 경우에는 기존의 화면보호기를 실행시켜 줌으로써, 루트 사용자의 보안 경각심을 강화시켰다.
리눅스 데스크탑에서 사용자 인터페이스 측면 중 중요한 부분이 한글 환경이다. 부요 데스크탑에서는 한글 표준화를 제안하고 데스크탑 환경 내 응용 프로그램 이름, 메뉴, 메시지 등에 사용하는 용어들을 통일했다. 또한 키보드 한/영 키를 이용하여 한글과 영어를 전환할 수 있도록 지원하며, 외부 장치를 마운트할 경우 한글 문제를 해결했다. 웹 브라우저에 대한 국내 사용자의 편의를 위해 파이어폭스 한글화도 진행됐다.
더욱 가볍고 빠르게
리눅스는 서버 중심으로 개발됐으며 많은 데몬들을 기본적으로 제공해줘야만 한다. 하지만 데스크탑은 서버와는 달리 낮은 사양, 저장 장치, 메모리 등 기타 하드웨어 측면에서 효율적으로 운영되어야 하며, 멀티미디어, 오피스 등 원격지 중심이 아닌 개인 사용자의 중심에서 서비스들을 제공해야 한다. 또한 서버는 항상 컴퓨터의 전원이 공급되는 반면, 데스크탑은 사용할 때만 시스템을 가동하기 때문에 개인이 사용하고자 하는 순간에 쉽고 빠르게 부팅되길 희망한다. 따라서 리눅스 데스크탑의 최적화 기술로 개인 사용자가 좀 더 쉽고 빠르게 사용할 수 있게 하여 적극적인 리눅스 데스크탑의 이용을 이끌어 내도록 했다. 부요 데스크탑의 최적화 기술은 부트 스플래시(splash) 패치를 적용하여 데스크탑 화면 시작과 종료 시 부팅·종료 화면으로 복잡한 정보 출력을 피하고 그래픽 환경의 부팅을 지원하여 좀 더 사용자 친화적인 화면을 제공했다.
복잡한 정보 출력 제거뿐만 아니라 기존 부팅시 순차적으로 서비스 데몬이 실행됐지만, 병렬 부팅을 지원하도록 해 서비스 데몬을 동시에 실행시켜 부팅 시간을 최소화했다. 그 결과 부요 데스크탑 1.0 개발에 참조됐던 페도라 코어 3 기준 시스템 관련 패키지, 네트워크 관련 패키지 등의 기본적으로 제공되는 서비스 수를 55% 이상 줄였으며, 활성 패키지 수도 50% 정도 줄였다. 즉, 기존의 리눅스 데스크탑 솔루션은 최대한 많은 서비스를 제공하는 반면, 부요 데스크탑에서는 필요한 서비스만을 제공하므로써 효율성을 극대화하고 서비스를 최적화했다.
< 표 1>과 <그림 4>는 부요 데스크탑과 타 솔루션간의 패키지 수, 용량, 데몬 수 비교와 설치 및 부팅 시간 비교를 나타낸다. 부요 데스크탑은 부팅 시간을 1분 이내로 지원한다. 부트 최적화뿐만 아니라 커널 컴파일 옵션과 형상 설정을 통해 커널의 서비스 정책 변경과 서버용 기능들을 적용하지 않도록 했다.
부요로 인터넷 뱅킹도 가능
부요 데스크탑에서는 인터넷 뱅킹 업무를 수행할 수 있도록 브라우저 플러그인 모듈을 지원한다. 국내 인터넷 뱅킹 서비스를 위한 웹 컨텐츠는 마이크로소프트(이하 MS)의 인터넷 익스플로러(이하 IE) 위주로 작성되어 리눅스에서는 한글과 페이지 깨짐이 발생한다.
즉 IE에서는 액티브X 기술 기반의 다양한 모듈이 탑재되어 실행 가능하다. 이 액티브X를 사용하여 로그인, 카드 결제, 인터넷 뱅킹 등 많은 기능을 하는 플러그인을 설치하여 사용하고 있다. 이에 대해 부요 데스크탑의 모질라는 XPCOM(Cross-Platform Component Object Model)으로 확장된 기능을 구현해 웹 브라우저에 다양한 플러그인 모듈을 사용할 수 있다.
자연스러운 Cut/Paste 환경 지원
윈도우 환경에서는 Cut/Paste가 일관성있게 동작하고 데이터 교환이 제대로 이루어지지만, X윈도우 환경 하에서는 표준이 없어서 Cut/Paste가 제대로 이루어지지 않는다. 부요 데스크탑에서는 X윈도우 환경 하에서 응용 프로그램끼리 Cut/Paste가 자연스럽게 이루어지면서 데이터 교환을 원활히 할 수 있도록 했다. 이 사업에서 개발되고 있는 클립보드 프로그램 이름은 Bclipboard라 이름붙였다. Bclipboard 구조는 <그림 5>와 같으며, 클립보드 동작에 필요한 주요 요소들은 다음과 같다.
◆ 클립보드 서버 : MS에서는 데이터의 보관을 OS 레벨에서 하지만, X윈도우에서는 응용 프로그램끼리 데이터를 주고받아야 한다. Cut한 응용 프로그램이 종료하면 그 데이터도 따라서 사라지게 된다. 이를 방지하기 위해 응용 프로그램의 종료 뒤에도 데이터를 보관해 주는 서버가 필요하다.
◆ 이력 관리기 : 클립보드 데이터의 히스토리를 보관하고 이를 관리한다.
◆ 클립보드 제어 : X윈도우 환경에서의 클립보드에는 owner와 requestor가 존재하기 때문에 owner와 requestor간 데이터를 제어한다.
◆ 데이터 교환 포맷 : 부요 데스크탑에서는 응용 간 데이터 변환을 위해 XML를 사용한다.
기존의 공개 소프트웨어인 Gcm, Klipper, Gclipboard와 BClip board를 <표 2>와 같이 비교해 보았다./p>
USB, 무선 인터넷 자유자재로 사용 가능
부요 데스크탑에서 하드웨어 장치 편이를 개선하기 위해 우선적으로 USB 장치와 노트북 사용자를 위한 무선랜 장치를 고려했다. USB 장치 경우, 대중적인 데스크탑 OS 계열과 유사하게 장치에 대한 관리와 USB 응용 매니저를 자동적으로 수행되도록 했으며, USB 드라이버 업데이트 지원과 USB 장치에 대한 한글 파일명, 고용량 메모리 지원, 쓰기 금지 장치 및 암호가 걸린 메모리 장치를 지원토록 했다. 무선 인터넷 경우도 액세스 포인트 검색, 사용자가 편리하고 쉽게 무선 인터넷을 사용할 수 있도록 자주 사용되는 정보들을 저장하는 기능을 지원하는 무선 인터넷 매니저를 제공한다.
다양한 기능을 통합할 수 있는 개발도구 환경
(그림 없음 http://www.imaso.co.kr/data/article/0509-170-02.jpg – 오른쪽)
소프트웨어 통합개발환경(IDE, Integrated Development Environ ment)은 소프트웨어 편집기, 컴파일러, 코드 분석 도구, 테스팅 도구, 디버거 등 서로 다른 기능을 가지는 다양한 도구를 포함해야 한다. 따라서 부요 통합개발환경에서는 각종 개발도구를 기능적으로 포괄하는 IDE 기본 환경에 각종 개발도구를 포함할 수 있는 플러그인 기술, 디버깅을 위한 이벤트 모니터링 기술, 각종 템플릿 지원과 광범위한 개발언어 지원, 한글화 등 사용자 편의성을 향상시키고자 한다.
개발도구는 오픈소스 기반 통합개발도구의 대명사인 이클립스 IDE를 기반으로 코드 기반 검증도구를 플러그인하는 형식을 취한다. 이클립스 IDE는 기본 데스크탑 응용 계층에서 제공하는 JRE 또는 JDK를 이용하여 사용자에게 통합개발도구의 기능을 제공한다. 이클립스 IDE는 자바 기술과 플러그인 기술을 이용하여 기본적으로 이클립스에서 제공하는 자바 프로그램 개발 외에 사용자가 원하는 기능들을 추가할 수 있다. 이와 같은 플러그인 기술을 이용하여 프로그램 개발 과정 중에 발생하는 사용자의 다양한 요구 사항들을 충족할 수 있다. 예를 들면 자바 프로그램 개발 외에 웹, C/C++, UML, GUI 프로그램 개발과 같은 사용자의 요구 사항들을 모두 수용할 수 있다.
이클립스 IDE를 기반으로 한 통합개발도구는 신뢰성과 객관성을 보장하는 프로그램 개발을 위해 소스코드 기반 검증도구를 플러그인한다. 소스코드 기반 검증도구와 이클립스 IDE간의 데이터 통합을 위해 공통으로 사용되는 데이터의 스키마를 정의하고 공유함으로써 이루어진다. 따라서 부요 개발도구에서는 <그림 6>과 같이 XML 저장소를 설계하고 XML 저장소를 기반으로 소스코드 기반 검증 도구 외에 프로그램에 대한 복잡도 분석 도구를 통합한다.
부요 서버 개발은 이렇게
이제부터는 부요 서버에 대해 알아보자. 앞에서 기술한 부요 데스크탑의 사용 환경 개선, 리눅스 데스크탑의 부족한 기능 개선 등 대부분의 특징은 부요 서버에서도 적용되어, 부요에서 데스크탑이나 서버 사용 환경은 동일하다. 그러나 커널에서는 차이점이 있다. 데스크탑의 경우는 빠르고 가벼운 커널로 구성하는 반면, 서버에서는 국제 산업 표준을 만족하고 고성능, 고가용성, 고신뢰성을 보장하면서 엔트리급, 엔터프라이즈급 서버 환경을 안정적으로 지원해야 한다. 따라서 부요 서버는 다음과 같은 개발 목표를 가졌다.
◆ LSB2.0.3, FHS2.3 등 국제 산업 표준 만족
◆ 리눅스 기능 강화를 위한 CGL, DCL 규격 만족
◆ 풍부한 서버 개발 도구 제공
◆ 고부하 지속 환경 및 서버 성능 벤치마킹에서 국외 제품과 동일 기능, 성능 제공
◆ 공개 소프트웨어 기반의 보안, 시스템관리, 서버 가상화, 웹, DBMS 등 솔루션 제공
현재 리눅스 커널이 2.6까지 발전해왔지만, 국외 기술 분석지에 따르면 2008~2009년 정도에 유닉스 대비 기능적, 성능적으로 대등한 운영체제가 될 것이라 분석하고 있다. 즉 엔터프라이즈 시장에 리눅스 기술이 적용되기 위해서는 여전히 기능 개선, 구현이 필요하다는 의미이다. 2000년에 설립되어 현재 다수의 대형 소프트웨어 업체가 참여하고 있는 비영리단체 OSDL의 CGL, DCL 규격 명세서는 리눅스 운영체제가 미래에 케리어급 또는 엔터프라이즈급 운영체제로 발전하기 위해 필요한 기능을 요구 사항 형식으로 기술하고 있다. 특히 CGL 경우에는 예전의 독점적인 통신 시스템에서 개방형 구조의 시스템으로 하드웨어가 전환되고 있는 시점에 소프트웨어도 개방형 구조인 리눅스 기술을 적용하기 위해 추가적으로 요구되는 기술을 정의하는 규격 문서이다. 그러나 CGL 규격 명세서는 통신 시스템에 국한된 것이 아니라 서버 시스템이 엔터프라이즈급으로 변모하기 위해서도 필수적인 기능을 정의하고 있다. 따라서 부요 서버에서는 CGL 규격 반영 시 모든 규격을 개발하는 것보다 서버 시스템에 필수적이며 다른 기능과 상호 도움이 되는 것을 선택적으로 개발한다.
이 CGL은 2002년 8월에 CGL 규격 1.0 발표 이후, 현재 CGL 규격 3.1 작업을 진행하고 있다. DCL은 엔터프라이즈급 운영체제로 발전하기 위한 규격을 정의하며, 현재 규격 DCL 1.0까지 작업되어 있다. DCL에서는 CGL에서 정의된 규격 이외에 시스템 확장성과 성능을 우선적으로 하고 있다. 결론적으로 부요 서버는 리눅스 커널 2.6을 기반으로 기능과 성능 향상을 추구하기 위해 CGL, DCL 규격으로 개발되고 있다. <그림 7>은 부요 서버 소프트웨어 구조이다. 리눅스 커널뿐만 아니라 공개 소프트웨어의 웹, 데이터베이스 솔루션 등과 최근에 이슈가 되고 있는 표준 기반 시스템 관리 기술과 서버 가상화 기술도 제공한다. 이들 기술은 이 글의 뒷 부분에서 다시 다룰 예정이다.
부요 서버는 커널 2.6.10을 기반으로 페도라 프로젝트의 서버 서비스 데몬 등의 패키지들로 구성된다. 커널은 네 가지의 작업 방향을 통해 개발된다. 첫 번째 방향은 kernel.org의 공개 커널을 통한 기능의 개선이고, 두 번째는 주요 커널 개발자들의 공식 커널 패치를 이용한 기능 개선이다. 세 번째는 앞의 두 가지 방향으로 개발된 커널에 대한 기능, 성능 및 고부하 시험을 통해 도출된 개선점에 대한 수정이다. 마지막 개발 방향으로 CGL, DCL 규격 명세서를 기반으로 한 자체 분석을 통해 얻어진 부족한 부분에 대한 개발 작업이며, 이 작업을 통해 타제품에서 제공하지 않은 기능을 먼저 제공할 수 있다.
이제부터 부요 서버 커널의 기능을 자세히 알아보자. 일반적인 프로세스 관리, 메모리 관리 및 입출력 관리 측면보다 CGL 2.0 규격 명세서를 기반으로 커널 2.6에 추가·강조된 기능에 대해 표준, 성능과 확장성, 가용성, 편리성, 보안, 관리성 측면으로 구분한다.
국제 표준 기능은 반드시 만족
시스템 개발자나 사용자 모두에게 혼란을 방지하려면 API, 파일 시스템 디렉토리 구조, 소프트웨어 설치 방법과 배포 방법 등을 정의해야 한다. 이를 위해 리눅스 개발 업체들의 주도하에 LSB가 제안됐고, 모든 리눅스 배포판들은 이 표준 인터페이스를 따르고 있다. POSIX에서 정의한 다음과 같은 필수적인 기능도 만족한다.
◆ 다중 쓰레드 수행 중 특별한 지점에서 쓰레드들 사이의 동기화를 위한 Barrier 기능
◆ 다중 쓰레드가 공유 데이터에 대한 접근을 허용하는데 사용되는 스핀락 기능
◆ 프로세스/쓰레드의 스케쥴링 변수 설정 및 정책 방식 설정 기능
◆ 특별한 프로세스/쓰레드 수행 시간을 측정하기 위한 타이머 기능
◆ 특정 클럭에 의해 측정된 시간이 지정된 시점에 도달하거나 지정한 값을 지났을 때 쓰레드에게 알릴 수 있는 기능
◆ 어떤 클럭을 선택할 것인가를 결정하는 기능
◆ 프로세스들이 동일한 주소 공간을 공유하지 않고 통신을 하거나 동작을 동기화할 수 있도록 허용하는 기능
◆ 기존 시그널 함수와 호환성을 유지하면서 응용 프로그램에게 비동기적 시그널 통지가 가능하도록 해주는 향상된 시그널 기능
◆ 공유 자원에 대한 배타적 사용을 지원하는 기능
◆ 프로세스나 쓰레드가 대기 상태로 있는 시간을 설정하는 기능
◆ IPv6 기능
◆ 메모리 자원 로깅 기능
또한 부요 서버의 쓰레드는 쓰레드 생성 및 소멸에서 성능 측면에서 우수한 NPTL(Native POSIX Thread Library)을 제공한다. 멀티미디어 응용 서비스 등의 전송을 지원하기 위해 SCTP(Stream Control Transport Protocol)를 제공하는데, 데이터의 순차적인 전달을 비롯해 망 장애에 대비한 복구 기능을 수행할 수 있다.
시스템 성능 향상
커널 2.6부터는 프로세스의 문맥교환을 위한 부하를 감소시킴으로써 스케쥴링 확장성을 제공하는 저부하 스케쥴러(O(1) 스케쥴러)를 제공하여, 다음에 실행할 프로세스를 선택하는데 소요되는 시간이 프로세스의 수에 관계없이 일정하게 처리된다. 이와 함께 선점형 커널을 통해 최적의 스케쥴링을 제공할 수 있다. 하이퍼쓰레딩(Hyper-Threading) 혹은 SMT(Symmetric Multi-Threading)란 하나의 프로세서가 가상적으로 두 개의 프로세서처럼 동작하도록 하는 하드웨어 기술이다. 이 기술은 프로세서가 다수의 쓰레드를 동시에 각각의 프로세서에서 병렬적으로 실행되도록 함으로써 시스템의 성능을 상당히 향상시킬 수 있다. 하이퍼쓰레딩이 활성화되면 운영체제나 사용자의 관점에서 하나의 물리적 프로세서가 두 개의 프로세서로 보인다.
그러나 기존의 리눅스 커널은 하이퍼쓰레딩이 활성화된 프로세서에서 논리적인 두 개의 프로세서를 두 개의 물리적인 프로세서와 같이 취급했다. 즉, 스케쥴러는 논리적인 프로세서와 물리적인 프로세서를 구분할 수 없었다. 이것은 하이퍼쓰레딩 시스템에서 멀티프로세싱의 성능을 최대화하지 못하게 한다. 따라서 부요 서버에서는 하나의 물리적인 프로세서가 두 개의 작업을 처리하고 다른 물리적인 프로세서가 유휴 상태인 물리적인 프로세스의 불균형적인 문제와 하이퍼쓰레딩 환경에서 affinity를 고려하는 HT-aware 스케쥴러를 제공한다. 이 스케쥴러는 계산 위주의 작업, 입출력 위주의 작업 및 혼합형 작업의 벤치마킹 시험을 통해 안정적으로 시스템 성능을 유지시키는 것으로 판별되었다.
또한 프로세스가 실행될 프로세서를 지정하여 특정한 프로세서에서만 실행되도록 하는 process affinity 기능을 제공하는데, 응용 수준에서 사용할 수 있도록 sched_setaffinity, sched_getaffinity 시스템 호출도 지원한다. 메모리 관리 부분에서는 물리 주소를 가상 주소로 변환할 때 모든 페이지 테이블을 검색해야 하는 문제를 개선했으며, 최대 64GB 물리적 메모리와 가변 크기 페이지를 지원한다. 입출력 관리의 경우는 먼저 효율적인 입출력 성능 향상을 위해 기존의 인터럽트 방식에 의한 프로세서 간섭을 최소화하기 위해 인터럽트 방식과 폴링(polling) 방식을 혼합한 NAPI(New API) 인터페이스를 드라이버 개발자에게 제공한다. 이더넷 링크 통합은 분리된 물리적인 네트워크 카드를 논리적으로 통합하여 하나의 카드처럼 사용하도록 하는 기술로 높은 네트워크 대역폭 제공과 안정성을 강화할 수 있다. 통합된 링크들은 하나의 IP 주소와 MAC 주소를 사용한다. 또한 네트워크 성능 향상을 위해 더 큰 IP 프레임, 즉 최대 9,000바이트 크기의 MTU, 사용을 지원한다. 디스크 및 파일에 대한 비동기 입출력 지원과 최대 4096개의 디스크 연결 지원, 소프트웨어 스트라이핑(striping) 기능도 제공한다.
시스템 가용성 향상
부요 서버의 가용성 기능은 대부분 입출력 관리 기능에 해당된다. 앞에서 기술한 이더넷 링크 통합에 따른 네트워크 처리 대역폭 향상뿐만 아니라 일부 네트워크 카드 고장 시에 대기 중인 카드를 대체하여 장애를 극복한다. 이를 위해 동일 IP를 다수 네트워크 인터페이스에 할당하고, 드라이버는 지속적인 네트워크 상태를 감시하고 고장 시 자동으로 대체 인터페이스로 전환할 수 있는 기능을 제공한다. 소프트웨어 방식으로 미러링을 제공하는데, 일반적으로 특정한 컨트롤 카드를 이용한 하드웨어 방식의 미러링을 많이 사용하고 있다. 하지만 비용면에서 휠씬 유리하고 효율성이 좋은 소프트웨어 방식을 제공하므로써 일부 디스크 고장 시에도 모든 데이터를 복원할 수 있다.
CGL 규격 명세서 서버 사용 중에 저장 장치 공간의 부족 등과 같은 이유로 저장 내용의 변동없이 저장 공간의 크기를 변경할 수 있도록 권장하고 있다. 일반적으로 파티션의 크기를 정한 후에 파티션을 확장하려면 그 파티션의 내용을 삭제하고 새로운 파티션을 구성해야 하는데, 이 때 시스템 운영을 정지시켜야 한다. 따라서 이러한 요구사항을 반영하기 위해 논리 볼륨 관리 기능을 제공한다. 볼륨 관리자는 다수의 독립적인 저장 장치를 볼륨이라는 논리적인 하나의 대용량 저장 장치로 관리하여, 볼륨의 생성 등이 시스템을 재기동하지 않고 가능하도록 한다. 또한 시스템이 비정상적으로 재가동될 때 파일 시스템 무결성 검사 과정을 거치지 않고 빠르게 활성화될 수 있는 견고한 파일 시스템들을 지원한다. 입출력 장치에 핫스왑(Hot swap) 기능을 지원한다. CGL 규격 명세서에서는 주로 디바이스 장치에 대한 핫플러그(hot plug) 기능 지원을 요구하고 있으며, DCL의 경우는 메모리, 프로세서 등의 서버 핵심 하드웨어 요소에 대한 핫플러그 지원을 요구하고 있다. 현재 부요 서버에서는 부요 데스크탑과 마찬가지로 USB 장치에 대해서는 시스템 동작 중에 장치 추가·제거, 그에 따른 장치 드라이버 적재와 응용 동작이 자동으로 진행되고, 사용자에게 상태 통보 등의 전달 방식을 개발 완료했다.
소프트웨어 미러링을 통한 저장 장치의 데이터 가용성을 비롯해 저장 장치의 케이블, 버스 등의 하드웨어적인 고장에 대한 대비를 위해 multipath I/O를 지원한다. 즉 이 기능으로 저장 장치 접근 가용성을 높일 수 있는데, <그림 8>과 같이 사용자 수준의 도구와 커널 수준의 DM(Device Mapper) 기능을 구현해야 한다. 현재 이 기능을 사용하는 데는 별 어려움은 없지만, 입출력 path가 다운될 때 상태를 감지하고 대처하는데 다소 많은 시간이 소요되는 등의 개선 사항들이 존재하기 때문에 점차적으로 부요에서 반영할 예정이다.
부요 서버에서는 파일 시스템의 이상 또는 저장 장치의 문제 발생 시 파일시스템 상에 오픈 파일 또는 수행 태스크가 존재하는 상황에서도 그 파일시스템을 강제로 해제할 수 있는 기능을 제공한다. 커널 2.6에서 이 기능을 완전하게 제공하는 배포판이 없기 때문에 여기서 좀 더 자세히 기술하고자 한다. 수많은 파일 작업을 수행하고 있는 도중에 블럭 디바이스나 시스템을 업그레이드를 위해 잠시 파일시스템을 해제해야 한다면, 일반적으로 사용하는 umount는 정상 처리되지 못할 것이며, 사용자는 시스템 재가동 이외에는 다른 대안을 찾을 수 없을 것이다. 이 문제를 해결하기 위해 모든 파일시스템에 적용할 수 있는 force unmount 기능을 개발한다. 다음 4가지 경우 파일시스템 해제 시 기존의 umount는 해당 파일시스템이 busy 상태로 실패하게 된다.
◆ 오픈된 파일이 존재하는 경우
◆ 수행중인 태스크의 바이너리 파일이 존재하는 경우
◆ 태스크의 CWD(Current Working Directory)가 파일시스템 하의 위치로 설정되어 있는 경우
◆ Nested Mounting Filesystem이 존재하는 경우
각 경우마다 처리되어야 할 것은 다르지만 전체적인 흐름은 <그림 9>와 같으며 부요에서는 시스템 관리자를 위해 fumount 명령어를 제공한다.
향상된 편리성 제공
편리성 기능은 시스템을 관리하는 편리한 도구, 기능 및 환경과 개발자를 위한 디버깅 환경 등을 포함한다. 일관성 있는 장치 명명 기능을 제공하여 장치가 제거된 후 다른 버스, 슬롯 또는 어댑터에 재설치되더라도 장치명이 동일하도록 유지시켜 주는 persistent device naming 기능을 제공한다. 또한 심각한 손상을 초래한 시스템 이미지로부터 이전의 안정된 이미지로 복구할 수 있는 시스템 이미지 복구 기능을 제공하는데, 주기적으로 또는 운용상의 변경이 생기기 전 시점으로 안정적인 이미지를 관리하여 대처한다. <화면 2>는 시스템 이미지 복구 기능 GUI를 나타낸다.
CGL 규격 명세서에서는 시스템을 운영할 때 발생할 수 있는 원인 파악 분석과 커널 디버깅 기능을 요구하고 있다. 따라서 부요 서버에서는 GUI 기반으로 사용하기 편리하고 강력한 모니터링 및 추적(tracing) 기능을 가지고 있는 도구들을 점차적으로 개발, 이식하고자 한다. 현재까지 지원하고 있는 도구로는 시스템 덤프(dump) 발생 시 일반적인 디버거 사용 방법과 유사하게 명령을 입력하면서 커널 덤프 이미지에 대한 분석을 통해 시스템 다운 원인을 파악하는데 도움을 주는 LKCD(Linux Kernel Crash Dump) 기능을 제공한다. 또한 LKCD는 메모리, 디스크, 네트워크를 통해서 반드시 필요한 부분의 덤프 이미지만을 저장할 수 있으며 다음 시스템 부팅 때 그 내용을 보존한다. 리눅스 커널 디버깅 및 정보를 출력하는데 일반적으로 printk를 많이 사용하는데, printk 작성 후 커널을 컴파일한 다음에 재부팅해야 하는 불편한 점이 있다. 이 문제를 해결하기 위해서 dymanic probes 기능을 제공한다.
개념적으로는 일반적인 디버거의 breakpoint를 설정하는 방식으로 수행될 커널 루틴 주소를 등록할 수 있는 인터페이스를 제공한다. 커널 공간뿐만 아니라 사용자 공간에서도 이 기능을 사용할 수 있도록 인터페이스를 제공한다. 커널이 생성하는 메시지를 기록하여 시스템에서 발생하는 여러 상황들을 명확히 표현할 수 있도록 이벤트 로그(evlog) 기능도 제공한다. 물론 기존에 사용되던 syslog가 존재하긴 하지만, syslog의 체계적이지 못한 로깅 방식은 시스템 개발자나 관리자에게 필요한 정보를 충분히 제공하지 못하기 때문에 새로운 표준을 적용하고자 하는 것이다. 또한 커널 디버거도 지원하며, 소스코드 시험 빈도 정도를 확인할 수 있는 coverage 도구를 제공하여 파일별, 소스 라인별 수행된 정보를 HTML 파일을 생성하여 보여준다.
보안은 CGL 규격 명세서의 기본적인 보안 기능을 만족시킨다. 또한 보안 결함을 발견할 때마다 보안 패치를 적용하는 사후 대응식의 접근을 방지하기 위해 MAC(Mandatory Access Control) 방식의 SELinux(Security-Enhanced Linux) 기능을 제공한다. SELinux는 미국 NSA(National Security Agency) 주도로 이루어진 오픈소스 기반의 프로젝트로, 비교적 최근에 제품으로 활용되고 있지만 오랜 기간에 걸쳐 개발·검증됐다. 데비안, 수세, 레드햇, 젠투(Gentoo) 등의 주요 배포판에서 적용하고 있다.
SELinux 의 보안 정책은 시스템 내의 모든 프로세스가 제한된 도메인에서만 실행되도록 sandbox 개념을 구현한 것이다. 즉 각 프로세스는 자신 도메인에서 자신에게 주어진 최소한의 권한 내에서만 동작하고 다른 프로세스 도메인을 간섭할 수 없다. 따라서 악의적인 사용자에 의해 시스템이 해킹당했다 하더라도 그 피해는 해당 프로세스 내로 제한되고, 피해가 확산되지 않는다. 이러한 보안 정책 설정을 위해 RBAC(Role Based Access Control)와 TE(Type Enforcement)를 결합한 형태의 정책 설정과 여러 개의 정책 설정 파일을 설정해야 한다.
예를 들면 아파치 기반의 웹 서비스의 경우 웹 서비스를 위한 프로세스의 데이터 파일 접근에 대한 정의와 라이브러리 사용에 대한 규칙, 사용자의 접근 제어, 네트워크 포트 등의 접근 정의 등 웹 서비스가 이루어지기 위해 사용되는 서버 자원과 주체 등 모든 부분에 대한 보안 정책을 설정해야 한다. 이러한 보안 정책 파일로 생성된 바이너리 정책 파일은 명령어에 의해 커널에 로드된다. 따라서 SELinux는 기존의 보안 코드 패치 방식이 아닌, 규칙 설정 방식이다. 또한 SELinux의 커널 코드 부분은 기존 방식인 시스템 호출 수준에서의 보안 제어 방식이 아니라 커널 기능 중 보안 확인이 필요한 부분이 설정된 규칙 등에 부합되는지를 확인하기 위해 보안 모듈을 호출하는 방식으로 구현되어 있다.
차세대 클러스터링 기술인 서버 가상화
리눅스 서버 가상화 기술은 인프라 내의 모든 IT 자원을 공개 표준에 기반해 가상화된 자원으로 정의하고 자원 풀을 형성하여 통합 관리할 수 있도록 해준다. 또한 이렇게 가상화된 자원을 각 서비스에 동적으로 할당 혹은 반환하여 자원의 활용도를 향상시키고 가상의 컴퓨팅 환경을 구축할 수 있도록 해준다. 이러한 가상화 기술을 통해 인프라 내 시스템의 성능을 향상시키고 확장성과 안정성을 제공할 수 있다. 더욱이 인프라 내 시스템 자원의 활용도를 극대화시켜 시스템 관리 비용을 줄일 수 있다. 이러한 리눅스 서버 가상화 기술을 <그림 10>과 같이 효과적으로 구현함으로써 최종 사용자들은 물론이고 시스템 관리자들에게도 가상의 리눅스 환경(linux virtual environment)을 제공할 수 있다. 이 리눅스 서버 가상화 기술을 LiVE(Linux Virtual Environment)라고 한다. 부요 서버에서는 <표 3>과 같이 단계적으로 기술을 개발하고자 한다.
1, 2단계는 CGL 규격 명세서 중 리눅스 클러스터링 기능에 관한 것으로 고가용 scalability 클러스터이며, 3단계는 기업 컴퓨팅용의 그리드 시스템을 의미하며 차세대 컴퓨팅 모델인 유틸리티 컴퓨팅 환경, 즉 전기나 수도와 마찬가지로 자유롭고 쉽게 컴퓨팅 지원을 사용할 수 있는 환경의 핵심 기술을 확보하고자 한다. 현재의 부요 서버에서 제공되는 LiVE 기술은 LiVE-HA와 LiVE-C로 나누어진다. LiVE-HA는 시스템 전체의 가용성을 높이고 중단 없이 안정적인 서비스를 제공할 수 있는 HA 클러스터링 지원 기능이다. LiVE-C는 클러스터 내 모든 자원을 통합 관리하여 가상의 단일 시스템 이미지를 제공함으로써 사용자 편이성을 높이고 클러스터 시스템의 자원 활용도를 개선할 수 있는 클러스터 자원 가상화 기술이다.
LiVE -HA는 독립 소프트웨어 시스템으로 동작 가능하며 일반적인 HA 클러스터링을 지원할 수 있다. 또한 LiVE-HA는 LiVE-C의 고가용성을 위해 LiVE-C의 핵심 기반 소프트웨어로 포함될 수도 있다. 기존의 HA 클러스터링 방식과 LiVE-HA의 차이점으로는 primary/backup 기법과 cascading 기법의 문제점을 해결하고 장점을 결합한 cascading primary/backup HA 기법을 제공한 점이다. 따라서 패일오버(fail-over) 시간이 단축되어 전체 시스템의 가용성을 향상시킬 수 있다. LiVE-C 구성요소는 scalability 클러스터링 기능, 클러스터 프로비저닝(provisioning)과 관리 기능과 원격 설치 기능으로 구성된다. Scalability 클러스터링 기능은 오래 전부터 잘 알려져 있는 LVS(Linux Virtual Server)이기 때문에 여기서는 더 이상 언급하지 않는다. 클러스터 프로비저닝이란 클러스터 시스템(HW & SW)의 구축부터 시작하여 특정 서비스를 설치하고 실제로 서비스를 실행시키기까지 일련의 모든 과정을 통합 가상화하여 제공하는 것을 의미한다. 따라서 LiVE-C에서는 이러한 클러스터 프로비저닝을 위해 다음과 같은 기능을 제공한다.
◆ 클러스터 모델링 : 클러스터 내 자원의 통합 관리를 통해 각 구성 요소들간의 구성 데이터의 일관성 유지
◆ 설치부터 응용 서비스까지의 완전한 프로비저닝 지원 : OS조차 설치되지 않은 노드에서 시스템 이미지 설치 및 서비스를 위한 가상 서버 풀 구성 후, 현재 제공되고 있는 서비스와 모니터링 자료 등을 기반으로 추가된 노드가 담당한 서비스 구성
이러한 클러스터 프로비저닝은 표준화된 개방형 프레임워크를 지원함으로써 상호호환성을 높여 일관된 시스템 관리를 가능하게 하는 DMTF 표준을 근간으로 한다. 1992년 설립된 DMTF는 인터넷과 기업 환경에 대한 표준을 개발, 채택하고 상호 이용을 주도하는 기술 산업 조직으로서 멤버를 중심으로 워킹그룹을 형성하여 표준 규격을 정의하고 개발해 나가고 있다. DMTF에서 정의하고 있는 표준 중에 부요 서버와 관련되는 표준은 CIM, WBEM(Web-Based Enterprise Management)이며, CGL 규격 명세서에서도 요구 기능으로 이미 정의되어 있다. CIM은 시스템 자원 및 서비스 등의 관리 정보를 교환하기 위한 표준 모델이며, WBEM은 시스템 관리 응용, CIM 정보 전달자 등 간의 정보 표현 방식과 전달 방식에 대한 표준을 기술하고 있다.
LiVE -C의 마지막 기능은 원격 설치 부분으로 단순히 단일 시스템에서의 설치가 아니라 분산 혹은 클러스터 환경을 고려한 설치 방법을 제공한다. LiVE-C는 여러 노드를 위한 시스템 이미지를 생성하고, 하나의 클러스터 시스템을 구축함에 있어 다양한 정보들, 즉 사용자, 호스트, 서비스의 설정 파일들을 동기화하여 유지한다. 그리고 생성된 이미지로 네트워크의 설정을 통해 이미지를 사용하는 모든 서버 노드들에 자동 설치가 이루어진다. 또한 클러스터 환경에서 패키지 목록 조회, 정보 조회, 원격 패키지 설치 기능도 제공한다. 이러한 LiVE 기능들은 LAT(LiVE Administration Tool) 통합 관리 도구를 통해 사용할 수 있다.
부요 서버의 표준 기능 만족도와 성능
마지막으로 부요 시험에 대해 살펴보자. LSB2.0 표준 준수 여부 시험은 서버뿐 아니라 데스크탑에서 LSB runtime 시험슈트 2.0.6-2를 사용하여 진행됐다. 특히 부요 서버 경우는 기본 기능 시험과 고부하 지속 시험, 다양한 성능 시험이 이루어졌다. 기본 기능 시험은 시스템 호출 인터페이스를 통해 부요 커널의 기본 동작 상태를 시험하는 것으로, 공개 프로젝트인 LTP(Linux Test Project)의 시험슈트를 활용했으며 타 제품과 비교 결과 동일한 결과를 낳았다. 고부하 지속 시험은 모든 서버 자원을 고갈시키는 스트레스 부하 상태를 5일 동안 계속적으로 수행해야 시험을 통과하는 조건이다. 사용된 슈트는 기본 기능 시험 때와 마찬가지로 LTP 슈트를 사용했다.
마지막으로 성능 시험의 경우는 운영체제 성능, 웹 성능, 데이터베이스 성능, 파일전송 성능 등으로 이루어졌으며 타 제품과 유사한 결과를 낳았다. 이 글에서는 운영체제 성능에 대해 언급한다. 이 성능 시험은 다중 사용자 환경을 모델링하여 시스템에 부하를 가할 때 전체 시스템의 작업 처리량을 측정함으로써 시스템의 성능을 확인하는 방식의 AIM 멀티유저 벤치마킹 슈트를 사용했다. 2프로세서 및 4프로세서 시스템에서 커널 2.6 기반의 국외 제품인 수세, 레드햇과 비교 분석한 결과는 <그림 11>과 같다. 결론적으로 기본 기능 시험 및 고부하, 성능 시험 등을 통해 부요 규격이 국외 타 제품과 동등한 기능, 성능을 발휘함을 알 수 있었다.
한국 리눅스의 희망
지금까지 부요의 전반적인 스펙에 대해 자세히 알아보았다. 부요가 가야할 길은 아직 멀지만 충분히 좋은 결실을 얻었고 또 전망이 밝기 때문에 부요를 감히 한국 리눅스의 희망이라고 말할 수 있을 것이다. 부요의 향후 계획으로는 부요 플랫폼 기술을 기반으로 동북아시아 한·중·일 공개 소프트웨어 공통 핵심 기술 개발과 3국간 공통 표준플랫폼 개발에 점차적으로 참여를 강화하여 국제 커뮤니티에 기여하고, 글로벌 제품 개발에 노력할 것이다. 이제부터 리눅스 사용자와 개발자들의 지지와 충고가 본격적으로 필요한 시기이다. [MASO]