diff --git a/content/ko/docs/setup/production-environment/container-runtimes.md b/content/ko/docs/setup/production-environment/container-runtimes.md
index 7f9885faa0..fb749a2346 100644
--- a/content/ko/docs/setup/production-environment/container-runtimes.md
+++ b/content/ko/docs/setup/production-environment/container-runtimes.md
@@ -118,8 +118,8 @@ containerd를 설치한다.
 {{% /tab %}}
 {{% tab name="Windows (PowerShell)" %}}
 
-PowerShell 세션을 시작하고 `$Version`을 원하는 버전(예: `$Version:1.4.3`)으로
-설정한 후 다음 명령을 실행한다.
+PowerShell 세션을 시작하고 `$Version`을 원하는 버전으로
+설정(예: `$Version:1.4.3`)한 후 다음 명령을 실행한다.
 
 1. containerd 다운로드
 
diff --git a/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md b/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md
index 3567d287f4..9875b8426e 100644
--- a/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md
+++ b/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md
@@ -25,7 +25,7 @@ weight: 75
 * 쿠버네티스에서 서비스와 워크로드를 생성하고 배포하는 것은 리눅스나 윈도우 컨테이너
 모두 비슷한 방식이라는 것이 중요하다.
 [Kubectl 커맨드](/ko/docs/reference/kubectl/overview/)로 클러스터에 접속하는 것은 동일하다.
-아래 단원의 예시는 윈도우 컨테이너를 경험하기 위해 제공한다.
+아래 단원의 예시를 통해 윈도우 컨테이너와 좀 더 빨리 친숙해질 수 있다.
 
 ## 시작하기: 윈도우 컨테이너 배포하기
 
@@ -99,17 +99,17 @@ spec:
 
 1. 이 디플로이먼트가 성공적인지 확인한다. 다음을 검토하자.
 
-    * 윈도우 노드에 파드당 두 컨테이너, `docker ps`를 사용한다.
-    * 리눅스 마스터에서 나열된 두 파드, `kubectl get pods`를 사용한다.
-    * 네트워크를 통한 노드에서 파드 간에 통신, 리눅스 마스터에서 `curl`을
+    * 윈도우 노드에 파드당 두 컨테이너가 존재하는지 확인하려면, `docker ps`를 사용한다.
+    * 리눅스 마스터에서 나열된 두 파드가 존재하는지 확인하려면, `kubectl get pods`를 사용한다.
+    * 네트워크를 통한 노드에서 파드로의 통신이 되는지 확인하려면, 리눅스 마스터에서 `curl`을
       파드 IP 주소의 80 포트로 실행하여 웹 서버 응답을 확인한다.
-    * 파드와 파드 간에 통신, `docker exec` 나 `kubectl exec`를 이용해 파드 간에
-      핑(ping)한다(윈도우 노드를 여럿 가지고 있다면 호스트를 달리하며).
-    * 서비스와 파드 간에 통신, 리눅스 마스터와 독립 파드에서 `curl`을 가상 서비스
-      IP 주소(`kubectl get services`로 보여지는)로 실행한다.
-    * 서비스 검색(discovery), 쿠버네티스 [기본 DNS 접미사](/ko/docs/concepts/services-networking/dns-pod-service/#서비스)와 서비스 이름으로 `curl`을 실행한다.
-    * 인바운드 연결, 클러스터 외부 장비나 리눅스 마스터에서 NodePort로 `curl`을 실행한다.
-    * 아웃바운드 연결, `kubectl exec`를 이용해서 파드에서 외부 IP 주소로 `curl`을 실행한다.
+    * 파드 간 통신이 되는지 확인하려면, `docker exec` 나 `kubectl exec`를 이용해 파드 간에
+      핑(ping)한다(윈도우 노드가 2대 이상이라면, 서로 다른 노드에 있는 파드 간 통신도 확인할 수 있다).
+    * 서비스에서 파드로의 통신이 되는지 확인하려면, 리눅스 마스터와 독립 파드에서 `curl`을 가상 서비스
+      IP 주소(`kubectl get services`로 볼 수 있는)로 실행한다.
+    * 서비스 검색(discovery)이 되는지 확인하려면, 쿠버네티스 [기본 DNS 접미사](/ko/docs/concepts/services-networking/dns-pod-service/#서비스)와 서비스 이름으로 `curl`을 실행한다.
+    * 인바운드 연결이 되는지 확인하려면, 클러스터 외부 장비나 리눅스 마스터에서 NodePort로 `curl`을 실행한다.
+    * 아웃바운드 연결이 되는지 확인하려면, `kubectl exec`를 이용해서 파드에서 외부 IP 주소로 `curl`을 실행한다.
 
 {{< note >}}
 윈도우 컨테이너 호스트는 현재 윈도우 네트워킹 스택의 플랫폼 제한으로 인해, 그 안에서 스케줄링하는 서비스의 IP 주소로 접근할 수 없다.
@@ -122,8 +122,8 @@ spec:
 
 로그는 가시성의 중요한 요소이다. 로그는 사용자가 워크로드의 운영측면을
 파악할 수 있도록 하며 문제 해결의 핵심 요소이다.
-윈도우 컨테이너와 워크로드 내의 윈도우 컨테이너가 리눅스 컨테이너와는 다르게 동작하기 때문에,
-사용자가 로그를 수집하는 데 어려움을 겪었기에 운영 가시성이 제한되었다.
+윈도우 컨테이너, 그리고 윈도우 컨테이너 내의 워크로드는 리눅스 컨테이너와는 다르게 동작하기 때문에,
+사용자가 로그를 수집하기 어려웠고 이로 인해 운영 가시성이 제한되어 왔다.
 예를 들어 윈도우 워크로드는 일반적으로 ETW(Event Tracing for Windows)에 로그인하거나
 애플리케이션 이벤트 로그에 항목을 푸시하도록 구성한다.
 Microsoft의 오픈 소스 도구인 [LogMonitor](https://github.com/microsoft/windows-container-tools/tree/master/LogMonitor)는
@@ -131,8 +131,8 @@ Microsoft의 오픈 소스 도구인 [LogMonitor](https://github.com/microsoft/w
 LogMonitor는 이벤트 로그, ETW 공급자 그리고 사용자 정의 애플리케이션 로그 모니터링을 지원하고
 `kubectl logs <pod>` 에 의한 사용을 위해 STDOUT으로 파이프한다.
 
-LogMonitor Github 페이지의 지침에 따라 모든 컨테이너 바이너리와 설정 파일을 복사하고,
-LogMonitor에 필요한 입력 지점을 추가해서 로그를 STDOUT으로 푸시한다.
+LogMonitor GitHub 페이지의 지침에 따라 모든 컨테이너 바이너리와 설정 파일을 복사하고,
+LogMonitor가 로그를 STDOUT으로 푸시할 수 있도록 필요한 엔트리포인트를 추가한다.
 
 ## 설정 가능한 컨테이너 username 사용하기
 
@@ -151,14 +151,14 @@ GMSA로 구성한 컨테이너는 GMSA로 구성된 신원을 들고 있는 동
 
 ## 테인트(Taint)와 톨러레이션(Toleration)
 
-오늘날 사용자는 리눅스와 윈도우 워크로드를 특정 OS 노드별로 보존하기 위해 테인트와
-노드 셀렉터(nodeSelector)의 조합을 이용해야 한다.
+오늘날 사용자는 리눅스와 윈도우 워크로드를 (동일한 OS를 실행하는) 적절한 노드에 할당되도록 하기 위해 테인트와
+노드셀렉터(nodeSelector)의 조합을 이용해야 한다.
 이것은 윈도우 사용자에게만 부담을 줄 것으로 보인다. 아래는 권장되는 방식의 개요인데,
 이것의 주요 목표 중에 하나는 이 방식이 기존 리눅스 워크로드와 호환되어야 한다는 것이다.
 
 ### 특정 OS 워크로드를 적절한 컨테이너 호스트에서 처리하도록 보장하기
 
-사용자는 윈도우 컨테이너가 테인트와 톨러레이션을 이용해서 적절한 호스트에서 스케줄링되기를 보장할 수 있다.
+사용자는 테인트와 톨러레이션을 이용하여 윈도우 컨테이너가 적절한 호스트에서 스케줄링되기를 보장할 수 있다.
 오늘날 모든 쿠버네티스 노드는 다음 기본 레이블을 가지고 있다.
 
 * kubernetes.io/os = [windows|linux]
@@ -194,14 +194,14 @@ tolerations:
 
 ### 동일 클러스터에서 여러 윈도우 버전을 조작하는 방법
 
-파드에서 사용하는 윈도우 서버 버전은 노드 버전과 일치해야 한다. 만약 동일한 클러스터에서 여러 윈도우
-서버 버전을 사용하려면, 추가로 노드 레이블과 nodeSelectors를 설정해야만 한다.
+파드에서 사용하는 윈도우 서버 버전은 노드의 윈도우 서버 버전과 일치해야 한다. 만약 동일한 클러스터에서 여러 윈도우
+서버 버전을 사용하려면, 추가로 노드 레이블과 nodeSelectors를 설정해야 한다.
 
-쿠버네티스 1.17은 이것을 단순화하기 위해 새로운 레이블인 `node.kubernetes.io/windows-build` 를 자동으로 추가 한다.
+쿠버네티스 1.17은 이것을 단순화하기 위해 새로운 레이블인 `node.kubernetes.io/windows-build` 를 자동으로 추가한다.
 만약 이전 버전을 실행 중인 경우, 이 레이블을 윈도우 노드에 수동으로 추가하는 것을 권장한다.
 
-이 레이블은 호환성을 일치해야 하는 윈도우 메이저, 마이너 및 빌드 번호를 나타낸다.
-여기에 현재 사용하는 각 윈도우 서버 버전이 있다.
+이 레이블은 호환성을 위해 일치시켜야 하는 윈도우 메이저, 마이너 및 빌드 번호를 나타낸다.
+각 윈도우 서버 버전에 대해 현재 사용하고 있는 빌드 번호는 다음과 같다.
 
 | 제품 이름                            |   빌드 번호            |
 |--------------------------------------|------------------------|
@@ -212,12 +212,12 @@ tolerations:
 
 ### RuntimeClass로 단순화
 
-[RuntimeClass]를 사용해서 테인트(taint)와 톨러레이션(toleration)을 사용하는 프로세스를 간소화 할 수 있다.
-클러스터 관리자는 이 테인트와 톨러레이션을 캡슐화하는데 사용되는 `RuntimeClass` 오브젝트를 생성할 수 있다.
+[런타임클래스(RuntimeClass)](/ko/docs/concepts/containers/runtime-class/)를 사용해서 테인트(taint)와 톨러레이션(toleration)을 사용하는 프로세스를 간소화 할 수 있다.
+클러스터 관리자는 이 테인트와 톨러레이션을 캡슐화하는 데 사용되는 `RuntimeClass` 오브젝트를 생성할 수 있다.
 
 
 1. 이 파일을 `runtimeClasses.yml` 로 저장한다. 여기에는 윈도우 OS,
-아키텍처 및 버전에 적합한 `nodeSelector` 가 포함되었다.
+아키텍처 및 버전에 적합한 `nodeSelector` 가 포함되어 있다.
 
 ```yaml
 apiVersion: node.k8s.io/v1