Chrome의 Prompt API에 제동 건 Mozilla, HN이 잠금 효과를 걱정한 이유

Mozilla가 Chrome의 Prompt API에 반대한 일을 HN은 평범한 표준 문서 싸움으로 읽지 않았다. 오래된 웹의 악몽이 AI 껍데기를 쓰고 돌아온다는 감각이 더 컸다. 개발자가 한 모델의 말투와 버릇에 맞춰 프롬프트를 다듬기 시작하면, 웹의 휴대성은 다시 특정 벤더 스택 쪽으로 휘어진다. HN이 바로 그 지점에 반응했다.

쟁점의 첫 줄은 상호운용성이다. Mozilla 쪽 코멘트는 시스템 프롬프트가 눈앞의 모델 특성에 맞춰 계속 조정된다고 짚는다. Google 모델에 맞는 프롬프트가 다른 모델에서는 과보정이 되거나 아예 어긋날 수 있다는 뜻이다. 여기서 한 단계만 더 가면 다른 브라우저는 사이트 호환성을 위해 Google 모델을 라이선스하거나, 최소한 그 버릇을 흉내 내야 하는 상황으로 밀린다. 개발자도 그 위험을 예상해 모델 종류를 알아낸 뒤 벤더별로 프롬프트를 나누기 시작할 수 있다. HN이 떠올린 장면은 낯설지 않았다. 한때 웹을 지저분하게 만들었던 브라우저별 분기 코드가 AI 레이어에서 다시 살아나는 그림이다.

두 번째는 업데이트 문제다. 웹앱이 특정 모델의 성격에 조용히 의존하면, Chrome이 자기 모델을 바꾸는 일조차 위험해진다. 더 나은 모델을 넣어도 결과가 오히려 나빠 보일 수 있다. 세상에 퍼진 프롬프트가 전부 어제 모델의 버릇에 맞춰져 있기 때문이다. HN이 이 대목을 흥미롭게 본 이유는 AI 표류를 연구실 문제가 아니라 플랫폼 문제로 바꿔 놓기 때문이다. 어떤 댓글은 브라우저가 공통 표준 모델 묶음을 가져야 한다고 했고, 다른 댓글은 그런 중립 장치도 없이 브라우저가 이런 API를 먼저 싣는 게 맞느냐고 물었다.

세 번째는 중립성이다. Mozilla는 Chrome 문서가 API 사용 전에 Google의 생성형 AI 사용 정책을 인정하라고 요구한다고 지적했다. HN은 이걸 단순한 약관 문장으로 넘기지 않았다. 사이트가 댓글 요약 버튼 하나를 붙였을 때, 밑에서 도는 모델이 벤더별 콘텐츠 규칙을 갖고 있다면 책임이 누구에게 돌아가는지 흐려진다. 클릭한 이용자인지, 기능을 만든 사이트 운영자인지, 모델 제공자인지 바로 답이 나오지 않는다. 이 불확실성은 개발자가 브라우저 뒤에 어떤 모델이 있는지 더 집요하게 확인하게 만든다.

그래서 이 스레드가 뜨거웠다. HN이 따진 건 브라우저 AI가 멋지냐 아니냐가 아니다. 가장 먼저 대중화될 가능성이 있는 브라우저 AI API가 웹이 가장 중립적으로 지키려 했던 층위에 잠금 효과, 호환성 꼼수, 약관 부담을 다시 들여오고 있는지 여부였다.