본문으로 건너뛰기
피드

Waterfox: "우리는 AI 안 넣음" - Mozilla의 AI 퍼스트 전략에 대한 반박

frontend 약 4분
vote
0
댓글
북마크

Waterfox 창립자가 Mozilla의 AI 중심 전략을 정면 반박하며, ML과 LLM의 차이, 브라우저에 LLM을 넣으면 안 되는 이유, Waterfox는 절대 LLM을 탑재하지 않겠다고 선언한 글

  • 1

    Mozilla 새 CEO가 AI를 브라우저 중심에 놓겠다고 선언

  • 2

    ML(Bergamot 번역)은 투명하고 감사 가능하지만 LLM은 블랙박스

  • 3

    브라우저는 user agent인데 LLM 넣으면 user agent의 user agent가 됨

  • 4

    AI 옵셔널이라는 말 자체가 깊이 내장되어 있다는 반증

  • 5

    Mozilla가 10년간 일반 사용자 추격하며 기술 커뮤니티 이탈시킨 전략 반복

  • 6

    Waterfox는 LLM 절대 미탑재 선언

Mozilla의 AI 전환, 뭐가 문제인가

  • Mozilla 새 CEO가 "세계에서 가장 신뢰받는 소프트웨어 기업"을 내세우면서 AI를 중심에 놓겠다고 선언했는데, Waterfox 창립자(15년간 Waterfox 개발)가 이건 근본적인 실수라고 정면 반박한 글임
  • ML과 LLM은 다른 거라는 게 핵심 주장임. Bergamot 같은 로컬 번역 엔진은 입력/출력이 명확하고 감사 가능한 반면, LLM은 블랙박스라서 데이터로 뭘 하는지 검증 자체가 불가능하다는 거임
  • 브라우저는 원래 "user agent"인데, 여기에 LLM을 끼얹으면 "user agent의 user agent"가 되는 셈임. AI가 사용자와 웹 사이에서 중재자 역할을 하면서 탭 정리하고, 히스토리 재구성하고, 보이는 콘텐츠를 맘대로 조작하게 됨

"선택 사항"이라는 약속의 함정

  • Mozilla가 "AI는 언제든 끌 수 있다"고 하지만, 그 말 자체가 AI를 브라우저 깊숙이 내장하니까 옵트아웃이 필요하다는 뜻이라는 거임
  • 블랙박스를 켜놓은 상태에서 뭘 하는지 일일이 감시하는 인지적 부담이 엄청나다는 지적임. 꺼도 문제, 켜도 문제인 상황
  • Mozilla는 10년 넘게 일반 사용자 쫓아가는 전략을 폈는데 시장 점유율은 계속 떨어졌음. 텔레메트리, Pocket, 스폰서 콘텐츠 추가할 때마다 핵심 기술 커뮤니티만 이탈했는데 또 같은 실수를 반복하는 거임

Waterfox의 입장

  • Waterfox는 LLM을 절대 탑재하지 않겠다고 선언함. "Full stop." 현재 형태로든, 가까운 미래든 안 넣는다는 거임
  • Firefox 포크 생태계 중 상당수가 법인도 없고, 개인정보처리방침도 없고, 이용약관도 없다는 점을 지적함. Waterfox는 법인과 공식 정책을 유지하고 있어서 Widevine 같은 DRM 스트리밍 서비스 접근도 가능했다는 거임
  • "AI 브라우저가 세상을 집어삼킬 수도 있지만, 사용자들이 더 단순하고 신뢰할 수 있는 걸 원하게 되면 Waterfox는 여전히 여기 있을 것"이라는 게 결론임
  • XUL 확장 지원 유지, 텔레메트리 제거 등 Mozilla가 버린 것들을 Waterfox가 계속 지켜온 트랙레코드를 강조하면서, 브라우저의 역할은 사용자를 대신해서 생각하는 게 아니라 사용자를 위해 봉사하는 거라고 마무리함

브라우저에 LLM을 넣는 것이 user agent 본질과 충돌한다는 구조적 비판이 흥미로움. 포크 생태계의 거버넌스 문제도 짚음.

댓글

댓글

댓글을 불러오는 중...

frontend

요즘 픽셀 폰트가 그냥 복고 감성이 아닌 이유

1990년대 기기 화면 느낌을 현대 폰트 시스템으로 재해석한 픽셀 폰트 몇 가지를 소개한 글이다. 핵심은 예쁜 복고풍 글자 모양만이 아니라, 실제 제품에서 쓸 수 있게 기준선, 자간, 메타데이터, 세로 메트릭까지 챙기는지가 중요하다는 점이다.

frontend

HTML의 `<dl>`이 생각보다 쓸모 많은 이유

이 글은 HTML의 description list, 즉 `<dl>`, `<dt>`, `<dd>`가 단순 용어 사전용 태그가 아니라 이름-값 쌍 UI를 표현하는 꽤 강력한 시맨틱 도구라고 설명한다. 숙소 편의시설, 요금 내역, 기술 용어 설명, 게임 능력치표처럼 흔한 패턴을 중첩 `<div>` 대신 의미 있는 HTML로 만들 수 있다는 얘기다.

frontend

HTML을 캔버스 안에 넣는 데모 모음이 등장함

구글 크롬 랩스 저장소에 HTML-in-Canvas 관련 데모와 프레임워크 지원 목록이 정리됐다. Duck Hunt 스타일 폼, 흔들리는 버튼, 셰이더 기반 페이지 전환, 천처럼 매달린 폼 같은 실험적 예제가 포함돼 있고 Three.js와 PlayCanvas 쪽 샘플도 연결돼 있다.

frontend

싱글 페이지 앱이 웹을 너무 비싸게 만들었다는 불평

이 글은 싱글 페이지 앱(SPA)이 사용자 경험을 좋게 만든다는 명분 아래 웹의 초기 로딩 비용, 도구 복잡도, 개발 진입 장벽을 키웠다고 비판한다. 페이스북 로그인 페이지의 CSS 3.8MB, 레딧 몇 개 클릭 후 33MB 다운로드 같은 숫자를 들며, 지금의 프론트엔드 생태계가 사람보다 대기업의 요구에 맞춰져 있다고 주장한다.

frontend

네이티브로 끝까지 가려다 텍스트에서 막힌 macOS 개발자의 고백

20년 가까이 macOS와 iOS 네이티브 개발을 해온 작성자가 SwiftUI, AppKit, TextKit 2로 마크다운 채팅 UI를 만들다 결국 WebKit과 Electron 쪽이 훨씬 낫다는 결론에 도달한 글이다. 문제는 성능 하나가 아니라 선택, 스트리밍, 스크롤, 접근성, 텍스트 상호작용 같은 ‘사용자가 당연히 기대하는 기본기’가 네이티브 조합에서 계속 깨진다는 점이다.