--- title: "젠투는 ‘컴파일 덕후용 배포판’이 아니라 통제권을 주는 리눅스다" published: 2026-05-28T21:47:22.000Z canonical: https://jeff.news/article/3484 --- # 젠투는 ‘컴파일 덕후용 배포판’이 아니라 통제권을 주는 리눅스다 젠투 개발자는 젠투가 단순히 모든 걸 컴파일해서 성능을 뽑아내는 배포판이라는 이미지가 틀렸다고 말한다. 핵심은 독립성, 보안, 안정성, 유연성, 개발자 친화성, 그리고 사용자를 어른으로 대하는 철학에 있다. 소스 기반 배포판이라는 특성은 성능보다 선택 가능한 구성, 공격면 축소, 오래된 하드웨어 지원, 업스트림과의 건강한 협업에서 더 큰 의미를 가진다. ## 젠투는 ‘컴파일해서 빠른 배포판’이라는 이미지에서 벗어나고 싶어함 - 글쓴이는 젠투(Gentoo)를 “성능에 미친 사람들이 쓰는 리눅스”로 보는 시선이 너무 낡았다고 말함 - 젠투가 컴파일 중심인 건 맞음 - 하지만 요즘 CPU는 빨라졌고, 컴파일러 최적화도 좋아졌고, 우분투 같은 일반 배포판도 꽤 공격적으로 최적화함 - 그래서 `-O9999` 같은 식으로 성능을 짜내는 게 젠투의 본질이라고 보긴 어렵다는 얘기 - 젠투의 진짜 포인트는 성능보다 “내 시스템을 내가 정한다”에 가까움 - 패키지를 어떤 기능으로 빌드할지 고를 수 있음 - 특정 라이브러리 버전을 유지하거나, 다른 구현체를 써볼 수도 있음 - 필요하면 패치를 직접 얹거나 빌드 과정을 조정할 수 있음 > [!NOTE] > 젠투에서 소스 빌드는 목적이 아니라 수단에 가까움. 성능보다 유연성, 공격면 축소, 디버깅 가능성, 오래된 하드웨어 지원 같은 쪽에서 더 큰 의미가 있음. ## 독립성과 보안 쪽 철학이 꽤 강함 - 젠투 뒤에는 회사도, 비즈니스 모델도 없음 - 대부분 자원봉사자가 운영함 - 일부 인프라는 기부받고, 일부는 후원금으로 유지함 - 특정 후원자 하나가 프로젝트를 인질로 잡을 수 없게 하려는 방향을 유지함 - 재정 거버넌스 리스크를 줄이기 위해 젠투 재단(Gentoo Foundation)을 정리하고 SPI 쪽으로 옮기는 중이라고 함 - 단일 재단이나 재정 구조가 병목이 되는 걸 피하려는 선택 - “한 바구니에 계란을 다 담지 않는다”는 표현이 딱 맞는 운영 철학 - 보안도 꽤 보수적으로 가져감 - 전담 보안팀이 취약점을 추적하고 사용자에게 알림 - 업스트림보다 먼저 패치를 백포트하는 경우도 있음 - 배포 채널과 미러는 자체 인프라와 OpenPGP로 보호함 - Codeberg와 GitHub는 미러·기여 채널로 쓰지만, 젠투 자체가 거기에 종속되지는 않게 설계함 - 품질 정책도 강함 - 번들된 의존성은 최대한 거부 - 정적 링크도 선호하지 않음 - 고정된 의존성 핀도 가능하면 풀려고 함 - 오래된 의존성을 품은 소프트웨어가 공급망 리스크가 되는 걸 막으려는 쪽 ## 젠투는 대규모 언어 모델 코드 기여를 이미 금지함 - 젠투는 2년 전에 대규모 언어 모델(LLM) 기여를 금지했고, 글쓴이는 “후회하지 않는다”고 말함 - 기다려보자는 접근 대신 초기에 선을 그었다는 설명 - 100% 오염된 코드가 안 들어왔다고 보장할 수는 없지만, 최대한 경계하고 있다고 함 - 핵심은 코드 품질만이 아니라 커뮤니티 내부 신뢰라는 관점 - 그렇다고 젠투가 LLM으로 만들어진 모든 소프트웨어를 배포판에서 막을 수 있는 건 아님 - 최신이고 안전한 소프트웨어를 제공해야 하는 책임도 있기 때문 - 다만 “copywashed chardet”이나 “vibe-coded cryptography software”처럼 특히 위험해 보이는 사례는 최대한 막으려 한다고 함 > [!IMPORTANT] > 젠투의 LLM 기여 금지는 단순한 취향 문제가 아니라 배포판 신뢰 모델 문제로 다뤄짐. 누가 쓴 코드인지, 누가 책임질 수 있는지, 유지보수가 가능한지가 핵심임. ## 안정성은 의외로 젠투 사용자들이 가장 많이 칭찬하는 지점임 - 젠투는 시작이 쉽진 않지만, 세팅이 끝난 뒤에는 놀랄 만큼 안정적이라고 주장함 - 문제가 생겨도 보통 시스템을 재설치하지 않고 고칠 수 있음 - 패키지 트리가 특정 패키지의 단일 버전에만 묶이지 않아서 다운그레이드 여지가 있음 - 이미 트리에서 사라진 버전도 비교적 복원하기 쉽다고 함 - 젠투는 롤링 릴리스(rolling release)이지만, 무조건 최신만 강요하지 않음 - 최신 패키지를 빨리 받을 수도 있음 - 안정화된 패키지만 쓸 수도 있음 - 그 중간 어디쯤으로 커스터마이즈하는 것도 가능함 - 한 사용자는 `ACCEPT_KEYWORDS="~amd64"`, LLVM 프로파일, mold 링커, 전체 LTO까지 켜고도 다른 데스크톱 리눅스보다 안정적이었다고 말함 - 꽤 실험적인 구성인데도 시스템이 완전히 깨진 적은 없었다는 사례 - 젠투 개발자들이 다양한 조합에서 안정성을 맞추는 데 들이는 노력이 크다는 얘기 ## 유연성은 ‘선택권’이라는 말보다 더 구체적임 - 젠투의 소스 우선(source-first) 모델은 사용자가 패키지 기능을 직접 조절하게 해줌 - 예를 들어 RSS 리더나 메일 클라이언트를 빌드할 때 필요 없는 웹브라우저 컴포넌트를 뺄 수 있음 - 이러면 성능보다 공격면 감소가 더 현실적인 이득이 됨 - 특정 라이브러리 버전을 유지하거나, 더 새 버전으로 올리거나, 다른 구현체를 시도할 수도 있음 - 다만 젠투가 무조건 “모든 선택지를 영원히 제공한다”는 뜻은 아님 - OpenRC 대 systemd, glibc 대 musl처럼 유지 가능한 선택지는 제공함 - 하지만 LibreSSL 대 OpenSSL, libav 대 ffmpeg처럼 유지 비용이 너무 큰 선택지는 포기한 사례도 있음 - 선택지는 누군가 실제로 유지할 때만 의미 있다는 현실적인 선을 긋고 있음 - 중요한 건 대부분의 선택이 옵트인이라는 점임 - 기본값만 써도 좋은 경험을 주려 함 - 관심 있는 부분만 커스터마이즈하고 나머지는 기본값에 맡길 수 있음 - 한 사용자는 젠투를 “조립 키트보다 레고에 가깝다”고 표현함 ```mermaid sequenceDiagram participant 사용자 participant 포티지 participant 패키지트리 participant 업스트림 participant 시스템 사용자->>포티지: 유즈 플래그와 버전 정책 설정 포티지->>패키지트리: 가능한 버전과 의존성 확인 포티지->>업스트림: 소스와 패치 기준 확인 포티지->>시스템: 선택한 기능으로 빌드·설치 사용자->>시스템: 필요하면 다운그레이드나 패치 적용 ``` ## 오래된 하드웨어와 개발자 경험도 꽤 큰 축임 - 젠투는 소스 빌드만 고집하는 배포판처럼 보이지만, 바이너리 패키지 지원도 확장하고 있음 - 여러 구성의 같은 패키지를 빌드할 수 있음 - 공식 바이너리 패키지를 쓰거나, 자기만의 바이너리 패키지를 만들어 쓸 수 있음 - 필요하면 바이너리와 소스 빌드를 섞는 것도 가능함 - 지속가능성 관점에서는 오래된 하드웨어 지원을 중요하게 봄 - Rust나 V8이 지원하지 않는 하드웨어에서도 가능한 한 쓸 수 있는 시스템을 제공하려 함 - 상업 벤더가 수익성이 없다는 이유로 버린 장비를 바로 폐기하지 않아도 된다는 논리 - 개발자 입장에서는 툴체인이 자연스럽게 갖춰진다는 장점이 있음 - 런타임 패키지와 개발 패키지를 과하게 쪼개는 방식이 젠투에서는 덜 의미 있음 - 소스에서 빌드하니 개발 환경과 빌드 환경이 더 가깝게 붙어 있음 - 여러 Python 버전을 동시에 지원하고, 빌드 중 테스트 스위트를 쉽게 켤 수 있음 - 젠투는 업스트림과도 적극적으로 협업하려고 함 - 패키지를 대충 패치해서 배포판 안에서만 통과시키기보다, 업스트림에 버그를 보고하고 고치려 함 - Python 생태계 같은 곳에서 젠투 개발자들의 호환성·크래시 수정 기여가 꽤 중요하다는 외부 평가도 있음 ## 결국 젠투는 사용자를 ‘어른’으로 대한다는 얘기임 - 글의 결론은 젠투가 사용자를 존중한다는 것임 - 시스템을 어떻게 쓸지 과하게 지시하지 않음 - 텍스트 파일을 직접 보고 고칠 수 있게 둠 - `su`로 권한을 얻으면 사용자가 시킨 일을 시스템이 수행함 - 젠투 설치 과정 자체가 “마법은 없다”는 감각을 준다는 사용자 의견도 나옴 - 시스템이 갑자기 부팅되지 않아도 어디서부터 봐야 할지 감이 생김 - 다른 배포판의 “오류가 발생했습니다”보다 디버깅 출발점이 명확하다는 얘기 - 텔레메트리도 기본적으로 좋아하지 않음 - 젠투가 어떻게 쓰이는지 텔레메트리로 수집하지 못하는 걸 농담처럼 말함 - 대신 버그 리포트를 기다린다고 함 - 패키지에서 텔레메트리를 발견하면 기본적으로 제거하고, 필요하면 유즈 플래그로 되살릴 수 있게 하려 함 --- ## 기술 맥락 - 젠투의 핵심 선택은 “바이너리를 받아 쓰는 편의성”보다 “소스에서 빌드하며 구성을 통제하는 능력”에 있어요. 이게 귀찮아 보이지만, 어떤 기능을 넣고 뺄지 정할 수 있어서 보안과 유지보수 측면에서 의미가 생겨요. - Portage와 USE flags가 중요한 이유는 선택을 일회성 실험으로 끝내지 않기 때문이에요. 사용자가 특정 기능을 끄거나 다른 라이브러리를 고르면, 패키지 관리자가 그 상태를 계속 추적하고 업데이트까지 이어가요. 그냥 직접 컴파일하고 끝나는 방식과 차이가 여기서 나요. - 젠투가 번들 의존성, 정적 링크, 의존성 핀을 싫어하는 건 배포판 전체의 보안 업데이트 흐름 때문이에요. 라이브러리가 패키지 안에 숨어 있으면 취약점이 나왔을 때 한 곳만 고쳐서는 해결이 안 되거든요. 그래서 업스트림이 편하다고 선택한 방식과 배포판 유지보수 관점이 충돌할 때가 있어요. - LLM 기여 금지도 같은 맥락에서 볼 수 있어요. 배포판은 수많은 사용자의 신뢰 기반 위에서 돌아가니까, 코드가 그럴듯하게 컴파일되는 것보다 누가 책임지고 이해할 수 있는지가 더 중요해요. 젠투는 여기서 자동 생성 코드의 생산성보다 검증 가능성을 택한 셈이에요. - 롤링 릴리스인데도 안정성을 강조할 수 있는 건 버전 선택과 다운그레이드 여지가 남아 있기 때문이에요. 최신 패키지를 빨리 받을 수 있지만, 문제가 생겼을 때 이전 조합으로 돌아가거나 특정 패키지를 고정하는 식의 대응이 가능해요. ## 핵심 포인트 - 젠투의 핵심 가치는 성능 튜닝보다 유연성과 통제권에 있다. - 회사나 단일 후원자에 종속되지 않는 독립 프로젝트로 운영된다. - 보안팀, 자체 인프라, 강한 품질 정책으로 공급망 리스크를 줄이려 한다. - 젠투는 2년 전부터 대규모 언어 모델 기여를 금지했다. - 포티지와 유즈 플래그는 패키지 기능·의존성·빌드 방식을 세밀하게 조정하게 해준다. ## 인사이트 요즘 개발 환경은 점점 SaaS, 원격 빌드, 자동 생성 코드 쪽으로 기울고 있는데, 젠투는 정반대로 ‘내 시스템이 왜 이렇게 동작하는지 내가 안다’는 감각을 강조한다. 모든 팀이 젠투를 쓸 필요는 없지만, 배포판이 사용자에게 어떤 통제권을 줄 수 있는지 보여주는 좋은 기준점이다.