본문 바로가기
세미나 후기

DEVIEW 2016 1일차 방문기

by Havi 2016. 10. 25.
반응형

DEVIEW 2016 방문기

목차

  • 키노트
  • CTO 송창현님
  • Web Payment API의 현재와 미래
  • REST에서 GraphQL과 Relay로 갈아타기
  • Electron: 웹 개발자들을 위한 Desktop Application 제작
  • Angular2 vs React, React vs Angular2
  • React로 개발자 2명이 플랫폼 4개를 서비스하는 이야기

이번에 우리나라에서는 제일 크다는 Deview에 참석한 기념으로 첫 방문기를 작성하고자 합니다. 방대한 내용과 여러 세션으로 구성되어 있지만...제가 참석하고 이해한 정도까지만 내용으로 간단하게 담고자 하였습니다.


(두근두근 시작전!)



도착하여 재빠르게 등록을 마치고 선물을 받았습니다. 이쁜 가방과 함께 생필품(?)들이 들어있는 주머니 가방을 받았습니다. 개인적으로 점심쿠폰이 없는게 아쉬웠다는... 

부스는 다양한 장르로 구성되어 있습니다.(기술홍보, 채용, 책판매, 기타)



( 강연장 앞 전경, 사람들이 빼곡한 부스) 



(Angular2 vs React(저는 개인적으로 React에 스티커를~ㅋㅋ))



데뷰 전체적인 사진은 끝났고 각 세션에 대한 설명은 간단한 요약본이므로 문어체로 쓰도록 하겠습니다.


키노트

(이해진 의장님 연설) 


네이버 이해진 의장님이 나오셔서 인터넷 기업의 미래는 '기술'에 있다는 점을 강조하셨습니다.

  • 행사를 통해 좋은 기술자들이 나왔으면 좋겠다.
  • 세미나를 통해 해외로 나가는데 조그마한 힘이라도 되었으면 한다.


CTO 송창현님

네이버는 다음과 같은 일을 하고 있습니다.

  • 핀포인트 외국등지에서 상용화
  • 개발자를 위한 폰트 5만 다운로드(나눔고딕코딩)
  • 네이버 개발자센터 업데이트
  • D2 개발자 센터 공간 제공 및 스타트업 지원

네이버 내부 기술 이야기

  • 원천기술 내제화를 목표로!
  • 실생활에 필요한 스마트 기술, 인공지능에 집중

1.papago

  • 한/영/일/중 통역앱
  • 음성인식기술
  • 다양한 기능 제공
    • 1:1 대화모드, 이미지 번역, WSD화면, 환율 자동 변환, 글로벌 회화
  • 머신러닝을 활용해 기존 성능보다 2배 향상시킴

2.WHALE

  • 네이버 자체 브라우저
  • 자유롭게 창을 띄움
  • 검색어를 입력하지 않아도 빠르게 검색
  • 똑똑한 브라우저 기능
  • 보안기능
  • 다양한 디자인 제공
  • 12월1일부터 베타 테스트 제공(http://whale.naver.com)

3.Project BLUE

  • 상황에 맞는 더욱 개인화된 실생활서비스 / 플랫폼

4.AMICA

  • 음성 인식된 사용자 발화로부터
  • 영화에서 보던 인공지능 음성대화 시스템
  • 기존의 손으로 하던 모든 기능 동작들을 언어적인 수단으로 옮긴듯
  • AMICA 베타 테스트 오늘부터 시작
  • 삼성 ARTIK과도 연계
  • http://amica.ai

(시연영상입니다. 마치 아이언맨의 자비스를 보는 느낌이였습니다.)

  • 위의 연구 이외에도 다른 연구를 계속 진행중이다.
  • 자율주행 연구
  • 이미지 인식 기술 및 음성인식 기술을 통해 사용자가 미처 생각 못한부분까지 적재적소에 제공
  • 인공지능 로봇 'M1'
    • 로봇은 스타워즈의 알투같은 느낌...?
    • 실내 지도를 더 정밀하게 측정 가능하게 해주는 로봇

끝나는 매 세션마다 안내 음성까지 아미카의 음성을 사용하여 관객들에게 계속해서 어필을 하는것도 세미나의 컨셉중 일분인듯 합니다. 네이버가 단순히 기존 사업뿐만 아니라 다방면의 미래발전적인 사업에 뛰어들고 성과를 보이는 것 같아 박수를 보내드리고 싶습니다. 특히 AMICA의 동영상은 정말 충격이였습니다.


Web Payment API의 현재와 미래


W3C Web Payment WG에서 표준으로


1.Motivation

  • 쇼핑 고객68%는 결제를 하지 않고 나간다.
  • 모바일의 경우 데스크탑보다 66% plus해서 더 사용하지 않는다.
  • 이유를 분석해 보니 Form을 입력하는게 귀찮고 힘들다.
  • 그래서 국제적으로 웹 표준 결제방법을 정의하기 시작했다.
  • 버튼 하나로 결제를 처리하는 시스템으로!



2.Basic Cards

  • One Button Payment Request API
  • User benefit
    • 모든 쇼핑몰에 익숙한 ux사용하여 결제 진행
    • 처음 이용하는 고객도 저장된 신용카드 사용 가능
  • Merchant benefit
    • 결제 시스템을 위한 ux등의 비용 노력 절감
    • 각 Merchant가 신용카드 저장을 위한 높은 보안 수준의 서버 운용비용 절감

3.Payment Apps

  • Merchant benefit
    • Web Page의 변경없이 지원하는 payment app 추가/제거 가능
    • Web Page 유지보수 비용 절감
  • Payment Apps
    • Merchant Integration 이용함


REST에서 GraphQL과 Relay로 갈아타기


1.Rest API

  • 서버와 클라이언트 소통
  • 보통 GET방식으로 Response받을 때 Json API형식으로 반환되어 진다.
그러나 한계가 있다.
  • 필드 제한
    • 요청에 대한 모든 데이터를 가져와야 할지
    • 접근 권한이 없는 필드는 가져오지 말아야 하나...고민
  • 필드 타입
    • 필드 타입에 대해 정의하지 않아 클라이언트와 서버 개발자 각각의 협업이 힘들어진다.
  • Side Effect
    • 데이터의 동기화 이슈
  • Query Hell
    • 다양한 데이터에 대해 가져오는 URI 엄청나게 길어진다.
  • 라이브러리 부족
    • 일반적인 라이브러리(GET, POST)를 맞춰주는 방식정도만 있음
    • RESTful과 JSON API는 쓸만한 프로토콜이지 쓸만한 라이브러리가 없다.

2.GraphQL(2015)


  • 리액트가 프론트엔드를 대체한 혁명처럼...GraphQL도?
  • Rest 방식에 대한 대체!
  • 자세한 내용은 공식문서 참조
  • 한 마디로 쿼리 언어
  • 그래프큐엘의 목적은 스키마를 정의하는 것
  • Query, Mutation이 엔트리 포인트의 역할을 수행함
  • type, args, resolve 각각을 정의해서 스키마를 정의한다.
  • 필드 타입도 개인적으로 커스터마이징해서 정의 가능
  • 자동 문서화와 Type Inspection이 강력한 툴적요소도 제공 (스샷으로 같은 쿼리에 대한 스펙 붙여넣기)

3.Relay(2015)

  • GraphQL의 부족한 점을 매꿔주는 확장판 같은 느낌
  • React와 연계하여 시너지 효과를 창출
  • Node - Resource에 대한 단일 Interface, Data Management에서 유용
    • 단순히 String만으로 어떤 리소스인지 파악이 힘들어 GlobalId 제공
  • Connection - 다수의 Node를 가져올때 사용
    • pagination에 특화되어 있음
    • after, before, first, last라는 파라미터를 제공하여 pagination구성
    • lazy loading 방식에도 사용(자신이 원하는 데이터만 filter를 통해 제공)
  • React Relay
    • 컴포넌트가 하이어러키한 구조를 갖고 있을 경우 각각 다른 데이터 스키마를 사용해서 가져와야 하는 경우가 있다.
    • Relay.createContainer를 사용해서...
    • Relay를 사용할 경우 쿼리들을 하나의 컴포넌트로 묶어서 개발할 수 있다.
    • 만약 rest를 사용할 경우 더욱 복잡한 형태의 개발이 필요할 수 있는 거에 비해 장점이 있다!
  • Mutation Config
    • Mutation의 Side Effect를 적용시키는 방식을 Config에 명시하면 클라이언트에 적절하게 반영

Summary

  • 데이터 가져올때 query 사용, 변경할땐 Mutation 사용
  • 항상 데이터의 의존성을 명시
  • GraphQL은 타입이 정해져 있고 프로토콜 단에서 확인할 수 있음(Introspection)
  • 데이터 의존성을 명세한 query/mutation를 보낸다.
  • Mutation Config만 잘 써주면 알아서 데이터 변경사항을 처리한다.

발표자 본인이 적용하면서 느낀사항

  • Data Management를 React와 묶어줘서 생산성과 개발 속도 크게 향상
  • Query build + Cache로 인하여 성능 향상
  • 현재는 GraphQL Relay만으로 안정적인 서비스 구현 가능
  • 발표자는 반년동안 안정적인 서비스 운영을 진행하고 있다.
But...
  • 지금 존재하는 온라인 문서만으로 Relay의 진입장벽이 높다.
  • 실시간 지원이 미비...

당연시하게 여겨왔던 RESTful방식을 더 명확하게 스펙을 정의해서 사용하는 방식이 있다는 것에 시야가 확장되었다고 생각합니다. 다만 회사의 프로젝트에 적용하기에는...서버, 프론트 둘 다 바꾸고 작업의 양이 커져서 적용은 힘들것 같다는....ㅠㅠ

22세 개발자라고 하시는데...개인적으로 선배분들의 질문에도 당황하지 않고 생각하시는데로 깔끔하게 답변하시는 모습이 놀라웠습니다.


Electron: 웹 개발자들을 위한 Desktop Application 제작


1.Electron

  • Desktop GUI Application을 만들기 위한 Framework
  • 2013년 시작(Atom shell)
  • 러닝커브 장벽이 낮은게 장점

2.Electron 구조


3.공부 방법

  • 보강 되어가는 Document site
  • Naver말고 Google에서 검색하셔야 합니다.^^
  • 키워드에는 github를 붙여서 검색하세요!
  • Slack과 Microsoft의 표준을 보고 참고

4.Electron을 사용하게 된 계기

  • 대다수 ProtoPie 개발진이 web based
  • 개발자들이 web service 특화
  • 초기 개발은 Cloud로 개발
  • 외국(북미/중국)에서 실행이 안되는 문제
    • 지역적 Packet less
    • 보안에 따른 접속문제 발생

5.Electron 도입과 검토

  • 빠른 개발 가능
    • chromium - 최신 기술 모두 도입 가능
    • 브라우저 브랜드 & 버전 고려가 필요 없음
  • 개방형 개발 플랫폼
  • Desktop App이 가져야 할 기능

6.당면과제와 해결 방안

  • 소스 보호는 어떻게?
    • 비즈니스 로직을 최대한 백엔드로 옮기기
    • 그 후, 백엔드를 Binary로 build하자.
  • 무거은 Resource 처리는 어떻게 할 것인가?
    • 이미지 최적화 logic 추가
  • 다양한 Object 처리가 필요하다.

7.Design Pattern

Event-based Asynchronous Pattern
  • 동시 다발적인 복잡한 계산이 필요한 경우
  • Busindess Logic을 최대한 보호
Command Pattern 사용
  • client는 UI에만 집중, 입력값만 전달
  • Undo/Redo 구현

8.Front-End Framework 선택

  • AngularJS or React 고민하였지만...
  • 결론
    • ES6 and TypeScript를 도입하여 개발
  • DOM을 활용한 Architecture

9.Debugging 방법

Chrome Debugger & Devetron
  • Chrome Debugger(일반적인 디버거 방법과 같음)
  • Devtron
    • Electron에서 더 자세한 디버깅을 원할 때
    • 호출되는 라이브러리상태 확인
    • IPC 모니터링

10.Build & Deploy

EncloseJS
  • Node.js를 각 플랫폼에 맞춰 build가 가능
    • window, mac, linux 지원
    • NodeJS를 Binary함으로써 Source를 상대적으로 보호 가능해 졌다.
  • 한 줄만에 빠른 배포가 가능
  • Document가 부족
수정 Deploy 방식
  • CDN을 구축(중국 기준 60~120배의 다운로드 속도 향상)

11.Summary

  • web기술을 가진 개발자를 위한 Dsktop app 제작
  • 상용 서비스가 아니라면, 자신이 선호하는 기술쪽으로 개발 가능
  • 사용 서비스의 경우 소스 보호에 대한 대비가 필요


Angular2 vs React, React vs Angular2


왜 이 발표를 하는가?

  • 우리가 React나 Angular2에 대해 잘못 알고 있는게 있다는 것을 깨닫고 세미나를 하게 되었다.
  • 이러한 것들에 대해 공유하는 자리를 얻기 위해서!
  • 진행은 두명이서 서로 React(김훈민님)와 Angular2(손찬욱님)를 대변해서 진행

(비교 정보(카메라가 안좋아서...좀 번지네요ㅠㅠ))

파일 사이즈는?

  • Augular2: 314k
  • React: 240k

성능

  • 6개의 테스트 시나리오에 따라
  • 결과는 생각보다 큰 차이가 없음
  • vanilla.js를 제외하고는 도찐개찐

메모리 사용량

  • 딱 보면 Angular2가 좀 더 쓴다...

Framework, 왜 사용하는 걸까?

  • 생산성이라는 한 단어가 떠 오름
    • 학습비용: 두개 비슷(제외)
    • 생태계: (제외)
    • 신뢰성: (제외)

1.개발환경(김훈민님)

  • 시간상 제외
  • 손찬욱님이 한마디 해주셨음 "Angular2가 훨씬 좋은데 안타깝다...ㅋㅋ"

2.언어 생산성(김훈민님)

  • Flow
    • 페이스북에서 만든 타입 스크립트 비슷한 녀석
  • React랑 Flow, Typescript 사용량은 4%가 안됨
  • 타입스크립트 사용시 상위에 인터페이스로 각각의 타입을 정의해야 하는데 이러한 것들이 자바스크립트의 장점을 깍아 내리는 단점이라 생각한다.
  • 비용 > 소득(따져봐야 할 문제)

Angular2를 쓰려면 TypeScript를 배워야 하나요...?(손착욱님)

  • 실제로는 아니고 3가지의 방식을 지원한다.(TypeScript, JavaScript, Dart)
  • 실제로 타입스크립트가 배우기에는 좀 부담스럽다고 생각한다.
  • 구글이 타입스크립트를 만드는 과정을 보면 좀 더 이해하기 쉬울 것이다.
언어 생산성 향상(손찬욱님)
  • Angular2의 고민
  • 언어를 만들자! AtScript!!
  • ES2015를 사용해서 생산성 극대화
  • Optional Type
  • Metadata
  • 구글의 파워를 사용한 웹표준 지향!한다고 선언하였으나...
  • 사람들의 반응이 별로...ㅠㅠ
  • 궁극적으로 MS의 타입스크립트를 사용하여 개발하는게 옳다고 판단
  • 실제로 비용 < 소득을 따져보면 그렇지 않다.
  • 새로운 언어, 학습비용?? 자바스크립트 개발자라면 선행학습이 필요한 것이라 생각한다.

Angular2의 매력은!?(손찬욱님)

  • 컴포넌트 = HTML + JS + CSS
  • Angular2의 컴포넌트는 이식성이 높고 재사용성이 높다.
  • css의 캡슐화도 제공
  • 이에 반해 React는 이러한 캡슐화의 기능은 없다.
JSX in JS(손찬욱님)
  • 왜 스크립트에 JSX가 들어가는 것인가?
  • 이 때문에 협업이 곤란하다.
  • 저는 관대한 개발자니까 이러한것 까지 받아들일 수 있다.^^
  • 이에 반해 앵귤러는 표준 HTML + Extend한 개념으로 기존의 스펙안에서 확장한 개념으로 이해하기 훨씬 수훨하다.
  • 알고보면 JSX도 새로운 언어 아닌가?

이미 앵귤러 자체에 로직구조를 넣는 것 자체가(김훈민님)

  • 순수 HTML을 파괴하여 마크업 개발자와의 협업을 힘들게 한다.
  • 사실은 React나 앵귤러나 둘 다 이 문제를 해결하지는 못했다.(앞으로 해결해 나아가야할 문제)

JSX가 다른언어가 아니다.(김훈민님)

  • 그저 순수 자바스크립트로 짜면 트리구조로 알아보기 어려운 코드를 알아보기 쉽도록 만든 것이 JSX이다.
  • JSX = 구조 + 기능

4. 데이터 동기화(김훈민님)

  • 뷰와 모델의 분리, 데이터 문기화 문제 등장!
앵귤러하면 데이터 바인딩
  • 양방향 데이터 바인딩때문에 복잡도도 증가하였고 성능도 떨어졌다.
  • 하지만 개발상에서 편한 이점이 있다.
React는 Virtual DOM을 생성하여 바뀐 부분만 체크하여 데이터 바인딩을 수행
  • 렌더링 부분은 React가 짱이다.(손찬욱님 인정)

그래서 Angular2도 인정! 양방향 데이터 바인딩을 사용하지 않겠다.(손찬욱님)

(웃음포인트가 재미있는 강연!!ㅋㅋㅋㅋ)

  • Angular2에는 Change Detector를 사용
  • React의 가상돔과 거의 비슷
  • Zone: 자바스크립트의 실행영역
  • 이제는 Zone을 사용하기 때문에 '$'를 사용할 필요없이 그냥 사용할 수 있음
  • 장점으로는 DOM이 아닌 모델에 집중한다.

5. 비동기 처리

  • Angular2랑 RxJS랑 손을 잡았다.
  • React는 라이브러리를 지향한다.
  • 주로 React가 제공하지 않는 부분을 RxJS로 체우려 하지만...학습 비용이 매우 높다.

그래서 최종 선택해야 할 프레임워크는?

  • Angular2: 최소 기능 + 기본도 제공
  • React: 최소 기능제공
  • 두 가지다 개발자의 선택(각각의 프로젝트에 따른...)

Angular2의 생각(손찬욱님)

  • 프로젝트에서 프레임워크를 써야 한다면 Angular2를 추천
    • 대부분의 이슈에 대해 솔루션을 갖고있다.
    • 구글은 웹표준을 지향한다.

React의 생각(김훈민님)

  • 선택은 개발자가 해야 할 일
  • 각각의 처한 상황에 따라 유연하게 대응할 수 있는 React를 추천한다.

(개인적으로 두분이서 시나리오를 구성하고 치고박고(?) 유쾌한 강연을 보여주셔서 시간가는줄 모르고 즐겼습니다.)

저는 개인적으로 리액트를 응원합니다~ 리액트 짱짱!!


React로 개발자 2명이 플랫폼 4개를 서비스하는 이야기


  • 개발자 2명이서 단시간 내에 백앤드, 프론테앤드, 안드로이드, ios를 개발하기는 불가능에 가까움 그래서...
  • OSMU(One Source Multi Use) - 여러번 할 삽질을 한 번만 하는 것
  • ORMU(One ReSource Multi Use) - 여러명이 할 삽질을 한 명이 하는 것
  • 백엔드, 프론트 둘 다 자바스크립트로 통일하여 개발 시작!

1.리액트를 쓰는 이유

  • 렌더링 시점을 직접 제어할 필요 없음
  • Virtual DOM으로 성능 확보
  • Angular는 성능이 안좋아서...
  • 결정적 이유는 React-Hot-Loader
    • 재시작 없이 State를 유지한 상태로 변경된 코드 반영
    • 생산성 업
    • react + webpack + hot-loader
    • boilerplate 등 참고할 수 있는 예제 많음

2.하비브리드에서 적용 가능할까?

  • 안드로이드, 아이폰 등 빌드 필요없이 변경된 코드 반영(최대 강점)

3.Alt

  • Flux 구현체
  • 선택한 가장 중요한 이유는 서버 사이드 렌더링

4.React Isomorphic

  • 클라이언트의 Action, Store, Component 코드를 서버에서 사용
  • React-Router 코드를 서버에서 불러서 라우팅 처리
  • ISO 모듈을 이용하여 클라이언트 코드로 렌더링 수행

5.더미 노출

  • 더미 페이지를 노출하여 사용자가 페이지 전환에 대해 더 부드럽게 느끼도록 역할 수행

6.멀티플랫폼 환경구성 방법

  • 무조건적인 분기구문은 보기에 않좋음
  • 성격이 다른 플랫폼은 폴더를 분리
  • 공통 기능은 공통 로직으로 구성
  • 성격이 유사한 플랫폼은 같은 파일 내에서 분기문 처리

Summary

  • 자바스크립트를 통해 클라이언트와 서버 언어 통일
  • Isomorphic: React, React hot-loader, Alt,
  • 네이티브 같은 앱: Phonegap, Native Page Transition, 더미 노출(하이브리드앱같은 앱)
  • 이런식으로 하여 2명이서 4개의 플랫폼을 개발하는 것이 가능해 졌다!

뒤로갈수록 지쳐서 사진들이 좀 줄었지만...대략 제가 느낀 점과 각 세션의 내용들을 대략적으로 요약해 보았습니다. 많이 부족하지만 읽어주신 분들께 감사드립니다. 아! 알차게 데뷰를 준비해주신 모든 분들께 감사드립니다.

반응형

'세미나 후기' 카테고리의 다른 글

DDD 입문 후기  (0) 2017.05.20
2017 스프링 캠프 두번째날 후기  (0) 2017.04.23
2017 스프링 캠프 첫번째날 후기  (0) 2017.04.22
2017 AWSomdeDay 후기  (0) 2017.03.19
제 6회 커뮤니티 데이 탐방기  (0) 2017.02.26

댓글