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

> Clean Markdown view of GeekNews topic #25974. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=25974](https://news.hada.io/topic?id=25974)
- GeekNews Markdown: [https://news.hada.io/topic/25974.md](https://news.hada.io/topic/25974.md)
- Type: news
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-01-20T11:31:01+09:00
- Updated: 2026-01-20T11:31:01+09:00
- Original source: [polypane.app](https://polypane.app/blog/not-all-browser-apis-are-web-apis/)
- Points: 17
- Comments: 0

## Summary

웹 API가 곧 ‘웹 표준’이라는 인식은 현실과 거리가 있습니다. Geolocation, Speech, Push, Payments, Passkeys 등은 표준 인터페이스를 따르지만 실제로는 **Google·Apple·Microsoft의 인프라**에 의존하며, 동일한 코드라도 브라우저·지역·정책에 따라 결과가 달라집니다. 개발자는 이를 **벤더 서비스 추상화 계층**으로 인식하고, 프라이버시 고지와 대체 설계, 브라우저별 테스트를 병행해야 안정적인 사용자 경험을 보장할 수 있습니다.

## Topic Body

- 웹 플랫폼은 **표준화된 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 호출은 곧 특정 벤더의 서버·정책·비즈니스 모델을 사용하는 행위임  
- 웹 플랫폼은 강력하지만, 실제로는 **더 분절되고 벤더 중심적인 구조**임  
- 개발자는 **표준과 구현의 경계**를 명확히 이해하고 설계해야 함

## Comments



_No public comments on this page._