React 프로젝트를 하다 보면 코드 구조가 복잡해지는 순간이 찾아옵니다.
처음에는 괜찮지만, 시간이 지날수록 특정 기능을 찾기 힘들고,
수정하려고 들어갔다가 다른 부분까지 영향을 주는 일이 생기기도 하죠.
이럴 때 필요한 것이 바로 모듈화입니다.
이번 글에서는 모듈화가 무엇인지, 왜 필요한지, 그리고 어떤 상황에서 해야 하는지에 대해
간단한 예시와 함께 정리해보려고 합니다.
모듈화란 무엇인가요?
모듈화는 기능 단위로 코드를 잘게 나누고, 각각을 독립적인 단위(모듈)로 관리하는 것을 말합니다.
즉, 하나의 파일이나 함수가 너무 많은 역할을 하지 않도록, 책임을 분리하는 작업이에요.
예를 들어 API 요청, UI 렌더링, 상태 관리가 한 컴포넌트 안에 모두 들어있다면
이들을 각각 나눠서 관리하는 것이 모듈화라고 할 수 있습니다.
모듈화는 언제 해야 할까요?
모듈화를 꼭 해야 할 때는 보통 아래와 같은 경우입니다.
1. 코드가 길어지고 복잡해질 때
처음에는 괜찮았던 파일이 점점 길어져서,
한눈에 읽기 어려워지고 특정 로직을 찾기 어려워진다면, 그건 모듈화 신호입니다.
2. 같은 로직을 여러 곳에서 쓰게 될 때
예를 들어 날짜 포맷, 폼 검증 같은 유틸 함수는 반복적으로 쓰일 가능성이 높습니다.
이럴 때는 별도 파일로 빼두고 import해서 사용하는 것이 효율적입니다.
3. 기능 단위로 책임을 나누고 싶을 때
하나의 컴포넌트나 파일에서 너무 많은 역할을 하고 있다면,
기능별로 나누는 것이 유지보수에 훨씬 유리합니다.
4. 협업 시 충돌이나 혼선을 줄이고 싶을 때
팀 작업에서는 각자의 영역을 명확히 구분하는 것이 중요합니다.
모듈화된 구조는 역할 분담을 자연스럽게 만들어줍니다.
모듈화 예시 (Before vs After)
예를 들어, API 요청을 컴포넌트 내부에서 직접 하고 있다고 가정해볼게요.
Before – 하나의 컴포넌트에 모든 로직이 몰려 있는 상태
// Page.tsx
useEffect(() => {
fetch('https://api.example.com/data')
.then(res => res.json())
.then(setData);
}, []);
After – API 요청을 별도 모듈로 분리한 상태
// api/getData.ts
export const getData = async () => {
const res = await fetch('https://api.example.com/data');
return res.json();
};
// Page.tsx
useEffect(() => {
getData().then(setData);
}, []);
이처럼 기능 단위로 코드를 분리하면 훨씬 더 깔끔하고,
다른 곳에서도 쉽게 재사용할 수 있게 됩니다.
모듈화할 때 팁
- 너무 잘게 쪼개기보다는 기능 단위로 나누는 것이 중요합니다.
- 폴더 구조를 미리 설계해두면 나중에 파일이 많아져도 정리하기 쉬워집니다.
- 네이밍은 기능이 드러나는 이름으로, 가독성이 좋게 작성하는 게 좋습니다.
⭐ 실무에서의 모듈화 – 폴더 구조와 구조화 팁
실제로 프로젝트를 진행하면서 가장 효과를 느낀 부분은 폴더 구조를 명확히 나눴을 때였습니다.
파일이 많아질수록 어디에 어떤 코드를 둬야 할지 애매해지기 쉬운데,
초반에 구조를 잘 나눠두면 협업도, 유지보수도 훨씬 수월해지더라고요.
예를 들어 다음과 같이 폴더를 정리하면 기준이 생기고,
새 기능을 추가할 때도 자연스럽게 자리를 찾아갑니다.
src/
├── components/
├── pages/
├── hooks/
├── api/
├── utils/
├── constants/
└── types/
또는 규모가 크지 않은 프로젝트라면, 기능 단위로 묶는 방식(feature-based) 도 많이 사용합니다.
features/
└── auth/
├── AuthPage.tsx
├── authApi.ts
├── useAuth.ts
└── authTypes.ts
이렇게 구성하면 한 기능에 필요한 파일들이 한 폴더에 모이게 되어서,
관련된 로직을 파악하거나 수정할 때 훨씬 편해요.
처음부터 완벽할 필요는 없지만, 기준을 갖고 정리해두는 것만으로도 큰 차이가 생깁니다.
특히 협업할 때 역할 분담도 명확해지고, 코드 리뷰 시에도 파악이 쉬워집니다.
모듈화할 때 주의할 점
모듈화는 무조건 많이 나눈다고 좋은 건 아닙니다.
오히려 지나치게 세분화하면 구조가 더 복잡해지고,
코드를 따라가기 어려워질 수 있어요.
예를 들어, 특정 컴포넌트에서만 사용하는 훅이나 함수라면
공통 디렉토리로 빼기보다는 그 컴포넌트 폴더 안에 두는 게 더 낫습니다.
핵심은 “기능 단위의 관심사 분리”이지
“최대한 많이 쪼개기”가 아니라는 점을 기억해 주세요.
모듈화 후, 실제로 이렇게 달라졌어요
- 새 기능 추가 시, 어디에 코드를 넣을지 고민할 일이 줄어듦
- 코드 충돌 줄고, 팀원 간 작업 범위도 자연스럽게 분리됨
- 재사용성과 유지보수성이 높아짐
- 리팩토링이나 테스트도 훨씬 수월해짐
단순히 구조를 정리한 것 같지만,
개발 속도와 협업 효율까지 달라지는 걸 체감할 수 있었습니다.
마무리하며
모듈화는 귀찮다고 느껴질 수 있지만,
장기적으로 유지보수를 훨씬 쉽게 만들어주는 작업입니다.
코드가 복잡해지기 전에 미리 구조를 잘 나눠두면
나중에 작업할 때 훨씬 수월해지고, 협업에서도 불필요한 충돌을 줄일 수 있어요.
작은 습관처럼 모듈화를 시작해보면, 어느 순간부터
더 깔끔하고 재사용성 높은 코드를 작성하는 자신을 발견할 수 있을 거예요.

'개발이야기 > Etc.' 카테고리의 다른 글
스킴(Scheme)이란? 앱에서 자주 쓰는 URL 스킴 개념 정리 (0) | 2025.04.15 |
---|---|
nginx 서버 버전 정보 노출, 왜 막아야 할까? (0) | 2025.04.09 |
SQL이란 무엇인가? SQL 이해하기 (0) | 2024.08.06 |
데이터베이스란 무엇인가? SQL 학습의 첫걸음 (0) | 2024.07.26 |
왜 SQL을 배워야 하는가? - 서론 (1) | 2024.07.23 |