[후기] Deview 2016

개발자 컨퍼런스가 풍성한 10월이다. 저번주 테크플레닛 2016 (opens new window)을 다녀오고 이번주는 Naver에서 주관하는 Deview 2016 (opens new window)을 다녀왔다.

Deview는 작년 (opens new window)에 이어 2년째 출석 중이다. 그 전에도 간 적 있었던것 같은데... (블로그에 글이 없으니 헷갈린당...이래서 글을 써놔야해..)

일단 작년에 비해 참석자가 더 늘어난 것 같았다. 정말 사람 많았다 ;;; 인기 세션은 자리가 모자라서 강연장 곳곳에 그냥 자리에 앉아 듣는 사람들도 많았다. 의자와 의자 사이가 좁아 많이 불편하긴 했다. 노트북을 다들 무릎위에 두고 치다보니 옆사람들과 부딪히는 일이 종종 발생했다.ㅠ 그만큼 Deview 행사의 규모도 커지고 개발자들의 참여도도 높아진 거라 생각한다.

해가 갈수록 더욱더 볼거리가 풍성해지는 Deview를 보며 한번 놀랐으며, 그 너머로 보이는 네이버의 규모, 로드맵에 대해서 또 한번 감탄사가 절로 나왔다.

AI, 인공지능, 딥 러닝 , 챗봇 api, 파파고까지 다양한 최신 기술을 직접 느껴 볼 수 있는 시간들로 가득했다.

이 외에도 다른 회사들의 크고 작은 트러블슈팅, 개발기 등을 들으며 직접 현업에 가져다 쓰고 싶은 기술들, 개인적으로 라도 공부해보고 싶은 것들을 많이 배울 수 있었다.

가장 크게 느낀 점은, 머신러닝, 딥러닝은 이제 미룰 수 없는 과제가 된 것 같다. 늦은 것 같지만 ㅠㅠㅠ 아직 진입하고 있는 사람이 많은 것 같으니 이제 미루지 말고 공부를 시작해야겠다.

그리고 기억에 남는 세션 중 하나는 1일차에 있었던 Apache Zeppelin과 오픈소스 비즈니스 (opens new window) 였는데, 아파치 재플린이 어떻게 성공적인 오픈소스 프로젝트가 되었는지 공유한 시간이였다. 이번 deview 에서는 개발자 문화 관련 세션이 두개밖에 없었는데, 그 중 하나로 ,개발자로써, 오픈소스에 대한 갈증이 있다면 꼭 발표영상을 보길 바란다.

요즘 개발자 치고 오픈소스를 단 한번도 사용하지 않았다!! 라는 사람은 없을 것이다. 근데 기여를 하는 사람은 그렇게 많지 않을 꺼라 생각한다.(나 역시 그러하다..힝) 개발자 커리어에 도움이 된다는 것은 알고 있지만 시간을 내기가 어렵거나, 내 실력으로 저렇게 큰 프로젝트에 어떻게 컨트리뷰트를 할까라는 경우가 많을 것 같다. 하지만 강연을 들으며 오픈소스 매력에 흠뻑 빠지게 되었다. 많은 사람들의 github star(개발자들의 로망이 아닐까)와 전 세계인들과의 커뮤니티, 그리고 다양한 글로벌 회사들의 러브콜까지. 그 로켓에 발 하나쯤 사알짝 올려보고 싶은 생각이 많이 들었다. 빨리 찾아봐야징ㅋ

개발자 컨퍼런스는 항상 즐겁다. 그저 기술 습득의 즐거움 뿐만 아니라, 오랜만에 만나는 개발자 친구들도 좋고 새롭게 만나게 되는 사람들도 좋다. 이 마음 잊지말고 커뮤니티, 오픈소스 등 참여해보도록 해야겠다.

강연 발표 자료 : Deview 2016 Schedule (opens new window)

이번 참관 후기 역시 들은 내용 노트를 공유하며 마무리 하고자 한다. 이틀동안 이어진 세션들을 후다닥 정리한거라 저번보다 더 엉망 ㅠ.ㅠ..

• 안타깝게도 ㅠ 내가 듣지 못한 세션 중 Angular2 vs React, React vs Angular2 (opens new window)가 아주 재미있고 핫했다고 한다. 꼭 챙겨보자!

---

내 스케쥴과 주제

topic	내용
[1] Web Payment API의 현재와 미래	W3C Web Payments 표준에 대하여 이야기
[2] REST에서 GraphQL과 Relay로 갈아타기	GraphQL와 Relay를 풀어나가며 실제 서비스에 어떻게 사용했는지에 대한 경험을 공유
[3] Apache Zeppelin과 오픈소스 비즈니스	Zeppelin 프로젝트를 어떻게 시작해서 성공적인 프로젝트로 만들었는지에 대한 여정을 재미있는 에피소드와 함께 이야기
[4] 한 달 만에 개발한 하이브리드 앱, 50만 사용자 서비스가 되기까지	네이티브 앱 개발 경험이 전혀 없는 웹 프론트엔드 개발자의 100% 웹뷰 하이브리드 앱 개발기
[5] 5년간의 네이버 웹엔진 개발/삽질기 그리고...	웹엔진에 대한 이야기, 그 엔진들의 기술적인 이슈들 뿐만 아니라 새로운 엔진을 만들고 그것으로 제품을 만들려는 시도 속에서 벌어지는 많은 이슈들도 함께 이야기
[6] 딥러닝을 활용한 이미지 검색: 포토요약과 타임라인	이미지 검색 서비스를 개선하기 위해 딥러닝을 활용한 다양한 방법을 소개하고, 검색 서비스의 인터페이스 개선에 응용한 대표적인 두가지 사례를 자세하게 소개
[7] 딥러닝과 강화 학습으로 나보다 잘하는 쿠키런 AI 구현하기	쿠키런 AI 구현에 사용된 네 가지 연구(Deep Q-learning, Double Q-learning, Dueling network, Prioritized Experience Replay)를 소개하고 각각의 기술이 얼마나 성능을 향상시켰는지 보여줍니다.
[8] Backend 개발자의 Neural Machine Translation 개발기	Neural Machine Translation(NMT) 개발에 도전해서 성공한 경험을 공유
[9] 네이버 콘텐츠 통계서비스 소개 및 구현 경험 공유	람다아키텍쳐를 살펴 보고, Realtime과 Batch 데이타 흐름을 효과적으로 처리할 수 있는 구현체를 직접 구현 내용 공유
[10] 딥러닝 예제로 보는 개발자를 위한 통계	데이터마이닝, 머신러닝 그리고 통계 , 통계로 바라본 딥러닝 , 개발자를 위한 통계

---

[1] Web Payment API의 현재와 미래

webpayment api

• W3C (참고: https://www.w3.org/Payments/ (opens new window))
• working group으로 표준으로 진행하는중
• 2015 oct 에서 시작.
• 지금까지 한 일년정도 된것

삼성 인터넷앱

• 크로미움 엔진
• 구글 플레이에 업데이트 햇음

why? Motivation

• 카트 > 결제 : 68%
• 다양한 이유가 있음. 근데 모바일만 따로 이유를 찾아봤더니
• mobile은 66%가 더 pc보다 높음. ( 거의 90% 는 결제를 안한다)
• 가장 큰 이유. form을 입력하기 싫다. (오타, 화면을 채우는 키보드 등)

신용카드를 이용한 결제

• 3가지 페이먼트 - payment request API, payment method identifiers, basic card payment

• 브라우저 : 지금 준비된건 크롬

• 뭐가 바뀔꺼냐.

  • 카드넘버나, expire date 등을 입력하지 않아도 되게

• 원버튼 for payment request api

어떻게 바뀌냐

• 미국같은 경우에는 checkout 버튼을 누르면 바로 결제 form 이 반이 뜨고 잇어서 더 복잡해 보임.

• 온라인쇼핑몰에서는 정해진 api를 주기만 하면 브라우저에서 form 을 알아서 만들어 주겠다.

• 쇼핑몰이 가격 정보를 넘기면

• 브라우저에 저장된 신용카드와 주소를 저장

• 소비자가 아무런 입력도 하지 않고 바로 결제 할 수 있도록 해주자.

flow

• 내가 받을 payment method 리스트를 넘겨주고 (아메리카 익스프레스. 비자카드 등)
  • 내가 얼마를 받아야 한다 .
  • 브라우저는 그 저장된거랑 mehods 교집합을 보여줌.
• 협의된 결제 네트웍에 대한

장점

• 어느 쇼핑몰에 가든 같은 form 을 보니 익숙.편안함.
• merchant 입장에서는 따로 구현할 필요가 없음.
  • 서버에 저장 하게 될 경우 보안도 신경써야 하는데 이런 mainteinanace cost가 들지 않음.

code level

Payment Request

• JSON으로 요청
  • methodData // rufwpqkdqjq
  • Details = // 뭘 결제할꺼냐
  • Options // 수집할 내용

paymentMethod

Details

Options

- 어떤 정보를 받을 것인지를 정의
- Ex) request shopping false이면 뭐 아이템? 사는거라 생각하고 택배 정보 노노

show()

- Promise

Shipping Address Change

- merchant가 택배이슈가 잇을때 ex) 수도권만 배송등

Shipping OptionChange

• 배송 옵션에 따른 가격 변동 ex) 빠른 배송 + 5000원 같은 경우

Payment Response

- pg로 결제 요청
- Complete 에 따라서 결제 성공/실패를 response 보내줌

browser 에서 바로 payment gateway (pg)로 바로 보내는게 아니라 merchant로 다시 보내주시면 알아서 서버호출을 하고 다시 커스터머에게 보여줘야함 이리 되면.. 귀찮아.. UI만 바뀌고 개발자가 해야할 일이 많아짐 .. 그래서!!

미래

• payment app을 사용한 결제

payment app

• 이것도 계속 늘어 날텐데 >> 이것도 하나의 버튼으로 하자
• 설치된 payment app의 리스트를 고르고 결제 버튼을 누르면 그 페이먼트 앱에서 결제를 진행
• 브라우저가 하는 일 페이먼트 앱으로 merchant의 결제 내역을 넘겨주는 것

이제는 내가 accept하는 payment app의 리스트를 넘겨줌

등록

1. web based payment app
2. Native payment app

웹 베이스의 경우

• 서비스 워커를 브라우저에 install
• 브라우저에 저장 하여 사용.

이렇게 되면 payment flow가 조금 바뀐다

• merchant로 가는게 아니라 payment app으로 바로 가게되고
• payment app 내에서 payment network를 타게 된다.
  • Payment token, reponse (뭐 아이디라던가)
  • 이걸 userAgent로 reponse를 내려주게 되고 User에게 보내줌

장점

Merchant

• 온라인 웹페이지 변경 없이 payment app에서만 기능 추가/제거 가능
  • 페이지에대한 유지보수 비용 절감

Payment app

• merchant integration이 용이함

code level

service worker

• 구글 , 삼성이 주도

• Event worker : 초기 이름

• 이벤트를 수신 하는 deamon

• 필요한 경우에, 항상 살아있는 데몬

• securee context가 보장되어 결제와 같은 보안에 중요한 서비스를 할 수 있음.

• Service worker와 payment app 1:1 매핑

• 동작이 기존과 동일 service worker가 paymentapp이라고 생각해도 괜춘.

설치

• 명시적 : 사용자가 직접 설치 ( 버튼을 통해)
• 묵시적 : 쇼핑몰 또는 브라우저의 추천에 의한 설치
  • 자동으로 설치. (스크립트로 동작이라 1초도 안걸림)
  • 맘대로 깔면 넘나 많아지면 어째

예제

• 시나리오 : 만원 이하, 광고를 끝까지 보면 결제해주겟음
• 결제 선택하면 > payment app (광고를 보고) >> payment complete

worker 입장에서

- 브라우저에 의해서 service worker가 활성화
- Onpaymentrequest가 불리우고 결제 정보를 받고 > 결제에 대한
- OpenWindow >> 광고 화면을
- PostMessage>> 필요한 정보를 보냄

[2] REST에서 GraphQL과 Relay로 갈아타기

Rest API

• client <> server
• 리소스를 uri로 표현
• GET/POST/DELETE/PUT
• Http response 여러 회사에서 사용중
• twitter, facebook, naver 등
• 추가 함수, 정렬, pagenation 등등
• 사실상 각자 제멋대로
• 그나마 정해진 것은 JSON:API

JSON:API

- Relationship
- 부분필드,
- 필터 적용 등등등

그래도 rest의 한계가 느껴짐

한계

• parse fieldset

  • 원하는 것만 가져오는것
  • 그럼 기본값은? 전부 다 가져와야 하나?
  • 접근 권한이 없는 필드는 어떻게 하지
  • admin과 유저 다르게 내려야 하나?

• ex) 나를 퐐로 하는 사람들을 가져오고 싶은데

• 내 정보 : 개인정보 + 다른 사람 정보 : 어느정도만

필드타입을 전혀 정하지 못함

• amount : "10.00" // object 타입일 경우 이건 string? Integer?

Side effect

• 결제라고 했을떄 payment에 대한거, credit의 정보 변경 한번씩 쳐야 한다
• 가져와야 정보가 많을때 param이 기하급수적으로 길어짐
  ex) query=dsajkd,dsadasd,asdasd,as,das,das
• 라이브러리 부족.
• endpoint에 따라 json 맞게 답변을 해줘야 한다.
• 클라이언트에서도 데이터를 알맞게 받아서 store 해줘야 한다

GraphQL

• Rest 방식을 바꿈
• query 언어
• rest uri를 그래프 언어로 바꾸면 더 간결해짐
• 여러 method를 표현할 수 있음.

스키마 정의 하기

• Query : GET
• Mutation : UPDATE DELETE PUT
  • args와 resolve를 사용

스카마가 정의도면 express-graphql 을 이용해서

Graphql clinet - lokka ? 를 사용해서 클라이언트에서 사용할수 잇음

GraphiQL

• postman 같은거
• 자동완성, 자동 문서화도 해줌

Relay

• 웹 어플리케이션 개발을 편하게 하기 위해 만들어주는것
• react 와 graphql을 연동을 도와줘 시너지 증가

컨셉

노드

• 단일 interface

 Query {
	node (id:1) {
		id,
		user,
		age
	}
}

데이터 매니지먼트에 용이함, cache를 한다던가 String 만으로는 resource 알기 어려움 type과 id가 합쳐진 GrobalId를 이용하여 알랴줌

NodeDefinition

커넥션

• 다수의 node를 가져올때
• pagination에 특화되
• Connection Definition을 정의해서
  • PageInfo 와 edges를 내려줌.
  • After before last first를 이용해서

React Relay

• Data 의존성과 component가 공존한다.

• 리액트에서는 컴포넌트가 여러개가 잇고 그 안에 그안에 이런식으로 되어있는데

• 그 각 컴포넌트들은 필요한 데이터가 각각 다르다.

• Relay.createContiner

• 각각 컴포넌트에 알맞는 쿼리만 작성하면 알아서 그걸 합쳐서 한번에 불러준다.

Mutation Config

• node방식으로 가져오니 data manage가 더 편함
• 어떻게 반영할 것인지 conf에 추가하면 됨
• Ex) 이미 불러온 node의 값을 업데이트, 기존에 불러온 connection에 추가/제거

summary

1. 기존 GET/DELE - >> Query / Mutation

2. 데이터를 미리 정해야 하고 그게 애매햇는데 >> 항상 데이터 의존성을 명시 ( 기본이 없고 원하는 것만)

3.필드가 정해져 잇지 않아 문서화 하지 않으면 협업이 어렵 ( 이게 integer인지 string인지) - 타입이 정해져 잇고 (strong type) 프로토콜 단에서 확인할 수 있음 - Introspection 4. 기존에는 어떤 param을 받는지를 명세 해놔야 함 >> 데이터 의존성에 명세할 필요가 없음 . 5. 데이터 변경 사항을 클라이언트에서 처리를 각각 해야함 - mutation config를 잘 써주면 알아서 데이터 변경 사항을 처리한다 .

• 생산성, 속도, 재미 보두 크게 향상
• 스타텁에서는 비지니스 로직을 계속 짜내는게 어려웠는데 서버와 클라이언트에 어떻게 보일때까지 한 큐에 도니까 개발이 더 편하다. (한명이 개발해도 좋다)
• 공식문서가 좀 미비함. Relay의 진입 장벽이 꽤 높은 ㅕㄴ
• Relay 실시간 지원이 미비. Mutation??을 통해서 바뀐 정보를 relaystore에 넣어줘야하는데 이게 안되서 hack을 이용해야함
• 아직 실험적인 생태
• 하려면 소통 방식부터 바꿔야 하기 때문에 프로젝트를 완전 엎어버려서 해야함. (기존 rest 에서 넘어가기 어렵. )

질문

Q Redux + graphql

redux를 쓰게 되면 relay 를 같이 쓰긴 어렵. data와 render가 분리 되어있어서 뷰와 데이터가 분리가 되는게 요즘 대세긴 하지만 그냥 데이터를 받아와서 뷰에서 핸들링 해주는게 더 편하더라 redux보다는 그냥 relay만 사용하는게 더 편하더라

Awesome graphql

• mysql
• mongodb
• resyncDB사용중 - 직접 만들어서 사용중중 Express graphql

Q 만약 Spring framework를 쓴다면..

• graphql 미들웨어를 하나 만들어 놓고 실제 데이터를 가져오는것은 rest로 해서 레거시와 연경 ( facebook 사례 )

Q angular와 같은 다른 framework 와 써도 되나요

• 그거와 종속성이 잇는게 아니니 쓸 수 있다.

Q 앱에서도 적용해본적 있나유? - http 에 국한된게 아니라 - protocol일뿐. - 소켓에서 때리든 자바스크립트에서 ajax에서 string으로 만들어서 보내든 - 뭐 그래서 상관이 없을 것 같다.

어느 정도 React Native

Q SQL 최적화

• 중요하지..
• join 이나 이런게 중요하지
• 어떤 쿼리가 어떻게 되는건지 보이긴 함.
• 어떤 필드가 필요한지 분석할 수는 있으나 애매하다.
• 화이트 리스트를 만들어서 미리 구현해 놓는 방법도 있을 것 같다.
• 최적화 이슈는 여전히 있음. graphQL 이슈에도 올라와 잇음. Plan? 이라는걸 누가 fork 따서 해놓은게 잇는데 그걸 참고해보3

Q null이나 제너릭 obj 을 지원하지 않음

• nonnulll로
• 1. stringlify

2. 하나하나 명세하는 방법

이러다간 끝이 없을것 같아 스키마에 추천하는중

[3] Apache Zeppelin과 오픈소스 비즈니스

• 기능보다는 프로젝트
• 오픈소스 생태계

발표자

• 아파치 제플린 PMC chair

어떻게 시작되었나

• 2012년 말에 interacitve 분석 커머셜 솔루션 개발

• 작은 회사에서 엔터프라이즈 비지니스를 하기가 어려웟음

• 기능 중 인터렉티브 분석 기능을 오픈 소스로 하면 어떨까?

• hadoop in Seoul 2013에서 발표하며 오픈소스 제플린을 제안 >> 관심이 없엇음.

• 회사에서 사이드 프로젝트로 시작 -> 노트북 형식의 소프트 웨어 형식을 만듬

• 2014년 여름부터 사용자가 생기기 시작

어떻게 시작할까

• 스파크 메일링 리스트에서 관련 질문이 올라오면 제플린을 추천
• 스택 오버플로우에도 계속 답변을 달면서 영업을 함.
• 홍보 1달도 안됬는데 제플린을 이용해서 서비스를 만드는 회사 발생.
• 2014년 12월에 아파치 인큐베이션에 들어가게됨

아파치 프로젝트가 된다는 것은

• 소스코드 소유권 (copyright)
• 브랜드 등
• 아파치로 기부, 양도를 하게 되는것

아파치 재단

• 오픈소스 재단은 다양한 곳이 있음
  • 리눅스 파운데이션
  • 모질라 파운데이션
  • 아파치 파운데이션 등

아파치 재단은 - Community over code - 좋은 커뮤니티를 만드는것이 재단의 목표 - 인큐베이터 : 아파치방식으로 일하는 방법, 의사결정하는 방법 - 탑레벨 프로젝트 혹은 subproject

트롤을 vote를 통해서 쫓아낼수 잇는데 멘토들의 조언

• 커뮤니티와 이야기를 해서 잘 풀어나가보아라
• 멘토들이 코드 이야기가 아니라 커뮤니티를 어떻게 꾸려가는가, 유지시키는가에 집중함.

탑레벨이 되면

PMC Committer Contributor

의사결정

• 코드 커밋부터 시작해서 릴리즈까지 여러가지 결정을 해야함.
• 비슷한 프로세스로 제안 > 토론 > 공감대 형성 > 투표 (consencus 기록의 의미) ** 투표 > 공감대 형성 (X) 투표를 햇으니 공감하라가 아님

아파치 프로젝트의 가장 큰 장점

• 아파치 브랜드 사용 가능

오픈소스 프로젝트 종류

크게 두가지로 나눌 수 있을 것 같다.

• 소스코드만 공개
• 소스코드와 의사결정 공개

어떤 프로젝트의 릴리즈가 그냥 딱 오픈된다. ( 의사결정을 어떤 집단 혹은 회사가 결정)

• 물론 이것도 오픈소스 하지만 이렇게되면 컨트리뷰터들이 참여하기가 어렵다.

• 재플린은 여러 노력을 했음

• 왠만하면 모든 토론을 온라인으로

• 회사에서도 가능하면 온라인으로

• 왠만한 모든 대화는 영어로

• 외국인 개발자들이 좀 있엇고, 원격근무, 자율근무를 하고 있어서 오픈소스를 도입하기가 쉬웠음.

• 버그패치만 제공하는게 아니라 어떠한 기능을 만들때 어떠하게 햇음 좋겟다 처럼 참여햇으면 좋겟다.

• 많은 회사들이 비지니스 도입하기 쉽게 했으면 좋겠다 .

오픈소스 비지니스

• 서포트/트레이닝/컨설팅 --- 일반적인 시도
• 듀얼 라이센스 - 조건부 오픈소스 라이센스 ex) 학술 개발에만 쓰일수 잇고 상업적인 용ㄷ는 안된다
• 엔터프라이즈 버전 - 오픈소스에 추가 기능을 붙혀 commercial production
• 기부 - 개인 기부 / 프로젝트 자체 재단을 만들어 기업들로부터 기부를 받는다.
• SaaS - 오픈소스를 그대로 서비스로서 제공
• Open adoption - 제플린은 여기
  • 오픈소스에서 직접 수익을 얻지 않고
  • 다른 product 에서 수익을 만든다.
  • 오픈 소스의 기능을 제한하고 비지니스를 독점 할 필요가 없다
  • 다른 비지니스를 하는 회사들과 경쟁할 필요가 없다
  • 선순한을 만들기 위해. ○ 기능을 제한/비지니스 독점하게되면 사용자가 감소 시장 크기가 감소하게됨 ○ 다양한 비지니스 허용하게 되면 사용자가 증가하고 시장의 크기가 증가 ** 요걸 기대

ZepplinHub

• 제플린 노트북 공유/협업 환경
• 아파치에서만이 아니라 다른 써드파티 회사에서도

극대화 하기 위해 다양한 전략을 수행

• 아파치 브랜드를 사용하거나
• 다양한 프로젝트와 인테그레이션
  • 플링크, 스파크, 카산드라, 알, 구글 빅 쿼리 등등등.
• 3rd party 비지니스
  • 아마존 웹서비스 emr
  • MS azure HD insignt 에서
  • 구글 클라우드 데이터 에서도
  • 클라우드 서비스 뿐만 아니라
  • Hotonwork HDP 패키지에 제플린 탑재 이런 회사들과 경쟁 하기 보다는 친구가 되는 쪽으로 노력함

그 결과로

깃헙 별 갯수 아파치 프로젝트 중에서 12번째

컨트리 뷰터 숫자는 153명으로 8위

이제는 유명한 프로젝트

컨트리뷰션 하는 회사들

• nflabs
• 트위터
• 구글 -허톤워크

사용자

• 국내외 회사들에서 많이 사용됨

생태계

• Contributors

  • Users
  • Service provider
  • Technology Integration

• 소스코드 오픈 뿐만아니라 이러한 풍부한 생태계가 오픈소스의 생태계라고 생각한다.

• 혼자있을때보다 더 많이 사용되고 더 빨리 성장하고 더 안정적인 프로젝트가 된다 생각한다.

비지니스 측면

• 모든 3파티 재플린 배포/서비스에 제플린 허브 integration 이미 탑재하여 재플린 퍼브의 기능/품질이 일정 수준이 오르면 hub integration 스위치를 켜도록 유도
• hotonworks에서는 데이터 분석 패키지에 이미 재플린을 넣어서 팔고 있음.
• 다른 클라우드 서비스에도 도입되었음 .

성공적인 오픈소스 프로젝트를 만들기 위해서는

• 프로젝트가 주는 가치
• 열린 커뮤니티 (사용자, 개발자) : 커뮤니티가 생성되지 않으면 오픈소스 형태를 굳이 가질 필요가 없다. 그냥 회사에서 하는거랑 뭐가 다르냐
• 3rd party projects/ business : 다양한 회사들이 integration되어있는 오픈소스가 혼자 덜렁 도는 오픈소스프로젝트보다 더 매력적이다 .

오픈소스 프로젝트로 도움된 것

• 아직 돈 벌 준비를 하고 있는 단계인데도
• 회사가 커지고
• 한국 > 미국
• 한국 seed > 미국에서 Series A 투자를 받음
• 컨퍼런스/밋업 : 한국 > 전세계

덧붙여

• 엔지니어 입장에서는 오픈소스가 괸장히 매력적이다
• 전 세계인과 같이 커뮤니케이션
• 회사 입장에서도 다양한 비지니스 기회를 많이 제공받으니 매력적이다.
• 힌반쯤은 오픈소스에 참여해보시길길

질문

Q 선순환 구조, 사용자를 늘리고 ,.. 선순환을 시작 되려면? 한정된 리소스, 개발자의 시간. (개발, 홍보, 메일링 리스트 뒤지기 등) 어떻게 시작하셧는지

A

• 몸으로 떼우기도 하고, 온난하게 대답을 잘해주면서
• 컨퍼런스 에서 다른 개발자들도 만나고 참여 유도도 하고
• 다른 프로젝트와의 integration들도 많이 하고

[4] 한 달 만에 개발한 하이브리드 앱, 50만 사용자 서비스가 되기까지

• iOS 하이브리드 앱 개발기
• 웹 프론트앤드 개발자의 앱 개발기 (100% 웹뷰)
• 디자인 하다가 웹 프론트앤드 개발자 > 풀스택으로 나가고자함

마이크로 앱으로 간보기

• 나도 앱 개발 해보고 싶다.
• 내가 만든 건 흔히 말하는 하이브리드앱과는 다르다. (네이티브에 부분부분 webview)
• 대부분의 기능을 웹 기술로 구현하려고 하기 때문에

첫 시도

• 아이템미
• 반응형 웹 제작
• 웹뷰 앱 (Single Webview App)
  • 사람들을 속이고 있다 라는 생각이 듬.
  • 심지어 상을 받음. 의미있는 시도였으나 기술적인 한계가 많았음 .
  • 터치 인터페이스 오동작 튜딩, UI 개발 복잡도 증가. 피로도 증가

보이는 것들은 앱 같아 보이지만 앱으로써 당연해야 할 것들이 미흡했음

하이브리드가 넘어야 할 장애물

1. view전환 효과

   • 쓱쓱 넘어가는

2. 터치 반응 지연 시간

   • 웹뷰 터치 반응시 300ms의 지연시간이 존재
   • single tap과 double tap 구분을 위한 설계 의도
   • 이를 해결하기 위해 fastclick.js / hammer.js 가 대표적

3. 유려한 애니메이션 처리

   • css webkit transition translate3d 하드웨어 가속으로는 괜찮지만
   • css/ javascript 는 뚝뚝 끊김 ( 모바일 쥐쥐)

4. 푸시

   • push notification
   • 소설로그인

두번째 시도

• LCC Finder
  • 반응형 웹으로 제작
  • 제이쿼리 기반
  • SPA
  • Cordova, phongap을 이용해서 pushRkwl goruf 서비스로서 가능성 증명 .
• 자신감이 생김

여러 앱을 만듬.

그 후 개선된 구축 방식

- IonicFramework로 제작
- Angular + cordova

정리..

하이브리드앱

• 구축이빠름
• 텍스트 위주는 네이티브 수준의 퍼포먼스가 보임
• Cordova CLI 이외에 앱 개발에 필요한 추가 학습 요소가 없음
• 생각보다 Cordova/PhoneGap 플러그인이 많음
• 유명한 SDK 플러그인 지원 (Facebook, Twtitter, Fabric 등)

해먹남녀 하이브리드 앱 개발

상황

• 한달뒤에 특정 기능을 추가해야함
• iOS 개발자 채용 장기화
• 내부 인력들 obj-c 개발 경험 전무
• 클라 개발 가능한 웹개발자 1명

하이브리드로 아예 새로 만들죠

정리

• 꼭 필요하지 않는 UI 표현을 과감히 포기하면 꽤 괜찮은 퍼포먼스
• Cordova/PhoneGap 플러그인중에 내가 필요한게 없으면 ..
  • 없다면.. 그건 정말 common하지않은 걸꺼임. 일단 포기를 해보자
• 앱스토어 순위에 패널티가 있지 않을까? > 그런건 나중에 고민하자

스팩 산정

• 카메라
• 푸시
• 소셜 등등
• 다 plugin이 있다.

Ionic Framework 개발 착수

• 디버깅도 편했음 ( web view에서 하면 되니까 live reload 기능)

• 다양한 ionic에서 제공하는 기능들이 많앗음

• 패키지 설치, 웹브라우저에서 아이폰 안드로이드폰 동시 개발 가능

• 도구는 도구일뿐 내가 잘 만들어야함.

제작!

화면을 제일 먼저 만듬. - AngularJS Directive

가장 고민 되었던것

1.View 전환의 위계문제

• Router를 이용해서 위계를 짜면 앙대..

2. 이미지 콘텐츠의 비중이 높기 때문에 목록이 길어지니 페이지 전환이 느려짐.

-> 모두 모달로. 위계가 없는 페이지끼리 모달을 위에 띄워서.

• 아이폰5 테스트. 6~70 페이지까지 견디고 꺼짐. 그보다 더 가는 유저는 칭찬 해줘야징ㅋ

제작 2주차

앱 내에서 데이터 sync 맞추기

• 좋아요, 스크랩, 댓글 수 등.
• sync directive : 데이터 싱크를 수행하는 diriective를 만들어 View에서 반복 호출
• 이 뒤에 불리는 modal에서는 $rootScop 레벨에 데이터를 넣어서 갱신 및 재호출.

문제!

하다보니 플러그인이 30여개

• 업데이트 하다보면 애플 디자인 가이드라인,정책 변경 등으로 리젝 받게됨

기본적으로 해야하는게 안되는게 있음 .

• 동영상 음소거 없애주세요. 백그라운드에서 켜야 하는데 애플정책에 걸려서 따로 다중 파일 같은경우에도 안되서 서버쪽에서 바꿈

3주차

• 성능 최적화

• 다양한 디바이스에서 잘 돌아가야함

• 목록 > 상세로 갈떄

• 중간에 안뜨는 것들을 허옇게뜨는게 싫어서 앞에서 어느정도 정보를 가져와서 먼저 뿌려주고 appending 되게

Infinitescroll

indicator 를 띄워서 무리한 scroll을 못하게

아이폰5

이미지 리사이즈

• 동적으로 이미지가 내려오도록
• 뒤에 뜨는 이미지같은 것들은 원래 블러였는데 완전 작은걸(40px) 받아서 up-scaleing을 처리해서 마치 블러 한것처럼

사용자 피드백 대응

• 안된다 안된다 안된다. ㅠㅠㅠ 앱은 한달만에 만들었는데 후대응은 2달이 소요.

실시간 업데이트

• CodePush 진짜 급할때

• 클라우드를 통해서 코드를 넣어주고 install

• 용량이 크면 복사하고 다운받는데 오래걸림 : 자주 사용하지 못했음.

Ionic 기본 프로젝트 폴더 구조에다가만 다 넣어버리니 1 file of controller 1 file of service

컴포넌트별로 목록을 나누는게 좋음.

cordova핵심 - config.xml 프로젝트 설정 파일

• 꿀기능들이 많음
• xcode 프로젝트 Info.plist작성 등

코드의 재사용

• 원소스 멀티플랫폼. : 앱과 웹 모두 한번에 순수 웹 개발이다 보니 웹을 만들때 70% 코드 재활용

• D3js를 이용해서 앱/웹

iCook

• 전용 동영상 플레이어 웹 앱
• 웹에서도 앱에서도 다 재활용 가능

회고 및 정리

• 네이티브 : 모듈화가 잘 된 Dell
• 내 하이브리드앱 : 용산에서 만든 조립 PC

힘듬…

방법론

제한적인 환경에서 의사 결정 방식.

• 해결이 가능 한가 > 대안을 찾는다..
• 굳이 꼭 해야하나.. 라는
• 제품이 되는게 중요한것이, 중간에 막히는건 빠른 결정과 불필요한 욕심을 버려야함.

추천하는 경우

• 작게 시작할 경우
• 현실과 타협을 잘 하시는 분
• 초기 스타트업 대안 기술로 사용하고 싶은 경우
• Html css javascript 오래 한 분
• UI 감각 센스가 좋고 꼼꼼하신 분

너무 개발자 욕심만 내기에는 돈이 없어지면... 서비스도 없어지는 것 빠르게 만들어야 함..

[5] 5년간의 네이버 웹엔진 개발/삽질기 그리고...

• 네이버 : 5년전. 지금이든 web portal

  • 이 의미 : 웹에서 생존하는 회사
  • 그 회사가 가진 기술. 컨텐츠, 프론트, 서버기술 등등.. 근본적으로 웹을 표현하는 기술이란..
  • Web platform ( == web engine)
  • 우리가 컨텐츠만 올리지말고 코어에 잇는 기술을 직접 만들자.

• 엔지니어를 모으자

  • 오페라, firefox, 크롬 사파리 ie
  • 한국형... 이라는 단어가 붙으면 하기 싫어짐.. 부정적.
  • 하지만, 한국 소프트웨어에 대한 갈증은 계속 잇음
  • os는 왜 못만드냐 db는 왜 못만드냐
  • 부제 : 대형 system software의 꿈
  • 많은 기술을 가지고 있지만 대형 system software는 우리나라 핵심이 없음

why

• 당위성은 있지만 타당한 이유가 없엇음 .
• 다시 why를 고민
  • 무엇을 얻고 싶은가. Web platform
  • 많은 사업이 플랫폼에 대한 갈증이 잇음.
  • 특성상 매우 좋아보이지만 실제로 가지기도 어렵고 정의하기도 어려움.
  • 플랫폼 : 성공한 서비스 + API
• 그럼, 웹 플랫폼이 뭐냐
  • 자체 엔진 : 크롬, 사파리, IE, 파폭
  • 변형 엔진
  • UX/ feature : 돌핀 등

Web OS

• Tizen : gear ..
• Chrome
• Fire OS

Contents

• Viewer, Renderer

특화된 것 .

• App
• Device
• Browser

App engine

• Cross platform
• hybrid
• 웹기술 기반으로 앱을 만들면 iOS/ Android
• Cordova/phonegap

Device

• Wearables, IoT, Big screen tablet

그래서... 웹 플랫폼을 만든다는 것 저 위에있는것 모든것.. 너무 큰 일..

웹 브라우저 엔진

• 그 중에 네이버랩에서 고른 것
• 엔진은 뭘 쓸까

Webkit

• 제품 : mac safari
• 단점 : 32bit 최적화 안함

Chromium

• 네이버에서 엔진을 바꾸는 앱을 배포하기도 했음. : 네이버 브라우저 엔진 for kitkat
• Higgs Engine

Mozila

• Gecko
• Servo라는 차세대 엔진, 장기 프로젝트라 가져다 쓰기 어렵

결론. 웹킷

• 결국 이걸로 골랏다!!!
• 그나마 엔지니어가 가장 많았다.
  • tizen도 웹킷 베이스 기능
• 할수 있는게 더 많다.
  • 아키텍쳐가 잘 되어있고
  • windows와 android port 부재.없음 .
  • 새로운 cross platform 시도
  • 경량화 가능

네이버에서 한것

cross platform

• 젤 처음한게 android/windows webview

thin client

• 마리오넷, 아마존 실크 등 다양한 회사가 시도 햇으나 없어짐
• 연산은 서버에서 그림을 그리는 device에 냅두고
  • 스몰 디바이스에서도 리치 해진다.
  • 서버 한대가지고 하면 되니까 다양한 디바이스에서 seamless handoff
  • 결국은 잘 안됨
• 로드맵 Higgs engine을 만들고 웹킷 > 브라우저 > 디바이스 > 앱앤진 > 웹 OS까지 만들자!!!!

브라우저

• 처음 시작은 next generation browser를 만들자!
• 기본적인 task만 뽑아도 엄청남.

네이버 웹 브라우저 엔진 : Sling

• 다윗이 던진 돌 달린 그 무기가 Sling
• 크롬과 싸우기 위해

ONIG

• 자바로만 짜면 C++쪽도 해결되도록 (cross platform)
• Posix
• 웹킷 개발에 크로스플랫폼을 고려
• Swig로
• 크로스 플랫폼 개발에 많은 시간과 노력을 절약.

크롬 좋네 파이어 폭스에 Mor2D가 좋다 MS IE의 chakracore가 좋다.

Web browser

데스크탑 브라우저

• SLING User Agent : 자꾸 맥이라고 나오고(윈도우 인데) , (옛날) Windows Safari로 인식. Unknown
  • QA를 해봣더니 이상한 사이트들이 많이 나옴.
• Open source (webkit) bugs
  • Plugin support
  • javaScoptCore : javascritp엔진

결론. 크로미움.

• 결국 모든걸 내려놓고 크로미움 베이스로……

• 제품은 기술을 자랑하는 창구가 아님. 사용자가 쓰는 것.

• 사이트가 ua를 잘못 확인해서 사이트가 이상하게 나온다던가..

장점

커버리지가 높음. 브라우저 자체의 베이스라인 이 높음. (알아서 해주는게 많음) 크로미움에도 자체 테크를 넣을 수 있음.

슬링을 버리지 말고

• 멀티엔진으로. sling tab에서 써볼수 있음.
• 웹킷 을 사용하는 사람들을 위해

Whale

• 키노트에 나왔던것
• 제품.
• 빠르고 가벼움 (크롬) -> 다양함, 기술 최신성, 커스터마이징

고민

• 익숙함을 넘을까? ie를 생각해보면..
• 체감할 수 있는 효익은 ?
• 사용자가 정말 원하는 것?

multitaking 을 계속 강요당햇던것 같아.. 이제 그 다음은 ?

Omni-taking

• 내가 한눈에서 처리할수 잇게.
• 메인 테스크가 돌아가는걸 한 컨텍스트 안에서
• Whale 의 큰 목표

투 매니 탭스 (over-tabber) - 브라우저에서 탭 넘나 많이 사용하고 잇는거 - 다 쓰고 잇지도 않은데 왜 그렇게 켜놓고 잇을까? - Ex) 쇼핑 하다보면 새로운 탭이 열고 열고 - EX) 좋은 뉴스라면서 누가 보내주면 일단 올려두고 마음의 안식으로 언젠가 봐야지 하면서 계속 탭을 늘려가게됨.

Whale space

• 창 분할처럼 보인다

• index 페이지와 contents 페이지

• 왼쪽에서 클릭하면 오른쪽에 보임임

• 학습을 시킴 ( 2번 을 누르면 2번이 오늘쪽에 뜸 >> 2쪽 누르면 왼쪽이 바뀌도록 )

밸리

• 담아놓겠다.
• 관심 있는것, 관심 가질 것, 좋아요 담아두기
• 계속 업데이트 예정

퀵서치

• 단순한거 확인할때 탭이 늘어남
• 원하는 정보만 찹이 뜨거나 스페이스 한쪽에서 나오도록

사이드바

• 퀵서치와 다른 것.
• 문맥 안에서 누구인지 (동명이인 확인) context 서치 결과

스마트 팝업

• too many 팝업

  • 팝업 블락커를 사용할수 있음.
  • 근데 불편한 일들이 잇음 로그인창이라던가 진짜 유용한 정보를 놓친다던가

• 웹브라우징을 하면 자동으로 사라지고 누르면 해당 팝업만 팝업이 뜸.

techlogies

• 파파고
• 텍스트 투 스피치
• Js engine 튜닝
• 메모리 파워 세이빙 등

장점

• 다음이라고쓰면 바로 사이트로 연결해줌
• 번역기능 등 이메일도 번역해줘
• 성인 사이트 블락은 옵션으로

디자인 : 인간적인 모던함, 좀 더 따뜻하게 기존 : 차가운 툴

• http://whale.naver.com/

• Big Pregmentation 로 만들자

질문

Q. UA가 어떻게 나오나요

• 크롬. 웨일

Q 크롬과의 동기화

• 그대로 동기화 됨
• Extention
• 크롬 익스텐션 풀로 그대로 쓸 수 잇다 .

[6] 딥러닝을 활용한 이미지 검색: 포토요약과 타임라인

• 이론보다는 어떻게 활용했는지 초점을 맞춰서

이미지 검색

• search by image : 개발중
• search by text : 텍스트 질의어로 이미지 검색
  • 이미지에 대한 description이 잘 되어 잇어야 한다.
  • 어케하면 더 잘 보여 줄 수 있을까?

이미지 description

• 이미지 인식, 언어 처리 기술 활용

  • 딥러닝을 이용하자

• 품질 개선 사례

• 인터페이스

이미지 딥러닝

• Convolution Neural Network를 활용
• Topic Modeling, 데이터 분석

문제 정의

• 대규모 데이터 및 이미지 대상 문제 정의
• ex) 블로그 1개의 제목, n개의 이미지, m개의 문장 : 12억건 (1년 이내에 생성/수정된 블로그)

이미지 검색 오버뷰

Deep learning의 역할

문서분석

• 하나의 제목/이미지와 텍스트
• 이미지와 텍스트 거리를 측정

메타 텍스트 정제

• 이미지 어노테이션 과정

• 이미지와 텍스트 페어

• 자체 엔진으로 질의 -> 도큐먼트 셋 > 텍스트 + 이미지 > 이미지 셋을 통해 > (딥러닝을 통한) 딥 피처 > 이미지 벡터 리스트 > 비슷한 이미지를 묶기 위해 클러스터링 알고리즘 > 텍스트 모델링 > 각 클러스터에 맞는 모델링 > 대표적인 워드 선정

• 특정 스팟을 해보면.. ex) 미용실, 명소

  • 컬러, 드라이, 클리닉, 염색
  • 탁사정 정자 안내판 소나무,

이미지태깅

• 비슷한 이미지 어노테이션 과정
• 위에는 unsuoervused 가 아닌 supervised leanrning 즉, 사전 학습된 모델 을 이용해서 이미지 어노테이션
• 만오천개 >어떤 클래스로 분류되는지> 이 블로그 사진들이 어디론가 분류 될꺼고 > 텍스트 모델링 >

정답 도구

• 사람의 힘에 의해서 이미지 description이 들어가는 것
• 정답 데이터를 직접 넣는게 부끄러웠지만.. 하다보니 딥러닝에서는 이 단계도 중요하다
• Evaluator가 특정 질의를 해보고 > 그 검색에 대한 딥피처를 뽑고 > 유사도 순으로 > 트레이닝 데이터로 사용되고 있음.

기존 결과중에 괜찮은 것들을 체크하게 함. 그것들을 딥피처를 뽑아내서 좋은 결과가 어떤건지를 찾아냄.

딥러닝을 이용한 이미지 검색 (사용자 인터페이스 개선)

포토요약

• 비슷한 이미지를 묶어준다.
• 맛집뷰. 포토 요약 전에 되던 서비스 >> 좀더 개선하고 싶다.>> 분석하여 이미지를 묶어주자

기술

• svm를 이용해 분류

• 음식 클래스 같은 경우에는 더 자세히 클러스터링 하고 싶다.

• 대표 키워드(자체 언어처리 이용)를 추출하여 이 워드를 텍스트 마이닝과 통계 분석을 이용해서 이 클러스터를 대표할 키워드를 꺼냄.

• 랭킹/서비스까지 확장

  • 서비스 별로 서로 다른 클러스터 랭킹
  • 식당 : 다출처 우선 (많이 언급한곳)
  • 미용실 : 시술사진 (어떤 시술을 하는지)
  • 명소 : 대표 이미지 유사도 우선 (이미 대표사진을 가지고 잇으니 그 명소와 가장 가까운 것들을)

VGGNet Finetuning

• Food101데이터 : 음식사진 데이터셋

• 요리가 확대된 이미지에대해서는 품질이 좋음

• 요리가 아닌 이미지에 대해서는 클러스터링 품질이 좋지 않음. (간판이라던가..)

• 이미지 분석과 텍스트 마이닝 조합이 강력하다. 딥러닝을 잘 이용하면 적은 데이터로도 학습을 통해 좋은 결과를 얻을 수도 있다. Unsupervised <-> supervised learning을 이용하여 사람의 손을 안타더라도 트레이닝이 계속 되도록

타임라인

• 연예인 사진을 좋게 보면 얼마나 좋을까로 시작

Ex) 인물과 식당.

• 인물 : 같은날, 같은 장소가 찍어도 다르다
• 식당 : 시간이 지나도 같다

이벤트를 타임 라인으로

같은날/같은 장소면 머리나 스타일이 비슷비슷

• 이미지를 이벤트 별로 묶어서 시간순으로 제공

스타검색/이미지 서비스로 나가는중

이벤트를 찾는것 event detection

• 소셜 이벤트 디텍션
• 같은 이벤트로 문서를 클래스로 묶어주는것
• 어떤 이벤트를 보여줄 것인가

이벤트

• 의미가 있는 event
• ex) 시상식, 공항패션, >> 고유한 성격이 잇을것 (X) 열애설 >> 대부분 프로필 사진을 가져다 놓는 경우가 많으므로 큰 의미;가 없음

Ex) 포토뉴스 데이터 - 제목이 짧고, n개의 이미지, m개의 문장 - 서로 다른 어휘, 기자님의 사소한 실수(오타, 이름 헷갈리는것) >> 이런 노이즈도 감안해야함

데이터 전처리

• 데이터 클랜징 : 짧은 문장에서 의미있는 단어를 뽑아낸다 (네이버 자체 엔진을 이용)

분류

• 메타데이터, 본문의 단어와 기존에 정의된 이벤트와 매핑

• Doc2Vec feature

  • 같은 문맥안에서 같은 의미
  • 같은 이벤트라면 같은 의미가 잇겟지?
  • 문제 발생! 이벤트는 같아도 기사의 목적이 다른 경우가 있음. ( 이미지만 목표기 때문에 이벤트가 같다면 묶고 싶다)

• Visual Feature

  • 같은 이벤트라면 옷차림/스타일이 비슷하지 않을까?
  • 다른 이벤트라도 비슷하게 입을 수 있다
  • Ex) 시상식 - 남자 다 턱시도 입음

중요 task

• 단어 자체가
• 이미지 유사도

다양한 사진을 어떻게 정리하나

• Visual feature : AlexaNet 이용
• 이걸 가지고 클러스터링 (k-means clustering)
• 처음엔 얼마나 클러스터링 될지 모르므로 일단 임의의 k를 잡고 > 중심과의 거리가 멀어지면 삭제하고 재 정의한 central로
• DB

잘 묶이긴 하는데 너무 비슷해서 중복되고 지루하다.

어디까지 보여줘야 하나가 중요해짐 >> 랭킹이 중요

최대한 다양한 리소스로 랭킹을 묶자.

• 클러스터 간의 랭팅
• 각 클러스터 내에 잇는 것들로도 랭킹

이미지 설명문 찾기

• 클러스터의 가장 중심에 잇는 문장을 선정

서비스

• 이벤트 카드
• 이벤트 데이트
• 디스크립션
• 이미지 : 너무 많으면 피로도 증가 및 최대 30개 정도로 제한에서 ( 너무 겹치면 비쥬얼 디텍팅을 통해서 정제해주고 잇음)

Event Card 역시 search by text

• 단어와 메타데이터를 이용해 clustering keyword를 찾을 수 있다 .

서비스를 만들고 싶엇고 그걸 하기 위해서 어떤 기술을 있는지

• 가장 좋은 성능을 내는 기술을 선정하고 활용하는가 에 집중해야한다

• 짧은 데이터, 오류가 많은 데이터를 이용해보았다.

• 딥러닝/딥피처를 어떻게 활용하느나에 따라 텍스트 /이미지

[7] 딥러닝과 강화 학습으로 나보다 잘하는 쿠키런 AI 구현하기

딥러닝 + 강화학습

딥러닝

• 뉴럴 네트워크: 인간의 뇌구조를 활용하여 이용하는 것

강화 학습

• Reinforcement learning

학습

1. 지도학습
   • 학습 데이터가 있을때 정답 ㅇㅇ
   • 분류
2. 비지도 학습
   • 학습데이터가 잇는데 정답이 없음
   • 상관 관계를 학습
   • 클러스터링
3. 강화 학습
   • 분류도 군집도도 아닌것

Ex) 로봇 걷게 하기

• 막 랜덤으로 관절을 움직이게 되면 못움직임 계속 시행착오를 통해 배운다 > 정답이 없음

목표

• 쿠키를 오래 뛰게 하고 점수를 많이 따도록

• 장애물을 피하고 쿠키를 먹기 위해 뛰고

• 행동 주체 agent = 쿠키 행동을 취하는 공간 environment = 바닷가 들판 등 환경이 주체에게 주는 영향 State >> 행렬로 만들 수 있음.

이런 state를 통해 행동을 결정한다. State > 뉴럴 네트워크로 들어오고 가장 적절한 행동하는것을 뽑아낸다 ex) 점프를 한다. 이를 통해 Action을 하게되고 점수를 타게되면 양수의 리워드를 주고 틀리게 햇으면 음수의 리워드를 돌려주어 학습 시킨다.

체력이 깍이게 되면 음수 리워드를 줘서 다른 행동을 예측하도록 학습 시킨다.

목표를 달성할때까지 계속 .

DL + RL로 뭘 했을까? alphaRun이라고 하는 것을 만듬 .

• 계기 : 알파고를 보고 알파런 프로젝트를
• 기술발전이 있다면 이걸 쿠키런과 융합시키면 더
• 스스로 달릴수 잇다 > 게임 밸런싱을 자동으로 할 수 있다

밸런스 팀

• 게임 밸런스를 맞추기 위해
• 다양한 쿠키 , 펫, 보물, 맵을 가지고 잇음 -> 다양한 조화가 필요
• 평균 플레이 4분 > 모두 다 하면 5040일이 걸림

AI가 플레이를 하면

평균 플레이 4초 : 단일 프레임에 제한시간이 잇지 않음 1개 6프로세스면 14일이 걸림

지탱하는 기술들

Q(s,a) = 기대되는 미래의 가치 Q Action = 점프, 슬라이드, 가만히 Q 가 가장 높은 행동을 을 선택한다.

쿠키런의 가치 : 점수

Q > 쿠키런의 점수 . 미래의 점수의 합

Loss를 계산. 더블큐 러닝

가끔 하나씩 놓치기도 하고 가끔 이상한 행동을 함. (가만히 잇으면 되는데 그냥 막 뜀) 2. 더블 큐 러닝

• 미래의 가치

loss = (예측 - 정답 )제곱 > 0에 가깝도록 학습 학습 처음에는 거의 0에가깝다(Q값이 둘다 0에 가깝) 가 예측값이 높아지고 정답도 올라가게 된다.

우리가 예상하는것보다 더 높아짐 Q는 계속 발산하게 되는데 어째뜬 로스는 계속 작아져서 예상 못하는데로 튀게 됨

더블큐 러닝 : 너무 커지지 않도록 사용되는 기술

• Q값은 확실히 작지만, 점수는 확실히 높다.

오오오 잘되 근데 새로운 랜드로 들어가니 더 다양한 장애물과

• 속도가 빨라지면 막 점프함. ( 이런 경우가 학습 경우가 적어서 잘 못함)
• 보너스 타임 그냥 막 쩜프만함.

3. 듀얼링 네트워크

• 막 상황이 바뀌어서 정확한 Q를 예측하기 어려울때 ( 10인지 1인지)
• 꼭 정확하게 예측할 필요가 있을까?

슬라이드를 x라는 기준값을 줫을때 점프를 했을때 x+1인지 가만히 있을때 x+2인지를 확인해서 대강적으로 액션을 취한다.

하나의 기준을 두고 그 차이를 비교하는게 더 쉽겟다

Q = V + A(s,a)

딥 큐네트워크 + 듀얼링 네트워크 하나를 더 추가 V가 예측을 잘 못하더라도 A가 잘해주게 되면 잘 학습 할 수 있음

Max 듀어링을 선택함. 상황이나 뭐 다른거에 따라 달라질 수 있으므로 이게 정답은 아니다.

그래도 안된다면

엔지니어링

1. 하이퍼파라미터 튜닝

• 학습에 필요한 파라미터들을 바꿔본다.
  • 네트워크 바꿔보기, 옵티마이저 바꾸기, 리워드식 바꾸기
  • 젤리를 먹엇느냐가 아니라 젤리를 얼마나 놓쳣느냐 등
  • 70개가 넘는 하이퍼파라미터들이 나왓다.
• 너무 많으면.. 과유불급
• 성능은 올릴수 잇지만, 끝이 없어서 힘듬
• 고정 시킬수 잇는 변수는 정해서 건드리지 않는다.
• 랜드, 쿠키를 정해두고, 하이퍼 파라미터를 정리하고 돌림.
• 텐서보드를 사용하는군

2. 디버깅

• 딥러닝은 디버깅이 어렵다.

• 네트워크가 정확히 어케 판단하게 된건지 알수 없다.

• 쿠키가 이상하게 행동하는데 이유라도 알려줬으면….

• state 히스토리를 남겨둔다.

• 듀얼링 네트워크 값 V, A를 로그를 남겨둔다

Ex) 해결한 예제

• 모든 액션에 대한 Q값이 0이엿음.
• state 값을 바꿔가면서 출력을 해봄 > QV가 바뀌지 않음.
• Activation function을 None으로 해줌. Default nn.relu

시도 해봣다면 좋앗을 디버깅

• state를 실시간으로 수정하면서 > 변화보기 Ex) 젤리를 쿠키 앞에 그려보며 변화를 확인

Exploration을 어떻게 하고 있는지

• Exploration : 액션을 랜덤으로 해보는 것. 탐험을 해보는 것. 이걸 해봣더니 더 점수가 좋으면 그걸로 학습한다

• Reward는 제대로 학습 될 수 있도록 정해져 있는지

• ex) 부스트 아이템을 먹는지. 리워드가 없으니 안먹는다. 같은 리워드를 줬다.

• 반복되는 실험의 학습 시간을 단축 시켜야 한다.

• -> 학습한 네트워크의 weight릏 저장해 나중에도 그 weight을 쓰도록

• -> 더 높은 점수를 얻을 확률이 높다.

4. Ensumble method 앙상블 메소드

• 여러가지 실험을 통해 얻은 모델들에게 같은 S를 넣어서 그것들을 조합해서

• 하나의 실험으로 만들어진 여러 weight를 동시에 로드하면 ? Ex) 가장 잘한건 보너스 타임을 잘햇는데 두번째 잘한건 젤리를 잘 먹는다. 하나의 실험에서 얻은 것이지만

텐서플로에서는 앙상블 메소드를 사용하기가 어렵

In 텐서플로

• 왜냐하면 세션 아래에 그래프가 있는데
• 같은 이름의 노드는 하나의 그래프에 듀개 이상 존재 할수 없음.

그럼 그래프 두개를 그린다? 이것도 안대 한 세션에서는 하나의 그래프만 존재

고로 세션2 그래프 2개 로 해야한다.

텐서플로 코드 예제

이러한 방식으로 보너스타임만도 학습. 네트워크 두개를 만들어 보너스 타임일때 일단 게임 모드일때따로따로 보너스타임에는 장애물이 없으니 한번만 학습 시켜도 댐. (시간 단축)

밸런싱 자동화 하기

• 쿠키를 바꿔가면서
• 펫을 바꿔가면서 성틍 차이를 확인 사람이 하면 한시간 > 1분내로 결과를 뽑아 낼 수 있다.

[8] Backend 개발자의 Neural Machine Translation 개발기

기계 번역

• Rule based machine translation (RBMT)
  • 두 언어의 문법 규칙 기반으로 > 성문 문법 을 직접 프로그래밍
  • 그게 쉬운 일이 아님.
  • 한국어 영어, 한국어 프랑스, 한국어 일어 >> 확장성 어려움
  • 기계번역 초기에는 이렇게 많이 사용

통계 기반 번역 SMT

• 한국어 번역, 영어 번역을 동시에 나타나는 것을 통계내어서 번역을 수행
• 언어 구조가 비슷한 경우 좋은 성능을 내고 있음

뉴럴 머신 트랜스레이션 (NMT)

• 뉴럴 네트워크 기반의 머신 트렌스레이션
• 한국어 영어에도 좋은 성능을 내고 잇음

NMT 구조

입력 > end of sentence (EOS) 넣고

Encoder와 Decoder로 구성

• 벡터화된 문장을 타겟문장으로 디코딩
• 반복반복

주요 NMT

• Stacked LSTM : Google Brain팀
• RNNEncDec / RNN Search : NYU 조경현 교수님 가장 많이 참고되고 가장 논문에 많이 레퍼러 됨

개발에 앞서 어떻게 학습하였나

1. Word2Vec
   • 옛날엔 괜찮은 뉴럴 네트워크가 없엇음
   • 워드를 벡터화 시킨다.
   • 앞 단어와 뒤 단어를 학습해 뒤로올 단어를 예측 확률 극대화 시키게 그 과정에서 Word Vetor들이 조정 됨 > word embedding
   • Man - woman
   • Uncle - aunt
   • King - queen
   • 이와같이 비슷한 관계를 가진 단어들 = same vector

Bilingual word embedding을 하고 싶엇음 Uncle - 이모 이렇게 하고 싶엇는데 잘 안됨 >>그래도 뉴럴 네트워크 워드 벡터에 대해서 이해를 하게 되었음

KSTM LM - 네이버에서 만든 랭기지 모델 - 랭기지 모델 : 문장의 생성 확률 분포 ○ Real world의 문장 분포를 기반으로 확률 분포 계산 ○ 엄마는 아기를 매우 (사랑한다) - 이 경우 너무 많아.

N gram language model N-1개의 이전 단어 열을 이용해 다음 단어를 예측하는 방법

• 다음 올 단어에 대한 확률을 근사값으로 계산 할 수 있다.

RNN 이 적용되기 시작 문장의 단어가 순차적으로 들어가면 네트워크로 반복적으로 들어가게되고 다음 나올 단어를 예측.

LSTM : long shor term memory 1보다 작은 값을 자꾸 계속 하게되면 0으로 수렴해서 희석되서 사라짐 >> LSTM을 통해 완화됨. - 단기 기억을 오랫동안 - 구성 : input gate - / forget gate - / output gate - / cell - , hidden output

소프트맥스 레이어를 더 올려서

개발 과정

Stacked LSTM 기반 NMT

• 인코더와 디코더 디코더에는 가장 상위에 softmax layer

NMT vs LSTM

• NMT
  • 인코더 + 디코더 구성되어있음
  • 변형 LSTM
  • 인코더 :

개발하려고 할떄... 막막해서 찾아보니 슈스케? 분의 동영상을 봄

1단계 : 임력 문장 재생성 하기 : 입력 문자를 인코딩하고복호화 되도록 다시 디코딩

-- > 영어로 인코딩 한다음에 독어로 디코딩하니 번역도 되더라 -- > 만약 인코딩하는 부분이 그림이라면 description이 디코딩 될 것.

2단계 : Small parallel Corpus로 작은 NMT만들기

• 작문에 취약 -작은 코퍼스는 괜찮지만 대용량은 퍼포먼스가 안나옴

3단계 : 퍼포먼스 향상을 위한 개선

학습속도를 올리기 위해 multi-GPU (ref stacked LSTM 논문에 나오는데로 구현해봄) 멀티 패러렐 로 돌리면 학습시간 단축 .

계산량이 가장 많이 드는건 softmax쪽 5만개 단어 - 1000차원 == 매트릭스 5만 * 1000 이 연산을 하려면 맥트릭스 연산의 크기는 매트릭스 5만 * 1000 * (1000 * 1 ) 이 필요함.

--> Vocab 개수 증가하면 계산량 증가

• 해결책
  • 일부만 샘플링 하여 학습
  • 텐서플로에서는 타워 모델 / 발표자는 요거 안쓰고 샘플링 방식
  • 계산량도 줄이고 , 실제로 결과값도 잘 나왓다

####4단계 : Attention

• 작문에 여전히 취약점이 있음.
  • Attention Layer를 추가 b4 softmax
  • 타겟 word생성시 어떤 소스에 포커스를 맞춰서 생성해야하는지 알려주는 모델

어텐션을 구축하게 되면 어텐션 맵이라는게 나오는데. Ex) jon loved Mary. -> jonn은 noun으로 매칭이 높에 나옴.

##N2mt ###소개

• 네이버 뉴럴 머신 트랜스레이션
• NSMT 2세대 머신 트랜세션
• 자체 기술 개발 (no open source)

내가 지각(late)했다는 것을 지각(perceive)했을때 너무 늦었다(late). 잘 되는 예문 ㅋㅋㅋㅋㅋㅋㅋ

실제 파파고앱에서 직접 사용해 볼 수 있다. Labspace NMT ?

정량적 평가

- 평가방법 BLEU
- 이거 1점 올리기가 겁나 힘듬.

정성적 평가

• blind test
  • 거의 2배정도의 향상

번역 결과의 주요 특징

• 완전한 형태의 문장을 생성 // 예전에는 비문이 생성되는 경우가 있엇음.

• 영어 관사/ 한글 조사 등 잘 사용함

• SMT 대비에 많이 우수

• 단점 : 번역결과가 틀리면 아예 딴소리를함

softmax쪽에 계산량이 너무 많아서 vocab 갯수에 제약이 생김

마무리하며

• 딥 러닝 개발자가 많이 필요함

• 노력 하면 기존 개발자도 진입할 수 있다.

• 꼼꼼해야함. 버그가 잘 안보임. 에러나면 잡지뭐 이런식 개발하게되면 어려움 ..ㅠㅠ (난데..)

• 학습을 막 돌리면 나중에 어디서부터 잘못됫는지 알기 어려움 많은 인내심이 필요. 시간이 오래걸림.

• 코드량이 많이 줄어듬

• 팀 빌딩

  • 하모니가 중요. 여러가지 주특기를 가진 사람들이 함께 잇으면 더 강력!
  • 파파고팀 = 기계번역 + 뉴럴 네트워크 전문가 + 시스템 전문가

• 뉴럴 네트워크 = 러닝 코스트가 좀 들지만 서비스를 구축할떄 누구 보다 더 유리하다

[9] 네이버 콘텐츠 통계서비스 소개 및 구현 경험 공유

intro

개선 배경

• 설문조사를 통해 개선 사항을 모아봄
  • 오늘 지표에 대한 실시간 통계
  • 게시글 별 통계 (기존엔 유저에 대해서만 나옴)

어려움

• 레거시 통계 시스템

• 주로 배치 작업에 치중 되어있엇음.

• 툴이 너무 많은데 어떤 걸 선택해야하는지 어려움

• 안정적 서비스에 대한 경험 부재

• 째뜬 오픈함.

• 카페에서도 통계 시스템을 사용 할꺼임(내년에)

overview

• 가장 기본적으로 로그를 수집함
• 언제 어떤 사용자가 어떤 컨텐츠를 소비햇는지 기록

통계결과

• Metric : 조회수/ 방문수 / 방문자 수 등
• Demension

계산 방식

• 사람 별로 where 유저로 group
• 배치 : 필터조건 수에 로우수가 너무 많으면 그룹바이 비용 상승.
  • 제공단위 시간단위로 미리 계산
• 리얼타임 : 지금 수집되고 잇는 정보. 미리 계산 노노해

규모

• 로그
  • 1일 수억 로그
  • 1일 수천만 유저
  • 1일 수천만 게시글 조회
• 질의:
  • 1일 수억

보는것도 다 통계시스템에서 제공

아키텍쳐

• 빅데이터 기반에서 realtime/ batch 데이터 처리 설계

• twitter 나탄 와치? 라는 사람이 람다 아키텍쳐라는 설계를 함.

• 처리해야할 로그 데이터를 배치와 speed layer에 모두 보내고

• 서비스 결과는 질의 단에서 배치와 realtime을 묶어서 결과를 내놓는다.

• 빅데이터 /

• 각 파트마다 다양한 오픈 플랫폼들 존재

• 로그 스태시 등등등 겁나많드아아아아아 ㅏ

• 그나마 경험이 많앗던 플랫폼 시스템들로 만들기 시작

• 햇다가 더 좋은 성능이 잇으면 바꾸기도 하고~

네이버 아키텍쳐

• 배치 : 스파트 SQL
• 리얼 : 스파크 스트리밍
• 질의단 nodejs

lessons learned

• 시스템을 안정적으로 하기위한 노력

• 집중해서 해결해야할 것들을 선정해야햇다.

• 로그 중복 없이 처리하는 부분

• 로그량이 증가하게 되면 병렬로 처리할 수 있게

• 배치

• 빠르고 쉽게 배치 통계를 만들 수 있게

• 쿼리 체크 파트

  • 서비스 (사용자입장에서 ) 응답속도를 빠르게 하기 위해
  • 운영 서버 통합 모니터링 할 수 있도록

Exactly-once

• 로그를 정확하게 한번 처리하도록

• 엔진엑스 최초 로그 아이디 발급

• 둥간 로그스태시 카프카 등을 이용해서 유실없이

• 최종은 엘라스틱에 id에 엔진엑스에서 발급된 로그 ID로 매핑

• 하나씩 다 찍으면 좋지만 그렇게 하면 비용이 너무 많이 듬.

logstash

• 엔진엑스 로그를 받아서 카프카 분산 큐에 넣는 역할
• sincedb라는걸 따로 관리. 로그스테시가 재시작 하더라도 올바르게 재처리 할수 잇도록
• 대부분 일자별로 하게 되는데
• 새로운 날자로 넘어갈때 유실이 발생하지 않도록. Start_position = beginning 으로 설정해줌.

Kafka

• 로그 유실이 없도록.
  • acks option 을 all
• retries 값을 설정

Storm

• 부하가 많은 경우 로그 유실이 있다. << 앙대!!!!
• 처음 쓸때 많은 삽질을 했다.
• entry를 잘 받앗어 ack라는걸 알려주면 한다던가.. 째뜬 그리햇어야 햇는데. 자꾸 유실댐. > 그만 사용하자.

Spark streaming

• 로그량이 많을때도 쉽게 잘 되었다.
  • Kafka direct api fmf tkdydgotj
  • 데이터를 담아주면 elasic 에 쓰기 시도.
  • 전체 흐름은 주키퍼 를 통해 offset을 직접 관리

분산/병렬 처리

로그 스태시

• 필터단계에서 로그를 받게되면 그 여러 필드에서 추가적으로 정보를 포함한다던가 처리를 해야하는게 잇을때.
• 쓰레드 갯수와 필터쓰레드 갯수를 같이 해주면 병렬 프로세싱 극대화 사용 가능

카프카

• Topic
  • 메세지를 저장
  • 다수의 물리적인 파티션에 저장됨
  • producer와 consumer 입장에서 병렬
  • 로그스태시는 >> 여러 파티션에 넣고 >>
  • 균등하게 메세지 전송 하길 원했으나.. Message_key를 잘 명시 안해주면 하나에만 넣더라... (default hash가 음슴)
  • 원래 방식 하나에 쭈우욱 넣고 그 다음 파티션에 꾸우욱 넣고

스파크 스트리밍

• 워커(논리적) 갯수
  • 원하는 throughput이 나올때까지 갯수 계속 증가 시켜도 됨
  • 올렷는데도 내가 원하는 퍼포먼스가 안나온다>>> repartition을 해줄수 있음.
  • 리파티션이라는 추가 비용을 더 쓰는거임. : 이게 정말 좋은지는 테스트 해서 병렬성을 확보해야하는거임.
  • 어떤 잡에 따라서 워커 갯수를 늘리는게 좋은지 다르다
    • IO bound가 크면 워커를 늘려도 성능 변화 별로 음슴

Elasic search

• 저장단
• 내부적으로는 index ( table 같은거 논리단위) >> 샤드 단위로 쪼개짐
• 질의를 하는 질의쪽과 넣는 색인 쪽이 있는데 샤드에 따라 병렬성이 달라짐
• 클러스터에 샤드를 운영하는 코스트 vs 샤드 병렬성에 따른 코스트

Aggregation 최적화 (배치)

• 처음에는 M/R(맵리듀스)로 개발 하다보니 스팤이 좋아보인다

스파크SQL

• 개발이 쉽다.
• SQL 로 표현이 쉽다,
• 통상적인 DB sql 처럼
• 퍼포먼스도 좋음. ( 메모리 기반)
• 대부분 MR코드를 SQL로 표현
• 재방문율 구하는게 좀 복잡햇음. >> 어쨰뜬 잘 해서 SQL로 잘 풀어냄

Elasticsearch vs parquet

초기에는 엘라스틱 쓰다가 배치 데이터 가져오는걸 parquet colum db라는걸로 바꿈

배치 처리에는 파켓이 더 적합

• ES hadoop이라는 걸 통해서 전체를 읽어왔엇는데
• 컬럼 디비인 파켓을 사용하게됨.

응답속도 최적화

###엘라스틱 서치

routing

• 분산하지말고
  • 특정 샤드에만 넣고 특정 질의만 처리하게되면 오히려 처리량이 증가 (routing) but 데이터 량이 많으면 분산하는게 더 나음.
• 특정 사용자 기준으로 사용했음. 질의 처리하는 양에 따라서 다르다

복합 필드.

• 공통적으로 질의 필드에 대해서만 사용하게 되면 성능향상을 노려볼 수 있음

execution_hint

• ordinal : 스트링 필드같은 경우에 생기는 필드 값.

• 별도로 지정하지 않고 map으로 처리하면 ?????????

• 특정 질의 패턴을 ordinal을 쓰지 말고 map을 쓰면 더 나을 수 있음.

• 데이터가 큰 경우에 ordinal 순서처리를 잘하고 질의를 잘해서 빠름

• 서치가 아닌 쿼리(매핑방식) 별로 데이터가 안될땐 map이 더 나음

Java GC

• 다량 데이터가 es 입수시 풀 GC가 일어남

• CMS GC를 쓰는데 ... aompaction 때 STW가 나타남

• 최대한 풀gc는 없애야하는 상황

• 힙 객체들이 영 영역에서 올드 영역으로 이동할때 객체 이동하면서 sirvivor 영역의 크기가 작아서 GC가 일어나면서 문제가 발생 늘려서 cg를 좀 제거 햇음

그래도 간간히 생김

• compaction 자체를 없애야 하는거임.
• 월간데이터 입수 후에 문제가 생겻던걵디 월간 데이터 수집 후에는 껏다 켜줘용

캐시 정책

• Batch 결과 캐시

  • 대체로 길게

• real time

  • 캐시를 안하거나 비교적 짧게 하거나

• 실시간 조회수는

  • scoreboard

• 리얼타임에서 집계하기엔 너무 많음

  • n-base-arc 메모리 DB를 이용해 조회수 ++

확장성과 가용성

• 성능/ 처리

• 각 플랫폼의 특징을 이해하고 최적화를 해야한다.

• Elastic 추가 서버를 넣으면 자동으로 분산

• 카프카/ 하둡은 추가 서버를 넣으면 수동 으로 분산

• 각 특징에 맞게 잘 맞춰야 한다.

availability

- 이중화를 적절히 적절히

운영

• cloudera 배포본 사용
• 시스템 설정 및 모니터링을 편하게 함
• 각 구간별로 data가 잘 흐르는지를 Lag 모니터링

spark 메모리 오류

Off-heap 메모리 를 기본값보다 큰 값으로 설정하면 메모리 초과 오류가 적어짐.

• Elasricsearch : alias

  • 결과 작업이 끝난 index에 대해서 서비스 노출 가능
  • 잘못되엇을떄 롤백도 용이

• 엘라스틱 샤드는 어케 나눌 것인가

• 문서 갯수를 기준 >> 운영하는것보다 더 많아짐

• 샤드 크기 기준으로 변경 >> 어짜피 이미 그룹바이 된 결과라서 문서내에서 가져오는게 어렵지 않음. 운영가능한 숫자정도로

elastic 보안

• 아무나 와서 혹은 api로 해서 delete 해버릴수 잇음.
  • 기본 기능이 없어서 (유로 외부 서비스들이 있긴 함)
  • 그래서 네이버는 nginx basic auth 설정을 통해서 보안 설정을 해줌

정리

• 많은 오픈 소스가 있지만. .
• 어떤 라이브러리를 통계 시스템으로 써야하는가
• 자신의 use - case에 맞게 사용하는게 좋음. ( 정답이 있는게 아님)
• 테스트를 통한 검증이 필요하긴 하쥐

질문

Q. 평균적인 es 시간

• 초당 수천 요청량
• 수백 ms정도로 응답
• 조회 기간이 늘어나더라도

Q. 서버 한대 스팩?

• 96기가

[10] 딥러닝 예제로 보는 개발자를 위한 통계

• 작년 : 좋은 데이터 를 뽑으려면…. 데이터 마이닝 관련해서
• 머신러닝, 데이터 마이닝, 통계를 적절히 잘해야 분석을 잘 핤 ㅜ 잇다.

1. Data mining
   • 문제를 푸는데 특화
   • 네이버 연관 검색어. 해결한 문제가 많다.
   • 하지만 안풀리는것도 많다
2. 머신 러닝
   • 역사가 오래되다보니 광범위함 ㅋㅋ
   • AI는 모든 컴퓨터 사이언스다.
   • 이 안에 딥러닝이라던가 등등등이 있다.
   • 네이버 랭킹
3. 통계
   • 통계 하나로 푼 문제는 별로 없다.
   • 데이터 마이닝과 머신러닝을 함께 해서 푸는 방법

통계가 왜 필요한가?

• 머신러인 K-means 평균값 구해서 그 중심을 옮겨가는 식
• 데이터마이닝 : Conditional probability

Deep Learning in ML

• 딥러닝은 운명. 꼭 해야해..
• relu 덕에 딥러닝을 통계적 관점에서 보게된 첫 시작!

ReLU 의 정체

• hinton 교수

• 양수면 값을 위로

• 통계 배울떄 봣엇어 이거! - 이것은 통계랑도 관계가 잇을 것이다.

• sigmoid 자리에 다른 함수가 들어가도 된다.

• non- linear하게

Generalized linear model -통계에서는 굉장히 익숙한 모델

통계에서는 이미 있는 함수인데 머신러닝 함수에도 다 매핑되는 게 있음 .

머신 러닝

• Drop out(2015)

  • 데이터 갯수가 100개인데 추정해야할 weight이 100개 이상이면 문제가 생긴다.

• 통계에서는 이미 1988 년에 잇엇음.

  • Pike and slab
  • break through

• 딥 가우시안 mixture

  • 딥러닝을 통계적 시점으로 보면서 눈이 띄임

어떻게 통계를 공부를 했는가

• 통계 공부... 고통 그 자체
• 베이지안 통계추론 - 네이버 검색 랭킹도 저걸로. 겁나 어려움. 가우시언믹스쳐를 알고는 있지만 사용할수 없을 것 같앗는데.
• 네이버에서 실제 상황을 느껴볼 수 있엇음

통계 (발표자가 생각하는 개발자가 알아야할 통계)

• 기술통계
• 회귀 통계 *
• 분포 통계 *
• 검정통계

기초통계

• 송중기가 어떻게 생겻나
  • (평균) 잘생겻네
  • 눈은 어떻고 코는 어떻고 media… 데이터가 어떻게 생겻는지 알고 싶다.

분포 통계

• 이게 제에에일 중요하다고 생각한다

• drichlet 드리쉴레

  • 다항 분포와 관련

• 분포의 관계로 부터 출발한다.

  • 지금 분포 구조를 이렇게 생각하신답니다 § 동전던지기 : 베르누이 분포 >> 여러번 : 이항분포 >> 무한번 :정규분포 ...
    • 주사위 던지기 >> 여러번 : 다항분포 >> 다변량정규분포

LDA

• 분포구조를 잘 알고있느냐가 중요함.

LDA를 책으로 공부햇으면 몰랏을꺼다. 네이버에서 어쩔수 없이 적용하게 되면서 알게됨

회귀 통계

• 각 feature의 weight 학습

• 제뉴얼라이즈드 리니어 모델 (첨에 말햇던 그것)

• 노출되는 랭킹과 클릭수와의 관계

• 지수 분포를 이용한 리니어 분포 모델..

• 데이터 마이닝이나 머신 러닝을 할떄 통계를 알면 많은 것들을 영감 받을 수 있다 .