Deview DAY01 Review (1 )— 연결과 발견의 기술
DEVIEW는 네이버가 주최하는 국내 최대 IT기술 컨퍼런스로, 올해로 벌써 열한 번째입니다. 2018 DEVIEW는 코엑스 그랜드볼룸에서 10월 10일과 10월 11일, 두 차례에 걸쳐서 진행되었습니다. 올해 티켓팅이 무려 10초만에 마감되었다고 기사가 뜬 걸 다들 보셨을까요? 저 역시 처음엔 10초의 승리자에 들어가지 못하였지만, 제가 제일 관심있던 DAY01의 티켓을 양도해주시겠다는 분이 계셔서 덕분에 행사를 즐겁게 다녀올 수 있었습니다.
기회가 주어졌으니 한 번 제대로 들어보자고, 매 발표 세션 집중하며 들었습니다. 그 당시엔 아침 10시부터 오후 4시 45분까지 진행된 강행군 탓에 피로했지만, 돌이켜 생각하면 여러분께 유익한 내용을 생생히! 전해드릴 수 있어서 기쁘네요.
DAY01 10:00–10:40 키노트 송창현 / NAVER LABS
송창현 네이버 CTO는 AI를 더이상 Artificial Intelligence라 하지 않습니다. Ambient intelligence, 즉 생활 속에 스며든 미래의 기술이 바로 미래의 네이버가 지향하는 목표입니다.
새롭게 펼쳐질 네이버의 ‘그린닷’ 기술로 DEVIEW 2018, 네이버의 메인 키워드인 ‘연결과 발견의 기술’을 이야기했습니다.
연결 : 사물 인식 텍스트가 아닌 이미지로 정보를 얻는다.
발견 : 적시에 답을 제공하고, 정보를 추천하고, 이후의 액션까지 제공한다.
단순한 네비게이션을 넘어서 사용자의 삶을 담기 위해 노력했다는 네이버는 지도 서비스의 개선에 많은 시간을 투자한 듯 싶었습니다. 아래는 간략하게 요약한 지도 서비스 개선 사항입니다.
주소 자동완성의 품질 향상
런처 삽입을 통한 빠른 네비게이션 활용 가능
다이나믹 지도
- 사용자가 네이버 서비스를 통해 예약한 정보를 지도에 자동으로 표시
- 현재 개최중인 스포츠 및 기타 행사를 지도에 표시
11월 13일, NAVER 지도 Enterprise API 출시
이전까지의 문제점 : 실내에서 gps가 정확히 잡히지 않음 / 전에 가본 매장도 수시로 바뀜 / 정체 지점에서의 명확한 길안내 정보 제공
- 해결책 : 실내, 실외, 도로까지 파악하여 고정밀 지도 생성 -> 자동으로 지도를 업데이트
또한 네이버는 위와같이 개선된 지도 서비스를 이용하여 위치기반에 더욱 중점을 둔 키즈를 위한 스마트 착용 디바이스 사업에도 힘을 싣고자 합니다.
앞으로 더욱 우리의 삶 속으로 스며들어올 네이버 지도 기술을 기대해볼까요?
DAY01 11:00–11:45 React Native : 웹 개발자가 한 달 만에 앱 출시하기 이성민 / SNOW
React Native 선택 이유
React Native는 Facebook에서 개발한 웹 용 GUI 라이브러리 React를 모바일 플랫폼에서 사용할 수 있도록 만들어진 도구입니다.
Facebook, instagram, baidu, tencent, cake 등지에서 React Native, 약칭 RN은 앱개발에 미숙한 소수의 자바스크립트 개발자들도 5개월의 짧은 시간만에 해당 어려움을 해결하고 앱 서비스를 출시할 수 있기 때문에 효율적으로 사용되고 있다고 합니다.
SNOW의 이성민 개발자가 cake 서비스를 개발하기 위하여 RN을 선택한 이유는 다음과 같다고 이야기합니다.
- 빠른 개발속도, 투입한 리소스 대비 高 퀄리티
- 플랫폼 간 공유 코드의 양 ↑ — QA & 유지 보수 비용 감소 ↓
- 개선이 쉬움
- 안정적이면서 빠른 개발 사이클 진행
∴ RN, 단기간에 프로덕션 레벨의 크로스 플랫폼 앱을 만들어야 할 때 고려할 수 있는 여러 선택지 중 가장 가성비 좋은 프레임워크
RN 완벽한 이해
RN은 React 기반 위에서 javascript 로 Native 모바일 앱을 만드는 프레임워크입니다.
RN의 쓰레드 구조는 다음과 같습니다.
- Main (UI) Thread = 화면의 UI와 터치
- Javascript Thread
각 Thread는 독립적으로 실행되고, 직접적 통신이 불가능합니다. Thread가 통신하기 위해선 Bridge라는 개념을 통해 간접적으로 접근해야만 한다고 합니다.
Bridge의 특징은 다음과 같습니다.
(1) Asynchronous
- RN Bridge는 비동기식
- 자바스크립트에 결과를 전달하는 유일한 방법은 ‘콜백’ 또는 ‘이벤트 발생’
(2) Serializable
- 직렬화된 메세지 교환 방식으로 구조는 간결, 성능 저하 문제 발생
- Native 호출마다 직렬화 및 역직렬화 과정에서 부하 발생
- 개선 : Batched 큐에 넣어 5ms 단위로 일괄 처리
Cake 프로젝트로 얻은 노하우 & 팁
production-level 프로젝트라면 Expo(CRNA)사용 X
- 속 편하게 처음부터 빌드 방식(react-native-cli)로 시작 O
중간에 안드로이드에서 꼭 확인
- 효율적인 작업 순서 : iOS (기본적인 작업 — 레이아웃, 데이터 연동) -> android (복잡한 애니메이션 & 인터랙션 확인) -> iOS (특화된 UX 작업)
import 경로 지옥 탈출
- babel-plugin-root-import 사용
Optional Chaining
if(data && data.items && data.items.length > 2)
-> if(data?.items?.length > 2)Lock dependencies (버전 고정하기)
Flow는 처음부터 꼭 사용
- Flow 기능 : 코드 진단 / 자동 완성 / 타입 힌트 / 빠른 함수 이동
컴파일 된 번들 파일을 확인하는 것도 유의미한 작업
성능을 고려해서 정적/리모트 이미지 사용
JavaScriptCore의 동작 오류를 파악하여 대비 (플랫폼 간에도 다르게 동작할 수 있음 : 버전 차이)
플랫폼 별 컴포넌트 스타일링은 재정의 방식으로 정의
android text 위아래 패딩을 includeFontPadding 스타일 속성을 꺼서 제거
놓치기 쉬운 최초 화면 렌더링 체크
- render() 함수가 최초에 한 번 실행된다는 것을 잊지 말자
무거운 코드의 올바른 실행 시점을 체크
DAY01 12:00–12:45 Learn how Material Design makes it easier and faster to build apps without compromising quality Jonathan Chung /Google / UX Lead
DEVIEW 뿐만 아니라 다른 디자이너 밋업을 갔을 때에도 꾸준히 나오던 이야기입니다.
“Time is money, 시간이 금이고 최대한 빠르게 작업하는 것이 중요하다.”
때문에 현재에 와서 디자인 시스템이라는 체계가 나오게 되었고, 중요하게 여겨지기 시작했다며 발표가 진행되었습니다.
Q. 디자인 시스템이 디자이너의 일을 대체해버리진 않을까요?
A.
- 디자인, 사람의 직접적인 사고가 흐름으로써 작업이 되는 것
- 디자인 시스템은 디자이너를 완전히 대체할 순 없음
- 디자인 작업을 좀 더 빠르고 쉽게 시도할 수 있는 스타팅 포인트
Q. 머티리얼 디자인을 적용해서 앱을 만들다 보면 누가 만들어도 다 똑같은 디자인 같습니다. 이를 극복하거나, 개선하기 위한 점이나 똑같지 않게 잘 만들어진 케이스가 궁금합니다.
A.
- 구글 내에서도 2014년도에 대두되었던 문제점
- 2018년 5월에 출시한 버전에 브랜드성을 명확히 표시하기위한 고민을 담음
- ( 큐트한 디자인이라면 버튼을 어느정도로 동그랗게 해야 좋을까? 등등…)
Q. 디자인 시스템에서 컴포넌트를 만들다 보면, 컴포넌트를 조합해서 새로운 컴포넌트를 만들 수 있습니다. 그러다보니 고민이 드는 것이, 최소한의 컴포넌트들만 정의하고 조합해서 사용하는 게 좋을까요? 아니면 자주 사용하는 컴포넌트는 그때그때 턱턱 추가하는 게 맞을까요?
A.
- 새로운 패러다임이나 툴이 나오면 전부 체크 (그러나 기저에는 일관성을 목적으로 사고)
- 어떤 앱에 유니크하게 작업해야할 사항 生 -> 다른 페이지에서도 쓰일 수 있는지 고민하고 신중히 추가
- 특정 스크린에서 해당 디자인을 꼭 쓰지 않아도 되는데 굳이 쓰고싶다 주장 들어옴
- 커뮤니케이션을 통하여 합의점 도출 후 결정
Q. 새로운 씬을 추가하고자 하는데, 기존의 가이드라인과 충돌할 경우엔 어떻게 해야 할까요?
A.
- UX 자체가 어긋나는 걸 진행하고자 하면 -> 당연히 막기
- case, kakaotalk 상단 탭 -> 하단 네비게이션 바 전환 이유, “머티리얼 디자인 가이드에서 하지 말라고 해서”
- 기존의 디자인과 충돌하더라도 ux적으로 개선이 된 부분이라면 변경해나가는 게 맞음
Q. 어떤 부분을 설득해야 머티리얼을 써야한다고 주장할 수 있을까요?
A.
- 스피드, 효율성
- 디자인을 검증할 수 있다는 점
Q. 머티리얼 디자인을 설명하다보면 컴포넌트 기준으로 설명을 하게 됩니다. 듣는 사람한테 설명하기에 전체 흐름을 이야기하기가 어려운 것 같습니다.
A.
- 머티리얼 디자인에 해당 요소에 대한 가이드라인이 나와있으니 그걸 사용해보자! 라고 이야기
- 컴포넌트 기준으로 설명하게 되면?
- 이걸 써야하는데 왜 써야하는지 온전히 이해 못하고 사용하는 경우 多
- 머티리얼 디자인, 프레임워크로만 사용. user flow 중심으로 리서치를 많이 진행하여 커뮤니케이션
다음 내용은 (2) 편에서 이어집니다 …
