라이브러리와 프레임워크 차이는 제어 역전의 여부.

스프링, 스프링 하면서 IoC와 DI라는 말을 무수히 많이 들어봤을 것이다. 국내 프로젝트에서 스프링이 적용되지 않는 곳이 있을까 싶을 정도로 많이 이용되는 상황이니 말이다. 스프링에 대한 기초서적만 보더라도 ioc, ioc, di , di 계속 나오기도 하고...

 

얼마 전 모 유명 IT 테크 회사의 경력 면접 질문에 이런 질문이 나왔다고 한다. 라이브러리와 프레임워크의 차이가 무엇인가? 

 

보면서 순간적으로 멍~ 했던 기억이 난다. 분명 뭐라고 말을 만들어내서 말하면 될거 같기는 한데~ 늘 그렇듯 자연스럽게 라이브러리를 가져다 사용하고, 많은 프레임워크가 적용되어 개발을 하고 있는데도 딱 이거다! 라고 표현을 못하겠는거다. 

 

바로 구글링을 했고, 내 블로그에 기록으로 적어놓는다. 바로 이 그림이다. 

 

1. 프레임워크는 내 코드를 사용하고

 

2. 내 코드가 라이브러리를 사용한다. 

 

정도로 이해하면 된다고 본다. 프레임워크 내부에 각종 라이브러리가 있는 거야 많은 jar 파일들이 포함되어있는 것을 눈여겨 봤다면 당연히 알 수 있는 거다. 

 

이 1번의 프레임워크가 내 코드를 사용하여 어플리케이션이 돌아가는 것을 조금 더 유식한 말로 IoC( Inversion of Control ) : 제어의 역전이라고 하는데 GoF 디자인 패턴에서부터 유래된 용어이지만 현재는 스프링의 주요 핵심 원칙으로 자리 잡은 용어이다. 

 

당연히 어디가서 스프링좀 아세요? 라고 하면 이 IoC가 빠질 수 없다는 것이다. 하지만 이 IoC는 스프링 고유의 유니크한 특성을 나타내는 말은 아니니 오해하지 말자. 

 

사실 서블릿으로 개발을 하더라도 근본적으로는 서블릿 엔진에서 제공되는 기반하에 서블릿 매핑을 이용해서 서블릿을 연결하여 각각의 서비스 코드를 구현하게 되므로 엄밀히 말하면 서블릿, jsp와 같은 j2ee 기반의 자바 웹 프로그램 자체가 모두 IoC라고 할 수 있다. 

 

jsp나 서블릿 또한 직접적으로 프로그램의 흐름 제어 코드를 가지지 않는다. 스프링에서 컨트롤러를 등록하듯 서블릿 url 매핑을 등록한 다음 해당 서블릿을 추가하는 수준의 작업은 내용이 거의 같다. 

 

이 특성을 IoC라고 하는 거고...

 

---

1. 프레임워크란 뭘까?

 

그럼 서블릿이나 JSP이 스프링처럼 프레임워크라고 부를 수 있을까? 나는 부를 수 있다고 생각한다. 물론 요즘 제공하는 스프링과 같은 다수의 기능을 제공하지는 않지만 어떤 기반, 틀 내에서 비지니스 코드를 구현할 수 있는 체계를 제공하는 것을 프레임워크라고 부른다면.

 

서블릿 엔진, J2EE 스펙을 제공하는 구현체 내에서 업무 코드만을 구현하면 되지 않은가. 여기에 mvc를 붙인 그림이 과거 스트럿츠였고 디비를 엑세스 하기 위해서 직접 jdbc를 이용하기도 했고 퍼시스턴스 프레임워크인 아이바티스,마이바티스, jpa 와 같은 것들을 붙여서 사용 했었던 거다. 

 

즉, 자바에서 main을 구현하듯 직접 프로그램의 흐름을 구현하지 않는다면 모두 프레임워크라고 부를 수 있을 것이다. 

 

프레임워크란

---

2. 라이브러리란 뭘까?

 

라이브러리란 자바를 사용 할 때  바로 친숙하게 접할 만한 것으로 대표적으로 log4j.jar 를 생각하는 것이 가장 간단할 것 같다. 어떤 프로그램에서나 로깅을 하기 위해서 간단하게 log4j를 추가해서 사용한다. 

 

사용법도 가장 많이 알려져있는 편이고 가장 널리 사용되는 라이브러리라고 생각된다. 어떤 기능을 사용하기 편하게 모듈화하여 만들어진 프로그램을 뜻한다. 

 

당신이 만든 코드에서 jar(라이브러리)를 호출한다면 라이브러리라고 말할 수 있다. 

 

라이브러리란?

---

이렇게 여러 레퍼런스의 그림들과 내 생각들을 짬뽕해서 정리해봤다. 적어도 누군가 '라이브러리와 프레임워크의 차이를 말해보세요'라고 했을 때 저정도의 심플한 답만 나와주더라도 괜찮을 것 같다. 

 

라이브러리와 프레임워크의 차이는 제어 역전의 여부에서 비롯된다.