141: tweet overflow

개인 위키의 꿈: 베어(Bear) 8개월 사용기

베어를 사용하기 시작하기 시작한 건 비교적 우연이었다. 2017년 초 어느 스터디 모임에서 다른 분이 사용하는 모습을 보았고 깔끔한 에디터에 반했다. 하지만 거기까지였다. 마크다운을 지원하지만 이미 율리시스(Ulysses)MWeb을 잘 사용하고 있었기에 큰 매력을 느끼진 못 했다. 그러다가 노트 애플리케이션 이야기를 하면서 베어 이야기가 한 번 나왔다. 누군가 베어를 잘 아는 사람이 있던 것은 아니었지만, 이야기를 나누면서 베어를 한 번 제대로 써봐야겠다는 생각이 들었다. 그 시작이 이제 8개월 전이다.1 (아이러니컬하게도 이 글은 율리시스에서 작성하고 있지만) 이제 다른 노트 애플리케이션은 거의 사용하지 않고, 글을 쓰는 대부분의 시간을 베어와 함께 보낸다.

에버노트의 초기 모습.  클라우드 싱크 기능은 없었고, 오직 데이터베이스로서의 노트 애플리케이션의 본질에 충실했다.

에버노트의 초기 모습. 클라우드 싱크 기능은 없었고, 오직 데이터베이스로서의 노트 애플리케이션의 본질에 충실했다.

나는 노트 애플리케이션의 팬이다. 클라우드도 지원하지 않은 시절부터 에버노트를 사용해왔다. 에버노트는 나를 제목없음.txt로부터 해방시켜주었다. 노트 애플리케이션은 파일 시스템에 의존하는 대신 노트들을 데이터베이스에 저장한다. 클라우드의 도래와 함께 이러한 노트들은 자연스럽게 다수의 기기들에서 공유된다. 하지만 여전히 한계는 있다. 노트 애플리케이션에서 기록들은 산만하게 부유한다. 노트 애플리케이션을 잘 써서 이미 수백 수천 개의 노트가 쌓여있는 사람이라면 이 문제에 공감할 것이다. 특히 시간이 지남에 따라 오래된 노트들은 자연스럽게 잊혀지게 된다. 검색과 태그라는 강력한 도구가 있지만, 이것만으로는 이 많은 노트들을 정리하는 것이 버겁게 느껴질 뿐이다.

그래서 정보를 조직한다는 관점에서 노트 애플리케이션보다 위키위키를 선호한다. 협업을 통한 글쓰기에 있어서 위키위키는 독보적인 위치를 차지하고 있다. 위키위키에는 협업 못지 않게 중요한 특징이 있다. 위키위키의 문서는 주제 별로 작성된다. 주제 별로 작성되는 문서들이 쌓여나가고 사용자는 [[Document]]와 비슷한 문법을 사용해서 문서에서 문서로 가는 구멍을 만든다. 위키의 문법은 인터넷 상의 하이퍼링크보다 민첩하고, 긴밀하게 위키위키 내부의 문서들을 조직할 수 있게 도와준다. 위키위키의 문서들은 시간의 흐름에 전혀 게의치 않는다. 위키위키에서 협업을 지운 개인위키는 여전히 매력적인 도구이다.

노트 애플리케이션은 편리하지만 정보를 조직하기엔 부족함이 있고, 위키위키는 정보를 조직하기엔 매력적이지만 불편하다. 개인위키로 쓸만한 도구는 많지않다. 대부분은 웹 기반이었고, 사용자 경험에서 노트 애플리케이션처럼 매력적이지 않다. 10년 전쯤엔 위키를 사용했지만, 노트 애플리케이션들이 자리를 잡으면서 개인 위키를 포기한지도 10년이 되었다. 하지만 나에게 노트 애플리케이션이란 늘 개인위키의 불완전한 대안일 뿐이었다.

이제 베어가 등장할 시간이다. 베어는 여느 노트 애플리케이션과 다른 기능을 하나 가지고 있다. [[Link]] 문법을 사용해서 다른 노트에 링크를 걸 수 있다. 위키위키의 그 문법이다. 베어는 개인위키로 기획된 애플리케이션은 아니지만, 이 기능 하나만으로 가뭄에 단비 같은 노트 애플리케이션이 되어주었다. 나는 베어를 개인위키로 사용하고 있다. 모든 문서는 주제 별로 작성되고, 문서들은 링크를 통해 느슨하게 연결되어있다. 베어는 이제 내 지식을 저장하고, 외부의 정보를 스크랩하고, 글도 쓰는 하이브리드 애플리케이션으로 자리잡아가고 있다. 8개월간 2200개의 노트를 작성했다.2 위키로서의 기능을 보완하기 위한 간단한 알프레드(Alfred) 워크플로우를 작성해서 사용하고 있다.3 이렇게 나는 다시 개인위키의 꿈을 꾸고 있다.4

그렇다고 내가 베어에 반한 것이 단순히 위키 문법을 지원하기 때문은 아니다. 베어는 겉보기에는 단순해보인다. 하지만 이는 겉멋이 없을 뿐이고, 내실은 탄탄하다. 베어를 처음 시작한다면 FAQ를 읽어보는 것을 추천한다. 의외로 다양한 기능에 깜짝 놀랄 것이다. 무엇보다도 베어의 마크다운 에디터는 독보적이다.5 프리뷰 없이 에디터가 그 자체로 프리뷰와 거의 동일하다는 점에서 베어는 율리시스의 계보를 잇는다.6 문서 작성은 플레인 텍스트 에디터와 다르지 않지만, 에디터의 표현 능력은 리치 텍스트 에디터 뺨친다. 베어는 율리시스에서 한 걸음 더 나아간다. 베어의 에디터는 이미지를 문서에 저장할 수 있으며7 에디터 상에서 보여준다.8 플레인 텍스트와 리치 텍스트 사이에서 사용자들은 이미지의 화면 출력 여부에 대해서 선택권이 없었다. 그래서 많은 마크다운 에디터들이 마크다운을 HTML로 렌더링한 결과를 다시 프리뷰로 보여주는 방식을 사용했지만, 나는 이 방식을 진심으로 싫어한다.9

베어가 완벽한 것은 아니지만, 율리시스에 충분히 매력을 느꼈던 입장에서, 위키 기능까지 겸비한 베어는 사용하지 않을 이유가 없는 노트 애플리케이션이었다.

  1. 이 글은 2017년 10월에 작성했다.
  2. 베어의 또 다른 장점 중 하나는 이 정도 규모에서도 느려지지 않는다는 점이다. Devonthink나 Papers3 등 데이터에 비례해서 느려지는 데스크탑 앱들은 시간이 지남에 따라 사용하기 어려워진다.
  3. 아직 내가 만든 워크플로우는 공개하지 않았지만, 비슷한 워크플로우들을 이미 다른 사람들이 오픈소스로 만들고 있다. 관심이 있다면, chrisbro/alfred-bear 를 사용해보길.
  4. 사실 베어에서 핵심적으로 내세우는 문서 조직 기능은 내부 링크가 아니다. 베어는 디렉터리 분류를 지원하지 않고 문서 태그를 지원하는데, 이 방식도 독특하다. 트윗처럼 본문 내부의 원하는 위치에 태깅(#태그)을 할 수 있다.
  5. 엄밀한 의미에서 율리시스도 베어도 마크다운 에디터는 아니다. 마크다운과 거의 비슷한 문법을 지원한다. 대신 마크다운 출력과 Copy as Markdown 기능을 지원한다.
  6. 나는 율리시스와 베어가 플레인 텍스트 에디터의 새로운 패러다임을 보여줬다고 생각한다.
  7. 일반적인 플레인 텍스트 에디터는 이미지를 저장하는 기능일 지원하지 않는다. 율리시스가 처음으로 Textbundle이라는 포맷을 통해서 이미지와 플레인 텍스트가 결합된 포맷을 지원했으며, 베어는 이 방식을 따르고 있다.
  8. 율리시스도 2017년 10월에 출시된 버전 12(37233)부터 에디터 상에서 이미지 프리뷰를 지원한다.
  9. 내가 이 방식을 원래부터 싫어했는 지는 잘 모르겠다. 적어도 율리시스나 베어를 사용해본 지금은 그렇다.
, nacyot.

블로그nacyot이 운영합니다.