🤿 딥다이브 – 브라우저에서 getUserMedia 호출 시 내부에서 벌어지는 일

🤔 브라우저에서는 어떻게 미디어 장치에 접근하는 거지?

프로젝트를 진행하며 미디어의 정보를 가져와야 하는 경우가 있었습니다.
예를 들어 디바이스의 카메라 실시간 스트리밍을 해야 한다거나, 배터리 상태를 가져와야 하는 등의 경우인데요.

자바스크립트로 getUserMedia()를 호출하면 도대체 브라우저 내부에서는 어떤 일이 일어나는 걸까?

하는 궁금증이 들었습니다.

특히 인턴 기간에 브라우저와 OS 레벨의 개념들을 많이 공부하게 되면서,
"내가 작성한 코드가 진짜 내부적으로는 어떻게 실행되는 걸까?"에 대한 관심이 생겼고,
먼저 브라우저에서 미디어에 접근하는 방식부터 간단히 정리해보고자 합니다.

---

🎯 우리가 흔히 쓰는 브라우저 API

브라우저에서 자바스크립트로 미디어 장치에 접근하려면 보통 다음과 같은 API를 사용합니다.

navigator.mediaDevices.getUserMedia({ video: true, audio: true })

이런 API들은 단순히 DOM을 조작하는 수준이 아니라, 로컬 머신의 실제 하드웨어 장치에 접근합니다.
자바스크립트 코드 한 줄이면 웹캠 화면을 띄울 수 있지만, 그 이면에는 복잡한 브라우저 내부 구조가 숨겨져 있습니다.

---

🧠 브라우저는 하나의 프로그램이 아니다?

Chromium 멀티 프로세스 아키텍처 문서에 따르면,
브라우저는 하나의 거대한 프로그램처럼 보이지만, 사실은 여러 개의 프로세스로 구성되어 있습니다.

대표적으로 두 가지 핵심 프로세스가 있습니다:

• 브라우저 프로세스
  → UI, 네트워킹, 파일 접근, 미디어 디바이스 제어 등 중앙 제어 역할을 담당

• 렌더러 프로세스
  → 각 탭의 웹 페이지를 렌더링하고, V8 엔진이 자바스크립트 실행을 담당

👉 탭마다 렌더러 프로세스가 따로 생성되며, 브라우저 프로세스와는 독립적인 프로세스입니다.
👉 이 둘은 IPC(Inter-Process Communication)이라는 메커니즘을 통해 데이터를 주고받습니다.

---

🔄 실제 미디어 접근 흐름

그렇다면, 자바스크립트 코드에서 navigator.mediaDevices.getUserMedia()를 호출했을 때
브라우저 내부에서는 구체적으로 어떤 일이 일어날지를 조금 더 단계별로 자세히 살펴보겠습니다.

---

1. 렌더러 프로세스: 자바스크립트 실행

우리가 작성한 getUserMedia() 호출은 렌더러 프로세스 안에서 자바스크립트 엔진(V8)에 의해 실행됩니다.
이때 단순한 자바스크립트 함수 호출이 아니라, 내부적으로 C++로 구현된 Web API(native 코드) 쪽으로 요청이 넘어갑니다.

즉, V8은 "아, 얘가 getUserMedia를 요청했네"를 인지하고,
브라우저 레벨에 "나 카메라 쓰고 싶어!"라는 요청을 보낼 준비를 합니다.

---

2. 렌더러 → 브라우저 프로세스에 IPC 요청

렌더러 프로세스는 직접 OS 자원(카메라, 마이크 등)을 만질 수 없습니다.
대신 IPC(Inter-Process Communication)를 통해 브라우저 프로세스에 요청을 보냅니다.

렌더러 프로세스 → (IPC 요청) → 브라우저 프로세스

브라우저 프로세스는 마치 "중간 관리자"처럼 요청을 받고, 이 요청이 합당한지(권한 허용 여부 등)를 판단합니다.

---

3. 브라우저 프로세스: 권한 확인 및 장치 접근

브라우저 프로세스는 다음과 같은 일들을 처리합니다.

• 사용자가 이미 이 도메인에 대해 카메라/마이크 접근을 허용했는지 확인
• OS 레벨 API를 통해 카메라, 마이크 장치를 실제로 연결
• 사용자가 허용하지 않았다면, 팝업을 띄워 권한 요청

만약 권한이 승인되면, 브라우저 프로세스는
실제 디바이스로부터 스트림(MediaStream) 을 생성합니다.

---

4. 브라우저 → 렌더러 프로세스로 스트림 전달

장치 연결이 완료되면, 생성한 스트림을 다시 렌더러 프로세스로 전달합니다.
렌더러 프로세스는 이 스트림을 자바스크립트 컨텍스트에 올리고, 우리가 <video> 엘리먼트에 연결하거나 WebRTC로 활용할 수 있게 해줍니다.

브라우저 프로세스 → (IPC 응답) → 렌더러 프로세스
→ JS에서 MediaStream 객체를 다룰 수 있게 됨

---

정리하면

단계	내용
렌더러 프로세스	getUserMedia() 호출 → V8 → native binding 요청
렌더러 → 브라우저	IPC로 "카메라 요청" 메시지 전송
브라우저 프로세스	권한 확인, OS 디바이스 접근, 스트림 생성
브라우저 → 렌더러	스트림(MediaStream) IPC로 응답

---

🧩 왜 이런 구조로....?

이렇게까지 복잡하게 관리해서 얻을 수 있는 장점이 무엇인지 궁금해져서 알아보았는데,
보안과 안정성을 위해 꼭 필요한 구조라고 합니다.

• 보안 격리
  웹 페이지가 직접 OS 장치에 접근하는 걸 막아줍니다.
  → 악성 스크립트가 내 카메라를 몰래 켤 수 없음

• 자원 소유권 관리
  하나의 카메라는 하나의 프로세스만 사용할 수 있어야 합니다.
  → 브라우저 프로세스가 이를 중앙에서 관리

• 안정성 확보
  탭(렌더러 프로세스)이 죽어도 브라우저 전체는 죽지 않습니다.
  → 크롬이 "이 페이지가 응답하지 않습니다"만 뜨고, 브라우저는 살아있는 이유!

---

🖼 참고한 유명한 구조도

이 그림은 Chrome의 멀티 프로세스 아키텍처를 잘 설명한 구조도입니다.
브라우저 프로세스, 렌더러 프로세스, 그리고 IPC 통신 구조까지 한 눈에 볼 수 있습니다.

저는 이 그림을 처음 보았었는데, 브라우저의 동작 원리를 이해하기 위한 유명한 그림이라고 하더라고요,,,, 아직 공부해야 할 게 너무 많은 것 같습니다....

---

결론

결국 우리가 한 줄로 쓰는 navigator.mediaDevices.getUserMedia()는 단순한 함수가 아니라는 것을 알게 되었습니다.

브라우저 프로세스, 렌더러 프로세스, V8 엔진, IPC 메커니즘, 그리고 OS 자원까지 연계되는 복합적인 아키텍처의 결과물이라는 것을 알게 되었습니다.

개인적으로 프론트 개발을 하며 코드를 가져다 쓸 줄만 알았지 브라우저 내부 흐름까지는 생각해보지 못했었는데, 이번 기회에 조금이나마 알게 되어 재미있었고, 앞으로도 이런 하위 레벨의 개념까지 많이 공부해보고 싶습니다.

이번 딥다이브를 통해 "내가 작성하는 코드가 어디까지 어떻게 연결되어 동작하는가"를 다시 생각해볼 수 있었고,
프론트엔드 개발자로서 더 깊이 공부해야겠다고 또 한 번 생각하게 되었습니다.

---

참고

• Chrome 개발자 블로그 – 브라우저 내부 구조 시리즈 Part 3
• 네이버 D2 – 브라우저가 HTML을 보여주는 과정
• Study-IHL – Chromium 구조
• Chromium 멀티 프로세스 아키텍처 문서