dev-dock

Eletron으로 Desktop App을 만들고자한다.평소에 이리저리 분주하게 일하는 편이지만 요즘 들어 개발 문서를 작성하다가도 검색하고, 참고해야될 내용을 찾을때도 Chrome 브라우저를 열어 검색해서 URL 붙여넣기, 아키텍쳐 예시 이미지 검색해서 붙여넣기 등..

이 글은 2026-07-24에 게시한 기존 글을 현재 프로젝트 기준에 맞춰 보완하는 후속 원고다. 기존 글의 제목은 그대로 두되, 기술 명칭은 Electron으로 통일한다.개발 문서를 작성할 때 링크 하나, 아키텍처를 설명할 이미지 하나가 필요해도 보통은 에디터를 떠난

Electron 템플릿을 만든 뒤 가장 먼저 한 일은 화면을 예쁘게 만드는 일이 아니었다. 어떤 기능을 만들지, 어디까지를 MVP로 볼지, 보안 때문에 절대 허용하지 않을 것은 무엇인지 문서로 먼저 고정했다.Dock은 로컬 파일과 외부 검색 결과를 함께 다룬다. 이 조

초기 Electron Forge 템플릿은 저장소 루트에서 시작했다. 작게 시작할 때는 편하지만, Dock은 앞으로 문서, 자동화 스크립트, 공용 패키지, 앱 확장 가능성을 함께 관리해야 한다. 그래서 앱 하나를 실행할 수 있다는 현재 상태와, 저장소가 맞춰야 할 구조를

구조 이동이 끝난 뒤에는 곧바로 편집기를 넣지 않았다. 먼저 React를 안전하게 올릴 수 있는지, 타입 검사와 포맷 검사가 재현 가능한지 확인했다. 이 단계의 목표는 화려한 화면이 아니라 ‘이후 기능이 쌓일 바닥’을 만드는 것이었다.npm run typecheck에서

이 글은 다음 구현을 설명하는 계획 글이다. F4의 항목들은 아직 완료라고 표기하면 안 된다. 구현과 검증이 끝나면 결과와 명령을 이 글에 보완한다.React 앱 셸까지 연결됐지만, 아직 Renderer와 운영체제 권한 사이의 보안 경계는 기본 템플릿 상태다. Dock

Dock은 아직 MVP가 아니다. 현재 완료된 것은 Electron 기반 저장소 구조와 React 앱 셸, 그리고 그 다음에 기능을 안전하게 쌓기 위한 작업 순서다. 이 글은 앞으로 무엇을 어떤 순서로 만들지와, 저장소 문서와 Velog 기록을 어떻게 일치시킬지 정리한

보안 설정과 단위 테스트를 추가한 뒤에는 꼭 남는 질문이 있다.“각 조각은 맞는데, 실제 앱을 켰을 때도 Main·Preload·Renderer가 같은 규칙으로 연결될까?”Dock에서는 이 질문을 Playwright의 Electron API로 확인했다.이번 글은 기능을

개발 모드에서 창이 열리고 E2E가 통과해도, 배포용 앱이 같은 방식으로 동작한다는 보장은 없다. Dock은 Vite로 Main·Preload·Renderer를 번들링하고 Electron Forge가 ASAR 기반 package를 만든다. 이 과정에서 경로나 prelo

Dock에 파일 열기나 Markdown 편집 기능을 바로 붙일 수도 있었다. 하지만 그 전에 사용자가 어떤 흐름으로 문서를 찾고, 쓰고, 미리보고, 명령을 실행하는지를 담을 화면 구조가 필요했다. 그래서 M1에서는 권한을 추가하지 않고 Application Shell부

이번 단계에서는 Dock 화면에 실제 로컬 문서 폴더를 연결했다.사용자는 폴더를 선택하고, Markdown 파일 목록을 확인하고, 문서를 열어 편집한 뒤 저장할 수 있다. 다만 파일 시스템을 Renderer에 직접 열어 주지는 않았다. 파일 권한은 Main 프로세스가

Markdown 파일은 내 컴퓨터에서 만든 문서일 수도 있지만, 외부에서 내려받았거나 다른 사람이 공유한 파일일 수도 있다. Markdown 안의 HTML과 링크를 그대로 화면에 넣으면 문서가 실행 가능한 입력이 될 수 있다.이번 단계에서는 Markdown을 HTML로

/image 전체 로직을 한 번에 구현하지 않고, 먼저 검색 결과를 보여 주고 사용자가 선택하는 경계까지 만들었다.이미지 결과는 제목, 출처 페이지, thumbnail URL, download URL, 라이선스 정보를 가질 수 있는 계약으로 정리했다. 현재는 deter

이번 단계에서는 /image 검색 결과를 문서에 넣는 과정을 마무리했다. 검색 결과를 고르는 것과 실제 파일을 저장하는 것은 서로 다른 책임이기 때문에, Renderer에서 바로 Markdown을 만들지 않고 Main의 다운로드 과정을 거치도록 구성했다.이미지 결과를

/link 기능의 목표는 단순하다. Markdown 문서를 작성하다가 자료를 찾고, 확인한 페이지를 안전한 Markdown 링크로 넣는 것이다.하지만 “검색 결과를 가져온다”는 구현 선택은 전혀 단순하지 않았다.API key를 누가 보관할지, 검색 결과 HTML을 어디

Research View를 만든 뒤 자연스럽게 다음 질문이 나왔다.앱 안에서 Google 검색을 열었으니, DevTools Network 탭의 XHR·Fetch 응답을 한 번만 읽어 링크 카드로 보여 주면 되지 않을까?Selenium Wire를 사용해 본 적이 있다면

/link 기능은 처음부터 검색 공급자를 앱 내부 API로 고정하지 않았다. 사용자가 자료를 찾고 문서에 링크를 남기는 흐름을 안전하게 만드는 것이 목적이었다. Brave API는 사용자 key와 외부 구독 문제가 있었고, 시스템 브라우저를 여는 방식은 앱 안에서 맥락

Research View는 Main이 소유하는 별도 WebContentsView다. 코드에서 sandbox: true, nodeIntegration: false, permission 거부를 설정했다고 해도, 실제 Electron에서 원격 페이지가 어떤 권한을 갖는지까지

Dock에서 문서를 저장한다는 말은 textarea의 상태를 바꾸는 일이 아니다. 사용자가 고른 document workspace 안에서만 Main이 파일을 열고, Renderer는 좁은 IPC로 상대 경로와 내용만 전달하며, 저장 결과는 앱을 닫아도 로컬 파일로 남아

이전 TIL에서는 document workspace에서 문서를 선택하고, 생성하고, 저장한 뒤 앱을 종료했다가 다시 실행해 같은 파일을 다시 읽는 흐름을 실제 Electron IPC로 검증했다.그 다음 문제가 생겼다. Windows에서 개발하고 Windows에서 테스트

지난 포스팅에서는 Windows·macOS·Linux를 대상으로 한 CI 기준과 Windows 패키징을 점검했다. 로컬 검사가 통과했다는 사실만으로 제품 전체가 검증된 것은 아니므로, 플랫폼별 검사 범위와 실제 실행 가능한 패키지를 분리해 확인하는 과정이었다.이번에는

앞선 글에서는 Architecture Workspace에서 다음 ADR을 추가하는 흐름을 만들었다. 제목·상태·배경·결정·결과를 입력하면 Main이 다음 번호의 ADR 파일을 생성하고, README Index까지 갱신하는 기능이었다.그런데 사용 흐름을 다시 보니 아키텍

처음 만든 로컬 Markdown 편집기는 폴더를 선택하고 파일을 열어 내용을 수정하는 데 집중했다. 문서를 실제로 작성하기 시작하면 곧 다른 문제가 보인다. 파일이 많아질수록 원하는 문서를 찾기 어렵고, 문서 사이의 링크를 따라가려면 파일을 직접 열어 봐야 한다. 외부

Dock에서 폴더를 선택하면 Markdown 파일 목록을 보여주고 문서를 편집할 수 있었다. 하지만 실제 디렉터리와 앱 화면은 계속 같은 상태를 유지하지 못했다. Dock 밖에서 파일을 만들거나 삭제해도 앱에 바로 반영되지 않았고, 폴더가 여러 단계로 나뉜 프로젝트에서

Dock은 사용자가 선택한 로컬 document workspace에서 Markdown을 열고 편집하는 애플리케이션이다. 처음에는 파일 목록을 다시 조회하면 실제 디렉터리와 화면이 어느 정도 맞을 것이라고 생각했다. 하지만 편집기가 실제 파일을 열고 있는 동안에는 단순한

20개가 넘는 개발 포스팅을 작성해오면서 텍스트와 Mermaid로 워크 플로우만 공유했지, 실제 어떤 제품을 개발하고 있는지 공유한 사항은 없었다.어떤걸 만들고 있고어떤 기능들이 어떻게 구현되어있는지실제 화면은 어떻게 구성되어있는지포스팅에 공유하고 개선되어가는 과정도

앞선 수동 QA에서 Dock은 대부분의 핵심 흐름을 통과했다. 하지만 실제 사용자의 관점에서는 버튼을 눌러도 아무 반응이 없는 기능, 실패했지만 이유를 알 수 없는 기능, 파일은 저장됐지만 문서에는 참조가 들어가지 않는 기능이 남아 있었다.이번 작업의 기준은 단순했다.

지난 포스팅에서는 실제 문서 작업 중 발생한 Explorer와 상태 보존 문제를 다뤘다. 그 과정을 진행하면서 기능이 정상적으로 동작하는지와 별개로, 큰 저장소를 열었을 때 앱이 얼마나 빨리 반응하는지도 제품 품질의 일부라는 사실이 분명해졌다.작은 테스트 폴더에서는 보