개발자라면 누구나 한 번쯤 겪어봤을 상황이 있습니다. 급하게 코드를 푸시해야 하거나, 중요한 PR(Pull Request)을 검토해야 하는데 깃허브(GitHub) 상태 페이지에 빨간불이 들어와 있는 순간입니다. 우리는 즉각적으로 분노합니다. “세계 최고의 코드 호스팅 플랫폼이라는 곳이 왜 이렇게 자주 죽는 거야?”라고 말이죠. 하지만 우리가 믿고 있는 ‘가동률(Uptime)’이라는 지표가 과연 서비스의 실제 건강 상태를 정확히 반영하고 있을까요?

대부분의 사용자는 99.9% 혹은 99.99%라는 숫자에 집착합니다. 소수점 아래의 숫자가 낮아지는 순간 서비스의 품질이 급격히 떨어졌다고 판단하기 때문입니다. 하지만 엔지니어링의 세계에서 100%에 가까운 가동률을 유지한다는 것은 단순히 기술적인 문제를 넘어, 엄청난 비용과 기회비용의 포기를 의미합니다. 깃허브의 가끔 발생하는 다운타임은 어쩌면 더 거대한 시스템의 안정성과 혁신을 위해 지불하고 있는 ‘합리적인 비용’일지도 모릅니다.

가동률 지표가 우리를 속이는 방법

우리가 흔히 보는 가동률 통계는 매우 단순한 산술 평균에 기반합니다. 전체 시간 중 서비스가 작동한 시간의 비율을 계산하는 방식이죠. 하지만 이 수치에는 치명적인 맹점이 있습니다. 바로 ‘장애의 깊이’와 ‘영향 범위’를 무시한다는 점입니다.

예를 들어, 전 세계 모든 사용자가 10분 동안 접속하지 못한 완전한 중단(Total Outage)과, 특정 지역의 일부 사용자가 1시간 동안 느린 응답 속도를 경험한 부분적 장애(Partial Degradation)는 가동률 수치상으로는 비슷하게 계산될 수 있습니다. 하지만 실제 사용자 경험과 비즈니스에 미치는 영향은 완전히 다릅니다. 깃허브와 같은 초거대 플랫폼은 수억 개의 리포지토리와 복잡한 마이크로서비스 아키텍처로 얽혀 있습니다. 모든 기능이 100% 작동하는 상태를 유지하는 것보다, 핵심 기능(코드 저장 및 조회)은 살리되 부가 기능(알림, 액션 등)의 일시적 장애를 허용하는 ‘우아한 성능 저하(Graceful Degradation)’ 전략이 훨씬 효율적입니다.

완벽한 무중단을 포기했을 때 얻는 이득

만약 깃허브가 단 1초의 다운타임도 허용하지 않는 극단적인 가용성 목표를 세웠다면 어떤 일이 벌어졌을까요? 아마도 우리는 지금처럼 빠르게 업데이트되는 새로운 기능들을 만나지 못했을 것입니다. 시스템의 가용성을 극단적으로 높이려면 다음과 같은 제약이 따릅니다.

• 보수적인 배포 주기: 작은 변경 사항 하나가 전체 시스템을 무너뜨릴 수 있다는 공포 때문에, 새로운 기능을 배포하는 주기가 매우 길어집니다.
• 과도한 리소스 중복: 모든 컴포넌트를 다중화하고 실시간 동기화를 유지하기 위해 천문학적인 인프라 비용이 투입됩니다.
• 복잡성의 증가: 무중단 배포를 위한 정교한 오케스트레이션 도구들이 추가되면서, 오히려 시스템의 복잡도가 올라가 예상치 못한 지점에서 치명적인 버그가 발생할 확률이 높아집니다.

결국 깃허브는 ‘완벽한 가동률’이라는 숫자 놀음 대신 ‘빠른 회복 탄력성(Resilience)’을 선택한 것입니다. 장애가 발생하지 않게 막는 것이 아니라, 장애가 발생했을 때 얼마나 빠르게 감지하고 복구하느냐에 집중하는 SRE(Site Reliability Engineering) 철학을 실천하고 있는 셈입니다.

실제 사례로 보는 가용성의 트레이드오프

과거 깃허브의 대규모 장애 사례들을 분석해 보면, 대부분의 문제는 단순한 서버 다운이 아니라 복잡한 데이터베이스 마이그레이션이나 네트워크 설정 변경 중에 발생했습니다. 이는 깃허브가 멈춰 서 있는 것이 아니라, 더 나은 인프라로 나아가기 위해 ‘위험한 도약’을 계속하고 있다는 증거이기도 합니다.

반면, 극도로 보수적인 가동률을 유지하는 금융권 시스템이나 의료 시스템을 생각해보십시오. 그곳에서는 기능 업데이트가 매우 느리며, UI/UX의 변화 또한 더딥니다. 깃허브는 개발 도구입니다. 개발 도구의 핵심 가치는 ‘안정성’만큼이나 ‘생산성’과 ‘혁신’에 있습니다. 새로운 GitHub Actions 기능이 추가되고, Copilot이 통합되는 속도는 가끔 발생하는 몇 분의 다운타임보다 개발자 커뮤니티에 훨씬 더 큰 가치를 제공합니다.

기술적 관점에서의 득과 실

가동률 중심의 설계와 회복 탄력성 중심의 설계는 명확한 차이가 있습니다. 이를 간단히 비교하면 다음과 같습니다.

우리가 가져야 할 관점의 변화

이제 우리는 “왜 또 죽었어?”라는 질문을 “이번 장애를 통해 깃허브는 어떤 기술적 부채를 해결하고 있는가?”라는 질문으로 바꿔야 합니다. 서비스가 중단되었을 때 깃허브가 제공하는 투명한 상태 페이지와 사후 분석 보고서(Post-mortem)는 그들이 장애를 숨기지 않고 학습의 기회로 삼고 있음을 보여줍니다.

또한, 이는 개별 개발자와 기업에게도 중요한 교훈을 줍니다. 자신의 서비스에 99.999%의 가용성을 설정하는 것이 항상 정답은 아니라는 점입니다. 비즈니스의 성격에 맞는 ‘에러 예산(Error Budget)’을 설정하고, 그 예산 범위 내에서 과감하게 실험하고 배포하는 문화가 진정한 성장을 만들어냅니다.

실무자를 위한 액션 아이템: 장애에 강한 시스템 만들기

깃허브의 사례처럼, 완벽함보다는 회복력에 집중하고 싶은 엔지니어와 팀 리더들은 지금 당장 다음의 액션 아이템을 실행해 보시기 바랍니다.

• 에러 예산(Error Budget) 도입: 무조건적인 무중단이 아니라, 한 달에 허용 가능한 다운타임 시간을 정의하십시오. 이 예산이 남아 있다면 더 공격적인 배포를 시도하고, 예산을 다 썼다면 안정화 작업에 집중하십시오.
• 관측 가능성(Observability) 강화: 단순한 Up/Down 체크를 넘어, 시스템 내부에서 어떤 일이 벌어지고 있는지 알 수 있는 분산 트레이싱과 상세 로그 시스템을 구축하십시오.
• 카오스 엔지니어링 실천: 시스템이 예상치 못한 상황에서 어떻게 반응하는지 확인하기 위해, 의도적으로 일부 서버를 종료하거나 네트워크 지연을 발생시키는 테스트를 수행하십시오.
• 투명한 사후 분석 문화 정착: 장애가 발생했을 때 담당자를 비난하는 ‘Blame’ 문화가 아니라, 시스템의 결함을 찾아내는 ‘Blameless Post-mortem’ 문화를 만드십시오.

결국 깃허브의 ‘나쁜 가동률’은 역설적으로 그들이 얼마나 역동적으로 움직이고 있는지를 보여주는 훈장과 같습니다. 우리는 완벽한 시스템이 아니라, 끊임없이 진화하는 시스템을 원합니다. 가끔의 멈춤은 더 멀리 뛰기 위한 준비 과정일 뿐입니다.