docs: needs driven page translated into Korean

i18n/kr/docusaurus-plugin-content-docs/current/about/understanding/needs-driven.md

@@ -0,0 +1,160 @@
+---
+sidebar_position: 2
+---
+
+# 필요 중심
+
+:::note TL;DR
+
+— _새로운 기능의 목표가 불분명하거나 작업 자체가 명확히 정의되지 않았나요?  **이 방법론의 핵심은 작업과 목표를 명확히 정의하는 데 있습니다.**_
+
+— _프로젝트는 정적인 것이 아닙니다. 요구 사항과 기능은 계속해서 변화하며, 시간이 지남에 따라 코드는 점점 복잡해지고 관리가 어려워집니다. 이는 초기 설계가 당시의 요구 사항에만 맞춰져 있기 때문입니다.  **우수한 아키텍처는 이러한 변화에 유연하게 적응할 수 있어야 합니다.**_
+
+:::
+
+
+## 왜 이런 접근이 필요할까요?
+
+코드에 포함된 각 엔티티의 이름을 명확히 짓고 구성 요소를 이해하려면, **그 코드가 어떤 문제를 해결하기 위해 작성되었는지 명확히 알아야 합니다.**
+
+> _@sergeysova: 개발할 때 각 엔티티와 함수의 실행 의도와 의미를 이름에 명확히 반영하려고 노력합니다._
+
+_작업이 명확하지 않으면 주요 사례를 포괄하는 적절한 테스트를 작성하기 어려워집니다. 또한, 오류를 사용자에게 유용한 방식으로 처리하지 못하거나, 사소한 수정이 필요한 오류조차 사용자 흐름을 방해할 위험이 있습니다._
+
+## 우리가 말하는 작업은 무엇인가?
+
+프론트엔드는 최종 사용자를 위한 애플리케이션과 인터페이스를 개발하며, 이를 통해 사용자의 문제를 해결하고 요구를 충족합니다.
+
+사용자가 우리 서비스를 이용할 때, **그는 자신의 문제를 해결하거나 필요를 충족시키고자 합니다.**
+
+_관리자와 분석가의 역할은 이러한 필요를 명확히 정의하고, 개발자가 웹 환경의 특성(예: 통신 지연, 백엔드 오류, 입력 실수, 커서나 손가락의 오작동 등)을 고려하여 이를 구현할 수 있도록 돕는 것입니다._
+
+**사용자가 해결하고자 하는 바로 그 목표가 곧 개발자의 작업입니다.**
+
+> _Feature-Sliced Design의 기본 철학 중 하나는 — 프로젝트의 전체 작업 범위를 더 작은 목표로 나누는 것입니다._
+
+## 이것이 개발에 어떤 영향을 미치는가?
+
+### 작업 분해
+
+개발자는 작업을 구현할 때, 코드의 이해와 유지 관리를 용이하게 하기 위해 이를 **단계적으로 분해**합니다:
+
+* 먼저 _최상위 엔티티로 나누어 구현_ 합니다. 
+* 이후 이러한 엔티티를 _더 세부적인 단위로 분해_ 합니다. 
+* 계속해서 진행합니다.
+
+_이 과정에서 개발자는 코드가 해결하는 작업의 본질을 반영하도록 각 엔티티와 구성 요소에 명확한 이름을 부여합니다._ 
+_동시에, 모든 작업이 사용자의 문제를 해결하고 필요를 충족시키는 데 기여해야 함을 항상 염두에 둡니다._ 
+
+
+### 작업의 본질 이해
+
+엔티티에 명확한 이름을 부여하려면 **개발자가 해당 엔티티의 목적과 역할을 충분히 이해해야 합니다.**
+
+* 이 엔티티가 어떻게 사용될 것인지
+* 사용자 작업의 어떤 부분을 구현하며, 어디에 적용될 수 있는지
+* 다른 작업에 어떤 방식으로 기여할 수 있는지
+* 등등
+
+결론은 명확합니다: **개발자가 방법론의 틀 안에서 엔티티의 이름을 고민하는 과정에서, 코드 작성 이전에 불분명한 작업을 발견할 가능성이 높아집니다.**
+
+> 엔티티의 이름을 어떻게 정의할 수 있을까요? 엔티티가 해결해야 할 작업을 제대로 이해하지 못한다면, 이를 적절히 분리하거나 정의하는 것은 불가능할 것입니다.
+
+## 어떻게 정의할 것인가?
+
+**기능을 통해 해결할 작업을 정의하려면, 그 작업의 본질을 이해해야 합니다. 이는 주로 프로젝트 관리자와 분석가의 책임입니다.**
+
+_방법론은 개발자에게 제품 관리자나 분석가가 주목해야 할 작업의 방향성을 제시할 수 있을 뿐입니다._
+
+> _@sergeysova: 프론트엔드는 본질적으로 정보를 표시하는 데 초점이 맞춰져 있습니다. 어떤 컴포넌트든 먼저 정보를 표시하는 작업을 수행합니다. 그러나 단순히 "사용자에게 무엇을 보여준다"는 작업은 그 자체로는 별다른 가치를 가지지 않습니다._
+>
+> _프론트엔드의 특성을 떠나서 "왜 이것을 보여줘야 하는가?"라는 질문을 던질 수 있으며, 소비자의 문제나 필요를 명확히 이해할 때까지 계속해서 탐구할 수 있습니다._
+
+기본적인 사용자 문제나 필요를 이해한 후에는 **귀하의 제품이나 서비스가 어떻게 사용자의 목표를 지원할 수 있는지를 구체적으로 파악할 수 있습니다.**
+
+트래커에 등록된 모든 새로운 작업은 비즈니스 문제를 해결하는 데 목적이 있으며, 이는 비즈니스가 수익을 창출하면서도 사용자 문제를 해결하도록 돕는 데 초점을 맞추고 있습니다. 따라서, 각 작업은 설명 텍스트에 명시되지 않더라도 분명한 목표를 가지고 있습니다.
+
+_**개발자는 해당 작업이 달성하고자 하는 목표를 명확히 이해해야 합니다.** 모든 회사가 완벽한 프로세스를 갖추고 있는 것은 아니지만, 개발자는 직접 관련 관리자와 소통하여 이를 확인하고 자신의 업무를 효과적으로 수행할 수 있어야 합니다._
+
+## 그래서 이익은?
+
+이제 처음부터 끝까지 전체 프로세스를 살펴보겠습니다.
+
+### 1. 사용자 작업 이해
+
+개발자가 고객의 문제와 비즈니스가 이를 어떻게 해결하는지 이해하면, 웹 개발의 한계로 인해 비즈니스가 제공할 수 없는 부분까지 보완하는 솔루션을 제안할 수 있습니다.
+
+> 물론 이러한 접근은 개발자가 자신의 역할과 목표에 대해 관심을 가지고 있을 때만 가능합니다. 그렇지 않다면, 방법론과 접근 방식의 의미는 무엇이겠습니까?_
+
+### 2. 구조화 및 정리
+
+작업을 이해하면 **사고 과정, 작업, 코드 모두에 명확한 구조와 정리가 생깁니다.**
+
+### 3. 기능과 그 구성 요소 이해
+
+**하나의 기능은 사용자에게 유용한 하나의 기능이어야 합니다.**
+
+* 하나의 기능 안에 여러 기능이 포함되면 **경계 위반**입니다. 
+* 기능은 분리될 수 있고, 확장될 수 있습니다. **이는 문제가 아닙니다.**
+* **진짜 문제는** 기능이 _"이 기능이 사용자에게 제공하는 비즈니스 가치는 무엇인가?"_ 라는 질문에 답하지 못할 때입니다.
+* "지도-사무실" 같은 모호한 기능은 지양해야 합니다.
+  * 대신 `지도에서-회의-예약하기`, `직원-검색`, `근무지-변경` 같은 **명확한 기능은 가능합니다.**
+
+> _@sergeysova: 기능은 불필요한 내부 세부 사항 없이 기능 자체를 구현하는 코드만 포함해야 합니다 (이상적으로는).
+>
+> 기능 코드를 열었을 때, **해당 작업과 직접적으로 관련된 내용만 보여야 합니다.** 그 외에는 포함되지 않아야 합니다.
+
+### 4. 이익
+
+비즈니스가 방향을 급격히 바꾸는 경우는 매우 드뭅니다. **따라서, 프론트엔드 애플리케이션 코드에 비즈니스 작업을 반영하는 것은 큰 이점을 제공합니다.**
+
+_그 결과, 새로운 팀원이 합류할 때마다 코드가 무엇을 하고, 왜 추가되었는지 따로 설명할 필요가 없습니다. **코드 자체에 반영된 비즈니스 작업을 통해 모든 것이 설명될 것입니다.**_
+
+> [도메인 주도 설계에서 "비즈니스 언어"라고 불리는 개념입니다.][ext-ubiq-lang]
+
+---
+
+## 현실로 돌아가기
+
+비즈니스 프로세스가 명확히 이해되고, 설계 단계에서 적절한 이름이 부여되었다면, _이 논리와 이해를 코드로 전달하는 일은 비교적 간단합니다._
+
+**그러나 현실에서는,** 작업과 기능이 종종 너무 반복적으로 처리되거나 설계에 충분히 시간을 투자하지 못하는 경우가 많습니다. 
+
+**그 결과, 오늘 유의미했던 기능이 한 달 뒤 확장되면서 프로젝트의 성격을 완전히 바꿔야 하는 상황이 생길 수 있습니다.**
+
+> *[토론에서][disc-src]: 개발자는 향후 요구 사항을 2~3단계 앞서 내다보려고 노력하지만, 여기에는 경험이 큰 영향을 미칩니다.*
+>
+> _경험 많은 엔지니어는 종종 10단계 앞까지 예측하며, 어디에서 기능을 나누고, 어떤 방식으로 다른 기능과 결합할지를 이해합니다._
+>
+> _그러나 때로는 경험조차 해결할 수 없는 복잡한 작업이 나타나기도 하며, 이러한 경우 불행한 결과를 최소화하면서 적절히 문제를 분해하는 방법을 찾기가 어렵습니다._
+
+## 방법론의 역할
+
+**방법론은 개발자의 문제를 해결함으로써, 사용자의 문제를 더 효과적으로 해결할 수 있도록 돕는 데 목적이 있습니다.** 
+
+방법론은 단순히 개발자를 위한 것이 아닙니다.
+
+개발자가 자신의 작업을 잘 해결하려면, **무엇보다 사용자의 작업과 문제를 명확히 이해해야 합니다.** 그 반대로 사용자의 문제를 모른 채로는 개발자의 문제를 해결할 수 없습니다.
+
+### 방법론 요구 사항
+
+다음은 **Feature-Sliced Design**에서 충족해야 할 두 가지 핵심 요구 사항입니다:
+
+1. 방법론은 **기능, 프로세스, 엔티티를 생성하는 방법**을 명확히 제시해야 합니다.
+    * 이는 코드가 이들 간에 _어떻게 나뉘어야 하는지_ 를 명확히 설명하고, 엔티티의 명명 규칙 또한 구체적으로 정의되어야 함을 의미합니다.
+
+2. 방법론은 **[프로젝트 요구 사항의 변화에 유연하게 대응할 수 있는 아키텍처를 제공해야 합니다][refs-arch--adaptability]**
+
+## See also
+
+* [(포스트) 명확한 작업 정의를 위한 자극 (+ 토론)][disc-src]
+    > _**현재 글은 이 토론의 내용을 바탕**으로 작성된 적응 버전입니다. 전체 원문은 링크에서 확인할 수 있습니다._
+* [(토론) 기능을 어떻게 분해할 것인가, 그리고 그것이 무엇인가][tg-src]
+* [(아티클) "애플리케이션을 더 잘 조직하는 방법"][ext-medium]
+
+[refs-arch--adaptability]: architecture#adaptability
+
+[ext-medium]: https://alexmngn.medium.com/how-to-better-organize-your-react-applications-2fd3ea1920f1
+[disc-src]: https://t.me/sergeysova/318
+[tg-src]: https://t.me/atomicdesign/18972
+[ext-ubiq-lang]: https://thedomaindrivendesign.io/developing-the-ubiquitous-language