GitLab은 단점이 많아도 일반적인 기업·조직의 프로젝트에는 훨씬 잘 맞음. 소프트웨어 개발과 주변 업무에 참여하는 사람들이 일하는 방식과 더 잘 맞아떨어짐. 처음부터 거의 오픈소스 개발자 소셜 네트워크를 지향하다가 최근에는 Microsoft 색채까지 짙어진 GitHub와는 다름. CI와 GitHub Actions 얘기는 꺼내지도 않겠음.
어떤 면에서 기업·조직 프로젝트에 더 잘 맞는다는 건가요? 업무에서 둘 다 써봤지만 기능상으로는 같았음.
솔직히 좋을 때도 나쁠 때도 있음. GitLab은 기능 목록 채우기에 열중하던 시절에 추가한 잡다한 것들을 걷어내면 훨씬 나아질 것임. 왼쪽 메뉴의 "Secure", "Deploy", "Operate", "Monitor", "Analyze", "Auto Devops" 같은 것부터 치워서 사용자를 방해하지 않게 해야 함.
최근 장애 때문에 이전한 것이라면, 지금 상황에서 다른 곳도 얼마나 오래 쾌적할지는 모르겠음. GitHub 장애 대부분은 내부 엔지니어가 AI를 써서 생기는 게 아니라, 개발자들의 작업 속도가 빨라지면서 시스템 수요가 늘어나는 것이 주원인이라고 봄. AI 사용 때문에 발생한 장애도 한두 건은 있을 수 있음.
이용자마다 더 큰 부하를 만들고 있고, 이런 수요 증가는 당분간 멈추지 않을 듯함. 시간당 5,000회인 GitHub API 한도를 2027년 전에 절반으로 줄이겠다는 메일이 언제 와도 놀랍지 않을 것임.
자체 호스팅이나 기업용 요금제를 쓰지 않는 한 GitLab이라고 이 압력에서 자유로울 이유를 모르겠음. 두 선택지 모두 GitHub도 제공함.
Roku가 Fox에 인수되는 중이라는 점도 짚어둘 만함. Microsoft와 도덕성을 겨룬다면 어느 쪽도 깨끗하지 않음.
거대 복합기업에서는 고객과의 새로운 이해충돌이 계속 늘어난다는 점이 핵심임.
무슨 도덕성 대결인가요?
우선 그 거래는 아직 완료되지 않았고, Roku가 GitHub를 떠나는 일과 FOX가 무슨 관계인지도 모르겠음. 어떤 관련이 있는지 더 설명해 주실 수 있나요?
모든 미디어 기업이 소수의 손에 집중되는 것처럼 보임. 앞으로 좋은 일이 생길 징조는 아닌 듯함.
이전한 이유와 속사정을 좀 공개해 줬으면 좋겠음.
나도 자세한 글을 보고 싶음. 다들 GitHub 장애 때문이라고 추측하지만, GitHub는 모든 면에서 조금씩 뒤처지고, 그 차이가 쌓이면 대형 프로젝트와 조직에서는 관리·운영이 꽤 복잡해짐. GitLab은 대규모 조직과 복잡한 파이프라인을 지원하도록 설계되어 있음. 자체적인 불편함은 있지만 비교가 안 될 정도이고, 그에 비하면 GitHub는 장난감 프로젝트용 개발 플랫폼처럼 보임.
최근 두어 달 사이에 장애가 열두 번쯤 난 것으로는 이유가 충분하지 않은 건가요?
Roku는 내부적으로 GitLab을 쓰고 있으니 단순히 도구를 통일하는 것일 수도 있음.
나는 꽤 다른 상황이라 이 스레드가 흥미로움. 사람들이 좋아할 만한 게임을 만들어 F-Droid에 등록하려는데, GitLab 계정을 만들라는 압박을 받고 있음.
F-Droid 같은 프로젝트가 이러는 게 무척 역설적으로 느껴짐. 자체 절차 때문에 다른 사람이 연동하려면 GitLab에 가입해야 하는 종속 구조를 만들어 놓은 셈임.
부실한 AI 답변이라 미안하지만, 이런 방법이 도움이 될까요? AI 답변에 따르면 F-Droid 등록에는 공식 fdroiddata 저장소에 메타데이터 파일을 추가해야 하지만, GitLab 계정 없이 제출하는 방법도 있다고 함. 기존 GitHub·Google·Bitbucket·Salesforce 계정으로 로그인하거나, F-Droid 포럼에 요청해 커뮤니티 기여자가 대신 메타데이터를 제출하게 할 수 있다는 내용임.
그렇다면 GitLab 계정을 별도로 만들 필요 없이 GitHub 등으로 로그인하면 되는 것 아닐까요? 아마 OAuth 방식일 것으로 추측함. 문서를 잠깐 봐서는 명확하지 않고 이 정보가 오래됐을 수도 있지만, 메타데이터만 맞추면 계정 생성 없이 제출할 수 있는지 확인해 볼 만함.
Git 호스팅 서비스와 무관하게 Dagger로 CI를 구성하는 긴 글을 봤는데, 실제로 어떤 이점이 있는지 궁금함.
Dagger를 좋아하지만 대규모 작업 부하에서는 확장성이 그리 좋지 않음. 다만 중소 규모 프로젝트에는 아주 좋음.
Dagger를 써보지는 않았지만 기존 CI 엔진과 근본적으로 설계가 달라 보여서, 이전에 어려움을 겪는 사람도 있을 듯함.
자체 CI를 운영하려면 Drone.io나 WoodpeckerCI를 추천함. 설계가 단순하고 운영과 사용이 쉬우며, 필요한 대부분의 시스템과 연동됨. 구성요소를 강하게 결합하는 대신 추상화하고, 프로그래머가 아니어도 사용할 수 있음. 사실상 Dagger와는 정반대임.
Dagger를 쓰고 있는데, 단순히 컨테이너를 빌드하는 도구 이상임. 컨테이너 기반 작업 흐름을 CI와 로컬에서 동일하게 한 줄 명령으로 실행할 수 있고, 추가 설정 없이 원격 캐시도 제공함. 여러 언어의 SDK로 BuildKit과 컨테이너의 방향성 비순환 그래프(DAG) 를 활용해 실질적인 재사용이 가능함.
로그와 에이전트에 비밀값이 노출되지 않게 가려주기도 함. 나는 Dagger 위에 분기와 과거 상태로 돌아가기 기능까지 갖춘 에이전트 환경을 구축했음. 요약하면 빌드든 다른 작업이든 BuildKit과 컨테이너 기반 DAG를 SDK로 다루게 해주는 도구임.
v1-beta가 바로 어제 출시됨. https://dagger.io/blog/dagger-10-beta/.
수정: 타당한 이유로 BuildKit을 대체하고 있으며, 그 변경은 이미 공개됨. https://dagger.io/changelog/theseus/.
Game of Trees와 통합된 gotwebd로 옮기고, 더 고민하지 말고 편하게 살면 됨.
이렇게 피상적인 기사가 큰 관심을 받는 게 나만 의아한가요? 소프트웨어 회사가 도구 하나에서 다른 도구로 옮겼다는 것뿐이고, 기사에는 기술적 이유든 비기술적 이유든 이전 배경이 전혀 없음. HN에서 관심을 끄는 이유가 뭔가요? 내가 놓친 게 있나요?
이게 왜 중요한 소식인가요?
주요 소프트웨어 프로젝트가 주요 개발 도구를 교체하는 일인데, 왜 중요하지 않은 건가요? 적어도 HN에서 주목할 만한 일 아닌가요?