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

Framework Vs Library

프레임워크는 단지 미리 만들어 둔 반제품이나, 확장해서 사용할 수 있도록 준비된 추상 라이브러리의 집합이 아니다.

프레임워크가 어떤 것인지 이해하려면 라이브러리와 프레임워크가 어떻게 다른지 알아야 할 것이다.

Framework(프레임워크)

프레임워크는 뼈대나 기반구조를 뜻하고, 제어의 역전 개념이 적용된 대표적인 기술이다.  

소프트웨어에서의 프레임워크는 '소프트웨어의 특정 문제를 해결하기 위해서 상호 협력하는 클래스와 인터페이스의 집합' 이라 할 수 있으며, 완성된 어플리케이션이 아닌 프로그래머가 완성시키는 작업을 해야한다. 

객체 지향 개발을 하게 되면서 통합성, 일관성의 부족이 발생되는 문제를 해결할 방법중 하나라고 할 수 있다.

프레임워크의 특징

• 특정 개념들의 추상화를 제공하는 여러 클래스나 컴포넌트로 구성되어 있다.  
• 추상적인 개념들이 문제를 해결하기 위해 같이 작업하는 방법을 정의한다. 
• 컴포넌트들은 재사용이 가능하다. 
• 높은 수준에서 패턴들을 조작화 할 수 있다.

라이브러리(Library)

라이브러리는 단순 활용가능한 도구들의 집합을 말한다.

즉, 개발자가 만든 클래스에서 호출하여 사용, 클래스들의 나열로 필요한 클래스를 불러서 사용하는 방식을 취하고 있다.

 

 

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

라이브러리와 프레임워크의 차이는 제어 흐름에 대한 주도성이 누구에게/어디에 있는가에 있다.

즉, 어플리케이션의 Flow(흐름)를 누가 쥐고 있느냐에 달려 있다.

프레임워크는 전체적인 흐름을 스스로가 쥐고 있으며 사용자는 그 안에서 필요한 코드를 짜 넣으며 반면에 라이브러리는 사용자가 전체적인 흐름을 만들며 라이브러리를 가져다 쓰는 것이라고 할 수 있다.

다시 말해, 라이브러리는 라이브러리를 가져다가 사용하고 호출하는 측에 전적으로 주도성이 있으며 프레임워크는 그 틀안에 이미 제어 흐름에 대한 주도성이 내재(내포)하고 있다.

프레임워크는 가져다가 사용한다기보다는 거기에 들어가서 사용한다는 느낌/관점으로 접근할 수 있다.

라이브러리를 사용하는 애플리케이션 코드는 애플리케이션 흐름을 직접 제어한다.  

단지 동작하는 중에 필요한 기능이 있을 때 능동적으로 라이브러리를 사용할 뿐이다. 

반면에 프레임워크는 거꾸로 애플리케이션 코드가 프레임워크에 의해 사용되는 것이다. 

보통 프레임워크 위에 개발한 클래스를 등록해두고, 프레임워크가 흐름을 주도하는 중에 개발자가 만든 애플리케이션 코드를 사용하도록 만드는 방식이다.

프레임워크에는 분명한 제어의 역전 개념이 적용되어 있어야 한다.

애플리케이션 코드는 프레임워크가 짜놓은 틀에서 수동적으로 동작해야 한다.

제어의 역전이란 어떠한 일을 하도록 만들어진 프레임워크에 제어의 권한을 넘김으로써 클라이언트 코드가 신경써야 할 것을 줄이는 전략이다. 이것을 제어가 역전 되었다 라고 한다. 일반적으로 라이브러리는 프로그래머가 작성하는 클라이언트 코드가 라이브러리의 메소드를 호출해서 사용하는 것을 의미한다.

프레임워크를 규정하는 특성은 프레임워크의 메소드가 사용자의 코드를 호출 한다는데 있다. 

여기까지는 이해가 쉽지만, 의문이 생긴다. 

대체 어떻게 프레임워크가 나의 메소드를 호출하는가에 대한 의문이다. 

어떻게 하면 프레임워크가 나의 코드를 호출 할 수 있을까? 프레임워크는 내가 작성한 코드를 모르잖아!. 

제어를 역전시키는 (프레임워크가 나의 코드를 호출 할 수 있게 하는) 가장 쉽게 생각할 수 있는 접근 방법은 프레임워크의 event, delegate 에 나의 메소드를 등록 시키는 것이다. 

전달되는 인자와 반환 형식만 일치 한다면, 프레임워크 코드는 내가 작성한 객체와 타입을 고려하지 않는다. 

등록된 메소드만 감지하여 실행 invoke 하는 것이다. 

다른 방법은 프레임워크에 정의 되어 있는 인터페이스 interface, 추상타입 abstract 을 나의 코드에서 구현, 상속 한후 프레임워크에 넘겨주는 것이다. 

프레임워크는 인터페이스와 추상을 알고 있으므로 내가 하고자 하는 일련의 작업을 처리할 수 있다. 

이는 객체를 프레임워크에 주입하는 것이고, 이를 의존을 주입 dependency injection 한다고 한다.

라이브러리는 그냥 함수들이나 기능 모음을 가져다가 쓰는 것이고. 프레임워크는 특정 디자인 패턴이나, 전처리 후처리에 필요한 동작과 기능들을 수행하기 위해서 프레임워크가 실행되다가 중간 중간에 특정 비지니스나, 특정 구현 단에서만 사용자의 코드를 lookup(검색)하여 사용하는 형태라고 할 수 있다.

아직까지 개념이 모호하다면 좀더 구체적인 ex)

일단 모든 소스코드든 라이브러리든 간에 메모리에 들어가는 정보는, 컴파일러나 인터프리터에게는 호출가능한 모듈일 뿐이다. 

이런 물리적인 계층을 보지말고, 그 위의 논리적인 계층을 봐야한다.  

라이브러리는 톱, 망치, 삽같은 연장이다. 

사람이 들고 썰고, 바꿔들고 내려치고, 다시 바꿔들고 땅을 파는거다. 

프레임워크는 차, 비행기, 배같은 탈 것이다. 

사람이 타서 엔진 켜고, 기어 넣고, 핸들 돌리고, 운전하거나, 조종하거나 해야한다. 

도구를 쓸 때, 급하면 썰어야 할 곳에 망치를 쳐도 된다. 땅 파야할 때 톱으로 땅을 긁어내도 된다. 

사람은 도구를 선택하는 입장이기 때문에, 어떤 도구를 사용하든 원하는 것을 만들어낼 수 만 있으면 된다. 

반면에, 탈것은 정해진 곳으로만 다녀야 한다. 

차를 타고 하늘을 날거나, 배를 타고 땅으로 갈 수는 없습니다. 

하지만, 그 목적에 맞게 만들어져 있기 때문에, 톱이나 망치를 들고 먼저 탈것을 만들어야 할 필요가 없다. 

그저 정해진 규칙에 맞춰서 엔진, 기어, 핸들만 잘 돌리면 되는 것이다. 

 

라이브러리와는 달리 프레임워크는 이미 프로그래밍할 규칙이 정해져 있다. 

예를 들어, 설정파일로 사용되는 XML에 어떤 태그를 써야하며, 어떤 함수를 추가적으로 작성해야하고, 소스 파일을 어느 위치에 넣어야하며, DB와 연동하기 위해 무엇을 써넣어야 하는지 정해져 있다. 

보통 이런 대부분의 작업은 프레임워크가 하고자 하는 일에 비하면 아주 작은 일이며, 사람은 극히 일부분만 조정함으로써 목적을 달성할 수 있다. 

 

만약 프레임워크가 담당하는 부분이 내가 하고자 하는 목적과 다를 경우에는 어떻게 해야 할까?

그렇다면 단순히 프레임워크를 잘못 가져다 쓴 것이다. 

더 목적에 가까운 프레임워크를 찾아보면 대부분 있을 것이고 없거나 찾기 힘들다면 비슷한 프레임워크를 라이브러리 단계에서 변경해서 다른 프레임워크로 만들면 될 것이다. 

차를 튜닝한 다음에, 차를 다시 운전하면 된다는 것이라고 할 수 있다. 

프레임워크 없이 그냥 라이브러리로만 만들어도 된다. 

그냥 다 다시 만들 능력과 시간과 여유만 있다면 그렇게 해도 된다. 

스스로 만든 프레임워크는 버그도 스스로 잡아야하지만, 남들이 만들어놓은 프레임워크는 쓰는 사람이 많은 만큼 그만큼 수정이나 업데이트도 빠르다. 

기능이 마음에 안드는 부분이 있다면, 프레임워크를 고쳐서 사용할 수 있다. 

처음부터 모든 것을 만드는 것보다는 훨씬 비용이 적게 들 것이다. 

내일 당장 지방에서 서울로 출근해야하는데, 혼자서 차를 만들어서 타고 가야한다는 생각을 해보면 된다.