Update Korean doctrine content and wording

Author: hahwul

doctrine/ko.html

@@ -42,9 +42,9 @@ <h1>The Rails Doctrine.</h1>
   <div class="container">
     <div class="text__body">
       <div class="text__content common-content">
-        <p>Ruby on Rails의 놀라운 부상은 새로운 기술과 시기의 적절함 덕분에 많은 도움을 받았습니다. 그러나 기술적 이점은 시간이 지남에 따라 약화되고, 좋은 시기만으로는 장기적으로 운동을 지속할 수 없습니다. 따라서 Rails가 계속해서 관련성을 유지하고 그 영향력과 커뮤니티를 성장시킬 수 있었던 더 넓은 설명이 필요합니다. 저는 지속적인 원동력이 논란의 여지가 있는 그 교리였고 여전히 그렇다고 제안합니다.</p>
-        <p>이 교리는 지난 10년 동안 진화해왔지만, 가장 강력한 기둥 중 대부분은 창립 당시의 것들입니다. 저는 이러한 아이디어의 근본적인 독창성을 주장하지 않습니다. Rails의 주요 성과는 프로그래밍과 프로그래머의 본질에 대한 광범위한 이단적 생각을 중심으로 강력한 부족을 결집하고 육성한 것입니다.</p>
-        <p>이제 서론은 이쯤 하고, 제가 생각하는 Rails 교리의 가장 중요한 아홉 가지 기둥을 소개합니다:</p><ol>
+        <p>Ruby on Rails가 놀라운 성공을 거두며 두각을 나타낼 수 있었던 이유는 새로운 기술과 시기에 맞는 타이밍 덕분이었습니다. 하지만 기술적 우위는 시간이 지나면서 약화되기 마련이며, 좋은 타이밍만으로는 장기적으로 움직임을 유지할 수 없습니다. 따라서 Rails가 어떻게 계속해서 관련성을 유지하고, 그 영향력과 커뮤니티를 확장해 나갈 수 있었는지에 대한 더 넓은 설명이 필요합니다. 저는 그 지속적인 원동력이, 그리고 앞으로도 그럴 것이, Rails의 논쟁적인 원칙이였다고 제안합니다.</p>
+        <p>이 원칙은 지난 10년 동안 진화해왔지만, 가장 강력한 기둥 중 대부분은 창립 당시의 것들입니다. 저는 이러한 아이디어의 근본적인 독창성을 주장하지 않습니다. Rails의 주요 성과는 프로그래밍과 프로그래머의 본질에 대한 광범위한 이단적 생각을 중심으로 강력한 부족을 결집하고 육성한 것입니다.</p>
+        <p>이제 서론은 이쯤 하고, 제가 생각하는 Rails 원칙의 가장 중요한 아홉 가지 기둥을 소개합니다:</p><ol>
           <li><a href="#optimize-for-programmer-happiness">프로그래머의 행복을 최적화</a></li>
           <li><a href="#convention-over-configuration">설정보다 관례</a></li>
           <li><a href="#omakase">메뉴는 오마카세</a></li>
@@ -65,7 +65,7 @@ <h1>The Rails Doctrine.</h1>
     <div class="text__body">
       <div class="text__content common-content">
         <h3>프로그래머의 행복을 최적화</h3>
-        <p>루비가 없었다면 레일즈도 없었을 것입니다. 따라서 첫 번째 교리적 기둥이 루비를 만든 핵심 동기에서 직접 가져온 것은 당연합니다.</p>
+        <p>루비가 없었다면 레일즈도 없었을 것입니다. 따라서 첫 번째 원칙적 기둥이 루비를 만든 핵심 동기에서 직접 가져온 것은 당연합니다.</p>
         <p>루비의 원래 이단은 프로그래머의 행복을 최우선으로 두는 것이었습니다. 이전에 프로그래밍 언어와 생태계를 이끌었던 많은 다른 경쟁적이고 유효한 관심사들보다도 말입니다.</p>
         <p>파이썬이 "무언가를 하는 방법은 하나, 그리고 가능하면 하나뿐이다"라고 자랑할 때, 루비는 표현력과 미묘함을 즐겼습니다. 자바가 프로그래머를 스스로 보호하도록 강력히 주장할 때, 루비는 환영 키트에 날카로운 도구 세트를 포함시켰습니다. 스몰토크가 메시지 전달의 순수성을 강조할 때, 루비는 거의 탐욕스러운 식욕으로 키워드와 구조를 축적했습니다.</p>
         <p>루비는 다른 것을 가치 있게 여겼기 때문에 달랐습니다. 그리고 대부분의 것들은 프로그래머의 행복을 추구하는 데 기여했습니다. 이 추구는 대부분의 다른 프로그래밍 환경뿐만 아니라 프로그래머가 무엇인지, 그리고 그들이 어떻게 행동해야 하는지에 대한 주류 인식과도 충돌했습니다.</p>
@@ -89,7 +89,7 @@ <h3>프로그래머의 행복을 최적화</h3>
         <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>Matz처럼, 저도 때때로 제 원칙을 위해 어리석은 길을 갔습니다. 한 예로 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>
@@ -152,7 +152,7 @@ <h3>단일 패러다임 없음</h3>
         <p>그러나 저는 뷰 템플릿의 많은 추상화에서와 같이 개별 함수가 상호작용할 필요가 거의 없을 때, PHP가 개별 함수를 제시하는 데 있어 옳았다고 주장합니다. 그리고 이 목적을 위해, 단일 네임스페이스, 즉 큰 메서드 모음은 합리적인 선택일 뿐만 아니라 훌륭한 선택입니다.</p>
         <p>이것이 우리가 때때로 뷰를 구축할 때 더 객체 지향적인 것을 원하지 않는다는 의미는 아닙니다. 많은 메서드가 서로와 그 아래의 데이터와 상호 의존하는 경우, 이를 래핑하는 프레젠터 개념은 종종 의존성으로 인해 시큼해진 메서드 수프에 대한 완벽한 해독제가 될 수 있습니다. 그러나 이는 일반적으로 드문 경우에 해당합니다.</p>
         <p>비교해보면, 우리는 일반적으로 MVC 레이어 케이크의 모델을 객체 지향적 선의의 주요 요새로 취급합니다. 객체에 적합한 이름을 찾고, 일관성을 높이며, 결합도를 낮추는 것이 도메인 모델링의 재미입니다. 이는 뷰와 매우 다른 레이어이므로 다른 접근 방식을 취합니다.</p>
-        <p>그러나 여기서도 우리는 단일 패러다임 교리에 구독하지 않습니다. Rails의 컨선, 즉 Ruby의 믹스인을 전문화한 것은 종종 개별 모델에 매우 넓은 표면적을 제공합니다. 이는 컨선된 메서드가 상호작용하는 데이터와 저장소에 직접 접근할 수 있게 함으로써 Active Record 패턴과 잘 맞습니다.</p>
+        <p>그러나 여기서도 우리는 단일 패러다임의 원칙을 따르지 않습니다. Rails의 Concern(관심사)은 Ruby의 믹스인(mixins) 기능을 활용하여 개별 모델에 매우 넓은 기능 범위를 부여하는 데 자주 사용됩니다. 이는 Concern 메서드가 상호작용하는 데이터와 저장소에 직접 접근할 수 있도록 함으로써 Active Record 패턴과 잘 맞아떨어집니다.</p>
         <p>Active Record 프레임워크의 매우 기초조차도 일부 순수주의자들을 불쾌하게 합니다. 우리는 데이터베이스와 인터페이스하는 데 필요한 로직을 비즈니스 도메인 및 로직과 직접 혼합하고 있습니다. 이러한 경계의 혼합! 그렇습니다, 왜냐하면 이는 웹 애플리케이션 고양이를 벗기는 실용적인 방법으로 입증되었기 때문입니다. 웹 애플리케이션은 거의 항상 도메인 모델의 상태를 지속시키기 위해 어떤 형태로든 데이터베이스와 대화합니다.</p>
         <p>이렇게 이념적으로 유연한 것이 Rails가 다양한 문제를 해결할 수 있게 하는 것입니다. 대부분의 개별 패러다임은 문제 공간의 특정 부분에서 매우 잘 작동하지만, 자연스러운 편안함의 영역을 넘어 적용될 때 어색하거나 경직됩니다. 많은 중첩된 패러다임을 적용함으로써, 우리는 측면을 덮고 후방을 보호합니다. 최종 프레임워크는 개별 패러다임이 허용했을 것보다 훨씬 더 강력하고 능력 있습니다.</p>
         <p>이렇게 많은 프로그래밍 패러다임과의 다중 관계의 대가는 개념적 오버헤드입니다. Rails를 잘 사용하려면 객체 지향 프로그래밍만 알아서는 충분하지 않습니다. 절차적 및 함수적 경험도 잘 갖추는 것이 바람직합니다.</p>
@@ -276,9 +276,9 @@ <h3>안정성보다 진보</h3>
     <div class="text__body">
       <div class="text__content common-content">
         <h3>큰 텐트를 세우다</h3>
-        <p>많은 논란의 여지가 있는 아이디어를 가지고 있는 Rails는 모든 사람들이 항상 모든 교리에 완전히 순응하도록 요구한다면, 이념적 은둔자의 고립된 그룹이 될 수 있습니다. 그래서 우리는 그렇게 하지 않습니다!</p>
+        <p>많은 논란의 여지가 있는 아이디어를 가지고 있는 Rails는 모든 사람들이 항상 모든 원칙에 완전히 순응하도록 요구한다면, 이념적 은둔자의 고립된 그룹이 될 수 있습니다. 그래서 우리는 그렇게 하지 않습니다!</p>
         <p>우리는 이견이 필요합니다. 우리는 방언이 필요합니다. 우리는 다양한 생각과 사람들이 필요합니다. 이러한 아이디어의 용광로에서 모두가 공유할 수 있는 최고의 공통점을 얻을 수 있습니다. 많은 사람들이 코드나 신중한 논쟁으로 그들의 의견을 기여합니다.</p>
-        <p>그래서 이 교리가 이상화된 형태를 설명했지만, 일상적인 현실은 훨씬 더 미묘하고 흥미롭습니다. Rails는 리트머스 테스트가 거의 없기 때문에 하나의 큰 커뮤니티를 지원할 수 있습니다.</p>
+        <p>그래서 이 원칙이 이상화된 형태를 설명했지만, 일상적인 현실은 훨씬 더 미묘하고 흥미롭습니다. Rails는 리트머스 테스트가 거의 없기 때문에 하나의 큰 커뮤니티를 지원할 수 있습니다.</p>
         <p>제가 종종 심각한 불만을 표명한 테스트를 위한 DSL인 RSpec의 지속적인 성공이 완벽한 증거입니다. 제가 왜 그것이 옳지 않다고 생각하는지 얼굴이 파랗게 될 때까지 소리칠 수 있지만, 그것은 여전히 번창하고 번영할 수 있습니다. 그 점이 훨씬 더 중요한 것입니다!</p>
         <p>Rails가 API로 등장한 것도 마찬가지입니다. 저의 개인적인 초점과 헌신은 뷰를 포함하는 통합 시스템에 있지만, 클라이언트와 서버를 분산시키고자 하는 사람들에게도 Rails가 잘 작동할 여지가 분명히 있습니다. 우리는 이것이 부차적인 임무로 공존할 수 있는 한 이를 받아들여야 하며, 저는 그것이 확실히 가능하다고 믿습니다.</p>
         <p>큰 텐트를 세운다는 것은 모든 사람에게 모든 것을 제공하려는 것이 아닙니다. 단지 모든 사람을 파티에 환영하고, 그들이 자신의 음료를 가져오도록 허용하는 것입니다. 우리는 다른 사람들이 우리와 합류하도록 함으로써 우리의 영혼이나 가치를 잃을 필요가 없으며, 새로운 맛있는 음료를 섞는 방법을 배울 수도 있습니다.</p>