GN⁺: Gitlab에서 일하는 경험

GitLab에서의 경험

• 2015년 10월부터 2021년 12월까지 약 6년간 GitLab에서 근무함.
• GitLab을 떠나 Inko 작업에 전념하기로 결정했지만, GitLab에서의 경험에 대해서는 공유한 적 없음.
• NDA(비밀유지협약)가 만료되어 GitLab에서의 시간을 되돌아볼 수 있는 에너지가 생김.

GitLab 이전

• 암스테르담에 기반을 둔 작은 스타트업에서 근무하며 Rubinius와 Oga라는 XML/HTML 파싱 라이브러리 작업을 함께 진행함.
• 자금 부족과 기술적 문제로 인해 Rubinius 사용을 더 이상 추진하지 않음.
• GitLab에서 일주일에 하루를 Rubinius 작업에 할애할 수 있는지 문의하며 GitLab에 입사함.

2015-2017

• GitLab에서의 첫날은 이전 회사에서 마지막으로 근무한 다음 날로, 원격 근무로 전환함.
• GitLab은 원격 회사였지만 사회적인 회사였으며, 여러 모임과 행사가 있었음.
• GitLab은 성능 문제, 자주 발생하는 서버 다운, 관리 문제 등으로 어려움을 겪음.
• 성능 모니터링 인프라가 부족하여 성능 개선에 어려움을 겪음.
• GitLab의 문화와 태도를 바꾸려고 노력했으나, 성능 개선에 대한 회사의 불만족으로 인해 어려움을 겪음.

2017-2018

• 성능이 크게 향상되고 GitLab이 성능을 더 심각하게 받아들이기 시작함.
• 데이터베이스 성능에 초점을 맞춘 '데이터베이스 팀'으로 변경됨.
• GitLab의 데이터베이스 로드 밸런서를 구축하여 성능에 긍정적인 영향을 미침.
• 데이터베이스 샤딩에 대한 GitLab의 요구에 대해 데이터를 바탕으로 반대함.

2019-2021

• '배달' 팀으로 이동하여 GitLab의 릴리스 프로세스와 도구를 개선하는 데 집중함.
• 커밋이 메인 브랜치에 도착한 후 GitLab.com에 배포되기까지 평균 며칠에서 최악의 경우 3주가 걸림.
• GitLab Community Edition과 GitLab Enterprise Edition을 하나로 통합하는 작업을 주도함.
• 노트북 관리와 관련된 문제와 문화적 변화로 인해 동기 부여와 생산성이 감소함.
• 새로운 관리자와의 갈등으로 인해 '성과 촉진 계획'을 수립함.

배운 점

• 규모 확장성은 회사 문화의 일부가 되어야 함: GitLab은 규모 확장성에 충분히 신경 쓰지 않았음.
• 팀을 더 데이터 및 개발자 중심으로 만들어야 함: GitLab은 제품 관리자 중심의 구조를 가지고 있었음.
• 데이터 없이는 '최소 기능 제품'을 결정할 수 없음: GitLab은 '최소 기능 변경'을 핵심 원칙으로 삼았으나, 실제로는 유용하지 않은 기능을 많이 만들었음.
• SaaS와 자체 호스팅은 잘 어울리지 않음: GitLab은 자체 호스팅 설치와 SaaS 제공을 동시에 제공했으나, 이는 효과적이지 않았음.
• 더 많은 사람이 더 나은 결과를 의미하지 않음: GitLab은 수년에 걸쳐 많은 사람을 고용했지만, 더 많은 개발자가 생산성을 향상시키는 것은 아님.
• Ruby on Rails 사용에 대한 갈등: GitLab은 Ruby와 Ruby on Rails를 사용하여 성공을 거두었지만, 큰 프로젝트에서는 도전이 됨.
• 코드 배포 시간은 조직의 성공에 매우 중요함: GitLab에서는 코드 배포 시간을 단축하는 것이 중요한 목표였음.
• 위치 기반 급여는 차별적임: GitLab은 위치에 따라 급여를 다르게 지급했으나, 이는 차별적인 행위임.

GN⁺의 의견

• GitLab에서의 경험은 원격 근무 환경의 장단점과 스타트업의 성장 과정에서 겪는 다양한 문제를 이해하는 데 도움이 됨.
• 성능 향상과 규모 확장성의 중요성, 그리고 이를 문화로 정착시키는 것의 중요성을 강조함.
• 위치 기반 급여의 문제를 지적하며, 이는 원격 근무 환경에서의 공정한 보상 체계를 논의하는 데 중요한 사례임.

[neo]

Hacker News 의견

• 위치 기반 급여가 차별적이라는 주장

  • 피부색이나 성별로 인한 차별과 위치 기반 급여를 비교하는 것은 적절하지 않음. 피부색과 성별은 바꿀 수 없는 반면, 거주 위치는 변경 가능함.
  • 거주 위치는 회사가 직면하는 법적, 세금 문제, 시차, 여행 비용 등 업무와 관련된 실질적인 문제들과 연관이 있음.
  • 위치 기반 급여 차별에 대한 논의는 가능하지만, 인종이나 성별 차별과 동일시하는 것은 논의를 종결시킬 수 있음.

• 직원 번호 28번으로 시작하여 점차 많은 관리자가 그 위에 배치됨

  • 초기에 CEO에게 직접 보고하던 직원이 점차 많은 관리자 아래에 놓이게 되고, 결국 성과 평가를 받고 회사를 떠남.
  • 대기업에서 종종 발생하는 일반적인 상황으로, 이러한 구조 때문에 대기업에서는 종종 위대한 업적을 이루기 어려움.

• 직원이 개인 컴퓨터를 사용하는 것에 대한 의견

  • 조직의 크기에 상관없이 회사에서 제공하는 컴퓨터를 사용하도록 해야 함.
  • 회사의 지적 재산을 통제하고, 업무와 개인 시간을 분리하는 데 큰 이점이 있으며, 비용도 많이 들지 않음.

• 나쁜 관리자에 대한 의견

  • 나쁜 관리자는 우리 산업의 해악이지만, 많은 스타트업은 창업자들이 이전 직장에서 나쁜 관리자를 겪은 경험 덕분에 생겨남.
  • 저자 자신도 비기술적이고 정치적인 나쁜 관리자를 만나 스타트업을 시작하는 동기를 얻음.

• 위치 기반 급여에 대한 의견 변화

  • 위치 기반 급여가 차별적이라고 생각했던 것에서 벗어나, 각자의 지역에서 적절한 생활을 할 수 있는 급여를 받는 것이 합리적임.
  • 더 많은 급여를 원한다면 이사를 가야 하며, 이사를 가지 않는다면 그에는 이유가 있음.

• Ruby/Rails 사용에 대한 의견

  • Ruby는 언어의 속도가 중요하지 않다는 전제 하에 설계되었지만, 현재는 Node.js와 JVM에서 비동기 처리를 통해 IO/네트워크 대기 시간에 다른 작업을 처리할 수 있는 프로그래밍 모델이 있음.
  • Ruby/Rails는 특정 상황에서 여전히 유용할 수 있지만, 시간이 지남에 따라 유지 관리가 어려워질 수 있음.

• 글로벌 회사에서의 급여 정책에 대한 의견

  • 암스테르담 개발자가 베이 지역 개발자와 동일한 가치를 제공한다면 동일한 급여를 지급해야 함.
  • 글로벌 회사로서 다른 글로벌 회사들과 경쟁하고 있으므로, 장기적으로는 위치에 관계없이 인재에게 가치에 상응하는 급여를 지급하는 것이 중요함.

• GitLab 가격 정책에 대한 질문

  • GitLab의 가격 페이지에서 위치 기반 가격을 선택하는 방법에 대한 질문.

• GitLab의 확장성에 대한 관리의 문제

  • GitLab은 자체 호스팅하는 GitLab Enterprise Edition에서 주로 수익을 창출하며, GitLab.com은 비용이 많이 들지만 수익은 적음.
  • 회사는 수익을 창출하는 부분에 투자하는 것이 합리적이지만, GitLab.com의 성능 향상이 더 많은 고객을 유치하고 더 강한 명성을 구축할 수 있다는 점을 고려해야 함.

• 회사 성장과 초기 직원의 역할에 대한 의견

  • 작은 회사에서 성장한 후에도 동일한 사람들이 모두 잘 해낼 수 있는 것은 아님.
  • 초기에 중요한 역할을 한 직원들에게 적절한 보상을 제공하고, 개인적 성장이나 회사의 성장을 방해하지 않도록 관리하는 것이 리더십의 책임임.
  • 초기 기여자들이 가치와 정신 건강을 동시에 유지하기 어려워서 이른 유동성 이벤트를 기다리거나 큰 재정적 이득을 포기하는 경우가 발생함.
  • 문화 충돌과 이직을 최소화하기 위해 스톡 옵션의 행사 기간을 대폭 늘리고, 문화 충돌과 이직의 초기 징후를 보이는 개인에게 중복 역할을 우선적으로 채용하며, 문제를 명확히 지적하고 적합한 팀이나 회사에 대한 자원을 포함하는 공감적인 코칭이 필요함.