[2018 프로그래밍 트렌드 따라잡기]프로그래밍, 21가지 뜨는 트렌드와 지는 트랜드

프로그래머들은 유행이 바람처럼 왔다가 사라지는 패션 세계를 비웃곤 한다.

스커트 길이가 짧아졌다가 길어지고, 넥타이가 두꺼워졌다가 다시 얇아진다.

IT 세계에서는 이런 유행보다는 엄격함, 과학, 수학, 그리고 정밀함이 더 중요하다.

그렇다고 프로그래밍이 유행과 동떨어진 직업은 결코 아니다.

프로그래밍 세계에서 유행을 이끄는 힘은 패션 세계와는 달리 더 높은 효율성, 더 유연한 맞춤 구성 기능, 그리고 사용 편의성 이라는 점이다.

이 가운데에서 하나 이상을 제공하는 새로운 기술은 이전 세대 기술을 밀어내 고 그 자리를 차지한다.

기발함 중심이 아닌 철저한 실력 중심이다.

다음은 현재 프로그래머 사이에서 뜨는 기술과 지는 기술 목록이다.

각각의 목록에 대해 동 의하지 않는 사람도 물론 있다.

결국 빠른 변화, 치열한 논쟁, 그리고 뜻밖의 복귀는 프로그래머 라는 직업이 매력적인 이유이기도 하다.

프리프로세서(Preprocessors) vs 풀 랭귀지 스택(Full language stacks)

예전만 하더라도 새 프로그래밍 언어를 만들려면 코드를 반도체 칩이 알아듣는 비트로 바꿔 주는 모든 것을 직접 만들어야 했다.

그러다 이전 작업을 그대로 이용할 수 있다는 사실이 드러났다.

이제 사람들은 좋은 아이디어가 떠오르면 그냥 프리프로세서를 작성한다.

이 프리프로세서는 새 코드를 풍부한 라이브러리와 API 집합을 갖춘 기존의 무언가로 바꿔준다.

파이썬 또는 자바스크립트와 같은 스크립팅 언어는 한때 소규모 프로젝트에 제한적으로 사용됐지만 지금은 중차대한 작업의 기반으로 사용된다.

자바스크립트를 좋아하지 않았던 사람은 번거로운 구두점 없이 코딩할 수 있게 해주는 프리프로세서인 커피스크립트(CoffeeScript)를 만들었다.

현재 각기 다른 방식으로 구문을 나누고 자르는 수십 가지의 변형이 있다.

동적 타이핑을 좋아했던 사람은 지긋지긋한 구두점이 없는 자바의 더 간소한 버전인 그루비(Groovy)를 만들었다.

JVM에서 실행되는 언어는 그루비, 스칼라(Scala), 클로저(Clojure), 코틀린(Kotlin) 등 10여 가지에 이르지만 JVM은 하나다.

닷넷의 VM에서도 많은 언어를 실행할 수 있다.

이미 있는 것을 굳이 다시 만들 필요가 없다.

서버리스(Serverless) vs 도커(Docker)

사실 도커 컨테이너는 모든 곳에 사용된다.

서버는 쉴 새 없이 컨테이너를 올리고 내린다.

그러나 도커 컨테이너는 필요에 비해 덩치가 너무 커졌다.

잘 생각해 보면 지금 배포하고 있는 마이크로서비스를 위한 실질적인 의사 결정 코드는 수십 줄만 쓰면 된다.

그러나 Node.js든 무엇이든 도커에서 제대로 가동되도록 하려면 방대한 양의 구성 코드를 집어넣어야 한다.

물론 모두 규격화된 표준 구문이지만 요점은 그게 아니다.

새로운 서버리스 아키텍처를 사용하면 실제 의사 결정을 실행하는 몇 개의 if-then-else 문만 넣으면 된다.

그 외의 모든 것은 서버리스 플랫폼을 임대해주는 쪽에서 알아서 할 일이다.

물론 몇 년이 지나면 종속과 맞춤 구성의 부족에 대해 불평하겠지만 지금은 서버리스 옵션이 모든 데브옵스와 구성으로부터의 달콤한 구원으로 보인다.

자바스크립트 MV* 프레임워크(JavaScript MV* frameworks) vs 자바스크립트 파일(JavaScript files)

오래 전에는 모두가 경고 상자를 팝업으로 띄우기 위해, 또는 양식의 이메일 주소에 @ 기호가 포함되었는지 여부를 확인하기 위해 자바스크립트를 배웠다.

지금은 HTML AJAX 앱이 워낙 잘 되어 있어서 처음부터 새로 시작하는 사람은 거의 없다.

정교한 프레임워크를 가져와 글루 코드(glue code)를 약간 써서 비즈니스 로직을 구현하는 편이 더 간단하다.

지금은 켄도(Kendo), 센차(Sencha), j쿼리 모바일(jQuery Mobile), 앵귤러JS(AngularJS), 엠버(Ember), 백본(Backbone), 메테오 JS(Meteor JS) 등 수십 가지 프레임워크가 존재하며 모두 웹 앱과 페이지를 위한 이벤트나 콘텐츠를 처리할 수 있다.

이는 단순한 웹 앱일 뿐이다.

또한 스마트폰/태블릿 세상을 위한 크로스 플랫폼 개발에 맞게 튜닝된 것도 있다.

네이티브스크립트(NativeScript), 폰갭(PhoneGap), 아파치 코도바(Apache Cordova), 리액트 네이티브(React Native)는 HTML5 기술로 앱을 만들기 위한 여러 가지 옵션 가운데 일부다.

CSS 프레임워크(CSS frameworks) vs 일반 CSS(Generic CSS)

한때 웹 페이지에 활기를 불어넣으려면 CSS 파일을 열고 font-style:italic과 같은 새로운 명령을 집어넣었다.

그렇게 파일을 저장하고 힘든 오전 일을 마친 후 점심을 먹으러 갔다.

현재 웹페이지는 상당히 복잡해 이런 단순한 명령으로 파일을 채우기가 불가능하다.

색상 하나 바꾸려고 했을 뿐인데 모든 곳에서 어긋난다.

음모론과 생태학에서 흔히 말하듯이, 모든 것이 연결되어 있다.

SASS나 그 사촌인 컴파스(Compass)와 같은 CSS 프레임워크가 이 부분에서 탄탄한 기반을 마련했다.

CSS 프레임워크는 실변수(real variables), 중첩 블록(nesting blocks), 믹스인(mixin)과 같은 프로그래밍 구조를 제공함으로써 읽기 편하고 안정적인 코딩을 장려한다.

프로그래밍 계층에서는 그다지 새로운 이야기가 아닐지 몰라도 설계 계층에서는 큰 진전이다.

캔버스(Canvas)의 SVG(Scalable Vector Graphics) vs 플래시(Flash)

플래시는 몇 년 전부터 공공의 적으로 취급됐지만 아티스트들은 항상 플래시의 결과물을 좋아했다.

안티앨리어싱(anti-aliased)이 적용된 렌더링은 보기 좋고 많은 재능있는 아티스트가 세련된 화면 전환과 애니메이션을 위해 깊은 플래시 코드 스택을 구축했다.

가벼운 게임의 인기도 계속되고 있다.

웹에서 플래시의 생명력은 끈질기다.

자바스크립트 계층이 플래시와 거의 동일한 작업을 할 수 있게 된 지금, 브라우저 업체와 개발자들은 플래시의 종말에 힘을 싣는 중이다.

SVG와 같은 새로운 형식은 DOM 계층과의 통합에 더 유리하다.

SVG와 HTML은 웹 개발자가 사용하기 쉬운 방대한 태그 모음을 형성한다.

또한 비디오 카드의 힘으로 캔버스 개체 상에서 정교한 드로잉을 제공하는 API가 있다.

이 둘을 합치면 플래시를 사용할 이유는 거의 남지 않는다.

유사 빅데이터(하둡없는 분석) vs 빅데이터(하둡 있음)

모두가 조직에서 돋보이는 사람이 되길 원한다.

그렇지 못하다면 자신이 돋보일 수 있는 적당한 크기의 조직을 물색한다.

그렇게 보면 "빅데이터"라는 용어가 중역실까지 흘러 들어가 높으신 분들이 마치 요트나 고층 건물을 구입하듯 가장 크고 가장 강력한 빅데이터 시스템이 무엇이냐고 묻기 시작한 것은 자연스러운 수순이다.

재미있는 점은 굳이 가장 웅장한 빅데이터 솔루션을 사용해야 할 만큼 큰 문제는 별로 없다는 것이다.

물론 구글 또는 야후와 같은 기업은 모든 사람의 웹 탐색을 추적하고, 페타바이트 또는 요타바이트 단위의 데이터 파일을 보유하고 있다.

그러나 대부분의 기업이 보유한 데이터는 기본형 PC의 RAM에 다 들어가는 정도다.

필자는 이 글을 16GB RAM이 장착된 PC에서 쓰는 중이다.

몇 바이트짜리 이벤트 10억 개도 들어가는 용량이다.

대부분의 알고리즘에서는 데이터를 메모리로 읽어 들일 필요가 없다.

SSD에서 스트리밍하는 것만으로 충분하기 때문이다.

병렬로 실행되는 하둡 클라우드 내 수십 개 시스템의 빠른 응답 시간이 필요한 경우도 있지만, 많은 경우 조율이나 통신에 신경 쓸 필요 없이 단일 시스템으로 충분히 굴러간다.

스파크(Spark) vs 하둡(Hadoop)

하둡이 식었다기보다는 아파치 스파크가 뜨겁다는 편이 정확하다.

스파크로 인해 하둡 모델이 구식처럼 보인다.

스파크는 대량의 데이터에서 의미를 추출하는 하둡 접근 방식에서 가장좋은 부분을 차용한 다음 여기에 코드 실행 속도를 대폭 높이는 개선을 더해 업데이트했다.

가장 큰 부분은 스파크가 모든 요소를 분산 파일 시스템에 쓰고 읽을 필요 없이 빠른 메모리 안에 데이터를 보관한다는 것이다.

물론 많은 사람은 하둡의 분산 파일 시스템에 저장된 데이터에 스파크의 처리 속도를 사용하는 식으로 두 가지 방법을 합친다.

하둡과 스파크는 경쟁 상대보다는 파트너에 가깝다.

데이터베이스 구성(Database configuration) vs 소프트웨어 프로그래밍(Software programming)

오래 전, 프로그래머들은 다음 세기의 프로그래밍이 어떤 형태가 될지는 모르지만 이름은 분명 포트란(Fortran)일 것이라는 우스개 소리를 즐겨 했다.

너무 웃겨서 의자에서 굴러 떨어져 다쳤다는 전설도 있다.

그리고는 자리로 돌아가 데이터베이스 구성 작업에 몰두했다.

우리는 지금도 데이터베이스를 구축하고 있지만, 지금 개념의 "데이터베이스"는 과거보다 훨씬 더 정교하고 강력하다.

범용 데이터베이스는 여러 대륙에 걸쳐 스스로를 동기화하면서 일관성과 속도 사이에서 유연한 균형점을 제공한다.

파이어베이스(Firebase)와 같은 일부 클라우드 서비스는 모바일 클라이언트에서 실행되는 웹 앱까지 새로운 데이터를 푸시한다.

서버리스 혁명(serverless revolution)의 대부분은 이제 클라우드 데이터 저장소의 상당수가 아주 강력해 if-then-else 문 몇 개만 쓰면 멋진 웹 앱을 만들 수 있다는 인식에 그 기반을 두고 있다.

게임 프레임워크(Game frameworks) vs 네이티브 게임 개발(Native game development)

한때 게임을 개발하려면 개발자를 많이 채용해 모든 것을 처음부터 C로 작성했다.

물론 많은 비용이 들었지만 보기에 그럴듯했고 잘 굴러갔다.

지금 맞춤형 코드는 아무도 감당할 수 없는 사치다.

대부분의 게임 개발자는 오래 전에 자부심을 포기했으며 이제는 유니티(Unity), 코로나(Corona), LibGDX와 같은 라이브러리를 사용해 시스템을 구축한다.

이들이 작성하는 C 코드의 양은 라이브러리에 대한 지침보다도 적다.

자부심을 갖고 일일이 수작업으로 게임을 만들지 않고 동일한 엔진을 사용해 찍어낸다는 것이 과연 수치스러운 일일까?

아니다.

대부분의 개발자에게 이는 구원이다.

세세한 면에 신경 쓸 필요가 없으므로 게임 플레이, 이야기의 전개, 캐릭터와 아트에 집중할 수 있게 됐다.

정적 웹사이트 생성기(Static website generators) vs 단일 페이지 웹 앱(Single-page web apps)

URL이 가리키는 웹 페이지가 정적 테스트와 이미지만으로 구성됐던 시절을 기억하는가?

그이후 동적 단일 페이지 웹 앱이 등장했다.

데이터를 검색하는 하나의 똑똑한 웹 앱이 이런 웹 페이지를 모두 대체했다.

그런데, 시계추가 되돌아와서 지금은 다시 모든 애들이 정적 사이트 생성기를 만들고 있다.

수십 가지나 된다.

하이브리드와 같다.

모든 데이터를 한 곳에 쌓은 다음 이 데이터를 템플릿에 붙이는 코드를 쓴다.

따라서 각 정적 URL마다 하나의 HTML 파일이 있고, 이는 데이터 테이블의 각 행에서 가져온다.

신입 개발자들은 이런 정적 사이트가 초고속이라고 생각하는데, 실제로도 빠르다.

다만 이들에게 대놓고 말하기는 좀 그렇지만, 워드프레스(WordPress)와 드루팔(Drupal)같은 기존의 동적 시스템도 최신 데이터를 사용해 생성된 정적 페이지로 채워진 캐시를 보관함으로써 거의 같은 방식으로 동작했다.

그래프QL(GraphQL) vs REST

REST도 죽진 않았다.

다만 사람들은 API로 더 많은 일을 하고 싶어하고, 그래프QL이 그 방법을 제공할 뿐이다.

그래프QL은 REST와 마찬가지로 JSON으로 데이터를 반환한다.

그래프QL은 REST 호출과 마찬가지로 HTTP POST로 시작한다.

그래프QL 구문의 장점은 극히 복잡한 쿼리를 아주 간단하게 지정할 수 있다는 점이다.

덕분에 프로그래머는 원하는 것을 간단히 요청할 수 있다.

또한 아주 약간 다른 API가 필요할 때 해야 하는 서비스 측 작업의 양도 줄어든다.

클라우드 IDE(Cloud IDEs) vs 로컬 IDE(Local IDEs)

오래 전 사람들은 명령줄 컴파일러를 사용했다.

그러다가 누군가 명령줄 컴파일러를 편집기 및 기타 툴과 통합해 IDE(Integrated Development Environment)라는 것을 만들었다.

이제 IDE는 코드, 심지어 작업 중인 시스템의 코드까지 편집할 수 있게 해주는 브라우저 기반 툴로 대체될 시점이다.

워드프레스의 작동 방식이 마음에 들지 않는 사람을 위해 코드를 그 자리에서 바로 변경할 수 있는 내장 편집기가 제공된다.

마이크로소프트 애저는 포털에서 자바스크립트 글루 코드를 바로 작성할 수 있게 해준다.

이런 시스템은 최적의 디버깅 환경을 제공하지는 않으며 프로덕션 코드 편집에 따르는 위험성도 있다.

그러나 그 개념은 유효하다.

AWS 클라우드9, 코드엔비(Codenvy), 모질라의 웹 IDE로 시작할 수 있지만 계속 더 탐구해야 한다.

웹 기반 툴은 점점 더 강력해지고 있다.

예를 들어 마이크로소프트 애저 웹 사이트에서 완전한 빅데이터 분석 프로젝트를 구축하는 것도 가능하다.

서버리스 옵션 쪽으로 시선을 돌리면 웹 페이지의 양식 요소에 모든 코드를 쓸 수 있다는 사실을 발견할 수 있다.

페이스북에서 친구를 업데이트할 때 사용하는 양식과 별 차이도 없다.

GPU vs CPU

소프트웨어가 단순하고 명령어가 한 줄에 가지런히 배열되던 시절에는 CPU가 모든 무거운 작업을 다 처리했으므로 컴퓨터의 왕이었다.

지금의 비디오 게임은 병렬로 실행되는 광범위한 그래픽 루틴으로 꽉 차 있다.

이제는 그래픽 카드가 주인공이다.

괜찮은 그래픽 카드의 가격은 500, 600달러를 훌쩍 넘고, 열혈 게이머들은 그래픽 카드를 두 개 이상 사용하기도 한다.

이 경우 그래픽 카드 가격만 기본적인 데스크톱 가격의 두 배 이상이다.

게이머만 GPU 카드에 집착하는 것도 아니다.

컴퓨터 과학자들도 현재 많은 병렬 애플리케이션을 변환해 GPU에서 수백배 더 빠른 속도로 실행하고 있다.

데이터 과학자들은 GPU가 빼곡히 들어찬 서버를 사용해 머신러닝 모델의 개발 속도를 높인다.

깃허브(GitHub) vs 이력서(Resumes)

물론 중학교 바둑 동아리 부회장 이력을 포함한 시시콜콜한 성취 목록을 읽는 것으로 구직자에 대해 알아볼 수도 있다.

그러나 그 사람이 작성한 실제 코드를 보는 것이 훨씬 더 유익하고 많은 정보를 얻는 방법이다.

주석은 충실히 작성하는가?

별 기능도 없는 자잘한 클래스로 각종 항목을 분할하느라 너무 많은 시간을 소비하는가?

확장의 여지가 있는 실질적인 아키텍처가 있는가?

코드만 훑어보면 이런 모든 질문에 대한 답을 구할 수 있다.

구직을 위해 오픈소스 프로젝트에 참여하는 것이 점점 더 중요해지는 이유이기도 하다.

사유 프로젝트의 코드는 공개적으로 올리기 어렵지만 오픈소스 코드는 어디든 게시할 수 있다.

임대(Renting) vs 구매(Buying)

아마존은 블랙 프라이데이를 맞아 컴퓨터를 비롯한 전자제품 할인에 돌입했지만 정작 아마존 클라우드 할인은 행사에 포함하지 않았다.

기다리면 그런 날도 올 것이다.

얼마 전까지만해도 기업들은 자체 데이터센터를 열고, 직접 구매한 컴퓨터를 운용할 자체 직원을 채용했다.

지금 기업들은 컴퓨터, 데이터센터, 직원, 심지어 소프트웨어까지 시간 단위로 임대한다.

누구도 무언가를 소유하거나 서버를 관리하는 데 따르는 골치 아픈 문제를 떠안고 싶어하지 않는다.

다 좋은 아이디어다.

적어도 웹 사이트가 갑자기 폭발적인 인기를 끌고 문득 모든 비용을 클릭 기준으로 지불하고 있음을 인지하기 전까지는.

클라우드 복잡성(Cloud complexity) vs 클라우드 단순성(Cloud simplicity)

클라우드 컴퓨팅의 초기, 업체들은 버튼을 클릭해 시스템을 가동하는 것이 얼마나 쉬운 지를 강조했다.

단순성이 최고의 미덕이었다.

지금은 코드를 쓰는 시간보다 적절한 시스템을 선택하고 적절한 할인 프로그램을 찾는 데 더 많은 시간이 걸릴 수 있다.

수십 가지 시스템 프로필이 있고 대부분의 클라우드 제공업체는 몇 가지 기존 모델을 지원한다.

제공하는 성능 수준은 제각각이므로 벤치마크를 통해 비용대비 효과가 가장 높은 상품을 선택해야 한다.

예를 들어 RAM을 줄이고 시간당 12센트를 절약할 가치가 있는가?

한꺼번에 100개의 시스템을 한달 동안 가동한다면 가치가 있을 것이다.

게다가 클라우드 업체들은 선불 또는 대량 구매를 조건으로 할인을 해주는 여러 가지 옵션을 제공하므로 계산이 더욱 복잡해진다.

할인도 스프레드시트에 정리해둬야 한다.

클라우드 비용계산을 주제로 한 온라인 강의라도 들어야 할 판이다.

모바일 웹 앱(Mobile web apps) vs 네이티브 모바일 앱(Native mobile apps)

예를 들어 좋은 모바일 콘텐츠 아이디어가 있다고 치자.

바로 iOS, 안드로이드, 윈도우 10 모바일용으로(시간이 난다면 블랙베리 OS까지) 별도의 버전을 만들 수 있다.

각 버전에는 서로 다른 프로그래밍 언어를 사용하는 개별 팀이 필요하다.

그 다음 각 플랫폼의 앱 스토어가 요구하는 터무니없는 조건을 받아들여야 비로소 앱을 사용자에게 제공할 수 있다.

아니면 HTML 앱을 하나 만들어 이를 모든 플랫폼에서 구동되는 웹 사이트에 올리는 방법이 있다.

변경 사항이 있을 때 앱 스토어에 버그 수정을 빨리 검토해 달라고 조를 필요도 없다.

HTML 계층이 더 빨라지고 칩 속도도 더 빨라진 지금 이 접근 방법은 복잡한 상호작용 앱에서도 네이티브 앱과 대등하게 경쟁할 수 있는 수준까지 발전했다.

안드로이드 vs iOS

불과 몇 년 전만 해도 애플 스토어 앞에 사람들이 뱀처럼 줄지어 서 있던 광경을 볼 수 있었다.

시대가 변했다.

아이폰과 아이패드는 여전히 풍부하고 정교한 UI를 좋아하는 굳건한 팬층을 보유하고 있지만 순수 판매 수치를 보면 계속 안드로이드로 기우는 중이다.

판매되는 폰의 80%이상이 안드로이드라는 언론 보도도 있다.

그 이유는 단순하다.

바로 비용이다.

iOS 디바이스는 변함없이 상당히 비싼 반면 경쟁 업체들이 넘쳐나는 안드로이드 세계에서 생산되는 태블릿 중에는 가격이 애플 대비 1/5에 불과한 경우도 있다.

가격이 싸다는 것은 언제나 강력한 매력이다.

오픈소스도 또 다른 요인이다.

안드로이드 시장에서는 누구나 경쟁할 수 있다.

크고 작은 온갖 안드로이드 태블릿이 있다.

안드로이드 카메라, 안드로이드 냉장고도 있다.

누구도 혁신을 위해 사전에 구글에 허락을 받을 필요가 없다.

아이디어만 있으면 그대로 실천하면 된다.

Node.js vs 자바 EE(Java EE), 루비 온 레일즈(Ruby on Rails)

지금까지 서버 세계는 프로그래머의 고집스럽고 비효율적이고 무절제한 행동을 운영체제가

다 받아주도록 하는 스레드 모델 위에서 번창했다.

이상한 루프, 과도한 계산, 프로그래머가 무엇을 코딩하든 운영체제는 스레드 사이를 왔다갔다하면서 성능의 균형을 맞춰준다.

그런데 자바스크립트 콜백 프로그래밍 모델을 갖춘 Node.js가 등장했고 코드의 실행 속도가 빨라졌다.

한때 경고 상자용으로 사용됐던 장난감같은 이 언어에서 이 정도 속도가 가능할 것 이라고는 누구도 예상하지 못했다.

새 스레드에 수반되는 오버헤드가 명확히 드러났고 Node.js가 떴다.

프로그래머가 잘못 행동할 경우 문제가 발생하지만 이 책임성은 대체로 프로그래머에게 긍정적으로 작용했다.

프로그래머에게 리소스 제약이 명확하게 제시되면 보통 프로그래머는 더 빠른 코드를 생산한다.

브라우저와 서버 간의 조화도 Node.js 세계에는 이득이다.

동일한 코드가 양 쪽 모두에서 실행되므로 개발자는 손쉽게 기능을 살펴보고 복제할 수 있다.

결과적으로 Node.js 계층은 지금 인터넷에서 가장 뜨는 스택이 됐다.

PHP 7.2 vs 기존 PHP

과거 PHP는 동적 웹 페이지를 뚝딱 만들어 내기 위한 간편한 수단이었다.

다양성이 좀 필요하다 싶을 때 HTML 태그 사이에 간단한 코드만 집어넣으면 됐다.

기초적이라 웹 개발자는 어렵지 않게 수용할 수 있었지만 속도가 느린 탓에 하드코어 프로그래머들은 시큰둥했다.

하지만 다 지난 이야기다.

워드프레스, 페이스북 등 곳곳의 PHP 애호가들이 한때 자바를 고성능 솔루션으로 만들었던 JIT(Just-in-Time) 컴파일러 기술을 채택함으로써 PHP 코드를 예전보다 훨씬 더 빠르게, 경쟁적으로 실행하고 있다.

현재 힙합(HipHop) 가상 머신, PHP 7.2와 같은 툴은 이전 버전에 비해 2배 더 빠른 속도를 제공한다.

Node.js와 자바는 경계해야 할 것이다.

적시 교육(Just-in-time education) vs 4년 선행 투자(Four years up front)

컴퓨터 매개 교육 과정은 더 이상 새롭지 않다.

누구나 동영상 강의를 보면서 버튼으로 속도를 높이고 낮추고 방금 들은 부분을 반복 재생하기도 한다.

온라인 포럼 역시 말빨 좋은 한 명이 토론을 지배할 수 있었던 과거의 세미나 룸에 비해 개선된 개념이다.

그러나 교육 업계를 뒤흔드는 요소는 온라인 교육 과정의 기반 기술만이 아니다.

언제, 어디서나 필요할 때 학습할 수 있는 유연함도 있다.

덕분에 사람들은 더 이상 자신의 삶에 중요할지 어떨지도 모르는 광범위한 교육 과정 모음에 4년이라는 어처구니 없는 시간을 투자할 필요가 없어졌고, 이로 인해 교육 역학이 바뀌고 있는 것이다.

실제로 컴파일러를 다루게 될지 여부를 알기도 전에 컴파일러 교육 과정을 들을 필요가 있는가?

사장이 관계형 데이터베이스에서 NoSQL 엔진으로 전환하고자 하면 그때 현대적 데이터 저장소에 대한 과정에 시간을 투자하면 된다.

필요할 때 최신 정보를 습득하므로 빠른 속도로 부식하는 지난 개념으로 머리를 어지럽힐 일도 없다.

출처 : IDG Korea - HowTo 2018 프로그램 트렌드