feature-sliced
diff --git a/‎i18n/kr/docusaurus-plugin-content-docs/current/about/motivation.md
Copy file name to clipboard
+149 b/‎i18n/kr/docusaurus-plugin-content-docs/current/about/motivation.md
Copy file name to clipboard
+149
@@ -0,0 +1,149 @@
+---
+sidebar_position: 2
+---
+
+# 동기
+
+**Feature-Sliced Design**은 [여러 개발자들의 연구와 경험을 결합하여][ext-discussions] 복잡하고 점점 더 커지는 프로젝트의 개발을 용이하게 하고, 비용을 줄이려는 아이디어에서 출발했습니다.
+
+물론 이 방법론이 모든 문제를 해결하는 만능은 아니며, [적용 가능한 제한 사항][refs-mission]이 존재합니다.
+
+그럼에도 불구하고 *이 방법론이 주는 전반적인 효용성*에 대해 많은 개발자들이 관심을 가지고 있습니다.
+
+:::note
+
+자세한 논의 내용은 [토론 게시글][disc-src]에서 확인할 수 있습니다.
+
+:::
+
+## 기존 솔루션으로는 부족한 이유
+<!--TODO: #existing-solutions -->
+> 일반적으로 다음과 같은 반문들이 제기됩니다:
+>
+> - *"이미 `SOLID`, `KISS`, `YAGNI`, `DDD`, `GRASP`, `DRY` 등 오랜 기간 확립된 접근 방식과 설계 원칙들이 있는데, 왜 새로운 방법론이 필요한가?"*
+> - *"모든 문제는 적절한 프로젝트 문서화, 테스트, 구조화된 프로세스로 해결될 수 있다."*
+> - *"모든 개발자들이 위의 원칙들을 제대로 따른다면 문제가 발생하지 않았을 것이다."*
+> - *"이미 필요한 모든 것이 발명되었고, 당신은 단지 그것을 제대로 활용하지 못할 뿐이다."*
+> - *"\{프레임워크_이름\}을 사용하라. 거기에는 이미 모든 것이 정해져 있다."*
+
+### 원칙만으로는 충분하지 않다
+
+**좋은 아키텍처를 설계하기 위해 원칙들이 존재하는 것만으로는 충분하지 않습니다.**
+
+모든 개발자가 이러한 원칙들을 완벽히 알고 있는 것도 아니며, 이해하고 올바르게 적용할 수 있는 사람은 더욱 적습니다.
+
+*설계 원칙들은 일반적인 지침이기 때문에, "확장 가능하고 유연한 애플리케이션의 구조와 아키텍처를 어떻게 설계해야 하는가?"에 대한 구체적인 답을 제공하지 못합니다.*
+
+### 프로세스가 항상 작동하지는 않는다
+
+*문서화, 테스트, 프로세스* 관리는 분명 중요하지만, 여기에 많은 비용을 들이더라도 **아키텍처 문제나 신규 인력의 프로젝트 적응 문제를 완전히 해결하지는 못합니다.**
+
+- 문서가 방대해지거나 오래되면 각 개발자가 프로젝트에 빠르게 적응하는 데 큰 도움이 되지 않습니다.
+- 모든 구성원이 아키텍처를 동일하게 이해하고 있는지 지속적으로 확인하는 데에도 상당한 리소스가 소모됩니다.
+- bus-factor에 대해서도 잊지 말아야 합니다
+
+### 기존 프레임워크를 모든 상황에 적용할 수는 없다
+
+- 기존 솔루션들은 보통 진입 장벽이 높아 새로운 개발자를 구하기가 어렵습니다.
+- 또한 대부분의 경우, 프로젝트 초기에 기술 스택이 이미 결정되기 때문에 **기술에 얽매이지 않고** “주어진 조건에서 작업할 수 있어야” 합니다.
+
+> Q: "내 프로젝트에서 `React/Vue/Redux/Effector/Mobx/{당신의_기술}`을 사용할 때, 엔티티의 구조와 이들 간의 관계를 어떻게 더 잘 구축할 수 있을까요?"
+
+### 결과적으로
+
+각 프로젝트는 팀원이 오랜 시간 몰입해야 하며, 다른 프로젝트에는 적용하기 어려운 *"눈송이처럼 독특한"* 형태로 남게 됩니다.
+
+> @sergeysova: *"이것이 바로 현재 프론트엔드 개발 분야에서 일어나고 있는 문제입니다. 각 리드는 각기 다른 아키텍처와 프로젝트 구조를 만들어 내지만, 그 구조가 시간의 시험을 견딜 수 있을지는 보장할 수 없습니다. 결과적으로 두세 명 정도의 개발자만 해당 프로젝트를 유지할 수 있고, 새로운 개발자가 참여할 때마다 다시 긴 적응 기간이 필요해집니다."*
+
+## 개발자들이 왜 방법론이 필요한가?
+
+### 개발자의 아키텍처 고민을 줄이고 비즈니스 기능에 집중
+
+이 방법론은 아키텍처 설계에 드는 리소스를 줄여 개발자들이 비즈니스 개발에 더 집중할 수 있도록 돕습니다. 동시에 아키텍처 구조는 표준화되어 프로젝트 간에 일관성을 제공합니다. 
+
+*이 방법론이 커뮤니티에서 신뢰를 얻기 위해서는 다른 개발자들이 이 방법론을 쉽게 익히고, 정해진 시간 내에 각자의 프로젝트 문제를 해결하는 데 도움이 되어야 합니다.*
+
+### 경험으로 입증된 솔루션 제공
+
+이 방법론은 복잡한 비즈니스 로직을 설계하는 데 검증된 솔루션이 필요한 개발자들을 위해 만들어졌습니다.
+
+또한, 이 방법론은 개발 중 발생하는 특정 문제와 사례를 다루는 베스트 프랙티스와 참고 자료들의 모음이기도 하므로, 개발과 설계 과정에서 여러 문제를 겪는 다른 개발자들에게도 유용할 것입니다
+
+
+### 프로젝트의 장기적인 건강성을 유지
+
+이 방법론은 *많은 리소스를 들이지 않고도 프로젝트에서 발생할 수 있는 문제를 사전에 해결하고 추적할 수 있도록* 돕습니다.
+
+**대부분의 경우 기술 부채는 시간이 지남에 따라 누적되며, 이를 해결하는 책임은 리드와 팀 모두에게 있습니다**
+
+이 방법론은 프로젝트 확장과 개발 과정에서 생길 수 있는 문제들을 미리 *경고할 수* 있게 해줍니다.
+
+## 비즈니스에게 왜 방법론이 필요한가?
+
+### 빠른 온보딩
+
+이 방법론을 통해 **이미 이 접근 방식에 익숙한 사람을 프로젝트에 고용할 수 있어 추가 교육이 필요하지 않습니다.**
+
+*덕분에 팀원들이 프로젝트를 더 빨리 이해하고 기여할 수 있으며, 다음 단계에 필요한 인력을 확보하는 데도 유리한 조건을 갖추게 됩니다.*
+
+### 검증된 솔루션 제공
+
+이 방법론을 통해 비즈니스는 *시스템 개발 중 발생하는 대부분의 문제들에 대한 해결책*을 얻을 수 있습니다.
+
+대부분의 경우, 비즈니스는 프로젝트 개발 중 발생하는 다양한 문제를 해결할 수 있는 프레임워크나 솔루션을 필요로 하기 때문입니다.
+
+### 프로젝트의 다양한 단계에 적용 가능
+
+이 방법론은 *프로젝트 지원 및 개발 단계뿐만 아니라 MVP 단계에서도* 프로젝트에 도움이 될 수 있습니다.
+
+네, MVP에서 가장 중요한 것은 *"미래를 위해 설계된 아키텍처가 아닌 기능"*입니다. 하지만 제한된 기한 내에서도 방법론의 베스트 프랙티스를 알고 있다면, 시스템의 MVP 버전을 설계할 때 합리적인 타협점을 찾아 *"적은 희생으로"* 해결할 수 있습니다 
+(기능을 "무작위로" 모델링하는 대신).
+
+*테스팅에 대해서도 같은 말을 할 수 있습니다*
+
+## 방법론이 필요하지 않은 경우
+
+- 프로젝트 수명이 짧은 경우
+- 프로젝트가 지속적인 아키텍처 관리가 필요하지 않은 경우
+- 비즈니스가 코드베이스와 기능 전달 속도 간의 연관성을 충분히 인식하지 못하는 경우
+- 비즈니스가 사후 지원보다 신속한 주문 처리를 우선해야 하는 경우
+
+### 비즈니스 규모
+
+- **소규모 비즈니스** - 대부분 즉시 사용 가능하며 빠른 솔루션이 필요합니다. 비즈니스가 성장하여 최소한 중간 규모에 가까워질 때, 고객 유지와 더불어 솔루션의 품질과 안정성에 투자할 필요성을 이해하게 됩니다.
+- **중간 규모 비즈니스** - 일반적으로 개발 과정에서 발생하는 문제들을 이해하고 있으며, *"기능 경쟁"*이 필요한 상황에서도 품질 개선, 리팩토링, 테스트에 시간을 투자합니다. 물론 확장 가능한 아키텍처 역시 중요하게 고려합니다.
+- **대규모 비즈니스** - 대규모 비즈니스는 보통 이미 광범위한 사용자층, 많은 직원, 그리고 자체적인 관행과 아키텍처 접근 방식을 가지고 있습니다. 따라서 외부에서 가져온 새로운 접근 방식을 적용하려는 경우는 드뭅니다.
+
+## 계획
+
+주요 목표는 [여기에 명시되어 있지만][refs-mission--goals], 앞으로의 방법론에 대해 우리가 기대하는 바를 추가로 설명할 필요가 있습니다.
+
+### 경험 결합
+
+현재 우리는 `core-team`의 다양한 경험을 하나로 모아 견고하게 단련된 방법론을 만드는 데 힘쓰고 있습니다.
+
+물론 그 결과가 Angular 3.0과 같은 결과물일 수도 있겠지만, 여기서 더 중요한 것은 *복잡한 시스템 아키텍처 설계라는 문제를 심도 있게 탐구*하는 것입니다.
+
+*현재 버전의 방법론에 대해 불만족스러운 점이 있지만, 커뮤니티의 경험도 함께 고려하여 모두가 합의할 수 있는 단일하고 최적의 솔루션에 도달하는 것이 목표입니다.*
+
+### 사양을 넘어선 생명력
+
+모든 것이 계획대로 진행된다면, 이 방법론은 단순히 사양과 툴킷에만 국한되지 않을 것입니다.
+
+- 보고서나 기사들이 생길 수도 있습니다.
+- 방법론에 따라 작성된 프로젝트를 다른 기술로 마이그레이션하기 위한 CODE_MODE가 있을 수 있습니다.
+- 이로 인해 대규모 기술 솔루션의 유지보수자들이 이 방법론을 활용할 기회를 가질 수 있습니다.
+    - *특히 React의 경우, 다른 프레임워크에 비해 특정 문제를 해결하는 구체적인 방안을 제시하지 않는다는 점이 주요 문제로 남아 있습니다.*
+
+## See also
+
+- [(토론) 방법론이 필요하지 않나요?][disc-src]
+- [방법론의 목표와 한계에 대한 설명][refs-mission]
+- [프로젝트에서 다루는 지식의 유형][refs-knowledge]
+
+[refs-mission]: /docs/about/mission
+[refs-mission--goals]: /docs/about/mission#goals
+[refs-knowledge]: /docs/about/understanding/knowledge-types
+
+[disc-src]: https://github.com/feature-sliced/documentation/discussions/27
+[ext-discussions]: https://github.com/feature-sliced/documentation/discussions