Chrome 151이 바꾸는 카메라·마이크 권한 요청 방식: `<usermedia>` 요소 해설 (developer.chrome.com)
목차(4)
한줄 요약
Chrome 151, <usermedia> 요소로 카메라·마이크 권한 요청을 선언형으로 바꾼다.
Chrome 151부터 사용 가능한 <usermedia> HTML 요소는 웹에서 카메라와 마이크를 다루는 방식을 근본적으로 바꾼다. 기존의 getUserMedia() JavaScript API 호출 방식에서 벗어나, 브라우저가 직접 권한 흐름과 스트림 전달을 관리하는 선언형 컨트롤로의 전환이다.
무엇이 달라지나?
지금까지 웹에서 카메라나 마이크에 접근하려면 getUserMedia()를 직접 호출하고, 콜백을 처리하고, 에러 상태를 별도로 관리해야 했다. 코드 양도 문제지만 더 큰 골칫거리는 따로 있었다. 사용자가 실수로 권한을 거부하면, 이를 되돌리려면 브라우저 설정 깊숙이 들어가야 했다. 이 구조적 문제를 업계에서는 오랫동안 "permission hole"이라 불러왔다.
<usermedia> 요소는 이 흐름을 통째로 바꾼다. 브라우저가 직접 신뢰 신호를 갖는 방식으로 설계됐다. 권한 프롬프트가 스크립트 실행 시점이 아니라, 사용자가 브라우저가 제어하는 버튼을 직접 클릭한 시점에만 뜬다. 덕분에 자동화 스크립트로 인해 조용히 차단되는 문제도 사라진다.
구현 자체도 대폭 단순해진다. HTML에 <usermedia> 태그를 넣고, setConstraints()로 해상도나 에코 캔슬링 같은 하드웨어 조건을 사전에 지정한 뒤, stream 이벤트 리스너 하나로 MediaStream 객체를 받아 사용할 수 있다. error와 cancel 이벤트도 별도로 처리 가능하다.
권한이 이미 거부된 사용자를 위한 복구 흐름도 내장돼 있다. 요소를 탭하면 브라우저 설정 진입 없이 페이지 내에서 즉시 재승인할 수 있는 전용 복구 플로우가 실행된다.
실무에서 어떤 의미인가?
Origin Trial 단계에서 수집된 실제 데이터가 이 요소의 설득력을 높인다.
기존 방식에서 권한을 한 번 거부한 사용자가 다시 권한을 허용하는 비율은 약 10% 수준이었다. <usermedia> 요소를 적용한 환경에서는 이 비율이 65% 이상으로 올라갔다. Zoom은 카메라·마이크 캡처 에러가 46.9% 감소했다고 보고했고, Google Meet는 "마이크가 작동하지 않는다"는 피드백이 17% 줄었으며 권한 재승인 성공률은 131% 증가했다.
웹 기반 화상회의, 녹음 서비스, 라이브 스트리밍 기능을 구현하는 서비스라면 이 수치는 단순한 기술 스펙 이상의 의미를 갖는다. 권한 거부로 이탈하는 사용자를 구제하는 것은 곧 전환율과 직결되는 문제다.
스타일링 측면에서도 주목할 점이 있다. 브라우저는 이 요소에 대해 텍스트·배경 대비 비율, 크기 제한, 변형 효과 범위 등 엄격한 스타일 규칙을 강제한다. 기만적인 UI 패턴으로 사용자를 속지 못하도록 설계 단계에서 막아둔 것이다. :granted, :hover, :active 같은 CSS 의사 클래스는 지원하되, 투명도 조작이나 음수 마진 같은 시각적 트릭은 허용하지 않는다.
이 요소는 Chrome 144에서 먼저 출시된 <geolocation> 요소와 같은 "Capability Elements" 시리즈의 일환이다. 하드웨어 권한을 개별 기능별로 전용 요소로 분리하는 방향으로 브라우저 설계가 이동하고 있다는 신호로 읽힌다.
도입 전 체크포인트
기존 getUserMedia() 기반 코드를 교체하기 전에 확인해야 할 지점이 있다.
브라우저 지원 범위를 먼저 확인하라. Chrome 151 미만 또는 다른 브라우저 환경에서는 <usermedia> 요소가 HTMLUnknownElement로 처리되고 자식 요소가 그대로 렌더링된다. HTMLUserMediaElement in window 조건으로 지원 여부를 감지하고, 기존 방식을 폴백으로 유지하는 점진적 개선 전략이 필요하다.
스타일 구조를 미리 검토하라. 브라우저가 강제하는 스타일 제약이 기존 디자인 시스템과 충돌할 수 있다. 특히 투명도, 크기 제약, 변형 효과 제한이 UI 컴포넌트 라이브러리의 기본 스타일과 맞지 않는 경우가 생길 수 있다.
setConstraints() 호출 시점을 주의하라. 하드웨어 조건은 반드시 사용자 인터랙션 이전에 지정해야 한다. 동적으로 디바이스를 선택하는 플로우가 있다면, 조건 설정 로직을 요소 초기화 시점에 맞게 재구성해야 한다.
개발 외주나 웹 개발 업체를 통해 화상통화·미디어 기능을 구현 중이라면, 이 요소의 등장은 기술 스펙 협의 단계에서 짚어볼 만한 변화점이다.
자주 묻는 질문
Q.`<usermedia>` 요소는 기존 `getUserMedia()` API를 완전히 대체하나?
완전한 대체보다는 권장 경로의 전환으로 보는 것이 정확하다. `getUserMedia()`는 여전히 동작하지만, 브라우저는 사용자 인터랙션 기반의 선언형 방식을 더 신뢰하는 방향으로 설계됐다. 특히 권한이 거부된 상태에서의 복구 플로우는 `<usermedia>` 요소를 통해서만 제공된다. 기존 코드베이스라면 점진적 전환 전략이 현실적이다.
Q.Chrome 외 다른 브라우저에서는 어떻게 처리되나?
`<usermedia>`를 지원하지 않는 브라우저는 이 요소를 알 수 없는 HTML 요소로 취급하고, 내부에 작성된 자식 요소를 그대로 렌더링한다. 따라서 폴백 버튼이나 기존 `getUserMedia()` 기반 로직을 자식 요소 안에 함께 작성해두면 크로스 브라우저 대응이 가능하다. `HTMLUserMediaElement in window`로 지원 여부를 분기하는 패턴이 공식 권장 방식이다.
Q.스타일 제약이 심하면 기존 디자인 시스템에 적용하기 어렵지 않나?
실제로 제약이 존재한다. 텍스트와 배경의 대비 비율, 최소·최대 크기, 변형 효과의 범위가 브라우저에 의해 강제된다. 이는 사용자를 기만하는 UI 설계를 원천 차단하기 위한 의도적 설계다. 다만 `:granted`, `:hover`, `:active` 같은 상태 기반 CSS는 지원하므로, 제약 안에서 브랜드에 맞는 스타일링은 충분히 가능하다. 📌 원문: [Chrome for Developers](https://developer.chrome.com/blog/usermedia-html-element) 🔗 새로운 기술 도입이나 기술 검토가 필요하다면 → [삼태연구소에 문의하기](/contact)
관련 아티클
관련 사례
이 글의 키워드와 맞닿은 실제 개발 사례를 함께 보세요.