Update Korean doctrine content and wording

doctrine/ko.html

@@ -67,7 +67,7 @@ <h1>The Rails Doctrine.</h1>
         <h3>프로그래머의 행복을 최적화</h3>
         <p>루비가 없었다면 레일즈도 없었을 것입니다. 따라서 첫 번째 원칙적 기둥이 루비를 만든 핵심 동기에서 직접 가져온 것은 당연합니다.</p>
         <p>루비의 원래 이단은 프로그래머의 행복을 최우선으로 두는 것이었습니다. 이전에 프로그래밍 언어와 생태계를 이끌었던 많은 다른 경쟁적이고 유효한 관심사들보다도 말입니다.</p>
-        <p>파이썬이 "무언가를 하는 방법은 하나, 그리고 가능하면 하나뿐이다"라고 자랑할 때, 루비는 표현력과 미묘함을 즐겼습니다. 자바가 프로그래머를 스스로 보호하도록 강력히 주장할 때, 루비는 환영 키트에 날카로운 도구 세트를 포함시켰습니다. 스몰토크가 메시지 전달의 순수성을 강조할 때, 루비는 거의 탐욕스러운 식욕으로 키워드와 구조를 축적했습니다.</p>
+        <p>파이썬이 "어떤 일을 하는 데에는 하나의 방법, 가능하면 단 하나의 방법만 있어야 한다"고 자랑할 때, 루비는 표현력과 미묘함을 즐겼습니다. 자바가 프로그래머를 스스로로부터 보호하려는 강력한 방식을 옹호할 때, 루비는 환영 패키지에 날카로운 칼들을 포함시켰습니다. 스몰톡이 메시지 전달의 순수성을 강조할 때, Ruby는 마치 폭식하듯 키워드와 구조를 쌓아갔습니다.</p>
         <p>루비는 다른 것을 가치 있게 여겼기 때문에 달랐습니다. 그리고 대부분의 것들은 프로그래머의 행복을 추구하는 데 기여했습니다. 이 추구는 대부분의 다른 프로그래밍 환경뿐만 아니라 프로그래머가 무엇인지, 그리고 그들이 어떻게 행동해야 하는지에 대한 주류 인식과도 충돌했습니다.</p>
         <p>루비는 프로그래머의 감정을 인식하고 수용하며 높이 평가했습니다. 그것이 불충분함, 변덕, 또는 기쁨이든 간에 말입니다. 마츠는 기계가 인간 공모자에게 미소를 짓고 아첨하는 것처럼 보이게 하기 위해 놀라운 복잡성의 구현적 장애물을 뛰어넘었습니다. 루비는 우리의 마음의 눈에 단순하고 명확하며 아름답게 보이는 것이 실제로는 후드 아래에서 곡예적인 와이어의 엉킴인 착시 현상으로 가득합니다. 이러한 선택은 무료가 아니었습니다 (이 마법의 음악 상자를 역설계하려고 시도한 JRuby 팀에게 물어보세요!), 그래서 그것들이 매우 칭찬받을 만한 이유입니다.</p>
         <p>프로그래밍과 프로그래머에 대한 대안적 비전에 대한 이 헌신이 루비와의 사랑을 확고히 했습니다. 그것은 단순한 사용의 용이성, 블록의 미학, 단일 기술적 성취가 아니었습니다. 그것은 비전이었습니다. 반문화였습니다. 기존의 전문 프로그래밍 틀에서 벗어난 부적응자들이 소속되고 같은 마음을 가진 사람들과 어울릴 수 있는 장소였습니다.</p>
@@ -85,11 +85,11 @@ <h3>프로그래머의 행복을 최적화</h3>
 >>> exit
 Use exit() or Ctrl-D (i.e. EOF) to exit
 {% endhighlight %}
-        <p>Ruby는 프로그래머가 인터랙티브 콘솔을 종료하고자 하는 명백한 욕구를 수용하기 위해 exit와 quit를 모두 허용합니다. 반면에 Python은 프로그래머가 요청한 작업을 올바르게 수행하는 방법을 세세하게 지시합니다. 이는 Python이 무엇을 의미하는지 명확히 알고 있음에도 불구하고 (오류 메시지를 표시하고 있기 때문에) 그렇습니다. 이것은 PoLS(최소 놀람의 원칙)의 명확한 예입니다.</p>
-        <p>PoLS가 Ruby 커뮤니티에서 인기를 잃은 이유는 이 원칙이 본질적으로 주관적이기 때문입니다. 누구에게 가장 놀랍지 않은가? 바로 Matz에게. 그리고 Matz와 같은 방식으로 놀라는 사람들에게. Ruby 커뮤니티가 성장하면서, Matz와 다른 방식으로 놀라는 사람들의 비율도 함께 증가하면서, 이는 메일링 리스트에서 무익한 논쟁의 원천이 되었습니다. 그래서 이 원칙은 배경으로 사라졌고, 사람 X가 행동 Y에 놀랐는지 여부에 대한 논쟁을 더 이상 초대하지 않게 되었습니다.</p>
-        <p>그래서 다시, 이것이 Rails와 무슨 관련이 있을까요? Rails는 최소 놀람의 원칙(To Matz)과 유사한 원칙으로 설계되었습니다. 더 큰 미소의 원칙(DHH의), 이는 단지 그것이 말하는 그대로입니다: 나를 더 크게, 더 넓게 미소 짓게 할 무엇이든지에 큰 주의를 기울여 설계된 API들. 이렇게 써놓고 보니, 거의 우스꽝스럽게 자기중심적이라는 인상을 주며, 저조차도 그 첫인상에 반박하기 어렵습니다.</p>
-        <p>그러나 Ruby나 Rails와 같은 것을 만드는 것은 적어도 처음에는 깊이 자기중심적인 노력입니다. 두 프로젝트 모두 단일 창조자의 마음에서 비롯되었습니다. 그러나 아마도 저는 여기서 Matz에게 제 자신의 동기를 투영하고 있을지도 모릅니다. 그래서 제가 알고 있는 것으로 제 선언의 범위를 좁히겠습니다: 저는 Rails를 저를 위해 만들었습니다. 우선적으로 저를 미소 짓게 하기 위해서. 그것의 유용성은 제 삶을 더 즐겁게 만드는 능력에 종속되었습니다. 웹 정보 시스템에 대한 요구사항과 요청을 다루는 일상적인 고된 작업을 풍요롭게 하기 위해서였습니다.</p>
-        <p>Matz처럼, 저도 때때로 제 원칙을 위해 어리석은 길을 갔습니다. 한 예로 Inflector는 Person 클래스를 People 테이블로, Analysis를 Analyses로, 단순히 Comment를 Comments로 매핑할 수 있는 영어의 패턴과 불규칙성을 충분히 이해하는 클래스입니다. 이 동작은 이제 Rails의 의심할 여지 없는 요소로 받아들여지지만, 우리가 원칙과 그 중요성을 통합하던 초기에는 큰 논란의 불씨였습니다.</p>
+        <p>루비는 프로그래머가 인터랙티브 콘솔을 종료하고자 하는 명백한 욕구를 수용하기 위해 exit와 quit를 모두 허용합니다. 반면에 파이썬은 프로그래머가 요청한 작업을 올바르게 수행하는 방법을 세세하게 지시합니다. 이는 파이썬이 무엇을 의미하는지 명확히 알고 있음에도 불구하고 (오류 메시지를 표시하고 있기 때문에) 그렇습니다. 이것은 PoLS(최소 놀람의 원칙)의 명확한 예입니다.</p>
+        <p>PoLS가 Ruby 커뮤니티에서 인기를 잃은 이유는 이 원칙이 본질적으로 주관적이기 때문입니다. 누구에게 가장 놀랍지 않은가? 바로 마츠에게. 그리고 마츠와 같은 방식으로 놀라는 사람들에게. Ruby 커뮤니티가 성장하면서, 마츠와 다른 방식으로 놀라는 사람들의 비율도 함께 증가하면서, 이는 메일링 리스트에서 무익한 논쟁의 원천이 되었습니다. 그래서 이 원칙은 배경으로 사라졌고, 사람 X가 행동 Y에 놀랐는지 여부에 대한 논쟁을 더 이상 초대하지 않게 되었습니다.</p>
+        <p>그래서 다시, 이것이 Rails와 무슨 관련이 있을까요? Rails는 최소 놀람의 원칙(To 마츠)과 유사한 원칙으로 설계되었습니다. 더 큰 미소의 원칙(DHH의), 이는 단지 그것이 말하는 그대로입니다: 나를 더 크게, 더 넓게 미소 짓게 할 무엇이든지에 큰 주의를 기울여 설계된 API들. 이렇게 써놓고 보니, 거의 우스꽝스럽게 자기중심적이라는 인상을 주며, 저조차도 그 첫인상에 반박하기 어렵습니다.</p>
+        <p>그러나 Ruby나 Rails와 같은 것을 만드는 것은 적어도 처음에는 깊이 자기중심적인 노력입니다. 두 프로젝트 모두 단일 창조자의 마음에서 비롯되었습니다. 그러나 아마도 저는 여기서 마츠에게 제 자신의 동기를 투영하고 있을지도 모릅니다. 그래서 제가 알고 있는 것으로 제 선언의 범위를 좁히겠습니다: 저는 Rails를 저를 위해 만들었습니다. 우선적으로 저를 미소 짓게 하기 위해서. 그것의 유용성은 제 삶을 더 즐겁게 만드는 능력에 종속되었습니다. 웹 정보 시스템에 대한 요구사항과 요청을 다루는 일상적인 고된 작업을 풍요롭게 하기 위해서였습니다.</p>
+        <p>마츠처럼, 저도 때때로 제 원칙을 위해 어리석은 길을 갔습니다. 한 예로 Inflector는 Person 클래스를 People 테이블로, Analysis를 Analyses로, 단순히 Comment를 Comments로 매핑할 수 있는 영어의 패턴과 불규칙성을 충분히 이해하는 클래스입니다. 이 동작은 이제 Rails의 의심할 여지 없는 요소로 받아들여지지만, 우리가 원칙과 그 중요성을 통합하던 초기에는 큰 논란의 불씨였습니다.</p>
         <p>또 다른 예로는 구현 노력이 덜 들었지만 거의 같은 정도의 논란을 일으킨 Array#second에서 #fifth까지 (그리고 좋은 트롤링을 위한 #forty_two). 이 별칭 접근자는 Array#[1], Array#[2] (그리고 Array[41])로도 쓸 수 있는 것을 비난하는 매우 목소리가 큰 구성원들에게 깊은 모욕감을 주었습니다.</p>
         <p>그러나 두 결정 모두 오늘날까지도 저를 미소 짓게 합니다. 저는 테스트 케이스나 콘솔에서 people.third를 쓸 수 있는 것을 즐깁니다. 아니, 그것은 논리적이지 않습니다. 효율적이지도 않습니다. 심지어 병적일 수도 있습니다. 그러나 그것은 계속해서 저를 미소 짓게 하며, 원칙을 충족시키고 제 삶을 풍요롭게 하며, 12년간의 서비스 후에도 Rails에 계속 참여할 수 있는 정당성을 부여합니다.</p>
         <p>성능 최적화와 달리, 행복 최적화는 측정하기 어렵습니다. 이는 거의 본질적으로 비과학적인 노력으로 만들며, 일부에게는 덜 중요하거나 노골적으로 좌절감을 줄 수 있습니다. 프로그래머는 측정 가능한 것을 논쟁하고 정복하도록 교육받습니다. 명확한 결론이 있고 A가 B보다 더 낫다는 것을 범주적으로 보여줄 수 있는 것을 말입니다.</p>