젠투는 ‘컴파일 덕후용 배포판’이 아니라 통제권을 주는 리눅스다

젠투는 ‘컴파일해서 빠른 배포판’이라는 이미지에서 벗어나고 싶어함

• 글쓴이는 젠투(Gentoo)를 “성능에 미친 사람들이 쓰는 리눅스”로 보는 시선이 너무 낡았다고 말함

  • 젠투가 컴파일 중심인 건 맞음
  • 하지만 요즘 CPU는 빨라졌고, 컴파일러 최적화도 좋아졌고, 우분투 같은 일반 배포판도 꽤 공격적으로 최적화함
  • 그래서 -O9999 같은 식으로 성능을 짜내는 게 젠투의 본질이라고 보긴 어렵다는 얘기

• 젠투의 진짜 포인트는 성능보다 “내 시스템을 내가 정한다”에 가까움

  • 패키지를 어떤 기능으로 빌드할지 고를 수 있음
  • 특정 라이브러리 버전을 유지하거나, 다른 구현체를 써볼 수도 있음
  • 필요하면 패치를 직접 얹거나 빌드 과정을 조정할 수 있음

독립성과 보안 쪽 철학이 꽤 강함

• 젠투 뒤에는 회사도, 비즈니스 모델도 없음

  • 대부분 자원봉사자가 운영함
  • 일부 인프라는 기부받고, 일부는 후원금으로 유지함
  • 특정 후원자 하나가 프로젝트를 인질로 잡을 수 없게 하려는 방향을 유지함

• 재정 거버넌스 리스크를 줄이기 위해 젠투 재단(Gentoo Foundation)을 정리하고 SPI 쪽으로 옮기는 중이라고 함

  • 단일 재단이나 재정 구조가 병목이 되는 걸 피하려는 선택
  • “한 바구니에 계란을 다 담지 않는다”는 표현이 딱 맞는 운영 철학

• 보안도 꽤 보수적으로 가져감

  • 전담 보안팀이 취약점을 추적하고 사용자에게 알림
  • 업스트림보다 먼저 패치를 백포트하는 경우도 있음
  • 배포 채널과 미러는 자체 인프라와 OpenPGP로 보호함
  • Codeberg와 GitHub는 미러·기여 채널로 쓰지만, 젠투 자체가 거기에 종속되지는 않게 설계함

• 품질 정책도 강함

  • 번들된 의존성은 최대한 거부
  • 정적 링크도 선호하지 않음
  • 고정된 의존성 핀도 가능하면 풀려고 함
  • 오래된 의존성을 품은 소프트웨어가 공급망 리스크가 되는 걸 막으려는 쪽

젠투는 대규모 언어 모델 코드 기여를 이미 금지함

• 젠투는 2년 전에 대규모 언어 모델(LLM) 기여를 금지했고, 글쓴이는 “후회하지 않는다”고 말함

  • 기다려보자는 접근 대신 초기에 선을 그었다는 설명
  • 100% 오염된 코드가 안 들어왔다고 보장할 수는 없지만, 최대한 경계하고 있다고 함
  • 핵심은 코드 품질만이 아니라 커뮤니티 내부 신뢰라는 관점

• 그렇다고 젠투가 LLM으로 만들어진 모든 소프트웨어를 배포판에서 막을 수 있는 건 아님

  • 최신이고 안전한 소프트웨어를 제공해야 하는 책임도 있기 때문
  • 다만 “copywashed chardet”이나 “vibe-coded cryptography software”처럼 특히 위험해 보이는 사례는 최대한 막으려 한다고 함

안정성은 의외로 젠투 사용자들이 가장 많이 칭찬하는 지점임

• 젠투는 시작이 쉽진 않지만, 세팅이 끝난 뒤에는 놀랄 만큼 안정적이라고 주장함

  • 문제가 생겨도 보통 시스템을 재설치하지 않고 고칠 수 있음
  • 패키지 트리가 특정 패키지의 단일 버전에만 묶이지 않아서 다운그레이드 여지가 있음
  • 이미 트리에서 사라진 버전도 비교적 복원하기 쉽다고 함

• 젠투는 롤링 릴리스(rolling release)이지만, 무조건 최신만 강요하지 않음

  • 최신 패키지를 빨리 받을 수도 있음
  • 안정화된 패키지만 쓸 수도 있음
  • 그 중간 어디쯤으로 커스터마이즈하는 것도 가능함

• 한 사용자는 ACCEPT_KEYWORDS="~amd64", LLVM 프로파일, mold 링커, 전체 LTO까지 켜고도 다른 데스크톱 리눅스보다 안정적이었다고 말함

  • 꽤 실험적인 구성인데도 시스템이 완전히 깨진 적은 없었다는 사례
  • 젠투 개발자들이 다양한 조합에서 안정성을 맞추는 데 들이는 노력이 크다는 얘기

유연성은 ‘선택권’이라는 말보다 더 구체적임

• 젠투의 소스 우선(source-first) 모델은 사용자가 패키지 기능을 직접 조절하게 해줌

  • 예를 들어 RSS 리더나 메일 클라이언트를 빌드할 때 필요 없는 웹브라우저 컴포넌트를 뺄 수 있음
  • 이러면 성능보다 공격면 감소가 더 현실적인 이득이 됨
  • 특정 라이브러리 버전을 유지하거나, 더 새 버전으로 올리거나, 다른 구현체를 시도할 수도 있음

• 다만 젠투가 무조건 “모든 선택지를 영원히 제공한다”는 뜻은 아님

  • OpenRC 대 systemd, glibc 대 musl처럼 유지 가능한 선택지는 제공함
  • 하지만 LibreSSL 대 OpenSSL, libav 대 ffmpeg처럼 유지 비용이 너무 큰 선택지는 포기한 사례도 있음
  • 선택지는 누군가 실제로 유지할 때만 의미 있다는 현실적인 선을 긋고 있음

• 중요한 건 대부분의 선택이 옵트인이라는 점임

  • 기본값만 써도 좋은 경험을 주려 함
  • 관심 있는 부분만 커스터마이즈하고 나머지는 기본값에 맡길 수 있음
  • 한 사용자는 젠투를 “조립 키트보다 레고에 가깝다”고 표현함

sequenceDiagram
    participant 사용자
    participant 포티지
    participant 패키지트리
    participant 업스트림
    participant 시스템
    사용자->>포티지: 유즈 플래그와 버전 정책 설정
    포티지->>패키지트리: 가능한 버전과 의존성 확인
    포티지->>업스트림: 소스와 패치 기준 확인
    포티지->>시스템: 선택한 기능으로 빌드·설치
    사용자->>시스템: 필요하면 다운그레이드나 패치 적용

오래된 하드웨어와 개발자 경험도 꽤 큰 축임

• 젠투는 소스 빌드만 고집하는 배포판처럼 보이지만, 바이너리 패키지 지원도 확장하고 있음

  • 여러 구성의 같은 패키지를 빌드할 수 있음
  • 공식 바이너리 패키지를 쓰거나, 자기만의 바이너리 패키지를 만들어 쓸 수 있음
  • 필요하면 바이너리와 소스 빌드를 섞는 것도 가능함

• 지속가능성 관점에서는 오래된 하드웨어 지원을 중요하게 봄

  • Rust나 V8이 지원하지 않는 하드웨어에서도 가능한 한 쓸 수 있는 시스템을 제공하려 함
  • 상업 벤더가 수익성이 없다는 이유로 버린 장비를 바로 폐기하지 않아도 된다는 논리

• 개발자 입장에서는 툴체인이 자연스럽게 갖춰진다는 장점이 있음

  • 런타임 패키지와 개발 패키지를 과하게 쪼개는 방식이 젠투에서는 덜 의미 있음
  • 소스에서 빌드하니 개발 환경과 빌드 환경이 더 가깝게 붙어 있음
  • 여러 Python 버전을 동시에 지원하고, 빌드 중 테스트 스위트를 쉽게 켤 수 있음

• 젠투는 업스트림과도 적극적으로 협업하려고 함

  • 패키지를 대충 패치해서 배포판 안에서만 통과시키기보다, 업스트림에 버그를 보고하고 고치려 함
  • Python 생태계 같은 곳에서 젠투 개발자들의 호환성·크래시 수정 기여가 꽤 중요하다는 외부 평가도 있음

결국 젠투는 사용자를 ‘어른’으로 대한다는 얘기임

• 글의 결론은 젠투가 사용자를 존중한다는 것임

  • 시스템을 어떻게 쓸지 과하게 지시하지 않음
  • 텍스트 파일을 직접 보고 고칠 수 있게 둠
  • su로 권한을 얻으면 사용자가 시킨 일을 시스템이 수행함

• 젠투 설치 과정 자체가 “마법은 없다”는 감각을 준다는 사용자 의견도 나옴

  • 시스템이 갑자기 부팅되지 않아도 어디서부터 봐야 할지 감이 생김
  • 다른 배포판의 “오류가 발생했습니다”보다 디버깅 출발점이 명확하다는 얘기

• 텔레메트리도 기본적으로 좋아하지 않음

  • 젠투가 어떻게 쓰이는지 텔레메트리로 수집하지 못하는 걸 농담처럼 말함
  • 대신 버그 리포트를 기다린다고 함
  • 패키지에서 텔레메트리를 발견하면 기본적으로 제거하고, 필요하면 유즈 플래그로 되살릴 수 있게 하려 함

기술 맥락

• 젠투의 핵심 선택은 “바이너리를 받아 쓰는 편의성”보다 “소스에서 빌드하며 구성을 통제하는 능력”에 있어요. 이게 귀찮아 보이지만, 어떤 기능을 넣고 뺄지 정할 수 있어서 보안과 유지보수 측면에서 의미가 생겨요.

• Portage와 USE flags가 중요한 이유는 선택을 일회성 실험으로 끝내지 않기 때문이에요. 사용자가 특정 기능을 끄거나 다른 라이브러리를 고르면, 패키지 관리자가 그 상태를 계속 추적하고 업데이트까지 이어가요. 그냥 직접 컴파일하고 끝나는 방식과 차이가 여기서 나요.

• 젠투가 번들 의존성, 정적 링크, 의존성 핀을 싫어하는 건 배포판 전체의 보안 업데이트 흐름 때문이에요. 라이브러리가 패키지 안에 숨어 있으면 취약점이 나왔을 때 한 곳만 고쳐서는 해결이 안 되거든요. 그래서 업스트림이 편하다고 선택한 방식과 배포판 유지보수 관점이 충돌할 때가 있어요.

• LLM 기여 금지도 같은 맥락에서 볼 수 있어요. 배포판은 수많은 사용자의 신뢰 기반 위에서 돌아가니까, 코드가 그럴듯하게 컴파일되는 것보다 누가 책임지고 이해할 수 있는지가 더 중요해요. 젠투는 여기서 자동 생성 코드의 생산성보다 검증 가능성을 택한 셈이에요.

• 롤링 릴리스인데도 안정성을 강조할 수 있는 건 버전 선택과 다운그레이드 여지가 남아 있기 때문이에요. 최신 패키지를 빨리 받을 수 있지만, 문제가 생겼을 때 이전 조합으로 돌아가거나 특정 패키지를 고정하는 식의 대응이 가능해요.