웹 개발을 하다 보면 우리는 '웹 플랫폼(Web Platform)'이라는 용어를 자주 사용합니다. 이는 전 세계적으로 통용되는 표준 사양에 따라 모든 브라우저가 동일하게 동작하는 하나의 거대한 생태계를 의미하죠. 하지만 우리가 매일 사용하는 수많은 API 중에서, 사실은 '웹 표준'이 아닌 '브라우저 제조사의 서비스'에 불과한 것들이 많다는 사실을 알고 계셨나요?
오늘은 Polypane의 최신 아티클 "Not all browser APIs are Web APIs"**의 내용을 바탕으로, 우리가 당연하게 여겼던 웹 기능들의 이면에 숨겨진 진실과 개발자가 주의해야 할 점들을 자세히 번역하고 정리해 드리겠습니다.
1. 표준화의 환상: 당신의 위치 정보는 어디서 오는가?
브라우저가 동일한 사양(Specification)을 구현한다고 해서 그 결과물까지 완벽히 동일한 것은 아닙니다. 가장 대표적인 예가 바로 Geolocation API입니다.
우리가 navigator.geolocation.getCurrentPosition()을 호출할 때, 브라우저는 표준화된 방식으로 위도와 경도를 반환합니다. 하지만 그 '데이터'를 가져오는 방식은 브라우저마다 다릅니다. 크롬(Chrome)은 구글의 위치 서비스를 사용하고, 사파리(Safari)는 애플의 서비스를 사용하며, 파이어폭스(Firefox)는 구글이나 모질라의 데이터를 활용합니다.
이것이 왜 중요할까요? 바로 정확도와 프라이버시 때문입니다. 같은 장소에서 같은 코드를 실행하더라도 브라우저 제조사가 사용하는 백엔드 인프라에 따라 위치 정보의 오차 범위가 달라질 수 있습니다. 이는 "API가 표준"이라고 해서 "데이터의 품질까지 표준"인 것은 아님을 시사합니다.
2. Speech API: 구름 위에서 들려오는 목소리
웹 페이지에서 텍스트를 읽어주는 Speech Synthesis API와 목소리를 인식하는 Speech Recognition API는 더욱 극명한 차이를 보입니다.
- Speech Synthesis (음성 합성): 여러분이 사용하는 브라우저의 목소리가 어떤 때는 아주 기계적이고, 어떤 때는 사람처럼 자연스러운 이유를 궁금해한 적 없으신가요? 어떤 브라우저는 운영체제(OS)의 내장 음성을 사용하지만, 크롬 같은 브라우저는 구글 서버에서 생성된 고품질의 음성을 실시간으로 스트리밍하기도 합니다. 즉, 인터넷 연결이 끊기면 목소리의 종류가 바뀌거나 기능 자체가 작동하지 않을 수 있다는 뜻입니다.
- Speech Recognition (음성 인식): 더 심각한 것은 인식 기능입니다. 대부분의 브라우저는 음성 데이터를 제조사의 서버(구글, 애플 등)로 보내 분석한 뒤 결과만 돌려줍니다. 이는 단순한 API 호출을 넘어, 사용자의 음성 데이터가 제3의 서버로 전송된다는 프라이버시 이슈를 내포하고 있습니다. 개발자는 이를 단순히 '웹 기술'로만 치부해서는 안 됩니다.
3. Passkeys와 결제 API: 브라우저에 종속된 사용자 경험
최근 각광받는 **Passkeys(WebAuthn)**와 Payment Request API 역시 겉보기에는 웹 표준이지만, 실제 구현은 브라우저 제조사의 플랫폼 서비스에 깊게 뿌리박고 있습니다.
- Passkeys: 이는 단순한 암호화 기술을 넘어 브라우저의 비밀번호 관리자(iCloud 키체인, 구글 비밀번호 관리자 등)와 긴밀하게 연결됩니다. 사용자가 어떤 에코시스템(iOS, Android, Windows)을 쓰느냐에 따라 사용자 경험이 완전히 달라지며, 개발자가 이를 제어할 수 있는 권한은 극히 제한적입니다.
- Payment Request API: 결제 버튼을 누를 때 뜨는 UI는 브라우저가 제공하는 기능입니다. 하지만 그 밑단에는 애플 페이(Apple Pay)나 구글 페이(Google Pay) 같은 제조사의 결제 게이트웨이가 자리 잡고 있습니다. 특정 브라우저에서만 특정 결제 수단이 강제되거나 활성화되는 현상은 이것이 '순수한 웹 표준'이라기보다 '제조사 서비스의 웹 인터페이스'에 가깝다는 증거입니다.
4. Web Push: 세 개의 서로 다른 네트워크
푸시 알림(Web Push)은 브라우저가 꺼져 있어도 사용자에게 정보를 전달할 수 있는 강력한 도구입니다. 하지만 이 역시 '푸시 서버'라는 거대한 인프라가 뒤를 받치고 있습니다.
크롬은 **FCM(Firebase Cloud Messaging)**을 사용하고, 사파리는 **APNs(Apple Push Notification service)**를, 파이어폭스는 모질라의 자체 푸시 서비스를 사용합니다. 개발자는 표준화된 Push API를 사용해 코드를 짜지만, 실제 알림이 전송되는 경로는 제조사마다 완전히 다릅니다. 만약 특정 제조사의 푸시 서버에 장애가 발생한다면, 여러분의 웹 서비스는 해당 브라우저 사용자들에게 알림을 보낼 수 없게 됩니다. 이는 명백한 벤더 종속(Vendor Lock-in) 사례입니다.
5. 개발자가 가져야 할 실전 전략
그렇다면 우리는 이러한 "가짜 웹 표준"의 시대에 어떻게 대응해야 할까요? 아티클은 다음과 같은 구체적인 가이드라인을 제시합니다.
- 기능 감지(Feature Detection)의 고도화: 단순히 API가 존재하는지(
'share' in navigator)만 체크하는 것을 넘어, 해당 기능이 제공하는 결과물의 품질이나 동작 방식이 다를 수 있음을 인지해야 합니다. - 우아한 퇴보(Graceful Degradation) 설계: 특정 브라우저에서 위치 정보가 부정확하거나 음성 인식이 느릴 수 있음을 가정하고, 항상 대체 수단(Fallback)을 마련해야 합니다.
- 프라이버시 투명성: 사용자의 데이터(음성, 위치 등)가 브라우저 제조사의 서버로 전송될 가능성이 있다면, 이를 개인정보 처리방침에 명확히 명시하는 것이 좋습니다. 브라우저가 중간에서 이를 숨기고 있더라도 개발자는 그 원리를 이해하고 있어야 합니다.
- 벤더 종속성 평가: 특정 브라우저의 독자적인 API나 서비스 중심의 API에 너무 깊게 의존하고 있지는 않은지 주기적으로 검토해야 합니다.
이번 포스팅을 마치며 (회고 및 느낀 점)
오늘 번역하고 정리한 Polypane의 글은 저에게도 큰 울림을 주었습니다. 그동안 당연히 navigator 객체 안에 있으면 모두가 평등한 '웹의 자식'들이라고 생각했는데, 실제로는 각 제조사의 전략과 인프라가 얽혀 있는 '대리인'들이었다는 사실이 흥미롭습니다.
특히 Web API라는 용어를 우리가 너무 무분별하게 사용하고 있었던 것은 아닐까 하는 생각이 듭니다. 진정한 의미의 웹 표준은 인프라에 독립적이어야 하지만, 현실은 브라우저라는 창문을 통하지 않고서는 아무것도 할 수 없으니까요. 개발자로서 우리가 도구를 선택할 때 그 도구가 가진 '정치적, 인프라적 배경'까지 고민해야 한다는 점이 다소 피로할 수도 있지만, 결국 더 견고한 서비스를 만드는 밑거름이 될 것입니다.
이번 내용을 통해 여러분도 브라우저 API를 바라보는 새로운 시각을 갖게 되셨기를 바랍니다.
