폴더구조 고민과 회고

새로운 프로젝트를 시작하면서 폴더구조를 어떻게 잡아야할까 고민하다가 FSD 아키텍처를 제대로 알아보고 사용해보자 결심했다!

그 전에 CodIN 프로젝트에서 느꼈던 점들과 폴더구조 마이그레이션을 하는 과정에대한 회고글을 작성해 보고자 한다.

기존 폴더구조의 문제점

codin 프로젝트에서 새로운 기능이 덧붙여지고 프로젝트 규모가 커지면서 직면한 문제가 있었다.

1. 새로운 부원이 들어왔을때 온보딩 시간이 너무 오래걸리는 문제

2. 어떤 기능에 문제가 생겼을때 봐야하는 파일을 찾기위해 오랜 시간을 씀

3. 폴더구조에 대한 협의 없이 각자 따로 작업함으로 인한 일관성 없는 폴더구조

기존 폴더구조

컴포넌트 분리도 잘 안되어있어 페이지 파일 하나에 500줄이 넘는 파일도 있었다.

src/
├── api/                      # 모든 API 함수
│   ├── boards/
│   ├── chat/
│	└── ...
│
├── app/                      # Next.js 라우팅 + 일부 컴포넌트/타입 혼재
│   ├── (auth-required)/
│   │   ├── roomstatus/
│   │   │   ├── components/   #여기는 컴포넌트가 app 안에
│   │   │   ├── interfaces/
│   │   │   ├── constants/
│   │   │   └── utils/
│ 	│ 	├── ticketing/ 
│ 	│	│ 	├── eventId/
│ 	│	│ 	│	└─ page.tsx  # 컴포넌트 분리가 안돼서 500줄 넘는 페이지
│	│	│	└── page.tsx 
│   │   └── ...
│
├── components/               # 모든 컴포넌트
│   ├── Layout/
│   ├── Review/
│   ├── board/ 				#이건 또 컴포넌트가 밖에있음
│   ├── buttons/
│   ├── chat/
│   ├── comment/
│   └── ...
│
├── context/
├── ...
├── hooks/                    
└── utils/                    

다시보니 정말 혼돈 그 자체인 폴더구조였다ㅜㅜ

이 폴더구조에서 가장 큰 문제는 board 기능에 문제가 생기면 src/api/boards/ , src/components/board/, src/hooks/, src/interfaces/ 를 동시에 열어야 했다.

하나의 기능을 수정해도 여러개의 폴더를 왔다갔다하면서 작업하려니 정신이 없고 파일 찾는것도 일이었다...

그래서 feature기반 구조로 바꾸기로 결심했다.

Cursor로 폴더구조 마이그레이션하기

일단 당시 상황은 이랬다.
1. 프론트 개발 가능 인원이 나 혼자뿐이었다. (다른 팀원은 군대가거나 취업해서 나갔다...😭)
2. 신입 부원 모집이 얼마 안남은 상태였다. 그 전에 프로젝트 구조를 정리하고싶었다.
-> 인원이 적고 시간이 촉박한 상태

그래서 이 기회에 cursor를 열심히 활용해보려고 냅다 질문을 날렸다.

feature 기반 폴더구조로 개편할건데 마이그레이션 방향 제안해줘!!!!
결합도는 낮게, 응집도는 높게 할수있는 폴더구조였으면 좋겠어

여기서 커서의 답변을 통해 FSD 구조를 처음 알았던 것 같다.
(feature 기반 폴더구조는 대충 알았지만 정확한 명칭과 규칙에 대해선 모르고있었다)

gpt로 FSD 구조에대한 rule 파일을 생성한 후, cursor에 세팅하고,
제안하는대로 마이그레이션을 진행했다.

마이그레이션을 하면서 생긴 문제

일단 처음엔 너무 편하고 좋았다.
하나하나 파일을 옮기고 경로수정을 하지 않아도 알아서 해주었고,
프로젝트 전체를 손봐야하는 작업에 대한 심리적 부담이 줄었다.

하지만 AI가 만능은 아니었다.

1. 파일을 옮기면서 한글이 깨지는 문제가 발생했다.

다른 AI는 모르겠지만 cursor는 파일을 옮기면서 한글이 깨지는 상황이 종종 발생했다.
깨진 파일들을 복구해달라고 요청해도 복구하지 못할 때가 있었다.
글자가 많지 않아서 다행이었지만, 깨진 파일을 일일이 찾고, 수정하는것도 일이었다.

2. 세세한 부분들까지는 AI가 알 수 없다.

feature A에서만 쓰이는데 shared 폴더에 들어가있거나, feature A, B에서 같이 쓰이는 파일이 A폴더의 컴포넌트 폴더에 들어가 있는 등 내가 원하는대로 알잘딱하게 정리해주지 못한 것들이 있었다. 이런 부분들은 내가 직접 확인 후 파일을 옮겨야 했다.

->그래서 아직도 완벽히 정리한 상태는 아니다...

AI가 한것은 내가 한게 아니다

사실 저런 상황에서 AI를 사용한건 나쁘지 않은 선택이라고 생각한다!
하지만 나의 문제점은 AI가 한 결과를 내가 했다고 착각하고있었다는 것이다.

내가 직접 확인 후 파일을 옮겨야하는 과정에서 FSD 폴더구조에 대해 제대로 학습하지 않은 상태에서 하려니 머리가 복잡해졌고, 그러다보니 하기 귀찮아져서 점점 미루게되었다.

이러고나서 뭔가 했다고 이력서에 써놓더라도 막상 깊은 질문이 들어오면 제대로 대답할 수 없을 것 같았다. 사실 내가 한건 AI 버튼 딸깍 누른게 끝이기 때문이다.

앞으로는 AI를 사용하기 전에 다시 한 번 생각을 해보려한다.

그 작업에 대한 개념을 완벽하게 알고 있는지, AI가 하는 일들이 내가 당연히 할수있는 것들인지

위 질문들에 당당하게 그렇다 대답할 수 있을 때 AI를 사용하려고 한다!!

그래야 AI를 '활용' 했다고 이력서에 써놓을 수 있고, 내가 한 성과라고 얘기할 수 있을 것 같다.