Ubuntu 서비스가 흔들릴 때, 당신은 그냥 웹사이트 접속이 불편한 사용자일까요. 아니면 Canonical이 잠시라도 멈추면 업데이트, 배포, 복구까지 줄줄이 막히는 환경을 만들어둔 운영자일까요.
이번 장애가 중요한 이유는 여기에 있습니다. Canonical은 "지속적이고 국경을 넘는 공격"을 받았다고 밝혔고, 실제로 ubuntu.com, Launchpad, 로그인, 일부 보안 API, Livepatch, Landscape 등 여러 서비스에 장애가 길게 이어졌습니다.12 Ars Technica를 포함한 복수 보도에 따르면 다운타임은 하루 이상 이어졌고, 일부 환경에서는 Ubuntu 업데이트 실패도 재현됐습니다.3 핵심은 "Ubuntu가 해킹됐느냐"보다, "내 Linux 운영이 특정 벤더의 온라인 가용성에 얼마나 묶여 있느냐"입니다.
Ubuntu가 멈추면 실제로 무엇이 깨지나
사실부터 나누면, 모든 것이 한꺼번에 멈춘 것은 아닙니다. 외부 모니터링 기준으로도 archive.ubuntu.com, security.ubuntu.com, releases.ubuntu.com, cloud-images.ubuntu.com처럼 살아 있던 구성요소가 있었고, 반대로 ubuntu.com, launchpad.net, ppa.launchpad.net, Ubuntu Security API 일부, DNS, Livepatch API 등은 광범위하게 영향을 받았습니다.2 다른 보도에서도 "APT 저장소 전체가 사라진 것"과 "기본 경로나 관련 서비스가 불안정한 것"은 구분해서 다뤘습니다.4
실무적으로는 세 부류가 갈렸습니다.
첫째, 이미 돌아가고 있는 서버. 이런 시스템은 당장 애플리케이션이 멈추지 않을 수 있습니다. 패키지를 새로 설치하지 않고, 외부 인증이나 Livepatch, Snap, PPA에 의존하지 않으면 체감이 작습니다.
둘째, "지금 뭔가를 받아와야 하는" 시스템. apt update, 신규 패키지 설치, CI 빌드, 새 서버 프로비저닝, 클라우드 이미지 풀, WSL 이미지 다운로드가 여기에 걸립니다. 이쪽은 장애가 바로 생산성 손실로 번집니다.35
셋째, 보안 자동화에 기대는 팀입니다. Ubuntu Security API의 CVE·Notice 엔드포인트가 내려가면 취약점 추적, 패치 우선순위 산정, 컴플라이언스 보고가 stale 상태가 됩니다.26 서버는 살아 있어도 "지금 무엇을 고쳐야 하는가"를 알려주는 신호 체계가 죽는 셈입니다.
내 환경의 Ubuntu 의존도는 어느 정도인가
간단히 자가진단해보면 됩니다.
의존도가 낮은 환경은 대개 이렇습니다. 이미 설치된 패키지로 오래 돌고, 배포 때마다 외부 저장소를 새로 치지 않으며, 문서와 운영 절차가 내부에 있고, 필요 패키지를 캐시나 사설 미러에서 가져옵니다. 이런 환경은 Canonical 장애를 "불편"으로 겪습니다.
의존도가 높은 환경은 반대입니다. 데스크톱에서 Snap 비중이 높고, 빌드 파이프라인이 매번 최신 패키지를 외부에서 내려받고, 서버 부팅 직후 cloud-init이 공식 경로를 반드시 때리고, PPA와 Launchpad 없이는 배포가 안 됩니다. 이런 환경은 장애를 "중단"으로 겪습니다.
여기서 반론도 있습니다. "오픈소스 배포판인데 미러도 많고 우회도 가능하니 괜찮지 않나?" 어느 정도 맞습니다. 실제로 Ubuntu는 분산 미러 구조 덕분에 완전 정지는 아니었습니다.4 하지만 운영이 우회 경로를 자동으로 타도록 설계돼 있지 않다면, 우회 가능성은 운영 복원력과 다릅니다. 수동으로 미러를 찾아 바꾸는 건 비상대응이지, 설계가 아닙니다.
오늘 바로 할 수 있는 80/20 복원력 점검
가장 효과가 큰 건 패키지 공급 경로를 둘 이상 확보하는 일입니다. 서버와 CI에 공식 기본값만 두지 말고, 지역 미러나 사설 캐시를 검토하세요. apt-cacher-ng, Nexus, Artifactory 같은 내부 캐시만 있어도 같은 장애의 체감이 크게 줄어듭니다.
두 번째는 "새로 만드는 능력"을 외부 가용성과 분리하는 것입니다. 골든 이미지나 베이스 VM 이미지를 미리 만들어 두면, 장애 중에도 서버 증설과 복구가 가능합니다. 매번 인터넷에서 처음부터 조립하는 방식이 가장 취약합니다.
세 번째는 Snap, PPA, Launchpad 의존도를 적어도 파악하는 것입니다. 전부 없애라는 뜻은 아닙니다. 다만 어떤 워크스테이션과 어떤 배포 절차가 그것 없이는 멈추는지 목록은 있어야 합니다. 대체 deb 패키지, 컨테이너 이미지, 내부 레지스트리 중 무엇으로 우회할지 정해두면 좋습니다.
네 번째는 문서와 상태 확인 경로를 분리하는 것입니다. 공식 상태 페이지 자체가 불안정할 수 있으니 외부 상태 집계 서비스, 사내 런북, 오프라인 문서를 같이 준비해야 합니다.27
마지막으로, unattended-upgrades와 보안 리포트가 장애 시 어떻게 실패하는지 실제로 테스트해보세요. "업데이트가 안 되면 그냥 나중에 다시 하면 되지"가 아니라, 실패 로그가 남는지, 알림이 오는지, 누가 재실행하는지가 중요합니다.
커널 안정성보다 더 먼저 봐야 할 것
이번 일의 교훈은 Linux의 안정성이 커널 uptime만으로 설명되지 않는다는 점입니다. 더 취약한 곳은 패키지 배포, 서명 키 경로, 보안 공지 API, 클라우드 이미지, 로그인, 호스팅 문서 같은 공급망의 가장자리입니다.
Ubuntu를 버리라는 얘기는 아닙니다. 오히려 널리 쓰이는 배포판일수록 "벤더가 잠시 안 보여도 내 운영은 계속되는가"를 점검해야 합니다. 개인 데스크톱 사용자는 미러와 오프라인 문서 정도면 충분할 수 있습니다. 홈랩 운영자는 로컬 패키지 캐시와 백업 이미지를 갖춰두면 체감이 달라집니다. 프로덕션 팀이라면 이제 질문이 바뀌어야 합니다. 우리 시스템은 Ubuntu 위에서 도는가가 아니라, Ubuntu 공급 경로가 끊겨도 계속 굴러가는가.
참고
2Canonical Status. Check if Canonical is down or having an outage. | StatusGator
4Attack knocks Ubuntu websites, services and Snap store offline
5Ubuntu services hit by outages after DDoS attack
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.