반대 논점은 꽤 명확해 보임: 프롬프트와 모델의 강한 결합, 그리고 약관에서의 모델 중립성 문제임 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 팀 관점에서 시작하지 않고 처음부터 협업으로 다시 쓰기를 기대하는 것 같음. 다만 그런 식으로 잘 된 경우를 별로 못 봤으니, 그냥 구체적인 수정안을 제시하는 편이 더 나아 보임
이건 반대함
새로운 fingerprinting 정보가 되고, fingerprinting script를 속이기 어렵기 때문에 “device verification”에 악용될 수 있음. 브라우저를 “검증”할 수 있어선 안 되고 누구나 어떤 브라우저든 에뮬레이트할 수 있어야 함
LLM은 메모리와 CPU를 많이 쓰고, 현재 RAM 가격을 고려하면 업그레이드도 비쌈. 웹사이트가 로컬 모델에 의존하면 저가 기기에서는 느리게 동작함
API가 OpenAI 같은 특정 LLM에 맞춰진 듯함
브라우저 시장에서 자체 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당하지 않는다는 확신이 필요함
개발자로서는 사용자들이 어떤 모델을 쓰는지 알아야 모델별 프롬프트를 만들 선택지가 생김
방향이 틀렸다고 봄. 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로는 절대 돌아가지 않을 것임
Hacker News 의견들
반대 논점은 꽤 명확해 보임: 프롬프트와 모델의 강한 결합, 그리고 약관에서의 모델 중립성 문제임
https://github.com/mozilla/standards-positions/issues/1213의 개인 사례처럼, 홈 오토메이션 알림용 시스템 프롬프트를 만들 때 Gemini가 처음엔 너무 미국식으로 답했고, 영국식 음성으로 말한다고 알려주자 이번엔 “a'waight guv'nor apples and pears” 같은 미국인의 어설픈 영국 흉내가 나와서 더 조정해야 했음
이 과정에서 시스템 프롬프트가 특정 모델에 맞춰지고, 다른 모델은 다른 quirks가 있어서 한 모델을 위해 넣은 보정이 다른 모델에는 과보정이 될 수 있음
모델마다 다르다는 건 이 기술의 핵심 특성임. 기기나 방향에 따라 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 Chrome 팀 관점에서 시작하지 않고 처음부터 협업으로 다시 쓰기를 기대하는 것 같음. 다만 그런 식으로 잘 된 경우를 별로 못 봤으니, 그냥 구체적인 수정안을 제시하는 편이 더 나아 보임
이건 반대함
explainer는 데이터를 어디에도 보내지 않고 로컬에서 처리할 수 있다고 하지만, 그렇다면 왜 Google Gemini 로컬 모델에 Prohibited Use Policy가 필요한지 의문임. Google이 알 수 없는 프롬프트와 응답을 왜 신경 써야 하나
오프라인 LLM 접근 자체는 좋아 보이지만, 브라우저에 LLM을 내장하지 않아도 웹사이트가 WebGPU를 쓰거나 ML 모델 처리를 위해 WebGPU를 개선할 수 있음. 아니면 모두가 같은 오픈소스 LLM을 써야 함
robots.txt가 강제 요건이 아니고 완전히 우회할 수 있다는 게 이제 상식이 됐고, 열린 웹을 사실상 dark forest로 만들어버림
브라우저 세션이 변조되지 않았거나 “trusted”하다고 검증되는 방식은 앞으로 생길 가능성이 큼. 정말 별로지만, 결국 우리가 자초한 면도 있음
사이트가 작은 LLM 요청을 보내 모델 자체를 fingerprinting하는 경로는 가능하지만, 끌 수 있다면 큰 문제는 아니라고 봄
더 넓게는 “웹 플랫폼은 이걸 할 수 없어야 한다”는 형태의 우려가 있음. 이런 입장에서는 사용자가 끌 수 있어도 “LLM이 없으니 브라우저 미지원” 같은 사이트가 생기고 웹이 나빠진다고 말할 수 있음
하지만 그건 결국 웹사이트 운영자가 LLM이 없으면 사이트를 꺼버리기로 한 결정이지, 기능을 만든 플랫폼이나 유지관리자의 잘못은 아님. Firefox에서도 잘 동작하는데 테스트하기 귀찮아서 지원을 끄는 것과 비슷함
웹은 PDF와 경쟁하는 게 아니라 SwiftUI와 경쟁하는 세계에서 가장 성공한 애플리케이션 플랫폼임. “웹을 지금처럼 정적으로 유지하면 된다”는 선택지는 환상이고, 실제 선택지는 사용자의 변화하는 요구에 맞춰 웹을 적응시키거나, 웹이 실패해서 SwiftUI나 WinUI가 그 빈자리를 채우는 것임. 후자가 훨씬 나쁨
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
Android와 ChromeOS로 직접 그걸 시도하지만, Chrome은 Windows 같은 환경의 평균 사용자도 대부분의 시간을 Google 세계 안에서 보내게 만듦
현재의 LLM과 API harness는 이런 API가 표준에 들어갈 만큼 기술적으로 성숙하지 않았다고 강하게 봄
그래도 해야 한다면 최소한 사이트별 opt-in 권한이어야 하고, 어떤 모델에 프롬프트를 보내는지 식별할 방법이 있어야 함. 시스템 프롬프트의 작은 조정까지도 그 정체성에 포함됨
사용자로서는 임의의 사이트에 방문했을 때 허락 없이 이 API로 fingerprinting당하지 않는다는 확신이 필요함
개발자로서는 사용자들이 어떤 모델을 쓰는지 알아야 모델별 프롬프트를 만들 선택지가 생김
“브라우저와 운영체제가 언어 모델에 접근할 것으로 점점 기대된다”라고? 정말 그런가?
https://github.com/webmachinelearning/prompt-api/blob/main/R...
그러니 기본값은 꺼진 상태로, 사용자가 원할 때 켤 수 있는 LLM용 인터페이스만 제공하면 된다고 봄
그러면 Apple이 OS에 넣은 LLM에 lock-in되지 않고 어떤 LLM provider를 쓸지 선택할 수도 있음. 예를 들어 Apple Intelligence가 접근할 수 있는 것들을 Claude에도 접근하게 하고 싶음
이제는 “접근할 것으로 기대된다”보다 “탑재되고 있다”로 바꿀 수 있을 듯함. 많은 사람이 헷갈리는 것 같으니 프로젝트 유지팀이 그렇게 업데이트해주면 좋겠음
이론적으로는 유용함. 개발자들이 로컬 모델에 의존할 수 있으면 더 private하고 decentralized하며, AWS나 Anthropic에 돈을 보낼 필요도 줄어듦. 로컬이라서 오프라인으로 가능하고 무료일 때만 의미 있는 low-stakes 사용처도 있음
하지만 실제로는 네이티브 앱에서 Apple Foundation Models 채택을 거의 못 봤음. Mac/iOS 개발자들이 공유할 만한 게 있는지 궁금함
이제 모든 것이 점점 bikeshed를 기대하게 됨. CVE가 기대됨
오픈 프로토콜의 좋은 점은 특정 구현을 지지하거나 쓸 필요가 없다는 건데, 어쨌든 브라우저 독점은 계속 딜레마로 남아 있음
ungoogled chromium, Tor 같은 좋은 프로젝트들이 있지만, 가장 큰 문제는 평균적인 사람을 위한 목소리와 대중과 연결되는 프로젝트가 부족하다는 것임
잘 모르는 사용자들 중 상당수는 원인과 메시지 전달 방식에 무관심하고, 자유와 통제보다 “재미” 있고 마찰이 적은 것에 더 반응함
이걸 어떻게 해결할까? 어떻게 브라우저를 우리의 것, 사람들에 의한, 사람들을 위한 것으로 만들 수 있을까? 이런 생각을 할 때마다 그냥 슬픔
Browser Agent 문자열이 Chrome이나 Firefox가 아니면 끝없는 Cloudflare CAPTCHA나 403을 만나게 됨
그다음에는 Chrome이 하는 대로가 아니라 웹 표준에 기반해 웹 애플리케이션을 만들고, Firefox와 Safari가 못 따라온다고 불평하지 않아야 함
평균적인 사람에게 닿는 프로젝트가 필요하다면서, 동시에 그들이 자유와 통제보다 마찰이 적은 것을 원한다고 했음. 모순이 보임. 평균적인 사람은 통제보다 less friction에 연결됨
이 API의 use case가 뭔지 궁금함
로컬 LLM을 돌릴 때의 내 경험은 llama-server를 띄우고, 필요하면 별도 머신에서 돌린 뒤 다른 애플리케이션이 OpenAI나 비슷한 서비스 대신 그 OpenAI 호환 서버를 가리키게 설정하는 것임
브라우저가 LLM 인스턴스를 만들거나 실행하는 건 원하지 않음. 그 머신이 LLM 인스턴스를 돌릴 능력이나 여유가 없을 수 있기 때문임
이게 LLM 없이는 이미 못 사는 젊은 세대와, 프라이버시를 침해하는 웹 브라우저를 돌리려고 슈퍼컴퓨터까지 요구받고 싶지 않은 낡은 세대의 차이인지 궁금함
내게는 사람들이 브라우저/웹의 대안을 찾고 개발하기 시작하는 지점처럼 들림
현재 형태의 제안 API가 웹 상호운용성에 왜 나쁜지 명확하고 논리적인 이유를 설명한 것임
개인적으로는 코딩 보조와 홈 오토메이션에 LLM을 쓰지만, 이 API가 웹에 좋다고 생각하진 않음
정답은 모르겠지만 Niri/Wayland, GNOME, Windows, Mac을 써본 뒤로는 non-tiling desktop과 키보드 중심이 아닌 데스크톱 창 관리 workflow로는 절대 돌아가지 않을 것임