
이번 글은 Loading.tsx에 관련된 강의를 보다가 1시간 졸고 화나서 적는 글이다.
이번 글에선 Loading.tsx를 언제 사용해야 하는지와 Suspense와의 차이점을 정리한 글이다.
Loading.tsx의 사용방법
Loading.tsx의 사용방법은 매우 간단하다.
그저 아래의 코드를 조건의 맞게 파일로 만들어주면 된다.
export default function Loading() {
return <p>Loading...</p>
}
조건 또한 매우 간단하다.
그저 파일 이름과 파일의 위치만 지켜준다면 자동으로 loading.tsx가 실행된다.
파일 이름
반드시 loading.tsx or loading.jsx
파일 위치
APP Router의 route segment 폴더 안
app/
└─ dashboard/
├─ page.tsx
└─ loading.tsx ← 여기
이 상태면 끝이다.
추가 설정, import, Suspense 감싸기 전부 필요 없다.
이런 설정을 끝낸 Loading.tsx는 이럴 때 화면에 표시된다
- /dashboard로 이동할 때
- /dashboard/page.tsx 또는 그 하위 Server Component가 아직 준비되지 않았을 때
Next.js가 자동으로 이 컴포넌트를 보여준다.

loading.tsx의 기본적인 사용방법을 알았으니, 이제 본론으로 들어가겠다.
Suspense VS Loading.tsx 차이점
| 구분 | Suspense | Loading.tsx |
| 구현 방식 | 수동 | 자동 |
| 구현 주체 | 개발자 | Next.js |
| 적용 방법 | 직접 위치를 정해 감쌈 | 파일 생성만으로 자동 적용 |
| 최적화 포인트 | 렌더링 제어 | Prefetch 경계 설정 |
| 서버 부하 | 개발자가 직접 관리 | Next.js 판단으로 감소 |
| 유연함 | 높음 | 낮음 |
| 동작 다 | 컴포넌트 단위 | Route Segment - 페이지 단위 |
Suspense와 Loading.tsx는 위와 같이 많은 차이점이 있지만 크게 3가지로 볼 수 있다.
- 구현 방식
- 최적화 관점
- 유연함
첫 번째 구현 방식부터 살펴보자면,
Suspense는 개발자가 직접 위치를 지정해줘야 하며, 수동으로 감싸지 않으면 동작하지 않는 반면,
Loading.tsx는 그저 파일을 만들기만 하면 되며, Next.js가 자동으로 Suspense를 생성해 준다.
두 번째 최적화 관점을 살펴보자.
Suspense는 렌더링 단위를 제어하며, 준비된 컴포넌트는 바로 렌더링 된다. 느린 컴포넌트만 fallback으로 대체한다.
Loading.tsx는 Loading.tsx 하위에 있는 컴포넌트는 Prefetch를 하지 않도록 경계를 설정해 주어 서버에서 가져오는 데이터 양을 줄여 결과적으로 서버의 부하를 줄여준다.
마지막으로 유연함을 보자면,
Suspense는 커스텀 로딩 상태를 표현 가능하며, 단위가 고정될 필요가 없어 매우 유연하며 자유롭다.
Loading.tsx는 파일 시스템 기반 컨벤션이며, Route Segment 단위로 동작한다. 페이지 단위 전용이기 때문에 다른 단위는 제어하기 힘들다.
언제 무엇을 사용해야 할까?
둘은 비슷하지만 다르다. 그렇다면 이 둘은 언제 무엇을 사용해야 할까?
loading.tsx를 사용할 때
- 페이지 단위 최적화가 필요할 때
- 페이지 전체 로딩 상태로 충분할 때
- Route Segment 단위 UX가 명확해야 할 때
Suspense를 사용할 때
- 컴포넌트 단위로 로딩 상태를 표현하고 싶을 때
- 커스텀 로딩 UI가 필요할 때
- 부분 렌더링이 UX에 도움이 될 때
'Next.js' 카테고리의 다른 글
| Parallel Route의 필요 이유 (0) | 2026.01.05 |
|---|