Hacker News 의견들

• 이번 Cloudflare 장애는 단순한 Lua 버그가 아니라, 근본적인 아키텍처 문제를 드러낸 사건임
  원래의 분산형 웹 구조는 이런 전역 장애에 훨씬 강했음. 반면 Cloudflare처럼 동질적인 중앙집중형 시스템은 한 번의 실수로 전 세계 서비스가 동시에 멈출 수 있음. Rust로 짜도 사람은 실수함. 결국 견고한 설계가 중요함

  • 결국 Cloudflare나 AWS 같은 거대 사업자에 의존할수록 웹의 안정성이 떨어진다는 뜻임
  • “말벌 1,000마리 vs 개 1마리” 비유처럼, 전역 장애든 지역 장애든 고통의 형태만 다를 뿐임. Cloudflare가 멈추면 수백 명의 엔지니어가 즉시 대응하지만, 내 서버가 멈추면 담당자는 산속 별장에 있을 수도 있음
  • 독점이 나쁘다는 논의는 제쳐두고, Cloudflare의 장기적 가동률을 보면 오히려 개별 사이트가 직접 인프라를 운영하는 것보다 낫다고 봄. 모든 서비스가 동시에 1시간 멈추는 게, 각각 따로따로 1시간씩 멈추는 것보다 사용자 입장에서는 낫다는 논리임. 다만 Cloudflare의 안정성이 평균 이하로 떨어진다면 그 가치는 사라짐
  • 초당 8천만 요청을 처리하는 규모라면, 애초에 하나의 제품이 이렇게 커지는 구조 자체가 문제라고 생각함
  • Cloudflare는 여전히 전 세계 어디서나 가장 빠르게 글로벌 인프라를 복구하는 회사 중 하나임. 이번에도 28% 네트워크 장애를 25분 만에 해결했고, 다른 클라우드보다 다운타임이 객관적으로 적음

• 어젯밤 Cloudflare 500 오류를 여러 사이트에서 봤음. 그런데 상태 페이지에는 아무 언급이 없고, 예정된 유지보수 공지만 있었음

  • 대부분의 상태 페이지가 그렇듯, 실제 문제를 인식하고 업데이트하기까지 시간이 걸림. 완전 자동화되기 전까지는 Cloudflare도 예외가 아님. 더 걱정되는 건 최근 AWS, Azure, Cloudflare가 연달아 다운된 점임. 내 직감으로는 LLM 사용 증가, 인력 부족, 팬데믹 여파, 정치적 불안 등이 복합적으로 작용하는 듯함
  • 이런 상태 페이지 문제는 공개적인 비판을 통해서만 개선될 것 같음. “Cloudflare는 장애 감지조차 제대로 못 한다”는 피드백이 많아져야 함

• Cloudflare의 품질 엔지니어링이 생산 속도를 따라가지 못하는 듯함. 예전 방산업계에서는 품질팀이 항상 더 숙련됐다고 들었는데, 소프트웨어 업계는 반대인 것 같음

  • 방산업계에서도 메모리 누수를 알고도 “사용 시간 내엔 문제없다”며 무시한 적이 있었다는 일화가 떠오름
  • 이런 일이 한 달에 두 번 일어났는데 “칭찬할 일”은 아님. 반복은 변명의 여지가 없음

• 인터넷의 패킷 스위칭 구조는 원래 이런 전역 장애를 견디도록 설계된 것임.
  냉전 시절 DARPA 네트워크는 핵 공격 상황에서도 지휘 체계를 유지하려는 목적이 있었음.
  지금이야말로 인터넷의 로컬 우선(local-first) 패러다임으로 돌아가야 할 때임

  • 참고: The Real Internet Architecture
  • 참고: Local-first software

• 최근 Cloudflare가 인터넷을 더 느리고 불편하게 만들고 있다고 느낌. “당신이 인간임을 증명하세요” 같은 절차가 늘었고, 페이지 로딩도 지연됨.
  이는 사이트 보호보다는 AI 크롤링 과금 정책 때문인 듯함 (Pay-per-crawl 소개)

  • 이런 인간 인증 절차가 구형 브라우저와 호환되지 않아, 아예 접근이 불가능한 사이트도 생김
  • 하지만 AI가 무단으로 콘텐츠를 긁어가는 것도 문제임. Cloudflare는 사이트 주인에게 콘텐츠 보호 옵션을 제공하는 셈이고, 원치 않으면 끌 수도 있음
  • “이제는 우리를 몰래 감시조차 못 하네”라는 냉소도 나옴

• Cloudflare의 전역 설정 시스템이 점진적 롤아웃 없이 몇 초 만에 전체 네트워크로 퍼지는 구조라 위험함.
  설정 변경이 오류를 일으킬 때 즉시 상관관계를 파악할 수 있는 체계가 필요함

  • 문제는 경보가 너무 늦게 울린 것임. 2분 만에 알림이 왔는데, 초 단위로 감지했어야 함.
    배포 담당자는 실시간 지표를 보며 즉시 롤백 버튼을 눌렀어야 함.
    코드 라인까지 명확히 로그에 찍혔는데, 배포팀과 코드 이해팀이 단절돼 있었던 듯함
  • 경고 신호를 보고 롤백을 시도했는데, 그 과정이 오히려 문제를 일으킨 것으로 보임
  • 내부 도구는 종종 오탐지가 많고, 스스로 깨져 있는 경우도 많음
  • “엔진 경고등이 계속 켜지길래 그냥 전구를 뽑았다”는 농담처럼 들림

• Cloudflare의 가동률이 99.9% 아래로 떨어졌음. 내 집 PC보다 못한 수준임

  • AWS도 마찬가지임. 클라우드의 존재 이유가 “더 높은 가용성”인데, 비싸고 불안정하다면 직접 호스팅할 이유가 충분함
  • 하지만 자가 호스팅은 하드웨어 고장이나 백업 실패 시 복구에 며칠 걸릴 수도 있음
  • 지역 정전이 잦은 곳에서는 노트북과 배터리로 버티기도 힘듦. 가끔은 자급자족형 인프라를 꿈꾸기도 함
  • 현재 Cloudflare의 정확한 업타임 통계를 어디서 확인할 수 있는지 궁금함
  • 그래도 개인 PC와 Cloudflare를 단순 비교하는 건 무의미한 비유임

• Cloudflare 규모라면 반드시 테스트 환경이 있어야 함.
  모든 변경은 격리된 모델 환경에서 시뮬레이션 후 점진적으로 배포해야 함.
  강한 타입 시스템보다 중요한 건 절차적 안전장치임

  • 우리 회사는 세 단계 배포 체계를 씀: 개발 → 내부 통합 → 프로덕션.
    실수 잦은 팀은 속도를 늦추고, 신뢰도 높은 팀은 빠르게 진행함.
    결국 기술적 속도는 선택의 문제임. SLA 위협이 생기면 속도를 줄이고 테스트를 강화해야 함
  • 무료 사용자들을 테스트 베드로 삼고, 유료 고객에게는 안정된 버전을 제공하는 것도 방법임
  • “강한 타입 시스템이 널 구해주지 않는다”는 말은, 절차적 실패 앞에서는 언어가 무력하다는 뜻임

• Cloudflare의 소프트웨어 품질이 흔들리는 듯함.
  엔터프라이즈 전용 기능의 접근 검증이 마지막 단계에서만 이뤄지는 버그도 있었음

  • 나도 Cloudflare API에서 롤백이 불가능한 설정을 경험했음.
    지원팀을 거쳐야만 변경 가능했고, 수정까지 며칠 걸렸음
    관련 사례 링크
  • 이런 버그는 AI가 작성한 코드일 가능성도 있다고 봄
  • “마지막 단계에서만 체크한다”는 게 무슨 뜻인지 더 구체적으로 듣고 싶음

• Cloudflare의 운영 문화가 궁금함.
  보안 이슈 대응 중 오류가 발생했는데, 롤백 대신 전역 배포를 또 진행했다는 건 위험한 결정임.
  “의심스러우면 롤백하라”는 기본 원칙을 어긴 셈임

  • 다만 이번은 React Server RCE 취약점 대응처럼 긴급한 상황이었음.
    배포를 늦추면 고객이 실제로 해킹당할 수 있었기에, 속도가 곧 보안이 되는 케이스였음
  • 롤백이 항상 정답은 아님. 절차가 익숙하지 않으면 그 자체가 리스크가 됨
  • 사실 두 번의 배포는 서로 다른 컴포넌트였음.
    첫 번째 수정이 두 번째의 잠재 버그를 드러낸 셈이라, 롤백보다 전진 배포(roll forward) 가 더 현실적일 때도 있음
  • Cloudflare는 빠른 성장 속에서 기술 부채를 쌓아왔을 가능성이 큼.
    최근의 잦은 장애는 그 부채가 드러나는 신호일 수 있음