# Chrome의 Prompt API에 대한 Mozilla의 반대 > Clean Markdown view of GeekNews topic #29053. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29053](https://news.hada.io/topic?id=29053) - GeekNews Markdown: [https://news.hada.io/topic/29053.md](https://news.hada.io/topic/29053.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-05-01T08:52:07+09:00 - Updated: 2026-05-01T08:52:07+09:00 - Original source: [github.com/mozilla](https://github.com/mozilla/standards-positions/issues/1213#issuecomment-4347988313) - Points: 2 - Comments: 1 ## Topic Body - 브라우저 내 언어 모델을 웹 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이 빠르게 업데이트해 사용자가 알아차리지 못했다는 선례가 함께 다뤄짐 ## Comments ### Comment 56632 - Author: neo - Created: 2026-05-01T08:52:09+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47959463) - 반대 논점은 꽤 명확해 보임: **프롬프트와 모델의 강한 결합**, 그리고 약관에서의 모델 중립성 문제임 [https://github.com/mozilla/standards-positions/issues/1213]()의 개인 사례처럼, 홈 오토메이션 알림용 시스템 프롬프트를 만들 때 Gemini가 처음엔 너무 미국식으로 답했고, 영국식 음성으로 말한다고 알려주자 이번엔 “a'waight guv'nor apples and pears” 같은 미국인의 어설픈 영국 흉내가 나와서 더 조정해야 했음 이 과정에서 시스템 프롬프트가 특정 모델에 맞춰지고, 다른 모델은 다른 quirks가 있어서 한 모델을 위해 넣은 보정이 다른 모델에는 과보정이 될 수 있음 - 그 결과는 **adversarial mode**에서 조롱하는 것처럼 들림 - 그게 LLM 기능을 지원하지 말아야 할 좋은 이유라면, 어떤 플랫폼 API에도 넣지 말아야 한다는 결론이 됨. 그런데 이미 수많은 플랫폼에 추가되어 있음 모델마다 다르다는 건 이 기술의 핵심 특성임. 기기나 방향에 따라 canvas 크기가 달라지고, geolocation API 정확도가 달라지고, Speech Synthesis 음성이 기기마다 다른 것과 비슷함 이건 건설적 비판이라기보다 **anti-AI 정서**에 가까움. 지금은 권한 UI가 필요하고, 언젠가 low/medium/high 같은 IQ 레벨이 붙을 수도 있지만, 신경 쓰는 개발자는 어차피 90%는 특정 모델에 의존하게 됨 시간이 지나 AI 혐오가 줄고 도움이 된다는 걸 사람들이 깨달으면, Firefox에 이 기능이 없는 건 **개인 데이터 자율성** 측면에서 실패로 보일 수 있음. Chrome의 관련 TOU가 문제라면, 오히려 Firefox가 문제 없는 모델 약관으로 이 기능을 넣어야 할 이유가 됨 - 반대 글을 누가 썼는지 몰랐는데, Chrome 팀에 오래 있던 Googler **Jake Archibald**가 Mozilla로 옮겨 Chrome API에 반대하는 글을 쓴 거였음. 비판이 잘 정리된 게 놀랍지 않고, 이번엔 당론을 따르지 않아도 돼서 후련했을 듯함 - 고맙지만, Google에 있을 때도 당론을 따르진 않았다고 봄. 다만 그 때문에 내부에서 점점 더 힘들어졌고 결국 떠났음 아직 팀에 남아 있는 사람들 얘기를 들어보면, 그 면에서는 상황이 기하급수적으로 더 나빠진 듯함 - standards-positions repo에 아주 익숙할 테고, Google이 충분한 의견 수렴 없이 뭔가를 밀어붙일 때의 전형적인 방어처럼 읽힘 변경 제안을 하기보다 전체를 폐기하려는 식인데, 폐기되면 Google Chrome 팀 관점에서 시작하지 않고 처음부터 협업으로 다시 쓰기를 기대하는 것 같음. 다만 그런 식으로 잘 된 경우를 별로 못 봤으니, 그냥 구체적인 수정안을 제시하는 편이 더 나아 보임 - 이건 반대함 1) 새로운 **fingerprinting 정보**가 되고, fingerprinting script를 속이기 어렵기 때문에 “device verification”에 악용될 수 있음. 브라우저를 “검증”할 수 있어선 안 되고 누구나 어떤 브라우저든 에뮬레이트할 수 있어야 함 2) LLM은 메모리와 CPU를 많이 쓰고, 현재 RAM 가격을 고려하면 업그레이드도 비쌈. 웹사이트가 로컬 모델에 의존하면 저가 기기에서는 느리게 동작함 3) API가 OpenAI 같은 특정 LLM에 맞춰진 듯함 4) 브라우저 시장에서 자체 AI 모델이 없는 경쟁자를 밀어낼 수 있음. 사이트들이 Google Gemini 모델을 기대하고 만들어지면 다른 모델이나 AI 모델이 없는 국가 브라우저에서는 깨질 수 있고, “1급”과 “2급” 브라우저가 생겨선 안 됨 explainer는 데이터를 어디에도 보내지 않고 로컬에서 처리할 수 있다고 하지만, 그렇다면 왜 Google Gemini 로컬 모델에 **Prohibited Use Policy**가 필요한지 의문임. Google이 알 수 없는 프롬프트와 응답을 왜 신경 써야 하나 오프라인 LLM 접근 자체는 좋아 보이지만, 브라우저에 LLM을 내장하지 않아도 웹사이트가 WebGPU를 쓰거나 ML 모델 처리를 위해 WebGPU를 개선할 수 있음. 아니면 모두가 같은 오픈소스 LLM을 써야 함 - Google은 다른 박테리아처럼 돈이 있는 방향을 가리키고 편모를 흔들며 그쪽으로 갈 뿐임. 왜 누가 Google이 웹이나 인류를 위해 좋은 일을 할 거라고 생각하는지 모르겠음 - “브라우저를 검증할 수 없어야 한다”는 데에는 강하게 반대함. AI 업계는 코로나 이전에 있던 anti-scraping, anti-botting의 사회적 합의를 완전히 찢어놨음 robots.txt가 강제 요건이 아니고 완전히 우회할 수 있다는 게 이제 상식이 됐고, 열린 웹을 사실상 **dark forest**로 만들어버림 브라우저 세션이 변조되지 않았거나 “trusted”하다고 검증되는 방식은 앞으로 생길 가능성이 큼. 정말 별로지만, 결국 우리가 자초한 면도 있음 - fingerprinting 우려에 대해서는 Chrome에도, 당연히 Firefox에도 “LLM을 절대 다운로드하지 않고 모든 LLM 기능 끄기” 옵션이 있을 거라고 봄 사이트가 작은 LLM 요청을 보내 모델 자체를 fingerprinting하는 경로는 가능하지만, 끌 수 있다면 큰 문제는 아니라고 봄 더 넓게는 “웹 플랫폼은 이걸 할 수 없어야 한다”는 형태의 우려가 있음. 이런 입장에서는 사용자가 끌 수 있어도 “LLM이 없으니 브라우저 미지원” 같은 사이트가 생기고 웹이 나빠진다고 말할 수 있음 하지만 그건 결국 웹사이트 운영자가 LLM이 없으면 사이트를 꺼버리기로 한 결정이지, 기능을 만든 플랫폼이나 유지관리자의 잘못은 아님. Firefox에서도 잘 동작하는데 테스트하기 귀찮아서 지원을 끄는 것과 비슷함 웹은 PDF와 경쟁하는 게 아니라 **SwiftUI**와 경쟁하는 세계에서 가장 성공한 애플리케이션 플랫폼임. “웹을 지금처럼 정적으로 유지하면 된다”는 선택지는 환상이고, 실제 선택지는 사용자의 변화하는 요구에 맞춰 웹을 적응시키거나, 웹이 실패해서 SwiftUI나 WinUI가 그 빈자리를 채우는 것임. 후자가 훨씬 나쁨 - 이 스레드의 답글들을 보다가 깨달았음: 어차피 그들은 할 것이고, 이미 LLM에 의존하거나 제대로 판단할 능력이 부족한 사람들이 칭찬할 것임 [https://news.ycombinator.com/item?id=47960596]() 결론은 이제 넘어갈 때라는 것임. 웹 브라우저보다 나은 온라인 정보 교환 및 미디어 재생 형식을 생각해야 함. 우리가 상품이라면, 우리가 쓰는 도구도 몰래 광고 수익을 신뢰할 수 없는 지배자에게 흘려보내는 프록시처럼 굴지 말고 그 사실을 직접 반영해야 함 - 생각할수록 이번에는 Google의 API 설계 쪽에 더 동의하게 됨 **프롬프트와 모델의 강한 결합**은 실제 우려이고 매일 겪는 문제임. 하지만 해결책이 사용자의 브라우저에 있는 모델과 평가될 프롬프트를 더 강하게 결합하는 API라면, 곧 “우리 프롬프트는 Gemini에서만 테스트했으니 이 사이트는 Chrome이 필요함” 같은 상황이 됨 더 나쁘게는 “사용 중인 AI 모델을 인식할 수 없음”이 될 수 있음. 2026년에 만든 사이트가 2030년까지 업데이트되지 않으면 충분히 일어날 일임 이는 Mozilla 엔지니어가 뒤에서 말한 약관 문제와도 연결됨. 특정 AI 모델 약관에 동의하지 않아도 되는 브라우저, 예를 들어 좋은 오픈소스 모델을 쓰는 브라우저가 존재하려면, Big Models를 fingerprinting할 수 없게 하는 편이 유리함 물론 많은 사이트는 어차피 isChrome() 같은 호출을 할 것임. 그래도 브라우저 fingerprinting 방법을 늘리는 변경에는 대체로 반대함. 모델을 익명으로 유지하는 이점이, Gemini와 Qwen 같은 모델 간 작은 차이 때문에 드물게 이상한 출력이 나오는 단점보다 큼 - 왜 Google은 브라우저가 이미 할 수 있는 수많은 것들의 구조적 약점을 고치는 데 막대한 자원을 쓰지 않고, 계속 잡동사니를 덧붙여 브라우저를 **Homermobile**로 만들려 하는지 모르겠음 정적 블로그부터 전자상거래, 최첨단 웹앱까지 웹 플랫폼 전반의 삶의 질을 높일 기초적인 것들에 집중하면 안 되나 [https://simpsons.fandom.com/wiki/The_Homer]() - Google은 더 나은 웹을 만들려고 Chrome을 만드는 게 아님. 좋은 브라우저 자체를 위해 좋은 브라우저를 만드는 건 goodwill에 수십억 달러를 쓰는 일이고, Chrome의 목표는 사용자가 기기에서 무언가 할 때 사용자의 OS를 대체하는 플랫폼이 되는 것임 Android와 ChromeOS로 직접 그걸 시도하지만, Chrome은 Windows 같은 환경의 평균 사용자도 대부분의 시간을 Google 세계 안에서 보내게 만듦 - Google에서 승진하려면 **prompt API**를 출시해야 함 - prompt API를 구현하지 않는다고 해서, 이전에는 중요하게 여기지 않던 다른 일에 자원을 투입하게 될까? 이건 **false dichotomy**처럼 보임 - 현재의 **LLM과 API harness**는 이런 API가 표준에 들어갈 만큼 기술적으로 성숙하지 않았다고 강하게 봄 그래도 해야 한다면 최소한 사이트별 opt-in 권한이어야 하고, 어떤 모델에 프롬프트를 보내는지 식별할 방법이 있어야 함. 시스템 프롬프트의 작은 조정까지도 그 정체성에 포함됨 사용자로서는 임의의 사이트에 방문했을 때 허락 없이 이 API로 fingerprinting당하지 않는다는 확신이 필요함 개발자로서는 사용자들이 어떤 모델을 쓰는지 알아야 모델별 프롬프트를 만들 선택지가 생김 - “브라우저와 운영체제가 언어 모델에 접근할 것으로 점점 기대된다”라고? 정말 그런가? [https://github.com/webmachinelearning/prompt-api/blob/main/R...]() - 방향이 틀렸다고 봄. OS나 브라우저가 LLM에 접근하는 건 원하지 않지만, LLM이 브라우저나 OS에 접근하는 건 원하고 이미 그렇게 되고 있음 그러니 기본값은 꺼진 상태로, 사용자가 원할 때 켤 수 있는 LLM용 인터페이스만 제공하면 된다고 봄 그러면 Apple이 OS에 넣은 LLM에 lock-in되지 않고 어떤 **LLM provider**를 쓸지 선택할 수도 있음. 예를 들어 Apple Intelligence가 접근할 수 있는 것들을 Claude에도 접근하게 하고 싶음 - 저 문장을 원래 썼는데, 이렇게 오해될 줄은 몰랐음. 사용자나 개발자의 기대라는 뜻이 아니라, OS와 브라우저 벤더들이 LM을 탑재하거나 준비하는 **업계 트렌드**를 말하려던 것임 이제는 “접근할 것으로 기대된다”보다 “탑재되고 있다”로 바꿀 수 있을 듯함. 많은 사람이 헷갈리는 것 같으니 프로젝트 유지팀이 그렇게 업데이트해주면 좋겠음 - macOS, iOS, Windows에는 서드파티 개발자를 위한 로컬 모델 API가 있고, Chrome도 시험 중임. Firefox는 모델로 alt-text를 생성하지만 API는 없음 이론적으로는 유용함. 개발자들이 로컬 모델에 의존할 수 있으면 더 private하고 decentralized하며, AWS나 Anthropic에 돈을 보낼 필요도 줄어듦. 로컬이라서 오프라인으로 가능하고 무료일 때만 의미 있는 low-stakes 사용처도 있음 하지만 실제로는 네이티브 앱에서 **Apple Foundation Models** 채택을 거의 못 봤음. Mac/iOS 개발자들이 공유할 만한 게 있는지 궁금함 - AI는 bikeshedding밖에 못 하는 사람들에게 엄청난 힘을 줌. AI 자체도 bikeshed일 가능성이 크지만 합법적인 사용처도 있긴 하고, 쓸모없는 아이디어를 반대보다 더 오래 떠들어 밀어붙일 힘도 줌 이제 모든 것이 점점 **bikeshed**를 기대하게 됨. CVE가 기대됨 - 브라우저 API 표면이 아직도 충분히 외설적으로 넓지 않은 모양임 - 오픈 프로토콜의 좋은 점은 특정 구현을 지지하거나 쓸 필요가 없다는 건데, 어쨌든 **브라우저 독점**은 계속 딜레마로 남아 있음 ungoogled chromium, Tor 같은 좋은 프로젝트들이 있지만, 가장 큰 문제는 평균적인 사람을 위한 목소리와 대중과 연결되는 프로젝트가 부족하다는 것임 잘 모르는 사용자들 중 상당수는 원인과 메시지 전달 방식에 무관심하고, 자유와 통제보다 “재미” 있고 마찰이 적은 것에 더 반응함 이걸 어떻게 해결할까? 어떻게 브라우저를 우리의 것, 사람들에 의한, 사람들을 위한 것으로 만들 수 있을까? 이런 생각을 할 때마다 그냥 슬픔 - 직접 브라우저를 컴파일하면 오히려 더 나빠짐. Spotify나 Netflix를 원하면 attestation이 있는 **Widevine**이 필요하고, 결국 Google에 비용을 내야 함 Browser Agent 문자열이 Chrome이나 Firefox가 아니면 끝없는 Cloudflare CAPTCHA나 403을 만나게 됨 - “native” 애플리케이션에 Chrome을 끼워 넣지 않고 플랫폼 API를 배우는 것부터 시작해야 함 그다음에는 Chrome이 하는 대로가 아니라 **웹 표준**에 기반해 웹 애플리케이션을 만들고, Firefox와 Safari가 못 따라온다고 불평하지 않아야 함 - 간단함. 반독점 법으로 모든 대형 기술 기업을 쪼개면 됨. 이들은 우리 시대의 **robber barons**임 - 안타깝지만 답은 거의 항상 **실질적인 공공 자금**임 - 괜찮은 브라우저는 이미 있고, 평균적인 사람은 Chrome을 씀. 관심 있는 사람은 전자로 갈아탐. 무엇을 해결해야 하나? 평균적인 사람에게 닿는 프로젝트가 필요하다면서, 동시에 그들이 자유와 통제보다 마찰이 적은 것을 원한다고 했음. 모순이 보임. 평균적인 사람은 통제보다 **less friction**에 연결됨 - 이 API의 use case가 뭔지 궁금함 로컬 LLM을 돌릴 때의 내 경험은 llama-server를 띄우고, 필요하면 별도 머신에서 돌린 뒤 다른 애플리케이션이 OpenAI나 비슷한 서비스 대신 그 **OpenAI 호환 서버**를 가리키게 설정하는 것임 브라우저가 LLM 인스턴스를 만들거나 실행하는 건 원하지 않음. 그 머신이 LLM 인스턴스를 돌릴 능력이나 여유가 없을 수 있기 때문임 - 이게 LLM 없이는 이미 못 사는 젊은 세대와, 프라이버시를 침해하는 웹 브라우저를 돌리려고 슈퍼컴퓨터까지 요구받고 싶지 않은 낡은 세대의 차이인지 궁금함 내게는 사람들이 **브라우저/웹의 대안**을 찾고 개발하기 시작하는 지점처럼 들림 - 이건 Mozilla가 AI에 반대하는 입장을 낸 게 아님 현재 형태의 제안 API가 **웹 상호운용성**에 왜 나쁜지 명확하고 논리적인 이유를 설명한 것임 - 여기서의 반대는 LLM을 좋아하느냐 싫어하느냐와 무관하다고 봄. 이 특정 오픈 웹 API 제안이 실현 가능한가의 문제임 개인적으로는 코딩 보조와 홈 오토메이션에 LLM을 쓰지만, 이 API가 웹에 좋다고 생각하진 않음 - 내 경험상 젊은 사람들은 대체로 AI를 싫어함 - 약간 벗어난 얘기지만, 재작업이 필요한 건 브라우저 인터페이스보다 운영체제라는 개념 자체에 더 가깝다고 봄 정답은 모르겠지만 Niri/Wayland, GNOME, Windows, Mac을 써본 뒤로는 non-tiling desktop과 키보드 중심이 아닌 데스크톱 창 관리 workflow로는 절대 돌아가지 않을 것임 - “슈퍼컴퓨터가 필요하고 프라이버시를 침해하는 브라우저”라는 배는 2008년에 이미 떠났음