이 API는 내가 오래 생각하던 de-snarkifier 아이디어에 딱 맞아 보임
소셜 미디어는 지적으로 자극적이고 배울 것도 있지만, 원치 않아도 이념적 말싸움과 플레임워에 빨려 들어가기 쉬움. 인터넷에서 모르는 사람과 감정 소모하며 싸우는 건 인간 자본 낭비에 가까움
이런 API가 있으면 브라우저 확장으로 글을 보여주기 전에 공격적이거나 비꼬는 표현만 순화하고, 사실 정보는 그대로 보존하게 만들 수 있을 듯함. 더 나아가 공격적인 톤일수록 우스꽝스럽거나 무능하게 들리도록 바꿔버릴 수도 있음
그러면 읽는 사람은 낯선 이들의 인신공격에서 보호되고, 쓰는 사람도 무례하게 굴 유인이 사라짐. 다들 이런 필터를 쓰면 누가 더 못되게 구는지 경쟁할 이유도 없어짐
이건 글로 된 커뮤니케이션의 Soylent 같음
영양가는 다 있는데 맛은 특별할 것 없다는 느낌임
이런 도구가 정말 기대됨. 인터넷의 빈 칼로리를 걷어내서 지금의 인기 플랫폼 사용이 크게 줄어들 가능성이 있음
내가 원하는 건 전부 클릭베이트 제목과 광고를 없애고, 건조한 사실형 제목만 보여주는 것임
어떤 주제든 핵심 기사 하나와 실질적인 댓글 몇 개만 있으면 충분하고, 나머지는 대부분 보고 싶지 않은 잡음임
지금 소셜 미디어 상태가 너무 나빠서 거의 안 쓰고 있고, HN만 예외였는데 여기도 AI 포화로 비슷한 방향으로 가는 듯함. 그래도 격주쯤 몇 시간을 허비하게 되는데, 그마저 완전히 끊고 싶음
이상적으로는 콘텐츠의 98%를 필터링하거나 요약해서 없애고, 시간이 갈수록 인터넷은 의도적으로 검색할 때만 쓰게 되면 좋겠음. 기본적으로 인터넷의 엔터테인먼트성을 대부분 제거해서 시간과 에너지를 현실과 책 같은 고품질 소스로 돌리고 싶음
YouTube에는 이미 비슷한 게 있고, 나는 DeArrow를 쓰고 있음
이 확장은 크라우드소싱으로 선정성을 줄이려는 도구인데, 상위 기여자 중 일부는 LLM 봇일 수도 있겠다는 생각이 듦
흥미로운 아이디어라 탐색해볼 가치가 있어 보임
다만 이런 건 현실과 맞부딪히면 예측 불가능하고, 잘 되더라도 처음 상상한 방식과는 꽤 다르게 작동할 가능성이 큼
나는 Chrome의 built-in AI APIs PM인데, 이 de-snarkifier 아이디어가 정말 마음에 들고 관심도 넓어 보임
못 참고 Snarknada 프로토타입을 급히 만들어 보면서 저지연 패턴과 정확도 가능성을 같이 살펴봤음
이런 유형의 사용처에선 온디바이스가 맞다고 보는 이유가 정확히 여기에 있음. 무한 스크롤 피드 전체를 클라우드 API로 순화하려면 토큰 비용이 개발자 입장에서 감당 안 될 정도로 커짐. 게다가 개인 피드나 DM을 톤 정리하려고 제3자 서버로 보내고 싶어 하지 않는 것도 당연함
이걸 기기 안으로 옮기면 고빈도 Semantic Mutation이 비용과 기술 면에서 처음으로 현실화될 수 있음. 내 장난감 같은 PM 프로토타입보다 더 진지하게 만들다가 구체적인 마찰 지점이 생기면 꼭 듣고 싶음. 로드맵 우선순위를 정하는 데 도움이 됨
[1]: 코딩 에이전트(Cursor, Claude Code 등)를 쓴다면 https://www.npmjs.com/package/built-in-ai-skills-md-agent-md를 가리키는 걸 추천함. 많은 모델이 이제는 구식이 된 window.ai 네임스페이스로 학습돼 있어서, 이 스킬 파일이 현재 API를 올바르게 쓰게 도와줌
단기와 장기에서 이 API의 타깃 사용처를 어떻게 보고 있는지 궁금함
또 이런 걸 만들 때 브라우저들끼리 W3C 차원이 아니라 실무적으로 서로 조율해서 공통점을 맞추려 하는지도 궁금함. 결국 이 업계는 꽤 좁은 편이니까
은퇴 축하드림
이건 실제로 돌아가고, 나는 이미 local inference 용도로 출시해봤음
검색 같은 저사양 LLM 작업에서 일종의 가난한 사람용 ollama처럼 쓸 수 있었음. 가장 큰 장점은 무료이고 프라이버시를 지키며, 사용자가 거의 아무것도 안 해도 되니 비기술 사용자에게 로컬 추론을 주기 좋다는 것임
다만 실제 사용자 경험은 좋지 않음. 모델 다운로드 크기가 브라우저 자체보다 몇 자릿수는 더 크고, 첫 토큰을 받기 전에 그 과정을 끝내야 함
이건 운영체제가 미리 구워 넣은 모델을 안정적으로 제공하고, 이런 API가 거기에 붙을 수 있게 되기 전까진 해결이 어려워 보임
이건 Prompt API를 쓰는 모든 사이트가 공유하는 1회성 다운로드임
더 큰 문제는 대부분의 일반 PC에서 모델이 너무 작고 느리다는 점임. infocom 텍스트 어드벤처의 문장을 실시간으로 바꿔보려 했는데, 지금은 많은 PC에서 너무 느려서 실용적이지 않음
다음 큰 흐름은 아예 5090 여러 장을 끼워 파는 소프트웨어 구독 프리미엄일지도 모르겠음
MoE 모델이라면 전문가 레이어를 필요할 때만 네트워크에서 HTTP range query로 가져올 수 있음
bittorrent가 여러 호스트에서 파일 조각을 받는 방식과 비슷함. 공용 레이어는 여전히 받아야 하지만, 첫 토큰까지 걸리는 시간은 전체 크기보다 활성 크기에 비례하게 만들 수 있음
물론 그러면 완전한 오프라인 추론은 아니지만, 브라우저 웹 기능이라면 그건 핵심 고려사항은 아닐 수 있음
운영체제가 사전 탑재 모델을 안정적으로 넣어주는 세상이 오지 않기를 바람
정말 좋음
다만 모델이 브라우저보다 훨씬 크고 첫 토큰 전에 다운로드가 필요하다면, 이게 지연 다운로드라는 뜻인지 궁금함. 처음 호출하는 사용자는 그 시점에 다운로드가 끝날 때까지 기다려야 한다는 얘기라면 사용자 경험이 꽤 끔찍해 보임
Chrome이 다운로드 상태 대화상자 같은 걸 보여줘서 혼란을 줄이는지도 궁금하고, 디스크 사용량이 어느 정도인지도 알고 싶음
겉보기엔 이게 Gemini Nano를 쓰는 듯한데, 최신 Gemma 4 E2B/E4B가 훨씬 좋아 보여서 당장은 확장으로 양자화 버전을 배포하는 편이 나을 수도 있음
지금은 내부 사정을 모르지만, 내가 이 팀에 있던 시절에는 최신 소형 Google 모델을 Chrome에 굉장히 빨리 넣었음
Gemma 4나 그에 대응하는 Gemini Nano가 아직 Chrome에 없다면 곧 들어갈 거라 예상함
그리고 이 글은 2025-09-21에 마지막 업데이트됐고, 그 시점엔 이미 Gemini Nano 3였음
맞음
Prompt API는 브라우저 안의 Gemini Nano에 자연어 요청을 보내는 방식이라고 적혀 있음
Prompt API는 브라우저에서 사용 가능한 모델을 씀
Edge에선 아마 Phi4일 것 같음
이건 악성 JS 스크립트가 아무것도 모르는 방문자들에게 토큰 생성을 떠넘기게 만드는 좋은 수단처럼 보이기도 함
더 큰 프롬프트를 잘게 쪼개 여러 브라우저에 보내고, 각각이 작은 조각만 처리하는 subagent 패턴이나 RLM 비슷한 구조로 유용한 결과를 만드는 분산화가 가능한지도 흥미로울 듯함
보상 대비 일이 너무 커 보임
기술적·사업적 인프라도 엄청 복잡해질 텐데, 굳이 사용자 브라우저에 프롬프트를 떠넘기고 싶다면 그냥 Chrome API를 제대로 쓰는 편이 낫지 않나 싶음. 이런 저사양 모델에 서버 측 프롬프트를 오프로딩해서 실제로 유의미할 경우가 얼마나 될지도 의문임
게다가 정말 그렇게 하고 싶다면 WebGPU도 이미 한참 전부터 있었음
작은 모델의 토큰 생성 정도는 거의 가치가 없음
이건 제대로 된 Model API로 가는 한 걸음처럼 보이지만, 아직은 작은 걸음에 불과함
Apple의 Foundation Models도 떠오름
많은 AI 통합이 텍스트 커뮤니케이션이나 채팅 스타일에 집중돼 있지만, 실제로는 비텍스트 인터페이스에서 이득 보는 소프트웨어도 많음
결국 OS와 브라우저가 모델을 관리하는 API를 제공해서, 앱이 단순한 인터페이스로 온디바이스 모델과 원격 모델에 접근할 수 있어야 한다고 봄
이게 크로스플랫폼으로 표준화되면 정말 좋겠고, 모바일까지 포함돼야 하니 현실적으로 쉽게 밀어붙일 수 있는 쪽은 Apple과 Google이 대부분일 듯함. Meta가 뒤따르거나 반대로 먼저 움직일 수도 있겠지만
핵심은 특정 홍보 모델 전용이어선 안 된다는 것임
앱은 질의해서 적절한 모델을 골라 쓸 수 있어야 함
(1) https://developer.apple.com/documentation/foundationmodels
Apple의 Foundation Models는 문서상으론 좋아 보이지만, 막상 보면 4k 컨텍스트 윈도우가 걸림
물론 아직은 초반 단계이긴 함
브라우저에서 접근 가능한 로컬 LLM은 프라이버시 측면에선 좋지만, 브라우저마다 이 API 뒤에 붙는 모델이 다르면 테스트 악몽이 지금보다 더 심해질 듯함
결국 대부분의 구현이 Gemini Nano 기준으로 맞춰질 가능성이 있어서, 이게 사용자를 Chrome 쪽으로 더 몰아갈지도 궁금함
테스트 파편화가 진짜 핵심 문제임
실제로 프롬프트는 모델 불가지론적이지 않아서, Gemini Nano 3 v2025에 맞춰 정교하게 튜닝한 프롬프트가 Gecko 쪽 모델에서는 조용히 성능이 떨어질 수 있음. 그런데 API는 분기 처리할 능력 탐지조차 주지 않음
이건 적어도 확장 지원 여부를 질의할 수 있었던 WebGL보다 더 나쁨. 이름도 버전도 브라우저 뒤에 숨겨진 모델의 프롬프트 품질에 의존해 기능을 출시하는 건, 사용자가 설치한 사전에 기능이 좌우되는 소프트웨어를 내놓는 것과 비슷함
Gemini Nano는 Gemma와 달리 오픈 웨이트가 아니지 않나 싶음
누가 이미 해뒀다면 모르겠지만, 모델 가중치를 덤프해보고 싶음
Hacker News 의견들
이 API는 내가 오래 생각하던 de-snarkifier 아이디어에 딱 맞아 보임
소셜 미디어는 지적으로 자극적이고 배울 것도 있지만, 원치 않아도 이념적 말싸움과 플레임워에 빨려 들어가기 쉬움. 인터넷에서 모르는 사람과 감정 소모하며 싸우는 건 인간 자본 낭비에 가까움
이런 API가 있으면 브라우저 확장으로 글을 보여주기 전에 공격적이거나 비꼬는 표현만 순화하고, 사실 정보는 그대로 보존하게 만들 수 있을 듯함. 더 나아가 공격적인 톤일수록 우스꽝스럽거나 무능하게 들리도록 바꿔버릴 수도 있음
그러면 읽는 사람은 낯선 이들의 인신공격에서 보호되고, 쓰는 사람도 무례하게 굴 유인이 사라짐. 다들 이런 필터를 쓰면 누가 더 못되게 구는지 경쟁할 이유도 없어짐
영양가는 다 있는데 맛은 특별할 것 없다는 느낌임
내가 원하는 건 전부 클릭베이트 제목과 광고를 없애고, 건조한 사실형 제목만 보여주는 것임
어떤 주제든 핵심 기사 하나와 실질적인 댓글 몇 개만 있으면 충분하고, 나머지는 대부분 보고 싶지 않은 잡음임
지금 소셜 미디어 상태가 너무 나빠서 거의 안 쓰고 있고, HN만 예외였는데 여기도 AI 포화로 비슷한 방향으로 가는 듯함. 그래도 격주쯤 몇 시간을 허비하게 되는데, 그마저 완전히 끊고 싶음
이상적으로는 콘텐츠의 98%를 필터링하거나 요약해서 없애고, 시간이 갈수록 인터넷은 의도적으로 검색할 때만 쓰게 되면 좋겠음. 기본적으로 인터넷의 엔터테인먼트성을 대부분 제거해서 시간과 에너지를 현실과 책 같은 고품질 소스로 돌리고 싶음
이 확장은 크라우드소싱으로 선정성을 줄이려는 도구인데, 상위 기여자 중 일부는 LLM 봇일 수도 있겠다는 생각이 듦
다만 이런 건 현실과 맞부딪히면 예측 불가능하고, 잘 되더라도 처음 상상한 방식과는 꽤 다르게 작동할 가능성이 큼
못 참고 Snarknada 프로토타입을 급히 만들어 보면서 저지연 패턴과 정확도 가능성을 같이 살펴봤음
이런 유형의 사용처에선 온디바이스가 맞다고 보는 이유가 정확히 여기에 있음. 무한 스크롤 피드 전체를 클라우드 API로 순화하려면 토큰 비용이 개발자 입장에서 감당 안 될 정도로 커짐. 게다가 개인 피드나 DM을 톤 정리하려고 제3자 서버로 보내고 싶어 하지 않는 것도 당연함
이걸 기기 안으로 옮기면 고빈도 Semantic Mutation이 비용과 기술 면에서 처음으로 현실화될 수 있음. 내 장난감 같은 PM 프로토타입보다 더 진지하게 만들다가 구체적인 마찰 지점이 생기면 꼭 듣고 싶음. 로드맵 우선순위를 정하는 데 도움이 됨
[1]: 코딩 에이전트(Cursor, Claude Code 등)를 쓴다면 https://www.npmjs.com/package/built-in-ai-skills-md-agent-md를 가리키는 걸 추천함. 많은 모델이 이제는 구식이 된 window.ai 네임스페이스로 학습돼 있어서, 이 스킬 파일이 현재 API를 올바르게 쓰게 도와줌
이 API 디자인 작업을 주도했고, 은퇴 전에 관련 설계 고려사항을 정리한 글도 써뒀음
https://domenic.me/builtin-ai-api-design/
또 이런 걸 만들 때 브라우저들끼리 W3C 차원이 아니라 실무적으로 서로 조율해서 공통점을 맞추려 하는지도 궁금함. 결국 이 업계는 꽤 좁은 편이니까
이건 실제로 돌아가고, 나는 이미 local inference 용도로 출시해봤음
검색 같은 저사양 LLM 작업에서 일종의 가난한 사람용 ollama처럼 쓸 수 있었음. 가장 큰 장점은 무료이고 프라이버시를 지키며, 사용자가 거의 아무것도 안 해도 되니 비기술 사용자에게 로컬 추론을 주기 좋다는 것임
다만 실제 사용자 경험은 좋지 않음. 모델 다운로드 크기가 브라우저 자체보다 몇 자릿수는 더 크고, 첫 토큰을 받기 전에 그 과정을 끝내야 함
이건 운영체제가 미리 구워 넣은 모델을 안정적으로 제공하고, 이런 API가 거기에 붙을 수 있게 되기 전까진 해결이 어려워 보임
더 큰 문제는 대부분의 일반 PC에서 모델이 너무 작고 느리다는 점임. infocom 텍스트 어드벤처의 문장을 실시간으로 바꿔보려 했는데, 지금은 많은 PC에서 너무 느려서 실용적이지 않음
bittorrent가 여러 호스트에서 파일 조각을 받는 방식과 비슷함. 공용 레이어는 여전히 받아야 하지만, 첫 토큰까지 걸리는 시간은 전체 크기보다 활성 크기에 비례하게 만들 수 있음
물론 그러면 완전한 오프라인 추론은 아니지만, 브라우저 웹 기능이라면 그건 핵심 고려사항은 아닐 수 있음
다만 모델이 브라우저보다 훨씬 크고 첫 토큰 전에 다운로드가 필요하다면, 이게 지연 다운로드라는 뜻인지 궁금함. 처음 호출하는 사용자는 그 시점에 다운로드가 끝날 때까지 기다려야 한다는 얘기라면 사용자 경험이 꽤 끔찍해 보임
Chrome이 다운로드 상태 대화상자 같은 걸 보여줘서 혼란을 줄이는지도 궁금하고, 디스크 사용량이 어느 정도인지도 알고 싶음
겉보기엔 이게 Gemini Nano를 쓰는 듯한데, 최신 Gemma 4 E2B/E4B가 훨씬 좋아 보여서 당장은 확장으로 양자화 버전을 배포하는 편이 나을 수도 있음
출처:
Gemma 4나 그에 대응하는 Gemini Nano가 아직 Chrome에 없다면 곧 들어갈 거라 예상함
그리고 이 글은 2025-09-21에 마지막 업데이트됐고, 그 시점엔 이미 Gemini Nano 3였음
Prompt API는 브라우저 안의 Gemini Nano에 자연어 요청을 보내는 방식이라고 적혀 있음
Edge에선 아마 Phi4일 것 같음
이건 악성 JS 스크립트가 아무것도 모르는 방문자들에게 토큰 생성을 떠넘기게 만드는 좋은 수단처럼 보이기도 함
더 큰 프롬프트를 잘게 쪼개 여러 브라우저에 보내고, 각각이 작은 조각만 처리하는 subagent 패턴이나 RLM 비슷한 구조로 유용한 결과를 만드는 분산화가 가능한지도 흥미로울 듯함
기술적·사업적 인프라도 엄청 복잡해질 텐데, 굳이 사용자 브라우저에 프롬프트를 떠넘기고 싶다면 그냥 Chrome API를 제대로 쓰는 편이 낫지 않나 싶음. 이런 저사양 모델에 서버 측 프롬프트를 오프로딩해서 실제로 유의미할 경우가 얼마나 될지도 의문임
게다가 정말 그렇게 하고 싶다면 WebGPU도 이미 한참 전부터 있었음
이건 제대로 된 Model API로 가는 한 걸음처럼 보이지만, 아직은 작은 걸음에 불과함
Apple의 Foundation Models도 떠오름
많은 AI 통합이 텍스트 커뮤니케이션이나 채팅 스타일에 집중돼 있지만, 실제로는 비텍스트 인터페이스에서 이득 보는 소프트웨어도 많음
결국 OS와 브라우저가 모델을 관리하는 API를 제공해서, 앱이 단순한 인터페이스로 온디바이스 모델과 원격 모델에 접근할 수 있어야 한다고 봄
이게 크로스플랫폼으로 표준화되면 정말 좋겠고, 모바일까지 포함돼야 하니 현실적으로 쉽게 밀어붙일 수 있는 쪽은 Apple과 Google이 대부분일 듯함. Meta가 뒤따르거나 반대로 먼저 움직일 수도 있겠지만
핵심은 특정 홍보 모델 전용이어선 안 된다는 것임
앱은 질의해서 적절한 모델을 골라 쓸 수 있어야 함
(1) https://developer.apple.com/documentation/foundationmodels
물론 아직은 초반 단계이긴 함
https://github.com/mozilla/standards-positions/issues/1067
우리는 이걸 해크데이 회고 요약에 쓰고 있음
https://remotehack.space/previous-hacks/
RSS 피드를 읽고 본문으로 요약을 생성하는 작은 스크립트인데, 정적 사이트와 꽤 잘 맞음. 언젠가는 같은 콘텐츠에 대해 다른 질문도 던지도록 확장하고 싶음
브라우저에서 접근 가능한 로컬 LLM은 프라이버시 측면에선 좋지만, 브라우저마다 이 API 뒤에 붙는 모델이 다르면 테스트 악몽이 지금보다 더 심해질 듯함
결국 대부분의 구현이 Gemini Nano 기준으로 맞춰질 가능성이 있어서, 이게 사용자를 Chrome 쪽으로 더 몰아갈지도 궁금함
실제로 프롬프트는 모델 불가지론적이지 않아서, Gemini Nano 3 v2025에 맞춰 정교하게 튜닝한 프롬프트가 Gecko 쪽 모델에서는 조용히 성능이 떨어질 수 있음. 그런데 API는 분기 처리할 능력 탐지조차 주지 않음
이건 적어도 확장 지원 여부를 질의할 수 있었던 WebGL보다 더 나쁨. 이름도 버전도 브라우저 뒤에 숨겨진 모델의 프롬프트 품질에 의존해 기능을 출시하는 건, 사용자가 설치한 사전에 기능이 좌우되는 소프트웨어를 내놓는 것과 비슷함
Gemini Nano는 Gemma와 달리 오픈 웨이트가 아니지 않나 싶음
누가 이미 해뒀다면 모르겠지만, 모델 가중치를 덤프해보고 싶음