과거
리액트를 배우는과정에서 폴더 구조에 대해 그렇게 크게 생각할 필요가 없었다. 배우는 과정과 혼자 만드는 작은 프로젝트들은 단순한 CRA로 진행하고 별 고민 없이 component들을 제작해 나갔다. 이렇게 진행해도 대부분 규모가 작다보니 폴더구조에 대해서 고민을 해보거나 필요성을 찾지 못했다.
하지만, 처음으로 토이 프로젝트를 진행하면서 component들이 무수히 많아지다보니 점차 필요성을 느끼게 되었다. 이 프로젝트를 진행했을 초반에는 프론트는 나 혼자뿐이여서 매일 하던방식으로 components폴더를 만들고component파일들을 모조리 때려 박았다. 일정한 규칙 없이 크게 page별 component파일을 제작하고 page이름으로 파일이름을 생성했다. 이후, 진행하다보니 page별로 나눈 component들을 더 작게 쪼개야 하는 상황에 부딪혔다. 더 작게 쪼개고 그 파일들을 component폴더에 다 때려박으니 한 폴더에 파일이 10개 이상 되면서 폴더구조를 보고 의도를 파악하기가 쉽지 않았다. 이 때는 유지, 보수라는 개념도 아예 모르고 있었고, 단순히 기능이 잘 구현되고 내가 만든 웹페이지가 잘 돌아가기만 하면 되지.. 왜 코드의 가독성이나 그런것들을 생각하지?? 라는 마음이 컸다.
이후, 기능이나 에러를 수정하거나 기능을 추가할 때, 코드 또한 간단한 변수명, 함수명도 의미 없이 대충 작성해서 나는 이해가 될 때까지 코드를 읽고 엉망징찬인 내 폴더 구조에서 몇 번씩 다시 봐야지 나의 의도를 파악할 수 있었다. 이렇게 되니까 시간적인 비용이 엄청 커졌고 효울적인 측면에서도 좋지 않았다. 필요성은 조금 느꼈지만 이때도 내가 아직 부족해서 그런가보다 하고 넘겼다. 여기서 부족하다는 의미는 유지 보수를 개념 같은 것들을 모른채 단순히 코드를 읽는 능력이 떨어진다는 생각이다.
진짜 문제는 다른 프론트 팀원이 한 분 들어왔을 때부터 시작됐다. 내가 새로 들어온 팀원 분에게 코드와 디렉토리 구조를 설명드려야 하는데 설명드리기가 쉽지가 않았고 너무 막막했다. 정해진 나만의 규칙과 컨벤션이 하나도 없다 보니까 설명하기도 쉽지 않았고 새로 들어오신 팀원 분도 이해하는데 오래걸렸을 것이라고 생각된다. 이렇게 되면 유지 보수 관점에서 효율적이지 못하고 시간적인 비용만 많이 소요된다. 드디어 폴더 구조에 대해서 고민해보며 하나씩 해결해나갔다. page를 기준으로 component폴더 안에 page별로 폴더를 분리해서 해당 폴더안에 component들을 집어넣었다.
단계별 구조
- 단일 리액트 파일
- 여러 리액트 파일
- 리액트 파일에서 리액트 폴더로
⇒ 페이지별로 component 분리
페이지별로 기능적으로도 겹치는 것들이 많아서 작업하기 편하고, 수정이나 추가할 때도 디렉토리 구조를 보고 한 눈에 파악하여 기능 수정이나, 추가가 쉬워졌다.
(나만의 리엑트 설계 기준과 가이드 라인)
리액트는 라이브러리다보니 프레임워크처럼 어디 부분에 어떻게 넣어야 된다는 일정한 규칙이 없이 리액트를 이용하는 우리가 자유자재로 넣어서 사용이 가능하다. 이 때문에 자유성은 높아지지만 자유성만 높인채 일정한 규칙을 나름대로 정해놓지 않으면 폴더구조가 엉망이 되기 마련이다.
그래서 일정한 가이드 라인을 정해야 한다.
현재 원티드 프리온보딩 코스를 진행하면서 하는 프로젝트 대부분의 구조
public
data // mock data
images // image file
src
API
components
common // ui적으로나 공통적으로 쓰이는 컴포넌트
pages // page별 큰 component
styles // 공통 style이나 style들
utils // 공통 로직 함수
hooks
redux // actions, reducer, selector
Router.js // routing을 하기 위한 파일
config.js
index.js
