나의 컨벤션 V1 (폴더구조)

지금까지 개발을 하면서, 다른 사람들의 프로젝트를 보면 “와, 대박... 이 사람 진짜 잘한다!” 싶은 순간이 종종 있었다.
왜 그런지 생각해보니, 그 사람들에겐 자기만의 틀이 있었다.

반면 나는 새로운 프로젝트를 할 때마다 구조도, 네이밍도, 폴더 구성도 매번 달랐다.
심지어 같은 프로젝트를 할때도 일관성이 없다는 걸 알게 되었다.

그렇기에 나에게는 없는 자신만의 틀이 더 빛나보였던 것 같다.

그래서 이번 글은 이전 스터디에서 진행했던, 폴더 구조를 바탕으로 ⭐️나만의 틀⭐️을 조금씩 만들어 보려한다.

📌 정해진 구조 속에서 발견한 내가 선호하는 방식

회사를 다니던 도중, 조직개편이 이루어지면서 컨벤션이 명확한 프로젝트에 투입이 되기 시작했다.
자연스럽게 회사에서 정한 컨벤션으로 개발을 하게 되었고, 기존 코드들도 컨벤션에 맞게 리팩토링을 하는 작업도 했다.
처음에는 익숙하지 않았지만 빠르게 익숙해 졌다. 그런데 프로젝트의 규모가 클수록 폴더 구조의 아쉬움이 보였다.

📁 역할 단위로 나눈 구조

회사 컨벤션은 역할 단위로 폴더를 분리하고,
그 내부에서 페이지 단위로 폴더를 만드는 방식이다.

# common - 전체 공통
# page - 각 페이지
src
  ├── components
  │   ├── common
  │   └── [page]
  │
  ├── services
  │   ├── common
  │   └── [page]
  │
  ├── store
  │   ├── common
  │   └── [page]
  │
  ├── hooks
  │   ├── common
  │   └── [page]
  │
  ├── pages
  │   └── [page]
  │
  ├── utils
  │   ├── common
  │   └── [page]
  │
  └── constants
      ├── common
      └── [page]

프로젝트가 작았을 때는 페이지가 많지 않다보니 각 역할 안에 폴더 숫자가 많지 않아 크게 불편하지는 않았다.

그런데 프로젝트가 커지고 페이지가 많아지면서 상황이 달라졌다.
유지/보수를 하거나 기능을 추가될 떄마다 좌측 워크 스페이스 트리가 복잡해져갔다.

예를 들어, Login 페이지에서 컴포넌트와 API, 상태 관리 모두 수정해야 한다면 components/login, services/login, store/login 서로 다른 역할 안에 있는 흩어진 파일들을 찾아가 수정해야 했다.

새로운 페이지를 만들때도 각 역할별 폴더 안에 해당 페이지 폴더를 생성해야하는 불편함이 있었다.

"왜 이렇게 불편하지?"라는 생각을 해봤는데, 원인은 바로 낮은 응집도 였다. 대부분의 파일들은 해당 페이지에서만 사용되는 경우가 많았는데, 역할별로 분리되어 있다보니, 관련된 코드들이 한 곳에 모여있지 않았다.

📁 페이지 단위로 나눈 구조

나는 현재 Next.js를 사용하기 때문에 자연스럽게 페이지 기반으로 개발을 하게 되었다.
그래서 나는 페이지 단위로 폴더를 나누는 것을 기반으로 재사용성을 위해 가장 큰 틀로 세가지를 나누었다.

1. shared – 전역 범위
2. pages – 해당 페이지
3. features – 여러 페이지에서 공유되는 기능

src
├── shared
│   ├── components
│   ├── services
│   ├── store
│   ├── hooks
│   ├── utils
│   └── constants
└── pages
│   └── [page]
│       ├── components
│       ├── services
│       ├── store
│       ├── hooks
│       ├── utils
│       ├── constants
│       └── page.tsx
└── features
    └── [feature]
        ├── components
        ├── services
        ├── store
        ├── hooks
        ├── utils
        ├── constants
        └── README.md

이 구조로 프로젝트를 구성하니 확실히 응집도가 높아졌다.
또한 유지/보수할때도 분산되지 않아 훨씬 효율적이었다.

전역에서 재사용되는 코드는 shared에, 여러 페이지에서 사용되는 기능은 features에 정리하면서 재사용성을 챙길 수 있었다.

단점도 존재했다.
프로젝트 규모가 작을 경우에는 과도한 폴더 분리로 독이 될 수 있고, 재사용성을 위한 분리 기준이 명확하지 않다면 오히려 혼란스럽다는 것이었다.

그래서 기본 규칙 두가지를 정했다.

1. 사용되지 않는 폴더는 생성하지 않는다.
   → 사용되지 않는 폴더까지 만든다면, 오히려 수정해야할 곳을 찾기 어렵다.
   
2. features의 사용 기준과 사용되는 부분을 문서화하고, 프로젝트 관리자가 관리한다.
   → 공통코드라는 것이 사용자에 따라 기준이 애매하기 때문에, 프로젝트를 전반적으로 아는 사람이 필두로 관리하는 것이 가장 효율적이라 생각한다.

⭐️마무리

이번 기회에 폴더 구조를 정리하면서 그동안 내가 얼마나 주먹구구식으로 개발해왔는지를 돌아보게 되었다.

아직 이 구조를 실무에 바로 도입하진 못했지만, 나에게 맞는 틀을 정리하는 것은 생각보다 깊은 고민도 필요 했고, 그만큼 뿌듯한 일이었다.

물론 지금 정리한 이 구조로 내 틀이 완성되었다고 생각하지 않는다.
그저 나의 개발을 위한 최소한의 틀을 만들었다 생각한다.

이 글을 읽는 여러분도, 자신만의 틀을 정리하는 시간을 가져보면 좋은 경험을 하지 않을까 생각한다!