클라우드 진화와 가상화 – 각 단계별 설명

각 단계별로 어떤 식으로 하여 서비스가 진화되는지를 실제로 살펴보는 글을 적어볼 것이다.

  • 가상화하기

가상화의 첫 단계는 제한적으로 사용되는 자원들을 통합된 자원으로 탈바꿈시키는 것이다. 즉, 가상화 서버를 도입하고, SAN을 티어링하여 부분적인 통합 관리를 하는 것이다. 그러면 데이터센터의 전력 및 공간 사용 비용의 절감 효과를 얻을 수 있으며(일부 인프라에서는 얻을 수 없다.), 스토리지 관리의 생산성을 증가시킬 수 있다.

가상화를 통하여 기본적으로 얻을 수 있는 효과는 다음과 같다.

  1. 전력 및 공간 사용 비용 절감
  2. 데이터 센터 장비 비용 절감
  3. 스토리지 관리 생산성 향상
  4. 에너지 효율성 증가
  5. 탄소 배출 감소
  • 운영화하기

그 다음 단계로는 IT 환경 통합과 운영화이다. 여기서는 보안, 가용성, 성능, 통제 요구 사항에 근거한 리소스 풀을 극대화한 스토리지 회적화 및 계층화된 티어드 가상화 서버를 포함한다. 통합된 관리 및 보안은 이 단계에서 궁극적으로 얻고자 하는 결과치를 극대화해주는 주요한 요소로 인식된다.

운영화를 통하여 기본적으로 얻을 수 잇는 효과는 다음과 같다.

  1. 운영 비용 절감
  2. 데이터 센터 장비 비용 절감
  3. OS 가상화
  4. 미션 크리티컬 어플리케이션내의 가상화 컴포넌트
  5. 탄소 배출 감소
  • IT-as-a-Service

마지막으로 총체적으로 공유되고 단계화된 인프라를 다중 소유, 셀프 서비스, 서비스 필요에 근거한 개발 플랫폼 및 서비스 소프트웨어 형식의 인프라로 변화시켜야 한다.

개발자들은 J2EE, .NET 같은 통합된 개발 환경을 선택하고, 셀프서비스 형식으로 자신들의 어플리케이션을 Quality Assurance / Develope / Test 의 과정을 거쳐 개발을 진행할 수 있으며, 최종 사용자는 서비스 카탈로그에서 원하는 것을 고르는 것처럼 원하는 어플리케이션을 고르고, 심지어는 2개 이상의 어플리케이션을 함께 선정하여 사용할 수도 있게 된다. 이것의 예로 들면 세일즈포스닷컴과 구글 맵을 사용하여 고객 사이트로의 목표, 방향 설정 등을 하는 서비스를 예로 들 수 있다.

이 마지막 단계는 최종 사용자에게 투명한 비용 구조를 제공해 주는 역할을 한다. 즉, 최종 사용자는 원하는 대로 사용한 후, 상세한 비용 내역을 확인하고 비용을 지불할 수 있고, 또한 조직 내 및 회사 내의 어느 누가 서비스를 얼마만큼 사용하였는지 또한 총채적으로 파악할 수 있게 된다. 보안, 통제, 규제, 규정은 신뢰할 수 있을 만큼 각 서비스 내에 내제되어 있는 상태로 말이다.

클라우드 진화와 가상화

물리적인 인프라들을 결합하여 동일한 서비스를 지원하는 가상화 작업을 통해 운영화, IT-as-a-Service(Iaas)로 진화해 가는 과정에 있어서 어떤 과정으로 진화하는지, 그리고 가상화가 어떤 식으로 쓰이는지 알아보겠다.

가상화의 주체는 주요 IT조직, 부서이며, 가상화는 높은 운영비용 예산 하에서 운용된다. 각 비즈니스 부문은 가상화 인프라상에서 움직이게 된다. 그러나, 사용되는 어플리케이션은 특정 비즈니스 부분, 부서, 조직에서 사용하는 하드웨어와 연관성이 많다. 그 이유는 어플리케이션은 하드웨어(컴퓨터 하드웨어 뿐만 아닌 여러 복잡한 하드웨어 전체를 예기합니다.) 상에서 존재하고, 예산 편성이 어떻게 수렵되고 집행되는지는 일반적으로 그 비즈니스 부분, 부버, 조직에 따라 달라지기 때문이다. 이러한 환경은 비즈니스 부분의 필요에 따라 확장되게 되는데, 모든 일련의 IT 환경은 그 특정 부분, 부서, 조직의 필요품을 충족하면서 그에 맞는 신뢰받는 IT 환경으로 인식되어 사용될 수 있다.

이제 가상화를 통한 클라우드로의 진화를 이루기 위해서 비즈니스와 IT 조직은 점진적인 IT 통합 및 일반화된 리소스 풀(Resource Pool)을 통하여 추가적인 비용 절감을 할 수 있도록 지속적인 노력을 한다. 운영화에서는 IT 관리부서나 비즈니스 관리는 “모든 것은 가상화한다”라는 전략을 수렴해 놓은 상태이다. 운영화에서의 선택적인 접근 방식은 시스템 장비들의 효율성을 증가시킨다. IT 환경은 인건비 효율성을 향상시키기 윈하여 고도로 자동화되어야 한다. 이 단게에서 IT 환경은 이미 내부적으로 정의된 서비스 레벨 목표에 부합하기 위하여 On-Demand화 되고, 비즈니스는 IT 자원의 고가용성 및 높아진 용량을 최대한 활용할 수 있게 된다.

서비스로서의 IT 단계에서 IT는 비즈니스에게 있어서 유틸리티이다. 각 비즈니스 부문은 이제 원하는 자원 및 새로운 어플리케이션을 셀프서비스 형식으로 사용할 수 있게 되며, IT 자원이용 및 IT 비용에 대한 리포트를 구체적으로 작성하고 받아볼 수 있게 된다. 이것은 경쟁력 있는 IT를 사용하게 됨으로써 진정한 비즈니스 민첩성을 얻는 효과를 누리게 된다. IT 서비스는 마치 메뉴를 고르듯 서비스 카탈로그에서 찾아볼 수 있게 되고, 사용자는 원하는 만큼의 서비스를 필요에 따라 늘리거나 줄이면서 사용할 수 있게 된다.

가상화의 역사

가상화는 1960년 중, 후반에 IBM이 가상화의 개념을 탄생시켰다. 당시 가상화는 하드웨어와 소프트웨어가 필요했으며, 가상 메모리가 가상화를 실현시키는 개념이었다. IBM은 현재까지도 가상화 메인프레임을 제작중이다.

이후에 x86 하드웨어 가상화는 1990년대 후반에 스탠포드대학의 리서치팀이 VMware를 개발하면서 소개되었으며, 당시 명명된 코드네임은 Disco였다. 이것에 대한 자료는 http://www.cs.pdx.edu/~walpole/class/cs533/winter2008/slides/9a.ppt를 참조. ㅇㅅㅇ

2000년대 초에 접어들면서부터, 상가상화가 개발되었다. 상가상화는 게스트 OS가 Hypervisor와 직접 연동될 수 있도록 시스템이 수정되었다. 지금 이것의 가장 대표적인 예가 바로 Xen이다.

가상화의 진화 과정 요약

  1. 1960년대: IBM 시스템 360-67 메인프레임 W/CP-40 OS
    1. 궁극적으로 VM/370으로 발전함.
    2. VM/370에 풀 버추얼 메모리 용량 추가.
    3. Hypervisor라는 용어가 Supervisor로부터 파생됨.
  2. 1990년대 후반: 전체 가상화(Full Virtualization) – Disco
    1. 수정되지 않은 OS/애플리케이션 코드.
    2. Hypervisor 조정으로 인한 Performance 감소
    3. x86 아키텍쳐 문제 발생
  3. 2000년대 초: 상가상화(Paravirtualization) – Xen
    1. OS가 Hypervisor와 직접 연동.
    2. OS 코드는 Hypervisor와의 직접 연동을 위해 수정되어 만들어짐.

현재 IT 정보기술의 당면 문제

오늘날에 여러 곳에서 클라우드가 크게 화제가 되고 있는데, 무엇이 클라우드로 변화를 이끌고 있는 것일까..? 오늘날의 IT 시장은 도데체 무슨 문제를 가지고 있는 것일까?

정보 기술이 메인 프레임 -> 미니 컴퓨터 -> PC/마이크로프로세서 -> 네트워크/분산 컴퓨팅 으로 진화하여 클라우드까지 닿는 데에는 정보 기술의 진보와 함께 어떠한 당면 문제가 있기에 바뀌게 된 것이다.

각 IT 조직들에 있어 클라우드로 변화하는데 영향을 주는 요소는 조직마다 처한 비즈니스 환경, 요구, 가고자 하는 방향에 따라 다를 수 있으나, 공통적으로 동작하는 부분이 있다. 바로 비용(Cost), 가용성(Availability), 신속한 시장 출시성(Time-to-Market) 등이 있다.

하나의 기업, 회사, 조직에서 최고 결정권자들이 기업 경쟁력 강화 및 시장에서 유리한 위치를 차지하기 위해서는 이용 가능한 정보 및 데이터를 최대한 효율적으로, 유연하게, 최다핸 저렴하게 사용할 수 있는 혁신적인 방법을 필요로 한다. 이에 IT 담당자들은 자신들이 관리하고 유지하는 IT 기술에 최대한 민첩하고, 최고 결정권자들의 기대에 부흥할 수 있는 방법을 찾기 위해 노력하고 있을 것이다.

이에 비즈니스 각 부분, 즉 비즈니스 프로세스 담당자들은 외부의 소싱을 통하여 업무를 진행하는 것이 회사 차원에서 일정한 금지가 있는 환경에서도 자신들의 목적에 맞게 외부 IT 아웃소싱을 구매할지, 아니면 사내 IT만을 이용할지, 사용을 하지 않을 지에 대해 충분한 결정을 할 것이라 믿고 있는 듯 한 경우가 많다. 대부분의 IT조직에서는 자신들이 내부적으로 제공하는 IT 서비스가 외부의 IT 아웃소싱 서비스보다 더 훌륭한 서비스로 인정받기를 원하고, 그에 부응하도록 끊임없는 노력을 하고 있다. 즉, 기본적으로 제공되어 수행할 임무를 넘어, 외부의 다른 서비스보다도 더 좋은 서비스로 인식되어 사용되기를 바라는 것이다. (이건 경영자 마인드이다.)

IT 조직들은 이를 검토할 때, 새로운 컴퓨팅 모델을 통하여 IT 성과를 극대화시키길 원하지만, 동시에 기존 IT 환경의 효율성 또한 향상시키려고 노력해야 하는 책임은 벗어날 수 없다. 즉, IT 조직들은 기존 IT 환경의 효율성과 새로운 IT 모델을 통한 IT 효과 극대화라는 두 마리의 토끼를 잡기를 희망하지만, 서로 상이한 도구, 인프라, 예산 집행 등을 병행하여 생성하는 것을 희망하지 않는다. 이 문제가 얼마나 골치아픈 문제인지는 실제로 겪어보지 않은 사람들은 모르는 일이다.

그렇다면 지금에 와서 여러 회사들이 공통적으로 IT 관련 직면 문제로서 고민할 사항들을 예로 보면 다음과 같다.

  • 글로벌화(Globalization): 비즈니스 서비스는 24시간, 365일 멈추지 않고 진행해야 한다. 그리고 이 비즈니스 서비스가 불과 몇년전까지는 국내 서비스만으로 만족해야 했으나 이젠 스마트폰 서비스, 네트워크의 강화 등을 이용하면 전 세계 어디서나 작업할 수 있는 환경이 되었기에 반드시 확인해야 할 요소로 자리잡고 있다.
  • 노화되는 데이터센터(Aging Data Centers): 오래된 IT의 마이그레이션, 업그레이드를 통한 개선이 필요하다. 특히 닷컴 붐을 통하여 구축된 클라이언트/서버, 분산처리 시스템은 현재 2000년 초반에 주로 구축한 서비스 시스템들이고 이 시스템들이 때를 맞춰서 노후화가 진행되어가고 있다.
  • 저장 데이터 증가(Storage Growth): 스토리지 소비 및 사용량이 폭발적으로 증가하고 있다. 접근성이 쉬워질수록 그로 인해 생성되는 정보의 양은 기하급수적으로 증가하게 된다.
  • 어플리케이션 증가(Application Explosion): 어플리케이션 수가 증가하고, 그에 따른 사용량이 증가하지만 이 속도를 따라갈 정도의 신속한 인프라의 대응 및 확장이 부족한 상태이다.
  • IT 유지비용 증가(Cost of Ownership): 각종 성장비용(ex: 장비, 전력, 냉각, 라이센스, 서비스 서포트 등)에 따른 영향으로 인해 확장이 어려운 상황이다. 실제로 인프라 증가를 위한 코스트는 소규모라도 몇백에서부터 시작한다.
  • 정보 보안(Security): IT 거버넌스 및 리스크에 대하여 우리 회사, 조직이 얼마나 취약한지를 파악해야 한다. 인프라가 증가하고 그에 따라 시스템을 계속 이어붙이게 되면 여기저기에 컴퓨터공학적 보안의 구멍이 생길 수 있게 된다. 이 부분에 대한 코스트도 구축 당시부터 시작하여 유지, 보수 단계까지 해서 기하급수적으로 증가하게 된다.
  • IT 복잡성(Complexity): 곳곳에 흩어져있는 시스템들과의 물리적인 엑세스가 부족하며, 작업 부하 분산을 통하여 사용자들의 요구를 맞출 수 있다고 하지만 그에 따른 비용과 시간이 너무 많이 소요되고 있다.
  • 병합, 인수(M&A): 회사간의 M&A를 통하여 IT 인프라의 통합 움직임이 보여지고 있다. 서로가 부족한 서비스를 보충하기 위하여 경영진의 입장에서 M&A를 추진하여 생긴 문제와 그를 해결하기 위한 코스트가 발생한다. 이 코스트는 IT 조직 내에서도 측정 불가능한 코스트에 속하기 때문에 쉽게 볼 문제가 아니다. (실제로 외부 회사의 시스템이 내부 시스템과 많이 상이해서 서로간의 연계 방식을 찾지 못하는 최악의 경우에는 데이터 센터를 합병한 회사가 가진 갯수만큼 갑작스럽게 증가하게 되는 경우가 되므로 이 코스트는 무시할 수 없는 수준이 된다.)

적을 게 없어 보여도 정말로 많은 문제들이 있다. ㅇㅅㅇ;;

Single UNIX Specification

단일 유닉스 규격(Single UNIX Specification)은 컴퓨터 운영체제가 유닉스란 이름을 사용하기 위해 지켜야 하는 규약을 말한다.

이 규격은 1980년대 중반, 여러 유닉스 계열의 인터페이스를 표준화하기 위해서 시작한 프로젝트에서부터 시작하게 되었다. 업체마다 각기 다른 운영체제 사이의 소프트웨어 이식에 들어가는 비용을 되도록이면 줄여달라는 운영 기업들의 요청으로 인해 시작되었다. 이때, 표준화 운영체제로 선택된 운영체제는 유닉스인데 유닉스가 특정 회사에 의해서 만들어진 운영체제가 아닌 데다가 특정 회사 제품에 의한 종속성이 없었기 때문에 유닉스를 사용하게 되었다. 이 프로젝트로 만들어진 것이 바로 POSIX이다.

그러나 1990년대, 이시기에는 유닉스 전쟁이란 말로 전부 해설이 가능한 시기이다. 몇 군데의 회사들이 COSE(Common Open Source Environment) 협정을 결성하여, Common API Specification 또는 Spec 1170이라 불리는 사양을 내놓았다. 이 사양은 POSIX와는 달리 무료로 입수할 수 있었기에 IEEE에 접근하여 인증받는 비용을 부담해야 하는 POSIX보다 널리 일반화되었다. 1998년에 Austin Group이라 불리는 공동의 워킹 그룹이 이 사양들의 통합을 시작하여, 그 결과로 Single UNIX Specification version 3(단일 유닉스 규격 제3판)이 탄생하게 된다.

단일 유닉스 규격에서 규정하는 운영체제와 사용자 및 소프트웨어 사이의 인터페이스는 다음의 4 가지로 분류된다.

  • Base Definitions : 표준 규격을 기술하는 데 사용되고 있는 정의와 규약 등의 목록과, 이에 따르는 운영체제가 반드시 제공해야 할 C 언어의 헤더 파일 목록들.
  • Shell and Utilities : 유틸리티(약 160개의 명령들)의 목록 및 셸(sh)의 내역.
  • System Interfaces : 제공되어야 하는 시스템 호출 및 C 라이브러리의 목록들.
  • Rationale : 위의 표준에 대한 해설들.

이 표준에 의한 사용자 명령 줄 인터페이스와 스크립트 인터페이스는 초기 콘 셸에 바탕을 둔 본 셸의 확장판인 POSIX 셸이다. 이 밖에 사용자 레벨의 프로그램 또는 서비스, 유틸리티로는 awk, echo, ed 등 수백여개의 목록이 포함되어 있다. 프로그램 레벨에서 필요로 하는 서비스로는 입출력(파일, 터미널, 네트워크) 등이 있다. 이 표준을 테스트하는 프로그램 모음인 PCTS(Posix Certification Test Suite)가 있다. PCTS는 NIST에서 오픈 소스로 공개되어 있다.

이 사양이 알려주는 것중에 제일 주의할 점은 사양을 만족하기 위해 AT&T의 유닉스 소스 코드를 사용하지 않아도 된다는 점을 주의해야 한다. (실제의 예로, IBM의 z/OS (OS/390)은 소스코드는 완전히 독자적으로 만들어졌으나, ‘UNIX’란 이름을 사용하도록 허용받고 있다.)

단일 유닉스 규격을 따르고 있는 유닉스들은 다음과 같다.

  • AIX
  • HP-UX
  • Mac OS X: 10.5 레오파드부터 인증에 통과했다.
  • Reliant UNIX

  • SCO
  • Solaris
  • Tru64 Unix
  • z/OS
  • NCR UNIX SVR4
  • NEC UX/4800
  • SGI IRIX 6.5

유닉스 계열로 분류되면서 단일 유닉스 규격을 만족하지 않는 운영체제들

  • BSD 계열: C99 and POSIX Conformance Project에 의해 제작된 BSD 계열은 단일 유닉스 규격을 만족하지 않는다. FreeBSD, OpenBSD도 마찬가지 이유. ㅇㅂㅇ
  • 리눅스: 유닉스 운영체제에서 파생되어 나온 것이지만 전체적으로 규격이 많이 다르다.

PC-UNIX

음… 솔직히 말하면 이게 상당히 애매한 용어이다. 왜 애매한 용어인지를 알려주겠다는 식의 글이라 보시면 될 거 같다.

PC-UNIX는 PC에서도 동작을 하는 유닉스를 말한다. 근데 이게 용어로 써있는 책을 잘 뒤져봐라.. 미국과 유럽 계열에서는 거의 없을 것이다. 주로 아시아 계열의 책이나 용어집에서는 반드시 나온다. (위키백과에서도 영어로 써있지도 않다. ㅡㅅㅡ;;)

이 용어를 주로 쓰는 곳은 바로 일본이다. ㅡㅅㅡ 주로 운영체제에 대한 서적을 뒤져보면 PC에서 동작하도록 나온 유닉스를 말하며, 원래 명칭으로는 Unix-like system의 일부분중 PC에서 돌아가는 녀석들을 모아다가 죄다 PC-UNIX라고 써놨다.

원서보면 거의 헷갈리는데 이 용어가 나중에 산업기사/기사 보는 분들은 꼭 한번씩은 접한다. 그러다 보면 이 용어갖고 여러모로 말이 무지 많이 돌기도 한다. (근데 현업에서만 개발하는 인간들은 그런 거 필요없다. ㅡㅅㅡ)

이 용어에 대한 일본측 원서에서는 이 운영체제들에 대해 이와 비슷하게 정의하고 있다. [고가의 대형 컴퓨터를 동작시키기 위한 Unix를 PC에서 이용할 수 있도록 아키텍쳐 지원과 메모리 관리 기능의 수정 등을 통하여 PC에서 동작이 가능하도록 만든다. 단, 유닉스에서 사용할 수 있는 기능들은 거의 그대로 이용할 수 있도록 지원하는 것을 전제로 한다.] 라고들 써 있다. 아니면 이 문장 순서의 변경이 있긴 하겠지만 기본적으로는 PC에서 동작 가능하도록 설정은 다 맞춰주면서 기능은 그대로 가져간단 것이다. 뭐, 유닉스 시스템이 그만큼 성능적으로는 인증되어 있는 시스템이니 그럴 수 밖에 없겠지만..

일단 여기에 속하는 듯하게 적어놓은(?) 유닉스 계열의 시스템들은 다음과 같다.

  • PANIX
  • XENIX
  • Linux
  • FreeBSD
  • NetBSD
  • OpenBSD
  • Solaris/OpenSolaris

…좀이라도 유닉스 시스템을 아는 사람들은 바로 보고 눈치챘을 것이다. 여기에 있을 필요가 없는 녀석이 하나 눈에 띈다는 것을…ㅡㅅㅡ;; 그리고 대놓고 타분류화된 녀석이 또 하나 있다…ㅡㅂㅡ;;

애당초 리눅스의 탄생이 PC에서 돌리는 유닉스였고, 솔라리스는 x86 플랫폼 지원을 하다 보니 어쩌다 PC도 지원한다. 게다가 10부터 오픈소스화 되는 바람에 PC에서 돌아가야 하는 상황이었고, 오픈솔라리스는 원래부터 대상이 PC다. ㅡㅅㅡ

뭐, 이것저것 골때리는 용어이긴 한데.. 그냥 PC 구동용 유닉스라고만 대충 생각하고 넘기면 될 듯 하다..

POSIX(Portable Operatiing System Interface)…?

POSIX(Portable Operatiing System Interface)는 서로 다른 유닉스 운영체제의 공통 API를 정리하여 이식성이 높은 유닉스 운영체제 프로그램 개발을 위한 목적으로 정의된 인터페이스 규격입니다. 규격의 정의는 IEEE에 정의가 되어 있고, 최신 규격으로는 2.0 버전까지 정의되어 있습니다.

유닉스의 장점인 높은 이식성은 바로 이 규격을 통하여 이용되는 장점이죠… 커널 수준의 시스템 콜뿐만 아니라 사용자 레벨 프로그램, 프로세스 환경, 파일과 디렉토리 관련, 시스템 데이터베이스, 압축 포맷 등등의 다양한 분야에서 이용되는 표준 규격 인터페이스이기 때문에 여러 유닉스, 리눅스에서도 거의 동일하게 프로그램 소스를 컴파일해서 이용할 수 있는 장점을 가지게 되는 겁니다.

실제로 사용하는 데 있어서 차이점이 있다면 각 운영체제마다 가지는 환경적인 특징들만 차이가 날 것이지 쓰는데는 별 지장이 없다는 것을 알게 될 겁니다. 유닉스, 리눅스 프로그램들의 경우에는 프로그램 바이너리 파일만 받아서 그대로 make 돌려도 거의 바로 이용할 수 있는 게 바로 이 POSIX 규격에 맞춘 프로그램 바이너리이기 때문이죠. 소스 코드만 받아서 바로 컴파일 해서 쓰는 프로그램들도 표준 C 컴파일러조차 POSIX 규격에 맞춰서 시스템마다 동일하게 적용되어 있기 때문입니다. 간혹 페도라라던가 AIX와 같이 독자 환경이 있는 경우에는 좀 손을 봐서 처리해야 겠지만 규격에 준수가 되어 있는 대부분의 유닉스, 리눅스에서는 별 문제가 없습니다….ㅇㅅㅇ;;

윈도우 NT 계열에서도 POSIX 서브시스템을 탑재하고 있어서, POSIX 응용 프로그램을 서브시스템에서 실행할 수 있었습니다. 이게 윈도우 2000까지는 POSIX 서브시스템을 탑제하고 있었으나, XP에서 폐지되었습니다. 이후에 2003 서버에서부터 POSIX 2.0을 준수하는 서브시스템을 통하여 POSIX를 지원하는 형식으로 갖추고 있게 되었습니다. 윈도우에 보면 프로그램 추가/제거에 보면 유닉스 서브시스템이라고 되어 있는 것이 이 POSIX 지원 기능이죠. ㅇㅅㅇ;;

헷갈리면 안되는 게 윈도우 XP에 프로그램 추가 -> 윈도우 추가 제거에 보면 유닉스 시스템에서 프린터 공유하는 기능이 있습니다. 이걸 착각해서 예기하는 분이 있긴 한데.. 이거 아닙니다…ㅡㅅㅡ;;; 옛날부터 있던 프린터 공유 기능입니다.

MINIX…?

유닉스 운영체제를 공부할 때 해외에서 주로 이용하는 운영체제이다. 네델란드의 암스테르담 자유학교에 재직하던 교수 앤드루 타넨바움(Andrew Tanenbaum)에 의해서 교육용으로 만들어진 유닉스이다. 어원명은 mini-UNIX라고 한다.

미닉스의 커널이 리눅스 커널의 영감을 주게 되었다는 것이 리눅스 탄생설이다. (근데 진짜다.)

미닉스의 최신버전이 MINIX 3의 커널은 다른 커널과는 달리 마이크로 커널을 채용하였다. 커널 제작 라인도 그렇게 많지도 않고, 소스코드도 그렇게 많이 들어있지 않은 편이다. 따라서, 쉽게 재작해서 쓰면서 동시에 OS 공부도 할 수 있기 때문에 미국, 유럽 지역에서는 자주 사용되는 녀석이다. 요즘은 리눅스로도 할 수 있지만…

일단 좀만 더 깊이 공부해 보신 분들은 알겠지만 유닉스랑 리눅스는 커널 자체가 완전 다릅니다. 그렇기 때문에 유닉스를 기반으로 본격적인 OS 커널을 다루고자 하실때는 이걸 주로 이용하죠. 근데 오픈솔라리스 등의 유닉스 계열의 오픈소스들도 많다보니 굳이 이걸 쓸 일이 없어졌지만요..^^;;

본인이 마이크로커널에 관심이 많다면 한번 제대로 봐보세요. 공부 많이 됩니다.

Unix…?

이걸 모르고는 뭔 넘의 컴퓨터 역사와 운영체제를 논하리오!!!! ㅇㅁㅇ/

AT&T 벨 연구소에서 개발한 운영체제이다. 워크스테이션, 서버, 메인프레임 등에서 쓰이기 시작하였으며 데스크탑용, 임베디드용으로도 널리 쓰이고 있다. (지금은 리눅스에게 밀리는 거 같아 보이지만 그래도 여전히 유닉스 쓰는 곳 많다.)

컴퓨터 역사상으로도 엄청나게 중요한 운영체제이다. 지금 현재 프로그래밍 언어공부의 시작이자 업계 표준인 C언어도 원래는 유닉스를 프로그래밍하기 위해서 만들어진 것이다. ㅇㅁㅇ?! 이때 당시의 서버나 메인프레임 운영에 쓰이던 프로그래밍 언어는 전부 어셈블리어로 개발되어 기계어랑 1:1 대응되어 다른 하드웨어 이식 등에 여러 문제를 가지고 있었으나, 유닉스가 C언어라는고급언어로 만들어지면서 하드웨어 이식에 따른 제약이 사라지게 되었다. 여기에 추가로 당시 최신 기술이었던 멀티테스킹 기술을 가지고 있었기 때문에 인기가 많았다.

몇십년동안 자라온 CLI 기술의 축적이 강하기 때문에 윈도우 서버보다 더 인기가 강하다. 특히 초 대용량 서버들은 유닉스와 윈도우 서버로 양분되어 있다고 보면 된다. (리눅스는 초대형 시스템 구축에는 좀 어려운 점이 있다.) iOS, Android도 유닉스를 기반으로 만들어졌다고 보면 되겠다. 뭐, 정확하게 말하면 안드로이드는 리눅스에 가깝겠지만.. 위로 올라가면 다 유닉스로 올라가겠지..;;

추가로 인터넷 역사와도 함께 한다. OS가 인터넷으로 접근하기 위해 이용하는 소캣도 BSD 유닉스에서 만들어져서 사용되는 것이다. ㅇㅁㅇ?!?!

이렇듯 상당히 다양한 곳에서 역사와 함께한 시스템이므로 컴퓨터를 공부하는 사람들은 알아두면 좋은 게 많은 운영체제이다.

Year 2038 Problem – Another Unix Millennium bug

한참 옛날 일이 되어버렸지만 Y2K 라는 문제가 있었다. 컴퓨터가 날짜 계산시, 특히 1999년 12월 31일에서 2000년 1월 1일로 넘어갈 때 연도를 1900년도로 인식하여 날짜 계산에 엄청난 오류가 발생할 것이라는 인식하지 못할 것이라는 일종의 컴퓨터 설계 버그였다. 컴퓨터의 메모리가 용량은 적고 값은 무지 비쌌을 시절에 천공카드 사용시 1969년을 그냥 69년으로 표기하면 카드에 들어가는 데이터의 용량을 그나마 줄일 수 있었던 시절의 설계 오류였으나 몇몇 문제가 있는 것을 제외하고는 별 문제가 없이 끝났던 사건이었다. (이를 밀레니엄 버그라고 한다.)

근데 이젠 또 다른 시스템의 시계 문제가 불거졌다. 바로 2038년 문제라고도 하는 유닉스의 밀레니엄 버그이다. 근데 이거에 대해서는 현재 업계 종사자 대부분의 사람들이 별 걱정하지 않고 있다. 그렇다면 이게 무슨 문제이고, 왜 그냥 막 넘어가는 걸까?

POSIX 규격에 따른 시간 표기법에 의하면, 시간을 1970년 1월 1일 자정 UTC 시간 이후부터 경과된 초 시간을 이용하여 시간을 표기한다. 이 표기법은 대부분의 유닉스, 리눅스 계열의 OS에서는 거의 공통적으로 나타나는 표기 형식이고, POSIX를 지원하는 기타 운영체제들 또한 마찬가지로 일어나는 형식이다. POSIX 규격에 맞춰서 개발되었다면 C로 개발되었을 것이고, C의 데이터 표기 체계에 맞춰진 대부분은 32비트 시스템에서 초 시간을 저장하는 데 이용되는 time_t 자료 형식을 그대로 이용한다고 보면 된다.

time_t 자료 형식은 부호 있는 32비트 정수형이다. POSIX 표준에 따르면 이 형식을 이용하여 나타낼 수 있는 최후의 시각은 1970년 1월 1일 자정에서부터 정확히 2147483647초가 지난 2038년 1월 19일 화요일 03시 14분 7초 (UTC)이다. 이 시각을 지나면 시각 표기 자릿수 범위를 초과하여 내부적으로 음수로 표현되고 프로그램의 이상 작동을 유발하게 된다. 프로그램 구현 방법에 따라서 년도 값이 2038년이 아닌 1970년 또는 1901년으로 표기되기 때문에 기존에 있던 자료들의 생성 시간과의 차이가 생기게 된다. 이는 치명적인 오류를 낳게 된다. 상대시간 표기 오류가 발생하거나 바이너리 수준의 호환성 오류가 발생하여 파일이나 프로그램을 정상적으로 실행시킬 수 없게 된다.

이 문제의 해결책은 의외로 간단하다. 현재 나오는 CPU와 OS들이 이 문제를 다 해결해 주고 있다. 바로 64비트 아키텍쳐를 이용하면 된다. 표현되는 확장 범위가 32비트에서 64비트로 넘어가면 그만큼의 시간은 무지 길어지게 된다. 64비트 정수 체계로 넘기면 대략 계산 가능한 시간은 1970년 1월 1일 자정을 기준으로 9223372036854775807초를 경과한 2922억 7702만 6596년 12월 4일 일요일 15시 30분 8초 (UTC)까지 진행할 수 있게 된다. 근데 이 글을 보고 있는 여러분이 이 시간까지 살아서 오류가 날지 안날지를 지켜볼 수 있을 거라 생각하는가…? 최소한 태양의 수명이 앞으로 약 123억년이라고 하였고, 현대 과학은 아직은 시간 도약을 할 수 있는 기술이 없다. 그냥 잘~ 해결된다고 보면 된다. ㅡㅅㅡ;;;

현재 대부분의 PC의 경우에는 64비트 운영체제와 프로세서로 전환되고 있는 실정이기 때문에 문제 없이 진행이 될 수 있으나, 임베디드 장비들의 경우에는 아직도 심각한 문제일 수 있다. 임베디드형 연산은 아직까지도 최대 32비트 연산체계를 벗어나지 못하였기 때문이다. 거의 수많은 임베디드 시스템이 2038년에 모두 교체가 될지부터 엄청난 미지수이지만 눈앞에 당장 바로바로 사용되는 것들의 경우에는 쉽게 교체가 이루어질 수 있을 거란 전망이다. 단, 스마트폰 빼고는…ㅡㅅㅡ

(스마트폰 제조사들은 오버클럭 매니아들처럼 클럭 수 올리는 거에 혈안두지 말고 64비트 지원이나 먼저 신경 좀 쓰지…ㅡㅅㅡ)