DEVIEW 2019 Day1 참가 세션 메모

세션에 참가해서 필요한 내용이나 기억에 남길 것을 메모함. 자세한 내용은 발표자료 참고.

솔직히 ML, AI는 뭔소린지 모르겠음.

[외산 클라우드 없이 AI 플랫폼 제공하기: features, training, serving, and AI Suite]

https://deview.kr/2019/schedule/303

자체 AI 플랫폼 이유

.security - 국내 데이터는 국내에서, 지리, 정부 승인 등

.cost 

.demand

네이버는 사용하던 AI 플랫폼이 있었음

이를 엮어서 > AI Suite : End-to-End AI platform

머신러닝을 위해서

데이터 처리 ㅡ 모델 학습 ㅡ 서빙이 필요함.

실제 개발에서는 

=> 데이터 처리가 오래 걸림, 자동화 고려 필요

AI Feature 안에서

. Dump : 데이터를 가져오고
. Analyze : 가시화를 통한 인사이트
. Batch : 데이터를 선별하여 feature vector생성

Facets

단점 

. 모든 데이터 클라이언트에서 돌리므로 성능 이슈 > 샘플링을 통해서 통계를 보고 인사이트를 얻음

. HDFS라 전체를 다 읽어야 샘플링 가능 > 일부를 읽어서 전체를 예상하고  estimation 하여 샘플링

모델연구시

. 최대 GPU자원 사용

. 동시 사용하여 성능 좋은 모델 선정

. 데이터 고정으로 캐싱하면 이득

하지만 제품화 시

. 최소한의 자원 사용 (비용문제 이유)

. 배포전 이전 모델의과 품질을 검증 필요

. 새로운 데이터로 캐싱 의미 없음

서빙 = APS 서빙 + 모델 서빙

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

[Papago: Engineering BERT into NMT]

https://deview.kr/2019/schedule/296

몇가지 적긴 했는데 그냥 발표자료를 참고하여 논문을 찾아 읽어야 할 듯

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

[챗봇 1만 개의 모델 서빙하기: AI 서비스 어디까지 해봤니]

https://deview.kr/2019/schedule/310

중요한 건 모델의 규모와 서비스 형태 

미신러닝

.수백 수천 토큰 질의를 해하는 모델

. 도메인 전용 학습이 필요하지 않은 모델

.10턴 이상 문맥을 고려하지 않는 모델

구축>훈련>평가>개선 흐름을 자동화

모델의 비용을 계산하고 결과를 봐야함.

Amdahl's law

무한의 컴퓨팅 자원을 투입해도 20%의 속도 개선이 가능함.

아니 경제적인 모델: 학습과 추론의 성능 최적화가 곧 비용인 시대

최적화?

. 모델 최적화

. 모델러와 소통

. Framework customizing, JNI 수준까지

. 확장 CPU Register사용(bert 120ms에서 bert AVX-512 MKL 7ms로 개선)

1만개 서빙?

. AutoML auto quantization

. One source multi environment models(네이버 C3DL 기반 동작)

. Decentralized clusters (kaa) akka, spark, scala, tf

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

[모바일 얼굴인식, 엔진부터 DEVIEW에 적용하기까지]

https://deview.kr/2019/schedule/312

얼굴인식으로 인증 단계 감소

1:N의 얼굴 인식의 경우 보조 인증을 주로 사용

Face engine

얼굴 검출 > 특징점 검출 > 얼굴인식 딥러닝

=>Clova Face

얼굴 검출을 위한 모델 얘기는 발표자료 참고
Engine을 Product에 적용하는 얘기도 발표 자료 참고

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

[어디까지 깎아봤니?: 모바일 서비스를 위한 가벼운 이미지 인식/검출 딥러닝 모델 설계]

https://deview.kr/2019/schedule/321

발표를 들으며 "발표자는 진정 방망이모델 깍는 노인이구나"라는 생각이 머리를 계속 맴돌았음.

발표자료는 꼭 보시길

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

[예약 전화도 쉽게 받는 인공지능 비서를 만드는 P;ㅠ]

https://deview.kr/2019/schedule/293

이분은 회사에서 자주 본 것 같은데 비슷한 사람이었나?

아직도 전화 예약을 많이 한다.

사람도 전화응대를 잘 못한다.

스피커, 챗봇과는 다름

Conversation Space

Turn, Sequence, Activity,Task 로 대화를 구분

대화에는 실패가 없다. 

Command control 패턴과 같은 스피커에서와는 다르게 대화를 반복하여 해결 가능

Full duplex <> Gateway >ASR >DNNLU >SYNTH >Gateway

성능향상을 위한 모델

. Contextual hint

. Multi turn

. Task moving

. Barge in

엔지니어링 이슈들
. Latency

. Initiative Control

DEVIEW 2019 Key Note 메모

Deview key note 메모

https://www.naverlabs.com/storyDetail/142

https://platum.kr/archives/130372

https://byline.network/2019/10/28-67/

치타 시연 

Autonomous space + AI AR Automation

>> A(utonomous) city

하이브리드 HD 매핑

인도어, 아웃도어 모두 매핑

도로 HD MAP DATA 무상 배포

아웃도어 로봇 Alt platform 을

인도어 로봇 Around platform 와 통합

로봇과 제 2 사옥을

Human friendly Robot & Robot friendly Building 으로

Global AI R&D Belt : 한국/일본/프랑스/동남아의 인공지능 연구진과 스타트업, 기관들을 연결

새로운 표준

더 큰 연결의 가능성

기술 상상 도전

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

수아랩

퓨리오사AI chip

문재인 대통령님 연설

https://www.google.com/amp/s/m.yna.co.kr/amp/view/AKR20191028054400001

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

(네이버 서치)

인플루언서 검색 지원 > 창작자 연결

AI 기술 - 비전 검색 등등 기술 개발

"사용자 이해" 네이버 검색 기술의 핵심 가치

>Deep understanding

(네이버 플랫폼)

클라우드 네이티브 컴퓨팅

네이버 컨테이너 클러스트

.auto scaling 트래픽 예비자원

.서버 효율 증대

2019년 네이버 서비스  60% 이상 컨테이너 운영

Pinpoint 2015년 공개

+ Nel02? npot?

+ 지원 생태계 확장

클라우드 네이티브 컴퓨팅

Observability 확대를 위한 서비스

오픈소스 생태계 지원

(네이버 클라우드 플랫폼)

2014년 부터 퍼블릭 오픈

장점

.국내 자체 기술

.안정성, 보안 측면

.클라우드 서비스 대안

(네이버 동영상)

2013 

카메라 ㅡ 인코더 ㅡ 범용미디어버서 ㅡ CDN ㅡ 모바일 플레이어 

2015

모바일카메라ㅡ모바일 인코더ㅡ범용미디어서버

2018

모바일카메라ㅡ모바일 인코더ㅡ네이버미디어서버

2020년 까지 4K

안드로이드 지원 중, 삼성 스마트 티비 지원 예정

(네이버 AI)

사용자를 이해

사용자에게 감동 제공

사용자가 편리

이해

.정확하게 듣고 이해 (영상 사용)

.의도를 정확이 이해 (징면 인지)

감동

.자연스럽게 말하고(감정, 사투리)

편리

.영수증, 고지서 플레이릴스트 OCR

.얼굴인식

.Ai Call 음성전화 예약

Cloud AI API 제공

GDG Devfest 2019 메모

https://festa.io/events/559

발표자료 공유해주시면 감사할텐데..

이런 행사를 제공하는 것만으로도 감사.

다만 발표자 역량에 따라 발표내용이...

[Google Cloud 키노트]

시대의 흐름?

1. Dev & operation 

2. DevOps

3. Infrastructure as a code

4. SRE - site reliable engineering

Google cloud에서는 대규모의 여러 구글 서비스들을 지원 중 (Analytics, data, application ,infra 등-구글의 9-10억명 기반 서비스의 기반이기도 함.)

구글의 앱,서비스 제공 원칙

1. User를 먼저 생각

2. 기획안의 10배를 고민하고 생각함.

3. 공유할 수 있는 것들을 모두 공유하라

--------------------------------------------------------------------------------

[안드로이드 기반 AR 세계로의 초대]

안드로이드 7.0 이상

지원기기가 특정되어 있음

Android, unity, ios, unreal

Unity - all in one engine

AR core SDK for unitiy를 다운로드 받음.

Case study

- Life style 

 Streem사에 나온 VR 기반 가전 가이드 서비스

- Game

 Tend AR 사용자 얼굴로 가상의 물고기를 조정하는 펫 게임

- real estate

 Curate에서 가구를 배치할 수 있는 서비스

개발 및 학습 팁

- AR core API reference

- community : guthub, stack, AR experiments

--------------------------------------------------------------------------------

[Reactive Native와 Flutter를 고민하는 개발자분들에게]

Native platform, hybrid platform

Flutter skia ui 엔진이 모든 위젯을 그림

디바이스 platform, sdk 종속성 없음

React Native는 Platform 기본 컴포넌트를 활용하여 Platform, sdk 종속성이 있음

React Native는 bridge를 사용하고 플랫폼 종속적은 컴포넌트를 지원하여 이라 플랫폼용 코드 구현이 필요하기도 함.

Flutter도 스타일이 구분되어 있어 각 스타일을 다른 플랫폼에서  유지하기 위해서 분기처리 필요함.

모두 Platform specific code를 위해 platform code를 작성하여 호출함.

App size , 

Android hello world, Flutter 4.5M, Raect Native 7.1M

Flutter은 engine이 4M

React native js engine이 5M

iOS

Flutter 52M, React Native 24M

Flutter 30M, complied dart module 20M

Js core 15M

개발자 측면

.IDE 지원은 충분

.Hit reload 모두 지원

Dart는 인터프리터가 아닌 컴파일 언어, class 기반으로 중첩 코드 형태로 개발 해야함

JS - html을 활용하여 개발 가능

Architecture 

F BLoC 패턴,  페이지당 BLoC를 하나씩 개발 필요

R Flux 패턴, redux 데이터가 한 방향으로 이동, 함수형 프로그래밍에 최적화

3rd party library

F Package manager

R NPM

Reactive native의 라이브러리가 많고 flutter은 많지 않고 퀄리티도 부실함.

예제도 마찬가지

Flutter은 stack overflow보다 github 이슈에 있는 경우 많음

Flutter

- Camera library는 사용 못함

- Google 인증 library는 로그인 수준만 사용 가능

- video player도 성능 문제, frame drop

- web view도 성능 문제

--------------------------------------------------------------------------------

[Toy project가 쏘아올린 작은 공]

Pingcloud-cli

https://github.com/reoim/pingcloud-cli

개인 golang 공부를 사용하기 위해 시작

결국 뱅크샐러드 취업 및 다른 취업 기회 얻음

- 적절한 커뮤니티네 공유

- README.md 정리, 최대한 자세히 정리 아니면 문의 폭탄

실력이 증요(자격증, 공부, 컨퍼런스 발표 등), 실력을 알리는 것도 중요(블로그, 링크드인, 커뮤니티 등)

-----------------------------------------------------------------------------

[Declarative(<->imperative) UI patterns]

Declarative programming

필요한 것을 선언하여 사용 

Declarative UI patterns

화면에 필요한 컴포넌트를 선언하며 UI로 부터 구현을 분리?

사용할 컴포넌트를 선언(css선언하듯이)

왜?

화면 이동 시 개발자 버든을 줄여줌

게발자는 상태를 정의하면 되고 프레임워크에서 알아서 트랜지션을 처리

>앱의 기능 구현에 집중

>적은 코드량

>예측 가능한 코드

Flexibility

Data + UI code + behavior로 분리됨

Flutter에서는

UI = f(state)

Widget 기반으로 개발

- react에서 영향

- 현재 state로 보여줄 UI를 표시

- immutable 선언하여 수정 없이 사용

Flutter render tree

: 기존 뷰 같은 개념

Render Object

: 인스턴스화가 비용이 들어서 render tree가 업데이트 될 경우 재사용함 

React

- declarative, component base

- reconciliation(UI component tree를 저정하기 위해 On 알고리즘 사용) - flutter와 유사

Jetpack Compose

- Event handling을 명확히 > data input으로 event 주입

Swift UI

- view protocol 정의

- inheritance 보다는 compsition

- Modifier로 정의

Galaxy Home mini 개봉기

갤럭시 홈 미니 개봉기

https://blog.naver.com/sunshine_308/221646757628

Galaxy Home Mini 베타 프로그램​

Galaxy Home Mini

베타 프로그램​

삼성전자의 스마트 홈 스피커 

갤럭시 홈 미니를 가장 먼저 경험할 수 있는 기회!

모집기간 2019. 08. 28(수) ~ 2019. 09. 01(일) 

https://www.samsung.com/sec/templateEvent/Home_Mini_Beta/

왜 goto문을 사용하는 것이 해로운가?에 대한 글들

사실 교재나 강의에서 goto문이 해롭다고만 했지
왜? 에 대해서는 알아볼 생각을 못했던 것 같다.

찾아보니 다음 글에서 Dijkstra님께서 프로그래머로서의 goto문 사용에 대해서 언급 하시고 이것이 발단되어 많은논쟁들이 있었고 지금의 구전과 같이 전달되고 있었음.

Go To Statement Considered Harmful, Edsger W. Dijkstra, 1968년
http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_Harmful.html

영어라서 천천히 읽어 보면 그냥 goto문을 사용하지 말라는 것이 아니지만 goto문을 사용하는 것은 프로그래머로서 s/w 작성하는데 있어 goto문이 적절하지 않다는 얘기 같다.

이를 한글로 자세히 설명하는 글들은 다음과 같고 아랫글들을 읽어보니 이해가 쉽게 되었음.

https://blog.nacyot.com/articles/2015-12-02-programming-is-difficult/

https://www.phpschool.com/gnuboard4/bbs/board.php?bo_table=old_talkbox&wr_id=289198

일부 발췌함.

이 논문으로 인해 구조적 프로그래밍에 대한 관심이 크게 일기 시작했고, 여러 언어의 형성에 큰 영향을 끼쳤다. 이 논문이 나오고, 이후 10년도 넘게, 아니 지금까지도 이 논문에 대한 논쟁은 그치지 않고 있다. 이 논문의 핵심은 다음 두 문장에 잘 드러나고 있다. 

① 우리는(우리의 한계를 알고 있는 현명한 프로그래머처럼) 정적인 프로그램과 동적인 진행과정 간의 개념적인 간격을 최소화하기 위해 최선을 다해야 하고, 그렇게 해서 (텍스트 공간에 펼쳐진) 프로그램과 (시간상에 펼쳐진) 진행 과정 사이의 대응 관계가 가능한 한 명백하게 해야 한다. 

② 어떠한 구문(clause)이든, 프로그래머 독립적 좌표계(programmer independent coordinate system)가 진행과정을 여전히 유익하고 편리하게 설명해 줄 수 있어야 한다는 요구 사항을 만족시켜야 한다. 

...

독자들도 모두 동의하겠지만 이 논문은 단순히 ‘goto 문을 없애라’는 수준이 아니다. 다익스트라 스스로도 자신이 제안하는 구조적 프로그래밍이 단순히 goto 문 제거 정도로 도매급으로 팔리는 데 심한 불쾌감을 표현했다. 구조적 프로그래밍은 물론이고, 이 논문 역시 시간과 공간의 갭을 줄여 프로그래머가 실수를 덜하고 올바른 프로그램을 좀더 쉽게 만들게 도와주는 것이 중요하다고 역설한다. 

...

이 논문의 결론이 현재 어느 정도나 실현됐을까? 일단, 대부분의 언어에서는 goto를 흡수하여 상위 수준의 제어문인 break, continue, exception 등을 지원하게 됐다. 덕분에 우리는 자신도 모르게 안전한 goto를 쓰고 있는 셈이다. 하지만 여전히 goto를 쓰는 언어가 남아 있다. 아직 논쟁은 그치지 않았다. 영원히 끝나지 않을지도 모르겠다. 

include, extern C, naming mangling, linking error

얼마 전 cpp 파일에서 header를 include 하지 않아서 linking error가 발생한 적이 있어 이에 대해서 찾아봤는데, 찾아보니 간단한 이유였었음.
아무래도 내가 C/C++ 수업에서 설명을 들었을 것 같은데 제대로 공부하지 않고 아무 생각 없이 코딩했던 내가 한심했음.

먼저 위의 현상이 발생한 원인을 예를 들어 설명하면
a.cpp 파일에서 정의된 test() 함수를 a.h에서 c-style(extern "C")로 선언을 하고
test() 함수를 b.cpp에서 사용하고 있는 상황에서
a.cpp에서 a.h를 include 하지 않으면 test() 함수 naming mangling으로
b.cpp에서 찾을 수 없는 상황이 되어 linking error가 발생하는 것이었음.

덕분에 아래 내용도 알게 되었으니 위안으로 삼자..

그리고 아래 내용은 모두 이 책에 정리되어 있음.
http://www.yes24.com/Product/Goods/23441719?scode=032&OzSrank=1

---------------------------------------------------------------------------------------------
https://stackoverflow.com/questions/48211215/how-is-the-header-file-connected-to-the-corresponding-cpp-file

cpp 파일 컴파일 시 header의 선언들에 대한 정의의 위치를 symbol table에 저장하고 컴파일 단위인 transition unit에서 찾지 못한 선언의 경우도 함께 저장한다.

cpp 파일이 모두 컴파일되고 linking 단계에서 모든 transition unit의 symbol table을 모아서 찾지 못한 선언의 정의도 업데이트하게 된다고 한다.

추가로 MS Visual C++ language guide에서 컴파일 방법과 참조 범위를 설명하고 있는데
https://docs.microsoft.com/en-us/cpp/cpp/program-and-linkage-cpp?view=vs-2019

컴파일 단계에서 각 cpp에 대해서
cpp와 cpp에서 include하는 모든 header를 묶어서 translation unit으로 만든다고 하고
각 translation unit은 독립적이라 compile 시 영향을 주지 않는다고 함.

전역이나 namespace scope에 정의된 function이나 non-const 전역 변수들은 External linkage라고 하며 모든 translation unit에서 참조가 가능하지만
다른 object(variable, class definition 등)는 Internal linkage라 불리며 해당 object가 정의된 translation unit에서만 참조 가능하다고 함.


위에서 설명된 symbol table에 대해서 여러 사례로 보여주고 설명하는 article이다.
https://www.toptal.com/c-plus-plus/c-plus-plus-understanding-compilation
Symbol table, naming mangling, undefined symbol, header guard, pass by value/reference 등에 대해서 실제 예를 들며 자세히 설명하고 있음.

Naming mangling
https://en.wikipedia.org/wiki/Name_mangling