Gentoo

psycho 2014. 5. 19. 22:54
 이 글을 찾아온 사람이라면, 아마 Gentoo를 사용해본 경험이 있는 사람은 아닐 것이다. 보통 Gentoo라는 리눅스 배포판을 처음 접하게 되는 계기가 "최적화"라는 키워드일 것인데, 이 글에서는 이것 때문에 퍼져있는 소문들에 대해 한 번 짚고 넘어갈 것이다. 필자와는 의견이 조금 다른 부분도 있지만, 다음 글을 읽어보는 것도 많은 도움이 될 것이다.

Gentoo 리눅스의 허와 실 - https://kldp.org/node/81215


 1. Gentoo는 초보자용이 아니다?

     확실히 다른 배포판에 비해 초기 진입장벽이 높은 것은 사실이다. 요즘엔 어지간한 배포판은 X 서버를 활용하여 마치 Windows를

    연상시키는 설치과정을 제공하고 있다. Windows하고 똑같이 버튼 몇 번 클릭하고 키보드 몇 번 쳐 주면 설치가 되는 것이다.

    그러나 Gentoo는 그렇지 않다. 컴파일 과정을 생략할 수는 있을지라도, 기본적인 시스템 구조를 설계하는 것은 여전히 사람이 해

    주어야 한다. 자동화된 도구들을 많이 제공해주고는 있지만, 보통 생각하는 "편함"과는 거리가 멀다.

     하지만, 정말로 아무것도 모르는 초보자 입장이고, 배우는 데 있어 게으르지 않다면, 처음 사용하기 위해서 좀 더 해줘야 할 게

    많은 것 빼고는 크게 다를 것이 없다. 오히려, 다른 배포판을 설치하면서는 쉽게 접할 수 없게 되어버린, Gentoo를 설치하면서

    접할 수 있는 많은 요소들은 앞으로 리눅스, 넓게는 Unix-like OS들을 사용하는 데 많은 도움을 줄 것이다.


 2. 최적화된 환경을 위해서는 Gentoo가 답이다?

     결론부터 말하자면 아니다. 보통 Gentoo에서 최적화라는 단어를 언급할 때 많이 나오는 것이 USE 플래그와 컴파일러 플래그인데,

    이들은 어떻게 사용하느냐에 따라 최적화는커녕 사용자의 두통을 유발할 수 있는 물건들이다. 자동화된 도구와 패키지 관리 체계는

    사용자의 실수를 방지해 주고 사용자를 편하게 해 줌과 동시에 사용자가 시스템을 마음대로 주무를 권리를 빼앗는다. 극한으로

    최적화된 환경을 만들고 싶다면 Gentoo보다는 LFS(Linux from scratch)를 알아보는 것을 권한다. 물론 LFS는 비록 해 보면 얻는

    것이 많을지라도, 진짜로 어지간한 실력으로는 손을 대지 않는 것이 정신건강에 유리하고 자원 절약에 도움이 된다. 매뉴얼이 잘

    되어 있긴 하지만, 그대로 하면 진정한 의미의 "최적화된" 시스템을 만들 수는 없으니까.

     이야기가 조금 다른 곳으로 샜는데, 다른 배포판을 사용한다 하더라도 크게 문제될 것은 없다. 그들이 일부러 느리게 동작하도록

    만드는 게 아닌 이상, Gentoo를 사용하여 할 수 있는 최적화를 다 한다 하더라도 실 사용시의 체감성능은 큰 차이가 나지 않는다.

    빠른 시스템에 대한 환상을 갖고 있다면, Gentoo를 연구하느라 많은 시간을 소비하느니 돈을 투자해서 더 나은 하드웨어를 갖추는

    것이 낫다.




 깊이 따지고 들자면 더 많은 것을 이야기해야 하겠지만, 여기서는 앞에서 말한 "두통을 유발할 수 있는 요소"들에 대해 기초적인

사항만 짚어볼까 한다.


 먼저, "컴파일러 플래그"로 언급한 CFLAGS나 CXXFLAGS 등은 컴파일러에게 "이런 옵션을 사용해서 컴파일하라"라고 지시해주는 변수다.

이것은 단순히 최적화만을 위해 있는 것이 아니라, 최적화 옵션을 포함하여 컴파일러가 지원하는 다양한 옵션을 줄 수 있다. 당연히 

디버그가 용이하도록 컴파일할 수도 있다. 여기에서 두통을 유발할 소지가 많지는 않지만, 이곳저곳에서 주워들은 최적화 옵션에 관한

지식을 믿고 이것저것 집어넣다가는 낭패를 당할 수 있다. 대표적인 경우로 SIMD 확장 명령어 세트에 관한 옵션들이 있는데, 넣으면

빨라진다고 무심코 넣어대다간 멀쩡하게 컴파일은 되는데 부팅이 실패하는 사태가 발생한다. 이 옵션들을 넣을 때는 자신이 사용하고

있는 CPU가 해당 명령어 세트를 지원하는지 반드시 확인할 필요가 있다. 이외에도 생각보다 여러 곳에 정신을 피곤하게 하는 함정들이

파여 있지만, 대개는 욕심을 포기하면 해결된다. 골치가 아프다면, 기본값을 사용하라.


 다음으로, 지금도 수많은 사용자들을 혼란의 늪에 빠뜨리고 있을 USE 플래그에 관한 이야기다. 이것은 기본적으로 사용자의 요구를

패키지 관리 시스템에 알려주는 역할을 한다. 예를 들어 내가 X 서버를 사용하고 싶을 때 "X"라는 플래그를 설정하면, X 서버에 포함된 기능을 필요로 하거나 X 서버 존재시 추가적인 기능을 지원하는 패키지들을 컴파일할 때 자동적으로 그에 관한 설정을 해주는 것이다.

물론 - 기호를 앞에 넣어서 특정 기능을 명시적으로 빼는 것도 가능하다. 어떻게 보면 굉장히 편리한 기능이라고도 할 수 있는데,

이것에 관한 가장 큰 맹점은 circular dependency, 즉 "꼬리에 꼬리를 무는" 의존성 문제이다.


 이해를 돕기 위해 설명을 좀 하자면, 이런 식의 의존성에 관한 아주 보기 쉬운 예로 컴파일러 자체를 들 수 있다. DOS 시절과 달리

리눅스에서 사용하는 C 컴파일러(gcc)는 표준 C 라이브러리를 포함하지 않기 때문에, 커널 같은 특수한 소프트웨어가 아닌 일반적인

프로그램을 컴파일하기 위해서는 C 라이브러리(glibc)가 필요하다. 당연히 gcc 자체도 리눅스라는 운영체제 아래에서 작동하는 일종의

프로그램이기 때문에 이를 만들기 위해서는 glibc가 필요하다. 문제는 이 C 라이브러리 자체가 C로 작성되어 있는 데서 발생한다.

결국 glibc를 만들기 위해서는 gcc가 필요한데, gcc를 만들기 위해서는 glibc가 필요한 상황이 되는 것이다. native 환경에서는 gcc와

glibc가 이미 둘 다 존재하기 때문에 큰 문제가 되지 않는다. 그런데, 시작 시점에서 이 둘 모두가 없는 상황1에는 상당히 골치아픈

문제가 된다.

 이를 해결하는 방법은 설령 완전한 형태로 동작하지 못하게 되더라도 어느 한 패키지가 이런 순환고리를 끊을 수 있는 기능을

제공하는 방법밖에 없다. 위의 예에서는 gcc가 glibc 대신 newlib라는 다른 표준 C 라이브러리를 사용하게 함으로써 해결할 수 있다.

물론, newlib는 범용으로 사용하라고 만들어진 게 아니기 때문에 glibc에 포함된 수많은 확장 기능들을 사용하는 프로그램에 물려서

사용하기는 힘들다. 요는 이를 사용함으로써 glibc를 컴파일할 수 있는 gcc를 만들고, 이를 사용하여 glibc를 컴파일한 다음, 이를

사용하는 gcc를 다시 컴파일한다는 것이다.


 이런 경우를 목격하는 아주 쉬운 방법 중 하나는 USE="gpm" ROOT="/mnt/GENTOO" emerge -e ncurses를 실행해보는 것이다. 여기에서

ROOT 변수는 패키지가 설치될 경로를 지정해주며, 이를 사용하면 해당 경로가 /인 것처럼 취급하여 패키지를 설치해준다. 이는 빈

경로의 예시로 사용한 것으로, 꼭 /mnt/GENTOO를 사용할 필요는 없다. 예제에서 gpm이라는 USE 플래그를 설정해준 것을 볼 수 있는데,

이는 gpm2이라는 패키지에 포함된 기능을 활용하겠다는 의미이다. 이렇게 설정하면, 패키지 설치 프로그램은 gpm에 든 기능을

활용하는 ncurses 코드를 컴파일하기 위해 gpm 패키지를 찾게 된다. 당연히 ROOT를 내용물이 없는 빈 경로로 지정해줬기 때문에 그런

패키지는 없다. 이 문제를 해결하기 위해 gpm을 먼저 설치하기 위한 준비를 하게 되는데, 문제는 이 gpm이라는 녀석이 기본적으로

ncurses 라이브러리를 사용하게 되어 있다는 것이다. 이 라이브러리 또한 당연히 ROOT 경로 안에 없기 때문에, 결과적으로는 ncurses를

컴파일하기 위해 ncurses가 필요한 묘한 상황에 빠지게 된다. 이렇게 되면 당연히 오류를 내뱉고 설치과정이 중지된다. 다행히도 이

경우에는 gpm이라는 USE 플래그를 사용하지 않도록 설정해보라고 친절하게 안내해준다. 이럴 때 올바르게 설치하는 방법은 일단 gpm

플래그 없이 ncurses를 설치해놓고 gpm을 설치한 다음, gpm 플래그를 사용하여 ncurses를 다시 설치하는 것이다.


 위에서 예시로 든 경우는 매우 간단한 경우로, 실제 상황에서는 호환성 등을 이유로 설정을 제공하기는 하지만 기본적으로 사용하지

않도록 masking을 해둔 패키지 등으로 인해 훨씬 복잡한 경우를 보게 된다. 어떤 패키지를 쓰고자 하는데 이걸 쓰려면 특정 버전의

다른 패키지가 필요하고, 하필 그 버전의 그 패키지가 기존에 설치해둔 또다른 패키지와 충돌을 일으키기 때문에 설치할 수 없다...

라는 식이다. 이런 경우에는 단순히 USE 플래그를 조작하는 걸로는 해결되지 않고, 최악의 경우에는 시스템 전체를 새로 설계해야 할

수도 있다.


 패키지들의 버전이 고정되어 있는 다른 배포판들은 이미 그런 류의 호환성을 전부 따져서 개별 패키지의 버전을 선택하기 때문에,

이런 사태는 어지간하면 발생하지 않는다. Gentoo라는 배포판을 사용하기 위해서는 그 위에서 사용하고자 하는 프로그램의 종류에

따라 수많은 실험과 고난을 각오해야 할 수도 있다. 그리고 어지간히 특이한 취향을 갖고 있는 것이 아니라면 그 고난을 이겨내고 얻을

수 있는 결과가 다른 배포판을 사용하는 것에 비해 크지 않을 가능성이 상당히 높다. 그럼에도 불구하고 Gentoo를 사용해야겠다면

말리지는 않겠다. 선택은 전적으로 사용자의 몫이며, 여기서는 장점(실상 이 글에 나온 것 중에는 별로 없지만)과 단점, 기타 알고

있으면 좋은 점들을 설명하였을 뿐이다.


 이쯤해서 글을 마칠까 한다. 틀린 부분에 대한 지적은 환영하며, 이 글이 Gentoo라는 리눅스 배포판을 선택하는 데 있어서 하나의

참고사항이 될 수 있기를 바란다.

각주 1

대표적으로 다른 architecture에서 사용할 프로그램을 만드는 과정인 cross-compile시

각주 2

General Purpose Mouse, 콘솔에서의 마우스 지원

  1. 대표적으로 다른 architecture에서 사용할 프로그램을 만드는 과정인 cross-compile시 [본문으로]
  2. General Purpose Mouse, 콘솔에서의 마우스 지원 [본문으로]