협업을 위한 폴더 구조와 네이밍 규칙 총정리

 

 

팀 프로젝트를 하다 보면 이런 상황을 자주 겪습니다.

• “이 코드 어디에 있어?”
• “파일 이름 왜 이렇게 지었지?”
• “같은 기능인데 파일이 여기저기 흩어져 있네…”

👉 이런 문제의 원인은 대부분 폴더 구조와 네이밍이 통일되지 않았기 때문입니다.

 

 

---

 

1. 잘못된 폴더 구조 vs 좋은 폴더 구조

 

❌ 잘못된 예 (사람 기준 구조)

mina/
koo/
boo/

 

문제점

• 기능이 사람 기준으로 흩어짐
• 코드 찾기 어려움
• 협업이 아닌 개인 작업처럼 변함

 

 

❌ 또 다른 나쁜 예 (섞여있는 구조)

utils/
api/
components/
pages/
stock/
chat/
data/

👉 기준이 섞여 있음 (기능 + 역할 혼합)

 

 

✅ 좋은 예 (기능 기준 구조)

backend/
  user/
  order/
  payment/

frontend/
  user/
  order/
  payment/

 

장점

• 기능 단위로 코드가 모여 있음
• 유지보수 쉬움
• 협업 시 역할 분리 명확

---

2. 네이밍 컨벤션, 왜 중요한가?

코드는 결국 “읽는 것”이 더 많습니다.
👉 이름이 곧 문서입니다.

 

 

❌ 나쁜 네이밍 예

data1
temp
abc
getD

 

👉 문제:

• 의미를 알 수 없음
• 협업 시 해석 필요 → 시간 낭비

 

✅ 좋은 네이밍 예

userList
getUserData
fetchOrderHistory
calculateTotalPrice

👉 이름만 보고 역할이 바로 이해됨

 

---

3. 네이밍 규칙 정리

🔹 변수 / 함수 → camelCase

userName
getUserProfile
calculateDiscountPrice

 

🔹 클래스 / 컴포넌트 → PascalCase

UserService
OrderController
PaymentCard

 

🔹 파일명 → kebab-case (추천)

user-service.js
order-controller.js
payment-utils.js

 

🔹 DB 컬럼 → snake_case

user_id
created_at
order_price

 

🔹 API 경로 → 소문자 + kebab-case

/api/user-profile
/api/order-history
/api/payment-status

 

---

4. 흔히 하는 실수

• camelCase / snake_case 섞어 쓰기
• 파일명 규칙 사람마다 다르게 쓰기
• 의미 없는 이름 사용
• 축약어 남발 (usr, dt 등)

👉 결국 코드 이해도가 떨어짐

---

5. 좋은 구조와 네이밍의 효과

• 코드 찾는 시간 감소
• 협업 효율 증가
• 유지보수 쉬움
• 코드 리뷰 속도 향상

---

🔥 한 줄 정리

👉 “폴더는 기능 기준으로, 이름은 일관되게” 이 두 가지만 지켜도 프로젝트 퀄리티가 달라진다