141: tweet overflow

이 글은 2016년 8월 1일에 다른 블로그에 공개했던 글을 옮겨온 것이다.

광역적인 맥락에서 정보 시스템은 구글로 대표되며, 구글이 다루지 않는 전문 분야들은 각 분야 별로 별도의 데이터베이스가 구축되어 있다. 하지만 이러한 광역적 정보 시스템의 개인의 정보 시스템을 대체할 수 있냐고 묻는다면 그렇지 않다고 생각한다. 왜냐하면 구글은 정말로 광역적인 맥락만을 수용하기 때문에, 각 개인의 고유한 정보와 맥락들까지 모두 포용할 수는 없기 때문이다.

이러한 관점에서 2000년 중후반에는 광역적인 정보 시스템이나 유사 서비스들에서 이른바 개인화라고 불리는, 개인의 맥락을 덧씌우는 작업이 활발하게 진행되었다. 하지만 여기서 말하는 개인화는 개인의 정보나 맥락을 온전하게 포함하지 못 하며 근본적인 두 시스템(광역 정보 시스템과 개인 정보 시스템)의 차이와 개인 정보 문제 때문에 완결을 이루지 못 한 채로 시들어져 갔다. 개인화는 개인 정보 시스템을 완결하지 못 했고, 재미있게도 개인 정보 시스템은 구글이 급속하게 성장하면서 정보 시스템으로서 실질적인 발전을 이룩하는 동안에, 거의 아무런 발전도 하지 못 했다.

아직도 대부분의 사람들은 개인 정보 시스템의 기반으로 파일 시스템을 사용한다. 예를 들어 어떤 디자이너를 상상해보자. 이 디자이너는 포토샵(Photoshop)과 일러스트레이터(Illustrator)를 주로 사용한다. 하나의 작업을 할 때마다 작업 내용을 담고 있는 자체 포맷(예를 들어, psd)와 최종 퍼블리싱 포맷(예를 들어, png)으로 다수의 파일을 생산해낸다. 이러한 작업물들은 처음부터 파일 시스템에 저장된다는 전제에서 생산된다. 이 디자이너는 파일 관리에 고충을 겪어와서 자신만의 디렉터리 관리 방법을 정해서 사용하고 있다.

2016/09/낰욧 기획사/봉투 디자인/20160902 초기 시안.ai
2016/09/낰욧 기획사/봉투 디자인/20160921 최종 디자인.ai
2016/09/낰욧 기획사/봉투 디자인/20160921 최종 디자인.png
2015/05/낰욧 블로그/로고 디자인/20150513 디자인.psd

아마 현실에서 이 정도로만 파일이 관리되면, 충분할 지 모른다. 이러한 접근 방법은 하나의 디렉터리에서 모든 맥락을 소실한 채 이름만으로 파일만을 관리하는 것보다 훨씬 더 구조적이다. 하지만 디렉터리 깊이가 깊어짐에 따라서 파일들을 일일히 탐색하는데 고충이 생길 수도 있다. 이 디자이너에게 파일 시스템은 자신의 작업물 전체를 저장하고 관리하고 기억하고 탐색하는 개인 정보시스템이다. 하지만 이 시스템은 효율적이지 않다.

안타깝게도 컴퓨터 위에서 모든 작업은 파일 기반으로 이루어지고, 파일이라는 것은 서로 다른 애플리케이션들이 작업을 공유할 수 있는 기반이기도 하다. 하지만 파일 시스템의 근본적인 원시성에 대해서 이야기해볼 필요가 있다. 파일 시스템은 근본적으로 정보의 가치를 극대화하기 위해서 만들어진 시스템이 아니라, 컨텐츠를 특정한 단위(파일)로 저장하기 위해서 설계된 시스템이다. 파일엔 메타데이터를 유연하게 담기 위한 충분한 공간이 준비되어있지 않으며, 만약 그러한 파일 시스시템이 있다고 하더라도 그것을 인덱스하고 검색하기 위한 기능들이 내장되어있지 않다.

이러한 근본적인 한계를 극복하기 위해서 각 운영체제들은 파일 시스템에 덧씌워 별도로 파일을 인덱스하고 검색할 수 있는 인터페이스를 제공한다. 각 시스템에서 제공하는 이러한 기능들을 충분히 활용하고 있다면 이미 그 사람은 개인 정보 시스템에 있어서 충분히 파워유저라고 할 수 있다. 하지만 이러한 접근은 근본적인 한계가 있는 접근이다. 첫번째로 이러한 레이어는 운영체제 간에 공유되지 않는다. 두번째로 운영체제는 기본적으로 모든 종류의 파일 형식들을 지원하지 않는다. 즉, 파일 내부에 포함된 내용이나 메타 데이터들을 모두 적절히 처리할 수 있는 것은 아니다. 마지막으로 여전히 파일 시스템 기반의 경로에 지나치게 의존적이다.

파일 시스템을 개인 정보 시스템으로 이해한다면, 이 시스템은 개인이 가진 정보를 유용하게 한다는 맥락을 포함하지 않는다는 점을 인지할 필요가 있다. 파일 시스템은 철저히 데이터를 구조적으로 저장한다는 맥락에서 설계되었다. 하지만 정보 시스템의 본질적인 가치는 정보의 저장에 있지 않다. 앞선 디자이너의 예에서 다음 파일을 찾고 싶다고 가정해보자.

2016/09/낰욧 기획사/봉투 디자인/20160902 초기 시안.ai

이 디자이너는 분명히 구조적으로 폴더 시스템을 잘 활용하고 있다. 하지만 이러한 디렉터리 구조는 얕은 경로에서 작업 시기를 정확히 알고 있어야만 해당하는 주제를 찾을 수 있도록 구성이 되어있다. 단순 이름 검색이 가능하다고 하더라도 실제로 찾고 있는 파일인지를 확인하는 방법은 경로를 확인하거나 실제로 열어보는 일이다.

다시 광역적인 정보 시스템을 생각해보자. 구글과 같은 거대한 검색엔진은 우리가 상상할 수도 없을만큼 많은 정보를 매일 인덱스하고 검색 가능하게 해준다. 이 때 우리에게 중요한 것은 실제 데이터가 어디에 있는 지가 아니다. 구글 덕분에 우리는 정보를 검색할 때 정보의 위치(즉, 파일시스템의 경로)를 완전히 무시한 채, 키워드만으로 어떤 정보에 이르는 새로운 경로를 가질 수 있게 된다. 구글이 가진 근본적인 가치는 무수히 많은 문서 중에서 가장 가치 있는 문서로 정렬을 해준다는 점이다. 우리는 때때로 나중에 필요한 것들을 로컬 파일 시스템에 저장해놓곤 한다. 하지만 어떤 정보가 필요할 때 그것을 파일 시스템에서 찾는 것보다, 구글에서 다시 검색하는 게 더 빠른 경우가 자주 발생한다. 즉, 구글의 본질적인 가치는 이 세상의 모든 정보를 저장하는 것이 아니라, 이전 글(정보 과잉과 개인을 위한 정보 관리 도구)에서 이야기했듯이, 기록된 것을 유용하게 하는 능력의 진화에 있다.

버니바 부시가 지적했듯이 정보 과잉이 디지털 시대의 전유물이라고 생각하는 것은 착각에 불과하다. 정보 과잉은 이미 1900년대 초반부터 시작되었다. 앞서 이야기했듯이 광역적 정보 시스템의 본질적 가치는 정보의 양이 많아지는 속도보다 기록된 것을 유용하게 하는 능력을 빠르게 증가시키는 일이다.

안타깝게도 파일 시스템에 기반한 개인 정보 시스템이란 한 수십년 동안 정체중인 것으로 보인다. 추측컨데, 개인 정보 시스템에 있어서 정보 과잉이란 깊게 논의되지 않았던 게 아닐까 싶다. 개인 정보 시스템은 광역적인 정보 시스템과는 본질적인 차이가 하나 있다. 광역적 정보 시스템은 매우 탐욕적이라서 수집하고자 하는 모든 대상을 가능한 한 모두 수집하려고 한다. 이러한 탐욕성은 구글 북스와 같은 시스템에서 여실히 드러난다. 하지만 개인 정보 시스템은 지극히 개인적으로 정보(파일)을 늘려나간다. 그것은 개인의 창작물일 수도 있으며, 타인이 생산한 정보들일 수도 있다. 파일 시스템에 파일이 추가되는 것은 철저히 개인의 행동에 의해서 이루어진다. 즉, 파일 시스템은 시스템이 가진 정보를 유용하게 하는 능력보다도, 소유자가 파일 시스템 전체를 충분히 파악하고 있는 동안에만 유용하다. 그리고 바로 그러한 사실에 의존적으로 존재해왔던 셈이다.

나는 파일 시스템의 한계를 여실히 드러냈던 사례 중에 하나가 NAS(network attached storage)였다는 생각이 든다. NAS는 기존 파일 시스템에 기반해 파일을 통째로 넣을 수 있는 보조장치에 불과하고 결코 개인 정보 시스템은 아니다. 저장장치를 확장해주는 동시에, 지나치게 많은 파일들을 가질 수 있게 만들어준다는 점과 레이턴시의 증가로 컴퓨터를 개인 정보 시스템으로 활용하고자 할 때 더 지옥 같은 경험을 만들어준다.

예를 들어 사진을 관리하고자 한다면 NAS보다는 구글 포토스(Google Photos)나 어도비 라이트룸(Adobe Lightroom) 같은 모델이 훨씬 던 미래적이고, 개인 정보 시스템에 가까울 것이다. 중요한 것은 사진 수만-수십만 장을 한 파일 시스템에 저장하는 것이 아니다. 오히려 저장 장치는 파일의 경로에 의존하지 않도록 분산화될 수 있어야하고, 이것들을 관리하는 데이터베이스와 그것을 유용하게 하는 소프트웨어가 필요하다. 어도비 라이트룸은 데이터베이스를 구축하고, 메타데이터를 통해서 사진들을 분류하고 관리할 수 있도록 도와준다. 구글 포토스는 (다른 제약을 가지고 있지만) 좀 더 급진적이다. 사진을 분석하고 새로운 메타데이터를 생성해내서, 수동으로 태그나 메타데이터를 관리하지 않더라도 사진을 탐색할 수 있는 새로운 접근을 가능하게 해준다.

파일 시스템 위에서 개인들은 정보 과잉에 시달리고 있다. 이는 자신들이 가진 정보를 충분히 유용하게 만드는 능력이 없기 때문에 발생하는 일이다. 이는 개인의 한계가 아니라 소프트웨어적인 한계이다. 이런 맥락에서 보더라도 데스크탑에서 개인 정보 시스템을 구축하는 가장 근본적인 접근은 파일 시스템을 벗어나는 일이라고 생각한다. 운영체제의 접근이 성공적이진 못 했지만, 여전히 파일 시스템에 의존적이라고 할 지라도, 그 위에 하나 이상의 레이어가 덧씌워져야 함은 분명하다. 이러한 방향에서 서비스나 애플리케이션들이 존재하지 않는 것은 아니다. 앞서 보았듯이 어도비 라이트룸 같은 경우는 기존의 저작물 생산 도구들과는 확연이 다른 방향에서 개인 데이터베이스를 구축하는 데 초점을 맞추고 있다. 구글 포토스 역시 최근에 알파고가 보여준 것과 비슷한 맥락에서 정보에 대한 새로운 패러다임을 제시한다. 좀 더 범용적인 도구로는 에버노트(Evernote)나 데본싱크(Devonthink)와 같은 도구들이 있을 것이다. 이러한 소프트웨어들은 파일 시스템을 극복하고 어떻게 개인이 구축한 좀 더 많은 정보들을 유용하게 만들 수 있는 지를 보여준다.

개인 정보 시스템은 이제 첫 걸음을 시작했을 뿐이다. 앞으로도 이러한 소프트웨어에 대한 필요는 갈수록 늘어갈 것이다.

기록은 자산이다. 기록이 그 자체로서 큰 의미를 가지는 것은 아니다. 기록은 되어야하며, 그리고 활용되어야한다. 예를 들어 온라인 상에는 어마하게 많은 정보가 있고, 이것 자체만으로도 인류의 집단 지성 그 자체라고 말할 수 있을 것이다. 여기서 기록은 각자의 몫이다. 그리고 서로 다른 목적을 가진 개인들이 이러한 공개된 기록에 접근하고 가치있게 사용할 수 있도록 돕는 것이 바로 검색엔진의 몫이다. 그래서 기록은 되어야하며, 활용되어야한다.

일반적으로 구글과 같은 범용적인 검색엔진은 사용자의 맥락까지 염두에 두진 않는다. 하지만 모든 기록이 범용적인 것은 아니다. 기록은 방대하며, 검색엔진은 범용적이다. 이를 보완하기 위한 기법 중 하나는 개인화된 기록이다. 이는 개개인이 자신을 위해서나 국소적인 맥락에서 일부 사람들과 공유하기 위해서 만들어내는 것이다. 인간의 기억은 한계를 가지고 우리가 보고 들은 것, 그리고 검색하고 탐구한 것을 전부 기억하지는 못 한다. 개인화된 기록은 이를 보완하는 장치이며, 컴퓨터에 기반한 개인화된 기록 장치는 일반적으로 무한에 가까운 저장용량을 제공한다. 위키위키, 블로그, 노트 애플리케이션, 서지 애플리케이션, 웹 스크랩 도구와 같은 것들은 모두 기록을 돕고, 이를 활용하기 위한 다양한 기능들을 제공하는 도구이다. 여전히 많은 사람들이 개인의 내제적인 능력을 중요하게 여기지만, 나는 기록을 대하는 태도가 궁극적으로는 개인의 경쟁력에 있어서 더 큰 의미있는 차이를 만들어 낼 것이라고 믿는 쪽이다.

그리고 이는 법인에 있어서도 마찬가지이다. 나는 오래된 기업이 신생 기업에 비해서 가질 수 있는 거의 유일한 장점은 기록이라고 믿는다. 직원으로서 개인의 신체에 축적되는 경험은 개인에게 귀속된다. 이 때 이 경험을 법인과 개인이 공유할 수 있는 방법은 기록밖에 없다. 만약에 이 경험에 대한 어떠한 기록도 남기지 않는다면, 개인은 회사에 다니면서 얻은 수많은 신체에 각인된 능력(혹은 기록)들을 가지고 회사를 떠날 수 있지만, 기업은 그 사람이 떠난 이후에 아무런 가치도 얻지 못 할 것이다. 이런 일은 현실에서 빈번하게 일어나는 것처럼 보인다. 전임자가 떠나고 나면, 후임자는 마치 백지에서 일을 시작하는 것처럼 보이기도 한다. 아니면 전임자가 떠날 때야 비로소 인수인계를 하라고 이야기하지만 이 역시 빈틈이 많고 문서화 되기보다는 구전되는 경우가 많다. 하지만 기업 내에 기록을 위한 충분한 시스템이 갖추어져있다면, 인수인계라는 것은 업무에 대한 것이 아니라, 권한에 대한 것만으로도 충분해질 것이다.

법인은 어떤 면에서 개인보다도 이러한 가치를 인지하는데 무능할 수 있다. 왜냐면 법인으로서 살아남기 위해서는 장기적인 맥락에서 가치를 축적하는 것보다 당장 돈을 보는 것이 급급하기 때문이고, 법인은 스스로 기록의 가치를 인지하지 못 하고, 항상 법인을 운영하는 주체들에 의해서 기록의 가치를 인지할 수 있기 때문이다. 법인이라고 본질이 달라지는 것은 아니다. 개인보다 나은 점도 있다. 그 가치를 이해하기만 한다면, 시스템으로 잘 갖추기만 한다면 기록은 자동적으로 이루어지고 또한 오랜 시간 남아 법인의 가치를 높여갈 것이다.

컴퓨터는 크게 하드웨어와 소프트웨어로 구성된다. 범용 컴퓨터는 고정된 물리적 하드웨어에서 변경 가능한 소프트웨어를 실행 가능하도록 하면서 등장했다. 흥미로운 건 원래 소프트웨어도 물리적 실체가 있었다는 점이다. 그 이전에는 더욱 그랬지만, 천공 카드만 보더라도 눈에 보이고, 만질 수 있고, 촉감이 있고, 온도가 있으며 심지어 사람이 내용을 읽고 이해할 수 있는 물체였다. 하지만 저장장치와 입출력 장치의 발전에 따라서 이러한 물리적인 성질은 사라져버린다. 이제 소프트웨어는 가상적인 실체가 되었다. 눈에 보이지도 않고, 만질 수도 없으며, 촉감도 없고, 온도도 없고 오직 컴퓨터 하드웨어 연결된 출력 장치(모니터)를 통해서만 내용을 확인하거나 실행해볼 수 있는 가상의 존재이다.

하드웨어의 물리적인 지위는 공고해보인다. 특히 입력장치(키보드, 마우스 등)와 출력장치(모니터) 세트로 구성된 인간과 계산 유닛의 인터페이스로서 컴퓨터의 물리적인 실체가 위협 받은 일은 아직까지는 없는 것 같다. 하지만 모든 계산 장치(컴퓨터)가 인간과 직접 상호작용하는 인터페이스와 직접 연결되어있는 것은 아니다. 일반적으로 서버 컴퓨터는 사용자가 이 컴퓨터에 접근하기 위한 물리적인 인터페이스를 가지지 않는다. 이러한 인터페이스는 초기 셋업이나 컴퓨터가 정상적으로 작동하지 않는 비상시에만 사용되며, 평시에는 네트워크를 사용해 외부의 인터페이스를 사용해서 접근한다. 인터페이스로 사용하는 컴퓨터에서는 직접 계산을 하지 않고, 서버 컴퓨터의 자원을 사용해 계산을 할 수 있다.

명령을 내리는 클라이언트 컴퓨터와 계산만을 수행하는 서버 컴퓨터의 구성은 지금은 너무나도 당연한 것이 되었다. (인터페이스 역할을 하는) 컴퓨터에서 가능한 많은 일들이 실제로 클라이언트 컴퓨터에서 일어난다고 생각하면 오산이다. 연산은 네트워크 상에 있는 사람 컴퓨터를 통해서 이루어진다. 단순히 웹브라우저로 어떤 웹사이트에 접속하는 것조차도 사실은 다른 사람 소유의 컴퓨팅 자원을 사용하는 일이다. 네트워크의 본질은 다른 컴퓨팅 자원을 활용하는 일이다.

그렇다고 원격에 존재하는 물리적인 실체가 사라지는 것은 아니다. 서버 컴퓨터는 누군가 조립해서 만든 특정한 CPU와 메모리, 저장용량을 가진 한 단위의 컴퓨터이기 때문이다. 네트워크 너머의 물리적 실체. 인터넷 데이터 센터(IDC)에 가면 이러한 독립적인 단위의 서버 컴퓨터들이 무수히 많이 설치되어있다. 서버 컴퓨터를 관리하는 사람들에게 이런 물리적인 실체와 물리적으로 셀 수 있는 단위를 가진 컴퓨터란 굉장히 중요하다.

하지만 클라우드가 등장하면서 컴퓨터의 단위가 도전받기 시작한다. 예를 들어서 특정한 사양을 가진 컴퓨터 10대가 필요하다고 해보자. 기존에는 IDC 상에 물리적 실체를 가진 서버 컴퓨터 열 대를 설치해서 네트워크 설정을 해야했다. 하지만 클라우드에서는 사양과 필요한 대수를 지정하면 곧바로 서버 컴퓨터들을 사용할 수 있다. 여기서 중요한 점은 클라우드 서비스가 서버 설치 업무를 대행해주는 일을 하는 서비스가 아니라는 점이다. 실제로는 클라우드 데이터 센터에 이미 무수히 많은 서버 컴퓨터가 존재하고 있다. 이러한 서버 컴퓨터들은 여전히 셀 수 있는 물리적 실체를 가지고 있지만, 이제 더 이상 이 물리적인 단위를 기준으로 사용자에게 제공되지는 않는다. 클라우드 서비스는 이러한 인프라스트럭처(서버 컴퓨터들의 집합) 위에서 가상화된 컴퓨팅 자원(=새로운 단위의 서버 컴퓨터)을 제공한다. 따라서 데이터 센터에서 허용하는 한 어떠한 사양(크기)의 컴퓨터라도 요청받는 즉시 생성해서 제공할 수 있게 된 것이다.

가상화라는 기술을 클라우드 서비스에서 처음 사용한 것은 당연히 아니다. 하지만 클라우드가 혁명적이었던 이유는 서버 컴퓨터가 필요한 사람들이 더 이상 서버 컴퓨터의 물리적 실체를 고려할 필요가 없도록 만들어주었다는 점이다. 클라우드 서비스를 제공하는 쪽에게 여전히 서버 컴퓨터는 물리적 실체를 가지고 있지만, 적어도 이를 이용하는 사람들은 서버 컴퓨터의 물리적인 제약에 대해서 고려를 할 필요가 없어졌다. 이제 컴퓨팅 자원은 사양이 고정되어있지 않으며, 아무리 많이 사용하더라도 공간을 차지하지도 않는다. 클라우드가 등장하면서 이제 컴퓨터를 세는 단위는 물리적 하드웨어가 아니며, 클라우드 위에서 진정으로 가상화된 실체가 되었다.

클라우드 데이터 센터는 물리적인 실체를 가지고 있지만 클라우드 서비스의 컴퓨팅 자원을 비롯한 모든 하드웨어 장비는 가상화되어있다. (제대로 된) 클라우드 서비스들은 기존의 물리적인 하드웨어가 하는 역할을 하는 가상화된 장치를 생성하고 수정하고 삭제하는 일련의 작업을 코드로 실행할 수 있도록 API를 제공한다. 소프트웨어가 동적인 성격을 가진 것처럼, 소프트웨어를 실행하는 하드웨어 자체가 동적으로 구성될 수 있는 가능성이 열린 것이다. 물리적인 실체는 이제 가상화된 자원을 조작하는 인터페이스 뒤로 숨어버린다. 하드웨어가 소프트웨어로 추상화되었다.

컴퓨터 네트워크 구성을 위한 물리적인 장비들을 구성하고 설계한 것을 아키텍처라고 한다. 설계란 제약 위에서 어떤 문제를 해결하기 위해 상상력을 펼치는 공간이다. 그러나 현실에서 아키텍처를 구성하는 요소는 모두 물리적인 실체를 가지고 있으며, 이러한 설계로부터 구현된 아키텍처가 얼마나 경직되어있는지는 쉽게 상상할 수 있다. 물리적으로 구현되어야하는 아키텍처는 자연스럽게 물리적인 제약들에 대해서 고려해야만 한다. 가장 간단한 경우를 생각해보자. 서버 컴퓨터를 한 두 대 설치할 때 공간은 문제가 아니지만, 이런 서버를 1000대씩 설치하기 시작한다면 공간에 대한 비용이나, 건물이 서버 무게를 견딜만큼 튼튼한지가 현실적인 문제가 된다. 처음 구상하던 아키텍처를 서버실의 형태나 크기를 확인하고 다시 처음부터 설계해야할 수도 있다. 이외에도 다양한 구성요소들이 있으며 처음 아키텍처를 구현할 때 드는 비용도 높지만, 이를 다시 수정하는 비용은 처음에 설치하는 비용보다 더 클 수도 있다. 이런 면에서는 컴퓨팅은 물리적 공간을 설계하는 건축의 영역에 걸쳐있다.

클라우드를 감히 혁명이라고 말하는 것은 이러한 아키텍처의 물리적인 속성을 증발시켜버렸기 때문이다. 클라우드 위의 모든 자원은 가상화되어있으며 아키텍처를 상상하기만 한다면 그대로 만들어질 수 있다. 물론 기존 하드웨어 리소스를 가상화된 리소스가 완벽히 대체하는 것은 아니다. 클라우드 위에서는 아키텍처를 설계하기 위해서는 클라우드 리소스들이 어떤 역할을 하는지에 대한 충분한 이해가 필요하며, 게임의 논리 자체가 달라졌으므로 완전히 새로운 설계 원칙들을 익혀야만 한다. 기능이 아니라, 리소스의 실체 때문에 설계 전략도 달라진다.

클라우드 위에도 여전히 설계와 구현 사이의 갭은 존재한다. 설계를 클라우드 자원들로 구현하는 작업은 의외로 쉽지 않다. 이런 작업을 처음하는 사람이라면 상당한 시행착오를 거쳐야만 한다. 클라우드가 다음으로 발전할 방향은 사실 여기서부터 이미 확정되어있던 걸지도 모른다.

설계와 구현의 갭을 메우기 위해 자연스럽게 코드로서의 인프라스트럭처(Infrastructure as Code, IaC) 패러다임이 등장한다. 여기서 코드는 절차적인 명령이라기보다는 아키텍처 설계를 위한 문법이라고 이해되어야한다. 이러한 대표적인 도구로는 아마존 웹 서비스의 클라우드 포메이션(CloudFormation)이나 하시코프의 테라폼(Terraform)이 있다. 테라폼은 HCL이라는 전용 언어를 사용하며, 이를 사용해 컴퓨팅 자원을 정의하는 코드는 다음과 같다.

resource "aws_instance" "web" {
  instance_type = "t2.micro"
}

이 코드가 곧 컴퓨팅 자원 한 단위를 정의하는 명령어이다. 실제로 이 코드가 곧 컴퓨팅 자원이라는 것을 이해한다면 클라우드의 강력함을 실감할 수 있을 것이다. 이 코드 어디에도 물리적인 실체에 대한 고려는 없다.

훨씬 더 좋은 성능을 가진 컴퓨터 10 단위를 정의하는 코드도 크게 다르지 않다. instance_type과 count 속성을 지정하면 그만이다.

resource "aws_instance" "web" {
  instance_type = "m4.4xlarge"
  count = 10
}

IaC는 아키텍처 설계와 구현의 갭을 메워준다. 테라폼의 HCL 코드는 그 자체가 클라우드 아키텍처의 설계도이며 동시에 구현이다. 테라폼에는 plan과 apply 명령어가 있는데, plan은 HCL로 설계한 아키텍처가 실제로 구현 가능한 아키텍처인지를 임시로 검증해주며, apply는 설계도 대로 클라우드 위에 아키텍처를 구현한다. 설계도가 곧 실체가 되었다. 이 실체는 기존의 물리적인 하드웨어들로 구성된 아키텍처와 같은 역할을 하는 실체이다.

이러한 변화는 놀라운 것이지만 아직 끝이 아니다. 테라폼에는 모듈 기능이 있다. 모듈은 아키텍처 재사용을 위한 추상화된 형태로 아키텍처를 작성하는 방식을 지원한다. 모듈은 재사용될 수 있으며 몇 가지 매개변수에 따라 다양한 양태로 실체화된다. 물리적인 아키텍처든 클라우드 아키텍처든 기존에 아키텍처를 조금이라도 설계해보고 구현해본 적이 있다면 이러한 접근이 마냥 반갑지만은 않을 것이다. 앞서 살펴보았지만 하드웨어가 물리적인 실체였던 시절에 아키텍처란 매우 경직되어있는 것이었다. 아키텍처는 다양한 제약들을 바탕으로 최적화된 형태로 만들어져야 했으며, 아키텍처 설계를 위해 공유할만한 패턴들이 존재하더라도 아키텍처 자체를 재사용한다는 발상은 상식적으로 받아들이기 쉽지 않은 것이었다. 클라우드에 온다고 이런 사정이 완전히 달라지는 것은 아니다. 일반적인 아키텍처 설계를 받아들인다고 하더라도 항상 자신의 상황에 맞춰 최적화를 해야하기 때문이다. 따라서 여전히 아키텍처는 재활용하는 것이 아니라 상황에 따라 최적화된 형태로 매번 재설계하는 것이었다. 나는 모듈 기능에 대해 회의적인 입장이었지만, 하시코프(Hashicorp)는 이런 생각에 게의치 않고 하시콘프(Hashiconf) 2017에서 테라폼 모듈 레지스트리(Terraform Module Registry)를 발표한다.

테라폼 모듈의 본질은 아키텍처를 추상화하는 것이다. 이에 대한 불신은 아키텍처가 추상화할 수 있는 성질의 것인지에 대한 의문이다. 테라폼 모듈 레지스트리를 보면서 아키텍처 추상화가 비록 어려운 것이더라도 결국 이 방향으로 발전해나갈 것이라는 확신이 들었다. 아키텍처가 추상화 되면 복잡한 설계는 모듈 뒤로 숨어버린다. 모듈을 사용하면 복잡한 아키텍처 구현에 대한 충분한이해 없이도 아키텍처의 가치를 충분히 향유할 수 있게 된다. 예를 들어보자. 클라우드에서 병렬적으로 딥 러닝 학습을 수행하고 싶은 데이터 과학자가 있다. 하지만 클라우드 위에서 이러한 학습 환경을 구축하기 위해서는 클라우드를 비롯해 아키텍처에 대해서도 상당한 지식을 필요로 한다. 하지만 이러한 학습 환경을 지원하는 잘 구현된 아키텍처 모듈이 있다면 이 데이터 과학자는 이 아키텍처를 사용하고 자신은 학습 프로그램을 개발하는 데만 집중할 수 있다.

이런 일이 정말로 가능하냐고 묻는다면 현재 내 답은 당연히 아니오이다. 아키텍처에 대한 이해없이 아키텍처를 향유한다는 것 자체가 어려운 일이기 때문이다. 모듈은 여전히 가상화된 자원 자체를 완벽하게 숨겨주지는 않는다. 사용자는 아키텍처 모듈을 사용하더라도 클라우드 콘솔과 API를 직접 사용해서 많은 문제에 대응해야 하며, 이를 위해서 극단적인 경우 아키텍처 모듈을 설계한 사람만큼의 지식이 필요할 수도 있다. 또 다른 문제도 있다. 원칙적으로 모듈을 같은 클라우드 계정 안에서 매개변수만 바꿔서 여러번 정의할 수 있어야한다. 그러나 클라우드는 모듈을 구현하기 위해 충분히 격리된 공간을 제공하지 않는다. 이 때문에 아키텍처를 모듈로 추상화하는 작업이나 사용하는 방식은 상당히 교묘해질 수 있다. 예를 들어 이름 충돌을 방지하기 위해서 리소스의 자원이 어느 정도 범위에서 공유되는지 이해하고 있어야한다. AWS의 경우 S3의 이름은 모든 사용자 수준에서 공유되며, IAM은 계정 수준에서 공유된다. ELB는 리소스 이름이 곧 id로 사용되며(즉, 이름이 같으면 충돌이 난다), EC2와 같은 어떤 자원은 리소스 이름을 태그로 지정되기 때문에 전혀 충돌이 일어날 일이 없기도 하다. 모듈을 정의하려면 추상적으로 아키텍처를 설계해야하며 이러한 예상가능한 충돌에 대해서 충분히 대비해야한다. 바로 이러한 이유들 때문에 아키텍처 모듈(추상화)에 대한 의심은 합리적으로 보인다.

마법은 없다. 현실적으로 아직은 쉽지 않고, 많은 시행 착오들이 필요해보인다. 현실적인 한계는 있지만, 그럼에도 불구하고 아키텍처 추상화는 충분히 이상적인 발전 방향이다. 결국에 테라폼의 모듈도 진화해나갈 것이고, 클라우드 역시 이러한 추상화를 충분히 지원하는 방향으로 진화해나갈 것이다. 컴퓨터의 진화라는 관점에서 이러한 변화는 하루 아침에 시작된 것이 아니다. 이 아래에는 분명히 물리적인 제약으로부터의 해방과 더 높은 추상화라는 일관적인 저류가 흐르고 있다.

나는 플레인 텍스트를 좋아한다. 비단 나만 그런 것은 아니다. 프로그래머라면 대부분 플레인 텍스트를 좋아한다. 프로그래머가 아닌 사람들에게 플레인 텍스트라는 표현은 이상하게 들릴지도 모르겠다. 텍스트면 다 똑같은 텍스트이지 플레인 텍스트가 있고 아닌 게 따로 있을까. 플레인 텍스트는 일반적으로 서식이 없는 순수한 텍스트 집합을 의미한다. 미디어로서의 컴퓨터는 플레인 텍스트로부터 사람들에게 더 큰 자유를 부여하는 방향으로 가고 있는 것처럼 보이지만, 역설적으로 프로그래머들은 플레인 텍스트를 더 선호한다. 이 둘의 차이는 분명히 기술적인 문제를 내포하고 있지만, 이보다는 둘을 분리해서 바라볼 수 있는 세계관의 차이가 더 중요하다.

프로그래머는 소스 코드를 편집하고 이를 실행하는 과정에서 플레인 텍스트의 강력함에 눈을 뜬다. 플레인 텍스트의 제 1 원칙은 문자들로만 구성된다는 점이다. 프로그래밍 언어로 표현된 소스 코드는 서식을 가지지 않는다. 임의로 부여된 서식을 가지지 있지만 않지만, 텍스트 에디터는 코드를 분석하고 자동적으로 품사 별로 색을 입혀준다. 이 기능을 코드 하이라이팅이라고 부른다. 무미건조한 텍스트의 나열일 뿐인 코드가 화려해보이는 이유는 여기에 있다. 또한 플레인 텍스트는 범용적이다. 문자로만 구성된 문서는 어디에나 저장할 수 있고, 어떤 텍스트 에디터로도 편집할 수 있다.

텍스트 에디터 위의 소스 코드(플레인 텍스트)는 어떤 서식보다도 화려하다.

이러한 범용성 덕분에 텍스트는 서로 다른 도구들 간의 가교 역할을 한다. 명시적인 프로토콜이 결정되어있지 않더라도 텍스트를 전달한다는 것을 보장함으로서 데이터를 처리할 수 있다. 그래서 플레인 텍스트의 제 2 원칙은 플레인 텍스트를 다루는 애플리케이션은 플레인 텍스트로 입력으로 받고 플레인 텍스트로 출력해야한다는 점이다. 오직 플레인 텍스트로 소통하는 타입 없는 평면적인 세계.¹ GUI에만 익숙한 사람들에게 명령어를 직접 입력하고 텍스트밖에 출력되지 않는 CUI 환경은 부족해보일지 모르지만, CUI의 본질적인 강력함은 플레인 텍스트라는 전제를 공유함에 기반한다. 플레인 텍스트를 이해하지 못 한다면 CUI는 영원한 미스터리로 보일 것이다. 플레인 텍스트의 강력함은 프로그래머를 둘러싼 세계관이자, 세계 그 자체인 것이다.²

이러한 강력함으로부터 프로그래머들은 심지어 소스코드가 아닌 글도 플레인 텍스트로 작성하려고 한다. 그렇다고 서식을 버린 것은 아니다. HTML이나 TeX도 플레인 텍스트이지만 직접 작성하기에는 너무 복잡하다. 이에 대한 대안으로 글쓰기를 위한 경량 플레인 텍스트 포맷들이 존재한다. 경량 마크업 언어라고도 불린다.

예를 들어 어떤 플레인 텍스트 포맷은 서식을 문자로 표현하는 방법을 정의한다. *강조*와 같이 * 사이에 글자를 넣으면 볼드체가 되고, /기울임/과 같이 / 사이에 글자를 넣으면 이탤릭체가 된다. ³ 이런 방식으로 글쓰기에만 집중할 수 있고 제약은 있지만 서식을 충분히 사용할 수 있다. 충분하다는 말은 이를 테면 이런 뜻이다. 글을 쓰다가 어떤 문자를 강조하고 싶을 때 1677만 색 중에 하나를 정확히 고를 수도 있겠지만, 플레인 텍스트 포맷에서는 애시당초에 그런 선택지가 제공되지 않는다. 또한 마크다운의 서식은 에디터 상에서 충분히 서식처럼 보인다. 제목은 제목처럼 보이고, 강조는 강조처럼 보이고, 목록은 목록처럼 보인다. (그리고 코드 하이라이팅은 더욱 더 그렇게 만들어준다)

하지만 가독성은 무엇보다도 중요하다. 마크다운은 문서는 그 자체로 플레인 텍스트로서 태그나 포맷팅 명령으로 보이는 것들 없이 퍼블리싱 될 수 있어야한다.

Readability, however, is emphasized above all else. A Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions.

— Markdown: Syntax , John Gruber

마크다운⁴도 경량 마크업 언어 중 하나이다. 글쓰기를 위한 경량 플레인 텍스트 포맷들이 언제부터 지금만큼 인기 있었는지는 모르겠지만⁵, 마크다운의 등장은 특히 중요한 역할을 했다. 프로그래머들도 마크다운을 좋아했고, 프로그래머가 아닌 사람들도 마크다운의 강력함을 깨닫기 시작한다.⁶ 경량 마크업 언어(플레인 텍스트 포맷)와 글쓰기는 실제로 찰떡궁합이다. 리치 텍스트 에디터나 워드프로세서의 서식은 궁극적으로 유용하지만, 글을 쓰는 과정에서는 거추장스럽다. 몇 가지 마크다운 문법만 익히고 나면 서식에 대한 고민 없이 글쓰기에만 집중할 수 있다.

이에 발맞춰 마크다운에 최적화된 에디터들이 등장하기 시작했다. 나는 마크다운 등장 이전의 텍스트 에디터를 (소스 코드 편집에 주로 사용되던) 제 1세대 텍스트 에디터라고 부르고, 그리고 그 이후의 등장한 (마크다운을 지원하는) 글쓰기 도구를 2세대 마크다운 에디터라고 부른다.

여기까지는 플레인 텍스트 만능주의가 옳은 것처럼 보인다. 마크다운은 분명히 글쓰기에서 강력한 힘을 발휘했다. 1세대, 2세대 에디터 모두 마크다운으로 글을 쓰기에는 훌륭한 도구였다. 1세대 에디터들은 마크다운 에디터라기보다는 마크다운도 지원하는 에디터들이라고 보는 것이 정확하다.⁷ 2세대 에디터는 플레인 텍스트의 철학을 유지하면서 마크다운으로 글을 쓰는 경험을 향상 시키기 위한 노력의 성과였다. 하지만 한 가지 면만을 바라봐서는 안 된다. 플레인 텍스트의 철학은 곧 마크다운 에디터의 한계가 되었다.

나는 마크다운의 가장 큰 장점이자 동시에 가장 큰 문제가 플레인 텍스트 포멧이라고 생각한다. 가장 치명적인 단점, 텍스트는 이미지를 표현하지 못 한다. 이는 GUI에 익숙한 사람들이 CUI를 의심하는 눈초리로 바라볼 때 느끼는 정확히 그 문제이다. 마크다운은 이미지를 표현하지 못 하고, 이는 앨런 케이가 컴퓨터를 모든 미디어를 표현할 수 있는 메타 미디엄이라고 정의했던 관점에서 바라보자면 명백한 굴욕이다. 명백히 텍스트 편집에만 관심을 두던 제 1세대 텍스트 에디터들은 이 문제에 관심을 두지 않았다. 안타깝게도 제 2세대 마크다운 에디터들조차 이 문제를 교묘하게 회피해버렸다.

텍스트 에디터는 이미지의 표현에 대해 완전하게 무관심했다.

미디어 표현의 문제는 두 겹의 층위를 가진다. 첫 번째 층위는 에디터에서 미디어를 표현할 능력이다. 이미지 출력이 불가능한 워드프로세서를 상상해보길 바란다. 마크다운 에디터가 그렇다. 마크다운 에디터에서는 이미지가 ![아름다운 이미지](http://IMAGE_URL)와 같은 문자열로 표현된다.⁸ 아름다운 이미지가 아름다운지 아름답지 않은지를 문서 상에서 확인할 방법은 없다. 두 번째 층위는 미디어에 대한 참조만 가능하다는 점이다. 마크다운으로 작성된 문서는 .md나 .markdown 확장자로 저장되며, 이 파일 하나가 문서를 온전히 표현해야만한다. 이 원칙에 충실하기 때문에 문서는 미디어와 완전히 분리되어 있고, 그래야만 한다. 마크다운으로 글을 써본 사람이라면 이미지를 어디에 저장할지 고민해본 적이 있을 것이다. 이미지는 문서 이전에 참조 가능한 위치에 먼저 존재해야 한다. 특히 로컬 이미지를 참조하는 마크다운 문서를 다른 경로나 컴퓨터로 복사한다면 이미지 참조는 깨질 것이다. 이미지가 있는 마크다운 문서는 출력물로서는 완벽하지 않지만, 여전히 미디어조차 텍스트로 표현하는 마크다운 문서로서는 완벽하다. 이미지 참조가 깨져도 완벽한 이 얄궂은 플레인 텍스트여…

2세대 마크다운 에디터들은 미디어 표현의 두 번째 층위는 완전히 무시했으며, 첫 번째 층위는 제한적으로만 해결책을 제시했다. 나중에 개발된 일부 마크다운 에디터는 에디터에 참조된 이미지를 바로 보여주는 기능을 지원했다. 이 방법은 미디어 표현 문제의 첫 번째 층위에 대해서는 괜찮은 해답이었지만, 2번째 층위는 여전히 완전히 무시하고 있었다. 2세대 마크다운 에디터에서 가장 인기 있었던 방법은 라이브 프리뷰다. 하지만 라이브 프리뷰 역시 마크다운의 한계를 자백할 뿐이었다. 마크다운은 명백히 플레인 텍스트로만 이루어진 마크다운 문법만으로도 충분한 표현력을 가졌지만, 사람들은 최종적으로 HTML으로 렌더링된 결과물을 신경써야만 했다. 결국 라이브 프리뷰는 에디터에서 온전히 글쓰기에만 집중할 수 있다는 마크다운의 장점을 갉아먹는 접근 방법이었다.

2세대 마크다운 에디터들은 이미지를 간접적으로 보여주지만 이미지의 존재 여부를 보장해주지는 못 한다.

라이브 프리뷰는 여러가지로 문제가 많았지만, 특히 긴 글을 쓸 때는 쥐약과 같았다. 긴 글을 쓸 대면 어김없이 에디터와 라이브 프리뷰의 스크롤은 일치하지 않는다. 자동 싱크를 사용하면 엉뚱한 위치를 가리키고, 그렇다고 수동으로 스크롤을 하면 현재 위치를 찾기가 힘들어진다. 글쓰기 도구로서 마크다운과 마크다운 에디터들에 대해서는 호평 일색이었고 이 도구들로 책을 쓴 사람들도 있었지만, 사실 긴 글을 쓰는 도구로서 마이크로소프트 워드나 스크리브너 같은 본격적인 글쓰기 도구의 진정한 경쟁자가 된 적은 없었다. 긴 글은 한 편의 글이 아니다. 글들이 모여서 장이 되고 부가 되고 책이 된다. 이 정도 길이의 글을 쓸 때는 글들을 구성하는 기능이 필수적이다. 긴 글은 글들과 글들의 구성, 그리고 주변의 메타데이터들까지 한 데 어우러져 비로소 하나의 문서가 된다. 그런데 이런 배려를 갖춘 마크다운 에디터는 내가 아는 한 나오지 않았다.⁹

퍼블리싱은 어떤까? 마크다운 문서를 퍼블리싱하는 방법은 크게 두 가지가 있다. 마크다운을 지원하는 플랫폼에 마크다운으로 작성한 텍스트를 복사해서 넣는 것이다. 하지만 마크다운은 텍스트로서는 완전하지만 문서로서는 완전하지 않기 때문에 참조 파일들을 처리하는 게 상당히 고통스럽다. 플레인 텍스트의 부흥과 함께 스태틱 웹사이트 제네레이터들도 함께 성장했지만 이러한 도구들은 그저 프로그래머들의 장난감일 뿐이었다. 이런 도구는 프로그래머나 쓰는 것이다. 나도 한 때 이런 도구들을 찬양했지만, 프로그래머가 아닌 사람에게 이런 도구를 추천하는 장면을 목격한다면 냉소적인 감정을 느낄 것이다.

정리해보자. 경량 마크업 언어(플레인 텍스트 포맷)와 마크다운 에디터는 글쓰기에 좋다. 나는 마크다운으로 글을 작성하는 경험을 사랑한다. 하지만 어떠한 미디어도 포함하지 않는 한 편으로 구성된 짧은 글을 쓸 때 가장 유용하다. 플레인 텍스트는 만능이 아니다. 나사와 망치가 어울리지 않는 것처럼.

아담 하이드(Adam Hyde)는 신랄하게 이야기한다.

마크다운이 유용한 경우는 제한적이다. 깃허브에서 README 파일을 작성할 때나 마크다운을 사용하길 바란다.

Markdown is good for limited use cases. Use it for README files on github.

— What’s Wrong with Markdown?, Adam Hyde

공감한다. 최상의 경험에 대한 기대와 실망의 시간들. 하지만 실망하기는 이르다.

다음 이야기는 율리시스(Ulysses)로부터 시작한다. 나는 율리시스를 제 3세대 마크다운 에디터로 정의한다.¹⁰ 세대를 나누고자하는 시도는 그 둘 사이에 현저한 차이가 있기 때문이다. 플레인 텍스트 기반 글쓰기 도구들은 이제 여명을 맞이했을 뿐이다.

스크리브너는 직업으로 글을 쓰는 사람들에게 갈수록 많은 인기를 얻고 있지만, 모던한 앱들의 세련된과 완성도를 생각했을 때 썩 만족스러운 앱은 아니다. 인터페이스는 낡았고, 아이클라우드나 드랍박스에 기반한 자연스러운 싱크를 지원하지도 않으며, 메인 에디터는 기본 텍스트 에디터와 같은 rtf 기반이다.¹ 그럼에도 스크리브너가 인기 있는 이유가 있다. 나는 글쓰기에 베어나 율리시스를 주로 사용하지만 2만자 이상의 글을 쓸 때는 이런 노트 애플리케이션보다 스크리브너를 선호한다. 스크리브너는 글쓰기에 대한 독자적인 철학을 가지고 있으며 그러한 철학을 훌륭히 구현하고 있다. 그렇기 때문에 다른 도구들은 스크리브너의 자리를 함부로 넘보지 못 한다.

명확한 기준은 없지만, 위에서 이야기했듯이 내가 스크리브너를 다른 도구보다 선호하는 기준은 2만자 정도이다. 보통 IT 전문서에 코드나 이미지가 포함되는 걸 고려했을 때 한 페이지에 700-800 자 정도가 되니, 2만자면 30페이지가 조금 못 되는 분량이다. 물론 그 이상이라고 했으니 상한은 없다. 나에게 이 길이는 의미가 있다. 이 길이는 내가 노트 하나에 적을 수 있는 최대 길이이다. 이 길이가 되면 더 이상 하나의 글을 대번에 파악하는 게 불가능해진다. 글은 제대로 구성되었는지, 앞뒤로 문맥은 어울리는지, 잘못된 내용은 없는지 검토하려면 끊임없이 앞뒤로 왔다갔다 해야하는데, 점점 정신은 산만해진다. 더욱이 베어나 율리시스 에디터는 이 정도 길이가 되면 반응도 조금씩 느려진다.

베어보다 율리시스가 조금 사정이 낫다. 율리시스는 긴 글을 나눠서 쓰고 한 번에 볼 수 있는 기능을 제공한다. 율리시스에서는 여러개의 노트를 선택하면, 하나의 노트처럼 연속해서 볼 수 있고 편집도 할 수 있다. 그럼에도 불구하고 율리시스를 긴 글 쓰기에 추천하지는 않지만, 여기서 중요한 단서를 얻을 수 있다. 긴 글은 하나의 글이라기보다 일관성을 가지고 작성된 글들을 모아놓은 집합체라는 점이다. 실제로 스크리브너는 써본 사람이라면 이해하겠지만, 스크리브너는 글을 하나의 문서로 정의하기보다는 글들의 집합으로 정의한다. 앞서도 지적했지만 스크리브너의 에디터는 후지다. 그럼에도 스크리브너를 사용할 수밖에 없는 이유는 하나의 긴 글을 작은 글들의 집합으로 정의하는 도구가 드물기 때문이다. 이런 철학을 끝까지 밀어붙인 도구는 스크리브너 외에는 발견하기 힘들다.

긴 글을 쓰는 도구로서 워드와 비교해보면 이 차이는 좀 더 선명하게 드러난다. 마이크로소프트 워드도 긴 글을 쓰는 도구로 둘째가라면 서러워할만큼 훌륭한 도구이다. 하지만 스크리브너의 세계관은 조금 다르다. 예를 들어 워드나 스크리브너는 둘 다 개요를 작성하는 기능을 제공한다. 하지만 워드에서 긴 글은 어디까지나 하나의 글이다. 개요를 작성하고 글을 작성하는 일은 하나의 거대한 글의 부분을 작성하는 일이다. 하지만 스크리브너에서는 개요로 작성되는 모든 항목들은 하나 하나가 온전한 글(부분)이 된다. 스크리브너에서 글(프로젝트)는 이러한 글들을 모아서 비로소 하나의 글이 된다.

비슷해보이지만 이 차이는 의외로 크다. 앞서 율리시스의 여러개의 글을 선택해서 하나의 글처럼 볼 수 있는 기능을 소개했다. 스크리브너에서는 이 기능을 스크리브닝 모드라고 부른다. 스크리브너에서는 각 부분을 완전히 독립된 글로 작성할 수 있고, 이러한 글들을 여러개 선택해서 한꺼번에 보고 그 상태에서 편집을 할 수도 있다. 심지어 선택은 순서대로만 가능한 것도 아니다. 순서대로 여러 글을 선택할 수도 있고, 목차에서는 떨어져있는 부분들을 각각 선택해서 볼 수도 있다(워드에서는 불가능하다). 스크리브닝 모드는 작성중인 글을 여러가지 시점에서 볼 수 있는 기회를 제공해준다. 나는 이 차이가 바로 세계관의 차이라고 생각한다.

그 외에도 다양한 기능들이 있지만² 핵심은 바로 글을 바라보는 시각 그 자체이다. 이에 기반한 스크리브닝 모드와 아웃라이너를 대체할만한 도구는 별로 없다. 나는 플레인 텍스트로 글을 작성하는 경험을 사랑하지만, 그럼에도 불구하고 긴 글을 작성할 때는 스크리브너의 리치 텍스트 에디터에서 글을 작성하는 경험과 결과물을 그에 못지 않게 사랑한다.³