당니의 개발자 스토리

프레임워크와 라이브러리의 차이, IoC 제어의 역전 본문

Java, Spring

프레임워크와 라이브러리의 차이, IoC 제어의 역전

clainy 2026. 5. 4. 11:12

프레임워크와 라이브러리는 둘 다 개발을 편하게 해주는 도구처럼 보인다.

그래서 처음 배우면 둘이 비슷하게 느껴진다.

 

하지만 둘의 차이는 분명하다!!

 

라이브러리는 내가 필요할 때 가져다 쓰는 도구이고,

프레임워크는 내가 그 틀 안에 맞춰서 코드를 작성하는 구조다.

 

가장 중요한 차이는 제어의 흐름(IoC)이다.

라이브러리는 내가 불러서 호출한다(도구 같은 느낌)
프레임워크는 프레임워크가 내 코드를 호출한다(양식, 틀 같은 느낌)

이 차이를 이해하면 프레임워크와 라이브러리의 구분이 훨씬 쉬워진다.

 

라이브러리는 내가 필요할 때 꺼내 쓰는 도구다.

예를 들어 Java에서 정렬 기능이 필요하다고 해보자.

import java.util.*;

public class Main {
    public static void main(String[] args) {
        List<Integer> numbers = new ArrayList<>();

        numbers.add(3);
        numbers.add(1);
        numbers.add(2);

        Collections.sort(numbers);

        System.out.println(numbers);
    }
}

여기서 Collections.sort(numbers)는 Java가 제공하는 정렬 기능을 가져다 쓴 것이다.

정렬을 언제 할지 결정하는 사람은 개발자다.

즉, 코드의 흐름은 내가 가지고 있고, 필요한 순간에 라이브러리를 호출한다.

 

흐름을 단순하게 보면 이렇다.

내 코드
→ 라이브러리 호출
→ 결과 사용

라이브러리는 망치, 드라이버, 톱 같은 도구가 들어 있는 공구함이 있다고 생각하면 된다.

집을 어떻게 지을지는 내가 결정한다.

필요할 때 망치를 꺼내 쓰고, 필요할 때 드라이버를 꺼내 쓴다.

라이브러리는 구조를 강제하지 않는다.

그냥 필요한 기능을 제공해줄 뿐이다.

 

그런데 프레임워크는 조금 다르다!!

 

프레임워크는 이미 정해진 구조가 있고,

개발자는 그 구조 안에 자기 코드를 넣는다.

 

예를 들어 Spring에서는 이런 코드를 작성할 수 있다.

@Controller
public class UserController {

    @GetMapping("/user")
    public String getUser() {
        return "user";
    }
}

이 코드에서 개발자가 직접 getUser() 메서드를 호출하지 않는다.

브라우저에서 /user 요청이 들어오면 Spring이 알아서 이 메서드를 찾아 실행한다.

 

즉, 흐름은 이렇게 된다.

요청 들어옴
→ Spring이 요청을 분석함
→ Spring이 알맞은 메서드를 호출함
→ 개발자가 작성한 코드 실행됨

여기서 중요한 점은 개발자가 흐름 전체를 직접 제어하지 않는다는 것이다.

 

Spring이라는 프레임워크가 전체 흐름을 잡고 있고,

개발자는 그 흐름 안에 필요한 코드를 작성한다.

 

그래서 프레임워크는 이미 집의 뼈대가 잡혀 있고,

개발자는 그 안에 벽지나 문, 가구를 채워 넣는 느낌이다.


이 차이를 설명할 때 자주 나오는 개념이 IoC다.

IoC는 Inversion of Control의 약자이고, 우리말로는 제어의 역전이라고 한다.

 

원래는 개발자가 프로그램의 흐름을 직접 제어한다.

어떤 객체를 만들지, 어떤 메서드를 호출할지, 언제 실행할지 개발자가 직접 정한다.

 

그런데 프레임워크를 사용하면 흐름의 주도권이 프레임워크로 넘어간다.

개발자는 코드를 작성해두고, 프레임워크가 필요한 시점에 그 코드를 호출한다.

이것이 제어의 역전이다.


소프트웨어에서 프레임워크도 마찬가지다.

 

애플리케이션의 기본 구조는 프레임워크가 제공하고,

개발자는 그 안에 비즈니스 로직을 채운다.

 

여기서 비즈니스 로직은 서비스의 핵심 기능을 의미한다.

예를 들어 쇼핑몰이라면 회원가입, 로그인, 상품 주문, 결제, 환불 같은 기능이 비즈니스 로직이다.

 

프레임워크는 이런 핵심 기능 자체를 대신 만들어주는 것이 아니다.

대신 그 기능을 만들기 위해 반복적으로 필요한 구조를 제공한다.

 

예를 들어 Spring객체 생성, 요청 처리, DB 연결, 트랜잭션 처리 같은 복잡하고 반복적인 일을 도와준다.

그래서 개발자는 회원가입 로직, 주문 로직, 결제 로직처럼 실제 서비스에 중요한 코드에 더 집중할 수 있다.

 

Spring Framework는 자바 애플리케이션 개발을 위한 경량 프레임워크라고 설명된다.

불필요하게 무겁고 복잡한 방식이 아니라,

필요한 기능을 조합해서 사용할 수 있도록 설계되었다.

 

Spring은 개발자가 애플리케이션을 만들 때 반복적으로 해야 하는 많은 일을 대신 처리해준다.

예를 들어 웹 요청이 들어왔을 때 어떤 컨트롤러를 실행할지 찾아준다.

객체가 필요하면 직접 new로 만들지 않아도 Spring이 관리해줄 수 있다.

트랜잭션이 필요하면 개발자가 직접 commit, rollback 코드를 반복해서 작성하지 않아도 된다.

 

이런 점 때문에 Spring은 프레임워크다.

개발자가 Spring의 구조 안에서 코드를 작성하고,

Spring이 전체 흐름을 관리하기 때문이다.


그렇다면 Maven은 프레임워크 일까 ..?

프레임워크와 헷갈리기 쉬운 개념 중 하나가 Maven이다.

 

Maven도 개발할 때 많이 쓰고, Spring 프로젝트에서도 자주 같이 등장한다.

그래서 틀 같은 느낌이라 Maven도 프레임워크처럼 느껴질 수 있다.

하지만 Maven은 프레임워크가 아니다.

 

Maven은 빌드 자동화 도구다.

프로젝트를 빌드하고, 필요한 라이브러리를 관리해주는 도구다.

 

예를 들어 JUnit이 필요하면 pom.xml에 dependency를 추가한다.

<dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter</artifactId>
    <scope>test</scope>
</dependency>

그러면 Maven이 필요한 라이브러리를 알아서 가져온다.

 

또 프로젝트를 컴파일하고, 테스트하고, jar나 war 파일로 묶는 작업도 도와준다.

 

하지만 Maven은 애플리케이션의 실행 흐름을 제어하지 않는다.

사용자의 요청을 받아서 컨트롤러를 실행하지도 않고,

객체를 대신 관리하면서 비즈니스 로직을 호출하지도 않는다.

그냥 프로젝트를 만들고 관리하는 데 도움을 주는 도구다.

 

따라서 Spring은 프레임워크이고,

Maven은 빌드 도구다.

 

코드 흐름으로 보면 더 명확하다.

라이브러리
내 코드 → 라이브러리 호출
프레임워크
프레임워크 → 내 코드 호출
빌드 도구
소스 코드와 라이브러리 관리
→ 컴파일
→ 테스트
→ 패키징

 

'Java, Spring' 카테고리의 다른 글

Spring의 DI, AOP, PSA, POJO 이해하기  (1) 2026.05.06
Spring이 JDBC와 트랜잭션 작업을 줄여주는 방식  (1) 2026.05.06
gRPC란? REST와 gRPC의 차이  (0) 2026.04.21
Filter Mapping과 Dispatcher  (0) 2026.04.21
Filter  (0) 2026.04.21