DEVIEW 2018 1일차 후기

이번에 네이버에서 진행하는 DEVIEW 2018 ~ !

2017년도에서 매우 좋은 기억으로 들었고, 세션들이 유익하여서 잘 들었던 찰나에

DEVIEW 2018 에 당첨이 되어서,  1일차인 웹 세션들이 많아 해당 세션들을 들으러 갔습니다 .

2

DEVIEW 입장권을 받고, DEVIEW 세션들을 들을 수 있는 장소와,

복도에서는 작년처럼 사람이 앉을 수 있는 휴식 공간까지 마련되어 있었습니다.

1. 외부 부스

3

4

이번 DEVIEW 외부 부스들은, DEVIEW 2017과는 다르게 주로 네이버의 서비스들이 대부분의 부스였습니다.

네이버 서비스들이 각각 현재 어떤 방향으로 진행이 되는지, 곧 나올 서비스는 어떤지에 대해 직접 체험하는 부스 또한 존재하였습니다.  생각하지 못한 네이버 서비스들도 존재하였고, 이를 알 수 있어서 좋았습니다. 다만 작년보다는 여러기업이 오지 않아서 우리가 알지 못하는 기업들에 대해 알 수 있는 기회는 그만큼 적었기에 아쉬움과 좋음 모두 공존하였습니다.

2.  React Native: 웹 개발자가 한 달 만에 앱 출시하기 - 이성민

6

첫 발표는 SNOW 개발자신 이성민님의 React-Native에 대한 세션이었습니다.

1.React-Native 선택의 이유

  • FaceBook , Instargam 등에서 안드로이드 개발을 시작
  • 개발자가 없기 때문에 React- Native 시작 => 2배 이상의 개발 효율
  • Cake APP 또한 앱 개발자 1명이 안드로이드, IOS 개발 기간 1달 소요
  • 개발 리소스가 적음 =>  리소스가 적기 때문에 빠르고 코드 공유가 쉬우며 개선 또한 쉽다.

2. React-Native 완벽한 이해

  • React Native는 React 기반 위에서 Bridge를 이용한 개발
  • Thread 구조
    • 각 Thread는 독립적으로 실행
    • Bridge를 통해서만 연결 가능 -> Thread 간의 간섭을 통해 효율이 낮아지는 것을 방지하기 위함
  • Bridge 특징 (1) : 비동기 호출
    • 기존 코드가 실행되면서 Native 공유 코드 실행 -> 끝나면 콜백
  • Bridge 특징 (2) : Native 호출시 직렬화 및 Callback 역직렬화
    • 직렬화 ( JSON 방식 ) , 역직렬화 많을시 보안 이슈 있음 -> 일괄 처리를 통해 개선 가능
  • MessageQueue를 이용해 쉽게 로그 확인 가능
    • Javascript Core 동작 오류 확인 가능
  • React Native 호출시 내부에서 실행되는 예시 코드 설명
    • fetch(), Message, Network 코드 및 설명

3. Cake 프로젝트에 얻는 노하우 & 팁

  • CRNA 미사용 추천 -> 빌드 방식으로 Native 시작할 것
  • IOS가 안드로이드보다 성능이 좋으므로, 중간에 안드로이드에서 확인할 것
    • 완벽한 코드면 차이가 없다지만.. ( 가능할까요 ㅠㅠ )
  • Import시에 발생하는 ../../ 경로를 babel-plugin을 통해 탈출 가능
  • 0.56 Version 부터 && 대신 ? 를 통해 Null Safety 가능
  • Version은 고정 버전 미작성시 수시로 업데이트 되며 버그 발생 우려 있음 -> 고정 버전 작성할 것
  • Flow를 사용하면 파라미터 타입 오류 감지 가능
  • Javascript Packager 동작 방식 설명 -> 크기 설정 필요
    • SDWebImage (IOS) / Glide(Android) 사용을 통해 해결 가능
  • Android 의 오래된 엔진 떄문에 Date 처리 문제가 있어 Date만 따로 분리하거나, moment.js 사용할 것 ( ex) 국제화 함수 )
  • 플랫폼 별 재정의 컴포넌트 스타일링 필요
  • Atom-react-native-style 통해 Style 자동완성 가능
  • Android Text 패딩은 IOS와 유사하게 맞추기
  • 우리의 손가락이 크기 때문에 44dp의 터치 영역 보장 필요
  • React-Native는 IOS, Android, Xcode에서 해당되는 개발자 도구를 사용할 수 있습니다.
  • 높이가 고정된 Layout은 getItemLayout을 사용하여 매번 계산하는 것을 방지합니다.
  • 레퍼런스 사용은 React.createRef()를 통해 Ref 객체를 만들고 레퍼런스 할당을 통해 사용합니다.
  • React-Native라고 앱 크기가 무조건 크지 않음
  • 네비게이션 모듈은 React-native-navigation 2.0이 나오기 전까지는 react-navigation ( JS 구현체 ) 를 사용하는 것이 좋다.

2 - 1 . 생각하는 요점과 소감평

요점 : React-Native는 웹을 이해하고 잘 활용하시는 분들이라면 짧은 기간에 App을 개발할 수 있다.  또한 React-Native로 App을 잘 개발하기 위해서는 개발자의 역량이 제일 중요하다.

소감평 : React - Native의 튜토리얼을 알려주시는 듯한 느낌이 들었습니다. React - Native를 시작하시는 분들에게 매우 유용할 것 같고, 해당 코드 스타일 및 내부 작동 원리까지 파악할 수 있었습니다.

3. 책에서는 맛볼 수 없는 HTML5 Canvas 이야기 - 방진호

7

두번째 세션은 삼성전자 개발자신 방진호님의 세션이었습니다.

1. Canvas의 역사

  • Canvas는 2004년 Apple의 확장 기능으로 시작
  • 점차 Mozila, Opera 에서 구현 시작
  • 현재는 30% 사이트에서 사용하고 있음

2. Broswer는 어떻게 그림을 그리나?

  • Rendering Engine + Javascript Engine + Graphics Library ( Skia ) 의 3가지 모듈이 서로 연계하여 그림
  • Rendering Engine을 통해 어떤 모양,  어떤 위치, 어떤 크기, 어떤 순서로 그릴지를 결정
    • Parsing DOM, Parsing CSS,  Layouting, Layerization
    • 렌더링 엔진을 통해 트리 구조의 자료구조 산출
    • 즉, 자료구조 안에 브라우저를 그리는 방법을 Rendering Engine이 담고 있다.

3. Canvas는 어떻게 그림을 그리나?

  • Canvas도 HTML Element임
  • Canvas도 유사한 과정으로 그림이 그려지나 , 내부는 비어있음
    • 내부는 개발자의 손에 따라 달림
  • Rendering Engine은 JS를 해석하지 못함
    • Rendering Engine은 Javascript Engine에게 JS 해석 요청
    • Javascript Engine은 Rendering Engine에게 해석 후 전달
    • Rendering Engine은 SKia ( Graphics Library ) 에게 요청하여 Canvas를 그림

4.  Canvas Animation의 문제점

  • 16.7ms 안에 Canvas 코드가 실행되고 한 프레임을 그려야함
    • Javascript, Rendering, Graphics Library가 동시에 실행
    • Size가 커지면 Main Thread가 하는 일이 많이 16.7 ms  안에 불가능
    • 그럼 어떻게 해결하느냐?

5.  기존의 Canvas Animation의 개선

  •  DOM은 main Thread가 건드림 -> 개선 불가
  • Painting을 다른 Raster Thread 가 그림
    • Canvas를 그릴때는 GPU에게 그리라고 함 -> 성능이 좋아질수 있다?
    • => 실제로는 Binding Overhead 발생
  • GPU 가속을 했을때 DOM을 덜 쓰므로 성능이 좋아 질 수 있다
    • => GPU 가속을 하여도 Skia 내부 Overhead 발생
  • BackGround Canvas를 하나 더 만들어 Copy를 통한 Canvas 그리기
    • => 실제로는 Dom Rendering으로도 Main Thread는 벅참
  • 즉, 현재는 모두 사용하지 않아도 됨.

6. 새로운 API - Offscreen Canvas

  •  우리는 다른 Thread를 통해 Canvas를 그리고 싶음
    • Offscreen Canvas를 통해 work thread에서 새롭게 수행할 수 있다.
    • 현재 Chrome 69 Stable 부터 Chrome은 사용중
  • Offscreen Canvas를 사용하면 WorkerThread를 사용하여 Canvas를 16.7ms 내에 그릴수 있다 !

7. How To USE Offscreen Canvas

  • Main Thread에서 해야할 일
    • Canvas를 document.getElementByid를 통해 가져옴
    • Offscreen을 transferControlToOffScreen()을 통해 가져옴
    • Worker Thread 객체 생성 후 Offscreen Canvas 전달
  • Worker Thread에서 해야할 일
    • MessageHandler 생성
    • OffscreenCanvas 전달 받음
    • CanvasRendering Context 생성
    • -> 이후 과정은 Main Thread에서 Canvas를 그리는 과정과 동일함

8. Case Study

  • Case 1  : Three.js Offscreen Canvas 사용
    • Three.js에서 OffsecreenCanvas 사용 - > Texture 생성
  • Case 1 의 경우 대부분 이상이 없음.
    • 그러나 OffscreenCanvas는 Style Property가 미존재
    • 개발자 도구 확인시 오류 발견할 수 있음.
    • 이에 따라 Style 값을 width : 0, height : 0이라도 지정할 것
    • 이를 통해 해결 가능
  • Case 2: Zero-copy Background Rendering 문제
    • drawimage()를 통해 개선하려고 하지만 Worker Thread에서 그릴 수 없고, Image 복사 발생
    • BackCanvas 에서 사용시 이미지를 언제 보여줄지 몰라 미리 Image 복사를 하는 것임
  • OffscreenCanvas는 직접 생성하여 그림을 그리고 , TransferToImageBitMap을 사용하여 복사함
  • Case 3: 멀티뷰의 경우 WebGL이 되지 않아 여러개의 Canvas를 그려야 하나 OffscreenCanvas의Background 방식을 통해 해결 가능

3 - 1 . 생각하는 요점과 소감평

요점 : HTML Canvas의 역사 또한 설명해주며, 16.7 ms안에 한 프레임을 그리기 위해 여러가지 개선 방법이 있었으며, 현재는 Offscreencanvas를 통해 Canvas를 그리는 속도를 개선할 수 있습니다.

소감평 : HTML5 Canvas 태그를 단순히 그리는 용도로 잠깐 사용했던 저에게, Canvas를 그릴 때 어떤 이슈가 있고, 현재 Offscreen Canvas를 통해 여러가지 이슈를 어떻게 해결했는지에 대해 설명을 들을 수 있었습니다.

4.LINE x NAVER 개발 보안 취약점 이야기- 허규 , 이명재

8

세번째 세션은 이명재 라인 개발자님과 허규 네이버 개발자님의 두분 공동 세션이었습니다.

1. 2018 LINE 버그바운티

  • 버그바운티 프로그램이란?
    • 사용자가 취약점을 해당 회사나 전문대행회사에게 연락하면 회사가 이를 판단하여 보상금을 지급하는 프로그램
  • LINE과 NAVER는 취약점 보고창구가 존재함
  • 회사의 가장 좋은 보안방법은 버그 바운티 프로그램을 통해 화이트 해커를 고용하는 것임
  • HackerOne, BugCrowd를 통해 다른 회사의 버그바운티 프로그램을 확인할 수 있음
  • LINE은 Bug Bounty Program Site를 통해 버그바운티 프로그램을 운영

2. LINE이 말하는 보안

  • WebView의 위협 ( MITM / XSS )
    • MITM  / XSS : 네이티브 기능 접근시 HTTP면 악성 페이지로 접속되어 ( MITM 공격 및 XSS ) , 악성 페이지는 기기 접근을 통해 정보를 빼냄
    • HTTPS 일지라도 XSS 존재시 위험
    • Old Android OS의 WebView 에서 HTTP페이지 로딩시 위험
  • LINE에서는 WebView 서비스를 모두 HTTPS ( MITM 공격 방지 ) / 상시 SSL 사용 / XSS는 이스케이프 처리를 기본으로 함
  • CSRF 이슈
    • POST 랜덤 파라메터 혹은 커스텀 헤더로 대책을 세움
    • 주로 커스텀 헤더를 사용하고 있음
    • 커스텀 헤더를 서버에 추가하여 인증을 관리하면 해당 도메인은 CSRF 미발생
  • 사이트에 Open Redirect 가 있는 경우
    • Redirect URL을 변조하여 공격
    • 외부 도메인 Redirect 필요시에 화이트 리스트 방식으로 방지
    • 외부 도메인 Redirect 필요 없을시에는 경로를 통해 방지
    • 바이패스에 대해 주의 필요
  • SSRF 이슈
    • 사내 시스템이나 추측 가능한 도메인에 주로 이슈 발생
    • EX) http://127.0.0.1:8080 ...
    • 불필요한 Javascript:, ftp:// , file:// 대신 HTTP나 HTTPS로 URL Protocol 사용
    • DNS는 localhost및 사내 내부 IP를 허용하면 안됩니다.
  • 서버 설정 미스로 인한 정보 노출
    • Mongodb, Spring Boot EndPoint 노출 문제
    • shodan.io를 통해 확인 해 볼 수 있음
  • Other Case...

3. NAVER가 말하는 보안

  • Naver는 KISA를 통해 버그바운티 프로그램을 운영하고 있음
    • 공격자는 NAVER에 직접 연락하는 것은 아니고 , KISA를 통해 NAVER에 전달됨
  • Whale Broswer 만이 직접 네이버에서 버그바운티 프로그램 운영 중
  • 서비스 영역의 취약점도 네이버에서는 버그바운티 운영 중
  • NAVER에서의 버그 바운티의 경우 2017, 2018 모두 XSS가 제일 많이 차지
  • 왜 Security Bug  ( 보안 취약점 ) 이 계속 존재할까?
    • 모든 취약점을 보안팀에서 잡아낼 수 없음
    • Source Code Logcial Bug 또한 모두 잡아낼 수 없음
    • Google, FaceBook 등의 거대한 회사도 모두 Security Bug는 존재
  • XSS 이슈
    • Crawler에서 모든 URL을 수집할 수 없는 것이 가장 큰 이유
    • Naver Security Team에서는 Genji Web이라는 도구를 이용하여 XSS를 자동으로 진단
    • Genji는 Web Access Log를 확보하여 URL 저장소에 보관하며 이를 정적 , 동적 XSS 분석 하여 개발자에게 이를 알려줌
    • XSS를 Genji를 통해 발견하여, 서비스에는 현재까지 XSS 이슈가 없음
    • 다만, 서비스마다 룰셋, 파라미터가 달라서 각각 커스터마이징을 해야 하여 자동화에 오랜 시간이 걸림
  • Logical Security Bug
    • 투표하기 예시
    • 남이 생성한 투표에 생성된 Key를 close Page에 해당 키를 넣으면 강제 종료됨
    • 투표 생성자의 소유를 확인하지 않아 이 사례가 발생
  • 즉, 매우 세심한 플랫폼 및 라이브러리 관리가 필요함
    • 하지만 모든 플랫폼 및 라이브러리를 보안팀이 관리할 수 없다.
    • 모든 라이브러리 및 플랫폼에 대한 보안가이드의 양이 너무 많다
  • 개발자가 생산하는 코드에 최대한 취약점을 제거해야 함
    • 코드 변경시 보안팀과 함께 취약점 진단을 받는 것이 좋다.
    • 다만 코드는 이를 만든 개발자가 제일 잘 알기 때문에, 개발자가 직접 취약점에 대해 생각함이 필요하다.
    • NAVER에서는 버그 바운티 사례를 통해 취약점을 개발자 교육에 활용중이다

4 - 1 . 생각하는 요점과 소감평

요점 :  현재 NAVER, LINE에서는 이러한 버그바운티 프로그램을 운영 중이고, 가장 중요한 것은 개발자가 취약점에 대해 최대한 파악을 할 수 있어야 한다.

소감평 : 현재 NAVER, LINE에서 어떻게 사이트의 버그를 버그바운티 프로그램을 통해 잡아내는지 통계 또한 알 수 있었으며, 보안팀이 이를 위해 한 노력과 개발자가 노력해야 될 부분 설명이 들어가 있었던 세션이었습니다.

5.네이버에서 사용되는 여러가지 Data Platform, 그리고 MongoDB - 이덕현

9

네번째 세션은 네이버 데이터 플랫폼 이덕현 개발자님의 세션이었습니다.

1. 네이버에서의 Data Platform

  • 네이버에서는 초창기에는 Web Server <-> RDBMS Server의 2 Tier 구조 였음
  • 하지만 서비스가 커지며 DB Query 가 무거워져 Cache를 추가했음
  • 지표를 저장하기에 RDBMS의 공간과 비용에서 문제가 생겨, HBase 사용 시작

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

  • 기존의 네이버에서 지원했던 Data Platform에서 Cover 되지 않는 영역 바생
  • Schemaless 하고 sharding , secondary Index, Transaction 처리가 가능한 MongoDB 도입
  • MongoDB는 SchemaLess, Data Sharding, Secondary Index, Transaction, JSON 지원 등의 장점이 있음
    • Secondary Index의 경우 Hbase에서는 미존재 하기 때문에 Full Scan을 해야 되서 비효율적임

3. 네이버에서 MongoDB를 사용하며 겪은 에피소드들

  • Mongos를 통해 Data Sharding 을 제조사에서는 배포 권장을 하고 있음
    • 그러나 네이버에서는 사용하고 있지 않음
    • 수백 대 이상의 서비스의 경우 모두 Mongos를 도입해서 배포, 관리하는 것은 비합리적
    • 네이버는 DBA와 개발자의 역할이 확실히 분리되어 있어서 Mongos의 경우 웹서버 접근을 해야함 -> 불가능
  • L4와 GetMore 이슈
    • 처음에는 MongoDB에서 L4(Network-Switch)를 사용하려고 하였음
    • 하지만 GetMore 이슈때문에 현재는 미사용중
    • GetMore란? 100건의 요청이 있을 경우 100건을 한번에 리턴하는 것이 아닌, 20건 ( 예시 ) 등으로 나눠서 리턴, 그 이후 20턴 나눠서 리턴
    • 하지만 다른 Mongos에 접속하게 되면 GetMore가 안됨. 이러한 이슈로 미사용중
  • Mongos <-> Shared 커넥션 - 중요
    • Connection 설정은 Web Server <-> mongos의 Connection만 적용
    • Cmongos <-> shared Connection 설정은 Mongos가 담당
    • Mongos의 경우 Shared Connection의 Min은 1개이나 Max가 끝이 없습니다
    • Connection이 너무 많으면 서비스가 느려지고 터짐
    • Naver에서는 Min 10개 ~ Max 20개로 커스터마이징해서 사용
    • MongoDB를 도입할때는 이 부분에 대해 제일 중요하게 생각하여 커스터마이징 하는 것이 좋음
    • 종료 시간 또한 각자 커스터마이징 하는 것이 좋음
  • Node.js Driver 3.x는 커넥션이 close되지 않는 이슈가 있음 -> 2.x 사용할것
    • Mongoose 모듈은 성능이 좋지 않아 미사용 권장
  • Storage Engine 이슈
    • mongodb 3.4 미만일시에는 WiredTiger 미사용 권유
    • 3.4 이상은 사용 해도 상관없음
    • 오래된 버전에는 eviction 시에 갑자기 데몬이 죽을수 있음
  • eviction , endpoint 이슈
    • endpoint : Buffer와 db사이 불일치하는 것을 일치시키기 위한 작업
    • Mongodb는 한번에 Endpoint를 처리해서 갑자기 느려질 수 있음
    • 일정 기간 중에 갑자기 느려지면 End Point를 의심할 것
    • eviction : 가장 오래된 데이터를 삭제하는 것
    • Mongodb 3.4 미만에서는 ( 3.4 이상은 무방 ) 버그가 있어 갑자기 eviction 작업 중 디비가 죽을 수 있음
  • Background Index 이슈
    • mongodb 사이트에서는 이상 없다고 함
    • 실제로는 mongodb에서 index 생성시 해당 DB단위로 lock이 걸림
    • RDBMS는 해당 테이블만 lock이 걸림
    • 즉, DB에 lock이 걸리므로 쓰기가 안되서 디비 응답 지연이 발생하므로 주로 새벽에 이러한 작업을 함
  • Compact
    • 네이버는 미사용
    • 다시 조각모음처럼 구성하나, 이럴때는 질의 수행 (SQL)이 안되서 안하고 있음
  • Clustered Index
    • 해당 Key 값 기준으로 정렬하는 방식
    • 하지만 Mongodb에는 없기 떄문에.. 결국 Clusterd Index를 하는 서비스에서는 MongoDB 사용을 안하는 것이 좋음
    • Clustered 작업시 Mongodb는 Full Scan
  • Unique Index
    • MongoDB Sharding 환경에서 Unique index는 Unique해 보이지만 실제로는 shared 전체에서 Unique 하지 않음
  • Bind_IP는 해당 IP가 DB접속이 가능한 걸 파악하는 것뿐임 => DB_ACL 제한이 아님

4. 개인적으로 바라보는 MongoDB의 장단점 그리고 전망

  • MongoDB는 NOSQL의 특징과 RDBMS의 특징을 모두 가지고 있는 장점이 있음
    • 그러나 RDBMS와 NOSQL의 모든 단점도 가지고 있음
    • 즉, 사용시에 어떻게 써야할지 신중히 생각해야함
  • CheckPoint, Mongos <-> Shared 커넥션 , 한글 전문 검색 문제등의 이슈는 여전히 존재
  • 위의 있는 단점들이 해결된다면 Main Stream으로 도입할 만한 DB이나, 해결이 되지 않는다면 Main Stream이 아닌 일부 기능에서만 활용할 것 같다.
  • 다만 현재 확대되고 있으며, 회사 단위로 지원이 늘어나는 중

5 - 1 . 생각하는 요점과 소감평

요점 : Naver에서 MongoDB를 활용하는 부분에 대해 설명하고, 현재 NOSQL의 장점과 단점 이슈 설명 후 앞으로의 전망을 이야기하였습니다.

소감평 : MongoDB가 현재 가지고 있는 장점과, 단점에 대해 모두 들을 수 있었고, 이후의 미래에 대해 생각해 볼만한 결론을 내려준 세션이었습니다.

6.웹 성능 최적화에 필요한 브라우저의 모든 것 - 이형욱

마지막

마지막 세션은 이형욱 네이버 개발자님의 세션이었습니다.

6 - 1 . 생각하는 요점과 소감평

요점 : JS -> Layout -> Paint -> Composite 의 과정이 16.6ms에 처리될 수 있게 파이프라인 최적화를 해야합니다.

소감평 :  실제 브라우저 작동 흐름도와 tracing을 통해 더 상세히 개발자도구보다 활용할 수 있는 도구를 알수 있게 되었고,  파이프라인 최적화에 대한 설명을 들을 수 있었던 세션이었습니다.

7. 후기

이번 NAVER DEVIEW 2018에서 해당 세션들을 들었을때, 처음 시작하는 분들이나 주니어 분들이 많이 참조하고 시작할때 레퍼런스 같이 참조할 수 있는 세션이 많아서 좋았습니다. 다만 마지막 세션을 제외하고는 시니어 분들이나 오래 작업을 하신 분들이라면 더 어려운 지식을 듣고 싶었을 거라는 생각을 하는 컨퍼런스였습니다. ( 마지막 세션은 용어를 모르면 이해하기 어렵다.. 라고 생각하였습니다. )

이 글을 마치면서 후기 글 작성 양식 및 스타일에 도움을 주신 창천향로님에게 감사의 말씀 전달드립니다.

창천향로님의 다른 블로그 후기도 참조하시면 많은 도움이 될 것 같습니다. 감사합니다 !

- 창천향로님의 후기

해당 모든 세션들은 NAVER DEVIEW 페이지에서 발표자료 제공을 하고 있습니다. 감사합니다.


Popit은 페이스북 댓글만 사용하고 있습니다. 페이스북 로그인 후 글을 보시면 댓글이 나타납니다.