12/31/2021

효율적으로 일하는 방법

Written by   in , , , ,   with 댓글 없음

일을 하다보면, 공식적으로 Jira에 관리되어 진행하는 Task와 Jira에서 관리하기 애매한 자잘한 Task들이 존재한다. 거기다가 회의 일정등 여러가지 것들을 복합적으로 관리해야 하는 상황에 부딪히게 된다.

오래전부터 나는 GTD(Getting Things Done)를 사용하여 Task를 구성하고 관리하고 있다.

쉽게 말하면 GTD 방법은 추적하고 있는 모든 것(진행중, 대기, 준비등)을 머릿속에서 제거하고 어딘가에 적어 두도록 구성하는 것이다. 어떤 일을 끝냈을 때, 다음에 해야 할 일을 기억하는데 에너지를 쏟을 필요가 없는 것이다.

Email

사용 툴 : Outlook

대부분의 사람과 마찬가지로 내 작업의 대부분은 이메일을 통해 이루어진다. 다른점은 Inbox내에 처리하지 않은 작업만 남아 있을 뿐이다.

가능하면 Inbox(받은 편지함)내에 메일이 0이 되도록 노력중이다. 메일이 올 때마다 메일을 읽고 즉시 처리할 작업을 결정한다는 의미다. 새로운 메일을 받게되면 분류하거나 처리하는 작업을 절대 미루지 않는다.

  • Action
    • 조치를 취해야 하는 모든 이메일이 표시된다. 기한이 있는 작업이라면 캘린더나 Task 관리툴에 등록한다.
  • Waiting For
    • 다른 사람의 작업 완료를 기다리는 메일에 지정한다.
    • 내가 누군가에게 메일을 보냈고, 받은 사람이 처리하기를 기다린다는 것을 기억할 필요가 없다.
    • 이 메일에 대한 응답을 받으면 레이블을 제거한다.
  • Reference
    • 나중에 다시 봐야할 수 있는 정보는 관련 폴더에 저장한다.
    • 메일내 폴더 혹은 원드라이브에 폴더를 지정하여 관리중이다.
  • Archive
    • 작업이 완료된 이메일은 날짜별로 메일내에 폴더를 만들어 관리한다.
      • 2021/12, 2022/01, 2022/02 …

적용해보기

  1. Label 설정 : Action, Waiting For, Reference
  2. 받은 편지함을 정리하여 0(Zero)으로 만들기
    1. 메일을 확인하기 위한 시간을 확보
    2. 메일에 라벨을 지정
    3. 작업이 완료된 받은 편지함의 모든 메일을 보관
  3. 받은 편지함 관리
    1. 받은 편지함의 메일을 검토
    2. 각 메일을 읽고 무엇을 할 것인지 결정
      1. 즉시 답장을 보낸다.
      2. Action 폴더로 이동
      3. 나중에 참조해야 할 경우 Reference 폴더로 이동
      4. 필요 없는 메일일 경우에는 삭제
    3. 메일 답장 후 응답을 받아야 하는 경우 나중에 처리 할 수 있도록 “Waing For” 라벨 지정
  4. 많은 양의 메일로부터 해방되기

메모

사용 툴: Google Keep, Notion

내가 사용하는 메모툴은 다양하지만, 주로 이용하는 툴은 Notion과 Google Keep이다. 특히 Google Keep의 경우 스마트폰을 사용하여 메모를 작성하거나, 사진을 찍어 메모에 추가하고, 알림으로 활용한다.

특히, Google Keep의 경우 시간외에 장소에 대한 알림을 제공하기에 매우 유용하다. 그리고 Google Calendar와 연동되기에 캘린더에서 모두 확인할 수 있는 장점이 있다.

  • 필기 하기
  • 작업 관리
    • 메일로 관리되지 않는 작업은 Google Task나 Google Keep을 통해 관리한다.
  • 반복 작업에 대한 체크 리스트
    • 반복적인 작업들은 Task를 설정하여 놓치지 않도록 관리한다.
  • Reference
    • 필요할 때 참조할 수 있는 항목에 대해 관리한다.
    • Google Keep에 “Reference”라는 태그로 지정하고 관리한다.

메모를 정리하기 위해 라벨을 사용한다. 모든 메모에는 여러 개의 라벨이 있을 수 있다. 그 이유는 메모를 찾기 유용하기 때문이다.

  • @Action
  • @Reference
  • Checklists
  • Agenda
  • Project specific notes

위 라벨로 메모를 관리하고 있다.

적용해보기

  1. Keep에서 라벨을 설정한다.
  2. 라벨 설정 예시
    1. 해야할 작업 - @Action
    2. 회의록등을 작성하기 위한 프로젝트 노트 - Project specific notes
    3. 중요한 미팅을 위한 의제 - Agenda
    4. 아이디어 및 영감 관련 노트 - Incubator
  3. 메모 작성시 라벨 지정
  4. 중요한 메모는 고정
  5. 일반적인 활동에 대해 체크리스트 작성

캘린더

사용 톨: Google Calendar, Outlook Calendar

주로 Google Calendar를 이용하는 편이다. 매일 하루가 끝나면 다음 날 일정을 검토하고 미비된 것이 있는지 확인한다. 아침에 출근시 가장 먼저 확인하는 것이 캘린더이고 모든 일정 15분전에 스마트폰으로 알림을 받도록 설정해두었다.

시간이 정해져 있는 모든 활동과 정보를 추적하기 위해 캘린더를 이용한다. 위에서 언급한 메모도 캘린더에서 확인할 수 있다. 개인 일정 및 업무 일정도 라벨을 지정하여 한 곳에서 볼 수 있도록 설정했다.

  • 그날 해야 할 일을 빠지지 않고 확인할 수 있다.
    • 일회성 알림
      • e.g. 요청한 응답이 왔는지 체크하기
    • 정기적 알림
      • e.g. Weekly 작성하기
  • 미틸
  • 작업을 완료하기 위해 예약된 시간 블록
    • Focus time을 활용한다. 내게 주어진 작업을 완료하기 위해 드물지만 일정이 촉박할 경우 Focus time을 확보해둔다.
  • 휴가 및 휴일
    • 내 휴가외에 팀원들의 휴가도 기록한다.

적용해보기

  1. 한 곳에서 모든 캘린더 보기
    1. 개인 및 업무 캘린더 추가
  2. 각 프로젝트에 대한 캘린더 설정
    1. 각 프로젝트별 고유 색상 지정
  3. 일정 알림 설정
    1. 반복 작업
    2. 미팅등

마치며

GTD 방법을 이용한 관리 방식은 개인차가 있을 것 같다. 나의 경우는 작업들을 효율적으로 관리하기 위한 방법인 GTD를 오래전부터 적용하여 습관화가 되어서 편하고 효율적이라고 느끼지만 그렇지 않을 수 도 있을 것 같다.

어쨌든, 밀려오는 업무를 효율적으로 처리하는 방법은 필요하다고 생각한다.

21년의 마지막 날이다. 22년에는 21년보다 나은 내가 될 수 있기를…


12/08/2021

스토리 포인트 바르게 사용하기

Written by   in , ,   with 댓글 없음

 

스토리 포인트는 팀이 특정 기능을 개발하는데 필요한 노력의 양을 추정하기 위한 편리하고 효율적인 측정 기술이다.

스토리 포인트는 추정치이다. 추정은 예측을 하는 것이고 실제 사실과는 다를 수 있다. 애자일 및 스토리 포인트의 제작자도 정기적인 스프린트 기대치를 충족시키지 못했다고 한다. 경영진은 숫자, 약속, 속도등을 원하기에 스토리 포인트를 이용해 그들을 즐겁게 한거라고 한다. 결국 스토리 포인트를 추가함으로써 경영진을 행복하게 만드는 방법을 찾은 것이다. (믿거나~ 말거나~)

일반적으로 사용자 스토리가 주어지면 스토리의 복잡성을 숫자로 추정한다. 1-5 혹은 1-10 범위로 제한되며 때로는 큰 추정치로 작성한다.

예전부터 스토리 포인트를 사용했었다. 스토리 포인트가 팀의 작업 능력을 식별하는 데 도움이 된다고 생각했다. 그러나 이번에 진행을 하면서 스토리 포인트와 퍼포먼스 측정을 내가 잘 사용하고 있는가에 대한 의문이 들었다.

몇 가지 가정을 해보자. 모든 개발자가 동등한 역량을 지니고 있고, 유사한 스킬을 가지고 있고, 전체 스프린트에 걸쳐 있고, 다른 스프린트에 속하지 않는다면, 예측 가능한 시간으로 작업할 수 있기에 추정치와 비슷하게 나올 것이다. 하지만 현실에서는 거의 불가능하다고 생각한다. 그 이유는 아래에 언급한 것들을 세세하게 고려하기가 어렵기 때문이다.

  • Lamp-up 타임 (문제를 이해하고 그 문제를 해결하는 시간) - 사람마다 다르기에 이 부분이 고려되어 있지 않다.
  • 방해 타임 (회의, 1:1 미팅, 비즈니스 우선 순위 변경, 개인 사유등)
  • 숨겨진 작업

스토리 포인트는 무엇을 추정하는데 사용되는 것일까? 고정된 크기의 스프린트와 정확한 포인트 추정치가 존재한다면, 예측 가능한 번다운 비율이 있어야 한다. 이를 통해 고정된 시간 내에 수행될 작업을 매우 정확하게 예측할 수 있게된다. 그러나 현실에서는 정확한 포인트 추정을 할 수 없다. 그래서 번다운 비율을 예측하기가 어렵다. 그렇다고 해서 스토리 포인트가 가치가 없는 것은 아니다.

스토리 포인트의 역할은 복잡성을 측정하는 것이다.우리팀이 스프린트당 얼마나 많은 복잡성을 처리 할 수 있는지에 대한 추정해 볼 수 있는 것인데, 단순히 시간과 같은 것으로 생각했던 것 같다. 일반적으로 포인트1당 = 하루로 계산했던 것 같다. 물론 이렇게 계산하는게 내부적으로도 편하고 경영진과 의사소통하기에도 무난했지만, 이는 잘못된 방식인 것을 깨달았다. 스토리 포인트는 관리를 위한 것이라기보다는, 팀을 위한 것인데… 이 부분을 놓쳤던 것 같다.

우리 인간의 두뇌는 하루에도 많은 일을 처리하고 있다. 팀원들은 시간을 기능으로 바꾸는 기계가 아니다. 즉, “8시간이 하나의 기능을 의미한다면 16시간에는 2개의 기능을 의미한다.” 처럼 잘못된 것으로 인지 될 수 있다. 이것은 사실이 아니기 때문이다. 인간이 하루에 집중할 수 있는 시간은 생각보다 많지 않다고 생각한다. 스토리 포인트가 5점이라고 해서 1점보다 5배의 시간이 걸린다는 의미는 아니고 1점보다 5배 더 복잡하다는 의미로 생각해야했다. 일반적으로 5점짜리가 1점짜리보다 더 많은 시간이 걸릴 가능성이 매우 높기에 이를 시간으로 환산 하려 했던 점이 잘못되었던 것 같다.

이번에 Jira를 세팅하면서 제품 백로그를 추정하기 위해 스토리 포인트를 사용했다. 하지만 스프린트 백로그는 포인트 단위가 아닌 시간 단위로 추정하도록 했다. 즉, 스토리 포인트는 복잡도/장기적 관점에서 활용하고 스토리 포인트는 스프린트 시간으로 나누는 방식이다.

앞으로 스토리 포인트는 팀이 현재 스프린트의 복잡성 추정하는 용도로만 사용할 것이다.

References

  • https://rigidity.medium.com/agile-waste-story-points-pt-1-a9df2572d0a3
  • https://www.leadingagile.com/2018/12/the-problem-with-story-points/


9/28/2021

Miniservices : MSA에 대한 현실적 대안

Written by   in ,   with 댓글 없음

 

마이크로 서비스가 현재 프로덕트를 만들때 가장 인기 있는 트렌드 중 하나라는데 이견이 없습니다. 하지만 모든 상황에서 마이크로 서비스가 적합한지에 대해서는 의문이 듭니다.

제가 블로그에 그동안 많이 언급했던 마이크로 서비스 아키텍처에 대해 마틴 파울러는 다음의 조건을 충족해야 한다고 언급합니다.

  • 독립적으로 배포 가능하고 확장이 가능해야 함
  • 단일 책임
  • 느슨한 결합

하지만, 현실은 만만치 않습니다. Legacy가 있는 경우에는 더욱 그렇습니다.

오늘 소개하려고 하는 미니 서비스는 “마이크로 서비스 그룹이 작은 패턴으로 모인 것”과 같습니다.

위의 그림에 미니 서비스가 중간에 위치한 것을 알 수 있습니다. 흔히들 모놀리스는 레거시라고 하며, 마이크로 서비스는 복잡하고 어렵다라고 합니다.

미니서비스 아키텍처는 여러 책임과 공유 데이터 저장소가 있는 아키텍처입니다. 서비스와 구현 세부 정보가 완전히 분리된 마이크로서비스와 달리 미니서비스는 라이브러리와 데이터베이스를 공유할 수 있습니다.

미니서비스 아키텍처 특징

  • 관련 서비스는 동일한 데이터베이스를 공유할 수 있습니다.
    • 서로 관련된 모듈이 데이터베이스를 공유할 수 있습니다. 예를 들어서 미니서비스는 이미지 처리, 이미지 렌더링 또는 애플리케이션에 대한 기타 관련 기능을 포함한 여러 기능을 수행할 수 있습니다.
  • 서비스 간 통신은 REST API를 통해 이루어집니다.
  • 관련 서비스는 배포에 사용되는 코드베이스 및 인프라를 공유할 수 있습니다.

미니서비스 사용 이점

미니서비스는 확장성, 내결함성 및 견고성을 포함한 마이크로서비스 아키텍처의 모든 이점을 상속합니다.

  • 향상된 성능
    • 도메인 간의 서비스, 상호 연결 및 네트워크 트래픽의 수를 줄임으로써 애플리케이션 성능을 향상 시킵니다.
  • 공유 유지 관리 오버헤드
    • 다양한 관련 기능을 처리하는 서비스를 통해 마이크로서비스와 관련된 유지 관리 오버헤드가 감소합니다.
  • 개발자 친화적
    • 미니서비스는 종종 각 개별 서비스를 전담하는 소규모 개발팀을 구성할 여력이 없는 회사에 더 적합합니다.

미니서비스 한계

종단간 테스트는 단일 서비스와 관련된 종속 항목 수로 인해 미니서비스에서는 어려울 수 있습니다. 그렇기에 효율적인 오류 처리 관련하여 복잡성을 증가 시킬 수 있습니다.

마이크로서비스와 미니서비스

미니서비스는 데이터 저장 및 인프라 공유를 허용한다는 점에서 마이크로서비스와 다릅니다. 미니서비스는 마이크로서비스에 대한 보다 실용적인 접근 방식으로 꾸준히 추진력을 얻고 있습니다.

각 아키텍처별로 장점과 한계가 존재하기에 아키텍처를 선택전 철저하게 분석 및 조사를 하는 것이 중요합니다.

미니서비스란?

이런 상황에서 우리가 행복해지는 무엇일까요? 다음은 레거시가 존재하는 상황에서 미니서비스 아키텍처를 선택해야 하는 이유입니다.

1. 재사용성

미니서비스는 재사용 가능한 코드를 생성하기가 수월합니다. 미니서비스는 프로젝트가 제공해야 하는 모든 도메인간 기능에 쉽게 접근할 수 있도록 합니다. Shared 방식을 활용하기에 모든 서비스가 항상 최신 버전의 기능을 참조합니다. copy-past 코드가 없습니다.

2. 단순성

기존 모놀리스는 경량화하는데 초점을 두고 있기에 우리가 구축하는 애플리케이션의 아키텍처를 관리하는데 이보다 좋은 방법은 없습니다.

애플리케이션 아키텍처는 코드 표준을 생각하고, 구성하고, 적용하는 프로세스로 진행됩니다. 아래의 다이어그램은 다계층 코드 구조를 보여줍니다. domain1은 추가 기능을 위해 domain2의 컨트롤러를 호출합니다.


미니서비스를 올바르게 수행하려면, 합당한 경우에만 커플링을 식별해야 합니다.

3. 분리 그리고 빠른 속도

모든 서비스는 애플리케이션 수준에서 “결합”됩니다. 마이크로서비스처럼 도메인 사이를 이동시 네트워크 트래픽을 걱정할 필요가 없습니다. 아키텍처 구조에 스며들었던 대기열도 발생하지 않습니다.

4. DevOps

각 미니서비스를 독립적으로 배포하여 탄력적으로 만들 수 도 있지만, 그것이 필요한것인지 고민할 필요가 있습니다.

5. 쉬운 디버깅

단일 프로젝트 또는 도메인에 대한 모든 미니서비스를 로컬에서 쉽게 실행 할 수 있습니다. 로그는 쉽게 통합되고 캡쳐되기에 기본적인 디버깅을 수월하게 할 수 있습니다.

6. 네크워크 트래픽 감소


Network Hop이 적을 수록 대기 시간이 줄어들며, 성능이 향상됩니다. 미니서비스는 코드 기반으로 미니서비스간 통신을 허락하거나 혹은 네트워크를 통해 통신을 하도록 선택할 수 있습니다. 어느 방식을 선택하던 런타임을 줄일 수 있는 옵션이 존재합니다.

7. 빠른 개발

각 마이크로서비스별 별도의 데이터베이스를 두는 것이 효율적일지 고민해봐야할 문제입니다. 데이터베이스를 중앙 집중화해도 문제가 없다면, 이렇게 진행하는 것도 방법입니다.

이렇게 하게 될 경우에는 코딩 표준, 원칙, 좋은 코드 작성이 핵심입니다.

8. 공유 간접비

“미니”의 기본 목표와 원칙은 필요한 비즈니스 로직의 양을 최소화 하지만, 분리되는 형태의 아키텍처에 충실하다는 것입니다. 또한 코드를 쉽게 재사용할 수 있는 기능이 제공됩니다.

9. 필요한 경우 마이크로서비스화

미니서비스를 올바르게 수행하려면, 합당한 경우에만 커플링을 식별해야 합니다.


마이크로서비스와 미니서비스는 분리될 수 있습니다. 미니서비스로 구축하고 진행하다가 특정 서비스의 경우 마이크로서비스로 분리가 가능합니다. 이미 앞써서 코드 표준을 지켰기에., 미니서비스와 연동에 대한 부분만 네트워크 접근 방식으로 변경하면 됩니다.

결론

미니서비스는 대부분의 서비스가 매우 느슨하게 결합되는 경향이 있는 애플리케이션에 적합합니다. 마이크로서비스가 원하는 아키텍처라고 해도 미니서비스로 시작하는 것이 프로젝트를 위한 더 나은 출발점이 될 수 있습니다.

자, 우리팀은 어떤 선택을 할까요? 정리되면 공유하도록 하겠습니다.

References:




6/18/2021

자율 주행이 시장에 미치는 영향

Written by   in   with 댓글 없음

최근 자율주행 기술력을 확보하고 있는 회사와 함께 자율주행에 관련된 버티컬 서비스를 기획하고 구축하는 일을 진행하고 있다.

자율 주행 기술은 단계별로 분류된다. SAE(미국 자동차 공학회)에서 자동화 레벨을 2016년에 정의했다.

자율 주행 기술 단계

  • Level 0 (비자동화)
    • 인간이 제어와 주행 책임을 갖는다.
  • Level 1 (운전자 보조)
    • 인간 + 시스템이 차를 제어하며, 주행 책임은 인간이 갖는다. (e.g 차간거리, 조항등 보조)
  • Level 2 (부분 자동화)
    • 인간 + 시스템이 차를 제어하며, 주행 책임은 인간이 갖는다. (e.g 특정한 상황에서 시스템이 보조 운행)
  • Level 3 (조건부 자율주행)
    • 시스템이 제어와 주행 책임을 갖는다. (e.g 특정 조건에서 자율 주행, 위험시 운전자 개입)
  • Level 4 (고등 자율주행)
    • 시스템이 제어와 주행 책임을 갖는다. (e.g 운전자 개입 불필요)
  • Level 5 (완전 자율주행)
    • 시스템이 제어와 주행 책임을 갖는다. (운전자 불필요)

우리나라의 경우 국토교통부가 세계 최초로 자율주행 레벨4에 대한 안전기준을 제정했다. (참고: https://bit.ly/3xy3e23) 그리고 실증 대상지를 선정하여 레벨4에 대한 시범 사업을 진행하고 있다.

상상을 해보자. “완전자율주행”이 상용화 된다면 세상은 어떻게 변할 것인가?

시장 규모

완전자율주행이 현실화된다면 영향을 미칠 시장 규모를 분석했다.

택시


생활에 가장 밀접한 택시 시장의 규모는 2020년 기준 약 8조원이고 카카오, UT, 타다, 마카롱, 티머니onda, 반반택시등과 같은 플랫폼 기업들이 기존 시장을 플랫폼화 시키고 있다.

현재 전국에 약 25만대의 택시가 있으며, “가맹택시”로 확보하기 위한 전쟁을 벌이고 있다.

전국택시운송사업조합연합회의 자료에 의하면,

  • 택시 면허대수: 252,254대
  • 택시 운전자수: 267,842명
  • 일반택시:
    • 등록대수: 9,813대
    • 운전자수: 102,960명
  • 개인택시:
    • 등록대수: 164,662대

2020년 기준 택시 운전자 분들의 월수입은 평균 150만원 ~ 200만원이고, 평균 200만원으로 단순 계산을 하면 매달 약 5400억원이 임금으로 지불된다.

이중, 65세 이상의 택시 운전자가 72,800명이다. 전체 택시 운전자의 약 27% 수준이다. 즉, 택시 운전자 4명중 1명은 고령 운전자이다.

배달


2020년 기준 음식 서비스 배달 시장의 규모는 약 17조 2828억원이다. 코로나로 인해 시장의 규모가 19년에 비해 78.6% 증가했고, 3년동안 약 536% 증가했다.

  • 2017년 2조 7326억원
  • 2018년 5조 2628억원
  • 2019년 9조 7328억원
  • 2020년 17조 3828억원

음식 배달 시장의 성장을 이끌고 있는 것은 배달앱이다. 배달의 민족, 요기요, 쿠팡이츠등 전국민의 절반 가량이 배달앱을 이용하고 있다. 어린이와 고령층을 제외하면 거의 모든 사람이 배달앱을 사용하고 있는 것이다.

고용노동부에 따르면 2019년 기준 배달대행원 숫자 추정치는 약 13만명이고 통계청에 따르면 19년 기준 평균 소득은 약 309만원이다.

19년 기준으로 평균 300만원으로 단순 계산을 하면 매달 약 3,900억원이 임금으로 지불된다.

택배

2019년 기준 국내 택배 시장 규모는 5조 6673억원이다.


2019년 기준 국내 택배 점유율

택배 운송을 자율주행으로 하게 될 경우 고려해야 할 부분은 집앞까지의 배송 및 여러개의 택배가 실린 짐칸에서 배송해야 할 택배를 정확하게 빼야 하는 상황이 존재한다. 그래서 완전자율주행이 되더라도 문앞까지 배송해야 하는 상황으로 인해 전체에 적용되기는 어려워 보인다.

택배 기사님이 직접 운전하지 않고, 아파트까지 자율주행으로 이동 후 그 이후 부터 관여할 가능성이 높다.

캠핑


국토교통부에 따른 2019년 기준 전국에 등록된 캠핑카는 24,869대이다. 2011년에 1300대였지만 8년만에 20배 가량 성장한 수치다.

캠핑카로 튜닝하는 자동차 튜닝 시장은 2019년 기준 3조 8000억원 규모이다.

뜬금없이 캠핑 시장 규모를 조사한다고 생각할 수 도 있다. 캠핑장이나 노지에서 타프와 텐트를 치고 캠핑을 즐기는 방식도 있지만 “차박”도 존재한다. “완전자율주행”이 가능해지면 차 내부의 변화가 “차박”에 많은 영향을 줄 수 있을 것으로 판단되고 더 나아가 캠핑 시장에 영향을 끼칠 수 있다고 생각한다.

자율주행이 일자리를 뺏을 것인가?

자율주행이 보급화되면 승객을 운송하는 차량보다 물류 운송에 더 큰 영향을 미칠 것으로 보는 사람들이 있지만, 물류 운송 운전자들은 단순히 운전하는 것 이상의 일을 하고 있다.

고도로 자동화된 트럭에도 적재, 하역, 유지보수와 같은 손길이 필요하기에 다른 이유로 일자리는 남아 있을 것이다.

승객을 운송하는 분야의 경우에는 커다란 실직 위험이 다칠 수 있다고 생각했다. (e.g 택시)

하지만, 골드만삭스경제연구그룹의 분석결과는 정반대의 결과가 나왔다. 승객을 운송하는 운전자보다 트럭 운전자의 일자리가 더 많이 사라질 것이라는 전망이다.


Stacy Liberatore, Self-Driving Vehicles Are Set to Take 25,000 Jobs a MONTH Away from Americans with Truck Drivers being Worst Hit, DailyMail, 2018. 5. 23.

위의 결과가 모든 국가에 정확히 매칭된다고 생각하지는 않는다. 아파트나 골목이 많은 우리나라의 경우에는 맞지 않을 수 있다고 생각한다.

결론

AI 및 디지털 기술이 발전함에 따라 시스템과 로봇에 의해 일자리가 줄어들 것이라 생각한다. 본 글에서 언급한 자율주행도 대표적으로 일자리를 뺏을 것 같은 기술중에 하나이다.

“어플라이드 인튜이션”의 창업자인 카사르 유니스와 피터 루드비히는

“새로운 기술에 대해 일자리가 대체될 수 있다는 것을 간과해서는 안되지만, 동시에 더 많은 기회가 자율주행이나 새로운 기술로 만들어 질 수 있다”고 얘기한다.

완전자율주행이 시장에 출시되어 기존 택시를 대체한다고 했을 때, 기존에 택시를 소유한 회사/개인에게 사업 라이센스를 부여할 수 있을 것이다. 그리고 자율주행차의 수익의 일부를 가져갈 수 있다고 한다면 새로운 기회가 만들어질 수 도 있지 않을까? 물론, 이와 같은 새로운 기회는 정책이 뒷받침되어야 할 것이다.