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

프레임워크도 알고있고, 라이브러리도 알고있지만 이 둘의 차이점에 대해서는 잘 알지 못하고 넘어가는 경우가 많다. 단순히 API를 모은 게 라이브러리고 라이브러리가 모여서 프레임워크가 되는거 아니야? 라고 말할 수 있지만 사실 그렇게 쉽게 설명되지 않는 문제이다. 프레임워크를 설명할 때 등장하는 다른 여러 개념들이 있기 때문에 이 개념들과 함께 프레임워크를 알아보도록 하자.

프레임워크의 개요

---

프로그램 개발에 투입되는 개발자들이 늘어남에 따라서(특히 객체 지향 프로그래밍이 늘어남에 따라서) 다양성 또한 비례되어 늘어나고, 전체 시스템의 통합성, 일관성이 부족함을 느끼게 되었다. 그래서 개발자의 자유를 제한하는 대신에 일정한 테두리 안에서 일관되고 유지 보수를 쉽게 개발할 수 있는 환경인 프레임워크를 도입했다.

프레임워크란?

---

기본적인 뼈대가 이미 완성되어 있고 규칙이 존재하는 개발 환경

한마디로 정의하자면 위와 같다. 쉽게 예를 들자면 자동차의 뼈대가 있다면 이 뼈대를 기초로해서 세단이나 쿠페, SUV 등 외형을 덫붙혀 자동차를 완성하게 된다.

이 뼈대의 역할을 프레임워크가 하고있고 외형적인 네비게이션이나 내장장식, 유리창 등 라이브러리를 가져와서 사용해 붙일 수 있다. 다만 프레임이 만약 4WD 프레임이라면 목적은 오프로드 차량이나 SUV를 의도하는 것이므로 어느 정도 차량을 개발할 때 제약사항이 생긴다.

특정한 틀을 만들어놓고 거기에 살을 붙여 놓음으로써 프로그램을 만들 때 작업시간을 줄여주는 것이다. 이를 스켈레톤 코드라고도 하는데, 뼈대가 이미 만들어져 있어서 거기에 살만 덧붙이면 완성이 되도록 공통된 함수 또는 클래스를 미리 만들어 놓는 것을 이야기한다.

따라서 프레임워크는 다음과 같은 특징을 가진다.

1. 개발자들이 따라야 할 가이드라인을 가진다.
2. 개발할 수 있는 범위가 정해져 있다.
3. 개발자를 위한 다양한 도구들이 지원된다.

프레임워크 사용의 장/단점

---

• 장점

1. 개발편의성이 올라서, 시간을 줄일 수 있다.
2. 오류의 폭을 좁힐 수 있다.
3. 어느 정도의 코드 품질을 보장한다.
4. 유지 보수하기 좋다.

• 단점

1. 프레임워크의 의존도가 늘어나 개발 능력이 저하될 수 있다.
2. 개발자의 자유도가 떨어진다.

 

라이브러리의 개요

---

프로그래밍을 하게되면서 공통적으로 반복적으로 사용되는 기능들이나 특정한 기능들을 부딪히게 되고 그때마다 새로 알고리즘을 짜거나 새로 코딩을 하는 것보다 잘 만들어진 모듈화된 코드를 가져다 쓰는 것이 훨씬 간편하고 안정적이라는 필요와 수요가 생기면서 만들어졌다.

 

라이브러리란?

---

개발 시 활용가능한 도구들을 모아 모듈화한 것

여러 회사들 중에 잘 만든 네비게이션이나 라디오가 있다고 하자. 그렇다면 우리는 하나하나 라디오나 네비게이션을 처음부터 만드는 것이 아니라, 만드는 자동차에 이미 만들어진 이들 네비게이션이나 라디오들을 원하는 곳에 설치만 하면 된다. 다시 돌아와서 설명하자면 여러 라이브러리들 중에서 우리가 원하는 함수, 클래스들만 가져다쓰면 되는 것이다.

 

라이브러리와 API의 차이점

---

여기서 API(Application Programming Interface)랑 햇갈릴 수가 있는데, 라이브러리는 실제로 실행이 되는 기능을 담당하는 단편화된 프로그램이고 API는 다른 목적으로 개발된 프로그램/라이브러리 들의 특정 기능을 호출하기 위해서 인터페이스를 노출시킨 것이 API다.

따라서 특정한 부분만을 수행하며 API자체로는 사용자가 직접적으로 일반적인 조작을 할 수 없다.

예를 들어 네이버 지도를 우리가 직접적으로 코드를 변형시킨다던가 하는 조작은 할 수 없지만 API를 통해 간접적으로 일정한 기능을 호출할 수 있다.

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

---

둘의 개념을 보고도 여전히 차이점에 대해서는 명확히 꼽기 힘들다. 다만 확실한 것은 프레임워크는 단순히 라이브러리의 집합만은 아니라는 것이다.

가장 크게 눈에 띄는 차이점은 바로 환경적인 면이다. 프레임워크는 개발자들의 환경을 제한하는 대신에 일정한 환경을 제공한다.

하지만 라이브러리는 그냥 내가 원하는 코드를 내가 원할 때 원하는 곳에 가져다 넣으면 된다. 여기서 고려해야할 환경은 없고 오로지 의도와 목적성만 존재한다.

그리고 또 하나는 제어의 주도성을 누가 가지고 있느냐이다.

이는 자바의 프레임워크 중에 하나인 스프링 관련 저서 토비의 스프링에서 참고할 수 있다.

라이브러리를 사용하는 어플리케이션 코드는 어플리케이션 흐름을 직접 제어한다. 단지 동작하는 중에 필요한 기능이 있을 때 능동적으로 라이브러리를 사용할 뿐이다. 반면에 프레임워크는 거꾸로 어플리케이션 코드가 프레임워크에 의해 사용된다. 프레임워크에는 분명한 제어의 역전 개념이 적용되어 있어야 한다.

여기서 등장하는 용어가 바로 제어의 역전(Inversion Of Control)혹은 제어 역행, IOC라고 부른다. 어렵게 생각할 것 없이 어떤 기능을 불러오고 사용할 때 사용자가 직접하는 것이 아니라 프레임워크가 이 일을 대신하게 된다. 반대로 라이브러리는 그냥 우리가 원할 때 직접 불러올 수 있다. 쉽게 예를 들어본다면 최근 기술적으로 발전하고 있는 자율 운행도 우리가 직접 핸들을 제어하고 조작하는 것이 아니라 자동차 프로그램에서 이를 보정하고 제어하는 것이다. 이 또한 제어의 역전이라고 부를만하다.

하지만 대체 언제 어떻게 프레임워크가 우리 대신에 알아서 이런 기능들을 가져오고 수행한다는 것일까?

이때 같이 알아두어야 할 개념이 바로 의존성 주입(Dependency Injection)인데, 줄여서 DI라고 부른다. 여러 객체들간에 의존성이 생기고 이들 의존성을 정리한 BeanCotainer 정보를 생성하면 이 스프링 컨테이너에서 외부에서 받은 메타데이터를 의존성 주입함으로써 제어의 역전을 일으키며 사용자에게 객체를 전달하게 되는 것이다.

이것 또한 쉽게 설명하자면 객체들을 정리해놓은 메타데이터를 외부에서 주입해주는 것이 DI고 이 주입받은 것을 통해서 프레임워크에 의해 코드가 실행되므로 제어의 역전이 일어난다라고만 이해해두면 괜찮다.