Fix typo error and improve Korean translation.

content/ko/admin-processes.md

@@ -4,7 +4,7 @@
 [프로세스 포메이션](./concurrency)은 애플리케이션의 일반적인 기능들(예: Web request의 처리)을 처리하기 위한 프로세스들의 집합 입니다. 이와는 별도로, 개발자들은 종종 일회성 관리나 유지 보수 작업이 필요합니다. 그 예는 아래와 같습니다.
 
 * 데이터베이스 마이그레이션을 실행합니다. (예: Django에서 `manage.py migrate`, Rail에서 `rake db:migrate`)
-* 임의의 코드를 실행하거나 라이브 데이터베이스에서 앱의 모델을 조사하기 위해 콘솔([REPL](http://en.wikipedia.org/wiki/Read-eval-print_loop) Shell로도 알려져 있는)을 실행한다. 대부분의 언어에서는 인터프리터를 아무런 인자 없이 실행하거나(예: python, perl) 별도의 명령어로 실행(예: ruby의 irb, rails의 rails console)할 수 있는 REPL를 제공합니다.
+* 임의의 코드를 실행하거나 라이브 데이터베이스에서 앱의 모델을 조사하기 위해 콘솔([REPL](http://en.wikipedia.org/wiki/Read-eval-print_loop) Shell로도 알려져 있는)을 실행합니다. 대부분의 언어에서는 인터프리터를 아무런 인자 없이 실행하거나(예: python, perl) 별도의 명령어로 실행(예: ruby의 irb, rails의 rails console)할 수 있는 REPL를 제공합니다.
 * 애플리케이션 저장소에 커밋된 일회성 스크립트의 실행 (예: php scripts/fix_bad_records.php)
 
 일회성 admin 프로세스는 애플리케이션의 일반적인 [오래 실행되는 프로세스](./processes)들과 동일한 환경에서 실행되어야 합니다. 일회성 admin 프로세스들은 릴리즈를 기반으로 실행되며, 해당 릴리즈를 기반으로 돌아가는 모든 프로세스처럼 같은 [코드베이스](./codebase)와 [설정](./config)를 사용해야 합니다. admin 코드는 동기화 문제를 피하기 위해 애플리케이션 코드와 함께 배포되어야 합니다.

content/ko/build-release-run.md

@@ -3,8 +3,8 @@
 
 [코드베이스](./codebase)는 3 단계를 거쳐 (개발용이 아닌) 배포로 변환됩니다.
 
-* *빌드 단계*는 코드 저장소를 코드 저장소를 *빌드*라는 실행 가능한 번들로 변환시키는 단계입니다. 빌드 단계에서는 커밋된 코드 중 배포 프로세스에서 지정된 버전을 사용하며, [종속성](./dependencies)를 가져와 바이너리와 에셋들을 컴파일합니다.
-* *릴리즈 단계*에서는 빌드 단계에서 만들어진 빌드와 배포의 현재 [설정](./config)을 결합 합니다. 완성된 *릴리즈*는 빌드와 설정을 모두 포함하며 실행 환경에서 바로 실행될 수 있다도록 준비됩니다. 
+* *빌드 단계*는 코드 저장소를 코드 저장소를 *빌드*라는 실행 가능한 번들로 변환시키는 단계입니다. 빌드 단계에서는 커밋된 코드 중 배포 프로세스에서 지정된 버전을 사용하며, [종속성](./dependencies)을 가져와 바이너리와 에셋들을 컴파일합니다.
+* *릴리즈 단계*에서는 빌드 단계에서 만들어진 빌드와 배포의 현재 [설정](./config)을 결합 합니다. 완성된 *릴리즈*는 빌드와 설정을 모두 포함하며 실행 환경에서 바로 실행될 수 있도록 준비됩니다. 
 * *실행 단계*(런타임이라고도 하는)에서는 선택된 릴리즈에 대한 애플리케이션 [프로세스](./processes)의 집합을 시작하여, 애플리케이션을 실행 환경에서 돌아가도록 합니다.
 
 

content/ko/codebase.md

@@ -1,17 +1,17 @@
 ## I. 코드베이스
 ### 버전 관리되는 하나의 코드베이스와 다양한 배포
 
-Twelve-Factor 앱은 항상 [Git](http://git-scm.com/), [Mercurial](https://www.mercurial-scm.org/), [Subversion](http://subversion.apache.org/) 같은 버전 컨트롤 시스템을 사용하여 변화를 추적하며, 버전 추적 데이터베이스의 사본을 *코드 저장소*, 줄여서 *저장소*라고 부른다.
+Twelve-Factor 앱은 항상 [Git](http://git-scm.com/), [Mercurial](https://www.mercurial-scm.org/), [Subversion](http://subversion.apache.org/) 같은 버전 컨트롤 시스템을 사용하여 변화를 추적하며, 버전 추적 데이터베이스의 사본을 *코드 저장소*, 줄여서 *저장소*라고 부릅니다.
 
-*코드베이스*는 단일 저장소(Subversion 같은 중앙 집중식 버전 관리 시스템의 경우) 일수도 있고, 루트 커밋을 공유하는 여러 저장소(Git 같은 분산 버전 관리 시스템)일수도 있다. 
+*코드베이스*는 단일 저장소(Subversion 같은 중앙 집중식 버전 관리 시스템의 경우) 일수도 있고, 루트 커밋을 공유하는 여러 저장소(Git 같은 분산 버전 관리 시스템)일수도 있습니다. 
 
 ![하나의 코드베스는 여러 배포로 매핑됩니다.](/images/codebase-deploys.png)
 
-코드베이스와 앱 사이에는 항상 1대1 관계가 성립된다.
+코드베이스와 앱 사이에는 항상 1대1 관계가 성립됩니다.
 
-* 코드베이스가 여러개 있는 경우, 앱이 아니라 분산 시스템으로 봐야한다. 분산 시스템의 개별 구성요소가 앱이 되며, 개별 앱이 Twelve-Factor를 따른다.
-* 여러개 앱이 동일한 코드를 공유한다면 Twelve-Factor를 위반하는것이다. 이를 해결하려면 공유하는 코드를 라이브러리화 시키고, 해당 라이브러리를 [종속성 매니저](./dependencies)로 관리한다.
+* 코드베이스가 여러개 있는 경우, 앱이 아니라 분산 시스템으로 봐야합니다. 분산 시스템의 개별 구성요소가 앱이 되며, 개별 앱이 Twelve-Factor를 따릅니다.
+* 여러개 앱이 동일한 코드를 공유한다면 Twelve-Factor를 위반하는것입니다. 이를 해결하려면 공유하는 코드를 라이브러리화 시키고, 해당 라이브러리를 [종속성 매니저](./dependencies)로 관리해야합니다.
 
-앱의 코드베이스는 한개여야  하지만, 앱 배포는 여러개가 될수 있다. *배포*는 앱의 실행중인 인스턴스를 가리킨다. 보통 운영 사이트와 여러 스테이징 사이트가 여기에 해당한다. 모든 개발자는 자신의 로컬 개발 환경에 실행되는 앱을 가지고 있는데, 이것 역시 하나의 배포로 볼 수 있다.
+앱의 코드베이스는 한개여야  하지만, 앱 배포는 여러개가 될수 있습니다. *배포*는 실행중인 앱의 인스턴스를 가리킵니다. 보통 운영 사이트와 여러 스테이징 사이트가 여기에 해당합니다. 모든 개발자는 자신의 로컬 개발 환경에 실행되는 앱을 가지고 있는데, 이것 역시 하나의 배포로 볼 수 있습니다.
 
-배포마다 다른 버전이 활성화 될수 있지만, 코드베이스 자체는 모든 배포에 대해 동일하다. 예를 들어, 개발자는 아직 스테이징 환경에 배포하지 않은 커밋이 있을 수 있으며, 스테이징 환경에는 아직 운영 환경에 배포되지 않은 커밋이 있을 수 있다. 하지만 이 모든 것들이 같은 코드베이스를 공유하고, 같은 앱의 다른 배포라고 할 수 있다.
+배포마다 다른 버전이 활성화 될수 있지만, 코드베이스 자체는 모든 배포에 대해 동일합니다. 예를 들어, 개발자는 아직 스테이징 환경에 배포하지 않은 커밋이 있을 수 있으며, 스테이징 환경에는 아직 운영 환경에 배포되지 않은 커밋이 있을 수 있습니다. 하지만 이 모든 것들이 같은 코드베이스를 공유하고, 같은 앱의 다른 배포라고 할 수 있습니다.

content/ko/concurrency.md

@@ -5,7 +5,7 @@
 
 ![Scale는 실행되는 프로세스의 갯수로 표현되고, Workload Diversity는 프로세스의 타입으로 표현됩니다. ](/images/process-types.png)
 
-**Twelve-Factor App에서 프로세스들은 일급 시민입니다.** Twelve-Factor App에서의 프로세스는 [서비스 데몬들을 실행하기 위한 유닉스 프로세스 모델](https://adam.herokuapp.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/)에서 큰 힌트를 얻었습니다. 이 모델을 사용하면 개발자는 애플리케이션이 작업을 적절한 *프로세스 타입*에 할당함으로서 다양한 작업 부하를 처리할 수 있도록 설계할 수 있습니다. 예를 들어, HTTP 요청은 웹 프로세스가 처리하며, 오래 걸리는 백그라운드 작업은 worker 프로세스가 처리하도록 할 수 있습니다.
+**Twelve-Factor App에서 프로세스들은 일급 시민입니다.** Twelve-Factor App에서의 프로세스는 [서비스 데몬들을 실행하기 위한 유닉스 프로세스 모델](https://adam.herokuapp.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/)에서 큰 힌트를 얻었습니다. 이 모델을 사용하면 개발자는 애플리케이션의 작업을 적절한 *프로세스 타입*에 할당함으로서 다양한 작업 부하를 처리할 수 있도록 설계할 수 있습니다. 예를 들어, HTTP 요청은 웹 프로세스가 처리하며, 시간이 오래 걸리는 백그라운드 작업은 worker 프로세스가 처리하도록 할 수 있습니다.
 
 이는 런타임 VM 내부의 쓰레드나 [EventMachine](http://rubyeventmachine.com/), [Twisted](http://twistedmatrix.com/trac/), [Node.js](http://nodejs.org/)에서 구성된 것 처럼 async/evented 모델처럼 개별 프로세스가 내부적으로 동시에 처리하는 것을 금지하는 것은 아닙니다. 하지만 개별 VM이 너무 커질 수 있습니다.(수직 확장) 따라서 애플리케이션은 여러개의 물리적인 머신에서 돌아가는 여러개의 프로세스로 넓게 퍼질 수 있어야만 합니다.
 

content/ko/config.md

@@ -1,7 +1,7 @@
 ## III. 설정
 ### 환경(environment)에 저장된 설정
 
-애플리케이션의 *설정*은 [배포](./codebase) (staging, production, 개발 환경 등) 마다 달라질 수 있는 모든 것들입니다. 설정에는 다음이 포함됩니다.
+애플리케이션의 *설정*은 [배포](./codebase) (스테이징, 프로덕션, 개발 환경 등) 마다 달라질 수 있는 모든 것들입니다. 설정에는 다음이 포함됩니다.
 
 * 데이터베이스, memcached 등 [백엔드 서비스](./backing-services)들의 리소스 핸들
 * Amazon S3 이나 트위터 등의 외부 서비스 인증 정보

content/ko/dependencies.md

@@ -5,7 +5,7 @@
 
 **Twelve-Factor App은 전체 시스템에 특정 패키지가 암묵적으로 존재하는 것에 절대 의존하지 않습니다.** *종속선 선언* mainifest를 이용하여 모든 종속성을 완전하고 엄격하게 선언합니다. 더나아가, *종속성 분리* 툴을 사용하여 실행되는 동안 둘러싼 시스템으로 암묵적인 종속성 "유출"이 발생하지 않는 것을 보장합니다. 이런 완전하고 명시적인 종속성의 명시는 개발과 서비스 모두에게 동일하게 적용됩니다.
 
-예를 들어, 루비에서 사용되는 [Bundler](https://bundler.io/)는 종속성 선언을 위해 `Gemfile` manifest 포맷을 지원하며, 종속성 분리를 위해 `bundle exec`를 지원합니다. 파이썬에는 이를 지원하기 위한 2가지 도구가 있습니다. [Pip](http://www.pip-installer.org/en/latest/)은 종속성 선언을 위해 사용되며, [Virtualenv](http://www.virtualenv.org/en/latest/)는 종속성 분리를 위해 사용됩니다. 심지어 C에도 종속성 분리를 위해 [Autoconf](http://www.gnu.org/s/autoconf/)가 있으며, static link를 활용해 종속선 분리도 가능합니다. 어떤 툴체인을 사용하든, 종속석 선언과 분리는 항상 같이 사용되어야 합니다. 하나만 사용하는 것은 Twelve-Factor에 만족하는 데 불충분합니다.
+예를 들어, 루비에서 사용되는 [Bundler](https://bundler.io/)는 종속성 선언을 위해 `Gemfile` manifest 포맷을 지원하며, 종속성 분리를 위해 `bundle exec`를 지원합니다. 파이썬에는 이를 지원하기 위한 2가지 도구가 있습니다. [Pip](http://www.pip-installer.org/en/latest/)은 종속성 선언을 위해 사용되며, [Virtualenv](http://www.virtualenv.org/en/latest/)는 종속성 분리를 위해 사용됩니다. 심지어 C언어에도 종속성 분리를 위해 [Autoconf](http://www.gnu.org/s/autoconf/)가 있으며, static link를 활용해 종속성 분리도 가능합니다. 어떤 툴체인을 사용하든, 종속성 선언과 분리는 항상 같이 사용되어야 합니다. 하나만 사용하는 것은 Twelve-Factor에 만족하는 데 불충분합니다.
 
 명시적인 종속성 선언의 장점 중 하나는 애플리케이션 개발에 새로 참가하게 된 개발자가 설치를 간단하게 할 수 있다는 점입니다. 새로 참가한 개발자는 애플리케이션의 코드베이스를 개발 머신에 체크아웃 하고, 언어의 런타임과 종속성 매니저만 미리 설치하면 됩니다. 개발자는 정해져있는 *빌드 명령어*만 입력하면 응용 프로그램의 코드를 실행하는 데 필요한 모든 것을 설치할 수 있습니다. 예를 들어, Ruby의 빌드 명령어는 `bundle install`이며, Clojure/[Leiningen](https://github.com/technomancy/leiningen#readme)에서는 `lein deps`입니다.
 

content/ko/disposability.md

@@ -1,12 +1,12 @@
 ## IX. 폐기 가능(Disposability)
 ### 빠른 시작과 그레이스풀 셧다운(graceful shutdown)을 통한 안정성 극대화
 
-**Twelve-Factor App의 [프로세스](./processes)는 *간단하게 폐기 가능*합니다. 즉, 프로세스는 바로 시작하거나 종료될 수 있습니다. 이러한 속성은 신축성 있는 확장과 [코드](./codebase)나 [설정](./config)의 변화를 빠르게 배포하는 것을 쉽게 하며, production 배포를 안정성 있게 해줍니다.
+**Twelve-Factor App의 [프로세스](./processes)는 *간단하게 폐기 가능*합니다. 즉, 프로세스는 바로 시작하거나 종료될 수 있습니다.** 이러한 속성은 신축성 있는 확장과 [코드](./codebase)나 [설정](./config)의 변화를 빠르게 배포하는 것을 쉽게 하며, production 배포를 안정성 있게 해줍니다.
 
 프로세스는 **시작 시간을 최소화**하도록 노력해야합니다. 이상적으로, 프로세스는 실행 커맨드가 실행된 뒤 몇 초만에 요청이나 작업을 받을 수 있도록 준비 됩니다. 짧은 실행 시간은 [릴리즈](./build-release-run) 작업과 확장(scale up)이 더 민첩하게 이루어질 수 있게 합니다. 또한 프로세스 매니저가 필요에 따라 쉽게 프로세스를 새로운 머신으로 프로세스를 옮길 수 있기 때문에 안정성도 높아집니다. 
 
-프로세스는 프로세스 매니저로부터 **[SIGTERM]((http://en.wikipedia.org/wiki/SIGTERM) 신호를 받았을 때 그레이스풀 셧다운(graceful shutdown)을 합니다. ** 웹프로세스의 그레이스풀 셧다운 과정에서는 서비스 포트의 수신을 중지하고(그럼으로써 새로운 요청을 거절함), 현재 처리 중인 요청이 끝나길 기다린 뒤에 프로세스가 종료 되게 됩니다. 이 모델은 암묵적으로 HTTP 요청이 짧다는 가정(기껏해야 몇 초)을 깔고 있습니다. long polling의 경우에는 클라이언트가 연결이 끊긴 시점에 바로 다시 연결을 시도해야 합니다. 
+프로세스는 프로세스 매니저로부터 **[SIGTERM](http://en.wikipedia.org/wiki/SIGTERM) 신호를 받았을 때 그레이스풀 셧다운(graceful shutdown)을 합니다.** 웹프로세스의 그레이스풀 셧다운 과정에서는 서비스 포트의 수신을 중지하고(그럼으로써 새로운 요청을 거절함), 현재 처리 중인 요청이 끝나길 기다린 뒤에 프로세스가 종료 되게 됩니다. 이 모델은 암묵적으로 HTTP 요청이 짧다는 가정(기껏해야 몇 초)을 깔고 있습니다. long polling의 경우에는 클라이언트가 연결이 끊긴 시점에 바로 다시 연결을 시도해야 합니다. 
 
-worker 프로세스의 경우, 그레이스풀 셧다운은 현재 처리중인 작업을 작업 큐로 되돌리는 방법으로 구현됩니다. 예를 들어, [RabbitMQ](http://www.rabbitmq.com/)에서는 worker는 [`NACK`](http://www.rabbitmq.com/amqp-0-9-1-quickref.html#basic.nack)을 메시지큐로 보낼 수 있습니다. [Beanstalkd](http://kr.github.com/beanstalkd/)에서는 woker와의 연결이 끊기면 때 자동으로 작업을 큐로 되돌립니다. [Delayed Job](https://github.com/collectiveidea/delayed_job#readme)와 같은 Lock-based 시스템들은 작업 레코드에 걸어놨던 lock을 확실하게 풀어놓을 필요가 있습니다. 이 모델은 암묵적으로 모든 작업은 [재입력 가능(reentrant)](http://en.wikipedia.org/wiki/Reentrant_%28subroutine%29)하다고 가정합니다. 이는 보통, 결과를 트랜잭션으로 감싸거나 요청을 [idempotent](http://en.wikipedia.org/wiki/Idempotence)하게 함으로써 구현될 수 있습니다.
+worker 프로세스의 경우, 그레이스풀 셧다운은 현재 처리중인 작업을 작업 큐로 되돌리는 방법으로 구현됩니다. 예를 들어, [RabbitMQ](http://www.rabbitmq.com/)에서는 worker는 [`NACK`](http://www.rabbitmq.com/amqp-0-9-1-quickref.html#basic.nack)을 메시지큐로 보낼 수 있습니다. [Beanstalkd](http://kr.github.com/beanstalkd/)에서는 woker와의 연결이 끊기면 때 자동으로 작업을 큐로 되돌립니다. [Delayed Job](https://github.com/collectiveidea/delayed_job#readme)와 같은 Lock-based 시스템들은 작업 레코드에 걸어놨던 lock을 확실하게 풀어놓을 필요가 있습니다. 이 모델은 암묵적으로 모든 작업은 [재입력 가능(reentrant)](http://en.wikipedia.org/wiki/Reentrant_%28subroutine%29)하다고 가정합니다. 이는 보통, 결과를 트랜잭션으로 감싸거나 요청을 [멱등(idempotent)](http://en.wikipedia.org/wiki/Idempotence)하게 함으로써 구현될 수 있습니다.
 
 프로세스는 하드웨어 에러에 의한 **갑작스러운 죽음에도 견고해야합니다.** 이러한 사태는 `SIGTERM`에 의한 그레이스풀 셧다운에 비하면 드문 일이지만, 그럼에도 발생할 수 있습니다. 이런 일에 대한 대책으로 Beanstalkd와 같은 견고한 큐잉 백엔드를 사용하는 것을 권장합니다. 이러한 백엔드는 클라이언트가 접속이 끊기거나, 타임 아웃이 발생했을 때, 작업을 큐로 되돌립니다. Twelve-Factor App은 예기치 못한, 우아하지 않은 종료도 처리할 수 있도록 설계됩니다. [Crash-only design](http://lwn.net/Articles/191059/)에서는 [논리적인 결론](http://docs.couchdb.org/en/latest/intro/overview.html)으로 이러한 컨셉을 가져왔습니다. 

content/ko/toc.md

@@ -28,8 +28,8 @@ The Twelve Factors
 ## [IX. 폐기 가능(Disposability)](./disposability)
 ### 빠른 시작과 그레이스풀 셧다운(graceful shutdown)을 통한 안정성 극대화
 
-## [X. dev/prod 일치](./dev-prod-parity)
-### development, staging, production 환경을 최대한 비슷하게 유지
+## [X. 개발/프로덕션환경 일치](./dev-prod-parity)
+### 개발, 스테이징, 프로덕션 환경을 최대한 비슷하게 유지
 
 ## [XI. 로그](./logs)
 ### 로그를 이벤트 스트림으로 취급