Russ Cox, Go 기술 리더 자리에서 물러남

 (groups.google.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Go 프로젝트는 12년 넘게 이어진 Russ Cox 중심 리더십에서 Austin Clements와 Cherry Mui 중심의 새 체제로 전환함
  • 2024년 9월 1일부터 Austin은 Google Go 팀과 전체 Go 프로젝트의 기술 리더를 맡고, Cherry는 컴파일러·런타임·릴리스를 포함한 Go core를 이끔
  • Cox는 장기 단일 리더십이 안정성을 주지만 새 리더가 성장할 공간을 줄일 수 있다고 보고, Python의 2018년 리더십 전환을 긍정적 선례로 봄
  • Cox는 Go를 떠나지 않고 설계 논의, CL 리뷰, 이슈 제출, 일부 표준 라이브러리 작업, GoLab 발표 등 개인 기여자로 남음
  • 앞으로는 Gaby와 Oscar에 더 집중해 Go 이슈 트래커 생산성을 높이고, 오픈소스 유지관리자에게 도움이 되는 방식을 다른 프로젝트로 확산하려 함

Go 리더십 전환

  • 2024년 9월 1일부터 Austin Clements가 Go의 기술 리더를 맡음
    • 대상은 Google의 Go 팀과 전체 Go 프로젝트 모두임
    • Austin은 현재 “Go core”로 불리는 영역의 기술 리더임
  • Cherry Mui는 Go core 영역을 이끄는 역할로 올라섬
    • Go core는 컴파일러 툴체인, 런타임, 릴리스를 포함함
  • Russ Cox는 Go 프로젝트를 떠나지 않지만, 의사결정 중심에서는 한 걸음 물러남

12년 리더십 이후 교체가 필요한 이유

  • Cox에게 기술 리더는 명예직이 아니라 서비스 역할에 가까움
    • 그는 12년 넘게 Go 프로젝트를 이끌며 구성원들이 좋은 작업을 할 조건을 만드는 데 집중해 왔음
  • 큰 프로젝트는 안정적인 리더십의 이점을 얻지만, 어느 시점에는 새 리더의 강점과 신선한 관점도 필요함
  • Cox는 Go가 12년 이상의 단일 리더십을 통해 충분한 안정성을 쌓았다고 판단함
  • BDFL 모델은 개인과 프로젝트 모두에 건강하지 않다고 봄
    • 새 리더를 위한 공간을 만들기 어려움
    • 단일 장애점이 됨
    • 프로젝트가 더 성장할 여지를 줄임
  • Python은 Guido van Rossum이 2018년에 물러나 다른 사람들이 이끌게 되면서 크게 이익을 얻은 사례로 언급됨

Austin Clements와 Cherry Mui에 대한 신뢰

  • Austin은 2014년부터, Cherry는 2016년부터 Google에서 Go 작업을 해왔음
  • Cox는 두 사람의 판단력과 Go 및 Go가 실행되는 시스템에 대한 지식이 뛰어나다고 평가함
  • 일반 설계 질문이나 컴파일러, 링커, 런타임 세부 사항을 더 깊이 이해해야 할 때 Austin과 Cherry에게 의지해 왔음
  • 기존 리더들도 각 영역을 계속 이끎
    • Roland Shoemaker는 Go 보안을 계속 이끎
    • Rob Findley와 Hana Kim은 Go 도구와 IDE 지원을 계속 이끔

Russ Cox가 앞으로 맡을 역할

  • Cox는 의사결정에서 의식적으로 물러나 Austin과 다른 리더들이 앞으로 나설 공간을 만들 예정임
  • Go 안에서는 계속 개인 기여자로 남음
    • Go 설계 논의 참여
    • CL 리뷰
    • 오래된 히스토리 관련 질문 답변
    • 필요할 때 지원
    • 이슈 제출과 CL 작성
    • 몇 가지 잠재적 새 표준 라이브러리 작업
    • 산업 전반에서 Go 옹호
    • 11월 이탈리아 GoLab에서 Go 관련 발표
  • 전환의 세부 사항은 아직 정해지지 않았고, 공개 논의를 위해 메일링 리스트에 공유됨
  • Cox와 Austin은 이번 변화가 Go 프로젝트를 더 강하고 좋게 만드는 것 외에는 큰 사건처럼 보이지 않기를 원함

Gaby와 Oscar로 옮겨가는 초점

  • Cox는 앞으로 Gaby and Oscar에 더 집중할 예정임
  • 목표는 Go 이슈 트래커에서 유용한 기여를 만들어 Go 작업자들이 더 생산적으로 일하도록 돕는 것임
  • Oscar 작업을 통해 오픈소스 유지관리자에게 도움이 되는 방식을 찾고, 다른 프로젝트에서도 채택되기를 기대함
  • Oscar의 상위 목표는 세 가지임
    • 유용한 것을 만들기
    • 새로운 것을 배우기
    • 다른 프로젝트를 위한 길을 그리기
  • 이 목표들은 Go에서 항상 추구해 온 넓은 목표와 이어져 있어, Oscar는 Cox에게 자연스러운 다음 단계로 보임

커뮤니티 반응과 투명성 요청

  • Daniel Martí는 지난 10년간 Go의 큰 변화와 이정표로 modules와 generics를 들며, Cox가 장기적 성공에 핵심 역할을 했다고 평가함
  • 그는 전환 논의와 함께 컴파일러·런타임 관련 투명성을 높이는 방안을 제안함
  • Cherry Mui는 회의록과 오피스아워가 Google의 컴파일러·런타임 팀과 커뮤니티 사이의 투명성과 참여를 높일 좋은 기회라고 답함
    • 다음 오피스아워 일정이 정해지면 메일링 리스트에 업데이트를 올릴 예정임
  • 여러 참가자들은 Cox의 12년 리더십과 Go에 대한 기여에 감사를 표하고, Austin과 Cherry의 새 역할을 축하함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • rsc, 그동안의 모든 작업에 감사함. 지난 12년 동안 Go 개발은 경쟁 상태 검출기, 표준화된 오류 래핑, 모듈, 제네릭, 도구 체인 업데이트 등으로 훨씬 즐거워졌음
    아직 바라는 점은 남아 있음. 개인적으로는 합 타입, 더 나은 열거형/범위 타입, 불변성, nil 불가능성이 위시리스트에 있지만, 그래도 Go는 지금까지 개발해 본 생태계 중 가장 즐거운 편임

    • RSC의 가장 큰 기술적 기여로는 모듈 버전 관리를 꼽고 싶음. 언어 생태계에 절대적으로 근본적인 요소임
      https://research.swtch.com/vgo-intro
    • non-nilness를 보니 아직도 이 스레드가 기억남
      https://groups.google.com/g/golang-nuts/c/rvGTZSFU8sY/m/R7El...
    • 최근 몇 년 동안 Go를 더 나은 언어로 만든 요소들이 잘 정리된 목록임. 여기에 Russ가 최근 크게 밀어붙인 반복자도 추가하고 싶음
    • Go가 처음부터 nullable 타입이나 합 타입을 갖고 있었다면 훨씬 더 인기가 많았을 것 같음
    • 전통적인 3절 for 루프의 의미 변경도 잊으면 안 됨: https://go101.org/blog/2024-03-01-for-loop-semantic-changes-...
      이 변경 때문에 Go 1.22는 Go 공식이 인정하지 않더라도, 실제로는 Go 1 호환성을 심각하게 깨뜨린 첫 Go 버전이라고 봄

  • 개인적으로 Go는 지금까지 가장 잘 관리된 오픈소스 프로젝트 중 하나라고 봄. 이를 지원한 Google에도 경의를 표함

    • 잘 관리된 프로젝트라고 볼 만한 요소가 무엇인지 궁금함
    • 현실적으로 Go의 “소유권”은 누구에게 있는지 궁금함
      이론상으로는 독립 단체나 위원회 같은 것이겠지만, 실제로 작업하는 사람들 대부분의 비용은 누가 내는지 궁금함. Google인가?
    • Go가 C++나 Java를 대체하려던 임무에는 실패하고, API 쪽에서 Ruby/Python 등을 대체하는 언어가 된 부작용 같음
      그래서 프로젝트 목표가 더 이상 세계 정복이 아니라 사용자와 맞아떨어지게 됐고, 그 전쟁은 Rust, Zig 등이 가져간 셈임
    • glibc 동작만 지원하고 ELF 표준은 마음대로 무시하는 게 정말 “최고로 관리된” 프로젝트의 자격이겠지. /s

  • “BDFL(자비로운 종신 독재자) 모델이 사람이나 프로젝트에 건강하다고 믿지 않는다”는 대목이 흥미로움. 최고의 프로젝트에는 BDFL이 있고, 최고의 BDFL들은 자기 권력에 회의적인 듯함

    • 리더십에 관심 없는 유능한 사람들이 오히려 최고의 리더가 되는 경우가 많아 보임
      반대로 “리더”로 알려지고 싶어서 리더가 되려는 사람들은 능력도 책임감도 없는 경우가 있음
    • 앞부분 전체에 동의하는지는 별개로, 최고의 BDFL들이 자기 권력에 회의적인 건 그리 놀랍지 않음
      한 사람이 일방적으로 결정할 수 있는 권한의 주된 장점은 이해관계자가 많을 때 생기는 교착 상태를 우회할 수 있다는 점이라고 봄. 강한 합의가 있는 결정을 지도자가 정당하게 뒤집어도 된다고 느끼는 프로젝트라면, 사람들이 알 만큼의 커뮤니티가 형성되기 훨씬 어려울 것임
    • 이 말이 맞다고 생각하지 않음. Python에는 BDFL이 있었지만 큰 이득을 본 것 같지는 않음. 이 태도가 어떤 다른 프로젝트들에서 나온 것인지도 잘 모르겠음
      대충 보면 드라마는 줄이겠지만 품질을 눈에 띄게 높이지는 못하는, 다른 관료제와 비슷한 형태로 보임. 한편 단일 소유자가 충분히 유연하지 못해서 실패한 프로젝트는 산더미처럼 많지만, 그런 건 논의할 가치가 없다고 여겨질 뿐임
    • 권력을 가질 만한 사람은 권력을 원하지 않는 사람뿐임
      이건 오픈소스 프로젝트를 훨씬 넘어서는 이야기임
    • BDFL이라는 발상 자체가 농담이고, 이름에도 드러나 있음
      GvR이 Python 창시자로서 맡고 있던 “현장의 현실”을 인정한 표현이었지, 프로젝트 관리 원칙으로 진지하게 의도된 건 아니었음. 처방이 아니라 묘사였는데, 그 개념이 지나치게 실체화돼 버림

  • rsc, 나를 소프트웨어 엔지니어링으로 이끌어 준 이 언어에 들인 모든 노력에 정말 감사함
    여러 프로그래밍 언어를 만져봤지만 Go는 여전히 집처럼 느껴짐. 개발 경험이 훌륭하고, 언어와 창작자들이 단순함과 책임감을 변명 없이 지켜온 점을 정말 높이 평가함. 앞으로의 모든 일에 행운과 좋은 결과가 있길 바람

    • 천만에요. 이 댓글에도 감사드립니다
      Go를 시작했을 때는 Go가 사람들의 삶에 이렇게 긍정적인 영향을 주고, 새로운 사람들을 프로그래밍과 소프트웨어 엔지니어링으로 끌어들일 거라고는 전혀 예상하지 못했음. 그 영향이야말로 가장 자랑스럽게 생각하는 부분임

  • RSC의 블로그가 정말 좋음: https://research.swtch.com/

    • 이제야 rsc가 그 블로그의 두문자어가 될 수 있다는 걸 처음 눈치챔
    • 엄청난 블로그임. 예전에도 이 사이트에서 말했지만, 그의 정규식 시리즈는 말도 안 되게 품질이 높고, 그걸 모두가 볼 수 있게 그냥 올려뒀다는 건 큰 특권임

  • Go에 대한 모든 기여에 감사함
    다만 Go와는 무관한 한 가지에는 동의하지 않음. Python은 GvR이 물러난 뒤 이득을 보지 못했음. 새 “리더십”은 비기술적이고 폭압적이며, 진짜 오픈소스 기여자 대부분을 떠나게 만들었음
    개발은 의심스러운 품질의 일부 기업 기여를 빼면 정체됐고, 분위기는 억압적이며 중요한 것은 Microsoft/Instagram/Bloomberg에서 권력 있는 자리에 있는지뿐임. 꼭 이 회사들의 잘못은 아닐 수 있음. 자신들의 관대함이 악용되고 있다는 걸 모를 수도 있음

  • gofmt 하나만으로도 전 세계에서 엄청난 시간을 절약했을 것 같음. 사실상 다른 모든 언어 생태계가 “좋아, 그냥 자동 포맷하자”라고 말하게 만든 상류에 있음
    자동 포매터가 내 코드에 하는 짓은 싫지만, 더 이상 공백에 대해 말하지 않아도 되는 건 좋음

    • 흥미롭게도 다른 모든 언어에서는 자동 포매터를 싫어하고 탭 대신 공백을 쓰지만, Go에서는 처음부터 gofmt가 코드를 포맷하는 방식에 익숙해짐
      그러고 나면 더 이상 거기에 시간을 많이 쓰지 않아도 된다는 점을 고맙게 여기게 되고, 적어도 대부분에게는 문제가 되지 않음

  • 오늘 그가 집중하려는 프로젝트를 알게 됨: https://go.googlesource.com/oscar/+/refs/heads/master/README...
    오픈소스 프로젝트 유지를 돕는 LLM 기반 아키텍처라고 함. 멋져 보임

  • https://www.youtube.com/watch?v=wwoWei-GAPo — 이때 이후로 프로젝트가 정말 멀리 왔음
    아직도 살아 있고 번성하고 있어서 기쁨. 2009년에는 이렇게 될 거라고 기대하지 않았던 것 같음. Russ 없이는 Go가 지금 위치에 오지 못했을 거라고 봄. 프로젝트에 대한 그의 기여는 엄청났음

  • Russ에게 감사함. 도구 지원을 일급 요소로 둔 것은 혁명적이었고, 지금도 Go의 가장 두드러진 특징임

답변달기