이 글은 Song Seunggeun 님의 글을 보고 작성한 글이며, 허락을 받았습니다. 논란의 여지가 있을 수 있지만, 자바스크립트는 2021년 현재 소프트웨어 업계에서 가장 유명한 언어라고 할 수 있습니다. 2020년 Github의 분석에 따르면 자바스크립트는 2014년 이래로 항상 영향력 있는 언어였고, 자바스크립트의 친척이라고 할 수 있는 타입스크립트 또한 그 순위가 4위에 달합니다. Show  자바스크립트는 어떻게 이렇게 유명해질 수 있었을까요? 파이썬, 자바, C 등의 전통의 강자들, 그리고 Golang, Rust, Swift, Dart 등의 신흥 강자들과의 경쟁에서 자바스크립트는 어떻게 우위를 점할 수 있었을까요? 이번 글에서는 클레이튼 크리스텐슨 교수의 파괴적 혁신 이론을 이용해서 자바스크립트가 성장할 수 있었던 이유를 설명해보고자 합니다. 파괴적 혁신 이론 - 돈 안되는 기술 무시하다가 망한다파괴적 혁신 이론은 크리스텐슨이 ‘위대한 기업들조차 왜 실패하는가’ 라는 질문에 대한 해답을 찾는 과정에서 제안한 이론입니다. 필름 카메라 시장의 1위 기업이었던 코닥이 디지털 카메라 시대에 적응하지 못한 사례를 통해서 이번 글의 주제와 관련이 있는 부분만을 좀 더 자세히 들여다보겠습니다! 파괴적 기술이 등장한다파괴적 기술이란 단기적으로 제품의 성능을 떨어뜨리지만 기존 기술이 제공하지 못하는 다른 가치를 제공하는 기술을 의미합니다. 파괴적 기술에 기초한 제품들은 일반적으로 더 싸고, 더 단순하고, 더 작고, 사용하기 더 편리합니다. (혁신 기업의 딜레마, 1997). 예를 들어, 초기의 디지털 사진은 기존의 필름 사진에 비해서 사진의 질은 낮았지만 필름 인화 과정을 거칠 필요가 없다는 편리함을 제공했습니다. 기존 기업은 파괴적 기술이 돈이 안 되서 무시한다기존 시장의 지배적인 기업은 파괴적 기술을 이용할 지 여부를 검토하지만, 돈이 되지 않기 때문에 투자를 하지 않습니다. 코닥은 1975년 세계 최초로 디지털 카메라를 개발했습니다. 하지만 초기의 디지털 카메라는 카메라의 크기, 화질, 가격 등 여러 면에서 필름 카메라에 비해 열등했기 때문에 필름 카메라 고객들에게 디지털 카메라를 판매하는 것은 어려웠습니다. 또한 필름 판매에서 수익을 많이 내는 코닥이 필름이 필요 없는 디지털 카메라 사업을 키우는 것은 자신의 이익을 갉아먹을 수도 있는 일이었습니다. 파괴적 기술이 성숙해져서 기존 지배적 기업의 시장을 잠식한다파괴적 기술이 발전하면서 그 성능이 고객이 만족할만큼 성장하면 기존 시장을 잠식하기 시작합니다. 디지털 카메라의 크기가 작아지고 화질이 좋아지고 일반 소비자들에게 판매할 수 있을 만큼 저렴해지면서 디지털 카메라의 필름 시장 파괴가 시작되었습니다. 코닥은 뒤늦게 디지털 카메라 시장에 참여하지만, 캐논과 니콘 등의 디지털 카메라 시장 선도 업체와의 경쟁에서 이길 수 없었습니다. 파괴적 혁신에 의한 코닥의 몰락에 대해서는 동아 비즈니스 리뷰와 하버드 비즈니스 리뷰에 실린 아래의 두 글에서 보다 자세한 정보를 확인할 수 있습니다. 또한 파괴적 혁신 이론에 대한 훨씬 풍부한 내용이 클레이튼 크리스텐슨 교수의 저서 『 혁신기업의 딜레마』에서 잘 설명되어 있습니다. [DBR] 사진왕국 코닥의 몰락… 도대체 무슨 일이? 조지 이스트먼은 자신이 만든 첫 카메라에 이름을 붙이고 싶었다. 그는 철자가 잘못 쓰이거나 발음이 잘못될 염려가 없으면서 누구도 모방할 수 없는 이름을 고민하다가 어머니 성의 첫 글자인 dbr.donga.com Kodak’s Downfall Wasn’t About Technology What it missed was the business model. hbr.org 자바스크립트의 탄생과 발전 (1995 ~ 2008)자바스크립트, 접착제 (Glue language) 로서 탄생하다 1990년대 중반, 웹 (World Wide Web) 이 본격적으로 소비자들에게 받아들여지기 시작했습니다. 웹이라는 신대륙의 패권을 차지하기 위한 싸움에서 두각을 나타내는 기업 중 웹 브라우저 넷스케이프를 만든 넷스케이프 커뮤니케이션즈가 있었습니다. 초기의 웹 브라우저는 팀 버너스 리가 웹을 만들 때 제안한 것처럼 HTML 로 이루어진 정적인 웹 문서를 보여줄 뿐이었습니다. 하지만 업계는 브라우저를 좀 더 동적으로 만들 방법, 사용자에게 풍부한 상호작용을 잘 지원해줄 수 있는 방법을 모색하게 되었습니다. 이를 위해서 넷스케이프는 브라우저에서 동작하는 스크립트 언어를 도입하기로 했습니다. 이 스크립트 언어는 전문적인 수준의 애플리케이션을 만들기 위한 목적으로 도입된 것은 아니었고, 자바와 같이 성능이 좋고 풍부한 생태계를 가지고 있는 프로그래밍 언어로 작성된 프로그램 (ex. Java Applet) 을 웹 문서와 연결해줄 수 있는 접착제 역할 (Glue Language) 을 하기만 하면 되었습니다. 예를 들어 웹 문서의 특정 버튼을 클릭하면 특정한 Java Applet이 실행되도록 하고 싶은 경우, 버튼이 클릭되었을 때 자바스크립트가 실행되어 그 자바스크립트가 Java Applet을 실행하도록 하는 것입니다. 비슷한 역할을 하는 기존 기술로 마이크로소프트 오피스의 Visual Basic이 있었습니다. 자바스크립트는 1995년 넷스케이프 브라우저에 탑재되어 세상에 첫 선을 보이고, 1996년 마이크로소프트가 자바스크립트와 유사한 JScript를 자사의 브라우저 익스플로러에 도입했으며, 이후 1997년 표준화되어 ECMAScript 라는 이름으로 불리게 됩니다. 웹 브라우저 안에서 조용히 힘을 키우다자바스크립트가 웹 브라우저의 공식 스크립트 언어로 채택되기는 했지만 그것이 자바스크립트의 성공을 보장하지는 않았습니다. 넷스케이프의 전략적 실책과 마이크로소프트의 OS 시장 지배력을 이용한 끼워팔기 전략 등의 요소가 겹쳐서 2000년대 초중반 마이크로소프트의 익스플로러 브라우저는 90%에 달하는 웹 브라우저 시장 점유율을 차지하게 됩니다. OS와 웹 브라우저의 지배권을 동시에 가진 마이크로소프트는 웹 개발자들에게 ActiveX 와 같은 기술을 이용해서 웹페이지가 일종의 윈도우즈 애플리케이션처럼 동작할 수 있도록 했습니다. 결과적으로 웹이 윈도우즈용 앱스토어 비슷한 역할을 하게 된 것입니다. 이런 상황에서 개발자는 자바스크립트보다는 ActiveX 모듈을 개발할 수 있는 C++, C# 등의 언어를 사용하게 됩니다. 그 밖에 자바스크립트를 이용하지 않고도 웹사이트 기능을 강화할 수 있는 어도비의 Flash, 마이크로소프트의 Sliverlight 등의 기술들이 자바스크립트가 해야 했을 역할을 대신하며 자바스크립트의 입지를 위협했습니다. 하지만 자바스크립트가 전혀 발전하지 않은 것은 아닙니다. 비동기 HTTP 통신 기술인 AJAX가 도입되면서 자바스크립트만으로 서버와 통신을 하는 동적인 웹사이트를 만들 수 있게 되었고, 초보자도 쉽게 웹페이지 화면을 조작할 수 있는 jQuery 가 탄생하기도 했다. 엔진 성능의 폭발적인 향상자바스크립트가 발전을 했다 하더라도 아직 자바스크립트는 웹 페이지를 만들 수 있는 여러 방법 중 하나에 지나지 않았습니다. 그 유명세나 활용도는 아직 C++ 이나 Java 와 같은 주류 언어에 비해서는 초라한 수준이었습니다. 하지만 자바스크립트는 2008년 큰 성장의 계기를 맞게 됩니다. 스크립트 실행 속도를 크게 개선하는 JIT (Just in time) 기술이 도입된 것입니다. Google 크롬은 JIT를 이용한 V8 엔진 덕분에 익스플로러를 포함한 기존 브라우저에 비해 빠른 성능을 보여주었고, 파이어폭스도 JIT를 적용한 TraceMonkey 엔진을 내놓았습니다. 자바스크립트의 독특한 장점웹 브라우저 내부에서 사용되는 기술로서 자바스크립트는 결코 파괴적인 기술은 아닙니다. 자바스크립트는 웹 브라우저 표준으로 채택된 유일한 스크립트 언어로서 독점적인 지위를 누렸습니다. 그 독점적인 지위가 자바스크립트에게 AJAX를 통한 네트워크 기능이나 JIT을 이용한 성능 개선을 가져다준 것입니다. 자바스크립트가 파괴적 기술이라면 그 역량을 웹 브라우저 이외의 다른 시장에서 증명할 수 있어야 합니다. 웹 브라우저 이외의 시장에 대해서 논의하기에 앞서 자바스크립트가 다른 언어에 비해 우위를 가지는 점이 무엇인지 정리해보겠습니다. 저는 아래의 네 가지 장점이 있다고 생각합니다.
단순하고 쉽다자바스크립트는 탄생부터 비전문가를 위한 언어였습니다. 웹 디자이너나 초급 프로그래머가 웹페이지에서 고급 개발자들이 개발한 Java Applet 등의 고도화된 프로그램을 이용할 수 있도록 개발된 접착제였습니다. Java나 C++ 등의 언어가 제공하는 높은 성능을 가져다 주지만 개발하기 어려운 멀티스레드 기능이 자바스크립트에서는 가능하지도 않습니다. 이런 점은 Java나 C++ 개발자가 보기에는 아쉬운 부분이지만, 초급 프로그래머의 입장에서는 프로그래밍 난이도는 낮추고 생산성을 더하는 부분이기도 하다. 비동기 코드를 짜기 좋다자바스크립트는 웹 브라우저의 UI 와 관련된 작업(ex. 클릭)과 AJAX를 이용한 네트워크 작업을 처리하기 위해 많이 이용되었습니다. UI 관련 작업과 네트워크 작업의 공통점은 후속 작업이 언제 실행되어야 할 지 예측할 수가 없다는 것입니다. 더 자세히 말하자면, “유저가 버튼을 클릭할 때 이런 작업을 수행해" 라는 코드가 실행되는 순간에는 유저가 언제 버튼을 클릭할 지 알 수 없고, “서버에 이런 요청을 보내고 응답이 오면 이렇게 처리해” 라는 코드가 실행되는 순간에는 서버가 응답이 오는 정확한 시점을 알 수가 없습니다. 이렇게 특정 코드가 실행되어야 할 시점을 정확하게 알기 어려운 경우에 보통 사용하는 두 가지 방법이 있습니다. 하나는 그 시점이 오기까지 무한히 대기하는 방법 (동기적 블로킹, Synchronous blocking) 이고, 다른 하나는 그 시점이 오면 실행되어야 하는 코드를 지정해두고 다른 할 일을 처리하는 방법 (비동기적 논블로킹, Asynchronous non-blocking) 입니다. 어떤 시점까지 무한히 대기하는 방법은 대기 중 다른 작업을 처리할 수 없게 되므로 멀티쓰레드 프로그래밍이 불가능한 자바스크립트 환경에서는 사용하기 어렵습니다. 따라서 자바스크립트는 비동기적 논블로킹 방식의 코드를 쉽게 작성할 수 있도록 문법과 API가 발달하게 되었습니다. 궁합이 잘 맞는 강력한 UI 기술이 존재한다웹 브라우저의 UI 기술 (HTML, CSS, 렌더링 엔진…) 은 다양한 OS 위에서 전 세계의 수억개의 웹사이트를 그리면서 쉽고 유연하면서도 강력하게 발전했습니다. 이 UI 기술은 당연하게도 자바스크립트와 궁합이 잘 맞습니다. 실행 성능이 좋다구글의 V8을 위시한 JIT 기술을 채택한 자바스크립트 엔진이 자바스크립트의 성능을 크게 끌어올려주었습니다. 이 덕분에 자바스크립트는 C++이나 Java와 같은 정적 언어에는 미치지 못하지만 스크립트 언어 중에서는 최고 수준의 성능을 갖게 되었습니다. 이제 이러한 장점을 바탕으로 웹 브라우저 외의 시장에서 자바스크립트가 어떻게 파괴적 혁신을 이루었는지를 살펴보겠습니다. 자바스크립트의 기존 시장 파괴사례1 - Node.js의 등장과 서버 시장 진출 V8이 출현한 지 얼마 되지 않은 2009년, 라이언 달은 구글의 V8 자바스크립트 엔진과 비동기 네트워크 API를 결합하여 자바스크립트로 서버 프로그래밍을 가능케 해주는 Node.js라는 서버사이드 런타임엔진을 공개했습니다. Node.js에 관한 10가지 후회 - 라이언 달과 Deno.js Node.js를 개발한 라이언 달(Ryan Dahl) 은 지난 2018년 6월 Javascript 최대 콘퍼런스인 JSConf 2018에서 10 Things I Regret About Node.js 을 발표하였습니다. 그 후 Node.js를 개발하면서 생겼던 후회를 바탕.. kingofbackend.tistory.com 서버 프로그래밍 기술 시장에서 주로 인정받는 가치는 어떤 것이 있을까요? 기존 서버 프로그래밍은 주로 SQL 데이터베이스에서 데이터를 가져와서 데이터를 가공한 후에 HTML로 렌더링하여 웹브라우저에 전달하는 일을 주로 수행했습니다. 따라서 RDB 데이터베이스와의 연동이 얼마나 잘 되는지, 데이터를 HTML로 표현하는 일이 얼마나 쉽고 확장성이 있는지 등이 서버 기술을 평가하는 주요 요소였고, 기존 기술들은 이러한 작업을 잘 수행했습니다. Node.js가 기존 서버 기술과 경쟁할 때 도움이 된 것은 환경의 변화였습니다. 웹 브라우저의 성능이 개선되면서 Backbone과 Angular.js를 위시한 Single Page Application(SPA)이 유행했고, 스마트폰의 앱 생태계가 활성화되면서 서버는 웹 브라우저 이외에 모바일 앱을 지원해야 했습니다. 이 두 가지 흐름에 맞춰서 서버는 JSON, XML 등의 형식으로 클라이언트에 데이터를 전달하는 API 서버의 역할을 할 필요가 더욱 커졌습니다. 이에 따라 UI와 관련한 많은 비즈니스 로직이 서버에서 클라이언트로 이전되었고, 서버는 더 단순한 작업을 더 많이 처리해야 하는 상황이 되었습니다. 클라이언트 뿐만 아니라 데이터베이스 측면에서도 변화가 있었습니다. Oracle, MySQL 등의 관계형 데이터베이스(RDB)는 오랜 기간 주류 데이터베이스로서 강력한 위상을 가지고 있었지만, 인터넷 서비스의 규모가 커지고 서비스 변화의 속도가 빨라지면서 그 효용에 의문을 가지는 사람들이 생겨났습니다. SQL을 이용하는 RDB는 데이터 간의 관계를 엄격하게 정의하고 유지할 수 있다는 강점이 있었는데, 이 강점이 서비스의 규모가 커졌을 때 오히려 확장성을 방해하는 요소가 된다는 것입니다. 또한 서비스가 빠르게 변화할 때는 데이터의 형태(Schema)를 엄격하게 관리하지 않는 것이(Schemaless) 서비스 변화에 더욱 기민하게 대처할 수 있다는 비판 또한 생겨났습니다. 이러한 관계형 데이터베이스의 한계에 대한 대안으로 SQL을 사용하지 않는 MongoDB, Cassandra 등의 NoSQL 데이터베이스가 등장했습니다. [DB] RDS, NoSQL 그리고 NewSQL 대부분 사람들은 데이터베이스와 데이터베이스 관리 시스템(DBMS : DataBase Management System)을 구별하지 않고 흔히 데이터베이스로 통합해서 말하곤 합니다. 하지만 정확히 이 둘의 개념은 엄연히 다 kingofbackend.tistory.com 기존 서버 기술들이 가지고 있는 장점들(RDB와의 연동, HTML 생성)의 중요성이 줄어든 환경은 Node.js에게 기회가 되었습니다. 기존 서버 기술들이 가진 기능이 없다는 것이 오히려 Node.js는 배우기 쉽다는 인식을 만들었고, 비동기 문법과 V8에서 비롯한 강력한 실행 성능은 Node.js의 특별한 장점이 되었습니다. Node.js는 당시의 최신 데이터베이스(MongoDB)와 최신 클라이언트 기술(Angular.js)과 함께 MEAN(MongoDB, Express(Node.js내 서버 기술), Angular.js, Node.js)이라는 세트 상품을 구성하여 홍보되기도 했습니다. 단일 제품 단위가 아닌 주변 구성 요소를 포함하는 전체 아키텍처 단위의 변화는 파괴적 혁신의 주요 특징 중 하나입니다. 또 언급할만한 Node.js의 다른 장점이 있었는데, 그것은 실시간(Real-time) 서버를 작성하기 좋다는 점이었습니다. Node.js는 자바스크립트의 비동기적인 문법과 내부적으로 사용하는 비동기 네트워크 API 덕택에 성능이 좋은 실시간 서버를 작성하기 유리했습니다. 이는 FaceBook과 Twitter 등의 실시간성이 강조되는 SNS의 급속한 발달과 맞물려서 개발자들에게 어필하는 요소가 되었습니다. Node.js가 서버 시장에 자리를 잡은 이상 시간이 갈수록 영향력을 키울 수 있었습니다. Google의 V8 팀 덕분에 자바스크립트 엔진의 성능은 다른 언어에 비해서 안정적으로 성장을 지속할 수 있었고, RDB 지원 등의 기존 기술의 장점도 Node.js가 흡수했습니다. 사례2 - Electron으로 데스크탑 앱 개발 시장을 성공적으로 공략함 Node.js의 성공은 자바스크립트에서 서버 시장에서의 성공 이상의 의미가 있었습니다. 자바스크립트에서 파일 시스템 등의 OS 자원에 안정적으로 접근할 수 있는 경로가 생겼을 뿐만 아니라 NPM(node package manager)을 중심으로 자바스크립트 생태계가 크게 활성화된 것입니다. 오픈 소스 플랫폼으로 잘 알려진 Github의 직원들은 Node.js의 성공을 보고 매우 창의적인 생각을 떠올리게 됩니다. Node.js와 Google Chrome 브라우저의 오픈소스 버전인 Chromium을 섞어서 확장성이 뛰어난 텍스트 에디터를 만드는 것입니다. Chromium은 이미 거의 모든 OS에서 웹 페이지를 빠르고 유연하게 그릴 수 있는 최고 수준의 UI 기술을 탑재하고 있었고, Node.js를 이용하면 운영체제의 자원을 자바스크립트를 이용해서 쉽게 접근할 수 있고 NPM을 중심으로 구축된 자바스크립트 생태계의 작업물들을 가져다 쓸 수 있었습니다. 이 조합은 텍스트 에디터 하나만 만들고 그치기에는 아까운 것이었고, 텍스트 에디터 요소를 제외한 Node.js + Chromium 조합이 Electron이라는 이름으로 출시 되었습니다. Electron의 경쟁자는 크게 두 분류로 나누어 볼 수 있습니다. 하나는 OS 마다 직접 제공하는(Native) 데스크탑 앱 개발 도구이며, 다른 하나는 여러 OS를 지원하는 크로스 플랫폼 앱 개발 도구입니다. OS마다 직접 제공하는 데스크탑 앱 개발 도구는 Electron에 비해서 성능이 좋습니다. 해당 OS에 최적화되어 있으니 당연한 일입니다. 하지만 Electron의 떨어지는 성능에 고객들이 만족할 경우에는 성능 외에 다른 가치들이 판단 기준이 되면서 기존 시장의 파괴가 일어납니다. OS 별로 따로 앱을 개발하고 관리해야 하는 데스크탑 앱에 비해서 Electron은 널리 알려진 웹 기술을 이용해서 한 번만 개발을 하면 되었습니다. 심지어 웹 사이트와 데스크탑 앱 사이에 코드를 공유하면 하나의 코드로 웹사이트와 모든 OS에서 동작하는 데스크탑 앱을 만들 수 있게 된 것입니다. 이는 Electron을 이용할 경우 회사가 개발 비용 감소, 생산성 향상, 기술 파편화 방지를 통한 개발 안정성 향상 등의 가치를 누릴 수 있도록 해주었습니다. 기존 크로스 플랫폼 앱 개발 도구는 Electron에 대적할 수 없었을까요? 기존 크로스 플랫폼 앱 개발 도구들은 Electron처럼 웹사이트와 앱의 코드 공유를 가능하게 해주지 못했고, 개발 편의성과 기술의 범용성과 등에서도 Electron에 비해 떨어졌습니다. Electron의 배후에 거대한 웹 생태계가 있다는 점을 생각해보면 당연한 일입니다. 결국 Eletron은 데스크탑 개발 시장에서 경쟁자들을 물리칠 수 있었고, Microsoft, Facebook, Twitch, Slack, Discord, Skype, WhatsApp 등 큰 규모의 서비스들이 Electron을 기반으로 데스크탑 앱을 제작하게 되었습니다. 정리하기 - 자바스크립트의 현재 위상이상의 논의를 정리해보겠습니다. 자바스크립트는 웹 브라우저 내장 스크립트라는 독특한 포지션을 가지고 시작했습니다. 그 후 20년 이상의 시간 동안 수많은 도전을 받았지만 결국 웹페이지는 자바스크립트로 개발해야 한다는 독점적인 지위를 얻었습니다. 그 사이 초기의 단순하고 쉬운 언어라는 가치는 유지한채 비동기적인 코드 작성의 용이성, 궁합이 맞는 강력한 UI 기술 확보 등의 추가적인 가치를 확보했습니다. 이런 강점을 바탕으로 자바스크립트는 서버 개발 분야와 데스크탑 앱 개발 분야에 진출했습니다. 서버 개발 분야에서는 당시 최신 개발 트렌드를 포착하여 시장에 진입한 뒤 영향력을 넓혔고, 데스크탑 앱 개발 분야에서는 압도적인 호환성과 생산성으로 시장에 진입하자마자 당시의 주류 기술들을 압도할 수 있었습니다. 결국 웹 브라우저라는 본진을 탄탄히 지키고 파괴적 혁신의 방법으로 서버와 데스크탑 등의 신규 시장에서 상당한 점유율을 확보한 결과 자바스크립트는 세계적으로 가장 인기있는 언어가 될 수 있었습니다. 자바스크립트가 파괴될 가능성파괴적 혁신 이론이 주는 또 다른 가르침은 현재의 시장 지배적인 기술과 정면 대결을 해서는 승산이 없다는 것입니다. 즉 자바스크립트가 이미 대세가 된 영역에서 자바스크립트가 하던 일을 더 잘해서 자바스크립트를 추월하기는 어렵습니다. 자바스크립트를 파괴적 혁신의 방법으로 이기기 위해서는 다음의 시나리오를 따라갈 것 같습니다.
저는 자바스크립트가 다른 언어에 의해 도태되기는 쉽지 않다고 생각합니다. 언어 문법 레벨에서도 계속 발전을 하고 있고, 브라우저 경쟁이 존재하는 이상 엔진의 성능은 계속 좋아질 것입니다. 마땅한 경쟁자도 잘 보이지 않습니다. 굳이 고르자면 모바일 앱 크로스플랫폼 개발 환경 Flutter에서 사용하는 Dart를 들 수 있을 것 같습니다. 하지만 Dart가 진입하고 하는 시장(크로스플랫폼 개발)은 신규시장이라던가 로우 엔드 시장이라는 이유로 자바스크립트가 무시하는 종류의 시장이 아니기 때문에 Dart로 인한 파괴적 혁신이 일어나기 좋은 상황은 아닙니다. 저는 오히려 Wix, Shopify와 같은 웹페이지 빌더, Airtable과 같은 비개발자도 사용하기 쉬운 데이터베이스, Typeform과 같은 설문 서비스 등의 웹서비스들이 각자의 전문 분야에서 자바스크립트를 대체할 수도 있다고 봅니다. 이려한 서비스들이 제공하는 기능은 개발자들이 프로그래밍을 해서 구현할 수 있는 기능에 비해 수준이 낮지만, 이용하기 쉽고 사용료도 개발자를 고용하는 비용에 비해서는 훨씬 쌉니다. 개발자들이 보기에 이러한 서비스들이 제공하는 기능의 수준이 떨어져서 위협으로 느끼지 않을 수도 있지만, 미래는 어떻게 될 지 모르는 일입니다. 실제 시나리오를 상상해보면 이렇습니다. 마케터가 개발자에게 새로운 서비스의 렌딩 페이지를 개발을 부탁하면 개발자는 (마케터 입장에서는 없어도 좋을) 신기능들을 웹페이지에 담겠다고 열의를 보이지만 작업 시간을 또 오래 걸립니다. 마케터는 개발자를 기다리다 지쳐서 웹사이트 빌더 서비스를 이용해서 렌딩 페이지를 만들어서 바로 배포했습니다. 한번 써보니깐 결과물이 아주 예쁘진 않아도 생각보다 쓸만했고, 예전에는 개발자에게 부탁해야 했던 외부 서비스 연동도 버튼을 몇 번 클릭하는 것만으로 완료할 수 있었습니다. 웹사이트 빌더에 만족한 마케터는 이후 웹페이지 관리 작업을 개발자에게 부탁하지 않고 직접 관리하게 되었습니다. 개발자는 다른 중요한 일들을 하느라 바빠서 마케터의 요청이 없어짐 사실조차 모르고 있습니다. 이렇게 조용하게 파괴적 혁신 일어나고 있을지도 모릅니다. |
자바스크립트 어려움 - jabaseukeulibteu eolyeoum
관련 게시물
저작권 © 2024 ko.ketajaman Inc.
