4차산업 혁명, 직장인에게 퇴사란(?)

 * 사는 것보다 파는 것이 더 중요하다 -- 주식 고수들
 * 등산보다 하산이 더 중요하다 -- 등산하는 사람들
 * 빨리 올라가는 것보다 잘 내려오는 것이 더 중요하다 -- 정치인들
 * 이륙하는 것보다 착륙하는 것이 더 중요하다 -- 파일럿들
 이렇듯 회사 또한 입사하는 것보다 언제 어떻게 퇴사하는지가 중요하다. 우리는 도대체 언제 퇴사해야 할까? 잘 내려오지 못하면 이전보다 더 높이 올라 갈수가 없거든. 

 먼저 실리콘 밸리의 IT 업계를 얘기 한번 들어보자. 태평양을 건너 구글에 입사한 친구 왈, 1년차 퇴사율이 50%에 육박한다고 한다. 여기서 대부분의 한국 직장인들은 의아해 한다. "그리 좋은 회사를 와이!?". 우리는 퇴사라는 단어를 너무 부정적인 의미로 바라보기 때문이다. 내가 이해하는 (좋은 회사를 박차고 1년 이내 퇴사한) 그들의 이유는 의외로 대단히 간단명료하다. 좋은 회사에 취업하는 것이 그들의 목표가 아니기 때문이야.

 왜 한국 인재들은 대기업에 취업하는 것을 고집할까? 첫째도 둘째도 안전했으니까 그렇다. 과거의 한국 제조 산업을 보자. 고용 보장으로 애사심과 근면한 장인 정신을 고취하고 이를 통해 경쟁력을 세계 수준으로 끌어올려왔다. 우리는 모두 그러한 사회에서 근면성실을 최고의 덕목으로 '개근상'이라는 것이 있었고, 부득이한 조퇴 조차 눈치 보며 학교를 다녔지. 우리가 어른이 된 이후 직장 생활에서는 다를까? 연차 휴가를 회사 눈치보지 않고 사용하는 직장인이 과연 몇명이나 될까? 요즘도 농업적 근면성이 갑이다 (비웃음).

 각설하고 문제는 요즘의 회사가 경제구조가 빠르게 변하는 데에 있다. 근속 연수는 계속 짧아지고 일자리는 계속 사라지고 있다. 튼튼한 자동차, 반도체 등 제조 산업은 위기를 당면하고 있으며, On-demand 경제라는게 물 밀듯이 밀려온다. 이러한 상황에서 고용 보장, 대기업 같은 구시대적인 것만 붙잡고 늘어진다면 고민과 시름은 한없이 깊어진다.

 우리는 이때문에 앞으로 퇴사를 실패의 부정적 의미가 아니라 성장하기 위한 과정으로 이해해야하며, 직장인은 항상 퇴사를 진지하게 고민해야할 필요가 있다. 직장생활이 더러워서가 아니라 그게 닥쳐오는 현실과 미래이며, 좋은 회사를 찾는게 아니라 내가 성장하기 위한 회사를 찾아야 하며, 궁극적으로는 자신의 일과 자생력을 만들어 나아가야 한다고 본다.

 사실 이 글을 작성한 계기는 챠니윤의 "개발자 경력 관리 조언" 글을 읽은 것인데, 경력 관리를 통한 "취업전"보다는 자신에 대한 성찰이 먼저여야 하며, (이 글을 접하는 이에게 나마) 화려한 과거 경력이 미래의 일자리를 보장하지 않는다는 점을 말하고 싶었다.

Serverless Computing will be game changer

The core of the emerging Serverless Computing is the programming model paradigm, not container infra technology. One example is the existing event processing programming, which takes the stream data produced in the real world and emits it to the backend,
   frontend: App program -> emit streaming data to backend
   backend: kafka -> storm / spark / dataflow -> data store -> reuse
Inefficiency and disadvantages arising from the structure of the frontend and the backend are complex and slow (eg, distributed queuing, distributed streaming processing, etc.) and difficulty in constructing the server-side system. In particular, the task topology management problems of DAG-style or minibatch-style job are difficult. These are the Storm, Spark, which is now going to legacy.

So how does this change in Serverless?
  App program: pipeline of lightweight functions
To achieve this, runtime provisioning of lightweight function services is required, and that is Serverless Computing.

As another example, imagine the prediction model of Google Flights introduced in the previous post. The traditional approach would be to implement the prediction service by deploying the learned model with the existing dataset:


Machine Learning can also be implemented with the Serverless Computing Architecture in the fashionable DevOps style. The following is the Serverless Architecture of the event-driven prediction algorithm:


The advantage of this is that the complexity of the implementation and system is dramatically reduced, and it is possible to design the system with a decentralized architecture.

Serverless Computing 이란?

최근 대두되는 Serverless Computing의 핵심은 프로그래밍 모델 패러다임에 있다. 한가지 예를 들어, 기존 event processing programming을 보면 현실세계에서 생산되는 stream data를 넘겨받아 backend에서 분산처리하는 구조인데,
   frontend: App program -> emit streaming data to backend
   backend: kafka -> storm / spark / dataflow -> data store -> reuse
이렇게 frontend와 backend 를 나누면서 발생하는 비효율성과 단점은 server-side 시스템 구축이 어렵고 (e.g., 분산 큐, 분산 streaming 프로세싱 등) 복잡하며 느리며 특히, backend의 DAG-style 또는 minibatch-style 분산 컴퓨팅 작업 내 Task topology 관리 문제가 어렵다. 이런걸 하던 애들이 기존에 Apache Storm, Spark 이런건데 이것도 이제 legacy로 가는 거다.

그럼 Serverless에서는 이것이 어떻게 바뀌느냐.
   App program: pipeline of lightweight functions
끗~. 이를 달성하기 위해서 lightweight function 서비스의 runtime provisioning 이 필요한 것이고, 그걸 한다는게 Serverless Computing 이다.

또 다른 예로, 이전 포스트에서 소개한 Google Flights의 가격 변동 예측 모델을 상상해보자. 전통적인 방법은 다음과 같이 기존에 쌓아둔 dataset을 가지고 학습된 model을 deploy 해서 prediction 서비스를 구현 할 것이다:


Machine Learning 또한 요즘 유행하는 DevOps 스타일로 Serverless Computing Architecture로 구현가능하다. 다음은 Event-driven prediction 알고리즘의 Serverless Architecture이다:



이로써 얻는 장점은 구현과 시스템의 복잡도가 극적으로 줄어들며, decentralized architecture로 시스템을 설계 하는 것이 가능하다.

관련 오픈소스는 Tensorflow on Openwhisk 에서 확인해보시라 (주말 프로젝트라 속도가 느림).