왜 또 다른 Markdown 앱을 만들까
개발 문서를 작성할 때 링크 하나, 아키텍처를 설명할 이미지 하나가 필요해도 보통은 에디터를 떠난다. 브라우저에서 검색하고, 결과를 고르고, URL이나 이미지를 복사한 뒤 다시 문서로 돌아와 Markdown 문법으로 정리한다.
한 번은 사소하지만 문서 한 편을 쓰는 동안 여러 번 반복된다. Dock은 브라우저를 대체하려는 제품이 아니다. 로컬 Markdown 문서를 쓰는 흐름 안으로 검색과 삽입을 가져와 컨텍스트 스위칭을 줄이는 Developer Workspace를 만들려는 실험이다.
MVP에서 검증할 핵심 흐름은 두 가지다.
- 로컬 폴더를 선택하고 Markdown 문서를 안전하게 열고, 편집하고, 저장한다.
/link,/image명령으로 결과를 검색하고 사용자가 고른 항목만 Markdown에 삽입한다.
따라서 단순히 Electron 창을 띄우는 것만으로는 MVP가 아니다. 문서의 원본 소유권, 파일 시스템 안전성, 검색 결과의 신뢰성, 테스트 가능한 흐름까지 함께 증명해야 한다.
첫 선택: Electron Forge + TypeScript + Vite
처음에는 Electron Forge의 Vite + TypeScript 템플릿으로 시작했다. Dock은 로컬 파일, 창 수명 주기, 향후 OS 연동이 필요하면서도 React 기반 편집기 생태계를 활용해야 했다. 그래서 데스크톱은 Electron, UI는 React, 언어는 TypeScript, 번들러는 Vite, 패키징은 Electron Forge로 정했다.
이 선택은 ‘가장 가벼운 앱’을 만들기 위한 것이 아니라, 현재의 목표를 가장 빨리 안전하게 검증하기 위한 선택이다. 비용도 분명하다. Electron은 프로세스 경계와 IPC를 다뤄야 하고, 앱 크기와 플랫폼별 패키징도 고려해야 한다.
pnpm 생성 오류에서 npm을 선택한 이유
처음 pnpm create electron-app을 시도했을 때 Electron Forge 하위 의존성의 Git 기반 의존성이 pnpm의 blockExoticSubdeps 정책과 충돌했다. 이 프로젝트에서 패키지 관리자 문제를 푸는 일은 제품 가치를 증명하는 일이 아니었다.
그래서 프로젝트는 npm으로 통일했다.
- npm workspaces 사용
- 저장소 루트의
package-lock.json하나만 유지 - CI와 깨끗한 재설치는
npm ci사용 - pnpm의 공급망 보안 옵션을 전역으로 낮추지 않음
이 결정은 프로젝트의 의사결정 기록으로 남겼다. 도구 선택의 핵심은 선호가 아니라 재현 가능한 설치와 검증이다.
기존 글에서 바로잡을 점
기존 글에는 생성 과정에서 .git 디렉터리를 삭제하라는 문장이 있었다. 이는 현재 기준에서 따르면 안 되는 안내다. Git 저장소에는 사용자의 작업과 복구 기준점이 있으므로, 문제를 해결하려고 .git을 지우거나 프로젝트를 다시 초기화하지 않는다.
대신 다음 순서를 따른다.
Get-Location
git status --short
npm ci예상하지 못한 파일이나 설치 오류가 보이면 삭제하기 전에 원인과 영향을 먼저 확인한다. 이 원칙은 단순한 주의사항이 아니라, 실제 작업을 안전하게 되돌릴 수 있게 하는 기반이다.
다음 글에서 다룰 것
템플릿을 만들었다고 구조가 끝난 것은 아니었다. 다음 글에서는 왜 Electron 앱을 저장소 루트에 계속 두지 않고 apps/desktop으로 옮겼는지, 그리고 이 이동을 React 도입이나 의존성 업그레이드와 섞지 않은 이유를 정리한다.
참고
