프레임워크
Framework.
사전에서는 '뼈대, 틀, 체계'와 같은 의미로 설명하는 단어다. 컴퓨터 소프트웨어에서 많이 쓰이는 용어로, 어떤 플랫폼을 기반으로 응용프로그램을 빠르고 간편하게 만들 수 있도록 여러 가지 함수, 클래스, 데이터, 그밖에 필요한 것을 묶어서 제공하는 소프트웨어를 뜻한다. 이는 응용프로그램을 만들기 위한 하나의 틀, 즉 템플릿을 제공한다.
윈도우, 맥, 안드로이드, iOS와 같은 운영체제, 또는 웹과 같은 플랫폼에서 돌아가는 프로그램을 만들려면 많은 양의 코드를 필요로 한다. 'Hello world' 달랑 한 줄을 출력하는 프로그램을 만들려고 해도 바닥부터 직접 만들려고 하면 수백 줄의 코드를 써야 할 수도 있고 추가로 이런 저런 설정 파일까지 작성해야 한다. 여기에 뭔가 쓸만한 기능을 붙이려면 코드의 양은 크게 늘어난다. 그런데 이러한 코드 중에는 중복되는 것도 많고, 새로 프로그램을 만들 때마다 규칙에 따라 똑같은 코드를 수십 수백 줄 씩 작성해야 할 때도 많다. 실제 내가 구현하고 싶은 기능을 위한 코드보다 어떤 플랫폼에서 그 프로그램이 돌아가기 위해서 작성해야 할 코드의 양이 더 많을 때도 비일비재하다.
또한 많은 응용프로그램은 비슷비슷한 패턴을 가지고 있다. 예를 들어 웹 프로그램은 사용자의 요청이 들어오면 데이터베이스에서 데이터를 꺼내오고 이를 적당히 가공해서 사용자에게 HTML 형식으로 응답을 보내준다. 때로는 사용자의 요청으로부터 데이터를 받아서 데이터베이스에 새로 데이터를 넣거나 기존 데이터를 업데이트할 수도 있다. 많은 프로그램들은 이러한 과정이 많이 닮아 있다. 만약 어떤 뛰어난 프로그래머가 이를 패턴화하여 공통으로 쓸 수 있는 코드를 만들고, 실제 프로그램을 만드는 개발자는 이 코드에 자신이 구현하고자 하는 기능만 얹으면 개발에 들어가는 시간과 노력을 대폭 단축할 수 있을 것이다. 예를 들어 피자를 만들 때, 그 기반이 되는 밀가루 빵, 즉 도우는 밀가루를 반죽하고 발효시키고 빙빙 돌려가면서 원판 모양으로 만들려면 시간과 노력은 물론 상당한 기술이 필요한데, 알고 보면 대부분 피자는 같은 도우를 사용한다. 그렇다면 도우는 미리 만들어 놓은 다음에 내가 먹고 싶은 토핑만 얹으면 피자를 만드는 데 드는 시간이 크게 단축될 것이고, 그렇다고 맛도 그닥 떨어지지 않을 것이다.[1] 도우를 만드는 기술과 토핑 뿌리는 기술을 생각해 보면 누가 봐도 토핑이 훨씬 쉽다.
장점
프레임워크를 사용함으로써 개발자는 응용프로그램을 만들 때마다 작성해야 하는 많은 양의 비슷비슷한 코드, 이른바 보일러플레이트 코드를 크게 줄일 수 있다. 따라서 자신이 구현하고자 하는 기능에 더 많이 집중하고 시간을 쓸 수 있다. 또한 잘 만든 프레임워크는 응용프로그램을 효과적으로 만들 수 있는 좋은 패턴을 제공해 주므로, 이러한 패턴을 따라가면 경험이나 실력이 아직 충분하지 않은 개발자도 효율이 좋은 코드를 만들 수 있다. 여기에 더해 프레임워크는 많은 테스트를 거치고 계속해서 사용자의 피드백을 받아서 문제점을 개선하므로 버그가 적다. 만약 프레임워크를 사용하지 않고 직접 다 코드를 짰다면 어마어마한 버그에 시달렸을 텐데 적어도 프레임워크에 해당하는 코드는 직접 짰을 때와 비교하면 버그가 큰 폭으로 적을 것이다.
최근에는 다양한 운영체제와 플랫폼에서 실행될 수 있는 응용프로그램을 만들 수 있는 크로스플랫폼 프레임워크들이 등장하고 있다. 모바일 운영체제의 투톱인 안드로이드와 iOS 양쪽을 모두 지원하는 리액트 네이티브, 자마린, Flutter와 같은 프레임워크들이 경쟁을 하고 있고, 심지어 웹과 데스크톱 환경으로까지 보폭을 넓히고 있다. 데스크톱 운영체제 중심으로는 일렉트론 프레임워크가 윈도우, macOS, 리눅스를 아우르고 있으며 Flutter도 아성을 넘보고 있는 상태.
단점
물론 반대급부도 있다. 최적화라는 측면에서 본다면 직접 바닥부터 코드를 짰을 때와 비교했을 때 프레임워크는 불필요한 코드가 들어갈 가능성이 높다. 프레임워크는 광범위한 응용프로그램에 사용될 것을 전제로 하고 만들기 때문에 개별 프로그램의 관점으로 보면 자신에게는 필요 없는 코드가 들어가 있을 가능성이 높다. 따라서 불필요한 코드 때문에 프로그램의 덩치가 커지거나, 속도가 느려지거나 할 수 있다. 이른바 '맥가이버 칼'로 알려진 스위스 아미 나이프는 여러 가지 공구가 들어 있기 때문에 그거 하나만 가지고 다니면 여러 가지 작업에 사용할 수 있지만 개개의 도구만으로 놓고 보면 전용 공구보다는 떨어지며 그 중에 일부만 사용하는 사람들이라면 불필요한 공구까지 함께 가지고 다녀야 한다. 범용성을 추구할수록 공구의 종류가 많아지므로 일부 도구만 사용하는 사람들은 더더욱 불편해진다. 예를 들어 드라이버와 나이프만 사용하는 사람이라면 8개 공구가 들어 있는 거나 12개 공구가 들어 있는 거나 사용하는 건 두 가지 뿐인데 12개 공구는 훨씬 불편할 것이다. 프레임워크 개발자도 이런 문제를 알고 있어서 될 수 있으면 각 응용프로그램에 필요한 코드들만 포함될 수 있도록 모듈화나 패키지와 같은 다양한 기법을 사용하고 있지만 아무래도 한계는 있다.
크로스플랫폼 프레임워크의 경우 같은 코드로 여러 운영체제 및 플랫폼을 넘나드는 응용프로그램을 작성할 수 있다는 장점이 있으나, 뒤집어 말하면 프레임워크가 지원하는 범위가 이들 운영체제 및 플랫폼의 교집합으로 갇히기 쉽다는 문제가 있다. 즉 개별 OS가 각자 지원하는 기능을 사용하기가 어려워진다. 또한 모바일 환경은 메모리 및 저장장치가 데스크톱에 비해 빡빡한 경우가 많은데, 네이티브로 개발한 앱보다 덩치가 크고 메모리도 많이 먹는 단점이 더 크게 부각될 수 있다.
프레임워크는 사용하는 프로그래밍 언어가 정해져 있으며, 개발 방법론이나 코드의 구조를 특정한 패턴으로 고정하는 경향이 있다. 이러한 특징은 골치아프게 많이 생각할 거 없이 프레임워크가 잡아놓은 뼈대대로만 프로그래밍하면 많은 수고를 덜 수 있다는 커다란 장점이 있으나, 고급 개발자에게는 자유도를 가로막는 원인이 될 수 있다. 특히, 프로그래밍도 시간이 지나면 여러 가지 방법론으로 발전하고 진화하는데, 나온지 시간이 많이 지난 프레임워크는 이러한 변화와 발전을 제대로 반영하지 못해서 도태될 수 있으며, 이렇게 되면 다른 프레임워크를 사용해야 하는데 그러면 이전에 쓰던 프레임워크로 작성한 코드는 다 내다 버려야 할 수 있다.[2]
결국 프레임워크는 속도나 최적화를 위해 쓰는 물건이 아니다. 가장 중요한 것은 생산성이다. 즉 대다수 응용프로그램이 많이 사용하는 기능을 위한 코드는 프레임워크가 제공하고, 개발자는 자신의 응용프로그램을 위한 코드에 집중함으로써 개발 기간을 단축하는 것이 가장 큰 이유다. 또한 지식과 경력이 뛰어나지 않은 프로그래머라고 해도 프레임워크가 제공하는 방법론 안에서 프로그래밍을 하면 그럭저럭 좋은 코드를 짤 수 있다는 것 역시 장점이다.
라이브러리와의 차이
라이브러리나 패키지도 클래스, 함수, 데이터가 묶여서 어떤 기능을 제공한다는 점에서는 닮아 있지만 가장 큰 차이점이라면 라이브러리는 어떠한 '기능'을 편리하게 구현할 수 있는 소프트웨어의 묶음이라면 프레임워크는 하나의 완전한 응용프로그램을 만들 수 있을 정도로 각종 기능을 제공하는 묶음이다. 즉 라이브러리는 어떤 프로그램이 필요로 하는 최소 한 가지의 기능만 제공해 주면 되며 그것만으로는 하나의 완전한 응용프로그램을 만들 수 없다.[3] 프레임워크는 하나의 완전한 응용프로그램을 만들 수 있는 각종 기능을 제공하며 따라서 하나의 프레임워크는 거의 대부분 여러 개의 라이브러리를 품고 있다.
응용프로그램 프로그래밍 인터페이스와의 차이
응용프로그램 프로그래밍 인터페이스(API)는 '통신'에 초점을 맞춘 소프트웨어다. 어떠한 운영체제나 플랫폼 위에서 응용프로그램을 만들려는 개발자가 그 OS 혹은 플랫폼과 어떻게 통신할 것인가를 정하는 '규약'이라고 할 수 있다. 예를 들어, 윈도우의 창에 'Hello, world!'라는 글자를 표시하려면 어떻게 해야 할까? 윈도우 API는 이를 위한 함수[4]를 정의한다. 인터넷의 날씨 정보 서버로부터 오늘의 날씨 데이터를 받아오려면 어떻게 해야 할까? 날씨 정보 서버는 어떤 URL에 어떤 매개변수 혹은 POST 데이터를 넘겨주면 정보를 어떤 형식으로 돌려주는지를 정의해 놓는다. 따라서 API는 운영체제 또는 플랫폼이 제공하는 함수, 클래스, URL와 같은 통신 수단의 인터페이스, 즉 '정의'에 가깝다. 실제 응용프로그램을 작성하기 위해서는 이러한 API에 따라 작성된 라이브러리가 필요할 수도 있고, REST API처럼 그냥 URL로 인터페이스를 정의해 놓은 문서만 있으면 그만일 수도 있다.
