diff --git a/public/docs/ts/latest/cookbook/component-relative-paths.jade b/public/docs/ts/latest/cookbook/component-relative-paths.jade
index df9845c8..3c0d94e1 100644
--- a/public/docs/ts/latest/cookbook/component-relative-paths.jade
+++ b/public/docs/ts/latest/cookbook/component-relative-paths.jade
@@ -1,33 +1,56 @@
 include ../_util-fns
 
 :marked
+  ## *컴포넌트-상대* URL을 컴포넌트 템플릿과 스타일에 쓰기
+  
   ## Write *Component-Relative* URLs to component templates and style files
 
+  Angular에서는 컴포넌트들을 외부 템플릿이나 외부 스타일 파일을 참조하는 경우가 많습니다.
+  이러한 파일들은 `@Component` 메타데이터의 `templateUrl`과 `styleUrls` 속성안의 URL들로 식별합니다. 
+
   Our components often refer to external template and style files.
   We identify those files with a URL in the `templateUrl` and `styleUrls` properties of the `@Component` metadata
   as seen here:
   
 +makeExample('cb-component-relative-paths/ts/src/app/some.component.ts','absolute-config')(format='.')
 :marked
+  기본적으로 어플리케이션 루트까지의 전체 경로를 *표시해야만* 합니다.
+  이것은 어플리케이션 루트로부터 확실하게 위치를 표현할 수 있기 때문에 때문에 ***절대 경로***라고 부릅니다.
+  
   By default, we *must* specify the full path back to the application root.
   We call this an ***absolute path*** because it is *absolute* with respect to the application root.
 
+  *절대 경로*에는 두가지 문제점이 있습니다.
+
   There are two problems with an *absolute path*:
   
+  1. 어플리케이션 루트까지의 모든 경로를 기억해야만 합니다.
+  
   1. We have to remember the full path back to the application root.
   
+  1. 어플리케이션 파일 구조에서 컴포넌트를 이동할때 URL을 업데이트 해야 합니다.
+  
   1. We have to update the URL when we move the component around in the application files structure.
   
+  컴포넌트의 클래스 파일에 *상대적으로* 으로 템플릿과 스타일 위치들을 표시할 수 있다면 어플리케이션 컴포넌트들을 유지하고 작성하는 것이 더 쉬워지겠죠.
+  
   It would be much easier to write and maintain our application components if we could specify template and style locations
   *relative* to their component class file.
   
+  *그렇게 할 수 있습니다.*
+  
   *We can!*
   
 .alert.is-important
   :marked
+    어플리케이션을 `commonjs` 모듈 처럼 작성하고 `systemjs`나 `webpack`같은 적절한 패키지 로더로 적재한다면 위치를 상대적으로 명시하는 것이 가능합니다.
+  
     We can if we build our application as `commonjs` modules and load those modules
     with a suitable package loader such as `systemjs` or `webpack`.
     Learn why [below](#why-default).
+ 
+    Angular CLI는 이 기술을 사용하며 기본적으로 *컴포넌트 상대 경로* 접근법을 사용합니다.
+    CLI 사용자들은 이 장을 건너 뛰어도 되고 아니면 어떻게 동작하는지 이해하기 위해 읽으셔도 됩니다.
     
     The Angular CLI uses these technologies and defaults to the
     *component-relative path* approach described here.
@@ -36,13 +59,22 @@ include ../_util-fns
   
 .l-main-section
 :marked
+  ## _컴포넌트-상대_ 경로
+
   ## _Component-Relative_ Paths
   
+  템플릿 파일과 스타일 URL 을 컴포넌트 클래스 파일에 *상대적으로* 표시하는 것이 목적이기 때문에 ***컴포넌트-상대 경로***라는 이름이 붙었습니다.
+  
   Our goal is to specify template and style URLs *relative* to their component class files, 
   hence the term ***component-relative path***.
   
+  관련된 컴포넌트 파일들을 잘 알려진 위치에 두는 관습을 따르는 것이 성공의 비결입니다. 
+  
   The key to success is following a convention that puts related component files in well-known locations.
   
+  컴포넌트 템플릿과 컴포넌트의 특화된 스타일 파일들을 동반하는 컴포넌트 클래스 파일의 *자매*로 관리하는 것을 추천합니다.
+  아래의 예시를 보면 `SomeComponent`를 위한 세 파일이 `app` 폴더의 다음에 나란히 위치하고 있는 모습을 볼 수 있습니다.
+
   We recommend keeping component template and component-specific style files as *siblings* of their
   companion component class files. 
   Here we see the three files for `SomeComponent` sitting next to each other in the `app` folder. 
@@ -55,27 +87,47 @@ include ../_util-fns
       .file some.component.ts
     .file ...
 :marked
+  어플리케이션의 크기가 커지면 커질수록 파일들과 폴더들이 많아지고 디렉터리 구조가 더 깊어질 것 입니다.
+  그렇지만 분리할수 없는 자매들끼리 묶어서 컴포넌트 파일들을 이동하는 한 괜찮습니다.
+
   We'll have more files and folders — and greater folder depth — as our application grows.
   We'll be fine as long as the component files travel together as the inseparable siblings they are.
   
+  ### *moduleId* 설정하기
+  
   ### Set the *moduleId*
   
+  이러한 파일 구조 규칙을 적용하면, `@Component` 메타데이터의 `moduleId` 속성을 아래와 같이 적용하는 것으로
+  템플릿과 스타일 파일들의 위치를 컴포넌트 클래스 파일에 상대적으로 표현할 수 있습니다.
++makeExample('cb-component-relative-paths/ts/src/app/some.component.ts','module-id')(format='.')
+  
   Having adopted this file structure convention, we can specify locations of the template and style files
   relative to the component class file simply by setting the `moduleId` property of the `@Component` metadata like this
 +makeExample('cb-component-relative-paths/ts/src/app/some.component.ts','module-id')(format='.')
 :marked
+  `src/app` 기본 경로를 `templateUrl` 과 `styleUrls` 에서 제거하고 이를 `./`로 변경하세요.
+  그 결과는 아래와 같습니다.
++makeExample('cb-component-relative-paths/ts/src/app/some.component.ts','relative-config')(format='.')
+  
   We strip the `src/app/` base path from the `templateUrl` and `styleUrls` and replace it with `./`. 
   The result looks like this:
 +makeExample('cb-component-relative-paths/ts/src/app/some.component.ts','relative-config')(format='.')
 
 .alert.is-helpful
   :marked
+    Webpack 유저들은 [다른 접근법](#webpack) 을 선호할 수도 있습니다.
+    
     Webpack users may prefer [an alternative approach](#webpack).
     
 .l-main-section
 :marked
+  ## 소스
+  
   ## Source
   
+  **여기에서 <live-example name="cb-component-relative-paths"></live-example>**
+  를 보고 다운로드하거나 관련된 소스를 아래에서 확인하실 수 있습니다
+  
   **We can see the <live-example name="cb-component-relative-paths"></live-example>**
   and download the source code from there
   or simply read the pertinent source here.
@@ -90,39 +142,70 @@ include ../_util-fns
 a#why-default
 .l-main-section
 :marked
+  ## 부록 : *컴포넌트-상대* 가 기본 설정이 아닌 이유
+  
   ## Appendix: why *component-relative* is not the default
 
+  *컴포넌트-상대* 경로는 명백히 *절대*경로보다 뛰어납니다.
+  왜 Angular가 기본으로 *절대*경로를 사용할까요?
+  왜 `moduleId`를 `직접` 설정해야 할까요? 왜 Angular가 기본적으로 설정할 수 없나요?
+  
   A *component-relative* path is obviously superior to an *absolute* path.
   Why did Angular default to the *absolute* path?
   Why do *we* have to set the `moduleId`? Why can't Angular set it?
   
+  첫째로, 만일 우리가 `moduleId`를 생략하고 상대 경로를 사용할때 어떤 일이 일어나나 봅시다.
+  
   First, let's look at what happens if we use a relative path and omit the `moduleId`.
   
   `EXCEPTION: Failed to load some.component.html`
 
+  Angular는 파일을 찾지 못하고 에러를 발생시킵니다.
+
   Angular can't find the file so it throws an error.
   
+  왜 Angular는 템플릿과 스타일 URL을 컴포넌트 파일의 위치로부터 계산해내지 못할까요?
+  
   Why can't Angular calculate the template and style URLs from the component file's location? 
 
+  그 이유는 컴포넌트의 위치가 개발자의 도움 없이는 결정될 수 없기 때문입니다.
+  Angular 어플리케이션은 여러 방식으로 로드될 수 있습니다: 조금만 예시를 들어보면 단일 파일, SystemJS 패키지,
+  아니면 CommonJS 패키지 등을 통해서 로드될 수 있습니다.
+  여러 포맷들중 어떤 방식으로든 모듈을 만들 수도 있고, 아니면 모듈러한 코드를 아예 작성하지 않을 수도 있습니다.
+  
   Because the location of the component can't be determined without the developer's help.
   Angular apps can be loaded in many ways: from individual files, from SystemJS packages, or
   from CommonJS packages, to name a few. 
   We might generate modules in any of several formats. 
   We might not be writing modular code at all!
-  
+ 
+  이러한 패키징 및 모듈 로드 전략에 다양성때문에,
+  Angular 가 런타임시에 이러한 파일들이 어디에 위치하고 있는지 정확하게 알기란 불가능 합니다.
+ 
   With this diversity of packaging and module load strategies, 
   it's not possible for Angular to know with certainty where these files reside at runtime.
 
+  Angular가 오직 확실히 알 수 있는 위치는 `index.html` 홈페이지의 URL, 어플리케이션 루트 뿐입니다.
+  따라서 기본적으로 템플릿과 스타일 경로를 `index.html`에 상대적으로 계산합니다.
+  이것이 이전에 우리가 파일의 URL들을 `app/` 기본 경로 접두사를 붙여서 작성했던 이유입니다.
+
   The only location Angular can be sure of is the URL of the `index.html` home page, the application root.
   So by default it resolves template and style paths relative to the URL of `index.html`.
   That's why we previously wrote our file URLs with an `app/` base path prefix.
 
+  하지만 *만일* 권장되는 가이드라인을 따라서 `commonjs` 포맷에 맞게 모듈을 작성하고
+  *잘 동작*하는 모듈 로더를 사용한다면, 어플리케이션 개발자는 반절대적인 `module.id` 변수를 알 수 있고
+  이것이 컴포넌트 클래스 모듈 파일의 절대적인 위치를 포함하고 있을 것입니다. 
+
   But *if* we follow the recommended guidelines and we write modules in `commonjs` format
   and we use a module loader that *plays nice*,
   *then* we &mdash; the developers of the application &mdash;
   know that the semi-global `module.id` variable is available and contains
   the absolute URL of the component class module file.
   
+  그 정보가 Angular가 `moduleId`를 설정하지 않고도 *component*파일이 어디 있는지를 알게 해주는 정보입니다.
++makeExample('cb-component-relative-paths/ts/src/app/some.component.ts','module-id')(format='.')
+    
   That knowledge enables us to tell Angular where the *component* file is
   by setting the `moduleId`:
 +makeExample('cb-component-relative-paths/ts/src/app/some.component.ts','module-id')(format='.')
@@ -130,9 +213,19 @@ a#why-default
 a#webpack
 .l-main-section
 :marked
+  ## Webpack: 템플릿과 스타일들을 로드하기
+  
   ## Webpack: load templates and styles
+  
+  Webpack 개발자들에게는 `moduleId`의 대체 수단이 있습니다.
+  
   Webpack developers have an alternative to `moduleId`.
 
+  *component-relative URL들을 참조하는 `template`과 `styles` / `styleUrls` 속성의 맨 처음에 
+  `./`를 추가하는 것으로 템플릿과 스타일을 런타임에 로드할 수 있습니다.
++makeExample('webpack/ts/src/app/app.component.ts')(format='.')
+
+
   They can load templates and styles at runtime by adding `./` at the beginning of the `template` and `styles` / `styleUrls`
   properties that reference *component-relative URLS.
   
@@ -140,8 +233,12 @@ a#webpack
 
 .l-sub-section
   :marked
+    Webpack은 뒤에서 `require`를 수행해서 템플릿과 스타일을 로드합니다. 더 읽기 [여기](../guide/webpack.html#highlights).
+  
     Webpack will do a `require` behind the scenes to load the templates and styles. Read more [here](../guide/webpack.html#highlights).
 
 
 :marked
+  [Webpack 소개](../guide/webpack.html)을 보세요.
+
   See the [Introduction to Webpack](../guide/webpack.html).