2014년 2월 18일 화요일

[튜토리얼/한글화] HTML의 새로운 태그 Template: 클라이언트측 템플릿의 표준(HTML's New Template Tag: standardizing client-side templating)

HTML5Rocks의 웹 컴포넌트 관련 튜토리얼 중 +Eric Bidelman의 'HTML의 새로운 태그 Template: 클라이언트측 템플릿의 표준(HTML's New Template Tag: standardizing client-side templating)' 튜토리얼의 한국어 번역이 업데이트되었습니다.

Template는 웹 컴포넌트를 지탱하는 4가지 규격 중의 하나입니다. Template 규격 이전에도 여러가지 형태의 템플릿들이 자바스크립트 라이브러리나 프레임워크를 통해 제공되어 왔습니다만 이번에 템플릿에 대한 표준 규격이 작성됨에 따라 이러한 템플릿 기능을 네이티브 브라우저를 통해 활용할 수 있게 되었습니다.

이 튜토리얼은 템플릿을 어떻게 정의하고 컨텐츠와 연동할 수 있는지 설명합니다. 이로써 HTML5Rocks에 올라온 웹컴포넌트 관련 튜토리얼은 전부 번역되었으므로 아직 읽어보지 않으신 분들은 참조 링크에서 웹 컴포넌트에 관련된 내용을 일독해보시기를 권해드립니다.

"캡슐화된 컴포넌트를 정의하여 문서 내에서 재사용하고 요구사항에 따라 컴포넌트의 내부를 깨뜨리지 않으면서 확장할 수 있습니다. 계속해서 말씀드리지만 웹 컴포넌트는 프론트엔드에 있어 2014년에 빠질 수 없는 가장 중요한 개념 중의 하나가 될 것입니다."


TL;DR;


이 튜토리얼은 Template의 개념과 Template를 선언하고 컨텐츠를 적용하여 DOM을 런타임에 손쉽게 생성할 수 있도록 합니다.

템플릿은 뷰를 위한 기반 구조로 사용되는 미리 작성된 형식의 문서나 파일입니다. 즉, 형식(Format)를 한번 정의한 뒤 재사용하도록 하여 (마크업의 작성이나 런타임 마크업 생성 모듈과 같은) 추가적인 개발 작업으로부터 개발을 간편하게 만들어줍니다.

템플릿의 개념은 웹 개발에 있어 새로운 것은 아닙니다. 서버 측에서의 템플릿 활용뿐만 아니라 클라이언트에서도 우리가 주로 사용해오던 여러가지 방법들이 이미 존재합니다. "오프스크린" 상에서 DOM을 생성하고 이를 hidden 속성이나 display:none을 사용하여 뷰로부터 이를 감추는 오프스크린 DOM은 브라우저에서 제공하는 다양한 기능을 활용하여 템플릿을 구현할 수 있지만 문서 내의 다른 DOM에 영향을 주는 등의 부작용을 가지고 있습니다. 반대로 <script>를 오버로딩하고 <script>의 컨텐츠를 문자열로 처리하는 스크립트 오버로딩은 렌더링 이슈 및 비활성화를 해결하고 있으나 .innerHTML의 사용을 필요로 하고 이로 인한 보안 취약성이 존재합니다.

WhatWG HTML Templates 표준규격은 템플릿을 위한 표준적인 DOM 기반의 접근 방법을 기술하는 새로운 엘리먼트인 <template>를 정의하였으며 템플릿 컨텐츠는 사용시까지 비활성화되어 렌더링되지 않고 템플릿 안의 스크립트나 DOM이 다른 곳에 영향을 미치는 부작용이 없습니다. 선언/재활용 역시 마찬가지이며 또한 적용 위치 역시 자유롭기 때문에 많은 부분에서 활용이 가능합니다.

보다 자세한 내용은 튜토리얼을 참고하시기 바랍니다.



번역 링크


참고 글

2014년 2월 5일 수요일

[튜토리얼/한글화] Shadow DOM 101

HTML5Rocks의 Shadow DOM 관련 튜토리얼 중 +Dominic Cooney의 'Shadow DOM 101(섀도 DOM 101)' 튜토리얼의 한국어 번역이 업데이트되었습니다.

웹 컴포넌트 관련 튜토리얼마다 말씀드리는 내용입니다만 Shadow DOM 역시 이전의 Custom Element나 HTML Imports처럼 웹 컴포넌트를 지탱하는 4가지 규격 중의 하나입니다. Shadow DOM은 DOM에 대한 캡슐화(Encapsulation)와 같은 매우 강력한 기능을 제공합니다. HTML5Rocks에는 다음과 같이 Shadow DOM에 대한 3개의 튜토리얼이 업데이트되어 있습니다.
  1. Shadow DOM 101 - Shadow DOM의 기초적인 개념 및 구조
  2. Shadow DOM 201: CSS and StylingShadow DOM의 CSS 규칙 적용 및 스타일화 방법
  3. Shadow DOM 301: Advanced Concepts and DOM API - 다중 ShadowRoot 사용 및 자바스크립트를 통한 삽입 등의 발전된 DOM 동작

이 튜토리얼은 Shadow DOM에 대한 기초 개념과 Shadow DOM을 이용하여 내용(Contents)와 표현(Presentation)이 어떻게 분리될 수 있는지에 대해 설명합니다.

"Shadow DOM의 가장 큰 장점 중의 하나는 캡슐화이기도 하지만 기본적으로 감춰진 DOM을 제어하기 위한 Shadow Root와 이를 투영하기 위한 Shadow Host를 이용하여 컨텐츠와 표현을 분리합니다. Shadow DOM은 이를 이용하여 캡슐화된 DOM 트리를 HTML 문서에 활용할 수 있는 가장 기초적인 개념과 원칙을 제공합니다. Shadow DOM은 웹 프론트엔드에 있어 2014년에 빠질 수 없는 가장 중요한 개념 중의 하나가 될 것입니다."


TL;DR;


이 튜토리얼은 Shadow DOM의 개념과 Shadow DOM을 이용하여 컨텐츠와 표현을 계층적으로 분리하는 방법들을 다루고 있습니다.

웹 페이지를 개발할 때 몇 가지 UI 요소들은 지속적으로 재활용됨에도 불구하고 개발자가 올바른 DOM Tree를 구축하기 위해 마크업을 재작성하고 UI 요소를 둘러싸는 다른 요소들과의 구조적인 이슈들을 해결하기 위해 추가적인 작업을 필요로 합니다. 이러한 과정에서 발생하는 복잡한 DOM 트리들(좀 더 정확하게는 Tag Soup)은 재사용성과 개발 효율성에 크게 영향을 미치는 부분이기도 합니다.

Shadow DOM에서 제공하는 섀도 호스트(Shadow)는 문서 상에서 섀도 루트(Shadow Root)가 관리하는 Shadow DOM Tree 투영의 가장 기본적인 방법을 제공합니다. 표현(Presentation)과 내용(Contents)의 분리는 위와 같은 문제(Tag Soup)를 해결해줄 뿐만이 아니라 보다 근본적인 기능-즉, 개발된 UI 요소의 재사용을 위한 가장 기본적이고도 중요한 기능-을 제공합니다.

보다 자세한 내용은 튜토리얼을 참고하시기 바랍니다.



번역 링크



참고 글

2014년 2월 4일 화요일

[튜토리얼/한글화] 모바일 브라우저에서 할당량과 함께 작업하기 : 브라우저 스토리지에 관한 연구 보고서(Working with quota on mobile browsers: A research report on browser storage)

HTML5Rocks에 +Eiji Kitamura의 "모바일 브라우저에서 할당량과 함께 작업하기 : 브라우저 스토리지에 관한 연구 보고서(Working with quota on mobile browsers: A research report on browser storage)"가 업데이트되었습니다.

"HTML5이 도입되면서 서버에서 클라이언트로 이동한 것은 단지 로직만이 아닙니다. 데이터 저장소 역시 클라이언트로 범위를 확대하였습니다. 이러한 클라이언트 측의 데이터는 브라우저가 관리하는 공간 속에 저장됩니다. 또한 다양한 액세스 방법은 적합한 방식을 개발 중에 선택할 수 있도록 하였습니다. 그러나, 이러한 저장소는 웹 앱 입장에서 보면 브라우저에 의해 컨트롤되고 있으며 이에 의한 다양한 제한점이 존재하기 때문에 이에 대한 숙지가 필요합니다."


TL;DR;


HTML5 이전에 사용자의 데이터를 저장하기 위해 쿠키를 사용하는 것 이외에는 대안이 없었지만 HTML5의 가장 큰 혁신 중 하나는 브라우저 상의 영구적인 저장소를 제공한다는 것입니다.

HTML5의 시대가 오면서 웹 어플리케이션이 점점 더 풍부해짐에 따라 더 많은 개발자가 브라우저 측의 스토리지를 사용하고 있습니다. 그러나 다양한 한계를 비교하는 중요한 연구가 이루어지고 있지 않으므로  개발자가 이를 극복하기 위한 시간이 소요됩니다. 이 튜토리얼은 다양한 브라우저에 대한 스토리지 상의 제한점들과 이를 측정하는 방법에 대해 다루고 있습니다.

이 튜토리얼에서 다루는 대상 스토리지는 다음과 같습니다.

  • WebStorage
    • 키-값(Key-Value) 기반의 API를 제공하며 일반적으로 가장 많이 사용됩니다. (익히 아시다시피 WebStorage는 반영구적으로 저장 가능한 LocalStorage와 세션이 연결된 동안만 사용할 수 있는 SessionStorage로 나뉘어집니다.)
  • WebSQL Database
    • 브라우저를 위한 관계형 데이터베이스(RDB)를 제공합니다. 실제 WebSQL은 W3C에서 표준화 진행을 중단한 상태이지만 현재까지는 브라우저에서는 사용이 가능한 상태입니다.
  • Indexed Database
    • 자바스크립트 객체가 저장가능하고 이를 기반으로 한 인덱스 처리가 가능한 새로운 규격입니다. 점진적으로 이에 대한 지원 및 사용이 확장될 것입니다.
  • FileSystem API
    • 웹을 위한 파일 시스템입니다. 개발자는 샌드박스 형태로 사용자의 파일 시스템을 사용할 수 있으며 이를 URL 형태로 직접 참조할 수도 있습니다. 현재 크롬과 오페라만 이를 구현하고 있지만 표준화는 순조롭게 진행 중입니다.
  • Application Cache
    • 단일 페이지 어플리케이션을 위한 강략한 캐쉬 메커니즘을 제공합니다. 그러나 많은 제한점으로 인해 ServiceWorker로 불리는 표준 규격이 이를 대치할 예정입니다. 현재(2014, Jan.)까지 이를 제외하면 진정한 오프라인 웹앱 솔루션은 없다고 해도 과언이 아닙니다.


보다 자세한 내용은 튜토리얼을 참고하시기 바랍니다.



번역 링크

2014년 1월 23일 목요일

[튜토리얼/한글화] 사용자 타이밍 API: 웹앱의 이해(User Timing API Understanding your Web App)

HTML5Rocks에 +Alex Danilo의 튜토리얼 '사용자 타이밍 API: 웹앱의 이해(User Timing API Understanding your Web App)'의 한글 버전이 업데이트되었습니다.

이전에도 시간을 이용하여 성능을 측정하는 방법은 있었지만 실제로 스크립트의 설정과 시간 관련 API 들의 제한으로 인해 자세하고 정확하게 측정하기는 어려웠습니다. 이를 해결하기 위해 W3C에서는 High Resolution Time Stamp라는 타입을 추가하였고 이제 모던 브라우저에서 이를 사용할 수 있는 User Timing API이 구현되어 있습니다.

이 튜토리얼은 사용자가 페이지의 로딩, DOM Ready, Navigation 시간 등이나 사용자가 지정한 지점 간의 시간을 측정하기 위한 Timing API를 다루고 있습니다. 이번 번역은 한순보님께서 수고해주셨습니다. :)

"Performance API는 개발자가 직접 측정하기 어려운 페이지 로딩 시간 등을 조회할 수 있도록 해주며 개발자가 직접 지정한 지점을 표시(.mark() 함수)하고 이를 측정(.measure() 함수)할 수 있도록 해주는 등의 스크립트 수준에서의 성능 측정 방법을 제공합니다. Performance API를 이용하면 로딩, 렌더링부터 함수 혹은 특정 실행 사이클을 가지는 모듈의 측정 등 다양한 형태로도 활용할 수 있는 가능성이 있습니다. 프로젝트에서 개발자도구만으로 측정할 수 없는 부분이 있다면 Performance API를 개발 작업흐름 내에 포함하는 것도 좋은 방법이 될 것입니다."


TL;DR;


최적화에 있어서 가장 첫번째 단계는 병목 지점을 찾아내기 위한 측정(Measure)입니다. 반대로 이야기하자면 측정이 없다면 단지 경험과 시간을 사용하여 수정하고 테스트하는 반복적인 과정을 피할 수 없습니다. 물론 개발자 도구에서 렌더링이나 리소스에 대한 로딩 타임들을 측정할 수 있지만 이는 우리의 프로젝트에서 일부에 불과합니다.

User Timing API는 이렇게 도구에서 지원하지 않는 코드 상의 측정을 위한 기능들을 다음과 같이 제공합니다.

(Perfomance API는 아래에서 언급하는 내용 이외에도 Navigation에 대한 정보 그리고 Chrome의 경우 여기에 메모리 사용량도 지원하지만 이 튜토리얼에서는 다루지 않습니다.)


고해상도 시간(High Resolution Time)
  • W3C의 규격에서 High Resolution Time이란 밀리초(msec) 이하의 시간 단위를 말합니다. 이는 보다 정밀한 시간 측정이 가능하므로 아주 짧게 실행되는 코드에 대한 반복적인 실행 없이 시간 측정이 가능한 것을 뜻합니다.

사용자 타이밍 인터페이스(User Timing Interface)
  • 기본적으로 사용자 타이밍 인터페이스는 개발자가 직접 측정하기 어려운 URL 요청, 응답, 페이지 로딩 시간, DOM 로딩, 완료 등에 대한 지점(Mark)를 기본으로 포함합니다.
[그림] performance.timing이 가진 기본 Mark들
  • User Timing API는 사용자 타이밍 인터페이스의 기본 지점과 사용자가 직접 지점을 설정 및 해제할 수 있으며 이를 기반으로 하는 측정 시간과 데이터 액세스 기능을 제공합니다.
  • 설정 및 해제
    • .mark()/.clearMarks() : 사용자 지점 설정/해제
    • .measure()/.clearMeasures() : Mark 간의 시간 측정 설정/해제
  • 데이터 액세스
    • .getEntriesByType() : 주어진 타입('mark' 혹은 'measure')에 대한 엔트리 반환
    • .getEntriesByName() : 주어진 이름에 따른 엔트리 반환


이 튜토리얼은 이러한 API의 사용 방법부터 Ajax 호출에 대한 성능 측정 방법에 대해 다루고 있습니다. 보다 자세한 내용은 튜토리얼을 참고하시기 바랍니다.



번역 링크

[업데이트] Yo Polymer – 웹 컴포넌트 도구화로의 빠른 여행 (Yo Polymer – A Whirlwind Tour Of Web Component Tooling)

HTML5Rocks에 +Addy Osmani의 Yeoman, Polymer의 도구화와 관련된 포스트가 업데이트되었습니다. Whirlwind tour는 원래 '정신없이 빠르게 진행되는 여행'이라고 하네요. :)

이 포스트는 웹 컴포넌트의 Polyfill 라이브러인 폴리머(Polymer)와 이를 구축하기 위한 도구인 Yeoman의 개괄적인 사용 방법, 그리고 +Addy OsmaniChrome Dev Summit의 발표에서 보여준 데모인 Jukebox 앱에 대한 간략한 소개와 동영상을 담고 있습니다. 자세한 내용은 전문을 참조하세요. :)




전문


Web Components는 웹을 구축하는데 있어 여러분이 알고 있다고 생각하는 모든 것을 바꾸고 있습니다. 처음으로 웹이 우리 자신의 HTML 태그들을 생성하는 것만이 아니라 로직과 CSS를 캡슐화할 수 있는 저수준 API를 가질 예정이었습니다. 더 이상의 전역 스타일시트 수프나 보일러플레이트 코드는 없습니다! 이는 모든 것이 엘리먼트인 멋지고 새로운 세계입니다.

DotJS에서의 발표에서 저는 웹 컴포넌트가 무엇을 제공해야하는지와 최근의 도구들을 이용하여 이를 어떻게 구축할 수 있는지에 대해 자세하게 설명했습니다. 저는 여러분에게 오늘날 모던 브라우저에서 웹 컴포넌트를 사용하여 앱을 개발하기 위해 Yeoman과 Polymer를 이용하여 웹앱 생성을 간소화하는 도구들의 작업흐름, Polyfill 그리고 설탕 한 숟가락(sugar)을 보여드릴 것입니다.



커스텀 엘리먼트 생성하기와 다른 이들이 만든 엘리먼트 설치하기

이 발표에서 우리는 다음과 같은 것들을 배울 수 있을 것입니다.

  • 웹 컴포넌트를 구성하는 Custom ElementsTemplatesShadow DOM 그리고 HTML imports 4가지의 각 규격들에 대해
  • Bower를 이용하여 어떻게 여러분만의 커스텀 엘리먼트를 정의하고 다른 이들이 만든 엘리먼트를 설치하는지
  • 적게 자바스크립트를 작성하고 페이지 구축에 더 많은 시간을 사용하기
  • 폴리머와 generator-polymer를 사용하여 어플리케이션을 스캐폴딩하기 위한 모던 프론트엔드 도구(Yeoman) 사용하기
  • 웹 컴포넌트의 생성을 폴리머가 얼마나 대단하게 바꾸었는가

예를 들어 폴리머의 웹 컴포넌트 폴리필들(Polymer's Web Component polyfills)과 그 자신의 라이브러리를 설치하기 위해 여러분은 다음과 같이 한줄을 실행할 수 있습니다.

bower install --save Polymer/platform Polymer/polymer

이는 bower_components 폴더와 위의 패키지들을 추가합니다. --save는 이들을 앱의 bower.json 파일에 추가합니다.

그 다음, 폴리머의 아코디언(accordion) 엘리먼트를 설치하기 위해 다음과 같이 실행합니다.

bower install --save Polymer/polymer-ui-accordion

그리고나서 이를 어플리케이션 내에 불러(import)옵니다.

<link rel="import" href="bower_components/polymer-ui-accordion/polymer-ui-accordion.html">

시간을 절약하고  앱 최적화를 위한 도구들과 보일러플레이트 코드들이 완료될 수 있도록 Yeoman을 통해 새로운 폴리머 앱을 필요한 모든 의존성들과 함께 스캐폴딩하도록 다음과 같이 또다른 한줄을 실행합니다.

yo polymer

추가 설명


또한 저는 이 발표에서 보여드린 폴리머 주크박스 앱에 대한 30분짜리 자세한 추가 설명을 기록해두었습니다.




이 추가 비디오가 다루는 것들은 다음과 같습니다.

  • "모든 것이 엘리먼트(Everything is an element)"라는 주문이 무엇을 의미하는가
  • 폴리머의 플랫폼 폴리필과 엘리먼트들을 설치하기 위해 어떻게 Bower를 사용하는가
  • 주크박스 앱을 Yeoman generator와 sub-generator들을 사용하여 스캐폴딩하기
  • 보일러플래이트를 통해 스캐폴딩된 플랫폼 기능의 이해
  • 어떻게 제가 Angular 앱을 폴리머로 실용적으로 포팅했는지

또한 우리는 새로운 폴리머 엘리먼트들을 스캐폴딩하기 위해 Yeoman sub-generator를 활용하였습니다. 예를 들어 foo 엘리먼트를 위한 보일러플래이트를 생성하기 위해 다음과 같이 실행합니다.

yo polymer:element foo

엘리먼트를 자동으로 불러올지 혹은 생성자가 별도로 필요한지와 몇가지 다른 선호사항들에 대한 프롬프트가 표시될 것입니다.

앱을 위한 최종적인 소스는 발표와 GitHub에서 확인할 수 있습니다. 좀 더 구조적이고 읽기 쉽도록 약간 더 리팩토링을 해두었습니다.

앱의 미리보기는 다음과 같습니다.




추가적인 읽을거리들


요약하자면 폴리머는 웹 컴포넌트가 네이티브로 구현되기를 기다리는 동안 이를 모던 웹 브라우저에서 가능하도록 하는 자바스크립트 라이브러리입니다. 현재적인 도구화는 이들을 사용하는 여러분의 작업흐름을 개선할 수 있도록 도와주므로 여러분은 여러분만의 태그를 개발할 때 Yeoman과 Bower에 대한 시도를 즐겨볼 수 있을 것입니다.

이 주제에 대해 확인해볼만한 몇가지 다른 글들은 다음과 같습니다.




2014년 1월 20일 월요일

[튜토리얼/한글화] Shadow DOM 201: CSS와 스타일링 (Shadow DOM 201: CSS and Styling)

HTML5Rocks의 Shadow DOM 관련 튜토리얼 중 +Eric Bidelman의 'Shadow DOM 201: CSS와 스타일링 (Shadow DOM 201: CSS and Styling)' 튜토리얼의 한국어 번역이 업데이트되었습니다.

웹 컴포넌트 관련 튜토리얼마다 말씀드리는 내용입니다만 Shadow DOM 역시 이전의 Custom Element나 HTML Imports처럼 웹 컴포넌트를 지탱하는 4가지 규격 중의 하나입니다. Shadow DOM은 DOM에 대한 캡슐화(Encapsulation)와 같은 매우 강력한 기능을 제공합니다. HTML5Rocks에는 다음과 같이 Shadow DOM에 대한 3개의 튜토리얼이 업데이트되어 있습니다.
  1. Shadow DOM 101 - Shadow DOM의 기초적인 개념 및 구조
  2. Shadow DOM 201: CSS and Styling - Shadow DOM의 CSS 규칙 적용 및 스타일화 방법
  3. Shadow DOM 301: Advanced Concepts and DOM API다중 ShadowRoot 사용 및 자바스크립트를 통한 삽입 등의 발전된 DOM 동작

이 튜토리얼은 Shadow DOM를 사용할 때 캡슐화된 DOM 내의 스타일과 호스트 문서로부터의 스타일 상속 혹은 상속을 재설정하는 방법 등에 대해 설명합니다.

"Shadow DOM이 컴포넌트를 구성하는 DOM을 감추는 역할(encapsulation)뿐만이 아니라 스타일에 대한 캡슐화를 지원함으로써 여러분은 배포된(혹은 배포한) 웹 컴포넌트에 대해 여러분의 스타일을 유지하거나 반대로 사용자의 페이지의 Look&Feel을 상속받아 위화감 없는 스타일을 구성할 수도 있습니다. 이러한 스타일에 대한 캡슐화는 특히 사이트를 구축하는 UI 요소로써는 매우 중요한 속성이 될 것입니다. 더불어 이러한 캡슐화된 스타일을 어떻게 관리할 것인가도 웹 컴포넌트의 사용자들에게는 중요한 지점이 될 것입니다."


TL;DR;


이 튜토리얼은 Shadow DOM 101에서 다뤘던 개념들을 기초로 하여 Shadow DOM의 외양(Look&Feel)을 다루기 위한 몇가지 방법과 개념에 대해 다룹니다.

Shadow DOM은 DOM 자체에 대한 캡슐화(Encapsulation) 외에도 스타일에 대한 캡슐화를 지원하고 있습니다. 이렇게 스타일에 관련된 Shadow DOM의 핵심 기능 중의 하나는 섀도 경계(shadow boundary)입니다. Shadow DOM이 DOM에 대한 캡슐화만 지원하는 것이 아니라 자유로운 스타일 캡슐화를 제공하여 Shadow DOM 내의 스타일을 외부에서 격리시켜 유지하거나 반대로 외부의 스타일을 그대로 상속받아 위화감 없이 페이지의 Look & Feel을 유지할 수도 있습니다.

특히 :host를 이용하여 호스트가 되는 엘리먼트에 따라서 스타일을 다르게 지정하거나 확장하는 것이 가능하며, ^과 ^^ 연결자를 통해 섀도 경계(Shadow Boundary)를 무효화하는 것처럼 Shadow Tree 내의 스타일에 관여할 수도 있습니다. (^은 Hat, ^^은 Cat이라고 부릅니다.) 이러한 섀도 경계를 가로지르는 스타일링의 경우 Shadow DOM의 사용자가 정의한 스타일을 손쉽게 연결할 수 있도록 CSS Variable을 이용한 스타일 연결을 만들어내거나 .resetStyleInheritance 혹은 .applyAuthorStyles를 이용하여 스타일에 대한 상속 적용 여부를 결정지을 수도 있습니다. 또한 Shadow DOM 내에 배포된 노드들의 경우는 의사 엘리먼트(::content)를 이용하여 유연하게 확장할 수 있습니다.

보다 자세한 내용은 튜토리얼을 참고하시기 바랍니다.



번역 링크


참고 글

2014년 1월 17일 금요일

[튜토리얼/한글화] EME란 무엇인가? (EME WTF?: An introduction to Encrypted Media Extensions)

HTML5Rocks에 +Sam Dutton의 'EME란 무엇인가?: 암호화된 미디어 확장(EME WTF?: An Introduction to Encrypted Media Extensions)' 튜토리얼이 라이브되었습니다. 이번 번역은 한순보님께서 수고해주셨습니다. :)

EME는 말 그대로 Encrypted Media Extension의 약자로 미디어 엘리먼트(Video, Audio)에 대한 DRM(Digital Rights Management)를 제공하는 규격입니다. 논란이 있기는 했지만 어쨌던 서버에서 제어하던 비디오 등의 미디어 액세스 권한을 브라우저 측으로 내렸다고 봐도 무방합니다. 미디어 서비스를 하시는 분들이 주로 관심이 많겠네요. :)

아래는 W3C Restrict Media Community Group에서 이루어진 EME에 대한 논의 요약입니다. 본문에도 포함되어 있지만 아직 논란이 많은 부분이라 따로 발췌해서 첨부합니다.

  • 장점
    • EME(또는 같은 기술) 없이는 미디어 기업들은 웹을 통해 컨텐츠를 배포하지 않을 것입니다.
    • 잠겨진 장치에 대해 제한된 컨텐츠의 배포를 방지할 수 있습니다.
    • 파편화되고 유지보수가 불가능하며 독점적인 솔루션에 대한 의존을 줄여주는 개방형 표준입니다.
    • CDM으로부터 분리된 EME API 디자인의 유지를 통해 EME가 노후되는 것을 방지할 수 있습니다.
      • 역주: 즉, 실제 복호화 등에 대해 기능이 분리되어 운영체제 등의 업데이트로 지속적으로 암/복호화 등의 기반 기술의 업데이트가 가능하다는 뜻입니다만 이게 논란의 여지이기도 합니다. 인터페이스는 있으나 실제 구현으로 인한 의존도가 있다는 주장도 있다는 것이죠.
    • 컨텐츠 저작자가 수익을 얻는 것을 가능하게 하므로 DRM은 본질적으로 악한 것이 아닙니다.
    • 미디어 기업들이 다른 것을 건드리지 않고 웹을 통해 배포할 수 있도록 합니다.
    • EME(또는 같은 기술)은 W3C에서 관리할 것이며 W3C 표준은 여러개의 산업 표준보다 낫습니다.
  • 단점
    • 실제의 권한 관리는 W3C 규격에 포함되지 않았습니다.
    • 이를 다르게 부르자면 DRM이며 DRM은 오픈 웹에 대해 적대적인 개념입니다.
    • EME는 DRM이고 DRM은 지금까지 절대로 동작한 적이 없습니다.
      • 역주: 즉, DRM이 제대로 지원 및 표준화되어 제공된 사례가 없다는 뜻입니다.
    • (DVD에서 사용자가 광고를 건너뛰는 것을 불가능하게 한 것처럼) 사용자가 아니라 기업의 이익을 위해 설계되어 있습니다.
    • 다른 형태의 DRM보다 접근성에 있어 더 안좋습니다.
    • 본질적으로 플러그인 아키텍처를 의미하는 CDMS에 의존하며 플러그인은 좋지않은 선택입니다.
    • 컨텐츠 보호 메커니즘과 같은 결함이 있습니다 .
    • 스트리밍은 표준이 될 것이며 그 맥락에서 모든 형태의 DRM은 미디어가 훨씬 더 적게 액세스되도록 할 것입니다. 사용자 에이전트, 운영체제 그리고 하드웨어를 방해함으로써 말입니다.


"사실 DRM은 온라인 미디어 산업의 요구사항이 강하게 반영된 것이지만 도입과정에는 많은 논란이 있었습니다. 모두에게 공평하게 정보를 오픈하는 웹에 대해 보안이 아니라 사실상 컨텐츠의 제어를 제공하는 기능을 제공한다는 점과 실제 구현에 있어서 암호화된 컨텐츠를 복호화하기 위한 CDM(Content Decryption Module)은 브라우저 외부에 정의되어 기술의 지나친 경쟁과 파편화를 유도할 수 있다는 점이었죠. 현재 시점에서는 컨텐츠 저작 및 유통측의 손을 들어준 상태입니다만 CDM에 대해서는 지속적인 논란이 있을 것 같습니다."


TL;DR;


EME는 미디어 엘리먼트(Video, Audio)에 대한 DRM(Digital Rights Management)를 제공하는 규격입니다. EME(Encrypted Media Extensions)는 웹 어플리케이션이 암호화된 오디오와 비디오 재생의 허가를 위한 컨텐츠 보호 시스템과 연동할 수 있도록 하는 API를 제공합니다.

이 튜토리얼은 다음과 같은 EME를 이용한 미디어 재생의 개략적인 동작 과정을 다루며

  1. 하나 이상의 암호화된 스트림을 가진 오디오나 비디오의 재생 시도
  2. 브라우저가 미디어의 암호화를 인지하고 액세스를 위한 키 요청 이벤트(needkey)를 메타데이터와 함께 전달하고
  3. 어플리케이션이 needkey 이벤트에 대해 미디어키가 없을 경우 사용가능한 키 시스템과 라이센스 서버를 통해 키 생성합니다.
  4. CDM 연동을 위한 세션을 생성하여
  5. CDM이 준비되면 message 이벤트를 발생하고
  6. 세션이 message 이벤트를 수신하여 라이센스 서버에 대해 키를 요청하고
  7. 라이센스 서버로부터 전달받은 데이터를 미디어 키 세션을 통해 전달받고
  8. 라이센스 내의 키들을 이용하여 미디어 복호화하여
  9. 미디어 재생을 시작

이외에도 기본적인 기능으로 미디어에 대한 복호화 기능을 제공하는 CDM부터 라이센스 서버로부터의 키획득, 일반적인 암호화 및 클리어 키(Clear Key) 등에 대한 소개와 데모 등을 포함하고 있습니다.

보다 자세한 내용은 튜토리얼을 참고하시기 바랍니다.

번역 링크