GitHub 머지 큐(Merge Queue) 오류, 658개 저장소(Repository)에 치명타!

GitHub 머지 큐(Merge Queue) 오류는 불완전한 기능 플래그(Feature Flag)로 인해 발생했다. 새로운 머지 베이스(Merge Base) 계산 코드가 기능 플래그(Feature Flag)에 의해 완전히 제어되지 않아, 특정 조건(Squash Merge + Multi-PR)에서 의도치 않게 실행된 것이다. 특히, 스쿼시 머지(Squash Merge)를 사용하는 경우, 잘못된 머지 베이스(Merge Base)로 인해 이전 풀 리퀘스트(Pull Request)의 변경 사항이 손실되는 문제가 발생했다. 이는 코드 변경 사항의 무결성(Code Integrity)을 심각하게 훼손하는 결과를 초래했다.

GitHub의 모니터링 시스템은 가용성(Availability)을 감지하는 데 초점을 맞추었지만, 코드 무결성(Code Integrity)을 검증하는 데 실패했다. 즉, 서비스의 요청 처리량, 지연 시간, 오류율 등은 정상적으로 유지되었지만, 머지된 코드의 내용이 올바른지 확인하는 기능은 부재했다. 가용성 모니터링(Availability Monitoring)은 서비스 중단을 감지하지만, 데이터의 정확성(Data Accuracy)을 보장하지 못한다는 점을 시사한다. 따라서, 가용성(Availability)뿐만 아니라 데이터 무결성(Data Integrity)을 위한 검증 시스템 구축이 필요하다.

이번 오류로 인해 658개의 저장소(Repository)와 2,092개의 풀 리퀘스트(Pull Request)가 영향을 받았다. GitHub는 문제 발생 후, 코드 변경 사항을 롤백(Rollback)하고, 영향을 받은 저장소(Repository) 관리자에게 복구 지침을 제공했다. 하지만, 자동 복구가 불가능한 경우도 발생하여, 수동적인 수정 작업이 필요했다. 이는 자동화된 시스템(Automated System)의 한계와 수동 개입(Manual Intervention)의 필요성을 보여준다. 또한, 데이터 격리 아키텍처(Data Isolation Architecture) 부재는 피해 범위를 더욱 확대시켰을 수 있다.

이번 사건을 통해, 기능 플래그(Feature Flag)의 정확한 적용과 테스트 전략의 중요성이 강조된다. 기능 플래그(Feature Flag)는 모든 코드 경로를 포괄해야 하며, 특정 조건에서만 발생하는 오류를 감지하기 위해서는 다양한 조합의 테스트가 필요하다. 특히, 스쿼시 머지(Squash Merge)와 같이 특정 설정에서만 발생하는 문제를 파악하기 위해서는, 교차 테스트(Cross-Product Testing)가 필수적이다. 또한, 데이터 미저장 정책(Zero-Retention Policy)을 통해 잠재적 피해를 최소화할 수 있다.