누가 자바스크립트를 파괴할 수 있을까?
파괴적 혁신 이론으로 살펴본 자바스크립트의 역사
주의! 이것은 엄밀하지 않은 글입니다. 틀린 부분이 있다면 지적해주시면 감사하겠습니다. 다른 의견의 공유도 환영입니다.
논란의 여지가 있을 수 있지만, 자바스크립트는 2021년 현재 소프트웨어 업계에서 가장 유명한 언어라고 할 수 있다. 2020년 Github의 분석에 따르면 자바스크립트는 2014년 이래로 항상 영향력 있는 언어였고, 자바스크립트의 친척이라고 할 수 있는 타입스크립트 또한 그 순위가 4위에 달한다.
자바스크립트는 어떻게 이렇게 유명해질 수 있었을까? 파이썬, 자바, C 등의 전통의 강자들, 그리고 Golang, Rust, Swift, Dart 등의 신흥 강자들과의 경쟁에서 자바스크립트는 어떻게 우위를 점할 수 있었는가?
이번 글에서는 클레이튼 크리스텐슨 교수의 파괴적 혁신 이론을 이용해서 자바스크립트가 성장할 수 있었던 이유를 설명해보고자 한다.
파괴적 혁신 이론 - 돈 안되는 기술 무시하다가 망한다
파괴적 혁신 이론은 크리스텐슨이 ‘위대한 기업들조차 왜 실패하는가’ 라는 질문에 대한 해답을 찾는 과정에서 제안한 이론이다. 필름 카메라 시장의 1위 기업이었던 코닥이 디지털 카메라 시대에 적응하지 못한 사례를 통해서 이번 글의 주제와 관련이 있는 부분만을 좀 더 자세히 들여다보자.
파괴적 기술이 등장한다
파괴적 기술이란 단기적으로 제품의 성능을 떨어뜨리지만 기존 기술이 제공하지 못하는 다른 가치를 제공하는 기술을 의미한다. 파괴적 기술에 기초한 제품들은 일반적으로 더 싸고, 더 단순하고, 더 작고, 사용하기 더 편리하다 (혁신 기업의 딜레마, 1997). 예를 들어, 초기의 디지털 사진은 기존의 필름 사진에 비해서 사진의 질은 낮았지만 필름 인화 과정을 거칠 필요가 없다는 편리함을 제공했다.
기존 기업은 파괴적 기술이 돈이 안 되서 무시한다
기존 시장의 지배적인 기업은 파괴적 기술을 이용할 지 여부를 검토하지만, 돈이 되지 않기 때문에 투자를 하지 않는다. 코닥은 1975년 세계 최초로 디지털 카메라를 개발했다. 하지만 초기의 디지털 카메라는 카메라의 크기, 화질, 가격 등 여러 면에서 필름 카메라에 비해 열등했기 때문에 필름 카메라 고객들에게 디지털 카메라를 판매하는 것은 어려웠다. 또한 필름 판매에서 수익을 많이 내는 코닥이 필름이 필요 없는 디지털 카메라 사업을 키우는 것은 자신의 이익을 갉아먹을 수도 있는 일이었다.
파괴적 기술을 활용하는 기업은 돈이 안 되는 시장에 만족하거나 새 시장을 개척한다
파괴적 기술의 활용을 결심하는 기업은 기존 시장의 지배적인 기업과 정면 대결하는 대신 돈이 안 되는 시장에 만족하거나 새로운 시장을 개척한다. 디지털 카메라 시장의 경우 코닥이 적극적으로 디지털 카메라 시장을 공략하기 전에 캐논과 니콘 등의 회사가 자리를 잡기 시작했다.
파괴적 기술이 성숙해져서 기존 지배적 기업의 시장을 잠식한다
파괴적 기술이 발전하면서 그 성능이 고객이 만족할만큼 성장하면 기존 시장을 잠식하기 시작한다. 디지털 카메라의 크기가 작아지고 화질이 좋아지고 일반 소비자들에게 판매할 수 있을 만큼 저렴해지면서 디지털 카메라의 필름 시장 파괴가 시작되었다. 코닥은 뒤늦게 디지털 카메라 시장에 참여하지만, 캐논과 니콘 등의 디지털 카메라 시장 선도 업체와의 경쟁에서 이길 수 없었다.
파괴적 혁신에 의한 코닥의 몰락에 대해서는 동아 비즈니스 리뷰와 하버드 비즈니스 리뷰에 실린 아래의 두 글에서 보다 자세한 정보를 확인할 수 있다. 또한 파괴적 혁신 이론에 대한 훨씬 풍부한 내용이 클레이튼 크리스텐슨 교수의 저서 『 혁신기업의 딜레마』에서 잘 설명되어 있다.
자바스크립트의 탄생과 발전 (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을 이용한 성능 개선을 가져다준 것이다. 자바스크립트가 파괴적 기술이라면 그 역량을 웹 브라우저 이외의 다른 시장에서 증명할 수 있어야 한다.
웹 브라우저 이외의 시장에 대해서 논의하기에 앞서 자바스크립트가 다른 언어에 비해 우위를 가지는 점이 무엇인지 정리해보자. 나는 아래의 네 가지 장점이 있다고 생각한다.
- 단순하고 쉽다.
- 비동기 코드를 짜기 좋다.
- 호환이 잘 되는 UI 기술이 존재한다.
- 실행 성능이 좋다.
단순하고 쉽다
자바스크립트는 탄생부터 비전문가를 위한 언어였다. 웹 디자이너나 초급 프로그래머가 웹페이지에서 고급 개발자들이 개발한 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년, Ryan Dahl은 구글의 V8 자바스크립트 엔진과 비동기 네트워크 API 를 결합하여 자바스크립트로 서버 프로그래밍을 할 수 있는 환경을 만들어서 Node.js 라는 이름으로 공개했다.
서버 프로그래밍 기술 시장에서 주로 인정받는 가치는 어떤 것이 있을까? 기존 서버 프로그래밍은 주로 SQL 데이터베이스에서 데이터를 가져와서 데이터를 가공한 후에 HTML로 그려서 웹 브라우저에 전달하는 일을 주로 수행했다. 따라서 RDBMS 데이터베이스와의 연동이 얼마나 잘 되는지, 데이터를 HTML로 표현하는 일이 얼마나 쉽고 확장성이 있는지 등이 서버 기술을 평가하는 주요 요소였고, 기존 기술들은 이러한 작업을 잘 수행했다.
Node.js가 기존 서버 기술과 경쟁할 때 도움이 된 것은 환경의 변화였다. 웹 브라우저의 성능이 개선되면서 Backbone과 Angular.js를 위시한 Single Page Application (SPA) 이 유행했고, 스마트폰의 앱 생태계가 활성화되면서 서버는 웹 브라우저 이외에 모바일 앱을 지원해야 했다. 이 두 가지 흐름에 맞춰서 서버는 JSON, XML 등의 형식으로 클라이언트에 데이터를 전달하는 API 서버의 역할을 할 필요가 더욱 커졌다. 이에 따라 UI와 관련한 많은 비즈니스 로직이 서버에서 클라이언트로 이전되었고, 서버는 더 단순한 작업을 더 많이 처리해야 하는 상황이 되었다.
클라이언트 뿐만 아니라 데이터베이스 측면에서도 변화가 있었다. Oracle, MySQL 등의 관계형 데이터베이스 (RDBMS) 는 오랜 기간 주류 데이터베이스로서 강력한 위상을 가지고 있었지만, 인터넷 서비스의 규모가 커지고 서비스 변화의 속도가 빨라지면서 그 효용에 의문을 가지는 사람들이 생겨났다. SQL을 이용하는 관계형 데이터베이스는 데이터 간의 관계를 엄격하게 정의하고 유지할 수 있다는 강점이 있었는데, 이 강점이 서비스의 규모가 커졌을 때 오히려 확장성을 방해하는 요소가 된다는 것이다. 또한 서비스가 빠르게 변화할 때는 데이터의 형태 (Schema) 를 엄격하게 관리하지 않는 것이 (Schemaless) 서비스 변화에 더욱 기민하게 대처할 수 있다는 비판 또한 생겨났다. 이러한 관계형 데이터베이스의 한계에 대한 대안으로 SQL을 사용하지 않는MongoDB, Cassandra 등의 NoSQL 데이터베이스가 등장했다.
기존 서버 기술들이 가지고 있는 장점들 (RDBMS 데이터베이스와의 연동, 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 팀 덕분에 자바스크립트 엔진의 성능은 다른 언어에 비해서 안정적으로 성장을 지속할 수 있었고, RDBMS 지원 등의 기존 기술의 장점도 Node.js가 흡수했다.
사례 2 - Electron으로 데스크탑 앱 개발 시장을 성공적으로 공략함
Node.js 의 성공은 자바스크립트에게 서버 시장에서의 성공 이상의 의미가 있었다. 자바스크립트에서 파일 시스템 등의 OS 자원에 안정적으로 접근할 수 있는 경로가 생겼을 뿐만 아니라 NPM (node package manager) 을 중심으로 자바스크립트 생태계가 크게 활성화된 것이다.
오픈 소스 플랫폼으로 잘 알려진 Github의 직원들은 Node.js의 성공을 보고 매우 창의적인 생각을 떠올리게 된다. Node.js 와 구글 크롬 브라우저의 오픈소스 버전인 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의 배후에 거대한 웹 생태계가 있다는 점을 생각해보면 당연한 일이다.
결국 Electron은 데스크탑 개발 시장에서 경쟁자들을 물리칠 수 있었고, Microsoft, Facebook, Twitch, Slack, Discord, Skype, WhatsApp 등 큰 규모의 서비스들이 Electron을 기반으로 데스크탑 앱을 제작하게 되었다.
정리하기 - 자바스크립트의 현재 위상
이상의 논의를 정리해본다. 자바스크립트는 웹 브라우저 내장 스크립트라는 독특한 포지션을 가지고 시작했다. 그 후 20년 이상의 시간 동안 수많은 도전을 받았지만 결국 웹페이지는 자바스크립트로 개발해야 한다는 독점적인 지위를 얻었다. 그 사이 초기의 단순하고 쉬운 언어라는 가치는 유지한 채 비동기적인 코드 작성의 용이성, 궁합이 맞는 강력한 UI 기술 확보 등의 추가적인 가치를 확보했다.
이런 강점을 바탕으로 자바스크립트는 서버 개발 분야와 데스크탑 앱 개발 분야에 진출했다. 서버 개발 분야에서는 당시 최신 개발 트렌드를 포착하여 시장에 진입한 뒤 영향력을 넓혔고, 데스크탑 앱 개발 분야에서는 압도적인 호환성과 생산성으로 시장에 진입하자마자 당시의 주류 기술들을 압도할 수 있었다.
결국 웹 브라우저라는 본진을 탄탄히 지키고 파괴적 혁신의 방법으로 서버와 데스크탑 등의 신규 시장에서 상당한 점유율을 확보한 결과 자바스크립트는 세계적으로 가장 인기있는 언어가 될 수 있었다.
자바스크립트가 파괴될 가능성
파괴적 혁신 이론이 주는 또 다른 가르침은 현재의 시장 지배적인 기술과 정면 대결을 해서는 승산이 없다는 것이다. 즉 자바스크립트가 이미 대세가 된 영역에서 자바스크립트가 하던 일을 더 잘 해서 자바스크립트를 추월하기는 어렵다. 자바스크립트를 파괴적 혁신의 방법으로 이기기 위해서는 다음의 시나리오를 따라갈 것 같다:
- 자바스크립트보다 성능은 떨어지지만 자바스크립트가 갖지 못한 장점을 가진 파괴적 기술이 등장한다
- 이 파괴적 기술이 자바스크립트가 사용되지 않는 시장 (로우 엔드 시장이나 신규 시장) 에서 고객을 만들면서 발전한다
- 이 파괴적 기술의 성능이 자바스크립트보다는 떨어지지만 고객이 만족할 만한 수준이 되었을 때 자바스크립트를 대체하기 시작한다
나는 자바스크립트가 다른 언어에 의해 도태되기는 쉽지 않다고 생각한다. 언어 문법 레벨에서도 계속 발전을 하고 있고, 브라우저 경쟁이 존재하는 이상 엔진의 성능은 계속 좋아질 것이다. 마땅한 경쟁자도 잘 보이지 않는다. 굳이 고르자면 모바일 앱 크로스플랫폼 개발 환경 Flutter 에서 사용하는 Dart 를 들 수 있을 것 같다. 하지만 Dart가 진입하고자 하는 시장 (크로스플랫폼 개발)은 신규 시장이라던가 로우 엔드 시장이라는 이유로 자바스크립트가 무시하는 종류의 시장이 아니기 때문에 Dart로 인한 파괴적 혁신이 일어나기 좋은 상황은 아니다.
나는 오히려 Wix, Shopify 와 같은 웹페이지 빌더, Airtable과 같은 비개발자도 사용하기 쉬운 데이터베이스, Typeform과 같은 설문 서비스 등의 웹서비스들이 각자의 전문 분야에서 자바스크립트를 대체할 수도 있다고 본다. 이러한 서비스들이 제공하는 기능은 개발자들이 프로그래밍을 해서 구현할 수 있는 기능에 비해 수준이 낮지만, 이용하기 쉽고 사용료도 개발자를 고용하는 비용에 비해서는 훨씬 싸다. 개발자들이 보기에 이러한 서비스들이 제공하는 기능의 수준이 떨어져서 위협으로 느끼지 않을 수도 있지만, 미래는 어떻게 될 지 모르는 일이다. 실제 시나리오를 상상해보면 이렇다.
마케터가 개발자에게 새로운 서비스의 랜딩 페이지 개발을 부탁하면 개발자는 (마케터 입장에서는 없어도 좋을) 신기능들을 웹페이지에 담겠다고 열의를 보이지만 작업 시간은 또 오래 걸린다. 마케터는 개발자를 기다리다 지쳐서 웹사이트 빌더 서비스를 이용해서 랜딩 페이지를 만들어서 바로 배포했다. 한번 써보니까 결과물이 아주 예쁘진 않아도 생각보다 쓸만했고, 예전에는 개발자에게 부탁해야 했던 외부 서비스 연동도 버튼을 몇 번 클릭하는 것만으로 완료할 수 있었다. 웹사이트 빌더에 만족한 마케터는 이후 웹페이지 관리 작업을 개발자에게 부탁하지 않고 직접 관리하게 되었다. 개발자는 다른 중요한 일들을 하느라 바빠서 마케터의 요청이 없어진 사실조차 모르고 있다.
이렇게 조용하게 파괴적 혁신이 일어나고 있을지도 모른다.
