141: tweet overflow

플레인 텍스트의 매력과 2세대 마크다운 에디터의 한계

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

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

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

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

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

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

예를 들어 어떤 플레인 텍스트 포맷은 서식을 문자로 표현하는 방법을 정의한다. *강조*와 같이 * 사이에 글자를 넣으면 볼드체가 되고, /기울임/과 같이 / 사이에 글자를 넣으면 이탤릭체가 된다. 3 이런 방식으로 글쓰기에만 집중할 수 있고 제약은 있지만 서식을 충분히 사용할 수 있다. 충분하다는 말은 이를 테면 이런 뜻이다. 글을 쓰다가 어떤 문자를 강조하고 싶을 때 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

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

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

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

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

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

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

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

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

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

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

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

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

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

아담 하이드(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세대 마크다운 에디터로 정의한다.10 세대를 나누고자하는 시도는 그 둘 사이에 현저한 차이가 있기 때문이다. 플레인 텍스트 기반 글쓰기 도구들은 이제 여명을 맞이했을 뿐이다.


  1. 이것은 좋기도 하고, 나쁘기도 하다. 
  2. 물론 이러한 세계가 이상적인 세계는 아니다. 적절한 타입이 없다는 건 어떠한 데이터도 안전하지 않다는 의미가 될 수도 있다. 하지만 강력하다. 
  3. 이맥스(Emacs) org-mode. http://orgmode.org/ 
  4. 마크다운은 2004년 존 그루버(John Gruber)에 의해 발표되었다. 
  5. 멀리는 TeX나 roff까지 거슬러 올라가겠지만, 거기까지 고려하진 않는다. 
  6. 여기서부터 경량 마크업 언어라고 이야기하면 기본적으로 마크다운만을 이야기한다. 충분한 생태계를 가지고 있는 유일한 언어이기 때문이다. 
  7. 나는 특히 이맥스(Emacs)의 팬이었다. 모든 것을 이맥스로 해결하기를 원했지만, 그럴 수 없다는 것을 깨닫는 것은 오래 걸리지 않았다. 
  8. 대부분의 마크다운으로 글을 작성하는 사람들은 [] 사이에 들어갈 이미지를 설명하는 문구도 작성하지 않는다. 
  9. 내 생각에 마크다운으로 긴 글을 쓰는 가장 합리적인 방법이라면 스크리브너의 리치 텍스트 에디터 멀티마크다운으로 글을 쓰는 방법이다. 뭐라고? 리체 텍스트 에디터에서 플레인 텍스트 포맷으로 글을 쓴다고? 
  10. 나는 지금 이 글을 율리시스에서 쓰고 있다. 

비지니스 윤리를 내던져버린 기업들: 검은돈(넷플릭스 오리지널)

검은 돈은 오랜만에 흥미롭게 봤던 다큐멘터리였다. 하나의 사건을 파헤치는 책들을 보면 내가 어떤 사건을 얼마나 피상적으로밖에 이해하지 못 하고 있는 지를 알려준다. 예를 들어 천재들의 머니게임을 읽으면서 롱텀캐피털매니지먼트에 대해서 아는 게 없었다는 걸 알게 되었고, 비트코인: 암호 화폐에 베팅하라을 보면서 사이퍼펑크라는 단어를 처음 들어봤다. 좋은 다큐멘터리는 그런 역할을 한다.

검은 돈은 회차별로 완전히 다른 내용을 다루고 있다. 개인적으로는 1, 3, 4, 6화를 추천한다.1 폭스바겐이 몇 년 전 오염물질 배출량을 속여서 크게 문제가 됐다는 것은 알고 있었지만 딱 거기까지였다(1화). 밸리언트라는 기업에 대해서도 처음 들었다(3화). HSBC라는 은행은 이름만 들어봤지만, 돈세탁 때문에 문제가 된 건 금시초문이었다(4화). 트럼프가 누군지 모를리 없지만, 미국에서 어떻게 인지되는지에 대해서는 전혀 알지 못 했다(6화).

특히 재미있었는 건 밸리언트(VRX)라는 기업을 다룬 3화였다. 밸리언트는 뉴욕증권거래소에 상장된 캐나다의 제약회사인데 인수 합병를 중심으로 몸집을 불려나가며 한 때 월가의 총애를 받았다고 한다. 특히 퍼싱스퀘어 캐피털매니지먼트의 빌 애크먼이 밸리언트에 투자하고 경영에 참여하면서 더 큰 관심을 받는다. 다큐멘터리에서는 밸리언트에 투자한 빌 애크먼과 밸리언트를 의심스러운 행태를 뒤쫓아온 숏 트레이더들을 교차해서 보여준다. 밸리언트가 어떻게 성장했는지를 보면 가관이다. 다른 제약사를 인수 합병한 다음 R&D 비용을 줄이고 기존의 약값을 올려서 성과를 부풀린다. 밸리언트 편은 비합리성에 기반한 투자 시장의 어두운 면과 그리고 그런 부분을 먼저 캐치해서 움직이는 숏 트레이더를 잘 보여준다. 그 결과는? 주가 그래프가 잘 말해준다.

밸리언트의 지난 5년간 주가 그래프

밸리언트의 지난 5년간 주가 그래프

제가 하는 일은 돈이 목적이 아니에요. 이런 회사는 처단해야 마땅하잖아요.

파미 콰디르(Fahmi Quadir, Safkhet Capital), 검은돈 시즌1 3화 환자를 팝니다 중

이 이야기의 진짜 교훈은 부정직한 기업이 결국엔 망한다는 게 아니다. 이렇게 발생한 비용은 결국 사회 전체가 감당해야한다. 그리고 사실 밸리언트는 아직 망하지도 않았다. 바로 며칠 전에 이름을 밸리언트에서 바슈 헬스(Bausch Health, BHC)로 바꾼다는 기사2가 나왔다. 좀 늦은 감이 없지 않아 있지만, 문제가 생기면 이름을 바꿔보는 건 미국도 다르지 않은 모양이다.3

1화에서 다룬 폭스바겐도 디젤 게이트 당시 주가가 250유로에서 100유로까지 폭락한다. 그린 디젤이라는 표어 아래로 노골적인 조작을 해오던 폭스바겐을 보면 소름이 돋는다. 하지만 그런 짓을 하고도 폭스바겐도 망하지 않았다. 망하기는커녕 폭스바겐 그룹은 중국시장에서 약진하면서 재작년과 작년에 세계 자동차 판매 순위 1위를 기록한다 4.

폭스바겐의 지난 5년간 주가그래프

폭스바겐의 지난 5년간 주가그래프

현실은 안 그래도 모순 투성이지만, 폭스바겐은 또 하나 어려운 숙제를 안겼다는 생각이 든다.


넷플릭스에 올라와있는 또 다른 금융 다큐멘터리 차이나 허슬에서도 공매도를 다룬다. 정확히는 엉터리 중국 기업을 상장시켜 이익을 취하는 사람들과 이들의 사기 행각을 쫓는 숏 셀러들이 등장한다. 두 다큐멘터리는 성공적인 공매도 사례를 보여주고 있다. 밸리언트의 숏 셀러들이나 차이나 허슬의 숏 셀러들에게서 흥미로웠던 점은 숏 셀러가 행동하는 근거였다. 파미 콰디르가 지적한 것처럼 사람들은 주식이 오를 것이라고만 믿는다. 그래서 숏 셀러는 독자적으로 정보를 찾아야한다고 이야기한다. 숏 셀러들은 이런 맥락에서 타겟 기업이 확실하게 문제가 있다는 사실을 확인하고 움직인다. 단지 그것이 분명하다고 하더라도 버블이 붕괴다는 시점은 알 수 없기 때문에 손실을 각오해야겠지만, 그럼에도 불구하고 확실한 것은 사실을 기반으로 움직인다는 점이다. 적어도 다큐멘터리에 등장한 숏 셀러들은 그렇다. 막연한 기대로 주식을 사기는 쉽지만, 수익구조가 비대칭적이라 공매도하기는 쉽지 않다.5 어떤 면에서 이러한 행동 양식은, 가치투자가보다 더 가치투자가다운 면모를 드러낸다. 주가는 충분한 시간이 주어진다면 기업의 가치를 비교적 정확히 반영한다.


  1. 2화는 미국의 고금리 대출, 5화는 캐나다의 메이플 시럼 도난 사건을 다룬다. 
  2. Valeant, Distancing Itself From Its Past, Will Change Its Name to Bausch Health, The New York Times, 2018-05-08 
  3. 밸리언트가 인스한 회사 중에는 바슈&롬(Bausch&Lomb)도 있다. 
  4. 폭스바겐은 어떻게 중국 대륙을 장악했을까?, 꿈꾸는 섬 
  5. 대수의 법칙이 필요하겠지만, 시장 전체로 봤을 때도 ‘떨어진다’보다는 ‘오른다’에 거는 쪽이 훨신 더 유리한 게임이다. 

후잉은 복식부기 가계부이자 자산 관리 도구이다

가계부와 금전출납부와 단식부기는 실질적으로 동의어이다. 이러한 기록방식은 현금 흐름이 발생하는 사건을 기록하는 데 충실하다. 현금 흐름이 발생하는 사건들을 기록한다. 기록이 쌓이면 어떤 사건에서 돈이 들어오고, 어떤 사건들에서 주로 지출이 발생하는 지 알 수 있다. 그래서 가계부는 절약의 상징과 같은 존재로 여겨진다. 계획적인 소비와 절약의 관점에서 가계부는 유용하다.

하지만 거기까지이다. 단식부기 가계부는 자산을 관리하는 데는 별로 유용하지 않다. 단식부기 가계부로 표현하기 어려운 상황은 열 손가락으로 세기 부족할 만큼 많다. 돈이란 더하고 뺄 수 있기 때문에 섞이기 쉽다. 하지만 섞이기 쉽다고, 본질적으로 모든 돈이 같은 돈은 아니다.

예를 들어 우리은행 통장에 1,000만원이 있다고 해보자. 여기서 500만원은 저축을 해서 모은 돈이고, 500만원은 은행에서 대출 받은 돈이다. 하지만 은행 잔고는 1,000만원이다. 단식부기에는 계정 개념이 없거나 제한적이라서 서로 다른 성격의 돈을 구별해내는 게 어렵다. 은행 대출이라고 옆에 기록해둘 수는 있다. 하지만 잔고를 계산할 때는 자산과 부채가 항상 섞여있다.

복식부기라는 이름은 대변과 차변으로 이루어진 기록 방식에서 유래하지만, 이러한 기록 방식의 바탕에는 계정이라는 개념이 있다. 자산만 놓고 보자면 계정을 돈을 담는 주머니라고 이해할 수 있다. 예를 들어 국민은행 계좌와 우리은행 계좌를 별도의 계정으로 정의할 수 있다. 후잉을 사용한다면 이런 접근이 낯설지 않을 것이다. 따라서 전체 잔고가 아닌 계좌별 잔고를 관리할 수 있다. 이 뿐만이 아니다. 계정을 사용하면 서로 다른 성격의 돈을 별도 계정에 기록할 수 있다. 우리은행 대출(부채) 계정을 만들고 500만원을 담을 수 있다. 부채의 증가는 대변에 기록된다. 이에 대응하는 자산의 증가는 차변에 기록한다. 우리은행 계좌에 500만원이 늘어나서 결과적으로 1,000만원이 된다.

후잉의 첫 페이지

후잉의 첫 페이지

결과적으로 계좌에 1,000만원이 있다는 사실은 다르지 않다. 하지만 계좌에 1,000만원이 있다는 사실과 부채 계정에 500만원이 있다는 사실이 명백히 분리되어 기록되어있다. 그리고 순수한 내 돈(자본)은 자산에서 부채를 뺀 500만원이 된다는 것도 쉽게 파악할 수 있다. 그렇다면 자산은 다 같은 자산이고, 부채는 다 같은 부채인가? 그렇지 않다. 앞서 계좌 별로 자산 계정을 나누는 접근에 대해서 살짝 언급했지만, 기업 회계 계정 과목을 보면 계좌가 아닌 돈의 성격으로 계정을 나눈다는 것을 알 수 있다. 단식부기 세계에서는 현금 잔고가 전부였지만 복식부기 세계에서 현금은 자산의 한 가지 유형일 뿐이다. 당좌예금, 유가증권, 외상매출금, 어음, 미수금, 상품, 원재료, 토지, 건물, 비품, 영업권, 개발비 등 다양한 자산 계정들이 있다.1

계정들은 모두 돈의 단위로 계산되고 더하고 빼는 것이 가능하다. 하지만 애써 계정을 나누는 이유는 돈이 모두 같은 돈이 아니기 때문이다. 이렇게 생각하면 기업의 재무상태표(대차대조표)를 이해하는 것도 어렵지 않다. 재무상태표는 특정 시점에 어떤 기업의 모든 계정들의 잔고를 보여주는 표이다. 복식부기는 사건을 기록하는 (단식부기와는) 다른 접근 방법이기도 하지만, 그 결과를 종합해서 보면 그게 곧 재무상태표인 것이다. 즉, 이를 통해 그 기업의 자산과 부채 현황을 한 눈에 볼 수 있다.2

삼성전자의 제 48기(2017년) 요약 재무상태표

삼성전자의 제 48기(2017년) 요약 재무상태표

후잉은 복식부기 가계부다. 나는 후잉이 가계부라는 사실보다 복식부기 도구라는 게 훨씬 더 중요하다고 생각한다. 후잉에 기록한 사건들의 기록은 근거가 되고, 그 결과는 재무상태표가 된다. 사건을 기록하는 것도 중요하지만, 사건들을 기록한 결과가 가계의 재산 현황을 한 눈에 보여주는 가계 재무상태표가 된다는 사실이 훨씬 더 중요하다.

자신의 정확한 재산은 얼마나 될까? 은행도, 경찰도, 심지어 국가도 개인의 정확한 재산은 모른다. 심지어 자기 자신조차 그렇다. 대부분의 사람들은 자신의 자산이 얼마나 되는지 대충은 알고 있지만 정확히 알고 있지 않다. 나는 복식부기로 가계부를 쓰는 사람들3 외에는 자신의 자산 규모를 정확하게 파악하고 있는 사람들이 없다고 생각한다. 정확하다는 표현은 대충 알고 있는 것과 실제 재무재표를 작성해본 다음에 알게 되는 크기의 차이를 이야기하는 것이다. 나는 후잉을 쓰고 처음으로 내 자산의 크기를 알았고 그 차이는 상당했다. 한 지인은 후잉으로 자산 규모를 파악하고 처음으로 구체적인 부채 상환 계획을 세웠다고 이야기했다.

후잉의 재무상태표

후잉의 재무상태표. 기업의 재무상태표와 크게 다르지 않다.

바로 이러한 점에서 후잉은 가계부라기보다 자산 관리 도구이다.


한 걸음 더 나아가, 후잉을 완전히 자산 관리 도구로만 생각해볼 수도 있다. 자산 관리라는 관점에서 수입이나 지출이 발생한 사건 하나하나를 기록하는 것은 번거로운 일이다. 굳이 수입, 지출을 하나하나 기록해야만 복식부기의 가치를 온전히 누릴 수 있을까? 꼭 그렇지만은 않다. 개인에게 필요한 모든 계정 항목을 만들고, 한 달에 한 번씩 모든 계정의 잔고만 업데이트해주는 전략도 생각해볼 수 있다. 여전히 재무상태표의 역할은 충실하다. 현재의 자산을 정확히 파악할 수 있고, 자산 변동 사항도 파악할 수 있다. 문제가 있다면 거기서부터 사건들을 역추적해나가는 것도 방법이다.


  1. 물론 후잉에서는 이런 계정들로 기록하지 않는다. 하지만 본질은 같다. 
  2. 단식부기를 평생 써도 재무상태표는 만들어지지 않는다. 자산 관리라는 관점에서 단식부기는 빨리 버리면 빨리 버릴수록 유익하다. 
  3. 바꿔말해 후잉을 사용하는 사람들 

스크리브너(Scrivener)와 긴 글 쓰기

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

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

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

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

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

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


  1. 그나마 최근에 iOS 앱이 출시되었지만, 이 역시도 썩 만족스럽지 않았다. 
  2. 스크리브너의 더 많은 기능이 궁금하다면 스크리브너 튜토리얼을 추천한다. 
  3. 리치 텍스트 에디터지만 주로 아스키닥(Asciidoc)으로 문서를 작성한다. 텍스트 에디터와 달리 문법 하이라이팅 같은 건 지원하지 않는다. 불완전하지만 내가 직접 필요한 부분에 직접 서식을 입힌다. 

베어(Bear): 이미지를 처음 이미지로 보여준 마크다운 에디터

마크다운은 플레인 텍스트로 작성할 수 있도록 설계된 경량 마크업 언어이다. 마크다운은 플레인 텍스트 포맷이기 때문에 이미지를 직접 처리할 수 없다. 그 대신에 URL을 사용해 로컬이나 네트워크 상의 이미지를 참조할 수 있다. 여기서 참조라는 표현이 중요하다. 실제로 그곳에 이미지가 있는 지 없는 지는 마크다운 문서에서 관여하지 않는다. 있으면 좋지만, 없으면 그것대로 어쩔 수 없다. 지금은 이미지가 잘 나오더라도, 미래에도 잘 나올 것이라고 보장할 수는 없다. 마크다운과 같은 경량 마크업 언어에서 이미지를 다루는 일은 오래된 골칫거리였다.

원래 플레인 텍스트를 편집하기 위해서 만들어졌던 텍스트 에디터들은 이 문제에 큰 관심을 두지 않았다. 이러한 텍스트 에디터들은 본래 미디어를 다루기 위해서 만들어진 애플리케이션이 아니다. 주로 프로그래밍 언어로 작성되는 소스 코드를 편집하기 위한 도구였고 이미지를 다루는 기능 자체가 필요 없었다. 이미지에 처리는 마크다운이 성공적으로 자리 잡으면서 중요한 문제로 떠오르게 된다.

이에 대한 가장 간단한 해결책은 에디터와 프리뷰를 2컬럼 레이아웃으로 나눠서 프리뷰를 보여주는 방식이다. 마크다운을 직접 HTML 문서로 변환하는 대신에 라이브 프리뷰를 통해서 문서 편집과 동시에 렌더링 결과를 확인할 수 있는 장점이 있었다. 참조된 이미지를 출력하는 기능은 자동적으로 구현되었다. 하지만 라이브 프리뷰는 근본적인 한계가 있다.

이에 대한 또 다른 접근은 에디터 상에서 참조한 이미지를 직접 보여주는 방식이다. 이 방식은 많은 에디터가 지원하지는 않았던 걸로 기억한다. 마크다운을 편집하는 에디터는 주로 플레인 텍스트 에디터로 만들어졌고, 플레인 텍스트에서 이미지라는 문자가 아닌 요소를 직접 다루는 일은 이질적이었기 때문이다. 타이포라(Typora)엠웹(MWeb)이 이 방식을 사용한다.

타이포라는 참조한 이미지를 에디터에서 직접 보여준다.

타이포라는 참조한 이미지를 에디터에서 직접 보여준다.

위의 두 방식은 이미지가 어딘가에 존재한다는 마크다운의 가정을 그대로 따른다. 이미지는 참조하기 전에 먼저 존재해야하면 확정된 URL을 가지고 있어야한다. 따라서 이미지를 저장하는 방식은 여전히 그대로였다.

이와 조금 다른 방식을 취하고 있는 노트 애플리케이션이 율리시스와 베어였다. 율리시스는 에디터 위에서 직접 이미지를 보여주지는 않지만 (img)로 정의하는 특별한 객체로 다뤄진다. 사용자는 (img) 이미지 객체를 먼저 생성하고 이 객체에 외부 이미지를 참조하거나 이미지를 지정할 수 있다. 참조 방식은 이전 방식 그대로지만, 로컬의 이미지를 지정하면 이 이미지는 노트에 저장된다. 율리시스는 하이브리드 에디터였고, 이미지가 저장되는 (가상의) 공간이 존재하기 때문에 좀 더 과감한 접근도 가능하다. 이미지의 바이너리 데이터를 직접 에디터 붙여넣기 하면 (img) 객체로 만들어져서 문서에 포함된다.1 드래그앤드롭으로 이미지를 첨부할 수도 있다. 단순히 URL을 참조하는 게 아니라 문자 그대로 이미지가 문서에 포함 된다. 율리시스에서는 텍스트와 이미지가 항상 함께 움직인다. 이 방식의 장점은 노트가 남아있다면 이미지 영원히 함께 남아있다는 점이다.

율리시스에서는 이미지를 이미지는 아니지만 특별한 객체로 취급한다.

율리시스에서는 이미지를 이미지는 아니지만 특별한 객체로 취급한다.

베어에서는 한 발 더 나아간다. 표현에서도 이미지 처리 방식에서도 율리시스보다 더 나아졌다.2 베어는 이미지를 그냥 에디터 상에서 보여준다. 이미지 처리 방식은 기존 마크다운의 방식과는 완전히 다르다. 베어는 마크다운의 이미지 참조 문법을 아예 지원하지 않는다. 문서 상에 마크다운 이미지 참조 문법을 사용하는 것은 자유지만, 베어에서는 이 문법을 무시한다. 베어는 오직 이미지 첨부만 지원한다. 율리시스는 여전히 이미지 참조를 지원하기 때문에 이미지가 깨질 가능성이 존재한다. 하지만 베어에서는 이미지 첨부만 지원하기 때문에 그럴 가능성 자체가 없다. 율리시스와 마찬가지로 이미지를 바이너리 데이터로 처리할 수 있기 때문에 직접 복사하거나 드래그앤드롭으로 첨부할 수도 있다. 플레인 텍스트에서 문자가 네이티브한 요소인 거처럼, 베어에서는 이미지도 네이티브한 요소이다.

베어에서 이미지는 이미지 객체로 보여지고, 텍스트와 함께 텍스트번들(Textbundle) 형식으로 저장된다.

베어에서 이미지는 이미지 객체로 보여지고, 텍스트와 함께 텍스트번들(Textbundle) 형식으로 저장된다.

이전에도 얘기했지만 율리시스나 베어는 플레인 텍스트 에디터의 궤적을 쫓아 발전하는 도구라기보다는, 노트 애플리케이션을 설계하면서 플레인 텍스트의 훌륭한 편집 경험을 빌려온 도구라고 평가하는 것이 더 정확할 것이다. 그렇기 때문에 다른 마크다운 에디터와는 다른 방향으로 발전할 수 있었다. 특히 베어는 플레인 텍스트 세계에서 언제나 무시 당해온 이미지를 처음으로 제대로 대우해준 노트 애플리케이션(텍스트 에디터)이다. 🐻


  1. 율리시스는 이것을 가능하게 하기 위해서 텍스트번들(TextBundle)이라는 간단하고 특별한 포맷을 만들었다. 
  2. 이 글은 2017년 9월에 처음 작성되었다. 율리시스도 2017년 10월에 출시된 버전 12(37233)부터 에디터 상에서 이미지 프리뷰를 지원한다. 

블로그nacyot이 운영합니다.