diff --git a/docs/documentation/ko/Nightly Builds.md b/docs/documentation/ko/Nightly Builds.md
new file mode 100644
index 00000000..36e1ad34
--- /dev/null
+++ b/docs/documentation/ko/Nightly Builds.md	
@@ -0,0 +1,80 @@
+---
+title: Nightly Builds
+layout: docs
+permalink: /ko/docs/handbook/nightly-builds.html
+oneline: How to use a nightly build of TypeScript
+translatable: true
+---
+
+[TypeScript의 `master`](https://github.com/Microsoft/TypeScript/tree/master) 브랜치의 nightly 빌드는 태평양 표준시(PST) 자정까지 NPM에 배포됩니다.  
+도구를 사용하여 가져오는 방법과 사용하는 방법은 다음과 같습니다.
+
+## npm 사용하기 (Using npm)
+
+```shell
+npm install -g typescript@next
+```
+
+## nightly 빌드를 사용하도록 IDE 업데이트 (Updating your IDE to use the nightly builds)
+
+nightly drop을 사용하도록 IDE를 업데이트할 수 있습니다.  
+먼저 npm을 통해 패키지를 설치해야 합니다.
+npm 패키지를 전역으로 설치하거나 로컬에 있는 `node_modules` 폴더에 설치할 수 있습니다.
+
+이 섹션의 나머지 부분에서는 `typescript@next`가 이미 설치되어 있다고 가정합니다.
+
+### 비주얼 스튜디오 코드 (Visual Studio Code)
+
+`.vscode/settings.json` 파일을 다음과 같이 업데이트하세요:
+
+```json
+"typescript.tsdk": "<path to your folder>/node_modules/typescript/lib"
+```
+
+자세한 내용은 [VSCode 문서](https://code.visualstudio.com/Docs/languages/typescript#_using-newer-typescript-versions)를 참조하세요.
+
+### 서브라임 텍스트 (Sublime Text)
+
+`Settings - User` 파일을 다음과 같이 업데이트하세요:
+
+```json
+"typescript_tsdk": "<path to your folder>/node_modules/typescript/lib"
+```
+
+자세한 내용은 [서브라임 텍스트를 위한 TypeScript 플러그인 설치 문서](https://github.com/Microsoft/TypeScript-Sublime-Plugin#installation)를 참조하세요.
+
+### 비주얼 스튜디오 2013 및 2015 (Visual Studio 2013 and 2015)
+
+> 주의사항: 대부분의 변경 사항에는 새로운 버전의 VS TypeScript 플러그인을 설치할 필요는 없습니다.
+
+현재 nightly 빌드에는 전체 플러그인 설정이 포함되어 있지 않지만 nightly 기반으로 설치 프로그램을 배포하기 위해 노력하고 있습니다.
+
+1. [VSDevMode.ps1](https://github.com/Microsoft/TypeScript/blob/master/scripts/VSDevMode.ps1) 스크립트를 다운로드하세요.
+
+   > 또한 [커스텀 언어 서비스 파일 사용](https://github.com/Microsoft/TypeScript/wiki/Dev-Mode-in-Visual-Studio#using-a-custom-language-service-file)에 대한 위키 페이지를 참조하세요.
+
+2. PowerShell 커맨드 라인 창에서 다음을 실행합니다:
+
+VS 2015:
+
+```posh
+VSDevMode.ps1 14 -tsScript <path to your folder>/node_modules/typescript/lib
+```
+
+VS 2013:
+
+```posh
+VSDevMode.ps1 12 -tsScript <path to your folder>/node_modules/typescript/lib
+```
+
+### IntelliJ IDEA (Mac)
+
+`Preferences` > `Languages & Frameworks` > `TypeScript`를 선택합니다:
+
+ > TypeScript 버전: npm으로 설치한 경우: `/usr/local/lib/node_modules/typescript/lib`
+
+### IntelliJ IDEA (Windows)
+
+`File` > `Settings` > `Languages & Frameworks` > `TypeScript`를 선택합니다:
+
+ > TypeScript 버전: npm으로 설치한 경우: `C:\Users\USERNAME\AppData\Roaming\npm\node_modules\typescript\lib`
diff --git a/docs/documentation/ko/declaration-files/By Example.md b/docs/documentation/ko/declaration-files/By Example.md
new file mode 100644
index 00000000..e73f5066
--- /dev/null
+++ b/docs/documentation/ko/declaration-files/By Example.md	
@@ -0,0 +1,263 @@
+---
+title: Declaration Reference
+layout: docs
+permalink: /ko/docs/handbook/declaration-files/by-example.html
+oneline: "How to create a d.ts file for a module"
+---
+
+# 소개 (Introduction)
+
+이 가이드는 양질의 선언 파일을 작성하는 방법을 설명하기 위해 작성되었습니다.
+이 가이드는 일부 API 문서를 해당 API 사용 예시와 함께 보여주고,
+  상응하는 선언을 작성하는 방법을 설명합니다.
+
+예제는 대체로 후반부로 갈수록 복잡해집니다.
+
+* [프로퍼티를 갖는 객체 (Objects with Properties)](#프로퍼티를-갖는-객체-objects-with-properties)
+* [오버로드된 함수 (Overloaded Function)](#오버로드된-함수-overloaded-functions)
+* [재사용 가능한 타입 (인터페이스) (Reusable Types (Interfaces))](#재사용-가능한-타입-인터페이스-reusable-types-interfaces)
+* [재사용 가능한 타입 (타입 별칭) (Reusable Types (Type Aliases))](#재사용-가능한-타입-타입-별칭-reusable-types-type-aliases)
+* [타입 구조화하기 (Organizing Types)](#타입-구조화하기-organizing-types)
+* [클래스 (Classes)](#클래스-classes)
+* [전역 변수 (Global Variables)](#전역-변수-global-variables)
+* [전역 함수 (Global Functions)](#전역-함수-global-functions)
+
+# 예제 (The Examples)
+
+## 프로퍼티를 갖는 객체 (Objects with Properties)
+
+_문서_
+
+> 전역 변수 `myLib`에는 인사말을 만드는 함수 `makeGreeting`와,
+> 지금까지 생성한 인사말의 수를 가리키는 `numberOfGreetings` 프로퍼티가 있습니다.
+
+_코드_
+
+```ts
+let result = myLib.makeGreeting("hello, world");
+console.log("The computed greeting is:" + result);
+
+let count = myLib.numberOfGreetings;
+```
+
+_선언_
+
+점 표기법으로 접근하는 타입이나 값을 설명하기 위해 `declare namespace`를 사용하세요.
+
+```ts
+declare namespace myLib {
+    function makeGreeting(s: string): string;
+    let numberOfGreetings: number;
+}
+```
+
+## 오버로드된 함수 (Overloaded Functions)
+
+_문서_
+
+`getWidget` 함수는 숫자를 인자로 받아 Widget을 반환하거나, 문자열을 인자로 받아 Widget 배열을 반환합니다.
+
+_코드_
+
+```ts
+let x: Widget = getWidget(43);
+
+let arr: Widget[] = getWidget("all of them");
+```
+
+_선언_
+
+```ts
+declare function getWidget(n: number): Widget;
+declare function getWidget(s: string): Widget[];
+```
+
+## 재사용 가능한 타입 (인터페이스) (Reusable Types (Interfaces))
+
+_문서_
+
+> greeting을 명시할 때, 반드시 `GreetingSettings` 객체를 전달해야 합니다.
+> 이 객체는 다음의 프로퍼티를 갖고 있습니다:
+>
+> 1 - greeting: 필수 문자열
+>
+> 2 - duration: 선택적 시간 (밀리초)
+>
+> 3 - color: 선택적 문자열, 예. '#ff00ff'
+
+_코드_
+
+```ts
+greet({
+  greeting: "hello world",
+  duration: 4000
+});
+```
+
+_선언_
+
+프로퍼티를 갖는 타입을 정의하기 위해 `interface`를 사용하세요.
+
+```ts
+interface GreetingSettings {
+  greeting: string;
+  duration?: number;
+  color?: string;
+}
+
+declare function greet(setting: GreetingSettings): void;
+```
+
+## 재사용 가능한 타입 (타입 별칭) (Reusable Types (Type Aliases))
+
+_문서_
+
+> 인사말이 예상되는 어느 곳에나, `string`, `string`을 반환하는 함수, 또는 `Greeter` 인스턴스를 전달할 수 있습니다.
+
+_코드_
+
+```ts
+function getGreeting() {
+    return "howdy";
+}
+class MyGreeter extends Greeter { }
+
+greet("hello");
+greet(getGreeting);
+greet(new MyGreeter());
+```
+
+_선언_
+
+타입에 대한 약칭으로 타입 별칭을 사용할 수 있습니다:
+
+```ts
+type GreetingLike = string | (() => string) | Greeter;
+
+declare function greet(g: GreetingLike): void;
+```
+
+## 타입 구조화하기 (Organizing Types)
+
+_문서_
+
+> `greeter` 객체는 파일에 로그를 작성하거나 경고 창을 띄울 수 있습니다.
+> 로그 옵션을 `.log(...)` 내부에, 경고 창 옵션을 `.alert(...)` 내부에 전달할 수 있습니다.
+
+_코드_
+
+```ts
+const g = new Greeter("Hello");
+g.log({ verbose: true });
+g.alert({ modal: false, title: "Current Greeting" });
+```
+
+_선언_
+
+타입을 구조화하기 위해 네임스페이스를 사용하세요.
+
+```ts
+declare namespace GreetingLib {
+    interface LogOptions {
+        verbose?: boolean;
+    }
+    interface AlertOptions {
+        modal: boolean;
+        title?: string;
+        color?: string;
+    }
+}
+```
+
+중첩된 네임스페이스를 하나의 선언으로 만들 수 있습니다:
+
+```ts
+declare namespace GreetingLib.Options {
+    // Refer to via GreetingLib.Options.Log
+    interface Log {
+        verbose?: boolean;
+    }
+    interface Alert {
+        modal: boolean;
+        title?: string;
+        color?: string;
+    }
+}
+```
+
+## 클래스 (Classes)
+
+_문서_
+
+> `Greeter` 객체를 인스턴스화해서 greeter를 생성하거나, 이 객체를 상속해서 커스텀 greeter를 생성할 수 있습니다.
+
+_코드_
+
+```ts
+const myGreeter = new Greeter("hello, world");
+myGreeter.greeting = "howdy";
+myGreeter.showGreeting();
+
+class SpecialGreeter extends Greeter {
+    constructor() {
+        super("Very special greetings");
+    }
+}
+```
+
+_선언_
+
+클래스 혹은 클래스-같은 객체를 설명하기 위해 `declare class`를 사용하세요.
+클래스는 생성자 뿐만 아니라 프로퍼티와 메서드를 가질 수 있습니다.
+
+```ts
+declare class Greeter {
+    constructor(greeting: string);
+
+    greeting: string;
+    showGreeting(): void;
+}
+```
+
+## 전역 변수 (Global Variables)
+
+_문서_
+
+> 전역 변수 `foo`는 존재하는 위젯의 수를 포함합니다.
+
+_코드_
+
+```ts
+console.log("Half the number of widgets is " + (foo / 2));
+```
+
+_선언_
+
+변수를 선언하기 위해 `declare var`를 사용하세요.
+만약 변수가 읽기-전용이라면, `declare const`를 사용하세요.
+변수가 블록-스코프인 경우 `declare let` 또한 사용할 수 있습니다.
+
+```ts
+/** 존재하는 위젯의 수 */
+declare var foo: number;
+```
+
+## 전역 함수 (Global Functions)
+
+_문서_
+
+> 사용자에게 인사말을 보여주기 위해 `greet` 함수를 호출할 수 있습니다.
+
+_코드_
+
+```ts
+greet("hello, world");
+```
+
+_선언_
+
+함수를 선언하기 위해 `declare function`을 사용하세요.
+
+```ts
+declare function greet(greeting: string): void;
+```
diff --git a/docs/documentation/ko/declaration-files/Consumption.md b/docs/documentation/ko/declaration-files/Consumption.md
new file mode 100644
index 00000000..737e1d10
--- /dev/null
+++ b/docs/documentation/ko/declaration-files/Consumption.md
@@ -0,0 +1,47 @@
+---
+title: Consumption
+layout: docs
+permalink: /ko/docs/handbook/declaration-files/consumption.html
+oneline: "How to download d.ts files for your project"
+---
+
+TypeScript 2.0에서는 선언 파일을 얻고, 사용하고, 찾는 것이 훨씬 쉬워졌습니다.
+이 페이지에서 세 가지를 어떻게 하는지 정확하게 설명합니다.
+
+## 다운로드 (Downloading)
+
+TypeScript 2.0 이상에서 타입 선언을 가져오는데 npm 이외의 도구는 필요하지 않습니다.
+
+예를 들어, lodash와 같은 라이브러리에 대한 선언을 얻는 것은 다음 명령어로 충분합니다.
+
+```cmd
+npm install --save @types/lodash
+```
+
+[Publishing](/docs/handbook/declaration-files/publishing.html)에서 설명한 대로 npm 패키지에 이미 선언 파일이 포함되어 있다면, `@types` 패키지를 설치할 필요는 없다는 걸 유의하세요.
+
+## 사용하기 (Consuming)
+
+TypeScript 코드에 별 어려움 없이 lodash를 사용할 수 있습니다.
+이는 모듈 및 전역 코드에 모두 적용됩니다.
+
+예를 들어, 타입 선언에 대해 `npm install`을 한 번만 수행하면, import 하고 사용할 수 있고
+
+```ts
+import * as _ from "lodash";
+_.padStart("Hello TypeScript!", 20, " ");
+```
+
+또는 모듈을 사용하지 않는다면, 전역 변수 `_` 를 사용할 수 있습니다.
+
+```ts
+_.padStart("Hello TypeScript!", 20, " ");
+```
+
+## 찾기 (Searching)
+
+대부분의 경우, 타입 선언 패키지 이름은 항상 `npm` 상의 패키지 이름과 같아야 하지만, `@types/` 가 앞에 붙어야 합니다.
+  하지만 필요시 [https://aka.ms/types](https://aka.ms/types) 를 방문해 선호하는 라이브러리의 패키지를 찾으세요.
+
+> 참고: 만약 찾고자 하는 선언 파일이 없는 경우, 언제든지 기여하고, 다음 개발자가 이를 찾는 데 도움을 줄 수 있습니다.
+> 자세한 내용은 DefinitelyTyped의 [기여 지침 페이지](http://definitelytyped.org/guides/contributing.html)를 참고하세요.
\ No newline at end of file
diff --git a/docs/documentation/ko/declaration-files/Deep Dive.md b/docs/documentation/ko/declaration-files/Deep Dive.md
new file mode 100644
index 00000000..95f8db2f
--- /dev/null
+++ b/docs/documentation/ko/declaration-files/Deep Dive.md	
@@ -0,0 +1,238 @@
+---
+title: Deep Dive
+layout: docs
+permalink: /ko/docs/handbook/declaration-files/deep-dive.html
+oneline: "How do d.ts files work, a deep dive"
+---
+
+## 정의 파일 이론: 심층 분석 (Definition File Theory: A Deep Dive)
+
+원하는 API 형태를 제공하는 모듈을 만드는 것은 까다로울 수 있습니다.
+예를 들어, `new`의 사용에 따라 호출할 때 다른 타입을 생성하는 모듈을 원할 수 있고,
+  계층에 노출 된 다양한 명명된 타입을 가지고 있으며,
+  모듈 객체에 대한 여러 프로퍼티도 가질 수 있습니다.
+
+이 가이드에서는, 익숙한 API를 노출하는 복잡한 정의 파일에 대해 작성하는 도구를 제공합니다.
+또한 옵션이 다양하기 때문에 여기서는 모듈 (또는 UMD) 라이브러리에 중점을 둡니다.
+
+## 주요 컨셉 (Key Concepts)
+
+TypeScript 작동 방식에 대해 여러 주요 개념을 이해하여
+  정의의 형태를 만드는 방법을 완전히 이해할 수 있습니다.
+
+### 타입 (Types)
+
+이 가이드를 읽고 있다면, 아마도 TypeScript의 타입에 대해 이미 알고 있을 것입니다.
+보다 명확하게하기 위해, 다음과 같이 *타입*이 도입됩니다:
+
+* 타입 별칭 선언 (`type sn = number | string;`)
+* 인터페이스 선언 (`interface I { x: number[]; }`)
+* 클래스 선언 (`class C { }`)
+* 열거형 선언 (`enum E { A, B, C }`)
+* 타입을 가리키는 `import` 선언
+
+이러한 각 선언 형태는 새로운 타입 이름을 만듭니다.
+
+### 값 (Values)
+
+타입과 마찬가지로 값이 무엇인지 이미 알고 있을 것입니다.
+값은 표현식에서 참조할 수 있는 런타임 이름입니다.
+예를 들어 `let x = 5;`에서는 `x`라고 불리는 값을 생성합니다.
+
+다시 명확하게 말하자면, 다음과 같이 값을 만듭니다:
+
+* `let`, `const`, 그리고 `var` 선언
+* 값을 포함하는 `네임스페이스` 또는 `모듈` 선언
+* `열거형` 선언
+* `클래스` 선언
+* 값을 참조하는 `import` 선언
+* `함수` 선언
+
+### 네임스페이스 (Namespaces)
+
+타입은 *네임스페이스* 안에 존재할 수 있습니다.
+예를 들어, `let x: A.B.C` 이란 선언이 있다면,
+  타입 `C`는 `A.B` 네임스페이스에서 온 것 입니다.
+
+이 구별은 미묘하지만 중요합니다 -- 여기서 `A.B`는 타입이거나 값일 필요는 없습니다.
+
+## 간단한 조합: 하나의 이름, 여러 의미 (Simple Combinations: One name, multiple meanings)
+
+`A`라는 이름이 있으면, `A`에 대해 타입, 값 또는 네임스페이스라는 세 가지 다른 의미를 찾을 수 있습니다.
+이름을 해석하는 방법은 사용하는 컨텍스트에 따라 다릅니다.
+예를 들어 `let m: A.A = A;` 선언에서,
+  `A`는 먼저 네임스페이스로 사용 된 다음, 타입의 이름으로, 그 다음 값으로 사용됩니다.
+즉 완전히 다른 선언을 의미할 수 있습니다!
+
+약간은 혼란스러워 보이지만, 과하게 사용하지 않는 한 실제로 매우 편리합니다.
+결합 동작의 유용한 측면을 살펴 보겠습니다.
+
+### 내부 조합 (Built-in Combinations)
+
+영리한 사람이라면, *타입*과 *값* 목록에서 `클래스`가 둘 다 나온 것을 눈치챘을 것입니다.
+`class C { }` 선언은 두 가지를 만듭니다:
+  클래스 인스턴스의 형태를 나타내는 *타입* `C`와
+  클래스 생성자를 나타내는 *값* `C` 입니다.
+열거형 선언도 비슷하게 동작합니다.
+
+### 사용자 조합 (User Combinations)
+
+모듈 파일 `foo.d.ts`을 작성했습니다:
+
+```ts
+export var SomeVar: { a: SomeType };
+export interface SomeType {
+  count: number;
+}
+```
+
+그 다음 사용했습니다:
+
+```ts
+import * as foo from './foo';
+let x: foo.SomeType = foo.SomeVar.a;
+console.log(x.count);
+```
+
+잘 작동하지만, `SomeType`과 `SomeVar`는 이름이 같도록
+  밀접하게 관련되어 있다고 상상할 수 있습니다.
+결합을 사용하여 같은 이름 `Bar`로 두 가지 다른 객체 (값과 타입)를 표시 할 수 있습니다:
+
+```ts
+export var Bar: { a: Bar };
+export interface Bar {
+  count: number;
+}
+```
+
+이 경우 사용하는 코드를 구조 분해할 수 있는 아주 좋은 기회입니다:
+
+```ts
+import { Bar } from './foo';
+let x: Bar = Bar.a;
+console.log(x.count);
+```
+
+여기서도 `Bar`를 타입과 값으로 사용했습니다.
+`Bar` 값을 `Bar` 타입으로 선언할 필요가 없다는 점을 유의하세요 -- 저 둘은 독립적입니다.
+
+## 고급 결합 (Advanced Combinations)
+
+선언은 여러 개의 선언에 걸쳐 결합될 수 있습니다.
+예를 들어, `class C { }`와 `interface C { }` 같이 결합할 수 있으며 둘 다 `C` 타입에 프로퍼티를 추가합니다.
+
+충돌을 일으키지 않는다면 충분히 합법적입니다.
+일반적인 경험 법칙은 값의 이름이 `네임스페이스`로 선언되지 않는 한 항상 같은 이름의 다른 값과 충돌하고,
+  타입 별칭 선언(`type s = string`)으로 선언 된 경우 타입이 충돌하며,
+  네임스페이스와는 절대로 충돌하지 않는 것입니다.
+
+어떻게 사용되는지 살펴보겠습니다.
+
+### `인터페이스`를 사용하여 추가하기 (Adding using an `interface`)
+
+`인터페이스`에 다른 `인터페이스` 선언을 사용하여 멤버를 추가할 수 있습니다:
+
+```ts
+interface Foo {
+  x: number;
+}
+// ... 다른 위치 ...
+interface Foo {
+  y: number;
+}
+let a: Foo = ...;
+console.log(a.x + a.y); // 성공
+```
+
+클래스와도 같이 동작합니다:
+
+```ts
+class Foo {
+  x: number;
+}
+// ... 다른 위치 ...
+interface Foo {
+  y: number;
+}
+let a: Foo = ...;
+console.log(a.x + a.y); // 성공
+```
+
+단, 타입 별칭 (`type s = string;`)에는 인터페이스를 사용해서 추가할 수 없습니다.
+
+### `네임스페이스`를 사용하여 추가하기 (Adding using a `namespace`)
+
+`네임스페이스` 선언은 충돌을 일으키지 않는 방식으로 새로운 타입, 값 그리고 네임스페이스를 추가할 수 있습니다.
+
+예를 들어, 클래스에 정적 멤버를 추가할 수 있습니다:
+
+```ts
+class C {
+}
+// ... 다른 위치 ...
+namespace C {
+  export let x: number;
+}
+let y = C.x; // 성공
+```
+
+위 예제에서 `C`의 *정적* 측면(생성자 함수)에 값을 추가했습니다.
+*값*을 추가 했고 모든 값에 대한 컨테이너가 다르기 때문입니다.
+  (타입은 네임스페이스에 포함되고 네임스페이스는 다른 네임스페이스에 포함됩니다).
+
+네임스페이스 타입을 클래스에 추가할 수 있습니다:
+
+```ts
+class C {
+}
+// ... 다른 위치 ...
+namespace C {
+  export interface D { }
+}
+let y: C.D; // 성공
+```
+
+이 예제에서 `namespace` 선언을 작성할 때까지 네임스페이스 `C`는 없었습니다.
+네임스페이스 `C`는 클래스에 의해 생성된 `C`의 값 또는 타입과 충돌하지 않습니다.
+
+마지막으로 `namespace` 선언을 사용하여 다양한 병합을 할 수 있습니다.
+특히 현실적인 예는 아니지만, 흥미로운 동작을 확인할 수 있습니다:
+
+```ts
+namespace X {
+  export interface Y { }
+  export class Z { }
+}
+
+// ... 다른 위치 ...
+namespace X {
+  export var Y: number;
+  export namespace Z {
+    export class C { }
+  }
+}
+type X = string;
+```
+
+위 예제에서 첫 번째 블록은 다음 이름의 의미를 만듭니다:
+
+* 값 `X` (`네임스페이스` 선언은 값 `Z`를 포함하기 때문입니다)
+* 네임스페이스 `X` (`네임스페이스` 선언은 타입 `Y`를 포함하기 때문입니다)
+* `X` 네임스페이스 안의 타입 `Y`
+* `X` 네임스페이스 안의 타입 `Z` (클래스의 인스턴스 형태)
+* `X` 값의 프로퍼티인 값 `Z` (클래스의 생성자 함수)
+
+두 번째 블록은 다음 이름의 의미를 만듭니다:
+
+* `X` 값의 프로퍼티인 값 `Y` (`number` 타입)
+* 네임스페이스 `Z`
+* `X` 값의 프로퍼티인 값 `Z`
+* `X.Z` 네임스페이스 안의 타입 `C`
+* `X.Z` 값의 프로퍼티인 값 `C`
+* 타입 `X`
+
+## `export =` or `import` 사용하기 (Using with `export =` or `import`)
+
+중요한 규칙은 `export`와 `import` 선언이 대상의 *모든 의미* 를 내보내거나 가져온다는 것 입니다.
+
+<!-- TODO: Write more on that. -->
diff --git a/docs/documentation/ko/declaration-files/Do's and Don'ts.md b/docs/documentation/ko/declaration-files/Do's and Don'ts.md
new file mode 100644
index 00000000..7e4e32e9
--- /dev/null
+++ b/docs/documentation/ko/declaration-files/Do's and Don'ts.md	
@@ -0,0 +1,228 @@
+---
+title: Do's and Don'ts
+layout: docs
+permalink: /ko/docs/handbook/declaration-files/do-s-and-don-ts.html
+oneline: "Recommendations for writing d.ts files"
+---
+
+# 일반 타입 (General Types)
+
+## `Number`, `String`, `Boolean`, `Symbol` and `Object`
+
+`Number`, `String`, `Boolean`, `Symbol`, `Object` 타입을 사용*하지 마세요*.
+이 타입들은 JavaScript 코드에서 거의 사용되지 않는 비-원시형 박싱된 객체를 가르킵니다.
+
+```ts
+/* 잘못됨 */
+function reverse(s: String): String;
+```
+
+`number`, `string`, `boolean`, `symbol` 타입을 사용 *하세요*.
+
+```ts
+/* 좋음 */
+function reverse(s: string): string;
+```
+
+`Object` 대신에, [TypeScript 2.2 에 추가된](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-2.html#object-type) 비-원시형 `object`타입을 사용*하세요*.
+
+## 제네릭 (Generics)
+
+타입 매개변수를 사용하지 않는 제네릭 타입을 사용*하지 마세요*. 더 자세한 내용은 [TypeScript FAQ 페이지](https://github.com/Microsoft/TypeScript/wiki/FAQ#why-doesnt-type-inference-work-on-this-interface-interface-foot---)에서 확인하세요.
+
+<!-- TODO: More -->
+
+# 콜백 타입 (Callback Types)
+
+## 콜백의 반환 타입 (Return Types of Callbacks)
+
+<!-- TODO: Reword; these examples make no sense in the context of a declaration file -->
+
+사용하지 않는 콜백의 반환 값 타입에 `any`를 사용*하지 마세요*:
+
+```ts
+/* 잘못됨 */
+function fn(x: () => any) {
+    x();
+}
+```
+
+사용하지 않는 콜백의 반환 값 타입은 `void`를 사용*하세요*:  
+
+```ts
+/* 좋음 */
+function fn(x: () => void) {
+    x();
+}
+```
+
+*이유*: `void`를 사용하면 실수로 `x`의 반환 값을 사용하는 것을 방지 할 수 있기 때문에 더 안전합니다.:
+
+```ts
+function fn(x: () => void) {
+    var k = x(); // oops! meant to do something else
+    k.doSomething(); // error, but would be OK if the return type had been 'any'
+}
+```
+
+## 콜백에서 선택적 매개변수 (Optional Parameters in Callbacks)
+
+정말 의도한 것이 아니라면 콜백에 선택적 매개변수를 사용*하지 마세요*:
+
+```ts
+/* 잘못됨 */
+interface Fetcher {
+    getObject(done: (data: any, elapsedTime?: number) => void): void;
+}
+```
+
+이는 아주 구체적인 의미를 가지고 있습니다: `done` 콜백은 1개 혹은 2개의 인자로 호출될 수 있습니다.
+작성자는 아마 `elapsedTime` 매개변수가 콜백에 상관없다는 것을 말하려는 의도였을 것입니다,
+  하지만 이를 위해 매개변수를 선택적으로 만들 필요는 없습니다 --
+  콜백에 더 적은 인수를 제공하는 것은 항상 허용됩니다.
+
+콜백 매개변수를 비-선택적으로 작성*하세요*:
+
+```ts
+/* 좋음 */
+interface Fetcher {
+    getObject(done: (data: any, elapsedTime: number) => void): void;
+}
+```
+
+## 오버로드와 콜백 (Overloads and Callbacks)
+
+콜백의 인수만 다른 오버로드를 분리해서 작성 *하지 마세요*:
+
+```ts
+/* 잘못됨 */
+declare function beforeAll(action: () => void, timeout?: number): void;
+declare function beforeAll(action: (done: DoneFn) => void, timeout?: number): void;
+```
+
+최대 인수를 사용해 하나의 오버로드를 작성 *하세요*:
+
+```ts
+/* 좋음 */
+declare function beforeAll(action: (done: DoneFn) => void, timeout?: number): void;
+```
+
+*이유*: 콜백이 매개변수를 무시하는 것은 항상 허용되므로, 짧은 오버로드는 필요하지 않습니다.
+더 짧은 콜백을 먼저 작성하면 넘어오는 함수가 첫 번째 오버로드와 일치하기 때문에 잘못된-타입의 함수를 허용합니다.
+
+# 함수 오버로드 (Function Overloads)
+
+## 순서 (Ordering)
+
+더 일반적인 오버로드를 더 구체적인 오버로드 이전에 두지 *마세요*:
+
+```ts
+/* 잘못됨 */
+declare function fn(x: any): any;
+declare function fn(x: HTMLElement): number;
+declare function fn(x: HTMLDivElement): string;
+
+var myElem: HTMLDivElement;
+var x = fn(myElem); // x: any, wat?
+```
+
+구체적인 오버로드 뒤에 일반적인 오버로드가 위치하게 정렬 *하세요*:
+
+```ts
+/* 좋음 */
+declare function fn(x: HTMLDivElement): string;
+declare function fn(x: HTMLElement): number;
+declare function fn(x: any): any;
+
+var myElem: HTMLDivElement;
+var x = fn(myElem); // x: string, :)
+```
+
+*이유*: TypeScript는 함수 호출을 처리할 때 *첫 번째로 일치하는 오버로드*를 선택합니다.
+이전의 오버로드가 뒤에 것보다 "더 구체적"이면, 뒤에 것은 사실상 가려져 호출되지 않습니다.
+
+## 선택적 매개변수 사용 (Use Optional Parameters)
+
+뒤따라오는 매개변수만 다른 오버로드를 작성*하지 마세요*:
+
+```ts
+/* 잘못됨 */
+interface Example {
+    diff(one: string): number;
+    diff(one: string, two: string): number;
+    diff(one: string, two: string, three: boolean): number;
+}
+```
+
+가능한 선택적 매개변수를 사용 *하세요*:
+
+```ts
+/* 좋음 */
+interface Example {
+    diff(one: string, two?: string, three?: boolean): number;
+}
+```
+
+이 문제는 모든 오버로드가 같은 반환 타입을 가질 때만 발생한다는 점에 유의하세요.
+
+*이유*: 두 가지 중요한 이유가 있습니다.
+
+TypeScript는 소스의 인수로 대상의 시그니처를 호출할 수 있는지 확인하여 시그니처 호환성을 결정합니다.
+  *그리고 관계없는 인수가 허용됩니다*
+예를 들어, 이 코드는 선택적 매개변수를 사용하여 올바르게 작성된 경우에만 버그를 노출합니다:
+
+```ts
+function fn(x: (a: string, b: number, c: number) => void) { }
+var x: Example;
+// 오버로드로 작성한 경우, OK -- 첫번째 오버로드가 사용됨
+// 선택적으로 작성한 경우, 올바르게 오류.
+fn(x.diff);
+```
+
+두 번째 이유는 사용자가 TypeScript의 "strict null checking" 기능을 사용할 때입니다.
+JavaScript에서 지정되지 않은 매개변수는 `undefined`로 나타나기 때문에, 일반적으로 선택적 매개변수가 있는 함수에 명시적으로 `undefined`를 전달하는 것이 좋습니다.
+예를 들어, 이 코드는, strict null에서 문제없습니다.
+
+```ts
+var x: Example;
+// 오버로드로 작성한 경우, `undefined`를 `string` 에 전달했기 때문에 잘못된 에러
+// 선택적으로 작성한 경우, 올바름
+x.diff("something", true ? undefined : "hour");
+```
+
+## 유니언 타입 사용 (Use Union Types)
+
+한 인수 위치에서 타입만 다른 오버로드를 사용*하지 마세요*:
+
+```ts
+/* 잘못됨 */
+interface Moment {
+    utcOffset(): number;
+    utcOffset(b: number): Moment;
+    utcOffset(b: string): Moment;
+}
+```
+
+가능한 유니언 타입을 사용 *하세요*:
+
+```ts
+/* 좋음 */
+interface Moment {
+    utcOffset(): number;
+    utcOffset(b: number|string): Moment;
+}
+```
+
+시그니처의 반환 타입이 다르기 때문에 `b`를 선택적으로 만들지 않은 점에 유의하세요.
+
+*이유*: 이는 함수에 값을 "전달하는" 사람들에게 중요합니다.:
+
+```ts
+function fn(x: string): void;
+function fn(x: number): void;
+function fn(x: number|string) {
+    // 분리된 오버로드로 작성된 경우, 잘못된 에러
+    // 유니언 타입으로 작성된 경우, 올바름
+    return moment().utcOffset(x);
+}
+```
diff --git a/docs/documentation/ko/declaration-files/Introduction.md b/docs/documentation/ko/declaration-files/Introduction.md
new file mode 100644
index 00000000..3a6f1622
--- /dev/null
+++ b/docs/documentation/ko/declaration-files/Introduction.md
@@ -0,0 +1,56 @@
+---
+title: Introduction
+layout: docs
+permalink: /ko/docs/handbook/declaration-files/introduction.html
+oneline: "How to write a high-quality TypeScript Declaration (d.ts) file"
+---
+
+이 가이드는 고품질의 TypeScript 선언 파일을 작성하는 방법을 알려주기 위해 작성되었습니다.
+
+이 가이드는, TypeScript 언어에 대한 기본 지식이 있다고 가정합니다.
+만약 기본 지식이 없다면, [TypeScript 핸드북](/docs/handbook/basic-types.html)을 반드시 읽고
+  기본 개념, 특히 타입과 모듈에 익숙해져야 합니다.
+
+# 섹션 (Sections)
+
+이 가이드는 다음 섹션들로 구성됩니다.
+
+## 라이브러리 구조 (Library Structures)
+
+[라이브러리 구조](/docs/handbook/declaration-files/library-structures.html)는 일반적인 라이브러리 포맷과 각 포맷에 대한 올바른 선언 파일을 작성하는 방법에 대해 알려줍니다.
+기존 파일을 수정하는 경우라면, 이 섹션을 읽으실 필요는 없습니다.
+새로운 선언 파일을 작성해야 한다면 라이브러리의 포맷이 선언 파일 작성에 어떻게 영향을 미치는지 올바르게 이해하기 위해 반드시 읽어야 합니다.
+
+## 예제를 통해 (By Example)
+
+많은 경우, 기본 라이브러리 예제만 있을 때, 선언 파일을 작성해야 합니다.
+[예제를 통해](/docs/handbook/declaration-files/by-example.html) 섹션은 많은 API 패턴들과 각 패턴들의 선언을 작성하는 방법을 보여줍니다.
+이 가이드는 TypeScript의 모든 언어 구성에 아직 익숙하지 않은 TypeScript 초심자에 초점을 맞추고 있습니다.
+
+## 해야 할 것과 하지 말아야 할 것 ("Do"s and "Don't"s)
+
+선언 파일의 많은 실수들은 쉽게 피할 수 있습니다.
+[해야 할 것과 하지 말아야 할 것](/docs/handbook/declaration-files/do-s-and-don-ts.html) 섹션은 흔한 오류들을 식별하고,
+  감지하는 방법과,
+  수정하는 방법을 설명합니다.
+흔한 실수들을 피하기 위해 반드시 모두가 이 섹션을 읽어야 합니다.
+
+## 깊게 들어가기 (Deep Dive)
+
+선언 파일이 동작하는 메커니즘에 관심 있는 숙련된 사용자들에게,
+  [깊게 들어가기](/docs/handbook/declaration-files/deep-dive.html) 섹션은 선언 작성의 많은 고급 개념을 설명해 주고,
+  이 개념들을 활용하여 깔끔하고 더 직관적인 선언 파일을 만드는 방법을 보여줍니다.
+
+## 템플릿 (Templates)
+
+[템플릿](/docs/handbook/declaration-files/templates.html)에서는 새로운 파일을 작성할 때, 유용한 시작점을 제공하는
+  여러 선언 파일들을 찾을 수 있습니다.
+[라이브러리 구조](/docs/handbook/declaration-files/library-structures.html) 문서를 참고하여 어떤 템플릿 파일을 사용할지 알아보세요.
+
+## npm에 배포하기 (Publish to npm)
+
+[배포](/docs/handbook/declaration-files/publishing.html) 섹션은 선언 파일을 npm 패키지에 배포하는 방법과, 의존성 패키지를 관리하는 방법을 설명합니다.
+
+## 선언 파일을 찾고 설치하기 (Find and Install Declaration Files)
+
+JavaScript 라이브러리 사용자를 위해, [소비](/docs/handbook/declaration-files/consumption.html) 섹션은 해당 선언 파일을 찾고 설치하는 몇 가지 간단한 방법을 제공합니다.
diff --git a/docs/documentation/ko/declaration-files/Library Structures.md b/docs/documentation/ko/declaration-files/Library Structures.md
new file mode 100644
index 00000000..25fd4ebc
--- /dev/null
+++ b/docs/documentation/ko/declaration-files/Library Structures.md	
@@ -0,0 +1,333 @@
+---
+title: Library Structures
+layout: docs
+permalink: /ko/docs/handbook/declaration-files/library-structures.html
+oneline: How to structure your d.ts files
+---
+
+# 개요 (Overview)
+
+일반적으로, 선언 파일을 *구조화*하는 방법은 라이브러리를 사용하는 방법에 따라 다릅니다.
+JavaScript에서 사용할 라이브러리를 제공하는 방법은 여러 가지가 있고, 이에 맞추어 선언 파일을 작성해야 합니다.
+이 가이드는 일반적인 라이브러리 패턴을 식별하는 방법과, 그 패턴에 상응하는 선언 파일을 작성하는 방법에 대해 다룹니다.
+
+주요 라이브러리 각각의 구조화 패턴 유형은 [템플릿](/docs/handbook/declaration-files/templates.html) 섹션에 있습니다.
+이 템플릿으로 시작하면 더 빠르게 진행할 수 있습니다.
+
+# 라이브러리 종류 식별하기 (Identifying Kinds of Libraries)
+
+첫 번째로, TypeScript 선언 파일이 나타낼 수 있는 라이브러리 종류를 다뤄보겠습니다.
+각 종류의 라이브러리를 *사용하는* 방법과, *작성하는* 방법, 그리고 실제 라이브러리들의 예제를 볼 것입니다.
+
+라이브러리의 구조를 식별하는 것은 선언 파일을 작성하는 첫 단계입니다.
+*사용법*과 *코드*를 기반으로 구조를 식별하는 방법에 대한 힌트를 제공합니다.
+라이브러리의 문서와 구성에 따라서, 어떤 건 다른 것보다 훨씬 쉬울 수 있습니다.
+본인에게 더 편한 것을 사용할 것을 추천합니다.
+
+## 어떤 사항을 고려해야 하는가? (What should you look for?)
+
+라이브러리를 사용하기 전에, 다음 사항을 고려해 볼 수 있습니다.
+
+1. 라이브러리를 다운로드하는 방식이 무엇인가?
+
+   예를 들어, npm으로만 다운로드 할 수 있는가? 아니면 CDN 에서만 다운로드 할 수 있는가?
+
+2. 라이브러리를 임포트하는 방식이 무엇인가?
+
+   전역 객체를 추가하는 방식인가? 아니면 `require` 또는 `import`/`export` 구문을 사용하는 방식인가?
+
+## 여러 종류의 라이브러리에 대한 간단한 샘플
+
+## 모듈형 라이브러리 (Modular Libraries)
+
+어떤 라이브러리는 모듈 로더 환경에서만 동작합니다.
+예를 들어, `express`는 Node.js에서만 동작하고 반드시 CommonJS의 `require` 함수로 로드되어야 합니다.
+
+ECMAScript 2015 (ES2015, ECMAScript 6, ES6로도 잘 알려진), CommonJS와 RequireJS는 *모듈*을 *importing*하는 비슷한 개념을 가지고 있습니다.
+JavaScript의 CommonJS (Node.js)를 예를 들면, 다음과 같이 작성합니다
+
+```js
+var fs = require("fs");
+```
+
+TypeScript나 ES6에서는, `import` 키워드가 같은 목적을 제공합니다:
+
+```ts
+import fs = require("fs");
+```
+
+일반적으로 모듈형 라이브러리의 문서에서 다음 코드들 중 하나를 볼 수 있습니다:
+
+```js
+var someLib = require('someLib');
+```
+
+혹은
+
+```js
+define(..., ['someLib'], function(someLib) {
+
+});
+```
+
+전역 모듈과 마찬가지로 UMD 모듈의 문서에서도 이 예제들을 볼 수 있으므로, 코드나 문서를 반드시 확인하세요.
+
+### 코드에서 모듈 라이브러리 식별하기 (Identifying a Module Library from Code)
+
+모듈형 라이브러리는 일반적으로 다음 중 몇 가지를 반드시 가지고 있습니다:
+
+* `require` 혹은 `define`에 대한 무조건적인 호출
+* `import * as a from 'b';` 혹은 `export c;` 같은 선언문
+* `exports` 혹은 `module.exports`에 대한 할당
+
+다음은 거의 갖지 않습니다:
+
+* `window` 혹은 `global` 프로퍼티 할당
+
+### 모듈을 위한 템플릿 (Templates For Modules)
+
+모듈을 위한 네 가지 템플릿이 있습니다.
+- [`module.d.ts`](/docs/handbook/declaration-files/templates/module-d-ts.html)
+- [`module-class.d.ts`](/docs/handbook/declaration-files/templates/module-class-d-ts.html)
+- [`module-function.d.ts`](/docs/handbook/declaration-files/templates/module-function-d-ts.html)
+- [`module-plugin.d.ts`](/docs/handbook/declaration-files/templates/module-plugin-d-ts.html)
+
+각각이 어떻게 동작하는지에 대한 개요는 [`module.d.ts`](/docs/handbook/declaration-files/templates/module-d-ts.html)를 참조하세요.
+
+만약 모듈을 함수처럼 *호출*할 수 있으면 [`module-function.d.ts`](/docs/handbook/declaration-files/templates/module-function-d-ts.html)을 사용하세요:
+
+```js
+const x = require("foo");
+// 참고: 함수로 'x'를 호출
+const y = x(42);
+```
+
+만약 모듈이 `new`를 사용하여 *생성*될 수 있다면  [`module-class.d.ts`](/docs/handbook/declaration-files/templates/module-class-d-ts.html)를 사용하세요:
+
+```js
+const x = require("bar");
+// 참고: 'new' 연산자를 import된 변수에 사용
+const y = new x("hello");
+```
+
+임포트 되었을 때 다른 모듈에 수정사항을 만드는 모듈을 사용한다면, [`module-plugin.d.ts`](/docs/handbook/declaration-files/templates/module-plugin-d-ts.html) 템플릿을 사용하세요:
+
+```js
+const jest = require("jest");
+require("jest-matchers-files");
+```
+
+## 전역 라이브러리 (Global Libraries)
+
+*전역* 라이브러리는 전역 스코프 (즉, `import` 형식을 사용하지 않음)에서 접근 가능한 라이브러리입니다.
+많은 라이브러리는 사용을 위해 간단히 하나 이상의 전역 변수를 노출합니다.
+예를 들어, [jQuery](https://jquery.com/)를 사용한다면, `$` 변수를 참조해서 사용할 수 있습니다:
+
+```ts
+$(() => { console.log('hello!'); } );
+```
+
+HTML 스크립트 태그로 라이브러리를 사용하는 방법은 라이브러리 문서에서 지침을 볼 수 있습니다:
+
+```html
+<script src="http://a.great.cdn.for/someLib.js"></script>
+```
+
+오늘날, 대부분의 전역에서 접근 가능한 유명 라이브러리들은 실제로 UMD 라이브러리로 작성되어 있습니다 (아래를 참조).
+UMD 라이브러리 문서는 전역 라이브러리 문서와 구별하기 어렵습니다.
+전역 선언 파일을 작성하기 전에, 실제로는 UMD가 아닌지 확인하십시오.
+
+### 코드에서 전역 라이브러리 식별하기 (Identifying a Global Library from Code)
+
+전역 라이브러리 코드는 대게 엄청 간단합니다.
+전역 "Hello, world" 라이브러리는 다음과 같습니다:
+
+```js
+function createGreeting(s) {
+    return "Hello, " + s;
+}
+```
+
+혹은 다음과 같습니다:
+
+```js
+// Web
+window.createGreeting = function (s) {
+  return "Hello, " + s;
+};
+
+// Node
+global.createGreeting = function (s) {
+  return "Hello, " + s;
+};
+
+// Potentially any runtime
+globalThis.createGreeting = function (s) {
+  return "Hello, " + s;
+};
+```
+
+전역 라이브러리의 코드를 보면, 보통 다음을 볼 수 있습니다:
+
+* 최상위 레벨 `var`문 이나 `function`선언
+* 하나 이상의 `window.someName` 할당
+* DOM 인터페이스 `document` 혹은 `window`가 존재한다고 가정
+
+다음은 볼 수 *없습니다*:
+
+* `require` 이나 `define` 같은 모듈 로더 검사 혹은 사용
+* `var fs = require("fs");` 형태의 CommonJS/Node.js-스타일 import
+* `define(...)` 호출
+* 라이브러리를 `require` 혹은 import하는 방법에 대해 설명하는 문서
+
+### 전역 라이브러리 예제 (Examples of Global Libraries)
+
+전역 라이브러리를 UMD 라이브러리로 바꾸는게 쉽기 때문에, 전역 스타일로 작성한 인기 라이브러리는 거의 없습니다.
+하지만, 크기가 작고 DOM이 필요한 (혹은 의존성이 *없는*) 라이브러리는 여전히 전역입니다.
+
+### 전역 라이브러리 템플릿 (Global Library Template)
+
+템플릿 파일 [`global.d.ts`](./templates/global.d.ts.md)은 예제 라이브러리 `myLib`를 정의합니다.
+["이름 충돌 방지" 각주](#preventing-name-conflicts)를 반드시 읽어보세요.
+
+## *UMD*
+
+*UMD* 모듈은 모듈로 (import를 통해) 사용할 수 있고 혹은 전역으로도 (모듈 로더 없는 환경에서 실행될 때) 사용할 수 있습니다.
+[Moment.js](http://momentjs.com/) 같은 많은 유명한 라이브러리들은 이 방법으로 작성되었습니다.
+예를 들어, Node.js나 RequireJS를 사용하면, 다음과 같이 작성합니다:
+
+```ts
+import moment = require("moment");
+console.log(moment.format());
+```
+
+반면 바닐라 브라우저 환경에서는 다음과 같이 쓸 수 있습니다:
+
+```js
+console.log(moment.format());
+```
+
+### UMD 라이브러리 식별하기 (Identifying a UMD library)
+
+[UMD modules](https://github.com/umdjs/umd)은 모듈 로더 환경 유무를 검사합니다.
+이는 다음과 같이 보이는 찾기 쉬운 패턴입니다:
+
+```js
+(function (root, factory) {
+    if (typeof define === "function" && define.amd) {
+        define(["libName"], factory);
+    } else if (typeof module === "object" && module.exports) {
+        module.exports = factory(require("libName"));
+    } else {
+        root.returnExports = factory(root.libName);
+    }
+}(this, function (b) {
+```
+
+만약 라이브러리 코드, 특히 파일 상단에서 `typeof define`, `typeof window` 혹은 `typeof module`에 대한 테스트를 보았다면, 거의 대부분 UMD 라이브러리입니다.
+
+UMD 라이브러리 문서에서는 `require`를 보여주는 "Node.js에서 사용하기" 예제를 종종 설명하고
+  "브라우저에서 사용하기" 예제에서는 `<script>` 태그를 사용해서 스크립트를 로드하는 방법을 보여줍니다.
+
+### UMD 라이브러리 예제 (Examples of UMD libraries)
+
+유명한 라이브러리 대부분은 UMD 패키지로 사용할 수 있습니다.
+예로는 [jQuery](https://jquery.com/), [Moment.js](http://momentjs.com/), [loadash](https://loadash.com/) 등 더 많이 있습니다.
+
+### 템플릿 (Template)
+
+[`module-plugin.d.ts`](/docs/handbook/declaration-files/templates/module-plugin-d-ts.html) 템플릿을 사용하세요.
+
+# <span id="consuming-dependencies" /> 의존성 사용하기 (Consuming Dependencies)
+
+라이브러리가 몇 가지 의존성을 가지고 있을 수 있습니다.
+이번 섹션에서는 선언 파일 안에 의존성을 import 하는 방법을 설명합니다.
+
+## 전역 라이브러리 의존성 (Dependencies on Global Libraries)
+
+만약 라이브러리가 전역 라이브러리에 의존성이 있다면, `/// <reference types="..." />` 디렉티브를 사용하세요:
+
+```ts
+/// <reference types="someLib" />
+
+function getThing(): someLib.thing;
+```
+
+## 모듈 의존성 (Dependencies on Modules)
+
+만약 라이브러리가 모듈에 의존성이 있다면, `import`문을 사용하세요:
+
+```ts
+import * as moment from "moment";
+
+function getThing(): moment;
+```
+
+## UMD 라이브러리 의존성 (Dependencies on UMD libraries)
+
+### 전역 라이브러리에서 (From a Global Library)
+
+만약 전역 라이브러리가 UMD 모듈에 의존성이 있다면, `/// <reference types` 디렉티브를 사용하세요:
+
+```ts
+/// <reference types="moment" />
+
+function getThing(): moment;
+```
+
+### 모듈이나 UMD 라이브러리에서 (From a Module or UMD Library)
+
+만약 모듈이나 UMD 라이브러리가 UMD 라이브러리에 의존성이 있다면, `import`문을 사용하세요:
+
+```ts
+import * as someLib from 'someLib';
+```
+
+UMD 라이브러리에 대한 의존성 선언에 `/// <reference` 디렉티브를 사용하지 *마세요*!
+
+# 각주 (Footnotes)
+
+## <span id="preventing-name-conflicts" /> 이름 충돌 방지하기 (Preventing Name Conflicts)
+
+전역 선언 파일을 작성할 때, 전역 스코프에 많은 타입을 정의할 수 있다는 점을 유의하세요.
+많은 선언 파일이 프로젝트 내에 있을 때, 해결할 수 없는 이름 충돌이 발생할 수 있으므로 이를 사용하지 않는 것이 좋습니다.
+
+따라야 하는 간단한 규칙은 라이브러리가 정의한 전역 변수가 무엇이든 타입을 *네임스페이스*로 정의하는 것입니다.
+예를 들어, 만약 라이브러리가 전역 값 'cats'를 정의하면, 다음과 같이 작성하고
+
+```ts
+declare namespace cats {
+    interface KittySettings { }
+}
+```
+
+이렇게 하지는 *마세요*
+
+```ts
+// 최상위-레벨에서
+interface CatsKittySettings { }
+```
+
+이 가이드는 선언 파일 사용자가 중단하지 않고 라이브러리를 UMD로 전환할 수 있도록 합니다.
+
+## <span id="the-impact-of-es6-on-module-plugins" /> ES6가 모듈 플러그인에 미치는 영향 (The Impact of ES6 on Module Plugins)
+
+어떤 플러그인은 기존 모듈에 최상위 export를 추가하거나 수정합니다.
+CommonJS와 다른 로더에서는 허용되지만, ES6 모듈은 불변하다고 간주되기에 이 패턴은 불가능합니다.
+왜냐하면 TypeScript는 로더에 구애받지 않기에, 이 정책이 컴파일-시간에 적용되지 않지만, ES6 모듈 로더로 전환하려는 개발자는 알고 있어야 합니다.
+
+## 모듈 호출 시그니처에 ES6가 미치는 영향 (The Impact of ES6 on Module Call Signatures)
+
+Express와 같은 많은 유명한 라이브러리들은 import 될 때 호출 가능한 함수를 노출합니다.
+예를 들어, 일반적인 Express 사용법은 다음과 같습니다:
+
+```ts
+import exp = require("express");
+var app = exp();
+```
+
+ES6 모듈 로더에서, 최상위-레벨 객체(여기에서는 `exp`로 import)는 프로퍼티만 가질 수 있습니다;
+  최상위-레벨 모듈 객체는 *절대* 호출할 수 없습니다.
+가장 일반적인 해결책은 호출 가능/생성 가능 객체를 `default` export로 정의하는 것입니다;
+  어떤 모듈 로더 shims은 자동으로 이 상황을 감지하고 최상위-레벨 객체를 `default` export로 바꿉니다.
+만약 `tsconfig.json` 파일에 [`"esModuleInterop": true`](/tsconfig/#esModuleInterop) 라고 되어 있으면, Typescript가 위의 사항을 자동으로 처리합니다.
diff --git a/docs/documentation/ko/declaration-files/Publishing.md b/docs/documentation/ko/declaration-files/Publishing.md
new file mode 100644
index 00000000..d244594d
--- /dev/null
+++ b/docs/documentation/ko/declaration-files/Publishing.md
@@ -0,0 +1,166 @@
+---
+title: Publishing
+layout: docs
+permalink: /ko/docs/handbook/declaration-files/publishing.html
+oneline: How to get your d.ts files to users
+---
+
+이 가이드를 따라 선언 파일을 작성했으므로, 이제 npm에 배포할 시간입니다.
+npm에 선언 파일을 배포하는 방법은 크게 두 가지가 있습니다:
+
+1. npm 패키지로 번들링하거나
+2. npm의 [@types organization](https://www.npmjs.com/~types)에 배포하기
+
+만약 패키지가 TypeScript로 작성되었다면 첫 번째 방법을 사용하는 것이 좋습니다.
+`--declaration` 플래그를 사용하여 선언 파일을 생성하세요.
+이 방법을 사용하면, 선언과 JavaScript가 항상 일치하게 됩니다.
+
+만약 패키지가 TypeScript로 작성되지 않았다면 두 번째 방법을 사용하는 것이 좋습니다.
+
+# npm 패키지에 선언 포함하기 (Including declarations in your npm package)
+
+만약 패키지가 메인 `.js` 파일을 가지고 있다면, 메인 선언 파일을 `package.json`에도 표시해야 합니다.
+번들링된 선언 파일을 `types` 프로퍼티로 가리키도록 하세요.
+예를 들어:
+
+```json
+{
+    "name": "awesome",
+    "author": "Vandelay Industries",
+    "version": "1.0.0",
+    "main": "./lib/main.js",
+    "types": "./lib/main.d.ts"
+}
+```
+
+`"typings"` 필드는 `"types"`와 동의어이기 때문에 역시 사용할 수 있습니다.
+
+또한 `package.json`이 `"files"` 프로퍼티를 포함하고 있으면 `"types"` 프로퍼티는 무시됩니다. 이 경우 메인 선언 파일을 `"files"` 프로퍼티에 전달해야 합니다.
+
+만약 메인 선언 파일 이름이 `index.d.ts`이고 패키지의 루트에 있으면 (`index.js` 옆에) `"types"` 프로퍼티를 쓰지 않아도 되지만, 쓰는 것이 좋습니다.
+
+## 의존성 (Dependencies)
+
+모든 의존성은 npm으로 관리됩니다.
+의존성이 있는 모든 선언 패키지가 `package.json`에 `"dependencies"` 섹션 안에 알맞게 작성되어 있는지 확인하세요.
+예를 들어, Browserify와 TypeScript로 작성된 패키지를 생각해봅시다.
+
+```json
+{
+    "name": "browserify-typescript-extension",
+    "author": "Vandelay Industries",
+    "version": "1.0.0",
+    "main": "./lib/main.js",
+    "types": "./lib/main.d.ts",
+    "dependencies": {
+        "browserify": "latest",
+        "@types/browserify": "latest",
+        "typescript": "next"
+    }
+}
+```
+
+여기에서, 패키지는 `browserify`와 `typescript` 패키지에 의존성이 있습니다.
+`browserify`는 선언 파일이 npm 패키지에 함께 번들링 되지 않기 때문에, `@types/browserify` 선언을 의존성에 추가해야 합니다.
+반면에 `typescript`는 선언 파일이 패키징되기 때문에, 별도의 의존성을 추가할 필요가 없습니다.
+
+이 패키지는 `browserify`와 `typescript` 패키지의 각 선언을 노출하기 때문에, `browserify-typescript-extension` 패키지는 이 의존성들을 가져야 합니다.
+이 이유로, `"devDependencies"`가 아니라 `"dependencies"`를 사용합니다. 왜냐하면 `"devDependencies"`를 사용하면 사용자가 직접 이 패키지들을 설치해야 하기 때문입니다.
+만약에 단지 명령줄 애플리케이션을 작성했고 패키지를 라이브러리로 사용하길 기대하지 않는다면, `devDependencies`를 사용해도 됩니다.
+
+## 경고 플래그 (Red flags)
+
+### `/// <reference path="..." />`
+
+선언 파일에 `/// <reference path="..." />`를 사용하지 *마세요*.
+
+```ts
+/// <reference path="../typescript/lib/typescriptServices.d.ts" />
+....
+```
+
+대신 `/// <reference types="..." />`를 사용*하세요*.
+
+```ts
+/// <reference types="typescript" />
+....
+```
+
+더 자세한 내용을 위해 [의존성 사용하기](./library-structures.md#consuming-dependencies) 섹션을 다시 보십시오.
+
+### 의존적인 선언 패키징하기 (Packaging dependent declarations)
+
+만약 타입 정의가 다른 패키지에 의존적이라면:
+
+* 각 파일은 유지하고 다른 패키지와 합치지 *마세요*.
+* 또한 작성한 패키지에 선언을 복사하지 *마세요*.
+* 만약 npm 타입 선언 패키지가 선언 파일을 패키징하지 않는다면, 해당 패키지에 의존*하세요*.
+
+## Version selection with `typesVersions`
+
+When TypeScript opens a `package.json` file to figure out which files it needs to read, it first looks at a new field called `typesVersions`.
+
+A `package.json` with a `typesVersions` field might look like this:
+
+```json
+{
+  "name": "package-name",
+  "version": "1.0",
+  "types": "./index.d.ts",
+  "typesVersions": {
+    ">=3.1": { "*": ["ts3.1/*"] }
+  }
+}
+```
+
+This `package.json` tells TypeScript to check whether the current version of TypeScript is running.
+If it's 3.1 or later, it figures out the path you've imported relative to the package, and reads from the package's `ts3.1` folder.
+That's what that `{ "*": ["ts3.1/*"] }` means - if you're familiar with path mapping today, it works exactly like that.
+
+In the above example, if we're importing from `"package-name"`, TypeScript will try to resolve from `[...]/node_modules/package-name/ts3.1/index.d.ts` (and other relevant paths) when running in TypeScript 3.1.
+If we import from `package-name/foo`, we'll try to look for `[...]/node_modules/package-name/ts3.1/foo.d.ts` and `[...]/node_modules/package-name/ts3.1/foo/index.d.ts`.
+
+What if we're not running in TypeScript 3.1 in this example?
+Well, if none of the fields in `typesVersions` get matched, TypeScript falls back to the `types` field, so here TypeScript 3.0 and earlier will be redirected to `[...]/node_modules/package-name/index.d.ts`.
+
+## Matching behavior
+
+The way that TypeScript decides on whether a version of the compiler & language matches is by using Node's [semver ranges](https://github.com/npm/node-semver#ranges).
+
+## Multiple fields
+
+`typesVersions` can support multiple fields where each field name is specified by the range to match on.
+
+```json tsconfig
+{
+  "name": "package-name",
+  "version": "1.0",
+  "types": "./index.d.ts",
+  "typesVersions": {
+    ">=3.2": { "*": ["ts3.2/*"] },
+    ">=3.1": { "*": ["ts3.1/*"] }
+  }
+}
+```
+
+Since ranges have the potential to overlap, determining which redirect applies is order-specific.
+That means in the above example, even though both the `>=3.2` and the `>=3.1` matchers support TypeScript 3.2 and above, reversing the order could have different behavior, so the above sample would not be equivalent to the following.
+
+```jsonc tsconfig
+{
+  "name": "package-name",
+  "version": "1.0",
+  "types": "./index.d.ts",
+  "typesVersions": {
+    // NOTE: this doesn't work!
+    ">=3.1": { "*": ["ts3.1/*"] },
+    ">=3.2": { "*": ["ts3.2/*"] }
+  }
+}
+```
+
+# [@types](https://www.npmjs.com/~types)에 배포하기 (Publish to [@types](https://www.npmjs.com/~types))
+
+[@types](https://www.npmjs.com/~types)안에 있는 패키지들은 [타입-배포 도구](https://github.com/Microsoft/types-publisher)를 사용하여 [DefinitelyTyped](https://github.com/DefinitelyTyped/DefinitelyTyped)에서 자동으로 배포되었습니다.
+선언을 @types 패키지로 배포하려면, [https://github.com/DefinitelyTyped/DefinitelyTyped](https://github.com/DefinitelyTyped/DefinitelyTyped)에 pull request를 제출하세요.
+[기여 지침 페이지](http://definitelytyped.org/guides/contributing.html)에서 더 자세한 내용을 찾을 수 있습니다.
diff --git a/docs/documentation/ko/declaration-files/Templates.md b/docs/documentation/ko/declaration-files/Templates.md
new file mode 100644
index 00000000..168dd536
--- /dev/null
+++ b/docs/documentation/ko/declaration-files/Templates.md
@@ -0,0 +1,15 @@
+---
+title: Templates
+layout: docs
+permalink: /ko/docs/handbook/declaration-files/templates.html
+oneline: "Different d.ts module template examples"
+---
+
+[global-modifying-module.d.ts](./templates/global-modifying-module.d.ts.md)
+
+- [global-plugin.d.ts](/docs/handbook/declaration-files/templates/global-plugin-d-ts.html)
+- [global.d.ts](/docs/handbook/declaration-files/templates/global-d-ts.html)
+- [module-class.d.ts](/docs/handbook/declaration-files/templates/module-class-d-ts.html)
+- [module-function.d.ts](/docs/handbook/declaration-files/templates/module-function-d-ts.html)
+- [module-plugin.d.ts](/docs/handbook/declaration-files/templates/module-plugin-d-ts.html)
+- [module.d.ts](/docs/handbook/declaration-files/templates/module-d-ts.html)
diff --git a/docs/documentation/ko/get-started/TS for Functional Programmers.md b/docs/documentation/ko/get-started/TS for Functional Programmers.md
new file mode 100644
index 00000000..d2235ad8
--- /dev/null
+++ b/docs/documentation/ko/get-started/TS for Functional Programmers.md	
@@ -0,0 +1,593 @@
+---
+title: TypeScript for Functional Programmers
+short: TS for Functional Programmers
+layout: docs
+permalink: /ko/docs/handbook/typescript-in-5-minutes-func.html
+oneline: Learn TypeScript if you have a background in functional programming
+---
+
+TypeScript는 웹에 전통적인 객체 지향 프로그램를 가져오기 위해서
+마이크로소프트 프로그래머들이 JavaScript에 전통적인 객체 지향 타입을
+가져오기 위한 시도로 시작되었습니다. 개발되어 가면서 TypeScript의
+타입 시스템은 네이티브 자바스크립터가 작성한 모델 코드로 발전되었습니다.
+결과적인 시스템은 강력하면서 흥미롭고 지저분합니다.
+
+이 소개는 TypeScript를 배우고자 하는 Haskell 또는 ML 프로그래머를
+위해 만들어졌습니다. Haskell 타입 시스템과 TypeScript 타입 시스템의
+차이를 설명합니다.
+또한 JavaScript 코드의 모델링에서 발생하는 TypeScript 타입 시스템의
+독특한 특징을 설명합니다.
+
+이 소개에서는 객체 지향 프로그래밍을 다루지 않습니다.
+실제로, TypeScript의 객체 지향 프로그램은 OO 기능이 있는 다른 인기 언어의
+프로그램과 유사합니다.
+
+# 전제조건 (Prerequisites)
+
+본 서론에서는 다음 사항을 알고 있다고 가정합니다:
+
+* JavaScript로 프로그래밍 하기 위한 핵심 개념.
+* C 계열 언어의 타입 구문.
+
+JavaScript의 핵심 개념을 배우고 싶다면
+[JavaScript: The Good Parts](http://shop.oreilly.com/product/9780596517748.do)를 추천합니다.
+많은 가변성을 가진 call-by-value 렉시컬한 스코프 언어로
+프로그램을 작성하는 방법을 알고 있다면 굳이 책을 안 읽어도
+상관없습니다.
+[R<sup>4</sup>RS Scheme](https://people.csail.mit.edu/jaffer/r4rs.pdf)가 좋은 예입니다.
+
+[C++ 프로그래밍 언어](http://www.stroustrup.com/4th.html)는
+C-스타일 타입 구문에 대해서 배우기 좋습니다.
+C++ 달리 TypeScript는 후위 타입을 사용합니다, 예를 들면: `string x` 대신에 `x: string`.
+
+# Haskell에는 없는 개념 (Concepts not in Haskell)
+
+## 내장 타입 (Built-in types)
+
+JavaScript에서는 7개의 내장 타입을 정의합니다:
+
+| 타입         | 설명                                         |
+| ----------- | ------------------------------------------- |
+| `Number`    | 배정밀도 IEEE 754 부동소수점.                    |
+| `String`    | 수정 불가능한 UTF-16 문자열.                     |
+| `Boolean`   | `true` 와  `false`.                          |
+| `Symbol`    | 보통 키로 사용하는 고유한 값.                       |
+| `Null`      | 단위 타입과 동등.                               |
+| `Undefined` | 또한 단위 타입과 동등.                           |
+| `Object`    | 레코드와 유사한 것.                             |
+
+[자세한 내용은 MDN 페이지를 참고하세요](https://developer.mozilla.org/docs/Web/JavaScript/Data_structures).
+
+TypeScript에는 기본 내장된 타입에 해당하는 원시 타입이 있습니다:
+
+* `number`
+* `string`
+* `boolean`
+* `symbol`
+* `null`
+* `undefined`
+* `object`
+
+### 다른 중요한 TypeScript 타입 (Other important TypeScript types)
+
+| 타입            | 설명                                                         |
+| -------------- | ----------------------------------------------------------- |
+| `unknown`      | 최상위 타입.                                                   |
+| `never`        | 하위 타입.                                                     |
+| 객체 리터럴       | 예, `{ property: Type }`                                     |
+| `void`         | 리턴 타입으로 사용하기 위해 의도된 `undefined` 의 서브타입.             |
+| `T[]`          | 수정가능한 배열들, 또한 `Array<T>` 으로 사용가능                      |
+| `[T, T]`       | 고정된 길이지만 수정 가능한 튜플                                     |
+| `(t: T) => U`  | 함수                                                          |
+
+유의하세요:
+
+1. 함수 구문에는 매개변수 이름이 포함되어 있습니다. 익숙해지기 꽤 어렵습니다!
+
+   ```ts
+   let fst: (a: any, d: any) => any = (a, d) => a;
+   // 또는 좀 더 정확하게 말하자면:
+   let snd: <T, U>(a: T, d: U) => U = (a, d) => d;
+   ```
+
+2. 객체 리터럴 타입 구문이 객체 리터럴 값 구문과 꽤 유사합니다:
+
+   ```ts
+   let o: { n: number; xs: object[] } = { n: 1, xs: [] };
+   ```
+
+3. `[T, T]` 는 `T[]` 의 서브타입입니다. Haskell과 달리, 튜플은 리스트와 관련이 없습니다.
+
+### 박스 형태 타입 (Boxed types)
+
+JavaScript는 프로그래머들이 해당 타입에 접근할 수 있는 메서드를
+포함하는 원시타입을 동등하게 박스해 왔습니다. 예를 들면, 원시 형태의
+`number` 과 박스 형태 타입의 `Number`의 다른 점을 TypeScript는
+반영해왔습니다.
+박스 형태 타입은 메서드가 원시 타입을 반환할 때 아주 드물게 필요합니다.
+
+```ts
+(1).toExponential();
+// 동등하게
+Number.prototype.toExponential.call(1);
+```
+
+숫자 리터럴에서 메서드를 호출하려면 파서를 지원하기 위해 메서드를 괄호
+안에 넣어야 한다는 점에 유의하십시오.
+
+## 점진적인 타이핑 (Gradual typing)
+
+TypeScript는 표현식의 타입을 알 수 없을 때마다 `any` 타입을
+사용합니다. `Dynamic`와 비교하면,`any` 는 타입이라고 부르기에
+과하다고 할 수도 있습니다.
+이 타입이 나타날 때마다 타입을 체크하지 않습니다. 예를 들어, `any[]`
+에 어떤 값이든 체크하지 않고 넣어도 상관없습니다:
+
+```ts
+// tsconfig.json 파일에 "noImplicitAny": false 를 삽입, anys: any[]
+const anys = [];
+anys.push(1);
+anys.push("oh no");
+anys.push({ anything: "goes" });
+```
+
+그리고 `any` 타입은 어디서든 간에 사용가능합니다:
+
+```ts
+anys.map(anys[1]); // 오 안되죠, "oh no" 함수가 아닙니다.
+```
+
+`any` 전염될 수 있는데, 역시 &mdash; 만약에 `any` 타입의 표현식과 함께 변수를 초기화하면,
+변수 역시 `any` 타입을 가집니다.
+
+```ts
+let sepsis = anys[0] + anys[1]; // 어떤 의미로도 가능합니다.
+```
+
+TypeScript는 `any`를 제공할 때 에러가 발생되면,
+`tsconfig.json`에서 `"noImplicitAny": true` 또는 `"strict": true`를 설정해야 합니다.
+
+## 구조적인 타이핑 (Structural typing)
+
+비록 Haskell과 대부분의 ML은 구조적으로 타이핑하지 않지만,
+구조적 타이핑은 대부분의 함수형 프로그래머에게는 익숙한 개념입니다.
+기본 형태는 아주 간단합니다:
+
+```ts
+// @strict: false
+let o = { x: "hi", extra: 1 }; // 성공
+let o2: { x: string } = o; // 성공
+```
+
+여기서, 객체 리터럴 `{ x: "hi", extra : 1 }`에 매치되는
+`{ x : string, extra : number }` 가 있습니다. 이
+타입은 필수 프로퍼티가 모두 있고 해당 프로퍼티에 할당 가능한 타입이 있으므로
+`{ x : string }` 에 할당할 수 있습니다.
+나머지 프로퍼티는 할당을 막지 않고, `{x : string}`의 서브타입으로
+만듭니다.
+
+네임드 타입들은 타입에서 이름을 붙일 뿐입니다. 할당을 위해서라면 타입 별칭
+ `One` 과 인터페이스 타입 `Two` 사이에는 별 다른 점이 없습니다.
+둘 다 `p: string` 프로퍼티를 가지고 있습니다.
+(단, 타입 별칭은 재귀 정의와 타입 매개변수에 관련한 인터페이스에서는 다르게
+동작합니다.)
+
+```ts
+// @errors: 2322
+type One = { p: string };
+interface Two {
+  p: string;
+}
+class Three {
+  p = "Hello";
+}
+
+let x: One = { p: "hi" };
+let two: Two = x;
+two = new Three();
+```
+
+## 유니언 (Unions)
+
+TypeScript에서 유니언 타입은 태그되지 않습니다. 다르게 말하면,
+Haskell에서 `data` 와 달리 유니언은 구별하지 않습니다.
+그러나 다른 프로퍼티나 내장된 태그를 사용하는 유니언으로 타입을 구별할 수 있습니다.
+
+```ts
+function start(
+  arg: string | string[] | (() => string) | { s: string }
+): string {
+  // JavaScript에서 아주 일반적입니다
+  if (typeof arg === "string") {
+    return commonCase(arg);
+  } else if (Array.isArray(arg)) {
+    return arg.map(commonCase).join(",");
+  } else if (typeof arg === "function") {
+    return commonCase(arg());
+  } else {
+    return commonCase(arg.s);
+  }
+
+  function commonCase(s: string): string {
+    // 마지막으로, 다른 문자열로 변환합니다
+    return s;
+  }
+}
+```
+
+`string`, `Array` 와 `Function` 은  타입 조건자가
+내장되어 있고, `else` 브랜치를 위한 객체 타입은 편의를 위해
+남겨두는 게 좋습니다.
+그러나 런타임에 구별하기 어려운 유니언을 생성할 수 있습니다.
+새로운 코드의 경우, 구별하는 유니언만 구축하는 게 가장 좋습니다.
+
+다음 타입들은 조건자를 가지고 있다:
+
+| 타입       | 조건자                               |
+| --------- | ---------------------------------- |
+| string    | `typeof s === "string"`            |
+| number    | `typeof n === "number"`            |
+| bigint    | `typeof m === "bigint"`            |
+| boolean   | `typeof b === "boolean"`           |
+| symbol    | `typeof g === "symbol"`            |
+| undefined | `typeof undefined === "undefined"` |
+| function  | `typeof f === "function"`          |
+| array     | `Array.isArray(a)`                 |
+| object    | `typeof o === "object"`            |
+
+함수와 배열은 런타임에서 객체이지만 고유의 조건자를 가지고 있다는 걸
+기록합시다.
+
+### 교집합
+
+유니언과 더불어 TypeScript은 교집합까지 가지고 있습니다:
+
+```ts
+type Combined = { a: number } & { b: string };
+type Conflicting = { a: number } & { a: string };
+```
+
+`Combined` 은 마치 하나의 객체 리터럴 타입으로 작성된 것 처럼
+`a` 와 `b` 두 개의 속성을 가지고 있습니다. 교집합과 유니언은 재귀적인
+케이스에서 충돌을 일으켜서 `Conflicting.a: number & string` 입니다.
+
+## 유니언 타입 (Unit types)
+
+유니언 타입은 정확히 하나의 원시 값을 포함하고 있는 원시 타입의 서브타입입니다.
+예를 들면, 문자열 `"foo"` 는 타입 `"foo"`를 가지고 있습니다.
+JavaScript는 내장된 enum이 없기 때문에 잘 알려진 문자열 세트를
+대신해서 쓰는게 흔합니다.
+문자열 리터럴 타입 유니언은 TypeScript에서 이 패턴을 따라갑니다:
+
+```ts
+declare function pad(s: string, n: number, direction: "left" | "right"): string;
+pad("hi", 10, "left");
+```
+
+필요한 경우에 컴파일러로 확장가능합니다_ &mdash; 상위 타입으로
+변환합니다 &mdash; 원시 타입에서 유닛 타입으로, `string`에서 `"foo"`으로
+수정가능할 때 일어나며, 수정가능한 변수를 일부 사용할 때 제대로
+동작하지 않을 수 있습니다:
+
+```ts
+// @errors: 2345
+declare function pad(s: string, n: number, direction: "left" | "right"): string;
+// ---cut---
+let s = "right";
+pad("hi", 10, s); // 오류: 'string'은 '"left" | "right"'에 할당할 수 없습니다.
+```
+
+이런 에러가 나타날 수 있습니다:
+
+*-* `"right": "right"`
+*-* `s: string` 은 `"right"` 가 수정가능한 변수에 할당될 때 `string` 으로 확장이 가능합니다.
+*-* `string` 은 `"left" | "right"`에 할당할 수 없습니다.
+
+`s`에 타입 표기를 사용하여 해결 가능하지만,
+그 결과 `"left" | "right"` 타입이 아닌 변수가
+`s`에 할당되는 것을 방지하게 됩니다.
+
+```ts
+declare function pad(s: string, n: number, direction: "left" | "right"): string;
+// ---cut---
+let s: "left" | "right" = "right";
+pad("hi", 10, s);
+```
+
+# Haskell과 비슷한 개념 (Concepts similar to Haskell)
+
+## 문맥적인 타이핑 (Contextual typing)
+
+TypeScript는 변수 선언과 같이 타입을 추론할 수 있는
+몇 가지 분명한 방법이 있습니다:
+
+```ts
+let s = "I'm a string!";
+```
+
+하지만 다른 C-계열 언어로 작업한 적이 있다면 예상하지 못했던
+다른 방법으로 타입 추론이 가능합니다:
+
+```ts
+declare function map<T, U>(f: (t: T) => U, ts: T[]): U[];
+let sns = map((n) => n.toString(), [1, 2, 3]);
+```
+
+여기에서, 이 예시의 `n: number`에서 또한, `T` 과 `U`는 호출 전에
+추론되지 않았음에도 불구하고.
+실제로 `[1,2,3]` 으로 `T=number`을 추론한 다음에,
+`n => n.toString()`의 리턴 타입으로 `U=string`을 추론하여,
+`sns`가 `string[]` 타입을 가지도록 합니다.
+
+추론은 어떤 순서로든 작동하지만, intellisense는 왼쪽에서 오른쪽으로만
+작동하므로, TypeScript는 배열과 함께 `map`을 먼저 선언하는 것을
+선호합니다:
+
+```ts
+declare function map<T, U>(ts: T[], f: (t: T) => U): U[];
+```
+
+문맥적인 타이핑은 또한 객체 리터럴을 통해 재귀적으로 작동하며, 그렇지 않으면
+`string`이나 `number`로 추론 가능한 유닛 타입으로 작동합니다.
+그리고 문맥을 통해서 리턴 타입을 추론할 수 있습니다:
+
+```ts
+declare function run<T>(thunk: (t: T) => void): T;
+let i: { inference: string } = run((o) => {
+  o.inference = "INSERT STATE HERE";
+});
+```
+
+`o` 의 타입은 `{ inference: string }` 으로 결정되었습니다. 왜냐하면
+
+1. 선언 이니셜라이저는 선언 타입: `{ inference: string }`에 따라서
+   문맥적으로 타입이 정해집니다.
+2. 호출의 리턴 타입은 추론을 위해 문맥적인 타입을 사용하기 때문에,
+   컴파일러는 `T={ inference: string }`으로 추론합니다.
+3. 화살표 함수는 매개변수에 타입을 지정하기 위해 문맥적인 타입을 사용하므로,
+   컴파일러는 `o: { inference: string }`를 제공합니다.
+
+입력하는 동안, `o.` 를 타이핑 후에,
+실제 프로그램에 있는 다른 속성과 함께 속성 `inference` 으로
+보완할 수 있습니다.
+이 기능은 TypeScript의 추론을 통해 통합적인 타입 추론 엔진처럼
+보이겠지만, 그렇지 않습니다.
+
+## 타입 별칭 (Type aliases)
+
+타입 별칭은 Haskell의 `type`과 마찬가지로 단순한 별칭입니다.
+컴파일러는 소스 코드에서 사용된 별칭 이름을 사용하려고
+시도하지만 항상 성공하지는 않습니다.
+
+```ts
+type Size = [number, number];
+let x: Size = [101.1, 999.9];
+```
+
+`newtype`과 가장 유사한 것은 _태그된 교차 타입(tagged intersection)_ 입니다:
+
+```ts
+type FString = string & { __compileTimeOnly: any };
+```
+
+`FString`은 컴파일러가 실제로는 존재하지 않는 `__compileTimeOnly`라는
+프로퍼티를 가지고 있다고 생각하는 점을 제외하면 일반 문자열과 같습니다.
+`FString`은 여전히 `string`에 할당 가능하지만,
+그 반대는 불가능하다는 것을 의미합니다.
+
+## 판별 유니언 (Discriminated Unions)
+
+`data`와 가장 유사한 것은 보통 TypeScript에서 판별 유니언이라 불리는,
+ 판별 프로퍼티를 갖는 타입의 유니언입니다:
+
+```ts
+type Shape =
+  | { kind: "circle"; radius: number }
+  | { kind: "square"; x: number }
+  | { kind: "triangle"; x: number; y: number };
+```
+
+Haskell과 달리, 태그 또는 판별은 각각 객체 타입에서 단지 속성에 불구합니다.
+특이 케이스는 다른 유닛 타입과 함께 동일한 속성을 가집니다.
+아직 평범한 유니언타입입니다; 리드하는 `|` 는
+유니언 타입 구문의 선택적인 부분입니다. 유니언을 사용하는 평범한 JavaScript
+코드로 구별가능합니다:
+
+```ts
+type Shape =
+  | { kind: "circle"; radius: number }
+  | { kind: "square"; x: number }
+  | { kind: "triangle"; x: number; y: number };
+
+function area(s: Shape) {
+  if (s.kind === "circle") {
+    return Math.PI * s.radius * s.radius;
+  } else if (s.kind === "square") {
+    return s.x * s.x;
+  } else {
+    return (s.x * s.y) / 2;
+  }
+}
+```
+
+`area` 의 리턴 타입은 `number` 를 나타내는데, TypeScript가 함수가 전체라는
+걸 알고 있기 때문에 유의해야할 필요가 있습니다. 몇몇 특이 케이스가 커버되지 않으면
+`area` 의 리턴 타입은 `number | undefined` 으로 대신될 것입니다.
+
+또한, Haskell과 달리 흔한 속성들은 어떤 유니언에도 나타나며,
+그래서 유용하게 여러 개의 유니언 구분가능합니다:
+
+```ts
+type Shape =
+  | { kind: "circle"; radius: number }
+  | { kind: "square"; x: number }
+  | { kind: "triangle"; x: number; y: number };
+// ---cut---
+function height(s: Shape) {
+  if (s.kind === "circle") {
+    return 2 * s.radius;
+  } else {
+    // s.kind: "square" | "triangle"
+    return s.x;
+  }
+}
+```
+
+## 타입 매개변수 (Type Parameters)
+
+대부분의 C-계열 언어처럼, TypeScript는 타입 매개변수의 선언을
+요구합니다:
+
+```ts
+function liftArray<T>(t: T): Array<T> {
+  return [t];
+}
+```
+
+대소문자에 대한 요구 조건은 없지만, 타입 매개 변수는 일반적으로 단일 대문자입니다.
+타입 매개 변수는 타입 클래스 제약과 비슷하게 동작하는
+타입으로 제한될 수 있습니다.
+
+```ts
+function firstish<T extends { length: number }>(t1: T, t2: T): T {
+  return t1.length > t2.length ? t1 : t2;
+}
+```
+
+TypeScript는 일반적으로 인자 타입에 기반하여 호출로부터 타입 인자를 추론할 수 있기 때문에
+대게 타입 인자를 필요로 하지 않습니다.
+
+왜냐하면 TypeScript는 구조적이기 때문에, 이름 기반의 시스템만큼 타입 매개 변수를 필요로
+하지 않습니다. 특히 함수를 다형성으로 만들
+필요는 없습니다. 타입 매개변수는 매개변수를 같은 타입으로
+제한하는 것처럼 타입 정보를 _전파하는데만_
+쓰여야 합니다:
+
+```ts
+function length<T extends ArrayLike<unknown>>(t: T): number {}
+
+function length(t: ArrayLike<unknown>): number {}
+```
+
+첫 번째 `length`에서 T는 필요하지 않습니다; 오직 한 번만 참조되며,
+다른 매개변수나 리턴 값의 타입을 제한하는데 사용되지 않는다는 것을
+알아둬야 합니다.
+
+### 상위 유형의 타입 (Higher-kinded types)
+
+TypeScript는 상위 유형의 타입이 없습니다. 그러므로 다음과 같이 하는 건 허용하지 않습니다:
+
+```ts
+function length<T extends ArrayLike<unknown>, U>(m: T<U>) {}
+```
+
+### 포인트-프리 프로그래밍 (Point-free programming)
+
+포인트-프리 프로그래밍은 &mdash; 커링 및 함수 합성의 과도한 사용
+&mdash; JavaScript에서 가능하지만 장황할 수 있습니다.
+TypeScript에서 포인트-프리 프로그래밍에 대한 타입 추론이 실패하는 경우가 많으므로,
+값 매개변수 대신 타입 매개변수를 지정하게 됩니다.
+그 결과는 너무 장황해서 보통 포인트-프리 프로그래밍은 피하는 게
+좋습니다.
+
+## 모듈 시스템 (Module system)
+
+`import` 또는 `export`가 포함된 파일이 암시적으로 모듈이라는 점을 제외하면
+JavaScript의 최신 모듈 구문은 Haskell과 약간 유사합니다:
+
+```ts
+import { value, Type } from "npm-package";
+import { other, Types } from "./local-package";
+import * as prefix from "../lib/third-package";
+```
+
+commonjs 모듈로 가져올 수 있습니다 &mdash; node.js' 모듈 시스템으로
+사용된 모듈:
+
+```ts
+import f = require("single-function-package");
+```
+
+export 목록으로 내보낼 수 있습니다:
+
+```ts
+export { f };
+
+function f() {
+  return g();
+}
+function g() {} // g is not exported
+```
+
+또는 개별적으로 표시해서:
+
+```ts
+export function f { return g() }
+function g() { }
+```
+
+후자의 스타일이 더 일반적이지만 같은 파일 내에서도 둘 다
+허용됩니다.
+
+## `readonly` 와 `const` (`readonly` and `const`)
+
+JavaScript에서, 수정 가능함이 기본이지만,
+_참조_가 수정 불가능함을 선언하기 위해 `const`로 변수를 선언할 수 있습니다.
+참조 대상은 여전히 수정 가능합니다:
+
+```js
+const a = [1, 2, 3];
+a.push(102); // ):
+a[0] = 101; // D:
+```
+
+TypeScript는 추가적으로 프로퍼티에 `readonly` 제어자를 사용할 수 있습니다.
+
+```ts
+interface Rx {
+  readonly x: number;
+}
+let rx: Rx = { x: 1 };
+rx.x = 12; // error
+```
+
+매핑된 타입 `Readonly<T>` 은 모든 프로퍼티를 `readonly` 으로
+만들어 버립니다:
+
+```ts
+interface X {
+  x: number;
+}
+let rx: Readonly<X> = { x: 1 };
+rx.x = 12; // error
+```
+
+그리고 부작용을 일으키는 메서드를 제거하고 배열 인덱스에 대한 변경을 방지하는
+특정 `ReadonlyArray<T>` 타입과,
+이 타입에 대한 특수 구문이 있습니다:
+
+```ts
+let a: ReadonlyArray<number> = [1, 2, 3];
+let b: readonly number[] = [1, 2, 3];
+a.push(102); // error
+b[0] = 101; // error
+```
+
+배열과 객체 리터럴에서 동작하는 const-assertion만
+사용할 수 있습니다:
+
+```ts
+let a = [1, 2, 3] as const;
+a.push(102); // error
+a[0] = 101; // error
+```
+
+그러나 이러한 기능들은 기본적인 기능이 아니므로 TypeScript 코드에
+일관적으로 사용하지 않아도 됩니다.
+
+## 다음 단계 (Next Steps)
+
+이 문서는 일상적인 코드에서 높은 수준의 구문과 타입에 대한 개요를 담고 있습니다. 여기서부터는 아래를 참고하시면 됩니다:
+
+*-* 전체 핸드북을 [처음부터 끝까지](/docs/handbook/intro.html) 읽으세요 (30m)
+*-* [Playground 예시](/play#show-examples)를 보세요.
diff --git a/docs/documentation/ko/get-started/TS for JS Programmers.md b/docs/documentation/ko/get-started/TS for JS Programmers.md
new file mode 100644
index 00000000..98c96c1e
--- /dev/null
+++ b/docs/documentation/ko/get-started/TS for JS Programmers.md	
@@ -0,0 +1,298 @@
+---
+title: TypeScript for JavaScript Programmers
+short: TypeScript for JS Programmers
+layout: docs
+permalink: /ko/docs/handbook/typescript-in-5-minutes.html
+oneline: Learn how TypeScript extends JavaScript
+---
+
+현대 프로그래밍 언어에서 TypeScript와 JavaScript의 관계는 다소 독특합니다.
+TypeScript은 JavaScript 위에 레이어로서 자리잡고 있는데, JavaScript의 기능들을 제공하면서 그 위에 자체 레이어를 추가합니다. 이 레이어가 TypeScript 타입 시스템입니다.
+
+JavaScript는 이미 `string`, `number`, `object`, `undefined` 같은 원시 타입을 가지고 있지만, 전체 코드베이스에 일관되게 할당되었는지는 미리 확인해 주지 않습니다. TypeScript는 이 레이어로서 동작합니다.
+
+이는 이미 존재하고 잘 동작하는 JavaScript 코드는 동시에 TypeScript 코드라는 의미지만, TypeScript의 타입 검사기는 사용자가 생각한 일과 JavaScript가 실제로 하는 일 사이의 불일치를 강조할 수 있습니다.
+
+이 튜토리얼은 TypeScript가 추가하는 타입 시스템 언어 확장을 이해하는데 중점을 두고 타입 시스템에 대한 5분 개요를 제공합니다.
+
+## 타입 추론 (Types by Inference)
+
+TypeScript는 JavaScript 언어를 알고 있으며 대부분의 경우 타입을 생성해줄 것입니다.
+예를 들어 변수를 생성하면서 동시에 특정 값에 할당하는 경우, TypeScript는 그 값을 해당 변수의 타입으로 사용할 것입니다.
+
+```ts
+let helloWorld = "Hello World";
+//  ^?
+```
+
+JavaScript가 동작하는 방식을 이해함으로써 TypeScript는 JavaScript 코드를 받아들이면서 타입을 가지는 타입 시스템을 구축할 수 있습니다. 이는 코드에서 타입을 명시하기 위해 추가로 문자를 사용할 필요가 없는 타입 시스템을 제공합니다. 이것이 위의 예제에서 TypeScript가 `helloWorld`가 `string`임을 알게 되는 방식입니다.
+
+JavaScript와 함께 VS Code를 사용하고 작업을 할 때 편집기의 자동 완성 기능을 사용해왔을 것입니다.
+이는 TypeScript에 필수불가결한 JavaScript에 대한 이해가 JavaScript 작업을 개선하기 위해 내부적으로 사용되었기 때문입니다.
+
+## 타입 정의하기 (Defining Types)
+
+JavaScript는 다양한 디자인 패턴을 가능하게 하는 동적 언어입니다. 몇몇 디자인 패턴은 자동으로 타입을 제공하기 힘들 수 있는데 (동적 프로그래밍을 사용하고 있을 것이기 때문에) 이러한 경우에 TypeScript는 TypeScript에게 타입이 무엇이 되어야 하는지 명시 가능한 JavaScript 언어의 확장을 지원합니다.
+
+다음은 `name: string`과 `id: number`을 포함하는 추론 타입을 가진 객체를 생성하는 예제입니다.
+
+```ts
+const user = {
+  name: "Hayes",
+  id: 0,
+};
+```
+
+이 객체의 형태를 명시적으로 나타내기 위해서는 `interface` 로 선언합니다.
+
+```ts
+interface User {
+  name: string;
+  id: number;
+}
+```
+
+이제 변수 선언 뒤에  `: TypeName`의 구문을 사용해 JavaScript 객체가 새로운 `interface`의 형태를 따르고 있음을 선언할 수 있습니다.
+
+```ts
+interface User {
+  name: string;
+  id: number;
+}
+// ---cut---
+const user: User = {
+  name: "Hayes",
+  id: 0,
+};
+```
+
+해당 인터페이스에 맞지 않는 객체를 생성하면 TypeScript는 경고를 줍니다.
+
+```ts
+// @errors: 2322
+interface User {
+  name: string;
+  id: number;
+}
+
+const user: User = {
+  username: "Hayes",
+  id: 0,
+};
+```
+
+JavaScript는 클래스와 객체 지향 프로그래밍을 지원하기 때문에, TypeScript 또한 동일합니다. - 인터페이스는 클래스로도 선언할 수 있습니다.
+
+```ts
+interface User {
+  name: string;
+  id: number;
+}
+
+class UserAccount {
+  name: string;
+  id: number;
+
+  constructor(name: string, id: number) {
+    this.name = name;
+    this.id = id;
+  }
+}
+
+const user: User = new UserAccount("Murphy", 1);
+```
+
+인터페이스는 함수에서 매개변수와 리턴 값을 명시하는데 사용되기도 합니다.
+
+```ts
+// @noErrors
+interface User {
+  name: string;
+  id: number;
+}
+// ---cut---
+function getAdminUser(): User {
+  //...
+}
+
+function deleteUser(user: User) {
+  // ...
+}
+```
+
+JavaScript에서 사용할 수 있는 적은 종류의 원시 타입이 이미 있습니다.: `boolean`, `bigint`, `null`, `number`, `string`, `symbol`, `object`와 `undefined`는 인터페이스에서 사용할 수 있습니다. TypeScript는 몇 가지를 추기해 목록을 확장합니다. 예를 들어, `any` (무엇이든 허용합니다), [`unknown`](/en/play#example/unknown-and-never) (이 타입을 사용하는 사람이 타입이 무엇인지 선언했는가를 확인하십시오), [`never`](/en/play#example/unknown-and-never) (이 타입은 발생될 수 없습니다) `void` (`undefined`를 리턴하거나 리턴 값이 없는 함수).
+
+타입을 구축하기 위한 두 가지 구문이 있다는 것을 꽤 빠르게 알 수 있을 것입니다.: [Interfaces and Types](/play/?e=83#example/types-vs-interfaces) - `interface`를 우선적으로 사용하고 특정 기능이 필요할 때 `type`을 사용해야 합니다.
+
+## 타입 구성 (Composing Types)
+
+객체들을 조합하여 더 크고 복잡한 객체를 만드는 방법과 유사하게 TypeScript에 타입으로 이를 수행하는 도구가 있습니다.
+여러가지 타입을 이용하여 새 타입을 작성하기 위해 일상적인 코드에서 가장 많이 사용되는 두 가지 코드로는 유니언(Union)과 제네릭(Generic)이 있습니다.
+
+### 유니언 (Unions)
+
+유니언은 타입이 여러 타입 중 하나일 수 있음을 선언하는 방법입니다. 예를 들어, `boolean` 타입을 `true` 또는 `false`로 설명할 수 있습니다:
+
+```
+type MyBool = true | false;
+```
+
+_참고:_ `MyBool`위에 마우스를 올린다면, `boolean`으로 분류된 것을 볼 수 있습니다 - 구조적 타입 시스템의 프로퍼티며, 나중에 살펴보겠습니다.
+
+유니언 타입이 가장 많이 사용된 사례 중 하나는 값이 다음과 같이 허용되는 `string` 또는 `number`의 [리터럴](/docs/handbook/literal-types.html)집합을 설명하는 것입니다:
+
+```
+type WindowStates = "open" | "closed" | "minimized";
+type LockStates = "locked" | "unlocked";
+type OddNumbersUnderTen = 1 | 3 | 5 | 7 | 9;
+```
+
+유니언은 다양한 타입을 처리하는 방법을 제공하는데, 예를 들어 `array` 또는 `string`을 받는 함수가 있을 수 있습니다.
+
+```
+function getLength(obj: string | string[]) {
+  return obj.length;
+}
+```
+
+TypeScript는 코드가 시간에 따라 변수가 변경되는 방식을 이해하며, 이러한 검사를 사용해 타입을 골라낼 수 있습니다.
+
+| Type      | Predicate                          |
+| --------- | ---------------------------------- |
+| string    | `typeof s === "string"`            |
+| number    | `typeof n === "number"`            |
+| boolean   | `typeof b === "boolean"`           |
+| undefined | `typeof undefined === "undefined"` |
+| function  | `typeof f === "function"`          |
+| array     | `Array.isArray(a)`                 |
+
+예를 들어, `typeof obj === "string"`을 이용하여 `string`과 `array`를 구분할 수 있으며 TypeScript는 객체가 다른 코드 경로에 있음을 알게 됩니다.
+
+<!-- prettier-ignore -->
+```
+function wrapInArray(obj: string | string[]) {
+  if (typeof obj === "string") {
+    return [obj];
+//          ^?
+  } else {
+    return obj;
+  }
+}
+```
+
+### 제네릭 (Generics)
+
+TypeScript 제네릭 시스템에 대해 자세히 알아볼 수 있지만, 1분 정도의 수준 높은 설명을 하기 위해, 제네릭은 타입에 변수를 제공하는 방법입니다.
+
+배열이 일반적인 예시이며, 제네릭이 없는 배열은 어떤 것이든 포함할 수 있습니다. 제네릭이 있는 배열은 배열 안의 값을 설명할 수 있습니다.
+
+```ts
+type StringArray = Array<string>;
+type NumberArray = Array<number>;
+type ObjectWithNameArray = Array<{ name: string }>;
+```
+
+제네릭을 사용하는 고유 타입을 선언할 수 있습니다:
+
+```
+// @errors: 2345
+interface Backpack<Type> {
+  add: (obj: Type) => void;
+  get: () => Type;
+}
+
+// 이 줄은 TypeScript에 `backpack`이라는 상수가 있음을 알리는 지름길이며
+// const backpack: Backpack<string>이 어디서 왔는지 걱정할 필요가 없습니다.
+declare const backpack: Backpack<string>;
+
+// 위에서 Backpack의 변수 부분으로 선언해서, object는 string입니다.
+const object = backpack.get();
+
+// backpack 변수가 string이므로, add 함수에 number를 전달할 수 없습니다.
+backpack.add(23);
+```
+
+## 구조적 타입 시스템 (Structural Type System)
+
+TypeScript의 핵심 원칙 중 하나는 타입 검사가 값이 있는 _형태_에 집중한다는 것입니다.
+이는 때때로 "덕 타이핑(duck typing)" 또는 "구조적 타이핑" 이라고 불립니다.
+
+구조적 타입 시스템에서 두 객체가 같은 형태를 가지면 같은 것으로 간주됩니다.
+
+```
+interface Point {
+  x: number;
+  y: number;
+}
+
+function printPoint(p: Point) {
+  console.log(`${p.x}, ${p.y}`);
+}
+
+// "12, 26"를 출력합니다
+const point = { x: 12, y: 26 };
+printPoint(point);
+```
+
+`point`변수는 `Point`타입으로 선언된 적이 없지만, TypeScript는 타입 검사에서 `point`의 형태와 `Point`의 형태를 비교합니다.
+둘 다 같은 형태이기 때문에, 통과합니다.
+
+형태 일치에는 일치시킬 객체의 필드의 하위 집합만 필요합니다.
+
+```
+// @errors: 2345
+interface Point {
+  x: number;
+  y: number;
+}
+
+function printPoint(p: Point) {
+  console.log(`${p.x}, ${p.y}`);
+}
+// ---cut---
+const point3 = { x: 12, y: 26, z: 89 };
+printPoint(point3); // prints "12, 26"
+
+const rect = { x: 33, y: 3, width: 30, height: 80 };
+printPoint(rect); // prints "33, 3"
+
+const color = { hex: "#187ABF" };
+
+printPoint(color);
+```
+
+마지막으로, 정확하게 마무리 짓기 위해, 구조적으로 클래스와 객체가 형태를 따르는 방법에는 차이가 없습니다:
+
+```
+// @errors: 2345
+interface Point {
+  x: number;
+  y: number;
+}
+
+function printPoint(p: Point) {
+  console.log(`${p.x}, ${p.y}`);
+}
+// ---cut---
+class VirtualPoint {
+  x: number;
+  y: number;
+
+  constructor(x: number, y: number) {
+    this.x = x;
+    this.y = y;
+  }
+}
+
+const newVPoint = new VirtualPoint(13, 56);
+printPoint(newVPoint); // prints "13, 56"
+```
+
+객체 또는 클래스에 필요한 모든 속성이 존재한다면, TypeScript는 구현 세부 정보에 관계없이 일치하게 봅니다.
+
+## 다음 단계 (Next Steps)
+
+해당 문서는 일상적인 코드에서 사용하는 구문 및 도구의 종류에 대한 수준 높은 5분 개요입니다. 여기에서:
+
+* 전체 핸드북을 [처음부터 끝까지](/docs/handbook/intro.html) 읽으세요(30분)
+* [Playground 예시](/play#show-examples)를 탐색하세요.
diff --git a/docs/documentation/ko/get-started/TS for OOPers.md b/docs/documentation/ko/get-started/TS for OOPers.md
new file mode 100644
index 00000000..14344438
--- /dev/null
+++ b/docs/documentation/ko/get-started/TS for OOPers.md	
@@ -0,0 +1,191 @@
+---
+title: TypeScript for Java/C# Programmers
+short: TS for Java/C# Programmers
+layout: docs
+permalink: /ko/docs/handbook/typescript-in-5-minutes-oop.html
+oneline: Learn TypeScript if you have a background in object-oriented languages
+---
+
+TypeScript는 C#, Java와 같이 정적 타이핑을 사용하는 언어에 익숙한 프로그래머들에게 인기 있는 선택입니다.
+
+TypeScript의 타입 시스템은 더 나은 코드 완성, 오류의 조기 발견, 프로그램 부분 간의 더 명확한 통신과 같이 정적 타이핑이 가지는 많은 이점을 제공합니다.
+TypeScript는 이러한 개발자에게 친숙한 기능을 많이 제공하지만, JavaScript(또한 TypeScript도 마찬가지로)가 기존의 객체 지향 프로그래밍(OOP) 언어와 어떤 차이가 있는지 다시 살펴볼 필요가 있습니다.
+이러한 차이점을 이해하는 것은 더 나은 JavaScript 코드를 작성하는데 도움을 줄 것이고, C#/Java에서 TypeScript로 바로 입문한 프로그래머가 겪는 흔한 함정을 피할 수 있을 것입니다.
+
+## JavaScript 함께 배우기 (Co-learning JavaScript)
+
+만약 JavaScript에 이미 익숙하지만 주로 Java또는 C#을 사용하는 프로그래머라면, 이 소개 페이지는 흔히 접할 수 있는 오해와 함정에 대한 설명에 도움을 줄 수 있습니다.
+TypeScript 모델이 유형화하는 방법 중 일부는 Java나 C#과 상당히 다르며, TypeScript를 학습하는 데에 있어 이 부분을 염두에 두는 것이 중요합니다.
+
+만약 JavaScript를 처음 접하는 Java나 C# 프로그래머라면, JavaScript의 런타임 동작을 이해하기 위해 우선적으로 타입을 _제외한_ JavaScript의 일부분을 배우는 것이 좋습니다.
+TypeScript는 코드를 _실행하는_ 방식을 바꾸지 않기 때문에, 실제로 무언가 동작하는 코드를 작성하기 위해서는 여전히 JavaScript가 어떻게 작동하는지 배워야 합니다!
+
+TypeScript가 JavaScript와 동일한 *런타임*을 사용하므로, 특정한 런타임 동작(문자열을 숫자로 변환하기, 경고 표시, 디스크에 파일 쓰기 등)을 구현하려는 리소스는 항상 TypeScript 프로그램에 똑같이 잘 적용된다는 점을 기억하는 것은 매우 중요합니다.
+TypeScript에 특정된 리소스에만 제한을 두지 마십시오!
+
+## 클래스 다시 생각하기 (Rethinking the Class)
+
+C#과 Java는 _의무적 OOP_ 언어라고 부릅니다.
+이러한 언어에서 *클래스*는 코드 구성의 기본 단위일 뿐만 아니라 런타임 시 모든 데이터 _그리고_ 동작의 기본적인 컨테이너입니다.
+기능과 데이터를 전부 클래스에 담도록 강제하는 것은 일부 문제에 대해선 좋은 도메인 모델이 될 수 있지만, 모든 도메인이 이러한 방식으로 표현될 *필요*는 없습니다.
+
+### 자유로운 함수와 데이터 (Free Functions and Data)
+
+JavaScript에서 함수는 어디에나 있을 수 있고, 데이터를 미리 정의된 ‘class’나 ‘struct’에 속하지 않고 자유롭게 전달할 수 있습니다.
+이러한 유연성은 매우 강력합니다.
+OOP 계층과 상관 없이 데이터를 처리하는 “자유로운” (클래스와 연관되지 않은) 함수는 프로그램을 JavaScript로 작성하는 모델로 선호됩니다.
+
+### 정적 클래스 (Static Classes)
+
+추가적으로, C#과 Java의 싱글턴과 정적 클래스 같은 특정 구조는 TypeScript에서 필요하지 않습니다.
+
+## TypeScript의 OOP (OOP in TypeScript)
+
+즉, 원한다면 계속 클래스를 사용해도 됩니다!
+일부 문제는 기존의 OOP 계층으로 해결하기 적합하며, TypeScript가 JavaScript의 클래스를 지원하므로 이러한 모델을 더 효과적으로 만듭니다.
+TypeScript는 인터페이스, 상속, 정적 메서드 구현과 같은 많은 일반적인 패턴을 지원합니다.
+
+우리는 이 가이드의 뒷부분에서 클래스를 다룰 것입니다.
+
+## 타입 다시 생각하기 (Rethinking Types)
+
+TypeScript의 *타입*에 대한 이해는 사실 C#이나 Java와 상당히 다릅니다.
+몇 가지 차이점을 살펴봅시다.
+
+### 이름으로 구체화된 타입 시스템 (Nominal Reified Type Systems)
+
+C#과 Java에서 주어진 값과 객체는 ‘null’, 원시 타입, 또는 정의된 클래스 타입 중 정확하게 하나의 타입을 가집니다.
+런타임 시점에서 정확한 타입을 묻기 위해 `value.GetType()` 또는 `value.getClass()`와 같은 메서드를 호출할 수 있습니다.
+이러한 타입의 정의는 특정한 이름을 갖고 클래스의 어딘가 존재하며, 명시적인 상속관계나 공통적으로 구현된 인터페이스가 없는 이상 두 클래스가 유사한 형태를 가졌다 해도 서로 대체하여 사용할 수 없습니다.
+
+이러한 양상은 *reified, nominal* 타입 시스템을 설명합니다.
+코드에서 사용한 타입은 런타임 시점에 존재하며, 타입은 구조가 아닌 선언을 통해 연관 지어집니다.
+
+### 집합으로서의 타입 (Types as Sets)
+
+C# 또는 Java에서 런타임 타입과 해당 컴파일 타임 선언 사이의 일대일 대응관계는 중요합니다.
+
+TypeScript에서 타입은 공통의 무언가를 공유하는 *값의 집합*으로 생각하는 것이 좋습니다.
+타입은 집합에 불과하기 때문에, 특정한 값은 동시에 _수많은_ 집합에 속할 수 있습니다.
+
+일단 타입을 집합으로 생각하기 시작하면, 특정 연산이 매우 자연스러워집니다.
+예를 들어, C#에서는 ‘string’과 ‘int’ *둘 다 가능한* 타입이 존재하지 않기 때문에 이 값을 인자로 전달하는 것은 이상합니다.
+
+TypeScript에서 모든 타입이 단순히 집합이라는 것을 깨닫는 순간 이는 매우 자연스러워집니다.
+‘string’ 집합 또는 ‘number’ 집합에 속할 수 있는 값을 어떻게 설명하시겠습니까?
+이 값은 단순히 그 집합들의 *유니언*: ‘string | number’에 속합니다.
+
+TypeScript는 집합론에 의거해 타입을 이용하는 여러 방법을 제공하며, 타입을 집합으로 생각하는 것이 더 직관적입니다.
+
+### 삭제된 구조적 타입 (Erased Structural Types)
+
+TypeScript에서, 객체는 정확히 단일 타입이 _아닙니다_.
+예를 들어 인터페이스를 만족하는 객체를 생성할 때, 둘 사이의 선언적인 관계가 없더라도 해당 인터페이스가 예상되는 곳에 해당 객체를 사용할 수 있습니다.
+
+```
+interface Pointlike {
+  x: number;
+  y: number;
+}
+interface Named {
+  name: string;
+}
+
+function printPoint(point: Pointlike) {
+  console.log("x = " + point.x + ", y = " + point.y);
+}
+
+function printName(x: Named) {
+  console.log("Hello, " + x.name);
+}
+
+const obj = {
+  x: 0,
+  y: 0,
+  name: "Origin",
+};
+
+printPoint(obj);
+printName(obj);
+```
+
+TypeScript의 타입 시스템은 명목이 아닌 _구조적_입니다: `obj`는 숫자인 `x`와 `y` 프로퍼티를 가지고 있으므로, `Pointlike`로써 사용될 수 있습니다.
+타입 간의 관계는 특정 관계로 선언되었는지가 아닌, 포함된 프로퍼티에 의해 결정됩니다.
+
+TypeScript의 타입 시스템은 또한 _구체화되지 않았습니다_: 런타임에 `obj`가 `Pointlike`임을 알려주지 않습니다.
+사실, `Pointlike` 타입은 런타임에 _어떤 형태로도_ 존재하지 않습니다.
+
+_집합으로서의 타입_ 개념으로 보면, `obj`를 `Pointlike` 값 집합이나 `Named` 값 집합의 멤버로 간주할 수 있습니다.
+
+### 구조적 타입화의 결과 (Consequences of Structural Typing)
+
+객체지향 프로그래머는 종종 구조적 타입화의 두 가지 측면에 놀라곤 합니다.
+
+#### 빈 타입 (Empty Types)
+
+첫 번째로 _빈 타입_은 예상을 무시하는 것처럼 보입니다:
+
+```
+class Empty {}
+
+function fn(arg: Empty) {
+  // 무엇인가를 하나요?
+}
+
+// 오류는 없지만, '빈' 타입은 아니지 않나요?
+fn({ k: 10 });
+```
+
+TypeScript는 주어진 인수가 유효한 `Empty`인지 확인하여 `fn`의 호출이 유효한지를 검사합니다
+`{ k: 10 }`과 `class Empty { }`의 _구조를 확인하여 유효성을 검사합니다.
+`Empty`에 프로퍼티가 없으므로 `Empty`가 수행하는 _모든_ 프로퍼티가 `{ k: 10 }`에 속해있습니다.
+그러므로, 유효한 호출입니다:
+
+놀랍지만, 최종적으로 명목적인 객체지향프로그래밍 언어와 매우 비슷하게 사용됩니다.
+파생 클래스와 파생 클래스의 기본 사이의 자연스러운 하위 타입 관계가 파괴되기 때문에, 하위 클래스는 _삭제_할 수 없습니다.
+구조적 타입 시스템은 호환 가능한 유형의 속성을 갖는 측면에서 하위 타입을 설명하므로 위의 관계를 암시적으로 구별합니다
+
+#### 동일한 타입 (Identical Types)
+
+또 다른 빈번한 놀라움의 원인은 동일한 타입에 기인합니다:
+
+```ts
+class Car {
+  drive() {
+    // hit the gas
+  }
+}
+class Golfer {
+  drive() {
+    // hit the ball far
+  }
+}
+
+// No error?
+let w: Car = new Golfer();
+```
+
+다시 말하지만, 오류가 아닌 이유는 클래스의 _구조_가 동일하기 때문입니다.
+잠재적인 혼란의 이유가 될 수도 있겠지만, 사실 상관없는 클래스가 동일한 경우는 일반적이지 않습니다.
+
+차후에 클래스 챕터에서 클래스가 서로 어떻게 관련되는지에 대해 자세히 알아볼 것입니다.
+
+### 반영 (Reflection)
+
+객체지향 프로그래머는 제네릭을 포함하여 어떤 값의 유형이라도 다룰(query)수 있음에 익숙합니다.
+
+```csharp
+// C#
+static void PrintType<T>() {
+    Console.WriteLine(typeof(T).Name);
+}
+```
+
+TypeScript의 타입 시스템이 완벽히 지워졌으므로, 제네릭 타입 인자의 인스턴스화와 같은 정보는 런타임에 사용할 수 없습니다.
+
+JavaScript에는 `typeof`와 `instanceof`와 같은 제한된 원시요소가 있지만, 이런 연산자는 타입이 지워진 코드의 출력에 존재하므로 여전히 작동함을 알아야 합니다.
+예를 들어, `typeof (new Car())`는 `Car`나 `"Car"`가 아닌 `"object"`입니다.
+
+---
+
+지금까지 개요였고, 여기에서 [핸드북](/docs/handbook/intro.html)을 읽거나 또는 [Playground 예제](/play#show-examples)를 탐색하세요.
diff --git a/docs/documentation/ko/get-started/TS for the New Programmer.md b/docs/documentation/ko/get-started/TS for the New Programmer.md
new file mode 100644
index 00000000..17d74460
--- /dev/null
+++ b/docs/documentation/ko/get-started/TS for the New Programmer.md	
@@ -0,0 +1,187 @@
+---
+title: TypeScript for the New Programmer
+short: TS for the New Programmer
+layout: docs
+permalink: /ko/docs/handbook/typescript-from-scratch.html
+oneline: Learn TypeScript from scratch
+---
+
+첫 번째 언어로 TypeScript를 고른것을 축하드립니다 - 정말로 좋은 결정입니다!
+
+Typescript가 Javascript의 "기호(flavor)"나 "변형(variant)"이라는 것을 들어봤을 겁니다.
+TypeScript(TS)와 JavaScript(JS)의 관계는 현대 프로그래밍 언어에서 꽤 독특한 관계이니, 이 관계를 더 배우는 것은 어떻게 TypeScript를 JavaScript에 추가할지에 도움이 될 것입니다.
+
+## JavaScript의 짧은 역사 (What is JavaScript? A Brief History)
+
+JavaScript(ECMAScript으로도 알려져있는)는 처음에 브라우저를 위한 스크립팅 언어로 만들어졌습니다.
+JavaScript가 처음 나왔을 때, 수십 줄 이상의 코드를 작성하는 것은 다소 이례적인 일이었기에 웹 페이지 속 짧은 코드들을 위해 사용할 것으로 여겨졌습니다.
+때문에, 초기 웹 브라우저들은 수십 줄 이상의 코드를 실행하는데 오래 걸렸습니다.
+그러나 시간이 흘러 JS가 점점 더 유명해지면서, 웹 개발자들은 JS를 이용해 상호작용을 하는 경험을 하기 시작했습니다.
+
+웹 브라우저 개발자들은 위와 같이 늘어나는 JS 사용량에 대하여 실행 엔진(동적 컴파일)을 최적화시키고 최적화 된 것을 이용해 할 수 있는 일(API 추가)을 확장하여 웹 개발자가 더 많이 JS를 사용할 수 있게 했습니다.
+현대 웹사이트에서, 브라우저는 수십만 줄의 코드로 구성된 어플리케이션을 자주 실행합니다.
+이는 정적 페이지의 간단한 네트워크로 시작해서, 모든 종류의 만족스러울만한 _어플리케이션_을 위한 플랫폼으로 성장한 "웹"의 길고 점진적인 성장입니다.
+
+이외에도, JS는 node.js를 사용하여 JS 서버들을 구현하는 것처럼, 브라우저 맥락에서 벗어나는 일에 사용하기 충분할 정도로 유명해졌습니다.
+"어디서든 작동됨"과 같은 JS의 성질은 교차 플랫폼(cross-platform) 개발을 위한 매력적인 선택지이기도 합니다.
+오늘날 많은 개발자들은 _오직_ JavaScript만을 이용하여 전체 스택을 프로그래밍하고 있습니다!
+
+요약하자면, 우리에게는 빠른 사용을 위해 설계되었으며 수백만 줄의 어플리케이션들을 작성하기 위해 만들어진 완벽한 도구인 JavaScript가 있습니다.
+모든 언어는 각자의 _별난 점_ - 이상한 점과 놀랄만한 점이 있으며, JavaScript의 자랑스럽지만은 않은 시작은 _많은_ 문제를 만들게 되었습니다. 예를 들어:
+
+* JavaScript의 동일 연산자는 (`==`) 인수를 _강제로 변환하여(coerces)_, 예기치 않은 동작을 유발합니다:
+
+  ```js
+  if ("" == 0) {
+    // 참입니다! 근데 왜죠??
+  }
+  if (1 < x < 3) {
+    // *어떤* x 값이던 참입니다!
+  }
+  ```
+
+* JavaScript는 또한 존재하지 않는 프로퍼티의 접근을 허용합니다:
+
+  ```js
+  const obj = { width: 10, height: 15 };
+  // 왜 이게 NaN이죠? 철자가 어렵네요!
+  const area = obj.width * obj.heigth;
+  ```
+
+대부분의 프로그래밍 언어는 이런 종류의 오류들이 발생하면 오류를 표출해주고, 일부는 코드가 실행되기 전인 컴파일 중에 오류를 표출해줍니다.
+작은 프로그램을 작성할 때에는, 이런 이상한 점들이 화를 돋구지만 관리는 가능합니다. 그러나 수백 또는 수천 줄의 어플리케이션들을 작성할 때에는, 이러한 지속적 놀라움들은 심각한 문제입니다.
+
+## TypeScript: 정적 타입 검사자 (TypeScript: A Static Type Checker)
+
+앞서 몇 언어는 버그가 많은 프로그램을 아예 실행시키지 않는다고 했습니다.
+프로그램을 실행시키지 않으면서 코드의 오류를 검출하는 것을 _정적 검사_라고 합니다.
+어떤 것이 오류인지와 어떤 것이 연산 되는 값에 기인하지 않음을 정하는 것이 정적 _타입_ 검사입니다.
+
+_정적 타입 검사자_인 TypeScript는 프로그램을 실행시키기 전에 _값의 종류_를 기반으로 프로그램의 오류를 찾습니다.
+예를 들어, 위의 마지막 예시에 오류가 있는 이유는 `obj`의 _타입_ 때문입니다.
+다음은 TypeScript에서 볼 수 있는 오류입니다:
+
+```
+// @errors: 2551
+const obj = { width: 10, height: 15 };
+const area = obj.width * obj.heigth;
+```
+
+### 타입이 있는 JavaScript의 상위 집합 (A Typed Superset of JavaScript)
+
+그렇다면 TypeScript는 JavaScript와 어떤 관계일까요?
+
+#### 구문 (Syntax)
+
+TypeScript는 JS의 구문이 허용되는, JavaScript의 _상위 집합_ 언어입니다.
+구문은 프로그램을 만들기 위해 코드를 작성하는 방법을 의미합니다.
+예를 들어, 다음 코드는 `)`이 없으므로 _구문_ 오류입니다:
+
+```
+// @errors: 1005
+let a = (4
+```
+
+TypeScript는 독특한 구문 때문에 JavaScript 코드를 오류로 보지 않습니다.
+즉, 어떻게 작성돼있는지 모르지만 작동하는 JavaScript 코드를 TypeScript 파일에 넣어도 잘 작동합니다.
+
+#### 타입 (Types)
+
+그러나 TypeScript는 다른 종류의 값들을 사용할 수 있는 방법이 추가된, _타입이 있는_ 상위 집합입니다.
+위의 `obj.heigth` 오류는 _구문_ 오류가 아닌, 값의 종류(_타입_)를 잘못 사용해서 생긴 오류입니다.
+
+또 다른 예시로, 아래와 같은 JavaScript 코드가 브라우저에서 실행될 때, 다음과 같은 값이 출력될 _것입니다_:
+
+```js
+console.log(4 / []);
+```
+
+구문적으로 옳은(syntactically-legal) 위 코드는 JavaScript에서 `NaN`을 출력합니다.
+그러나 TypeScript는 배열로 숫자를 나누는 연산이 옳지 않다고 판단하고 오류를 발생시킵니다:
+
+```
+// @errors: 2363
+console.log(4 / []);
+```
+
+실제로 어떤 일이 일어나는지 보려는 의도로 숫자를 배열로 나눌 수 _있지만_, 대부분은 프로그래밍 실수입니다.
+TypeScript의 타입 검사자는 일반적인 오류를 최대한 많이 검출하면서 올바른 프로그램을 만들 수 있게 설계되었습니다.
+(나중에 TypeScript가 코드를 얼마나 엄격하게 검사할 수 있는지에 대한 설정에 대해 알아봅시다.)
+
+만약 JavaScript 파일의 코드를 TypeScript 코드로 옮기면, 코드를 어떻게 작성했는지에 따라 _타입 오류_를 볼 수 있습니다.
+이는 코드 상의 문제이거나, TypeScript가 지나치게 보수적인 것일 수 있습니다.
+위와 같은 오류를 제거하기 위해 가이드는 다양한 TypeScript 구문을 추가하는 방법을 보여줍니다.
+
+#### 런타임 특성 (Runtime Behavior)
+
+TypeScript는 JavaScript의 _런타임 특성_을 가진 프로그래밍 언어입니다.
+예를 들어, JavaScript에서 0으로 나누는 행동은 런타임 예외로 처리하지 않고 `Infinity`값을 반환합니다.
+논리적으로, TypeScript는 JavaScript 코드의 런타임 특성을 **절대** 변화시키지 않습니다.
+
+즉 TypeScript가 코드에 타입 오류가 있음을 검출해도, JavaScript 코드를 TypeScript로 이동시키는 것은 같은 방식으로 실행시킬 것을 **보장합니다**
+
+JavaScript와 동일한 런타임 동작을 유지하는 것은 프로그램 작동을 중단시킬 수 있는 미묘한 차이를 걱정하지 않고 두 언어 간에 쉽게 전환할 수 있도록 하기 위한 TypeScript의 기본적인 약속입니다.
+
+<!--
+Missing subsection on the fact that TS extends JS to add syntax for type
+specification.  (Since the immediately preceding text was raving about
+how JS code can be used in TS.)
+-->
+
+#### 삭제된 타입 (Erased Types)
+
+개략적으로, TypeScript의 컴파일러가 코드 검사를 마치면 타입을 _삭제해서_ 결과적으로 "컴파일된" 코드를 만듭니다.
+즉 코드가 한 번 컴파일되면, 결과로 나온 일반 JS 코드에는 타입 정보가 없습니다.
+
+타입 정보가 없는 것은 TypeScript가 추론한 타입에 따라 프로그램의 _특성_을 변화시키지 않는다는 의미입니다.
+결론적으로 컴파일 도중에는 타입 오류가 표출될 수 있지만, 타입 시스템 자체는 프로그램이 실행될 때 작동하는 방식과 관련이 없습니다.
+
+마지막으로, TypeScript는 추가 런타임 라이브러리를 제공하지 않습니다.
+TypeScript는 프로그램은 JavaScript 프로그램과 같은 표준 라이브러리 (또는 외부 라이브러리)를 사용하므로, TypeScript 관련 프레임워크를 추가로 공부할 필요가 없습니다.
+<!--
+Should extend this paragraph to say that there's an exception of
+allowing you to use newer JS features and transpile the code to an older
+JS, and this might add small stubs of functionality when needed.  (Maybe
+with an example --- something like `?.` would be good in showing readers
+that this document is maintained.)
+-->
+
+## JavaScript와 TypeScript 학습 (Learning JavaScript and TypeScript)
+
+종종 "JavaScript 또는 TypeScript를 배워야 할까요?"와 같은 질문을 볼 수 있습니다.
+
+정답은 JavaScript를 배우지 않고선 TypeScript를 배울 수 없다는 것입니다!
+TypeScript는 JavaScript와 구문과 런타임 특성을 공유하므로, JavaScript에서 배운 모든 것들은 동시에 TypeScript를 배울 때 도움이 될 것입니다.
+
+프로그래머들을 위한 JavaScript 학습 자원이 많습니다; TypeScript를 작성할 때 그런 학습 자원을 무시해선 _안됩니다_.
+예를 들어 `javascript`태그가 붙은 질문이 `typescript`태그가 붙은 질문보다 약 20배는 많지만, _모든_ `javascript`질문은 TypeScript에도 적용할 수 있습니다.
+
+만약 "TypeScript에서 리스트를 정렬하는 법"과 같은 것을 찾는 경우, 기억하세요: **TypeScript는 컴파일-타임 타입 검사자가 있는 JavaScript의 런타임입니다**.
+리스트를 TypeScript에서 정렬하는 방법은 JavaScript에서 똑같은 방법으로 할 수 있습니다.
+만약 TypeScript를 직접적으로 사용하는 자원을 찾았다면 그것도 좋지만, 런타임 작업을 실행하기 위한 일상적인 질문을 TypeScript 관련 답변에만 제한시킬 필요는 없습니다.
+
+---
+
+여기서, JavaScript 기초 몇 가지를 배우는 것을 추천합니다 ([Mozilla 웹 문서의 JavaScript 가이드](https://developer.mozilla.org/docs/Web/JavaScript/Guide)가 괜찮겠네요.)
+
+익숙해지셨다면, 다시 돌아와서 [JavaScript 프로그래머들을 위한 TypeScript](/docs/handbook/typescript-in-5-minutes.html)을 읽어보시고, [핸드북](/docs/handbook/intro.html)을 시작하시거나 [예제](/play#show-examples)를 보세요.
+
+<!-- Note: I'll be happy to write the following... -->
+<!--
+## Types
+
+    * What's a type? (For newbies)
+      * A type is a *kind* of value
+      * Types implicitly define what operations make sense on them
+      * Lots of different kinds, not just primitives
+      * We can make descriptions for all kinds of values
+      * The `any` type -- a quick desctiption, what it is, and why it's bad
+    * Inference 101
+      * Examples
+      * TypeScript can figure out types most of the time
+      * Two places we'll ask you what the type is: Function boundaries, and later-initialized values
+    * Co-learning JavaScript
+      * You can+should read existing JS resources
+      * Just paste it in and see what happens
+      * Consider turning off 'strict' -->
+      
\ No newline at end of file
diff --git a/docs/documentation/ko/handbook-v2/The Handbook.md b/docs/documentation/ko/handbook-v2/The Handbook.md
new file mode 100644
index 00000000..279fb63c
--- /dev/null
+++ b/docs/documentation/ko/handbook-v2/The Handbook.md	
@@ -0,0 +1,60 @@
+---
+title: The TypeScript Handbook
+layout: docs
+permalink: /ko/docs/handbook/intro.html
+oneline: Your first step to learn TypeScript
+handbook: "true"
+---
+
+## 핸드북에 대해서 (About this Handbook)
+
+JavaScript는 프로그래밍 커뮤니티에 도입된 지 20년이 지난 지금, 가장 널리 퍼진 cross-platform 언어 중 하나입니다. JavaScript는 웹 페이지에 사소한 상호작용을 추가하기 위한 작은 스크립팅 언어로 시작하여, 규모에 상관없이 프론트엔드와 백엔드 애플리케이션에서 선택 가능한 언어로 성장했습니다. JavaScript로 작성된 프로그램의 크기, 범위 및 복잡성은 기하급수적으로 커졌지만, 다른 코드 단위 간의 관계를 표현하는 JavaScript 언어의 능력은 그렇지 못했습니다. JavaScript의 다소 특이한 런타임 의미 체계(runtime semantics)와 더불어, 언어와 프로그램 복잡성 간의 불일치는 JavaScript 개발을 규모에 맞게 관리하기 어려운 작업으로 만들었습니다.
+
+프로그래머들이 작성하는 가장 흔한 오류는 타입 오류입니다: 다른 종류의 값이 예상되는 곳에 특정한 값이 사용된 경우입니다. 이는 단순한 오타, 라이브러리 API를 이해하지 못한 것, 런타임 동작에 대한 잘못된 가정 또는 다른 오류 때문일 수 있습니다. TypeScript의 목표는 JavaScript 프로그램의 정적 타입 검사자 입니다. 즉, 코드가 실행되기 전에 실행하고(정적), 프로그램 타입이 정확한지 확인하는 도구(타입 검사)입니다.
+
+JavaScript에 대한 배경지식 없이 TypeScript를 첫 번째 언어로 사용한다면, 먼저 [Mozilla 웹 문서에서 JavaScript에 대한](https://developer.mozilla.org/docs/Web/JavaScript/Guide) 문서를 읽어 보는 것이 좋습니다.
+다른 언어에 대한 경험이 있다면, 핸드북을 읽으면서 JavaScript 구문을 꽤 빠르게 익힐 수 있을 것입니다.
+
+## 핸드북은 어떻게 구성되어 있는가? (How is this Handbook Structured)
+
+핸드북은 두 영역으로 나뉩니다:
+
+* **핸드북**
+
+  TypeScript 핸드북은 평범한 프로그래머들에게 TypeScript를 설명하는 종합적인 문서입니다. 왼쪽 메뉴를 통해 위에서 아래로 이동하며 읽을 수 있습니다.
+
+  각 장 또는 페이지가 주어진 개념에 대해 자세한 설명을 제공할 것이라고 기대할 것입니다. TypeScript 핸드북은 언어에 대한 완전한 설명서는 아니지만, 모든 특징과 동작에 대한 종합적인 가이드입니다.
+
+  실습을 완료한 독자는 다음을 수행할 수 있어야 합니다:
+
+  * 일반적으로 사용하는 TypeScript 구문 및 패턴을 읽고 이해하기
+  * 중요한 컴파일러 옵션의 효과 설명하기
+  * 대부분의 경우에서 타입 시스템 동작을 올바르게 예측하기
+  * 간단한 함수, 객체 또는 클래스에 대한 .d.ts 선언 작성하기
+
+  핸드북의 주요 내용은 명확성과 간결성을 위해, 다루어지고 있는 특징의 모든 엣지 케이스 또는 세부 사항을 탐구하지는 않습니다. 참고문헌에서 특정 개념에 대한 자세한 내용을 찾아볼 수 있습니다.
+
+* **핸드북 레퍼런스**
+
+  핸드북 레퍼런스는 TypeScript의 특정 부분이 어떻게 작동하는지 풍부한 이해를 제공하기 위해 작성되었습니다. 위에서 아래로 읽을 수 있지만, 연속적으로 설명하는 것이 아니라, 각 섹션은 단일 개념에 대한 더 깊은 설명 제공을 목표로 합니다.
+
+### 잠재적인 목표 (Non-Goals)
+
+핸드북은 몇 시간 안에 편하게 읽을 수 있는 간결한 문서로 제작되었습니다. 간결함을 유지하기 위해 특정 주제는 다루지 않습니다.
+
+특히, 함수, 클래스, 클로저와 같은 JavaScript 핵심 개념을 전부 소개하지는 않습니다. 필요한 경우, 해당 개념을 읽는 데 사용할 수 있는 배경 자료 링크를 제시할 것입니다.
+
+또한, 핸드북은 언어 명세를 대체하기 위함이 아닙니다. 경우에 따라서는, 대략적이고 이해하기 쉬운 설명을 위해, 에지 케이스나 동작의 형식적인 설명을 생략할 수 있습니다. 대신에, TypeScript 동작의 여러 측면을 보다 정확하고 공식적으로 설명하는 별도의 참조 페이지가 있습니다. 레퍼런스 페이지는 TypeScript에 익숙하지 않은 독자를 위한 것이 아니기 때문에, 아직 읽지 않은 고급 용어나 주제를 사용할 수 있습니다.
+
+마지막으로, 필요한 경우를 제외하고는 TypeScript가 다른 도구와 어떻게 상호작용하는지는 다루지 않습니다. webpack, rollup, parcel, react, babel, closure, lerna, rush, bazel, preact, vue, angular, svelte, jquery, yarn, npm으로 TypeScript를 구성하는 방법은 다른 웹사이트에서 찾을 수 있습니다.
+
+## 시작하기 (Get Started)
+
+[기본 타입](/docs/handbook/2/basic-types.html)을 시작하기 전에, 다음의 소개 페이지 중 하나를 읽어보는 것이 좋습니다. TypeScript와 당신이 선호하는 프로그래밍 언어 간의 주요 유사점과 차이점을 강조하고, 해당 언어에 대한 일반적인 오해를 정리했습니다.
+
+- [TypeScript for New Programmers](/docs/handbook/typescript-from-scratch.html)
+- [TypeScript for JavaScript Programmers](/docs/handbook/typescript-in-5-minutes.html)
+- [TypeScript for OOP Programmers](/docs/handbook/typescript-in-5-minutes-oop.html)
+- [TypeScript for Functional Programmers](/docs/handbook/typescript-in-5-minutes-func.html)
+
+또는, [기본 타입](/docs/handbook/2/basic-types.html)을 살펴보거나, [Epub](/assets/typescript-handbook.epub) 또는 [PDF](/assets/typescript-handbook.pdf) 형식의 핸드북을 다운로드 할 수 있습니다.
diff --git a/docs/documentation/ko/handbook-v2/Type Manipulation/Generics.md b/docs/documentation/ko/handbook-v2/Type Manipulation/Generics.md
new file mode 100644
index 00000000..d1904d50
--- /dev/null
+++ b/docs/documentation/ko/handbook-v2/Type Manipulation/Generics.md	
@@ -0,0 +1,376 @@
+---
+title: Generics
+layout: docs
+permalink: /ko/docs/handbook/2/generics.html
+oneline: Types which take parameters
+---
+
+잘 정의되고 일관된 API뿐만 아닌 재사용 가능한 컴포넌트를 구축하는 것도 소프트웨어 엔지니어링에서의 주요한 부분입니다.
+현재의 데이터와 미래의 데이터 모두를 다룰 수 있는 컴포넌트는 거대한 소프트웨어 시스템을 구성하는 데 있어 가장 유연한 능력을 제공할 것입니다.
+
+C#과 Java 같은 언어에서, 재사용 가능한 컴포넌트를 생성하는 도구상자의 주요 도구 중 하나는 제네릭입니다, 즉, 단일 타입이 아닌 다양한 타입에서 작동하는 컴포넌트를 작성할 수 있습니다.
+사용자는 제네릭을 통해 여러 타입의 컴포넌트나 자신만의 타입을 사용할 수 있습니다.
+
+# 제네릭의 Hello World (Hello World of Generics)
+
+먼저 제네릭의 "hello world"인 identity 함수를 해봅시다.
+identity 함수는 인수로 무엇이 오던 그대로 반환하는 함수입니다.
+`echo` 명령과 비슷하게 생각할 수 있습니다.
+
+제네릭이 없다면, identity 함수에 특정 타입을 주어야 합니다:
+
+```ts twoslash
+function identity(arg: number): number {
+  return arg;
+}
+```
+
+또는 `any` 타입을 사용하여 identity 함수를 기술할 수 있습니다:
+
+```ts twoslash
+function identity(arg: any): any {
+  return arg;
+}
+```
+
+`any`를 쓰는 것은 함수의 `arg`가 어떤 타입이든 받을 수 있다는 점에서 제네릭이지만, 실제로 함수가 반환할 때 어떤 타입인지에 대한 정보는 잃게 됩니다.
+만약 number 타입을 넘긴다고 해도 any 타입이 반환된다는 정보만 얻을 뿐입니다.
+
+대신에 우리는 무엇이 반환되는지 표시하기 위해 인수의 타입을 캡처할 방법이 필요합니다.
+여기서는 값이 아닌 타입에 적용되는 *타입 변수* 를 사용할 것입니다.
+
+```ts twoslash
+function identity<Type>(arg: Type): Type {
+  return arg;
+}
+```
+
+identity 함수에 `Type`라는 타입 변수를 추가했습니다.
+`Type`는 유저가 준 인수의 타입을 캡처하고 (예 - `number`), 이 정보를 나중에 사용할 수 있게 합니다.
+여기에서는 `Type`를 반환 타입으로 다시 사용합니다. 인수와 반환 타입이 같은 타입을 사용하고 있는 것을 확인할 수 있습니다.
+이를 통해 타입 정보를 함수의 한쪽에서 다른 한쪽으로 운반할 수 있게끔 합니다.
+
+이 버전의 identity 함수는 타입을 불문하고 동작하므로 제네릭이라 할 수 있습니다.
+`any`를 쓰는 것과는 다르게 인수와 반환 타입에 number를 사용한 첫 번째 `identity` 함수만큼 정확합니다. (즉, 어떤 정보도 잃지 않습니다)
+
+일단 제네릭 identity 함수를 작성하고 나면, 두 가지 방법 중 하나로 호출할 수 있습니다.
+첫 번째 방법은 함수에 타입 인수를 포함한 모든 인수를 전달하는 방법입니다.
+
+```ts twoslash
+function identity<Type>(arg: Type): Type {
+  return arg;
+}
+// ---cut---
+let output = identity<string>("myString"); // 출력 타입은 'string'입니다.
+//       ^?
+```
+
+여기서 우리는 함수를 호출할 때의 인수 중 하나로써 `Type`를 `string`으로 명시해 주고 인수 주변에 `()` 대신 `<>`로 감싸주었습니다.
+
+두 번째 방법은 아마 가장 일반적인 방법입니다. 여기서는 *타입 인수 추론* 을 사용합니다 -- 즉, 우리가 전달하는 인수에 따라서 컴파일러가 `Type`의 값을 자동으로 정하게 하는 것입니다:
+
+```ts twoslash
+function identity<Type>(arg: Type): Type {
+  return arg;
+}
+// ---cut---
+let output = identity("myString"); // 출력 타입은 'string'입니다.
+//       ^?
+```
+
+타입 인수를 꺾쇠괄호(`<>`)에 담아 명시적으로 전달해 주지 않은 것을 주목하세요; 컴파일러는 값인 `"myString"`를 보고 그것의 타입으로 `Type`를 정합니다.
+인수 추론은 코드를 간결하고 가독성 있게 하는 데 있어 유용하지만 더 복잡한 예제에서 컴파일러가 타입을 유추할 수 없는 경우엔 명시적인 타입 인수 전달이 필요할 수도 있습니다.
+
+# 제네릭 타입 변수 작업 (Working with Generic Type Variables)
+
+제네릭을 사용하기 시작하면, `identity`와 같은 제네릭 함수를 만들 때, 컴파일러가 함수 본문에 제네릭 타입화된 매개변수를 쓰도록 강요합니다.
+즉, 이 매개변수들은 실제로 `any` 나 모든 타입이 될 수 있는 것처럼 취급할 수 있게 됩니다.
+
+앞에서 본 `identity` 함수를 살펴보도록 합니다:
+
+```ts twoslash
+function identity<Type>(arg: Type): Type {
+  return arg;
+}
+```
+
+함수 호출 시마다 인수 `arg`의 길이를 로그에 찍으려면 어떻게 해야 합니까?
+아마 이것을 쓰고 싶을 겁니다:
+
+```ts twoslash
+// @errors: 2339
+function loggingIdentity<Type>(arg: Type): Type {
+  console.log(arg.length); // 오류: Type에는 .length 가 없습니다.
+  return arg;
+}
+```
+
+이렇게 하면, 컴파일러는 `arg`의 멤버 `.length`를 사용하고 있다는 오류를 낼 것입니다만, 어떤 곳에서도 `arg`가 이 멤버가 있다는 것이 명시되어 있지 않습니다.
+이전에 이러한 변수 타입은 `any`나 모든 타입을 의미한다고 했던 것을 기억하십시오. 따라서 이 함수를 쓰고 있는 사용자는 `.length` 멤버가 없는 `number`를 대신 전달할 수도 있습니다
+
+실제로 이 함수가 `Type`가 아닌 `Type`의 배열에서 동작하도록 의도했다고 가정해봅시다. 배열로 사용하기 때문에 `.length` 멤버는 사용 가능합니다.
+다른 타입들의 배열을 만드는 것처럼 표현할 수 있습니다.
+
+```ts twoslash {1}
+function loggingIdentity<Type>(arg: Type[]): Type[] {
+  console.log(arg.length); // 배열은 .length를 가지고 있습니다. 따라서 오류는 없습니다.
+  return arg;
+}
+```
+
+`loggingIdentity`의 타입을 "제너릭 함수 `loggingIdentity`는 타입 매개변수 `Type`와 `Type` 배열인 인수 `arg`를 취하고 `Type` 배열을 반환한다."라고 읽을 수 있습니다.
+만약 우리가 number 배열을 넘기면 `Type`가 `number`에 바인딩 되므로 함수는 number 배열을 얻게 됩니다.
+전체 타입변수를 쓰는 것보다 하나의 타입으로써 제네릭 타입변수 `Type`를 사용하는 것은 굉장한 유연함을 제공합니다.
+
+위 예제를 이렇게도 대체할 수 있습니다.
+
+```ts twoslash {1}
+function loggingIdentity<Type>(arg: Array<Type>): Array<Type> {
+  console.log(arg.length); // 배열은 .length를 가지고 있습니다. 따라서 오류는 없습니다.
+  return arg;
+}
+```
+
+다른 언어들과 비슷한 이런 타입 스타일이 이미 익숙할 것입니다.
+다음 섹션에서는 어떻게 `Array<T>`와 같은 고유한 제네릭 타입을 만들 수 있는지에 대해 다루도록 하겠습니다.
+
+# 제네릭 타입 (Generic Types)
+
+이전 섹션에서 우리는 타입을 초월한 제네릭 함수 `identity`를 만들었습니다.
+이번 섹션에서는 함수 자체의 타입과 제네릭 인터페이스를 만드는 방법에 대해 살펴보겠습니다.
+
+제네릭 함수의 타입은 함수 선언과 유사하게 타입 매개변수가 먼저 나열되는, 비-제네릭 함수의 타입과 비슷합니다.
+
+```ts twoslash
+function identity<Type>(arg: Type): Type {
+  return arg;
+}
+
+let myIdentity: <Type>(arg: Type) => Type = identity;
+```
+
+또한 타입 변수의 수와 타입 변수가 사용되는 방식에 따라 타입의 제네릭 타입 매개변수에 다른 이름을 사용할 수도 있습니다.
+
+```ts twoslash
+function identity<Type>(arg: Type): Type {
+  return arg;
+}
+
+let myIdentity: <Input>(arg: Input) => Input = identity;
+```
+
+제네릭 타입을 객체 리터럴 타입의 함수 호출 시그니처로 작성할 수도 있습니다:
+
+```ts twoslash
+function identity<Type>(arg: Type): Type {
+  return arg;
+}
+
+let myIdentity: { <Type>(arg: Type): Type } = identity;
+```
+
+이것들로 첫 번째 제네릭 인터페이스를 작성할 수 있습니다.
+앞서 예제의 객체 리터럴을 인터페이스로 가져옵니다:
+
+```ts twoslash
+interface GenericIdentityFn {
+  <Type>(arg: Type): Type;
+}
+
+function identity<Type>(arg: Type): Type {
+  return arg;
+}
+
+let myIdentity: GenericIdentityFn = identity;
+```
+
+비슷한 예제에서, 제네릭 매개변수를 전체 인터페이스의 매개변수로 옮기고 싶을지도 모릅니다.
+이를 통해 제네릭 타입을 확인할 수 있습니다 (예 -  `Dictionary` 가 아닌 `Dictionary<string>`).
+이렇게 하면 인터페이스의 다른 모든 멤버가 타입 매개변수를 볼 수 있습니다.
+
+```ts twoslash
+interface GenericIdentityFn<Type> {
+  (arg: Type): Type;
+}
+
+function identity<Type>(arg: Type): Type {
+  return arg;
+}
+
+let myIdentity: GenericIdentityFn<number> = identity;
+```
+
+예제에 아주 작은 변화가 있었습니다.
+제네릭 함수를 작성하는 것 대신 제네릭 타입의 일부인 비-제네릭 함수 시그니처를 가집니다.
+`GenericIdentityFn` 함수를 사용할 때, 시그니처가 사용할 것을 효과적으로 제한할 특정한 타입 인수가 필요합니다 (여기서는 `number`).
+타입 매개변수를 호출 시그니처에 바로 넣을 때와 인터페이스 자체에 넣을 때를 이해하는 것은 타입의 제네릭 부분을 설명하는 데 도움이 됩니다.
+
+제네릭 인터페이스 외에도 제네릭 클래스를 만들 수 있습니다.
+제네릭 열거형과 네임스페이스는 만들 수 없습니다.
+
+# 제네릭 클래스 (Generic Classes)
+
+제네릭 클래스와 제네릭 인터페이스는 형태가 비슷합니다.
+제네릭 클래스는 클래스 이름 뒤에 꺾쇠괄호(`<>`) 안쪽에 제네릭 타입 매개변수 목록을 가집니다.
+
+```ts twoslash
+// @strict: false
+class GenericNumber<NumType> {
+  zeroValue: NumType;
+  add: (x: NumType, y: NumType) => NumType;
+}
+
+let myGenericNumber = new GenericNumber<number>();
+myGenericNumber.zeroValue = 0;
+myGenericNumber.add = function (x, y) {
+  return x + y;
+};
+```
+
+이것은 `GenericNumber` 클래스의 문자 그대로 사용하지만 `number` 타입만 쓰도록 제한하는 것은 없습니다.
+대신 `string`이나 훨씬 복잡한 객체를 사용할 수 있습니다.
+
+```ts twoslash
+// @strict: false
+class GenericNumber<NumType> {
+  zeroValue: NumType;
+  add: (x: NumType, y: NumType) => NumType;
+}
+// ---cut---
+let stringNumeric = new GenericNumber<string>();
+stringNumeric.zeroValue = "";
+stringNumeric.add = function (x, y) {
+  return x + y;
+};
+
+console.log(stringNumeric.add(stringNumeric.zeroValue, "test"));
+```
+
+인터페이스와 마찬가지로 클래스 자체에 타입 매개변수를 넣으면 클래스의 모든 프로퍼티가 동일한 타입으로 동작하는 것을 확인할 수 있습니다.
+
+[클래스](./classes.md)에서 다뤘던 것처럼 클래스는 두 가지 타입을 가집니다: 정적 측면과 인스턴스 측면.
+제네릭 클래스는 정적 측면이 아닌 인스턴스 측면에서만 제네릭이므로 클래스로 작업할 때 정적 멤버는 클래스의 타입 매개변수를 쓸 수 없습니다.
+
+# 제네릭 제약조건 (Generic Constraints)
+
+앞쪽의 예제를 기억한다면 특정 타입들로만 동작하는 제네릭 함수를 만들고 싶을 수 있습니다.
+앞서 `loggingIdentity` 예제에서 `arg`의 프로퍼티 `.length`에 접근하기를 원했지만, 컴파일러는 모든 타입에서 `.length` 프로퍼티를 가짐을 증명할 수 없으므로 경고합니다.
+
+```ts twoslash
+// @errors: 2339
+function loggingIdentity<Type>(arg: Type): Type {
+  console.log(arg.length);
+  return arg;
+}
+```
+
+any와 모든 타입에서 동작하는 대신에, `.length` 프로퍼티가 있는 any와 모든 타입들에서 작동하는 것으로 제한하고 싶습니다.
+타입이 이 멤버가 있는 한 허용하지만, 최소한 `.length` 가 있어야 합니다.
+그렇게 하려면 `Type` 가 무엇이 될 수 있는지에 대한 제약 조건을 나열해야 합니다.
+
+이를 위해 우리의 제약조건이 명시하는 인터페이스를 만듭니다.
+여기 하나의 프로퍼티 `.length`를 가진 인터페이스를 생성하였고, 우리의 제약사항을 `extends` 키워드로 표현한 인터페이스를 이용해 명시합니다:
+
+```ts twoslash
+interface Lengthwise {
+  length: number;
+}
+
+function loggingIdentity<Type extends Lengthwise>(arg: Type): Type {
+  console.log(arg.length); // Now we know it has a .length property, so no more error
+  return arg;
+}
+```
+
+제네릭 함수는 이제 제한되어 있기 때문에 모든 타입에 대해서는 동작하지 않습니다:
+
+```ts twoslash
+// @errors: 2345
+interface Lengthwise {
+  length: number;
+}
+
+function loggingIdentity<Type extends Lengthwise>(arg: Type): Type {
+  console.log(arg.length);
+  return arg;
+}
+// ---cut---
+loggingIdentity(3);
+```
+
+대신 필요한 프로퍼티들이 있는 타입의 값을 전달해야 합니다:
+
+```ts twoslash
+interface Lengthwise {
+  length: number;
+}
+
+function loggingIdentity<Type extends Lengthwise>(arg: Type): Type {
+  console.log(arg.length);
+  return arg;
+}
+// ---cut---
+loggingIdentity({ length: 10, value: 3 });
+```
+
+## 제네릭 제약조건에서 타입 매개변수 사용 (Using Type Parameters in Generic Constraints)
+
+다른 타입 매개변수로 제한된 타입 매개변수를 선언할 수 있습니다.
+이름이 있는 객체에서 프로퍼티를 가져오고 싶은 경우를 예로 들어 봅시다.
+실수로 `obj`에 존재하지 않는 프로퍼티를 가져오지 않도록 하기 위해 두 가지 타입에 제약조건을 두었습니다.
+
+```ts twoslash
+// @errors: 2345
+function getProperty<Type, Key extends keyof Type>(obj: Type, key: Key) {
+  return obj[key];
+}
+
+let x = { a: 1, b: 2, c: 3, d: 4 };
+
+getProperty(x, "a");
+getProperty(x, "m");
+```
+
+## 제네릭에서 클래스 타입 사용 (Using Class Types in Generics)
+
+제네릭을 사용하는 TypeScript에서 팩토리를 생성할 때 생성자 함수로 클래스 타입을 참조해야 합니다. 예를 들면:
+
+```ts twoslash
+function create<Type>(c: { new (): Type }): Type {
+  return new c();
+}
+```
+
+고급 예제에서는 prototype 프로퍼티를 사용하여 생성자 함수와 클래스 타입의 인스턴스 사이의 관계를 유추하고 제한합니다.
+
+```ts twoslash
+// @strict: false
+class BeeKeeper {
+  hasMask: boolean;
+}
+
+class ZooKeeper {
+  nametag: string;
+}
+
+class Animal {
+  numLegs: number;
+}
+
+class Bee extends Animal {
+  keeper: BeeKeeper;
+}
+
+class Lion extends Animal {
+  keeper: ZooKeeper;
+}
+
+function createInstance<A extends Animal>(c: new () => A): A {
+  return new c();
+}
+
+createInstance(Lion).keeper.nametag; // 타입검사!
+createInstance(Bee).keeper.hasMask;  // 타입검사!
+```
+
+이 패턴은 [mixins](/docs/handbook/mixins.html) 디자인 패턴을 만드는 데에 사용되었습니다.
diff --git a/docs/documentation/ko/javascript/Creating DTS files From JS.md b/docs/documentation/ko/javascript/Creating DTS files From JS.md
new file mode 100644
index 00000000..0dc5da7e
--- /dev/null
+++ b/docs/documentation/ko/javascript/Creating DTS files From JS.md	
@@ -0,0 +1,88 @@
+---
+title: Creating .d.ts Files from .js files
+layout: docs
+permalink: /ko/docs/handbook/declaration-files/dts-from-js.html
+oneline: "How to add d.ts generation to JavaScript projects"
+translatable: true
+---
+
+[TypeScript 3.7에서](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-7.html#--declaration-and---allowjs),
+TypeScript는 JSDoc 구문을 사용한 JavaScript에서 .d.ts 파일을 생성할 수 있게 되었습니다.
+
+즉 프로젝트를 TypeScript에 이식하거나(porting) 코드베이스에 .d.ts 파일을 유지하지 않고도 TypeScript 기반 편집기의 환경을 유지할 수 있습니다.
+TypeScript는 대부분의 JSDoc 태그를 지원하며, [참조](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html#supported-jsdoc)에서 찾을 수 있습니다.
+
+## .d.ts 파일 생성을 위한 프로젝트 설정 (Setting up your Project to emit .d.ts files)
+
+.d.ts 파일을 프로젝트에서 생성하려면, 다음과 같은 4단계를 거쳐야합니다:
+
+* 개발 의존성에 TypeScript 추가
+* TypeScript 설정을 위해 `tsconfig.json` 추가
+* JS 파일에 해당하는 d.ts 파일을 생성하기 위해 TypeScript 컴파일 실행
+* (선택적으로) 타입을 참조하기 위한 package.json 수정
+
+### TypeScript 추가 (Adding TypeScript)
+
+[설치 페이지](https://www.typescriptlang.org/download)에서 방법을 확인할 수 있습니다.
+
+### TSConfig
+
+TSConfig는 컴파일러 플래그를 구성하고 파일을 찾을 위치를 선언하는 json5 파일입니다.
+위와 같은 경우, 다음과 같은 파일이 필요합니다:
+
+```jsonc tsconfig
+{
+  // 프로젝트에 알맞게 수정하세요.
+  "include": ["src/**/*"],
+
+  "compilerOptions": {
+    // 일반적으로 소스 파일로 무시되기 때문에,
+    // TypeScript가 JS 파일을 읽도록 지시합니다.
+    "allowJs": true,
+    // d.ts 파일을 생성시킵니다.
+    "declaration": true,
+    // 컴파일러 실행이 오직
+    // d.ts 파일만 출력하게 합니다.
+    "emitDeclarationOnly": true,
+    // 타입은 이 디렉터리 안에 존재해야 합니다.
+    // 해당 설정을 제거하면,
+    // .d.ts 파일이 .js 파일 옆에 생성됩니다.
+    "outDir": "dist",
+  },
+}
+```
+
+[tsconfig 참조](/reference)에서 더 많은 옵션을 찾을 수 있습니다.
+TSConfig 파일을 사용하는 대신 CLI를 사용할 수 있습니다.
+
+```sh
+npx typescript src/**/*.js --declaration --allowJs --emitDeclarationOnly --outDir types
+```
+
+## 컴파일러 실행 (Run the compiler)
+
+[설치 페이지](https://www.typescriptlang.org/download)에서 방법을 확인할 수 있습니다.
+프로젝트의 `.gitignore`에 파일이 있을 때, 이러한 파일들이 패키지에 포함되어 있는지 확인합니다.
+
+## package.json 수정 (Editing the package.json)
+
+TypeScript는 .d.ts 파일을 찾기 위한 추가 단계와 함께 `package.json`의 모듈에 대한 노드 관계(node resolution)를 복제합니다.
+대략적으로 먼저 선택적인 `"types"` 필드를 확인 후, 다음은 `"main"`, 마지막으로 루트에서 `index.d.ts`를 확인합니다.
+
+| Package.json              | 기본 .d.ts의 위치                 |
+| :------------------------ | :----------------------------- |
+| "types" 필드 없음           | "main" 확인 후, index.d.ts 확인   |
+| "types": "main.d.ts"      | main.d.ts                      |
+| "types": "./dist/main.js" | ./main/main.d.ts               |
+
+type 필드가 없다면, "main"으로 넘어갑니다.
+
+| Package.json             | 기본 .d.ts의 위치            |
+| :----------------------- | :------------------------ |
+| "main" 필드 없음           | index.d.ts                |
+| "main":"index.js"        | index.d.ts                |
+| "main":"./dist/index.js" | ./dist/index.d.ts         |
+
+## 팁 (Tips)
+
+.d.ts의 테스트를 작성하고 싶다면, [tsd](https://github.com/SamVerschueren/tsd)를 사용해보세요.
diff --git a/docs/documentation/ko/javascript/Intro to JS with TS.md b/docs/documentation/ko/javascript/Intro to JS with TS.md
new file mode 100644
index 00000000..65ce6f6a
--- /dev/null
+++ b/docs/documentation/ko/javascript/Intro to JS with TS.md	
@@ -0,0 +1,70 @@
+---
+title: JS Projects Utilizing TypeScript
+layout: docs
+permalink: /ko/docs/handbook/intro-to-js-ts.html
+oneline: How to add type checking to JavaScript files using TypeScript
+translatable: true
+---
+
+TypeScript의 타입 시스템은 코드베이스로 작업할 때 엄격함의 레벨이 다릅니다
+
+* 오직 JavaScript 코드의 추론을 기반으로 하는 타입 시스템
+* [JSDoc를 통한](/docs/handbook/jsdoc-supported-types.html) JavaScript에서의 Incremental typing
+* JavaScript에서의 `// @ts-check` 사용
+* TypeScript 코드
+* [`strict`](/tsconfig#strict)이 활성화된 TypeScript
+
+각 단계는 타입시스템을 더 안전하게 만들지만, 반드시 모든 프로젝트가 이 수준에 맞는 검증을 필요로 하는 것은 아닙니다.
+
+## JavaScript를 활용한 TypeScript (TypeScript with JavaScript)
+
+이는 자동 완성, 심벌로 이동 및 이름 바꾸기와 같은 리팩토링 툴을 제공하기 위해서 TypeScript를 사용하는 에디터를 사용할 때 유용합니다.
+[홈페이지](/)에는 TypeScript 플러그인들이 있는 편집자 목록이 있습니다.
+
+## JSDoc을 통하여 JS에 타입 힌트 제공하기 (Providing Type Hints in JS via JSDoc)
+
+`.js` 파일에서는, 종종 타입들을 유추할 수 있습니다. 타입들을 유추할 수 없는 경우, JSDoc 구문을 사용하여 구체적으로 알릴 수 있습니다.
+
+JSDoc 주석은 선언 앞에 위치하며 특정 선언의 타입을 설정하는 데 사용됩니다. 예를 들어:
+
+```js
+/** @type {number} */
+var x;
+
+x = 0; // 성공
+x = false; // 성공?!
+```
+
+지원되는 JSDoc 패턴의 전체 목록은 [JSDoc가 지원하는 타입에서](/docs/handbook/jsdoc-supported-types.html) 찾을 수 있습니다.
+
+## `@ts-check`
+
+이전 코드 예시의 마지막 줄은 TypeScript에서 오류를 발생시키지만, JS 프로젝트에서는 기본적으로 오류를 발생시키지 않습니다.
+JavaScript 파일에서 오류를 실행하려면 다음을 추가해야 합니다: `.js` 파일의 첫 번째 줄에 `// @ts-check`를 추가하여 TypeScript가 이를 오류로 올리도록 해야 합니다.
+
+```js
+// @ts-check
+// @errors: 2322
+/** @type {number} */
+var x;
+
+x = 0; // 성공
+x = false; // 성공 아님
+```
+
+만일 오류를 추가하려는 JavaScript 파일이 많은 경우, [`jsconfig.json`](/docs/handbook/tsconfig-json.html) 역시 사용할 수 있습니다.
+파일에 `// @ts-nocheck` 코멘트를 추가하면 일부 파일 확인을 건너뛸 수 있습니다.
+
+TypeScript는 우리가 동의하지 않는 오류들을 제공할 수도 있는데, 이 경우 특정 줄 맨앞에 `// @ts-ignore` 또는 `// @ts-expect-error`를 추가하여 그 줄의 오류를 무시할 수 있습니다.
+
+```js
+// @ts-check
+/** @type {number} */
+var x;
+
+x = 0; // 성공
+// @ts-expect-error
+x = false; // 성공 아님
+```
+
+JavaScript를 TypeScript로 해석하는 방법에 대한 자세한 내용은 [TS Type이 JS를 체크하는 방법](/docs/handbook/type-checking-javascript-files.html)을 참고하시기 바랍니다.
diff --git a/docs/documentation/ko/javascript/JSDoc Reference.md b/docs/documentation/ko/javascript/JSDoc Reference.md
new file mode 100644
index 00000000..653a17f2
--- /dev/null
+++ b/docs/documentation/ko/javascript/JSDoc Reference.md	
@@ -0,0 +1,693 @@
+---
+title: JSDoc Reference
+layout: docs
+permalink: /ko/docs/handbook/jsdoc-supported-types.html
+oneline: What JSDoc does TypeScript-powered JavaScript support?
+translatable: true
+---
+
+아래 목록은 JavaScript 파일에 타입 정보 제공을 위해 JSDoc 어노테이션을 사용할 때
+현재 지원되는 구성의 개요를 다룹니다.
+
+아래 명시적으로 나열되지 않은 태그(예 `@async`)는 아직 지원되지 않습니다.
+
+- [`@type`](#type)
+- [`@param`](#param-and-returns) (or [`@arg`](#param-and-returns) or [`@argument`](#param-and-returns))
+- [`@returns`](#param-and-returns) (or [`@return`](#param-and-returns))
+- [`@typedef`](#typedef-callback-and-param)
+- [`@callback`](#typedef-callback-and-param)
+- [`@template`](#template)
+- [`@class`](#constructor) (or [`@constructor`](#constructor))
+- [`@this`](#this)
+- [`@extends`](#extends) (or [`@augments`](#extends))
+- [`@enum`](#enum)
+
+#### `class` extensions
+
+- [Property Modifiers](#jsdoc-property-modifiers) `@public`, `@private`, `@protected`, `@readonly`
+
+The meaning is usually the same, or a superset, of the meaning of the tag given at [jsdoc.app](https://jsdoc.app).
+The code below describes the differences and gives some example usage of each tag.
+
+**Note:** You can use [the playground to explore JSDoc support](/play?useJavaScript=truee=4#example/jsdoc-support).
+
+## `@type`
+
+"@type" 태그를 사용하여 타입의 이름을 참조할 수 있습니다 (다음 경우 중 하나인 원시 타입과 TypeScript에 정의되어있거나 JSDoc "@typedef" 태그로 정의되어있거나).
+당신은 대부분 JSDoc 타입들이나 TypeScript 타입을 사용할 것입니다,[기존에 많이 사용하는 `string`](/docs/handbook/basic-types.html)부터 [조건부 타입인 고급 타입](/docs/handbook/advanced-types.html)까지.
+
+```js
+/**
+ * @type {string}
+ */
+var s;
+
+/** @type {Window} */
+var win;
+
+/** @type {PromiseLike<string>} */
+var promisedString;
+
+// DOM 프로퍼티를 사용하여 HTML 요소를 지정할 수 있습니다
+/** @type {HTMLElement} */
+var myElement = document.querySelector(selector);
+element.dataset.myData = "";
+```
+
+`@type` 을 이용하여 유니언 타입을 지정할 수 있습니다. 예를 들어 어떤 것은 string 또는 boolean 일 수 있습니다.
+
+```js
+/**
+ * @type {(string | boolean)}
+ */
+var sb;
+```
+
+괄호는 유니언 타입에 대한 선택 사항입니다.
+
+```js
+/**
+ * @type {string | boolean}
+ */
+var sb;
+```
+
+다양한 구문을 통하여 배열 타입을 지정할 수 있습니다:
+
+```js
+/** @type {number[]} */
+var ns;
+/** @type {Array.<number>} */
+var nds;
+/** @type {Array<number>} */
+var nas;
+```
+
+또한 객체 리터럴 타입들도 지정할 수 있습니다.
+예를 들어, 오브젝트에 프로퍼티 'a' (string) 와 'b' (number)을 사용한 경우 다음 구문을 사용합니다:
+
+```js
+/** @type {{ a: string, b: number }} */
+var var9;
+```
+
+당신은 JSDoc 구문이나 TypeScript 구문을 사용하여 문자열 및 숫자 인덱스 맵과 배열과 비슷한 오브젝트를 표시할 수 있습니다.
+
+```js
+/**
+ * 맵 같은 object는 임의의 `string` 프로퍼티들을 `number`로 바꿔줍니다.
+ *
+ * @type {Object.<string, number>}
+ */
+var stringToNumber;
+
+/** @type {Object.<number, object>} */
+var arrayLike;
+```
+
+앞의 두 타입은 TypeScript의 타입인 `{ [x: string]: number }` 와 `{ [x: number]: any }`를 동일합니다. 컴파일러는 이 두 구문을 모두 이해합니다.
+
+TypeScript나 클로저 구문을 사용하여 함수 타입을 지정할 수 있습니다:
+
+```js
+/** @type {function(string, boolean): number} 클로저 구문 */
+var sbn;
+/** @type {(s: string, b: boolean) => number} TypeScript 구문 */
+var sbn2;
+```
+
+혹은 특정하지 않은 `Function` 타입을 사용할 수 있습니다:
+
+```js
+/** @type {Function} */
+var fn7;
+/** @type {function} */
+var fn6;
+```
+
+클로저의 다른 타입들 또한 작동합니다:
+
+```js
+/**
+ * @type {*} - 'any' 타입으로 쓸 수 있습니다
+ */
+var star;
+/**
+ * @type {?} - 알 수 없는 타입 ('any'와 같습니다)
+ */
+var question;
+```
+
+### 형변환 (Casts)
+
+TypeScript는 클로저 구문을 차용합니다.
+이렇게 하면 괄호로 묶인 표현식 앞에 `@type` 태그를 추가하여 다른 유형으로 형변환할 수 있습니다.
+
+```js
+/**
+ * @type {number | string}
+ */
+var numberOrString = Math.random() < 0.5 ? "hello" : 100;
+var typeAssertedNumber = /** @type {number} */ (numberOrString);
+```
+
+### 타입 가져오기 (Import types)
+
+다른 파일에서 사용하고 있는 타입들은 import 선언을 통하여 가져올 수 있습니다.
+이 구문은 TypeScript에 따라 다르며 JSDoc 표준과 다릅니다:
+
+```js
+// @filename: types.d.ts
+export type Pet = {
+  name: string,
+};
+
+// @filename: main.js
+/**
+ * @param p { import("./types").Pet }
+ */
+function walk(p) {
+  console.log(`Walking ${p.name}...`);
+}
+```
+
+가져온 타입들 또한 별칭 선언에서 사용할 수 있습니다:
+
+```js
+// @filename: types.d.ts
+export type Pet = {
+  name: string,
+};
+// @filename: main.js
+// ---cut---
+/**
+ * @typedef { import("./types").Pet } Pet
+ */
+
+/**
+ * @type {Pet}
+ */
+var myPet;
+myPet.name;
+```
+
+만약 알 수 없는 타입이거나 너무 큰 타입일 경우 모듈에서 얻어온 값의 타입을 사용할 수 있습니다:
+
+```js
+// @filename: accounts.d.ts
+export const userAccount = {
+  name: "Name",
+  address: "An address",
+  postalCode: "",
+  country: "",
+  planet: "",
+  system: "",
+  galaxy: "",
+  universe: "",
+};
+// @filename: main.js
+// ---cut---
+/**
+ * @type {typeof import("./accounts").userAccount }
+ */
+var x = require("./accounts").userAccount;
+```
+
+## `@param` 과 `@returns`
+
+`@param`은 타입 구문인 `@type`과 동일하게 사용합니다, 하지만 매개변수 이름을 추가할 수 있습니다.
+매개변수는 이름 주변에 대괄호와 함께 선택적으로 선언됩니다:
+
+```js
+// 매개변수들은 다양한 구문형식으로 선언될 수 있습니다
+/**
+ * @param {string}  p1 - string 매개변수.
+ * @param {string=} p2 - 선택적 매개변수 (클로저 구문)
+ * @param {string} [p3] - 또다른 선택적 매개변수 (JSDoc 구문).
+ * @param {string} [p4="test"] - 기본값과 선택적 매개변수
+ * @return {string} 이것은 결과 값입니다
+ */
+function stringsStringStrings(p1, p2, p3, p4) {
+  // TODO
+}
+```
+
+마찬가지로, 함수의 반환형일 경우:
+
+```js
+/**
+ * @return {PromiseLike<string>}
+ */
+function ps() {}
+
+/**
+ * @returns {{ a: string, b: number }} - May use '@returns' as well as '@return'
+ */
+function ab() {}
+```
+
+## `@typedef`, `@callback`, and `@param`
+
+`@typedef` 는 복잡한 타입을 정의할 때 사용합니다.
+마치 `@param`과 비슷하게 동작합니다.
+
+```js
+/**
+ * @typedef {Object} SpecialType - 새로운 타입인 'SpecialType'을 생성합니다
+ * @property {string} prop1 - SpecialType의 string 프로퍼티
+ * @property {number} prop2 - SpecialType의 number 프로퍼티
+ * @property {number=} prop3 - SpecialType의 선택적 number 프로퍼티
+ * @prop {number} [prop4] - SpecialType의 선택적 number 프로퍼티
+ * @prop {number} [prop5=42] - SpecialType의 기본값이 존재하는 선택적 number 프로퍼티
+ */
+
+/** @type {SpecialType} */
+var specialTypeObject;
+specialTypeObject.prop3;
+```
+
+`object` 혹은 `Object`를 첫 번째 줄에 사용할 수 있습니다.
+
+```js
+/**
+ * @typedef {object} SpecialType1 - 새로운 타입인 'SpecialType'을 생성합니다
+ * @property {string} prop1 - SpecialType의 string 프로퍼티
+ * @property {number} prop2 - SpecialType의 number 프로퍼티
+ * @property {number=} prop3 - SpecialType의 선택적 number 프로퍼티
+ */
+
+/** @type {SpecialType1} */
+var specialTypeObject1;
+```
+
+`@param` 은 한 번만 사용하는 타입과 비슷한 구문을 허용합니다.
+포함된 프로퍼티의 이름은 파라미터의 이름을 접두사로 사용해야 합니다:
+
+```js
+/**
+ * @param {Object} options - 위의 SpecialType와 비슷합니다.
+ * @param {string} options.prop1
+ * @param {number} options.prop2
+ * @param {number=} options.prop3
+ * @param {number} [options.prop4]
+ * @param {number} [options.prop5=42]
+ */
+function special(options) {
+  return (options.prop4 || 1001) + options.prop5;
+}
+```
+
+`@callback`은 `@typedef`와 비슷합니다. 하지만 이것은 object 타입 대신 특정한 function 타입을 지정합니다:
+
+```js
+/**
+ * @callback Predicate
+ * @param {string} data
+ * @param {number} [index]
+ * @returns {boolean}
+ */
+
+/** @type {Predicate} */
+const ok = (s) => !(s.length % 2);
+```
+
+물론, 이런 타입들은 TypeScript 구문에서 `@typedef` 단 한 줄로 선언할 수 있습니다:
+
+```js
+/** @typedef {{ prop1: string, prop2: string, prop3?: number }} SpecialType */
+/** @typedef {(data: string, index?: number) => boolean} Predicate */
+```
+
+## `@template`
+
+`@template` 태그를 사용하여 제네릭 함수를 선언할 수 있습니다:
+
+```js
+/**
+ * @template T
+ * @param {T} x - 제네릭 매개변수는 리턴 타입과 같게 됩니다
+ * @return {T}
+ */
+function id(x) {
+  return x;
+}
+
+const a = id("string");
+const b = id(123);
+const c = id({});
+```
+
+콤마 혹은 여러 태그를 통하여 여러 타입의 매개변수를 선언할 수 있습니다:
+
+```js
+/**
+ * @template T,U,V
+ * @template W,X
+ */
+```
+
+또한 특정한 매개변수 앞에 타입을 지정할 수 있습니다.
+매개변수 중 오직 첫 번째 매개변수만 제한됩니다:
+
+```js
+/**
+ * @template {string} K - K는 string 혹은 string 리터럴이어야 합니다
+ * @template {{ serious(): string }} Seriousalizable - serious 메서드가 있어야 합니다
+ * @param {K} key
+ * @param {Seriousalizable} object
+ */
+function seriousalize(key, object) {
+  // ????
+}
+```
+
+제네릭 클래스 혹은 타입 선언은 지원되지 않습니다.
+
+## 클래스 (Classes)
+
+클래스는 ES6 클래스로 선언할 수 있습니다.
+
+```js
+class C {
+  /**
+   * @param {number} data
+   */
+  constructor(data) {
+    // 프로퍼티 타입은 추론될 수 있습니다
+    this.name = "foo";
+
+    // 또는 명시적으로 선언할 수도 있습니다
+    /** @type {string | null} */
+    this.title = null;
+
+    // 만약 다른 곳에 선언되어 있다면 어노테이션으로 표기할 수 있습니다.
+    /** @type {number} */
+    this.size;
+
+    this.initialize(data); // 오류가 난다면, 이니셜 라이저는 string을 예상합니다
+  }
+  /**
+   * @param {string} s
+   */
+  initialize = function (s) {
+    this.size = s.length;
+  };
+}
+
+var c = new C(0);
+
+// C는 new 와 함께 호출되어야합니다
+// 하지만 이건 JavaScript이고, 이것은 허용되며
+// 'any'로 간주됩니다.
+var result = C(1);
+```
+
+다음 섹션에 설명된 대로 생성자 함수를 선언할 수 있습니다:
+
+## `@constructor`
+
+컴파일러는 속성 할당을 기반으로 생성자 함수를 추론합니다, 하지만 `@constructor` 태그를 사용하면 더 엄격한 검사와 제안 사항을 확인할 수 있습니다:
+
+```js
+// @checkJs
+// @errors: 2345 2348
+/**
+ * @constructor
+ * @param {number} data
+ */
+function C(data) {
+  // 프로퍼티 타입은 추론될 수 있습니다
+  this.name = "foo";
+
+  // 또는 명시적으로 선언할 수도 있습니다
+  /** @type {string | null} */
+  this.title = null;
+
+  // 만약 다른 곳에 선언되어 있다면 어노테이션으로 표기할 수 있습니다.
+  /** @type {number} */
+  this.size;
+
+  this.initialize(data);
+}
+/**
+ * @param {string} s
+ */
+C.prototype.initialize = function (s) {
+  this.size = s.length;
+};
+
+var c = new C(0);
+c.size;
+
+var result = C(1);
+```
+
+> Note: 오류 메시지는 [a JSConfig](/docs/handbook/tsconfig-json.html) 및 [`checkJs`](/tsconfig#checkJs)가 활성화된 상태에서만 JS 코드 베이스에 나타납니다.
+
+`@constructor`를 사용하면 생성자 함수 `C`안에 `this`가 있는지 검사하므로, `initialize` 메서드에 대한 제안사항을 받으며 만약 인자로 숫자를 넘긴다면 오류가 발생합니다. 또한 `C`를 생성하지 않고 호출만 한다면 에디터에서 경고를 표시할 수 있습니다.
+
+유감스럽게도, 이는 호출가능한 생성자 함수는 `@constructor`를 사용하지 못함을 의미합니다.
+
+## `@this`
+
+컴파일러는 코드가 동작할 컨텍스트가 있다면 보통 `this`의 타입을 파악할 수 있습니다. 그렇지 않은 경우, `@this`를 사용하여 명확하게 `this`의 타입을 지정할 수 있습니다:
+
+```js
+/**
+ * @this {HTMLElement}
+ * @param {*} e
+ */
+function callbackForLater(e) {
+  this.clientHeight = parseInt(e); // 잘 작동해야 합니다!
+}
+```
+
+## `@extends`
+
+Javascript 클래스를 제네릭 기반 클래스로부터 상속(extend)하면, 매개변수가 어떤 타입이 되어야 하는지 지정할 곳이 없습니다. `@extends` 태그는 이러한 타입 매개변수를 위한 위치를 제공합니다:
+
+```js
+/**
+ * @template T
+ * @extends {Set<T>}
+ */
+class SortableSet extends Set {
+  // ...
+}
+```
+
+`@extends`는 클래스에서만 작동합니다. 현재까지, 생성자 함수가 클래스를 상속할 수 있는 방법은 없습니다.
+
+## `@enum`
+
+`@enum` 태그는 멤버가 모두 지정된 객체 리터럴을 만들 수 있게 도와줍니다. Javascript 대부분의 객체 리터럴과 달리, 이 태그는 다른 멤버를 허용하지 않습니다.
+
+```js
+/** @enum {number} */
+const JSDocState = {
+  BeginningOfLine: 0,
+  SawAsterisk: 1,
+  SavingComments: 2,
+};
+
+JSDocState.SawAsterisk;
+```
+
+`@enum`은 TypeScript의 `enum`과 상당히 다르고, 더 간단합니다. 하지만 TypeScript의 열거형(enum)과 달리, `@enum`은 어떠한 타입도 가질 수 있습니다:
+
+```js
+/** @enum {function(number): number} */
+const MathFuncs = {
+  add1: (n) => n + 1,
+  id: (n) => -n,
+  sub1: (n) => n - 1,
+};
+
+MathFuncs.add1;
+```
+
+## 추가 예제 (More examples)
+
+```js
+class Foo {}
+// ---cut---
+var someObj = {
+  /**
+   * @param {string} param1 - 프로퍼티 할당 문서를 참조하세요
+   */
+  x: function (param1) {},
+};
+
+/**
+ * 변수 할당 문서를 참조하세요
+ * @return {Window}
+ */
+let someFunc = function () {};
+
+/**
+ * 클래스 메서드
+ * @param {string} greeting 사용할 인사말
+ */
+Foo.prototype.sayHi = (greeting) => console.log("Hi!");
+
+/**
+ * 화살표 함수 표현식
+ * @param {number} x - 곱하는 수
+ */
+let myArrow = (x) => x * x;
+
+/**
+ * JSX의 무상태 함수형 컴포넌트(SFC)에도 작동합니다
+ * @param {{a: string, b: number}} test - Some param
+ */
+var sfc = (test) => <div>{test.a.charAt(0)}</div>;
+
+/**
+ * 매개변수는 클로저 구문을 사용하면 클래스 생성자로 사용할 수 있습니다.
+ *
+ * @param {{new(...args: any[]): object}} C - The class to register
+ */
+function registerClass(C) {}
+
+/**
+ * @param {...string} p1 - '나머지' 문자열 인수들의 배열 ('any' 타입으로 취급됨)
+ */
+function fn10(p1) {}
+
+/**
+ * @param {...string} p1 - '나머지' 문자열 인수들의 배열 ('any' 타입으로 취급됨)
+ */
+function fn9(p1) {
+  return p1.join();
+}
+```
+
+## 지원하지 않는다고 알려진 패턴 (Patterns that are known NOT to be supported)
+
+Value space 안의 객체를 타입으로 태그하는 것은 객체가 마치 생성자 함수처럼 타입을 생성하지 않는 이상 작동하지 않습니다.
+
+```js
+function aNormalFunction() {}
+/**
+ * @type {aNormalFunction}
+ */
+var wrong;
+/**
+ * 'typeof'를 대신 사용하세요:
+ * @type {typeof aNormalFunction}
+ */
+var right;
+```
+
+접미사(Postfix)는 선택적(Optional) 프로퍼티를 구체화하지 않는 객체 리터럴 타입의 프로퍼티 타입과 같습니다:
+
+```js
+/**
+ * @type {{ a: string, b: number= }}
+ */
+var wrong;
+/**
+ * 프로퍼티 이름 대신 물음표 접미사를 사용하세요:
+ * @type {{ a: string, b?: number }}
+ */
+var right;
+```
+
+`strictNullCheck`가 활성화 중인 경우에만 널러블(Nullable) 타입이 의미가 있습니다.
+
+```js
+/**
+ * @type {?number}
+ * With strictNullChecks: true  -- number | null
+ * With strictNullChecks: false -- number
+ */
+var nullable;
+```
+
+유니언 타입을 사용해도 됩니다:
+
+```js
+/**
+ * @type {number | null}
+ * With strictNullChecks: true  -- number | null
+ * With strictNullChecks: false -- number
+ */
+var unionNullable;
+```
+
+널러블 타입이 아닌 경우에는 아무 의미가 없으며 원래 타입으로 취급합니다:
+
+```js
+/**
+ * @type {!number}
+ * 타입 number를 가집니다
+ */
+var normal;
+```
+
+JSDoc의 타입 체계와 달리, TypeScript는 타입이 오직 null을 포함하거나 하지 않는다 표시할 수 있습니다.
+널러블은 명확하게 구분되지 않습니다 -- 만약 strictNullChecks가 활성화 중이라면, `number`는 널러블하지 않습니다.
+반대의 경우, `number`는 널러블합니다.
+
+### 지원하지 않는 태그 (Unsupported tags)
+
+TypeScript는 지원하지 않는 JSDoc 태그를 무시합니다.
+
+태그 지원을 위한 오픈 이슈가 아래에 있습니다:
+
+- `@const` ([issue #19672](https://github.com/Microsoft/TypeScript/issues/19672))
+- `@inheritdoc` ([issue #23215](https://github.com/Microsoft/TypeScript/issues/23215))
+- `@memberof` ([issue #7237](https://github.com/Microsoft/TypeScript/issues/7237))
+- `@yields` ([issue #23857](https://github.com/Microsoft/TypeScript/issues/23857))
+- `{@link …}` ([issue #35524](https://github.com/Microsoft/TypeScript/issues/35524))
+
+## JS Class extensions
+
+### JSDoc Property Modifiers
+
+From TypeScript 3.8 onwards, you can use JSDoc to modify the properties in a class. First are the accessibility modifiers: `@public`, `@private`, and `@protected`.
+These tags work exactly like `public`, `private`, and `protected` respectively work in TypeScript.
+
+```js twoslash
+// @errors: 2341
+// @ts-check
+
+class Car {
+  constructor() {
+    /** @private */
+    this.identifier = 100;
+  }
+
+  printIdentifier() {
+    console.log(this.identifier);
+  }
+}
+
+const c = new Car();
+console.log(c.identifier);
+```
+
+- `@public` is always implied and can be left off, but means that a property can be reached from anywhere.
+- `@private` means that a property can only be used within the containing class.
+- `@protected` means that a property can only be used within the containing class, and all derived subclasses, but not on dissimilar instances of the containing class.
+
+Next, we've also added the `@readonly` modifier to ensure that a property is only ever written to during initialization.
+
+```js twoslash
+// @errors: 2540
+// @ts-check
+
+class Car {
+  constructor() {
+    /** @readonly */
+    this.identifier = 100;
+  }
+
+  printIdentifier() {
+    console.log(this.identifier);
+  }
+}
+
+const c = new Car();
+console.log(c.identifier);
+```
diff --git a/docs/documentation/ko/javascript/Type Checking JavaScript Files.md b/docs/documentation/ko/javascript/Type Checking JavaScript Files.md
new file mode 100644
index 00000000..daf04600
--- /dev/null
+++ b/docs/documentation/ko/javascript/Type Checking JavaScript Files.md	
@@ -0,0 +1,309 @@
+---
+title: Type Checking JavaScript Files
+layout: docs
+permalink: /ko/docs/handbook/type-checking-javascript-files.html
+oneline: How to add type checking to JavaScript files using TypeScript
+---
+
+`.ts` 파일과 `.js` 파일은 타입을 검사하는 방법에 몇 가지 주목할만한 차이점이 있습니다.
+
+## 클래스 본문의 할당에서 추론된 프로퍼티 (Properties are inferred from assignments in class bodies)
+
+ES2015에는 클래스에 프로퍼티를 선언할 수 있는 수단이 없습니다. 프로퍼티는 객체 리터럴과 같이 동적으로 할당됩니다.
+
+`.js` 파일에서, 컴파일러는 클래스 본문 내부에서 할당된 프로퍼티로부터 프로퍼티들을 추론합니다.
+생성자가 정의되어 있지 않거나, 생성자에서 정의된 타입이 `undefined`나 `null`이 아닐 경우, 프로퍼티의 타입은 생성자에서 주어진 타입과 동일합니다.
+전자에 해당 프로퍼티의 경우, 할당되었던 모든 값들의 타입을 가진 유니언 타입이 됩니다.
+생성자에 정의된 프로퍼티는 항상 존재하는 것으로 가정하는 반면, 메서드, getter, setter에서만 정의된 프로퍼티는 선택적인 것으로 간주합니다.
+
+```js twoslash
+// @checkJs
+// @errors: 2322
+class C {
+  constructor() {
+    this.constructorOnly = 0;
+    this.constructorUnknown = undefined;
+  }
+  method() {
+    this.constructorOnly = false; // 오류, constructorOnly는 Number 타입임
+    this.constructorUnknown = "plunkbat"; // 성공, constructorUnknown의 타입은 string | undefined
+    this.methodOnly = "ok"; // 성공, 그러나 methodOnly는 undefined 타입 또한 허용됨
+  }
+  method2() {
+    this.methodOnly = true; // 이 또한 성공, methodOnly의 타입은 string | boolean | undefined
+  }
+}
+```
+
+프로퍼티가 클래스 본문에서 설정되지 않았다면, 알 수 없는 것으로 간주합니다.
+클래스에 읽기 전용 프로퍼티가 있는 경우, 생성자에서 선언에 JSDoc을 사용하여 타입을 추가하여 표시합니다.
+이후엔 초기화하더라도 값을 지정할 필요가 없습니다.
+
+```js twoslash
+// @checkJs
+// @errors: 2322
+class C {
+  constructor() {
+    /** @type {number | undefined} */
+    this.prop = undefined;
+    /** @type {number | undefined} */
+    this.count;
+  }
+}
+
+let c = new C();
+c.prop = 0; // 성공
+c.count = "string"; // 오류: string 은 number|undefined에 할당할 수 없음
+```
+
+## 생성자 함수와 클래스는 동일 (Constructor functions are equivalent to classes)
+
+ES2015 이전에는, JavaScript는 클래스 대신 생성자 함수를 사용했습니다.
+컴파일러는 이러한 패턴을 지원하며 생성자 함수를 ES2015 클래스와 동일한 것으로 이해합니다.
+앞서 설명한 프로퍼티 추론 규칙 또한 정확히 같은 방식으로 작용합니다.
+
+```js twoslash
+// @checkJs
+// @errors: 2683 2322
+function C() {
+  this.constructorOnly = 0;
+  this.constructorUnknown = undefined;
+}
+C.prototype.method = function () {
+  this.constructorOnly = false; // 오류
+  this.constructorUnknown = "plunkbat"; // 성공, 타입은 string | undefined가 됨
+};
+```
+
+## CommonJS 모듈 지원 (CommonJS modules are supported)
+
+`.js` 파일에서, TypeScript는 CommonJS 모듈 포맷을 이해합니다.
+`exports`와 `module.exports` 할당은 export 선언으로 인식됩니다.
+마찬가지로, `require` 함수 호출은 모듈 import로 인식됩니다. 예를 들어:
+
+```js
+// `import module "fs"`와 같음
+const fs = require("fs");
+
+// `export function readFile`과 같음
+module.exports.readFile = function(f) {
+    return fs.readFileSync(f);
+}
+```
+
+JavaScript의 모듈 지원은 TypeScript의 모듈 지원보다 구문적으로 훨씬 관용적입니다.
+따라서 대부분의 할당과 선언의 조합이 지원됩니다.
+
+## 클래스, 함수, 객체 리터럴은 네임스페이스 (Classes, functions, and object literals are namespaces)
+
+`.js` 파일에 있는 클래스는 네임스페이스입니다.
+예를 들어, 다음과 같이 클래스를 중첩하는 데에 사용할 수 있습니다:
+
+```js twoslash
+class C {}
+C.D = class {};
+```
+
+그리고 ES2015 이전 코드의 경우, 정적 메서드를 나타내는 데에 사용할 수도 있습니다:
+
+```js twoslash
+function Outer() {
+  this.y = 2;
+}
+
+Outer.Inner = function () {
+  this.yy = 2;
+};
+
+Outer.innter();
+```
+
+또한 간단한 네임스페이스를 생성하는 데에 사용할 수도 있습니다:
+
+```js twoslash
+var ns = {};
+ns.C = class {};
+ns.func = function () {};
+
+ns;
+```
+
+다른 번형도 허용됩니다:
+
+```js twoslash
+// 즉시 호출 함수 (IIFE)
+var ns = (function (n) {
+  return n || {};
+})();
+ns.CONST = 1;
+
+// 전역으로 기본 설정
+var assign =
+  assign ||
+  function () {
+    // 여기엔 코드를
+  };
+assign.extra = 1;
+```
+
+## 객체 리터럴은 확장 가능 (Object literals are open-ended)
+
+`.ts` 파일에서, 변수 선언을 초기화하는 객체 리터럴은 선언에 해당 타입을 부여합니다.
+원본 리터럴에 명시되어 있지 않은 새 멤버는 추가될 수 없습니다.
+이 규칙은 `.js` 파일에선 완화됩니다; 객체 리터럴은 원본에 정의되지 않은 새로운 프로퍼티를 조회하고 추가하는 것이 허용되는 확장 가능한 타입(인덱스 시그니처)을 갖습니다.
+예를 들어:
+
+```js twoslash
+var obj = { a: 1 };
+obj.b = 2; // 허용됨
+```
+
+객체 리터럴은 마치 닫힌 객체가 아니라 열린 맵(maps)으로 다뤄지도록 `[x:string]: any`와 같은 인덱스 시그니처를 가진 것처럼 동작합니다.
+
+다른 특정 JavaScript 검사 동작과 마찬가지로, 해당 동작은 변수에 JSDoc 타입을 지정하여 변경할 수 있습니다. 예를 들어:
+
+```js twoslash
+// @checkJs
+// @errors: 2339
+/** @type {{a: number}} */
+var obj = { a: 1 };
+obj.b = 2; // 오류, {a: number}타입엔 b 프로퍼티가 없음
+```
+
+## null, undefined 및 빈 배열 이니셜라이저는 any 혹은 any[] 타입 (null, undefined, and empty array initializers are of type any or any[])
+
+null 또는 undefined로 초기화된 변수나 매개변수 또는 프로퍼티는, 엄격한 null 검사가 있더라도 any 타입을 갖게 될 것입니다.
+[]로 초기화된 변수나 매개변수 또는 프로퍼티는, 엄격한 null 검사가 있더라도 any[] 타입을 갖게 될 것입니다.
+위에서 설명한 여러 이니셜라이저(initializer)를 갖는 프로퍼티만이 유일한 예외입니다.
+
+```js twoslash
+function Foo(i = null) {
+  if (!i) i = 1;
+  var j = undefined;
+  j = 2;
+  this.l = [];
+}
+
+var foo = new Foo();
+foo.l.push(foo.i);
+foo.l.push("end");
+```
+
+## 함수 매개변수는 기본적으로 선택 사항 (Function parameters are optional by default)
+
+ES2015 이전의 JavaScript는 선택적인 매개변수를 지정할 방법이 없었기 때문에, `.js` 파일에선 모든 함수의 매개변수는 선택적인 것으로 간주됩니다.
+선언된 매개변수보다 적은 인수로 호출하는 것이 허용됩니다.
+
+그러나 너무 많은 인수를 넣어 호출하면 오류를 일으킨다는 것에 유의하세요.
+
+예를 들어:
+
+```js twoslash
+// @checkJs
+// @strict: false
+// @errors: 7006 7006 2554
+function bar(a, b) {
+  console.log(a + " " + b);
+}
+
+bar(1); // 성공, 두 번째 인수는 선택 사항임
+bar(1, 2);
+bar(1, 2, 3); // 오류, 인수의 갯수가 너무 많음
+```
+
+JSDoc 표시가 된 함수는 이 규칙에서 예외입니다.
+JSDoc의 선택적 매개변수 구문 (`[` `]`) 을 사용하여 선택 사항을 표시할 수 있습니다. 예시:
+
+```js twoslash
+/**
+ * @param {string} [somebody] - 누군가의 이름
+ */
+function sayHello(somebody) {
+  if (!somebody) {
+    somebody = "John Doe";
+  }
+  console.log("Hello " + somebody);
+}
+
+sayHello();
+```
+
+## `arguments` 사용으로부터 추론된 var-args 매개변수 선언 (Var-args parameter declaration inferred from use of `arguments`)
+
+`arguments` 참조를 참조하는 본문을 가진 함수는, 암묵적으로 var-args 매개변수(예: `(...arg: any[]) => any`)를 갖는 것으로 간주합니다. JSDoc의 var-args 구문을 사용하여 인수의 타입을 지정할 수 있습니다.
+
+```js twoslash
+/** @param {...number} args */
+function sum(/* numbers */) {
+  var total = 0;
+  for (var i = 0; i < arguments.length; i++) {
+    total += arguments[i];
+  }
+  return total;
+}
+```
+
+## 타입이 지정되지 않은 매개변수는 기본적으로 `any`임 (Unspecified type parameters default to `any`)
+
+JavaScript에는 제네릭 타입의 매개변수를 지정하는 구문이 없으므로, 타입이 지정되지 않은 매개변수는 기본적으로 `any` 타입입니다.
+
+### 확장 절에서 (In extends clause)
+
+예를 들어, `React.Component`는 `Props`와 `State`라는 두 타입의 매개변수를 갖도록 정의되어 있습니다.
+`.js` 파일에는 이러한 것들을 확장 절에 지정할 수 있는 정당한 방법이 없습니다. 기본적으로 해당 타입 인수는 `any`가 될 것입니다:
+
+```js
+import { Component } from "react";
+
+class MyComponent extends Component {
+    render() {
+        this.props.b; // this.props의 타입이 any이므로 허용됨
+    }
+}
+```
+
+타입을 명시적으로 지정하려면 JSDoc의 `@augments`를 사용하세요. 예를 들어:
+
+```js
+import { Component } from "react";
+
+/**
+ * @augments {Component<{a: number}, State>}
+ */
+class MyComponent extends Component {
+    render() {
+        this.props.b; // 오류: b 는 {a:number}에 속하지 않음
+    }
+}
+```
+
+### JSDoc 참조에서 (In JSDoc references)
+
+JSDoc의 지정되지 않은 타입 인수는 기본적으로 any입니다:
+
+```js
+/** @type{Array} */
+var x = [];
+
+x.push(1);        // 성공
+x.push("string"); // 성공, x는 Array<any> 타입임
+
+/** @type{Array.<number>} */
+var y = [];
+
+y.push(1);        // 성공
+y.push("string"); // 오류, string을 number 타입에 할당할 수 없음
+
+```
+
+### 함수 호출에서 (In function calls)
+
+제네릭 함수의 호출은 인수를 사용해 타입 매개변수를 추론합니다. 때때로 이 과정은 추론 소스가 부족하여 어떠한 타입도 추론하지 못하는 경우가 있습니다; 이러한 경우, 매개변수 타입은 기본적으로 `any`입니다. 예를 들어:
+
+```js
+var p = new Promise((resolve, reject) => { reject() });
+
+p; // Promise<any>;
+```
+
+JSDoc의 모든 기능은 [여기](/docs/handbook/jsdoc-supported-types.html)에서 확인할 수 있습니다.
diff --git a/docs/documentation/ko/project-config/Compiler Options in MSBuild.md b/docs/documentation/ko/project-config/Compiler Options in MSBuild.md
new file mode 100644
index 00000000..d25dfd0a
--- /dev/null
+++ b/docs/documentation/ko/project-config/Compiler Options in MSBuild.md	
@@ -0,0 +1,133 @@
+---
+title: Compiler Options in MSBuild
+layout: docs
+permalink: /ko/docs/handbook/compiler-options-in-msbuild.html
+oneline: Which compiler options are available in MSBuild projects.
+---
+
+## 개요 (Overview)
+
+컴파일러 옵션은 MSBuild 프로젝트 내의 MSBuild 프로퍼티를 사용하여 지정할 수 있습니다.
+
+## 예제 (Example)
+
+```XML
+  <PropertyGroup Condition="'$(Configuration)' == 'Debug'">
+    <TypeScriptRemoveComments>false</TypeScriptRemoveComments>
+    <TypeScriptSourceMap>true</TypeScriptSourceMap>
+  </PropertyGroup>
+  <PropertyGroup Condition="'$(Configuration)' == 'Release'">
+    <TypeScriptRemoveComments>true</TypeScriptRemoveComments>
+    <TypeScriptSourceMap>false</TypeScriptSourceMap>
+  </PropertyGroup>
+  <Import
+      Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets"
+      Condition="Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets')" />
+```
+
+## 맵핑 (Mappings)
+
+컴파일러 옵션                              | MSBuild 프로퍼티 이름                      | 허용된 값
+---------------------------------------------|--------------------------------------------|-----------------
+`--allowJs`                                  | *MSBuild에서 지원되지 않습니다*                 |
+`--allowSyntheticDefaultImports`             | TypeScriptAllowSyntheticDefaultImports     | boolean
+`--allowUnreachableCode`                     | TypeScriptAllowUnreachableCode             | boolean
+`--allowUnusedLabels`                        | TypeScriptAllowUnusedLabels                | boolean
+`--alwaysStrict`                             | TypeScriptAlwaysStrict                     | boolean
+`--baseUrl`                                  | TypeScriptBaseUrl                          | 파일 경로
+`--charset`                                  | TypeScriptCharset                          |
+`--declaration`                              | TypeScriptGeneratesDeclarations            | boolean
+`--declarationDir`                           | TypeScriptDeclarationDir                   | 파일 경로
+`--diagnostics`                              | *MSBuild에서 지원되지 않습니다*                 |
+`--disableSizeLimit`                         | *MSBuild에서 지원되지 않습니다*                 |
+`--emitBOM`                                  | TypeScriptEmitBOM                          | boolean
+`--emitDecoratorMetadata`                    | TypeScriptEmitDecoratorMetadata            | boolean
+`--emitDeclarationOnly`                      | TypeScriptEmitDeclarationOnly              | boolean
+`--esModuleInterop`                          | TypeScriptESModuleInterop                  | boolean
+`--experimentalAsyncFunctions`               | TypeScriptExperimentalAsyncFunctions       | boolean
+`--experimentalDecorators`                   | TypeScriptExperimentalDecorators           | boolean
+`--forceConsistentCasingInFileNames`         | TypeScriptForceConsistentCasingInFileNames | boolean
+`--help`                                     | *MSBuild에서 지원되지 않습니다*                 |
+`--importHelpers`                            | TypeScriptImportHelpers                    | boolean
+`--inlineSourceMap`                          | TypeScriptInlineSourceMap                  | boolean
+`--inlineSources`                            | TypeScriptInlineSources                    | boolean
+`--init`                                     | *MSBuild에서 지원되지 않습니다*                 |
+`--isolatedModules`                          | TypeScriptIsolatedModules                  | boolean
+`--jsx`                                      | TypeScriptJSXEmit                          | `React` 또는 `Preserve`
+`--jsxFactory`                               | TypeScriptJSXFactory                       | 제한된 이름
+`--lib`                                      | TypeScriptLib                              | 쉼표로 구분된 문자열 목록
+`--listEmittedFiles`                         | *MSBuild에서 지원되지 않습니다*                 |
+`--listFiles`                                | *MSBuild에서 지원되지 않습니다*                 |
+`--locale`                                   | *자동*                                | 자동으로 PreferredUILang 값 설정
+`--mapRoot`                                  | TypeScriptMapRoot                          | 파일 경로
+`--maxNodeModuleJsDepth`                     | *MSBuild에서 지원되지 않습니다*                 |
+`--module`                                   | TypeScriptModuleKind                       | `AMD`, `CommonJs`, `UMD`, `System` or `ES6`
+`--moduleResolution`                         | TypeScriptModuleResolution                 | `Classic` 또는 `Node`
+`--newLine`                                  | TypeScriptNewLine                          | `CRLF` 또는 `LF`
+`--noEmit`                                   | *MSBuild에서 지원되지 않습니다*                 |
+`--noEmitHelpers`                            | TypeScriptNoEmitHelpers                    | boolean
+`--noEmitOnError`                            | TypeScriptNoEmitOnError                    | boolean
+`--noFallthroughCasesInSwitch`               | TypeScriptNoFallthroughCasesInSwitch       | boolean
+`--noImplicitAny`                            | TypeScriptNoImplicitAny                    | boolean
+`--noImplicitReturns`                        | TypeScriptNoImplicitReturns                | boolean
+`--noImplicitThis`                           | TypeScriptNoImplicitThis                   | boolean
+`--noImplicitUseStrict`                      | TypeScriptNoImplicitUseStrict              | boolean
+`--noStrictGenericChecks`                    | TypeScriptNoStrictGenericChecks            | boolean
+`--noUnusedLocals`                           | TypeScriptNoUnusedLocals                   | boolean
+`--noUnusedParameters`                       | TypeScriptNoUnusedParameters               | boolean
+`--noLib`                                    | TypeScriptNoLib                            | boolean
+`--noResolve`                                | TypeScriptNoResolve                        | boolean
+`--out`                                      | TypeScriptOutFile                          | 파일 경로
+`--outDir`                                   | TypeScriptOutDir                           | 파일 경로
+`--outFile`                                  | TypeScriptOutFile                          | 파일 경로
+`--paths`                                    | *MSBuild에서 지원되지 않습니다*                 |
+`--preserveConstEnums`                       | TypeScriptPreserveConstEnums               | boolean
+`--preserveSymlinks`                         | TypeScriptPreserveSymlinks                 | boolean
+`--listEmittedFiles`                         | *MSBuild에서 지원되지 않습니다*                 |
+`--pretty`                                   | *MSBuild에서 지원되지 않습니다*                 |
+`--reactNamespace`                           | TypeScriptReactNamespace                   | string
+`--removeComments`                           | TypeScriptRemoveComments                   | boolean
+`--rootDir`                                  | TypeScriptRootDir                          | 파일 경로
+`--rootDirs`                                 | *MSBuild에서 지원되지 않습니다*                 |
+`--skipLibCheck`                             | TypeScriptSkipLibCheck                     | boolean
+`--skipDefaultLibCheck`                      | TypeScriptSkipDefaultLibCheck              | boolean
+`--sourceMap`                                | TypeScriptSourceMap                        | 파일 경로
+`--sourceRoot`                               | TypeScriptSourceRoot                       | 파일 경로
+`--strict`                                   | TypeScriptStrict                           | boolean
+`--strictFunctionTypes`                      | TypeScriptStrictFunctionTypes              | boolean
+`--strictNullChecks`                         | TypeScriptStrictNullChecks                 | boolean
+`--strictPropertyInitialization`             | TypeScriptStrictPropertyInitialization     | boolean
+`--stripInternal`                            | TypeScriptStripInternal                    | boolean
+`--suppressExcessPropertyErrors`             |  TypeScriptSuppressExcessPropertyErrors    | boolean
+`--suppressImplicitAnyIndexErrors`           | TypeScriptSuppressImplicitAnyIndexErrors   | boolean
+`--target`                                   | TypeScriptTarget                           | `ES3`, `ES5`, 또는 `ES6`
+`--traceResolution`                          | *MSBuild에서 지원되지 않습니다*                 |
+`--types`                                    | *MSBuild에서 지원되지 않습니다*                 |
+`--typeRoots`                                | *MSBuild에서 지원되지 않습니다*                 |
+`--useDefineForClassFields`                  | TypeScriptUseDefineForClassFields          | boolean
+`--watch`                                    | *MSBuild에서 지원되지 않습니다*                 |
+*MSBuild 전용 옵션*                        | TypeScriptAdditionalFlags                  | *모든 컴파일러 옵션*
+
+## 나의 Visual Studio 버전에서 지원하는 것은? (What is supported in my version of Visual Studio?)
+
+`C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets` 파일을 확인하세요.  
+MSBuild XML 태그와 `tsc` 컴파일러 옵션 사이의 신뢰할 수 있는 맵핑이 여기에 있습니다.
+
+## 툴버전 (ToolsVersion)
+
+프로젝트 파일의 `<TypeScriptToolsVersion>1.7</TypeScriptToolsVersion>` 프로퍼티 값은 빌드하는 데 사용할 컴파일러 버전을 식별합니다 (이 예제에서는 1.7).  
+이렇게 하면 프로젝트가 다른 컴퓨터에 있는 동일한 버전의 컴파일러에 대한 빌드를 허용합니다.
+
+만약 `TypeScriptToolsVersion`이 지정되지 않으면, 설치된 최신 컴파일러 버전을 사용하여 빌드합니다.
+
+최신 버전의 TS를 사용하는 사용자에게는, 첫 로드 시 프로젝트를 업그레이드하라는 메시지가 표시됩니다.
+
+## TypeScriptCompileBlocked
+
+다른 빌드 도구를 사용하여 프로젝트 (예: gulp, grunt 등) 그리고 개발을 위한 VS와 디버깅 환경을 사용하는 경우 프로젝트에서 `<TypeScriptCompileBlocked>true</TypeScriptCompileBlocked>`를 설정하세요.
+이렇게 하면 모든 편집 지원이 제공되지만 F5키를 눌러도 빌드되지 않습니다.
+
+## TypeScriptEnableIncrementalMSBuild (TypeScript 4.2 Beta and later)
+
+By default, MSBuild will attempt to only run the TypeScript compiler when the project's source files have been updated since the last compilation.
+However, if this behavior is causing issues, such as when TypeScript's `incremental` option is enabled, set `<TypeScriptEnableIncrementalMSBuild>false</TypeScriptEnableIncrementalMSBuild>` to ensure the TypeScript compiler is invoked with every run of MSBuild.
diff --git a/docs/documentation/ko/project-config/Compiler Options.md b/docs/documentation/ko/project-config/Compiler Options.md
new file mode 100644
index 00000000..5b1bd322
--- /dev/null
+++ b/docs/documentation/ko/project-config/Compiler Options.md	
@@ -0,0 +1,137 @@
+---
+title: tsc CLI Options
+layout: docs
+permalink: /ko/docs/handbook/compiler-options.html
+oneline: A very high-level overview of the CLI compiler options for tsc
+disable_toc: true
+---
+
+## CLI로 사용하기 (Using the CLI)
+
+로컬에서 `tsc`를 실행하면 `tsconfig.json`가 정의한 가장 가까운 프로젝트를 컴파일하고, 원하는 파일 glob을 전달하여
+TypeScript 파일 집합을 컴파일할 수 있습니다.
+
+```sh
+# tsconfig.json에 대한 fs를 역방향으로 검토하여 컴파일 실행
+tsc
+
+# 컴파일러 기본값으로 index.ts만 트랜스파일
+tsc index.ts
+
+# 기본 설정으로 src 폴더 안에 모든 .ts 파일을 트랜스파일
+tsc src/*.ts
+
+# tsconfig.json의 컴파일러 설정으로 src 폴더 안에 모든 .ts 파일을 트랜스파일
+tsc --project tsconfig.json src/*.ts
+```
+
+## 컴파일러 옵션 (Compiler Options)
+
+tsconfig의 컴파일러 옵션에 대한 더 많은 정보를 찾는다면, 베타 TSConfig 레퍼런스를
+[v2 사이트](https://www.typescriptlang.org/v2/en/tsconfig)에서 확인하세요.
+
+옵션                                           | 타입      | 기본값                         | 설명
+-----------------------------------------------|-----------|--------------------------------|----------------------------------------------------------------------
+`--allowJs`                                    | `boolean` | `false`                        | JavaScript 파일의 컴파일을 허용합니다
+`--allowSyntheticDefaultImports`               | `boolean` | `module === "system"` 또는 `--esModuleInterop` | default export가 없는 모듈에서 default imports를 허용합니다. 코드 방출에는 영향을 주지 않으며, 타입 검사만 수행합니다.
+`--allowUmdGlobalAccess`                       | `boolean` | `false`                        | 모듈에서 전역 UMD 접근을 허용합니다.
+`--allowUnreachableCode`                       | `boolean` | `false`                        | 도달할 수 없는 코드에 대한 오류를 보고하지 않습니다.
+`--allowUnusedLabels`                          | `boolean` | `false`                        | 사용되지 않는 레이블에 대한 오류를 보고하지 않습니다.
+`--alwaysStrict`                               | `boolean` | `false`                        | strict mode에서 파싱하고 각 소스 파일에 대해 `"use strict"`를 내보냅니다.
+`--assumeChangesOnlyAffectDirectDependencies`  | `boolean` | `false`                        | 파일 안에서의 변경은 파일이 직접 의존하는 파일에만 영향을 미친다고 가정하고 '--incremental' 및 '-watch'로 다시 컴파일 합니다.
+`--baseUrl`                                    | `string`  |                                | 비-상대적 모듈 이름을 해석하기 위한 기본 디렉터리. 자세한 내용은 [모듈 해석 문서](./module-resolution.md#base-url)을 참조하세요.
+`--build`<br/>`-b`                             | `boolean` | `false`                        | [프로젝트 레퍼런스](./project-references.md)에서 지정한 이 프로젝트와 프로젝트의 모든 의존성을 빌드 합니다. 이 플래그는 이 페이지의 다른 플래그들과는 호환되지 않음에 유의하세요 자세한 내용은 [여기](./project-references.md)를 보세요.
+`--charset`                                    | `string`  | `"utf8"`                       | 입력 파일의 문자 집합입니다.
+`--checkJs`                                    | `boolean` | `false`                        | `.js` 파일에 오류를 보고합니다. `--allowJs`와 함께 사용하세요.
+`--composite`                                  | `boolean` | `true`                         | TypeScript가 프로젝트를 컴파일하기 위해 참조된 프로젝트의 출력을 찾을 위치를 결정할 수 있는지 확인합니다.
+`--declaration`<br/>`-d`                       | `boolean` | `false`                        | 해당하는 `.d.ts` 파일을 생성합니다.
+`--declarationDir`                             | `string`  |                                | 생성된 선언 파일의 출력 디렉토리입니다.
+`--declarationMap`                             | `boolean` | `false`                        | 해당하는 '.d.ts'파일 각각에 대한 소스 맵을 생성합니다.
+`--diagnostics`                                | `boolean` | `false`                        | 진단 정보를 보여줍니다.
+`--disableSizeLimit`                           | `boolean` | `false`                        | JavaScript 프로젝트의 사이즈 제한을 비활성화합니다.
+`--downlevelIteration`                         | `boolean` | `false`                        | ES5 또는 ES3를 대상으로 할 때 `for..of`, 스프레드와 구조분해할당에서 이터러블을 완전히 지원합니다.
+`--emitBOM`                                    | `boolean` | `false`                        | 출력 파일의 시작 부분에 UTF-8 바이트 순서표(BOM)를 내보냅니다.
+`--emitDeclarationOnly`                        | `boolean` | `false`                        | '.d.ts' 선언 파일만 내보냅니다.
+`--emitDecoratorMetadata`<sup>[1]</sup>        | `boolean` | `false`                        | 소스에 데코레이터 선언에 대한 설계-타입 메타 데이터를 내보냅니다. 자세한 내용은 [#2577 이슈](https://github.com/Microsoft/TypeScript/issues/2577)을 참조하세요.
+`--esModuleInterop`                            | `boolean` | `false`                        | 런타임 바벨 생태계 호환성을 위한 `__importStar`와 `__importDefault` 헬퍼를 내보내고 타입 시스템 호환성을 위해 `--allowSyntheticDefaultImports`를 활성화합니다.
+`--experimentalDecorators`<sup>[1]</sup>       | `boolean` | `false`                        | ES 데코레이터에 대한 실험적인 지원을 사용하도록 활성화합니다.
+`--extendedDiagnostics`                        | `boolean` | `false`                        | 자세한 진단 정보를 표시합니다
+`--forceConsistentCasingInFileNames`           | `boolean` | `false`                        | 동일 파일 참조에 대해 일관성 없는 대소문자를 비활성화합니다.
+`--generateCpuProfile`                         | `string`  | `profile.cpuprofile`           | 주어진 경로에 cpu 프로필을 생성합니다. 파일 경로 대신 존재하는 디렉터리 이름을 전달하면 타임스탬프 이름이 지정된 프로필이 그 디렉터리에 대신 생성됩니다.
+`--help`<br/>`-h`                              |           |                                | 도움말을 출력합니다.
+`--importHelpers`                              | `boolean` | `false`                        | [`tslib`](https://www.npmjs.com/package/tslib)에서 방출된 헬퍼를 import 합니다.  (예. `__extends`, `__rest`, 등..)
+`--importsNotUsedAsValues`                     | `string`  | `remove`                       | 타입을 위해서만 사용하는 import를 위한 내보내기/검사 동작을 지정합니다. `"remove"`와 `"preserve"`는 사이드 이펙트를 위해 사용하지 않는 import를 내보낼지 지정하고, `"error"`는 타입을 위해서만 사용하는 import는 `import type`으로 작성하게 강제합니다.
+`--incremental`                                | `boolean` | `composite`이 켜져있으면 `true` 아니면 `false` | 이전 컴파일에서 디스크의 파일로 정보를 읽거나/기록하여 증분 컴파일을 활성화합니다. 이 파일은 `--tsBuildInfoFile` 플래그로 컨트롤합니다.
+`--inlineSourceMap`                            | `boolean` | `false`                        | 별도의 파일 대신 소스 맵으로 단일 파일을 내보냅니다.
+`--inlineSources`                              | `boolean` | `false`                        | 단일 파일 내에서 소스 맵과 함께 소스를 내보냅니다. `--inlineSourceMap` 또는 `--sourceMap`을 설정해야 합니다.
+`--init`                                       |           |                                | TypeScript 프로젝트를 초기화하고 `tsconfig.json` 파일을 생성합니다.
+`--isolatedModules`                            | `boolean` | `false`                        | 추가 검사를 수행하여 별도의 컴파일 (예를 들어 [`트랜스파일된 모듈`](https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API#a-simple-transform-function) 혹은 [@babel/plugin-transform-typescript](https://babeljs.io/docs/en/babel-plugin-transform-typescript)) 이 안전한지 확인합니다.
+`--jsx`                                        | `string`  | `"Preserve"`                   | `.tsx` 파일에서 JSX 지원: `"React"`, `"Preserve"`, `"react-native"`. [JSX](./jsx.md)를 확인하세요.
+`--jsxFactory`                                 | `string`  | `"React.createElement"`        | 리액트 JSX 방출을 대상으로 할 때 사용할 JSX 팩토리 함수를 지정합니다. 예: `React.createElement` 또는 `h`.
+`--keyofStringsOnly`                           | `boolean` | `false`                        | `keyof`를 문자열 값으로 된 프로퍼티 이름에만 적용합니다 (숫자나 심벌에서는 안됨).
+`--useDefineForClassFields`                    | `boolean` | `false`                        | 클래스 필드를 ECMAScript-표준 시맨틱으로 내보냅니다.
+`--lib`                                        | `string[]`|                                | 컴파일에 포함될 라이브러리 파일 목록입니다.<br/>가능한 값은 다음과 같습니다:  <br/>► `ES5` <br/>► `ES6` <br/>► `ES2015` <br/>► `ES7` <br/>► `ES2016` <br/>► `ES2017` <br/>► `ES2018` <br/>► `ESNext` <br/>► `DOM` <br/>► `DOM.Iterable` <br/>► `WebWorker` <br/>► `ScriptHost` <br/>► `ES2015.Core` <br/>► `ES2015.Collection` <br/>► `ES2015.Generator` <br/>► `ES2015.Iterable` <br/>► `ES2015.Promise` <br/>► `ES2015.Proxy` <br/>► `ES2015.Reflect` <br/>► `ES2015.Symbol` <br/>► `ES2015.Symbol.WellKnown` <br/>► `ES2016.Array.Include` <br/>► `ES2017.object` <br/>► `ES2017.Intl` <br/>► `ES2017.SharedMemory` <br/>► `ES2017.String` <br/>► `ES2017.TypedArrays` <br/>► `ES2018.Intl` <br/>► `ES2018.Promise` <br/>► `ES2018.RegExp` <br/>► `ESNext.AsyncIterable` <br/>► `ESNext.Array` <br/>► `ESNext.Intl` <br/>► `ESNext.Symbol` <br/><br/> 주의사항: `--lib`가 지정되지 않으면 라이브러리의 기본 리스트가 삽입됩니다. 주입되는 기본 라이브러리는 다음과 같습니다:  <br/> ► `--target ES5`: `DOM,ES5,ScriptHost`<br/>  ► `--target ES6`: `DOM,ES6,DOM.Iterable,ScriptHost`
+`--listEmittedFiles`                           | `boolean` | `false`                        | 컴파일의 일부로 생성된 파일의 이름을 출력합니다.
+`--listFiles`                                  | `boolean` | `false`                        | 컴파일에 포함된 파일의 이름을 출력합니다.
+`--locale`                                     | `string`  | *(플랫폼 별)*          | 오류 메시지를 표시하는 데 사용할 지역화, 예: en-us. <br/>가능한 값은 다음과 같습니다:  <br/>► 영어 (US): `en` <br/>► 체코어: `cs` <br/>► 독일어: `de` <br/>► 스페인어: `es` <br/>► 프랑스어: `fr` <br/>► 이탈리아어: `it` <br/>► 일본어: `ja` <br/>► 한국어: `ko` <br/>► 폴란드어: `pl` <br/>► 포르투갈어(브라질): `pt-BR` <br/>► 러시아어: `ru` <br/>► 터키어: `tr` <br/>► 중국어 간체: `zh-CN`  <br/>► 중국어 번체: `zh-TW`
+`--mapRoot`                                    | `string`  |                                | 디버거가 생성된 위치가 아닌 맵 파일의 위치를 지정합니다. .map 파일이 .js 파일과 다른 위치에 런타임 시 위치할 경우 이 옵션을 사용하세요. 지정된 위치는 sourceMap에 포함되어 맵 파일이 위치할 디버거를 지정합니다. 이 플래그는 지정된 경로를 작성하지 않고 해당 위치에 맵 파일을 생성합니다. 대신 파일을 지정된 경로로 이동하는 빌드 후 단계를 작성하십시오.
+`--maxNodeModuleJsDepth`                       | `number`  | `0`                            | node_modules 및 로드 JavaScript 파일 아래에서 검색할 최대 의존성 깊이. `--allowJs`에만 적용됩니다.
+`--module`<br/>`-m`                            | `string`  | `target === "ES3" or "ES5" ? "CommonJS" : "ES6"`   | 모듈 코드 생성 지정: `"None"`, `"CommonJS"`, `"AMD"`, `"System"`, `"UMD"`, `"ES6"`, `"ES2015"` 또는 `"ESNext"`.<br/>► `"AMD"`와 `"System"`만 `--outFile`과 함께 사용할 수 있습니다.<br/>► `"ES6"`와 `"ES2015"` 값은 `"ES5"` 또는 이하를 대상으로 할 때 사용할 수 있습니다.
+`--moduleResolution`                           | `string`  | `module === "AMD" or "System" or "ES6" ?  "Classic" : "Node"`                    | 모듈 해석 방법 결정. Node.js/io.js 스타일 해석의 경우, `"Node"` 또는 `"Classic"` 중 하나입니다. 자세한 내용은 [모듈 해석 문서](./module-resolution.md)를 참조하세요.
+`--newLine`                                    | `string`  | *(플랫폼 별)*          | 파일을 내보낼 때 사용되는 지정된 라인 끝의 시퀀스 사용: `"crlf"` (윈도우) 또는 `"lf"` (유닉스)."
+`--noEmit`                                     | `boolean` | `false`                        | 출력을 내보내지 않습니다.
+`--noEmitHelpers`                              | `boolean` | `false`                        | 컴파일된 출력에서는 `__extends`와 같은 커스텀 헬퍼 함수를 생성하지 않습니다.
+`--noEmitOnError`                              | `boolean` | `false`                        | 오류가 보고된 경우 출력을 내보내지 않습니다.
+`--noErrorTruncation`                          | `boolean` | `false`                        | 오류 메세지를 줄이지 않습니다.
+`--noFallthroughCasesInSwitch`                 | `boolean` | `false`                        | 스위치 문에 fallthrough 케이스에 대한 오류를 보고합니다.
+`--noImplicitAny`                              | `boolean` | `false`                        | `any` 타입으로 암시한 표현식과 선언에 오류를 발생시킵니다.
+`--noImplicitReturns`                          | `boolean` | `false`                        | 함수의 모든 코드 경로에 반환값이 없을 때 오류를 보고합니다.
+`--noImplicitThis`                             | `boolean` | `false`                        | `any` 타입으로 암시한 `this` 표현식에 오류를 보고합니다.
+`--noImplicitUseStrict`                        | `boolean` | `false`                        | 모듈 출력에 `"use strict"` 지시자를 내보내지 않습니다.
+`--noLib`                                      | `boolean` | `false`                        | 기본 라이브러리 파일(`lib.d.ts`)은 포함하지 않습니다.
+`--noResolve`                                  | `boolean` | `false`                        | 컴파일된 파일 목록에 트리플-슬래시 참조 또는 모듈 임포트 대상을 추가하지 않습니다.
+`--noStrictGenericChecks`                      | `boolean` | `false`                        | 함수 타입에서 제네릭 시그니처의 엄격한 검사를 비활성화합니다.
+`--noUnusedLocals`                             | `boolean` | `false`                        | 사용하지 않는 지역 변수에 대한 오류를 보고합니다.
+`--noUnusedParameters`                         | `boolean` | `false`                        | 사용하지 않는 매개 변수에 대한 오류를 보고합니다.
+~~`--out`~~                                    | `string`  |                                | 더 이상 사용하지 않습니다. `--outFile`을 대신 사용합니다.
+`--outDir`                                     | `string`  |                                | 출력 구조를 디렉토리로 리다이렉트합니다.
+`--outFile`                                    | `string`  |                                | 출력을 단일 파일로 연결하여 방출합니다. 연결의 순서는 컴파일러에 전달된 파일 목록과 트리플-슬래시 참조 그리고 import와 함께 결정됩니다. 자세한 내용은 [출력 파일 순서 문서](https://github.com/Microsoft/TypeScript/wiki/FAQ#how-do-i-control-file-ordering-in-combined-output---out-)를 참조하세요.
+`paths`<sup>[2]</sup>                          | `Object`  |                                | `baseUrl`을 기준으로 관련된 위치에 모듈 이름의 경로 매핑 목록을 나열합니다. 자세한 내용은 [모듈 해석 문서](./module-resolution.md#path-mapping)를 참조하세요.
+`--preserveConstEnums`                         | `boolean` | `false`                        | 생성된 코드에 const enum 선언을 지우지 않습니다. 자세한 내용은 [const 열거형 문서](https://github.com/Microsoft/TypeScript/blob/master/doc/spec.md#94-constant-enum-declarations)를 참조하세요.
+`--preserveSymlinks`                            | `boolean` | `false`                       | symlinks를 실제 경로로 해석하지 않습니다. symlinked된 파일을 실제 파일처럼 다룹니다.
+`--preserveWatchOutput`                        | `boolean` | `false`                        | 스크린을 지우는 대신에 예전 콘솔 출력을 감시 모드로 남겨둡니다
+`--pretty`                                     | `boolean` | 다른 프로그램으로 파이프하거나 출력을 파일로 리다이렉션하지 않으면 `true` | 에러와 메시지를 색과 컨텍스트를 사용해서 스타일 지정합니다.
+`--project`<br/>`-p`                           | `string`  |                                | 유효한 설정 파일이 지정된 프로젝트를 컴파일하세요.<br/>이 인수는 유효한 JSON 설정 파일의 파일 경로일 수도 있고 `tsconfig.json` 파일이 포함된 디렉토리의 경로일 수도 있습니다.<br/>자세한 내용은 [tsconfig.json](./tsconfig.json.md)를 참조하세요.
+`--reactNamespace`                             | `string`  | `"React"`                      | 더 이상 사용하지 않습니다. `--jsxFactory`를 대신 사용합니다.<br/>`"react"` JSX emit을 대상으로 할 때 `createElement`와 `__spread`에 호출된 객체를 지정합니다.
+`--removeComments`                             | `boolean` | `false`                        | `/*!`로 시작하는 copy-right 헤더 주석을 제외한 모든 주석을 제거합니다.
+`--resolveJsonModule`                          | `boolean` | `false`                        | `.json` 확장자로 import된 모듈을 포함합니다.
+`--rootDir`                                    | `string`  | *(공통 루트 디렉토리는 input files 리스트에서 처리됩니다)*   | 입력 파일의 루트 디렉토리를 지정합니다. `--outDir`로 출력 디렉토리 구조를 제어하기 위해서만 사용합니다.
+`rootDirs`<sup>[2]</sup>                       | `string[]`|                                | 런타임 시 결합된 컨텐츠가 프로젝트의 구조를 나타내는 <i>루트</i> 폴더 목록입니다. 자세한 내용은 [모듈 해석 문서](./module-resolution.md#virtual-directories-with-rootdirs)를 참조하세요.
+`--showConfig`                                 | `boolean` | `false`                        | 다른 입력 옵션 및 구성 파일을 사용하여 빌드를 실제로 실행하는 대신 출력에 마지막 암시적 구성 파일을 표시하십시오.
+`--skipDefaultLibCheck`                        | `boolean` | `false`                        | 더 이상 사용하지 않습니다. `--skipLibCheck`를 대신 사용합니다.<br/>[기본 라이브러리 선언 파일](./triple-slash-directives.md#-reference-no-default-libtrue)의 타입 검사를 건너뜁니다.
+`--skipLibCheck`                               | `boolean` | `false`                        | 모든 선언 파일(`*.d.ts`)의 타입 검사를 건너뜁니다.
+`--sourceMap`                                  | `boolean` | `false`                        | 해당하는 `.map` 파일을 생성합니다.
+`--sourceRoot`                                 | `string`  |                                | 디버거가 소스 위치 대신 TypeScript 파일을 찾아야 하는 위치를 지정합니다. 설계 시점에 소스가 아닌 런타임에 소스가 있는 경우 이 옵션을 사용하세요. 지정한 위치는 소스 파일이 위치할 디버깅 위치를 지정하기 위해 소스 맵에 포함됩니다.
+`--strict`                                     | `boolean` | `false`                        | 모든 엄격한 타입 검사 옵션을 활성화합니다. <br/>`--strict`를 활성화하면 `--noImplicitAny`, `--noImplicitThis`, `--alwaysStrict`, `--strictNullChecks` 및 `--strictFunctionTypes`이 가능합니다.
+`--strictBindCallApply`                        | `boolean` | `false`                        | 함수에서 `bind`, `call` 그리고 `apply` 메서드의 더 엄격한 검사를 활성화합니다.
+`--strictFunctionTypes`                        | `boolean` | `false`                        | 함수 타입에 대한 bivariant 매개변수를 비활성화합니다.
+`--strictPropertyInitialization`               | `boolean` | `false`                        | undefined가 아닌 클래스 프로퍼티가 생성자에서 초기화 되도록 합니다. 이 옵션을 적용하려면 `--strictNullChecks`가 활성화되어야 합니다.
+`--strictNullChecks`                           | `boolean` | `false`                        | 엄격한 null 검사 모드에서는 `null`과 `undefined` 값이 모든 타입의 도메인에 있지 않고 그 자체와 `any`만 할당할 수  있습니다(한 가지 예외사항은 `undefined` 또한 `void`에 할당 가능하다는 것입니다).
+`--suppressExcessPropertyErrors`               | `boolean` | `false`                        | 객체 리터럴에 대한 프로퍼티 초과 검사를 억제합니다.
+`--suppressImplicitAnyIndexErrors`             | `boolean` | `false`                        | 인덱스 시그니처가 없는 객체를 인덱싱하는 경우 `--noImplicitAny` 억제합니다. 오류를 시그니처 자세한 내용은 [#1232 이슈](https://github.com/Microsoft/TypeScript/issues/1232#issuecomment-64510362)를 참조하세요.
+`--target`<br/>`-t`                            | `string`  | `"ES3"`                        | ECMAScript 대상 버전 지정: <br/>► `"ES3"` (기본 값) <br/>► `"ES5"` <br/>► `"ES6"`/`"ES2015"` <br/>► `"ES2016"` <br/>► `"ES2017"` <br/>► `"ES2018"` <br/>► `"ES2019"` <br/>► `"ES2020"` <br/>► `"ESNext"` <br/><br/> 주의사항: `"ESNext"`는 최신 [ES 제안 기능](https://github.com/tc39/proposals)을 대상으로 합니다.
+`--traceResolution`                            | `boolean` | `false`                        | 모듈 해석 로그 메세지를 보고합니다.
+`--tsBuildInfoFile`                            | `string`  | `.tsbuildinfo`                 | 증분 빌드 정보를 저장할 파일을 지정합니다.
+`--types`                                      | `string[]`|                                | 타입 정의가 포함될 이름의 목록. 자세한 내용은 [@types, --typeRoots 및 --types](./tsconfig.json.md#types-typeroots-and-types)를 참조하세요.
+`--typeRoots`                                  | `string[]`|                                | 타입 정의가 포함될 폴더의 목록. 자세한 내용은 [@types, --typeRoots 및 --types](./tsconfig.json.md#types-typeroots-and-types)를 참조하세요.
+`--version`<br/>`-v`                           |           |                                | 컴파일러의 버전을 출력합니다.
+`--watch`<br/>`-w`                             |           |                                | 컴파일러를 감시 모드로 실행합니다. 입력 파일을 감시하여 변경 시 다시 컴파일합니다. 감시 파일과 디렉터리의 구현은 환경 변수를 사용하여 구성합니다. 더 자세한 내용은 [감시 구성하기](./configuring-watch.md)를 보세요.
+
+* <sup>[1]</sup> 이 옵션은 실험단계입니다.
+* <sup>[2]</sup> 이 옵션은 `tsconfig.json`에서만 허용되며 커맨드 라인에서는 허용되지 않습니다.
+
+## 관련사항 (Related)
+
+- 각 옵션에 대한 상세한 설명은 [TSConfig 레퍼런스](/tsconfig)에 있습니다.
+- [`tsconfig.json`](/docs/handbook/tsconfig-json.html) 파일에서 컴파일러 옵션 설정하기
+- [MSBuild projects](/docs/handbook/compiler-options-in-msbuild.html) 프로젝트에서 컴파일러 옵션 설정하기
diff --git a/docs/documentation/ko/project-config/Configuring Watch.md b/docs/documentation/ko/project-config/Configuring Watch.md
new file mode 100644
index 00000000..127bf2ec
--- /dev/null
+++ b/docs/documentation/ko/project-config/Configuring Watch.md	
@@ -0,0 +1,69 @@
+---
+title: Configuring Watch
+layout: docs
+permalink: /ko/docs/handbook/configuring-watch.html
+oneline: How to configure the watch mode of TypeScript
+translatable: true
+---
+
+컴파일러가 어떻게 파일과 디렉터리를 감시할지에 대해
+- TypeScript 3.8+: 컴파일러 플래그
+- 그보다 이전 버전: 환경 변수
+를 사용하여 설정합니다.
+
+## 배경 (Background)
+
+컴파일러의 `--watch` 구현은 node에서 제공하는 `fs.watch`와 `fs.watchFile`에 의존하며, 이 두 방법 모두 장단점이 있습니다.
+
+`fs.watch`는 파일 시스템 이벤트를 사용하여 파일/디렉터리의 변경 사항을 알립니다. 하지만 OS에 따라 다르며, 알림은 완전히 믿을 수가 없고, 많은 OS에서 예상대로 동작하지 않습니다. 또한, 생성할 수 있는 watcher의 수에 제한이 있을 수 있으며(예: linux), 파일 수가 많은 프로그램을 사용하면 매우 빠르게 소진할 수 있습니다. 그러나 이 작업은 파일 시스템 이벤트를 사용하기 때문에 CPU cycle에 많이 관여하진 않습니다. 컴파일러는 일반적으로 `fs.watch`를 사용하여 디렉터리를 감시합니다. (예: 설정 파일에 포함된 소스 디렉터리, 모듈 확인을 실패한 디렉터리 ... 등) 변경 사항에 대한 알림에서 누락된 정밀도를 처리할 수 있습니다. 그러나 재귀 감시 기능은 Windows와 OSX에서만 지원됩니다. 즉, 다른 OS들은 재귀적 특성을 대체할 무언가가 필요합니다.
+
+`fs.watchFile`은 폴링을 사용하므로 CPU 주기를 포함합니다. 하지만 이는 파일/디렉터리 상태에 대한 업데이트를 받을 수 있는 가장 신뢰할 수 있는 메커니즘입니다. 컴파일러는 일반적으로 `fs.watchFile`을 사용하여 소스 파일, 구성 파일 및 누락된 파일(누락된 파일 참조)을 감시하는데 이는 CPU 사용량이 프로그램의 파일 수에 따라 달라진다는 것을 의미합니다.
+
+## Configuring file watching using a `tsconfig.json`
+
+```json tsconfig
+{
+  // Some typical compiler options
+  "compilerOptions": {
+    "target": "es2020",
+    "moduleResolution": "node"
+    // ...
+  },
+
+  // NEW: Options for file/directory watching
+  "watchOptions": {
+    // Use native file system events for files and directories
+    "watchFile": "useFsEvents",
+    "watchDirectory": "useFsEvents",
+
+    // Poll files for updates more frequently
+    // when they're updated a lot.
+    "fallbackPolling": "dynamicPriority"
+  }
+}
+```
+
+You can read more about this in [the release notes](/docs/handbook/release-notes/typescript-3-8.html#better-directory-watching-on-linux-and-watchoptions).
+
+## 환경 변수 `TSC_WATCHFILE`을 사용하여 파일 감시 설정 (Configuring file watching using environment variable `TSC_WATCHFILE`)
+
+<!-- prettier-ignore -->
+옵션                                            | 설명
+-----------------------------------------------|----------------------------------------------------------------------
+`PriorityPollingInterval`                      | `fs.watchFile`을 사용하지만 소스 파일, 설정 파일 및 누락된 파일에 대해 다른 폴링 주기(polling intervals)를 사용합니다.
+`DynamicPriorityPolling`                       | 자주 수정되는 파일을 자주 폴링하고 변경되지 않은 파일을 덜 자주 폴링 하는 동적 큐를 사용합니다.
+`UseFsEvents`                                  | 파일 시스템 이벤트를 사용하는 `fs.watch`를 사용하여 파일 변경/생성/삭제에 대한 알림을 받습니다. (`fs.watch`는 OS마다 다르게 작동할 수 있습니다.) 예를 들어. 리눅스는 watcher 수에 제한이 있으며 `fs.watch`를 사용하여 watcher를 만들지 못하면, `fs.watchFile`를 대신 사용하여 watcher를 만들게 됩니다.
+`UseFsEventsWithFallbackDynamicPolling`        | 이 옵션은 `fs.watch`를 사용하여 감시자를 만들지 못한 경우 폴링이 동적 큐를 통해 수행된다는 것을 제외하고는 `UseFsEvents` 옵션과 비슷합니다.(동적 큐에 대한 것은 `DynamicPriorityPolling`옵션에서 설명하였습니다.).
+`UseFsEventsOnParentDirectory`                 | 이 옵션은 `fs.watch`(파일 시스템 이벤트 사용하는)로 파일의 상위 디렉터리를 감시합니다. 다만, CPU 사용량이 늘어나고 정확도는 떨어질 수 있습니다.
+default (no value specified)                   | 환경 변수`TSC_NONPOLLING_WATCHER`가 true로 설정되면 파일의 상위 디렉터리를 감시합니다. (`UseFsEventsOnParentDirectory`와 동일).false 일 때는 `fs.watchFile`을 사용하여 `250ms` 시간 제한과 함께 모든 파일들을 감시합니다.
+
+## 환경 변수`TSC_WATCHDIRECTORY`를 사용하여 디렉터리 감시 설정 (Configuring directory watching using environment variable `TSC_WATCHDIRECTORY`)
+
+기본적으로 node에서 디렉터리의 재귀적인 감시를 지원하지 않는 플랫폼에서, 디렉터리 감시 기능은 `TSC_WATCHDIRECTORY`에서 선택한 다양한 옵션을 사용하여 하위 디렉터리에 대한 디렉터리 watcher를 재귀적으로 생성함으로써 지원됩니다. 기본적으로 재귀 디렉터리 감시(예: windows)를 지원하는 플랫폼에서는 이 환경 변수의 값이 무시됩니다.
+
+<!-- prettier-ignore -->
+옵션                                            | 설명
+-----------------------------------------------|----------------------------------------------------------------------
+`RecursiveDirectoryUsingFsWatchFile`           | `fs.watchFile`을 사용하여 폴링 감시(CPU cycles 사용)인 디렉터리 및 하위 디렉터리를 감시합니다.
+`RecursiveDirectoryUsingDynamicPriorityPolling`| 동적 폴링 큐를 사용하여 디렉터리 및 하위 디렉터리에 대한 변경사항을 폴링 합니다.
+default (no value specified)                   | `fs.watch`를 사용하여 디렉터리 및 하위 디렉터리를 감시합니다.
diff --git a/docs/documentation/ko/project-config/Integrating with Build Tools.md b/docs/documentation/ko/project-config/Integrating with Build Tools.md
new file mode 100644
index 00000000..842c7286
--- /dev/null
+++ b/docs/documentation/ko/project-config/Integrating with Build Tools.md	
@@ -0,0 +1,283 @@
+---
+title: Integrating with Build Tools
+layout: docs
+permalink: /ko/docs/handbook/integrating-with-build-tools.html
+oneline: How to use TypeScript with other build tools
+---
+
+빌드 도구들
+
+* [Babel](#babel)
+* [Browserify](#browserify)
+* [Duo](#duo)
+* [Grunt](#grunt)
+* [Gulp](#gulp)
+* [Jspm](#jspm)
+* [Webpack](#webpack)
+* [MSBuild](#msbuild)
+* [NuGet](#nuget)
+
+# Babel
+
+### 설치
+
+```sh
+npm install @babel/cli @babel/core @babel/preset-typescript --save-dev
+```
+
+### .babelrc
+
+```js
+{
+  "presets": ["@babel/preset-typescript"]
+}
+```
+
+### 커맨드 라인 인터페이스 사용
+
+```sh
+./node_modules/.bin/babel --out-file bundle.js src/index.ts
+```
+
+
+### package.json
+
+```js
+{
+  "scripts": {
+    "build": "babel --out-file bundle.js main.ts"
+  },
+}
+```
+
+### 커맨드 라인 인터페이스 사용
+
+```sh
+npm run build
+```
+
+
+# Browserify
+
+### 설치
+
+```sh
+npm install tsify
+```
+
+### 커맨드 라인 인터페이스 사용
+
+```sh
+browserify main.ts -p [ tsify --noImplicitAny ] > bundle.js
+```
+
+### API 사용
+
+```js
+var browserify = require("browserify");
+var tsify = require("tsify");
+
+browserify()
+    .add("main.ts")
+    .plugin("tsify", { noImplicitAny: true })
+    .bundle()
+    .pipe(process.stdout);
+```
+
+자세한 내용: [smrq/tsify](https://github.com/smrq/tsify)
+
+# Duo
+
+### 설치
+
+```sh
+npm install duo-typescript
+```
+
+### 커맨드 라인 인터페이스 사용
+
+```sh
+duo --use duo-typescript entry.ts
+```
+
+### API 사용
+
+```js
+var Duo = require("duo");
+var fs = require("fs")
+var path = require("path")
+var typescript = require("duo-typescript");
+
+var out = path.join(__dirname, "output.js")
+
+Duo(__dirname)
+    .entry("entry.ts")
+    .use(typescript())
+    .run(function (err, results) {
+        if (err) throw err;
+        // 컴파일된 결과를 출력 파일에 작성합니다
+        fs.writeFileSync(out, results.code);
+    });
+```
+
+자세한 내용: [frankwallis/duo-typescript](https://github.com/frankwallis/duo-typescript)
+
+# Grunt
+
+### 설치
+
+```sh
+npm install grunt-ts
+```
+
+### 기본 Gruntfile.js
+
+````js
+module.exports = function(grunt) {
+    grunt.initConfig({
+        ts: {
+            default : {
+                src: ["**/*.ts", "!node_modules/**/*.ts"]
+            }
+        }
+    });
+    grunt.loadNpmTasks("grunt-ts");
+    grunt.registerTask("default", ["ts"]);
+};
+````
+
+자세한 내용: [TypeStrong/grunt-ts](https://github.com/TypeStrong/grunt-ts)
+
+# Gulp
+
+### 설치
+
+```sh
+npm install gulp-typescript
+```
+
+### 기본 gulpfile.js
+
+```js
+var gulp = require("gulp");
+var ts = require("gulp-typescript");
+
+gulp.task("default", function () {
+    var tsResult = gulp.src("src/*.ts")
+        .pipe(ts({
+              noImplicitAny: true,
+              out: "output.js"
+        }));
+    return tsResult.js.pipe(gulp.dest("built/local"));
+});
+```
+
+자세한 내용: [ivogabe/gulp-typescript](https://github.com/ivogabe/gulp-typescript)
+
+# Jspm
+
+### 설치
+
+```sh
+npm install -g jspm@beta
+```
+
+_주의사항: 현재 jspm의 TypeScript 지원은 0.16beta 입니다._
+
+자세한 내용: [TypeScriptSamples/jspm](https://github.com/Microsoft/TypeScriptSamples/tree/master/jspm)
+
+# Webpack
+
+### 설치
+
+```sh
+npm install ts-loader --save-dev
+```
+
+### Webpack 2 사용 시 기본 webpack.config.js
+
+```js
+module.exports = {
+    entry: "./src/index.tsx",
+    output: {
+        path: '/',
+        filename: "bundle.js"
+    },
+    resolve: {
+        extensions: [".tsx", ".ts", ".js", ".json"]
+    },
+    module: {
+        rules: [
+            // '.ts' 또는 '.tsx' 확장자를 가진 모든 파일은 'ts-loader'에 의해 처리됩니다.
+            { test: /\.tsx?$/, use: ["ts-loader"], exclude: /node_modules/ }
+        ]
+    }
+}
+```
+
+### Webpack 1 사용 시 기본 webpack.config.js
+
+```js
+module.exports = {
+    entry: "./src/index.tsx",
+    output: {
+        filename: "bundle.js"
+    },
+    resolve: {
+        // '.ts'와 '.tsx'를 해석 가능한 확장자로 추가합니다.
+        extensions: ["", ".webpack.js", ".web.js", ".ts", ".tsx", ".js"]
+    },
+    module: {
+        loaders: [
+            // '.ts' 또는 '.tsx' 확장자를 가진 모든 파일은 'ts-loader'에 의해 처리됩니다.
+            { test: /\.tsx?$/, loader: "ts-loader" }
+        ]
+    }
+}
+```
+
+[ts-loader에 대한 자세한 내용](https://www.npmjs.com/package/ts-loader)은 여기를 참조하세요.
+
+대안:
+
+* [awesome-typescript-loader](https://www.npmjs.com/package/awesome-typescript-loader)
+
+# MSBuild
+
+로컬에 설치된 `Microsoft.TypeScript.Default.props` (맨 위)와 `Microsoft.TypeScript.targets` (맨 아래) 파일을 포함하도록 프로젝트 파일을 업데이트하세요:
+
+```xml
+<?xml version="1.0" encoding="utf-8"?>
+<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
+  <!-- 하단에 default props 포함 -->
+  <Import
+      Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.Default.props"
+      Condition="Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.Default.props')" />
+
+  <!-- TypeScript 환경 설정 -->
+  <PropertyGroup Condition="'$(Configuration)' == 'Debug'">
+    <TypeScriptRemoveComments>false</TypeScriptRemoveComments>
+    <TypeScriptSourceMap>true</TypeScriptSourceMap>
+  </PropertyGroup>
+  <PropertyGroup Condition="'$(Configuration)' == 'Release'">
+    <TypeScriptRemoveComments>true</TypeScriptRemoveComments>
+    <TypeScriptSourceMap>false</TypeScriptSourceMap>
+  </PropertyGroup>
+
+  <!-- 하단에 default targets 포함 -->
+  <Import
+      Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets"
+      Condition="Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets')" />
+</Project>
+```
+
+MSBuild 컴파일러 옵션 정의에 대한 자세한 내용: [MSBuild 프로젝트의 컴파일러 옵션 설정](./compiler-options-in-msbuild.md)
+
+# NuGet
+
+* 우-클릭 -> Manage NuGet Packages
+* `Microsoft.TypeScript.MSBuild`를 검색하세요
+* `Install` 클릭
+* 설치가 완료되면 다시 빌드 하세요!
+
+자세한 내용은 [패키지 매니저 다이얼로그](http://docs.nuget.org/Consume/Package-Manager-Dialog)와 [NuGet과 nightly builds 사용](https://github.com/Microsoft/TypeScript/wiki/Nightly-drops#using-nuget-with-msbuild)을 참고하세요
diff --git a/docs/documentation/ko/project-config/Project References.md b/docs/documentation/ko/project-config/Project References.md
new file mode 100644
index 00000000..c725ff1d
--- /dev/null
+++ b/docs/documentation/ko/project-config/Project References.md	
@@ -0,0 +1,217 @@
+---
+title: Project References
+layout: docs
+permalink: /ko/docs/handbook/project-references.html
+oneline: How to split up a large TypeScript project
+translatable: true
+---
+
+프로젝트 레퍼런스는 TypeScript 프로그램을 더 작은 조각으로 구성할 수 있는 TypeScript 3.0의 새로운 기능입니다.
+
+이를 통해, 빌드 시간을 크게 개선하고, 컴포넌트 사이의 논리적인 분리를 강제하여 코드를 새롭고 더 나은 방법으로 구성할 수 있습니다.
+
+또한, 빠른 TypeScript 빌드를 위해 프로젝트 레퍼런스와 함께 동작하는 `tsc` 의 새로운 모드인 `--build` 플래그를 도입했습니다.
+
+# 예제 프로젝트 (An Example Project)
+
+꽤 일반적인 프로그램을 보고 프로젝트 레퍼런스가 이 프로그램을 더 잘 구성하는데 어떻게 도움이 될 수 있는지 살펴보겠습니다.
+`converter`와 `units`이라는 두 모듈이 프로젝트 안에 있고, 각 모듈에 대응되는 테스트 파일이 있다고 상상해봅시다:
+
+```shell
+/src/converter.ts
+/src/units.ts
+/test/converter-tests.ts
+/test/units-tests.ts
+/tsconfig.json
+```
+
+테스트 파일은 구현 파일을 import 하고 테스트를 진행합니다:
+
+```ts
+// converter-tests.ts
+import * as converter from "../converter";
+
+assert.areEqual(converter.celsiusToFahrenheit(0), 32);
+```
+
+이전에는, 단일 tsconfig 파일을 사용한 경우 이 구조가 어색하게 동작했습니다:
+
+* 구현 파일을 테스트 파일에 import 하는 것이 가능합니다
+* 아마도 원치 않았겠지만 `src`가 출력 폴더 이름에 나타나지 않고는 `test`와 `src`를 동시에 빌드 하는 것이 불가능합니다
+* 구현 파일 안에 *내용물* 만 바꿔도 새로운 오류를 절대 발생시키지 않지만 테스트 파일에 대한 *타입 검사*를 다시 해야 합니다
+* 테스트 파일만 바꿔도 아무 변화 없지만 구현 파일의 타입 검사를 다시 해야 합니다
+
+여러 개의 tsconfig 파일을 사용하여 이 문제들 중 *몇 가지*는 해결할 수 있지만, 새로운 문제가 발생합니다:
+
+* 내장된 최신 검사가 없기 때문에, 항상 `tsc`를 두 번 실행해야 합니다
+* `tsc`를 두 번 호출하면 시작 시간 오버헤드가 더 많이 발생합니다
+* `tsc-w`는 한 번에 여러 config 파일을 실행할 수 없습니다
+
+프로젝트 레퍼런스는 이 모든 문제를 해결할 수 있습니다.
+
+# 프로젝트 레퍼런스는 무엇인가? (What is a Project Reference?)
+
+`tsconfig.json` 파일은 새로운 최상위-레벨 프로퍼티 `reference`를 가집니다. 이는 참조할 프로젝트를 지정하는 객체의 배열입니다:
+
+```js
+{
+    "compilerOptions": {
+        // The usual
+    },
+    "references": [
+        { "path": "../src" }
+    ]
+}
+```
+
+각 참조의 `path` 프로퍼티는 `tsconfig.json` 파일을 가지는 디렉터리를 가리키거나, config 파일 자체(어떤 이름도 가질 수 있음)를 가리킵니다.
+
+프로젝트를 참조하면, 새로운 일이 일어납니다:
+
+* 참조된 프로젝트에서 모듈을 import 하면 모듈의 *출력* 선언 파일을 대신 로드합니다 (`.d.ts`)
+* 만약 참조된 프로젝트가 `outFile`를 생성하면, 출력 파일 `.d.ts` 파일의 선언은 이 프로젝트 안에서 노출됩니다
+* 빌드 모드(아래 참조)는 필요하다면 자동으로 참조된 프로젝트를 빌드 합니다
+
+여러 프로젝트로 분리하는 것은, 타입 검사와 컴파일 속도를 크게 향상시키고, 에디터를 사용할 때 메모리 사용량을 줄이며, 프로그램의 논리적 그룹화를 향상시킵니다.
+
+# `composite`
+
+참조 된 프로젝트는 반드시 새로운 `composite` 설정이 활성화되어야 합니다.
+이 설정은 TypeScript가 참조된 프로젝트의 출력을 어디서 찾아야 할지 빠르게 결정하도록 하기 위해 필요합니다.
+`composite` 플래그를 활성화하면 몇 가지가 변합니다:
+
+* 만약 `rootDir` 설정이 명시적으로 지정되지 않으면, 기본 값은 `tsconfig` 파일을 가진 디렉터리입니다
+* 모든 구현 파일은 반드시 `include` 패턴에 맞거나 `files` 배열 안에 있어야 합니다. 만약 이 제약조건을 위반하면, `tsc`는 어떤 파일이 지정되지 않았는지 알려줍니다
+* `declaration`은 반드시 켜져 있어야 합니다
+
+# `declarationMap`s
+
+[선언 소스 맵](https://github.com/Microsoft/TypeScript/issues/14479)에 대한 지원도 추가했습니다.
+만약 `--declarationMap`을 활성화하면, "정의로 이동"과 이름 변경과 같은 에디터 기능을 사용하여 지원하는 에디터에서 투명하게 탐색하고 프로젝트 경계를 넘어 코드를 수정할 수 있습니다.
+
+# `prepend`와 `outFile` (`prepend` with `outFile`)
+
+레퍼런스에서 `prepend` 옵션을 사용하여 의존성의 출력을 덧붙이는 것을 활성화할 수 있습니다:
+
+```js
+   "references": [
+       { "path": "../utils", "prepend": true }
+   ]
+```
+
+프로젝트를 덧붙이는 것은 프로젝트의 출력을 현재 프로젝트의 출력 위에 포함시킵니다.
+이는 `.js` 파일과 `.d.ts` 파일에 모두 동작하고, 소스맵 파일 역시 올바르게 방출됩니다.
+
+`tsc`는 이 작업을 위해 디스크에 있는 기존 파일만 사용합니다, 그래서 어떤 프로젝트의 출력이 결과 파일에 한 번 이상 나타날 수 있기 때문에, 올바른 출력 파일이 생성될 수 없는 프로젝트를 생성하는 것이 가능합니다.
+예를 들어:
+
+```txt
+   A
+  ^ ^
+ /   \
+B     C
+ ^   ^
+  \ /
+   D
+```
+
+이 상황에서 각 레퍼런스에 덧붙이지 않는 것이 중요한데, 왜냐하면 `D`의 출력에 `A`의 두 가지 복사본이 나오기 때문입니다 - 이는 예상치 못한 결과를 초래할 수 있습니다.
+
+# 프로젝트 레퍼런스에 대한 주의사항 (Caveats for Project References)
+
+프로젝트 레퍼런스는 반드시 주의해야 할 몇 가지 트레이드오프가 있습니다.
+
+왜냐하면 의존성 있는 프로젝트는 의존성으로부터 빌드 된 `.d.ts` 파일을 사용하기 때문에, 에디터에서 잘못된 오류를 보지 않고 프로젝트를 탐색할 수 있기 전에 특정 빌드 출력을 검사하거나 *혹은* 클론 후 프로젝트를 빌드 해야 합니다.
+이를 개선할 수 있는 .d.ts 생성 과정을 작업하고 있습니다만, 지금은 클론 이후에 빌드 하는 것을 개발자분들에게 추천드립니다.
+
+추가적으로, 기존 빌드 작업 흐름과의 호환성을 유지하기 위해, `tsc`는 `--build` 스위치를 호출하지 않는 한 자동으로 의존성 빌드를 하지 *않습니다*.
+`--build`에 대해 배워봅시다.
+
+# TypeScript를 위한 빌드 모드 (Build Mode for TypeScript)
+
+오래 기다린 기능은 TypeScirpt 프로젝트를 위한 똑똑한 증분 빌드입니다.
+3.0에서 `tsc`에서 `--build` 플래그를 사용할 수 있게 되었습니다.
+이것은 단순한 컴파일러보다 빌드 관리자처럼 동작하는 `tsc`의 새로운 진입점입니다.
+
+`tsc --build` (약식은 `tsc -b`)를 실행하면 다음의 작업을 합니다:
+
+* 참조된 모든 프로젝트를 찾습니다
+* 최신 상태인지 감지합니다
+* 올바른 순서로 최신 상태가 아닌 프로젝트를 빌드 합니다
+
+`tsc -b`에 여러 config 파일 경로를 제공할 수 있습니다 (예를 들어. `tsc -b src test`).
+`tsc -p`처럼, 만약 config 파일 이름이 `tsconfig.json`이라면 이름을 지정하지 않아도 됩니다.
+
+## `tsc -b` 명령줄 (`tsc -b` Commandline)
+
+config 파일을 원하는 만큼 지정할 수 있습니다:
+
+```shell
+ > tsc -b                            # 현재 디렉터리에 있는 tsconfig.json 사용
+ > tsc -b src                        # src/tsconfig.json 사용
+ > tsc -b foo/prd.tsconfig.json bar  # foo/prd.tsconfig.json 와 bar/tsconfig.json 사용
+```
+
+명령줄에 전달한 파일의 순서에 대해서는 걱정하지 마세요 - 필요하면 `tsc`가 재배열하기 때문에 의존성이 언제나 먼저 빌드 됩니다.
+
+`tsc -b`에 지정할 수 있는 몇 가지 플래그들이 더 있습니다:
+
+* `--verbose`: 어떻게 진행되고 있는지 자세한 로그를 출력해 줍니다 (다른 플래그와 결합할 수 있습니다)
+* `--dry`: 실제로 빌드 하지 않지만 어떻게 될지 보여줍니다
+* `--clean`: 지정된 프로젝트의 출력을 제거합니다 (`--dry`와 결합할 수 있습니다)
+* `--force`: 모든 프로젝트가 최신이 아닌 것처럼 동작합니다
+* `--watch`: 감시 모드 (`--verbose`를 제외한 다른 플래그와는 결합할 수 없습니다)
+
+# 주의사항 (Caveats)
+
+일반적으로, `tsc`는 `noEmitOnError`가 활성화되어있지 않으면, 구문 또는 타입 오류가 있을 때 출력 (`.js`와 `.d.ts`)을 생성합니다.
+이것을 증분 빌드 시스템에서 하는 것은 매우 안 좋습니다 - 만약 최신 상태가 아닌 의존성 중 하나가 새로운 오류가 있으면, 다음 빌드가 현재 최신 상태인 프로젝트를 빌드 하는 것을 건너뛸 것이기 때문에, *한번* 만 볼 수 있습니다.
+이 이유로, `tsc -b`는 `noEmitOnError`가 모든 프로젝트에서 활성화된 것처럼 효과적으로 동작합니다.
+
+아무 빌드 출력 (`.js`, `.d.ts`, `.d.ts.map`, 등)을 검사하는 경우, 소스 제어 도구가 로컬 사본과 원격 사본 사이의 타임스탬프를 보존하는지에 따라 특정 소스 제어 연산 후에 `--force` 빌드를 실행해야 할 수도 있습니다.
+
+# MSBuild
+
+만약 msbuild 프로젝트가 있으면, 다음을 추가하여 빌드 모드를 proj 파일에
+
+```xml
+    <TypeScriptBuildMode>true</TypeScriptBuildMode>
+```
+
+활성화할 수 있습니다. 이는 제거뿐만 아니라 자동 증분 빌드를 활성화합니다.
+
+`tsconfig.json` / `-p`와 마찬가지로, 기존 TypeScript 프로젝트 프로퍼티는 고려되지 않음에 유의하십시오 - 모든 설정은 tsconfig 파일을 사용하여 관리해야 합니다.
+
+일부 팀들은 tsconfig 파일들이 함께 병행하여 관리되는 프로젝트와 같은 *암시적* 그래프 순서를 가지며 msbuild 기반의 작업 흐름을 설정했습니다.
+만약 해결책이 이와 같다면, 프로젝트 레퍼런스와 함께 `msbuild`를 `tsc -p`와 계속 사용할 수 있습니다; 이들은 완전히 상호 운용 가능합니다.
+
+# 안내 (Guidance)
+
+## 전체 구조 (Overall Structure)
+
+더 많은 `tsconfig.json` 파일과 함께, 공통의 컴파일러 옵션들을 중앙 통제하기 위해 [구성 파일 상속](https://www.typescriptlang.org/docs/handbook/tsconfig-json.html)을 사용하고 싶으실 겁니다.
+이 방법으로 여러 파일을 수정하지 않고 한 파일에서 설정을 변경할 수 있습니다.
+
+또 다른 좋은 방법은 단순히 모든 리프-노드 프로젝트에 `references`를 가지고 `files`를 빈 배열로 설정하는 "솔루션" `tsconfig.json` 파일을 갖는 것입니다 (그렇지 않으면 솔루션 파일 때문에 파일이 두 번 컴파일됩니다). 3.0부터 적어도 하나의 `reference`가 `tsconfig.json`에 있으면, 빈 `files` 배열을 갖는 것은 더 이상 오류가 아님에 유의하세요.
+
+이는 간단한 진입점을 제공합니다; 예를 들어, TypeScript 저장소에서 `src/tsconfig.json` 안에 모든 하위 프로젝트를 나열하기 때문에 단순히 `tsc -b src` 실행하여 모든 엔드포인트를 빌드 합니다.
+
+이 패턴들은 TypeScript 저장소에서 볼 수 있습니다 - 주 예제로 `src/tsconfig_base.json`, `src/tsconfig.json`, 그리고 `src/tsc/tsconfig.json`를 보세요.
+
+## 상대 모듈 구조화하기 (Structuring for relative modules)
+
+일반적으로, 상대 모듈을 사용하여 저장소를 전환하는 데에는 별 다른 것이 필요 없습니다.
+간단하게 부모 폴더의 `tsconfig.json` 파일을 각 하위 디렉터리 안에 위치시키고, 프로그램의 의도된 계층과 일치하도록 `reference`를 이 config 파일에 추가하십시오.
+`outDir`을 출력 폴더의 명시적인 하위 폴더로 설정하거나, `rootDir`을 모든 프로젝트 폴더의 공통 루트로 설정해야 합니다.
+
+## outFiles 구조화하기 (Structuring for outFiles)
+
+`outFile`을 사용한 컴파일의 레이아웃은 상대 경로가 크게 중요하지 않기 때문에 더 유연합니다.
+기억해야 할 한 가지는 "마지막" 프로젝트 전까지는 `prepend`를 사용하고 싶지 않다는 것입니다 - 이는 빌드 시간을 개선하고 주어진 빌드에 필요한 I/O 숫자를 줄여줄 것입니다.
+TypeScript 저장소 자체는 여기서 좋은 레퍼런스입니다 - 몇 가지 "라이브러리" 프로젝트와 "엔드포인트" 프로젝트가 있습니다; "엔드포인트" 프로젝트는 가능한 작게 유지되고 있고 필요한 라이브러리만 pull 합니다.
+
+<!--
+## Structuring for monorepos
+
+TODO: Experiment more and figure this out. Rush and Lerna seem to have different models that imply different things on our end
+-->
diff --git a/docs/documentation/ko/project-config/tsconfig.json.md b/docs/documentation/ko/project-config/tsconfig.json.md
new file mode 100644
index 00000000..b6f73588
--- /dev/null
+++ b/docs/documentation/ko/project-config/tsconfig.json.md
@@ -0,0 +1,115 @@
+---
+title: What is a tsconfig.json
+layout: docs
+permalink: /ko/docs/handbook/tsconfig-json.html
+oneline: Learn about how a TSConfig works
+translatable: true
+---
+
+## 개요 (Overview)
+
+디렉토리에 `tsconfig.json` 파일이 있다면 해당 디렉토리가 TypeScript 프로젝트의 루트가 됩니다.  
+`tsconfig.json` 파일은 프로젝트를 컴파일하는 데 필요한 루트 파일과 컴파일러 옵션을 지정합니다.
+
+JavaScript 프로젝트는 `jsconfig.json` 파일을 대신 사용할 수 있습니다. 이 파일은 `tsconfig.json` 파일과 거의 동일하게 동작하지만, 몇몇 JavaScript 관련 컴파일러 플래그가 기본으로 활성화되어 있습니다.
+
+프로젝트는 다음 방법들로 컴파일됩니다:
+
+## `tsconfig.json` 또는 `jsconfig.json` 사용하기 (Using `tsconfig.json` or `jsconfig.json`)
+
+* 입력 파일 없이 `tsc`를 호출하면 컴파일러는 현재 디렉토리에서부터 시작하여 상위 디렉토리 체인으로 `tsconfig.json` 파일을 검색합니다.
+* 입력 파일이 없이 `tsc`와 `tsconfig.json` 파일이 포함된 디렉토리 경로 또는 설정이 포함된 유효한 경로의 `.json` 파일 경로를 지정하는  `--project` (또는 `-p`) 커맨드 라인 옵션을 사용할 수 있습니다.
+
+커맨드 라인에 입력 파일을 지정하면 `tsconfig.json` 파일이 무시됩니다.
+
+## 예제 (Examples)
+
+`tsconfig.json` 예제 파일들:
+
+* `"files"` 속성 사용하기
+
+  ```json tsconfig
+  {
+    "compilerOptions": {
+      "module": "commonjs",
+      "noImplicitAny": true,
+      "removeComments": true,
+      "preserveConstEnums": true,
+      "sourceMap": true
+    },
+    "files": [
+      "core.ts",
+      "sys.ts",
+      "types.ts",
+      "scanner.ts",
+      "parser.ts",
+      "utilities.ts",
+      "binder.ts",
+      "checker.ts",
+      "emitter.ts",
+      "program.ts",
+      "commandLineParser.ts",
+      "tsc.ts",
+      "diagnosticInformationMap.generated.ts"
+    ]
+  }
+  ```
+
+* `"include"` 와 `"exclude"` 속성 사용하기
+
+  ```json  tsconfig
+  {
+    "compilerOptions": {
+      "module": "system",
+      "noImplicitAny": true,
+      "removeComments": true,
+      "preserveConstEnums": true,
+      "outFile": "../../built/local/tsc.js",
+      "sourceMap": true
+    },
+    "include": ["src/**/*"],
+    "exclude": ["node_modules", "**/*.spec.ts"]
+  }
+  ```
+
+## TSConfig Bases
+
+Depending on the JavaScript runtime environment which you intend to run your code in, there may be a base configuration which you can use at [github.com/tsconfig/bases](https://github.com/tsconfig/bases/).
+These are `tsconfig.json` files which your project extends from which simplifies your `tsconfig.json` by handling the runtime support.
+
+For example, if you were writing a project which uses Node.js version 12 and above, then you could use the npm module [`@tsconfig/node12`](https://www.npmjs.com/package/@tsconfig/node12):
+
+```json tsconfig
+{
+  "extends": "@tsconfig/node12/tsconfig.json",
+
+  "compilerOptions": {
+    "preserveConstEnums": true
+  },
+
+  "include": ["src/**/*"],
+  "exclude": ["node_modules", "**/*.spec.ts"]
+}
+```
+
+This lets your `tsconfig.json` focus on the unique choices for your project, and not all of the runtime mechanics. There are a few tsconfig bases already, and we're hoping the community can add more for different environments.
+
+- [Recommended](https://www.npmjs.com/package/@tsconfig/recommended)
+- [Node 10](https://www.npmjs.com/package/@tsconfig/node10)
+- [Node 12](https://www.npmjs.com/package/@tsconfig/node12)
+- [Node 14](https://www.npmjs.com/package/@tsconfig/node14)
+- [Deno](https://www.npmjs.com/package/@tsconfig/deno)
+- [React Native](https://www.npmjs.com/package/@tsconfig/react-native)
+- [Svelte](https://www.npmjs.com/package/@tsconfig/svelte)
+
+## 상세 설명 (Details)
+
+`"compilerOptions"` 속성은 생략될 수 있으며 생략하면 컴파일러의 기본 값이 사용됩니다. 지원되는 전체 목록은 [컴파일러 옵션](/docs/handbook/compiler-options.html)를 참고하세요.
+
+## TSConfig 레퍼런스
+
+TSConfig 레퍼런스를 보려면 [여기](/tsconfig)로 이동하세요.
+
+## 스키마 (Schema)
+
+`tsconfig.json` 스키마는 [http://json.schemastore.org/tsconfig](http://json.schemastore.org/tsconfig)에서 찾을 수 있습니다.
diff --git a/docs/documentation/ko/release-notes/TypeScript 3.8.md b/docs/documentation/ko/release-notes/TypeScript 3.8.md
new file mode 100644
index 00000000..6855cee2
--- /dev/null
+++ b/docs/documentation/ko/release-notes/TypeScript 3.8.md	
@@ -0,0 +1,461 @@
+---
+title: TypeScript 3.8
+layout: docs
+permalink: /ko/docs/handbook/release-notes/typescript-3-8.html
+oneline: TypeScript 3.8 Release Notes
+---
+
+* [타입-전용 Imports 와 Exports](#type-only-imports-exports)
+* [ECMAScript 비공개 필드](#ecmascript-private-fields)
+* [`export * as ns` 구문](#export-star-as-namespace-syntax)
+* [최상위-레벨 `await`](#top-level-await)
+* [JSDoc 프로퍼티 지정자](#jsdoc-modifiers)
+* [리눅스에서 더 나은 디렉터리 감시와 `watchOptions`](#better-directory-watching)
+* ["빠르고 느슨한" 증분 검사](#assume-direct-dependencies)
+
+## <span id="type-only-imports-exports" /> 타입-전용 Imports 와 Exports (Type-Only Imports and Exports)
+
+이 기능은 대부분의 사용자에겐 생각할 필요가 없을 수도 있지만; `--isolatedModules`, TypeScript의 `transpileModule` API, 또는 Babel에서 문제가 발생하면 이 기능과 관련이 있을 수 있습니다.
+
+TypeScript 3.8은 타입-전용 imports, exports를 위한 새로운 구문이 추가되었습니다.
+
+```ts
+import type { SomeThing } from "./some-module.js";
+
+export type { SomeThing };
+```
+
+`import type`은 타입 표기와 선언에 사용될 선언만 import 합니다.
+이는 *항상* 완전히 제거되므로, 런타임에 남아있는 것은 없습니다.
+마찬가지로, `export type`은 타입 문맥에 사용할 export만 제공하며, 이 또한 TypeScript의 출력물에서 제거됩니다.
+
+클래스는 런타임에 값을 가지고 있고 디자인-타임에 타입이 있으며 사용은 상황에-따라 다르다는 것을 유의해야 합니다.
+클래스를 import 하기 위해 `import type`을 사용하면, 확장 같은 것은 할 수 없습니다.
+
+```ts
+import type { Component } from "react";
+
+interface ButtonProps {
+    // ...
+}
+
+class Button extends Component<ButtonProps> {
+    //               ~~~~~~~~~
+    // error! 'Component' only refers to a type, but is being used as a value here.
+
+    // ...
+}
+```
+
+이전에 Flow를 사용해본 적이 있다면, 이 구문은 상당히 유사합니다.
+한 가지 차이점은 코드가 모호해 보이지 않도록 몇 가지 제한을 두었다는 것입니다.
+
+```ts
+// 'Foo'만 타입인가? 혹은 모든 import 선언이 타입인가?
+// 이는 명확하지 않기 때문에 오류로 처리합니다.
+
+import type Foo, { Bar, Baz } from "some-module";
+//     ~~~~~~~~~~~~~~~~~~~~~~
+// error! A type-only import can specify a default import or named bindings, but not both.
+```
+
+`import type`과 함께, TypeScript 3.8은 런타임 시 사용되지 않는 import에서 발생하는 작업을 제어하기 위해 새로운 컴파일러 플래그를 추가합니다: `importsNotUsedAsValues`.
+이 플래그는 3 가지 다른 값을 가집니다:
+
+* `remove`: 이는 imports를 제거하는 현재 동작이며, 계속 기본값으로 작동할 것이며, 기존 동작을 바꾸는 변화가 아닙니다.
+* `preserve`: 이는 사용되지 않는 값들을 모두 *보존*합니다. 이로 인해 imports/side-effects가 보존될 수 있습니다.
+* `error`: 이는 모든 (`preserve` option 처럼) 모든 imports를 보존하지만, import 값이 타입으로만 사용될 경우 오류를 발생시킵니다. 이는 실수로 값을 import하지 않지만 사이드 이팩트 import를 명시적으로 만들고 싶을 때 유용합니다.
+
+이 기능에 대한 더 자세한 정보는, `import type`선언이 사용될수 있는 범위를 확대하는 [pull request](https://github.com/microsoft/TypeScript/pull/35200), 와 [관련된 변경 사항](https://github.com/microsoft/TypeScript/pull/36092/)에서 찾을 수 있습니다.
+
+## <span id="ecmascript-private-fields" /> ECMAScript 비공개 필드 (ECMAScript Private Fields)
+
+TypeScript 3.8 은 ECMAScript의 [stage-3 클래스 필드 제안](https://github.com/tc39/proposal-class-fields/)의 비공개 필드를 지원합니다.
+
+```ts
+class Person {
+    #name: string
+
+    constructor(name: string) {
+        this.#name = name;
+    }
+
+    greet() {
+        console.log(`Hello, my name is ${this.#name}!`);
+    }
+}
+
+let jeremy = new Person("Jeremy Bearimy");
+
+jeremy.#name
+//     ~~~~~
+// 프로퍼티 '#name'은 'Person' 클래스 외부에서 접근할 수 없습니다.
+// 이는 비공개 식별자를 가지기 때문입니다.
+```
+
+일반적인 프로퍼티들(`private` 지정자로 선언한 것도)과 달리, 비공개 필드는 몇 가지 명심해야 할 규칙이 있습니다.
+그중 몇몇은:
+
+* 비공개 필드는 `#` 문자로 시작합니다. 때때로 이를 *비공개 이름(private names)* 이라고 부릅니다.
+* 모든 비공개 필드 이름은 이를 포함한 클래스 범위에서 유일합니다.
+* `public` 또는 `private` 같은 TypeScript 접근 지정자는 비공개 필드로 사용될 수 없습니다.  
+* JS 사용자로부터도 비공개 필드는 이를 포함한 클래스 밖에서 접근하거나 탐지할 수 없습니다! 때때로 이를 *강한 비공개(hard privacy)* 라고 부릅니다.
+
+"강한" 비공개와 별도로, 비공개 필드의 또 다른 장점은 유일하다는 것입니다.
+예를 들어, 일반적인 프로퍼티 선언은 하위클래스에서 덮어쓰기 쉽습니다.
+
+```ts
+class C {
+    foo = 10;
+
+    cHelper() {
+        return this.foo;
+    }
+}
+
+class D extends C {
+    foo = 20;
+
+    dHelper() {
+        return this.foo;
+    }
+}
+
+let instance = new D();
+// 'this.foo' 는 각 인스턴스마다 같은 프로퍼티를 참조합니다.
+console.log(instance.cHelper()); // '20' 출력
+console.log(instance.dHelper()); // '20' 출력
+```
+
+비공개 필드에서는, 포함하고 있는 클래스에서 각각의 필드 이름이 유일하기 때문에 이에 대해 걱정하지 않아도 됩니다.
+
+```ts
+class C {
+    #foo = 10;
+
+    cHelper() {
+        return this.#foo;
+    }
+}
+
+class D extends C {
+    #foo = 20;
+
+    dHelper() {
+        return this.#foo;
+    }
+}
+
+let instance = new D();
+// 'this.#foo' 는 각 클래스안의 다른 필드를 참조합니다.
+console.log(instance.cHelper()); // '10' 출력
+console.log(instance.dHelper()); // '20' 출력
+```
+
+알아 두면 좋은 또 다른 점은 다른 타입으로 비공개 필드에 접근하면 `TypeError` 를 발생한다는 것입니다.
+
+```ts
+class Square {
+    #sideLength: number;
+
+    constructor(sideLength: number) {
+        this.#sideLength = sideLength;
+    }
+
+    equals(other: any) {
+        return this.#sideLength === other.#sideLength;
+    }
+}
+
+const a = new Square(100);
+const b = { sideLength: 100 };
+
+// Boom!
+// TypeError: attempted to get private field on non-instance
+// 이는 `b` 가 `Square`의 인스턴스가 아니기 때문에 실패 합니다.
+console.log(a.equals(b));
+```
+
+마자막으로, 모든 일반 `.js` 파일 사용자들의 경우, 비공개 필드는 *항상* 할당되기 전에 선언되어야 합니다.
+
+```js
+class C {
+    // '#foo' 선언이 없습니다.
+    // :(
+
+    constructor(foo: number) {
+        // SyntaxError!
+        // '#foo'는 쓰여지기 전에 선언되어야 합니다.
+        this.#foo = foo;
+    }
+}
+```
+
+JavaScript는 항상 사용자들에게 선언되지 않은 프로퍼티에 접근을 허용했지만, TypeScript는 항상 클래스 프로퍼티 선언을 요구했습니다.
+비공개 필드는, `.js` 또는 `.ts` 파일에서 동작하는지 상관없이 항상 선언이 필요합니다.
+
+```js
+class C {
+    /** @type {number} */
+    #foo;
+
+    constructor(foo: number) {
+        // 동작합니다.
+        this.#foo = foo;
+    }
+}
+```
+
+구현에 대한 더 많은 정보는, [the original pull request](https://github.com/Microsoft/TypeScript/pull/30829)를 참고하세요
+
+### 어떤 것을 사용해야 할까요? (Which should I use?)
+
+이미 TypeScript 유저로서 어떤 종류의 비공개를 사용해야 하는지에 대한 많은 질문을 받았습니다: 주로, "`private` 키워드를 사용해야 하나요 아니면 ECMAScript의 해시/우물 (`#`) 비공개 필드를 사용해야 하나요?"
+상황마다 다릅니다!
+
+프로퍼티에서, TypeScript의 `private` 지정자는 완전히 지워집니다 - 이는 런타임에서는 완전히 일반 프로퍼티처럼 동작하며 이것이 `private` 지정자로 선언되었다고 알릴 방법이 없습니다.
+`private` 키워드를 사용할 때, 비공개는 오직 컴파일-타임/디자인-타임에만 시행되며, JavaScript 사용자에게는 전적으로 의도-기반입니다.
+
+```ts
+class C {
+    private foo = 10;
+}
+
+// 이는 컴파일 타임에 오류이지만
+// TypeScript 가 .js 파일로 출력했을 때는
+// 잘 동작하며 '10'을 출력합니다.
+console.log(new C().foo);    // '10' 출력
+//                  ~~~
+// error! Property 'foo' is private and only accessible within class 'C'.
+
+// TypeScript 오류를 피하기 위한 "해결 방법" 으로
+// 캄파일 타임에 이것을 허용합니다.
+console.log(new C()["foo"]); // prints '10'
+```
+
+이 같은 종류의 "약한 비공개(soft privacy)"는 사용자가 API에 접근할 수 없는 상태에서 일시적으로 작업을 하는 데 도움이 되며, 어떤 런타임에서도 동작합니다.
+
+반면에, ECMAScript의 `#` 비공개는 완벽하게 클래스 밖에서 접근 불가능합니다.
+
+```ts
+class C {
+    #foo = 10;
+}
+
+console.log(new C().#foo); // SyntaxError
+//                  ~~~~
+// TypeScript 는 오류를 보고 하며 *또한*
+// 런타임에도 동작하지 않습니다.
+
+console.log(new C()["#foo"]); // undefined 출력
+//          ~~~~~~~~~~~~~~~
+// TypeScript 는 'noImplicitAny' 하에서 오류를 보고하며
+// `undefined`를 출력합니다.
+```
+
+이런 강한 비공개(hard privacy)는 아무도 내부를 사용할 수 없도록 엄격하게 보장하는데 유용합니다.
+만약 라이브러리 작성자일 경우, 비공개 필드를 제거하거나 이름을 바꾸는 것이 급격한 변화를 초래서는 안됩니다.
+
+언급했듯이, 다른 장점은 ECMAScript의 `#` 비공개가 *진짜* 비공개이기 때문에 서브클래싱을 쉽게 할 수 있다는 것입니다.
+ECMAScript `#` 비공개 필드를 사용하면, 어떤 서브 클래스도 필드 네이밍 충돌에 대해 걱정할 필요가 없습니다.
+TypeScript의 `private`프로퍼티 선언에서는, 사용자는 여전히 상위 클래스에 선언된 프로퍼티를 짓밟지  않도록 주의해야 합니다.
+
+한 가지 더 생각해봐야 할 것은 코드가 실행되기를 의도하는 곳입니다.
+현재 TypeScript는 이 기능을 ECMAScript 2015 (ES6) 이상 버전을 대상으로 하지 않으면 지원할 수 없습니다.
+이는 하위 레벨 구현이 비공개를 강제하기 위해 `WeakMap`을 사용하는데, `WeakMap`은 메모리 누수를 잃으키지 않도록 폴리필될 수 없기 때문입니다.
+반면, TypeScript의 `private`-선언 프로퍼티는 모든 대상에서 동작합니다- ECMAScript3에서도!
+
+마지막 고려 사항은 속도 일수 있습니다: `private` 프로퍼티는 다른 어떤 프로퍼티와 다르지 않기 때문에, 어떤 런타임을 대상으로 하단 다른 프로퍼티와 마찬가지로 접근 속도가 빠를 수 있습니다.
+반면에, `#` 비공개 필드는 `WeakMap`을 이용해 다운 레벨 되기 때문에 사용 속도가 느려질 수 있습니다.
+어떤 런타임은 `#` 비공개 필드 구현을 최적화 하고, 더 빠른 `WeakMap`을 구현하고 싶을 수 있지만, 모든 런타임에서 그렇지 않을 수 있습니다.
+
+## <span id="export-star-as-namespace-syntax" /> `export * as ns` 구문 (`export * as ns` Syntax)
+
+다른 모듈의 모든 멤버를 하나의 멤버로 내보내는 단일 진입점을 갖는 것은 종종 일반적입니다.
+
+```ts
+import * as utilities from "./utilities.js";
+export { utilities };
+```
+
+이는 매우 일반적이어서 ECMAScript2020은 최근에 이 패턴을 지원하기 위해서 새로운 구문을 추가했습니다.
+
+```ts
+export * as utilities from "./utilities.js";
+```
+
+이것은 JavaScript에 대한 훌륭한 삶의 질의 향상이며, TypeScript 3.8은 이 구문을 지원합니다.
+모듈 대상이 `es2020` 이전인 경우, TypeScript는 첫 번째 줄의 코드 스니펫을 따라서 무언가를 출력할 것입니다.
+
+## <span id="top-level-await" /> 최상위-레벨 `await` (Top-Level `await`)
+
+TypeScript 3.8은 "최상위-레벨 `await`"이라는 편리한 ECMAScript 기능을 지원합니다.
+
+JavaScript 사용자는 `await`을 사용하기 위해 `async` 함수를 도입하는 경우가 많으며, 이를 정의한 후 즉시 함수를 호출합니다.
+
+```js
+async function main() {
+    const response = await fetch("...");
+    const greeting = await response.text();
+    console.log(greeting);
+}
+
+main()
+    .catch(e => console.error(e))
+```
+
+이전의 JavaScript(유사한 기능을 가진 대부분의 다른 언어들과 함께)에서 `await`은 `async` 함수 내에서 만 허용되었기 때문입니다.
+하지만 최상위-레벨 `await`로, 우리는 모듈의 최상위 레벨에서 `await`을 사용할 수 있습니다.
+
+```ts
+const response = await fetch("...");
+const greeting = await response.text();
+console.log(greeting);
+
+// 모듈인지 확인
+export {};
+```
+
+유의할 점이 있습니다: 최상위-레벨 `await`은 *module*의 최상위 레벨에서만 동작하며, 파일은 TypeScript가 `import`나 `export`를 찾을 때에만 모듈로 간주됩니다.
+일부 기본적인 경우에 `export {}`와 같은 보일러 플레이트를 작성하여 이를 확인할 필요가 있습니다.
+
+이러한 경우가 예상되는 모든 환경에서 최상위 레벨 `await`은 동작하지 않을 수 있습니다.
+현재, `target` 컴파일러 옵션이 `es2017` 이상이고, `module`이 `esnext` 또는 `system`인 경우에만 최상위 레벨 `await`을 사용할 수 있습니다.
+몇몇 환경과 번들러내에서의 지원은 제한적으로 작동하거나 실험적 지원을 활성화해야 할 수도 있습니다.
+
+구현에 관한 더 자세한 정보는 [the original pull request을 확인하세요](https://github.com/microsoft/TypeScript/pull/35813).
+
+## <span id="es2020-for-target-and-module" /> `es2020`용 `target`과 `module`   (`es2020` for `target` and `module`)
+
+TypeScript 3.8은 `es2020`을 `module`과 `target` 옵션으로 지원합니다.
+이를 통해 선택적 체이닝 (optional chaining), nullish 병합 (nullish coalescing), `export * as ns` 그리고 동적인 `import(...)` 구문과 같은 ECMAScript 2020 기능이 유지됩니다.
+또한 `bigint` 리터럴이 `esnext` 아래에 안정적인 `target`을 갖는 것을 의미합니다.
+
+## <span id="jsdoc-modifiers" /> JSDoc 프로퍼티 지정자 (JSDoc Property Modifiers)
+
+TypeScript 3.8는 `allowJs` 플래그를 사용하여 JavaScript 파일을 지원하고 `checkJs` 옵션이나 `// @ts-check` 주석을 `.js` 파일 맨 위에 추가하여 JavaScript 파일의 *타입-검사*를 지원합니다.
+
+JavaScript 파일에는 타입-검사를 위한 전용 구문이 없기 때문에 TypeScript는 JSDoc을 활용합니다.
+TypeScript 3.8은 프로퍼티에 대한 몇 가지 새로운 JSDoc 태그를 인식합니다.
+
+먼저 접근 지정자입니다: `@public`, `@private` 그리고 `@protected`입니다.
+이 태그들은 TypeScript 내에서 각각 `public`, `private`, `protected`와 동일하게 동작합니다.
+
+```js
+// @ts-check
+
+class Foo {
+    constructor() {
+        /** @private */
+        this.stuff = 100;
+    }
+
+    printStuff() {
+        console.log(this.stuff);
+    }
+}
+
+new Foo().stuff;
+//        ~~~~~
+// 오류! 'stuff' 프로퍼티는 private 이기 때문에 오직 'Foo' 클래스 내에서만 접근이 가능합니다.
+```
+
+* `@public`은 항상 암시적이며 생략될 수 있지만, 어디서든 해당 프로퍼티에 접근 가능을 의미합니다.
+* `@private`은 오직 프로퍼티를 포함하는 클래스 내에서 해당 프로퍼티 사용 가능을 의미합니다.
+* `@protected`는 프로퍼티를 포함하는 클래스와 파생된 모든 하위 클래스내에서 해당 프로퍼티를 사용할 수 있지만, 포함하는 클래스의 인스턴스는 해당 프로퍼티를 사용할 수 없습니다.
+
+다음으로 `@readonly` 지정자를 추가하여 프로퍼티가 초기화 과정 내에서만 값이 쓰이는 것을 보장합니다.
+
+```js
+// @ts-check
+
+class Foo {
+    constructor() {
+        /** @readonly */
+        this.stuff = 100;
+    }
+
+    writeToStuff() {
+        this.stuff = 200;
+        //   ~~~~~
+        // 'stuff'는 읽기-전용(read-only) 프로퍼티이기 때문에 할당할 수 없습니다.
+    }
+}
+
+new Foo().stuff++;
+//        ~~~~~
+// 'stuff'는 읽기-전용(read-only) 프로퍼티이기 때문에 할당할 수 없습니다.
+```
+
+## <span id="better-directory-watching" /> 리눅스에서 더 나은 디렉터리 감시와 `watchOptions`
+
+TypeScript 3.8에서는 `node_modules`의 변경사항을 효율적으로 수집하는데 중요한 새로운 디렉터리 감시 전략을 제공합니다.
+
+리눅스와 같은 운영체제에서 TypeScript는 `node_modules`에 디렉터리 왓쳐(파일 왓쳐와는 반대로)를 설치하고, 의존성 변화를 감지하기 위해 많은 하위 디렉터리를 설치합니다.
+왜냐하면 사용 가능한 파일 왓쳐의 수는 종종 `node_modules`의 파일 수에 의해 가려지기 때문이고, 추적할 디렉터리 수가 적기 때문입니다.
+
+TypeScript의 이전 버전은 폴더에 디렉터리 왓쳐를 *즉시* 설치하며, 초기에는 괜찮을 겁니다; 하지만, npm install 할 때, `node_modules`안에서 많은 일들이 발생할 것이고, TypeScript를 압도하여, 종종 에디터 세션을 아주 느리게 만듭니다.
+이를 방지하기 위해, TypeScript 3.8은 디렉터리 왓쳐를 설치하기 전에 조금 기다려서 변동성이 높은 디렉터리에게 안정될 수 있는 시간을 줍니다.
+
+왜냐하면 모든 프로젝트는 다른 전략에서 더 잘 작동할 수 있고, 이 새로운 방법은 당신의 작업 흐름에서는 잘 맞지 않을 수 있습니다. TypeScript 3.8은 파일과 디렉터리를 감시하는데 어떤 감시 전략을 사용할지 컴파일러/언어 서비스에 알려줄 수 있도록 `tsconfig.json`과 `jsconfig.json`에 `watchOptions`란 새로운 필드를 제공합니다.
+
+```json5
+{
+    // 일반적인 컴파일러 옵션들
+    "compilerOptions": {
+        "target": "es2020",
+        "moduleResolution": "node",
+        // ...
+    },
+
+    // NEW: 파일/디렉터리 감시를 위한 옵션
+    "watchOptions": {
+        // 파일과 디렉터리에 네이티브 파일 시스템 이벤트 사용
+        "watchFile": "useFsEvents",
+        "watchDirectory": "useFsEvents",
+
+        // 업데이트가 빈번할 때
+        // 업데이트하기 위해 더 자주 파일을 폴링
+        "fallbackPolling": "dynamicPriority"
+    }
+}
+```
+
+`watchOptions`는 구성할 수 있는 4가지 새로운 옵션이 포함되어 있습니다.
+
+* `watchFile`: 각 파일의 감시 방법 전략. 다음과 같이 설정할 수 있습니다:
+    * `fixedPollingInterval`: 고정된 간격으로 모든 파일의 변경을 1초에 여러 번 검사합니다.
+    * `priorityPollingInterval`: 모든 파일의 변경을 1초에 여러 번 검사합니다, 하지만 휴리스틱을 사용하여 특정 타입의 파일은 다른 타입의 파일보다 덜 자주 검사합니다.
+    * `dynamicPriorityPolling`: 동적 큐를 사용하여 덜-자주 수정된 파일은 적게 검사합니다.
+    * `useFsEvents` (디폴트): 파일 변화에 운영체제/파일 시스템의 네이티브 이벤트를 사용합니다.
+    * `useFsEventsOnParentDirectory`: 파일을 포함하고 있는 디렉터리 변경을 감지할 때, 운영체제/파일 시스템의 네이티브 이벤트를 사용합니다. 파일 왓쳐를 적게 사용할 수 있지만, 덜 정확할 수 있습니다.
+* `watchDirectory`: 재귀적인 파일-감시 기능이 없는 시스템 안에서 전체 디렉터리 트리가 감시되는 전략. 다음과 같이 설정할 수 있습니다:
+    * `fixedPollingInterval`: 고정된 간격으로 모든 디렉터리의 변경을 1초에 여러 번 검사합니다.
+    * `dynamicPriorityPolling`: 동적 큐를 사용하여 덜-자주 수정된 디렉터리는 적게 검사합니다.
+    * `useFsEvents` (디폴트): 디렉터리 변경에 운영체제/파일 시스템의 네이티브 이벤트를 사용합니다.
+* `fallbackPolling`: 파일 시스템 이벤트를 사용할 때, 이 옵션은 시스템이 네이티브 파일 왓쳐가 부족하거나/혹은 지원하지 않을 때, 사용되는 폴링 전략을 지정합니다. 다음과 같이 설정할 수 있습니다.
+    * `fixedPollingInterval`: *(위를 참조하세요.)*
+    * `priorityPollingInterval`: *(위를 참조하세요.)*
+    * `dynamicPriorityPolling`: *(위를 참조하세요.)*
+* `synchronousWatchDirectory`: 디렉터리의 연기된 감시를 비활성화합니다. 연기된 감시는 많은 파일이 한 번에 변경될 때 유용합니다 (예를 들어, `npm install`을 실행하여 `node_modules`의 변경), 하지만 덜-일반적인 설정을 위해 비활성화할 수도 있습니다.
+
+이 변경의 더 자세한 내용은 Github으로 이동하여 [the pull request](https://github.com/microsoft/TypeScript/pull/35615)를 읽어보세요.
+
+## <span id="assume-direct-dependencies" /> "빠르고 느슨한" 증분 검사
+
+TypeScript 3.8은 새로운 컴파일러 옵션 `assumeChangesOnlyAffectDirectDepencies`을 제공합니다.
+이 옵션이 활성화되면, TypeScript는 정말로 영향을 받은 파일들은 재검사/재빌드하지않고, 변경된 파일뿐만 아니라 직접 import 한 파일만 재검사/재빌드 합니다.
+
+예를 들어, 다음과 같이 `fileA.ts`를 import 한 `fileB.ts`를 import 한 `fileC.ts`를 import 한 `fileD.ts`를 살펴봅시다:
+
+```text
+fileA.ts <- fileB.ts <- fileC.ts <- fileD.ts
+```
+
+`--watch` 모드에서는, `fileA.ts`의 변경이 `fileB.ts`, `fileC.ts` 그리고 `fileD.ts`를 TypeScript가 재-검사해야 한다는 의미입니다.
+`assumeChangesOnlyAffectDirectDependencies`에서는 `fileA.ts`의 변경은 `fileA.ts`와 `fileB.ts`만 재-검사하면 됩니다.
+
+Visual Studio Code와 같은 코드 베이스에서는, 특정 파일의 변경에 대해 약 14초에서 약 1초로 재빌드 시간을 줄여주었습니다.
+이 옵션을 모든 코드 베이스에서 추천하는 것은 아니지만, 큰 코드 베이스를 가지고 있고, 나중까지 전체 프로젝트 오류를 기꺼이 연기하겠다면 (예를 들어, `tsconfig.fullbuild.json`이나 CI를 통한 전용 빌드) 흥미로울 것입니다.
+
+더 자세한 내용은 [the original pull request](https://github.com/microsoft/TypeScript/pull/35711)에서 보실 수 있습니다.
diff --git a/docs/documentation/ko/release-notes/TypeScript 3.9.md b/docs/documentation/ko/release-notes/TypeScript 3.9.md
new file mode 100644
index 00000000..c479ee84
--- /dev/null
+++ b/docs/documentation/ko/release-notes/TypeScript 3.9.md	
@@ -0,0 +1,542 @@
+---
+title: TypeScript 3.9
+layout: docs
+permalink: /ko/docs/handbook/release-notes/typescript-3-9.html
+oneline: TypeScript 3.9 Release Notes
+---
+
+* [추론과 `Promise.all` 개선](#improvements-in-inference-and-promiseall)
+* [속도 향상](#speed-improvements)
+* [`// @ts-expect-error` 주석](#-ts-expect-error-comments)
+* [조건문에서 호출되지 않은 함수 체크](#uncalled-function-checks-in-conditional-expressions)
+* [에디터 개선](#editor-improvements)
+    * [JavaScript에서 CommonJS 자동-Imports](#commonjs-auto-imports-in-javascript)
+    * [코드 작업 개행 유지](#code-actions-preserve-newlines)
+    * [누락된 반환문 빠른 수정](#quick-fixes-for-missing-return-expressions)
+    * [`tsconfig.json` 파일 "솔루션 스타일" 지원](#support-for-solution-style-tsconfigjson-files)
+* [주요 변경 사항](#주요-변경-사항-breaking-changes)
+
+## <span id="improvements-in-inference-and-promiseall" /> 추론과 `Promise.all` 개선 (Improvements in Inference and `Promise.all`)
+
+최신 버전의 TypeScript(약 3.7)는 `Promise.all` 및 `Promise.race`와 같은 함수 선언이 업데이트되었습니다.
+안타깝게도, 특히 `null` 또는 `undefined`와 값을 혼합할 때, 약간의 회귀가 발생했습니다.
+
+```ts
+interface Lion {
+    roar(): void
+}
+
+interface Seal {
+    singKissFromARose(): void
+}
+
+async function visitZoo(lionExhibit: Promise<Lion>, sealExhibit: Promise<Seal | undefined>) {
+    let [lion, seal] = await Promise.all([lionExhibit, sealExhibit]);
+    lion.roar(); // 오 이런
+//  ~~~~
+// 객체는 아마도 'undefined' 일 것입니다.
+}
+```
+
+이 동작은 이상합니다!
+`sealExhibit`가 `undefined`를 포함하는 것은 어떻게든 `lion` 타입에 `undefined`를 주입합니다.
+
+[Jack Bates](https://github.com/jablko)의 [pull request](https://github.com/microsoft/TypeScript/pull/34501) 덕분에, TypeScript 3.9의 추론 프로세스가 개선되었습니다.
+위 오류는 더 이상 발생하지 않습니다.
+`Promise`와 관련된 문제로 인해 이전 버전의 TypeScript에서 고생했다면, 3.9를 사용하는 것이 좋습니다.
+
+### `awaited` 타입은 무엇입니까? (What About the `awaited` Type?)
+
+이슈 트래커와 설계 회의 노트를 봐왔다면, [`awaited` 라는 새로운 연산자](https://github.com/microsoft/TypeScript/pull/35998)에 대한 일부 작업을 알고 있을 것입니다.
+이 타입 연산자의 목표는 JavaScript에서 `Promise`를 푸는 방식을 정확하게 모델링 하는 것입니다.
+
+처음에는 TypeScript 3.9에서 `awaited`을 제공할 것으로 예상했지만, 기존 코드 베이스와 함께 초기 TypeScript 빌드를 실행함으로써 모든 사용자에게 원활하게 배포하기 전에 이 기능에 더 많은 설계 작업이 필요하다는 사실을 알았습니다.
+결과적으로, 더 확실해질 때까지 메인 브랜치에서 이 기능을 빼기로 결정했습니다.
+이 기능에 대해 더 많은 실험을 할 예정이지만, 이번 릴리스에서는 제공하지 않습니다.
+
+## <span id="speed-improvements" /> 속도 향상 (Speed Improvements)
+
+TypeScript 3.9는 많은 새로운 속도 향상 기능이 포함되어 있습니다.
+우리 팀은 material-ui 및 styled-components와 같은 패키지를 사용할 때 편집 / 컴파일 속도가 매우 열악한 것을 확인한 후 성능에 중점을 두었습니다.
+거대한 유니언, 인터섹션, 조건별 타입 그리고 매핑된 타입과 관련된 특정 병리학적 사례를 최적화하는 다양한 pull request로 심층 분석했습니다.
+
+* https://github.com/microsoft/TypeScript/pull/36576
+* https://github.com/microsoft/TypeScript/pull/36590
+* https://github.com/microsoft/TypeScript/pull/36607
+* https://github.com/microsoft/TypeScript/pull/36622
+* https://github.com/microsoft/TypeScript/pull/36754
+* https://github.com/microsoft/TypeScript/pull/36696
+
+이러한 각 pull request는 특정 코드 베이스에서 컴파일 시간이 약 5-10% 단축됩니다.
+전체적으로 material-ui의 컴파일 시간이 약 40% 단축되었습니다!
+
+또한 에디터 시나리오에서 파일 이름 변경 기능이 일부 변경되었습니다.
+우리는 Visual Studio Code 팀으로부터 파일 이름을 바꿀 때 어떤 import 문을 업데이트해야 하는지 파악하는데 5초에서 10초가 소요될 수 있다고 들었습니다.
+TypeScript 3.9는 [컴파일러 및 언어 서비스가 파일 조회를 캐싱 하는 방식의 내부 변경](https://github.com/microsoft/TypeScript/pull/37055)을 통해 이 문제를 해결합니다.
+
+여전히 개선의 여지가 있지만, 이 작업이 모든 사람들에게 보다 빠른 경험으로 이어지기를 바랍니다!
+
+## <span id="-ts-expect-error-comments" /> `// @ts-expect-error` 주석 (`// @ts-expect-error` Comments)
+
+TypeScript로 라이브러리를 작성하고 퍼블릭 API의 일부분으로 `doStuff`라는 함수를 export 한다고 상상해보세요.
+TypeScript 사용자가 타입-체크 오류를 받을 수 있도록 `doStuff` 함수의 타입은 두 개의 `string`을 갖는다고 선언하지만, 또한 JavaScript 사용자에게 유용한 오류를 제공하기 위해 런타임 오류 체크를 합니다 (개발 빌드 시에만 가능).
+
+```ts
+function doStuff(abc: string, xyz: string) {
+    assert(typeof abc === "string");
+    assert(typeof xyz === "string");
+
+    // 어떤 작업을 하세요
+}
+```
+
+그래서 TypeScript 사용자는 함수를 잘못 사용할 경우 유용한 빨간 오류 밑줄과 오류 메시지를 받게 되며, JavaScript 사용자는 단언 오류를 얻게 됩니다.
+이러한 작동을 테스트하기 위해서, 유닛 테스트를 작성하겠습니다.
+
+```ts
+expect(() => {
+    doStuff(123, 456);
+}).toThrow();
+```
+
+불행히도 위의 테스트가 TypeScript에서 작성된다면, TypeScript는 오류를 발생시킬 것입니다!
+
+```ts
+    doStuff(123, 456);
+//          ~~~
+// 오류: 'number' 타입은 'string' 타입에 할당할 수 없습니다.
+```
+
+그래서 TypeScript 3.9는 새로운 기능을 도입했습니다: `// @ts-expect-error` 주석.
+라인 앞에 `// @ts-expect-error` 주석이 붙어 있을 경우, TypeScript는 해당 오류를 보고하는 것을 멈춥니다;
+그러나 오류가 존재하지 않으면, TypeScript는 `// @ts-expect-error`가 필요하지 않다고 보고할 것입니다.
+
+간단한 예로, 다음 코드는 괜찮습니다
+
+```ts
+// @ts-expect-error
+console.log(47 * "octopus");
+```
+
+그러나 다음 코드는
+
+```ts
+// @ts-expect-error
+console.log(1 + 1);
+```
+
+오류로 이어질 것입니다
+
+```
+Unused '@ts-expect-error' directive.
+```
+
+이 기능을 구현한 컨트리뷰터, [Josh Goldberg](https://github.com/JoshuaKGoldberg)에게 큰 감사를 드립니다.
+자세한 내용은 [the `ts-expect-error` pull request](https://github.com/microsoft/TypeScript/pull/36014)를 참고하세요.
+
+### `ts-ignore` 또는 `ts-expect-error`? (`ts-ignore` or `ts-expect-error`?)
+
+어떤 점에서는 `// @ts-expect-error`가 `// @ts-ignore`과 유사하게 억제 주석(suppression comment)으로 작용할 수 있습니다.
+차이점은 `// @ts-ignore`는 다음 행에 오류가 없을 경우 아무것도 하지 않는다는 것입니다.
+
+기존 `// @ts-ignore` 주석을 `// @ts-expect-error`로 바꾸고 싶은 마음이 들 수 있으며, 향후 코드에 무엇이 적합한지 궁금할 수 있습니다.
+전적으로 당신과 당신 팀의 선택이지만, 우리는 어떤 상황에서 어떤 것을 선택할 것인지에 대한 몇 가지 아이디어를 가지고 있습니다.
+
+다음 경우라면 `ts-expect-error`를 선택하세요:
+
+* 타입 시스템이 작동에 대한 오류를 발생시키는 테스트 코드 작성을 원하는 경우
+* 수정이 빨리 이루어지길 원하며 빠른 해결책이 필요한 경우
+* 오류가 발생한 코드가 다시 유효해지면 바로 억제 주석을 삭제하길 원하는 혁신적인 팀이 이끄는 적당한-크기의 프로젝트에서 작업하는 경우
+
+다음 경우라면 `ts-ignore`를 선택하세요:
+
+* 더 큰 프로젝트를 갖고 있고 코드에서 발생한 새로운 오류의 명확한 책임자를 찾기 힘든 경우
+* TypeScript의 두 가지 버전 사이에서 업그레이드하는 중이고, 한 버전에서는 코드 오류가 발생하지만 나머지 버전에서는 그렇지 않은 경우
+* 솔직히 어떤 옵션 더 나은지 결정할 시간이 없는 경우
+
+## <span id="uncalled-function-checks-in-conditional-expressions" /> 조건문에서 호출되지 않은 함수 체크 (Uncalled Function Checks in Conditional Expressions)
+
+TypeScript 3.7에서 함수 호출을 잊어버렸을 경우 오류를 보고하기 위해 *호출되지 않은 함수 체크*를 도입했습니다.
+
+```ts
+function hasImportantPermissions(): boolean {
+    // ...
+}
+
+// 이런!
+if (hasImportantPermissions) {
+//  ~~~~~~~~~~~~~~~~~~~~~~~
+// hasImportantPermissions 함수가 항상 정의되어 있기 때문에, 이 조건문은 항상 true를 반환합니다.
+// 대신 이것을 호출하려 하셨나요?
+    deleteAllTheImportantFiles();
+}
+```
+
+그러나, 이 오류는 `if` 문의 조건에만 적용됩니다.
+[Alexander Tarasyuk](https://github.com/a-tarasyuk)의 [a pull request](https://github.com/microsoft/TypeScript/pull/36402) 덕분에, 이 기능은 삼항 조건 연산자도 지원하게 되었습니다 (예. `cond ? trueExpr : falseExpr` 구문).
+
+```ts
+declare function listFilesOfDirectory(dirPath: string): string[];
+declare function isDirectory(): boolean;
+
+function getAllFiles(startFileName: string) {
+    const result: string[] = [];
+    traverse(startFileName);
+    return result;
+
+    function traverse(currentPath: string) {
+        return isDirectory ?
+        //     ~~~~~~~~~~~
+        // isDirectory 함수가 항상 정의되어 있기 때문에,
+        // 이 조건문은 항상 true를 반환합니다
+        // 대신 이것을 호출하려 하셨나요?
+            listFilesOfDirectory(currentPath).forEach(traverse) :
+            result.push(currentPath);
+    }
+}
+```
+
+https://github.com/microsoft/TypeScript/issues/36048
+
+## <span id="editor-improvements" /> 에디터 개선 (Editor Improvements)
+
+TypeScript 컴파일러는 주요 에디터의 TypeScript 작성 경험뿐만 아니라, Visual Studio 계열 에디터의 JavaScript 작성 경험에도 영향을 줍니다.
+에디터에서 새로운 TypeScript/JavaScript 기능을 사용하는 것은 에디터에 따라 다르겠지만
+
+* Visual Studio Code는 [다른 버전의 TypeScript 선택](https://code.visualstudio.com/docs/typescript/typescript-compiling#_using-the-workspace-version-of-typescript)을 지원합니다. 또는, 최신으로 유지하기 위한 [JavaScript/TypeScript Nightly Extension](https://marketplace.visualstudio.com/items?itemName=ms-vscode.vscode-typescript-next)도 있습니다.(대체로 안정적입니다.)
+* Visual Studio 2017/2019 에는 [SDK 설치 프로그램] 과 [MSBuild 설치](https://www.nuget.org/packages/Microsoft.TypeScript.MSBuild)가 있습니다.
+* Sublime Text 3은 [다른 버전의 TypeScript 선택]((https://github.com/microsoft/TypeScript-Sublime-Plugin#note-using-different-versions-of-typescript))을 지원합니다.
+
+### <span id="commonjs-auto-imports-in-javascript" /> JavaScript에서 CommonJS 자동-import (CommonJS Auto-Imports in JavaScript)
+
+CommonJS 모듈을 사용하는 JavaScript 파일에서 자동-import 기능이 크게 개선되었습니다.
+
+이전 버전에서는, TypeScript는 항상 파일에 관계없이 ECMAScript-스타일의 import를 원한다고 가정했습니다.
+
+```js
+import * as fs from "fs";
+```
+
+하지만, 모든 사람이 JavaScript 파일을 쓸 때 ECMAScript-스타일의 모듈을 원하는 것은 아닙니다.
+많은 사용자가 여전히 CommonJS-스타일의 `require(...)` import를 사용하고 있습니다.
+
+```js
+const fs = require("fs");
+```
+
+이제 TypeScript는 파일 스타일을 깔끔하고 일관되게 유지하기 위해서 사용 중인 import 유형을 자동으로 검색합니다.
+
+<video src="https://devblogs.microsoft.com/typescript/wp-content/uploads/sites/11/2020/03/ERkaliGU0AA5anJ1.mp4"></video>
+
+이 변경에 대한 자세한 내용은, [해당 pull request](https://github.com/microsoft/TypeScript/pull/37027)를 참고하세요.
+
+### <span id="code-actions-preserve-newlines" /> 코드 작업 개행 유지 (Code Actions Preserve Newlines)
+
+TypeScript의 리팩터링과 빠른 수정은 종종 개행을 유지하는데 큰 역할을 하지는 않았습니다.
+기본적인 예로 다음 코드를 보겠습니다.
+
+```ts
+const maxValue = 100;
+
+/*시작*/
+for (let i = 0; i <= maxValue; i++) {
+    // 먼저 제곱 값을 구한다.
+    let square = i ** 2;
+
+    // 제곱 값을 출력한다.
+    console.log(square);
+}
+/*끝*/
+```
+
+에디터에서 `/*시작*/` 에서 `/*끝*/` 까지 범위를 강조하여 새로운 함수로 추출하면, 다음과 같은 코드가 됩니다.
+
+```ts
+const maxValue = 100;
+
+printSquares();
+
+function printSquares() {
+    for (let i = 0; i <= maxValue; i++) {
+        // 먼저 제곱 값을 구한다.
+        let square = i ** 2;
+        // 제곱 값을 출력한다.
+        console.log(square);
+    }
+}
+```
+
+![이전 버전의 TypeScript에선 함수로 루프 추출은. 개행을 유지하지 않습니다.](https://devblogs.microsoft.com/typescript/wp-content/uploads/sites/11/2020/03/printSquaresWithoutNewlines-3.9.gif.gif)
+
+이건 이상적이지 않습니다 - `for` 루프에서 각각의 문 사이에 빈 줄이 있었지만 리팩터링이 없애버렸습니다!
+TypeScript 3.9은 우리가 작성한 것을 보존하기 위해 조금 더 작업을 합니다.
+
+```ts
+const maxValue = 100;
+
+printSquares();
+
+function printSquares() {
+    for (let i = 0; i <= maxValue; i++) {
+        // 먼저 제곱 값을 구한다.
+        let square = i ** 2;
+
+        // 제곱값을 출력한다.
+        console.log(square);
+    }
+}
+```
+
+![TypeScript 3.9의 함수에 대한 루프 추출. 개행이 보존됨](https://devblogs.microsoft.com/typescript/wp-content/uploads/sites/11/2020/03/printSquaresWithNewlines-3.9.gif.gif)
+
+[이 pull request](https://github.com/microsoft/TypeScript/pull/36688)에서 구현에 대해 더 자세히 볼 수 있습니다.
+
+### <span id="quick-fixes-for-missing-return-expressions" /> 누락된 반환 문 빠른 수정 (Quick Fixes for Missing Return Expressions)
+
+특히 화살표 함수에 중괄호를 추가할 때, 함수의 마지막 문의 값을 반환하는 것을 잊는 경우가 있습니다.
+
+```ts
+// 이전
+let f1 = () => 42
+
+// 실수 - 동일하지 않음!
+let f2 = () => { 42 }
+```
+
+커뮤니티 멤버인 [Wenlu Wang](https://github.com/Kingwl)의 [pull request](https://github.com/microsoft/TypeScript/pull/26434) 덕분에, TypeScript는 누락된 `return` 문을 추가하거나, 중괄호를 제거하거나, 객체 리터럴 처럼 보이는 화살표 함수 몸체에 괄호를 추가하는 빠른-수정을 제공할 수 있습니다.
+
+![TypeScript는 `return` 문을 추가하거나 중괄호를 제거하여 식이 반환되지 않는 오류를 수정합니다.](https://devblogs.microsoft.com/typescript/wp-content/uploads/sites/11/2020/04/missingReturnValue-3-9.gif)
+
+### <span id="support-for-solution-style-tsconfigjson-files" /> `tsconfig.json` 파일 "솔루션 스타일" 지원 (Support for "Solution Style" `tsconfig.json` Files)
+
+에디터는 파일이 어떤 설정 파일에 속하는지 파악하여 적절한 옵션을 적용할 수 있도록 하고 현재 "프로젝트"에 어떤 다른 파일이 포함되어 있는지 파악해야 합니다.
+기본적으로, TypeScript의 언어 서버가 영향을 주는 에디터는 각 상위 디렉터리를 따라 올라가 `tsconfig.json`을 찾음으로써 이 작업을 수행합니다.
+
+이 문제가 다소 실패하는 경우 중 하나는 tsconfig.json이 단순히 다른 tsconfig.json 파일을 참조하기 위해 존재할 때였습니다.
+
+```json5
+// tsconfig.json
+{
+    "files": [],
+    "references": [
+        { "path": "./tsconfig.shared.json" },
+        { "path": "./tsconfig.frontend.json" },
+        { "path": "./tsconfig.backend.json" },
+    ]
+}
+```
+
+다른 프로젝트 파일을 관리만 하는 이 파일은 어떤 환경에서는 종종 "솔루션"이라고 불립니다.
+여기서 `tsconfig.*.json` 파일 중 어떤 파일도 서버에 의해 검색되지 않지만, 현재 `.ts` 파일이 루트의 `tsconfig.json`에 언급된 프로젝트 중 하나에 속한다는 것을 언어 서버가 이해하기를 원합니다.
+
+TypeScript 3.9 는 이 설정에 대한 시나리오 수정을 지원합니다.
+더 자세한 사항은, [이 기능을 추가한 pull request](https://github.com/microsoft/TypeScript/pull/37239)를 확인하세요.
+
+## 주요 변경 사항 (Breaking Changes)
+
+### 선택적 체이닝과 널이 아닌 단언에서 파싱 차이점 (Parsing Differences in Optional Chaining and Non-Null Assertions)
+
+최근에 TypeScript는 선택적 체이닝 연산자를 도입했지만, 널이 아닌 단언 연산자 (`!`)와 함께 사용하는 선택적 체이닝 (`?.`)의 동작이 매우 직관적이지 않다는 사용자 피드백을 받았습니다.
+
+구체적으로, 이전 버전에서는 코드가
+
+```ts
+foo?.bar!.baz
+```
+
+다음 JavaScript와 동일하게 해석되었습니다.
+
+```js
+(foo?.bar).baz
+```
+
+위에 코드에서 괄호는 선택적 체이닝의 "단락" 동작을 중단합니다, 그래서 만약 `foo`가 `undefined`이면, `baz`에 접근하는 것은 런타임 오류를 발생시킵니다.
+
+이 동작을 지적한 바벨팀과 피드백을 준 대부분의 사용자들은 이 동작이 잘못되었다고 생각합니다.
+저희도 그렇게 생각합니다!
+`bar`의 타입에서 `null`과 `undefined`를 제거하는 것이 의도이기 때문에 가장 많이 들은 말은 `!` 연산자는 그냥 "사라져야 한다"입니다.
+
+즉, 대부분의 사람들은 원본 문장이 다음과 같이
+
+```js
+foo?.bar.baz
+```
+
+`foo`가 `undefined`일 때, 그냥 `undefined`로 평가하는 것으로 해석되어야 한다고 생각합니다
+
+이것이 주요 변경 사항이지만, 대부분의 코드가 새로운 해석을 염두에 두고 작성되었다고 생각합니다.
+이전 동작으로 되돌리고 싶은 사용자는 `!` 연산자 왼쪽에 명시적인 괄호를 추가할 수 있습니다.
+
+```ts
+(foo?.bar)!.baz
+```
+
+### `}` 와 `>` 는 이제 유효하지 않은 JSX 텍스트 문자입니다 (`}` and `>` are Now Invalid JSX Text Characters)
+
+JSX 명세서에는 텍스트 위치에 `}`와 `>` 문자의 사용을 금지합니다.
+TypeScript와 바벨은 이 규칙을 더 적합하게 적용하기로 결정했습니다.
+이 문자를 넣기 위한 새로운 방법은 HTML 이스케이프 코드를 사용하거나 (예를 들어, `<span> 2 &gt 1 </div>`) 문자열 리터럴로 표현식을 넣는 것입니다 (예를 들어, `<span> 2 {">"} 1 </div`).
+
+다행히, [Brad Zacher](https://github.com/bradzacher)의 [pull request](https://github.com/microsoft/TypeScript/pull/36636) 덕분에, 다음 문장과 함께 오류 메시지를 받을 수 있습니다
+
+```
+Unexpected token. Did you mean `{'>'}` or `&gt;`?
+Unexpected token. Did you mean `{'}'}` or `&rbrace;`?
+```
+
+예를 들어:
+
+```tsx
+let directions = <span>Navigate to: Menu Bar > Tools > Options</div>
+//                                           ~       ~
+// Unexpected token. Did you mean `{'>'}` or `&gt;`?
+```
+
+이 오류 메시지는 편리하고 빠른 수정과 함께 제공되고 [Alexander Tarasyuk](https://github.com/a-tarasyuk) 덕분에, 많은 오류가 있으면 [이 변경사항을 일괄 적용 할 수 있습니다](https://github.com/microsoft/TypeScript/pull/37436).
+
+### 교집합과 선택적 프로퍼티에 대한 더 엄격해진 검사 (Stricter Checks on Intersections and Optional Properties)
+
+일반적으로, `A & B`와 같은 교차 타입은 `A` 또는 `B`가 `C`에 할당할 수 있으면, `A & B`는 `C`에 할당할 수 있습니다; 하지만, 가끔 선택적 프로퍼티에서 문제가 생깁니다.
+예를 들어, 다음을 봅시다:
+
+```ts
+interface A {
+    a: number; // 'number' 인 것에 주목
+}
+
+interface B {
+    b: string;
+}
+
+interface C {
+    a?: boolean; // 'boolean' 인것에 주목
+    b: string;
+}
+
+declare let x: A & B;
+declare let y: C;
+
+y = x;
+```
+
+이전 버전의 TypeScript에서는, `A`가 `C`와 완전히 호환되지 않지만, `B`가 `C`와 호환 *되었기* 때문에 허용되었습니다.
+
+TypeScript 3.9에서는, 교집합 안의 모든 타입이 구제적인 객체 타입이면, 타입 시스템은 모든 프로퍼티를 한 번에 고려합니다.
+결과적으로, TypeScript는 `A & B`의 `a` 프로퍼티는 `C`의 `a` 프로퍼티와 호환되지 않는다고 봅니다:
+
+```
+'A & B' 타입은 'C' 타입에 할당할 수 없습니다.
+  'a' 프로퍼티의 타입은 호환되지 않습니다.
+    'number' 타입은 'boolean | undefined' 타입에 할당할 수 없습니다.
+```
+
+이 변경사항에 대한 자세한 정보는, [해당 pull request](https://github.com/microsoft/TypeScript/pull/37195)를 참조하세요.
+
+### 판별 프로퍼티로 줄어든 교집합 (Intersections Reduced By Discriminant Properties)
+
+존재하지 않는 값을 기술하는 타입으로 끝날 수 있는 몇 가지 경우가 있습니다.
+예를 들어
+
+```ts
+declare function smushObjects<T, U>(x: T, y: U): T & U;
+
+interface Circle {
+    kind: "circle";
+    radius: number;
+}
+
+interface Square {
+    kind: "square";
+    sideLength: number;
+}
+
+declare let x: Circle;
+declare let y: Square;
+
+let z = smushObjects(x, y);
+console.log(z.kind);
+```
+
+이 코드는 `Circle`과 `Square`의 교집합을 생성할 방법이 전혀 없기 때문에 약간 이상합니다 - 호환되지 않는 두 `kind` 필드가 있습니다.
+이전 버전의 TypeScript에서는, 이 코드는 허용되었고 `"circle" & "square"`가 `절대(never)` 존재할 수 없는 값의 집합을 기술했기 때문에 `kind` 자체의 타입은 `never`였습니다.
+
+TypeScript 3.9에서는, 타입 시스템이 더 공격적입니다 - `kind` 프로퍼티 때문에 `Circle`과 `Square`를 교차하는 것이 불가능하다는 것을 알고 있습니다.
+그래서 `z.kind`를 `never`로 축소하는 대신, `z` 자체(`Circle & Square`) 타입을 `never`로 축소합니다.
+즉 위의 코드는 다음과 같은 오류를 발생합니다:
+
+```
+'kind' 프로퍼티는 'never' 타입에 존재하지 않습니다.
+```
+
+관찰한 대부분의 오류는 잘못된 타입 선언과 일치하는 것으로 보입니다.
+자세한 내용은 [원문 pull request](https://github.com/microsoft/TypeScript/pull/36696)를 보세요.
+
+### Getters/Setters는 더 이상 열거하지 않습니다 (Getters/Setters are No Longer Enumerable)
+
+이전 버전의 TypeScript에서, 클래스의 `get`과 `set` 접근자는 열거 가능한 방법으로 방출되었습니다; 하지만, `get`과 `set`은 열거할 수 없다는 ECMAScript 사양을 따르지 않았습니다.
+결과적으로, ES5와 ES2015를 타겟팅 하는 TypeScript 코드는 동작이 다를 수 있습니다.
+
+깃허브 사용자 [pathurs](https://github.com/pathurs)의 [pull request](https://github.com/microsoft/TypeScript/pull/32264) 덕분에, TypeScript 3.9는 이와 관련하여 ECMAScript와 더 밀접하게 호환됩니다.
+
+### `any`로 확장된 타입 매개변수는 더 이상 `any` 처럼 행동하지 않음 (Type Parameters That Extend `any` No Longer Act as `any`)
+
+이전 버전의 TypeScript에서 `any`로 제한된 타입 매개변수는 `any`로 다룰 수 있었습니다.
+
+```ts
+function foo<T extends any>(arg: T) {
+    arg.spfjgerijghoied; // 오류가 아님!
+}
+```
+
+이는 실수였습니다, 그래서 TypeScript 3.9에서는 더 보수적인 접근을 취하고 이런 의심스러운 작업에 대해 오류를 발생시킵니다.
+
+```ts
+function foo<T extends any>(arg: T) {
+    arg.spfjgerijghoied;
+    //  ~~~~~~~~~~~~~~~
+    // 'spfjgerijghoied' 프로퍼티는 'T' 타입에 존재하지 않습니다.
+}
+```
+
+### `export *`은 항상 유지됩니다 (`export *` is Always Retained)
+
+이전 TypeScript 버전에서 `export * from "foo"` 같은 선언은 `foo`가 어떠한 값도 export 하지 않으면 JavaScript 출력에서 제외되었습니다.
+이런 내보내기는 타입-지향적이고 바벨에서 에뮬레이트 될 수 없기 때문에 문제가 됩니다.
+TypeScrip 3.9는 이런 `export *` 선언을 항상 내보냅니다.
+실제로 이 변화가 기존 코드를 깨뜨릴 것이라고 생각하지 않습니다.
+
+### 더 많은 libdom.d.ts 개선 (More libdom.d.ts refinements)
+
+Web IDL 파일에서 바로 TypeScript의 내장 .d.ts. 라이브러리 (lib.d.ts 및 제품군)가 생성될 수 있도록 DOM 규격의 TypeScript의 내장 .d.ts. 라이브러리를 옮기는 작업을 계속 진행하고 있습니다.
+그 결과 미디어 액세스와 관련된 일부 벤더별 타입이 제거되었습니다.
+
+프로젝트의 ambient *.d.ts 파일에 이 파일을 추가하면 다시 복구할 수 있습니다:
+
+```ts
+interface HTMLVideoElement {
+  msFrameStep(forward: boolean): void;
+  msInsertVideoEffect(activatableClassId: string, effectRequired: boolean, config?: any): void;
+  msSetVideoRectangle(left: number, top: number, right: number, bottom: number): void;
+  webkitEnterFullScreen(): void;
+  webkitEnterFullscreen(): void;
+  webkitExitFullScreen(): void;
+  webkitExitFullscreen(): void;
+
+  msHorizontalMirror: boolean;
+  readonly msIsLayoutOptimalForPlayback: boolean;
+  readonly msIsStereo3D: boolean;
+  msStereo3DPackingMode: string;
+  msStereo3DRenderMode: string;
+  msZoom: boolean;
+  onMSVideoFormatChanged: ((this: HTMLVideoElement, ev: Event) => any) | null;
+  onMSVideoFrameStepCompleted: ((this: HTMLVideoElement, ev: Event) => any) | null;
+  onMSVideoOptimalLayoutChanged: ((this: HTMLVideoElement, ev: Event) => any) | null;
+  webkitDisplayingFullscreen: boolean;
+  webkitSupportsFullscreen: boolean;
+}
+
+interface MediaError {
+  readonly msExtendedCode: number;
+  readonly MS_MEDIA_ERR_ENCRYPTED: number;
+}
+```
diff --git a/docs/documentation/ko/release-notes/TypeScript 4.0.md b/docs/documentation/ko/release-notes/TypeScript 4.0.md
new file mode 100644
index 00000000..b1ef23cb
--- /dev/null
+++ b/docs/documentation/ko/release-notes/TypeScript 4.0.md	
@@ -0,0 +1,739 @@
+---
+title: TypeScript 4.0
+layout: docs
+permalink: /ko/docs/handbook/release-notes/typescript-4-0.html
+oneline: TypeScript 4.0 Release Notes
+---
+
+## 가변 인자 튜플 타입 (Variadic Tuple Types)
+
+배열이나 튜플 타입 두 개를 결합하여 새로운 배열을 만드는 JavaScript의 `concat` 함수에 대해서 생각해봅시다.
+
+```js
+function concat(arr1, arr2) {
+  return [...arr1, ...arr2];
+}
+```
+
+그리고, 배열이나 튜플을 변수로 입력받아 첫 번째 원소를 제외한 나머지를 반환하는 `tail` 함수에 대해서도 생각해봅시다.
+
+```js
+function tail(arg) {
+  const [_, ...result] = arg;
+  return result;
+}
+```
+
+TypeScript에서는 이 두 함수의 타입을 어떻게 정의할 수 있을까요?
+
+`concat`의 경우, 이전 버전에서는 여러 개의 오버로드를 작성하는 방법이 유일했습니다.
+
+```ts
+function concat(arr1: [], arr2: []): [];
+function concat<A>(arr1: [A], arr2: []): [A];
+function concat<A, B>(arr1: [A, B], arr2: []): [A, B];
+function concat<A, B, C>(arr1: [A, B, C], arr2: []): [A, B, C];
+function concat<A, B, C, D>(arr1: [A, B, C, D], arr2: []): [A, B, C, D];
+function concat<A, B, C, D, E>(arr1: [A, B, C, D, E], arr2: []): [A, B, C, D, E];
+function concat<A, B, C, D, E, F>(arr1: [A, B, C, D, E, F], arr2: []): [A, B, C, D, E, F];)
+```
+
+음... 네, 이 오버로드들의 두 번째 배열은 전부 비어있습니다.
+이때, `arr2`가 하나의 인자를 가지고 있는 경우를 추가해봅시다.
+
+<!-- prettier-ignore -->
+```ts
+function concat<A2>(arr1: [], arr2: [A2]): [A2];
+function concat<A1, A2>(arr1: [A1], arr2: [A2]): [A1, A2];
+function concat<A1, B1, A2>(arr1: [A1, B1], arr2: [A2]): [A1, B1, A2];
+function concat<A1, B1, C1, A2>(arr1: [A1, B1, C1], arr2: [A2]): [A1, B1, C1, A2];
+function concat<A1, B1, C1, D1, A2>(arr1: [A1, B1, C1, D1], arr2: [A2]): [A1, B1, C1, D1, A2];
+function concat<A1, B1, C1, D1, E1, A2>(arr1: [A1, B1, C1, D1, E1], arr2: [A2]): [A1, B1, C1, D1, E1, A2];
+function concat<A1, B1, C1, D1, E1, F1, A2>(arr1: [A1, B1, C1, D1, E1, F1], arr2: [A2]): [A1, B1, C1, D1, E1, F1, A2];
+```
+
+이런 오버로딩 함수들은 분명 비합리적입니다.
+안타깝게도, `tail` 함수를 타이핑할 때도 이와 비슷한 문제에 직면하게 됩니다.
+
+이것은 "천 개의 오버로드로 인한 죽음(death by a thousand overloads)"의 하나의 경우이며, 심지어 대부분 문제를 해결하지도 못합니다.
+우리가 작성하고자 하는 만큼의 오버로드에 한해서만 올바른 타입을 제공합니다.
+포괄적인 케이스를 만들고 싶다면, 다음과 같은 오버로드가 필요합니다.
+
+```ts
+function concat<T, U>(arr1: T[], arr2: U[]): Array<T | U>;
+```
+
+그러나 위 시그니처는 튜플을 사용할 때 입력 길이나 요소 순서에 대한 어떤 것도 처리하지 않습니다.
+
+TypeScript 4.0은 타입 추론 개선을 포함한 두 가지 핵심적인 변화를 도입해 이러한 타이핑을 가능하도록 만들었습니다.
+
+첫 번째 변화는 튜플 타입 구문의 스프레드 연산자에서 제네릭 타입을 사용할 수 있다는 점입니다.
+우리가 작동하는 실제 타입을 모르더라도 튜플과 배열에 대한 고차함수를 표현할 수 있다는 뜻입니다.
+이러한 튜플 타입에서 제네릭 스프레드 연산자가 인스턴스화(혹은, 실제 타입으로 대체)되면 또 다른 배열이나 튜플 타입 세트를 생산할 수 있습니다.
+
+예를 들어, `tail` 같은 함수를 "천 개의 오버로드로 인한 죽음(death by a thousand overloads)"이슈 없이 타이핑 할 수 있게 됩니다.
+
+```ts
+function tail<T extends any[]>(arr: readonly [any, ...T]) {
+  const [_ignored, ...rest] = arr;
+  return rest;
+}
+
+const myTuple = [1, 2, 3, 4] as const;
+const myArray = ["hello", "world"];
+
+const r1 = tail(myTuple);
+//    ^ = const r1: [2, 3, 4]
+
+const r2 = tail([...myTuple, ...myArray] as const);
+//    ^ = const r2: [2, 3, 4, ...string[]]
+```
+
+두 번째 변화는 나머지 요소가 끝뿐만 아니라 튜플의 어느 곳에서도 발생할 수 있다는 것입니다.
+
+```ts
+type Strings = [string, string];
+type Numbers = [number, number];
+
+type StrStrNumNumBool = [...Strings, ...Numbers, boolean];
+//   ^ = type StrStrNumNumBool = [string, string, number, number, boolean]
+```
+
+이전에는, TypeScript는 다음과 같은 오류를 생성했었습니다:
+
+```
+A rest element must be last in a tuple type.
+```
+
+TypeScript 4.0에서는 이러한 제한이 완화되었습니다.
+
+길이가 정해지지 않은 타입을 확장하려고할 때, 결과의 타입은 제한되지 않으며, 다음 모든 요소가 결과의 나머지 요소 타입에 포함되는 점에 유의하시기 바랍니다.
+
+```ts
+type Strings = [string, string];
+type Numbers = number[];
+
+type Unbounded = [...Strings, ...Numbers, boolean];
+//   ^ = type Unbounded = [string, string, ...(number | boolean)[]]
+```
+
+이 두 가지 동작을 함께 결합하여, `concat`에 대해 타입이 제대로 정의된 시그니처를 작성할 수 있습니다.
+
+```ts
+type Arr = readonly any[];
+
+function concat<T extends Arr, U extends Arr>(arr1: T, arr2: U): [...T, ...U] {
+  return [...arr1, ...arr2];
+}
+```
+
+하나의 시그니처가 조금 길더라도, 반복할 필요가 없는 하나의 시그니처일 뿐이며, 모든 배열과 튜플에서 예측 가능한 행동을 제공합니다.
+
+이 기능은 그 자체만으로도 훌륭하지만, 조금 더 정교한 시나리오에서도 빛을 발합니다.
+예를 들어,[함수의 매개변수를 부분적으로 적용하여 새로운 함수를 반환하는](https://en.wikipedia.org/wiki/Partial_application) `partialCall` 함수가 있다고 생각해봅시다.
+`partialCall`은 다음과 같은 함수를 가집니다. - `f`가 예상하는 몇 가지 인수와 함께 `f`라고 지정하겠습니다.
+그 후, `f`가 여전히 필요로 하는 다른 인수를 가지고, 그것을 받을 때 `f`를 호출하는 새로운 함수를 반환합니다.
+
+```js
+function partialCall(f, ...headArgs) {
+  return (...tailArgs) => f(...headArgs, ...tailArgs);
+}
+```
+
+TypeScript 4.0은 나머지 파라미터들과 튜플 원소들에 대한 추론 프로세스를 개선하여 타입을 지정할 수 있고 "그냥 동작"하도록 할 수 있습니다.
+
+```ts
+type Arr = readonly unknown[];
+
+function partialCall<T extends Arr, U extends Arr, R>(
+  f: (...args: [...T, ...U]) => R,
+  ...headArgs: T
+) {
+  return (...tailArgs: U) => f(...headArgs, ...tailArgs);
+}
+```
+
+이 경우, `partialCall`은 처음에 취할 수 있는 파라미터와 할 수 없는 파라미터를 파악하고, 남은 것들은 적절히 수용하고 거부하는 함수들을 반환합니다.
+
+```ts
+// @errors: 2345 2554 2554 2345
+type Arr = readonly unknown[];
+
+function partialCall<T extends Arr, U extends Arr, R>(
+  f: (...args: [...T, ...U]) => R,
+  ...headArgs: T
+) {
+  return (...tailArgs: U) => f(...headArgs, ...tailArgs);
+}
+// ---cut---
+const foo = (x: string, y: number, z: boolean) => {};
+
+const f1 = partialCall(foo, 100);
+
+const f2 = partialCall(foo, "hello", 100, true, "oops");
+
+// 작동합니다!
+const f3 = partialCall(foo, "hello");
+//    ^ = const f3: (y: number, z: boolean) => void
+
+// f3으로 뭘 할 수 있을까요?
+
+// 작동합니다!
+f3(123, true);
+
+f3();
+
+f3(123, "hello");
+```
+
+가변 인자 튜플 타입은 특히 기능 구성과 관련하여 많은 새로운 흥미로운 패턴을 가능하게 합니다.
+우리는 JavaScript에 내장된 `bind` 메서드의 타입 체킹을 더 잘하기 위해 이를 활용할 수 있을 것이라고 기대합니다.
+몇 가지 다른 추론 개선 및 패턴들도 여기에 포함되어 있으며, 가변 인자 튜플에 대해 더 알아보고 싶다면, [the pull request](https://github.com/microsoft/TypeScript/pull/39094)를 참고해보세요.
+
+## 라벨링된 튜플 요소 (Labeled Tuple Elements)
+
+튜플 타입과 매개 변수 목록에 대해 개선하는 것은 일반적인 JavaScript 관용구에 대한 타입 유효성 검사를 강화시켜주기 때문에 중요합니다 - 실제로 인수 목록을 자르고 다른 함수로 전달만 해주면 됩니다.
+나머지 매개 변수(rest parameter)에 튜플 타입을 사용할 수 있다는 생각은 아주 중요합니다.
+
+예를 들어, 튜플 타입을 나머지 매개 변수로 사용하는 다음 함수는...
+
+```ts
+function foo(...args: [string, number]): void {
+  // ...
+}
+```
+
+...다음 함수와 다르지 않아야 합니다...
+
+```ts
+function foo(arg0: string, arg1: number): void {
+  // ...
+}
+```
+
+...`foo`의 모든 호출자에 대해서도.
+
+```ts
+// @errors: 2554
+function foo(arg0: string, arg1: number): void {
+  // ...
+}
+// ---cut---
+foo("hello", 42);
+
+foo("hello", 42, true);
+foo("hello");
+```
+
+그러나 차이점이 보이기 시작한 부분은: 가독성입니다.
+첫 번째 예시에서는, 첫 번째와 두 번째 요소에 대한 매개 변수 이름이 없습니다.
+타입-검사에는 전혀 영향이 없지만, 튜플 위치에 라벨이 없는 것은 사용하기 어렵게 만듭니다 - 의도를 전달하기 어렵습니다.
+
+TypeScript 4.0에서 튜플 타입에 라벨을 제공하는 이유입니다.
+
+```ts
+type Range = [start: number, end: number];
+```
+
+매개 변수 목록과 튜플 타입 사이의 연결을 강화하기 위해, 나머지 요소와 선택적 요소에 대한 구문이 매개 변수 목록의 구문을 반영합니다.
+
+```ts
+type Foo = [first: number, second?: string, ...rest: any[]];
+```
+
+라벨링 된 튜플을 사용할 때는 몇 가지 규칙이 있습니다.
+하나는 튜플 요소를 라벨링 할 때, 튜플에 있는 다른 모든 요소들 역시 라벨링 되어야 합니다.
+
+```ts
+// @errors: 5084
+type Bar = [first: string, number];
+```
+
+당연하게도 - 라벨은 구조 분해할 때 변수 이름을 다르게 지정할 필요가 없습니다.
+이것은 순전히 문서화와 도구를 위해 필요합니다.
+
+```ts
+function foo(x: [first: string, second: number]) {
+    // ...
+
+    // 주의: 'first'와 'second'에 대해 이름 지을 필요 없음
+    const [a, b] = x;
+    a
+//  ^ = const a: string
+    b
+//  ^ = const b: number
+}
+```
+
+전반적으로, 라벨링 된 튜플은 안전한 타입 방식으로 오버로드를 구현하는 것과 튜플과 인수 목록의 패턴을 활용할 때 편리합니다.
+사실, TypeScript 에디터 지원은 가능한 경우 오버로드로 표시하려 합니다.
+
+![라벨링된 튜플의 유니언을 매개변수 목록에서처럼 두 가지 시그니처로 보여주는 시그니처 도움말](https://devblogs.microsoft.com/typescript/wp-content/uploads/sites/11/2020/08/signatureHelpLabeledTuples.gif)
+
+더 알고 싶으시면, 라벨링된 튜플 요소에 대한 [풀 리퀘스트](https://github.com/microsoft/TypeScript/pull/38234)를 확인해보세요
+
+## 생성자로부터 클래스 프로퍼티 타입 추론하기 (Class Property Inference from Constructors)
+
+TypeScript 4.0에서는 `noImplicitAny`가 활성화되었을 때 클래스 내의 프로퍼티 타입을 결정하기 위해 제어 흐름 분석을 사용할 수 있습니다.  
+
+<!--prettier-ignore -->
+```ts
+class Square {
+  // 이전에 any로 추론했습니다.
+  area;
+// ^?
+  sideLength;
+// ^?
+  constructor(sideLength: number) {
+    this.sideLength = sideLength;
+    this.area = sideLength ** 2;
+  }
+}
+```
+
+생성자의 모든 경로가 인스턴스 멤버에 할당한 것이 아닐 경우, 프로퍼티는 잠재적으로 `undefined`가 됩니다.
+
+<!--prettier-ignore -->
+```ts
+// @errors: 2532
+class Square {
+  sideLength;
+// ^?
+
+  constructor(sideLength: number) {
+    if (Math.random()) {
+      this.sideLength = sideLength;
+    }
+  }
+
+  get area() {
+    return this.sideLength ** 2;
+  }
+}
+```
+
+더 많은 내용이 있는 경우(e.g. `initialize` 메서드 등이 있는 경우), `strictPropertyInitialization` 모드에서는 확정적 할당 단언(`!`)에 따라 명시적으로 타입을 선언해야 합니다.
+
+```ts
+class Square {
+  // 확정적 할당 단언
+  //        v
+  sideLength!: number;
+  //         ^^^^^^^^
+  // 타입 표기
+
+  constructor(sideLength: number) {
+    this.initialize(sideLength);
+  }
+
+  initialize(sideLength: number) {
+    this.sideLength = sideLength;
+  }
+
+  get area() {
+    return this.sideLength ** 2;
+  }
+}
+```
+
+더 자세히 알고 싶다면, [코드를 실행하는 Pull Request를 보세요](https://github.com/microsoft/TypeScript/pull/379200).
+
+## 단축 할당 연산자 (Short-Circuiting Assignment Operators)
+
+JavaScript와 많은 언어는 _복합 할당 (compound assignment)_ 연산자라고 불리는 연산자 집합을 지원합니다.
+복합 할당 연산자는 두 개의 인수에 연산자를 적용한 다음 결과를 왼쪽에 할당합니다.
+이전에 아래와 같은 것을 본 적이 있을 것입니다:
+
+```ts
+// 덧셈
+// a = a + b
+a += b;
+
+// 뺄셈
+// a = a - b
+a -= b;
+
+// 곱셈
+// a = a * b
+a *= b;
+
+// 나눗셈
+// a = a / b
+a /= b;
+
+// 지수화
+// a = a ** b
+a **= b;
+
+// 왼쪽 비트 시프트
+// a = a << b
+a <<= b;
+```
+
+JavaScript의 많은 연산자에 위와 같은 할당 연산자가 있습니다!
+그러나 최근까지도 논리 _and_ 연산자 (`&&`), 논리 _or_ 연산자 (`||`) 및 null과 같은 것을 병합하는 연산자 (nullish coalescing) (`??`)의 세 가지 주목할만한 예외가 있었습니다.
+
+이것이 TypeScript 4.0이 새로운 할당 연산자`&&=`,`||=`및`??=`를 추가하는 새로운 ECMAScript 기능을 지원하는 이유입니다.
+
+이러한 연산자는 사용자가 다음과 같은 코드를 작성할 수 있는 모든 예를 대체하는 데 유용합니다.
+
+```ts
+a = a && b;
+a = a || b;
+a = a ?? b;
+```
+
+혹은 아래와 비슷한 `if` 블록
+
+```ts
+// 'a ||= b'로 대체 가능
+if (!a) {
+  a = b;
+}
+```
+
+우리가 본(혹은 직접 작성한) 코드 패턴 중 필요한 경우에만 값을 지연 초기화시키기 위한 패턴도 있습니다.
+
+```ts
+let values: string[];
+(values ?? (values = [])).push("hello");
+
+// 이후
+(values ??= []).push("hello");
+```
+
+(보세요, 우리가 작성한 _모든_ 코드가 자랑스러운 것은 아닙니다...)
+
+드물지만 부수 효과(side-effects)가 있는 getter 또는 setter를 사용하는 경우 이러한 연산자가 필요한 경우에만 할당을 수행한다는 점에 유의할 필요가 있습니다.
+그런 의미에서 연산자의 오른쪽이 "단축 (short-circuited)"될 뿐만 아니라 할당 자체도 마찬가지입니다.
+
+```ts
+obj.prop ||= foo();
+
+// 다음 중 하나와 대략 동일함
+
+obj.prop || (obj.prop = foo());
+
+if (!obj.prop) {
+    obj.prop = foo();
+}
+```
+
+[다음 예시를 실행해보세요](https://www.typescriptlang.org/play?ts=Nightly#code/MYewdgzgLgBCBGArGBeGBvAsAKBnmA5gKawAOATiKQBQCUGO+TMokIANkQHTsgHUAiYlChFyMABYBDCDHIBXMANoBuHI2Z4A9FpgAlIqXZTgRGAFsiAQg2byJeeTAwAslKgSu5KWAAmIczoYAB4YAAYuAFY1XHwAXwAaWxgIEhgKKmoAfQA3KXYALhh4EA4iH3osWM1WCDKePkFUkTFJGTlFZRimOJw4mJwAM0VgKABLcBhB0qCqplr63n4BcjGCCVgIMd8zIjz2eXciXy7k+yhHZygFIhje7BwFzgblgBUJMdlwM3yAdykAJ6yBSQGAeMzNUTkU7YBCILgZUioOBIBGUJEAHwxUxmqnU2Ce3CWgnenzgYDMACo6pZxpYIJSOqDwSkSFCYXC0VQYFi0NMQHQVEA) 예시를 통해 _항상_ 할당을 수행하는 것과 어떻게 다른지 확인해보세요.
+
+```ts
+const obj = {
+    get prop() {
+        console.log("getter has run");
+
+        // 이곳을 바꿔보세요!
+        return Math.random() < 0.5;
+    },
+    set prop(_val: boolean) {
+        console.log("setter has run");
+    }
+};
+
+function foo() {
+    console.log("right side evaluated");
+    return true;
+}
+
+console.log("This one always runs the setter");
+obj.prop = obj.prop || foo();
+
+console.log("This one *sometimes* runs the setter");
+obj.prop ||= foo();
+```
+
+기여해주신 커뮤니티 멤버 [Wenlu Wang](https://github.com/Kingwl) 님에게 큰 감사를 표합니다.
+
+더 자세한 내용을 보고 싶으시다면 [이 풀 리퀘스트를 확인해보세요](https://github.com/microsoft/TypeScript/pull/37727).
+[TC39 제안 저장소에서도 이 기능을 확인할 수 있습니다.](https://github.com/tc39/proposal-logical-assignment/).
+
+## `unknown` on `catch` Clause Bindings
+
+Since the beginning days of TypeScript, `catch` clause variables have always been typed as `any`.
+This meant that TypeScript allowed you to do anything you wanted with them.
+
+```ts
+try {
+  // Do some work
+} catch (x) {
+  // x has type 'any' - have fun!
+  console.log(x.message);
+  console.log(x.toUpperCase());
+  x++;
+  x.yadda.yadda.yadda();
+}
+```
+
+The above has some undesirable behavior if we're trying to prevent _more_ errors from happening in our error-handling code!
+Because these variables have the type `any` by default, they lack any type-safety which could have errored on invalid operations.
+
+That's why TypeScript 4.0 now lets you specify the type of `catch` clause variables as `unknown` instead.
+`unknown` is safer than `any` because it reminds us that we need to perform some sorts of type-checks before operating on our values.
+
+<!--prettier-ignore -->
+```ts
+// @errors: 2571
+try {
+  // ...
+} catch (e: unknown) {
+  // Can't access values on unknowns
+  console.log(e.toUpperCase());
+
+  if (typeof e === "string") {
+    // We've narrowed 'e' down to the type 'string'.
+    console.log(e.toUpperCase());
+  }
+}
+```
+
+While the types of `catch` variables won't change by default, we might consider a new `--strict` mode flag in the future so that users can opt in to this behavior.
+In the meantime, it should be possible to write a lint rule to force `catch` variables to have an explicit annotation of either `: any` or `: unknown`.
+
+For more details you can [peek at the changes for this feature](https://github.com/microsoft/TypeScript/pull/39015).
+
+## Custom JSX Factories
+
+When using JSX, a [_fragment_](https://reactjs.org/docs/fragments.html) is a type of JSX element that allows us to return multiple child elements.
+When we first implemented fragments in TypeScript, we didn't have a great idea about how other libraries would utilize them.
+Nowadays most other libraries that encourage using JSX and support fragments have a similar API shape.
+
+In TypeScript 4.0, users can customize the fragment factory through the new `jsxFragmentFactory` option.
+
+As an example, the following `tsconfig.json` file tells TypeScript to transform JSX in a way compatible with React, but switches each factory invocation to `h` instead of `React.createElement`, and uses `Fragment` instead of `React.Fragment`.
+
+```json5
+{
+  compilerOptions: {
+    target: "esnext",
+    module: "commonjs",
+    jsx: "react",
+    jsxFactory: "h",
+    jsxFragmentFactory: "Fragment",
+  },
+}
+```
+
+In cases where you need to have a different JSX factory on a per-file basis<!-- (maybe you like to ship React, Preact, and Inferno to give a blazing fast experience) -->, you can take advantage of the new `/** @jsxFrag */` pragma comment.
+For example, the following...
+
+```tsx
+// @noErrors
+// Note: these pragma comments need to be written
+// with a JSDoc-style multiline syntax to take effect.
+
+/** @jsx h */
+/** @jsxFrag Fragment */
+
+import { h, Fragment } from "preact";
+
+export const Header = (
+  <>
+    <h1>Welcome</h1>
+  </>
+);
+```
+
+...will get transformed to this output JavaScript...
+
+```tsx
+// @noErrors
+// @showEmit
+// Note: these pragma comments need to be written
+// with a JSDoc-style multiline syntax to take effect.
+
+/** @jsx h */
+/** @jsxFrag Fragment */
+
+import { h, Fragment } from "preact";
+
+export const Header = (
+  <>
+    <h1>Welcome</h1>
+  </>
+);
+```
+
+We'd like to extend a big thanks to community member [Noj Vek](https://github.com/nojvek) for sending this pull request and patiently working with our team on it.
+
+You can see that [the pull request](https://github.com/microsoft/TypeScript/pull/38720) for more details!
+
+## Speed Improvements in `build` mode with `--noEmitOnError`
+
+Previously, compiling a program after a previous compile with errors under `--incremental` would be extremely slow when using the `--noEmitOnError` flag.
+This is because none of the information from the last compilation would be cached in a `.tsbuildinfo` file based on the `--noEmitOnError` flag.
+
+TypeScript 4.0 changes this which gives a great speed boost in these scenarios, and in turn improves `--build` mode scenarios (which imply both `--incremental` and `--noEmitOnError`).
+
+For details, [read up more on the pull request](https://github.com/microsoft/TypeScript/pull/38853).
+
+## `--incremental` with `--noEmit`
+
+TypeScript 4.0 allows us to use the `--noEmit` flag when while still leveraging `--incremental` compiles.
+This was previously not allowed, as `--incremental` needs to emit a `.tsbuildinfo` files; however, the use-case to enable faster incremental builds is important enough to enable for all users.
+
+For more details, you can [see the implementing pull request](https://github.com/microsoft/TypeScript/pull/39122).
+
+## Editor Improvements
+
+The TypeScript compiler doesn't only power the editing experience for TypeScript itself in most major editors - it also powers the JavaScript experience in the Visual Studio family of editors and more.
+For that reason, much of our work focuses on improving editor scenarios - the place you spend most of your time as a developer.
+
+Using new TypeScript/JavaScript functionality in your editor will differ depending on your editor, but
+
+* Visual Studio Code supports [selecting different versions of TypeScript](https://code.visualstudio.com/docs/typescript/typescript-compiling#_using-the-workspace-version-of-typescript). Alternatively, there's the [JavaScript/TypeScript Nightly Extension](https://marketplace.visualstudio.com/items?itemName=ms-vscode.vscode-typescript-next) to stay on the bleeding edge (which is typically very stable).
+* Visual Studio 2017/2019 have [the SDK installers above] and [MSBuild installs](https://www.nuget.org/packages/Microsoft.TypeScript.MSBuild).
+* Sublime Text 3 supports [selecting different versions of TypeScript](https://github.com/microsoft/TypeScript-Sublime-Plugin#note-using-different-versions-of-typescript)
+
+You can check out a partial [list of editors that have support for TypeScript](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Editor-Support) to learn more about whether your favorite editor has support to use new versions.
+
+### Convert to Optional Chaining
+
+Optional chaining is a recent feature that's received a lot of love.
+That's why TypeScript 4.0 brings a new refactoring to convert common patterns to take advantage of [optional chaining](https://devblogs.microsoft.com/typescript/announcing-typescript-3-7/#optional-chaining) and [nullish coalescing](https://devblogs.microsoft.com/typescript/announcing-typescript-3-7/#nullish-coalescing)!
+
+![Converting `a && a.b.c && a.b.c.d.e.f()` to `a?.b.c?.d.e.f.()`](https://devblogs.microsoft.com/typescript/wp-content/uploads/sites/11/2020/08/convertToOptionalChain-4-0.gif)
+
+Keep in mind that while this refactoring doesn't _perfectly_ capture the same behavior due to subtleties with truthiness/falsiness in JavaScript, we believe it should capture the intent for most use-cases, especially when TypeScript has more precise knowledge of your types.
+
+For more details, [check out the pull request for this feature](https://github.com/microsoft/TypeScript/pull/39135).
+
+### `/** @deprecated */` Support
+
+TypeScript's editing support now recognizes when a declaration has been marked with a `/** @deprecated *` JSDoc comment.
+That information is surfaced in completion lists and as a suggestion diagnostic that editors can handle specially.
+In an editor like VS Code, deprecated values are typically displayed a strike-though style ~~like this~~.
+
+![Some examples of deprecated declarations with strikethrough text in the editor](https://devblogs.microsoft.com/typescript/wp-content/uploads/sites/11/2020/06/deprecated_4-0.png)
+
+This new functionality is available thanks to [Wenlu Wang](https://github.com/Kingwl).
+See [the pull request](https://github.com/microsoft/TypeScript/pull/38523) for more details.
+
+### Partial Semantic Mode at Startup
+
+We've heard a lot from users suffering from long startup times, especially on bigger projects.
+The culprit is usually a process called _program construction_.
+This is the process of starting with an initial set of root files, parsing them, finding their dependencies, parsing those dependencies, finding those dependencies' dependencies, and so on.
+The bigger your project is, the longer you'll have to wait before you can get basic editor operations like go-to-definition or quick info.
+
+That's why we've been working on a new mode for editors to provide a _partial_ experience until the full language service experience has loaded up.
+The core idea is that editors can run a lightweight partial server that only looks at the current files that the editor has open.
+
+It's hard to say precisely what sorts of improvements you'll see, but anecdotally, it used to take anywhere between _20 seconds to a minute_ before TypeScript would become fully responsive on the Visual Studio Code codebase.
+In contrast, **our new partial semantic mode seems to bring that delay down to just a few seconds**.
+As an example, in the following video, you can see two side-by-side editors with TypeScript 3.9 running on the left and TypeScript 4.0 running on the right.
+
+<video loop autoplay muted style="width:100%;height:100%;" src="https://devblogs.microsoft.com/typescript/wp-content/uploads/sites/11/2020/08/partialModeFast.mp4">
+</video>
+
+When restarting both editors on a particularly large codebase, the one with TypeScript 3.9 can't provide completions or quick info at all.
+On the other hand, the editor with TypeScript 4.0 can _immediately_ give us a rich experience in the current file we're editing, despite loading the full project in the background.
+
+Currently the only editor that supports this mode is [Visual Studio Code](http://code.visualstudio.com/) which has some UX improvements coming up in [Visual Studio Code Insiders](http://code.visualstudio.com/insiders).
+We recognize that this experience may still have room for polish in UX and functionality, and we have [a list of improvements](https://github.com/microsoft/TypeScript/issues/39035) in mind.
+We're looking for more feedback on what you think might be useful.
+
+For more information, you can [see the original proposal](https://github.com/microsoft/TypeScript/issues/37713), [the implementing pull request](https://github.com/microsoft/TypeScript/pull/38561), along with [the follow-up meta issue](https://github.com/microsoft/TypeScript/issues/39035).
+
+### Smarter Auto-Imports
+
+Auto-import is a fantastic feature that makes coding a lot easier; however, every time auto-import doesn't seem to work, it can throw users off a lot.
+One specific issue that we heard from users was that auto-imports didn't work on dependencies that were written in TypeScript - that is, until they wrote at least one explicit import somewhere else in their project.
+
+Why would auto-imports work for `@types` packages, but not for packages that ship their own types?
+It turns out that auto-imports only work on packages your project _already_ includes.
+Because TypeScript has some quirky defaults that automatically add packages in `node_modules/@types` to your project, _those_ packages would be auto-imported.
+On the other hand, other packages were excluded because crawling through all your `node_modules` packages can be _really_ expensive.
+
+All of this leads to a pretty lousy getting started experience for when you're trying to auto-import something that you've just installed but haven't used yet.
+
+TypeScript 4.0 now does a little extra work in editor scenarios to include the packages you've listed in your `package.json`'s `dependencies` (and `peerDependencies`) fields.
+The information from these packages is only used to improve auto-imports, and doesn't change anything else like type-checking.
+This allows us to provide auto-imports for all of your dependencies that have types, without incurring the cost of a complete `node_modules` search.
+
+In the rare cases when your `package.json` lists more than ten typed dependencies that haven't been imported yet, this feature automatically disables itself to prevent slow project loading.
+To force the feature to work, or to disable it entirely, you should be able to configure your editor.
+For Visual Studio Code, this is the "Include Package JSON Auto Imports" (or `typescript.preferences.includePackageJsonAutoImports`) setting.
+
+![Configuring 'include package JSON auto imports'](https://devblogs.microsoft.com/typescript/wp-content/uploads/sites/11/2020/08/configurePackageJsonAutoImports4-0.png)
+For more details, you can see the [proposal issue](https://github.com/microsoft/TypeScript/issues/37812) along with [the implementing pull request](https://github.com/microsoft/TypeScript/pull/38923).
+
+## Our New Website
+
+[The TypeScript website](https://www.typescriptlang.org/) has recently been rewritten from the ground up and rolled out!
+
+![A screenshot of the new TypeScript website](https://devblogs.microsoft.com/typescript/wp-content/uploads/sites/11/2020/08/ts-web.png)
+
+[We already wrote a bit about our new site](https://devblogs.microsoft.com/typescript/announcing-the-new-typescript-website/), so you can read up more there; but it's worth mentioning that we're still looking to hear what you think!
+If you have questions, comments, or suggestions, you can [file them over on the website's issue tracker](https://github.com/microsoft/TypeScript-Website).
+
+## Breaking Changes
+
+### `lib.d.ts` Changes
+
+Our `lib.d.ts` declarations have changed - most specifically, types for the DOM have changed.
+The most notable change may be the removal of [`document.origin`](https://developer.mozilla.org/en-US/docs/Web/API/Document/origin) which only worked in old versions of IE and Safari
+MDN recommends moving to [`self.origin`](https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/origin).
+
+### Properties Overriding Accessors (and vice versa) is an Error
+
+Previously, it was only an error for properties to override accessors, or accessors to override properties, when using `useDefineForClassFields`; however, TypeScript now always issues an error when declaring a property in a derived class that would override a getter or setter in the base class.
+
+```ts
+// @errors: 1049 2610
+class Base {
+  get foo() {
+    return 100;
+  }
+  set foo(value) {
+    // ...
+  }
+}
+
+class Derived extends Base {
+  foo = 10;
+}
+```
+
+```ts
+// @errors: 2611
+class Base {
+  prop = 10;
+}
+
+class Derived extends Base {
+  get prop() {
+    return 100;
+  }
+}
+```
+
+See more details on [the implementing pull request](https://github.com/microsoft/TypeScript/pull/37894).
+
+### Operands for `delete` must be optional
+
+When using the `delete` operator in `strictNullChecks`, the operand must now be `any`, `unknown`, `never`, or be optional (in that it contains `undefined` in the type).
+Otherwise, use of the `delete` operator is an error.
+
+```ts
+// @errors: 2790
+interface Thing {
+  prop: string;
+}
+
+function f(x: Thing) {
+  delete x.prop;
+}
+```
+
+See more details on [the implementing pull request](https://github.com/microsoft/TypeScript/pull/37921).
+
+### Usage of TypeScript's Node Factory is Deprecated
+
+Today TypeScript provides a set of "factory" functions for producing AST Nodes; however, TypeScript 4.0 provides a new node factory API.
+As a result, for TypeScript 4.0 we've made the decision to deprecate these older functions in favor of the new ones.
+
+For more details, [read up on the relevant pull request for this change](https://github.com/microsoft/TypeScript/pull/35282).