프레임워크 (Framework)
Frame (틀/규칙) + Work (일)의 합성어로, 어떠한 일을 하기 위한 뼈대/구조를 의미한다.
소프트웨어의 전체적인 부분에 해당하는 설계와 구현을 재사용이 가능하게 하는 것이 목적이다.
따라서 애플리케이션 개발 시 필수적인 코드와 DB 커넥션 등의 기본 기능들을 제공하며, 개발자는 이러한 뼈대 위에서 추가적인 개발을 하는 것으로 기능을 추가할 수 있다.
앱/서버 등의 구동, 메모리 관리, 이벤트 루프 등의 공통된 부분을 프레임워크가 관리하며, 사용자는 프레임워크가 정해준 방식대로 클래스, 메서드들을 구현하면 된다.
한 번쯤 들어봤을 JAVA 서버 개발의 Spring 웹 개발에 사용되는 Angular, Vue.js 등도 모두 프레임워크의 일종이다.
이해를 쉽게 하기 위해 프레임워크는 자동차 프레임에 비유하기도 한다.
일반적으로 자동차는, 아래 그림처럼 모두 유사한 모양을 하고 있다.
구체적인 색이나 모양은 조금씩 다르지만, 공통적으로 직사각형에 위가 볼록한 모양을 하고 있다.
만약 아래와 같이 자동차의 기본 뼈대를 만들어 제공한다면, 색을 칠하고 바퀴를 다는 것만으로 자동차를 조금 더 쉽게 만들 수 있지 않을까?
이렇게 개발에 있어 공통적인 뼈대를 제공하는 것을 프레임워크라고 할 수 있으며, 색을 칠하고 바퀴와 창문을 만들어 붙이는 개발자의 추가적인 코딩을 통해 자동차 아니, 프로그램을 완성할 수 있다.
하지만 만약 바퀴를 만들 시간이나 능력이 부족하다면 어떻게 해야 좋을까?
답은 바로 라이브러리에 있다.
라이브러리(Library)
라이브러리는 개발에 필요한 것들을 미리 구현해 놓은 도구이다. 재사용이 가능한 기능을 미리 구현해놓고, 필요한 곳에서 그때그때 호출하여 사용할 수 있다.
위의 자동차 만드는 과정을 다시 살펴보자.
바퀴가 이미 만들어져있다면 그냥 사 와서 붙여도 되지 않을까?
사용자는 여러개의 바퀴 중 하나를 선택해서 붙일 수도 있고, 심지어 중간에 바꿀 수도 있다.
바퀴뿐만이 아니다. 창문도, 헤드라이트도 가져다 달 수 있다.
이처럼 라이브러리는 특정 기능을 모아둔 코드, 함수들의 집합이며 코드 작성 시 활용 가능한 비휘발성 자원/도구들을 의미한다.
C++의 표준 템플릿 라이브러리(STL), Node.js의 npm으로 설치한 모듈 등이 해당한다.
라이브러리는 다시 빌드 호출 시점에 따라 정적, 동적 라이브러리로 나눌 수 있다.
- 정적 라이브러리
컴파일러가 소스 파일을 컴파일할 때 참조되는 프로그램 모듈로, 빌드 시에 라이브러리가 제공하는 코드를 실행파일에 넣는다. 시스템 환경이 변해도 앱에는 아무 영향이 없으며, 완성된 앱을 안정적으로 사용 가능하다. 사용하는 모든 오브젝트 코드를 실행 파일에 내장하므로, 메모리에 로드되는 앱 코드가 많아진다는 단점이 있다.
- 동적 라이브러리
프로그램 수행 도중 해당 모듈이 필요할 때 호출되어 사용하는 프로그램 모듈로, 앱을 빌드할 당시 존재하지 않았던 라이브러리도 사용 가능하다. 플러그인 형식으로 경로를 설정해야하며, 설치가 따로 필요하다.
동적 링크 라이브러리는 실행 파일과 관련된 라이브러리를 모두 메모리에 읽어들여 호출 관계를 조정한 후에 앱이 실행된다.
동적 로드 라이브러리는 실행 파일 실행 시 읽어 들이지 않는 라이브러리를 추가적으로 이용할 수 있다.
프레임워크 vs 라이브러리
프레임워크와 라이브러리는 사용자의 개발을 편리하도록 도와준다는 점에서 같지만,
"제어 흐름"의 권한이 다르다는 점에서 명확한 차이가 있다.
프레임워크는 단지 미리 만들어준 반제품이나, 확장해서 사용할 수 있도록 준비된 추상 라이브러리의 집합이 아니다. 프레임워크가 어떤 것인지 이해하려면 라이브러리와 프레임워크가 어떻게 다른지 알아야 한다.
라이브러리를 사용하는 애플리케이션 코드는 애플리케이션 흐름을 직접 제어한다.
단지 동작하는 중에 필요한 기능이 있을 때 능동적으로 라이브러리를 사용할 뿐이다.
반면에 프레임워크는 거꾸로 애플리케이션 코드가 프레임워크에 의해 사용된다.
프레임워크에는 분명한 [제어의 역전] 개념이 적용되어 있어야 한다.
애플리케이션 코드는 프레임워크가 짜 놓은 틀에서 수동적으로 동작해야 한다.
- 토비의 스프링-
여기서 프레임워크에 적용된 제어의 역전(IoC, Inversion of Control)이란, 프레임워크에 제어의 흐름을 넘겨 개발자가 작성하는 코드에서 신경 써야할 부분을 줄인다는 뜻이다.
프레임워크 위에 개발자가 작성한 애플리케이션 코드가 올라가고, 이 코드가 다시 라이브러리를 호출할 수 있다.
위의 자동차의 예시로 다시 넘어가보자.
자동차 프레임은 사용자가 쉽게 자동차를 만들 수 있도록 제작되었지만, 바퀴 4개를 특정한 위치에 달아야한다는 것은 사용자가 바꿀 수 없다. 반면 어떤 모양의 바퀴를 달지는 사용자가 선택할 수 있다. 만약 자동차 프레임과 함께 기본 바퀴가 제공된다면, 기본 바퀴를 사용할 수도 다른 곳에서 가져온 바퀴를 사용할 수도 있다.
자동차 프레임은 프레임워크, 바퀴는 라이브러리로 치환된다.
프레임워크는 개발의 전체적인 흐름과 방향을 잡고 있으며 개발자의 코드는 프레임워크 위에 얹을 수 있다. 따라서 개발자 코드는 프레임워크의 틀 안에서 수동적으로 동작하기 때문에 제어의 흐름은 프레임워크에 있다고 할 수 있다. 또한 기본 바퀴가 제공되는 것처럼 프레임워크 안에 라이브러리가 포함되어 제공될 수 있으며, 사용자는 프레임워크에서 제공된 라이브러리의 사용 여부 역시 선택 할 수 있다.
반대로 라이브러리는 개발자가 필요한 순간에만 호출해서 사용하게 된다. 따라서 제어권은 개발자에게 있으며, 필요할 때마다 능동적으로 라이브러리를 호출해 사용할 수 있다.
Reference
https://cocoon1787.tistory.com/745
https://contents.premium.naver.com/3mit/wony/contents/220803201944775qi
https://code-lab1.tistory.com/284
https://blog.gaerae.com/2016/11/what-is-library-and-framework-and-architecture-and-platform.html
'Programming > Architecture' 카테고리의 다른 글
| [Architecture] MVC, MVP, MVVM Pattern (0) | 2024.01.13 |
|---|---|
| SDK vs API (0) | 2023.04.11 |
댓글