5주차 Unit 7.2 — 프레임워크 vs 라이브러리

Psj·2026년 5월 27일

F-lab

목록 보기
176/239

Unit 7.2 — 프레임워크 vs 라이브러리

F-LAB JAVA · 5주차 · Phase 7 · 제어의 역전 (IoC)

📌 학습 목표

이 Unit을 끝내면 다음을 답할 수 있어야 한다.

  • 프레임워크와 라이브러리 의 차이는?
  • 누가 흐름을 제어하는가 ?
  • 호출 방향 의 차이는?
  • 망치 vs 공장 비유는?
  • Hollywood Principle 이란?
  • jQuery 는 라이브러리인가 프레임워크인가 ?
  • Spring 이 프레임워크인 이유는?
  • 프레임워크의 IoC 는?
  • 둘의 경계가 모호한 경우는?

🎯 핵심 한 문장

라이브러리는 내 코드가 호출하여 제어권이 나에게 있고, 프레임워크는 프레임워크가 내 코드를 호출하여 제어권이 프레임워크에 있는 (IoC) 점이 결정적 차이다.
라이브러리 — 내가 필요할 때 꺼내 쓰는 도구로, 호출 방향이 "내 코드 → 라이브러리" 이고 제어의 흐름을 내가 가진다 (망치를 내가 휘두름).
프레임워크 — 내가 그 안에 들어가 일하는 틀로, 호출 방향이 "프레임워크 → 내 코드" 이고 제어의 흐름을 프레임워크가 가진다 (공장에 들어가 정해진 자리에서 일함).
이 차이를 Hollywood Principle ("Don't call us, we'll call you" — 우리에게 전화하지 마라, 우리가 부르겠다) 로 표현하며, 이것이 곧 IoC 다.
jQuery 는 내가 호출하므로 라이브러리, Spring 은 내가 만든 객체 (빈) 와 메서드 (컨트롤러) 를 Spring 이 생성·호출하므로 프레임워크다.

비유 — 망치 vs 공장

라이브러리 vs 프레임워크:

라이브러리 (망치):
  - 내가 필요할 때 꺼냄
  - 내가 휘두름 (호출)
  - 제어가 나에게
  - 내 코드 → 망치(라이브러리)

프레임워크 (공장):
  - 내가 공장에 들어감
  - 공장이 정한 자리에서 일함
  - 공장이 "이제 네 차례" (호출)
  - 제어가 공장
  - 공장(프레임워크) → 내 코드

Hollywood Principle:
  - "전화하지 마, 우리가 부를게"
  - 배우(내 코드)가 감독(프레임워크)에게 전화 X
  - 감독이 "액션!" 외칠 때 연기

호출 방향이 결정:
  - 라이브러리: 내가 부름
  - 프레임워크: 부름당함 (IoC)

→ 라이브러리(망치, 내가 호출) vs 프레임워크(공장, 호출당함=IoC).

🧭 9개 섹션 로드맵

1. 프레임워크 vs 라이브러리 정의
2. 누가 흐름을 제어
3. 호출 방향
4. 망치 vs 공장
5. Hollywood Principle
6. jQuery는?
7. Spring이 프레임워크인 이유
8. 경계가 모호한 경우
9. 면접 + 자기 점검

1️⃣ 프레임워크 vs 라이브러리 정의

1.1 라이브러리

라이브러리 (Library):

  재사용 가능한 코드 모음:
    - 내가 호출
    - 필요한 기능 가져다 씀
    - 제어권 = 나

1.2 프레임워크

프레임워크 (Framework):

  애플리케이션 골격:
    - 프레임워크가 호출
    - 내 코드를 끼워 넣음
    - 제어권 = 프레임워크

1.3 핵심 차이

핵심 차이:

  제어권:
    - 라이브러리: 나
    - 프레임워크: 프레임워크

  → IoC 여부

1.4 ILIC 의 맥락

// 라이브러리 사용 (내가 호출)
public class FreightCalculator {
    public BigDecimal calculate(Shipment s) {
        // Apache Commons (라이브러리) — 내가 호출
        BigDecimal weight = s.getWeight();
        return weight.multiply(BigDecimal.TEN);
        // StringUtils.isEmpty(...) 등 내가 호출
    }
}

// 프레임워크 (Spring 이 호출)
@RestController
public class ShipmentController {
    @GetMapping("/shipments/{id}")
    public Shipment get(@PathVariable Long id) {
        // 이 메서드를 Spring 이 호출 (제어가 Spring)
        return null;
    }
}

1.5 자기 점검 답변

프레임워크와 라이브러리의 차이는?

답:
1. 라이브러리:

  • 내가 호출
  • 제어 = 나

  1. 프레임워크:

    • 프레임워크가 호출
    • 제어 = 프레임워크

  2. 핵심:

    • 제어권

  3. IoC:

    • 프레임워크 = IoC

2️⃣ 누가 흐름을 제어

2.1 제어의 흐름

제어의 흐름:

  "프로그램 실행 흐름을 누가?"

라이브러리:
  - 내 코드가 흐름 제어
  - 라이브러리 호출

프레임워크:
  - 프레임워크가 흐름 제어
  - 내 코드 호출

2.2 라이브러리 흐름

// 라이브러리 — 내가 흐름 제어
public void process() {
    // 내가 순서대로 호출
    String data = readFile();        // 내 흐름
    String result = library.parse(data);  // 라이브러리 호출
    saveResult(result);              // 내 흐름
}
// 내가 흐름 결정

2.3 프레임워크 흐름

// 프레임워크 — 프레임워크가 흐름 제어
@RestController
public class Controller {
    @GetMapping("/api")
    public String handle() {
        // Spring 이 이 메서드를 적절한 때 호출
        // 흐름은 Spring 이
        return "result";
    }
}
// 프레임워크가 흐름 결정

2.4 제어권 표

항목라이브러리프레임워크
흐름 제어내 코드프레임워크
호출내가 함당함
IoCXO

2.5 ILIC 의 맥락

// 라이브러리 흐름 (내가 제어)
public class ShipmentBatch {
    public void run() {
        List<Shipment> shipments = loadShipments();   // 내 흐름
        for (Shipment s : shipments) {
            BigDecimal freight = calculator.calculate(s);   // 라이브러리 호출
            save(s, freight);   // 내 흐름
        }
        // 내가 전체 흐름 제어
    }
}

// 프레임워크 흐름 (Spring 제어)
@Service
public class ShipmentService {
    @Scheduled(cron = "0 0 * * * *")   // Spring 이 시간 되면 호출
    public void processBatch() {
        // 흐름(언제 실행)은 Spring 이 제어
    }
    
    @EventListener
    public void onCreated(ShipmentEvent e) {   // Spring 이 이벤트 시 호출
        // 흐름은 Spring 이
    }
}
record ShipmentEvent(Long id) {}

2.6 자기 점검 답변

누가 흐름을 제어하는가?

답:
1. 흐름 제어:

  • 라이브러리: 내 코드
  • 프레임워크: 프레임워크

  1. 라이브러리:

    • 내가 순서 결정

  2. 프레임워크:

    • 프레임워크가 호출

  3. IoC:

    • 프레임워크 = 제어 역전

3️⃣ 호출 방향

3.1 호출 방향

호출 방향:

라이브러리:
  내 코드 → 라이브러리
  (내가 호출)

프레임워크:
  프레임워크 → 내 코드
  (호출당함)

3.2 라이브러리 방향

라이브러리 방향:

  [내 코드] → 호출 → [라이브러리]

  - 내가 능동
  - 라이브러리는 수동

3.3 프레임워크 방향

프레임워크 방향:

  [프레임워크] → 호출 → [내 코드]

  - 프레임워크 능동
  - 내 코드 수동 (끼워짐)

3.4 방향이 IoC

방향이 IoC:

  프레임워크 → 내 코드:
    - 제어가 프레임워크
    - 내 코드 호출당함
    - = IoC

  → 호출 방향 역전

3.5 ILIC 의 맥락

// 호출 방향

// 라이브러리: 내 코드 → 라이브러리
public class ShipmentLogic {
    public void calculate(Shipment s) {
        BigDecimal result = MathUtils.round(s.getWeight());   // 내가 호출
        // 내 코드 → MathUtils (라이브러리)
    }
}

// 프레임워크: Spring → 내 코드
@Component
public class ShipmentHandler {
    @KafkaListener(topics = "shipments")   // Spring 이 메시지 시 호출
    public void handle(String message) {
        // Spring → 이 메서드 (호출당함)
    }
}
// 호출 방향이 반대 (IoC)

3.6 자기 점검 답변

호출 방향의 차이는?

답:
1. 라이브러리:

  • 내 코드 → 라이브러리

  1. 프레임워크:

    • 프레임워크 → 내 코드

  2. 방향:

    • 능동 vs 수동

  3. IoC:

    • 호출 방향 역전

4️⃣ 망치 vs 공장

4.1 망치 (라이브러리)

망치 (라이브러리):

  - 필요할 때 꺼냄
  - 내가 휘두름
  - 내가 통제

  → 내 도구

4.2 공장 (프레임워크)

공장 (프레임워크):

  - 내가 들어감
  - 정해진 자리에서 일함
  - 공장이 통제

  → 정해진 틀

4.3 비유 정리

비유 정리:

라이브러리 (망치):
  - 내가 주체
  - 도구 사용

프레임워크 (공장):
  - 공장이 주체
  - 틀 안에서 작업

4.4 선택 vs 따름

선택 vs 따름:

라이브러리:
  - 내가 선택해서 사용
  - 자유

프레임워크:
  - 규칙 따름
  - 제약 (틀)

4.5 ILIC 의 맥락

// 망치 (라이브러리) — 내가 사용
public class FreightUtil {
    public BigDecimal calc(Shipment s) {
        // 라이브러리(망치)를 내가 골라 씀
        return BigDecimalUtil.round(s.getWeight(), 2);
    }
}

// 공장 (프레임워크) — 틀 안에서
@RestController   // Spring 의 틀
@RequestMapping("/api/shipments")
public class ShipmentController {
    // Spring 이 정한 규칙(@GetMapping 등) 따름
    @GetMapping("/{id}")
    public Shipment get(@PathVariable Long id) {
        return null;
        // 공장(Spring)의 틀 안에서 작업
    }
}
class BigDecimalUtil {
    static BigDecimal round(BigDecimal v, int scale) { return v; }
}

4.6 자기 점검 답변

망치 vs 공장 비유는?

답:
1. 망치:

  • 라이브러리
  • 내가 휘두름

  1. 공장:

    • 프레임워크
    • 틀 안에서

  2. 주체:

    • 나 vs 공장

  3. 선택 vs 따름:

    • 자유 vs 규칙

5️⃣ Hollywood Principle

5.1 Hollywood Principle

Hollywood Principle:

  "Don't call us, we'll call you"
  "우리에게 전화하지 마라,
   우리가 부르겠다"

  → 프레임워크가 내 코드 호출

5.2 의미

의미:

  배우(내 코드):
    - 감독(프레임워크)에게 전화 X
    - 감독이 "액션" 외칠 때 연기

  → 제어가 프레임워크

5.3 IoC 표현

IoC 표현:

  Hollywood Principle = IoC:
    - 내가 호출 X
    - 호출당함
    - 제어 역전

→ 같은 개념

5.4 콜백 등록

// 콜백 등록 (Hollywood)
button.addClickListener(event -> {
    // 내가 등록만
    // 클릭 시 시스템이 호출 (we'll call you)
});
// 등록: 내가, 호출: 시스템

5.5 ILIC 의 맥락

// Hollywood Principle (ILIC)

// "전화하지 마, 우리가 부를게"
@Component
public class ShipmentEventHandler {
    
    // 내가 호출 X, Spring 이 이벤트 시 호출
    @EventListener
    public void onShipmentCreated(ShipmentCreatedEvent event) {
        // "we'll call you" — Spring 이 부름
        processNewShipment(event.shipmentId());
    }
    
    // 스케줄: 내가 호출 X, Spring 이 시간 되면
    @Scheduled(fixedRate = 60000)
    public void checkPendingShipments() {
        // Spring 이 1분마다 호출
    }
    
    private void processNewShipment(Long id) { }
}
record ShipmentCreatedEvent(Long shipmentId) {}
// 내 코드를 Spring 이 호출 (Hollywood = IoC)

5.6 자기 점검 답변

Hollywood Principle이란?

답:
1. 원칙:

  • "Don't call us, we'll call you"

  1. 의미:

    • 프레임워크가 호출

  2. IoC:

    • 같은 개념

  3. 예:

    • 콜백, 이벤트, 스케줄

6️⃣ jQuery는?

6.1 jQuery 분석

jQuery 는?

  라이브러리:
    - 내가 호출 ($("...").click())
    - 제어가 나
    - 필요할 때 사용

6.2 왜 라이브러리

왜 라이브러리:

  jQuery:
    - $(selector) 내가 호출
    - DOM 조작 내가 지시
    - 흐름 제어 = 나

  → 라이브러리

6.3 vs Angular/React

vs Angular (프레임워크):

Angular:
  - 프레임워크 구조
  - 생명주기 (프레임워크 호출)
  - 제어 = Angular

React:
  - 라이브러리 (자칭)
  - 하지만 프레임워크적 (렌더링 제어)
  - 경계 모호

6.4 판단 기준

판단 기준:

  "누가 호출?"
    - 내가 → 라이브러리
    - 그것이 → 프레임워크

  "제어가 어디?"
    - 나 → 라이브러리
    - 그것 → 프레임워크

6.5 ILIC 의 맥락

// 판단 기준 적용

// 라이브러리 (내가 호출)
public class Example {
    public void useLib() {
        // Jackson (라이브러리) — 내가 호출
        ObjectMapper mapper = new ObjectMapper();
        String json = mapper.writeValueAsString(shipment);   // 내가 호출
        // → 라이브러리
    }
}

// 프레임워크 (Spring 이 호출)
@RestController
public class Example2 {
    // Spring 이 요청 시 호출 → 프레임워크
    @PostMapping("/shipments")
    public void create(@RequestBody Shipment shipment) {
        // Spring 이 JSON 파싱 후 호출
    }
}
// Jackson: 라이브러리 (내가 호출)
// Spring MVC: 프레임워크 (호출당함)

6.6 자기 점검 답변

jQuery는 라이브러리인가 프레임워크인가?

답:
1. jQuery:

  • 라이브러리

  1. 왜:

    • 내가 호출 ($)
    • 제어 = 나

  2. vs Angular:

    • Angular = 프레임워크

  3. 판단:

    • 누가 호출?

7️⃣ Spring이 프레임워크인 이유

7.1 Spring 의 IoC

Spring 이 프레임워크인 이유:

  Spring 이:
    - 객체 생성 (빈)
    - 메서드 호출 (컨트롤러)
    - 생명주기 관리

  → 제어가 Spring (IoC)

7.2 빈 생성·관리

빈 생성·관리:

  Spring 컨테이너:
    - 빈 생성 (내가 X)
    - 의존성 주입
    - 생명주기

  → 객체 제어가 Spring

7.3 메서드 호출

// Spring 이 메서드 호출
@RestController
public class ShipmentController {
    @GetMapping("/shipments")   // Spring 이 요청 시 호출
    public List<Shipment> list() {
        return null;
    }
    // 내가 호출 X, Spring 이 호출
}

7.4 생명주기

// Spring 이 생명주기 관리
@Component
public class ShipmentService {
    @PostConstruct   // Spring 이 생성 후 호출
    public void init() { }
    
    @PreDestroy   // Spring 이 소멸 전 호출
    public void cleanup() { }
}
// 생명주기 콜백을 Spring 이 호출

7.5 ILIC 의 맥락

// Spring 의 IoC (전방위)

@Service
public class ShipmentService {
    private final ShipmentDao shipmentDao;
    
    // 1. Spring 이 생성 + 의존성 주입
    public ShipmentService(ShipmentDao shipmentDao) {
        this.shipmentDao = shipmentDao;   // Spring 이 주입
    }
    
    // 2. Spring 이 생명주기 호출
    @PostConstruct
    public void init() {
        log.info("초기화");   // Spring 이 호출
    }
}

@RestController
public class ShipmentController {
    private final ShipmentService service;
    public ShipmentController(ShipmentService service) {
        this.service = service;   // Spring 주입
    }
    
    // 3. Spring 이 요청 시 메서드 호출
    @GetMapping("/shipments")
    public List<Shipment> list() {
        return service.findAll();
    }
}
// 생성·주입·호출·생명주기 모두 Spring (IoC)
// → Spring = 프레임워크

7.6 자기 점검 답변

Spring이 프레임워크인 이유는?

답:
1. IoC:

  • 제어가 Spring

  1. 빈 생성·관리:

    • Spring 이 객체

  2. 메서드 호출:

    • Spring 이 호출

  3. 생명주기:

    • Spring 이 관리

8️⃣ 경계가 모호한 경우

8.1 모호한 경우

경계 모호:

  일부는 둘 다:
    - 라이브러리 + 프레임워크적
    - 사용 방식에 따라

  예: React, Spring 일부

8.2 React

React:

  자칭 라이브러리:
    - UI 컴포넌트

  프레임워크적:
    - 렌더링 제어
    - 생명주기

  → 경계 모호

8.3 사용 방식

사용 방식:

  같은 도구도:
    - 라이브러리처럼 (내가 호출)
    - 프레임워크처럼 (호출당함)

  → 맥락에 따라

8.4 본질은 IoC

본질은 IoC:

  구분 기준:
    - IoC 여부
    - 제어가 어디

  프레임워크적 = IoC 강함
  라이브러리적 = IoC 약함

8.5 ILIC 의 맥락

// Spring 도 라이브러리처럼 쓸 수 있음

// 프레임워크처럼 (IoC, 일반적)
@RestController
public class Controller {
    @GetMapping("/api")   // Spring 이 호출
    public String handle() { return ""; }
}

// 라이브러리처럼 (내가 호출)
public class ManualUsage {
    public void use() {
        // ApplicationContext 를 내가 직접
        ApplicationContext ctx = 
            new AnnotationConfigApplicationContext(Config.class);
        ShipmentDao dao = ctx.getBean(ShipmentDao.class);   // 내가 호출
        // 라이브러리처럼 사용
    }
}
// 같은 Spring, 사용 방식 다름
// 본질: IoC 여부로 판단
@Configuration
class Config {}

8.6 자기 점검 답변

둘의 경계가 모호한 경우는?

답:
1. 모호:

  • 둘 다 가능
  • React 등

  1. 사용 방식:

    • 맥락에 따라

  2. 본질:

    • IoC 여부

  3. 기준:

    • 제어가 어디

9️⃣ 면접 + 자기 점검

9.1 면접 단골 질문 매핑

Q핵심 답변
프레임워크 vs 라이브러리?제어권 (IoC 여부)
누가 흐름 제어?라이브러리: 나, 프레임워크: 그것
호출 방향?내→라이브러리, 프레임워크→내
망치 vs 공장?휘두름 vs 틀 안
Hollywood Principle?"우리가 부를게"
jQuery?라이브러리
Spring 프레임워크?생성·호출·생명주기
본질?IoC
경계 모호?사용 방식
IoC?프레임워크 = 제어 역전

9.2 자기 점검 체크리스트

정의

  • 라이브러리/프레임워크

제어

  • 누가 흐름

호출 방향

  • 내→/→내

비유

  • 망치/공장

Hollywood

  • 원칙

jQuery

  • 라이브러리

Spring

  • 프레임워크 이유

9.3 추가 심화 질문

Q1: Spring Boot 는?

답:

  • 프레임워크 (Spring 기반)
  • 자동 설정
  • 내장 서버
  • IoC 강함

Q2: 프레임워크 학습 곡선?

답:

  • 규칙 학습 필요
  • 틀 이해
  • 라이브러리보다 가파름
  • 생산성 (익히면)

Q3: 프레임워크 장단점?

답:

  • 장: 생산성, 일관성, 검증
  • 단: 제약, 학습, 종속
  • 라이브러리: 자유, 학습 ↓
  • 트레이드오프

Q4: 인라인 프레임워크?

답:

  • 마이크로 프레임워크
  • 최소 기능
  • 라이브러리에 가까움
  • 경계 흐림

Q5: SDK 는?

답:

  • Software Development Kit
  • 라이브러리 + 도구 모음
  • 보통 라이브러리적
  • 맥락에 따라

🎯 핵심 요약 — 3줄 정리

1. 핵심 차이

  • 라이브러리: 내가 호출 (제어 = 나)
  • 프레임워크: 호출당함 (제어 = 프레임워크 = IoC)

2. 호출 방향과 비유

  • 내 코드 → 라이브러리 (망치)
  • 프레임워크 → 내 코드 (공장, Hollywood Principle)

3. 판단

  • jQuery (라이브러리) vs Spring (프레임워크)
  • 본질은 IoC 여부 (제어가 어디)

📚 다음으로...

Unit 7.3 — IoC 컨테이너의 역할 (Phase 7 완주)

이번 Unit에서 프레임워크 vs 라이브러리를 봤다면, 다음은 IoC 컨테이너 (Phase 7 마지막).

  • 객체 생성·연결·생명주기 관리
  • ApplicationContext
  • IoC 컨테이너 없이 IoC 구현하면

Phase 7 진행 상황

🌱 Phase 7 — 제어의 역전 (IoC)
  ✅ Unit 7.1 IoC 개념 ★깊이
  ✅ Unit 7.2 프레임워크 vs 라이브러리 ← 여기
  ⏭ Unit 7.3 IoC 컨테이너의 역할 — Phase 7 완주

5주차 누적 진행

✅ Part A — 동시성 마무리 (7 Unit)
🌱 Part B — 토비의 스프링
  ✅ Phase 3~6 (12 Unit)
  🌱 Phase 7 — IoC (2/3 진행)

총: 21/26 Unit
profile
Psj
Software Developer
이전 포스트

5주차 Unit 7.1 — IoC (제어의 역전) 개념

다음 포스트

5주차 Unit 7.3 — IoC 컨테이너의 역할

0개의 댓글