라이브러리 vs 프레임워크
한마디 버전 한국어 : 프레임워크라는 개념보다는 오래된 개념인 라이브러리는 단지 어떠한 기능들을 얻기위한 클래스/메소드의 집합체입니다. 하지만, 프레임워크는 어떤 기능들이 특별한 목적을 가지게끔 확장하거나 특정하도록 만들게끔 당신의 코드를 호출한다. 이런 원리를 우리는 '제어 역전' 이라고 한다. 다시 말해, 당신의 코드가 라이브러리는 호출하는 반면, 프레임워크는 당신의 코드를 호출한다. 영어 : A library, an older concept than a framework, is simply a collection of classes/methods to obtain certain functionalities. However, the framework calls your code to make certain functions expand or specific to have special purposes. This principle is called 'Inversion of Control'. In other words, your code calls the library, while the framework calls your code. |
가장 중요한 개념 중 하나라고 생각해서 적어봤지만, 중요한 개념은 사실 이것뿐이 아닙니다.
1. 개요
우리는 개발할때(현업일 경우) 또는 개발을 앞으로 하면서(미래의 현업자!) 종종 '프레임워크'와 '라이브러리'와 같은 단어를 듣게 됩니다. 사실 어디서 배운적이 없습니다. 너무나 자연스럽게 사용하고 익히면서 둘의 차이점을 인지하지 못하고 살아왔습니다. 면접질문에 종종 등장하는 주제이기도 하지만, 어지간히 오래 개발 하신분에게 물어봐도... '아.. 그거..? 그거.. 그거잖아..'
그 분께서 모르시는 것은 절대 아니실 거고요. 한 번도 생각 안해보셔서 어떻게 말해줄지 모르시는 걸꺼에요. 하지만, 우리는 개발자에게는 커뮤니케이션 스킬도 중요하다고 말씀드렸었습니다. 그래서 한번 주제로 골라보았어요.
2. Independency(독립성)
프레임워크가 많은 라이브러리의 집합체인 반면, 라이브러리 하면 가장 먼저 떠오르는 단어가 바로 독립성입니다. 많은 라이브러리들이 다른 모듈이나 라이브러리에 의존하기도 하지만, 라이브러리가 가지는 덕목중 하나는 독립성입니다.
3. 라이브러리의 역할
라이브러리를 이해하려면 우리는 라이브러리가 왜! 생겼는지를 먼저 알아야 합니다. 아주 오래전에 프로그래밍이라는 것을 처음 할때, 그 당시 엔지니어들은 코드들이 상당히 복잡했습니다. 처음부터 끝까지 다 작성해야 했기 때문이지요. 때문에, 어플리케이션이 점점 더 커지면서, 버그 수가 급증하고 감당할 수 없는 지경이 되었습니다. 그래서, JOVIAL(ALGOL와 유사한 프로그래밍 언어)에서 어플리케이션 코드를 작게 쪼개는 방법을 도입했고, 이게 지금의 라이브러리의 기초가 되었습니다.
그리고 나서, KISS규칙(Keep it Simple, Stupid), 리눅스 방식(Linux-way) 이 탄생 했습니다. Github에 라이브러리를 찾아 다니다 보면 KISS Rule 이라는 것을 보실 수 있습니다. 모듈이나 라이브러리는 한가지 일 수행하고, 그리고 그것을 아주 잘 수행해야 했습니다. << 이것이 역할 이렇게 하나씩 역할을 쪼개서 나누어 큰 어플리케이션을 구현하는 겁니다. 이렇게 라이브러리가 분할정복(Divide and Conquer)기법과 만나 지금의 라이브러리 시스템이 생겼습니다.
4. 라이브러리의 단점
세상을 변화시켰던 라이브러리 지만, 단점이 있습니다. 바로 버그 전파와, 라이브러리 제한 입니다.
버그전파 : "딩그르르"가 "헬로월드" 라이브러리를 사용하는데 이 라이브러리가 "안녕" 이라는 라이브러리에게 의존하고 있습니다. 만약 이 "안녕" 라이브러리에 버그가 있다면, 모두가 잘못된 계산을 하게 될것입니다. 종속성과 버그가 합쳐지면서, 안드로메다급 버그가 생겨버립니다. 그리고 이 사슬이 길어지면 길어질수록 문제는 거지게 되죠.
라이브러리 제한: 제한사항이 있습니다. 바로 라이브러리의 내부가 사용자에게 숨겨져 있는 경우가 많은 것인데요. 이것은 사실 의도적으로 숨겨진 것입니다. 어떤 역할을 하는지 아는 라이브러리일 경우 그 코드를 볼 필요없기 그 해당 작업을 맡기면 되니까요. 하지만, 숨겨져 있다보니, 모든 상황에 대한 디버깅이 상당히 힘듭니다. 보다 자세히 살펴보거나 이 라이브러리에서 제공할 수 없는 정보를 얻어야 할 수도 있습니다. 요즘은 뭐.. 코드 공유 플랫폼들이 Git을 이용해서 많이 나와 괜찮지만요.. ㅎㅎ
5. 프레임워크의 역할
프레임워크는 "일반적인 기능을 제공하는 소프트웨어를 다른 사용자로 부터 추가적으로 작성된 코드와 합쳐서 특정 기능을 가진 소프트웨어를 제공한다" 라는 추상적인 개념입니다.
그럼 왜 추상적인 개념일까요?
프레임워크는 우리가 개발을 할때 대략 뭐.. 한.. 대충..? 반정도 완료된 상태로 우리에게 던져집니다. 우리는 그것을 채워나가는 것이지요. 우리가 라이브러리를 호출했지만, 프레임워크는 우리가 채워나간 것을 호출합니다. 그리고 우리가 두번째로 주목할 것은 위에 2번 항목에 이야기 한 것처럼, 다른 라이브러리들과 합쳐집니다.
프레임워크는 우리가 빠르고 쉽게 코딩할 수 있도록 도와주고 디자인패턴 중 하나인 MVC 패턴을 훌륭하게 지원해준다는 것입니다.(Django 처럼요!)
6. 프레임워크 단점
추상적인 개념으로 쉽고 빠르게 코딩할 수 있었던 반면, 이것이 역으로 단점이 될 수 있습니다. 다른 방향으로 개발하는 것이 다소 제한되어 있습니다.
7. 결론
이게 다는 아닐겁니다. 어쨌든! 우린 이 둘을 모두 다 써야 하고 쓰게 되어있습니다. 빠르고, 많은 사람들에게의해 다듬어진 우수한 품질의 코드, 그리고 재사용 가능성 및 제어까지 할 수 있는 라이브러리와 빠른 프로그래밍과 큰 커뮤니티의 지원등을 등에 업고 개발을 하게 해주는 프레임워크. 우리는 이 둘을 모두 다 써서 개발을 하면 어떨까요? ㅎㅎ
