브라우저 API가 모두 ‘웹’ API는 아님

• 웹 플랫폼은 표준화된 API 위에서 동일하게 동작한다는 인식이 널리 퍼져 있으나, 실제로는 브라우저 벤더별 인프라에 의존하는 API가 다수 존재함
• Geolocation, Speech, Push, Payments, Passkeys 등은 표면적으로는 웹 표준이지만, 내부적으로는 Google·Apple·Microsoft의 서비스를 호출
• 동일한 API 호출이라도 정확도·가용성·지역별 비호환성·프라이버시 정책이 브라우저마다 크게 달라지고, 개발자는 이를 인지하지 못한 채 의존하게 됨
• 대형 벤더 중심의 표준화 구조가 중소 브라우저와 오픈소스 생태계의 진입 장벽을 높이고 사실상 잠금 효과(lock-in) 를 강화함
• 개발자는 이러한 API를 순수 ‘웹 표준’이 아닌 벤더 서비스 추상화 계층으로 인식하고, 프라이버시 고지·대체 설계·브라우저별 테스트를 병행해야 함

웹 플랫폼에 대한 일반적 인식과 실제 구조

• 웹 플랫폼은 표준 스펙 기반의 통합 시스템으로 인식되며, 동일 엔진 기반 브라우저에서는 동일 동작을 기대함
• 실제로는 다수의 API가 브라우저별 독자 구현 및 제3자 서비스·독점 인프라·벤더 내부 시스템에 의존
• 표준화된 인터페이스와 달리 구현 세부는 브라우저 벤더의 선택에 따라 크게 달라짐

Geolocation API와 위치 정보의 실제 출처

• Geolocation API는 표준화된 인터페이스를 제공하지만, 실제 위치 정보는 다양한 경로를 통해 수집됨
  • OS 위치 서비스 및 GPS 활용
  • Wi-Fi AP 정보 기반 위치 추정
  • IP 주소 기반 위치 데이터베이스 조회
• Chrome은 Google Location Services, Safari는 Apple 서버, Firefox는 2024년 이후 Google 서비스 사용 중
• 위치 정보 사용 시 사용자 데이터가 특정 벤더 서버로 전송될 수 있으나, 브라우저 UI에서는 명시적으로 드러나지 않음
• 특정 지역에서 벤더 서비스 접근이 차단될 경우 기능이 정상 동작하지 않을 가능성 존재

Speech Synthesis와 음성 처리 인프라

• Web Speech API의 음성 합성은 브라우저와 OS, 기기 환경에 따라 서로 다른 엔진을 사용
• Speech Synthesis API는 표준화된 인터페이스지만, 음성 데이터는 운영체제 TTS 엔진 또는 클라우드 서버에서 처리
  • Chrome은 로컬·클라우드 병행, Safari는 OS 음성 엔진 사용
  • 일부 고품질 음성은 클라우드 기반 처리를 위해 온라인 전송이 필요해 사용자 데이터가 서버로 전송됨
  • 개인 메시지나 민감 정보가 의도치 않게 외부 서버로 전송될 위험 존재
• 또한, 테스트 환경에서 선택한 음성이 사용자 환경에서는 존재하지 않을 수 있음

Speech Recognition과 실시간 음성 전송

• Speech Recognition API는 대부분 클라우드 인식 서비스에 의존
  • Chrome은 Google, Safari는 Apple, Edge는 Azure 계열 서비스 활용
  • Chrome 139부터 processLocally 옵션으로 로컬 처리 가능하지만 기본값이 아니며, 이 역시 Chrome 한정 기능
  • 정확도 및 언어 지원이 벤더별 모델 품질에 따라 차이 발생

Passkeys와 WebAuthn의 실제 기반: 브라우저 생태계 종속

• WebAuthn API는 비밀번호 없는 인증을 표방하지만, 실제로는 브라우저의 비밀번호 관리자 인프라에 종속
  • Chrome은 Google Password Manager, Safari는 iCloud Keychain, Edge는 Microsoft Account 사용
  • Polypane 등은 Electron 한계로 Passkey 미지원, 1Password 같은 확장 사용 필요
• 자격 증명 저장·동기화·복구 방식은 전적으로 벤더별 구현에 따라 결정됨

Payment Request API와 결제 벤더 종속

• Payment Request API는 표준처럼 보이지만, 실제 결제는 벤더 파트너에 따라 작동 여부가 달라짐
• Chrome은 Google Pay, Safari는 Apple Pay, Edge는 Microsoft 통합, Firefox는 미지원
• 지역별 지원 여부, UX, 추가 사용자 설정 요구 사항이 브라우저마다 상이함
• 결과적으로 각 결제 수단에 대한 별도 계약과 대응 로직 필요

Push API와 벤더별 알림 네트워크

• Push API는 표주이지만, 브라우저별로 실제 알림 전달에 사용하는 서버 인프라가 다름
• Chrome/Edge는 FCM, Safari는 APNs, Firefox는 Mozilla Push Service 사용
• 전송 제한, 메시지 크기, 오프라인 처리, 프라이버시 정책이 서비스별로 상이
• 벤더 인프라 장애 시 해당 브라우저의 푸시 기능 전체 영향 가능성

미디어 API, 코덱, DRM 문제

• Media Source Extensions(MSE) 와 Encrypted Media Extensions(EME) 는 표준이지만, 코덱·DRM 라이선스에 따라 지원이 달라짐
• Chrome·Edge·Firefox는 Widevine, Safari는 FairPlay 사용하는 등 완전한 독점 기술에 의존
• 브라우저 벤더별로 선호 코덱과 전략이 다름
• DRM 라이선스 비용과 기술 제약으로 소형 브라우저는 지원 어려움

브라우저내 AI API의 등장: 새로운 독점 구조

• Chrome은 Gemini Nano 기반 AI API(요약·번역·교정 등)를 실험 중
• 로컬 실행으로 데이터 전송은 없지만, 모델 크기(약 4GB) 와 GPU 요구가 높고 Google 독점 모델
• 다른 브라우저는 자체 모델을 개발해야 하며, 소규모 브라우저나 오픈소스 프로젝트는 동일한 모델 확보·유지 불가능하여 경쟁 불가
• 이는 AI 기반의 새로운 벤더 종속 구조

왜 중요한가

• 이식성 문제: 동일 코드라도 브라우저·지역·환경에 따라 동작 품질이 달라질 수 있음
• 프라이버시 위험: 음성·위치·푸시 데이터가 의도치 않게 벤더 서버로 전송될 수 있음
• 표준화의 불균형: 대형 기업이 명세 작성과 구현을 주도하고, 자신들의 인프라를 사실상 필수 조건으로 만들어 소형 브라우저가 배제됨
• 개발자 영향: 기능은 유용하지만, 표준이 아닌 서비스 의존성을 인식해야 함

개발자가 취해야 할 접근

• API를 벤더 서비스 추상화 계층으로 인식하고, 테스트·문서화·대체 경로를 마련
• 점진적 저하(graceful degradation) 설계로 기능 불일치 대비
• 프라이버시 투명성 확보: 데이터가 제3자 서버로 전송될 가능성 명시
• 벤더 종속성 관리: 서비스 중단·정책 변경 시 대응 방안 필요
• 브라우저·지역별 테스트로 품질 차이 확인
• 전략적 선택으로 벤더 의존을 최소화

우리가 생각하는 웹 vs 실제의 웹

• 표준화된 API 호출은 동일하지만, 데이터 흐름·정확도·지역 지원·프라이버시·비용 구조는 브라우저마다 다름
  • navigator.geolocation.getCurrentPosition() 호출은 사실상 Google 또는 Apple 위치 서비스 호출
• 표준 명세는 인터페이스만 정의하며, 실제 동작은 벤더 인프라와 정책에 종속
  • API 호출은 곧 특정 벤더의 서버·정책·비즈니스 모델을 사용하는 행위임
• 웹 플랫폼은 강력하지만, 실제로는 더 분절되고 벤더 중심적인 구조임
• 개발자는 표준과 구현의 경계를 명확히 이해하고 설계해야 함