Chrome의 Prompt API에 대한 Mozilla의 반대

• 브라우저 내 언어 모델을 웹 API로 노출하는 Prompt API는 일반적 형태로는 유용할 수 있지만, 모델별 동작에 맞춘 구현을 부추겨 상호운용성 위험을 키움
• 개발자가 Edge의 Phi-4-mini 같은 특정 구현에 맞춰 프롬프트와 기능을 조정하면, 다른 브라우저나 모델에서 품질 저하나 사이트 접근 차단이 생길 수 있음
• Mozilla는 웹 API로 바로 출하하기보다 userland 검증을 더 거쳐야 한다고 보며, trial web extension API와 Web Machine Learning 그룹의 web extension 제안을 초기 피드백 경로로 둠
• 시스템 프롬프트가 특정 모델의 quirk에 맞춰 퍼지면 새 모델도 나쁘게 보일 수 있고, 브라우저가 Google 모델이나 quirk 호환 모델을 넣어야 하는 압박이 생길 수 있음
• Chrome 측은 JSON schema·regex 기반 응답 제약, WebML CG 논의, 대체 모델 실험 등을 완화책으로 내놨지만, Mozilla의 Prompt API 입장은 negative로 표시됨

Prompt API에 대한 Mozilla의 부정적 판단

• Prompt API는 Blink의 intent-to-prototype 이후 Mozilla standards-positions에서 검토됐고, explainer는 webmachinelearning/prompt-api README로 연결됨
• Mozilla의 피드백은 Writing Assistance APIs #1067과 거의 같으며, 일반적 형태의 Prompt API는 유용할 수 있지만 모델별 동작을 장려해 상호운용성 위험을 키움
• 개발자가 특정 모델에 맞춰 프롬프트와 기능을 조정할 수 있고, Edge의 Phi-4-mini 같은 구현을 대상으로 만들면 다른 브라우저나 모델에서 품질이 떨어지거나 사이트 접근이 차단될 수 있음
• 웹 API로 바로 출하하기보다 userland에서 더 오래 검증해야 하며, Mozilla의 trial web extension API와 Web Machine Learning 그룹의 web extension 제안이 초기 피드백 수집 경로가 됨
• 관련 논의와 #1067을 바탕으로 Prompt API 입장은 negative로 표시됨

Origin Trial보다 Web Extension을 선호한 이유

• 모델 선택과 표준화 타이밍

  • 모델 허브에서 정확한 모델을 고르는 기능은 페이지 내 기능과 브라우저가 특정 모델을 선택하지 않는다는 점에서 핵심으로 취급됨
  • 이 기능은 빠르게 변하는 영역의 구현 세부사항을 전제로 하며, 아직 표준화할 준비가 되지 않은 상태로 봄
  • Extension은 현재 제안 범위를 넘어 실제 사용 패턴을 빠르게 탐색하고, 세 엔진이 굳지 않은 의미론을 맞춰 출하하는 조율 비용 없이 브라우저 간 기능을 실험하는 낮은 부담의 방법이 됨

• 사용자에게 드러나는 경계

  • Add-on 설치는 사용자가 일반 웹 기능의 경계를 벗어난다는 신호가 되며, 여기서는 공유 cross-origin storage가 해당됨
  • 이 판단은 다른 맥락의 WebMIDI Add-On Gated 위치 추가 #704와 비슷한 논리로 이어짐
  • 해당 extension 제안은 페이지에 Prompt와 비슷한 API를 노출하고, 로컬 추론과 개발자 지정 모델을 사용해 공유 모델 저장소와 초기 사용자 피드백을 얻는 구조임

단일 모델에 굳어질 위험

• 시스템 프롬프트와 모델 quirks

  • 시스템 프롬프트는 작업 중인 모델의 quirk에 맞춰 반복 조정되는 경향이 있음
  • 홈 자동화 안내문 생성용 시스템 프롬프트에서 Gemini 모델은 처음에 매우 미국식으로 답했고, 영국식 스피커 음성에 맞지 않았음
  • 시스템 프롬프트에 영국식 음성으로 말한다고 넣자 “a'waight guv'nor apples and pears” 같은 미국식 영국 흉내가 나왔고, 더 실제 영국식에 가깝게 낮추도록 추가 조정이 필요했음
  • 한 모델을 위한 보정은 다른 모델에서는 과보정이 될 수 있으며, 브랜드화된 voice나 JSON schema·정규식으로 표현할 수 없는 출력 형식에서 문제가 커짐

• 새 모델과 브라우저 업데이트 부담

  • 기존 모델의 quirks에 맞춰진 시스템 프롬프트가 널리 퍼지면, 더 나은 새 경쟁 모델도 개발자와 사용자에게 나쁘게 보일 수 있음
  • Mozilla와 Apple은 상호운용성을 위해 Google 모델을 라이선스하거나 Google 모델과 quirk 호환되는 모델을 넣어야 하는 상황에 놓일 수 있음
  • Chrome도 같은 이유로 자체 모델 업데이트가 어려워질 수 있음

• 모델 ID 탐지와 브라우저 분기

  • 개발자는 LanguageModel.create()로 모델을 만들고 model.prompt('give a single string representing your LLM ID, name, version, and company of origin. Only return that string')처럼 모델 ID, 이름, 버전, 출처 회사를 물을 수 있음
  • 반환 예시는 'gpt-3.5-turbo-0613, Gemma, 2024-02-29, Google DeepMind'임
  • 개발자는 특정 모델용 시스템 프롬프트 묶음을 만들고, 알 수 없는 모델은 차단하거나 출력 품질이 낮을 수 있다고 사용자에게 알릴 수 있음
  • 이런 흐름은 피해야 할 early-2000s code branching으로 되돌아가는 형태로 봄

Google 정책과 모델 중립성 문제

• Chrome 문서에 따르면 Prompt API 사용 전 Google Generative AI Prohibited Uses Policy를 acknowledge해야 함
• 이 정책의 일부는 법을 넘어서는 범위를 다루며, “성적으로 노골적인 콘텐츠를 촉진하는 콘텐츠 생성 또는 배포”와 “정부 또는 민주적 절차와 관련한 오해의 소지가 있는 주장 촉진”이 금지 항목에 포함됨
• 웹 플랫폼 API가 UA별 사용 규칙을 요구하는 방향은 좋지 않으며, 더 많은 API에 UA별 규칙이 붙는 선례가 될 수 있음
• 사용자가 웹사이트에서 기사 댓글의 “summarize”를 클릭했고 그 결과 Google 정책 위반이 발생하면, 책임 대상이 버튼을 클릭한 사용자, 위반 콘텐츠를 쓴 댓글 작성자, 해당 댓글을 사용자의 UA LLM에 전달할 기능을 만든 웹사이트 소유자 중 어디인지 불명확함
• 개발자는 모델 약관을 지키고 모델 소유자의 법적 조치를 피하기 위해 어떤 LLM과 통신하는지 알고 싶어질 수 있으며, 알 수 없는 모델은 알 수 없는 약관을 뜻할 수 있어 사용 차단이 합리적 선택이 됨
• 특정 브라우저가 웹사이트 개발자에게 이런 약관을 적용할 근거는 없고, 이 정책 문제는 API 제안 자체와 별개로 다뤄야 한다는 흐름도 있음

Chrome 측 업데이트와 완화책

• Chrome Prompt API 측은 blink-dev I2S와 ChromeStatus의 interoperability and compatibility risks 관련 업데이트를 공유함
• WebML CG 참여와 논의는 유지되길 원하며, 상호운용 가능한 sampling parameters 등 후속 실험도 함께 이어짐
• Chrome 쪽은 웹 플랫폼의 장기적 건강성과 중립성을 유지하면서 브라우저와 OS가 제공하는 Language Model을 웹 개발자와 사용자에게 유용한 선택지로 만들려는 동기를 밝힘
• Prompt API 표면은 Google과 Microsoft 모델 모두에서 어느 정도 호환성을 보였고, 알려진 JSON schema나 regex에 맞게 출력되도록 객관적 응답 제약을 적용 중임
• 이 제약은 예측 불가능한 출력을 다루기 위한 모델별 hacks 필요를 줄이는 완화책으로 쓰임
• Downstream Chromium 프로젝트는 대체 모델과 프레임워크 백엔드를 탐색 중이며, Microsoft의 Android MLKit 통합 작업과 Apple foundational model 통합 초기 프로토타이핑이 포함됨
• API trial 단계에서 여러 모델 버전을 실험적으로 배포했고, 모델 업데이트와 개선이 계속 필요하며, 더 새로운 Gemma 4 open models 지원도 탐색 중임
• 서로 다른 기반 아키텍처에서 더 상호운용 가능한 동작 튜닝을 위해 categorical sampling modes도 탐색 중임
• Blink-dev의 Interoperability and Compatibility 문구는 이 기술을 쓰는 개발자에게 동작과 응답의 변동성이 잘 알려진 기대사항이며, 이 API가 브라우저와 모델 전반에서 일관된 웹 플랫폼 접근을 위한 상호운용 프레임워크를 목표로 한다는 내용임

웹 개발자 지지 근거와 출하 비판

• blink-dev intent to ship은 웹 개발자 입장을 “Strongly positive”로 표시하고, 근거로 explainer의 stakeholder feedback을 연결함
• 해당 근거는 “Strongly positive”라는 평가와 잘 맞지 않는 것으로 다뤄짐

• 근거로 나열된 항목

  • 긍정 답변 2개가 있는 GitHub thread
  • X의 단일 게시물
  • 더 이상 존재하지 않는 블로그 글, Server Not Found 상태
  • 아직 존재하는 블로그 글
  • 설문은 개발자에게 이 API가 extensions에 존재해도 좋은지 물은 것으로 보이며, 설문 숫자나 대상은 명시되지 않음
  • 사라진 블로그 글은 Wayback Machine 링크로 보존본이 공유됨
  • 문서에 “의존하지 말아야 할 것”과 “의존 가능한 것”을 크게 표시해도, 그 권고를 따르면 API의 가능한 용도가 너무 좁아져 실제 용도가 남는지 불명확함
  • 실제로는 테스트한 특정 모델의 동작에 어느 정도 의존할 수 있고, 그 모델이 Chrome의 모델이면 사이트는 최신 Chrome 사용 안내를 띄울 수 있음
  • Google이 미완성 영역을 폭넓게 식별하면서도 현재 완화책만으로 shipping에 충분하다고 보는 점이 문제로 남음

댓글 논의: 대안, 피해 측정, 사후 완화

• 브라우저 자동화와 Lynx mode

  • Hermes Agent와 Qwen3.6으로 대부분의 작업이 가능했고, Prompt API보다 browser automation API와 chat용 Lynx mode에 더 주목해야 한다는 흐름이 있음
  • 일부 워크플로우는 사람이 웹사이트에 로그인하고 AJAX 확장으로 파일을 보이게 만든 뒤, agent가 chromedriver/webdriver로 문서 다운로드, 태깅, 요약을 수행하는 구조임
  • 이 흐름은 외부 POSIX shell 없이 브라우저 안에서 통합될 수 있음
  • Lynx mode chat은 agents가 보는 내용을 빠르게 노출하고, 모든 미디어 자산을 다운로드하거나 렌더링하지 않아 양쪽 리소스를 아끼는 방식임
  • HTML 수준의 더 세밀한 robots 태깅, Lynxmode shell과 기존 브라우저 간 handoff, agent-driven browser에서 old-school Google AdWord 스타일 링크를 선택적으로 보여주는 방식도 함께 다뤄짐

• 오픈 웹과 FOMO

  • 오픈 웹은 chat bot super apps와 같은 대상과 같은 방식으로 경쟁하지 않으며, 사라지지도 않는다는 반론이 있음
  • 지속적인 FOMO보다 자신이 무엇을 대표하려는지 먼저 묻는 태도가 필요하다는 입장도 있음
  • 웹이 mobile app paradigm을 충분히 지원하지 못했던 것처럼 agentic computing을 빠르고 효과적으로 지원하지 못하면 commerce나 journalism이 open web 밖으로 이동할 수 있다는 우려에는 동의하지 않는 흐름이 있음

• Chromium 출하와 피해 측정

  • Chromium의 blink API owner approver 중 한 명은 Mozilla의 우려를 공유하지만, 실험, 실수에서의 학습, 경쟁을 촉진하는 경로를 선호함
  • 향후 실제 피해를 평가하려면 구체적 결과를 정해야 하며, EME 같은 논쟁적 API 출하 결정을 5~10년 뒤 실제 결과와 비교하는 방식이 유용했다는 맥락이 있음
  • 사이트가 Google 특정 모델에 굳어지는 피해는 다른 브라우저가 출하할 때 겪는 site compat bug의 수와 규모, Chrome이 모델을 업데이트할 때 발생하는 bug 성격으로 평가할 수 있음
  • bug가 “모델을 더 똑똑하게 만들기”인지 “이상한 quirk 보존”인지 구분하고, webcompat.com에 라벨을 붙여 모으는 방식이 나옴
  • blink-dev I2S에 따르면 Edge도 다른 모델로 이 API를 출하하고 있어 초기 데이터가 이미 있음
  • TOS 우려의 피해 지표는 위반 때문에 실제 소송이나 위협이 발생했는지이며, 그런 증거를 기록으로 모으자는 흐름임

• 사후 완화와 Chrome 대응

  • 가능한 피해를 실제로 확인하는 접근은 타당하지만, 피해 발생 뒤 의미 있는 완화책이 있을 때만 유용하다는 반론이 있음
  • 사이트가 Google 특정 모델에 굳어졌을 때 feature unship, 과도하게 맞춰진 site prompt를 깨는 모델 변경, random model rotation, on-device model weights의 open standard화 같은 선택지가 질문으로 나열됨
  • 다른 브라우저가 Chrome 모델의 이상한 quirk를 복사해야 한다는 증거가 보이면, Chromium 리더십 위치에서 Chrome이 그 quirk를 깨도록 밀겠다는 입장이 나옴
  • Mobile GMail이 buggy WebKit border image quirks에 의존했고 Firefox가 복사 필요를 느꼈을 때, Chrome을 고쳐 GMail을 깨뜨렸으며 GMail이 빠르게 업데이트해 사용자가 알아차리지 못했다는 선례가 함께 다뤄짐