웹3란 무엇인가
목차
제1부 · 질문과 그 틀

2. 독자를 위한 기초 입문: 컴퓨터, 네트워크, 소프트웨어를 쉬운 말로

2장8 분 분량

이 장은 이 책의 나머지가 조용히 기대고 있는 몇 안 되는 개념들을 맨바닥에서부터 쌓아 올린다. 전제하는 독자는 스마트폰을 쓰고, 메시지를 보내고, 계정에 로그인해 본 사람 — 다만 그 밑에서 실제로 무슨 일이 벌어지는지는 물을 일이 없었던 사람이다. 목표는 독자를 엔지니어로 만드는 것이 아니다. 컴퓨터, 데이터, 네트워크, 서버, 클라우드, 데이터베이스, 프로토콜, 소프트웨어, 계정, 신뢰라는 한 줌의 사고 모형을 충분히 또렷하게 심어 두어, 뒤의 장들이 "웹3(Web3)는 '데이터베이스를 누가 통제하는가'를 바꾸려는 시도"라고 주장할 때 그 문장이 구호로 스쳐 지나가는 대신 실감으로 와 닿게 하는 것이다. 여기 담긴 내용은 전부 교과서적인 컴퓨터과학을 쉬운 말로 옮긴 것이며, 논쟁적인 이야기는 뒤에 온다. 장의 끝에서 우리는 이 책 전체가 축으로 삼는 단 하나의 질문을 던진다. 당신이 디지털 서비스를 쓸 때, '기록을 지키고 있는 것은 누구의 컴퓨터이며, 그들이 그 기록을 바꾸는 것을 무엇이 막고 있는가?'

컴퓨터가 실제로 하는 일

화면과 앱과 상표를 걷어 내고 나면, 컴퓨터는 딱 두 가지 일만 하는 기계다. 정보를 저장하는 일, 그리고 그 정보를 바꾸는 지시를 따르는 일. 과장이 아니라 정말로 그것이 거의 전부다. 작업 대상인 정보와 작업 지시 목록을 같은 기억장치에 함께 담아 두는 이런 기계의 개념적 설계도는 1940년대에 마련되었다. 가장 큰 영향을 미친 것은 폰 노이만이 1945년에 쓴 EDVAC 설계 보고서로, 이후 거의 모든 컴퓨터가 — 당신 주머니 속 전화기까지 — 이 기본 설계를 따른다(von Neumann, 1945). 그보다 앞서 튜링(Turing, 1936)은 단순한 기계 하나가 올바른 지시만 받으면 원리상 '어떤' 계산이든 해낼 수 있음을 수학적으로 보였다. 한 대의 기기가 번갈아 계산기가 되고 카메라가 되고 지도가 되고 전화기가 될 수 있는 깊은 이유가 여기에 있다.

계속 가기 전에 단어 두 개를 정의해 두자.

여기서 정보란 일련의 선택 — 예/아니요, 켬/끔, 0/1 — 으로 적어 낼 수 있는 모든 것을 말한다. 그런 선택 하나를 비트(bit, "binary digit"의 준말)라 부른다. 숫자든 글자든 사진이든 노래든 '어떤' 메시지라도 이 켬/끔 선택의 나열로 부호화할 수 있고 비트 단위로 잴 수 있다는 통찰은 섀넌(Shannon, 1948)의 것으로, 모든 디지털 기술의 주춧돌이다.

쉽게 말해: 컴퓨터는 1과 0밖에 읽고 쓸 줄 모르지만 지치지도 않고 딴청도 부리지 않는, 빠른 서기다. 컴퓨터가 해내는 인상적인 일은 전부, 이 작고 단순한 걸음을 상상하기 어려울 만큼 여러 번, 아주 빠르게 밟아서 쌓아 올린 것이다.

컴퓨터가 정보를 "저장한다"고 할 때, 정보가 사는 곳은 두 종류다. 메모리는 기계가 지금 무언가를 하는 동안 쓰는 빠르고 임시적인 작업 공간으로, 전원이 꺼지면 깨끗이 지워진다. 저장장치(storage)는 기계를 꺼도 내용이 남는, 느리지만 영속적인 선반으로, 전화기 속 칩이나 노트북의 하드디스크가 그것이다. 일상의 비유로는, 일하는 동안 책상 위에 펼쳐 놓은 서류(메모리)와 밤에 그것을 도로 넣어 두는 서류함(저장장치)의 차이다.

데이터, 파일, 프로그램

컴퓨터가 저장하는 정보를 데이터라 부른다 — 숫자 하나에서 장편 영화까지, 저 1과 0으로 표현된 모든 기록된 사실이나 내용이다. 데이터를 다루기 쉽게, 컴퓨터는 서로 관련된 데이터를 한데 묶고 그 묶음에 이름을 붙인다. 이름 붙은 그 묶음이 파일이다.

파일은 본질적으로 '이름표를 단 데이터 상자'다 — 견출지에 이름을 적어 붙인 서류철의 디지털판이다. "휴가사진.jpg"도 "월세영수증.pdf"도 결국은 긴 비트의 나열일 뿐인데, 시스템이 거기에 이름과 크기와 날짜를 붙여 두어 나중에 다시 찾을 수 있게 한 것이다.

컴퓨터가 하는 두 번째 일 — 지시 따르기 — 은 이 장에서 가장 중요한 구별로 이어진다. 프로그램(소프트웨어를 가리키는 전문용어로, 아래에서 다시 다룬다)은 데이터로 무엇을 할지 컴퓨터에게 한 걸음씩 일러 주는 지시 목록이다. 어느 비트를 읽을지, 어떻게 바꿀지, 무엇을 도로 써 둘지, 화면에 무엇을 띄울지.

쉽게 말해: 데이터는 '재료'이고 프로그램은 '조리법'이다. 사진은 데이터다. 그 사진을 밝게 하고 자르고 저장하는 앱은 프로그램이다. 폰 노이만 설계의 천재성 — 그리고 위험 — 은 조리법 역시 같은 메모리에 놓인 또 하나의 데이터일 뿐이라는 데 있다. 컴퓨터에 새 프로그램을 건네면 즉시 새로운 종류의 도구가 되는 이유다. 정직한 단서 하나: 이 말은 곧, 컴퓨터가 나쁘거나 악의적인 조리법도 좋은 조리법과 똑같이 충실하게 따른다는 뜻이다. 컴퓨터에게는 판단이 없다. 돈을 다루는 소프트웨어에 이르렀을 때 이 사실이 대단히 중요해진다.

네트워크란 무엇인가

컴퓨터 한 대도 유용하다. 그러나 컴퓨터가 세상을 바꾸는 것은 서로 연결될 때다. 그때부터 데이터를 주고받을 수 있기 때문이다. 네트워크란 간단히, 데이터를 교환할 수 있도록 이어 놓은 두 대 이상의 컴퓨터를 말한다.

네트워크는 본질적으로 '정보의 우편 체계'다. 합의된 경로와 규칙의 집합이 있어, 메시지가 한 기계를 떠나 온전한 채로 다른 기계에 도착한다. 케이블, 광섬유, 전파(와이파이, 이동통신 데이터)가 도로라면 메시지는 우편물이다.

인터넷은 그런 네트워크 가운데 가장 큰 것이다 — 정확히는 '네트워크들의 네트워크', 곧 서로 연결된 작은 네트워크들의 지구적 그물망으로, 이 덕분에 한 나라의 컴퓨터가 다른 나라의 컴퓨터와 데이터를 주고받는다. 단어 자체가 "inter-network"의 준말이다. 두 가지 사실을 붙들어 둘 만하다. 첫째, 인터넷은 물리적이다. 진짜 케이블(대양 바닥에 깔린 다발들까지 포함해서), 진짜 기지국, 기계로 가득 찬 진짜 건물들로 이루어져 있다. 마케팅이 뭐라 하든, 하늘 위의 구름이 아니다. 둘째, 인터넷 전체를 소유한 회사나 정부는 하나도 없다. 인터넷이 굴러가는 것은 접속하는 모두가 데이터의 주소 지정과 전달에 '같은 규칙'을 쓰기로 합의했기 때문이다 — 아래 "프로토콜"에서 발전시킬 논점이다(Kurose & Ross, 2017).

쉽게 말해: 인터넷은 지분을 나눠 갖는 물건이 아니라, 각자 따로 소유된 수십억 대의 기계가 모두 따르는 '합의'다. 그 덕에 어느 기계든 다른 어느 기계에든 메시지를 보낼 수 있다. 만국우편연합을 떠올리면 된다. 나라마다 따로 운영되는 우편 사업자들이, 편지가 국경을 넘을 수 있을 만큼의 공통 규칙에 합의해 둔 것이다.

데이터가 네트워크를 건널 때는 한 덩어리로 가지 않는다. 패킷(packet)이라 부르는 작고 표준화된 조각으로 잘려, 각 조각에 출발지와 목적지가 적힌 채 따로따로 보내지고, 반대편 끝에서 다시 조립된다 — 집을 통째로 배송하는 대신 라벨 붙은 조립식 상자 더미로 부치는 것과 비슷하다. 연결 상태가 나빠도 영상통화가 화질만 조금 떨어진 채 이어지는 이유가 이것이다. 상자 몇 개가 늦게 도착하거나 다시 발송되어도 배송 전체가 실패하지는 않는다.

서버와 클라이언트: 식당 모델

사람들이 날마다 쓰는 디지털 서비스는 대부분 하나의 특정한 배치를 따르며, 웹3가 무엇에 반발하는지 이해하려면 이 배치부터 이해해야 한다. 배치에는 두 가지 역할이 있다. 클라이언트와 서버다.

서버는 요청이 오면 무언가 — 데이터, 웹 페이지, 서비스 — 를 '제공하는' 일을 맡은 컴퓨터다(흔히 성능 좋은 기계로, 전용 건물 안에서 쉬지 않고 돌아간다). 클라이언트는 그 무언가를 '요청하는' 컴퓨터나 프로그램이다. 앱을 돌리는 당신의 전화기, 웹 브라우저를 띄운 당신의 노트북이 클라이언트이고, 그 앱이 말을 거는 회사의 기계가 서버다.

가장 깔끔한 비유는 식당이다.

식당을 떠올려 보자. 테이블에 앉은 당신이 클라이언트다. 당신은 주방에 들어가 직접 요리하지 않는다. 주문을 넣을 뿐이다. 웨이터가 주문을 주방 — 곧 서버 — 에 전달하면, 주방이 요리를 만들어 내보낸다. 당신은 식료품 창고도, 조리법도, 주방장도 보지 못한 채 완성된 접시를 받는다. 소셜미디어 앱(클라이언트)을 열어 피드를 보여 달라고 하면, 요청이 회사의 서버(주방)로 가고, 서버가 저장된 데이터로 피드를 조립해 당신 화면에 표시될 완성본을 돌려보낸다 — 정확히 같은 방식이다.

쉽게 말해: 보통의 인터넷에서 '당신은 음식을 쥐고 있지 않고, 주방을 운영하지도 않는다.' 당신은 부탁하고, 다른 곳에 있는 — 다른 이가 소유한 — 기계가 무엇을 돌려줄지 결정한다. 이것은 편리하다. 무거운 일과 진짜 데이터는 서버에 있으니, 당신에게는 얇고 값싼 기기만 있으면 된다. 그러나 이는 곧 주방을 소유한 쪽이 식사를 좌우한다는 뜻이기도 하다. 그들은 조리법을 바꾸고, 메뉴를 없애고, 서빙을 거부하고, 주방 문을 닫을 수 있다 — 테이블에 앉은 당신이 할 수 있는 일은 부탁뿐이다.

이 비유가 어긋나는 지점도 정직하게 짚어 두자. 식당 주방은 당신이 이후 '소유하고 먹는' 음식을 내주지만, 많은 디지털 서비스가 건네는 것은 그들 서버에 그대로 남아 있는 데이터의 일시적인 '조망'뿐이다. 흔한 클라우드 앱에서 당신이 사진을 "볼" 때, 대개는 회사 기계에서 흘려보내 준 사본을 보고 있는 것이고, 권위 있는 원본은 그들 손에 있다. 진짜 물건은 그들이 갖고 당신은 그 조망만 받는다는 이 비대칭이, 이 책의 나머지가 살피는 중심 사실 가운데 하나다.

이 패턴을 클라이언트–서버 모델이라 부르며, 오늘날 인터넷의 지배적인 형태다. 그 반대, 곧 특별한 중앙 주방 없이 모든 참여자가 클라이언트이자 서버가 되어 대등한 동료로서 데이터를 직접 주고받는 형태는 P2P(peer-to-peer, 개인 간) 네트워크라 부른다. 지금은 이 용어를 가볍게만 쥐고 있으면 된다. P2P 아키텍처는 웹3의 기술적 뿌리 가운데 하나로, 제3부에서 다시 다룬다.

'클라우드'는 남의 컴퓨터다

컴퓨터의 작동 방식을 "클라우드"라는 말만큼 흐려 놓은 표현도 드물다. 이 말은 영묘하고, 장소가 없고, 거의 마법처럼 들린다. 그러나 클라우드는 마법도 아니고, 장소가 없지도 않다.

클라우드란, 쉽고 다소 김빠지게 말하면, '시간 단위로 빌려 쓰는 남의 컴퓨터'다. 어떤 서비스가 "클라우드에서" 돌아간다는 말은, 일을 하는 서버와 데이터를 담은 저장장치가 당신의 집이나 사무실이 아니라 데이터센터라 부르는 큰 건물 안의 기계들이라는 뜻이다. 그 건물은 어느 회사가 소유하고 운영하며, 그 사용권을 인터넷 너머로 빌려 준다.

가장 널리 인용되는 신중한 정의는 미국 국립표준기술연구소(NIST)의 것으로, 클라우드 컴퓨팅을 "구성 가능한 컴퓨팅 자원의 공유 풀에 언제 어디서나 편리하게, 요청 즉시 네트워크로 접근할 수 있게 하는 모델로서... 최소한의 관리 노력으로 신속하게 할당되고 반납될 수 있는 것"이라고 기술한다(Mell & Grance, 2011, p. 2). 풀이하면 이렇다. 기계를 직접 사서 건사하는 대신, 남이 유지해 주는 거대한 공용 컴퓨팅·저장 공급망에 접속해 쓴 만큼만 값을 치르고, 필요에 따라 늘렸다 줄였다 한다는 것이다.

쉽게 말해: "클라우드에 저장한다"는 것은 '내 데이터의 사본을 어느 회사의 데이터센터로 보내고, 그들이 안전하게 보관했다가 돌려주리라 믿는다'는 뜻이다. "클라우드에서 돌린다"는 것은 '내 기계를 소유하는 대신 그들 기계의 시간을 빌린다'는 뜻이다. 클라우드는 개인이 혼자 힘으로는 흉내 내기 어려울 만큼 편리하고 안정적이다. 그러나 이 김빠진 정의는 이 책의 나머지가 캐물을 핵심 관계를 드러낸다. 당신의 데이터와, 그 데이터에 작용하는 프로그램은 갈수록 당신 소유가 아닌 기계 위에서, 당신이 그저 믿는 수밖에 없는 조직의 통제 아래 살아간다.

위에서 언급한 데이터센터는 수천 대의 서버와, 이를 하루도 쉬지 않고 돌리기 위한 전력·냉각·보안 설비로 채워진 전용 창고 건물이다. "인터넷"이 물리적으로 사는 곳이 바로 이 건물들이다. 한국 독자는 이 사실을 이미 몸으로 배웠다. 2022년 10월 판교의 데이터센터 한 곳에 불이 나자 온 나라의 카카오톡과 카카오 서비스들이 한동안 멈춰 섰다 — "클라우드"가 실은 특정 건물 안의 특정 기계들이라는 사실을 이보다 생생하게 보여 준 사건은 드물다. 데이터센터는 부동산이고, 소유자가 있다. 조용하지만 결정적인 사실이다. 기계를 소유한 자가 그 위의 데이터를 쥐기 때문이다.

데이터베이스: 진짜 기록은 어디에 있고, 누가 지키는가

이제 웹3를 이해하는 데 이 입문 전체에서 가장 중요한 개념 하나에 도달했다. 웹3의 중심 제안은, 바닥까지 파고들면, 데이터베이스에 관한 제안이기 때문이다.

당신이 쓰는 디지털 서비스는 거의 전부, 알록달록한 화면 밑을 들추어 보면 어떤 데이터베이스로 통하는 창구다. 데이터베이스란 프로그램이 기록을 빠르고 안정적으로 저장하고 찾고 고치고 지울 수 있도록 조직해 놓은 데이터의 집합이다.

데이터베이스는 본질적으로 '아주 크고 아주 빠른 전자 장부이자 서류 보관 체계'다 — 사람이 아니라 프로그램이 읽고 쓰는 거대한 스프레드시트, 혹은 도서관의 목록 카드함을 떠올리면 된다. 당신의 은행 잔고는 어느 데이터베이스 속 숫자 하나다. 당신의 소셜미디어 팔로워, 메시지, 주문 내역, 진료 기록도 저마다 어느 조직의 데이터베이스 속 몇 줄의 기록이다.

이런 데이터를 조직하는 지배적인 방식 — 행과 열로 이루어진 표들과 그 사이의 정의된 관계 — 은 E. F. 코드(Codd, 1970)가 한 편의 논문에서 정식화했고, 이 논문이 현대 세계를 굴리는 사실상 모든 "관계형" 데이터베이스의 밑돌이 되었다. 세부는 여기서 중요하지 않다. 중요한 것은 거의 모든 통상적인 데이터베이스가 운영되는 방식에 관한 구조적 사실 하나다.

데이터베이스에는 왜 대개 주인이 하나인가

통상적인 데이터베이스에는 관리자(administrator)가 있다 — 그 데이터베이스에 대한 특권적 통제권을 가진 사람 또는 조직이다. 관리자는 어떤 기록이든 읽을 수 있고, 고칠 수 있고, 추가하고 지울 수 있다. 이는 남용도 결함도 아니다. 정상적이고 의도된 설계다. 누군가는 데이터를 책임져야 한다. 실수를 바로잡고, 규칙을 집행하고, 백업하고, 누가 무엇을 볼지 정하고, 문제가 생기면 답을 내놓을 사람 말이다.

이 중앙 통제 모델이 보편이 된 데는 그럴 만한 이유가 있다. 권위 있는 사본이 하나뿐이면 데이터가 "정말로" 무엇을 말하는지를 두고 다툴 일이 없다. 책임지는 당사자가 하나면 오류를 바로잡고 사기를 되돌릴 수 있다. 접근을 관리할 수 있고, 법을 지킬 수 있다. 은행, 병원, 항공사에게 기록을 맡은 신뢰받는 단일 관리자는 풀어야 할 문제가 아니다. 그것이 존재 이유 그 자체다.

쉽게 말해: 거의 모든 앱 뒤에는 한 조직이 지키는 마스터 기록이 있고, 마스터 키도 그 조직이 쥔다. 당신의 잔고는 그들의 데이터베이스가 말하는 그대로'이다'. 부동산의 소유권이 결국 등기부에 적힌 대로인 것과 같은 이치다. 당신의 계정이 "존재"하는 것은 그들의 표에 당신 몫의 행이 하나 있기 때문이고, 그들이 그 행을 지우면 계정은 사실상 존재하기를 멈춘다. 당신은 서비스를 경험하고, 진실은 그들이 보관한다.

이것이 무엇을 뜻하고 무엇을 뜻하지 않는지는 정확하고 공정하게 말해 둘 필요가 있다. 관리자의 권한은 '정당하며 대체로 선용된다.' 은행은 잔고를 함부로 고쳐 쓰지 않고, 평판 있는 회사는 계정을 심심풀이로 지우지 않는다. 법과 규제, 경쟁, 계약, 그리고 자신의 평판이 그들을 단속한다. 논점은 이 조직들이 악당이라는 것이 아니다. 논점은 '구조'다. 통상적인 설계에서 당신은 관리자의 정직과 역량과 계속되는 선의에 기대고 있다. 그들은 기록을 바꿀 수 '있고', 당신은 그것을 독립적으로 확인하거나 막을 수 없기 때문이다. 그 의존이 현명한지, 그리고 대안이 가능한지 또 바람직한지 — 바로 그것이 이 책이 펼쳐 놓을 논쟁이다.

쉽게 말해: — 그리고 이것이 뒤에 올 모든 장으로 들고 가야 할 문장이다 — 오늘의 인터넷에서 "무엇이 진실인가?"라는 질문의 답은 "해당 데이터베이스의 주인이 진실이라고 말하는 것"이다. 웹3의 근본 주장은 — 이 책은 이를 지지하는 대신 검토하고 시험할 것이다 — 돈, 소유, 신원 같은 특정 종류의 기록만큼은 '어느 한쪽도 몰래 고칠 수 없는' 공유된 방식으로 보관할 수 있으며, 그리하여 신뢰가 한 조직의 말이 아니라 검증 가능한 절차 위에 놓이게 할 수 있다는 것이다. 이 대비를 붙들어 두라. 이 책 전체가, 그것이 실재하는지 그리고 그 비용을 치를 가치가 있는지에 대한 탐구다.

프로토콜: 이 모든 것을 굴러가게 하는 공유 규칙

각자 따로 소유된 컴퓨터들이 조금이라도 협력하려면, 데이터를 어떤 형식으로 만들고 어떻게 주고받을지 미리 합의해 두어야 한다. 그런 합의를 프로토콜이라 부른다.

프로토콜(protocol)은 본질적으로 '공유된 언어에 예법 한 벌을 더한 것'이다 — 한 번도 만난 적 없는 두 당사자가 서로를 이해할 수 있도록 따르는, 합의된 형식과 절차다. 가장 또렷한 일상의 평행물은 우편 주소 체계다. 받는 사람 이름, 도로명 주소, 도시, 우편번호, 나라를 정해진 순서로 적는다는 관례에 온 세계가 합의해 둔 덕분에, 도쿄에서 쓴 편지가 서로 직접 조율한 적 없는 사람들과 기계들의 손을 거쳐 토론토에서 분류되고 배달된다. 그 봉투 서식이 곧 프로토콜이다.

프로토콜은 컴퓨팅 어디에나 있으며, 층층이 포개져 있다. 뒤에서 다시 나올 이름 몇 개는 요지만 알면 충분하다.

  • **인터넷 프로토콜(IP)**은 인터넷 위의 모든 기기에 주소('IP 주소' — 기계의 우편 주소에 해당한다)를 부여하고, 데이터 패킷에 어떻게 라벨을 붙여 그 주소 쪽으로 전달할지를 정의한다(Postel, 1981). 어느 기계든 다른 어느 기계에든 닿을 수 있게 해 주는 주소 지정 관례다.
  • HTTP(HyperText Transfer Protocol)는 웹 브라우저와 웹 서버가 웹 페이지를 요청하고 전달할 때 쓰는 관례로, 웹 주소 앞머리의 "http(s)://" 뒤에서 작동하는 규칙들이다(Berners-Lee et al., 1996).

쉽게 말해: 프로토콜은 '낯선 이들의 기계가 함께 일할 수 있도록 모두가 자발적으로 따르는 규칙집'이다. 봉투에 주소 적는 규칙은 누구의 소유도 아니다. 공유된 표준이며, 바로 그 덕에 우편 체계는 한 회사의 재산이 아니라 보편적인 것이 되었다. 인터넷의 기초 프로토콜들도 비슷하다 — 어느 기업의 사유물이 아니라 열린 공유 표준이다. 이 점을 기억해 두라. 웹3의 단골 논변 하나가, 인터넷의 '더 많은' 부분이 — 돈과 신원까지 포함해 — 개별 기업의 사설 데이터베이스 안이 아니라 누구의 소유도 아닌 열린 공유 프로토콜 위에서 돌아가야 한다는 것이기 때문이다. 이는 진짜이고 중요한 구별이며, 뒤에서 신중하게 저울에 올린다.

인터넷의 프로토콜들 밑에는 미묘하지만 중요한 설계 원칙 하나가 깔려 있다. 네트워크의 일은 일부러 단순하게 — 그저 패킷을 옮기는 것으로 — 묶어 두고, 영리하고 응용에 특화된 일은 가장자리의 컴퓨터들로 밀어낸다는 것이다. 이 "단대단"(end-to-end) 원칙(Saltzer, Reed & Clark, 1984) 덕분에 인터넷은 설계자들이 상상하지 못한 발명들을 — 영상통화부터, 마침내는 블록체인까지 — 품을 수 있었다. 파이프가 내용물을 이해할 필요가 없었던 것이다.

소프트웨어, 프로그램, 앱

"프로그램"이라는 말은 앞에서 지시 목록으로 만났다. 소프트웨어와 앱은 같은 발상을 다른 규모, 다른 어감으로 부르는 이름들이다.

소프트웨어는 프로그램 — 지시들 — 을 통칭하는 말로, 물리적 기계인 하드웨어와 짝을 이룬다. 컴퓨터가 자동 연주 피아노라면, 하드웨어는 피아노이고 소프트웨어는 악보 롤이다. 어느 롤을 끼우느냐에 따라 같은 악기가 전혀 다른 곡을 연주한다. "소프트(무른)"라는 말이 정확히 이 성질을 담고 있다. 하드웨어는 그대로 둔 채, 소프트웨어는 갈아 끼우고 고쳐 쓸 수 있다.

앱("application"의 준말)은 이용자를 위해 특정한 일을 하도록 만든 프로그램일 뿐이다 — 날씨 앱, 은행 앱, 메신저 앱. 전화기에 "앱을 설치한다"는 것은 '그 프로그램의 지시들을 내 기기에 복사해 실행할 수 있게 한다'는 뜻이다. 결정적으로, 대부분의 앱은 식당 모델의 클라이언트 쪽 절반일 뿐이다. 전화기 위의 앱은 웨이터와 메뉴판이고, 당신의 진짜 데이터를 쥔 주방 — 서버 — 은 회사에 남아 있다.

쉽게 말해: "앱을 쓴다"는 것은 대개, 회사 서버에서 돌아가는 훨씬 큰 프로그램과 데이터베이스에 그저 '말을 거는' 작은 프로그램 하나를 내 기기에서 돌린다는 뜻이다. 예쁜 부분은 당신 전화기에 있고, 힘과 데이터는 그들의 기계에 있다. 회사가 서버 쪽 — 당신이 볼 수도 통제할 수도 없는 그 부분 — 을 바꾸거나 꺼 버리면 앱이 갑자기 달라지고, 기능을 잃고, 아예 먹통이 되는 이유가 이것이다.

여기서 제4부에서 중심이 될 구별 하나가 마련된다. 보통의 세계에서는 정말 중요한 프로그램 — 권위 있는 데이터베이스를 쥔 그 프로그램 — 이 회사의 사설 서버에서 돌아가고, 그것을 들여다보거나 바꿀 수 있는 것은 그들뿐이다. 웹3를 규정하는 기술적 수 가운데 하나는, 특정 프로그램들을 그 대신 '공유된 공공' 인프라 위에서 돌리는 것이다. 거기서는 프로그램의 규칙이 누구에게나 열려 있고, 어느 운영자도 마음대로 고칠 수 없다. 그런 프로그램을 스마트 컨트랙트(smart contract)라 부르며, 13장 '이더리움과 스마트 컨트랙트'에서 본격적으로 다룬다. 지금은 대비 하나만 와 닿으면 된다. 소프트웨어는 한 주인의 기계에서 돌 수도 있고 공유 인프라 위에서 돌 수도 있으며, 그 차이는 '규칙을 누가 바꿀 수 있는가'에 있다.

계정과 비밀번호: 그 정체

디지털 생활에서 가장 낯익은 물건 둘이 가장 많이 오해받는 물건이기도 하다. 계정과 비밀번호다. 둘 다 방금 쌓아 올린 데이터베이스 개념으로 볼 때 가장 잘 이해된다.

계정(account)은 본질적으로 '어느 조직의 데이터베이스에 당신 몫으로 마련된 행 하나'다 — "이 사람이 우리 시스템에 존재한다"고 말하는 기록으로, 그 조직이 당신에 관해 아는 것들과, 그 행을 가리키는 라벨(아이디나 이메일)을 담고 있다. 어떤 서비스에 "계정이 있다"는 것은 '그들이 당신에 관한 기록을 만들어 유지하고 있다'는 뜻이다. 그 기록은 그들의 기계 위에, 그들의 뜻에 따라 존재한다. 회사가 "당신의" 계정을 정지하고 제한하고 삭제할 수 있는 이유가 이것이다. 그 기록은 당신에 '관한' 것일지언정, 처음부터 그들의 데이터베이스 속 그들의 것이었다.

비밀번호는 본질적으로 '당신이 특정 계정의 정당한 주인임을 조직이 판정하게 해 주는 공유된 비밀'이다 — 도착했을 때, 당신 이름이 붙은 그 행에 들어갈 자격이 있음을 대는 증표다. 얼굴을 알아보지 못하는 문지기와 미리 정해 둔 암호말과 같다. 똑바로 말하면 당신의 기록 앞까지 들여보내 준다.

여기서 정직한 해명 몇 가지가 중요하다. 큰 주제 하나를 예고하기 때문이다.

첫째, 통상적인 설계에서는 '회사가 당신의 비밀번호를 알거나 재설정할 수 있다.' 안전을 위해 비밀번호를 뒤섞어 저장하는 경우에도(8장에서 설명할 "해싱"(hashing)과 관련된 절차다), 문과 자물쇠를 통제하는 것은 회사다. 비밀번호를 잊으면 그들이 다시 들여보내 줄 수 있다. 뒤집어 말하면, 그들이 마음먹으면, 혹은 강제당하면, 혹은 뚫리면, 그 문은 당신 없이도 열릴 수 있다.

쉽게 말해: 보통의 계정은, 내 집 열쇠가 내 것이라는 의미에서의 '내 것'이 아니다. 클럽 회원권에 가깝다. 클럽이 회원 명부를 유지하고 문 앞에서 당신을 알아봐 주는 동안에는 특권을 누리지만, 건물은 클럽 소유이고, 명부도 클럽이 갖고 있으며, 출입은 취소될 수 있다. 당신의 접근은 그들의 계속되는 협조에 달려 있다.

바로 이 지점에서 웹3는 종류부터 다른 무언가를 제안하므로, 조심스럽게 미리 보아 둘 가치가 있다. 웹3 시스템에서 신원과 통제권을 정박시키는 것은 회사의 계정 행과 회사가 재설정할 수 있는 비밀번호가 아니라 암호학적 키(cryptographic key)다 — '오직 당신만 쥐고 있는' 아주 큰 비밀 숫자로, 어느 회사도 사본을 보관하지 않은 채 당신이 당신 기록의 주인임을 수학적으로 증명해 준다. 그 작동 방식(공개키와 개인키, 디지털 서명)은 8장 '비전공자를 위한 암호학'과 18장 '지갑, 키, 자가수탁'의 주제다. 약속은 "집주인 없는 소유"다. 그러나 똑같이 실재하는 위험이 있다. 어느 회사도 당신의 키를 재설정해 줄 수 없다면, 키를 잃는 것은 곧 모든 것을 잃는 것이며, 호소할 문지기도 없다. 공인인증서 시절을 지나온 한국 독자에게 이 마찰은 낯설지 않을 것이다 — 인증서 파일을 USB에 담아 다니고, 컴퓨터를 바꿀 때마다 옮기고, 만료될 때마다 갱신하던 그 수고가 '자기 열쇠를 스스로 건사하는 일'의 예고편이었던 셈이다. 다만 결정적인 차이가 있다. 공인인증서는 잃어버려도 은행에서 재발급받으면 그만이었지만, 개인키는 그 누구도 재발급해 주지 못한다. 이 책은 양면을 지금 표시해 두고 판정은 뒤로 미룬다. 여기서 중요한 것은 구조적 대비다. '계정과 비밀번호는 문지기를 책임자로 세우고, 개인키는 당신을 책임자로 세운다 — 좋은 쪽으로든 나쁜 쪽으로든.'

'회사에 내 데이터를 믿고 맡긴다'는 말의 의미

이제 앞의 절들이 맴돌던 것을 똑바로 말할 수 있다. 전형적인 디지털 서비스를 쓸 때마다 당신은 신뢰(trust)의 관계에 들어선다 — 그리고 이 단어는 감상적으로가 아니라 정밀하게 정의해 둘 가치가 있다.

이 기술적 맥락에서 어떤 상대를 신뢰한다는 것은 '그들이 나를 해칠 힘을 갖는 위치를 받아들이되, 그러지 않으리라는 기대에 기댄다'는 뜻이다. 회사에 데이터를 맡길 때 당신은, 권위 있는 사본이 그들의 기계에 있으며 그들이 그것을 읽고, 고치고, 남과 공유하고, 잃어버리고, 당신의 접근을 끊을 수 있다는 사실을 받아들이면서 — 그들이 당신을 해치는 방식으로는 그러지 않으리라는 데 건다. 여기서 신뢰는 훈훈한 감정이 아니다. '타인의 선택에 대한 노출'이다.

앞 절들이 세운 것을 쌓아 올려 보면 이 노출의 범위가 또렷해진다. 당신의 데이터는 그들의 데이터베이스에, 그들의 데이터센터("클라우드") 안 서버 위에 살고, 대체로 클라이언트에 불과한 앱을 거쳐 닿으며, 궁극적으로 그들이 통제하는 계정과 비밀번호로 잠겨 있다. 어느 층에서든 권위 있는 것은 카운터 저쪽, 그들 편에 있다. 당신은 조망을 쥐고, 그들은 원본과 조종간을 쥔다.

사람들은 왜 이것을 받아들이는가? 대체로 잘 작동하고, 대안이 고되기 때문이다. 자기 서버를 직접 돌리고, 자기 데이터베이스를 직접 지키고, 자기 열쇠를 한 번도 잃어버리지 않는 일은 어렵다. 대부분의 사람은 그럴 수도 없고, 그러고 싶지도 않다. 중앙화된 수탁은 실질적인 이득을 사 준다. 편리함, 비밀번호를 잊었을 때의 복구, 고장 났을 때 전화할 곳, 사기 거래의 되돌림, 그리고 소유자가 특정되는 데서 오는 법적 책임. 사소한 것들이 아니며, 웹3를 냉정하게 다루려면 이 공로를 인정해야 한다. 뒤의 장들은 그렇게 한다.

그러나 같은 배치에는 특유의 위험들이 따르며, 지금 그 이름을 붙여 두면 뒤의 장들이 호들갑 대신 정밀함을 유지할 수 있다. 한쪽이 권위 있는 기록과 조종간을 함께 쥐고 있을 때는 다음이 성립한다. 침해 사고 한 번으로 수백만 건의 기록이 한꺼번에 노출될 수 있다(데이터가 한곳에 몰려 있으니 노림수도 그만큼 커진다). 보유자는 규칙도, 약관도, 가격도 일방적으로 바꿀 수 있다. 보유자는 스스로의 선택으로든 법적·정치적 압력에 밀려서든 당신의 접근을 끊거나 당신의 데이터를 남에게 넘길 수 있다. 그리고 보유자가 망하거나, 인수되거나, 그냥 서비스를 접으면 기록도 — 접근도 — 사라질 수 있다. 현재 인터넷의 비판자들은(그 논거는 6장 '웹 2.0의 불만'에서 검토한다) 여기에 혐의 하나를 더 보탠다. 어떤 사업은 이용자가 보지도 못하고 의미 있게 동의하지도 않은 방식으로, 이 집중된 데이터에서 가치를 뽑아내는 위에 세워져 있다는 것이다(이 비판을 대표하는 이름이 Zuboff, 2019다). 이 책은 이 주장들을 증거에 비추어 저울질할 것이다. 여기서는 독자가 그 논증을 따라올 채비만 갖추면 된다.

쉽게 말해: "회사에 데이터를 믿고 맡긴다"는 것은 '진짜 사본과 마스터 키는 그들이 갖고, 당신은 그들이 잘 처신하기를 바란다'는 뜻이다. 대개는 잘 처신한다. 때로는 — 실수로, 탐욕으로, 강압으로, 파산으로, 공격으로 — 그러지 못한다. 통상의 인터넷은 이 내기를 끊임없이, 흔히 걸고 있다는 자각조차 없이 걸게 만든다. 웹3가 던지는 깊은 질문은, 유난히 중요한 몇몇 기록에 대해서는 이 내기 자체를 피할 수 있지 않느냐는 것이다. '내 기록의 마스터 키를 나 말고는 아무도 갖지 않고', '공유된 기록을 아무도 몰래 바꿀 수 없도록' 일을 배치할 수 있다면, 믿어야 할 단일한 주인이 아예 없으니 주인을 믿을 필요도 없어진다는 것이다.

종합: 이 책의 나머지가 답할 질문

이 장은 작은 연장통 하나를 조립했다. 부품마다 쉬운 말로 정의하고, 서로 이어 두었다. 컴퓨터는 데이터(파일로 정돈된)를 저장하고, 그 데이터를 바꾸는 프로그램(소프트웨어 — 이용자용으로 포장되면 앱)을 돌린다. 네트워크, 그중에서도 인터넷은 각자 따로 소유된 컴퓨터들이 공유된 프로토콜 — 우편 주소 관례처럼 누구의 소유도 아닌 열린 규칙집 — 을 따름으로써 데이터를 주고받게 한다. 대부분의 서비스는 클라이언트–서버 모델을 따른다. 당신의 기기가 묻고(클라이언트, 테이블의 손님), 회사의 기계가 답한다(서버, 주방). 그 기계들은 갈수록 클라우드 — 데이터센터 안 남의 컴퓨터 — 에 산다. 서비스 뒤에는 데이터베이스, 곧 권위 있는 기록이 있고, 어떤 항목이든 읽고 고치고 지울 힘을 가진 단일한 관리자가 그것을 지킨다. 당신의 계정은 그 데이터베이스의 행 하나이고, 비밀번호는 주인의 문지기가 당신을 그 행 앞까지 들여보내게 하는 비밀이다. 그러므로 그런 서비스를 쓸 때마다 당신은 주인을 신뢰한다 — 곧 당신 데이터에 대한 그들의 힘을 받아들이고, 그들이 그 힘을 오용하지 않으리라는 데 건다.

이 모든 것을 하나의 실이 꿰고 있다. '통상의 인터넷에서 중요한 기록들은 단일 조직이 소유하고 통제하는 데이터베이스에 보관되며, "무엇이 진실인가"는 그 주인의 데이터베이스가 말하는 대로다.' 이것을 여기서 추문으로 내놓는 것이 아니다. 대부분의 용도에서 이는 합리적이고 잘 작동하는 배치이며, 이 책은 그 진짜 장점들을 모르는 척하지 않을 것이다. 그러나 이를 정확히 이름 붙이고 나면, 앞 장이 손짓으로 가리키는 데 그칠 수밖에 없었던, 이후의 모든 것이 달려 있는 질문을 마침내 던질 수 있다.

쉽게 말해: 데이터베이스를 통제하는 것은 누구인가 — 그리고 낯선 이들이 어느 한쪽에게도 주도권을 맡기지 않은 채 신뢰할 만한 기록 하나를 공유하게 해 줄 수 있는 것은, 만약 있다면, 무엇인가? 제3부가 기술적으로 상세히 보여 주고 제5부가 신중하게 정의하듯, 웹3는 상당 부분 이 질문의 후반부에 답하려는 시도다 — 8장의 암호학, 10장의 분산 시스템 아이디어, 11장의 블록체인을 써서, 누구의 소유도 아니면서 누구나 검증할 수 있는 공유 기록을 짓는 것이다. 그 시도가 성공하는지, 어떤 비용을 치르는지, 그리고 어떤 용도에서 잘 운영되는 통상의 데이터베이스보다 실제로 나은지 — 이것이 이 책이 이제 시작하는 탐구다. 앞으로 단 하나의 이미지만 들고 가겠다면 이것을 들고 가라. 기록장 한 권, 그리고 '그 위에 누구의 손이 얹혀 있는가'라는 미결의 질문.

다음 3장에서는 이 구조물 전체가 어디서 왔는지 — 인터넷과 월드와이드웹의 기원과 아키텍처 — 로 넘어간다. 웹3가 내놓는 주장들을, 그것이 고쳐 쓰겠다고 나선 바로 그 시스템에 견주어 잴 수 있도록 하기 위해서다.

이 장에서 인용한 문헌

Berners-Lee, T., Fielding, R., & Frystyk, H. (1996). Hypertext Transfer Protocol — HTTP/1.0 (RFC 1945). Internet Engineering Task Force. https://www.rfc-editor.org/rfc/rfc1945

Codd, E. F. (1970). A relational model of data for large shared data banks. Communications of the ACM, 13(6), 377–387. https://doi.org/10.1145/362384.362685

Kurose, J. F., & Ross, K. W. (2017). Computer networking: A top-down approach (7th ed.). Pearson.

Mell, P., & Grance, T. (2011). The NIST definition of cloud computing (NIST Special Publication 800-145). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-145

Nakamoto, S. (2008). Bitcoin: A peer-to-peer electronic cash system. https://bitcoin.org/bitcoin.pdf

Postel, J. (1981). Internet Protocol: DARPA Internet Program protocol specification (RFC 791). Internet Engineering Task Force. https://www.rfc-editor.org/rfc/rfc791

Saltzer, J. H., Reed, D. P., & Clark, D. D. (1984). End-to-end arguments in system design. ACM Transactions on Computer Systems, 2(4), 277–288. https://doi.org/10.1145/357401.357402

Shannon, C. E. (1948). A mathematical theory of communication. The Bell System Technical Journal, 27(3), 379–423. https://doi.org/10.1002/j.1538-7305.1948.tb01338.x

Turing, A. M. (1936). On computable numbers, with an application to the Entscheidungsproblem. Proceedings of the London Mathematical Society, s2-42(1), 230–265. https://doi.org/10.1112/plms/s2-42.1.230

von Neumann, J. (1945). First draft of a report on the EDVAC. Moore School of Electrical Engineering, University of Pennsylvania. (Reprinted in IEEE Annals of the History of Computing, 15(4), 27–75, 1993.) https://doi.org/10.1109/85.238389

Zuboff, S. (2019). The age of surveillance capitalism: The fight for a human future at the new frontier of power. PublicAffairs.