docs: needs driven page translated into Korean (feature-sliced#765)

* docs: needs driven page translated into Korean

* docs: needs  page feedback

Author: Gaic4o

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

@@ -0,0 +1,160 @@
+---
+sidebar_position: 2
+---
+
+# 필요 중심
+
+:::note TL;DR
+
+— _새로운 Feature의 목표가 불분명하거나 작업 자체가 명확히 정의되지 않았나요? **이 방법론의 핵심은 작업과 목표를 명확히 정의하는 데 있습니다.**_
+
+— _프로젝트는 정적인 것이 아닙니다. 요구 사항과 Feature는 계속해서 변화하며, 시간이 지남에 따라 코드는 점점 복잡해지고 관리가 어려워집니다. **우수한 아키텍처는 이러한 변화에 유연하게 적응할 수 있어야 합니다.**_
+
+:::
+
+
+## 왜 이런 접근이 필요할까요?
+
+각 Entity의 이름과 구성을 명확히 하려면, **해당 코드의 목적을 정확히 이해**해야 합니다.
+
+> _@sergeysova: 개발할 때 각 Entity와 함수의 의도를 이름에 명확히 반영하려고 노력합니다._
+
+_명확하지 않은 작업은 테스트 작성을 어렵게 만들고, 오류 처리가 비효율적이 되어 사용자 경험을 저하시킬 수 있습니다._
+
+## 우리가 말하는 작업이란?
+
+프론트엔드는 사용자의 문제를 해결하고 요구사항을 충족하는 인터페이스를 제공합니다.
+
+사용자는 서비스 사용 시 **자신의 문제를 해결하거나 필요를 충족**하려 합니다.
+
+_관리자와 분석가는 이러한 요구사항을 명확히 정의하고, 개발자가 웹의 특성(네트워크 지연, 오류, 사용자 실수 등)을 고려하여 구현할 수 있도록 지원합니다._
+
+**사용자의 목표가 곧 개발자의 작업**입니다.
+
+> _Feature-Sliced Design의 핵심 철학 중 하나는 — 프로젝트의 전체 작업을 더 작은 목표 단위로 나누는 것입니다._
+
+## 이것이 개발에 어떤 영향을 미치는가?
+
+### 작업 분해
+
+개발자는 코드의 유지보수성을 위해 작업을 **단계적으로 분해**합니다:
+
+* _최상위 Entity로 분할_ 
+* _더 작은 단위로 세분화_ 
+* _각 Entity에 명확한 이름 부여_
+
+_개발자는 코드가 해결하는 작업의 본질을 반영하도록 각 Entity와 구성 요소에 명확한 이름을 부여합니다._ 
+_이 과정에서 모든 작업이 사용자의 문제 해결에 기여해야 함을 항상 고려합니다._ 
+
+
+### 작업의 본질 이해
+
+Entity에 명확한 이름을 부여하려면 **개발자가 해당 Entity의 목적과 역할을 충분히 이해**해야 합니다:
+
+* Entity의 구체적인 사용 목적
+* 구현하는 사용자 작업의 범위
+* 다른 작업과의 연관성
+
+결론적으로, **개발자가 Entity의 이름을 고민하는 과정에서 불명확한 작업을 미리 발견할 수 있습니다.**
+
+> Entity의 이름을 정의하려면 해당 Entity가 해결할 작업을 정확히 이해해야 합니다.
+
+## 어떻게 정의할 것인가?
+
+**Feature가 해결할 작업을 정의하려면 그 본질을 이해해야 합니다. 이는 주로 프로젝트 관리자와 분석가의 역할입니다.**
+
+_방법론은 개발자에게 작업의 방향성을 제시할 뿐입니다._
+
+> _@sergeysova: 프론트엔드는 정보 표시에 초점을 맞추지만, 단순히 "무엇을 보여준다"는 것은 충분한 가치를 가지지 못합니다. "왜 이것을 보여줘야 하는가?"라는 질문을 통해 사용자의 실제 필요를 이해해야 합니다._
+>
+> _이는 프론트엔드의 기술적 측면을 넘어서, 사용자의 문제와 필요를 정확히 이해할 때까지 지속적으로 탐구해야 하는 과정입니다._
+
+사용자의 필요를 이해한 후에는 **제품이 어떻게 사용자의 목표 달성을 도울 수 있는지 구체화**할 수 있습니다.
+
+모든 새로운 작업은 비즈니스와 사용자의 문제를 동시에 해결하는 것을 목표로 합니다. 각 작업은 명시적이지 않더라도 분명한 목적을 가집니다.
+
+_**개발자는 작업의 목표를 명확히 이해**해야 합니다. 완벽한 프로세스가 없더라도, 관리자와의 소통을 통해 이를 파악하고 효과적으로 구현할 수 있어야 합니다._
+
+## 이점
+
+전체 Process를 통해 얻을 수 있는 이점을 살펴보겠습니다.
+
+### 1. 사용자 작업 이해
+
+개발자가 사용자의 문제와 비즈니스 해결방안을 이해하면, 기술적 제약 내에서도 더 나은 솔루션을 제안할 수 있습니다.
+
+> _이는 개발자가 자신의 역할과 목표에 관심을 가질 때만 가능합니다. 그렇지 않다면, 방법론 자체가 의미를 잃습니다._
+
+### 2. 구조화 및 정리
+
+작업을 이해하면 **사고 과정, 작업, 코드가 자연스럽게 체계화**됩니다.
+
+### 3. 기능과 그 구성 요소 이해
+
+**하나의 Feature는 사용자에게 명확한 가치를 제공해야 합니다.**
+
+* 여러 기능이 섞이면 **경계 위반**입니다
+* Feature는 분리와 확장이 가능합니다. **이는 자연스러운 것입니다**
+* **핵심은** _"이 Feature가 사용자에게 제공하는 가치가 무엇인가?"_ 입니다
+* 예시:
+  * ❌ "지도-사무실" (모호한 Feature)
+  * ⭕ `회의실-예약`, `직원-검색`, `근무지-변경` (**명확한 Feature**)
+
+> _@sergeysova: Feature는 핵심 구현 코드만 포함해야 합니다.
+>
+> **관련 없는 코드는 제외하고, 해당 Feature의 핵심 로직만 담아야 합니다.**_
+
+### 4. 유지보수성
+
+비즈니스 방향은 쉽게 바뀌지 않습니다. **따라서 비즈니스 로직을 코드에 명확히 반영하면 장기적인 이점이 있습니다.**
+
+_그 결과, 새로운 팀원이 합류할 때마다 코드가 무엇을 하고, 왜 추가되었는지 따로 설명할 필요가 없습니다. **코드 자체에 반영된 비즈니스 작업을 통해 모든 것이 설명될 것입니다.**_
+
+> [도메인 주도 설계에서 "비즈니스 언어"라고 불리는 개념입니다.][ext-ubiq-lang]
+
+---
+
+## 현실적 고려사항
+
+비즈니스 Process가 명확하고 설계가 잘 되었다면, _이를 코드로 구현하는 것은 비교적 쉽습니다._
+
+**하지만 현실에서는,** 작업과 Feature가 충분한 설계 시간 없이 반복적으로 처리되는 경우가 많습니다.
+
+**결과적으로, 현재는 적절해 보이는 Feature가 한 달 후 확장 과정에서 전체 프로젝트 구조를 변경해야 할 수도 있습니다.**
+
+> *[토론에서][disc-src]: 개발자는 보통 2~3단계 앞의 요구사항을 예측하려 노력하며, 이는 경험에 크게 좌우됩니다.*
+>
+> _숙련된 개발자는 약 10단계 앞까지 예측할 수 있어서, Feature의 분할 지점과 통합 방식을 더 잘 이해합니다._
+>
+> _그러나 때로는 경험으로도 해결하기 어려운 복잡한 상황이 발생하며, 이때는 피해를 최소화하면서 문제를 적절히 분해하기가 매우 어렵습니다._
+
+## 방법론의 역할
+
+**방법론은 개발자가 사용자의 문제를 더 효과적으로 해결할 수 있도록 돕는 것이 목적입니다.**
+
+방법론은 단순히 개발자를 위한 것이 아닙니다.
+
+개발자가 좋은 결과를 내려면, **사용자의 문제와 요구사항을 정확히 이해해야 합니다.** 사용자의 문제를 모르면 좋은 해결책을 만들 수 없습니다.
+
+### 방법론 요구 사항
+
+**Feature-Sliced Design**이 충족해야 할 두 가지 요구사항:
+
+1. **Feature, Process, Entity를 구성하는 명확한 방법 제시**
+    * _코드 분할 기준과 명명 규칙을 구체적으로 정의_
+
+2. **[변화하는 요구사항에 유연한 아키텍처 제공][refs-arch--adaptability]**
+
+## 참고 자료
+
+* [(포스트) 명확한 작업 정의 가이드 (+ 토론)][disc-src]
+    > _**이 문서는 해당 토론을 바탕**으로 작성되었습니다. 원문은 링크를 참고하세요._
+* [(토론) Feature 분해 방법론][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