파일 안에 적을지, 전역으로 뺄지 헷갈리는 당신에게
1. 🤔 왜 이런 고민이 생길까?
타입스크립트를 쓰다 보면 이런 상황이 자주 생겨요:
“이 타입… 그냥 이 파일 안에서 선언할까?”
“아니면
types/폴더 만들어서 분리해야 할까?”“근데 분리하면 오히려 파일 왔다갔다 불편한데…?”
이런 고민의 본질은 단 하나입니다.
“이 타입이 ‘공통’인가, 아니면 ‘로컬’인가?”
2. ✅ 타입을 분리해야 하는 진짜 이유
타입을 types/*.ts로 분리하는 목적은 단순히 보기 좋게 정리하기 위해서가 아닙니다.
“의도를 명확히 하고, 타입을 공유하기 위해서”입니다.
| 분리 이유 | 설명 |
|---|---|
| 🔁 재사용 가능성 | 여러 페이지, 컴포넌트, API에서 동일한 타입을 쓰는 경우 |
| 🧩 도메인 모델화 | User, Log, Policy 등 도메인별 개념을 명확히 구분 |
| 🧠 이해도 향상 | 이름이 의미를 담고 있으면, 타입만 봐도 구조를 이해할 수 있음 |
| 🛠 유지보수 편의 | 타입이 바뀌었을 때, 한 곳에서 고치면 되니까 실수 방지 가능 |
✅ 예: User, MenuItem, SecurityLog, AccessPolicy, Tab, FilterOption
3. ❌ 분리하지 않는 게 좋은 경우
모든 타입을 분리하는 건 오히려 불편할 수도 있어요. 다음과 같은 경우에는 컴포넌트나 페이지 안에서 선언하는 게 낫습니다.
| 유지 이유 | 설명 |
|---|---|
| 📦 로컬 전용 타입 | 해당 페이지/컴포넌트에서만 쓰는 상태 타입, props 등 |
| ✂️ 복잡도 낮음 | `type Tab = 'daily' |
| 🧪 일회성 타입 | 특정 API 응답 구조를 파싱해서 한번 쓰고 마는 경우 |
✅ 예: ComponentProps, State, LocalOption, RowData, InternalFlag
4. 📐 기준을 정리하면 이렇게 됩니다
| 타입 특성 | 위치 추천 | 이유 |
|---|---|---|
| 여러 파일에서 재사용 | types/*.ts | 공유를 위한 목적 |
| 비즈니스 도메인 구조 반영 | types/*.ts | 도메인 레이어 분리 |
| 상태/props 전용 로컬 타입 | 해당 파일 내부 | 범위가 좁음 |
| API 응답 한 번 파싱용 | 해당 파일 내부 | 재사용 없음 |
5. 📌 정리: "타입 분리의 핵심은 스코프와 책임"
“스코프(Scope)”는 프로그래밍에서 “어디까지 영향을 미치느냐”, 즉 "변수나 타입이 어디까지 유효하게 적용되는 범위"를 말함
- 이 타입이 여러 곳에서 쓰이는가? →
types/*.ts - 이 타입이 오직 이 컴포넌트에서만 쓰이는가? →
해당 파일 내부 - 도메인 모델로 설명할 수 있는가? →
types/domain.ts에 정리 - 재사용할 가능성이 생길까? → 지금 당장은 아니더라도 나중을 고려
✨ 마무리 Tip
User,Log,MenuItem,Permission,Tab,Policy처럼 설명을 위한 이름이 붙는 타입은 대부분 분리하는 게 맞습니다.
- 반면
const FilterTabs: Tab[] = [...]같은 로컬 상수는 내부에 두는 게 편합니다.
✅ 전체 요약
타입을 분리할지 말지는 “코드가 의도를 잘 설명하고 있는가?”를 기준으로 판단하세요.
타입을 외부로 분리하는 건 코드의 이해 가능성과 유지보수성을 올리기 위한 수단일 뿐입니다.
프론트엔드 개발쟈!!