프레임워크가 추상화하는 것들
프레임워크는 “직접 구현하면 복잡한 것들”을 대신 해줘요.
아래 표를 보면 프레임워크가 정확히 무엇을 해주는지 한눈에 알 수 있어요.
프레임워크가 해결하는 문제들
문제 | 직접 구현하면 | 프레임워크가 해주면 |
URL별 다른 페이지 | 라우트마다 핸들러 등록, 중복 코드 | 파일만 만들면 자동 라우팅 |
렌더링 전 데이터 | 핸들러에서 fetch 후 props 전달 | getServerSideProps export |
클라이언트 인터랙션 | client.tsx 작성, 번들링 설정 | 자동 Hydration |
번들 크기 최적화 | Webpack/Vite 설정, 수동 청크 분리 | 자동 코드 스플리팅 |
정적 페이지 생성 | 빌드 스크립트 작성, 경로 관리 | getStaticProps + getStaticPaths |
이미지 최적화 | Sharp 서버 구축, CDN 연동, srcset 관리 | next/image 컴포넌트 |
환경 변수 관리 | dotenv 설정, 서버/클라이언트 분리 | .env.local, NEXT_PUBLIC_ 접두어 |
개발 서버 | HMR 설정, 프록시 설정 | npm run dev |
프로덕션 빌드 | 최적화 설정, 번들 분석 | npm run build |
왜 직접 구현이 힘든가: 대표 사례
표만 보면 ’그냥 좀 귀찮은 정도 아니야?’라고 생각할 수 있어요. 대표 사례 3개를 깊이 보면 왜 프레임워크가 필요한지 체감돼요.
1. 번들 크기 최적화
문제: 앱이 커지면 JavaScript 번들도 커져요. 100KB → 500KB → 2MB…
직접 구현하면:
- Webpack/Vite 설정 파일 작성 (수백 줄)
- 어떤 모듈을 어떤 청크로 분리할지 결정
- import() 동적 임포트 위치 선정
- 번들 분석 도구 설정 및 모니터링
- 프리페칭 전략 구현
왜 어려운가: 청크를 너무 잘게 쪼개면 HTTP 요청이 많아지고, 너무 크게 묶으면 초기 로딩이 느려져요. 적정 균형점을 찾는 게 어려워요.
2. 이미지 최적화
문제: 이미지는 웹 페이지 용량의 50% 이상을 차지해요.
직접 구현하면:
- Sharp 같은 이미지 처리 서버 구축
- WebP/AVIF 변환 로직
- 디바이스별 크기 계산 (srcset)
- Lazy loading 구현
- Blur placeholder 생성
- CDN 연동 및 캐시 전략
왜 어려운가: 이미지 최적화는 여러 전문 분야의 교차점이에요. 이미지 포맷 지식, 서버 인프라, 네트워크 최적화, 브라우저 렌더링 이해가 동시에 필요해요.
3. 환경 변수 관리
문제: API 키, 데이터베이스 URL 같은 민감한 정보를 코드와 분리해야 해요.
직접 구현하면:
- dotenv 설정
- 서버 전용 변수 / 클라이언트 노출 가능 변수 분리
- 빌드 타임 vs 런타임 변수 구분
- 환경별(dev/staging/prod) 설정 관리
왜 어려운가: 보안 실수 한 번이 치명적이에요. 클라이언트에 노출되면 안 되는 변수를 실수로 노출하면 API 키가 유출돼요. 프레임워크의 NEXT_PUBLIC_ 같은 규칙은 이 실수를 원천 차단해요.
왜 이걸 알아야 하나
이 표를 이해하면 두 가지가 가능해져요:
1.
프레임워크 선택: 내 프로젝트에 필요한 기능이 무엇인지 파악하고, 그에 맞는 프레임워크 선택
2.
디버깅: 문제가 생겼을 때 “프레임워크가 대신 해주는 부분”에서 뭐가 잘못됐는지 추론
직접 구현 vs 프레임워크
이 모든 걸 직접 구현할 수 있어요. 하지만 매 프로젝트마다 같은 걸 반복하는 건 비효율적이죠. 프레임워크는 검증된 방식으로 이 문제들을 해결해둔 거예요.
핵심: 프레임워크는 마법이 아니라, “반복되는 문제를 미리 해결해둔 코드”예요. 표의 왼쪽 칸이 원리, 오른쪽 칸이 추상화예요.
