Deview DAY01 Review (2 ) — 생활 속에 스며든 미래의 기술

Published in

SOPT

11 min readOct 16, 2018

DAY01 12:45–14:00 LUNCH

코엑스 그랜드불름 근처에 마땅히 점심을 먹을 곳이 없어, 아침에 나눠준 칼로리바를 먹으며 행사장을 배회했습니다. 각 곳에서 부스를 열고 매 시간마다 선착순으로 굿즈를 배부하더라구요. 이렇게 중요한 때에 밥을 먹으러 가질 않는 게 다행이라고 생각하며 냉큼 저 역시 저 인파 속에 뛰어들었죠. 덕분에 수많은 굿즈를 모아올 수 있었답니다.

그렇게, 짧은 휴식 후 오후 발표 세션이 시작되었습니다.

DAY01 14:00–14:45 JavaScript 배틀그라운드로부터 살아남기 박재성 / NAVER / PaaS

많은 사람들에게 배틀그라운드를 JS로 코딩하는 걸 알려주는 건가 생각하게 했던 발표 제목

오늘날의 자바스크립트는 많은 개발자들에게 사랑을 받은 언어입니다. 저 역시도 자바스크립트 베이스 프레임워크를 공부하는 입장에서, 해당 발표 세션을 흥미롭게 듣고 왔습니다.

자바스크립트는 현재 어디까지 왔고, 어디로 나아갈 것인가? 빠르게 변화하는 자바스크립트를 배워 살아남기 위해서 개발자는 어떤 행동지침을 가지고 움직여야하는가?

그 의문점을 NAVER의 박재성 개발자께서 45분이라는 짧은 시간 속에서 정말 알차게 풀어주셨습니다.

웹의 비전

정적, DOM 인터렉션을 통해 다이나믹해지자!
-> 1995년, 자바스크립트 등장
-> 1996년, 표준화 진행을 위해 ECMA 이름 선택
-> ajax 등장, 자바스크립트 : 프론트엔드의 key 역할

현재의 자바스크립트 = / = 자바스크립트

why? 오늘날의 자바스크립트, 바닐라로 개발하는 경우가 드물다
프레임워크 + toolchains로 개발이 진행되는 게 일반적
대다수의기능들 : npm 패키지를 적당히 조립하여 사용됨

2018년도 자바스크립트의 동향

버전 구분의 중요성 ↓
es8 -async / await 추가
webassembly, 주요 브라우저 및 node.js에서 지원
모호한 타입 시스템, typescript와 만남 -> 버그 ↓ 코드를 더욱 효율적으로 작성하는 게 가능해짐

이런 자바스크립트에서 생존하기 위해선?

자바스크립트는 쉽지 않다. 많은 가이드에서 나온 대로 몇 가지 설정 / 설치를 거치면 쉬워지는 언어가 아니다.
수많은 플러그인을 직접 접해보면 쉽지 않다는 사실을 알 수 있음

본격적인 생존법

첫 번째, 자바스크립트의 트렌드를 제 때 확인하라
두 번째, 브라우저 업데이트를 확인하라
세 번째, 다른 사람들에 대한 생각을 끊임없이 확인하라
네 번째, 컨퍼런스에 가라! 못가면 공개된 스케쥴을 살펴보는 것으로 대신해라. 현재의 흐름을 파악할 수 있다.

박재상 개발자는, 우리 개발자들이 기존에 문제 없이 사용하던 기술을 뒤로한 채 ‘새롭고 반짝’이는 것들에 너무 관심을 쉽게 빼앗긴다고 말합니다.

그러나 무엇을 사용하던 간에 그 근간은 자바스크립트라고, 너무 많은 것을 알려고 하지 않아도 좋다고 합니다.

그저 우리에게 필요한 건 적당한 ‘호기심’ 과 ‘지속적’인 꾸준함일 뿐이라고.

듣고보니 저를 포함한 개발자들에게 와닿는 말 같았습니다.

저 역시도 새로운 기술이 나오면 흥미를 가지고, 이전의 기술엔 약간 마음이 식어버립니다. 돌이켜보면 제일 중요한 건 가장 기본이 되는 언어였던 때가 많았으니까요.

그러한 과거의 잘못이 DEVIEW에 와서도 지적이 되니, 정말 감명이 깊습니다.

스스로를 반성하고 나아가는 계기로 다가오는 발표였습니다.

DAY01 15:00–15:45 네이버에서 사용되는 여러가지 Data Platform, 그리고 MongoDB 이덕현 / NAVER Business Platform / Data Platform

MongoDB는 최근 몇 년 전부터 많이 사용되고 있는 데이터베이스 소프트웨어입니다. 대다수의 사람들은, 프로토타입을 만들기 편하다고 해당 DBMS를 사용합니다. 그렇다고 쉬이 그냥 사용할 것이 아니고, MongoDB 역시 다른 DBMS처럼 신경써야할 게 많다고 합니다.

해당 발표 세션에선 네이버의 데이터 플랫폼에 대한 이야기와, 네이버에서 MongoDB를 사용하는 이유, 그에 따른 에피소드와 MongoDB의 장단점 및 희망에 대한 이야기가 나왔습니다.

네이버에서의 데이터 플랫폼

초창기 거의 모든 서비스, [ 웹서버 <-> RDBMS 서버 ] 2tier 구조

시간이 지나면서 서비스는 점점 커지고, DB query는 점점 복잡해짐

빠른 응답을 보장받기 위해 DB 앞에 캐쉬 추가

그러나, 지표를 저장하려고 하니 RDBMS 사용 공간과 비용 문제 발생

원활한 데이터 처리를 위해 HBase를 사용하고 있음

MongoDB가 네이버에서 어떤 경우 대안이 되고 있는가?

네이버, Schemaless 데이터 플랫폼 必

sharding, secondary index, transaction 처리까지도 가능하게!

∴ MongoDB 사용

스키마리스

사전에 데이터에 대한 구조 or 정의를 하지 않아도 됨
서비스의 종류 ↑ -> 공통 부분을 플랫폼 화
그러나, 성능이나 안정적 측면에서 MongoDB는 좋은 선택은 아니었음
RDBMS 1row 당 17 byte
NoSQL(MongoDB) 1document 당 46byte(_id 포함 시 58byte)
그럼에도 불구하고 왜?
수백 개 이상의 서비스 각각마다 공통부분 多 (중복 기술)
해당 중복 서비스를 공통 플랫폼 개발팀에서 만들고 각각의 팀에서 해당 기술을 가져가 쓰는 방식으로 진행

sharding

서비스의 규모가 커지면서 데이터 사이즈 증가 -> scale up에 대한 한계 봉착
RDBMS, 응용에서 sharding으로 scale out을 구현할 수 있지만 확장성 ↓ & 개발 및 관리의 overhead 발생

secondary index

HBase, 제품 자체에서 secondary index 제공 X

json 지원

rest api 사용 확대 -> 웹서버와 DB서버 간 데이터 통신 과정에서 json 선호

idc dr

서비스가 커지고, 중요도가 높아짐에 따라 IDC 이중화가 요구됨
MongoDB는 IDC 간 auto failover가 가능한 data platform

MongoDB의 장단점, 희망

MongoDB, NoSql과 RDBMS의 특징(장단점)을 고루 가지고 있는 DBMS

잘 사용해야 함

성능과 안정성

체크포인트 등 일부 성능상 문제점 해결이 시급하다
mongoose, shard 사이의 커넥션 안정화 필요

전망

우리나라에서 메인스트림으로 도입될 가능성은 높지 않다고 보여짐
그러나 사용처가 줄어드는 것은 아니고, 점차 확대될 것

DAY01 16:00–16:45 웹 성능 최적화에 필요한 브라우저의 모든 것 이형욱 / NAVER / Whale

NAVER whale 브라우저 소속 이형욱 개발자님께선 멀티 프로세스 기반의 최신 웹브라우저(웨일, 크롬, 오페라 등)에서 웹 콘텐츠를 어떻게 처리하여 화면에 렌더링 하는지에 대한 동작 원리에 대한 설명과, 이를 바탕으로 한 웹 성능 최적화 기법을 소개합니다.

웹 콘텐츠 (HTML, CSS, JS)는 브라우저에서 처리되어 화면에 렌더링됩니다. 그래서 브라우저 내부 동작 원리를 이해하지 못하면 일정 수준 이상의 성능 최적화가 어렵고, 왜 이런 문제가 발생하는지 이해하기도 쉽지 않습니다. 그렇기 때문에 내부 동작 원리를 이해하여 웹 성능을 최적화하는 데에 힘을 써야 합니다.

Summary of browsers main flows

HTMP Parser — HTML 문서를 파싱하여 DOM Tree를 만드는 과정

DOM : Document Object Model

Document : HTML, well-formed XML

Object Model : Data + Method

Recalculate Style : 파싱된 css 결과(cssom)를 렌더 트리에 적용하는 과정

html은 단순 문서, 각 엘리멘트들의 렌더링에 관한 모든 정보는 css가 가지고 있음
css parsing 과정은 dev tools에 따로 표시되진 않음
cssom : css object model
dom 과 비슷하게 트리의 형태로 구성됨
외부 링크로 정의된 경우 렌더링이 블로킹됨
cascade down 개념을 구현하기 위해 트리구조

render tree

recaculate style의 결과
render tree = dom tree + cssom tree
dom tree 와 render tree는 1:1 관계가 아님
화면에 보이는 요소들을 중심으로 구성
render tree에 웹 퍼포먼스가 없는 이유? : 화면에 보일 필요가 없는 건 렌더러 트리를 만들지 않아도 되기 때문에

layout

render tree 노드들의 좌표를 계산하는 과정
박스의 크기와 위치를 계산하는 과정
global and incremental layout
CSS 2.1 box model, visual formatting model 을 기반

layout 알고리즘

각 박스의 넓이는 viewport 기준(ICB)
각 박스의 높이는 contents 기준(폰트 사이즈)
윈도우 사이즈를 변경 하거나 폰트 변경 시 global layout 발생
dirty bit system으로 incremental layout

block : 아래위로만 쌓을 수 있음 / inline : 옆으로만 쌓을 수 있음

대부분의 html 태그들은 block 타입
그 외에 이미지와 같은 요소들은 inline 타입임

paint : 프린트처럼 한픽셀 한픽셀 그려내기 때문에 굉장히 렌더링이 느림

new version of browser’s main flow

js -> recal style -> layout -> (new) update layer tree -> paint -> (new) composite

js로 퉁치는 이유 : 페이지 로딩이 중심, 그러나 요즘엔 로딩 이후의 과정이 좀 더 중요함
앞쪽은 전부 생략하고 js를 시작 기준으로 보고 있음

렌더 트리를 만드는 과정 recal style

update layer tree : 레이어링 관련된 이야기. 브라우저, 한 장의 비트맵으로 레이아웃을 처리하지 않고 포토샵 레이어처럼 여러 겹으로 레이아웃을 처리한다. -> 렌더링에 사용될 최종 layer들을 계산해서 최종 종합하여 사용하는 과정

composite : 합성 . 레이어들을 합성하여 한 장의 비트맵으로 만드는 과정, 각 레이어별로 paint, tiled backing store 기법을 사용함

Rendering pipeline stage costs

전체 파이프라인 중에서 어디를 수정하는 것인지를 아는 게 중요

Layout : width, height, font …
Paint : color, background …
Composite : opacity, transform …

Pipeline Stage Costs : Layout

대략 1000개 정도의 DOM Elements 가 효율적
애니메이션은 transform 이나 web animations

Pipeline Stage Costs : Paint

GPU Rasterization 을 사용 -> 10배 정도 빨라짐
<meta name=”viewport” content=”width=devide-width, minimum-scale=1.0">

Pipeline Stage Costs : Composite

Layer ↑ -> 메모리 사용량 ↑, 속도 slow
대략 30개 정도의 layer가 효율적

그리고…

<SYSTEM : ‘Yujeong Noh’ 님께서 굿즈를 습득하셨습니다!>

10초만에 티켓팅이 마감된 이유를 알 수 있었습니다.

국내 최대 규모의 개발자 컨퍼런스란 위엄이 사그라지지 않고, NAVER는 DEVIEW 2018 DAY01을 성공적으로 마무리 지었습니다.

참가하여 세션을 즐긴 성장하는 개발자로써, 다양한 기술들이 NAVER 등지에서 어떻게 활용되는 지를 배울 수 있는 좋은 기회였습니다.

또한, 개발에 한정되지 않고 UI/UX와 Database와 같은 다양한 분야의 세션을 들을 수 있는 기회가 마련되어서 피로함은 있어도 지루함은 없이 컨퍼런스를 즐길 수 있었던 것 같습니다.

다음엔 다른 글로 찾아뵙도록 하며, 이만 DEVIEW 2018 DAY01 Review 포스팅을 마치도록 하겠습니다.