풀 리퀘스트, Git 작업, 이슈에서 발생한 장애

요약

GitHub에서 풀 리퀘스트, Git 작업, 이슈가 약 2시간 동안 오류와 지연을 겪었습니다.

GitHub 상태 페이지에 올라온 장애 기록입니다. 11월 4일 9시 49분(UTC 기준)에 조사를 시작했고, 11시 50분에 장애가 해결됐다고 발표했습니다.

왜 중요한가

Git 작업과 Actions가 함께 흔들려 코드 푸시부터 배포 자동화까지 GitHub에 묶인 작업이 모두 영향을 받았습니다.
근본 원인은 아직 공개되지 않았습니다. 재발 여부는 GitHub의 후속 분석을 기다려야 합니다.

핵심 내용

첫 공지는 Git 작업, 이슈, 풀 리퀘스트의 성능 저하 신고를 조사한다는 내용이었습니다.
몇 분 사이 Actions의 성능 저하와 풀 리퀘스트의 가용성 저하(요청 일부가 아예 실패하는 상태)가 더해졌습니다.
11시 11분에는 API 요청도 느려졌고, 복구 중에는 일부 요청이 실패하거나 늦어질 수 있다고 안내했습니다.
11시 30분에 API, Git 작업, 이슈, 풀 리퀘스트가, 11시 43분에 Actions가 차례로 안정을 찾았습니다.
GitHub은 상세한 원인 분석을 나오는 대로 공유하겠다고 밝혔습니다.

HN 반응

여러 이용자는 실제로 문제가 생겨도 상태 페이지가 정상으로 표시될 때가 많아 원인을 찾느라 시간을 허비한다고 불만을 나타냈습니다.
이날 예정된 낡은 SSH 방식(SHA-1을 쓰는 ssh-rsa 서명 등) 차단 시험이 원인일 수 있다는 추측이 나왔지만, 처음 말한 이용자도 확인된 사실은 아니라고 덧붙였습니다.

30개 표시 · 전체 133개

gophigure1일 전 HN

GitOps와 (비교적) 안정적인 GitHub에 의존하는 팀에게 특히 문제라고 생각하는 건, GitHub 상태 페이지를 믿을 수 없다는 점입니다. "이건 GitHub 문제다"라는 결론에 도달했는데 상태 페이지는 그렇지 않다고 하니, 결국 직접 파고들게 됩니다. 그러면 품이 많이 들고 시간도 낭비되는 데다, "근데 상태 페이지는 초록불인데요?" 같은 말과 함께 곱지 않은 시선까지 받게 됩니다.

증상이 있는 환자는 분명히 아픈 사람이지만, 무증상인 경우도 있습니다. 지금 GitHub 상태 페이지가 딱 그렇습니다. 빨간불에 문제가 표시되어 있으면 문제가 있다는 걸 알 수 있습니다. 그런데 전부 초록불이라면요? 문제가 있을 수도 있다는 것만 알 수 있습니다.

현실이 블랙박스이다 보니 이런 장애는 원인을 가려내기가 더 어렵습니다.
ozyschmozy1일 전 HN

"이건 GitHub 문제다"라는 결론에 도달했는데 상태 페이지는 그렇지 않다고 하니, 결국 직접 파고들게 됩니다

전 어떤지 모르겠지만, 저는 이제 GitHub가 아직 인정하지 않았을 때도 문제가 생긴 걸 알아채고 그냥 무시하게 됐어요.
arccy1일 전 HN

그래서 조사를 시작하기 전에 최소 30분은 다 무시하는 겁니다...
chrisjj23시간 전 HN

상태 페이지를 갱신할 때마다 홍보팀의 사전 승인을 받아야 하거든요.
a-squirrel-comm1일 전 HN

오늘 특정 종류의 SSH 키 지원을 중단하는 점검이 예정되어 있었던 것 같습니다: https://github.blog/changelog/2026-09-22-security-improvements-for-ssh/

2026년 11월 4일: ssh-rsa 서명 유형(즉 SHA-1을 쓰는 RSA 키)과 diffie-hellman-group-exchange-sha256 키 교환 알고리즘 제거를 시험 적용하는 브라운아웃을 진행합니다.

뭔가 잘못된 것 같습니다.
qtqtqt1일 전 HN

내 SSH 키가 아직 호환되는지 확인하려면 어떻게 하나요?
dist-epoch1일 전 HN

SSH 키 파일 중에 500바이트가 넘는 게 있으면 교체하세요.
matja1일 전 HN

mldsa44-ed25519도 그런가요?
SkiFire131일 전 HN

큰 건가요, 작은 건가요?
mschuster911일 전 HN

EC 키는 훨씬 작을 텐데... 이건 id_rsa SSH 키에만 해당되는 얘기예요.
anamexis1일 전 HN

그게 핵심이잖아요.
igleria1일 전 HN

와, 이렇게 엄청나게 중요한 정보를 알려주셨는데 얼마를 드리면 될까요? 비꼬는 거 아니에요, 진심입니다.
a-squirrel-comm1일 전 HN

공짜예요 :) 곧 공식 입장이 나오면 좋겠네요. 이건 제 추측이라 완전히 틀렸을 수도 있어요. 로컬에서 기본적인 git pull/push가 간헐적으로 안 돼서 좀 파봤거든요. 추신: 쓸 돈이 남으신다면 EFF( https://www.eff.org )에 기부해 보세요 B)
DanielHB1일 전 HN

하하, GitHub에서 왜 잘못된 키라는 에러가 뜨나 했네요.
igleria1일 전 HN

정말 고맙습니다! 그럴게요.
pksunkara1일 전 HN

이게 정말 장애의 원인이라면, 이번 사고는 사용량 증가 때문이 아니라 GitHub가 스스로 바이브 코딩을 한 결과로 보이네요.

공개: 저도 코드 포지를 만들고 있습니다.
shawabawa31일 전 HN

그건 공개가 아니라 그냥 광고예요.

rarisma1일 전 HN

       - - >  i wake up - -
       |                  |
       |                  V
       github has an outage

GrantMoyer1일 전 HN

확인차 여쭤보는데, GitHub에서 일하시나요?
Chris20481일 전 HN

어쩌면 프로세스나 스레드일지도 모르죠?
lta1일 전 HN

화요일이라 그런 게 분명해요.
dodslaser1일 전 HN

GitHub에 장애가 날 때마다 잠드시나요? 기면증이라도 있으신 건가요?
shepherdjerred1일 전 HN

순서가 반대예요. GitHub가 잠들어서 장애가 나는 거죠.
eknkc1일 전 HN

저희는 배포가 GitHub Actions에 묶여 있는데, 이제는 부담이 되고 있습니다. 다들 어떤 대안을 쓰시나요? FOSS용으로는 괜찮은 게 몇 개 있지만, 비공개 저장소를 맡길 만큼 믿을 수 있는 제공자가 필요합니다.
stack_framer1일 전 HN

저희 회사는 GitLab을 씁니다. 문제라면 풀 리퀘스트를 "머지 리퀘스트"라고 부른다는 건데, "PR" 대신 "MR"이라고 말하는 데에는 영영 익숙해지지 못할 것 같습니다.
jaapz1일 전 HN

GitHub 쓰는 분들은 왜 다들 자기 요청(request)을 끌어당기고(pull) 계신 거죠?

저는 제 변경 사항을 메인 브랜치에 병합해 달라고 요청(request to merge)하는 건데요.
dutchbart1일 전 HN

아니면 당신 변경 사항을 내 브랜치로 pull 해달라고 나한테 요청하는 거거나요.
crote1일 전 HN

git이 아직 분산 방식이던 호시절에는, 머지가 보통 누군가에게 이메일을 보내는 것에서 시작했거든요. 개인 GitWeb 서버의 어떤 URL에서 "gpu-drivers-for-linus" 브랜치를 git pull해서 새로 짠 커밋을 받아 가 달라고요. 즉 코드를 가져가(pull) 달라는 *요청(request)*이었던 거죠.

마찬가지로, GitLab 쓰는 분들은 왜 그렇게 *머지(merge)*를 좋아하는 거죠? "리베이스 리퀘스트"나 "스쿼시 리퀘스트", "체리픽 리퀘스트"는 어디 있나요?
ajasmin1일 전 HN

GitHub PR에서도 여전히 그렇게 할 수 있어요. 브랜치를 로컬로 pull 하고, 코드를 읽고, 이것저것 써 보고, main 위로 리베이스하고...

다 괜찮으면 원격 HEAD로 push 하면 GitHub가 알아서 PR을 닫아 줄 겁니다.

다만 규모가 큰 프로젝트는 최종 upstream 머지를 GitHub 자체에 맡기는 경우가 많죠. 접근 제어도 더 낫고, 활동이 아주 활발한 프로젝트에서는 단일 큐로 머지를 직렬화하기도 더 쉬우니까요.
chrisweekly1일 전 HN

재미있는 옛날이야기네요.

관련해서 하나 덧붙이면, git에서 "pull"은 기본적으로 "fetch + merge"의 줄임말이에요.

Hacker News에서 보기 ↗