[번역글] 인프라단계와 관련된 미신 (The Myth of The Infrastructure Phase)
이 글은 유니온벤처(usv.com) 블로그의 The Myth of The Infrastructure Phase를 번역한 글입니다. [원문: https://www.usv.com/blog/the-myth-of-the-infrastructure-phase]
[번역글]
웹 3.0 커뮤니티에서 공공연히 들리는 말은, 우리는 지금 인프라 단계(Infrastructure phase)이며, 지금은 그 인프라를 구축하는 것이 옳은 일이라는 것이다. 더 좋은 베이스 체인, 더 나은 인터체인 상호운영성(interoperability), 더 나은 고객, 지갑, 브라우저등 말이다. 이에 대한 로직은 — 먼저 블록체인 위에 올릴 앱을 쉽게 만들고 사용할 수 있는 도구가 만들어야 하고, 그 후, 그 도구들을 사용해서 앱들을 만들기 시작할 수 있다 — 는 것이다.
하지만, 인프라를 구축하는 창업자들과 이야기를 하면 그 위에 올릴 앱을 만들 개발자들을 찾는 것이 제일 큰 어려움이라고 한다. 우리가 정말로 지금 인프라 단계를 지나고 있다면, 대체 왜 이런걸까?
우리의 가설은 이게 자연스러운 순서가 아니라는 것이다. 우리는 인프라 단계를 지나고 있는게 아니라 앱-인프라 사이클 내 어딘가를 돌고 있는 것이다. 실제로 새로운 기술들이 발전된 전례를 보면 앱이 인프라를 이끌어 내는 것이지, 그 반대는 아니었다는 것을 알 수 있다. 인프라를 먼저 구축하고, 인프라가 구축되면 앱을 개발하는 것이 아니고, 정확하게 그 반대라는 이야기이다.
이게 대화의 주제가 되는 큰 이유 중 하나는 이미 모든 사람들이 “플랫폼"이야말로 가장 큰 성장/가치의 찬스를 가질 확률이 높다는 것 (페이스북, 아마존/AWS, Twilio 등을 보면 맞는 이야기이다)을 알고 있기 때문이다. 그 결과, 가치를 독점할 주요 플랫폼을 구축하는 경쟁이 자연스럽게 달아올랐다. 앱보다는 프로토콜 레이어에 가치가 더 많이 쌓이는 분산형웹의 경우 더 그랬을 것이라고 생각한다.
하지만, 이제부터 이야기하겠지만, 플랫폼은 앱 => 인프라 => 앱 => 인프라의 사이클 사이에서 성장하는 것이지 그냥 무에서 창조되는 경우는 흔치 않다.
첫째, 앱이 인프라의 개발을 이끌어낸다. 그리고, 그 인프라는 새로운 앱들의 탄생을 가능케 한다.
우리의 시점에서 보면, 주요 플랫폼의 쇠락의 시작에는 보통 Breakout App(역주: 번역이 어려워서 단어 그대로 사용합니다; 의미는 “업계의 근간을 흔드는 앱" 정도입니다.)이 있다. 그리고 그 Breakout App은 비슷한 앱을 간편하게 만드는 인프라 구축의 단계를 이끌어 내고, 그렇게 구축된 인프라는 그 앱들이 폭넓게 유저들에게 퍼지는 것을 가능케 한다. 아래 그림처럼 말이다:
예를 들면, 전구(앱)이 만들어지고 난 후에, 전기망electric grid(인프라)이 구축되었다. 전구가 있기 위해서 전기망은 필요없다. 하지만 전구가 대중에게 널리 퍼지기 위해서는 전기망이 필요하다. 실제로 Breakout App인 전구는 1879년 발명되었고, 전기망은 1882년 구축되기 시작되었다. (USV팀 북클럽은 전구의 발명과 관련된 The Last Days Of Night을 읽는 중이다.)
다른 예로 보면: 비행기(앱)은 공항(인프라)전에 발명되었다. 공항이 있어야만 비행기를 만들 수 있는 것이 아니다. 하지만 비행기가 대중에게 널리 쓰이려면 공항이 필요하다. 실제로 비행기는 1903년에 먼저 발명되었고, 1919년 항공사가 만들어지는 단계를 이끌어 냈으며, 1928년에는 공항이, 그리고 1930년에는 항공 교통 관제 시스템이 순차적으로 만들어졌다. 먼저 비행기가 먼저 만들어진 이후에.
같은 패턴은 인터넷에서도 볼 수 있다. 먼저, 앱으로 이야기는 시작된다. 메시징(1970년)과 이메일(1972년)이 먼저 개발되었고, 이후 이 기능들을 대중들에게 널리 퍼트리기 위해 필요한 인프라 — 이더넷(1973년), TCP/IP (1973년), 그리고 ISP (1974년) — 의 개발을 이끌어 냈다. 그 다음 앱의 물결은 웹포탈(Prodigy는 1990년, AOL은 1991년)이었고, 우리는 또 필요한 인프라 (검색엔진 및 웹브라우저; 1990년 초반)를 구축했다. 그 다음 앱 물결은 아마존(1994년)같은 초기 사이트였고, 웹사이트 구축을 쉽게 하기 위한 프로그래밍 언어(1994년 PHP, 1995년 자바스크립트/자바)의 인프라 구축을 이끌어 내었다. 그 후에 더 복잡한 앱 — 냅스터(1999년), 판도라(2000년), Gmail(2004년) 그리고 페이스북(2004년) — 은 이런 복잡한 앱 제작에 필요한 인프라(2004년 NGINX and Ruby on Rails, 2006년 AWS)를 이끌어 내었다. 이 사이클은 계속 반복되었다.
최근 모바일 앱의경우에도 비슷한 패턴을 볼 수 있다. 먼저 스트리밍 비디오에 특화된 앱들 — 스냅챗 (2011), Periscope (2014), Meerkat (2015), 인스타그램 스토리(2016) — 이 나오고 이제 모바일앱에 비디오를 추가하는 것을 쉽게 가능케하는 회사들이 속속 나오고 있다: Ziggeo (2014), Agora.io (2014), Mux (2017), Twilio Video API (2017), Cloudflare Stream (2018).
이런 사이클은 웹3.0에서 일어나는 몇몇 케이스에 대해서도 볼 수 있다. 먼저 Breakout App인 비트코인(2008년),이 있었다. 그리고 이더리움 스마트 컨트랙트 그리고 ERC20 (2015)과 같이 새로운 앱을 만드는 것을 간편화하게 하는 인프라, 그리고 Coinbase (2012)와 Metamask (2016)같은 새로운 앱을 대중화하는데 도움을 주는 인프라가 연이어 구축되었다. 이런 인프라의 구축은 새로운 앱의 물결 — tokens/ICOs (2017), 그리고 초기 댑 (2016년의 Rouleth와 vDice 그리고 2017년의 CryptoKitties) — 을 가능케 하였고, 이어서 새로운 인프라 — Infura (2016), Web3js와 Zeppelin (2017) — 가 개발되었다. 이게 우리는 다음 인프라 단계를 이끌 새롭고 큰 앱을 기다리는 단계이다.
The Adjacent Possible (역주: 번역이 어려워서 원문 그대로 씁니다)
주요 플랫폼 (전기, 자동차, 비행기, 웹, 모바일 등)의 개발에서 볼 수 있는 공통점은 우리는 우리에게 주어진 도구를 가지고 우리가 만들수 있는 것을 만든다는 것이다. 저서 Where Do Good Ideas Come From에서 Steven Johnson은 이런 현상을 The Adjacent Possible이라고 칭했다. 말인즉, 다음 방으로의 문을 여는 것은 가능하지만, 그 단계를 뛰어넘어서, 현관에서 베란다 문을 여는 것은 불가능하다는 말이다. 앱시장보다 너무 앞서있는 인프라를 성공적으로 구축하는 것은 어렵다.
앱 => 인프라 사이클이 반복 할 때마다 그 전 사이클에 구축된 인프라가 있기에 새로운 앱이 나오는 것이 가능하다.예를 들어서 유투브가 1995년이 아닌 2005년에 만들어진 이유는 eBay, Amazon, AskJeeves 그리고 내가 좋아하는Neopets같은 첫번째 닷컴 사이트 이후 일어난 2000년 초 브로드밴드같은 인프라의 배포 이후에나 말이 되는 서비스이기 때문이다.
Chris Dixon과 Fred Wilson은 최근 a16z 팟캐스트 에피소드에서 이 컨셉트에 대해서 이야기했다. Chris는 1990년 후반 닷컴 버블을 풍자한 “Dot Bomb”라는 닷컴 시절 보드게임을 가지고 있다. 그리고 그는 그 보드게임에서 풍자하는 ‘웃긴' 아이디어들이 지금 조단위의 유니콘들이라는 것을 집어 이야기 했다. 수 번의 앱 => 인프라 사이클 후 지금 가능한 아이디어들이 한 두번의 앱=>인프라 사이클 때는 불가능했었다.
이것이야 말로 우리가 인프라단계의 미신(the myth of the infrastructure phase)라고 부르는 것의 핵심이다. 우리가 앱없이 “인프라 단계”만을 생각한다면 우리는 너무 시대를 너무 앞선 고민을 하고 있는 리스크에 빠져있을 수 있다. 우리에게는 지금 앱=>인프라=>앱=>인프라 사이클을 따르는 것이 필요하다.
사이클이 더 반복할수록, 이런 앱들을 개발하는 것이 더 용이해진다. usv.com을 1995년에 제작했다면 지금의 몇 배의 비용이 들었을 것이고, 오늘 웹3.0앱을 개발하는 것은 15년 후와 비교했을 때 훨씬 더 많은 비용, 노력 그리고 시간이 소요될 것이다.
개발 프레임워크 vs. 투자 프레임워크
투자자의 시점으로 돌아와서, 무엇이 발명될 수 있는 기술적 프레임워크와 좋은 투자를 설명하는 투자적 프레임워크를 구분하는 것은 정말 중요하다.
앱=>인프라=>앱=>인프라 사이클은 언제 앱/인프라가 구축될 수 있는지를 설명하지만, 언제 인프라에 투자할지, 언제 앱에 투자할지를 설명하지는 않는다.
전구를 다시 예로 들어보자. 전기망 전에 발명이 된 것은 맞다. 하지만 투자자의 입장에서 보자면, 전기망이 나오기 전에 많은 전구를 팔 수 있지는 못 했다.
마무리하며
우리가 가졌던 한가지 질문은 “왜 앱이 인프라보다 먼저 사이클을 시작하는가?”였다. 한가지 이유는 인프라 문제를 해결해 달라는 앱이 있기 전에 그 인프라를 구축하는 것이 논리적이지 않기 때문이다. 앱이 없이 어떻게 지금 구축하는 인프라가 실제 문제를 해결할 것이라는 것을 알겠는가? 크립토 개발자들이 따라하고 싶어하는 Breakout App이 나오고 다른 개발자들이 더 쉽게 그런 앱을 만들 수 있는 개발 툴과 인프라를 원하기 전에 크립토 인프라를 만드는 것은 상당한 도전일 것이다.
크립토 업계에서는 훌륭한 도구를 먼저 만들고, 그 도구가 있어야 앱을 만들 수 있다는 말이 있다. 하지만 우리가 다른 플랫폼의 지각변동 예제를 통해서 말하고 싶었던 점은 인간은 훌륭한 도구 없이도 몇 개의 첫 앱을 구축할 수 있다는 것이며 (물론 더 많은 돈과 시간이 들겠지만), 그 초기 앱들이 우리가 더 좋은 도구를 만들도록 영감을 준다는 것이다. 그리고는 사이클은 반복한다.
즐거운 개발되시길. (Happy building.)
면책조항. 이 글은 매우 개인적인 의견을 담고 있으며, TTC프로토콜의 철학이나 다른 멤버들의 생각과 다를 수 있습니다. 글을 올리기 전에 최대한 내용을 신중하게 검토하지만, 읽는 이는 항상 정보를 주체적으로 받아들여야 합니다. 이 글에서 제공하는 정보의 이용 또는 비이용으로 인한 피해, 또는 부정확하거나 불완전한 정보 이용으로 인한 피해에 대한 책임을 지지 않습니다.
