프레임워크와 라이브러리의 차이점
Framework Vs Library
프레임워크와 라이브러리의 정확한 차이점은 무엇일까요?
대중 알것 같지만 정확히 어떠한 차이점이 있는지 모르고 있는 경우가 많을지도 모릅니다.
프레임워크는 단지 미리 만들어 둔 반제품이나, 확장해서 사용할 수 있도록 준비된 추상 라이브러리의 집합이 아닙니다.
프레임워크가 어떤 것인지 이해하려면 라이브러리와 프레임워크가 어떻게 다른지 알아야 할 것입니다.
먼저 프레임워크와 라이브러리의 개념에 대해 살펴보고 차이점에 대해 알아보도록 하겠습니다.
Framework(프레임워크)
프레임워크는 뼈대나 기반구조를 뜻하고, 제어의 역전 개념이 적용된 대표적인 기술입니다.
소프트웨어에서의 프레임워크는 '소프트웨어의 특정 문제를 해결하기 위해서 상호 협력하는 클래스와 인터페이스의 집합' 이라 할 수 있으며, 완성된 어플리케이션이 아닌 프로그래머가 완성시키는 작업을 해야합니다.
객체 지향 개발을 하게 되면서 통합성, 일관성의 부족이 발생되는 문제를 해결할 방법중 하나라고 할 수 있습니다.
프레임워크의 특징
- 특정 개념들의 추상화를 제공하는 여러 클래스나 컴포넌트로 구성되어 있습니다.
- 추상적인 개념들이 문제를 해결하기 위해 같이 작업하는 방법을 정의합니다.
- 컴포넌트들은 재사용이 가능합니다.
- 높은 수준에서 패턴들을 조작화 할 수 있습니다.
라이브러리(Library)
라이브러리는 단순 활용가능한 도구들의 집합을 말합니다.
즉, 개발자가 만든 클래스에서 호출하여 사용, 클래스들의 나열로 필요한 클래스를 불러서 사용하는 방식을 취하고 있습니다.
프레임워크와 라이브러리의 차이점
라이브러리와 프레임워크의 차이는 제어 흐름에 대한 주도성이 누구에게/어디에 있는가에 있습니다.
즉, 어플리케이션의 Flow(흐름)를 누가 쥐고 있느냐에 달려 있습니다.
프레임워크는 전체적인 흐름을 스스로가 쥐고 있으며 사용자는 그 안에서 필요한 코드를 짜 넣으며 반면에 라이브러리는 사용자가 전체적인 흐름을 만들며 라이브러리를 가져다 쓰는 것이라고 할 수 있습니다.
다시 말해, 라이브러리는 라이브러리를 가져다가 사용하고 호출하는 측에 전적으로 주도성이 있으며 프레임워크는 그 틀안에 이미 제어 흐름에 대한 주도성이 내재(내포)하고 있습니다.
프레임워크는 가져다가 사용한다기보다는 거기에 들어가서 사용한다는 느낌/관점으로 접근할 수 있습니다.
라이브러리를 사용하는 애플리케이션 코드는 애플리케이션 흐름을 직접 제어합니다.
단지 동작하는 중에 필요한 기능이 있을 때 능동적으로 라이브러리를 사용할 뿐입니다.
반면에 프레임워크는 거꾸로 애플리케이션 코드가 프레임워크에 의해 사용되는 것입니다.
보통 프레임워크 위에 개발한 클래스를 등록해두고, 프레임워크가 흐름을 주도하는 중에 개발자가 만든 애플리케이션 코드를 사용하도록 만드는 방식입니다.
프레임워크에는 분명한 제어의 역전 개념이 적용되어 있어야 합니다.
애플리케이션 코드는 프레임워크가 짜놓은 틀에서 수동적으로 동작해야 합니다.
제어의 역전이란 어떠한 일을 하도록 만들어진 프레임워크에 제어의 권한을 넘김으로써 클라이언트 코드가 신경 써야 할 것을 줄이는 전략입니다.
이것을 제어가 역전 되었다 라고 합니다. 일반적으로 라이브러리는 프로그래머가 작성하는 클라이언트 코드가 라이브러리의 메소드를 호출해서 사용하는 것을 의미 합니다.
프레임워크를 규정하는 특성은 프레임워크의 메소드가 사용자의 코드를 호출 한다는데 있습니다.
여기까지는 이해가 쉽지만, 의문이 생깁니다.
대체 어떻게 프레임워크가 나의 메소드를 호출하는가에 대한 의문입니다.
어떻게 하면 프레임워크가 나의 코드를 호출 할 수 있을까? 프레임워크는 내가 작성한 코드를 모르잖아!.
제어를 역전시키는 (프레임워크가 나의 코드를 호출 할 수 있게 하는) 가장 쉽게 생각할 수 있는 접근 방법은 프레임워크의 event, delegate 에 나의 메소드를 등록 시키는 것입니다.
전달되는 인자와 반환 형식만 일치 한다면, 프레임워크 코드는 내가 작성한 객체와 타입을 고려하지 않습니다.
등록된 메소드만 감지하여 실행 invoke 하는 것입니다.
다른 방법은 프레임워크에 정의 되어 있는 인터페이스 interface, 추상타입 abstract 을 나의 코드에서 구현, 상속 한후 프레임워크에 넘겨주는 것입니다.
프레임워크는 인터페이스와 추상을 알고 있으므로 내가 하고자 하는 일련의 작업을 처리할 수 있습니다.
이는 객체를 프레임워크에 주입하는 것이고, 이를 의존을 주입 dependency injection 한다고 합니다.
위의 글을 간단히 정리해 보면 라이브러리는 그냥 함수들이나 기능 모음을 가져다가 쓰는 것이고. 프레임워크는 특정 디자인 패턴이나, 전처리 후처리에 필요한 동작과 기능들을 수행하기 위해서 프레임워크가 실행되다가 중간 중간에 특정 비지니스나, 특정 구현 단에서만 사용자의 코드를 lookup(검색)하여 사용하는 형태라고 할 수 있습니다.
아직까지 개념이 모호하다면 좀더 구체적인 예를 들어보도록 하겠습니다.
일단 모든 소스코드든 라이브러리든 간에 메모리에 들어가는 정보는, 컴파일러나 인터프리터에게는 호출가능한 모듈일 뿐입니다.
이런 물리적인 계층을 보지말고, 그 위의 논리적인 계층을 봐야합니다.
라이브러리는 톱, 망치, 삽같은 연장입니다.
사람이 들고 썰고, 바꿔들고 내려치고, 다시 바꿔들고 땅을 파는 겁니다.
프레임워크는 차, 비행기, 배같은 탈 것입니다.
사람이 타서 엔진 켜고, 기어 넣고, 핸들 돌리고, 운전하거나, 조종하거나 해야합니다.
도구를 쓸 때, 급하면 썰어야 할 곳에 망치를 쳐도 됩니다. 땅 파야할 때 톱으로 땅을 긁어내도 됩니다.
사람은 도구를 선택하는 입장이기 때문에, 어떤 도구를 사용하든 원하는 것을 만들어낼 수 만 있으면 됩니다.
반면에, 탈것은 정해진 곳으로만 다녀야 합니다.
차를 타고 하늘을 날거나, 배를 타고 땅으로 갈 수는 없습니다.
하지만, 그 목적에 맞게 만들어져 있기 때문에, 톱이나 망치를 들고 먼저 탈것을 만들어야 할 필요가 없습니다.
그저 정해진 규칙에 맞춰서 엔진, 기어, 핸들만 잘 돌리면 되는 것입니다.
라이브러리와는 달리 프레임워크는 이미 프로그래밍할 규칙이 정해져 있습니다.
예를 들어, 설정파일로 사용되는 XML에 어떤 태그를 써야하며, 어떤 함수를 추가적으로 작성해야하고, 소스 파일을 어느 위치에 넣어야하며, DB와 연동하기 위해 무엇을 써넣어야 하는지 정해져 있습니다.
보통 이런 대부분의 작업은 프레임워크가 하고자 하는 일에 비하면 아주 작은 일이며, 사람은 극히 일부분만 조정함으로써 목적을 달성할 수 있습니다.
만약 프레임워크가 담당하는 부분이 내가 하고자 하는 목적과 다를 경우에는 어떻게 해야 할까요?
그렇다면 단순히 프레임워크를 잘못 가져다 쓴 것입니다.
더 목적에 가까운 프레임워크를 찾아보면 대부분 있을 것이고 없거나 찾기 힘들다면 비슷한 프레임워크를 라이브러리 단계에서 변경해서 다른 프레임워크로 만들면 될 것입니다.
차를 튜닝한 다음에, 차를 다시 운전하면 된다는 것이라고 할 수 있습니다.
혹시 프레임워크 없이 그냥 라이브러리로만 만들면 안될까요? 안될 이유가 어딨겠습니까?!
그냥 다 다시 만들 능력과 시간과 여유만 있다면 그렇게 해도 됩니다.
스스로 만든 프레임워크는 버그도 스스로 잡아야하지만, 남들이 만들어놓은 프레임워크는 쓰는 사람이 많은 만큼 그만큼 수정이나 업데이트도 빠릅니다.
기능이 마음에 안드는 부분이 있다면, 프레임워크를 고쳐서 사용할 수 있습니다.
처음부터 모든 것을 만드는 것보다는 훨씬 비용이 적게 들 것입니다.
내일 당장 지방에서 서울로 출근해야하는데, 혼자서 차를 만들어서 타고 가야한다는 생각을 해보세요.
[인용, 출처] 거꾸로 배우는 소프트웨어 개발, 프레임워크와 라이브러리, 토비의 스프링3, https://kldp.org/node/124237