00 — Foundations (챕터 인덱스)

이 챕터가 답하는 질문: “Electron이라는 게 정확히 무엇이고, 왜 등장했고, 왜 그냥 브라우저나 진짜 네이티브가 아니라 그 사이에 자리를 잡았는가?” 한 줄 답 (Pyramid Top): “Electron은 Chromium 렌더러와 Node.js 런타임을 한 프로세스 트리에 묶고 IPC로 연결한 패키지된 데스크톱 런타임이다 — 웹 기술을 그대로 쓰되 웹의 격리·배포·권한 모델은 다시 쓴다.”

챕터 지도

Why — 왜 기초 챕터가 따로 존재하는가

Electron은 세 단어(“Chromium + Node + IPC”)로 한 줄 요약이 되지만, 이 한 줄을 그냥 외운 상태로 코드에 들어가면 거의 반드시 길을 잃는다. 세 단어 각각이 다른 패러다임을 끌고 오기 때문이다.

세 패러다임이 한 프로세스 트리 안에서 부딪힌다. 이 챕터는 그 충돌을 만나기 전에 어디서 누가 무엇을 하는지의 지도를 먼저 그려준다. 운영 디테일(보안·배포·성능)은 뒷장에서 깊이 다루지만, 그 디테일이 왜 그런 식으로 설계됐는지는 이 챕터에서만 설명된다.

웹 개발자의 직관, 데스크톱 개발자의 직관, Node 개발자의 직관이 모두 부분만 맞는다. 이 챕터는 그 부분의 합집합과 차집합을 만든다.

본문 5개 인덱스

어떻게 읽는가

• 처음 만나는 사람: 01 → 04 → 03 → 05 → 02 순서. 무엇인지와 어떻게 생겼는지를 먼저 본 뒤, 비교와 역사로 맥락을 채운다.
• 이미 웹 개발자: 03만 깊게 — 직관과 어디서 깨지는지가 같이 잡힌다. 그다음 04.
• 이미 네이티브 개발자: 01 → 03 → 04. 왜 굳이 브라우저를 끼우는가의 합리화가 03에서 잡힌다.
• 기술 선택 회의 직전: 03 + 05만. 30분 의사결정 패키지.

What-if — 이 챕터의 한계

기초 챕터는 지도다 — 지도만 보고 운전할 수는 없다.

이 챕터를 끝내고 “이제 더 알 게 없네”라는 느낌이 들면 위험 신호다 — 운영 디테일이 전혀 안 들어와 있다는 뜻이다.

한 단락 요약

기초 챕터는 Electron의 정체성·계보·웹과의 거리·최소 코드 모양·대안과의 위치를 다섯 문서로 펼친다. 한 줄 답(“Chromium + Node + IPC를 묶은 런타임”)이 왜 그렇게 설계됐고 어디서 깨지는지까지 잡히면, 다음 챕터들의 운영 디테일이 맥락을 가진 디테일로 들어온다. 이 챕터의 가치는 답을 외우게 하는 것이 아니라, *“내 코드는 어느 프로세스에 살고, OS에 어떻게 닿는가”*라는 질문을 디폴트로 던지게 만드는 것이다.