우리 회사는 CI/CD와 GitOps를 거의 전부 GitHub Actions로 이전했음. 달걀을 한 바구니에 담는 것도 모자라 냉장고 열쇠까지 거기 넣는 건 위험하다고 경고했지만, 아무도 신경 쓰지 않아 나도 더는 신경 쓰지 않기로 함.
GitHub는 인수 이후 확연히 나빠진 듯함. 늘 그렇듯이.
GitHub가 나빠졌다는 데는 동의하지만, 인수는 벌써 거의 8년 전이고 소프트웨어 업계가 뒤집힌 건 최근 3년 정도임. 인수 후 품질이 떨어지는 일은 흔하지만, 이번에도 인수가 핵심 원인인지는 모르겠음. AI로 소프트웨어와 무료 CI 수요가 3년 전보다 1,000~100,000배 증가한 게 원인일 수도 있음.
이제는 담당 팀들이 안쓰러움. 이 정도 규모와 빈도로 사고가 나면 근본 원인 분석을 명분으로 희생양을 찾는 험악한 분위기가 생길 수밖에 없음.
회사가 일할 도구를 제공하지 못하는 건 본인 잘못이 아님. 남은 시간은 공원에 가거나 게임을 하거나 새로운 기술을 배우는 데 쓰는 편이 나음.
이제는 전에 제안했던 해결책을 들어줄 사람들이 생긴 셈임.
Microsoft가 손대면 다 망가짐. 형편없는 인프라인 Azure 때문임. 얼마 전 여기서 직원 한 명이 내부 사정이 얼마나 나쁜지 풀어놓았는데, 그것만 읽어도 Microsoft 소유 서비스 전반을 다시 평가하게 됨.
답은 너무 명백한데 왜 실행하지 않는지 모르겠음. 가격을 올리고 무료 제공량을 줄이면 됨. 증가세를 늦추거나 매출을 늘려 연산 자원을 더 투입해야 함.
지금은 성능이 나빠져도 고객이 떠나지 않고, 무료 이용자가 유료 고객으로 전환되고 있음. 가격 인상은 이탈을, 무료 제공량 축소는 신규 고객 유입 감소를 초래할 수 있음.
부하가 유일한 원인이 아니라면, 이용자만 크게 줄고 장애는 그대로인 결과가 나올 수도 있지 않을까?
나도 처음에는 그렇게 생각했지만, GitHub가 그러기만을 기다리는 경쟁자들이 없어야 통할 방법임.
곧 요청 횟수 제한이 도입된다는 안내를 받았음.
증가세를 늦추려면 누구나 AI 에이전트로 시간당 500개 커밋을 자동으로 올리는 것이 모두에게 좋은 일은 아닐 수 있다고 인정해야 함. 그럴 리는 없음.
우리 회사에서는 UTC 15시쯤이면 주간 GitHub Actions 장애가 온다는 게 거의 단골 농담임. 미국 이용자들이 하루 업무를 시작하는 시간과 관련이 있는 걸까?
공식 상태 공지보다 20분 먼저 장애를 알았다는 게 황당함.
왜 황당한 건지 모르겠음. 보통 상태 공지를 요약해서 올리려면 먼저 무슨 일이 벌어졌는지 진단해야 함. 아니면 “이상이 발생해 확인 중입니다”라는 안내라도 바로 보고 싶다는 뜻인가?
GitHub 인프라는 끊임없이 DDoS 공격을 받고, 오픈소스 프로젝트에 무료로 제공하는 것도 많음. 의존성 변경, 패치, 방치된 라이브러리도 계속 처리해야 하니 조금은 고마워할 필요가 있음. 이런 운영은 어려운 일임.
너무 관대하게 봐주는 듯함. 제공하는 서비스 특성상 기술적으로 무한 확장이 불가능할 이유가 없음. 예를 들어 자꾸 장애가 나는 풀 리퀘스트 페이지의 순간적인 대량 요청 처리는 이미 해결된 문제임.
정말 CI 연산 자원이 부족하다면 무료 제공량을 줄여야지, 유료 고객까지 계속 장애를 겪게 해서는 안 됨.
무료 제공분을 빼고 보더라도, 여기서는 중견 규모 회사의 자체 호스팅 Git 운영을 해본 사람이 없어 보임. 거기도 장애가 끊이지 않으며, 진단과 복구까지 직접 해야 함. 기술적 처리는 오히려 가장 쉬운 부분임.
어떤 팀이 절차나 제한을 우회하려고 Git 인프라를 기상천외하게 쓰다가 망가뜨리기도 함. 그러면 버전 관리 시스템을 Docker 레지스트리처럼 쓰면 안 되는 이유를 팀 관리자와 상위 책임자에게까지 설명하며 다퉈야 함.
무료 서비스 이용량이 얼마나 폭증했는지 사람들이 잘 모르는 듯함. 엄청난 수준임.
무료 제공분 때문에 유료 고객에게 장애가 난다면 무료 요금제 제공량을 줄여야 함.
GitHub가 문제를 해결하고 가동률을 개선하기를 바람. 이미 우리 팀 업무 흐름에 너무 깊이 자리 잡아서 다른 서비스로 바꾸면 엄청난 혼란이 생길 것임.
예전에 Atlassian Bitbucket을 쓰는 조직에서 일했는데, 당시 그것도 나름의 문제가 있었음. 지금처럼 나빠진 GitHub도 그것보다는 나을 것 같음. 솔직히 어떤 대안이 있는지도 모르겠음.
우리는 gitlab.com과 자체 호스팅 러너를 쓰며, 러너에서 내부망에도 접근할 수 있음. 장애는 우리 인프라에서만 발생함. 이전하려면 CI 작업 흐름을 옮겨야 하지만, 괜찮은 LLM이면 쉽게 처리 가능함.
그러니까 대안이 무엇인지 모르겠음. 그저 GitHub 장애에 휘둘릴 수밖에 없는 듯함.
완전히 새로운 플랫폼을 만들어 신규 이용자를 받고, 기존 이용자를 천천히 이전하면 안 될까? 기존 이용자를 옮기지 않더라도 기존 플랫폼의 부하는 안정될 것 같음. 이 방식의 단점은 무엇일까?
이제 GitHub는 사실상 웃음거리가 됨. 내가 아는 개발 조직은 모두 GitHub에서 벗어날 이전 경로를 만들고 있거나, 적어도 가능한지 검토 중임. Slack마다 불타는 GitHub 맞춤 이모지가 있을 정도니, GitHub는 이제 끝장난 듯함.