- *신규 팀원이 독립적으로 업무를 하기까지 시간이 오래 걸립니다*

- *아키텍처 설계 원칙이 없어, 개발자마다 다른 방식으로 문제를 해결합니다*

- *거대한 모놀리스에서 데이터와 흐름을 추적하기 어렵습니다*

- *기능 간 불필요한 의존성이 생깁니다*

- *한 페이지의 상태(store) 변경이 다른 페이지 동작에 예기치 않은 영향을 줍니다*

- *비즈니스 로직이 여러 곳에 흩어져 있어 흐름을 추적하기 어렵습니다*

- 같은 계산, 검증 로직이 여러 군데에서 **반복** 구현되어, 수정할 때 모든 위치를 일일이 고쳐야 합니다

- 동일한 버튼이나 팝업 컴포넌트가 스타일, 동작만 조금 다른 여러 버전으로 중복 존재합니다

- 유틸 함수들이 규칙 없이 계속 쌓여, 어떤 함수가 있는지 찾기 어렵고 중복도 많습니다

이상적인 아키텍처를 위한 핵심 요구사항은 다음과 같습니다.

sidebar_label: Knowledge types

프로그래밍의 기초가 되는 지식으로, 시간이 지나도 크게 변하지 않습니다:

- 프로그래밍 언어의 기본 원리와 API

- (선택적으로) 개발 환경과 배포 도구

- 팀 내 개발 규칙과 관례

이러한 지식은 다른 프로젝트에서는 크게 가치가 없지만, **신규 팀원이 프로젝트에 기여하기 위해서는 반드시 필요합니다.**

- 아키텍처가 더 많은 책임을 지도록 설계

- 새로운 팀원의 온보딩 과정을 단순화

sidebar_label: Naming

개발자들은 각자의 경험과 관점에 따라 같은 대상을 다르게 부르는 경우가 많습니다. 이는 팀 내에서 혼동을 유발할 수 있습니다. 예를 들어:

이러한 표준 용어를 사용하는 것은 매우 중요합니다.

- 팀 내 의사소통이 명확해집니다

- 새로운 팀원의 적응이 쉬워집니다

- 커뮤니티에 도움을 요청할 때도 원활한 소통이 가능합니다

- `FSD#process` vs 애플리케이션의 시뮬레이션 프로세스

- `FSD#page` vs 로그 페이지

- `FSD#model` vs 자동차 모델

예를 들어, 개발자가 코드에서 "process"라는 단어를 보았을 때 **어떤 의미인지 해석하는 데 시간이 걸릴 수 있습니다.** 이러한 **충돌은 개발 효율을 저하시킬 수 있습니다.**

따라서 프로젝트 용어집(glossary)에 FSD 특유의 용어가 포함되어 있다면, 팀원 및 비기술적 이해관계자와의 커뮤니케이션에서 주의해야 합니다.

1. **기술적 커뮤니케이션**

- FSD 용어 사용 시 FSD 접두어 사용을 권장합니다.

- 예: 이 기능을 FSD features 계층으로 이동하는 것이 좋겠습니다.

2. **비기술적 커뮤니케이션**

- FSD 관련 용어는 지양하고, 일반적인 비즈니스 용어를 사용합니다.

- 예: 코드 구조 대신 기능이나 목적 중심으로 설명합니다.