지난 글에서는 React로 개발했던 'ReelTrailer' 프로젝트를 다시 실행하고 기존 코드를 분석했습니다.
프로젝트를 확인하는 과정에서 TMDB와 YouTube API 호출 과정에서 발생하던 문제를 해결했고, 현재는 기존 서비스가 정상적으로 동작하도록 수정한 상태입니다.
이번 글에서는 Next.js로 마이그레이션하기 전에 현재 React Project의 상태를 기준점으로 기록하려고 합니다.
이번 측정의 목적은 단순히 성능 점수를 확인하는 것이 아니라,
- 기존 기능이 정상적으로 동작하는지
- 현재 프로젝트의 성능은 어느 정도인지
- 어떤 부분을 개선할 수 있는지
- Next.js 마이그레이션 이후 무엇이 달라졌는지
를 비교할 수 있는 기준을 만드는 것입니다.
1. 측정 목적
프로젝트의 목표는 단순히 React 프로젝트를 Next.js로 다시 만드는 것이 아닙니다.
기존 프로젝트를 다시 분석하면서 불필요한 코드와 구조를 정리하고, Next.js의 기능을 활용하여 데이터 처리 방식과 사용자 경험을 개선하는 것을 목표로 하고 있습니다.
2. 기존 기능 동작 여부 확인
먼저 기존 프로젝트에서 제공하고 있는 주요 기능들이 정상적으로 동작하는지 확인 했습니다.
| 기능 | 동작여부 | 비고 |
|---|---|---|
| 현재 상영 OTT 프로그램 조회 | V | TMDB API |
| 현재 상영 OTT 영화 조회 | V | TMDB API |
| 영화 예고편 | V | YouTube API |
| 영화 상세 모달 | X |
기존 프로젝트를 다시 실행했을때 처음에는 영화 데이터가 정상적으로 표시 되지 않았습니다.
원인을 확인하는 과정에서 TMDB와 YouTube API 호출 및 응답 처리 과정에 문제가 있는 것을 확인했고, 이를 수정했습니다.
수정 목록
- 환경변수 정리
- TMDB API 요청 URL 처리 개선
- JSON 응답 처리 로직 개선
- API 요청 헬퍼 함수 추가
- 영화 상세 정보 및 영상 데이터 처리 방식 개선
수정 이후 기존 React프로젝트가 정상적으로 데이터를 조회하고 화면에 표시되는 것을 확인했습니다.
3. 성능 측정 환경
기존 React프로젝트의 성능을 측정하기 전에 가능한 한 동일한 조건에서 비교할 수 있도록 측정 환경을 정했습니다.
측정 환경
- Browser: Chrome
- 측정 도구: Lighthouse
- 측정 대상: React 프로젝트
- Build 환경: Production Build('npm run build' -> 'npm run start')
- 측정 페이지: /index
- 네트워크 환경: Lighthouse 기본 설정
- Network throttling: Simulated Slow 4G
- CPU throttling: 4x slowdown
4. Lighthouse 측정
먼저 현재 React프로젝트의 Lighthouse 점수를 측정 했습니다.
측정 결과
| 항목 | React |
|---|---|
| Performance | 91 |
| Accessibility | 85 |
| Best Practies | 65 |
| SEO | 92 |
단순히 점수가 낮은 부분을 찾아 수정하는 것보다, 왜 해당 결과가 나왔는지 원인을 확인하는 것에 집중했습니다.
5. 초기 로딩 과정 확인
Lighthouse 측정과 함께 초기 페이지가 로딩되는 과정도 확인했습니다.
현재 React 프로젝트에서는 컴포넌트가 렌더링된 이후 API를 호출하고 데이터를 화면에 표시하는 구조가 사용되고 있습니다.
React Component
-> use Effect
-> API Call(TMDB / YouTube)
-> 응답 데이터 처리
-> State 업데이트
-> 화면 렌더링이 구조에서 개선 가능성을 발견했습니다.
- 서버에서 처리할 수 있는 데이터 요청이 클라이언트에서 처리되고 있음
- API 응답을 받은 이후 화면을 업데이트하는 과정이 필요함
- 컴포넌트에 데이터 요청과 UI 로직이 함께 존재하는 부분이 있음
- 로직이 클라이언트에서 실행되는 구조를 개선할 수 있음
6. API 요청 구조 확인
기존 프로젝트의 API 요청 흐름도 함께 확인했습니다.
현재 주요 데이터는 TMDB와 YouTube API를 통해 가져오고 있습니다.
React
├── TMDB
│ ├── OTT 상영 영화
│ ├── OTT 프로그램
│ └── 영화, 프로그램 상세 정보
│
└── YouTube
└── 예고편개선 가능성이 있는 부분은
- API 요청을 서버에서 처리
- API Key를 클라이언트에 노출하지 않는 구조로 변경
- 중복되는 데이터 요청을 줄이기
- 데이터 Fetching과 UI를 분리
7. 개선 대상
현재 프로젝트를 분석하고 측정하면서 다음과 같은 개선 대상을 정리했습니다.
7.1 Data Fetching
대부분의 데이터 요청이 클라이언트에서 실행되고 있습니다.
서버에서 데이터를 가져온 뒤 필요한 데이터만 클라이언트에 전달하는 구조를 적용할 수 있는지 검토할 예정입니다.
7.2 Component 책임
기존 컴포넌트 중에는
데이터 요청 + 데이터 가공 + 상태 관리 + UI 렌더링
이 하나의 컴포넌트에서 처리되는 부분이 있습니다.
마이그레이션 과정에서 각 컴포넌트의 책임을 다시 확인하고 필요한 경우 역할을 분리할 예정입니다.
7.3 Client/Server 영역
기존 React 프로젝트에서는 대부분의 코드가 클라이언트에서 실행 됩니다.
Next.js에서는 Server Component와 Client Component를 구분할 수 있기 때문에 각 기능이 실제로 클라이언트 실행을 필요로 하는지 확인해서 분리하려고 합니다.
7.4 불필요한 코드 및 의존성
기존 프로젝트를 다시 확인하면서 현재 기능에서는 사용하지 않거나 역할이 중복되는 코드가 있는지도 확인했습니다.
마이그레이션 과정에서 단순히 기존 코드를 그대로 옮기기 보다는
이 코드가 현재 필요한가?
를 기준으로 불필요한 코드와 의존성을 제거하려고 합니다.
8. 정리
| 구분 | React | Next |
|---|---|---|
| Routing | React Router | Next.js App Router |
| Data Fetching | Client 중심 | Server Data Fetchg |
| Component | Client 중심 | Server/Client 분리 |
| API | Client API 호출 존재 | 서버 처리 구조 |
| 코드 구조 | 기존 구조 유지 | 책임 기준으로 재구성 |
| 의존성 | 기존 프로젝트 기준 | 불필요한 의존성 제거 |
| UX | 기존 UI 유지 | 상세 페이지/Modal 개선 |
| 성능 | 측정 완료 | 마이그레이션 후 재측정 |
9. 이번 측정을 통해 알게 된점
이번 과정에선 단순히 Lighthouse 점수를 확인하는 것보다 리팩토링 전에 현재 프로젝트가 어떤 방식으로 동작하고 있는지를 파악하는 것이 중요하다는 것을 다시 확인했습니다.
특히 기존 프로젝트를 그대로 Next.js로 옮기는 것보다,
기존 구조 확인
문제 및 개선점 확인
개선 목표 설정
Next.js 구조 설계순서로 진행해야 마이그레이션의 의미가 있다고 판단했습니다.
React 프로젝트를 다시 분석하면서 과거에 작성했던 코드 중 현재 관점에서 개선해야할 부분도 많다고 생각했습니다.
단순히 새로운 기술을 적용하는 것이 아니라, 기존 코드를 다시 바라보고 더 나은 구조로 개선하는 과정 자체가 중요하다고 생각합니다.
10. 다음 작업
기존 React 프로젝트의 기능과 성능 측정을 완료했으므로 다음 단계에서는 실제 Next.js 프로젝트를 구성할 예정입니다.
Next.js 프로젝트의 구조와 마이그레이션 방향을 설계해보겠습니다.
- Next.js App Router 구조
- 기존 React Router의 마이그레이션
- Server/Client Component 분리 기준
- Data Fetching 구조
- API 처리 방식
- 기존 컴포넌트 재사용 여부
- 불필요한 코드 및 의존성 제서
