이 책의 저자는 프론트 엔드 개발을 프레임 워크 없이 하자는 주의를 갖고 있으나 그렇다고 프레임 워크를 아예 배제하자는 극단적인 사고 방식을 갖고 있지는 않은 것으로 보인다.
이 책의 장점은 프론트 엔드 개발의 역사를 초반부에서 간략히 소개해주면서 프론트 엔드 개발자가 읽으면 좋을 거 같은 기본 책같다는 생각을 했다.
마치, 사람들이 성장하면서 인류의 역사에 대해 점점 알아가듯 그런 느낌을 받았다.
프레임워크의 정의
이 책에서 프레임워크는 코드를 호출하는 것이라고 한다. 그리고 코드는 라이브러리를 호출한다고 한다.
import React from 'react';
import { useLocation } from 'react-router-dom';
function App() {
const location = useLocation();
return (<div>hello</div>);
}실제 애플리케이션 기능에 영향을 미치는 App 함수 컴포넌트 부분을 보면 useLocation 을 사용하기 위해 라이브러리를 호출하고 있다. 또한, 이 App 함수 컴포넌트를 작성하는 방식은 리액트에 의한 제약사항이라고 볼 수 있다. 내가 이 책을 읽으며 이해한 것은 프로그램 로직 자체가 제약을 받고 있기 때문에 이 책의 저자는 리액트를 프레임워크라고 생각하는게 아닌가 싶었다.
프론트엔드 프레임워크의 간략한 역사
제이쿼리 JQuery
브라우저 호환성, 프론트엔드 프레임워크의 모체
제이쿼리는 2006년에 개발자 존 레식이 개발했으며 이전까지는 웹개발자들이 각 브라우저에 맞춰 자바스크립트 코드를 다르게 작성해줘야했다고 한다. 하지만 제이쿼리의 등장으로 그럴 필요 없이 브라우저 호환성을 맞출 수 있게 되었다고 한다. 예를 들면, AJAX 통신 기능을 구현하더라도 제이쿼리 이전에는 개발자들이 각 브라우저에 맞춰 그 로직을 다르게 구현해줘야했으나 제이쿼리에서는 그럴 필요가 없어졌다고 이해했다.
그리고 제이쿼리는 모든 자바스크립트 프레임워크의 모체가 되었으므로 지금은 구시대의 유물 취급을 받으나 제이쿼리가 프론트 엔드 역사에서는 중요한 가치를 지녔다고 생각했다.
앵귤러JS
양방향 데이터 바인딩 대규모 애플리케이션
앵귤러 JS는 개발자 미스코 헤브리에 의해 개발되었으며 이 개발자가 구글에서 일하게 되면서 앵귤러JS도 구글에서 관리하게 되었다. 앵귤러JS는 프론트엔드 생태계에서 SPA(Single Page Application)이 주류가 되는데 큰 역할을 했다고 한다. 앵귤러는 데이터 바인딩 방식이 양방향인데 Model -> View, View -> Model이다. 이 양방향 데이터 바인딩 방식으로 인해 개발자들은 웹 애플리케이션 개발을 빠르게 할 수 있었다. 하지만 시간이 흐르면서 애플리케이션들의 규모가 점점 커져갔고 큰 규모에서 양방향 데이터 바인딩 방식은 적합하지 않아 개발자들이 앵귤러 JS를 떠나게 되는 계기가 되었다고 한다.
리액트
렌더링 라이브러리, 가상돔
리액트는 2011년 페이스북에서 개발하였으며 현재 가장 인기 있는 프론트엔드 프레임워크라고 한다 리액트의 특징은 개발자가 코드로 DOM(Document Object Model)객체를 직접 조작하는것이 아니라 리액트를 통해 가상 DOM을 조작하면 리액트가 이를 실제 DOM에 적용시키는 방식으로 작동한다. 개발자는 setState 함수를 통해 가상 DOM을 적용한다. 이 부분만 보자면 기술적으로 리액트는 렌더링 라이브러리라고 볼 수 있다. 하지만 리액트 커뮤니티에서 나온 아이디어들로 인해 점점 프레임 워크화 되었다고 생각하는걸로 보인다.
앵귤러
앵귤러 JS를 개발한 개발팀이 새로운 버전의 앵귤러JS를 만들고자 앵귤러 개발을 시작했다. 원래 앵귤러는 앵귤러2라고 불렸으나 전 버전과 앵귤러2의 접근 방식이 완전히 달라 프로젝트가 중단되었다고 한다.
기술 부채
우리가 프론트엔드 프레임워크를 사용할 때 그냥 공짜로 사용한다고 생각할 수 있지만 사실은 프레임 워크를 사용하면서 비용을 지출하게 된다고 한다. 그 이유는 프레임워크를 사용하면 그 프레임 워크는 언젠가는 도태되기때문에 시간이 지나면 기업은 프로젝트에서 그 당시의 프레임 워크를 없애기 위한 비용을 지불할 수 밖에 없다고 한다.
저자는 이것이 부채라고 표현한다. 다른 말로는 빚이 생긴다는 건데 프레임 워크를 사용하는 건 마치 은행에서 돈을 빌려 투자를 하는 것과 마찬가지라고 소개한다.
자신의 소득이 불안정한데 은행에서 대출을 받아 매우 비싼 차를 산다면 그것은 투자라고 볼 수 없다. 하지만 소득이 안정적인 상태에서 은행에 대출을 받아 집을 산다거나 하는 것은 투자라고 볼 수 있겠다. 저자는 프레임워크 사용이 이러한 현실 사례와 비슷하다고 한다.
내가 이 책에서 이해한 바는 프레임 워크를 사용하면 빠른 시간내에 프로젝트를 개발할 수 있고 그 프레임 워크를 프로젝트에서 더 많이 사용할 수록 부채가 쌓여가며 후에는 그 프레임 워크를 걷어내야할때 그 프레임 워크를 아는 개발자를 고용해야한다던지 아니면 개발자들이 그 프레임 워크를 사용하고 싶지 않은데도 학습해서 프레임 워크를 걷어내는데 커리어를 쏟게 된다던지 하는 상황이 발생하기 때문이 아닐까 싶다..
기술 투자
저자는 자신이 프레임 워크를 사용하면서 부채가 생긴다고 말했지만 프레임 워크를 적합하게 사용하면 투자가 된다고 한다. 빠른 시간내에 서비스를 개발하여 수익을 창출해야하는 상황이라면 프레임 워크를 사용하는게 사용하지 않는 것보다 나을 것이므로 투자가 될 수 있는 상황을 말한게 아닌가 싶다. 이 책에서는 프레임 워크가 그냥 빚이 될지 아니면 투자가 될지 판단할 수 있는 기술적 방법을 소개하고 비용이 적게 드는 프레임 워크를 선택하는 방법을 알아본다고 한다.
