📦 69. React Native 폴더 구조 설계 전략 — 유지보수와 협업을 위한 구조 만들기

---

React Native로 앱을 만들다 보면 처음에는 components, screens 정도만 있어도 충분하다고 생각했다.
그런데 프로젝트가 커지고 파일이 많아지니까, 점점 구조가 엉켜가기 시작했다.

처음엔 괜찮았는데,

• 어디에 어떤 파일이 있었는지 기억도 안 나고
• 만든 훅을 또 만들거나
• 기능이 추가될수록 관리가 점점 어려워졌다.

그래서 관심사 단위로 구조를 정리해보기로 했다.
이번 글은 실제로 적용하면서 얻은 폴더 구조 설계 전략과 그 경험을 정리한 것이다.

---

✅ 폴더 구조를 왜 신경 써야 하는가

항목	설명
유지보수	필요한 파일을 바로 찾을 수 있어야 유지보수가 편하다
협업	구조가 정리돼 있어야 팀원이 금방 이해하고 같이 작업할 수 있다
확장성	기능이 많아져도 구조가 무너지지 않는다
관심사 분리	로직, UI, 상태 등이 섞이지 않고 명확해진다

---

🧱 추천 폴더 구조 예시

src/
├── assets/         # 이미지, 폰트 등 정적 리소스
├── components/     # 재사용 가능한 공통 UI 컴포넌트
├── screens/        # 페이지 단위 컴포넌트
├── hooks/          # 커스텀 훅
├── navigation/     # 라우팅 관련 설정
├── services/       # API 호출, 외부 라이브러리 연동
├── store/          # 상태 관리 (Zustand, Redux 등)
├── utils/          # 유틸 함수
├── constants/      # 색상, 여백, 공통 스타일 값
└── types/          # 타입스크립트 타입 정의

프로젝트 규모와 팀 상황에 따라 조금씩 달라지지만,
중요한 건 기능별이 아니라 역할별로 나누는 것이 기준이 되어야 했다.

---

💡 폴더별 역할 정리

폴더	용도
components/	여러 화면에서 공통으로 사용하는 UI 조각들
screens/	페이지 단위 컴포넌트 (홈, 로그인 등)
hooks/	재사용 가능한 커스텀 훅
services/	axios, Firebase 등 외부 API 호출 관련
store/	전역 상태 관리 로직
constants/	색상, 폰트, 간격 등 전역 스타일 상수
types/	타입스크립트 타입 정의 (interface, enum 등)

---

🧩 기능 폴더 vs 관심사 폴더

분류 방식	설명	예시
관심사 기준	역할에 따라 나누는 방식	components, hooks, store, services 등
기능 기준	기능 단위로 모듈화	Home, Login, Search 등

보통은 둘을 혼합해서 썼다. 예를 들어 screens/Home 폴더 안에 해당 화면에서만 쓰는 컴포넌트나 훅을 같이 넣는 방식이 자연스러웠다.

---

🧠 실전 적용 팁

1. 컴포넌트 단위로 폴더를 만든다

components/
└── Button/
    ├── index.tsx
    ├── styles.ts
    └── test.tsx

스타일, 테스트, 구현을 한 폴더 안에 모아두면 구조가 깔끔해지고 관리가 쉬워진다.

2. API 요청은 services/로 분리한다

컴포넌트 안에 fetch 같은 API 호출을 넣으면 테스트도 어려워지고 재사용도 힘들어졌다.
서비스 계층으로 분리하니 유지보수가 훨씬 쉬워졌다.

3. 상태 관리는 store/에 정리한다

useUserStore, useThemeStore처럼 네이밍을 통일하고 역할별로 잘 나눠두면 찾기도 쉽고 확장도 편하다.

4. 공통 스타일 값은 constants/로 뺀다

색상, 여백, 폰트 크기 같은 값들이 여기저기 퍼져 있으면 일관성을 유지하기 어렵다.
상수화해두면 다크모드 적용이나 리디자인 시에도 손이 많이 안 간다.

---

⚙️ 구조 세팅 예시

// src/constants/colors.ts
export const COLORS = {
  primary: '#007bff',
  background: '#ffffff',
  text: '#333333',
};

// src/hooks/useKeyboard.ts
import { useEffect, useState } from 'react';
import { Keyboard } from 'react-native';

export function useKeyboardVisible() {
  const [isVisible, setVisible] = useState(false);

  useEffect(() => {
    const show = Keyboard.addListener('keyboardDidShow', () => setVisible(true));
    const hide = Keyboard.addListener('keyboardDidHide', () => setVisible(false));
    return () => {
      show.remove();
      hide.remove();
    };
  }, []);

  return isVisible;
}

---

🧠 실제 겪었던 일

초반에는 그냥 components, pages, utils 이렇게만 나눴다.
그렇게 몇 주 개발하고 나니 점점 구조가 복잡해졌고,
API 호출 로직이 UI 안에 섞여 있어서 재사용도 안 되고, 테스트도 어려워졌다.

리팩토링을 하면서 구조를 정리하기 시작했고,

• 공통 UI
• API 서비스
• 커스텀 훅
• 상태 관리
  를 각각의 폴더로 나누고 관심사에 따라 코드를 분리했다.

그렇게 바꾸고 나니 유지보수도 쉬워졌고,
협업할 때도 어디서 작업해야 할지 바로 알 수 있어서 효율이 확 올라갔다.

---

📦 폴더 구조는 단순히 정리의 문제가 아니라, 프로젝트를 함께 이해하는 방법이다.

---