2014년 2월 27일 목요일

[Summit/Summary] Google Developers Summit 후기

세미나나 컨퍼런스에 참가하는 것은 언제나 즐거운 일입니다. :) 어제(26일)도 코엑스 그랜드볼룸에서 Google Developers Summit이 있었습니다. 이번 서밋은 처음과 끝의 세션들은 서비스 관점에서의 내용들이 위주였고 중간 트랙 부분만 기술 관점의 세션들로 구성되어 있었습니다. 어제 들으며 요약해 놓은 내용을 공유합니다. 선발 신청 형태였음에도 많은 분들이 오셨더군요. 서밋 준비로 +Soonson Kwon님과 구글 코리아에서 고생하셨을 것 같습니다. 박수를~~ 보내드리며 후기 시작합니다. :)


  • 일시: 2월 26일 수요일 오후 1시 ~ 오후 6시 30분
  • 장소: 삼성역 코엑스 그랜드 볼룸 104호, 105호

아래는 제가 들은 세션의 스케쥴입니다.

시간주제 및 발표TL;DR
13:10 ~ 13:50Avoiding Pitfalls on Android App Quality and Visibility at Google Play (Ryosuke Matsuuchi)Your success with Android App depends on several quality characteristics of your app and good publishing techniques. In this session we'll discuss about how you can avoid common pitfalls on the app quality and publishing.
14:00 ~ 14:40다시 한번 안드로이드 디자인 가이드라인 (양찬석)
15:00 ~ 15:40Chrome WebView Essentials (Alex Danilo)Android 4.4 KitKat introduces a new WebView based on Chromium. The new WebView brings wonderful HTML5 APIs as well as lots of enhanced functionality. This session introduces the Chrome WebView, it's capabilities, debugging features and backward compatibility enhancements. Best practices for using the new WebView in existing applications will also be explained.
15:50 ~ 16:30Increasing user engagement in your apps with YouTube APIs (Yoshifumi Yamaguchi)In the past year, YouTube has made it easier for anyone to live stream content to the world as well as improved mobile video playback. Learn how you can utilize YouTube APIs to increase user engagement in your apps. We will show you examples of apps that have done this and walkthrough the technical implementation.
16:40 ~ 17:20크롬캐스트와 구글 캐스트 (미키김(김현유), 조시형)작년에 미국에서 출시한 크롬캐스트는 N 스크린과 스마트 TV 시장에 새로운 화두를 던지고 있으며 타임지가 뽑은 2013년도의 제품을 선정되기도 했습니다. 이번 세션에서는 크롬캐스트에 대한 소개 및 구글 캐스트 SDK에서 대해서 이야기하고 개발자가 가질 수 있는 기회에 대해서 다룹니다.

아래는 들으면서 적어둔 각 세션에 대한 요약 로그입니다.


Session.1: Avoiding Pitfalls on Android App Quality and Visibility at Google Play - +Ryosuke Matsuuchi 


료스케 마츠우치씨는 구글 플레이에서의 가이드라인에 대한 내용을 "구글 플레이에서 안드로이드 앱 품질과 가시성에 대한 위험 회피하기"라는 제목으로 세션을 진행했습니다. 일단 앞부분은 제가 딴짓 하느라 살짝 놓쳤는데 어쨌던 구글 플레이에서의 모든 노출 알고리즘은 영역에 상관없이 동일한 방식을 따른다더군요.

아래는 회피해야할 위험(Pitfall)들로 묘사된 슬라이드에 대한 내용입니다. 일반적인 내용도 많지만 참조해보시길.

> #1 나쁜 사용자 평가


일반적으로 4개에서 5개의 별을 받은 어플리케이션이 3개를 받은 어플리케이션의 매출 수준에 비해 2.8배의 매출을 보인다고 합니다. 근본적으로 사용자 평가를 관리하는 품질 관리, 운영 및 지원의 근본적 원인이겠죠.

> #2 높은 언인스톨율


가짜 스크린샷이나 잦은 알림(Notificaiton) 등으로 인한 언인스톨들이 많이 발생하며 이러한 언인스톨율이 높은 경우의 문제의 가장 일반적인 경우 중 하나는 프로모션을 통해 빠르게 랭킹에 진입한 뒤 언인스톨율이 높으면 빠르게 랭킹에서 사라지는 현상입니다.

그렇다면 랭킹에서의 drop율은 언인스톨율에 의해 가속될 수 있는 것인가? 라는 의문이 들었는데 질문 시간에 유사한 질문이 있어 따로 질의를 하지는 않았습니다. 랭킹 시스템 등은 일반적으로 비밀이기도 하고 해서 자세한 답변은 하지 않은 것 같더군요.

또다른 질의는 "개별 국가에서의 언인스톨이 영향을 주는가?" 였는데 결론적으로는 '직접적인 영향은 주지 않지만 다른 국가에 대한 간접적인 영향은 준다.'였습니다. 시스템적으로도 그런 것인지는 좀 불분명한데…기회가 되면 확인해보시고 공유해주시면 감사하겠습니다. :)

> #3 낮은 성능


소프트웨어 개발쪽에서는 '성능은 언제나 문제(Performance is always problem)'이라는 말을 쓰는 경우들이 많은데요. -저만 자주 들었나요? 제가 이쪽에 관심을 두고 있어서 그런 것 같기도 합니다만...:)-

아무튼 이에 대한 UX 관점에서의 권장 사항을 얘기하더군요.


  • 스크롤/애니메이션에 대해 20FPS 이상 유지
  • 터치에 대한 200ms 내의 반응성
  • 웹과는 다른 사용자 경험 
    • 웹과는 다르다기 보다는 멀티태스킹이나 시스템 자원 활용이 비교적 자유로운 네이티브 앱의 특성 상 프리패치나 백그라운드 태스크, 캐싱 등에 대한 지원을 통해 성능을 높이라는 얘기입니다.
  • 디버그 모드에서 Strict 상태에서의 “Red Flash”는 제거
    • 제가 안드로이드를 별로 안해봐서 정확하게는 모르지만 기억으로는 렌더링 오버헤드가 일어나는 영역에 빨간색 박스를 쳐주는 기능이 있었던 것 같은데요. 이를 응용해서 성능 최적화를 하라는 얘기로 생각합니다.


> #4 - 태블릿 사용자


일단 스마트폰과 대비했을 때 1.7배의 사용자가 앱을 구매한다고 하더군요. 그리고  13.1%의 안드로이드 디바이스가 높은 해상도를 가지고 있으므로 고해상도에 대한 대응을 반드시 해달라고 합니다.

  • 다양한 해상도를 지원하는 앱으로 제작
    • 안드로이드의 경우 Fragment를 사용하면 되겠고 하이브리드 웹앱의 경우는 반응형이나 뷰 분리같은 것들이 해당되겠죠.
  • 가급적 태블릿 버전을 별도로 분리하지 말 것
  • Google Play에서 “폰을 위해 디자인된 앱” 레이블링을 피할 것
    • 2013/11/22부터 구글 플레이에서 태블릿을 위해 디자인 된 앱에 대한 리스트를 보여주므로 사실은 태블릿을 지원한다는 것이 더 좋은 마케팅 포인트로 보입니다.


> #5 기존 디바이스 사용자를 타겟팅한 개발


매우 강조하던 부분 중의 하나인데 기존 디바이스에 비해 신규 단말의 사용자가 2.2배의 구매율을 보이므로 사실은 신규 단말을 대상으로 하라는 얘기입니다.


  • SDK Ver.19 이상으로 설정하여 “Menu button of shame”을 회피할 것
  • 2.x 버전에 대한 지원 패키지도 있으니 최신 UI/UX 가이드라인을 따를 것
  • 구글 게임 플레이 서비스 및 컨트롤러 등의 최신 기술에 대해 사용을 고려할 것

이 부분은 아무래도 최신의 안드로이드 플랫폼과 기술을 확산시키려는 구글의 의지가 반영된 내용이라고도 보입니다. 물론 UX 가이드라인은 지원 패키지가 있으니 하는게 Look & Feel에서 맞다고 보여집니다.


> #6 일반적인 배포 실수들


간단하게 정리하겠습니다.

  • 통신 사업자 및 호환 스크린 등에 대한 사용과 같은 좁은 범위의 대상으로 배포하는 것을 회피
  • 고해상도의 앱 런칭 아이콘을 제공. XXXHDPI까지 얘기를 하는 것을 보면 나름 TV 부분에 대한 니즈도 있는 것 같다는 생각이 듭니다.
  • 스팸이나 잘못된 정보 기재 조심
  • 소개 비디오는 가급적이면 삽입할 것
  • 해외 사용자를 위한 번역에도 신경쓸 것


> #7 끔찍한 권한 요청들


이 부분은 저도 동의하는 바입니다만, 가끔 퍼미션을 필요한 것보다 과도하게 넣는 경우들이 있는데 이건 좀 피해줬으면 좋겠습니다. 요즘 같이 정보 보안에 민감한 시대에 아무래도 걱정되는 부분들이 사용자 입장에서는 있으니까요. 예를 들어 게임에서 사용하지 않는 경우에도 사진 촬영 퍼미션을 넣는다던지 하는 경우죠. 권한이 필요하다면 왜 쓰는지 깔끔하게 정리해서 설명하는 것이 좋습니다.

게임에서 주로 잘못된 권한 요청의 예는 다음과 같습니다. -가만 보면 가끔 게임에서 쓰는 것들은 있기는 합니다.-

  1. WiFi 설정 변경
  2. 부팅 완료 노티
  3. 실행 태스크들에 대한 쿼리
  4. 현재 위치 정보
  5. 시스템 로그 접근
  6. 직접적인 전화 연결
  7. 연락처 및 캘린더 접근
  8. 북마크 접근
  9. 시스템 수준의 경고 출력
  10. SMS 송수신


> #8 IA 결제 API에 대한 잚못된 사용



  • Version 3 API를 사용하세요! - 구버전을 사용하는 경우가 많은가 봅니다.
  • 메모리 부족에 대해 반드시 테스트할 것
    • 생각보다 많은 프로그램이 결제 중 메모리 문제로 셧다운이 일어나서 사용자에게 결제 처리 여부에 대한 고민을 하게 되므로 사용자에게 결제가 진행되지 않았으면 이를 다시 시작한다는 것을 명확하게 처리
  • 구매 토큰을 반드시 서버에 저장할 것!!!!!
    • 어쨌던지 사용자의 불만 제기에 대해서 대응 시에도 이러한 부분은 필요하다는 것이 주요한 내용입니다. 생각보다 많은 사람들이 서버 없이 해서 그런가 싶기도 하네요.
  • 서버측 인증서 검증 기능을 구현할 것
    • java.security.Signature.verify()를 믿지 말고 서버에서 할 것.
    • …이건 뭐지…싶었는데 실제로는 가짜 신용카드나 결제 정보를 이용하여 구매를 해킹하는 경우가 많은 듯 합니다.
  • 사용자 구매 정보, 커스텀 리포트 등을 이용하여 잘 운영할 것


전반적으로 이 세션은 개괄적인 구글 플레이의 가이드라인임과 동시에 향후 구글이 준비하거나 진행 중인 서비스/플랫폼에 대한 최신화 유지에 대한 의지를 약간 느낄 수 있었던 듯 합니다.


Session.2: 다시 한번 안드로이드 디자인 가이드라인 - +Chansuk Yang


이번 세션은 구글코리아 Dev Relation의 안드로이드 담당이신 양찬석님의 발표였습니다. 간단하게 정리하자면 구글에서 제공하는 안드로이드 디자인 가이드라인에 따라 앱과 플랫폼의 UX를 일관성있게 가져가자는게 주요 내용입니다. - 사이트에도 있는 내용이라 일부만 텍스트로 정리했습니다. :)

그리고 킷캣 관련 수정 사항에 대한 얘기가 좀 있었는데요. 기본적인 내용은 개발자 블로그를 참고하셔도 될 듯 합니다.

그 외에도 풀스크린 모드가 있었는데 제가 안드로이드 개발을 안해서 2가지 모드가 있는지도 모르고 살았네요. :(


  • Lean Back - 일반적인 비디오 관련 재생과 유사한 풀스크린 처리 모델
  • Immersive - 화면 밖으로부터의 스와이프 인/아웃을 통해 풀스크린 뷰를 제어하여 일반적인 터치에는 메뉴 화면 등으로 전환 등이 반응하지 않는 형태의 뷰입니다. 많이 사용할 것 같은 기능이더군요. 안드로이드 개발자분들은 어떻게 생각하시는지 조금 궁금하네요.


그외에는 안드로이드 디자인에 대한 내용이 있었는데 정리하면 네비게이션과 관련된 UI 및 액션들은 안드로이드 공식 지원 패키지를 사용하여 작업하고 알림(Notification) 바의 각 알림이 중첩될 경우는 하나의 알림에 업데이트하는 것 등에 대한 가이드가 있었습니다. 마지막은 정말 동의!!!! 하는 바이고 웹에서도 그렇습니다!!!! 제발 좀!!!! ;(

또, 반응형 디자인에 대한 얘기가 있었는데 간략하게 정리하자면 만드는게 좋고 이유는 태블릿이나 고해상도 단말에 대한 이슈이기도 합니다. Pitfalls에서도 같은 내용이 있었죠. 웹이라고 예외는 아니니 요즘 시대의 앱이나 서비스는 반응형이던 분리형 뷰를 다루던 디테일한 접근이 필요한 것은 사실입니다.


Session.3: Chrome WebView Essentials - +Alex Danilo 


킷캣에서부터 안드로이드 크롬 웹뷰는 많은 변화가 있었습니다. 가장 중요한 것 중의 하나는 크롬과의 코드 베이스를 공유하게 된 것이죠. 최신 웹 기술의 반영 속도가 이제 중요한 이슈 중의 하나인 것을 반증하는 것이기도 합니다. 다시 정리하면 안드로이드 웹뷰는 크로미움 30 버전의 스냅샷을 각 앱들이 사용하는 것이나 마찬가지이고 Chrome for Android 역시도 코드 베이스는 같습니다. (그렇다고 모든 기능이 똑같이 적용되지는 않습니다. 이쪽도 포팅과 검증은 필요하니까요.)



이미 많이 다뤄진 내용이기도 하고 안드로이드 공식 문서에서도 있던 내용들이라 간략하게만 살펴보자면 HTML5 지원 점수가 284점 > 424점으로 크게! 향상되었고 IndexDB, Web Socket, requestAnimationFrame, SVG Filters and effects, H/W 가속 그래픽스(Canvas 포함)들이 새로 지원되었습니다.

디버깅 인터페이스가 정리되서 웹뷰에서도 데스크탑 크롬의 "chrome://insepct"를 사용해서 원격 디버깅을 할 수 있습니다. 그리고 개발자도구가 완전하게 동작하는 이유는 데스크톱 크롬과 동일한 버전이라는 설명도요. 자세한 내용은 여기를 참조하세요. :)

Hybird Web App에 대한 언급도 있었는데 Look & Feel의 통일을 위해서 네이티브 컨트롤로 앱의 UI를 구성하고 실제 컨텐츠만 웹뷰를 통해서 사용하는 것도 좋은 방법이라는 얘기가 있었습니다. Cordova에서도 그런 시도들이 있었는데 실제로는 자바스크립트와 네이티브 클라이언트 개발이 둘 다 필요해서 팀 단위의 프로젝트에서 적용은 해볼만 할 것 같습니다. (개인적으로도 몇달 전에 그러한 형태로 적용한 프로젝트가 있는데 약간의 시나리오 구상은 필요합니다.)

그리고 모르던 내용이었는데 웹뷰가 하위 호환을 위한 기능을 지원하고 있습니다. - targetSDKVersion이 19 미만일 경우 호환모드로 동작하도록 되어 있다고 합니다.-

UA String이 Chrome 30.0.0.0으로 변경된 것은 알고 계실테고 멀티스레드 관련해서 웹뷰와 인터페이스를 사용할 경우 기본적으로 mainUIThread에서 웹 컨텐츠 연동 기능을 호출하는 것이 시스템의 흐름 상 옳은 방법이지만 멀티스레드가 필요할 경우는 runOnUiThread() 사용하라고 합니다. (이는 웹에서의 자바스크립트 로직이 메인 UI 스레드 상에서 동작하는 이유로도 옳은 방법으로 보입니다.)

커스텀 URL 핸들링은  RFC 3986 기반의 URL Scheme 지원하고 있고 많이들 활용하시니 따로 언급은 필요없을 것 같고 뷰포트 관련하여 target-densitydpi는 지원되지 않고 실제 화면이 작을 때만 줌인으로 동작되며 다중 뷰포트 메타 태그는 지원되지 않는 부분은 주의하셔야 합니다. 메타 태그의 뷰포트 관련한 내용은 한번 정리를 해봐야 할 것 같네요. 아! 그리고 기본 줌 엔진은 deprecated되었습니다

그리고 스타일링 관련하여 변경으로 인한 주의 사항이 좀 있는데 예를 들자면 background 축약 표현(Shorthand)은 긴 표현(Longhand)을 오버라이딩하므로 아래와 같이 사용해야 합니다.

// 'background' will reset 'background-size'
.some-class {
  background-size: contain;
  background: url('images/image.png') no-repeat;
}

// fixed
.some-class {
  background: url('images/image.png') no-repeat;
  background-size: contain;
}


뷰포트 내에서의 CSS에서의 픽셀 단위는 window.outerWidth와 window.outerHeight를 기준으로 동작합니다.

지금까지의 내용을 기준으로 간략하게 3가지의 사례를 보자면 다음과 같습니다.

  • targetSDKVersion
  • <application android:hardwareAccelerated="true">
  • WebView.setWebContentsDebuggingEnabled(true);


향후 계획과 관련하여 WebRTC가 마침내 다음 버전의 크롬 웹뷰에 탑재될 예정이라고 하고, WebGL은 안드로이드의 기존 렌더링 시스템과의 문제 해결을 진행 중이며  그리고 자동 업데이트에 대한 이슈들을 풀기 위해 많은 개발자들이 노력 중이하고 하네요.

개인적인 질의 사항으로 현재 크롬의 경우 CSS3 Animation 및 Transition 엔진이 이미 웹 애니메이션 규격의 네이티브 엔진으로 대체되었는데 이에 대한 Chrome for Android 및 WebView에서의 현재 현황과 계획에 대해 물었습니다.

답변을 정리하자면 아마도 다음 웹뷰에서 Web Animation Engine이 탑재될 것이고 올해 내에는 JS API도 만나볼 수 있지 않을까라고 하네요. 정말 그랬으면 좋겠습니다! :)


Session.4: Increasing user engagement in your apps with YouTube APIs - +Yoshifumi YAMAGUCHI


유튜브가 gData API 이외에도 많은 API를 제공하고 있는데 오늘 세션에서 주로 다뤄진 내용은 유튜브에 비디오를 생성할 수 있는 기능을 포커스하여 발표가 진행되었습니다.

> 유튜브 API를 통해 무엇을 얻을 수 있는가? 바이럴???


'왜 사용해야 하는가?'에 대한 얘기로 세션이 시작되었는데 나온 예 중의 하나를 들자면 90% 이상의 게이머들이 게임 트레일러 영상을 봤다고 합니다. -일주일에 7시간 이상 게임을 플레이하는 13~35세의 게이머를 대상으로 한 조사라서 대략 하드코어 유저군이긴 합니다만 트레일러가 중요한 홍보 수단 중의 하나이니 틀린 말은 아니라고 봅니다.-

> Youtube API


유튜브 API는 구독 위젯, 라이브 스트리밍 API 등으로 구성되어 있고 이 모든 기능을 합치면  YouTube와 기능 상으로는 동치 관계에 가깝다네요. APIs들은 재생과 관련된 Playback API 외에도 Upload, Explore, Live Stream, 채널/비디오, 사용자 동작 및 플레이리스트 등의 오프사이트 API와 채널, 커스텀 리포트, Metric과 관련된 분석 기능들이 제공됩니다.

> 개발자 생태계와 사례


개발자 생태계에 대해서는  정리하자면 어쨌던 사용자의 게임 플레이와 같은 동작에 대해 앱 내에서 직접 레코딩 후 유튜브로 업로드하는 방법을 통해 바이럴 커뮤니티를 만들어 낼 수 있다는 것이 핵심이라고 볼 수 있을 것 같고 github.com/youtube 에서 관련 라이브러리를 확인할 수 있습니다. 물론 OAuth2를 사용하여 인증하는 과정이 필요합니다. 개인적으로는 Builder를 통해 API Interface 객체를 만드는 과정은 맘에 쏙 들었습니다. :)

Elgato, XSplit 같은 제게는 생소한 게임과 서비스로 예제를 들었는데 잠깐 딴짓하느라 자세하게는 못들었습니다. 제가 https://code.google.com/p/youtube-direct-lite/를 기록해두었는데 일단은 샘플 데모입니다만 왜 여기에 적어두었는지 도저히 생각이 안나네요. ;;

> Youtube Streaming API


Youtube Streaming API에 대한 이야기도 있었는데 자세한 내용은 개발자 사이트를 참조하시고 간단하게 다음 3가지의 요소로 구성되어 있는데 Boradcast가 일종의 중계 센터가 되는 개념이고 bind()를 통해 각 Peer가 스트리밍 데이터 연결되며 insert()를 통해 스트리밍 송신 채널 생성할 수 있도록 하는 개념을 가지고 있다고 보시면 되겠습니다.

> 한글 개발자 문서와 질의


아 그리고 얼마전에 YouTube 개발자 센터의 한글 문서가 오픈되었는데 아직 전부가 번역된 것은 아니지만 퀄리티가 좋더군요. 관심있으시면 방문하셔서 한글로 언어 선택을 하고 보시면 되겠습니다.

질의 시간에는 "Make Less With NO Budget"이라는 문구로 혼동이 있어 질의가 갔는데 결론적으로는 "Write Less Do More"와 비슷하게 비디오를 만들어 올리는데는 약간의 노력만 있으면 되고 실제 공유에 관련된 API 사용에 대한 어떠한 비용도 청구되지 않는다는 뜻이라고 합니다. 그리고 개인화된 미디어를 유튜브에 업로드하는 경우에 대한 질의가 있었는데 기본적으로 유튜브가 비디오 공유 서비스이므로 같은 API를 가진 개인화 서비스인 드라이브 API를 추천한다는 것으로 발표가 마무리 되었습니다.


Session.5: 크롬캐스트와 구글 캐스트 - +Mickey Kim+Chansuk Yang 


작년에 크롬캐스트에 대해 많은 관심들이 있었는데 이번에 +Mickey Kim님이 세션에서 이에 대한 소개를 하고 +Chansuk Yang님이 다시 등장해서 개발 환경을 살펴보는 시간을 가졌습니다.  일단 구글 TV는 이제 별도로 사용하지 않고 안드로이드 플랫폼으로 통합 운영되게 되었고 랩탑이나 안드로이드 디바이스로부터 스크린 캐스트가 가능한 서비스 형태로 제공됩니다. Android, iOS, ChromeApps  API가 개발 환경으로 배포된 상태이고 자세한 내용은 개발자 사이트에서 참조할 수 있습니다. 국내 출시 예정에 대한 질의가 있었는데 올해 출시를 목표로 준비 중이라네요. 나머지 질문은 개발자 사이트에서 확인할 수 있는 내용이라 생략합니다. :)

#

마지막 세션은 제가 GDG Seoul에서 발표가 있어서 못듣고 미리 나왔네요. 기념품이 노트북 파우치라는 소식을 전해듣고 땅을 칠 뻔 했지만 대신 커뮤니티에서 즐거운 시간을 가진 하루였습니다. ㅎㅎㅎ

2014년 2월 25일 화요일

[튜토리얼/한글화] WebRTC 데이터채널: 고성능 데이터 교환을 위한 WebRTC 데이터 채널(WebRTC data channels: WebRTC data channels for high performance data exchange)

HTML5Rocks에 +Dan Ristic의 'WebRTC 데이터채널: 고성능 데이터 교환을 위한 WebRTC 데이터 채널(WebRTC data channels: WebRTC data channels for high performance data exchange)' 튜토리얼의 한글 버전이 업데이트되었습니다.

이번 번역은 한순보님께서 수고해주셨습니다. :)

"WebRTC는 종종 화상 회의와 같은 미디어 통신을 위한 규격처럼 인식되는 경우가 있으나 그렇지 않습니다. 화상회의와 같은 것은 WebRTC의 P2P 통신과 mediaCapture()이 결합된 좋은 사례 중 하나일 뿐이죠. WebRTC는 근본적으로 P2P를 기반으로 하는 데이터 전송 메커니즘입니다. 이는 파일 전송뿐만이 아니라 P2P를 기반으로하는 멀티플레이어 게임에도 유용합니다. RTCDataChannel은 파일 공유, 멀티플레이어 게임, 콘텐츠 전송을 위한 앱을 만드는 새로운 방식이며 이를 사용하여 낮은 지연 시간을 가지는 고성능 네트워크 어플리케이션을 제공할 수 있습니다. RTCDataChannel의 출현은 브라우저에서 데이터의 통신 방식 중 많은 부분들을 바꾸게 될 것입니다."


TL;DR;


커뮤니케이션, 게임, 혹은 파일 전송을 위한 두 브라우저 간의 데이터 전송은 상당히 복잡한 과정일 수 있습니다. 우리에게는 WebSocket, AJAX, 그리고 Server Sent Events가 있지만 근본적으로 서버를 통한 통신 모델로 디자인되었습니다. 데이터를 중계(relay)하기 위해 서버를 설정하고 비용을 내야 하며, 아마도 이를 여러 데이터 센터로 확장할 필요가 있습니다. 이 시나리오는 높은 지연 시간(latency)의 가능성이 있고, 데이터를 비공개로 유지하는 것이 어렵습니다.

한 피어(peer)에서 다른 곳으로 직접 데이터를 전달하기 위해 WebRTC의 RTCDataChannel API를 사용하는 것은 P2P(peer-to-peer) 연결을 가능하게 하여 중개 서버가 없고 '홉(hops)'이 적어 지연 시간을 더 줄일 수 있습니다.

> WebRTC DataChannel의 특성


RTCDataChannel API는 웹소켓을 완전히 모방하여 디자인되었을 뿐만 아니라  문자열, Blob, ArrayBuffer 그리고 ArrayBufferView와 같은 일부지만 유용한 자바스크립트 바이너리 타입을 지원합니다. RTCDataChannel은 다음과 같이 UDP와 유사한 '신뢰성 없는 모드'와 TCP과 유사한 '신뢰성 있는 모드' 둘 중 하나로 동작할 수 있습니다.

[출처: +Ilya Grigorik 'High Performance Browser Networking']
신뢰성 있는 방식은 메시지 전송과 메시지가 전달되는 순서를 보장하지만 추가적인 오버헤드가 있으며 신뢰성 없는 방식은 모든 메시지가 상대편에 도달하는지와 어떤 순서로 도달하는지를 보장하지 않는 대신 오버헤드를 제거합니다

시그널링이 일어난 전후에 이미 설정한 피어 연결로부터 dataChannel 오브젝트를 생성하고 옵션을 설정하여 데이터 채널의 신뢰성 등을 설정할 수 있습니다. RTCDataChannel은 연결이 되거나, 끊기거나, 에러가 발생할 때와 다른 피어에서 메시지를 받았을 때 이벤트를 발생하도록 할 수 있습니다.

> 안전성


암호화(Encryption)는 WebRTC 요소의 기본 사항입니다. RTCDataChannel을 사용하면 모든 데이터가 데이터그램 전송 계층 보안 (Datagram Transport Layer Security, DTLS)을 사용하며 WebRTC를 지원하는 모든 브라우저가 DTLS를 내장하고 있으므로 추가적인 구현없이도 안전한 데이터 송수신을 가능하게 합니다.


이 튜토리얼은 WebRTC 데이터 채널을 설정하고 사용하는 기본적인 방법뿐만 아니라 오늘날 웹에서의 일반적인 사용 사례를 다루고 있습니다. 자세한 내용은 튜토리얼은 참조하시기 바랍니다. :)

번역 링크


참조 링크

[튜토리얼/한글화] 네비게이션 타이밍을 이용한 페이지 로딩 속도 측정하기(Measuring Page Load Speed with Navigation Timing)

HTML5Rocks에 +Sam Dutton의 튜토리얼 '네비게이션 타이밍을 이용한 페이지 로딩 속도 측정하기(Measuring Page Load Speed with Navigation Timing)'의 한글 버전이 업데이트되었습니다.

사용자는 브라우저를 통해 문서를 요청하고 다운로드하고 이를 파싱하거나 렌더링하는 등의 일련의 과정을 거쳐 완성된 페이지를 확인하게 됩니다. 같은 이유로 사용자 입장에서의 로딩 성능이란 이 일련의 과정에 대한 성능이 됩니다. 철저히 클라이언트 입장에서의 감각이죠. 그렇다면 사용자에게 높은 수준의 로딩 성능을 체험할 수 있도록 해주기 위해서는 무엇을 해야할까요? CDN을 통해 최소한의 네트워크 경로를 통해 리소스를 배포하고 웹 페이지의 구조는 최적화되어야 하며 여러가지 기법들이 사용되어야 합니다. 우리는 이를 위한 일반적인 체크리스트들을 많이들 보게되지만 이게 끝일까요?

모든 최적화는 '측정'에서 출발합니다. 측정되지 않는 것은 불행하게도 추측과 실험의 반복(Iteration)을 통해서 접근할 수 밖에 없습니다. 하지만 로딩 성능를 측정하는 방법은 쉽지 않습니다. 자바스크립트를 이용하여 어느 정도의 추적은 할 수 있지만 이 접근은 근본적으로 자바스크립트가 웹 페이지에서 가지는 생명 주기와 같은 이슈들로 인해 우리를 정확한 측정에서 한발 물러서 있도록 합니다. Navigation Timing은 우리가 해왔던 이러한 일들을 브라우저 측면에서 접근합니다. 정확한 시간을 측정하고 그 시간값을 통해 정확한 최적화 지점을 찾을 수 있도록 합니다.

이 튜토리얼은 브라우저의 네비게이션 과정에 대한 시간 흐름을 측정할 수 있는 Navigation Timing을 다루고 있습니다. 이번 번역은 변정훈(Outsider)님께서 수고해주셨습니다. :)

"Navigation Timing 인터페이스는 일련의 브라우징 과정에 대해 브라우저가 직접 측정한 결과값을 제공합니다. 사용자는 언제나 브라우저를 통해 우리의 웹페이지에 접근하므로 이러한 정확한 측정값은 제대로 된 최적화를 위한 첫걸음을 딛을 수 있도록 해줍니다. 사용자 타이밍과 함께 사용한다면 여러분의 웹페이지가 가지는 성능 상의 약점을 쉽게 파악할 수 있는 강력한 도구가 될 것입니다."


TL;DR;


사람들은 빨리 뜨는 웹페이지를 좋아합니다. 하지만 웹페이지의 로딩 속도는 어떻게 측정해야 하며 "페이지 로딩"의 의미는 정확히 무엇일까요?

Navigation Timing은 웹의 성능을 정확하게 측정하는 자바스크립트 API입니다. Navigation Timing API는 페이지 탐색과 로드 이벤트와 관련한 정확한 타이밍을 자세하게 얻을 방법을 제공합니다. 현재 이 API는 인터넷 익스플로러 9, 크롬, 파이어폭스에서 사용할 수 있습니다.

[그림] Navigation Timing에 대한 기본 Mark들

Date 객체를 사용해서 타이밍을 측정하는 방법과는 달리 Navigation Timing API는 페이지 로딩에 전혀 영향을 주지 않고 사용할 수 있습니다. 그러므로 사내 네트워크에서 개발용 컴퓨터를 사용해서 개발자가 직접 테스트하는 대신 실제 사용자가 겪는 "현실"의 페이지 로딩 지연시간을 측정하는 데 유용하게 사용할 수 있습니다.

Navigation Timing은 개발자가 성능을 이해하고 최적화하도록 유용한 도구를 제공하며 더 나은 정보는 페이지 로드 지연을 이해하는 데 유용하고 이로써 더 효율적인 웹사이트와 인프라, 더 빠른 웹 애플리케이션과 웹을 만들 수 있고 좋은 사용자 경험을 제공할 수 있습니다.

이 튜토리얼은 Navigation Timing API를 사용해서 타이밍 데이터를 사용하는 방법을 설명합니다. 보다 자세한 내용은 튜토리얼을 참고하시기 바랍니다.


번역 링크

참조 링크

2014년 2월 24일 월요일

[튜토리얼/MashUp] 웹 컴포넌트: 차세대 프론트엔드 웹 개발로 가는 관문(Web Component: the Gate to Next Front-end Web Developments)

오랜만에 업데이트를 하게 되는군요. 그간 HTML5Rocks의 튜토리얼들을 함께 번역해주신 분들의 노력에 힘입어 Web Component에 관련하여 설명할 수 있는 문서의 뼈대가 만들어졌습니다. 다른 한글화 및 업데이트 소식들도 밀려있는데 잠시 미뤄두고 이에 대한 포스팅을 하고자 합니다.

완전히 동의합니다. :) [출처: +Zeno Rocha - A future called Web Components]

"다소 거창한 제목을 붙였습니다만;; 컴포넌트가 완전한 에코 시스템하에서 가지는 강력함과 파괴력을 우리는 다른 플랫폼에서서도 익히 봐왔습니다. 같은 관점에서 웹 컴포넌트 역시 프론트엔드 개발에 있어 많은 변화를 예고하고 있는 기술이라고 예상할 수 있지 않을까요?" 



웹 컴포넌트?


웹 컴포넌트(Web Component)의 개념 자체가 아주 새롭고 특별한 기술은 아닙니다. 오랜동안 개발을 해오신 분들이 아니더라도 '컴포넌트(Component)'라는 말은 들어보셨으리라 생각합니다. 그러나 웹 컴포넌트가 가지는 의미를 알기 위해 웹에서의 컴포넌트가 왜 필요한지에 대해 잠시 생각해보도록 하겠습니다.


> 골격만큼이나 중요한 다른 것들...


한두번쯤은 게시판을 꾸미기 위해 혹은 만들기 위해 마크업 작업을 해보신 경험이 있을 것입니다. 사실 의미적으로 마크업이 가지는 모습은 매우 명확합니다. '<head>'에는 사용자의 눈에는 보이지 않지만 브라우저가 먼저 처리해야하는 많은 것들이 기술되어 있으며 '<body>'에는 우리가 사용자에게 전달하고자 하는 정보들이 담긴 수많은 마크업과 텍스트들이 존재합니다. 물론 이미지도 말이죠. 단지 이 관점에서 보자면 문서는 그리 복잡하지 않습니다. 예를 들어 W3C의 대한민국 인터넷 관심그룹이 그렇습니다. 문서는 깔끔하게 필요한 태그들만을 가지고 있고 그 자체로도 문서는 완전합니다.

그러나 실제는 어떤가요? 실제 현장까지 가지 않고 개인 홈페이지만 살펴보더라도 스타일에 대한 많은 시도들이 보이고 있습니다. 이들은 화려하고 아름답고 때로는 사용자 경험(UX)를 개선하는 많은 기능들을 제공합니다만 그 뒤에는 너무나도 복잡해져만 가는 마크업들과 스타일, 자바스크립트들이 존재합니다. 많은 요구사항들이 본래의 구조보다 많은 개발들을 요구하고 있죠. -물론 국내는 웹이 대중화되던 초기부터 그랬습니다. 지금은? :)-

GMail은 편리하지만 태그는 그렇지 않습니다. :( [출처: HTML5Rocks 'Custom Element' 튜토리얼]

GMail을 예로 들어보죠. 저는 GMail을 이용하고 있고 실제로는 애용하고 있습니다. 이 서비스는 쉽게 메일을 읽고 편리하게 기록 속에 남아 있는 다른 사용자들의 메일주소를 몇번의 타이핑만으로 찾을 수 있으며  답장 역시 현재 읽고 있는 페이지에서 가능합니다. 그러나 과연 개발도 그럴까요? 이 서비스를 개발자도구로 열어본다면 아마 그렇지 않다고 생각하게 될 것입니다.

전 오랜동안 네이티브 앱이나 서비스, 플랫폼을 개발해왔습니다. 사실 개발에 촛점을 맞춰보자면 웹 개발을 마지막으로 한 것은 CGI와 ASP가 전성시대를 열던 초기에 있었던 몇번이 제 경험의 대다수라고 해도 과언이 아닙니다. 그리고 현재 시점에서 다시 웹을 살펴보았을 때 정말 많은 것들이 바뀌었고 그에 놀라워함에도 불구하고 개발 방법 자체는 예전에 작업하던 많은 방식들이 그대로 이루어지고 있다는 것에 다시 놀랄 수 밖에 없습니다. (사실 편리해진 것들도 많고, 모든 것을 바꿔야할 필요가 없다는 것은 잘 알고 있습니다.)

여전히 우리는 다른 프로젝트에서 사용했던 리스트 아이템들을 새로운 프로젝트에서도 적용하기 위해 마크업을 복사해서 수정하고 스타일링을 위한 새로운 CSS를 작성하거나 기존 스타일과의 충돌을 제거하고, 자바스크립트를 최대한 모듈화하여 작성하고 있습니다. 그러나 여전히 이는 근본적인 재활용 방법이 아닌 개발자의 역량과 경험에 의존하고 있는 일종의 개선된 Workflow에 가깝습니다. 즉, 언제든지 우리는 태그의 바다(Tag Soup)와 같은 위험 지역에 다시 빠질 수 있는 가능성을 안고 있습니다. 게다가 태그의 바다에 빠진다는 것은 CSS나 자바스크립트의 태풍 속에 노출된다는 것과도 같죠.


> 무엇이 필요할까?


사실 우리는 필요한 것이 무엇인지는 이미 알고 있습니다. 다만 지금까지는 이를 방법론으로, 개발도구로, 경험으로 해결해왔을 뿐이죠. 이제 우리에게 필요한 것은 '자주 사용되는 유용한 것들 혹은 구조 상 분리가 필요한 것들을 개발의 다른 요소들과 충돌하지 않는 형태로 재활용이 가능하도록 만들어 주는 일관적인 방법'입니다. 특히 UI 요소들이 많은 프론트엔드 개발에서는 '리소스 관점에서 분리되어 있는 HTML, CSS, 자바스크립트를 하나로 묶어 주는 것' 또한 중요한 기능 중의 하나가 됩니다. 소프트웨어 개발에서는 이러한 요소들을 '컴포넌트(Component)'라는 개념으로 오랜동안 사용해 왔으며 예를 들자면 백엔드에서는 이미 다양한 형태의 컴포넌트가 각 플랫폼에 적합한 형태로 오랜동안 배포되고 사용되어 왔습니다. 이제 조금 더 나아가서 우리는 컴포넌트를 웹에서 (특히 프론트엔드 개발에서) 사용할 방법이 필요하며 가능하다면 도구적인 지원을 받을 수 있으면 더 좋을 것입니다.

다행스럽게도 W3C에서는 이러한 컴포넌트 기술을 웹에서 적용할 수 있도록 새로운 규격의 집합을 만들었으며 이 규격들을 묶어 '웹 컴포넌트(Web Component)'라고 부르게 되었고 이를 지원하는 도구와 라이브러리들의 작업이 여러 곳에서 매우 빠르게 진행되고 있습니다.



웹 컴포넌트를 지탱하는 규격들


앞에서 말씀드린 바와 같이 웹 컴포넌트는 하나의 규격으로 이루어진 것은 아닙니다. 개별적인 특성을 가진 여러개의 규격으로 이루어져 있죠. 이 포스트는 웹 컴포넌트의 기술적인 내용을 목적으로 하고 있지는 않지만 어떠한 규격들로 이루어져 있는지는 살펴보도록 하겠습니다.

웹 컴포넌트는 다음과 같은 4가지의 규격으로 구성되어 있습니다.

  • Shadow DOM - 컴포넌트의 DOM, CSS, JS를 감추는 캡슐화(encapsulation)와 외부로부터의 간섭을 제어하는 스코프(Scope)의 분리를 제공
  • HTML Template - 로딩 시간에는 비활성화되는 마크업을 정의하고 이를 실행 시간에 복제할 수 있는 기능을 제공
  • Custom Element - 웹 문서에서 사용할 엘리먼트의 동적인 등록을 통해 컴포넌트의 명시적인 alias를 선언
  • HTML Imports - 웹 문서 내에 외부 리소스를 포함(Import)하기 위한 기능을 제공


각 규격에 대해 간략하게 살펴보기 전에 +Eric Bidelman이 JSCamp에서 발표했던 다음 영상을 확인해보시기 바랍니다. (발표 자료는 여기에서 확인할 수 있습니다.)

JSCamp Talk: Eric Bidelman - WebComponents are the Future


> 캡슐화와 스코프의 제어 - Shadow DOM


지금까지의 웹 개발에서 하나의 페이지는 하나의 문서를 나타내었습니다. 이들은 구조를 나타내는 마크업이나 표현을 위한 스타일, 동작에 대한 자바스크립트들이 복잡하게 얽혀있지만 브라우저는 언제나 이들을 하나의 문서로 통합하여 제어해왔습니다. 하나로 보이는 것은 언제나 중요한 일입니다만, 실제로도 하나로 다루어지기 때문에 우리가 작성하는 모듈이나 마크업들은 언제나 다른 영역과 함께 보이고 관리되며 처리되어 왔습니다.

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

Shadow DOM은 이러한 하나의 문서에서 특정한 DOM을 통해 복잡한 서브 DOM 트리를 대표할 수 있도록 만들었습니다. 이러한 개념을 우리는 캡슐화와 스코프 관점에서 바라 볼 수 있습니다.

"캡슐화(Encapsulation)은 소프트웨어 공학에서 매우 중요하게 다뤄지던 개념 중의 하나입니다. 캡슐화는 어떠한 모듈이나 기능 단위를 인터페이스만 남기고 외부로부터 완전하게 감추어주는 역할을 하며 Shadow DOM의 대표적인 장점 중의 하나이기도 합니다. 스코프(Scope)는 이러한 캡슐화 과정에서 나타나는 부산물이지만 여러가지의 모듈이 연동하는 소프트웨어에서 각 모듈의 독립적인 동작을 보장하는 매우 중요한 개념입니다. 조금 더 정확하게 얘기하자면 Shadow DOM은 스타일에 대한 캡슐화도 지원하고 있습니다."

이러한 동작들이 어떻게 이루어지는지를 이해하기 위해 +Eric Bidelman이 작성한 'Shadow DOM Visualizer'를 통해  시각적으로 확인해 볼 수 있습니다.



우리는 Shadow DOM을 이용하여 컨텐츠와 표현을 분리할 수 있습니다. Shadow DOM은 이를 이용하여 캡슐화된 DOM 트리를 HTML 문서에 활용할 수 있는 가장 기초적인 개념과 원칙을 제공합니다. 표현(Presentation)과 내용(Contents)의 분리는 하나의 웹 문서가 지나치게 복잡해지는 태그의 바다(Tag Soup)를 해결해줄 뿐만이 아니라 보다 근본적인 기능-즉, 개발된 UI 요소의 재사용을 위한 가장 기본적이고도 중요한 기능-을 제공합니다.

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


> 런타임에만 활성화되는 복제 가능한 마크업 - HTML Template


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

템플릿의 개념 역시도 웹 개발에 있어 새로운 것은 아닙니다. 서버 측에서의 템플릿 활용뿐만 아니라 클라이언트에서도 우리가 주로 사용해오던 여러가지 방법들이 이미 존재합니다. 

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

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


> 새로운 엘리먼트의 동적인 등록 - Custom Element


웹은 문서의 구조적인 형식을 가지고 있지만 HTML 엘리먼트가 미리 정의된 엘리먼트에 대해서만 사용 가능하다는 문제로 앞에서도 얘기한 현재에도 웹앱을 구축하는데 있어서는 많은 이슈를 안고 있습니다. <div>가 끝도 없이 중첩되어 나타나는 <div> Soup가 대표적인 예입니다. 이를 기본적으로 해결해주는 기능은 Shadow DOM이라고 할 수 있습니다만, Custom Element는 사실 Web Components에서 가장 중요한 기본 API입니다.

Custom Element는 HTML의 엘리먼트를 사용자가 문서에서 확장하여 사용할 수 있도록 기능을 제공하고 있습니다. 즉, 모든 웹 개발자들이 새로운 타입의 HTML element를 정의할 수 있도록 하여 본질적으로 최종 개발자들이 Web Components를 쉽게 사용하기 위한 방법들을 제공한다고 볼 수 있습니다.

Custom Element는 새로운 HTML/DOM 엘리먼트뿐만이 아니라 다른 엘리먼트를 확장한 엘리먼트를 만들 수도 있고 하나의 엘리먼트에 사용자 지정 기능을 제공하는 방법을 논리적인 형태로 정의하거나 이미 존재하는 DOM 엘리먼트의 API 기능 자체를 확장하는데 사용할 수도 있습니다. 만약 여러분께서 Shadow DOM을 이용하여 복잡한 내부 구조를 가지는  웹 컴포넌트를 개발한다고 해도 Shadow DOM을 사용하도록 정의하는 Custom Element를 정의한다면 마치 '<itemlist type="card">' 형태로 단순화하여 사용자에게 전달할 수 있다는 뜻이기도 합니다.


> 웹을 위한 #include - HTML Imports


웹에서 각기 다른 형태의 리소스들은 개별적으로 로딩을 위한 메커니즘을 가지고 있고 이를 통해 개별적인 리소스에 대해서는 지속적으로 재사용 가능한 사례를 제공하고 있습니다. 그러나 웹의 기본 리소스인 HTML, CSS, 자바스크립트에 대해서도 그렇다고 생각할 수 있을까요?

<iframe>의 경우 사용이 가능하며 실제적인 방법이지만 무겁고 세부적인 제어에 있어서는 굉장히 큰 노력을 필요로 하면서도 결국 불가능한 부분들이 있습니다. 그외에도 Ajax를 사용하거나 <script> 태그를 응용한 각종 핵(hack)이 존재합니다. 동작을 위한 정말 굉장한 노력을 필요로 하는 웹 컨텐츠(HTML/JS/CSS 등)에 대해 하나의 패키지처럼 관리하며 로딩할 수 있는 메커니즘이 있다면 어떨까요?

HTML Imports는 HTML 문서를 다른 HTML 문서들에 가져오기 위한 방법이며 CSS, JavaScript 등의 어떠한 문서 리소스도 손쉽게 가져올 수 있습니다. 다시 말해서 Shadow DOM이 형태를 정의하고 Custom Element가 엘리먼트를 손쉽게 사용할 있도록 한다면 HTML Imports는 분산되어 있는 웹 컴포넌트 리소스를 불러올 수 있는 기능을 제공합니다. 컴포넌트를 배포의 경우는 말할 필요도 없을 것입니다.



웹 컴포넌트가 왜 중요한가?


여기까지 읽어보셨다면 웹 컴포넌트가 왜 중요한지는 이미 눈치채셨을 것이라고 생각합니다. '재사용성'을 기반으로 한 개발, 배포 및 유지보수의 편의성은 개발자에게는 다른 것들과 바꾸기 힘든 가치일 것입니다. 아마 앞으로는 웹 컴포넌트를 여러분이 쉽게 사용하기 위한 많은 서비스들이 나올 수 있을 것입니다. 배포와 삽입, 사용이 쉬워졌기 때문이죠. 게다가 일부 이슈가 있기는 하지만 현재도 이를 사용할 수 있도록 해주는 폴리필 기술들은 분명 축복이라고 할 수 있습니다.



도구들


웹 컴포넌트가 새로운 기술이라면 이를 지원하기 위한 많은 도구들 역시도 쉽게 찾을 수 있습니다. 최신 브라우저에서도 웹 컴포넌트 지원은 아직 진행 중인 사항이지만 우리는 웹 컴포넌트를 위한 폴리필 라이브러리인 Polymer나 X-Tag를 이용한 Brick을 쉽게 찾을 수 있습니다. Yeoman은 빌드를 위한 Grunt, 의존성 관리를 위한 Bower, 작업 흐름을 관리하기 위한 Yo를 통합하고 있는 도구입니다. 필요하다면 이러한 도구들을 이용하여 폴리필 라이브러리부터 여러분의 개발흐름까지도 손쉽게 개선할 수 있을 것입니다.



앞으로를 예상해봅시다.


예전에 GUI 개발이 일반화되던 시절 많은 회사들과 개발자들이 앞다투어 컴포넌트를 제공했습니다. 이는 그 당시의 프레임워크나 플랫폼들이 이를 지원하는 기술적인 기반을 제공했기 때문이기도 합니다. 웹 역시도 이미 오랜동안 그러한 시도들이 있어왔습니다만 이제 좀 더 유려한 방식으로 이를 지원할 수 있게 되었습니다. 여러분이 게시판의 아이템을 확장하기 위해 태그들을 다시 수정하고 이를 검토한 뒤에 실제 프로젝트에 적용하고 테스트하는 과정은 분명히 간소화될 수 있습니다. -언제나 새로운 기술과 방법들은 버그나 문제점을 만들었지만 이는 가치에 비하면 분명 사소한 것들입니다. 게다가 우리가 경험적으로 알고 있다시피 버그와 문제점들은 언제나 개발자의 가장 친한 친구입니다! 아, 그렇다고 화내지 마세요. :)-

이제 여러분은 이미 만들어 놓은 컴포넌트를 사용하여 보다 빠르게 웹 페이지를 개발할 수도 있고 유지보수를 페이지 기반이 아니라 컴포넌트 기반으로 옮겨갈 수도 있습니다. 혹은 잘 만들어 놓은 컴포넌트를 배포하여 수익을 만들어 낼 수도 있겠죠. 이 모든 것들의 뒤에는 퀩 컴포넌트가 있습니다. 아래의 링크들을 읽어보시고 사용해보시고 적용해보세요. :)


읽어볼만한 글들


Web Component Tutorials

Improving Workflow

링크모음

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.)까지 이를 제외하면 진정한 오프라인 웹앱 솔루션은 없다고 해도 과언이 아닙니다.


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



번역 링크