옵시디언 대안 노리는 오픈소스 노트 앱, Files.md

• Files.md는 ‘또 하나의 노트 앱’이긴 한데, 방향이 꽤 선명함 — Obsidian류의 복잡한 PKM 시스템보다 plain .md 파일과 로컬 소유권에 올인하는 쪽임

  • 노트, 문서, 프로젝트, 저널, 습관, 체크리스트, 태스크를 전부 Markdown 파일로 저장함
  • 기본값은 local-first라 파일이 기기 밖으로 나가지 않음
  • 작성자는 이 프로젝트를 5년 동안 만들었다고 밝힘

• 설치 경험도 일부러 단순하게 잡았음

  • 브라우저에서 app.files.md를 열고 Chrome 기준 주소창의 설치 버튼을 누르면 됨
  • 변경사항을 영구 저장하려면 로컬 폴더를 열어 연결하는 방식
  • 업데이트가 필요하면 가끔 강제 새로고침을 하라고 안내함

• 동기화 옵션은 꽤 현실적으로 나뉘어 있음

  • 완전 로컬 모드는 기기 안의 폴더에만 저장되고 서버가 필요 없음
  • iCloud, Dropbox, Google Drive 같은 클라우드 폴더를 쓰면 별도 서버 없이 여러 기기에서 동기화 가능함
  • 셀프호스팅은 Go 바이너리 하나로 서버를 띄우는 구조
  • 관리형 서버는 api.files.md를 통해 바로 써보는 선택지로 제공됨

• 흥미로운 건 LLM 친화성을 제품 기능이 아니라 구조 철학으로 밀고 있다는 점임

  • 코드베이스가 한 사람이나 LLM이 머릿속에 넣을 수 있을 정도로 단순해야 한다고 말함
  • 빌드 시스템 없이 web/index.html을 여는 방식으로도 돌아가게 하려는 목표가 있음
  • 파일 구조는 Chat.md, journal/YYYY.MM Month.md, Later.md, habits/*.md, media/*, config.json처럼 명확하게 정해져 있음
  • 이 구조를 CLAUDE.md나 AGENTS.md에 넣으면 AI 에이전트가 파일 체계를 이해할 수 있다고 설명함

• Telegram 봇을 ‘쓰기 전용 입구’처럼 쓰는 흐름도 있음

  • 이동 중에 생각, 할 일, 저널 기록, 체크리스트 항목을 메시지로 던져 넣을 수 있음
  • 나중에 앱에서 “저널로”, “나중에”, “체크리스트로” 같은 식으로 정리하는 방식
  • 작성자는 회의 중 머릿속 부담을 줄이기 위해 모든 입력을 일단 Chat.md에 쌓는 방향으로 바꿨다고 함

• 생산성 도구에 대한 태도는 은근히 까칠함

  • 고급 템플릿, 플러그인, AI 워크플로가 지식 관리를 해주는 것처럼 보이지만 실제 사고를 대신하진 못한다고 봄
  • “Second Brain”이 커질수록 생각을 미래의 나에게 미루는 문제가 생긴다는 관점임
  • 그래서 파일 하나에 아이디어 하나, 맥락 없이도 이해 가능한 노트, 관련 노트 링크, 재방문과 사고를 강조함

• 개발 쪽 디테일도 꽤 많이 공개돼 있음

  • 서버는 Go 기반이고, cmd/server, server/sync, server/bot.go, tests 같은 구조를 가짐
  • 의존성은 가능하면 피하고, 필요한 의존성도 repo 안에 vendoring해서 자기완결성을 유지하려고 함
  • Markdown 링크를 표준 문법으로 되돌린 이유도 GitHub 같은 외부 환경과의 호환성을 위해서임
  • WASM은 복잡도와 8MB 크기 때문에 제거하고 JS 구현으로 돌아섰다고 설명함

• 성능 감각도 재밌음 — “파일이나 mutex 때문에 느릴까 봐 겁먹지 말라”는 식임

  • mutex lock/unlock은 약 25ns
  • SSD에서 4KB 랜덤 읽기는 약 150,000ns
  • 1ms는 1,000,000ns라서, 실제 병목을 착각하지 말자는 메시지에 가까움

---

기술 맥락

• 이 프로젝트가 Markdown 파일을 고집하는 이유는 단순한 취향이 아니에요. 노트 앱이 망하거나 서비스가 닫혀도 사용자의 지식 베이스가 plain text로 남아야 한다는 판단이 깔려 있거든요.

• local-first를 기본값으로 둔 것도 같은 맥락이에요. 서버 DB를 먼저 설계하면 동기화와 계정 기능은 편해지지만, 데이터 소유권과 장기 보존성은 약해져요. Files.md는 그 트레이드오프에서 사용자의 파일을 우선한 셈이에요.

• 빌드 시스템을 피하고 web/index.html 중심으로 가려는 선택은 개발자 입장에선 꽤 과감해요. 최신 프론트엔드 생태계의 편의성을 일부 포기하는 대신, 10년 뒤에도 열릴 가능성과 LLM이 이해하기 쉬운 작은 코드베이스를 얻으려는 거예요.

• 동기화도 하나의 정답을 강요하지 않아요. 프라이버시가 중요하면 로컬만 쓰고, 편의성이 중요하면 클라우드 폴더나 호스팅 서버를 쓰는 식이에요. 노트 앱의 핵심이 서버 기능이 아니라 파일 구조에 있다는 걸 보여주는 설계예요.