FE 화면 디렉토리 어떤 구조로 생성하나요?

2에 맞게 꾸리면, feature라는 주제 아래 user, account, money라는 세 가지 기능이 있고 그 하위에 components, utils...가 있는 게 생각하시는 형태에 더 맞는 구조일 겁니다. BE에서 FE로 확장하시는 분들이 어려워하는 게 모듈이나 싱글턴 패턴을 적용하기가 쉽지 않고 클래스로 만든다고 하면 뭐가 그렇게 많다는 점이죠. feature split 아키텍쳐도 사실 거대한 global 위에 세워져야 해서 모듈이라고 볼 순 없습니다. npm 생태계가 보통의 FE의 구조라고 생각하시면 좋을 것 같네요.

FE(Frontend) 화면 디렉토리 구조는 프로젝트의 규모, 팀 구성, 사용하는 기술 스택 등에 따라 다양할 수 있지만, 보통 유지보수성과 확장성을 고려하여 설계합니다. 질문하신 내용을 기반으로 각각의 방법에 대한 장단점을 살펴보고, 일반적으로 추천되는 구조를 추가로 제안하겠습니다. 1. Path별 디렉토리 구조 장점 - URL과 디렉토리 구조가 일대일로 매칭되어 직관적입니다. - 페이지 간 이동 경로나 path를 설정하기 쉬워 RESTful한 API 설계와 연관짓기 편리합니다. 단점 - 디렉토리 구조가 깊어지고 복잡해질 수 있습니다. - 동일한 컴포넌트를 여러 디렉토리에서 중복 사용하기 어려움. - 파일이 많아질수록 유지보수 및 확장성이 떨어질 가능성이 큽니다. 2. 기능별 디렉토리 구조 장점 - 파일이 분리되어 재사용성이 높습니다. - 기능별로 파일을 그룹화하면 코드 가독성과 유지보수성이 높아집니다. 단점 - 디렉토리 구조와 URL이 매칭되지 않아 초기에 이해가 어려울 수 있습니다. - 작은 프로젝트에서는 오히려 과도한 구조일 수 있습니다. 추천하는 디렉토리 구조 (React 기준) src/ components/ User/ Edit/ Edit.js Edit.css Item/ Item.js Item.css Home/ Account/ Money/ Money.js Money.css pages/ User/ UserPage.js Home/ HomePage.js routes/ routes.js // path-to-component 매핑 설정 장점 - 중간 규모 이상의 프로젝트에서도 확장성과 유지보수성이 뛰어남. - 디렉토리가 지나치게 깊어지지 않으면서도 기능별로 적절히 분리. 결론 및 추천 - 작은 프로젝트라면 "기능별 디렉토리 구조(방법 2)"가 적합하며, HTML과 CSS만으로 작업한다면 이 방식을 추천드립니다. - 중간 이상 규모의 프로젝트에서는 컴포넌트 기반 설계와 pages/, components/ 디렉토리 분리를 통해 유지보수성과 확장성을 고려한 구조를 사용하는 것이 좋습니다. - RESTful API와 잘 맞추려면, **라우트 관리 파일(routes.js)**로 경로를 설정하고 이를 기준으로 URL과 화면을 매핑하는 방식을 고려해보세요.