DEVIEW 2017 참석 후기

1. Overview

• NAVER 주최 개발자 컨퍼런스 DEVIEW 2017에 참석하고, Day1, Day2에 참석한 Session에 대한 리뷰입니다.
• DEVIEW 2017은 2017년 10월 16일(월) ~ 2017년 10월 17일(화) 양일간, 서울 COEX Grand Ballroom 에서 개최되었습니다.
• DEVIEW에 대한 자세한 내용은 https://deview.kr 에서 확인 가능합니다.

012345678910

2. Schedule

2-1. Day 1

• 2017년 10월 16일(월)

시간	주제	발표자	발표자료 링크
10:00 ~ 10:40	키노트	송창현 NAVER LABS
11:00 ~ 11:45	책 읽어주는 딥러닝	김태훈데브시스터즈	설명  발표자료  음성합성 데모
12:00 ~ 12:45	Clova Platform: 인공지능을 엮는 기술	정민영NAVER	설명  발표자료
14:00 ~ 14:45	동네 커피샵도 사이렌오더를 쓸 수 있을까?	허형삼성전자  나동진 Lunch class	설명  발표자료
15:00 ~ 15:45	TABS 넌 누구니?	이창선LINE	설명  발표자료
16:00 ~ 16:45	머신러닝으로 쏟아지는 유저 CS 답변하기	김동화데브시스터즈  김범준 데브시스터즈	설명  발표자료

2-2. Day 2

• 2017년 10월 17일(화)

시간	주제	발표자	발표자료 링크
10:00 ~ 10:45	HBase 기반 검색 데이터 저장소	박범신NAVER	설명  발표자료
11:00 ~ 11:45	MIST: 고성능 IoT 스트림 처리 시스템	엄태건서울대학교  이계원서울대학교	설명  발표자료
12:00 ~ 12:45	의료 AI를 위해 세상에 없는 양질의 Data 만드는 도구 제작하기	김상근뷰노	설명  발표자료
14:00 ~ 14:45	네트워크 모니터링 시스템(NMS)을 지탱하는 기술	강영상NAVER	설명  발표자료
15:00 ~ 15:45	빅데이터를 위한 분산 딥러닝 플랫폼 만들기	유승현NAVER	설명  발표자료
16:00 ~ 16:45	네이버 검색 사용자를 만족시켜라! - 의도파악과 의미검색	최재걸NAVER	설명  발표자료

3. Review

3-1. Day 1

3-1-1. 키노트

• DEVIEW?
• DEVIEW는 기술생태계를 유지하는 데에 기여하고 있다.
• DEVIEW 2017도 신청자가 많았고, 첫쨋날은 32초, 둘쨋날은 15초에 마감되었다.
• 참가 인원은 양일 2700명 이다.
• NAVER D2프로그램(개발자들의 지식과 경험 공유) 중 하나이다.
• 오픈소스가이드
• Startup Factory : 2년간 1800개 검토하고, 16개 투자함(작년 400억 투자)
• NAVER LABS
• "기술이 생활속으로 사라졌을 때 가 진정한 기술의 가치 실현이다." 라는 모토로 기술 개발중이다.
• 기술력 확보를 위해서 작년에 제록스 유럽을 인수 하였다.
• 프로젝트
• Ambient Intelligence
• 사람이 원하는 위치, 시간에 적절하고 정확한 정보를 제공하는 네트워크 기반 서비스이다.
• 정확한 답이나, 답이 들어있는 문서를 찾는 것이 핵심이다.
• 서비스
• 스마트렌즈 검색(스마트폰 카메라 검색) 서비스
• Clova(구 AMIOKA) 음석인식 추천/실행 서비스
• Papago 번역 서비스
• 정식버전 출시됨
• 5000자 번역
• 사전기능
• 10개 언어지원
• 스마트키보드에 적용
• WHALE 브라우저
• 100만 베타
• 영어 지원
• 벨리(스크랩북) PC와 동기화
• 번역 지원
• 보안성 높음
• 12월 정식 버전 출시 예정
• Location Intelligence
• 실내/외 위치 확인 
• AKI 아이용 시계
• 위치 개인화
• 위치 알림
• 전화 기능
• 개인화 서비스(나를 알아주는 서비스)
• AWAY in-vehicle infotainment 플랫폼
• 2017년 말에 출시 예정
• 자율주행
• 전동스틸
• 40Km/h 속도
• AROUND 저렴한 자율주행
• M1으로 위침 맵핑 데이터 생성
• 클라우드 서버에서 자율주행 데이터 전송
• AIRCART 쉬운운반
• AMBIDEX 사람의 팔 같은 로봇

3-1-2. 책 읽어주는 딥러닝

책 읽어주는 딥러닝: 배우 유인나가 해리포터를 읽어준다면 DEVIEW 2017 from Taehoon Kim

• 모티브는, 유인나가 해리포터를 읽어준다면~?(정말좋겠네~ 정말좋겠네~)
• 딥러닝으로 음성 합성해서 어디에 사용할 수있나?
• 음성안내시스템(지하철, 박물관)
• 대화인공지능(Siri, 인공지능 스피커)
• 오디오북(성우 대체)
• 음성합성 기술은 네이버, 카카오, 구글등 많은 기업들이 기술을 이미 보유하고 있지만, 자연스러운 문장 읽기가 되지않고있다.
• 그래서, 텐서플로우를 사용하여, 딥러닝으로 직접 구현해보았다.(발표 이후에 오픈소스로 공개 예정)
• 딥러닝
• 데이터 (텍스트 <=> 음성)
• 딥러닝을 하려면, 에 대한 데이터가 있어야하는데, 공개된 데이터가 없어서 직접 학습 데이터를 만듦
• JTBC 뉴스룸의 손석희 앵커브리핑 동영상과, 텍스트가 정리된 페이지를 가져와서 데이터로 사용
• 뉴스 + Yotube + 오디오북 데이터 사용으로 손석희, 박근혜, 문재인등 5명 목소리를 데이터를 많듦
• 50+시간 데이터 확보
• 손석희 : 15+ 시간(13000문장)
• 박근혜 : 5+ 시간(6000문장)
• 문재인 : 2+ 시간(2000문장)
• 데이터 프로세싱
• 자연스러운 목소리가 포인트로
• 음성 추출, 문장자르기, 텍스트 <=> 음성 맞추기 => 자동화
• 노가다가 많음
• 데이터 모델링
• 구글 리서치에서 7개월전 발표한 Tacotron 모델
• A Full End-to-End Text-To-Speech Synthesis Model(완전 엔드 투 엔드 텍스트 음성 합성 모델)
• Encoder - Decoder - Attention - Vocoder 모듈로 구성됨
• Encoder : 텍스트 정보를 잘나타내는 숫자로 인코딩(Character Embedding)
• Decoder : 연속되는 스팩트로그램으로 디코딩(스팩트로그램으로 음성을 만들 수 있음) 
• Attention : 음성이 되기 직전의 숫자들(스팩트로그램)을 RNN(순환 신경망)에 넣어서, 어디에 집중해야하는가(첫번째 음성은 텍스트의 첫번째 단어에 집중) 판단하고, 일반화한다.(학습하지 않았던 문장도 얼마나 잘 말할수 있도록)
• Vocoder : 스팩트로그램을 가지고 음성을 만듦
• 바이두 리서치에서 5개월전 발표한 Deep Voice 2 모델
• Tacotron과 동일한데, N명의 목소리를 하나의 모델로 만들 수있다.
• Tacotron 목소리 하나당 5G GPU가 필요, Deep Voice 2 사용하면 여러 목소리도 5G GPU면 됨
• Character Embedding + Speaker Embedding 으로 해결
• 여러 목소리 데이터 학습시, 데이터가 적은 목소리도 데이터가 많은 다른 목소리가 학습시 Attention에 도움을 준다.
• Attention을 원하는 데로 치환해서 사용가능
• 말하는 속도 조절
• 한 사람의 Attention을 다른 사람에게 적용(성대모사 효과?)

3-1-3. Clova Platform: 인공지능을 엮는 기술

[112]clova platform 인공지능을 엮는 기술 from NAVER D2

• clova platform 이란?
• 네이버에서 만들어서 제공하는 인공지능 플랫폼으로
• App, Device <=> Clova <=> Contents, Service
• App, Device <=> Clova
• 모바일 앱, 생활가전등의 Device 와 Clova 간에 인터페이스를 제공하여, Clova 플랫폼을 사용하여 인공지능 Device 를 쉽게 만들 수 있도록 한다.(Clova Interface Connect, CIC)
• Public API 및 Java, Android, C++ SDK 제공
• Clova <=> Contents, Service
• Clova에서 제공하는 인공지능 서비스에 추가적인 컨텐츠나 서비스를 더하여, 확장 서비스를 제공하기 쉽도록 한다.(Clova Extention Kit, CEK)
• Public API 및 NodeJS, Python, Java, Ruby 등 SDK 제공
• Step by Step 형식의 Builder 및 온라인 테스트 환경 제공
• 네이버, 라인이 사용하는 Platform을 그대로 공개한다.
• 아키텍처 & 기술 스택
• Protocol : HTTP/2 사용
• Latency 가 높고, 
• 한개의 Connection에 여러개의 논리적인 연결, Stream으로 구성(순서와 방향이 섞여도 문제없는구성)
• 한 Stream 안에서 Request -> Response 구조인건 HTTP/1.x와 동일
• Multiplexing 기능 제공
• 러닝커브가 높은편이다
• 언어 : Golang
• HTTP/2 구현체가 잘되어있음
• I/O 성능이 좋음
• Cgo 사용으로 기존 C언어로 된라이브러리 재사용
• 개발환경, 빌드, 배포등의 추가적인 cost가 높아서 Native go로 이전중임
• 모니터링
• End to End 테스트, black box 테스트 진행
• 테스트 목적의 CIC Client 개발(python, Python-Hyper)하여 테스트
• Clova Interface Connect, CIC
• 서버가 먼저 보내는 Downstream Channel과 Event Request로 구성
• 모든 CIC Client는 반드시 1개의 Downstream Channel유지(서버측 명령어 감지용, HTTP/2 Multiplexing)
• Event Dirven 처리 Wake-Up Word 같은 Interruption 요소 사용
• Client에서 요청ID 생성하고, 자신의 현재상태 정보 포함하여 Event 전달(Queue 처리됨)
• 서버에서 표준화 된 Directive 처리
• Intent 개념을 두어서, 자연어, 행동등을 {Namespace}.{Name}의 형태로 표현
• Intent마다 개별 Parameter(Slot)를 가질 수 있음
• EX) Clova, 아이유 노래 틀어줘 => Music.Play, Slot: Artist
• Platform은 Intent를 기준으로 실제로 요청을 처리할 서비스를 선택
• Embedded 환경에서 많이 사용되는 특성상, 하위 호환성이 매우중요
• Text기반의 Protocol, Semantic Versioning 통한 Version 협상
• Field는 항상 추가만 수행
• Silently Ignore
• Clova Extention Kit, CEK)
• Interaction Model : Intent 사용, Bultin Intent 지원
• Request Model : RestfulAPI 제공, json 요청/응답, session 제공
• Response Model : 응답을 위한 Template 제공, CIC Device 작동을 제어, 작동을 보장하지는 않음
• Builder : 대시보드 제공, Intent, Slot 설정 페이지 제공
• 시연
• FRIENDS -> CIC -> Dash robot extension server -> Dash robot control APP -> Dash robot
• 
  

3-1-4. 동네 커피샵도 사이렌오더를 쓸 수 있을까?

[123]동네 커피샵도 사이렌 오더를 쓸 수 있을까 from NAVER D2

• 스타벅스 사이렌오더?
• 스타벅스에서 줄을 서지 않고 모바일로 주문/결재 할 수 있는 APP
• 작은 카페에서 사이렌오더?
• 작은 카페에서는 APP을 다운로드 받고 설치하고, 가입하고, 로그인하고, 주문하고 결재하고, 기다리다 알림받고 커피가져오고?
• 일단 설치/가입/로그인 때문에 귀찮아서 하지않게된다.
• Instance(일회성) 소비를 위한 서비스
• 설치/로그인 없지만, 결재, PUSH 알림까지 가능한 서비스?
• 기술 스택
• 크로미움 사용
• PWA(Progressive Web App) : App 설치 없이 URL 접근으로 서비스를 가능하게 하는 솔루션
• 웹에서 앱과 같은 사용자 경험을 제공
• Service worker
• Web page 로드시 register(설치 대체)
• Browser와 별개로 돌고있는 worker thread
• Browser가 꺼져 있는 상태에도 Push notification 가능
• Loginless
• Browser fingerprint 이용한 사용자 정보복원
• javascript -> web enginie -> cpu/gpu -> rendering 결과가 device간 조금씩 다르다 해당 값을 key로 사용
• Push Notification
• 브라우저에서 Permission을 구하도록 되어있음(Block 당하게 될경우 다시 알람을 허용할 방법이 거의 없음)
• 어떤서비스인지 보여주고 인지하게 한후에 알림창을 선택 할 수 있도록 처리(5% -> 50% 사용율 증가)
• Service worker를 통한 Push-notification은 App 처럼 Payload에 Icon, image등을 실어서 보낼수 있고, 메시지에 대한 응답을 구할 수 도 있다.
• Payment
• 서비스워커 형태의 결재앱 Payment Handler 를 사용하여, 결재앱 설치 및 결재사이트 이동없이 결재가 가능하도록 결재

3-1-5. TABS 넌 누구니?

what is_tabs_share from NAVER D2

• TABS?
• Total ABuse detection System 전체 남용 탐지 시스템, 데이터 분석 및 모니터링 시스템
• 기존시스템
• 정적 임계치 기반 탐지로 모든 게임에 대한 동일하 기준 적용
• 이벤트 등 게임 환경 변수 적용 미흡
• 분산 된 게임 이력 정보
• 어뷰징 포인트
• 메모리 치팅 : 메모리 값을 변경 하여, 게임 머니 무한대로 설정
• Resource Hack : 리소스 파일이 삭제되면, 적이 나오지 않음(라인레이저스)
• 패킷 변경 : 서버로 전송되는 패킷의 파라메터 값 변경(계속 잭팟터짐)
• 패킷 리플레이 : 로그인 페킷 계속 보내, 보상 계속 받음
• 신규시스템
• Line 안에서 기존에 사용하던 시스템 조합을 사용해서 만들어짐(kafka, storm, elasticsearh 등 인듯)
• Device Protection
• Line+ 게임보안실에서 만든 AirArmor로 Rooting, Cheating, 클라이언트 비정상 행위 감지 하여 서버로 전송
• client(AirArmor) -> AirAbuseTracker Server -> TABS Analysis System
• 분석 시스템
• Clusting analysis + 사용자별 점수 분석 = growth abuse detect system => TABS Analysis System
• 모든 게임 데이터 수집
• 배포확인(소스들의 해시코드 값 체크)
• 임계 값 확인
• 매일 게임 환경에 따른 탐지 기준 변경
• 게임별 탐지 기준 동적 반영
• 탐지율 증가, 오탐율 하락
• 정규분포도 기준으로 추출하여 평범하지 않는 사용자 사업부에서 관리
• WHITE List 관리(사장님 ID, VIP ID 관리)

3-1-6. 머신러닝으로 쏟아지는 유저 CS 답변하기

머신러닝으로 쏟아지는 유저 CS 답변하기 DEVIEW 2017 from Donghwa Kim

• 아이디어
• 쏟아지는 CS 질문/답변을 챗봇같은 느낌으로 자동 답변이 되면 좋을텐데...
• 시도
• 이미 존재하는 450,000 질의/응답을 사용하여 해결해보자
• 대부분의 Classification 문제로 접근
• CS 담당자들이 20+개의 Class를 제공(전체데이터의 70%)
• 주어진 Class에 속하는 질문들을 자동으로 분류/답변하자
• Preprocessing이 힘듦
• 제대로 붙어있지 않은 라벨
• 엉망으로 되어있는 맞춤법, 이모티콘
• 질문 내용 외의 메타 정보(유저ID, 구글ID, 영수증 정보 등)
• Vectorize : Question text -> vector embedding
• 한 토큰의 벡터 학습 : 다양한 기법을 통해 각 토큰과 벡터를 맵핑
• Model : Naive Bayes에서 결과 59%, 딥러닝 결과 최대 65%, 데이터 교정 68%
• 질문만 보고 답변을 하나로 특정 지을 수 없음
• 3가지 답변 후보를 예측하는 모델을 만들자?
• 결국 담장자가 확인을 해야하기 때문에 무의미함
• 배운점
• Baseline의 중요성 : 디버그 가능한 고전적인 ML 기법들을 사용)
• 데이터를 항상 꼼꼼히 살펴보자 : 문제 정의, 데이터 가공, 모델링 등 모든 과정에서 인사이트를 준다.
• 문제의 본질을 기억하자 : Top 3을 맞추는 모델로는 봇을 만들 수 없다.
• 영향도 : 하이퍼파라미터 < 모델 < 데이터 가공 < 문제 정의
• 하이퍼파라미터나 세세한 모델 튜닝은 보통 퍼포먼서를 크게 향상시키지 않음
• 문제 재정의
• 해결 가능하면서, CS담장자의 일을 줄여줘야함
• 특정 업데이트에 문제가 있으면, 수백~수천건의 CS문의가 들어온다
• CS 담당자는 그질문들에 대해 정확히, 똑같은 답변을 기계적으로 보냄
• 특정 장애로 인해 쏟아지는 CS를 머신러닝으로 자동 분류하고 답변하자.
• 2차 시도
• Anomaly Detection : 비정상 데이터 찾자, 일반 CS들속에서 장애관련 CS를 찾는것
• 다양한 기법들
• Support Vector Machine
• k-Nearest Neighbor
• Local outlier factor
• Autoencoder 사용 : 라벨이 필요 없음, 구현이 간단, 실제 사용예시 확인
• Normal Data로 AE(AutoEncoder)학습
• Abnormal Data가 들어왔을때 높은 loss
• Few-shot Learning : 새로운 장애 CS를 몇개의 샘플로만 구별
• 유사도 계산, KNN(K Nearest Neighbors) 
• 유사도가 높으면 Yes 선택
• 민감도(Sensitivity) : 91%, 93%(Matching Network), 93%(TCML), 94%(Voting)
• 특이도(Specificity) : 72%, 89%(Matching Network), 91%(TCML), 92%(Voting)
• 전체 CS -> 장애 CS분류기 -> 장애CS (최종 사람이 선택) -> 장애 CS 자동 답변
• 장애CS 분류기 적용함, Top3 FAQ도 적용예정

3-2. Day 2

3-2-1. HBase 기반 검색 데이터 저장소

[211] HBase 기반 검색 데이터 저장소 (공개용) from NAVER D2

• CUVE : 네이버에서 사용하고 있는 HBase 기반 검색 데이터 저장소
• 예전에는 데이터 생산과 소비를 1:1 물물교환 방식으로 했다면
• CUVE는 생산자와 소비자 사이에서 데이터를 저장/유통 해주는 서비스이다.
• 통일된 인터페이스로 데이터 생산과, 소비가 가능하도록 API를 제공하고 다양한 읽기방식을 제공
• stream read, time range scan, random read
• Catalog를 두어 데이터 종류, meta 정보, 권한부여, 티켓발급등 부가 정보 및 서비스를 제공하여, 데이터 활용이 쉽도록 한다.
• 하루 20억건 데이터가 들어가서, 5백여종의 데이터 종류를 가지고, 수천억건의 문서가 저장됨(수 페타바이트), 하루 300억건의 데이터를 소비한다.
• 데이터 특성
• 불변/가변 특성을 갖는다.
• 생성 또는 관리 주체에 따른 분류된다.
• 사용 패턴에 따라 분류된다.
• 실시간 생성/수정/삭제 HBase write 되고 time range/real-time read 가 되는 가변 데이터에 집중
• Time range scan & Real-time processing
• Time range scan
• HBase는 데이터 scan 시에 시작지점과 종료 지정하여,
• 전체를 읽는대신 일부만 읽어들일 수 있는데 그렇게 하려면 Row 키설계가 중요함, Row 키가 유일하고 보조 Index 없음
• table row key 설계
• Doc table
• Salt
• 시간 데이터와 같이 순차적으로 증가하는 값이 있는경우에 특정의 region에만 데이터가 들어가게 됨
• 이러한 hot spot 문제를 해결하기 위해서 ID 모듈러 연산으로 생성, 2Byte
• Group
• 처음에는 서비스별로 테이블을 분리했었는데, 하루치에 수정분만 처리하려고 해도
• 여러번 스캔이 되어야해서 비용이 높아짐, 여러 테이블을 하나의 테이블로 합치고, 이를 분류하는 용도 2Byte
• Time
• 기간에 따른 scan을 지원하기 위한 용도 8byte
• MessageType
• 문서, 이미지 구별용도, 1byte
• ID
• URL은 unique 한 속성이므로 ID로 사용가능, 고정크기 아니기 때문에 MD% hash 해서 사용
• Key table : random access 용 index 용 table을 생성, 컬럼에 timestamp 값 넣음
• ID, Group, MessageType Row키로 생성
• table schema 설계
• 읽기 패턴을 고려현 column family 구성(URL, meta, content, raw)
• Real-time processing
• kafka 큐를 사용하여 데이터 생산 시간 순서 보장이 안되기 때문에, 문서를 쓰기전에 문서를 읽어서 시간 비교 후 처리 하도록 처리
• storm 에서 Write 경쟁 발생, 같은 문서를 처리할때 발생하게 되는데, Storm bolt 연결 방식중 field grouping으로 같은 문서는 같은 bot에서 처리되도록하여 경쟁 회피
• 실시간 처리를 위해서 streaming queue 도입(Kafka + Storm)
• 배치 처리를 위해서는 직접개발한 CuveInputFormat 을 사용하여장 HBase에서 Hadoop으로 저장
• Multi contents & Filtered Scan
• Multi contents
• 문서는 여러개의 content를 가질수 있도록 확장, content는 meta + data로 구성하고, 하나의 문서에 여러 content를 저장하여, meta 컬럼을 통한 scan filtering이 가능하도록 처리
• 데이터 로스
• key table에만 있거나, doc table에만 있는 문서 존재(옛날 버전에서 mutateRow 버그가 있었음 수정함)
• 데이터 중복
• key 테이블은 삭제 되었으나, doc table 삭제안됨, 트랜젝션 지원이 안됨, multiTable은 아니지만 multi Row에 대한 트랜잭션을 지원, 동일 Regin에 존재하는 row에 대해서는 트랜젝션 제공함.(0.94 소스 구현되어있음)
• doc/key table을 하나로합치고, salt를 이용해서 동일 region에 배치 multi row transation 이용하여 처리 MessgeType을 가지고 row key 용도 구별
• Filtered Scan
• 보조 index row 추가 하여, 특정 사용자별 인텍스 추가하여 빠른 결과가 나올 수있도록 처리
• 그 외 저장소 구성 요소
• DB 데이터 Pulling 하여 Hbase 저장
• 모니터링, 단위시간단 얼마만큼의 문서들이 생성/수정/삭제 되는지 확인 및 이력관리
• 사용자 관리 및 제어, 사용자 사용량 관리, 접근제어

3-2-2. MIST: 고성능 IoT 스트림 처리 시스템

[232]mist 고성능 iot 스트림 처리 시스템 from NAVER D2

• 다양한 장소에서 많은 IoT 디바이스들이 생겨나고, 지속적인 데이터 스트리밍이 요구 되고있다. 
• 장소 : 집, 농장, 경기장, 건물 ...
• IoT 디바이스 : 맥박, 위치정보, 온도, 습도 ... 
• 예를 들면, 온도를 계속체크해서, 에어컨을 켠다던지, 선풍기의 속도를 조절한다던지 하는 작업이 많아지고 있음
• IoT stream query 속성
• 긴 실행시간
• 작은 데이터 스트림
• 많은 갯수
• 다양한 타입
• 위 속성에 부합하는 IoT 스트림 프로세싱 시스템(클러스터링된 시스템)
• Storm, HERON, Flink, Spark .... 등 기존 시스템이 존재
• MIST는 서울대 연구실에서 연구/개발중인 IoT 스트림 프로세싱 시스템
• Master, Slaves 구조의 클러스터로 마스터에서 요청을 받아, Slaves에 할당하여 처리 하는 방식(REEF 사용)
• Front
• Java 8 로 구현, MQTT 프로토콜 사용
• Java 람다를 사용하여, UDF(User-Defined Function, 사용자 정의 함수) 제공
• SQL 보다 유연한 프로그래밍 모델을 제공
• 두가지 타입의 쿼리 API를 제공
• Dataflow Model : UDF를 사용한, 저 레벨 쿼리
• 인풋 스트림 소스에 대한 정의 : MQTT 토픽과 브로커 주소 설정
• 인풋 이벤트가 변경되었을 때에 처리 정의 : Stream에 대한 처리 정의
• 아웃풋 설정 : 조건이 만족했을때에 대한 처리 정의
• MIST 마스터에 쿼리 제출
• Complex Event Processing(CEP, 복합 이벤트 프로세싱) Model : 고 레벨 패턴 탐지 지원
• 이벤트 패턴이 만족하는지 체크하고 만족할때 동작
• 이전 동작한 쿼리와 고 레밸 복합적 이벤트 프로세싱 결과 사용
• EX) 심박수 주기를 찾아라.
• 의사에 의해서 만들어진 정상 심박수 보다 높은 경우
• 오름차순 패턴을 확인
• 최근 5분 동안
• 비정상적인 패턴을 찾았을때 MQTT를 사용하여 알림
• Backend
• 하나의 머신에서 얼마나 많은 처리가 가능할까?
• 가능한한 리소스를 최대한 재사용
• Code sharing
• 동일 쿼리는, 하나의 컴파일된 코드를 사용하도록 구현(동작단위를 줄여서 개발)
• 코드의 참조 영역을 이용한다
• 사용자의 UDF들이 캐시 미스가 나지 않도록 사용자별로 순차적으로 저장되도록 한다.
• 그룹의식이 높은 실행 모델 적용
• 사용자별 그룹핑된 쿼리를 실행하도록 하고, 여러 thread 실행하여 처리할때 thread 별로 로드를 확인하여, 로드 높지않은 thread에 어사인 및 리어사인 하여 벨런싱을 맞춘다.
• 쿼리 머징
• 동일 UDF 가있으면, 한번만 실행한다.
• 싱글 머신 평가
• Flink 보다 375배 빠름
• 앞으로 할일
• 분산 마스터 서버 처리(마스터 서버가 bottleneck 이다.)
• 노드들에 대한 로드벨런싱(쿼리 할당과 유동적인 쿼리 이전)
• 실패에 대한 처리

3-2-3. 의료 AI를 위해 세상에 없는 양질의 Data 만드는 도구 제작하기

[213] 의료 ai를 위해 세상에 없는 양질의 data 만드는 도구 제작하기 from NAVER D2

• 현재 의료 AI와 Labeling tool의 중요성
• Deep 러닝은 데이터 기반의 일관적이고 객관적인 특징 학습 및 분성 방법
• 즉, 데이터가 많고, 좋은 데이터를 이용해 학습하면 좋은 결과가 나온다.
• 의료 AI란?
• 특정 병변의 검출 및 분류
• 인체 기관의 세부 구조 분할
• 유사 영상 검색 등
• 병원에서 좋은 데이터란?
• 병원에는 X-Ray, CT, MRI 등 데이터가 많지만, 좋은 데이터는 많지 않다.
• 결국 Labeling이 잘된 데이터가 좋은 데이터인데, 의사들의 컨디션에 따라서 달라질 수 있음
• EX) 당뇨성 망막증
• 당뇨성 망막증(DR)은 실명의 가장 빠른 성장 원인으로 초기에 찾으면 치료가능 병변의 유형에 의해 DR의 심각도를 판단
• 128,000장의 Fundus 이미지를 54명의 의사가 한 이미지에 3~7명이 Labeling 안과 의사에 버금가는 성능
• Labeling tool 제작(치아, 폐CT, 세포핵, 안저, 뼈스캔)
• 기술 스택
• HTML5 canvas, javascript, WebGL, gulp, babel, ...
• Flask, Celery, Keras, PyInstaller, ...
• MySQL, SQLite3, ...
• Labeling tool
• Dental Panorama X-ray (치아 X-ray)
• 26개의 카테고리아 81개의 질명(색으로 구분)
• DICOM Viewer기능(Viewer, Windowing, ... )
• 그리기 도구(2-layer)
• 결과는 Labeling image와 선택된 정보를 저장
• Lung CT Nodule(폐 CT 결절)
• 3D DICOM Viewer(Stack scroll, Windowing, Zoom, ...)
• Nodule(결절)의 심각한 정도를 색으로 표현
• Nodule의 크기 재는 도구
• 전공의/전문의로 나누어 Labeling
• 세포핵, 뼈스캔
• Copy & Paste
• Fundus(안저)
• DICOM Viewer(Viewer, Windowing ,Zoom, ...)
• 좌안/우안 구분 및 Dist/Fovea 자동 설정
• 8개의 구획을 나누어 병이 있는 구획 Labeling
• 이미지 한장당 세 명의 의사가 Labeling
• Image viewer
• *.dcm file reader(dicomParser.js)
• DICOM file
• 의료용 디지털 영상 및 통신 표준
• 환자 이름, 환자 ID, raw data, 검사 날짜 등(약 4000개 정도가 있음)
• (4자리 16진수, 4자리 16진수)를 key로 가짐
• 다이콤 표준문서(http://dicom.nema.org/standard.html)를 보고 원하는 데이터의 Tag를 찾아 파싱
• Windowing(cornerstone.js)
• 인체의 각 조직과 기관은 특정 값을 가지고 있음(e.g. 물=0, 공기=-1000, 뼈=1000[HU])
• 영상에서 보고자 하는 조직을 기준으로 하여(Window Center)
• 얼마만큼(Window Width)의 값을 볼 것인지 정하는 것
• 임상에서 일반적으로 사용하는 Windowing 값이 존재
• 폐실질 : 1,000~1,700 / -700~-800
• 뇌실질 : 80~100 / 0~30
• 뼈 : 1000~2000 / 200~300
• 흉부종격 : 400~500 / 40~60
• DICOM파일에서의 Brightness / Contrast 조정
• 일반적으로 마우스 오른쪽 버튼 이용(OsiriX)
• 이미지의 값을 계산 및 변경하는데 오래걸림
• WebGL을이용해 개선
• Zoom / Pan / Length (cornerstoneTools.js)
• Annotation Tools
• Brush
• Elliptical ROI
• Rectangle ROI
• Probe
• Eraser
• Colors
• Undo /Redo
• Image Save(2-Layer)
• 테블릿 PC 지원
• 공통기능
• Labeling data format
• 한 데이터에 몇 명이 Labeling을 할 것인지
• 단축키
• Dashboard
• 관리자의 관리용
• 누가 얼마나 라벨링 했는지 표시(사용자의 경쟁 심리 유도)
• CT 3D DICOM Image viewer
• DICOM header 중 instance number 기준으로 정렬
• 첫 이미지 로드 후 나머지 이미지 load and cache
• Mouse 혹은 방향키로 scroll
• 슬라이드 별 Labeling을 해야하지 때문에 다음과 같이 저장(json 형태)
• 전공의와 전문의의 분리
• 대부분의 Labeling은 대학병원 의사분들이 함
• 먼저 전공의 Level에서 Labeling을 함
• 전공의가 끝낸 이미지의 대해 다시 한번 전문의가 확인
• 이 때, 전공의가 Labeling한 정보는 그대로 Copy
• 전문의가 수정하여 저장하면 새로운 데이터가 됨
• 따라서 한 이미지에 대해 전공의/전문의 두 Label이 남음
• 학습에는 전문의 데이터를 사용
• Fundus region 나누기
• Disk와 Fovea가 기준점(이 둘은 학습을 통해 자동으로 찾음)
• Disk-Fovea거리의 2/3, 2/5의 반지름을 갖는 두 원을 그리고, 수학으로 두원의 교점을 찾은 뒤 나머지 선들을 그린다.
• Fundus 선택한 region 판단
• 선택한 좌표가 두 원 안에 존재하는지 먼저 확인
• 선택한 좌표와 가까운 두 점과의 ccw를 통해 판단
• Fundus 선택한 region 색채우기
• 선택한 지역의 둘레를 그린 후 색을 채운다
• 이때, 원의 각도를 삼각함수를 이용해 구한다.
• 폐쇠적인 병원에 Labeling tool 설치 및 관리하기
• 왜 설치 및 관리가 어려운가?
• Labeling을 위해서는 데이터가 있어야하는데 병원의 데이터는 환자 데이터고 IRB를 받더라도 외부로 반출되면 안됨 따라서 클라우드 서비스는 불가능
• 병원은 내부망을 쓰는데 내부망은 외부 인터넷 연결이 되지않음, 따라서 외부에서 접속하여 관리 할 수 없고, 운영체제가 다 다름
• 설치 및 관리하기
• Docker
• 개발 환경이 단일화 된다는 것은 신경 쓸 것이 많이 사라짐을 의미
• Docker image 덮어 씌움으로 해결되는 쉬운 업데이트
• 같은 Labeling tool로 여러 system을 만들기가 수월함
• VPN + PC
• GPU PC를 병원 내부에 둠
• VPN을 이용해 외부에서 접속
• 설치 및 관리를 전부 VPN을 연결한 상태에서 함(Packet log를 통해 데이터를 빼가는지 확인 가능)
• 업데이트도 용이
• Labeling data 학습도 쉽게 가능

3-2-4. 네트워크 모니터링 시스템(NMS)을 지탱하는 기술

[244]네트워크 모니터링 시스템(nms)을 지탱하는 기술 from NAVER D2

• 글로벌 서비스를 위해서 전세계에 분산된 네트워크 Region 모니터링 이슈
• 망간의 거리
• SNMP(Simple Network Management Protocol)을 사용하여 네트워크 장비를 모니터링하게 되는데
• 라우터의 SNMP 처리 성능
• 패킷당 요청 개수 : 최대 10개(Router 성능 패킷 크기에 따른 제한)
• 수집항목 갯수 : Router 당 1000 ~ 10000개
• 수집 시간이 1분을 초과할 수 있음(Data 누락, 이벤트 처리 오류)
• KR - CN : 90ms(90s)
• KR - US 220ms(220s)
• KR - DE 290ms(290s)
• Router의 리소스를 고려하여 수집시간을 줄일 수있는 방법 필요
• 수집 서버를 Router 근처에 배치
• Multi-threading 으로 처리
• 네트워크 장비 수
• Scale-out 검토 필요
• Router 개수가 수 천 대씩 증가하기도 함
• 관련한 다양한 기술 검토 필요 : Kafka, Zookeeper, Hbase, Redis, Spark, Storm, ...
• Scale-out이 안 된다면
• 갑작스러운 규모 증가에 대응이 어려움
• Global view 지원이 어려움
• Scale-out 구축
• Region 별 수집기 구축
• Kafka, Zookeeper, Redis, Hbase 사용
• Region 구분 -> Region별로 NMS 구축 -> Region 별로 Collector 구축 -> 스케일 아웃 가능한 분산처리 시스템을 통한 중앙 수집 시스템 구축
• 네트워크 장비 종류 수
• SNMP MIB(Management Information Base) 종류는 100가지
• 장비 모델별 MIB 형식에 일관성이 없음
• 모델별로 수집기를 개발할 경우 100가지의 실행 코드가 생산됨
• 수집 데이터를 추상화 하고, 모델별 MIB 값을 테이블로 관리 한다.(연산을 제공)
• 신규 모델에 대한 MIB 정보는 Network 담당자가 입력 할 수 있도록 툴제공
• 배포시 수집 누락
• 문제점
• 수집 서버 추가/제거, 수집기 배포
• 수집기 재시작 필요
• 수집기별 수집 대상 장비 변경됨
• 수집기 재시작
• 수집에 필요한 정보(Meta Data) loading
• 새로운 목록에 대해 수집 시작
• Data 누락
• 수집기별 loading 속도가 다름
• 수집 주기(1분) 내에 loading이 어려울 수 있음: 원거리, data size
• 기존 배포 시나리오
• Collector 종료시 Membership에서 Leave 후 즉시 종료
• Master는 수집 대상 장비를 Reassign하고, 각 Collector는 새로운 수집 대상 정보를 읽음
• 배포 및 실행 후 즉시 Membership에 Join
• Master는 수집 대상 장비를 Reassign하고, 각 Collector는 새로운 수집 대상 정보를 읽음 
• 개선된 배포 시나리오
• 종료하는 Collector는 Membership에서 Leave(zk의 member 노드만 제거하고 실제 프로세스는 살아있음)
• Master가 Reassign하고, 모든 Collector가 Redis로부터 새로운 수집 대상정보를 읽음 ==> 모든 Collector가 감지
• 모든 Collector가 감지 되기 전까지는 기존 할당 정보로 수집하고, 모든 Collector가 감지가 완료 되면 새로 Assign 된 정보로 수집하여 누락 없앰

3-2-5. 빅데이터를 위한 분산 딥러닝 플랫폼 만들기

[225]빅데이터를 위한 분산 딥러닝 플랫폼 만들기 from NAVER D2

• 탄생 배경
• 제한된 GPU 자원을 다수의 연구원들이 사용하고 싶어함
• 초기 요구 사항
• Caffe, TensorFlow, Theano, Torch 등 딥러닝 프레임워크 제공
• Docker 사용
• 다양한 딥러닝 프레임워크를 깔끔하게 지원 가능
• 패키지 표준화 하면서 동시에 개인 환경에 맞도록 셋팅 가능
• NVIDIA-Docker 사용(NVIDIA에서 제공하는 GPU용 Docker
• Hadoop YARN
• job 스케쥴링과 클러스터의 리소스 매니지먼트 프레임워크
• 새로운 요구 사항
• Distributed inference
• 대용량 배치 작업 오래 걸리는 작업들은 2~3개월 필요
• Map-reduce 처럼 input, output만 지정하면 자동으로 나눠졌으면 좋겠다
• GPU자원이 남으면 최대한 사용하고 싶다.
• Distributed training(Distributed tensorflow 사용하고 싶다.)
• Serving(long live 웹서버를 실행해서 request, response 방식으로 처리)
• CPU만 사용해서 실행
• training이 끝난 모델을 사용해서 inference만 하고 싶은데, CPU 가 가성비가 더좋은 경우가 있음
• 단, 기존과 동일한 방식으로 사용하고 싶다.
• 설계 및 검토
• YARN application 변경
• Distributed inference
• 여러 container 동시 실행할때 장비 다운등 에러 처리
• input 디렉토리를 자동으로 나누어주고, 분산 처리시 output도 디렉토리별로 나워어 저장 되록 처리
• 동시 실행 스케쥴링 기능 추가
• Distributed training
• Tensorflow on Spark 사용
• host, port 정보를 알아와야 하는데, cluster어디에서 실행하는지 알수가 없음
• Docker Overlay Network 기능을 사용하여 내부 네트워크 생성
• Serving(long live 웹서버를 실행해서 request, response 방식으로 처리)
• Apache Slider를 사용하여 구축
• Serving을 위해서 만들어짐
• CPU만 사용해서 실행
•  REST API를 앞단에 두어서 CPU클러스터 GUP클러스터 구분해서 실행 가능하도록 인터페이스 맞춤
• Flask-RESTPlus + swagger 사용
• 자유도 높은 API와 쉬운 API 둘다 제공

3-2-6. 네이버 검색 사용자를 만족시켜라! - 의도파악과 의미검색

[216]네이버 검색 사용자를 만족시켜라! 의도파악과 의미검색 from NAVER D2

• 검색 의도 확인
• 몇개의 검색 의도가 있는가? -> 모른다.
• BIG 6에 대해서 일단 답해보자
• 단답(Know Simple)
• 장소(Visit in Person)
• 행위(Do)
• 사이트(Website)
• 방법(HowTo)
• 정보(Know)
• 질의 88개 검색의도 6개 총 528개의 의도 관리
• 문제점
• 동일단어 검색이지만 전혀 다른 검색 결과 의미
• 14리라
• 터키돈 리라 환윤문제로 답변
• 달걀 번호 14리라(사회문화 Know)
• 런던
• 런던 관광지
• 런던 테러 상황
• 통합 검색 감시 시스템
• 검색 후 사용자가 어떤 결과를 보는지 확인하여, 상위 노출
• 의도에 맞는 검색
• 중의성 문제
• 시멘틱 태깅
• 문서는 분석하여, 어떤 분류의 문서인지 태그를 저장하고, 검색시에 해당 태그들을 노출하여 사용자가 선택할 수있도록 제공
• 주제 단위 검색
• 식당 : 광고가 맣은 영역으로, 진성 리뷰 모델링
• 스타 : 최근 활동 소식이궁금 할테니, 최신성 강조 모델링
• 개발자와 서비스
• 기술의 우위가 서비스의 우위가 아님
• 서비스 관점을 잃으면 바로 실패
• 서비스와 기술력에 균형이 필요

4. Self-evaluation

• 2013년부터 현재까지 4번째 Deview 를 참석하게 되었습니다.
• Day 1, Day 2 모두 참석하게 된 건 이번이 처음이네요. 참여 연차가 쌓이다보니, 선착순 신청 노하우가 생기는가 봅니다. ^^
• Deview 가 벌써 10년이 되었다고하니, =ㅁ= 세월이 이렇게 갔나, 감회가 새롭네요.
• 참가 할 때마다, 모든 세션이 꽉 차 있었던 같은데, 올해는 몇몇 빈 세션도 보이고, 전반적으로 네이버 주관 세션 비중이 높아진거같네요.
• 외부 참여도가 좀 떨어진거같아 아쉬운 감이 있지만, 개발자들을 위한 컨퍼런스를 이렇게나 멋지게 주최해주고 있는 네이버에 감사하다는 말을 하고 싶네요. 앞으로 더 많은 발전과 지원을 기대해봅니다. ㅎㅎ(언젠간 저도 참석자가 아닌 발표자로 참석하고 싶네요 ^^;)
• 역시 올해 제일 핫한 기술은 인공지능인거같네요. 인공지능 관련 세션들이 제일많은 비중을 차지하고, 관심도도 높았던거같습니다.
• 저는 핫한 인공지능과 업무랑 연계성있는 인프라 플랫폼, 개인적으로 관심 있는 서비스 아이디어 위주의 세션을 선택했습니다.
• 인공지능 분야는 직접해보지 않은 부분들이 많아서, 실제로 인공지능 모델부분 설명할때 못알아 듣는부분이 많았네요.
• 하지만, 여러분야에 걸쳐서 이제까지는 잘 안되던 것들과, 좀 더 편리하고 좋은 기능/서비스들을 인공지능 기술로 잘풀어 낼 수 있을거라 생각이 들었고, 앞으로의 다가올 인공지능 세상이 기대가 되네요. 앞으로 인공지능 분야에 더 관심을 갖고 미래를 준비해봐야 겠습니다.
• 여러 기업들이 플랫폼 시장을 선점하기 위해서, 많은 노력과 시도들을 하고있는데, 플랫폼에서 가장 중요한건 밑에서 받쳐 줄 인프라라고 생각합니다. 여러 기업들이 인프라를 구축하고, 지속적으로 유지, 발전 시켜가는 과정의 세션들을 들으면서, 한번 만들고 끝이 아니라, 지속적으로 개선과 발전을 이루어서 인프라를 유지하는 것이 어렵지만, 정말 중요한 것이라는 것을 다시한번 깨닫는 계기가 되었습니다.
• 그리고, 한번 만들어놓고, 아무리 좋은 서비스라해도 그 서비스에만 안주하게 되면, 그 서비스는 도태하게 된다고 생각하는데요.
• 또한, 좀 더 좋아 질 수 없는지, 새로운 아이디어를 내고, 연구하고 개선하는 것이 결국에는 우리 생활을 편리하고, 좋아지게 하는 것이 아닐까라는 생각을 해보았습니다.

4-1. Day 1

4-1-1. 키노트

• 네이버 랩스에서 진행하고 있는 프로젝트들이 매우 인상 깊었습니다. 
• "기술이 생활속으로 사라졌을 때 가 진정한 기술의 가치 실현이다." 라는 모토가 마음에 와닫았습니다.
• 현재는 매우 특별하고, 몇몇에게만 제공되는 기술이 미래에는 일상이 되는 때가 올 것이라는 생각이 들었습니다.
• 개인적으로 개발자로서 미래에 일상이 되는 서비스나 제품을 만드는데, 기여 할 수 있다면 좋겠다는 생각을 했습니다.

4-1-2. 책 읽어주는 딥러닝

• 딥러닝을 이용하여, 문재인, 손석희, 박근혜의 목소리를 합성하여 들려주었는데, TV에서만 듣던 목소리로 내가 원하는 말을 하도록하는 것이 매우 흥미를 끌었습니다.
• 예전에 앞으로 배우없이 영화를 만드는 시대가 올거라는 이야기를 들었는데, 앞으로개선 되어야하 부분도 많지만, CG로 영상을 대체하고, 배우의 음성을 딥러닝 음성합성기술을 사용하여 충분히 웰메이드 영화를 만들 수있을 것같다는 생각이 들었습니다.
• 목소리에 담긴 감정 까지 표현 할 수 있을까? 라는 생각도 들지만, 기술적으로 충분히 해결 할 수 있을것이라고 생각합니다.

4-1-3. Clova Platform: 인공지능을 엮는 기술

• 인공지능 플랫폼을 내부에서 사용하는 서비스와 동일하게 Device 개발자나, Service 개발자에게 SDK, API를 제공한다고 하는데,
• 인공지능은 사용자가 많을 수 록, 딥러닝 학습효과도 좋고 더 좋은 결과를 만들어 낼 수 있기때문에, 네이버와 다른 개발사들이 서로 윈윈 할 수 있는 전략이라고 생각합니다.

4-1-4. 동네 커피샵도 사이렌오더를 쓸 수 있을까?

• 일회성 소비를 위한 서비스는 오늘날 다양한 소비패턴에 맞게 현실적으로 접근한, 서비스라고 생각이 들었고, 앞으로 활용도가 높은 서비스가 되리라 짐작해 보았습니다.
• 특정 지역에 들어가면, 자동으로 푸쉬 알람이 와서, 해당 지역에 대한 정보를 제공한다던지 하는 지역 정보 서비스에 활용하면, 좋을 것 같습니다.

4-1-5. TABS 넌 누구니?

• 어뷰징 사용자를 분석 및 모니터링하고, 관리하는 통합관리 시스템이였는데,
• 이를 조금만 변형하여, 호스팅 서버관리에 적용하여 호스팅 어뷰징 사용자 또는 해킹 의심 사용자를 찾아내고 관리하는 통합 모니터링 시스템으로 활용을 하면 좋을것 같다라는 생각이 들었습니다.

4-1-6. 머신러닝으로 쏟아지는 유저 CS 답변하기

• 업무 특성상 장애로 인한 CS가 다수 발생을 하게 되는데, 우리 회사에도 장애 CS분류기를 사용하면, 고객지원팀에서 답변 장애로 인한 답변을 빠르게 할 수 있고, 일도 줄여줄 수 있을 것이라는 생각이 들었고, 사내에서도 도전해 볼만한 프로젝트라고 생각합니다.

4-2. Day 2

4-2-1. HBase 기반 검색 데이터 저장소

• 검색데이터 저장 및 활용을 위한 Hbase 저장소 설계와 이를 지속적으로, 개선 시키는 과정 자체가 매우 인상 깊었습니다.
• 이러한 대용량 저장소는 모니터링 데이터 저장 및 검색 등에 활용하면, 좋은 결과를 가져올 수 있을 것이라고 생각됩니다.

4-2-2. MIST: 고성능 IoT 스트림 처리 시스템

• 다양한 IoT 환경에서, 조금더 빠르고, 리소스 낭비없는 스트리밍 처리 시스템을 연구, 개발하는 내용인데,
• UDF를 지원하여 사용자가 직접 정의한 작업을 수행 할 수 있도록 하는 부분은, 회사 인프라 서비스들에서도 제공하면, 유연하게 운영 및 관리가 될 수 있을 것같다는 생각을 했습니다.
• 또한 성능을 극대화 하기 위한 방법들이 인상 깊었는데, 성능이슈가 있을때 같이 고려해보면 좋을 것 같다는 생각을했습니다.

4-2-3. 의료 AI를 위해 세상에 없는 양질의 Data 만드는 도구 제작하기

• 의료 인공지능의 딥러닝을 위해서, 많은 양질의 데이터를 확보하기 위한 도구를 만들어 의사들에게 제공한다는 내용으로, AI가 의료 분야까지 진출하여, 어느정도 성과를 내고있다는데에 놀라웠습니다.
• 인터넷이 안되는 폐쇄적인 병원에서, 툴 설치와 관리를 위해서 Docker와 VPN을 사용것과, 
• 누가 얼마나 라벨링 했는지 표시하고 나서, 라벨링 갯수가 늘었다는 이야기가, 약간 웃프게 들렸습니다.

4-2-4. 네트워크 모니터링 시스템(NMS)을 지탱하는 기술

• 글로벌 서비스를 위해서 전세계에 분산된 네트워크 모니터링을 위해서, NMS를 만들었다고 하는데, 해외 진출을 생각한다면, 이런 시스템도 필요하겠구나라는 생각을 하게되었습니다.
• 기존에 네이버에서 사용하고 발표도 많이한, 구성이였지만, MIB를 관리하는 방식이 흥미로웠고, 해당 방식을 사용하면, 개발자가 네트워크 지식이 부족하더라도, 네트워크 관리자가 MIB 값을 관리해줄 수 있기 때문에 좋은 방법이라고 생각이 들었습니다.

4-2-5. 빅데이터를 위한 분산 딥러닝 플랫폼 만들기

• 기존 네이버에서 CPU 분산처리 플랫폼에 GPU 분산처리 플랫폼을 추가하는 형태의 서비스를 만들었는데, 점점 인프라가 확장되어가는 모습이 보기 좋았습니다.
• REST API를 앞단에 두어 하나의 시스템 처럼 연동 하는것이 인상적이였고, 기존에 있는 인프라는 최대한 활용하고, 연계하여 시스템을 만들기 때문에, 개발 리소스도 줄고, 빠른 결과가 나올 수 있을 것이라는 생각이 들었습니다.

4-2-6. 네이버 검색 사용자를 만족시켜라! - 의도파악과 의미검색

• 검색결과를 사용자의 의도에 맞게 노출 시키도록 노력하는 모습이 인상깊었습니다.
• 현재 위치에 안주하는 것 이 아니라 좀 더 서비스를 사용자 위주로 개선해나가는 모습이 좋아 보였습니다.
• 개발자이지만, 서비스 마인드를 가져야한다는 말에 적극 공감하고, 조금 더 좋은 서비스를 만들어야 겠다는 생각을 하게 되었습니다.