[코드잇][위클리페이퍼][4주차] 프레임워크와 라이브러리의 차이점

아래는 4주차 위클리페이퍼 주제이다.

• Spring Framework가 탄생하게 된 배경과 이를 통해 해결하고자 했던 문제점에 대해 설명하세요.
• 프레임워크와 라이브러리의 차이점을 제어 흐름의 주체와 사용 방식을 중심으로 설명하고, Spring Framework와 일반 Java 라이브러리를 예시로 들어 설명하세요.

이번 포스팅에서는 두 번째 주제에 대해서 다룬다.

 

우리가 코드를 작성할 때 이미 작성된 코드를 다른 곳에서 재사용하려면 복사 붙여넣기를 통해 사용할 수 있다. 그러나 개발자라면 복사 붙여넣기가 아닌 함수를 통해 반복되는 작업을 줄일 것이다. 더 나아가, 내가 만든 함수뿐만이 아니라 남이 만들어 놓은 코드를 사용할 수도 있다. 이러한 것을 보고 '라이브러리' 또는 '프레임워크'를 사용한다고 한다. 둘다 코드를 '재사용한다' 라는 목적은 같지만, 서로 다른 이름으로 부르는 것에는 이유가 있다.

 

이 둘을 구분하는 가장 큰 기준은 이전에 스프링에 대해서 포스팅 할때 언급한 제어의 역전(IoC, Inversion if Control)의 유무이다. 즉, 프로그램의 흐름제어를 개발자가 가지고 있는지 외부에서 불러온 코드에 있는지 여부이다. 이를 통해 객체의 생명주기를 관리하는 주체가 개발자인지 아닌지가 갈리는데 이 개념을 통해 프레임워크와 라이브러리를 구분할 수 있다.

• 라이브러리: 제어의 주체가 개발자에게 있다. 개발자가 필요할 때 라이브러리를 호출해서 사용한다. 이를 통해 객체의 생명주기는 개발자가 제어한다.
• 프레임워크: 제어의 주체가 프레임워크에게 있다. 프레임워크가 정한 규칙에 따라 개발자가 코드를 작성하면, 프레임워크가 필요할 때 개발자가 작성한 코드를 불러서 사용한다. 이를 통해 프레임워크가 객체의 생명주기를 관리한다.

자바에서 제어의 주체가 넘어가는 사례를 쉽게 확인할 수 있다. 아래 코드를 보자.

List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5);


// 라이브러리 스타일
for (Integer n : numbers) { // 루프의 시작과 끝을 개발자가 직접 제어
    if (n % 2 == 0) {       // 조건 검사 시점을 개발자가 결정
        System.out.println(n); // 출력 시점도 개발자가 결정
    }
}

// 프레임워크 스타일
numbers.stream()
       .filter(n -> n % 2 == 0) // "짝수만 골라줘"라고 규칙만 전달
       .forEach(System.out::println); // "출력해줘"라고 결과만 선언

 

for문은 개발자가 루프의 범위를 조정할 수 있고, for문 내에 작성하는 순서에 따라 동작의 실행 순서를 정할 수 있다. 즉, 개발자가 직접 루프를 제어하는 외부 반복자 방식이다. 하지만 stream API를 사용하면 제어권이 스트림 내부로 넘어간다. 개발자는 무엇을 할지만 알려줄 뿐, 실제 루프를 언제 돌릴지나 필터링을 어떤 순서로 처리할지는 스트림이 판단한다. 이를 내부 반복자라고 하며 루프의 제어 흐름이 스트림에게 있기에 일부 제어의 역전(IoC)이 일어난 것이다.

다만 Stream은 여전히 스트림을 생성하고 종료하는 생명주기 관리는 개발자가 하고 있기에 라이브러리이다.

 

그렇다면 실제로 Spring Framework는 일반 Java 라이브러리와 어떤 차이점이 있을까? 아래 코드를 보자

// Math, Wrapper, Scanner -> 자바 표준 라이브러리의 클래스
public void myLogic() {
    // 필요할 때 직접 메서드를 호출함
    int maxVal = Math.max(10, 20); 
    
    // 문자열을 숫자로 바꾸는 시점도 내가 결정함
    int num = Integer.parseInt("123");
    
    // Scanner처럼 객체를 직접 생성해서 쓰기도 함
    Scanner sc = new Scanner(System.in);
}

// Spring Framework
@RestController
public class MyController {

    // "이 메서드는 /hello 요청이 오면 실행해줘"라고 규칙만 정함
    @GetMapping("/hello")
    public String welcome() {
        return "Hello, Spring!";
    }
}

자바 표준 라이브러리의 클래스는 개발자가 명확하게 실행 시점을 제어한다. Math.max()나 Integer.parseInt()는 언제 호출할지, 몇 번 호출할지를 전적으로 개발자가 결정하며, 객체의 생성과 소멸 또한 개발자의 책임이다. 즉, 애플리케이션의 흐름은 끝까지 개발자가 주도한다.

 

반면 @GetMapping("/hello")이 붙은 welcome() 메서드는 개발자가 직접 호출하지 않는다. 웹 서버가 요청을 받아들이고, 요청을 어떤 컨트롤러로 매핑할지 판단한 뒤, 적절한 시점에 Spring 컨테이너가 해당 메서드를 호출한다. 개발자는 언제 실행할지가 아니라 어떤 조건에서 실행되어야 하는지만 선언할 뿐이다. 실행 시점과 호출 흐름의 제어권은 Spring Framework가 가진다.

 

이 차이는 단순히 메서드 호출 방식의 차이가 아니다. Spring은 객체의 생성, 의존성 주입, 초기화와 소멸, 그리고 실행 시점까지 애플리케이션의 전체 생명주기와 흐름을 프레임워크가 관리한다. 이처럼 프로그램의 주도권이 개발자가 아닌 외부 컨테이너로 넘어가는 구조를 제어의 역전(IoC, Inversion of Control)이라 한다.

 

정리하자면, 라이브러리는 개발자가 흐름을 주도하며 필요할 때마다 꺼내 쓰는 ‘도구’라면, 프레임워크는 이미 정해진 실행 흐름 속에 개발자의 코드를 끼워 넣어 실행시키는 ‘공장’이다. 개발자는 프레임워크를 호출하지 않고, 프레임워크가 개발자의 코드를 호출한다.