개발자나 지식 노동자라면 한 번쯤 겪어본 풍경일 것이다. 오래 쓰던 메모 도구에 문득 싫증이 나고, 모든 것을 새 앱으로 옮기고 싶어진다. 블로거 잭 배티(Jack Baty)가 쓴 글은 바로 그 충동과 그 끝에 벌어지는 일을 솔직하게 기록한 개인적 회고다. 그는 이 상태를 "Emacs 피로감(Emacs Fatigue)"이라 부르며, 이것이 "텍스트 파일 피로감"과 맞닿아 있다고 설명한다. 특정 도구를 쓰다 보면 그 도구로 모든 일을 처리하게 되고, 결국 매일 같은 화면을 마주하는 데 지쳐 버린다는 것이다.
이번에 그가 선택한 대안은 메모 앱 베어(Bear)였다. 그는 베어를 견고하고 아름다우며 단순한 도구라고 평가한다. macOS와 iOS에서 돌아가고, 동기화가 무료로 깔끔하게 되며, 가격도 저렴하다. 내부적으로 SQLite 데이터베이스를 쓴다는 점도 그에게는 문제가 아니었다. 오히려 그는 "데이터베이스가 위험하지 않냐"는 식의 흔한 우려를 대체로 근거 없는 소문에 가깝다고 보고, 데이터베이스는 이런 작업에 원래 강하다고 말한다.
문제는 데이터베이스가 아니라 '앱 안에 갇힌 느낌'
그를 불편하게 만든 것은 기술적 저장 방식이 아니었다. 메모가 "앱 안에 들어가 있다"는 느낌, 그리고 그 앱이 있어야만 메모에 접근할 수 있다는 종속감이었다. 흥미롭게도 이것은 그가 Emacs에 대해 느끼기 시작한 감정과 같은 것이었다. 다만 Emacs의 경우 그 종속감의 원인은 대체로 Org mode였다고 그는 짚는다. 결국 그의 불만은 특정 포맷이나 저장소가 아니라, 하나의 폐쇄된 환경이 자신의 데이터를 붙잡아 두는 구조 자체였던 셈이다.
여기에 더해 베어는 macOS와 iOS 전용이라는 한계가 있었다. macOS에 정착하기로 "결정"한 그에게 원칙적으로는 문제가 없어야 했지만, 리눅스에 대한 미련이 머릿속에서 낮게 윙윙거리는 소리처럼 사라지지 않았다고 그는 털어놓는다. 플랫폼 선택이 곧 데이터 이동성의 제약으로 이어진다는 점은, 특정 OS 전용 앱을 쓸 때 늘 따라붙는 현실적인 문제이기도 하다.
결국 다시 Emacs, 그러나 포맷은 바꿔서
그가 찾은 출구는 Denote였다. Org mode 파일에 메모를 두고 싶지는 않지만 여전히 Emacs에 끌린다면, 선택지는 Denote라는 것이다. 사실 그의 메모는 처음부터 Denote에서 시작했는데, 당시에는 .org 형식이었다. 그는 Denote가 마크다운 파일도 기본적으로 다룰 수 있다는 사실을 거의 잊고 있었다. 설정 한 줄을 바꾸자 그는 자신이 "있어야 할 자리"로 돌아왔다. 베어의 메모가 이미 마크다운이었던 덕분에, 내보내기 한 번과 파일명·링크·첨부파일을 정리하는 변환 스크립트만으로 이전이 끝났다. 그 스크립트는 Claude Code의 도움을 받아 작성했다고 그는 덧붙인다.
이 대목은 한국 실무자에게도 시사하는 바가 있다. 핵심은 데이터를 마크다운 같은 개방형 텍스트 포맷으로 유지해 두면, 앱 사이를 오가는 비용이 극적으로 줄어든다는 점이다. 포맷이 개방적이면 "떠날 자유"가 보장되고, 역설적으로 그 자유가 있을 때 한 도구에 머무르는 결정도 더 편안해진다. 베어에서 Denote로의 이동이 비교적 수월했던 것도 양쪽 모두 마크다운을 쓴 덕분이었다.
도구 교체가 아니라 습관의 문제
배티는 자신이 Emacs를 그만뒀다가 결국 슬그머니 기어들어 오는 그 패턴을 또 반복했다고 자조한다. 더 나은 판단을 알면서도 그 앎이 충동을 막아 주지는 않는다는 것이다. 그가 마지막으로 꺼낸 아이디어는 Denote와 베어 사이를 잇는 동기화 혹은 브리지를 만들어 보는 것인데, 이는 구현된 결과가 아니라 가능성 수준의 구상으로 남아 있다.
이 글은 특정 도구의 우월함을 주장하는 리뷰가 아니다. 오히려 "완벽한 메모 앱을 찾아 떠도는 일" 자체가 많은 경우 생산성 향상이 아니라 일종의 회피이자 반복되는 습관임을 드러낸다. 도구를 바꾸면 신선함은 얻지만 축적된 메모의 맥락과 손에 익은 흐름은 매번 흔들린다. 교훈이 있다면, 어떤 앱을 쓰느냐보다 데이터를 열린 포맷으로 보관해 이동의 자유를 확보하고, 도구 교체 충동이 들 때 그것이 실제 필요인지 단순한 피로감인지 구분하는 태도일 것이다.