지금은 조용히 실패하는 것도 더 문제임
예를 들어 PR이 수십 개 있는데도 "There aren’t any open pull requests."라고 보여줘서 사람들을 확실히 오도하게 됨
지난주엔 merge queue를 쓰면 실수로 trunk를 날려버린 일도 있었고, 그것도 조용히 실패했음
우리 쪽은 오히려 드디어 PR을 전부 끝낸 것처럼 보여서 축하 중이라고 농담하게 됨
PR 목록이 뜨더라도 보고 있는 카테고리의 PR을 전부 보여주지 않는 경우가 있어서 정말 악질적임
이건 내게 정말 크게 와닿음
몇 달 전 $PARENT_CONGLOMERATE가 시너지와 효율성을 이유로 산하 조직 전체에 GitHub 마이그레이션을 강제했고, 이제 $DAYJOB에서도 self-hosted GitLab에서 옮기는 차례가 됐음
이미 불만이 몇 가지 있음 GH 계정 관련 IT 정책은 앞뒤가 안 맞아서, 개인 계정이든 예전에 $DAYJOB용으로 따로 만든 계정이든 기존 계정을 전혀 못 쓰고 IT 규칙에 맞춘 새 계정을 다시 만들어야 함
우리는 monorepo를 쓰지 않아서 groups를 많이 활용했는데 GitHub에는 그 개념이 직접 대응되지 않아 프로젝트 namespace를 수동으로 정리해야 함
거기에 이제 GitHub의 가용성까지 이 모양임
우리 팀은 출시 일정이 수익에 민감해서 하루이틀만 밀려도 월간 목표 달성 여부가 갈릴 수 있음
다른 상황이면 수익 핵심 코드를 미리 미러링했겠지만, 그런 게릴라성 우회책을 만들 만큼 위험을 감수할 가치는 없어 보임
가까운 미래의 포스트모템에서 The Synergy Mandate를 탓할 수 있으면 좋겠지만, 현실적으로 그럴 일 없다는 건 나도 잘 앎
수익 목표를 계속 맞추고 실적 부진으로 제품이 잘려 나가지 않기만 바랄 뿐임
이렇게 적다 보니 내가 입사했을 때와 지금 이 일이 얼마나 달라졌는지 더 실감하게 됨
모든 OSS 프로젝트에 다시 말하고 싶음
간단한 CI 작업으로 여러 forge 사이에서 코드를 동기화하는 건 엄청 쉽게 할 수 있고, 두 번째 forge의 이메일 알림을 받는 데도 추가 부담이 거의 없음
적어도 GitHub 바깥으로 옮겨서 기여할 선택지는 열어둬야 하고, 결국 그게 생태계 전체에 더 나음
코드 동기화 자체는 쉽고 사소한 부분이며, CI 작업은 사실 그 부분만 해결함
대부분 프로젝트에선 그것조차 아주 필수는 아닐 수 있음
어려운 건 코드 주변의 것들임
tickets와 PR, 닫힌 것들까지 포함한 기록
프로젝트를 참조하는 각종 링크
CI 설정
큰 프로젝트라면 커미터 권한 구성
필요하다면 push/commit/branch 규칙까지 전부 옮겨야 함
이런 건 프로젝트마다 마이그레이션하기 매우 성가시고, 일부는 잃어버릴 수도 있음
그런데 더 큰 문제는 소프트웨어를 찾는 기본 플랫폼을 잃는 일임
소프트웨어판 fediverse는 언제 나오나 싶음
동기화는 사소하지만 진짜 핵심은 CI임
아직도 GitHub Actions가 최선의 선택지이고, FSF든 다른 OSS 랩이든 오픈소스 유지보수자들에게 제대로 된 CI를 제공하지 못했음
게다가 CI 부하도 예전보다 엄청 커졌음
자체 GitLab 인스턴스를 꾸리는 것도 좋은 해법일 수 있음
이제는 진지하게 대안을 밀어야겠다고 느낌
이게 우리 비즈니스에 실제 영향을 주기 시작했고, 나아질 기미도 전혀 안 보임
GitHub 같은 UI를 원하면 Forgejo나 Gitea를 쓰면 됨
org/repo 구조 제약은 감수해야 함
비슷하지만 약간 다른 경험을 원하면 GitLab이 맞음
커널 쪽에 가까운 방식, 즉 호스팅과 유연한 저장소 구조, ssh key 기반 사용자 인증, 단순한 웹 UI를 원하면 gitolite에 cgit를 붙이거나 gitweb을 쓰면 됨
우리는 몇 년째 Gitea와 Drone/Woodpecker를 self-hosting 중인데 아주 잘 돌아감
Gitea든 Forgejo든 제공 기능만 맞으면 충분함
가끔 GitHub 장애 스레드에 와서 웃고 가는데, 우리 Gitea 인스턴스는 지난 몇 년간 총 다운타임이 몇 분 수준이었고 전부 한밤중의 계획된 업그레이드였음
GitLab이 더 주목받지 않는 게 의외임
완전한 복제품은 아니어도 충분히 가깝고, 오렌지와 사과 차이보다는 사과와 배 정도 차이라고 봄
나도 같은 생각이었음
다만 GitHub는 정말 끈적한 플랫폼이라 actions와 온갖 연동을 깔아두면 떠나기 어려움
그래도 장애가 이렇게 자주 나는 건 이제 좀 황당한 수준임
지금은 Forgejo로 Git과 CI를 self-hosting 중인데 아주 만족스럽게 잘 돌아감
GitHub가 죽는 것도 싫고, AI가 코드 훔쳐가는 것도 싫다면 sourcehut을 써보면 좋겠음
내겐 아주 잘 맞았고, 플랫폼으로 더 번성했으면 함
새 저장소를 탐험하는 경험이 좋아서 나는 전부 Codeberg로 옮겼고, 내가 관심 있는 프로젝트들 대부분도 거기 있음
sourcehut이 뭐가 다른지 모르겠음
결국 그것도 또 다른 중앙집중형 서비스 아닌가 싶음
이번 건 유난히 오래 걸리네 싶음
고치는 팀이 Claude 세션 제한에 걸려 쿨다운 끝날 때까지 손도 못 대고, AI 없이 직접 고칠 줄 아는 유일한 사람은 수술하러 자리를 비웠다는 식의 농담이 떠오름
AI 없이 직접 고치던 세대가 전부 은퇴하면 그다음엔 어떻게 되나 싶기도 함
GitHub가 내려갈 때마다 몇 사람씩 더 윤리적 대안으로 옮기고, FOSS 커뮤니티가 Microsoft 하나에 SPOF를 두는 구조도 조금씩 약해짐
Hacker News 의견들
지금은 조용히 실패하는 것도 더 문제임
예를 들어 PR이 수십 개 있는데도 "There aren’t any open pull requests."라고 보여줘서 사람들을 확실히 오도하게 됨
이건 내게 정말 크게 와닿음
몇 달 전 $PARENT_CONGLOMERATE가 시너지와 효율성을 이유로 산하 조직 전체에 GitHub 마이그레이션을 강제했고, 이제 $DAYJOB에서도 self-hosted GitLab에서 옮기는 차례가 됐음
이미 불만이 몇 가지 있음
GH 계정 관련 IT 정책은 앞뒤가 안 맞아서, 개인 계정이든 예전에 $DAYJOB용으로 따로 만든 계정이든 기존 계정을 전혀 못 쓰고 IT 규칙에 맞춘 새 계정을 다시 만들어야 함
우리는 monorepo를 쓰지 않아서 groups를 많이 활용했는데 GitHub에는 그 개념이 직접 대응되지 않아 프로젝트 namespace를 수동으로 정리해야 함
거기에 이제 GitHub의 가용성까지 이 모양임
우리 팀은 출시 일정이 수익에 민감해서 하루이틀만 밀려도 월간 목표 달성 여부가 갈릴 수 있음
다른 상황이면 수익 핵심 코드를 미리 미러링했겠지만, 그런 게릴라성 우회책을 만들 만큼 위험을 감수할 가치는 없어 보임
가까운 미래의 포스트모템에서 The Synergy Mandate를 탓할 수 있으면 좋겠지만, 현실적으로 그럴 일 없다는 건 나도 잘 앎
수익 목표를 계속 맞추고 실적 부진으로 제품이 잘려 나가지 않기만 바랄 뿐임
이렇게 적다 보니 내가 입사했을 때와 지금 이 일이 얼마나 달라졌는지 더 실감하게 됨
모든 OSS 프로젝트에 다시 말하고 싶음
간단한 CI 작업으로 여러 forge 사이에서 코드를 동기화하는 건 엄청 쉽게 할 수 있고, 두 번째 forge의 이메일 알림을 받는 데도 추가 부담이 거의 없음
적어도 GitHub 바깥으로 옮겨서 기여할 선택지는 열어둬야 하고, 결국 그게 생태계 전체에 더 나음
대부분 프로젝트에선 그것조차 아주 필수는 아닐 수 있음
어려운 건 코드 주변의 것들임
tickets와 PR, 닫힌 것들까지 포함한 기록
프로젝트를 참조하는 각종 링크
CI 설정
큰 프로젝트라면 커미터 권한 구성
필요하다면 push/commit/branch 규칙까지 전부 옮겨야 함
이런 건 프로젝트마다 마이그레이션하기 매우 성가시고, 일부는 잃어버릴 수도 있음
그런데 더 큰 문제는 소프트웨어를 찾는 기본 플랫폼을 잃는 일임
소프트웨어판 fediverse는 언제 나오나 싶음
아직도 GitHub Actions가 최선의 선택지이고, FSF든 다른 OSS 랩이든 오픈소스 유지보수자들에게 제대로 된 CI를 제공하지 못했음
게다가 CI 부하도 예전보다 엄청 커졌음
이제는 진지하게 대안을 밀어야겠다고 느낌
이게 우리 비즈니스에 실제 영향을 주기 시작했고, 나아질 기미도 전혀 안 보임
org/repo 구조 제약은 감수해야 함
비슷하지만 약간 다른 경험을 원하면 GitLab이 맞음
커널 쪽에 가까운 방식, 즉 호스팅과 유연한 저장소 구조, ssh key 기반 사용자 인증, 단순한 웹 UI를 원하면 gitolite에 cgit를 붙이거나 gitweb을 쓰면 됨
Gitea든 Forgejo든 제공 기능만 맞으면 충분함
가끔 GitHub 장애 스레드에 와서 웃고 가는데, 우리 Gitea 인스턴스는 지난 몇 년간 총 다운타임이 몇 분 수준이었고 전부 한밤중의 계획된 업그레이드였음
완전한 복제품은 아니어도 충분히 가깝고, 오렌지와 사과 차이보다는 사과와 배 정도 차이라고 봄
다만 GitHub는 정말 끈적한 플랫폼이라 actions와 온갖 연동을 깔아두면 떠나기 어려움
그래도 장애가 이렇게 자주 나는 건 이제 좀 황당한 수준임
GitHub만의 일이 아니라 더 큰 장애로 보임: https://downdetector.com
오늘도 하루 끝에 y가 들어가니, 그렇다면 역시 GitHub 장애가 있다는 뜻이 됨
Codeberg.org도 지금 문제가 있음
https://status.codeberg.org/status/codeberg
https://social.anoxinon.de/@codebergstatus/11647770704799298...
GitHub가 죽는 것도 싫고, AI가 코드 훔쳐가는 것도 싫다면 sourcehut을 써보면 좋겠음
내겐 아주 잘 맞았고, 플랫폼으로 더 번성했으면 함
결국 그것도 또 다른 중앙집중형 서비스 아닌가 싶음
이번 건 유난히 오래 걸리네 싶음
고치는 팀이 Claude 세션 제한에 걸려 쿨다운 끝날 때까지 손도 못 대고, AI 없이 직접 고칠 줄 아는 유일한 사람은 수술하러 자리를 비웠다는 식의 농담이 떠오름
AI 없이 직접 고치던 세대가 전부 은퇴하면 그다음엔 어떻게 되나 싶기도 함
GitHub가 내려갈 때마다 몇 사람씩 더 윤리적 대안으로 옮기고, FOSS 커뮤니티가 Microsoft 하나에 SPOF를 두는 구조도 조금씩 약해짐
https://sfconservancy.org/GiveUpGitHub/
협업이 쉬웠고, 지금은 여러 이유로 마찰이 커지는 중임
issues가 스팸처럼 쓰이는 일도 늘고 있고, 그보다 더 악의적인 활동도 점점 보이기 시작함