프레임워크 정리 비교 글

Funny Programing

Carry 2017. 12. 21. 09:26

프레임워크의 개념을 한번에 잡아주는 좋은 글이다..

프레임워크란 단어처럼 많이 쓰이면서도 애매한 단어가 없는 것 같다.

일단 구글링을 해 본 결과 다음과 같은 정의를 찾을 수 있었다.

==========================================================================

GoF의 디자인 패턴으로 유명한 랄프 존슨(Ralph Johnson) 교수는 프레임워크를

"소프트웨어의 구체적인 부분에 해당하는 설계와 구현을 재사용이 가능하게끔

일련의 협업화된 형태로 클래스들을 제공하는 것"

이라고 정의하였다.

프레임워크는 라이브러리와 달리 애플리케이션의 틀과 구조를 결정할 뿐 아니라,

그 위에 개발된 개발자의 코드를 제어한다.

프레임워크는 구체적이며 확장 가능한 기반 코드를 가지고 있으며,

설계자가 의도하는 여러 디자인 패턴의 집합으로 구성되어 있다.

==========================================================================

아, 저 말이 바로 이해가 간다면 굳이 다음 글을 읽을 필요는 없다.

이 글은 저 말을 이해하지 못하는 사람들 (나 자신을 포함하여) 을 위해

같은 이야기를 길게 풀어놓은 것에 불과하니까 말이다.

그런 분은 그냥 조용히 뒤로 가기 버튼을 눌러 주시거나,

가볍게 읽으시고 이 글에 잘못된 점이나 미비한 부분을 바로 잡아주셔도 된다.

위에서 프레임워크와 라이브러리를 비교한 글귀를 찾을 수 있듯이,

일단 프레임워크를 라이브러리의 연장선상에서 생각하는 것으로

프레임워크에 대한 이해를 시작해 보자.

라이브러리의 정의는 다들 대강은 알다시피

자 주 쓰일 만한 기능들을 모아 놓은 유틸(클래스)들의 모음집 정도로 정의할 수 있겠다.

사용자(프로그래머)와 실제 구현하고자 하는 기능 사이에,

사용자로 하여금 구현하고자 하는 기능을 쉽게 쉽게 제공해주는 중간 계층이란 면에 있어서

라이브러리와 프레임워크는 일견 비슷한 점이 있다.

음.. 그렇다면 그냥 라이브러리라고 부르면 되지 거창하게 프레임워크로 구분지어 부를 필요는 뭐냐?

대체 차이가 뭐냐? 라는 질문이 나올 법 하다.

프레임워크와 라이브러리의 가장 큰 차이점이라 할만 한건

프레임워크에는 라이브러리에

뼈대가 되는 클래스들과 그 클래스들의 관계로 만들어진

일종의 '설계의 기본 틀'이 추가된다는 점일 것이다.

여기서 쓴 혹은 설계 틀이란 말은

물론 위의 정의에서 나온 '확장 가능한 기반코드'라든지, '재사용 가능한 형태의 협업화된 클래스들' 이라는 말과 같은 뜻이다.

자, 우선 라이브러리부터 생각 해보자.

라이브러리가 아무리 날고 기어봤자 라이브러리는 라이브러리다.

라이브러리가 설계를 대신해주진 않는다.

뭔 말이냐면, 라이브러리는 그저 프로그래머가 프로그램을 짜다가

'아, 요럴 땐 라이브러리에서 이런 기능을 뽑아다 쓰면 되겠구나'

라는 생각이 들었을 때, 그때 그때 필요한 걸 가져다 쓰는 대상이지

라이브러리가 그 기능을 쓰기 위해 필요한(혹은 효율적인) 구조에 대해 말해주지는 않는다는 뜻이다.

따라서, 동일한 라이브러리를 쓰는 동일한 기능의 프로그램일지라도

클래스 관계 구조나, 데이터를 처리하는 절차라든지,

프로그램이 화면에 그려지는 방식 같은 등등의 요소들은

프로그램을 짜는 프로그래머마다 천차만별 일수 밖에 없으며

프로그램을 완성하는 데에 걸리는 시간도, 완성된 코드의 품질도

프로그래머의 역량에 따라 제각각일 것이다.

이제 프레임워크를 보자.

보통 프레임워크엔 프레임워크의 제작자가 '이걸 기초로 해서 만드세염' 이라고

지가 만들어 놓은 '기반 코드'가 있다.

물론 이 코드, 혹은 클래스들은

차후 사용자들에 의해 확장될 것을 충분히 고려해서 만들어졌기 때문에

사용자 입장에서는 그저 이 것을 가지고,

여기 저기를 자기 입맛대로 바꾸고

살을 덧붙여 자기만의 프로그램을 완성해 나가면 되는 것이다.

왜, 비주얼 스튜디오를 켜서 새 MFC 프로젝트를 열고

다이알로그 기반 -> 확인 만 눌러도

일단 기본적으로 돌아가는 다이알로그 박스가 완성되고,

사용자가 만약 여기다 그리기 기능을 추가하고 싶다, 하면

상속 받은 클래스에 OnPaint() 함수를 재정의해서

단순히 함수 몸체 안에 코드를 쳐 넣기만 하면 되는 것처럼 말이다.

이러한 샘플, 즉 '확장 가능한 기반 코드'에는

프레임워크 제작자 나름대로의 설계 철학이 담겨 있으며,

차후 이 프레임워크의 사용자가

제작자가 설계한 구조를 유지하면서 확장할 수 있도록,

제작자에 의해 의도된 제약 사항 이 존재한다.

아까 그 사용자가

OnPaint() 외에 다른 방식으로 그리기 구현을 해보고 싶다거나

혹시라도 OnPaint()가 호출되는 시점을

자신이 통째로 제어해보고 싶다던지 하는 금지된 욕망을 가지게 되면

프로그램 짜기가 상당히 껄쩍지근해 지는 것처럼 말이다.

(물론 불가능한 것은 아니며, 또 꼭 필요할 경우도 있기는 하지만,

이는 프레임워크를 사용할 때의 장점인 신뢰성과 비용 절감을 떨어뜨릴 수 있는 요소이다.)

이런 식으로 사용자에게 가해지는 제약 사항은

(특히 그 제약 규칙이 구조에 대한 것일 경우)

흔히 디자인 패턴을 구현한 코드의 형태 로 표현되는데,

이 중 가장 흔하고 쉽게 찾아 볼 수 있는 예가 MVC 패턴이다.

MFC의 SDI(단일 문서 프로젝트)를 열어보면

처음부터 C~~~View와 C~~~Document의 두 클래스가 생기는 걸 볼 수 있는데

이 것은 이 프레임워크의 제작자가

MVC 패턴을 구현한 클래스인 CView와 CDocument를 기반 코드로 제공함으로써

자기가 만든 프레임워크를 사용하여 만들어지는 프로그램들은

(MVC 패턴을 쓰는 이유인) '데이터의 연산 과 '데이터의 표현'이 서로 분리 되어야 한다는 것을

사용자에게 명시한 것이라고 보면 되는 것이다.

결론적으로 기반 코드는

프레임웍 제작자가 사용자들로 하여금

세세하게 신경 쓰지 않아도 쉽고 빠르게 기능을 확장하거나 유지보수할 수 있게 해주는

구조에 대한 가이드라인 이나,

혹은 함부로 건들 경우 프로그램이 자칫 '신비롭게' 동작할 수 있기 때문에

제약을 가하고 싶은 사항 등을

여러 디자인 패턴을 조합해 표현해 놓은 결과라고 보면 된다.

이 말은 다른 클래스의 부모가 되는 베이스 클래스를 짜본 경험이 있다면

쉽게 이해 할 수 있을 것이다.

다른 클래스들의 기초가 되는 기반 클래스의

각 멤버의 캡슐화 정도,

멤버의 상수화 여부,

다른 클래스들과의 관계,

함수 멤버의 가상화 여부 같은

만들 땐 별거 아닌거 같았던 자잘한 요소들이

후에 말단에서 실제로 사용되는 클래스들의 구현에 지대한 영향을 미치기 때문이다.

별 생각 없이 기반 구조를 짰다가

나중에 말단 클래스에서

어떤 기능을 구현하기가 참으로 난감한 경우가 생겨

기반 구조를 첨부터 다시 뜯어 고쳐야 했던 경험이 다들 한 번쯤은 있을 것이다.

여튼, 얘기가 약간 곁가지를 탄 느낌이 있는데 정리하자면

프레임워크란

설계의 기반이 되는 부분을 기술한 확장 가능한 기반 코드 와

사용자가 이 코드를 자기 입맛대로 확장하는 데 필요한 라이브러리

이 두 가지 요소가 통합되어 제공되는 형태를 말하며,

사용자가 이를 이용해

일정 수준 이상의 품질을 보장받는 코드를, 비교적 빠른 시간에 완성 및 유지 보수할 수 있는

환경을 제공해주는 솔루션으로

"기본적인 설계나 필요한 라이브러리는 알아서 제공해 줄꺼니깐

넌 그냥 니가 진짜로 하고 싶은 기능 구현에만 전념해!"

라는 취지에서 만들어진 물건이란 것이다.

출처 - http://blog.naver.com/PostView.nhn?blogId=sleepy1027&logNo;=150085034164

프레임워크라는 개념을 접하기 전에 '부트스트랩(Bootstrap)'이란 용어를 먼저 알게 되었습니다.

웹 프로젝트를 개발하기 위한 좋은 툴이라는 것을 듣게 되었죠.

그래서 부트스트랩이 무엇인지 자료 조사를 해본 결과, '프레임워크'의 종류 중 하나라는 것을 알게 되었습니다.

그렇다면 프레임워크란 무엇인가? Framework에 대한 개념을 먼저 잡아야겠다는 생각이 들었습니다.

프레임워크란?

Gof의 디자인 패턴으로 유명한 랄프 존슨(Ralph Johnson)은 "프레임워크란, 소프트웨어의 구체적인 부분에 해당하는 설계와 구현을 재사용이 가능하게끔 일련의 협업화된 형태로 클래스들을 제공하는 것" 이라고 정의하였습니다.

프레임워크란 용어를 아직 접하지 못하셨거나

저를 포함하여 접한 지 얼마 안 되신 분들은 아마 이해하기가 힘들 수 있습니다.

보통 Framework는 라이브러리라는 개념과 비교해서 많이 설명합니다.

프레임워크 vs 라이브러리

라이브러리란 자주 사용되는 로직을 재사용하기 편리하도록 잘 정리한 일련의 코드들의 집합 을 의미합니다. (참고: 생활코딩)

생활코딩에서 정의한 라이브러리 내용은 어느 정도 이해가 가지만 저명한 전문가가 Framework를 정의한 것은 이해하기가 쉽지 않습니다. 또한 위의 정의만으로 두 개념 사이의 차이도 명확히 모르겠습니다.

저는 머릿속에 그림을 그려서 이해하는 것을 선호합니다. 예를 들어보겠습니다.

프레임워크는 자동차의 프레임, 즉 기본적으로 구성하고 있는 뼈대를 말합니다.

라이브러리는 자동차의 기능을 하는 부품을 의미합니다.

예를 들어, 자동차를 굴러갈 수 있게 하는 바퀴, 어두운 밤을 환하게 비출 수 있는 헤드라이트, 비 올 때 창문을 닦아주는 와이퍼 등이 라이브러리라고 할 수 있습니다.

한 번 정해진 자동차의 프레임은 바꾸질 못합니다.

소형차를 만들기 위해 뼈대를 사용하는데, 이 뼈대로 SUV를 만들 수는 없습니다.

그러나 바퀴나, 선루프, 헤드라이트 등은 비교적 다른 종류로 쉽게 바뀔 수 있겠죠.

사실 자동차를 만들기 위해서 자동차의 프레임과 부품들을 가져다 쓰지 않아도 됩니다.

프레임을 일일이 만들고, 부품을 일일이 만들어서 자동차를 만들어도 됩니다.

그러나 너무 많은 시간과 비용이 들지 않겠습니까?

그래서 프레임워크와 라이브러리가 존재하는 겁니다.

내가 정말로 원하는 기능을 구현하기 위해 기본적인 뼈대와 부품을 가져다 쓰겠다는 겁니다.

자동차에 하늘을 나는 기능을 온전히 구현하기 위해 자동차의 프레임과 부품을 아웃소싱 하겠다는 거죠.

Framework라는 개념은 대강 잡았으니 써봐야 되겠죠?

종류에는 무엇이 있는지 한번 살펴보겠습니다.

프레임워크 종류

구분 종류 자바 프레임워크 Struts, Spring, 전자정부 프레임워크 QRM 프레임워크 myBatis(iBatis), Hibernate 자바스크립트 프레임워크 AngularJS, React, Polymer, Ember 프론트엔드 프레임워크 Bootstrap, Foundation, MDL

Framework라는 개념을 지금까지 들었을 때 좋아만 보입니다.

하지만 동전의 앞면이 있으면 뒷면이 있듯이 모든 것은 장, 단점이 존재합니다.

프레임워크의 장, 단점

장점

1) 효율적.

- 아무것도 그려지지 않은 제로에서 코드를 일일이 짜는 것보다 시간과 비용이 훨씬 절약되며 생산성이 좋아집니다.

2) Quality 향상.

- 버그 발생 가능성을 처리해줌으로써 개발자가 반복 작업에서 실수하기 쉬운 부분을 커버해줍니다. 다수의 개발자가 사용하며 수정하다 보니 이미 검증된 코드라고 볼 수 있습니다.

3) 유지 보수 Good!

- 프레임워크를 쓰지 않고 일일이 코드를 짜 놓은 경우, 회사 입장에서 개발 담당자가 바뀌어버리면 곤란해집니다. 그러나 Framework를 사용하면 코드가 보다 체계적이어서 담당자가 바뀌더라도 위험부담을 줄일 수 있으며 유지 보수에 안정적입니다.

단점

1) 학습시간이 길다.

- 코드를 본인이 짜 놓은 것이 아니기 때문에, 프레임워크에 있는 코드를 습득하고 이해하는 데 오랜 시간이 걸립니다.

2) 제작자의 의도된 제약 사항

- 제작자가 설계한 구조를 어느 정도 유지한 채 코드에 살을 붙여나가야 합니다. 따라서 개발자는 자유롭고 유연하게 개발하는 데 한계가 있습니다.

프레임워크는 단점이 존재하지만 단점을 커버할 수 있을 만한 좋은 장점이 있습니다. 개발의 상황과 목적에 맞는 프레임워크를 잘 파악하여 선택한다면 시간과 비용을 줄이는 것은 물론이고 코드의 품질이 훌륭한 개발을 할 수 있을겁니다.

모든 전문 분야가 그렇듯 개발 용어에도 일반적으로 사용하지만 다른 뜻이 있는 경우가 있습니다.

그중에서 개발 입문자나 혹은 현업 개발자지만 정의를 내리기 곤란한 라이브러리, 프레임워크, 아키텍처, 플랫폼에 대한 개인적인 생각을 정리했습니다.

이해를 돕기 위해 자동차로 비교하여 설명하도록 하겠습니다.

라이브러리란? - What is Library?

간략 설명: 프로그램 제작 시 필요한 기능

비교 설명: 자동차 바퀴, 자동차 헤드라이트, 자동차 에어백

재사용이 필요한 기능으로 반복적인 코드 작성을 없애기 위해 언제든지 필요한 곳에서 호출하여 사용할 수 있도록 Class나 Function으로 만들어진 것입니다.

사용 여부는 코드 작성자 선택 사항이며 새로운 라이브러리 제작 시에도 엄격한 규칙이 존재하지 않습니다. 제작 의도에 맞게 작성하면 됩니다.

라이브러리 예시

가장 유명한 자바스크립트 라이브러리는 jQuery입니다. (간혹 프레임워크라고 소개되는 곳이 있는데 공식 사이트에서도 라이브러리로 명시되어 있습니다.)

그래픽 사용자 인터페이스(Graphical user interface , GUI)에서 재사용하기 쉽게 버튼, 테이블 같은 구성 요소를 호출해서 쓸수 있도록 분리해두었다면 라이브러리입니다.

Windows에서 간혹 보았을 dll 확장자는 동적 링크 라이브러리(dynamic-link library, DLL)의 약자로 라이브러리라고 할수 있습니다.

객체지향 프로그래밍(object-oriented programming, OOP)은 기본적으로 각 기능마다 함수화하는 것으로 클래스 라이브러리라고 할수도 있습니다.

프레임워크란? - What is Framework?

간략 설명: 프로그램 기본 구조(뼈대)

비교 설명: 자동차 프레임

원하는 기능 구현에만 집중하여 빠르게 개발 할 수 있도록 기본적으로 필요한 기능을 갖추고 있는 것으로 위에서 설명한 라이브러리가 포함되어 있습니다.

프레임워크만으로는 실행되지 않으며 기능 추가를 해야 되고 프레임워크에 의존하여 개발해야 되며 프레임워크가 정의한 규칙을 준수해야 합니다.

겉보기에는 비슷하지만 많은 프레임워크가 존재하는 이유는 아래에서 설명하게 될 아키텍처가 다른 것이며 규칙을 준수해야 되는 이유기기도 합니다.

프레임워크 예시

Java 개발자라면 Spring!

Python 개발자라면 Django!

JavaScript 개발자라면 Angularjs!

PHP 개발자라면 Laravel!

아키텍처란? - What is Architecture?

간략 설명: 프로그램 주요 구조 설계

비교 설명: 자동차 도면

기획한 내용을 프로그램화했을 경우 필요한 주요 특징을 기술적으로 설계하고 명시하는 것입니다.

결과물에 필요한 모든 구성 요소를 명시하지만, 구체적인 구현 방법은 포함되어 있지 않습니다. 가령, 아래에서 설명할 플랫폼은 주요 특징이지만 프레임워크와 라이브러리는 주요 특징이 아니므로 명시되지 않을 가능성이 큽니다.

자동차 설계로 예를 들면 자동차 헤드라이트가 본넷 밑에 사각형 모양으로 존재한다고 설계하고 헤드라이트 고정 방식이 접착제인지, 볼트인지는 명시되지 않는다고 볼 수 있습니다. 하지만 상황에 따라 포함될 수도 있습니다.

아키텍처 예시

PC를 조립하기 위해 하드웨어 부분을 확인하고 선택한 리스트가 아키텍처라 할수 있습니다.

Azure 솔루션 아키텍처

인기 있는 소셜 네트워크 서비스로 본 아키텍처

플랫폼이란? - What is Platform?

간략 설명: 프로그램 실행 환경

비교 설명: 자동차 주행 환경(일반 고속도로용, 사막 전용, 경주용, 달 탐사용)

프로그램이 실행되는 환경이며 플랫폼은 플랫폼위에 다른 플랫폼이 존재할 수 있습니다. 가령, Windows에서 Java로 개발하고 있으며 앱스토어에서 어플을 내려받는 과정에서 이미 3개의 플랫폼을 사용하고 있는 것입니다.

플랫폼은 같은 영역에도 다양한 목적과 가치로 많이 만들어지고 있으며 모든 플랫폼에서 실행되도록 개발하기는 어렵습니다. 프로그램의 목적에 맞도록 플랫폼을 선택하는 것이 중요합니다.

플랫폼 예시

Windows, Linux, macOS등 O/S는 모두 플랫폼입니다.

어플을 다운받는 앱스토어, 구글플레이, 원스토어도 플랫폼입니다.

V8 JavaScript Engine은 JavaScript에게 큰 힘이 되어주고 있는 플랫폼입니다.

Java 프로그램은 OS제약이 없지만 실행하기 위해서는 해당 OS에 자바 가상 머신(Java Virtual Machine, JVM)위에서 실행되므로 Java 플랫폼이 필요합니다.

마무리하며

견해의 차이는 있을 수 있다는 점을 알아주시고 잘못된 부분이나 알려주실 것이 있다면 댓글 남겨주시면 많은 도움이 될 거 같습니다.

그리고 이 글은 2008년 1월 23일에 블로그에 포스팅했으나 현재 유실된 자료로 다시 정리하였습니다.

과거 게시글은 INTERNET ARCHIVE 사이트에서 확인 가능합니다. (https://web.archive.org/web/20080218135155....)

1,2,3 비교를 통해 어떤 설명이 더 직관적으로 이해되는지 비교 할 수 있어서

빠른 이해를 하려면 어떤 요소를 찾아야 하는지 알 수 있다.

<출처>

http://jokergt.tistory.com/89

http://moolgogiheart.tistory.com/87

http://blog.gaerae.com/2016/11/what-is-library-and-framework-and-architecture-and-platform.html

from http://fp11.tistory.com/23 by ccl(A) rewrite - 2020-03-07 12:56:08