이번 글에서 만든 것
이번 단계에서는 Dock 화면에 실제 로컬 문서 폴더를 연결했다.
사용자는 폴더를 선택하고, Markdown 파일 목록을 확인하고, 문서를 열어 편집한 뒤 저장할 수 있다. 다만 파일 시스템을 Renderer에 직접 열어 주지는 않았다. 파일 권한은 Main 프로세스가 가지고, 화면은 필요한 기능만 좁은 API로 요청한다.
왜 폴더 경로를 그대로 넘기지 않았을까?
Renderer는 화면을 그리는 영역이다. 여기에 절대 경로와 파일 시스템 객체를 그대로 노출하면 화면 코드의 실수나 악성 입력이 곧바로 로컬 파일 접근으로 이어질 수 있다.
그래서 폴더를 선택하면 Main이 임의의 workspaceId를 만들고 실제 경로와 연결한다. Renderer는 이 ID와 notes/today.md 같은 상대 경로만 보낸다. 실제 폴더 경로는 Renderer에 전달하지 않는다.
파일 요청은 어떻게 검증할까?
요청이 Main에 도착하면 다음을 차례로 확인한다.
- 요청을 보낸 화면이 우리가 허용한 Renderer인지 확인한다.
- workspaceId가 현재 앱 실행 중 선택된 폴더인지 확인한다.
- 절대 경로, 드라이브 경로,
.., null byte를 거부한다. - 최종 경로가 workspace 밖으로 나가지 않는지 확인한다.
- symbolic link를 따라간 실제 경로도 workspace 안인지 확인한다.
- 확장자는
.md와.markdown만 허용한다.
이 검사를 통과한 뒤에만 파일을 읽거나 저장한다.
저장 중 문제가 생기면 기존 파일은 어떻게 될까?
기존 파일을 바로 덮어쓰면 저장 도중 오류가 났을 때 문서가 깨질 수 있다. 그래서 새 임시 파일에 먼저 내용을 기록하고 flush한 다음, 같은 폴더 안에서 교체한다.
이 방식은 저장에 실패해도 기존 파일을 남겨 둔다는 장점이 있다. M2에서는 외부 프로그램이 동시에 파일을 수정했는지 감지하는 기능까지 넣지 않았다. 그 문제는 충돌 표시와 복구 UX를 함께 설계하는 별도 단계로 남겼다.
화면에서 실제로 연결한 흐름
- 폴더 선택 버튼을 누른다.
- Main의 폴더 선택 dialog가 열린다.
- 선택된 폴더의 표시 이름과 Markdown 목록만 화면에 나타난다.
- 파일을 누르면 Main이 내용을 읽어 편집기에 전달한다.
- 편집 후 저장 버튼을 누르면 Main이 원자적으로 저장한다.
- 미리보기는 아직 HTML로 렌더링하지 않고 안전한 일반 텍스트로 표시한다.
검증 결과
- 경로 계약과 파일 서비스 단위 테스트
- IPC handler 계약 테스트
- TypeScript, ESLint, Prettier 검사
- Windows x64 패키징
- Playwright Electron 보안 E2E
- 패키징 산출물 기동 smoke
전체 검증을 통과한 뒤 M2 핵심 흐름을 커밋했다. 다음 단계에서는 새 문서 생성 UX, 저장 상태와 오류 안내를 다듬고, 외부 파일 변경 감지 여부를 별도 설계한다.
