구글과 이갈리아의 Chromium 개발 방식 비교

Comparing Chromium Development at Google and Igalia

lwn.net ▲ 87 댓글 27 signa11

요약

구글에서 이갈리아로 옮긴 개발자가 두 회사의 Chromium 개발 방식을 비교했습니다.

Chromium 개발자 섀런 양이 FOSSY 2026에서 발표한 내용을 LWN이 정리했습니다. 양은 구글에서 6년 동안 Chrome을 개발한 뒤, 직원이 소유한 컨설팅 회사 이갈리아로 옮겼습니다.

왜 중요한가

  • 같은 저장소에서 일해도 구글 밖 개발자는 빌드 자원과 정보 접근에서 불리하다는 점이 드러났습니다.
  • 브라우저를 만들지 않는 회사 가운데 Chromium 기여가 가장 많은 곳이 관리자 없이 운영된다는 사례입니다.

핵심 내용

  • 구글은 직원이 약 18만 명이고, 이갈리아는 약 180명입니다.
  • 이갈리아는 어느 나라에 살든 모든 직원이 같은 급여를 받고, 승진 제도도 없습니다.
  • 이갈리아에는 관리자가 없고, 프로젝트 선정과 채용 인원, 휴가 정책을 직원 투표로 정합니다.
  • 구글의 프로젝트는 관리자의 우선순위와 승진에 묶여 있었고, 이갈리아에서는 기술 부채(미뤄 둔 코드 문제) 정리가 많습니다.
  • 외부 개발자는 빠른 빌드를 따로 신청해야 하고, 공개돼야 할 일부 버그는 구글 직원에게만 보입니다.

HN 반응

  • Gentoo의 Chromium 빌드 포기 소식을 두고, 선택 기능을 시험하지 않는 구글 탓이라는 쪽과 Gentoo의 선택이라는 쪽이 맞섰습니다.
  • 이갈리아의 직원 소유 구조에 청중이 박수를 쳤다는 대목에는, 구글 지분도 상당 부분 펀드를 통해 개인이 갖고 있다는 반론과 외부 투자자는 이익만 좇는다는 재반론이 오갔습니다.

댓글

24개 표시 · 전체 27개
  1. rmunn HN

    https://lwn.net/Articles/1097760/ 도 눈여겨볼 만합니다. Gentoo는 Chromium을 소스에서 빌드하는 일을 포기했습니다. 업스트림이 "'선택 사항'이라고 주장하는 기능을 꺼 놓고는 빌드를 전혀 테스트하지 않기" 때문이고, "Chromium의 경우 (업스트림의 만성적인 방치 속에서) 모든 토글 스위치가 제대로 동작하게 유지하는 일은 거의 넘을 수 없는 거대한 과제"라는 겁니다. 한 메인테이너는 노트북으로 Chromium을 컴파일하는 데만 15~16시간이 걸려서 Gentoo 빌드의 USE 플래그 조합을 전부 테스트하는 건 도저히 불가능하다고 했습니다. (아마 한 번 빌드하는 데 그렇다는 얘기일 텐데, 가능한 모든 플래그 조합을 테스트하려면 이걸 2^N번 반복해야 합니다.)

    LWN 기사에 훨씬 많은 내용이 있어서, 전부 인용하지는 않겠습니다.

  2. msdz HN

    Helium [0] 프로젝트는 이 문제를 어떻게 풀고 있을지 궁금하네요. 거기도 나름대로 주관이 뚜렷한 Chromium 기반으로 작업하잖아요.

    [0] https://helium.computer

  3. rmunn HN

    Helium 사이트는 대충 훑어보기만 했지만, 보아하니 그 선택 기능들의 상태(켜짐/꺼짐)를 전부 하나로 정해 놓고 --enable-foo / --enable-bar 플래그 조합을 하나(많아야 두세 개) 정도만 테스트하면 되는 것 같습니다. 반면 Gentoo는 사용자가 원하는 조합을 마음대로 고르게 해 주려 했는데, 업스트림이 도와주지 않으니 잘 안 풀린 거죠.

  4. Mic92 HN

    음, 그럼 애초에 플래그를 그렇게 많이 두지 않으면 되는 거 아닌가요?

  5. rmunn HN

    "Gentoo가 Gentoo이기를 그만두면 되겠네"라는 말씀이시네요. Gentoo의 핵심은 소스에서 빌드하는 패키지를 마음대로 커스터마이징하는 데 있습니다. (기억에 의존하는 얘기고, 써 본 지 10년이 넘어서 틀릴 수도 있습니다.) 소프트웨어의 선택 기능 가운데 configure의 --with-foo 같은 옵션으로 조절되는 것은 모두 Gentoo에서 USE 플래그가 됩니다. --with-foo, --with-bar, --with-baz, --with-quux가 있는 패키지는 USE 플래그가 네 개고, 켜고 끄는 조합은 16가지가 되죠. 그리고 Gentoo 메인테이너 팀은 명백히 서로 충돌하는 조합을 빼고는 그 모든 조합이 동작하도록 확인하려 애씁니다.

    그러니 플래그를 이렇게 많이 둔 건 Gentoo의 결정이 아니라 업스트림의 결정입니다. 업스트림이 "좋아, 이 '선택' 기능은 이제 더는 선택 사항이 아니야"라고 인정해 준다면 Gentoo 메인테이너들은 쌍수를 들고 환영할 겁니다. 하지만 업스트림은 그러지 않고 계속 수십 개의 플래그를 두고 있고, Gentoo는 (자기네 빌드 철학 때문에) 그걸 충실히 그대로 가져와 테스트하려다가 감당할 수 없는 일이 된 겁니다.

  6. shevy-java HN

    그러니 플래그를 이렇게 많이 둔 건 Gentoo의 결정이 아니라 업스트림의 결정입니다.

    그건 좀 이상한 말인데요. 모든 기능을 테스트하겠다고 한 건 Gentoo의 결정이라고 봅니다.

    그건 일단 접어 두더라도, 리눅스 커널에는 이게 어떻게 적용됩니까? 커널 설정 파일에는 옵션이 엄청나게 많잖아요. Gentoo가 그걸 전부 USE 플래그로 지원하나요? 안 한다면 왜죠? 그 구분은 제가 보기엔 완전히 자의적입니다.

  7. rmunn HN

    그럼 사용자에게 제공하는 옵션을 테스트하지 말아야 한다는 말씀입니까?

    Gentoo에게는 기본적으로 선택지가 세 가지 있습니다. 제가 놓친 네 번째가 있으면 알려 주세요.

    1. 업스트림의 선택 기능을 모두 USE 플래그로 만들고 테스트한다. 그러면 2^N가지 조합을 전부 테스트해야 합니다.

    2. 업스트림의 선택 기능을 모두 USE 플래그로 만들되 테스트는 하지 않는다. 그러면 사용자는 검증되지 않은 조합을 쓰게 될 수 있고, 그중 일부는 전에 버그가 있는 것으로 드러난 적도 있습니다.

    3. 업스트림의 선택 기능을 모두 USE 플래그로 만드는 걸 그만둔다. 그러면 이 패키지에서는 Gentoo의 차별점을 포기하는 셈입니다.

    아, 네 번째 선택지가 있긴 하네요.

    1. Chromium 패키지 자체를 아예 만들지 않는다. 결국 Gentoo가 선택한 길이 이겁니다.
  8. debugnik HN

    Gentoo가 하지 말아야 할 일이 뭔지는 말씀드릴 수 있습니다. N을 정하는 권한도 없으면서 스스로 2^N가지 옵션 조합을 지원하고 테스트하는 사명을 떠안아 놓고는 그걸 업스트림 탓으로 돌리는 겁니다.

    Gentoo는 제공하는 옵션을 제한할 수도 있고, 지원하는 조합을 제한할 수도 있고, 2^N의 순수성을 꼭 지키겠다면 소프트웨어를 포크하거나 접을 수도 있습니다(결국 그렇게 했고요). 하지만 그건 Gentoo의 사명이지 업스트림의 사명이 아닙니다. 업스트림은 그냥 있는 그대로 소프트웨어를 공짜로 내주고 있을 뿐입니다.

  9. rmunn HN

    업스트림은 그냥 있는 그대로 소프트웨어를 공짜로 내주고 있을 뿐입니다.

    "버그 수정은 당연히 해 줘야지" 하는 태도가 소프트웨어 메인테이너 입장에서 짜증스러운 건 분명하고, (최종 사용자로서) 오픈소스 프로젝트의 99%에 대해서는 뭔가를 당연히 요구할 권리가 없습니다. 하지만 지금 얘기하는 건 Chromium입니다. 전체 웹 브라우징의 75~95%를 움직이는 브라우저 엔진이죠(정확한 수치는 잡기 어렵지만 어쨌든 거대합니다). Chromium 메인테이너들에게 1) 가지고 있는 선택 플래그의 모든 조합을 테스트하거나, 2) 그중 일부 플래그는 더는 선택 사항이 아니라고 선언하라고 요구하는 건 지나친 일이 아닙니다. 다시 말해, 프로답게 행동하라는 겁니다.

    (저는 Chromium을 쓰지 않습니다. 탭을 많이 여는 편인데 Chromium이 RAM을 마구 먹는 것 같아서 몇 년 전에 Firefox로 갈아탔고, 적어도 그때는 Firefox가 RAM 관리를 조금 더 잘하는 것 같았습니다(최근에는 확인해 보지 않았습니다). 그러니 "Chromium 팀이 나한테 뭘 해 줘야 한다"는 얘기가 아니라, Gentoo 메인테이너들이 전하는 Chromium 팀의 행태, 정확히는 하지 않는 일에 실망해서 고개를 젓는 겁니다. 말씀드렸듯이 리눅스 커널이나 Chromium처럼 너무 널리 쓰여서 메인테이너에게 어느 정도의 프로 의식을 기대해야 하는 프로젝트가 일부 있습니다. 오픈소스 프로젝트의 99%에는 그런 당연하다는 태도가 어울리지 않는다는 데 동의합니다. 하지만 Chromium은 제 생각에 그 1%의 예외에 속합니다.)

  10. debugnik HN

    (저도 Firefox를 씁니다. 안드로이드에서도요.)

    저는 다운스트림 메인테이너가 스스로로부터 보호받아야 한다며 업스트림이 제공하는 옵션을 제한해야 한다는 생각이 마음에 들지 않을 뿐입니다.

    다운스트림은 최종 사용자가 아니고, 최종 사용자는 테스트를 거친 빌드만 받아야 한다는 데는 동의합니다. 하지만 다운스트림도 프로입니다. 어떤 구성으로 빌드할지 직접 고를 수 있고, 테스트가 얼마나 더 필요한지 판단할 수 있으며, 지원할 여력이 없는 구성은 지원 대상에서 뺄 수 있다고 믿어도 됩니다.

    또 프로 프로젝트라면 다른 프로에게 검증되지 않은 설정 조합을 제공하지 않는다는 생각 때문에 사람들이 리눅스는 어떠냐고 되묻는 겁니다. 잠깐 찾아보니 Kconfig 옵션이 약 19,000개라고 하네요1.

  11. uniq7 HN

    리눅스 커널에서는 어떤 선택지를 택했나요?

  12. csande17 HN

    전통적으로 Gentoo 패키지 매니저는 리눅스 커널을 아예 컴파일하지 않았습니다. 소스 코드를 하드 드라이브의 폴더에 풀어 주기만 하고, 설정과 빌드와 설치는 사용자가 직접 해야 했습니다. 특정 소프트웨어가 동작하게 하려면 make menuconfig 메뉴에서 어떤 옵션을 설정해야 하는지 Gentoo 위키 페이지에 나열되어 있었죠.

    요즘은 커널을 대신 빌드해 주는 패키지가 있지만, USE 플래그를 쓰지 않고 "savedconfig" 시스템으로 커널 설정 파일 전체를 저장하고 불러오는 방식입니다. 그래서 뭔가를 바꾸려면 여전히 직접 설정 메뉴를 뒤져야 합니다.

    제 경험으로 리눅스는 옵션 사이의 의존성을 정확히 선언하고, 옵션을 꺼도 잘 동작합니다. 그래서 Chromium처럼 문제가 크지는 않습니다.

  13. shevy-java HN

    공평하게 말하자면, 그건 Gentoo의 잘못입니다. 가능한 한 커스터마이징할 수 있게 하고 싶어 하는 건 좋지만, 모든 플래그 조합을 지원한다면 전부 테스트하든가 테스트를 포기하든가 둘 중 하나일 수밖에 없죠. 리눅스 커널에 대해서는 이런 얘기가 없는 것도 좀 어색하네요. 애초에 USE 플래그가 그렇게 제한적입니까?

  14. rmunn HN

    리눅스 커널은 설정 조합을 실제로 테스트한다고 봅니다. 불만은 Chromium이 선택 사항이라고 주장하는 기능을 꺼 놓고는 테스트하지 않는다는 겁니다. 그러다 그런 기능 중 하나가 주장만큼 선택 사항이 아니라는 게 드러나면, 그걸 알아내는 부담은 Gentoo 메인테이너가 집니다(테스트하지 않으면 사용자가 알게 되고요).

    Gentoo가 리눅스 커널을 USE 플래그로 어떻게 처리하는지는 저도 모릅니다. 마지막으로 Gentoo를 써 본 게 10년도 넘었고, 아무도 정말 궁금해하지 않을 것 같아서 찾아볼 시간을 쓰고 싶지 않습니다. (누군가 궁금해서 찾아본다면, 저도 딱 그만큼은 궁금하니 알아낸 걸 알려 주세요.)

  15. nh2 HN

    리눅스 커널은 설정 조합을 실제로 테스트한다고 봅니다.

    그렇게 보시는 근거가 뭔가요?

    제가 아는 한 커널에는 공식 CI가 없습니다. 사람들이 내키는 대로 테스트합니다. 어떤 사람이나 회사는 CI 이니셔티브를 만들고, 어떤 쪽은 쓰지 않습니다.

    https://lwn.net/Articles/972713/

    게다가 커널에는 Kconfig 옵션이 10,000개가 넘습니다. 2^64도 엄청 큰 수인데 2^10000은 그보다 훨씬 더 크다고 누가 말해 주더군요.

  16. evgpbfhnr HN

    모든 설정 조합이 유효한 건 아니고(의존성 때문에), 유효한 조합 중에서도 대부분은 서로 독립적이라서(예: 서로 관계없는 FOO/BAR라면 CONFIG_FOO=y/CONFIG_BAR=y 빌드와 CONFIG_FOO=n/CONFIG_BAR=n 빌드 두 개로 경우의 수를 100% 다 덮습니다) 그렇게 나쁘지 않습니다.

    그리고 사람들이 실제로 빌드를 많이 해 봅니다. 무작위 설정을 만들어 주는 근사한 "randconfig" 모드도 쓰고요. 그래서 특정 설정이 런타임에 동작하지 않을 수는 있어도, 빌드 자체가 실패하는 일은 (적어도 릴리스에서는) 사실 거의 없습니다.

  17. jazzypants HN

    Chromium 팀이 그 플래그들은 선택 사항이라고 한 말을 지키게 하려는 것뿐인데, 그게 어떻게 Gentoo의 잘못입니까? 정말 선택 사항이라면 어떻게 조합하든 문제가 없어야죠.

  18. mg794613 HN

    제대로 동작하지도 않는 선택 사항이 어떻게 Gentoo 잘못이에요??

  19. Charly_HW HN

    이제 리버스 엔지니어링이 가능한데, 더 나은 브라우저 대안이 나오기까지 얼마나 걸릴까요?

  20. epolanski HN

    Google은 기관 투자자가 소유하고 Igalia는 직원이 소유하는데, 청중이 여기에 박수를 쳤다.

    Google 지분의 63~68%는 가계가 직접 또는 펀드를 통해 보유하고 있습니다.

    회사가 비상장이고 직원 소유인 쪽이 왜 더 공정한 건지 모르겠습니다. 원하는 사람은 누구나 소유할 수 있는 쪽과 비교해서요.

  21. sfink HN

    개인 투자자, 특히 펀드로 뭉뚱그려진 개인 투자자들은 이익 극대화에 대한 동기만 있고, 이익에 반영되는 범위를 넘어서는 작업의 품질이나 노동자의 삶의 질에 대한 동기는 전혀 없기 때문입니다.

    "원하는 사람은 누구나"가 바로 문제입니다. 아무나 바라는 것과 프로젝트나 일터 환경의 건강 사이에는 아무 상관관계가 없습니다. 이해관계가 걸린 사람이 필요하고, 그것도 올바른 판에 걸려 있어야 합니다.

  22. shevy-java HN

    죄송하지만 사악한 AdChromium 제국을 키워 주는 개발자들에게는 별로 존경심이 안 듭니다. 사람들이 돈을 벌려고 시간을 투자하는 건 이해합니다. 그건 문제 삼지 않습니다. 하지만 결국 chromium 홍보물, 즉 Google 홍보물을 읽고 싶지는 않습니다. 그 회사는 수십 년 전에 이미 쪼개졌어야 했습니다.

  23. wbazant HN

    읽어 봤는데 좋은 글이었고, Chrome이나 Google을 딱히 홍보하지 않아요.

  24. throwaway2037 HN

    솔직히 이분이 돈을 얼마나 포기했는지 궁금하네요. 저라면 "경제적으로 완전히 자유로워진" 뒤에나 그런 일을 할 수 있을 것 같습니다.

Hacker News에서 보기 ↗