Merge pull request #2093 from preco21/master

Translate docs into korean #2 + added link of power-save-blocker API to README

docs/development/atom-shell-vs-node-webkit-ko.md

@@ -0,0 +1,34 @@
+# NW.js와 기술적으로 다른점 (이전 node-webkit)
+
+__알림: Electron은 이전까지 Atom Shell로 불려졌습니다.__
+
+NW.js 처럼 Electron은 JavaScript와 HTML 그리고 Node 통합환경을 제공함으로써 웹 페이지에서 저수준 시스템에 접근할 수 있는 웹 기반 데스크탑 어플리케이션을 작성할 수 있도록 합니다.
+
+하지만 Electron과 NW.js는 근본적인 개발흐름의 차이도 있습니다:
+
+__1. 어플리케이션의 엔트리 포인트__
+
+NW.js에선 어플리케이션의 엔트리 포인트로 웹 페이지를 사용합니다.
+`package.json`내의 main 필드에 메인 웹 페이지(index.html) 파일을 지정하면 어플리케이션의 메인 윈도우로 열리게 됩니다.
+
+Electron에선 JavaScript를 엔트리 포인트로 사용합니다. URL을 직접 제공하는 대신 API를 사용하여 직접 브라우저 창과 HTML 파일을 로드할 수 있습니다.
+또한 윈도우의 종료시기를 결정하는 이벤트를 리스닝해야합니다.
+
+Electron은 Node.js 런타임과 비슷하게 작동합니다. Electron의 API는 저수준이기에 브라우저 테스팅을 위해 [PhantomJS](http://phantomjs.org/)를 사용할 수도 있습니다.
+
+__2. 빌드 시스템__
+
+Electron은 Chromium의 모든것을 빌드하는 복잡성을 피하기 위해 [libchromiumcontent](https://github.com/brightray/libchromiumcontent)를 사용하여
+Chromium의 Content API에 접근합니다. libchromiumcontent은 단일 공유 라이브러리이고 Chromium Content 모듈과 종속성 라이브러리들을 포함합니다.
+유저는 Electron을 빌드 하기 위해 높은 사양의 빌드용 컴퓨터를 구비할 필요가 없습니다.
+
+__3. Node 통합__
+
+NW.js는 웹 페이지에서 require를 사용할 수 있도록 Chromium을 패치했습니다. 한편 Electron은 Chromium의 해킹을 방지하기 위해 libuv loop와 각 플랫폼의 메시지 루프에 통합하는 등의 다른 방법을 채택하였습니다.
+[`node_bindings`](../../atom/common/) 코드를 보면 이 부분이 어떻게 구현됬는지를 알 수 있습니다.
+
+__4. 다중 컨텍스트__
+
+만약 NW.js를 사용해본적이 있다면 Node context와 Web context의 개념을 잘 알고 있을겁니다. 이 개념은 NW.js가 구현된 방식에 따라 만들어졌습니다.
+
+Node의 [다중 컨텍스트](http://strongloop.com/strongblog/whats-new-node-js-v0-12-multiple-context-execution/)를 사용할 경우 Electron은 웹 페이지에서 새로운 JavaScript 컨텍스트를 생성하지 않습니다.

docs/development/build-instructions-linux-ko.md

@@ -0,0 +1,90 @@
+# 빌드 설명서 (Linux)
+
+## 빌드전 요구사양
+
+* Python 2.7.x. 몇몇 CentOS와 같은 배포판들은 아직도 Python 2.6.x 버전을 사용합니다. 그래서 `python -V`를 통해 버전을 확인해 줄 필요가 있습니다.
+* Node.js v0.12.x. Node를 설치하는 방법은 여러가지가 있습니다. 그중 하나는 [Node.js](http://nodejs.org) 사이트에서 소스코드를 받아 빌드하는 방법입니다.
+이렇게 하면 Node를 일반 유저로 홈 디렉터리에 설치할 수 있습니다. 또는 [NodeSource](https://nodesource.com/blog/nodejs-v012-iojs-and-the-nodesource-linux-repositories) 에서 받아올 수도 있습니다.
+자세한 내용은 [Node.js 설치 방법](https://github.com/joyent/node/wiki/Installation) 을 참고하세요.
+* Clang 3.4 또는 최신 버전
+* GTK+ 와 libnotify의 개발용 헤더
+
+Ubuntu를 사용하고 있다면 다음 커맨드로 설치하면 합니다:
+
+```bash
+$ sudo apt-get install build-essential clang libdbus-1-dev libgtk2.0-dev \
+                       libnotify-dev libgnome-keyring-dev libgconf2-dev \
+                       libasound2-dev libcap-dev libcups2-dev libxtst-dev \
+                       libxss1 gcc-multilib g++-multilib
+```
+
+다른 배포판의 경우 yum과 같은 패키지 매니저를 통해 패키지를 설치 할 수 있습니다. 패키지의 이름은 대부분 비슷할 것입니다.
+또는 소스코드를 내려받아 직접 빌드하는 방법도 있습니다.
+
+## 가상머신을 사용하여 빌드 하는 경우
+
+만약 Electron을 가상머신으로 빌드 할 계획이라면 해당 가상머신의 스토리지를 최소 25GB 이상을 확보해 놓아야 합니다.
+
+
+## 코드 가져오기
+
+```bash
+$ git clone https://github.com/atom/electron.git
+```
+
+## 부트 스트랩
+
+부트스트랩 스크립트는 필수적인 빌드 종속성 라이브러리들을 모두 다운로드하고 프로젝트 파일을 생성합니다.
+스크립트가 정상적으로 작동하기 위해선 Python 2.7.x 버전이 필요합니다.
+아마 다운로드 작업이 상당히 많은 시간을 소요할 것입니다.
+참고로 Electron은 빌드 툴체인으로 `ninja`를 사용하므로 `Makefile`은 생성되지 않습니다.
+
+```bash
+$ cd electron
+$ ./script/bootstrap.py -v
+```
+
+## 빌드 하기
+
+`Release` 와 `Debug` 두 타겟 모두 빌드 합니다:
+
+```bash
+$ ./script/build.py
+```
+
+이 스크립트는 `out/R` 디렉터리에 크기가 매우 큰 Electron 실행 파일을 배치합니다. 파일 크기는 1.3GB를 초과합니다.
+이러한 문제가 발생하는 이유는 Release 타겟 바이너리가 디버그 심볼을 포함하기 때문입니다.
+파일 크기를 줄이려면 `create-dist.py` 스크립트를 실행하세요:
+
+```bash
+$ ./script/create-dist.py
+```
+
+이 스크립트는 매우 작은 배포판을 `dist` 디렉터리에 생성합니다.
+create-dist.py 스크립트를 실행한 이후 1.3GB를 초과하는 공간을 차지하는 out/R 폴더의 실행파일 바이너리는 삭제해도 됩니다.
+
+`Debug` 타겟만 빌드 할 수도 있습니다:
+
+```bash
+$ ./script/build.py -c D
+```
+
+빌드가 모두 끝나면 `out/D` 디렉터리에서 `electron` 디버그 바이너리를 찾을 수 있습니다.
+
+## 정리 하기
+
+빌드 파일들을 정리합니다:
+
+```bash
+$ ./script/clean.py
+```
+
+## 문제 해결
+
+개발 종속성 라이브러리들을 제대로 설치했는지 확인하세요. 
+
+## 테스트
+
+```bash
+$ ./script/test.py
+```

docs/development/build-instructions-mac-ko.md

@@ -0,0 +1,53 @@
+# 빌드 설명서 (Mac)
+
+## 빌드전 요구 사항
+
+* OS X >= 10.8
+* [Xcode](https://developer.apple.com/technologies/tools/) >= 5.1
+* [node.js](http://nodejs.org) (external).
+
+만약 Homebrew를 이용해 파이선을 설치했다면 다음 파이선 모듈도 같이 설치해야 합니다:
+
+* pyobjc
+
+## 코드 가져오기
+
+```bash
+$ git clone https://github.com/atom/electron.git
+```
+
+## 부트 스트랩
+
+부트스트랩 스크립트는 필수적인 빌드 종속성 라이브러리들을 모두 다운로드하고 프로젝트 파일을 생성합니다.
+참고로 Electron은 빌드 툴체인으로 `ninja`를 사용하므로 Xcode 프로젝트는 생성되지 않습니다.
+
+```bash
+$ cd electron
+$ ./script/bootstrap.py -v
+```
+
+## 빌드 하기
+
+`Release` 와 `Debug` 두 타겟 모두 빌드 합니다:
+
+```bash
+$ ./script/build.py
+```
+
+`Debug` 타겟만 빌드 할 수도 있습니다:
+
+```bash
+$ ./script/build.py -c D
+```
+
+빌드가 모두 끝나면 `out/D` 디렉터리에서 `Electron.app` 실행 파일을 찾을 수 있습니다.
+
+## 32비트 지원
+
+Electron은 현재 OS X 64비트 빌드만 지원하고 있습니다. 그리고 앞으로도 OS X 32비트는 지원할 계획이 없습니다.
+
+## 테스트
+
+```bash
+$ ./script/test.py
+```

docs/development/build-instructions-windows-ko.md

@@ -0,0 +1,117 @@
+# 빌드 설명서 (Windows)
+
+## 빌드전 요구 사항
+
+* Windows 7 / Server 2008 R2 또는 최신 버전
+* Visual Studio 2013 - [VS 2013 커뮤니티 에디션 무료 다운로드](http://www.visualstudio.com/products/visual-studio-community-vs)
+* [Python 2.7](http://www.python.org/download/releases/2.7/)
+* [Node.js](http://nodejs.org/download/)
+* [git](http://git-scm.com)
+
+현재 Windows를 설치하지 않았다면 [modern.ie](https://www.modern.ie/en-us/virtualization-tools#downloads)에서
+사용기한이 정해져있는 무료 가상머신 버전의 Windows를 받아 Electron을 빌드할 수도 있습니다.
+
+Electron은 전적으로 command-line 스크립트를 사용하여 빌드합니다. 그렇기에 Electron을 개발하는데 아무런 에디터나 사용할 수 있습니다.
+하지만 이 말은 Visual Studio를 개발을 위해 사용할 수 없다는 말이 됩니다. 나중에 Visual Studio를 이용한 빌드 방법도 제공할 예정입니다.
+
+**참고:** Visual Studio가 빌드에 사용되지 않더라도 제공된 빌드 툴체인이 **필수적으로** 사용되므로 여전히 필요합니다.
+
+## 코드 가져오기
+
+```powershell
+git clone https://github.com/atom/electron.git
+```
+
+## 부트 스트랩
+
+부트스트랩 스크립트는 필수적인 빌드 종속성 라이브러리들을 모두 다운로드하고 프로젝트 파일을 생성합니다.
+참고로 Electron은 빌드 툴체인으로 `ninja`를 사용하므로 Visual Studio 프로젝트는 생성되지 않습니다.
+
+```powershell
+cd electron
+python script\bootstrap.py -v
+```
+
+## 빌드 하기
+
+`Release` 와 `Debug` 두 타겟 모두 빌드 합니다:
+
+```powershell
+python script\build.py
+```
+
+`Debug` 타겟만 빌드 할 수도 있습니다:
+
+```powershell
+python script\build.py -c D
+```
+
+빌드가 모두 끝나면 `out/D` 디렉터리에서 `atom.exe` 실행 파일을 찾을 수 있습니다.
+
+## 64비트 빌드
+
+64비트를 타겟으로 빌드 하려면 부트스트랩 스크립트를 실행할 때 `--target_arch=x64` 인자를 같이 넘겨주면 됩니다:
+
+```powershell
+python script\bootstrap.py -v --target_arch=x64
+```
+
+다른 빌드 단계도 정확하게 같습니다.
+
+## 테스트
+
+```powershell
+python script\test.py
+```
+
+## 문제 해결
+
+### Command xxxx not found
+
+만약 `Command xxxx not found`와 같은 형식의 에러가 발생했다면 `VS2012 Command Prompt` 콘솔로 빌드 스크립트를 실행해볼 필요가 있습니다.
+
+### Fatal internal compiler error: C1001
+
+Visual Studio가 업데이트까지 완벽하게 설치된 최신버전인지 확인하세요.
+
+### Assertion failed: ((handle))->activecnt >= 0
+
+Cygwin에서 빌드 할 경우 `bootstrap.py` 스크립트가 다음의 에러와 함께 빌드에 실패할 수 있습니다:
+
+```
+Assertion failed: ((handle))->activecnt >= 0, file src\win\pipe.c, line 1430
+
+Traceback (most recent call last):
+  File "script/bootstrap.py", line 87, in <module>
+    sys.exit(main())
+  File "script/bootstrap.py", line 22, in main
+    update_node_modules('.')
+  File "script/bootstrap.py", line 56, in update_node_modules
+    execute([NPM, 'install'])
+  File "/home/zcbenz/codes/raven/script/lib/util.py", line 118, in execute
+    raise e
+subprocess.CalledProcessError: Command '['npm.cmd', 'install']' returned non-zero exit status 3
+```
+
+이 버그는 Cygwin python과 Win32 node를 같이 사용할 경우 발생합니다.
+부트스트랩 스크립트에서 Win32 python을  사용함으로써 이 문제를 해결할 수 있습니다 (`C:\Python27` 디렉터리에 python이 설치되었다는 것을 가정하면):
+
+```bash
+/cygdrive/c/Python27/python.exe script/bootstrap.py
+```
+
+### LNK1181: cannot open input file 'kernel32.lib'
+
+32bit node.js를 다시 설치하세요.
+
+### Error: ENOENT, stat 'C:\Users\USERNAME\AppData\Roaming\npm'
+
+간단하게 해당 디렉터리를 생성하면 [문제가 해결될 겁니다](http://stackoverflow.com/a/25095327/102704):
+
+```powershell
+mkdir ~\AppData\Roaming\npm
+```
+
+### node-gyp is not recognized as an internal or external command
+
+Git Bash로 빌드 했을 때 이러한 에러가 발생할 수 있습니다. 반드시 PowerShell이나 VS2012 Command Prompt에서 빌드를 진행해야 합니다.

docs/development/build-system-overview-ko.md

@@ -0,0 +1,51 @@
+# 빌드 시스템 개요
+
+Electron은 프로젝트 생성을 위해 `gyp`를 사용하며 `ninja`를 이용하여 빌드합니다.
+프로젝트 설정은 `.gyp` 와 `.gypi` 파일에서 볼 수 있습니다.
+
+## gyp 파일들
+
+Electron을 빌드 할 때 `gyp` 파일들은 다음과 같은 규칙을 따릅니다:
+
+* `atom.gyp`는 Electron의 빌드 과정 자체를 정의합니다.
+* `common.gypi`는 Node가 Chromium과 함께 빌드될 수 있도록 조정한 빌드 설정입니다.
+* `vendor/brightray/brightray.gyp`는 `brightray`의 빌드 과정을 정의하고 Chromium과의 링킹에 대한 기본적인 설정을 포함합니다.
+* `vendor/brightray/brightray.gypi`는 빌드에 대한 일반적인 설정이 포함되어 있습니다.
+
+## 구성요소 빌드
+
+Chromium은 꽤나 큰 프로젝트입니다. 이 때문에 최종 링킹 작업은 상당한 시간이 소요될 수 있습니다.
+이러한 문제로 인해 개발 시 빌드 작업을 까다롭게 만듭니다. 이 문제를 해결하기 위해 Chromium은 "component build"를 도입했습니다.
+이는 각각의 컴포넌트를 각각 따로 분리하여 공유 라이브러리로 빌드 합니다. 이렇게 되면 링킹작업은 매우 빨라지지만 파일 크기와 성능이 느려집니다.
+
+Electron도 상당히 비슷한 접근을 했습니다:
+`Debug`빌드 시 바이너리는 공유 라이브러리 버전의 Chromium 컴포넌트를 사용해서 링크 속도를 높이고
+`Release`빌드 시엔 정적 라이브러리 버전의 컴포넌트를 사용합니다.
+이렇게 각 빌드의 단점을 상호 보완하여 디버그 시 빌드 속도는 향상되고 배포판 빌드 시 공유 라이브러리의 단점은 제거했습니다.
+
+## 부트스트랩 최소화
+
+모든 사전 빌드 된 Chromium 바이너리들은 부트스트랩 스크립트가 실행될 때 다운로드됩니다.
+기본적으로 공유 라이브러리와 정적 라이브러리 모두 다운로드되며 최종 전체 파일 크기는 플랫폼에 따라 800MB에서 2GB까지 차지합니다.
+
+만약 빠르게 Electron의 개발 또는 테스트만 하고 싶다면 `--dev` 플래그를 추가하여 공유 라이브러리만 다운로드할 수 있습니다:
+
+```bash
+$ ./script/bootstrap.py --dev
+$ ./script/build.py -c D
+```
+
+## 프로젝트 생성 (two-phrase)
+
+Electron은 `Release`와 `Debug` 빌드가 서로 다른 라이브러리 링크 방식을 사용합니다.
+그러나 `gyp`는 따로 빌드 설정을 분리하여 라이브러리 링크 방식을 정의하는 것을 지원하지 않습니다.
+
+이러한 문제를 해결하기 위해 Electron은 링크 설정을 제어하는 `gyp` 변수 `libchromiumcontent_component`를 사용하고 `gyp`를 실행할 때 단 하나의 타겟만을 생성합니다.
+
+## 타겟 이름
+
+많은 프로젝트에서 타겟 이름을 `Release` 와 `Debug`를 사용하는데 반해 Electron은 `R`과 `D`를 대신 사용합니다.
+이유는 가끔 알 수 없는 이유(randomly)로 `Release` 와 `Debug` 중 하나만 빌드 설정에 정의되어 있을때 `gyp`가 크래시를 일으키는데
+전술한 바와 같이 Electron은 한번에 한개의 타겟만을 생성할 수 있기 때문입니다.
+
+이 문제는 개발자에게만 영향을 미칩니다. 만약 단순히 Electron을 rebranding 하기 위해 빌드 한다면 이 문제에 신경 쓸 필요가 없습니다.

docs/development/coding-style-ko.md

@@ -4,20 +4,19 @@
 
 C++과 Python스크립트는 Chromium의 [코딩 스타일](http://www.chromium.org/developers/coding-style)을 따릅니다.
 파이선 스크립트 `script/cpplint.py`를 사용하여 모든 파일이 해당 코딩스타일에 맞게 코딩 되었는지 확인할 수 있습니다.
-
 파이선의 버전은 2.7을 사용합니다.
 
 ## CoffeeScript
 
-CoffeeScript의 경우 GitHub의 [스타일 가이드](https://github.com/styleguide/javascript)를 따릅니다, 동시에 다음 규칙도 따릅니다:
+CoffeeScript의 경우 GitHub의 [스타일 가이드](https://github.com/styleguide/javascript)를 따릅니다. 동시에 다음 규칙도 따릅니다:
 
-* Google의 코딩 스타일에도 맞추기 위해, 파일의 끝에는 **절대** 개행을 삽입해선 안됩니다.
+* Google의 코딩 스타일에도 맞추기 위해 파일의 끝에는 **절대** 개행을 삽입해선 안됩니다.
 * 파일 이름의 공백은 `_`대신에 `-`을 사용하여야 합니다. 예를 들어 `file_name.coffee`를
-`file-name.coffee`로 고쳐야합니다, 왜냐하면 [github/atom](https://github.com/github/atom) 에서 사용되는 모듈의 이름은
-보통 `module-name`형식이기 때문입니다, 이 규칙은 '.coffee' 파일에만 적용됩니다.
+`file-name.coffee`로 고쳐야합니다. 왜냐하면 [github/atom](https://github.com/github/atom) 에서 사용되는 모듈의 이름은
+보통 `module-name`형식이기 때문입니다. 이 규칙은 '.coffee' 파일에만 적용됩니다.
 
 ## API 이름
 
-새로운 API를 만들 땐, getter, setter스타일 대신 jQuery의 one-function스타일을 사용해야 합니다. 예를 들어,
+새로운 API를 만들 땐 getter, setter스타일 대신 jQuery의 one-function스타일을 사용해야 합니다. 예를 들어
 `.getText()`와 `.setText(text)`대신에 `.text([text])`형식으로 설계하면 됩니다.
 포럼에 이 문제에 대한 [논의](https://github.com/atom/electron/issues/46)가 있습니다.

docs/development/setting-up-symbol-server-ko.md

@@ -0,0 +1,44 @@
+# 디버거에서 디버그 심볼 서버 설정
+
+디버그 심볼은 디버깅 세션을 더 좋게 개선해 줍니다. 디버그 심볼은 실행 파일과 동적 링크 라이브러리에서 함수에 대한 정보를 담고 있으며 명료한 함수 호출 스텍 정보를 제공합니다.
+심볼 서버는 유저가 크기가 큰 디버깅용 파일을 필수적으로 다운로드 받지 않고도 디버거가 알맞은 심볼, 바이너리 그리고 소스를 자동적으로 로드할 수 있도록 해줍니다.
+서버 사용법은 [Microsoft의 심볼 서버](http://support.microsoft.com/kb/311503)와 비슷합니다. 이 문서를 참조하세요.
+
+참고로 릴리즈된 Electron 빌드는 자체적으로 많은 최적화가 되어 있는 관계로 경우에 따라 디버깅이 쉽지 않을 수 있습니다.
+Inlining, tail call 등의 컴파일러 최적화에 의해 디버거가 모든 변수의 컨텐츠를 보여줄 수 없는 경우도 있고 실행 경로가 이상하게 보여질 수 있습니다.
+유일한 해결 방법은 최적화되지 않은 로컬 빌드를 하는 것입니다.
+
+공식적인 Electron의 심볼 서버의 URL은 http://54.249.141.255:8086/atom-shell/symbols 입니다.
+일단 이 URL에 직접적으로 접근할 수는 없습니다: 디버깅 툴에 심볼의 경로를 추가해야합니다.
+아래의 예제를 참고하면 로컬 캐시 디렉터리는 서버로부터 중복되지 않게 PDB를 가져오는데 사용됩니다.
+`c:\code\symbols` 캐시 디렉터리를 사용중인 OS에 맞춰 적당한 경로로 변경하세요.
+
+## Windbg에서 심볼 서버 사용하기
+
+Windbg 심볼 경로는 구분자와 *(별) 문자로 설정되어 있습니다.
+Electron 심볼 서버만을 사용하려면 심볼 경로의 엔트리를 추가해야 합니다 (__참고:__  `c:\code\symbols` 디렉터리 경로를 PC가 원하는 경로로 수정할 수 있습니다):
+
+```
+SRV*c:\code\symbols\*http://54.249.141.255:8086/atom-shell/symbols
+```
+
+Windbg 메뉴 또는 `.sympath` 커맨드를 이용하여 환경에 `_NT_SYMBOL_PATH` 문자열을 설정합니다.
+만약 Microsoft의 심볼서버로 부터 심볼을 받아오려면 다음과 같이 리스팅을 먼저 해야합니다:
+
+```
+SRV*c:\code\symbols\*http://msdl.microsoft.com/download/symbols;SRV*c:\code\symbols\*http://54.249.141.255:8086/atom-shell/symbols
+```
+
+## Visual Studio에서 심볼 서버 사용하기
+
+<img src='http://mdn.mozillademos.org/files/733/symbol-server-vc8express-menu.jpg'>
+<img src='http://mdn.mozillademos.org/files/2497/2005_options.gif'>
+
+## 문제 해결: Symbols will not load
+
+Windbg에서 다음의 커맨드를 입력하여 왜 심볼이 로드되지 않았는지에 대한 오류 내역을 출력합니다:
+
+```
+> !sym noisy
+> .reload /f chromiumcontent.dll
+```

docs/development/source-code-directory-structure-ko.md

@@ -0,0 +1,48 @@
+# 소스 코드 디렉터리 구조
+
+## 개요
+
+Electron의 소스 코드는 몇 개의 파트로 분리되어 있습니다. 우리는 Chromium의 분리 규칙(separation conventions)을 주로 따르고 있습니다.
+
+이미 [Chromium의 멀티 프로세스 아키텍쳐](http://dev.chromium.org/developers/design-documents/multi-process-architecture)에 익숙해져 있다면 소스 코드를 이해하기 쉬울 것입니다.
+
+## 소스 코드 구조
+
+* **atom** - Electron의 소스코드.
+  * **app** - 시스템 엔트리 코드.
+  * **browser** - 주 윈도우를 포함한 프론트엔드, UI, 그리고 메인 프로세스에 관련된 것들. 주 랜더러와 웹 페이지 관리관련 코드.
+    * **lib** - 메인 프로세스 초기화 코드의 자바스크립트 파트.
+    * **ui** - 크로스 플랫폼에 대응하는 UI 구현.
+      * **cocoa** - 코코아 특정 소스 코드.
+      * **gtk** - GTK+ 특정 소스 코드.
+      * **win** - Windows GUI 특정 소스 코드.
+    * **default_app** - 어플리케이션이 제공되지 않으면 기본적으로 사용될 페이지.
+    * **api** - 메인 프로세스 API들의 구현.
+       * **lib** -  API 구현의 자바스크립트 파트.
+    * **net** - 네트워크 관련 코드.
+    * **mac** - Mac 특정 Objective-C 소스 코드.
+    * **resources** - 아이콘들, 플랫폼 종속성 파일들, 기타 등등.
+  * **renderer** - 렌더러 프로세스에서 작동하는 코드들.
+    * **lib** - 렌더러 프로세스 초기화 코드의 자바스크립트 파트.
+    * **api** - 렌더러 프로세스 API들의 구현.
+       * **lib** - API 구현의 자바스크립트 파트.
+  * **common** - 메인 프로세스와 렌더러 프로세스에서 공유하는 코드. 유틸리티 함수와 node 메시지 루프를 Chromium의 메시지 루프에 통합시킨 코드가 포함.
+    * **lib** - 공통 자바스크립트 초기화 코드.
+    * **api** - 공통 API들의 구현, Electron의 빌트인 모듈 기초 코드들.
+       * **lib** - API 구현의 자바스크립트 파트.
+* **chromium_src** - 복사된 Chromium 소스 코드.
+* **docs** - 참조 문서.
+* **spec** - 자동화된 테스트.
+* **atom.gyp** - Electron의 빌드 규칙.
+* **common.gypi** - 컴파일러 설정 및 `node` 와 `breakpad` 등의 구성요소를 위한 빌드 규칙.
+
+## 그외 디렉터리 구조
+
+* **script** - 개발목적으로 사용되는 빌드, 패키징, 테스트, 기타등을 실행하는 스크립트.
+* **tools** - gyp 파일에서 사용되는 헬퍼 스크립트 `script`와는 다르게 유저로부터 직접 실행되지 않는 스크립트들을 이곳에 넣습니다.
+* **vendor** - 소스코드의 서드파티 종속성 코드 소스 코드 디렉터리가 겹쳐 혼란을 일으킬 수 있기 때문에
+  우리는 `third_party`와 같은 Chromium 소스 코드 디렉터리에서 사용된 폴더 이름을 사용하지 않았습니다.
+* **node_modules** - 빌드에 사용되는 node 서드파티 모듈.
+* **out** - `ninja`의 임시 출력 디렉터리.
+* **dist** - 배포용 바이너리를 빌드할 때 사용하는 `script/create-dist.py` 스크립트로부터 만들어지는 임시 디렉터리.
+* **external_binaries** - `gyp`를 통한 빌드가 지원하지 않아 따로 다운로드된 서드파티 프레임워크 바이너리들.