DevGround 2019, 뭣이 중헌디? and 데이터야 흘러라

DevGround 2019, 뭣이 중헌디? and 데이터야 흘러라

DevGround 2019를 다녀오다

오늘 DevGround 2019 행사에 다녀왔다.

다양한 머신러닝과 관련된 연사분들의 고충(!)을 듣는, 일부는 공감되기도 하는 시간이었다.

이번 행사를 두 문장으로 요약하면,

“뭣이 중헌디?” & “데이터야 흘러라!”

였다.

회사의 ML Project가 지향해야하는 방향성이 회사의 핵심과 연결되어야 한다는 것이 첫번째.

그리고 우리가 머신러닝 혹은 딥러닝을 이용하고 보다 높은 성능의 모델을 만들기 위해 노력하지만 실제 현실의 회사들에서 겪는 문제는 모델의 성능이 아니라 데이터가 흐르는 환경을 만드는 것이 더 큰 문제라는 것을 다시한번 느꼈다.

이하 내용은 세션 들으며 노트테이킹한 내용들.

Session 01. 데이터와 머신러닝이 비즈니스와 만날 때 발생할 수 있는 비극들 (by 하용호님)

Data => Pattern => Money!

개발을 하고 => 통계를 낸 뒤 => 비즈니스를 하자!

2012년에 DataScience Boom이 일어났지만 2018년에는 이걸로 무엇을 할 수 있나?에 대한 의문이 제기되고 있다.

한편 회사들에서는 AI니 ML이니 빅데이터니 하는 이야기들이 나오고 있어 어라, 이걸 회사에 도입해보면 어떨까? 하는 생각을 하게되지만 실제로 Data를 이용해 을 해 본 경험이 없기 때문에 어떻게 해야하는지 자체에 대한 인식이 낮은 상태다.

C급이든 실무자든 모두 기술적 미신에만 빠져있는 상황이라고 볼 수도 있는 상태인 것.

따라서 ‘빅 데이터’ 혹은 ‘데이터 비즈니스’ 와 같은 공허한 키워드들만을 사용하게 되는 것.

“구슬이 서말이어도 꿰어야 보배다.”

1) 구슬이 “서말” => “데이터 량이 많아야…”

“우리 회사에는 데이터가 많아요!” == ‘데이터 없어요!’ or ‘(쓸 수 없는) 데이터가 많아요!’

하지만 실제 현실의 데이터는 1. 없거나 2. 쓰레기더미거나.

사장들의 환상을 이루기 위해서는 (엄청난) 데이터량과/컴퓨팅서버와/엔지니어가 모두 필요하지만,
정작 그걸 가지고 “뭘 할거야?” 라고 묻는 경우 ‘추천? 광고?’ 라는 이야기를 한다.

한편 추천/광고 등으로 재미를 보려면 MAU가 20만 이상이거나 앱 기준 Download 1천만 이상이 되어야 하고, 무엇보다 실제로 해당 분야의 업종(커머스-쿠팡/아마존 등 or 광고수입-구글 등)이거나 혹은 유저가 엄청 많거나(Netflix)의 조건이 충족되어야 유의미한 결과물을 도출해 낼 수 있다.

따라서 보다 현재(재직중인) 회사의 본질과 연결해서 일을 해야 유의미한 결과가 나온다.

예를들어 광고/추천 서비스의 경우 유저의 결정을 빠르게 해 빠른 Transaction으로 이어지게 하는 것이 목표이지만, 정말 이게 목표라면 서비스 초창기에는 그저 인기순위 Top10만으로도 충분히 위 목표를 성취할 수 있다.

오히려 결제 UX Flow를 원활히 만들어 결제 과정에서 이탈이 발생하지 않게 만드는 것이 더 중요한 것.

결국 ROI를 따질 때 들어가는 노력 대비 결과가 더 높고, ‘쉬운 방법’을 모두 선택한 뒤 그 다음에 복잡한 기법(ML등)으로 넘어가는 것이 효율적이라는 이야기.

2) 구슬을 “꿰어야” => “인력이 필요하다…”

문제는 관련 일을 하는 인력이 ‘비싸다’ 는 점.

일을 잘 하는 ML Engineer는 6k ~ 10k+의 연봉을 받고 다니고, 또 동시에 분야가 데이터와 관련이 적은 현재의 대기업들에서는 정작 들어가서는 메리트가 없기 때문에 잘 가지 않으려고 하는 편이라는 이야기.

‘좋은 엔지니어’ 들은 회사의 비즈니스 축에 속하지 않으면 재미없어하고 흥미와 동기가 DOWN.

한편 회사에서 기술을 사용하는 이유는 이익을 만들어 내기 위해서인데 이러한 기본적인 목적을 잃으면 안된다는 이야기.

3) 원하는 “보배”가 뭔지 모른다

“ML을 쓰고싶다. 어디에 쓰지?” (X)

“회사에 지금 이런 문제가 있는데, 여기에 ML을 써보면 효율적으로 바뀌지 않을까?” (O)

전자의 경우는 새로운 기술을 이용해 새로운 비즈니스를 만들려고 한다는 점에서 문제가 생긴다.

회사의 전체 Value의 상승에 도움이 되지 않는다. 공들여서 새로운 비즈니스를 만들어도 오래걸리고 impact도 작기 때문.

(회사가 현재 100이라면 신사업은 5~10인데 이걸 2,3배 올려도 10-30에 불과해 %는 높지만 실제 영향은 작음)

따라서 제대로 된 목표는 회사의 메인 비즈니스 체인 중 ‘느린 부분’을 찾고, 이를 ML등을 이용해 자동화 하는 등의 방법을 통해 효율을 높이는 것이 가장 유의미한 목표가 된다.

Q. 그렇다면 메인 비즈니스 체인 중 ‘느린 부분’은 어떻게 찾나?

어떤 일을 한다고 할 때 진행되는 작업을 개별적인 Transaction이라고 가정하고 시간단위로 재어서 실제로 시간이 오래 걸리는 병목을 찾는 것. (느린 부분은 실제로 시간이 오래 걸리고, 이 부분은 사람의 손이 가는 부분일 가능성이 매우 높다.)

복잡해 보이는 것만이 답이 아니다

“If all you have is a hammer, everything looks like a nail”

– Law of the instrument

현실에 있는 문제들은 복잡하고 고도화된 기법을 통해서만 답을 해결할 수 있는 것이 아니다.

오히려 기업에서는 ROI 계획이 필요하고, 기회비용을 고려해야 한다.

즉, 간단한 휴리스틱 혹은 룰베이스 기반으로 하는 처리방법이 비록 효율이 낮더라도 도입이 빠르고 어느정도의 성과가 나오는 것이 더 낫다는 이야기.

그러면 언제 ML등이 필요한가?

상품 100개를 정렬해보자. 어떻게 하지? (사람 손으로 OK)

그러면 상품 100만개를 정렬해보자. 어떻게 하지? (사람 손으로 X)

휴먼리소스로 커버가 되지 않는 순간이 오면 그때는 이런 기법들을 적극적으로 도입해야 한다!

카카오 플러스친구 이야기

시안 1, 2, 3이 있는데요, 어떤게 가장 좋을까요?

AS-IS: “음… 시안 3이 좋을 것 같으니 이것으로 발송하자.”

TO-BE: “1,2,3 모두 보내보고 AB테스트를 한 뒤 CTR이 가장 높은 것으로 발송하자.”

10000만명에게 보낸다면 앞선 1천명에게는 섞어서 보낸 뒤 CTR을 확인해 보고 가장 CTR이 높은 시안을 자동으로 선택해 나머지 9천명에게 발송하는 아이디어.

실제 카카오의 Value chain으로부터 실제 Viable product까지 이어진 프로젝트.

따라서 쓸 기술을 찾는 것보다 쓸 분야를 찾는 것이 더 중요하다.

Session 02. AI 프로젝트 간지나게 잘 진행하는 법 (by 백정상님)

“AI Project를 간지나게. 무엇이 프로젝트를 간지나게 만들까요?”

  • 좋은 팀
  • 풀려는 문제의 사이즈와 임팩트가 큰 것

한편 실패하는 머신러닝 프로젝트는?

  • 회사의 코어 비즈니스가 아닌 딴 사업
  • 낮은 데이터 품질 (로그를 찍는데 시간을 안써요)
  • 딥러닝만이 답이 아니다! 통계적 ML도 유의미함
  • 확증편향: 이거로 하면 잘 될거야! (행복회로 화르륵)
  • 부족한 인프라 - GPU 500대만 주세요

등등.. 수많은 실패하는 원인.

그렇다면 어떤 프로젝트를 시작해야 할까?

“투자 대비 10배가 나오는 프로젝트”

나쁜 계획:

​ 팀 = 1인 + 1PC + 3개월

​ -> 현실적으로 불가능함!

현실적 계획:

​ 팀 = PM + BM + DS + ML 이렇게 최소 4명

여기서 저 4명의 파티를 어떻게 잘 모으느냐가 가장 큰 관건

그런데- S급 인재 4명 월급은 4k, AWS비용은..? + 기간은 1년 => 8억!

x10배 원칙 하면 80억!

“어떤 ML 프로젝트를 해야 80억의 가치를 가져올 수 있을까?”

어떤 프로젝트를 해야 80억의 가치를 가져올 수 있나 + 회사의 메인 비즈니스 체인에서 ML을 이용해 어떤 개선을 만들 것인가?

  • 맥킨지 등의 Importance factor
  • Business factor => 현재 회사의 상태에 맞게 적용할 수 있는 방법론

또한 현재 회사들에서 다루는 대부분의 데이터는 Structured Data(1위)

그리고 데이터를 EDA하는 과정과 Corelation, 그리고 통계적 검증(빈도/타당도/z스코어/t스코어 등)을 하는 것 자체만으로도 얻는 결과가 크다.

그리고 만약 ML Project를 시작한다면 AutoML 혹은 Managed ML 서비스에서 돌려보는 것을 추천한다.

도메인 지식에 따라 Feature selection이 이루어질 수 있는데, 해당 부분은 우선 전체를 넣어보는 것이 일부만 골라 넣는 것보다 낫다.

그리고 딥러닝 모델을 만드는 데 있어 평가를 하는 Metric을 공유하는 것이 매우 중요함. “어떤 것을 높여야 우리가 원하는 모델인가?”

그럼에도 비즈니스 impact를 세상이 주려면… 어려움 ㅠㅠ

Session 03. 온라인 게임 데이터 분석 사례와 향후 과제 (by 이은조님)

“무엇이 (ML모델 개발의) 불쾌한 골짜기를 만드는가?”

ML모델을 만드는 과정 중, 간단한 모델을 만들어 어느정도 성과가 나오다가 일정 시기가 지나면 들이는 노력에 비해 굉장히 낮은 성과가 나오기 시작한다. 이 구간을 불쾌한 골짜기에 비유.

특히 Data가 시간이 지나면서 자체적으로 변화하기 때문에(게임의 경우 게임 업데이트 등) 기존의 데이터로 학습한 ML 모델이 제대로 동작하지 않는 경우가 많다. => “Concept Drift”

Academic issue를 연구할 때는 위와 같은 Concept drift를 경험하는 경우가 적으나, 실제 현실에서는 굉장히 많이 자주 접하게 되는 부분이고, Train data와 Live data와의 간극이 커지면서 Feature 자체가 바뀌게 된다.

따라서 이에 대한 해결책으로 Robust modeling을 선택해 불변하는 Feature를 지정해 모델을 만들 수도 있다. 하지만 심각한 문제는 그런 Feature로 만든 모델은 굉장히 Naive할 수 밖에 없다는 한계가 있다.

즉 모델을 실제로 배포할 때는 LiveData의 성능을 주기적으로 측정하는 것을 통해 모델의 성능을 감시하는 것이 필요하다. 물론 Online Learning같은 방식을 도입하는 것도 방법.

그리고 데이터와 모델 성능을 측정하는 것에 있어 Citizen data scientist와 같은 사람들의 참여가 있으면 좋다!

또한 정확도를 높인다 라기 보다는… ‘비용 지출’의 관점에서 볼 수도 있다. 전체 고객을 대상으로 이탈 예측 모델링을 돌리면 이미 이탈한 유저가 포함되어있기 때문에 마케팅 비용이 오히려 클 수 있지만, 충성고객만을 대상으로 한 경우는 기대이익을 높일 수 있다.

여기서 질문: “기대 이익 자체를 Loss Function으로 만들 수는 없을까?”

Session 04. 한국어 인공지능 콜센터 (by 맹윤호님)

IBM 왓슨 이용한 방식. 한국어는 원래 지원하지는 않지만 Custom으로 추가한 MVP(Minimal Viable Product)수준의 개발!

이슈: 옛날에는 이미지 or 버튼 선택의 챗봇을 했지만 이제는 ‘문장’단위의 자연어 처리하는 챗봇.

새로운 챗봇은 이제 사람이 말하는 걸 듣고 답해주는 콜센터가 되어야 한다.

한편 STT 데이터들은 8Khz(Narrow band)와 16Khz(Broad Band)가 있는데 현실에서는 데이터가 뒤죽박죽이고 양도 많지도 않음.

따라서 새로운 데이터를 만들어야 하는데…

  1. 음성을 듣고 텍스트로 받아적기: 가장 좋은 접근방법이고 현실적 데이터를 얻을 수 있다.
  2. 텍스트를 ‘읽어’ 음성 만들기: 빠른 데이터 생성이 가능함. 하지만 비현실적임

데이터가 없으면 QnA기반에서 만들어주거나 혹은 텍스트기반 고객센터 내용을 가져와 사용하기도 한다.

한편 STT 학습은 Lightly Supervisored Learning을 사용해 TimeStamp 없이도 학습! (LanguageModel 메뉴에서 지원함) 하지만 학습한 모델을 평가할 때는 TimeStamp된 데이터가 있어야 평가가 가능하다.

Chatbot이라는 측면에서 분기를 탄 뒤 Multilayer custom model을 만들어서 상황에 최적화된 Utterance별로 다른 모델을 사용하도록 만들게 된다.

전화를 사용하는 Chatbot이니 twilio등의 서비스를 이용해 가상 전화번호를 받아와 사용할 수 있다.

+사람들은 AI에 존댓말을 사용하지 않는다. 한편 train data는 존댓말 기반으로 이뤄지기 때문에 Train data와 live data와의 괴리가 생기게 된다. +짧은 단어만을 사용하는 것도 이슈.

적은 양의 정보만으로 이야기 하는 상담 대화의 데이터가 필요하나 현재는… (ㅠㅠ)

Session 05. 딥러닝과 자동차 (by 조국현님)

말 그대로 “최적화” 이야기. SIMD(AVX 등), SIMT(CUDA등)….

(사실 잘 모르는 내용이라 이해를 많이 못했다 ㅠㅠ 다만 최적화를 엄청 빡세게 한다는 것은 느낌.)

##Session 06. MOBILITY X DATA : 모빌리티 산업의 도전 과제 (by 변성윤님)

  • Google OR Tools
  • DeepST -> CNN 기반으로 수요예측하는 모델
  • SimPy: 시뮬레이터!
  • Route Planning: 어떤 길로 가지?
  • Map Matching: GPS를 도로 위로! (차가 바다 위에 떠있지는 않을테니까)

그 외에도 모빌리티에서 사용하는 다양한 사례. 그 주에 타다를 타고 배차를 하는 이야기를 들었는데 실제 현실에서 적용되는 케이스가 굉장히 합리적이고 잘 설계되었다는 느낌을 받았다.

Session 07. 린하게 구축하는 스타트업 데이터 파이프라인 (by 박재영님)

DataLake & Data ETL & Data Warehouse

DataLake

KInesis(Firehorse) -> S3 & ElasticSearch

Hot Data -> Redis

실시간 데이터 분석은 RDS Replica DB로 Custom Endpoint (메인 DB에 영향 거의 주지 않음)

Data ETL

Before: Single EC2 + Jupyter

Now: AWS EMR

Task관리는 Zeppelin + EMR AutoScaling // DAG관리에서 Airflow를 사용중은 아님.

Data Warehouse & BI

RedShift + 태블루(좋지만 비쌈…)

=> 대신 AWS QuickSight! (but 개발자를 위한 서비스)

=> MS Power BI (엑셀과 비슷해 비개발자도 쓰기 편함)

Session 08. AI의 스타크래프트 도전기 (by 배창현님)

분명히 빡세고 어렵다. 하지만 RL로 해보자는 도전!

-> Facebook쪽 팀도 이김! 1등!

벌쳐의 아주 강력한 카이팅(신컨)

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×