안녕하세요! 요즘 블로그 자동화 파이프라인 깎느라 밤낮없이 스크립트와 씨름 중인 DevBJ입니다. 🚀
최근 웹 개발이나 AI 자동화 쪽에 관심 있는 분들이라면 솔깃할 만한 소식이 하나 있었죠. 바로 Chrome에서 추진 중인 **‘Prompt API’**입니다. 웹 페이지에서 서버를 거치지 않고, 브라우저에 내장된 LLM(대형 언어 모델)을 직접 호출해서 쓸 수 있게 해주는 API인데요.
“와! 이거 되면 내 서버 API 호출 비용 아끼고 완전 개꿀인데?” 하면서 좋아하고 있었는데… 모질라(Mozilla) 측에서 공식적으로 ‘반대(Negative)’ 입장을 냈습니다.
오늘은 왜 모질라가 제동을 걸었는지, 웹 엔지니어 입장에서 아는 만큼 정리해 볼까 합니다. 틀려도 봐주세요~~ 💡
1. Prompt API, 뭐가 문제라는 걸까?
간단히 말해 **‘상호운용성(Interoperability) 파괴’**에 대한 우려입니다.
예전에 웹 퍼블리싱 해보신 분들은 아실 겁니다. IE6 시절 특정 브라우저에만 맞춰서 사이트 짜느라 며칠 밤을 새웠던 끔찍한 삽질의 기억이 나네요 ^^;;
AI 프롬프트라는 게 모델마다 성격이 다 다릅니다. 만약 개발자가 Chrome에 내장된 Google 모델이나, Edge의 Phi-4-mini 같은 특정 모델의 ‘입맛(Quirk)‘에 딱 맞춰서 프롬프트를 깎아놨다고 가정해 보죠.
- Chrome 접속 시: AI가 찰떡같이 알아듣고 완벽한 결과를 보여줌.
- Firefox (다른 모델 사용) 접속 시: AI가 헛소리를 하거나, 심하면 사이트 기능 자체가 차단됨.
결국 브라우저 파편화가 일어나고, 다른 브라우저들은 울며 겨자 먹기로 “구글 모델이랑 똑같이 동작하는 호환 모드”를 만들어야 하는 압박을 받게 됩니다.
2. 모질라의 제안: 기본 방식 vs 최적화(안전) 방식
모질라는 이 기술을 당장 웹 표준 API로 박아버리는 것에 반대하며, 더 안전한 접근법을 제시했습니다.
- 기본 방식 (현재 Chrome의 접근): Web API로 바로 출시. (브라우저 종속적 프롬프트 양산 위험)
- 최적화 방식 (모질라의 제안): Web Extension(확장 프로그램) 생태계에서 먼저 충분히 테스트!
모질라는 이 기능이 아직 표준화할 준비가 안 되었다고 판단했습니다. 그래서 웹 API로 바로 내보내기보다는, 사용자 단(Userland)에서 Extension 형태로 먼저 실험하며 의미론(Semantics)을 맞춰나가는 게 훨씬 부담이 적고 안전하다는 거죠. 확장 프로그램은 사용자가 명시적으로 설치하는 거니까, 페이지 내에서 몰래 모델을 호출하는 것보다 사용자 경계도 명확해집니다.
3. 강력 추천합니다! (이런 분들은 꼭 대비하세요)
주의할 점은!!!! AI 기능을 웹 프론트에 직접 붙이려는 분들은 당분간 브라우저 내장 API만 믿고 아키텍처를 짜면 안 된다는 겁니다.
- 추천 대상: 클라이언트 사이드 AI 기능을 도입하려는 프론트엔드 개발자, 브라우저 확장 프로그램 개발자.
- 한 줄 요약: 브라우저 내장 AI는 낭만적이지만, 표준화 전까지는 모델 파편화 지옥이 열릴 수 있으니 서버사이드 API나 Extension 기반으로 우회하자!
DevBJ | No Bio, Just Log #오늘을살자