프레임워크 vs 라이브러리

---

한 줄로 끝내기

라이브러리는 내가 부르고, 프레임워크는 나를 부른다.

이게 전부입니다. 나머지(IoC, DI, 콜백…)는 **“누가 먼저 움직이냐”**를 다른 말로 푼 것뿐입니다.

---

🎬 영화 촬영 비유

라이브러리 = 도구 상자

• 카메라, 조명, 마이크를 내가 꺼내서 씁니다.
• 언제, 어디서, 어떻게 찍을지는 **감독(내 코드)**이 정합니다.
• 예: axios, lodash, dayjs, zod

// 내가 주도권을 쥠
const data = await axios.get("/api/camps");
const sorted = lodash.sortBy(data, "name");

→ 내 코드 → 라이브러리 방향으로 호출

---

프레임워크 = 촬영 시스템 + 감독

• “이 장면에서는 이 타이밍에 네가 나와”라고 프레임워크가 정해 둡니다.
• 나는 **정해진 자리(규칙)**에 맞춰 코드를 넣습니다.
• 예: Next.js, React(엄밀히는 UI 라이브러리지만 프레임워크처럼 쓰임), Spring, NestJS

// Next.js가 "이 경로로 요청 오면 이 파일 실행해"라고 정함
export default async function Page() {
  const data = await fetch(...); // 내가 fetch 부르지만
  return <div>...</div>;       // "언제 이 컴포넌트를 그릴지"는 Next가 정함
}

→ 프레임워크 → 내 코드 방향으로 호출 (라우팅, 렌더 타이밍 등)

---

IoC(제어의 역전) — 어려운 말, 쉬운 뜻

IoC = Inversion of Control = 제어권 뒤집기

일상 비유: 식당

내가 요리사 역할은 하지만, **언제 플레이트에 올릴지는 뷔페(프레임워크)**가 정합니다.

---

“프레임워크가 나를 부른다”는 게 실제로 뭔 뜻?

1. 이벤트 / 콜백 — “그때 불러줄게”

useEffect(() => {
  // React: "화면 그린 다음에 이거 실행해"
  fetchData();
}, []);

• 내가 useEffect를 등록만 함
• 실제 실행 타이밍은 React가 정함

버튼 클릭도 마찬가지:

<button onClick={handleClick}>  // 클릭되면 handleClick 불러줘 — 등록

→ 브라우저/React가 이벤트 때 내 함수 호출

---

2. 규칙 맞춰 구현 — “이 형태로 만들어 오면 내가 씀”

Next.js App Router:

app/search/page.tsx  →  /search 요청 오면 이 파일 실행

• 파일 이름·폴더 구조 = 규약
• 내가 규약에 맞게 page.tsx 작성
• Next가 요청 올 때 내 페이지를 호출

Spring이면:

@RestController
public class CampController {
  @GetMapping("/camps")  // "GET /camps 오면 이 메서드 실행"
  public List<Camp> list() { ... }
}

→ 프레임워크가 HTTP 요청 받고 → 내 메서드 호출

---

3. DI(의존성 주입) — “필요한 거 내가 넣어줄게, 넌 일만 해”

손으로 다 만들면:

const db = new Database();
const repo = new CampRepository(db);
const service = new CampService(repo);

DI 컨테이너(NestJS, Spring 등):

@Injectable()
class CampService {
  constructor(private repo: CampRepository) {} // 컨테이너가 repo 넣어줌
}

• 누가 CampService를 만들고, 언제 주입할지 → 프레임워크
• 나는 클래스/함수 내용만 작성

→ 이것도 제어권이 프레임워크 쪽으로 넘어간 것

---

표 — 딱딱한 버전을 말로 풀기

---

헷갈리는 것 정리

“React는 라이브러리인데?”

맞습니다. 공식적으로는 UI 라이브러리입니다.

다만 useEffect, 라우터(Next), 상태관리까지 묶으면 프레임워크처럼 동작합니다.

• React만 → 라이브러리에 가깝 (내가 createRoot().render() 호출)
• Next.js → 프레임워크 (라우팅·빌드·서버 실행 흐름을 Next가 잡음)

“프레임워크 = 라이브러리 모음?”

반은 맞고, 핵심은 아님.

중요한 건 누가 main 역할을 하느냐입니다.

“라이브러리가 더 자유롭다?”

대체로 맞음. 대신 팀마다 코드 스타일이 제각각 될 수 있음.

프레임워크는 규칙 때문에 답답하지만, 10명이 와도 비슷하게 짭니다.

---

언제 뭘 쓰면 좋나 (실무 감각)

프레임워크 쓰기 좋을 때

• 팀이 크고 코드 모양 통일이 중요할 때
• 인증, 라우팅, SSR, API 규칙 같이 반복되는 걸 안 만들고 싶을 때
• → thankqcamping처럼 Next.js App Router 쓰는 이유

라이브러리만 쓰기 좋을 때

• 작은 스크립트, 위젯, 실험용 프로토타입
• “이 기능 하나만” 붙이고 싶을 때 (date-fns, zod 등)
• 프레임워크에 올인하기 싫을 때

---

3초 체크리스트 (면접·설계용)

• 앱이 시작될 때 누가 첫 실행을 정하나? → Next/Spring이면 프레임워크
• 내 함수는 주로 내가 부르나, 등록만 해두고 남이 부르나? → 후자면 프레임워크 패턴
• 갈아엎기 하려면 얼마나 아픈가? → 아프면 프레임워크에 깊이 묶인 것

---

신이 쓰는 스택에 대입해 보기

---

진짜 요약

프레임워크와 라이브러리의 차이는 “기능 많고 적음”이 아니라 “리모컨이 누구 손에 있나”입니다.

• 라이브러리: 내가 필요할 때 꺼내 씀
• 프레임워크: 정해진 타이밍에 내 코드를 꺼내 씀 (그게 IoC)

이 한 가지만 잡으면, DI·콜백·인터페이스 구현 같은 말들도 전부 **“제어권을 프레임워크에게 넘기는 방법”**으로 이어집니다.

---