[번역] 왜 Library들이 Framework 보다 더 나은가

원문 :  tom.lokhorst.eu/2010/09/why-libraries-are-better-than-frameworks

Why Libraries are better than Frameworks – Tom Lokhorst's blog

오역. 의역이 있을 수 있습니다.

잘못된 부분이 있다면 댓글 부탁드립니다.

왜 Librarys가 Frameworks 보다 더 나은가

 

어플리케이션을 디자인하는데 두가지 방법이 있습니다. 특정한 framework에 기반하거나, 라이브러리를 사용하는 것입니다. 사실, 두가지 방법을 혼합하여 사용하는 등 어플리케이션을 만드는 방법은 더 다양하지만, 이 두 방법에 집중해 보도록 하겠습니다.

 

먼저, "Framework" 라는 단어를 정의해보자. 이 단어를 Platform 이라는 것과는 분리해서 말하고 싶습니다.

플랫폼은 어플리케이션을 그 위에 짓기 위한 어떤 가장 낮은 단계이고, 예는 운영체제의 가상머신들을 들 수 있습니다.( 리눅스, OS X, 자바, .NET 등) 이러한 플랫폼들은 훌륭합니다. 이를 통해 개발자들은 소켓이나 파일시스템같은 "배관"들을 모두 재사용하면서 해당 어플리케이션의 논리구조에 집중할 수 있습니다.

그러나 내가 말하는 "프레임워크"는 당신의 어플리케이션이( 또는 어플리케이션의 일부가)  그 안에 존재하는 것을 의미합니다. 이러한 프레임워크의 예는 Java의 Swings 또는 ASP.NET MVC 가 있습니다.

 

 

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

프레임워크와 라이브러리에 대해서 다양한 정의들이 있지만 그것들에 대해 알아보는 대신 그림을 통해서 내가 생각하는 그 둘의 차이점에 대해 이야기해 보도록 하겠습니다.

 

 

 

 어떤 프레임워크를 사용해서 어플리케이션을 만들 때, 어플리케이션은 프레임워크의 "내부에" 존재하게 됩니다. 이것은 어플리케이션이 프레임워크의 어떤 class를 상속받으려고 할 때 가장 눈에 띕니다. 어플리케이션의 입장에서 프레임워크는 전체 세계라고 볼 수 있습니다. 프레임워크는 어플리케이션이 원하는 모든것을 해 줄 수 있는 하나의 강력한 환경입니다.( 최소한 특정 도메인에 한해서는..)

 

 그 대체제로서, 어플리케이션은 라이브러리들을 사용하여 작성될 수 있습니다. ( 라이브러리'들' 이다, 단 하나인 경우는 절대 없다.) 설계를 할 때, 라이브러리는 어플리케이션의 옆에 고정되어지는 것입니다. 어플리케이션은 독립적으로 존재하고, 특정 프레임워크 밖에서도 정체성을 갖습니다, 그리고 일의 일부분을 수행하는데 라이브러리들을 사용하는 것입니다.

 

프레임워크의 장점

 Martin Fowler (* 리팩토링 의 저자 ) 는 블로그 글에서 “제어의 역전(Inversion of Control)” 을 "프레임워크의 특징을 정의하는것" 으로 표현합니다. 위키피디아 에서도 역시 '제어의 역전'을 기본 행동,확장성과 함께  프레임워크를 구분짓는 특징으로 이야기하고 있습니다.

 제어의 역전은 또한 할리우드원칙 “Don’t call us, we’ll call you (호출하지 마세요. 우리가 당신을 호출할 것입니다.)" 로도 알려져 있으며 확실히 장점이 되기도 합니다. 이것의 예시는 데이터를 렌더링하는 그래픽(웹) 어플리케이션이 있습니다. 

 이 예시에서 데이터를 사용자에게 렌더링하는것에 대한 책임이 프레임워크에게 있습니다. 따라서 응용프로그램은 필요한 데이터의 양이나 계산시기를 몰라도 됩니다. 프레임워크가 응용프로그램의 코드를 호출하게 함으로써, 그들이 필요할 때 데이터를 요청하고, 지금 표시할 만큼의 데이터만 요청하게 됩니다.

  이 내용에 대해서는 마틴이 더 잘 설명을 해주었습니다.

Inversion of Control is a key part of what makes a framework different to a library. A library is essentially a set of functions that you can call, these days usually organized into classes. Each call does some work and returns control to the client. 제어의 역전은 프레임워크를 라이브러리와 다르게 구분짓는 핵심 요소이다. 라이브러리는 본질적으로 호출할 수 있는 함수의 집합이고, 요즘에는 대개 class로 구성되어있다. 각 호출이 이루어질 때 일을 하고 나서 client 에게 제어권을 반환한다. A framework embodies some abstract design, with more behavior built in. In order to use it you need to insert your behavior into various places in the framework either by subclassing or by plugging in your own classes. The framework’s code then calls your code at these points. 프레임워크는 더 많은 동작들을 내장하고있으며, 어떤 추상적인 설계들을 가지고 있다. 프레임워크를 사용하기 위해서는 상속을 하거나 자체 클래스를 연결하는 방법을 통해 당신의 행동을 프레임워크의 여러 위치에 맞추어 넣어주어야 한다. 그런 다음 ,프레임워크가 당신의 코드를 특정 시점에 호출할 것이다.

 

 

프레임워크의 단점

나는 이미 내가 생각하는 프레임워크의  단점 몇가지를 넌지시 이야기했습니다. (alluded)

 가장 먼저, 프레임워크는 client code 로부터 많은 것을 요구합니다. 어떤 객체지향 프레임워크들에서는 인터페이스 구축을 요구하기도 하고 또는 심지어 프레임워크의 base 클래스로부터 상속받아야 합니다.

 이런 것의 예시는 자바 GUI 프레임워크인 Swing 이 있습니다. 개발자는 Jcomponent 의 상속클래스를 만들어야만 합니다. 이렇게 했을 때, 예를들어 paint 메소드를 재정의 해서 super.getX()로 프레임워크를 호출하면, 프레임워크가 다시 당신의 코드를 호출합니다. 이런 설계를 이용함으로서, 당신은 Java에서 유일하게 사용할 수 있는 상속 메커니즘을 포기하는 셈이다. 모든 멋진 객체지향 디자인과의 바이바이입니다.

 

프레임워크는 대체하기 어렵기로 악명이 높습니다(notoriously hard). 정확하게는 프레임워크가 어플리케이션의 전체 세계이기 때문입니다. 만약 사용하고있는 암호화 라이브러리가 마음에 들지 않는다면 , 다른 라이브러리로 대체하면 된다. 프레임워크안에서는, 이것이 불가능합니다. 프레임워크만 그냥 교체할 수 없습니다. 

 프레임워크 내부 기능을 우회해서 새로운 암호화 라이브러리를 '추가' 하는것이 유일한 희망이라고 할 수 있겠습니다. 물론, 라이브러리들의 API들이 상당히 다를 수 있기 때문에 라이브러리를 교체하는 것도 품이 든다고 할 수 있겠지만, 어쨌든 이건 할만하다는 것입니다.

 

마찬가지로, 전달값을 대체하기 어려운 것도 플렛폼에 반해서 사용될 수 있습니다. 그러나 이 부분은 덜 문제가 된다고 생각된다. 일반적으로 순정 응용프로그램이 플렛폼 입장에서 더 네이티브하게 느껴진집니다. 예를 들어, 기본 OS X 어플리케이션은 OS X의 기능을 쓰지 않는 다른 어플리케이션들보다 훨씬 더 잘 동작합니다. 프레임워크를 더 많이 쓰는 어플리케이션은 네이티브하게 느껴지지 않습니다.

 

프레임워크에서 내가 느끼는 가장 큰 문제점은 어플리케이션과 프레임워크 간의 단단한한 결합입니다. 어플리케이션이 프레임워크가 어떤 일을 하도록 호출하고, 프레임워크는 어플리케이션을 다시 호출합니다. 이런 단단한 결합은 잘 알려진 소프트웨어 설계 규칙을 완전히 위반하는 것이고, 위에 기술된 문제들의 궁극적인 원인이 됩니다.

 

프레임워크의 대체제

자 , 이렇게 프레임워크에는 장점도 있고 단점도 있습니다.

그렇다면 프레임워크의 좋은 대안은 무엇일까요? 네 물론 라이브러리 입니다. 

 

 " 프로그래밍 언어 " 에 대한 주제로 넘어와야 겠군요. 만약 당신이 사용하는 프로그래밍 언어가 충분히 힘이 있다면, 프레임워크와 동일한 능력을 가진 라이브러리들을 만들 수 있을 것입니다. 고차함수(map)를 이용하여, 코드를 라이브러리로 전달하여 필요할 때 실행하게 할 수 있습니다. 어떤 사람들은 그런 라이브러리는 프레임워크나 마찬가지 아니냐 라고 할지도 모르겠는데, map 함수를 프레임워크라고 부르진 않는다. map 함수 ' 안에 존재 '하지는 않는다.

 

* 참고 : en.wikipedia.org/wiki/Map_(higher-order_function)

medium.com/@la.place/higher-order-function-%EC%9D%B4%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80-1c61e0bea79

Higher-Order Function 이란 무엇인가

 

그래서,  고차함수를 이용하면 프래임워크의 능력들을 라이브러리로 대체할수 있지만, 여전히 뭔가 아닌것 같습니다. 만약 당신의 라이브러리가 수많은 고차함수를 사용한다면 프레임워크와 동일한 기능을 구현할 수는 있지만 그 코드들은 inside-out (?) 으로 쓰여져 있을 것입니다.

 

이 이슈에 대한 해결법은 lazy evaluation (게으른 연산*) 입니다. * 불필요한 연산을 피하기 위해 연산을 지연시키는 것

 

* 참고 : dororongju.tistory.com/137

 

 Lazy가 기본값인 Haskell 같은 언어에서는 응용프로그램은 (잠재적인) 거대한 데이터를 렌더링 라이브러리에 넘겨주기만 한다. 라이브러리는 딱 필요한 만큼의 데이터만을 소비하게 될 것이고, 더이상의 연산은 일어나지 않을 것이다. 다른 말로 하면, Lazy Evaluation은 데이터 공급자와 데이터 소비자를 분리시킨다. 물론 얼마만큼의 데이터가 필요한지에 대한 의사소통이 여전히 필요하지만, 이것은 런타임 시스템이 처리하게 된다. 
 프레임워크와 어플리케이션 사이에 어떤 데이터가 언제 필요한지에 대한 대화가 필요하지 않다.

 Lazy Evaluation을 사람들이 설명하는데 드는 첫번째 예시는  "이제 무한한 소수들의 리스트를 만들 수 있다!" 는 것이다. 근데 누가 그걸 필요로 하는가. 내 생각에 lazy evalation은 그것보다 더 중요한 가치를 가치가 있는데 그것은 바로 소프트웨어 설계의 핵심적인 부분이다. Lazy Evaluation은 당신에게 Composibility 를 준다.

 

*하스켈 : 순수 함수형 프로그래밍 언어 라고함.

 

Composability (구성성?)

*composability

en.wikipedia.org/wiki/Composability

Composability

*Silver bullet : 현대에 와서는 문자 그대로의 탄환을 의미하는 것이 아니라, 어떤 일에 대한 해결책, 특효약, 그리고 스포츠에 있어선 팀의 중심 선수를 일컫는 말로 사용되기도 한다. 또, 소프트웨어 공학 분야에 있어서는 프레더릭 브룩스가 1986년에 발표한 논문에 No Silver Bullet 이라는 말을 사용, 모든 문제에 통용되는 만능 해결책 따위는 존재하지 않는다고 논하였는데, 이는 이상적인 소프트웨어 설계에 대해 부정적인 의미로 사용되는 경우가 많다.

 

 소프트웨어 개발에서 Silver bullet(특효약)은 구성성입니다. 아니면, 만약 여러분이 Silver bullet을 믿지 않는다면, 그냥 올바른 방향으로 나아가는 것이라고 이야기합시다.

 소프트웨어를 레고처럼 여러 파트로 나누는 것과 같은 고전적인 소프트웨어 설계 방식은 여전히 유효합니다. 그러나, 너무나 많은 프레임워크들이 나와 있다는 사실들은 "블록" 만으로는 충분하지 않고 무엇인가 더 필요하다는 것을 보여줍니다.

 제 생각에는, 우리가 만들어야 하는 더 크고 더 복잡한 어플리케이션의 조각들은 정육면체의 블록으로 생기지 않은 것 같습니다. 미래의 "구성품들" 은 더 좋은 composability(구성성) 을 허용하기 위해 lazy evaluation 과 고차함수들을 더 많이 사용하게 될 것 입니다. 라이브러리들을 핵심 기능에서 시작해서 lazy evalaution과 고차함수를 광범위하게 사용하게 까지 작성함으로서, 우리는 재사용성과 구성성이 좋고 느슨하게 연결된 구성요소를 얻을 수 있습니다.

 이 라이브러리들을 사용하는 것이 그 어떤 프레임워트보다 재사용성을 높일 수 있는 방법이며, 이것들이 더 잘 설계된 어플리케이션들이 되도록 해 줄 것입니다.

 

 

결론

 

 결론적으로, 나는 프레임워크가 기존 전통적인 라이브러리들에 비해 갖는 이점들이 비용 대비 크지 않다고 생각합니다. 충분히 강력한 프로그래밍 언어를 사용한다면 , 우리는 lazy evaluation 과 higher-order function을 이용하는 더 나은 라이브러리들을 만들 수 있습니다.

 잘 설계된 라이브러리가 프레임워크에 비해 갖는 유일한 단점은, 빌드하기가 훨씬 어렵다는 것입니다. 프레임워크는 기본적으로 기존 애플리케이션을 가져와서 컨텐츠를 제거하고, 클라이언트 코드에 다시 호출할 수 있는 후크를 삽입하면 되는 것이라 쉽게 만들 수 있습니다. ( 아마도 지나치게 단순화한 것일 수도 있지만, 저는 프레임워크를 두들겨 패는 것을 좋아합니다ㅋㅋ..) 반면, 라이브러리는 설계되어야하고, 깨끗하고 좋은 API가 필요합니다. 그렇지 않다면 재사용성이 떨어집니다.

 거꾸로 말하면, 프레임워크는 사용하려면 종종 "학습"이 필요한 반면, 라이브러리의 경우는 덜합니다. 사람들은 특정 프레임워크를 사용하는 방법에 대한 책을 통째로 읽어야 하지만, 라이브러리를 사용할 때는 그냥  프로그래밍을 시작하면 됩니다.

 다시 말하지만, 나는 프레임워크를 사용하는 것의 비용이 그것이 주는 이익보다 더 크다고 생각합니다. 특히 점점 더 많은 라이브러리들이 lazy-evaluation과 high-order-fuction을 사용하기 시작하고 있습니다. 특히 하스켈 같은 언어에서요.

소프트웨어 구성요소의 미래는 라이브러리입니다.
다른 말로 표현하면: 하스켈 사용자 분들.. 제발 "프레임워크"를 만들지 마세요, 우린 그보다 더 좋은 방법을 쓸 수 있습니다!