GitHub이 큰 위기에 처했습니다!
MMaximilian Schwarzmüller
Computing/SoftwareBusiness NewsManagementInternet Technology
Transcript
00:00:00GitHub이 매우 심각하고 좋지 않은 상황에 처해 있습니다.
00:00:04정말 많은 문제들이 있으며, 그중 상당수는 AI와 관련이 있습니다.
00:00:08하지만 여러분이 생각하는 그런 이유 때문은 아닐 수도 있습니다.
00:00:10그 점에 대해서는 뒤에서 다시 설명하겠습니다.
00:00:11그리고 당연히 이 문제는 중요합니다.
00:00:13GitHub은 현대 개발 업무의 근간이기 때문에
00:00:16중요할 수밖에 없습니다.
00:00:17오픈 소스 개발을 하든,
00:00:20특정 오픈 소스 프로젝트를 유지보수하든,
00:00:22혹은 그냥 본인만의 프로젝트를 하든 상관없이 말이죠.
00:00:24개인 프로젝트나 사이드 프로젝트일 수도 있고,
00:00:26작은 비즈니스나 소규모 회사를 운영 중일 수도 있으며,
00:00:29규모가 더 큰 회사에 다닐 수도 있습니다.
00:00:32GitHub은 코드 아카이브부터 시작해서
00:00:35CI/CD 워크플로우, 협업 등 온갖 용도로 사용됩니다.
00:00:38이슈를 통해 프로젝트를 함께 진행하거나
00:00:42풀 리퀘스트를 비롯해 수많은 용도와 사례가 있습니다.
00:00:47그래서 중요하지만, 앞서 말씀드렸듯이
00:00:49많은 문제들이 산재해 있습니다.
00:00:51먼저 무엇이 잘못되었는지부터 살펴보고,
00:00:53그 이유가 무엇인지,
00:00:54그리고 그것이 미래에 어떤 의미를 갖는지 알아보겠습니다.
00:00:57가장 큰 문제부터 시작해 보죠.
00:00:59크고 거대한,
00:01:02믿기 힘든 보안 취약점이 어제 보고되었습니다.
00:01:07제가 이 영상을 녹화하기 전날 기준으로요.
00:01:09바로 github.com의 원격 코드 실행(RCE) 취약점입니다.
00:01:12정말 읽기만 해도 말도 안 되는 소리죠.
00:01:16이는 보안 업체인 Viz에 의해 발견되었으며,
00:01:19악용되지는 않았습니다.
00:01:21발견 즉시 보고되었고 수정되었습니다.
00:01:25아무런 피해도 발생하지 않았습니다.
00:01:28GitHub 측에 따르면 말이죠.
00:01:31그들은 이 보고서에 대한 답변도 게시했습니다.
00:01:33자, 그 취약점이 어떻게 작동했는지에 대한
00:01:36세부적인 내용까지 들어가지는 않겠습니다.
00:01:39관련 기사 링크는 아래에 남겨두겠습니다.
00:01:42하지만 결국 모든 것은 git push를 통해 이루어졌습니다.
00:01:44피싱이 관여된 것도 아니고,
00:01:46직원의 계정을 탈취한 것도 아니며,
00:01:49공급망 공격도 아니었습니다.
00:01:51지난 몇 주 동안 그런 일들을 많이 봐왔지만,
00:01:54이번에는 그런 것들이 전혀 개입되지 않았습니다.
00:01:56대신 단순한 git push였고,
00:01:58구체적으로는 표준 push option 기능이었습니다.
00:02:03git push 명령에 추가 옵션을
00:02:05덧붙이기 위해 사용하는 기능이죠.
00:02:10해당 옵션 기능과 취약점,
00:02:13그리고 GitHub이 push를 처리하는 방식 때문에,
00:02:17보안 연구원들은 코드를 첨부할 수 있었고
00:02:22그 코드는 GitHub 서버에서 바로 실행되었습니다.
00:02:27다시 말씀드리지만, 정확한 내용은 보고서에 나와 있습니다.
00:02:31하지만 결론적으로 그들은 특정 사실을 악용했습니다.
00:02:34xstat 헤더에 추가 메타데이터를 넣을 수 있다는 점인데,
00:02:39이 헤더는 push options 플래그의 도움을 받아 채워집니다.
00:02:44그리고 그 메타데이터, 즉 함께 전달할 수 있었던 정보가
00:02:49해당 헤더를 통해 push 요청에 포함되었는데
00:02:52GitHub은 이를 제대로 검증(sanitize)하지 않았습니다.
00:02:54그들은 단지 push 요청에 대한 인증만 거쳤을 뿐입니다.
00:02:58push 명령 자체에 대해서 말이죠.
00:02:59당신이 해당 저장소에 push할
00:03:01권한이 있는지만 확인했습니다.
00:03:03하지만 그 후 데이터 검증 없이
00:03:07해당 옵션 데이터를 가져와 xstat 헤더를 구축했습니다.
00:03:12이로 인해 보안 연구원들은
00:03:15명령어를 실행할 수 있었고, 이는 그들이
00:03:18push한 저장소 내로 국한되지 않았습니다.
00:03:21대신 GitHub 서버에서 자유롭게 실행되어
00:03:24다른 저장소에도 접근할 수 있었습니다.
00:03:27비공개 저장소들을 포함해서 말이죠.
00:03:29다시 말하지만, 이 취약점은 보고되어 수정되었고
00:03:33더 이상 존재하지 않습니다.
00:03:35하지만 분명히 엄청난 사건입니다.
00:03:39github.com에서 원격 코드 실행이 가능한
00:03:43취약점이 있다는 건 정말 심각한 일입니다.
00:03:45정말 엄청난 일이죠.
00:03:47네, 이게 큰 문제 중 하나입니다.
00:03:48하지만 물론 이것만이 문제는 아닙니다.
00:03:51불과 며칠 전인 4월 23일에
00:03:56GitHub 머지 큐(merge queues)와 관련된 큰 사고가 있었습니다.
00:04:01GitHub 머지 큐가 생소하신 분들을 위해 설명하자면,
00:04:04활동이 매우 많고 작업이 활발하며
00:04:07풀 리퀘스트가 쏟아지는 저장소를 위한
00:04:11GitHub의 기능입니다.
00:04:13새로운 풀 리퀘스트를 보내기 전에
00:04:16모든 풀 리퀘스트를 일일이 머지할 필요가 없게 해주죠.
00:04:19저장소의 최신 상태를 바탕으로
00:04:21풀 리퀘스트를 만들어야 하기 때문입니다.
00:04:24예를 들어 메인 브랜치의 최신 상태 말이죠.
00:04:26새 풀 리퀘스트를 열기 전에 매번
00:04:28기존 풀 리퀘스트를 머지해야 하는 번거로움을 없애기 위해,
00:04:30결국 이 머지 큐 기능이 존재합니다.
00:04:34이 기능의 단순한 목표는 사실상
00:04:38중간 단계의 머지를 미리 생성하는 것입니다.
00:04:42머지하려는 브랜치의 새로운 상태를
00:04:46각 풀 리퀘스트마다 미리 만들어두는 거죠.
00:04:49풀 리퀘스트 체인에 새 항목이 추가되면
00:04:51그것 또한 메인 브랜치 앞의
00:04:53풀 리퀘스트들과 이미 머지된 것으로 결합되어,
00:04:57마치 이전 풀 리퀘스트들이
00:04:58이미 머지된 것처럼
00:05:01새로운 풀 리퀘스트가 열리게 됩니다.
00:05:05덕분에 팀원들은 훨씬 빠르게 작업할 수 있습니다.
00:05:08앞선 풀 리퀘스트가 처리되길 기다리지 않고
00:05:10계속해서 풀 리퀘스트를 열 수 있으니까요.
00:05:13결국 어느 시점에는 머지가 되겠지만,
00:05:15작업의 흐름을 끊지 않게 해주며
00:05:17이는 대규모 팀 등에게 매우 중요합니다.
00:05:19그 기능과 관련하여 또 중요한 점은
00:05:22당연히 올바르게 작동해야 한다는 것입니다.
00:05:24그런데 4월 23일에 발생한 일은,
00:05:28내부 로직 오류가 발생했다는 것입니다.
00:05:32GitHub이 여러 풀 리퀘스트를 해결하는 방식에서
00:05:37오류가 발생하여 결과적으로
00:05:41일부 정보를 누락시킨 채 머지하게 되었고,
00:05:45이는 잘못된 커밋으로 이어져
00:05:49Git 히스토리의 일부를 유실시켰습니다.
00:05:50실제로 데이터가 완전히 사라진 건 아니지만,
00:05:53이 기능이 비정상적으로 작동하여
00:05:55잘못된 커밋을 생성한 것입니다.
00:05:57이게 이번 사건의 요약이자 핵심입니다.
00:06:00그리고 당연히 이는 용납될 수 없는 일입니다.
00:06:03해당 기능을 신뢰하는 대기업이나 일반 기업의 입장에서
00:06:06갑자기 프로젝트가 망가진 상태가 되었는데
00:06:09그에 대한 명확한 설명조차 없다면,
00:06:13그것은 분명 받아들이기 힘든 일이죠.
00:06:16또한 여러분의 첫 번째 생각은 아마
00:06:19머지 큐 기능의 내부 버그라고는 생각 못 하실 겁니다.
00:06:23보통은 자신이 무언가 잘못했다고 생각하겠죠.
00:06:26그래서 에러를 찾느라 많은 시간을 허비하다가
00:06:28결국 GitHub의 문제라는 걸 알게 됩니다.
00:06:30여기에 더해, GitHub이 겪고 있는
00:06:33고질적인 가동 중단(업타임/다운타임) 문제도 있습니다.
00:06:38공식 상태 페이지(Status page)는 나빠 보이지만,
00:06:42그럭저럭 괜찮아 보일 수도 있습니다. 하지만 최소한
00:06:46대부분의 시스템 가동률이 99.9%에도 못 미칩니다.
00:06:49그들은 시스템별로 가동률을 따로 보고하긴 합니다.
00:06:53하지만 'missing GitHub status page'를 보면
00:06:55이야기가 조금 달라집니다.
00:06:57그곳은 다른 방식으로 가동 시간을 추적하며
00:07:00모든 사소한 사고를 문제로 간주하고,
00:07:04결국 가동 중단 시간으로 집계합니다.
00:07:05여기서 보면 GitHub처럼 중요한 시스템의 가동률이
00:07:10처참한 수준인데, 이는 절대 용납할 수 없는 수치입니다.
00:07:14가동 중단 문제는 지난 몇 달 동안,
00:07:18심지어 작년부터 계속되어 왔습니다.
00:07:20곳곳에서 자잘한 버그들도 발생해 왔죠.
00:07:23다만 이번 사건처럼 크거나 보안 취약점만큼
00:07:26중대하지는 않았을 뿐입니다.
00:07:28하지만 보시다시피 문제는 산더미 같고,
00:07:31GitHub은 이 시점에서 확실히 신뢰하기 힘든 플랫폼이
00:07:36되어버렸습니다. 안타까운 일이죠.
00:07:38서두에 말씀드렸듯이 현대 개발 분야에서의
00:07:43역할과 중요성을 고려할 때 이는 재앙과도 같습니다.
00:07:47여러분이 어떤 종류의 개발 업무를 하든 상관없이 말이죠.
00:07:50또 다른 문제는 GitHub 측의 소통이
00:07:54솔직히 말씀드리면, 별로 없었다는 점입니다.
00:07:59그동안 소통이 활발하지 않았습니다만,
00:08:014월 28일에 블로그 포스트가 하나 올라왔습니다.
00:08:06그 보안 취약점 사건이 터지기 직전에요.
00:08:10거기서 그들은 현재 상황과
00:08:14문제의 원인이 무엇인지 설명했습니다.
00:08:16또한 자신들의 소통 전략이
00:08:19이상적이지 않았음을 인정하고 개선을 약속했습니다.
00:08:23이제 다음 내용을 살펴보죠.
00:08:25이런 문제들은 어디서 오는 걸까요?
00:08:28공식 성명에서는 AI를 그 원인으로 꼽았습니다.
00:08:32하지만 마이크로소프트의 GitHub 엔지니어들이
00:08:36AI를 사용해서 버그투성이 소프트웨어나
00:08:40엉터리 업데이트를 내놓았다는 의미는 아닙니다.
00:08:43그럴 수도 있겠지만, 증거는 없으니까요.
00:08:47대신 여기서 언급한 주요 원인은,
00:08:51AI 덕분에 너무나 많은 프로젝트가
00:08:57생성되고 있고, 엄청난 양의 코드가 만들어져
00:09:00결국 그 모든 프로젝트와 코드가
00:09:03GitHub으로 push되고 있다는 점입니다.
00:09:04그들은 몇 가지 차트를 공유했는데, 뭐랄까,
00:09:09아주 유용하지는 않지만 보여드리겠습니다.
00:09:12y축이 없어서 그렇게 유용하지는 않습니다.
00:09:14절대적인 수치를 확인할 수는 없지만,
00:09:17대략적인 상관관계는 파악할 수 있습니다.
00:09:20보시다시피 2025년 한 해 동안,
00:09:23머지된 풀 리퀘스트 수와
00:09:28push된 커밋 수, 신규 저장소 수가 급증했습니다.
00:09:32이는 우리가 AI를 이용해 만들다가
00:09:34완성하지 못한 수많은 사이드 프로젝트들입니다.
00:09:36그리고 2026년에 들어서면서 모든 지표가
00:09:41말 그대로 하늘 높은 줄 모르고 치솟고 있습니다.
00:09:46네, 이는 아주 뚜렷한 추세입니다.
00:09:49그리고 이러한 트래픽 증가 현상은
00:09:54어떤 시스템이든 엄청난 압박을 줄 수밖에 없습니다.
00:09:58특히나 GitHub에게 문제가 되는 이유는
00:10:01그들이 현재 아키텍처를 이전하는
00:10:05과정 중에 있기 때문입니다. 모놀리식 구조와
00:10:09자체 데이터 센터 시스템에서 벗어나 Azure 클라우드와
00:10:13더 분산된 마이크로서비스 시스템으로
00:10:17넘어가는 과도기라고 할 수 있습니다.
00:10:21이는 2026년이 되기 전부터 진행 중이던 작업이었습니다.
00:10:26하지만 마이그레이션 도중에
00:10:31폭발적인 수요 증가를 맞닥뜨린 것이죠.
00:10:34즉, 마이그레이션을 진행하는 중이라 해도,
00:10:36현재 시스템을 어느 정도 안정화하면서
00:10:39마이그레이션을 계속 이어가야 한다는 뜻입니다.
00:10:40그러면 향후 트래픽 증가에
00:10:44도움이 되기를 바라는 것이죠.
00:10:46물론 희망 사항일 뿐, 보장은 없습니다.
00:10:50하지만 당연히 GitHub가 해결해야 할 과제입니다.
00:10:52여기 보면 그들은 2025년 10월에 GitHub의 용량을
00:10:5610배로 늘리기 위한 계획을 실행하기 시작했다고 합니다.
00:11:01이 시점쯤에 그들은 상황을 파악했을 겁니다.
00:11:04모든 지표가 치솟고 있다는 것을요.
00:11:06사실 그 전부터 이미 알고 있었겠지만,
00:11:09용량을 10배 늘려야겠다고 결정한 건 이때입니다.
00:11:13그러다 2026년 2월에 그들은 깨달았습니다.
00:11:1610배가 아니라 30배가 필요하다는 것을요. 왜냐하면,
00:11:20저기 보이는 그래프의 추세 때문이죠.
00:11:22당연히 이 작업은 마이그레이션과 병행되어야 합니다.
00:11:28이것은 분명히 엄청난 작업입니다.
00:11:33현재 마이크로소프트의 일부이기에 작은 스타트업은 아니지만,
00:11:37그럼에도 불구하고 매우 벅찬 일입니다.
00:11:39이것이 이 전체 GitHub 문제의 한 측면이며,
00:11:44제가 어느 정도 공감하는 부분입니다. GitHub를 비난하고
00:11:47비웃는 것은 쉽기 때문이죠.
00:11:51물론 그럴 만한 이유도 충분합니다.
00:11:52정말 심각한 다른 문제들도 나중에 다시 다루겠습니다.
00:11:56하지만 이런 식의 트래픽 증가는 어떤 시스템이나
00:11:59어떤 기업에게도 엄청난 문제가 될 것입니다.
00:12:03GitHub의 경쟁사라고 해서 이런 상황에서
00:12:07더 잘해냈을 거라고 믿기는 어렵습니다.
00:12:09그래도 물론 그것이 핑계가 될 수는 없습니다.
00:12:10그들은 마이크로소프트의 일원이니까요.
00:12:12따라서 그 전환 과정을 거치고 시스템을
00:12:16이 새로운 세상과 새로운 트래픽 규모에 맞게
00:12:20조정할 자원을 충분히 가지고 있는 셈입니다.
00:12:24그런데 GitHub에는 또 다른 중요한 문제가 있습니다.
00:12:28바로 더 이상 CEO가 없다는 사실입니다.
00:12:32전임 CEO인 토마스 돔케(Thomas Domke)는
00:12:372025년 8월에 은퇴하거나 사임하겠다고,
00:12:41혹은 물러날 것이라고 발표했습니다.
00:12:43그런데 마이크로소프트는 새 CEO를 임명하지 않았습니다.
00:12:48대신 GitHub는 Core AI의 일부가 되었습니다.
00:12:51마이크로소프트 내부 부서인 Core AI는 이름에서 알 수 있듯이,
00:12:56AI와 AI 도구 및 플랫폼 구축을 전담하는 곳입니다.
00:13:01GitHub가 그 하위 조직이 된 것이죠.
00:13:03마이크로소프트의 관점에서 본 GitHub의 임무는 분명히
00:13:07AI 툴체인의 일부가 되는 것,
00:13:11즉 AI 혁명의 일부가 되는 것입니다.
00:13:13그리고 마이크로소프트는 확실히 모든 제품에
00:13:15Copilot을 밀어넣고 있습니다.
00:13:16실제로 GitHub Universe 2023에서
00:13:20그들은 이미 GitHub를
00:13:24AI 기반 개발자 플랫폼으로
00:13:28변모시키겠다고 선언했습니다. 어디서나 GitHub를 쓸 수 있게 말이죠.
00:13:30여기에는 GitHub Copilot을 활용해
00:13:32이슈 생성을 돕는 것과 같은 새로운 기능들이 포함되는데,
00:13:36이것은 오픈 소스 메인테이너들에게 큰 문제입니다.
00:13:39또한 단순히 GitHub 어디에서나
00:13:43GitHub Copilot이 존재한다는 사실 그 자체도 문제죠.
00:13:44GitHub에는 'Agent HQ'라는 것이 있습니다.
00:13:48[github.com/copilot](https://github.com/copilot) 페이지인데요,
00:13:49여기서 GitHub Copilot과 소통하며
00:13:52코드 작업을 할 수 있습니다. GitHub Copilot 내부에서 직접요.
00:13:55로컬 IDE나 코딩 에이전트 도구를 열 필요도 없습니다.
00:14:00그 외에도 정말 많은 부분이 바뀌었습니다.
00:14:02GitHub Copilot은 GitHub의 모든 곳에 있습니다.
00:14:05마치 마이크로소프트의 모든 제품에
00:14:07Copilot이 들어있는 것과 마찬가지인 것 같네요.
00:14:10그리고 그것은 분명 전략적인 결정이지만,
00:14:14GitHub 본연의 사명과는
00:14:19다소 어긋나는 방향입니다. 적어도 과거의 사명과는요.
00:14:23서두에서 언급했듯이,
00:14:25GitHub는 다양한 유형의 개발자들과
00:14:29온갖 사용 사례에 있어 중요하기 때문입니다.
00:14:31오픈 소스 메인테이너들은 소스 코드를 호스팅하고
00:14:36다른 메인테이너들 및 커뮤니티의
00:14:39다른 기여자들과 협업하기 위해 이것을 사용합니다.
00:14:41이슈(Issues) 기능은 문제를 감지하고
00:14:45해결하는 데 필수적입니다.
00:14:46풀 리퀘스트(Pull Requests)는 다른 사람들이
00:14:50코드베이스에 기여하게 만드는 데 중요합니다.
00:14:52토론(Discussions)은 새로운 기능이나
00:14:55저장소나 라이브러리의 방향성을 논의하기에 좋습니다.
00:15:01여기에는 오픈 소스 메인테이너들에게
00:15:03도움이 되는, 혹은 적어도 과거에
00:15:04도움이 되었던 많은 기능이 있습니다.
00:15:07어떤 사람들은 GitHub를 단순히
00:15:11링크나 문서를 저장하는 용도로 씁니다.
00:15:13'Awesome Go', 'Awesome Rust' 같은 저장소들처럼요.
00:15:17Go나 Rust로 작업하고 싶을 때
00:15:20필요한 리소스를 쉽게 찾을 수 있는 곳이죠.
00:15:22저 역시 강의 자료를 호스팅하는 데 GitHub를 씁니다.
00:15:26제 Codex 강의나
00:15:29다른 많은 강의들처럼 말이죠.
00:15:31그러니 GitHub를 일종의
00:15:33문서 저장소로 활용할 수도 있는 셈입니다.
00:15:36그리고 당연히 CI/CD 작업에도 GitHub를 사용할 수 있습니다.
00:15:40기업에서는 소스 코드를 관리하고,
00:15:43팀원들이 풀 리퀘스트 등을 통해
00:15:46해당 소스 코드에서 협업하도록
00:15:50GitHub를 사용할 것입니다.
00:15:52또한 GitHub는 매우 빈번하게
00:15:54CI/CD 파이프라인의 일부로 활용됩니다.
00:15:57예를 들어 메인 브랜치에 새로운 푸시가 발생하면
00:15:59CI/CD 파이프라인이 트리거되는 식이죠.
00:16:02GitHub Actions의 도움을 받을 수도 있겠지만,
00:16:05그 제품 자체도 나름의 문제를 안고 있습니다.
00:16:08물론 GitHub Actions뿐만 아니라 다른 어떤
00:16:12CI/CD 제공업체에서도 파이프라인을 트리거할 수 있습니다.
00:16:16따라서 GitHub는 전형적인 전통적
00:16:20개발 작업에서 매우 중요한 역할을 합니다.
00:16:24하지만 마이크로소프트는 아니라고 결정했습니다.
00:16:27단순한 개발자 플랫폼이 아닌,
00:16:31AI 기반 개발자 플랫폼이 되어야 한다고 말이죠.
00:16:33그리고 이것은 일종의 불일치를 만들어냅니다.
00:16:37개발자들이 GitHub의 모든 측면에
00:16:41반드시 Copilot이 있기를 원하는 것은 아니니까요.
00:16:43일반적인 마이크로소프트 제품 사용자들도
00:16:46모든 제품에 GitHub가 들어가는 걸 원치 않을 겁니다.
00:16:48뭐, 그건 다른 이야기이긴 합니다만.
00:16:49결과적으로 GitHub는 개발자들에게 중요한
00:16:53핵심 기능들을 소홀히 해왔습니다.
00:16:56오픈 소스 개발 작업을 예로 들어보죠.
00:17:00오픈 소스 프로젝트 유지 관리자들은
00:17:03AI가 생성한 이슈와 풀 리퀘스트에 파묻히고 있습니다.
00:17:07여기서 문제는 물론 비대칭성입니다.
00:17:10AI를 사용해 코드나 이슈를 생성하는 것은 쉽습니다.
00:17:14하지만 그 모든 것을 검토하는 것은 훨씬 더 어렵죠.
00:17:19생성된 코드와 이슈들을 일일이 검토해야 하니까요.
00:17:24AI와 함께 작업해 본 개발자라면
00:17:26누구나 아는 사실입니다.
00:17:27AI 에이전트를 3개 이상 가동해서
00:17:30프로젝트를 수행하게 만드는 건 아주 쉽습니다.
00:17:32GitHub 외부에서도 충분히 가능하죠.
00:17:33개인 컴퓨터에서 Codec이나,
00:17:35Claude Code 등을 사용하면 됩니다.
00:17:36하지만 코드를 그냥 덮어쓰는 방식을 택하지 않는다면,
00:17:39제 생각엔 그래선 안 된다고 보지만요,
00:17:41결국 어느 시점에는 그 코드를 검토해야 합니다.
00:17:44그리고 거기엔 시간이 걸리죠.
00:17:45적어도 저에게는 그리 즐거운 일은 아닙니다.
00:17:48자, 에이전트 3개를 가동했다면,
00:17:51그 3개 에이전트의 결과물을 모두 검토해야 합니다.
00:17:54부담이 너무 크거나 생산성이 떨어진다고 느껴지면
00:17:57에이전트의 수를 줄일 수도 있겠죠.
00:17:59그건 본인의 선택입니다.
00:18:00하지만 GitHub의 오픈 소스 유지 관리자라면,
00:18:03AI가 생성한 이슈와 풀 리퀘스트에 파묻히게 되고
00:18:07보통 두 가지 주요 선택지에 놓입니다.
00:18:09그냥 무시할 수도 있지만, 그러면 기능 자체가 무색해지죠.
00:18:13물론 그것도 하나의 유효한 전략이긴 합니다.
00:18:16아니면 그 산더미 같은 일들을 처리하려다
00:18:18번아웃이 오겠죠. 양이 너무 많으니까요.
00:18:21개인적인 개발 작업과는 달리,
00:18:25유지 관리자는 쏟아지는 이슈와
00:18:29풀 리퀘스트의 양을 조절할 수 없습니다.
00:18:30자신의 에이전트라면 효과가 없거나
00:18:33생산성이 낮다고 판단될 때
00:18:36사용하는 에이전트 수를 줄이면 그만입니다.
00:18:38하지만 공개 저장소에서는 그럴 수 없습니다.
00:18:41얼마나 많은 사람이 AI로 생성한 이슈를 올리거나
00:18:45풀 리퀘스트를 보낼지 제어할 수 없기 때문입니다.
00:18:49이는 오픈 소스 유지 관리자들에게 매우 큰 문제입니다.
00:18:53오픈 소스 씬 전체와
00:18:56그 이면의 철학이
00:18:59현재 AI 때문에 심각한 위기에 처한 이유이기도 하죠.
00:19:04그리고 GitHub은 이 문제를 돕지 않고 있습니다.
00:19:06오히려 정반대 행보를 보이고 있죠.
00:19:08그들은 적극적으로 AI가 양산한 저질 이슈들이
00:19:13더 쉽게 공유될 수 있게 만들고 있습니다.
00:19:15유지 관리자와 개발자들에게 정말 필요한 것은
00:19:18이러한 AI 생성 이슈와 풀 리퀘스트를
00:19:22더 효과적으로 처리할 수 있는 도구입니다.
00:19:25하지만 GitHub은 그런 작업을 하고 있지 않습니다.
00:19:27그들의 전략에는 포함되어 있지 않은 것 같네요.
00:19:29물론 상황이 변할 수도 있습니다.
00:19:30앞서 언급한 GitHub의 공식 게시물은
00:19:35주로 안정성과 업타임 문제를 다루고 있으며,
00:19:39더 투명해지겠다는 등의 내용을 담고 있습니다.
00:19:41개발자들을 지원하겠다는 약속도
00:19:44언급하긴 했습니다.
00:19:46지켜봐야겠지만, 전 그리 낙관적이지 않습니다.
00:19:49결국 GitHub은 Microsoft의 일부이고,
00:19:52그들만의 독자적인 전략이 있기 때문입니다.
00:19:55그렇다면 이것이 GitHub에게 무엇을 의미할까요?
00:19:59이제 다른 곳으로 떠나야 할 때일까요?
00:20:02X(트위터) 여기저기서
00:20:05이제 GitHub의 대안이 필요하다는 목소리가 들립니다.
00:20:08이미 떠나버린 프로젝트들이 있다는 것도 압니다.
00:20:12ZIG가 아마 가장 대표적인 사례일 겁니다.
00:20:15그들은 2025년 11월에 GitHub에서 Codeberg로 이전했습니다.
00:20:20하지만 냉정하게 현실을 따져봅시다.
00:20:22우선 제가 전에 말씀드렸듯이,
00:20:24GitHub에 몰리는 엄청난 양의 트래픽은
00:20:28그 어떤 경쟁 플랫폼도 감당하기 힘들 겁니다.
00:20:31Microsoft의 지원을 받지 못하는 경쟁사라면
00:20:32GitHub보다 상황이 더 나쁠 가능성이 큽니다.
00:20:35따라서 GitHub이 대체되는 일은 절대 없을 겁니다.
00:20:40일부 개별 프로젝트들,
00:20:42특히 충분히 이해할 만한 이유로
00:20:45오픈 소스 프로젝트들이 GitHub을 떠날 수는 있겠지만,
00:20:48대부분의 기업과 개인 개발자들은
00:20:52떠나지 않을 가능성이 높습니다.
00:20:54여러 문제에도 불구하고 GitHub은
00:20:57수많은 개발자의 워크플로우와 일상 업무에
00:21:02필수적인 풍부한 기능들을 갖춘 플랫폼이기 때문입니다.
00:21:06특히 기업 입장에서는,
00:21:08GitHub을 다른 서비스로 교체하는 것이
00:21:11결코 쉬운 일이 아닙니다.
00:21:13최근의 안정성 문제들이
00:21:15기업들에게도 분명 큰 골칫거리이긴 하지만,
00:21:18그들은 이전을 고려하기까지
00:21:23훨씬 더 많은 고통을 기꺼이 감내할 것입니다.
00:21:25저는 그렇게 확신합니다.
00:21:26GitHub은 이미 너무나 중요한 플랫폼이 되었습니다.
00:21:30Git으로 관리되는 코드를 클라우드에 올리고
00:21:35작업하며 협업하기 위한 독보적인 플랫폼이니까요.
00:21:39그래서 상황이 더 악화되더라도
00:21:43쉽게 사라지지는 않을 것이라 확신합니다.
00:21:45물론 GitHub이 아무런 조치도 취하지 않는다면
00:21:47결국 사람들은 떠나가겠지만,
00:21:49적어도 업타임과 안정성 문제에 대해서는
00:21:50분명히 대응을 하고 있습니다.
00:21:55오픈 소스 작업과 AI 기반의 저질 이슈 문제는
00:21:58좀 더 지켜봐야 할 것 같습니다.
00:22:01그럼에도 불구하고 GitHub은 너무나 중요하며,
00:22:07오픈 소스 유지 관리자들에게 제공하는 이점이 많아서
00:22:10모두가 한꺼번에 떠나기는 어려울 것입니다.
00:22:14다만 개별 프로젝트들이 GitHub을 떠나는 것은
00:22:17충분히 이해하며, 실제로 일어날 수 있는 일입니다.
00:22:20하지만 기업들과 GitHub이라는 플랫폼 전체는
00:22:23여전히 건재할 것입니다.
00:22:24그럼에도 지금의 이 상황이
00:22:28Microsoft에게 일종의 경종이 되기를 바랄 뿐입니다.
00:22:33아마도 GitHub을 전담할 CEO를 다시 임명하겠죠.
00:22:38그들도 GitHub의 중요성을 이해할지 모릅니다.
00:22:41GitHub이 AI 플랫폼이기 이전에
00:22:45개발자와 개발을 위한 플랫폼이라는 점을 말이죠.
00:22:49하지만 뭐, 그저 희망 사항일 뿐입니다.
00:22:52그런 일이 실제로 일어날지는 알 수 없죠.
00:22:55어쨌든 이것이 현재 GitHub이 처한 상황입니다.
00:23:00상태가 좋지 않습니다. 정말 좋지 않아요.
00:23:03당분간은 이런 상황이 지속되겠지만,
00:23:06적어도 서비스 안정성만큼은 올해 안으로
00:23:11더 나아지기를 희망해 봅니다.
00:23:13두고 봐야 알 수 있겠네요.