유튜브와 넷플릭스, 사파리와 크롬에서 다르게 동작하는 이유
호기심을 갖게 된 계기
예전에 그런글을 본 적이 있었다.
"맥 기준으로 크롬에서 노래를 듣거나, 영상을 보면 손해를 본다."
찾아볼 당시에는 chrome에서 몇가지 제한이 있었고, 그에 따라서 음질 저하나, 해상도 제한이 있다는 것이었다.
다만, 정확히 찾아보지는 않았었고, 그냥 그런가보다 하고 넘어갔다.
그러다가 얼마전 동료들과의 식사자리에서 이와 관련된 이야기를 나왔고.. 제대로 체크하지 않은 탓에 낭패를 보았다.
그래서, 문뜩 궁금해져서 제대로 알아보기로 했다.
맥 크롬에서는 넷플릭스 4k가 되지 않는다고?
놀랍게도 그렇다. 맥의 크롬에서는 넷플릭스 4k가 되지 않는다.
구독 플랜에 상관없이 정상적으로 4k가 출력되지 않는다.
DRM과 넷플릭스
넷플릭스는 저작권 보호를 위해서 DRM(Digital Rights Management) 기술을 활용하고 있다.
넷플릭스는 고화질 콘텐츠를 보호하기 위해 매우 엄격한 DRM 시스템을 운영한다.
이 시스템에서는 하드웨어 수준의 보안이 필요한데, 이를 위해서는 특별한 보안 칩이나 하드웨어 기반 콘텐츠 보호 기술이 필요하다.
여기서 중요한 차이점이 나타난다.
사파리는 애플이 직접 개발한 브라우저로서 macOS와 깊이 통합되어 있어서 시스템 레벨의 하드웨어 보안 기능에 직접 접근할 수 있다.
반면 크롬은 구글에서 개발한 크로스 플랫폼 브라우저로서 이런 깊은 시스템 통합이 어렵다.
구체적으로 살펴보면, 넷플릭스는 4K 콘텐츠를 재생하기 위해 HDCP(High-bandwidth Digital Content Protection) 2.2라는 보안 프로토콜을 요구한다.
이는 단순히 소프트웨어 수준에서 구현할 수 있는 것이 아니라, 그래픽 카드, 디스플레이, 그리고 운영체제가 모두 협력해야 하는 하드웨어 기반 보안 시스템이다.
이 때문에 크롬에서는 일반적으로 최대 1080p까지만 지원된다.
사용자가 프리미엄 플랜에 가입하고 4K 모니터를 사용하며 충분한 인터넷 속도를 가지고 있어도, 브라우저 자체의 제한으로 인해 4K 재생이 차단된다.
하지만.. 윈도우에서는 잘 되는걸요?
윈도우 환경에서는 크롬에서도 특정 조건 하에서 4K 넷플릭스 시청이 가능한 경우가 있다.
이는 마이크로소프트와 넷플릭스가 협력하여 윈도우 10 이상에서 특별한 DRM 지원을 제공하기 때문이다.
하지만 macOS에서는 이런 예외적 지원이 제공되지 않는다.
그렇다면 맥에서 넷플릭스 4K를 보려면 어떻게 해야 할까?
제일 쉽게 접근할 수 있는 방법으로는 사파리를 사용하면 된다.
이런 제한이 존재하는 이유는 결국 콘텐츠 보호 때문이다.
영화 스튜디오와 콘텐츠 제작사들은 자신들의 고화질 콘텐츠가 불법 복제되는 것을 매우 우려하며, 따라서 가장 안전한 플랫폼에서만 최고 화질을 허용하는 정책을 요구한다.
애플의 생태계는 하드웨어부터 소프트웨어까지 모든 것을 통제할 수 있어서 이런 보안 요구사항을 만족시키기 쉽지만, 오픈소스 기반의 크롬은 상대적으로 제약이 많다 (애플이 제한하는 것도 있다).
즉, 정리하면 기술적 성능의 차이가 아니라 보안 정책과 플랫폼 통합의 차이인 것.
HDCP 보안 프로토콜이란?
유튜브에 관해서 알아보기 전에, HDCP에 대해서 좀 더 깊게 살펴보자.
HDCP란 무엇이며, 왜 등장했는가?
HDCP(High-bandwidth Digital Content Protection)는 디지털 콘텐츠를 보호하기 위한 보안 프로토콜이다.
보다 쉽게 이해하기 위해서, 디지털 콘텐츠의 근본적인 문제를 먼저 상상해보자.
예를 들어, 영화 제작사가 수백억 원을 들여 만든 블록버스터 영화가 있다고 하자.
이 영화를 넷플릭스나 다른 스트리밍 서비스를 통해 제공할 때, 제작사가 가장 걱정하는 것은 무엇일까?
바로 누군가가 그 고 화질 영상을 그대로 복사해서 불법적으로 배포하는 것이다. 특히 4K나 8K 같은 초고화질 콘텐츠는 더욱 엄격한 보호가 필요하다.
과거 아날로그 시대에는 복사할 때마다 화질이 떨어졌기 때문에 자연스러운 보호 메커니즘이 있었다. (소위 디지털 풍화라고 말하기도 한다.)
하지만 디지털 시대에는 복사해도 원본과 동일한 품질을 유지할 수 있어서, 이런 자연스러운 보호막이 사라졌다.
이 문제를 해결하기 위해 인위적인 보안 시스템이 필요하게 된 것이다.
HDCP의 작동 방식
HDCP가 작동하는 방식을 단계적으로 살펴보자.
이 프로토콜은 인텔에서 개발했으며, 디지털 콘텐츠가 전송되는 모든 경로에서 암호화된 상태를 유지하도록 설계되었다.
마치 귀중한 보석을 운반할 때 출발지부터 목적지까지 모든 구간에서 보안 요원이 지켜보는 것과 같은 개념이다.
구체적인 작동 과정을 이해하기 위해 넷플릭스에서 4K 영화를 보는 상황을 예로 들어보자.
먼저 넷플릭스 서버에서 암호화된 영상 데이터가 인터넷을 통해 컴퓨터로 전달된다.
이때 브라우저나 앱에서 이 데이터를 해독한 후, 그래픽 카드로 전달한다.
그래픽 카드는 이 영상을 처리해서 모니터로 보내는데, 바로 이 그래픽 카드에서 모니터로 가는 구간이 HDCP의 핵심 보호 영역이다.
여기서 중요한 개념이 나옵니다. HDCP는 단순히 소프트웨어적인 암호화가 아니라, 하드웨어 수준에서 구현되는 보안 시스템이다.
그래픽 카드와 모니터 가 서로 "핸드셰이크"라는 과정을 거쳐 상대방이 정당한 HDCP 지원 장치인지 확인한다.
이는 마치 두 사람이 서로 신분증을 확인하고 암호를 주고받아 신뢰를 구축하는 과정과 비슷하다.
HDCP가 제대로 작동하려면 전체 연결 체인의 모든 구성요소가 이를 지원해야 한다.
그래픽 카드, 케이블, 모니터뿐만 아니라 운영체제, 브라우저, 심지어 드라이버까지 모든 것이 HDCP를 지원해야 한다.
이 중 하나라도 지원하지 않으면 전체 시스템이 보안상 취약하다고 판단되어 고화질 재생이 차단된다.
HDCP 2.2의 특징
HDCP는 기본적으로 공개키 암호화 방식을 채택하고 있다.
공개키 암호화 시스템의 핵심 아이디어를 먼저 생각해보자.
전통적인 암호화에서는 암호를 만드는 열쇠와 푸는 열쇠가 같았다(대칭키 방식).
하지만 공개키 암호화에서는 두 개의 다른 열쇠가 쌍을 이룬다.
하나는 공개키로 누구나 알 수 있고, 다른 하나는 개인키로 오직 소유자만 알 수 있다.
이는 마치 우편함에 비유할 수 있는데, 우편함의 위치는 공개되어 있어서 누구나 편지를 넣을 수 있지만, 열쇠는 주인만 가지고 있어서 편지를 꺼낼 수 있는 것과 같다.
HDCP 2.2는 이런 공개키 암호화 개념을 기반으로 하되, 디지털 콘텐츠 보호라는 특수한 목적에 맞게 설계된 시스템이다. 4k와 같은 대용량, 고화질을 지원하기 위한 보안 프로토콜이라고 보면 된다.
이 시스템의 가장 중요한 특징은 실시간으로 작동해야 한 다는 점이다.
영화를 보는 동안 매 순간마다 끊임없이 암호화와 복호화가 일어나야 하므로, 속도와 효율성이 매우 중요하다.
HDCP 2.2의 초기화 과정을 단계별로 살펴보자.
1. 인증 과정
컴퓨터를 모니터에 연결했을 때 무엇이 일어나는지 상상해보자.
가장 먼저 일어나는 것은 "인증" 과정이다.
이는 마치 두 사람이 처음 만났을 때 서로의 신분을 확인하는 과정과 비슷하다.
그래픽 카드가 모니터에게 "안녕하세요, 저는 HDCP 2.2를 지원하는 정당한 송신 장치입니다"라고 인사를 건넨다.
이때 그래픽 카드는 자신의 디지털 인증서를 제시하는데, 이 인증서는 Digital Content Protection LLC라는 기관에서 발급한 인증서이다.
모니터는 이 인증서를 검증하고, 만약 유효하다면 자신의 인증서도 그래픽 카드에 제시한다.
즉, 처음에 서로의 인증서를 확인하는 과정을 거치는 것이다.
이 인증서들은 단순한 신분증이 아니라, 각각 고유한 암호화 키를 포함하고 있다.
각 HDCP 지원 장치는 제조 과정에서 고유한 키 세트를 부여받는데, 이는 마치 지문처럼 세상에서 유일한 식별자 역할을 한다.
이런 방식으로 시스템은 정품 장치와 불법 복제품을 구별할 수 있게 된다.
2. 키 교환 과정
인증이 완료되면 다음 단계인 "키 교환" 과정이 시작된다.
이는 매우 정교한 수학적 알고리즘을 사용하는데, 디피-헬만 키 교환이라는 방법을 기반으로 한다.
이 과정을 일상적인 예로 살펴보자.
두 사람이 공개된 장소에서 비밀 암호를 만들어야 한다고 상상해보자.
주변에 도청하는 사람들이 있지만, 그들이 들어도 비밀 암호를 알아낼 수 없어야 한다.
디피-헬만 키 교환은 바로 이런 상황에서 사용할 수 있는 매우 똑똑한 방법이다.
그래픽 카드와 모니터는 각각 비밀 숫자를 하나씩 가지고 있다.
이 숫자들은 절대로 상대방에게 직접 알려주지 않는다.
대신 이 비밀 숫자들을 특별한 수학적 공식에 넣어서 변환된 결과만 서로 교환한다.
놀랍게도, 이렇게 변환된 숫자들을 주고받는 것만으로도 양쪽 모두 같은 공통 비밀 키를 계산해낼 수 있다.
중간에 도청하는 사람은 변환된 숫자들만 볼 수 있을 뿐, 실제 비밀 키를 알아낼 수는 없다.
이제 실제 콘텐츠 보호가 어떻게 이루어지는지 살펴보자.
키 교환이 완료되면, 그래픽 카드와 모니터는 공통의 암호화 키를 가지게 된다.
이 키는 매우 짧은 시간 동안만 유효하며, 주기적으로 새로운 키로 교체된다. 이는 마치 은행의 일회용 비밀번호(OTP)와 같은 개념이다.
실제 영상 데이터가 전송될 때는 AES(Advanced Encryption Standard)라는 대칭 암호화 알고리즘을 사용한다.
이는 매우 빠른 속도로 대용량 데이터를 암호화할 수 있는 방법이다.
4K 영상은 초당 엄청난 양의 데이터를 전송해야 하므로, 이런 고속 암호화가 필수적이다.
3. 링크 검증 과정
HDCP 2.2의 특별한 점 중 하나는 "링크 검증" 시스템이다.
이는 연결이 유지되는 동안 계속해서 보안 상태를 점검하는 메커니즘이다.
마치 경비원이 주기적으로 순찰을 도는 것처럼, 시스템은 몇 초마다 한 번씩 연결 상태를 확인한다.
만약 중간에 누군가가 신호를 가로채려고 시도하거나, 승인되지 않은 장치가 연결되면 즉시 감지되어 영상 전송이 중단된다.
이 링크 검증 과정에서는 "챌린지-응답" 방식을 사용한다.
그래픽 카드가 모니터에게 무작위로 생성된 질문을 보내면, 모니터는 자신만이 알 수 있는 올바른 답을 계산해서 돌려보낸다.
이 과정이 실패하면 시스템은 즉시 비상 모드로 전환되어 저화질 영상만 전송하거나 아예 전송을 중단한다.
HDCP 2.2의 핵심적인 개선사항
HDCP 2.2가 이전 버전과 구별되는 핵심적인 개선사항을 이해해보자.
가장 중요한 변화는 암호화 강도의 증가이다.
HDCP 1.4에서는 56비트 키를 사용했지만, HDCP 2.2에서는 128비트 AES 암호화를 사용한다.
이는 보안 강도를 기하급수적으로 증가시키는 효과를 낳는다.
56비트 키를 무차별 대입 공격으로 뚫는 데 걸리는 시간이 며칠이라면, 128비트 키는 우주의 나이보다 오래 걸릴 만큼 강력하다.
또한 HDCP 2.2에서는 "리피 터" 처리 방식이 개선되었다.
리피터란 신호를 중계하는 장치를 의미하는데, 예를 들어 AV 리시버나 HDMI 분배기 같은 장치들이 이에 해당한다.
이전 버전에서는 이런 중계 장치들이 보안 체인의 약한 고리가 될 수 있었지만, HDCP 2.2에서는 각 리피터도 개별적으로 인증받아야 하며, 전체 연결 체인의 보안성을 해치지 않도록 설계되었다. (즉, 하드웨어 인증이 필요하기에, 이 지점에서 넷플릭스볼 때 HDCP 2.2 지원 케이블이 요구되기도 한다.)
HDCP 2.2의 실제 구현과 하드웨어적 고려사항
실제 구현 과정에서 고려해야 할 하드웨어적 요소들도 살펴보자.
HDCP 2.2는 단순히 소프트웨어로만 구현할 수 없다.
그래픽 카드의 칩셋 수준에서 지원되어야 하며, 이는 암호화 연산을 하드웨어로 가속화하기 위함이다.
소프트웨어만으로 이런 복잡한 암호화를 실시간으로 처리하려면 CPU에 과도한 부담이 가해져서 시스템 성능이 크게 저하될 수 있다.
모니터 측에서도 마찬가지로 전용 칩이 필요하다.
이 칩은 받은 암호화된 신호를 실시간으로 복호화해서 화면에 표시해야 한다.
4K 60fps 영상의 경우 초당 약 12기가비트의 데이터를 처리해야 하므로, 이는 매우 고성능의 하드웨어를 요구한다.
케이블의 역할도 생각해볼 필요가 있다. HDCP 2.2에서는 케이블 자체가 보안 시스템의 일부가 된다. 고품질 HDMI 케이블에는 인증 칩이 내장되어 있어서, 시스템이 정품 케이블인지 확인할 수 있다.
이는 누군가가 특수 제작된 케이블을 사용해서 신호를 가로채는 것을 방지하기 위함이다.
더 나아가서, HDCP 2.2에서는 "지리적 제한" 기능도 포함되어 있다.
이는 콘텐츠가 특정 지역에서만 재생되도록 제한하는 기능으로, 각 장치는 자신의 지역 코드를 가지고 있어서 해당 지역에서만 고화질 콘텐츠를 재생할 수 있다.
HDCP 2.2의 개선된 오류 처리 메커니즘과 현실적인 문제 이해
시스템의 오류 처리 메커니즘도 매우 정교하게 구현되어 있다.
만약 암호화 과정에서 오류가 발생하면, 시스템은 즉시 "그레이스풀 디그레이데이션" 모드로 전환된다.
이는 완전히 재생을 중단하는 대신, 더 낮은 화질로 재생을 계속하는 방식이다.
예를 들어, 4K 재생에 문제가 생기면 자동으로 1080p로 전환되고, 그것도 안 되면 720p로 내려간다.
마지막으로 HDCP 2.2의 한계와 현실적인 문제점들도 이해해야 한다.
이론적으로는 완벽한 보안 시스템이지만, 실제로는 호환성 문제가 자주 발생한다.
특히 서로 다른 제조사의 장치들을 연결할 때, 미묘한 구현 차이로 인해 핸드셰이크 과정이 실패하는 경우가 있다.
이런 문제들 때문에 때로는 정당한 사용자 도 구매한 콘텐츠를 제대로 볼 수 없는 상황이 발생하기도 한다.
유튜브도 크롬에서 4k가 안되는가?
사실 이 부분이 내가 햇갈렸던 부분이다. 넷플릭스는 HDCP 2.2를 요구하기 때문에, 크롬에서 4K가 안된다는 것은 이해했다.
그래서, 난 당연히 유튜브도 그러겠거니 해서 평소에도 크롬사용하다가 영상 볼때만 사파리를 쓰고는 했다.
그런데, 알고보니 사실 그런게 아니더라. 유튜브는 맥 크롬에서 4K가 잘 된다.
왜 그런지 살펴보자.
유튜브와 넷플릭스의 다른 철학
넷플릭스가 "보안과 콘텐츠 보호"를 최우선으로 한다면, 유튜브는 "접근성과 호환성"을 최우선으로 한다.
이는 두 플랫폼의 비즈니스 모델 차이에서 비롯된다.
넷플릭스는 구독료를 받고 프리미엄 콘텐츠를 제공하는 반면, 유튜브는 광고 수익을 기반으로 하므로 가능한 한 많은 사용자가 쉽게 접근할 수 있어야 한다.
이런 철학적 차이는 기술적 구현에서도 극명하게 드러난다.
유튜브는 HDCP 같은 하드웨어 기반 보안 시스템을 거의 사용하지 않는다.
대신 웹 표준 기술을 최대한 활용해서 어떤 브 라우저에서든 비슷한 경험을 제공하려고 노력한다.
유튜브의 영상 스트리밍 방식
유튜브의 영상 스트리밍 방식을 단계별로 살펴보자.
유튜브는 "적응형 스트리밍"이라는 기술을 사용한다.
이는 마치 물이 자연스럽게 가장 쉬운 길을 찾아 흐르는 것처럼, 시스템이 현재 상황에 가장 적합한 화질을 자동으로 선택하는 방식이다.
구체적으로 설명하면, 유튜브에 업로드된 하나의 영상은 실제로는 여러 가지 다른 화질과 압축 방식으로 변환되어 저장된다.
예를 들어 같은 영상이 360p, 720p, 1080p, 1440p, 4K 등 다양한 해상도로 존재하고, 각각 다시 H.264, VP9, AV1 등 여러 코덱으로 인코딩된다.
사용자가 영상을 재생할 때 시스템은 네트워크 속도, 기기 성능, 브라우저 지원 능력 등을 종합적으로 판단해서 가장 적절한 버전을 선택해서 제공한다.
"브라우저 별 코덱 지원 차이"에 주목하자.
코덱이란 영상을 압축하고 해제하는 방식을 의미하는데, 이는 마치 서로 다른 언어와 같다.
모든 브라우저가 모든 언어를 이해할 수 있는 것은 아니므로, 유튜브는 각 브라우저가 이해할 수 있는 언어로 영상을 제공해야 한다.
사파리와 크롬의 다른 코덱
맥의 사파리는 하드웨어 가속을 통한 H.264 디코딩에 매우 뛰어나다.
이는 애플이 자체 실리콘에 H.264 전용 디코더를 내장했기 때문이다.
따라서 사파리에서는 H.264로 인코딩된 고화질 영상을 매우 효율적으로 재생할 수 있다.
배터리 소모도 적고, 발열도 낮으며, CPU 사용량도 최소화된다.
반면 크롬의 상황은 조금 더 복잡하다.
크롬은 구글에서 개발한 브라우저이므로, 구글이 개발한 VP9 코덱을 적극적으로 지원한다.
VP9는 H.264보다 압축 효율이 좋아서 같은 화질을 더 적은 대역폭으로 전송할 수 있다.
하지만 VP9 디코딩은 주로 소프트웨어로 처리되기 때문에 CPU 사용량이 높아지고 배터리 소모가 증가할 수 있다.
최근에는 AV1이라는 차세대 코덱도 등장했다.
이는 VP9보다도 더 효율적인 압축을 제공하지만, 아직 하드웨어 지원이 제한적이어서 소프트웨어 디코딩에 의존해야 하는 경우가 많다.
따라서 고화질 AV1 영상을 재생할 때는 상당한 시스템 자원이 필요한 문제가 있다.
가끔 "사파리에서 유튜브가 더 부드럽게 재생된다"고 느끼는 경우가 있다.
이는 단순히 화질 자체의 문제가 아니라, 디코딩 효율성의 차이이다.
사파리에서는 하드웨어 가속 덕분에 높은 프레임레이트를 안정적으로 유지할 수 있지만, 크롬에서는 소프트웨어 디코딩으로 인해 때때로 프레임 드롭이 발생할 수 있다.
하지만 여기서 한 가지 고려해야 할 점이 있다. 크롬에서 VP9나 AV1을 사용할 때는 실제로 더 좋은 화질을 경험할 수도 있다.
같은 대역폭에서 더 많은 정보를 전달할 수 있기 때문이다. 특히 네트워크가 제한적인 환경에서는 크롬 이 더 나은 경험을 제공할 수 있다.
유튜브의 화질 선택 알고리즘
유튜브의 화질 선택 알고리즘도 살펴보자.
유튜브는 단순히 최고 화질을 제공하는 것이 목표가 아니다.
대신 "지각적 화질"을 최적화하려고 한다.
이는 사용자가 실제로 느끼는 화질을 의미하는데, 이론적 화질과는 다를 수 있다.
예를 들어, 네트워크가 불안정한 상황에서 4K 영상을 재생하려고 하면 버퍼링이 자주 발생해서 실제로는 나쁜 시청 경험을 제공할 수 있다.
이런 경우 유튜브는 차라리 1440p나 1080p로 화질을 낮춰서 끊김 없는 재생을 보장하는 것을 선택한다.
이는 "완벽한 화질의 몇 초"보다는 "적당한 화질의 연속적인 재생"이 더 좋은 경험을 제공한다는 판단에 기반한다. (한때, 이를 통해서 4G 사용시 마음대로 360p로 바꾸는 경우도 있었다.)
브라우저별 하드웨어 가속 차이
브라우저별 하드웨어 가속 지원의 차이도 살펴보는 김에 살펴보자.
하드웨어 가속이란 CPU 대신 그래픽 카드나 전용 칩을 사용해서 영상을 처리하는 기술이다.
이는 마치 손으로 계산하는 대신 계산기를 사용하는 것 과 같은 효과를 준다.
사파리는 macOS와 깊이 통합되어 있어서 애플 실리콘의 모든 하드웨어 가속 기능을 활용할 수 있다.
M1, M2, M3 칩에는 ProRes, H.264, HEVC 등 다양한 코덱을 위한 전용 엔진이 내장되어 있고, 사파리는 이런 엔진들을 직접 활용할 수 있다.
크롬도 하드웨어 가속을 지원하지만, 범용적인 접근 방식을 사용해야 한다.
다양한 운영체제와 하드웨어에서 동작해야 하므로, 특정 플랫폼의 고유한 기능을 완전히 활용하기는 어렵다.
이는 마치 여러 나라에서 사용되는 제품이 각 나라의 특수한 환경을 완전히 활용하기 어려운 것과 같다.
유튜브에서 코덱 확인하기
유튜브의 품질 설정 메뉴를 자세히 살펴보면 더 흥미로운 사실들을 발견할 수 있다.
설정에서 "고급"을 선택하면 단순히 해상도뿐만 아니라 코덱 정보도 확인할 수 있다.
예를 들어 "1080p60 (VP9)"이라고 표시되면 1080p 해상도에 60fps이며 VP9 코덱을 사용한다는 의미이다.
같은 해상도라도 사용하는 코덱에 따라 실제 데이터량과 화질이 달라진다.
H.264로 인코딩된 1080p와 VP9로 인코딩된 1080p를 비교하면, 일반적으로 VP9가 더 적은 비트레이트로 비슷하거나 더 좋은 화질을 제공한다.
하지만 디코딩에 필요한 연산량은 VP9가 더 많다.
정리
넷플릭스는 크롬에서 4k 지원이 안되고, 유튜브는 된다.
이 둘의 차이는, 유튜브와 넷플릭스의 경영 철학과 기술적 접근 방식의 차이에서 비롯된다.
처음에는 아무 생각 없이 그냥 그런갑다. 하고 넘어갔지만, 이렇게 자세히 살펴보니 정말 흥미롭다.
관련해서 찾아보게 되면 정말 다양한 요소가 존재하기에, 이 글에서 다루지 못한 부분도 많다.
현재 살펴봐야할 지식이 많은 관계로 간단히 호기심을 충족하는 정도로만 살펴보았다.
그럼에도 불구하고, 이 글을 통해서 간단하게나마 HDCP 2.2의 기본 개념과 유튜브와 넷플릭스의 차이를 이해하는 데 도움이 되었기를 바란다.