## Overview 약 한 달간 진행한 AllClass 리라이팅 프로젝트가 드디어 완료되었다. 창업팀 해체라는 예상치 못한 변화 속에서도 시작한 프로젝트는 끝까지 마무리하고 싶었고, 이전에 세운 목표들을 성공적으로 달성할 수 있었다. 정량적 성과 분석과 함께 이번 리라이팅에서 얻은 인사이트들을 정리해본다. ## 예상치 못한 변화들 리라이팅을 진행하던 도중 많은 일들이 있었다. 가장 큰 변화는 9개월간 함께 창업을 도전하던 팀이 각자의 길을 찾게 되면서 자연스럽게 해체된 것이었다. 하지만 시작한 프로젝트는 끝을 보고 싶었다. 개인적으로도 기술적 성장을 위해 시작한 리라이팅이었고, 무엇보다 지난 2년간 쌓아온 경험과 학습을 완전히 정리하고 싶었다. 그래서 혼자서라도 끝까지 완료하기로 했다. ## 목표 달성 결과 ### 목표 1: 렌더링 전략 최적화 리라이팅 계획에서 세웠던 첫 번째 목표를 성공적으로 달성했다: - 랜딩 페이지(`/`): SSG 적용으로 정적 생성 - 강의 목록 페이지(`/[universityName]`): On-Demand ISR로 캐싱 최적화 - 강의 상세 페이지(`/[universityName]/[lectureId]`): 하이브리드 렌더링으로 강의 정보는 정적 생성, 리뷰는 클라이언트 페칭

Before: 8개 정적 페이지

After: 84개 정적 페이지

기존 `getServerSideProps`로만 서버사이드 페칭을 하던 방식에서 On-Demand ISR과 React Query를 조합한 하이브리드 렌더링 전략으로 전환했다. `generateStaticParams`를 통해 동적으로 생성하던 페이지들을 정적 빌드로 바꾸면서 84개의 정적 페이지를 생성할 수 있었다. 각 페이지별로 필요한 렌더링 전략을 고민하고 클라이언트 캐싱과 서버 캐싱의 적절한 분배를 구현하는 과정에서 많은 것을 배울 수 있었다. [상세한 구현 과정은 여기서](https://solplog.vercel.app/articles/post-8) 확인할 수 있다. ### 목표 2: 안정적인 리라이팅 환경 구축 Cypress를 통한 E2E 테스트를 구축하고 GitHub Actions로 자동화하여 push나 PR이 감지되면 테스트가 자동으로 실행되도록 했다. [상세한 과정은 여기서](https://solplog.vercel.app/articles/post-10) 확인할 수 있다. 특히 인상 깊었던 경험이 있다. 리뷰 작성 후 revalidate가 되지 않아 리뷰가 즉시 반영되지 않는 버그가 있었는데, 내가 알지 못했던 이 버그를 테스트 코드가 찾아줬다. 솔직히 좀 놀랐다. 테스트 코드의 중요성을 몸소 체험할 수 있었던 소중한 경험이었다. ## 아쉬웠던 점들 목표는 달성했지만 아쉬운 부분들도 있었다. 특히 기존 백엔드 API와의 호환성을 유지하려다 보니 몇 가지 제약사항이 발생했다. ### 좋아요 기능의 한계 가장 아쉬웠던 부분은 좋아요 기능이다. 필요한 건 "현재 로그인한 사용자가 해당 리뷰에 좋아요를 눌렀는지 여부"를 나타내는 `isLikedByUser` 같은 필드인데, 기존 API에는 이런 정보가 없어서 좋아요 상태를 정확히 체크할 수 없었다. 로컬 스토리지를 사용하는 방법도 고려했지만, 브라우저를 바꾸거나 다른 기기에서 접속할 때 동기화 문제가 생길 수 있어서 결국 구현하지 않기로 했다. ### 정적 생성의 확장성 이슈 현재는 모든 강의 상세 페이지를 정적 빌드하고 있지만, 페이지가 늘어날수록 빌드 타임이 증가한다는 단점이 있다. 이를 해결하기 위해 조회수가 많거나 인기가 많은 몇몇 강의만 선별해서 정적 생성하려고 했지만, 현재 그런 API가 존재하지 않아 구현하지 못했다. 작은 부분이지만 UX 개선에 도움이 될 수 있는 아쉬운 부분이다. ## 새롭게 생긴 관심사 ### 테스트에 대한 관심 이번 프로젝트를 진행하면서 Cypress로 E2E 테스트를 작성해보니 생각보다 재미있었다. 테스트 코드를 작성하고 그게 통과하는 걸 보니 뭔가 성취감도 있고, 코드 변경할 때도 좀 더 안심이 되었다. 아직 테스트에 대해 모르는 게 많지만, 이런 재미가 있다는 걸 알게 되어서 조금씩 더 공부해보고 싶다는 생각이 들었다. ### 초기 설계의 중요성 이번 리라이팅을 통해 처음부터 잘못 설계된 것을 고치는 게 얼마나 힘든지 몸소 체험했다. 새로운 프로젝트를 하게 된다면 이런 아쉬운 점이 생기지 않도록 초기 설계 단계에서 더 면밀하게 요구사항을 분석하고, 렌더링 전략이나 데이터 페칭 방식을 더 신중하게 고민해봐야겠다는 교훈을 얻었다. ## 정량적 성과 분석 ### 기술 스택 현대화

항목	구버전 (Before)	신버전 (After)	개선사항
Next.js	14.2.5 (Pages Router)	15.3.5 (App Router)	App Router 마이그레이션
React	18	19	React 19 안정 버전
TypeScript	JavaScript only	완전 적용	100% 타입 안전성 확보
라우터	Pages Router	App Router	라우터 시스템 전환

### 의존성 최적화

지표	구버전	신버전	개선율
dependency	23개	6개	74% 감소
dev dependency	5개	17개	개발 도구 강화
총 패키지 크기	397MB	485MB	TypeScript + 개발도구 추가

### 코드 품질 지표

지표	구버전	신버전	개선사항
총 파일 수	45개	69개	+53% (모듈화)
총 코드 라인	6,750줄	5,488줄	-18.7%
평균 파일 크기	80줄	51줄	-36%
TypeScript 적용률	0%	100%	완전한 타입 안전성
테스트 커버리지	없음	E2E 구축	자동화된 품질 보증
컴포넌트당 평균 크기	156줄	101줄	35% 감소
100줄 이상 큰 파일	41개	17개	58% 감소

### 에셋 최적화

지표	구버전	신버전	개선사항
총 에셋 크기	17MB	5.3MB	68.8% 감소
이미지당 평균 크기	400KB	189KB	52.7% 최적화

### 도메인 단위 아키텍처 재설계 **Before**: 기능별 분산 구조 (도메인 로직이 여러 곳에 흩어짐) ``` 리뷰 도메인 로직이 분산된 예시: /components/common/reviews/ → 리뷰 컴포넌트들 /components/common/modal/writereview/ → 리뷰 작성 모달 /pages/[universityName]/detail/[lectureId].jsx → 리뷰 페이지 /stores/useReviewStateStore.js → 리뷰 상태관리 /hooks/useReviewForm.js → 리뷰 폼 훅 /hooks/useReviewHandlers.js → 리뷰 핸들러 훅 문제점: 하나의 기능을 수정하려면 여러 폴더를 돌아다녀야 함 ``` **After**: 도메인 단위 구조 ``` 리뷰 도메인 로직이 한 곳에 집중: /domains/review/ /client/ → 리뷰 컴포넌트, 훅, 모달 등 /server/ → 서버 컴포넌트 /shared/ → 리뷰 타입, 유틸리티 /styles/ → 리뷰 관련 스타일 개선점: 리뷰 관련 모든 것이 한 폴더에 응집되어 관리 편함 /domains/auth/ → 인증 관련 모든 로직 /domains/lecture/ → 강의 관련 모든 로직 /domains/mypage/ → 마이페이지 관련 모든 로직 ``` 주요 개선사항: - Pages Router에서 App Router로 새로운 라우터 시스템 적용 - 4개 도메인으로 명확한 구조 분리 - client/server/shared로 관심사 분리 - 배럴 익스포트를 11개에서 45개로 확대하여 모듈 인터페이스 체계화 결합도/응집도 개선: - 리뷰 수정 시 6개 폴더에서 1개 도메인만 수정하면 됨 - 관련 기능들(컴포넌트+훅+타입+스타일)이 한 도메인에 집중 - 도메인 간 경계가 명확해져 사이드 이펙트 최소화 - 배럴 익스포트를 통한 명확한 인터페이스 제공 ### 빌드 및 번들링 성과 #### 빌드 성능

버전	빌드 시간	정적 페이지 수	.next 폴더 크기
구버전	6.66초	8개	36MB
신버전	10.64초	84개	374MB

*신버전이 더 오래 걸리는 이유: TypeScript 컴파일 + 10.5배 더 많은 정적 페이지 생성* #### 번들 크기 최적화

페이지	구버전	신버전	개선율
강의 목록 페이지	183 kB	138 kB	25% 감소
강의 상세 페이지	249 kB	146 kB	41% 감소

핵심 개선사항: - 코드 스플리팅 최적화로 무거운 단일 청크(77.4 kB)를 작은 모듈 단위(최대 4.72 kB)로 분할 - Tree Shaking 효과로 의존성 74% 감소, 번들 경량화 ### 성능 개선 결과

Before

After

#### Core Web Vitals 개선

메트릭	Before	After	개선율
First Contentful Paint	2.1s	0.5s	76% 개선
Largest Contentful Paint	2.5s	0.7s	72% 개선
Speed Index	4.6s	0.9s	80% 개선
Total Blocking Time	0ms	20ms	약간 증가
Cumulative Layout Shift	0	0	동일

#### Lighthouse 점수

카테고리	Before	After	개선사항
Performance	69	100	+31점
Accessibility	94	96	+2점
Best Practices	89	98	+9점
SEO	100	92	-8점

## 마무리 개선 전과 개선 후의 수치들을 비교해봤을 때 나름 유의미한 성과라고 생각이 들어서, 아쉬운 만큼 기분이 좋았다. 약 2년동안 진행한 프로젝트에서 얻은 소중한 경험들과 기술적인 이슈들을 포함한 모든 과정들은 앞으로의 개발에도 큰 자산이 될 것이라고 생각한다. 이번 리라이팅을 통해 많은 것을 배울 수 있었다: - 렌더링 전략에 대해 조금 더 이해하게 되었고, 상황에 맞는 선택의 중요성을 느꼈다 - 테스트 자동화가 생각보다 재미있고 유용하다는 걸 알게 되었다 - 아키텍처 설계를 처음부터 잘못하면 나중에 고치기 얼마나 힘든지 깨달았다 - 정량적 지표로 성과를 측정해보니 개선사항이 더 명확하게 보였다 창업팀이 해체되어 혼자 마무리하게 된 프로젝트였지만, 오히려 끝까지 완주했기 때문에 더 의미 있는 경험이 되었다. 솔직히 중간에 그만둘까 싶은 순간도 있었는데, 끝내고 나니 뿌듯하다. 앞으로 새로운 프로젝트를 시작할 때는 이번에 얻은 교훈들을 바탕으로 더 나은 설계와 구현을 할 수 있을 것 같다.

Articles