완벽한 정리병에 걸려 주말 내내 노션만 꾸미다 프로젝트를 망친 이야기

솔직히 말해서, 저는 한때 '도구'에 미쳐있던 적이 있습니다. 청주에서 서울로 갓 올라와 구로의 등대라 불리는 SI 업체에서 파견직으로 일하던 시절 이야기입니다. 매일 야근에 시달리며 코드는 엉망진창으로 짜고 있으면서도, 아이러니하게 제 개인 노트북 속 세상은 누구보다 깔끔하고 싶었습니다.

그때는 왠지 좋은 도구를 쓰면 제가 더 나은 개발자가 될 것 같았습니다. 에버노트(Evernote)부터 시작해서 베어(Bear), 옵시디언(Obsidian), 그리고 노션(Notion)까지. 주말 내내 생산성 유튜브를 찾아보며 노션 템플릿을 꾸미고, 제텔카스텐(Zettelkasten) 방법론을 공부하느라 시간을 허비했습니다. 정작 월요일 아침에 배포해야 할 레거시 코드는 한 줄도 못 봤는데 말입니다.

결과는 뻔했습니다. 화려하게 꾸며놓은 노션 페이지는 정작 바쁠 때 열어보지도 못했고, 현장에서 급하게 휘갈긴 메모는 아이폰 메모장에, 기술 문서는 깃허브 리드미(README)에 파편화되어 흩어졌습니다. 데이터의 정합성이 깨진 DB처럼 제 머릿속도 엉망이 되더군요.

그때 뼈저리게 느꼈습니다. 개발자에게 진짜 필요한 건 화려한 대시보드가 아니라, '내가 일하는 곳'과 '내가 생각하는 곳'의 연결이라는 것을요.

최근 해커뉴스에서 발견한 'Stash'라는 도구를 보고 그때의 기억이 떠올랐습니다. 이 도구는 아주 투박합니다. 요즘 유행하는 화려한 SaaS도 아니고, AI가 자동으로 요약해주는 기능도 없습니다. 그저 터미널에서 Markdown 파일을 애플 메모(Apple Notes)와 동기화해주는 CLI 도구일 뿐입니다.

하지만 이 투박함이 오히려 제 마음을 움직였습니다.

개발자로서 우리는 대부분의 시간을 터미널과 코드 에디터에서 보냅니다. 문서는 Markdown으로 작성하는 게 숨 쉬는 것만큼 자연스럽죠. 반면, 지하철에서 퇴근길에 떠오른 아이디어는 애플 메모장에 적는 게 가장 빠릅니다. 이 둘 사이에는 거대한 장벽이 존재했습니다. 컴퓨터 앞에 앉아 "아, 그때 메모장에 뭐라고 적었더라?" 하며 폰을 뒤적거리는 그 멍청한 시간들 말입니다.

Stash는 이 문제를 아주 '더러운(Dirty)' 방식으로 해결합니다. 내부를 뜯어보니 AppleScript와 Shell Script, 그리고 Pandoc을 엮어서 만들었더군요. 클린 코드나 우아한 아키텍처를 따지는 분들이 보면 기겁할 수도 있습니다. AppleScript는 느리고 다루기 까다로운 구닥다리 기술이니까요. 하지만 저는 이 코드를 보며 무릎을 쳤습니다.

"이게 바로 비즈니스지."

작동 방식은 간단합니다. 터미널에서 stash push my-note.md를 입력하면 로컬의 마크다운 파일이 애플 메모로 전송됩니다. 반대로 폰에서 메모를 수정하고 stash pull my-note.md를 입력하면 로컬 파일이 업데이트됩니다. 파일 상단에 front-matter를 심어서 ID를 추적하는 방식입니다.

이 도구의 개발자도 저와 비슷한 고민을 했던 것 같습니다. 워크플로위(Workflowy), 노션, 굿노트 등 수많은 도구를 써봤지만 결국 '단순함'으로 회귀했다는 고백이 리드미(README)에 적혀 있더군요. 노트 작성의 본질은 시스템 관리가 아니라 '그냥 적는 것'이라는 말에 깊이 공감했습니다.

제가 팀원들에게 항상 하는 말이 있습니다. "우아한 쓰레기를 만들지 말고, 투박하더라도 작동하는 도구를 만들어라."

우리는 종종 수단과 목적을 혼동합니다. 완벽한 지식 관리 시스템을 구축하는 게 목적이 되어버리면, 정작 그 지식을 활용해 무언가를 만들어내는 시간은 줄어듭니다. 저처럼 주말 내내 노션 꾸미다 프로젝트 망치지 마십시오.

만약 여러분이 맥(macOS)을 사용하고 있고, 저처럼 '심플함'에 목마른 개발자라면 이 도구를 한번 써보시길 권합니다. 설치도 brew tap으로 간단하게 끝납니다. 복잡한 설정 파일도 필요 없습니다.

기술적으로 대단한 혁신은 아닙니다. 하지만 개발자의 워크플로우(Workflow)에 존재하는 아주 작은, 그러나 매일 겪는 '가시' 같은 불편함을 제거했다는 점에서 저는 이 도구에 높은 점수를 주고 싶습니다.

결국 좋은 엔지니어링이란, 문제를 가장 현실적이고 효율적인 방법으로 해결하는 것이니까요. 비록 그 방법이 AppleScript 같은 구식 기술을 덕지덕지 바르는 것이라 할지라도, 그게 내 생산성을 10%라도 올려준다면 그건 '좋은 코드'입니다.

지금 여러분의 워크플로우는 어떤가요? 도구를 관리하느라 정작 중요한 '생각'을 놓치고 있지는 않나요? 이번 주말에는 복잡한 툴을 다 내려놓고, 가장 단순한 메모장 하나만 켜두고 진짜 해야 할 고민을 적어보는 건 어떨까요.