일렉트론 앱에 main, preload, renderer 파일이 세 개인 이유

일렉트론 프로젝트를 처음 생성하면 눈에 띄는 게 있어요. `main.ts`, `preload.ts`, `renderer.ts` 세 개의 스크립트가 나란히 놓여 있죠. 왜 하나가 아니라 셋일까요? 이 질문에 답하려면 크로미움의 다중 프로세스 아키텍처까지 거슬러 올라가야 해요.

크롬 브라우저 팀은 각 탭마다 독립적인 프로세스를 두는 설계를 선택했어요. 악의적인 코드가 한 탭에서 실행되더라도 브라우저 전체가 다운되지 않도록 하기 위해서죠. 일렉트론은 이 구조를 그대로 물려받았어요. 덕분에 하나의 창에서 오류가 나도 애플리케이션 전체는 멀쩡하게 돌아가요.

메인 프로세스는 앱의 두뇌, 렌더러는 눈과 귀

메인 프로세스는 크롬의 단일 브라우저 프로세스와 같은 역할이에요. 일렉트론 앱에 딱 하나만 존재하고, Node.js 런타임에서 실행되죠. `BrowserWindow` 모듈로 창을 만들고, 사이즈를 조절하고, preload 스크립트를 지정하고, 렌더링할 HTML 파일을 연결하는 게 이 녀석의 일이에요. 앱의 라이프사이클도 여기서 관리해요. `ready` 이벤트로 초기화 완료를 감지하고, `window-all-closed`로 모든 창 닫힘에 대응하고, macOS 특화인 `activate`로 독 아이콘 클릭에 반응하죠.

렌더러 프로세스는 크롬의 각 탭에 해당해요. 메인 프로세스가 `BrowserWindow`를 만들 때마다 별도의 렌더러 프로세스가 생기고, 크로미움 런타임에서 실행돼요. 웹 콘텐츠를 화면에 그리는 역할이죠.

Node.js 환경이라서 가능한 것들

메인 프로세스가 Node.js 위에서 돌아간다는 건 단순히 웹 콘텐츠를 보여주는 래퍼를 넘어선다는 뜻이에요. `require`로 모듈을 불러오고 Node의 내장 API를 자유롭게 쓸 수 있으니까, 메뉴, 대화 상자, 시스템 트레이 아이콘 같은 OS 네이티브 기능을 직접 제어할 수 있거든요.

preload 스크립트는 이 두 세계를 잇는 다리 역할이에요. 렌더러 프로세스에서 Node.js API에 직접 접근하면 보안 위험이 생기니까, preload에서 안전하게 노출할 기능만 골라서 넘겨주는 구조죠. 결국 세 파일이 존재하는 건 보안과 안정성을 위한 아키텍처적 선택이에요. 귀찮아 보여도, 한 탭의 오류가 앱 전체를 죽이지 않는 견고함은 이 구조 덕분이에요.