0. 사 먹을 것이냐 해 먹을 것이냐. 그것이 문제로다.
FE 개발자 춘길 씨는 퇴근길에 문득, "카레"가 먹고 싶어졌다. 푸짐한 고기와 잘 익은 감자, 당근이 들어가 있는 그런 카레 말이다.
저녁으로 카레를 먹기 위해, 피곤한 몸을 이끌고 장을 보러 온 춘길 씨.
그에게는 두 가지 선택지가 있었다.
1) 직접 해 먹기
2) 카레 밀키트
1안을 택한다면, 조금 더 귀찮기는 하겠지만 내가 원하는 재료를 원하는 만큼 넣어 먹을 수 있을 것이고,
2안을 택한다면, 편하긴 하겠지만 기본적으로 들어있는 재료의 내용물, 비율, 양은 정해져 있어 아쉬움이 남을 수 있다.
즉석식품과 신선 식품 사이를 맴돌며 고민하는 춘길 씨...
그는 피곤한 몸을 이끌고 깊은 고민에 빠져만 간다.
1. 라이브러리와 프레임워크 간단 비교
라이브러리는 카레를 직접 해 먹는 것에 해당한다. 원하는 재료를 원하는 만큼 넣어 우리가 원하는 스타일의 카레를 만들 수 있다. 다만, 손질과 조리에 사용되는 여러 도구의 사용법을 익혀야 하며, 수고로움과 시간이 동반된다.
프레임워크는 카레 밀키트와 같다. 프레임워크는 카레 재료를 위한 일련의 손질 과정은 거의 끝나있으며, 카레의 조리법, 정량, 고기와 야채 등의 재료 비율은 이미 정해져 있는 상태이다. 춘길 씨는 그저 조리도구 사용법을 익혀서 지식의 산물을 완성하기만 하면 되는 것이다. (말은 쉽게 했지만 프레임 워크를 자유자재로 사용하기도 쉬운 일은 아니다)
2. 라이브러리란?
우리가 음악 애플리케이션을 만든다고 가정하자. 데이터들이 Array의 형식을 가진다고 했을 때, index와 관련된 메소드는 굉장히 자주, 그리고 요긴하게 사용될 것이다. 예를 들어 현재 event가 발생한 target인 "곡의 이름", "audioSrc", "imgSrc"를 가져와야 할 경우, 해당 기능이 필요할 때마다 코드를 작성하는 것이 아닌, 하나의 함수나 Class를 선언해 해당 데이터들을 핸들링하게 될 것이다.
쉽게 말해 라이브러리는 작업을 단순화하는 데 사용할 수 있는 함수 및 클래스의 집합을 의미한다. 보편적으로 라이브러리가 다루게 되는 범위는 넓지 않으며, 필요한 종속성이 적다. 라이브러리가 초점을 맞추는 부분은 애플리케이션 전체를 아우르는 광범위한 부분이 아닌, 특정 기능에 집중되어 있기 때문이다.
우리의 춘길 씨가 직접 카레를 만들어 먹기 위해 구매한 재료들을 살펴보자.
구매 내용 : 양파, 세척 감자, 세척 당근, 돼지고기 안심 500g, 고형 카레
카레를 직접 만들어 먹는다는 것이, 직접 감자를 재배하고, 돼지를 길러 카레에 넣어 먹는다는 것을 의미하진 않는다.
이미 타인들이 생산해둔 재료를 이용해 간편히 카레를 만들어 낼 수도 있기 때문이다.
다시 말하지만, 라이브러리란 작업을 단순화하는 데 사용할 수 있는 함수 및 클래스의 집합을 뜻한다.
3. 프레임워크란?
우리는 애플리케이션을 구현하며 특정 기능들이나 컴포넌트들은 반복적으로 생산하는 경험을 필연적으로 하게 된다. 프레임워크는 이러한 반복으로부터 발생하는 비효율성에 초점을 맞춘다.
그것은 여러 편의를 제공하지만, 라이브러리보다 더욱 큰 틀과 방향성을 제공하고 재사용할 수 있는 코드와 그에 맞는 규칙을 제공함에 따라 통해 반복되는 개발 프로세스에 효율성과 효과성을 부여하고자 한다는 것이다.
만약 춘길 씨가, 밀키트(프레임워크)를 구매했다면, 카레를 조리하기 위해 감자를 씻고 껍질을 벗겨내며 먹기 좋은 크기로 썰 필요가 없다는 뜻이다. 프레임워크는 조리를 제외한 일련의 과정이 전부 끝나있으며, 주어진 조리 방법대로 조리를 마치기만 하면 된다.
다만, 밀키트를 사용하는 순간 조리 방법이라는 강제성이 발생한다. 밀키트로 카레를 만드는 경우, 추가로 재료(라이브러리)들을 추가할 수는 있지만, 밀키트의 조리 규칙을 반드시 따라야 한다는 제약이 생긴다.
4. 카레의 맛은 누가 정할까?
직접 카레를 만드는 경우 재료 선정부터 조리과정 선별까지, 온전히 그 요리사에 의해 결정된다. 따라서 카레의 맛과 요리 과정의 주도권은 요리사에게 있다. 라이브러리 또한 그렇다. 애플리케이션 개발의 과정에서 모든 flow는 개발자에 의해 결정된다.
하지만, 밀키트를 사용하는 경우 카레의 맛과 요리 과정은 사실상 밀키트에 의해 결정된다. 프레임워크를 사용할 경우, 애플리케이션 제작의 흐름이나 사용 방식은 전적으로 밀키트 제작사가 결정하기 때문이다.
이 개념이 아래에서 설명할 라이브러리와 프레임워크의 가장 큰 차이점이다.
5. 제어의 역전(Inversion of control)
프레임워크와 라이브러리의 차이점을 가장 잘 설명하는 단어는 제어의 역전(inversion of control)이다.
제어의 역전(inversion of control)이란?
작성한 코드의 flow를 개발자가 직접 제어하는 것이 아닌, 재사용 할 수 있는 라이브러리의 제어를 받게 되는 것.
우리가 라이브러리를 사용할 때, 무엇을 언제 사용하느냐에 대한 flow는 온전히 개발자에게 달려있다. 하지만, 프레임워크를 사용하는 경우 이 flow는 프레임워크로 넘어가게 된다.
우리의 춘길 씨가 라이브러리를 통해 카레를 직접 만들어 먹는다면, 카레에 들어갈 재료 선정, 조리 과정에서 어떤 도구를 쓸 것인가, 조리를 어떤 방법으로 할 것인가, 고형카레를 얼마나 넣을 것인가, 고기를 얼마나 넣을 것인가, 감자의 익힘 정도 등, 수많은 과정은 온전히 춘길 셰프의 손에 의해 결정된다. (flow가 춘길 씨에 의해 제어됨)
다만, 우리의 춘길 씨가 밀키트를 선택했다면 이야기는 달라진다. 밀키트를 조리하는 춘길 씨는 그저 정해진 재료를 정해진 조리법대로 조리를 하게 되며 이 요리에 대한 flow는 밀키트에 의해 제어된다는 것이다.
이것이 제어의 역전이며 라이브러리와 프레임 워크의 차이점이라 볼 수 있다.
댓글