[W3C] HTML5 Conference 2019 후기

참가비 만원에 커피+점심+경품추첨까지 있던 가성비가 엄청났던 컨퍼런스!

13 min readOct 13, 2019

웹 개발자에게 관심있을 법한 주제를 잘 모은 컨퍼런스였다고 생각했습니다. 참가비 만원으로 이 세션들과 점심(코엑스 푸드코트)과 음료 한 잔을 할 수 있다니.. 그리고 당첨운은 없었지만 경품추첨의 기회도 있고.. 가성비가 엄청난 행사였습니다. 👍

여러 세션이 있었지만 저는 요 세션들을 들었습니다.

- 오전세션들
- React/Vue에서 이젠 SVELTE - 변규현/당근마켓
- React Native 성능개선(Redux, MobX, Context API 비교 적용 후기) - 김나람/스튜디오 그로테스큐
- Vue.js 입문자가 실무에서 주의해야 할 5가지 실수 - 장기표/KossLab
- 웹 개발자들이 SEO를 위해 알아두어야 할 구조화 데이터 - 김건오/트윈워드
- 웹성능 최적화를 위해 필요한 웹 브라우저의 모든 것 - 이형욱/네이버

Move the Web Forward(김효, Naver)

기조연설2. Move the Web Forward라는 주제로 Naver 김효 개발자님의 세션

중간중간 재미있는 농담을 섞어서 얘기하셔서 재밌는 세션이었습니다.

광고차단(클린앱) 기능이 있는 웨일브라우저

네이버에서는 10~20대를 잡기 위한 서비스를 고민하고 있는데, 이 고민을 30~40대가 고민하고 있고, 이걸 50대에게 승인받는 프로세스를 가지고 있습니다 🤣
네이버는 검색광고의 매출이 높은 포션을 차지하고 있는 회사인데, 그런 회사가 만드는 브라우저(Whale 웨일)에 광고차단을 넣어달라는 요청을 받고 있는 상황입니다 😂

네이버가 광고 매출이 상당히 높은 회사일 것임에도, 광고 차단에 대한 고민을 했다는 것이 인상 깊었습니다. 네이버는 Better Ads에 최근에 가입했고, 볼 수 있을만한 광고가 있는 사이트가 노출될 수 있도록 필터링 방법도 많은 고민을 했다고 합니다. (👉Better Ads에 대해 알아보기)

최근에는 Element Hiding과 Re-layout에 대한 고민을 하고 있다고 합니다. 필터링 기능으로 광고 데이터 요청은 막았는데, 그 광고자리가 뻥 뚫린(하얀색 빈공간)이 되버리다보니 다시 레이아웃을 재배치하도록 하는 것을 고려중이라고 합니다.

오픈소스의 무게, Rebase

네이버는 많은 개발자가 근무하고 있다보니, 각자가 작업한 것을 모으는 과정이 쉽지 않을 수 있겠다는 생각이 들었습니다.

제품 품질을 올리는 가장 효과적인 방법으로는 빠른 코드 리베이스(code rebase)가 필요하다고 생각을 했고, 몇 년에 걸쳐 리베이스 장인을 한 명 길러서 그 한 명이 리베이스를 전담하고 있다고 합니다. (누구실지, 어떤 성격일지 진짜 궁금)

phase1,2,3 이렇게 진행될 때마다 리베이스 장인의 리베이스 + 각 모듈 담당자들이 리팩토링으로 인해 점차 rebase 기간도 줄어들고 있고, bugs의 양도 줄었다고 합니다. rebase기간이 줄었는데 버그의 양은 줄어들었다는 것은 그만큼 구성원들의 손발이 척척 맞고, 코드 퀄리티가 올라갔다는 뜻일 것 같습니다. (phase 2가 시작되면 hotfix를 제외하고는 더 이상의 이전 버전의 release는 진행하지 않는다고 합니다.)

가장 인상 깊었던 것은 업무를 할 때에 기획/디자인은 미리 준비되어 있는 상태이고, 개발자가 rebase 주기에 맞춰서 선택할 수 있도록 한다는 점이었습니다. 그리고 회고에서 “이번에는 별로 할 말이 없어요”라고 하고 끝내는 것이 팀의 목표라고 합니다 😏

Whale 데스크탑 2.0 / 모바일 1.0 예정

Deview 2019에서 공식적으로 발표할 거라고 하던데, 데스크탑 웨일 브라우저가 이제 2.0으로 버전 업을 한다는 소식을 전해주셨습니다. 모바일은 1.0으로 정식 버전으로 릴리즈 된다고 합니다.

앱과 웹의 경계를 줄이려는 시도를 진행하고 있다고 했고, 데스크탑 브라우저의 경계를 넘을 수 있도록 인스턴트 사이드 패널, 웹앱, 사이드바 확장앱 같은 기능을 넣었다고 합니다.

LG V50s 듀얼 스크린 폰에서 웨일이 기본 브라우저로 탑재될 예정이라는데, 더블터치, 싱글터치에 따라서 듀얼 스크린을 최대한 이용할 수 있는 인터페이스를 구상하셨다고 합니다.

REACT/VUEW에서 이젠 SVELTE(변규현, 당근마켓)

새로운 라이브러리를 알게 됐습니다. Svelte(스벨트)는 리액트/뷰에 비해서 적은 코드를 쓰고 virtual dom을 사용하지 않는다고 합니다. 예시로 설명해주신 문법들이 어렵지 않았습니다. 리액트/뷰에 대해서 모르는 사람도 20–30분 정도 문서 보고 따라하면 스벨트를 사용할 수 있을 것 같다고 생각됐습니다.

이번 JS Conf에서 사용되었던 샘플을 가지고 리액트/Svelte일 때 메모리 사용량을 비교해서 보여주셨는데, 압도적으로 스벨트의 메모리사용량이 적었습니다. 간단한 기능이어도 리액트는 약간의 버벅임도 있었고요.

개인적으로 리액트를 공부하면 할 수록 리액트는 유용한 라이브러리라고는 생각하지만, 초보자가 배우기 어렵고, 자바스크립트에 대한 이해와 더불어서 리액트만이 가지고 있는 어떤 것들을 따로 공부해야한다는 점이 아쉬웠는데, 이 점을 얘기해주셔서 좋았습니다 ㅋㅋ 그래서 지금 당장은 아니어도 언젠가 간단한 기능이나 사이드 프로젝트는 Svelte로 해보는 것도 나쁘지 않겠구나!라는 생각을 갖게 됐습니다 ㅎㅎ

스벨트의 특징으로 언급해주셨던 것 중에서 몇 가지를 적어보자면…

스벨트도 리액트/뷰처럼 컴포넌트화해서 개발할 수 있다.
No Virtual DOM이다. 복잡한 컴포넌트 작업에서는 리액트가 빛을 발휘하지만, 간단한 기능에서는 리액트는 너무 무거운 라이브러리이다. Virtual DOM은 항상 빠른 것이 아니다. 매뉴얼로 돔을 조작하는 것보다 빠른 것이고, 컴포넌트 트리를 탐색하면서 진짜 변경된 것이 있다면 업데이트를 하는데, diffing이 생각보다 시간이 많이 걸리기 때문에 virtual dom은 느리다. 리액트/뷰는 원하는 성능을 구현하기 위해서는 virtual dom을 사용했어야만 했지만, 스벨트는 Virtual dom이 없다. 없어도 된다.
리액트나 뷰는 탑레벨 컴포넌트(<React.Fragment />, <>, <template /> 등)가 있어야하지만, 스벨트는 없어도 된다.
스벨트는 빌드타임에 run이 된다. 에러를 빌드타임에 잡을 수 있다. JS에서는 빌드타임에서 잡지 못하는 버그들이 있다보니 타입스크립트를 쓰기도 한다.
메모리 사용량이 적다. 리액트가 보통 100MB를 쓰는데, 스벨트는 8~20MB정도를 사용한다.
문법이 쉽다.

그런데, 당근마켓은 스벨트를 쓰고 계시나요? 🤨

React Native 성능 개선(Redux, MobX, Context API 비교 적용 후기) (김나람, 스튜디오 그로테스큐)

👉 Github: https://github.com/grotesq/context-q

이런 경험에 의한 세션을 들을 수 있는 게 컨퍼런스의 가장 큰 장점인 것 같습니다.

스튜디오 그로테스큐에서는 기존에 MobX를 도입했다가 앱에서 사진을 불러올 때 state들이 force update되는 점을 발견하고 현재는 Context API를 사용하고 있다고 합니다. 최종적으로 렌더횟수가 60%가 감소되어 상당한 성능개선을 하셨다고 합니다.

병아리 개발자인 저는 한 세션에서 Redux, MobX, Context API를 비교하면서 볼 수 있다는 점이 좋았고, 처음 알게 된 것들도 있었습니다. MobX가 급진적인 정책(예를 들면 IE에 대한 지원을 중단했다는 것)을 갖고 있다는 것도 처음 알았고, context API는 미들웨어를 직접 구현해서 처리해야한다는 것도 처음 알았거든요!

Redux가 무겁다는 점 빼고는 다른 단점이 없지만, 본인 회사에서는 Context API를 쓰신다고 했다 ㅎㅎ

Vue.js 입문자가 실무에서 주의해야하는 5가지 (장기효, KossLab)

사실 뷰/리액트에 국한된 이야기는 아니었고, SPA 입문자가 실무에서 주의해야하는 사항이라고 봐도 무방했던 것 같다!

👉 Github 예제: https://github.com/joshua1988/vue-five-common-mistakes

주의해야할 5가지 요약

반응성을 이해해야함(this.$set)
DOM 조작은 Native JavaScript처럼 하면 안됨
인스턴트 라이프 사이클(생애주기)에 대한 이해
Mounted가 된 후에 ref속성으로 DOM에 접근하자
computed 속성을 적절히 활용하자

시간이 없어서 진짜 엄청난 속도로 랩을 하면서 설명하셨지만, 핵심은 잘 전달된 세션이었던 것 같습니다. 특히 요 세션은 저희 회사 서버 개발자분들과 공유하고 싶었습니다 :)

어드민은 프론트엔드 개발자가 손대지 않고, 서버 개발자분들이 직접 작업하는데 예전에는 jQuery나 django 어드민을 이용해서 만드셨다면, 요즘에는 기능이 점점 많아지면서 Vue.js로 시도를 하고 계시는 것 같더라고요!

특히 리액트든 뷰든 그 라이프 사이클의 특성을 알고 DOM이든 state든 접근하는 방식이 중요하다고 생각합니다. 저도 직접적으로 DOM에 접근했다가 코드리뷰할 때 코멘트를 받기도 했어요! ㅋㅋㅋㅋ 지금은 ref를 이용하고 있습니다.

SEO 관련 (2개의 세션은 정말 유익했어요!)

다노샵이라는 e-commerce 서비스의 프론트엔드 개발자로서 SEO는 제가 진행해야하는 숙제들 중 하나입니다.

웹 개발자가 SEO를 위해 알아두어야 할 구조화 데이터(김건오, 트윈워드)

이 세션은 군더더기 없이 필요한 정보를 어디서 찾아야할지를 요약정리해주는 느낌이었습니다! :) 굿굿.

검색을 하고 난 다음에 사람들이 어떤 행동을 하는가? 검색하지만 아무 것도 안하는 사람이 많기 때문에, 41%를 잡기 위해서는 검색결과 첫 페이지에 우리 사이트가 올라가야합니다.
- 4%: 광고를 클릭한다.
- 41%: organic search 결과를 클릭한다.
- 나머지: 아무 것도 안한다.
구조화 데이터
- 구글에서 구조화 데이터라고 치면 여러 정보가 나온다.
- 구글 리치 스니펫 테스트, 구조화 데이터 생성도구 툴을 이용한다.
- 구조화된 데이터 작동에 관련된 문서를 참고한다(👉 문서)

웹성능 최적화에 필요한 브라우저의 모든 것(이형욱, 네이버)

사진찍거나 필기한 양이 압도적으로 많았던 세션이었습니다. 대학교 수업듣는 느낌이었는데, 나쁘다는 뜻이 아니고 기본이 부족한 저에게 이론을 공부할 수 있는 재밌는 시간이었습니다 😀

브라우저가 내가 보는 html 문서를 보여주기까지의 과정을 속사포 랩으로 설명해주셨습니다. (마지막 세션이라서 시간이 많지 않다보니 2시간 정도 분량의 세션인데, 1시간도 안되서 끝냈던 것 같습니다..)

브라우저는 어떻게 동작하는지

웹성능을 최적화하려면 어디가 느린지 이해해야한다. 어디가 느린지 보려면 디버깅을 할 때 퍼포먼스 쪽을 봐야하는데, 보통 network는 좀 알아도 main이나 raster, gpu, compositor는 뭔지 모르는 경우가 많아서 이 부분을 이해하는 것이 최적화를 하는데 도움이 된다.
브라우저는 DOM tree + CSSOM을 합쳐서 render tree를 만들어서 layout을 하고, paint하는 과정을 거친다.
전체적으로는 Js parsing > Recalc stlye > layout > update LayerTree > paint > composite하는 과정이다.

어떻게 화면을 렌더링하는지

Vsync라는 것을 설명해주셨습니다.(어렵다) 🧐
Vsync를 사용하게 되면 렌더링을 잘 할 수 있게 되고, 오버워킹을 안해도 된다.
위에 쓴 전체 과정을 Main thread에서만 처리할 경우 16.6ms안에 처리하지 못한다. 브라우저는 메인 쓰레드에서만 돌아간다. 기본적으로 싱글 쓰레드이다.
compositor thread로 시간을 줄일 수 있다. 메인 쓰레드에서 합성(composite)하는 과정을 뗀다. 합성 과정은 생각보다 가벼워서 빠르다.

어떻게 하면 웹서비스의 성능을 높일 수 있는지

최근 브라우저들은 멀티 프로세스 구조이다. 사용자 인풋을 먼저 처리하고, 그 다음에 vsnyc를 받아서 렌더링 하는 방식으로 되어 있다.
브라우저가 항상 바쁘게 일하는 것은 아니고 살짝 여유 있을 때도 있다. 그럴 때는 Idle GC task, Idle cllback task를 처리하는데, whale의 경우 Whale://tracing으로 볼 수 있다. 이런 툴은 개발자 도구를 봐도 어디를 최적화해야하는지 잘 모르겠을 때 보면 된다.

성능 최적화할 수 있는 팁들

JS > Layout > Paint > Composite 하는 파이프라인(단계)에서 어디를 수정해야하는지 아는 것이 중요하다. 보통 마지막 단계(composite) 쪽을 손대는 것이 최적화할 때 가성비가 가장 좋다.
- layout : width, height, font, …
- paint : color, background, …
- composite : opacity, transform, …
애니메이션은 transform이나 web animation을 사용하는 것이 좋다. 브라우저가 제공하는 걸 이용하면 최적화에 도움이 된다.
meta태그에 <meta name="vieport" … /> 이런 태그를 넣는 것이 좋다.
composite을 많이 쓰면 성능이 좋아지긴 하는데, 너무 많이 쓰면 비효율적이다. 레이어가 많아지면 메모리를 많이 사용하고 더 느려질 수 있기 때문이다. 대략 30개 정도의 layer가 효율적이다.