Mozilla 격분｜Chrome Prompt API 반대 × 웹 독점의 전모
機械翻訳 / Machine-translated
A
AI Friends
2026年5月2日・18分で読める
機械翻訳 / Machine-translated
@aifriends
AI Friends（https://aifriends.jp）のクロスポスト公式アカウント。AIツールの紹介・使い方・できることを、中学生でもわかるやさしい日本語で届けます。
"Chrome에 AI가 내장되어 편리해진다"——그 흐름에 대해 Mozilla가 진지하게 분노하고 있습니다. 이유는 단순한 반대가 아니라 "이것은 웹의 미래를 좁힌다"는 본질적인 우려입니다.
2026년 4월 30일, Mozilla 공식 표준화 저장소에서 『Prompt API』에 대해 『opposed（반대）』 상태가 명기되며 웹 개발자 커뮤니티에 큰 충격을 안겼습니다. 브라우저에 내장된 AI는 분명 편리하지만, 웹 전체가 Google Gemini Nano라는 특정 모델에 묶일 위험성이 지적되고 있습니다.
이 글에서는 Mozilla가 반대하는 3가지 본질적 이유, Firefox AI Runtime의 대안 설계, Chrome·Firefox·Safari 세 브라우저 비교, 그리고 한국 웹 개발 현장에 미치는 영향까지 차례로 정리합니다.
Mozilla는 자사 GitHub에서 관리하는 『standards-positions』 저장소에서, Google이 Chrome에 도입한 『Prompt API』에 대해 『opposed（반대）』 상태를 부여했습니다. 이는 『support（지지）』 『neutral（중립）』 등 여러 단계 중 가장 부정적인 신호에 해당합니다.
Mozilla의 개발자 릴레이션즈 리드 Jake Archibald는 "상호운용성·업데이트 가능성·중립성에 심각한 악영향이 있다"고 공식 코멘트를 냈습니다. 2026년 4월 30일 The Register가 이를 보도하면서 이 반대 표명은 널리 주목받았습니다. Mozilla는 과거에도 Chrome 전용 API에 반대해 왔지만, 이번에는 특히 강한 표현으로 위험성을 강조하고 있다는 점이 특징적입니다.
반대의 대상이 된 『Prompt API』는 Chrome에 내장된 『Gemini Nano（소형 Google 제작 AI）』를 JavaScript에서 직접 호출할 수 있는 구조입니다. 웹사이트가 "문장을 요약해줘" "번역해줘"와 같은 자연어 명령을 브라우저 내 AI에 보낼 수 있는 기능이라고 생각하면 이해하기 쉽습니다.
Chrome 138 이후 확장 기능 대상으로 『일반 제공（GA）』이 시작되었습니다. 웹 페이지 대상으로는 플래그 활성화 또는 오리진 트라이얼 참가로 이용 가능하며, 텍스트·이미지·음성의 멀티모달 입력을 지원합니다. 클라우드 AI와 통신할 필요가 없어 응답 속도·비용·프라이버시 모든 면에서 장점이 있는 것은 사실입니다. Mozilla가 경고하는 것은 편리함 자체가 아니라 그 너머에 있는 구조적인 문제입니다.
Prompt API는 현재 W3C（World Wide Web Consortium·웹 표준을 결정하는 국제기구）의 『WebML』 커뮤니티 그룹에서 제안 단계에 있습니다. 웹 표준으로 전 세계 브라우저에 채택될 가능성이 있는 사양으로서 논의가 진행 중입니다.
즉 Mozilla의 반대는 『단순한 한 기업의 의견』이 아니라 웹 표준화 프로세스에서 중요한 논점을 제시하는 행위입니다. Apple WebKit（Safari）도 2026년 시점에서 신중한 입장을 보이고 있어, 웹 개발자들에게는 자신들의 업무 미래를 좌우하는 논의가 바로 지금 진행 중인 상황입니다.
Mozilla의 가장 큰 논점은 "프롬프트는 AI 모델 고유의 특성과 정책에 최적화된다"는 성질에 있습니다. Gemini Nano에 맞게 조정한 프롬프트가 다른 브라우저의 다른 AI 모델에서도 동일하게 동작한다는 보장이 없습니다.
실제로 Prompt API의 README 파일 자체에 "브라우저 간 상호운용성은 보장되지 않는다"고 명기되어 있습니다. 이는 웹 표준의 근본 이념에 반한다는 것이 Mozilla의 강력한 비판입니다. 웹사이트를 만드는 입장에서 보면 "Chrome에서는 동작하지만 Firefox에서는 다르게 동작하고 Safari에서는 또 다르다"는 브라우저 호환성 문제——이른바 1990년대 IE 시절의 악몽——이 재현될 가능성을 Mozilla는 강하게 경계하고 있습니다.
두 번째 우려는 특정 모델로의 사실상 록인입니다. Mozilla는 "Gemini Nano가 사실상의 표준이 되면 Apple이나 Mozilla도 호환성을 위해 Nano 라이선스를 구매해야 하는 압력이 생긴다"고 경고합니다. 결과적으로 웹 전체가 Google의 단일 모델에 묶일 위험이 있다는 주장입니다.
AI의 응답은 비결정적（매번 답변이 미묘하게 다름）이기 때문에 개발자는 특정 모델의 "특성"에 최적화할 수밖에 없습니다. 그 결과 Gemini Nano 외에는 동작하지 않는 코드가 양산되는 악순환이 발생합니다. Mozilla는 "Apple이 Nano를 구매할 수밖에 없게 되는 구도는 건전하지 않다"고 업계 전반에 미치는 파급을 우려하고 있습니다.
세 번째 우려는 약관 측면의 종속 관계입니다. Prompt API 이용 시 Google의 『Generative AI Prohibited Uses Policy（생성 AI 금지 용도 정책）』 동의가 필수입니다. 이 정책에는 "불쾌한 콘텐츠 생성" 등 반드시 불법은 아닌 용도까지 금지 항목에 포함되어 있습니다.
Mozilla의 주장은 "웹 표준 API 이용이 특정 기업의 사내 정책에 의존하는 것은 중립성에 반한다"는 것입니다. 달리 말하면 Google의 사내 규칙 변경으로 웹 전체의 동작이 바뀌어버리는 취약한 구조에 대한 경고입니다. 웹은 본래 누구나 자유롭게 사용할 수 있는 공공 인프라로 발전해 왔기 때문에, 특정 기업의 약관에 종속되는 것은 철학적으로도 큰 문제로 보입니다.
Firefox에도 『AI Runtime』이라 불리는 브라우저 내 AI 기능이 존재합니다. 그러나 설계 철학은 Chrome과 결정적으로 다르며, 내부 기능（브라우저 자체가 사용하는 처리）과 확장 기능 대상으로 한정하여 일반 웹사이트에서는 호출할 수 없는 구조입니다.
배경에는 "웹의 중립성을 지키기 위해 브라우저가 AI를 사용하는 것은 괜찮지만, 그것을 Web API로 공개하는 것은 별개의 문제"라는 Mozilla의 철학이 있습니다. 브라우저 내부의 고기능화와 웹 표준으로서의 공개는 선을 나눈다는 신중한 구분입니다. 편의성과 웹 전체의 건전성을 동시에 추구하려는 자세가 드러납니다.
또 하나의 큰 차이는 모델의 투명성입니다. Firefox AI Runtime은 어떤 모델을 사용하는지 개발자·사용자에게 명시적으로 식별할 수 있도록 하는 설계를 채택했습니다. Prompt API가 "어떤 모델이 사용되는지는 브라우저에 따라 다르다"는 모델 비종속 방식을 취하는 것과 대조적입니다.
Mozilla는 "어떤 모델이 응답을 생성하고 있는지 알 수 없으면 개발자는 책임 있는 구현을 할 수 없고, 사용자도 무슨 일이 일어나고 있는지 이해할 수 없다"며 투명성의 중요성을 강조하고 있습니다. 장기적 신뢰성과 설명 책임을 중시하는 철학이 설계 구석구석에 드러납니다.
오해받기 쉬운 부분이지만, Mozilla는 "로컬 AI 처리·오프라인 동작·비용 절감·프라이버시 우위"라는 Prompt API의 장점 자체는 명확히 인정하고 있습니다. AI 브라우저 기능 자체에 반대하는 것이 아닙니다.
Mozilla의 주장은 "웹이 특정 모델·특정 기업에 묶이지 않는 설계를 확보해야 한다"는 점에 집중되어 있습니다. 즉 "반 AI"가 아니라 "반 록인" 입장입니다. 기술의 진보는 받아들이면서도 웹의 개방성이라는 근본 가치를 지키려는 자세가 명확합니다.
Google은 Chrome을 "AI 브라우저"로 재정의하는 전략을 취하고 있습니다. Prompt API 외에도 Summarizer API·Writer API·Rewriter API·Proofreader API 등 여러 AI 기능을 내장하여 Gemini Nano 에코시스템을 구축 중입니다.
2026년 5월 시점에서 Windows 10/11·macOS 13 이상·Linux·ChromeOS에서 동작하며, 시장 점유율 60% 이상의 우위를 활용한 사실상의 표준화 전략을 추진하고 있습니다. 점유율과 개발 리소스로 선행 구현하고 나중에 표준화를 주도한다——는 것이 Google의 일관된 방식입니다.
Mozilla는 웹 전체의 중립성을 지키는 오픈소스 진영의 파수꾼으로 자리매김하고 있습니다. 이번 Prompt API 반대 표명이 그 대표적인 사례로, 브라우저 점유율은 수 %로 낮아졌지만 표준화 논의에서의 영향력은 여전히 큰 존재입니다.
Firefox AI Runtime으로 내부 AI 기능은 구현하면서도 Web API로 공개하지 않는 선을 고수하고 있습니다. 독자적인 브라우저 AI 전략보다 "공정한 표준화"를 우선하는 자세로, Mozilla의 존재 의의는 시장 점유율이 아닌 "웹의 공공성을 지키는 감시자" 역할에 있다고 할 수 있습니다.
Apple의 Safari（WebKit）는 2026년 5월 시점에서 Prompt API 구현 예정이 없으며, Apple Intelligence는 독자적인 온디바이스 AI 전략을 전개하고 있습니다. Web API 통합에 대해서는 신중한 자세를 유지하고 있습니다.
Apple SVP Eddy Cue가 "AI 검색 엔진의 Safari 통합을 적극 검토 중"이라고 발언한 적은 있지만, 독자적인 Apple Intelligence 에코시스템을 우선하며 Google 에코시스템 추종은 피하는 전략입니다. 프라이버시 중시와 독자 에코시스템을 축으로, 웹 표준보다 자사 플랫폼 우선 자세가 명확합니다.
2026년 5월 시점에서 일본의 브라우저 점유율은 Chrome 약 65%·Safari 약 25%·Edge 약 7%·Firefox 약 3%입니다. Prompt API를 사용한 웹사이트는 Chrome 우선 설계가 되기 쉬워, 다른 브라우저에서의 동작 확인·대체 구현 부담이 증가합니다.
대형 EC 사이트·미디어 사이트는 "Chrome용 AI 기능"과 "Safari용 대체 구현"을 이중으로 유지보수해야 할 가능성이 생깁니다. 개발 공수와 테스트 부담이 늘어날 것이 우려되며, 특히 중소 웹 제작사에게는 비용 관리가 어려워지는 현실적인 문제입니다.
지금까지 웹사이트의 AI 기능은 "OpenAI API 등 외부 AI를 클라우드 경유로 호출"하는 구조로, 서버 비용과 API 비용이 무거운 과제였습니다. Prompt API라면 브라우저 내에서 완결되어 비용 없이 실현할 수 있습니다.
대기업은 "비용 절감을 위해 적극 도입하고 싶지만, Mozilla 반대 경고로 표준화 리스크를 의식하게 됐고, Chrome 전용 구현이 되면 나중에 이식이 어렵다"는 딜레마를 안고 있습니다. 비용과 록인의 균형을 어떻게 맞출지가 앞으로 중요한 경영 판단이 될 것입니다.
Prompt API의 "데이터가 브라우저 밖으로 나가지 않는" 특성은 의료·금융·법률 등 기밀성이 높은 업계에 큰 매력입니다. 환자 정보·고객 자산 정보를 클라우드 AI에 전송하지 않아도 되므로 정보 유출 위험을 크게 낮출 수 있습니다.
일본의 의료기관·금융기관은 개인정보보호법·APPI 대응으로 엄격한 제약이 있어, 브라우저 내 로컬 AI는 법적 리스크를 대폭 줄일 수 있는 선택지가 됩니다. Mozilla의 우려와는 별개의 맥락에서, 프라이버시 중시 업계에는 매력적인 기술인 것도 사실입니다.
도내에서 프리랜서 웹 개발을 하는 켄타 씨는 2026년 5월 시점에서 클라이언트로부터 Chrome Prompt API를 이용한 요약 기능 도입을 상담받고 있다고 합니다. "비용 측면에서는 매력적이지만 Mozilla 반대 뉴스 때문에 고민 중"이라는 것이 솔직한 심정입니다.
Firefox·Safari 사용자를 위한 대체 구현을 제안할지, Chrome 전용으로 못을 박을지에 따라 추가 견적이 30% 늘어나는 시산도 있습니다. "표준화가 정착될 때까지 반년 기다리는 것도 선택지"라며 판단에 고민하고 있습니다. 웹 개발자에게는 기술 선정의 어려움이 한층 커진 시대입니다.
지방의 중소 EC 사이트 운영자 사토 씨는 2026년 5월 시점에서 상품 설명 자동 요약·리뷰 번역 등에 AI를 활용하고 싶다고 생각하고 있습니다. "매월 10만 엔의 클라우드 AI 비용이 부담스러운데, Prompt API라면 비용 없이 꼭 도입하고 싶다"는 것이 도입 동기입니다.
"우리 고객의 Chrome 이용자가 7할이니까 일단 구현해서 시험해보고 싶다. Safari·Firefox 사용자는 기존의 대체 표시로 커버한다"는 긍정적인 판단입니다. 중소사업자에게는 비용 절감과 리스크 허용의 현실적인 저울질이 매일 이어지고 있습니다.
IT 기업에 근무하며 웹 리터러시가 높은 미사키 씨는 평소 Firefox를 사용하고 있습니다. "최근 Chrome 전용 기능 사이트가 늘어나 Firefox에서는 기능이 제한된 버전밖에 볼 수 없는 것에 위화감을 느끼고 있다"고 말합니다.
"Mozilla 반대 뉴스를 읽고 '이건 중요한 논의다'라고 느꼈다. 브라우저 선택지가 사실상 빼앗기는 미래는 피하고 싶다. 개인으로서는 Firefox를 계속 응원하고 싶다"는 의견입니다. 기술 선택의 자유가 웹의 미래를 결정하는 중요한 요소임을 사용자 측에서도 실감하는 사람이 늘고 있습니다.
Chrome 138 이후 확장 기능 대상으로 일반 제공（GA）이 시작되었습니다. 웹 페이지 대상으로는 플래그 활성화 또는 오리진 트라이얼 참가가 필요합니다.
멀티모달 기능（이미지·음성 입력）은 오리진 트라이얼 중으로 참가하면 실제 웹사이트에서 테스트할 수 있습니다. Chrome 측의 정식 릴리스 시기는 미정입니다. 동작 환경은 Windows 10/11·macOS 13 이상·Linux·ChromeOS이며, 모델（Gemini Nano）은 초회 이용 시 자동으로 다운로드됩니다.
시험해보고 싶은 개발자는 지금 바로 테스트할 수 있지만, 안심하고 사용하고 싶다면 본격적인 보급을 기다리는 것이 현명합니다.
"웹의 중립성과 브라우저 호환성의 근본을 위협하는 설계이기 때문"이 Mozilla의 본심입니다.
과거 역사에서도 IE 전용 기능·Flash·특정 기업 독자 API 등 웹의 분단을 초래한 사례가 다수 있습니다. Mozilla는 "같은 전철을 밟지 않겠다"는 것을 사명으로 삼고 있습니다. Prompt API는 편의성이 높기 때문에 안이하게 보급되면 "Chrome 전용 웹"이 사실상의 표준이 되어 웹의 개방성이라는 근본 가치가 사라질 위험이 있다——는 것이 반대의 핵심입니다.
장기적 관점에서 보면 Mozilla의 우려는 타당한 면이 크다고 할 수 있습니다.
"프로토타입·사내 도구는 OK, 실제 웹사이트는 신중하게"가 업계 어드바이저들의 일반적인 견해입니다.
2026년 5월 시점에서는 Chrome 전용 기능이므로 Safari·Firefox에는 별도 구현이 필요합니다. 실제 운영에서는 브라우저 판별과 폴백 설계가 필수입니다. 표준화 방향이 정해지는 2027년 이후에 본격 채용하는 것이 안전한 선택으로, 그때까지는 OpenAI API 등 클라우드 AI와의 병용이 현실적인 선택지입니다.
신규 구축이라면 업계 표준으로 구축하고 나중에 리폼할 수 있는 여지를 남겨두는——그 자세가 기술 선정의 핵심입니다.
"독자적인 Apple Intelligence 전략이 있어 Google 에코시스템 추종을 피하고 싶기 때문"이 주요 이유입니다.
Apple은 iOS 18·macOS 15부터 Apple Intelligence（독자 AI 기능）를 전개하고 있으며, Safari의 AI 기능도 자사 모델로 구현하는 방향입니다. Web API 통합에는 신중한 자세를 유지하고 있습니다.
배경에는 "프라이버시 중시의 Apple 철학", "독자 실리콘（Apple Silicon）에의 최적화", "Google 의존 회피" 등 여러 전략적 이유가 얽혀 있습니다.
"여러 브라우저를 구분해서 사용하며 웹의 선택지를 유지하는 의식이 중요하다"는 것이 커뮤니티의 공통 조언입니다.
개인 사용자가 Firefox·Safari를 계속 선택하는 것이 브라우저 다양성을 유지하는 직접적인 행동이 됩니다. 점유율 편중은 웹 전체의 선택지를 좁히는 결과로 이어질 수 있습니다.
프라이버시 중시라면 Firefox·Brave, Apple 제품 사용자라면 Safari, 업무 효율이라면 Chrome 등 용도에 따른 구분 사용이 현실적인 행동 방안입니다.
"Chrome에 AI가 내장되어 편리해진다"——그 이면에서는 웹의 중립성을 지키는 30년의 싸움이 새로운 국면을 맞이하고 있습니다.
Mozilla의 공식 반대는 "편리하니까 반대"가 아니라 "편리하기 때문에야말로 설계를 신중하게 해야 한다"는, 웹 개발의 장기적 건전성을 내다본 본질적인 논의입니다. Gemini Nano의 록인 우려, Google 이용약관에의 의존, 상호운용성 붕괴 위험은 개발자·사업자·사용자 모두에게 관련된 중요한 논점으로, 결코 "한 기업의 의견"으로 치부할 수 있는 것이 아닙니다.
오늘부터 할 수 있는 3단계는 다음과 같습니다. ①웹 개발자는 기술 선정 시 브라우저 호환성을 의식한다, ②사업자는 Chrome 전용 구현과 이식 비용을 세트로 견적한다, ③사용자는 여러 브라우저를 구분해서 사용하여 웹의 선택지를 유지한다. 편의성과 중립성의 균형을 누가 어떻게 지킬 것인가——웹의 미래를 좌우하는 논쟁이 2026년부터 본격화되고 있습니다.
이 글은 AI Friends 에서의 크로스포스트입니다.
