31
12월
2019

내맘대로 돌아보는 2019 Frontend 트렌드

오랫동안 프론트엔드 쪽의 일을 해왔지만, 이 분야는 새로운 것들이 등장하는 속도가 정말 빠름을 느끼고 있습니다. 어느덧 한해를 정리하고 다음 해를 준비하는 연말이 왔는데요, 나름대로 2019년에 프론트엔드 분야에서 화제가 되었던 것들을 돌아보고, 관심있는 분야와 공부해야 할 것들을 개인적으로 정리해봤습니다.

자세한 설명은 구글링으로 훨씬 좋은 자료를 찾을 수 있기 때문에 이론 설명보다는 개인적인 의견을 좀 더 담아봤습니다.


함수형 프로그래밍

현재의 프로그래밍 패러다임은 절차형에서 객체지향형, 객체지향형에서 함수형으로 이동하고 있는데요, 올해엔 유난히 함수형 프로그래밍 (Functional Programming, FP) 도입에 대한 논의가 많았던 것 같습니다.

함수형 프로그래밍은 기존의 절차형 / 객체지향형 프로그래밍과 다른 사고방식으로 문제를 해결합니다. 간단하게 정리하자면 어떤 문제를 해결할 때 해결에 필요한 동작을 아주 작은 단위까지 나눈 후 순수 함수(Pure function)로 만들고 이를 조합하여 해결하는 방식입니다. 또한 순수 함수는 공유 상태, 데이터의 변경, 부작용을 최소화하거나 제거해야 합니다.

객체지향형 프로그래밍함수형 프로그래밍
어떤 방법으로 해야하는가? (How)무엇을 할 것인가? (What)
명령의 수행함수의 조합
알고리즘을 명시하고 목표를 명시하지 않음목표를 명시하고 알고리즘을 명시하지 않음
동작하는 부분을 캡슐화하여 이해할수 있음동작하는 부분을 최소화하여 이해할 수 있음
추상화, 캡슐화, 상속, 다형성1급 객체, 순수함수, 고차함수, 불변성, 합성

다만 자바스크립트는 함수형 프로그래밍에 적합하지 않다는 것도 잘 알려져 있는데요,

  • 함수형 프로그래밍에서는 입출력이 완벽히 제한된 순수 함수가 필수이지만, 자바스크립트는 어떤 함수라도 this 때문에 이미 외부 입력이 들어가게 됩니다.
  • 값의 불변성(immutable) 역시 보장할 수 없습니다. letvar 문법은 말그대로 “변수”이기 때문에 불변성을 부여할 수 없습니다. const 역시 객체가 할당되면 변경이 가능하기 때문에 불변성과는 관련이 없습니다. Object.freeze() 를 사용해도 완벽한 immutable 객체를 만드는 것은 불가능합니다.
  • 자바스크립트의 객체는 call by reference (정확히는 call by sharing) 특성이 있기 때문에 이 역시 불변성과 어긋나게 됩니다.
  • 자바스크립트의 변수는 동적 타이핑이기 때문에 파라메터의 타입에 따라 함수의 결과가 달라지는 것도 문제입니다. 같은 함수라도 변수에 따라 3, “12”를 출력할 수 있다는 것은 함수형 프로그래밍에 있어서 방해가 되는 요소입니다.
  • 함수형 프로그래밍을 도입해서 얻을 수 있는 장점은 병렬 컴퓨팅, 즉 요즘 CPU의 추세에 맞는 멀티코어 프로그래밍에 유리하다는 것인데, 솔직히 자바스크립트에 적용하기엔 좀 애매합니다.

위와 같은 이유로 자바스크립트의 특징과 맞지 않는 프로그래밍 패러다임을 도입하는 것에는 부정적이지만, 함수형 프로그래밍 자체가 좋은 방식임에는 동의하고 있습니다. 어렵지만 익숙해진다면 문제 해결에 아주 유연하게 대처할 수 있는 좋은 방식입니다.

또한, 자바스크립트 자체가 어떤 패러다임이든 수용할 수 있는 유연한 언어입니다. ES6에서 객체지향 프로그래밍을 위해 Class가 추가되었듯, 함수형 프로그래밍에 적합한 문법도 추가되고 있습니다. (대표적으로 array의 map, filter, reduce 등) 그리고 함수형 프로그래밍을 지원하는 Ramda.js 라던가 Lodash FP도 이미 나와있습니다.

현재는… 함수형 패러다임을 넘어 반응형(ex. RxJS), 함수형 반응형(응?) 으로 넘어가고 있는 중이라고 합니다.

# https://github.com/Functional-JavaScript/FunctionalES
# https://velog.io/@kyusung/%ED%95%A8%EC%88%98%ED%98%95-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D-%EC%9A%94%EC%95%BD
# https://codeburst.io/functional-programming-in-javascript-e57e7e28c0e5
# https://medium.com/javascript-scene/master-the-javascript-interview-what-is-functional-programming-7f218c68b3a0

React와 Vue, Angular의 프레임워크 전쟁

frontend를 위한 언어로 css, html, javascript 는 당연한 선택입니다. 하지만, 요즘에는 그것 외에도 프로젝트 / 프로덕트의 성격에 따라 어떤 프레임워크를 사용할지 대부분 react겠지만, 저장소 패턴을 사용할 경우 어떤 상태관리 라이브러리를 사용할지 대부분 redux겠지만, 필요한 기능에 따라 node.js, babel, css pre-processor, 테스트 도구, 빌드 도구 대부분 webpack이겠지만 등을 선택해야 합니다.

최근에는 어지간한 소규모 프로젝트, 유틸리티가 아니라면 순수한 es6 vanilla로 진행되는 경우는 없다보니, 결국 프레임워크 선택이 가장 먼저 선행되어야 할 업무이기도 하죠.

2019년도 특별한 이변 없이 React, Vue, Angular 의 프레임워크 3대장이 현업을 리드하고 있는 것 같습니다. React hooks 때문 만은 아니겠지만, 역시 React는 부동의 1위를 유지하고 있습니다. 2020년엔 어떻게 될지는 모르겠지만, 프로젝트의 특성과 스펙에 따라서 프레임워크를 신중하게 선택할 필요가 있다고 생각합니다.

https://www.npmtrends.com/angular-vs-react-vs-vue

여담이지만, 12월 말이 되면 npm trends의 그래프가 급격히 꺾이는데 아마도 연말에 많이 놀아서 그런 것 같습니다. ㅋㅋㅋ

# Thinking in React

css-in-js

현재의 프론트엔드 개발 트렌드는 빠르게 변화하고 있지만, CSS의 개발 방식은 이전과 다를바 없이 계속 정체되어 있는 상황입니다. 모든 스타일을 하나의 CSS파일에 넣어 관리하는 전통적인 방식이 가장 많이 사용되고 있죠.

하지만 프론트엔드에 요구되는 스펙이 복잡하고 방대해진 만큼, 기존 방식만으로는 CSS의 개발과 관리가 어려워지고 있습니다. 특히 유지보수가 힘들어지고 있습니다. 주의를 기울이지 않으면 사용되지 않는 코드가 계속 남는 일도 허다합니다.

프레임워크 기반으로 개발한다면, css-in-js 개발 방식을 함께 도입하는 것도 고려할 만 합니다. 현재는 styled-components가 많은 인기를 얻고 있는데, css를 개발해봤다면 항상 했던 고민을 해결해주는 좋은 솔루션이기 때문입니다. 특히 다른 라이브러리에 비해 CSS문법을 거의 그대로 사용할 수 있다는 장점도 있습니다.

  • CSS를 컴포넌트 단위로 분리할 수 있으며, 유지보수에 유리합니다.
  • CSS파일은 항상 전역 scope로 동작하기 때문에 naming이 매우 중요하지만, css-in-js에서는 그럴 필요가 없으며 naming으로 고민하지 않아도 됩니다.
https://www.npmtrends.com/emotion-vs-jss-vs-styled-components

다만 단점도 있습니다. 현재는 css, js의 개발자가 달라서 개발 영역이 분리되고 협업이 필요한 경우가 많은데 (팀원이든 팀이든 회사든) 협업에는 불리한 방식이라는 점이 있습니다. 그리고 기존의 CSS를 완벽하게 대체할 수 없다는 점(대표적으로 css sprite)도 문제였습니다. 파일 크기 면에서도 이전처럼 CSS파일로 분리하여 관리하는 것이 아직은 가장 효율적입니다.

확실히 js보다는 html, css를 더 오래 개발해왔던 입장으로서 아직은 발전 여지가 좀 있는 분야라고 생각합니다.

TypeScript

TypeScript는 마이크로소프트에서 개발한 자바스크립트의 superset(상위 확장)입니다. 즉 자바스크립트에 정적 타이핑을 추가한 것입니다. 자바스크립트 개발 중 버그는 사실 동적 타이핑 때문에 발생하는 것이 많기 때문에 TypeScript의 도입 만으로 개발중 버그를 많이 잡을 수 있습니다. 프로젝트가 대규모이고 장기간 유지보수해야 할 경우 더욱 큰 장점이 됩니다.

from https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html

아이러니컬한 일이지만, 자바스크립트의 동적 타이핑은 다른 언어 개발자들이 이해하지 못하는 최대의 장애물인데 TypeScript로 인해 좀더 접근이 쉬워졌다고 합니다.

Typescript와 비슷한 정적 타이핑을 지원하는 라이브러리로 페이스북의 Flow가 있지만, 사실상 Typescript의 승리(?)라고 표현할 수 있을 것 같습니다. 2019년 12월 기준 최신 버전은 3.7인데, optional chaning, nullish coalescing operator의 지원이 시작되면서 한번 더 화제가 되기도 했죠.

https://www.npmtrends.com/typescript-vs-flow-bin

# https://www.typescriptlang.org/
# https://ahnheejong.gitbook.io/ts-for-jsdev/

TC39의 활약

자바스크립트의 최근 트렌드에 관심이 있다면 optional chaning, nullish coalescing operator에 대해서 많이 들어봤을 겁니다.

자바스크립트는 주로 “자바스크립트”라고 불리기는 하지만, 사실 ECMA script (ECMA-262)가 정식 명칭인 것은 다들 아는 사실인데요, 이 표준의 명세를 관리하는 단체가 TC39 입니다.

github repository로만 운영하다가 올해에 https://tc39.es/ 라는 주소로 공식 홈페이지가 개설되었고, 여기서도 제안과 토론이 진행되고 있는 스펙을 확인할 수 있습니다.

대부분 잘 아는 버전은 큰 변화가 있었던 ES6(2015), async / await를 도입한 ES8(2017)이 있습니다. 이것 이외에는 큰 변화가 없기 때문에 잘 언급되지 않고 있긴 하지만, ES10(2019)도 당연히 발표되었었고, 내년에는 ES11이 나오겠지요. 아마도 optional chaning (stage4), nullish coalescing operator (stage3) 등이 포함될 것 같습니다.

# https://github.com/tc39/proposal-optional-chaining
# https://github.com/tc39/proposal-nullish-coalescing

GraphQL

RESTful Api 개발 방식은 진입점(endpoint)이 여러개이고 하나의 진입점에서는 한가지 종류의 응답만 받을 수 있습니다. GraphQL은 이런 한계를 극복하기 위해 페이스북에서 만든 API통신용 query language인데, RESTful Api에 비해 많은 장점을 가지고 있습니다.

  • 클라이언트 측에서 직접 쿼리를 작성하기 때문에 서버를 수정할 필요가 없고 API를 재설계, 변경하는 비용을 없앨 수 있습니다.
  • 클라이언트에서 꼭 필요로 하는 데이터만 받을 수 있고, 클라이언트의 스펙이 변경되어도 유연하게 대처할 수 있습니다. 즉 자유도가 높아집니다.

대표적으로 Github API v4가 GraphQL을 지원합니다.

다만, 마냥 장점만 있는 것은 아닙니다. 프론트엔드 입장에서는 API까지 설계해야 하는 책임이 넘어오게 되어 할일이 더 늘어나는 것이 되기도 합니다. 또한 서버의 성능도 고려하여 정교하게 쿼리를 만들어야 합니다. 서버와의 협업도 더 긴밀해질 필요가 있지요.

RESTful 방식과 GraphQL의 장단점이 갈리고, GraphQL의 명세도 계속 추가되고 있는 상황이기 때문에 GraphQL로 완전히 전환하는 것은 시기상조로 보입니다. 그래도, 새로운 프로젝트를 시작하는 설계 시점에서 백엔드와 함께 GraphQL의 도입에 대해 논의해보는 것도 좋을 것 같습니다.

현재 GraphQL을 사용할 수 잇는 플랫폼으로는 Apollo (client/server)가 있습니다.

# https://graphql.org/
# https://tech.kakao.com/2019/08/01/graphql-basic/

devops 지식의 필요성

자바스크립트가 node.js라는 전환점을 맞아 프론트엔드 뿐만 아니라 백엔드 영역까지 확장하게 되었는데요, 이젠 프론트엔드 뿐만 아니라 backend, devops 영역의 지식까지 필요하게 되었습니다.

웹서비스의 Client to Server 구조 하에서 프론트엔드 개발자의 역할은 css, image, js 파일을 웹서버에 업로드하는 것 뿐입니다. 하지만, 백엔드 영역까지 확장하게 된 이상 백엔드 개발, 서버의 구축, 더 나아가 devops 영역의 지식도 필요하게 됩니다. 특히 1000tps가 넘는 대용량 서비스를 고려하다 보면 생각보다 많은 운영 지식이 필요하게 됩니다.

인프라 영역은 큰 IT 회사라면 전담 멤버가 있을 정도로 깊이가 있는 영역인데, 프론트엔드 개발자가 이 모든 분야를 다 챙길 수 없는 것은 당연합니다. 그래도 프론트엔드 개발자로서 대략적인 지식이 있으면, 운영 문제 등이 발생해도 담당자와 함께 빠르게 대응하는 것이 가능하지 않을까요?

nginx/apache, http(s), 캐시(CDN), DNS, Load balancer(L4/L7), domain, 보안, CI, 모니터링 등등 공부할 거리가 아주 많아졌습니다.

웹어셈블리

웹어셈블리(Web Assembly, wasm)는 C와 C++, RUST 같은 프로그래밍 언어로 작성된 프로그램을 어느 브라우저든 빠르게 실행되는 byte code로 컴파일하는 기술의 표준입니다.

즉 어떤 언어로 작성한 프로그램이든 웹에서 실행할 수 있기 때문에 웹과 앱의 경계가 허물어지는 이정표, 그리고 html / css / javascript 의 뒤를 잇는 제 4의언어라고 언급되기도 합니다. 현재 W3C Web Assembly working group을 통해 웹표준으로 개발이 되고 있으며 생각보다 많은 웹브라우저에서 지원하고 있습니다.

from https://caniuse.com/#feat=wasm

사실 프론트엔드 개발자로서 직접 wasm을 개발할 일은 많지 않을 것 같습니다. 프론트엔드 개발 입장에서는 C, C++, RUST 같은 언어로 작성된 프로그램이 wasm으로 컴파일되면 자바스크립트에서는 표준 API를 사용하여 로딩한 후 실행하기만 하면 됩니다. 어찌 보면 다른 언어로 개발된 web worker 같다는 느낌도 듭니다.

여러 언어로 작성된 코드들이 웹브라우저 안에서 네이티브에 가까운 속도로 실행되는 토대가 마련되었기 때문에 앞으로 어떻게 발전될 지 기대가 되는 분야입니다.

# WebAssembly becomes a W3C Recommendation
# https://developer.mozilla.org/ko/docs/WebAssembly


프론트엔드 분야는 “자바스크립트가 github 내의 부동의 점유율 1위”라는 소식은 더이상 신선하지 않을 정도로 많은 변화가 있습니다. 내년에는 어떤 새로운 도구와 프레임워크가 나올지…. 한순간도 공부를 게을리 할 수가 없게 되었습니다.

평생 프론트엔드 일만 해도 마스터할 수 없겠지만, 내년도… 힘을 내서 열심히 달려보려고 합니다. 🙂

1 Response

  1. HelloSamuel 댓글:

    좋은글 잘 읽고 갑니다 🙂

댓글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다

%d 블로거가 이것을 좋아합니다: