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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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