프레임워크 vs 라이브러리
프레임워크는 “내 코드를 호출하는” 것이고, 라이브러리는 “내가 호출하는” 거예요.
이 구분이 중요한 이유는 코드의 제어권이 어디에 있는지를 결정하기 때문이에요. 프레임워크를 쓰면 규칙을 따라야 하지만, 그 대가로 많은 것을 대신 해결해줘요.
라이브러리 vs 프레임워크
라이브러리: 내가 필요할 때 호출한다 (React, lodash)
프레임워크: 프레임워크가 내 코드를 호출한다 (Next.js, Remix)
Plain Text
복사
비유하자면 연필과 프린터의 차이예요.
연필(라이브러리)은 내가 쥐고 원하는 대로 사용해요. 글씨체도, 필압도, 어디에 쓸지도 내가 정해요. 마음에 안 들면 다른 필기구로 바꿀 수 있죠.
프린터(프레임워크)는 달라요. 내가 할 수 있는 건 허용된 입력(문서)을 주고, 허용된 출력(인쇄물)을 받는 것뿐이에요. 프린터 내부가 어떻게 동작하는지는 알 수 없고, 알 필요도 없어요. 그 제약을 감수하는 대가로 편리함을 얻어요.
핵심: 라이브러리는 내가 제어권을 갖고, 프레임워크는 프레임워크가 제어권을 가져요. 이것이 “제어의 역전(Inversion of Control)”이에요.
React는 라이브러리다
React는 라이브러리예요. 화면을 그리는 코드가 눈에 보여요.
ReactDOM.createRoot(document.getElementById("root")).render(<App />);
TypeScript
복사
이 한 줄을 지우면 아무것도 렌더링되지 않아요. renderToString을 언제, 어떻게 호출할지는 개발자가 결정해요.
Next.js는 프레임워크다
반면 Next.js는 프레임워크예요. 파일을 pages/ 폴더에 두면 라우팅이 되고, getServerSideProps를 export하면 서버에서 실행돼요. 하지만 이게 언제, 어디서, 어떻게 호출되는지 코드에서 직접 확인할 수 없어요. Next.js가 알아서 처리하니까요.
"도대체 코드가 어디서 시작하는지 알 수가 없다"
Plain Text
복사
이게 프레임워크를 처음 접할 때 느끼는 당혹감이에요. 하지만 그 “알 수 없음”이 바로 프레임워크가 제공하는 가치예요. 복잡한 설정과 연결을 프레임워크가 대신 처리해주니까요.
직접 구현할 수 있는 것들—라우팅, 데이터 페칭, Hydration—이 바로 프레임워크가 대신 해주는 것들이에요.
메타프레임워크
Next.js, Remix, Nuxt 같은 것들을 메타프레임워크라고 불러요. “라이브러리 위에 올라간 프레임워크”라는 뜻이죠.
React 자체는 라이브러리예요. 화면을 그리는 것만 담당하죠. Next.js는 React 위에 라우팅, SSR, 빌드 시스템을 얹은 프레임워크예요.
메타프레임워크가 해결하는 의사결정들:
•
“라우터는 뭘 쓰지?” → 파일 기반 라우팅 제공
•
“SSR은 어떻게?” → 자동 설정
•
“번들링은?” → Webpack/Turbopack 내장
•
“개발 서버는?” → npm run dev
이런 결정들을 프레임워크가 대신 해줘요. 개발자는 비즈니스 로직에만 집중하면 돼요.
핵심: 메타프레임워크는 “라이브러리 위의 프레임워크”예요. React(라이브러리) 위에 Next.js(프레임워크)가 올라간 구조예요.
