추상계층이 헷갈리는 거네요.

일단 모든 소스코드든 라이브러리든 메모리에 들어가는 정보는, 컴파일러나 인터프리터에게는 호출가능한 모듈일 뿐입니다. 이런 물리적인 계층을 보지말고, 그 위의 논리적인 계층을 봐야합니다.

라이브러리는 톱, 망치, 삽같은 연장입니다. 사람이 들고 썰고, 바꿔들고 내려치고, 다시 바꿔들고 땅을 파는 겁니다.

프레임워크는 차, 비행기, 배같은 탈것입니다. 사람이 타서 엔진 켜고, 기어 넣고, 핸들 돌리고, 운전하거나, 조종하거나 해야합니다.

도구를 쓸 때, 급하면 썰어야 할 곳에 망치를 쳐도 됩니다. 땅 파야할 때 톱으로 땅을 긁어내도 됩니다. 사람은 도구를 선택하는 입장이기 때문에, 어떤 도구를 사용하든 원하는 것을 만들어낼 수 만 있으면 됩니다.

반면에, 탈것은 정해진 곳으로만 다녀야 합니다. 차를 타고 하늘을 날거나, 배를 타고 땅으로 갈 수는 없습니다. 하지만, 그 목적에 맞게 만들어져 있기 때문에, 톱이나 망치를 들고 먼저 탈것을 만들어야할 필요가 없습니다. 그저 정해진 규칙에 맞춰서 엔진, 기어, 핸들만 잘 돌리면 됩니다.

라이브러리와는 달리 프레임워크는 이미 프로그래밍할 규칙이 정해져 있습니다. 예를 들어, 설정파일로 사용되는 XML에 어떤 태그를 써야하며, 어떤 함수를 추가적으로 작성해야하고, 소스 파일을 어느 위치에 넣어야하며, DB와 연동하기 위해 무엇을 써넣어야 하는지 정해져 있습니다. 보통 이런 대부분의 작업은 프레임워크가 하고자 하는 일에 비하면 아주 작은 일이며, 사람은 극히 일부분만 조정함으로써 목적을 달성할 수 있습니다.

만약 프레임워크가 담당하는 부분이 내가 하고자 하는 목적과 다를 경우에는 어떻게 할까요? 그럼 그냥 프레임워크를 잘못쓴겁니다. 더 목적에 가까운 프레임워크를 찾아보면 대부분 있을겁니다. 없거나 구하기 힘들다면, 비슷한 프레임워크를 라이브러리 단계에서 변경해서 다른 프레임워크로 만들면 됩니다. 차를 튜닝한다음, 차를 다시 운전하면 된다는 말이지요.

혹시 프레임워크 없이 그냥 라이브러리로만 만들면 안될까요? 안될 이유가 어딨겠습니까? 그냥 다 다시 만들 능력과 시간과 여유만 있다면 그렇게 해도 되지요. 스스로 만든 프레임워크는 버그도 스스로 잡아야하지만, 남들이 만들어놓은 프레임워크는 쓰는 사람이 많은 만큼 그만큼 수정이나 업데이트도 빠릅니다. 기능이 마음에 안드는 부분이 있다면, 프레임워크를 고치면 됩니다. 처음부터 다 만드는 것보다는 싸게 먹히지요. 내일 당장 지방에서 서울로 출근해야하는데, 혼자서 차를 만들어서 타고 가야한다는 생각을 해보세요.

현대 개발 환경에서의 변화

하지만 2020년대 들어서는 이 경계가 많이 흐려졌습니다. 특히 프론트엔드 개발 영역에서 말이죠.

React의 애매한 위치

React는 공식적으로는 “라이브러리”라고 합니다. 하지만 실제로 사용해보면:

// React - 라이브러리라고 하지만...
function App() {
  return <div>Hello World</div>; // JSX 문법 강제
}

// 컴포넌트 라이프사이클 규칙 존재
useEffect(() => {
  // 마운트/언마운트 규칙을 따라야 함
}, []);

React는 JSX 문법을 강제하고, 컴포넌트 라이프사이클 규칙이 있으며, 상태 관리 패턴을 제시합니다. 이는 망치나 톱처럼 자유롭게 쓸 수 있는 도구라기보다는, 어느 정도 정해진 방식으로 운전해야 하는 탈것에 가깝습니다.

생태계의 프레임워크화

더 흥미로운 건 React “생태계”입니다:

# Create React App - 프로젝트 구조 강제
npx create-react-app my-app
# src/ public/ 디렉토리 구조가 정해짐

# Next.js - 완전한 프레임워크
# pages/ 디렉토리 기반 라우팅 강제
# getServerSideProps, getStaticProps 등 정해진 함수명 사용

React 자체는 라이브러리지만, Create React App, Next.js, Gatsby 같은 도구들이 프레임워크 역할을 대신합니다. 마치 톱(React)을 사서 왔는데, 작업대(CRA)와 안전 가이드(Next.js)가 함께 딸려와서 결국 정해진 방식으로 작업하게 되는 격이죠.

하이브리드 도구들의 등장

최근에는 프레임워크와 라이브러리의 경계를 넘나드는 도구들이 많아졌습니다:

Vite - 빌드 도구지만 프로젝트 템플릿 제공:

npm create vite@latest my-app -- --template react
# 디렉토리 구조와 설정이 미리 정해짐

TanStack Query - 라이브러리지만 사용 패턴 강제:

// 정해진 훅 사용법을 따라야 함
const { data, isLoading } = useQuery({
  queryKey: ['users'],
  queryFn: fetchUsers
});

Tailwind CSS - 유틸리티 클래스 라이브러리지만:

/* 정해진 클래스명 체계를 따라야 함 */
<div className="flex items-center justify-center">

이들은 도구(라이브러리)의 자유로움과 탈것(프레임워크)의 체계성을 동시에 갖고 있습니다.

실무에서의 현실

실제 개발 현장에서는 이런 일이 벌어집니다:

  1. React 프로젝트 시작 → CRA나 Next.js 선택 (이미 절반은 프레임워크)
  2. 상태관리 → Redux, Zustand 등 (각자만의 패턴 강제)
  3. 스타일링 → Styled-components, Emotion 등 (CSS-in-JS 패턴 강제)
  4. 라우팅 → React Router (선언적 라우팅 패턴 강제)

결국 “라이브러리”라고 시작했지만, 실제로는 여러 도구들의 조합으로 사실상의 프레임워크를 구성하게 됩니다.

Vue vs Angular vs React 비교

현재 3대 프론트엔드 기술을 위의 비유로 분류해보면:

Angular - 완전한 탈것 (비행기)

  • TypeScript 강제, 의존성 주입 패턴 강제
  • 디렉토리 구조부터 테스트 방식까지 모든 게 정해짐
  • 복잡하지만 대규모 프로젝트에서는 안정적

Vue - 친절한 탈것 (자동차)

  • 단일 파일 컴포넌트(.vue) 패턴
  • 하지만 필요하면 일부분만 사용 가능 (점진적 도입)
  • 프레임워크지만 학습 곡선이 완만함

React - 도구에서 탈것으로 진화 중

  • 처음엔 단순한 뷰 라이브러리 (톱)
  • 생태계가 발달하면서 사실상 프레임워크화
  • 자유도는 높지만 선택의 피로감 존재

결론: 경계의 모호함

옛날에는 “도구 vs 탈것”으로 명확히 구분할 수 있었습니다. 하지만 현재는:

  1. 라이브러리가 프레임워크화: React 생태계처럼 여러 라이브러리가 합쳐져 프레임워크 역할
  2. 프레임워크가 모듈화: Angular도 부분적 사용이 가능해짐
  3. 하이브리드 도구들: 상황에 따라 도구로도 탈것으로도 쓰이는 도구들

중요한 건 여전히 “누가 주도권을 갖느냐”입니다.

  • 내가 호출하면 라이브러리
  • 나를 호출하면 프레임워크

다만 현실에서는 둘이 섞여서 쓰이는 경우가 대부분이라는 점이 달라졌죠.

실무 팁: 프로젝트 시작할 때 “순수하게 라이브러리만 쓸 것인가, 프레임워크 체계를 따를 것인가”보다는 “팀의 숙련도, 프로젝트 규모, 개발 속도” 등을 고려해서 적절한 조합을 선택하는 게 중요합니다.

마치 여행갈 때 목적지와 인원수에 따라 자전거, 자동차, 기차, 비행기 중에서 선택하는 것처럼 말이죠.

프레임워크와 라이브러리의 차이는 무엇입니까?