제 깃헙 페이지에 올렸던 글인데 글쓰는 공간을 이사 하면서 옮긴 글입니다.
요즘 프론트엔드 개발은 예전과 사뭇 다른 것 같다. 물론 모든 시스템이 그러하진 않겠지만 많은 어플리케이션들이, 백엔드는 점점 API화 되어 가고 프론트엔드에서는 처리하는 일들이 점점 많아지고 있고 따라서 프론트엔드 구조 또한 많이 복잡해지고 정교해 지고 있다. 그리고 그렇게 복잡해지고 있는 프론트엔드 개발에 맞춰 자동화 시스템도 동시에 점점 복잡 다양해 지고 있다.
이 글은 특별한 의미는 없고 그냥 개발 초기 세팅을 할 일이 그다지 많지 않은 나로써는 초기 세팅을 할 때마다 무엇들을 세팅하고 설치했는지 순서나 툴들이 기억이 안나 멍해질 때가 간혹 있어서 나름 다시 상기 시키기 위해 정리해 보는 글이다.
초기 셋업
Yeoman – 스카폴딩 (scaffolding)
쉽게 말하자면 어떤 프로트엔드 프레임웍을 쓰느냐 또는 어떤 서버앱을 쓰느냐에 따라 프로젝트 디렉토리 구조가 조금씩 바뀌는데 이런 폴더 구조 및 초기 세팅시 항상 필요한 기본 파일들을 자동으로 셋업 해 주는 툴이다. yo 명령어와 함께 generator라 불리는 각종 셋업 툴들 중 원하는 툴을 다운 받아 실행 시키면 그에 맞는 폴더 및 기본 파일들이 모두 자동으로 셋업 된다.
패키지 관리 툴
NPM – 노드 페키지 메니저
페키지라는 단어가 명확하지 않을 수 있는데, 이 글에서는 간단히 디펜던시와 같은 의미로 받아들여도 무관 하다. 어쨋든 원래 백엔드 프레임웍인 Node.js의 패키지 관리 툴 이지만 요즘은 웬만한 프론트엔드 페키지들도 npm을 통해 다 찾을 수 있는 듯 하다. 실제 참여했던 프론트엔드 프로젝트 중 npm만으로 모든 페키지를 관리해 진행했던 프로젝트가 있었다. 그래서 내 생각엔 npm은 더이상 Node.js만을 위한 페키지 관리 툴이 아니라 자바스크립트 관련 프로젝트면 백엔드나 프론트엔드를 막론하고 거의 필수로 사용되는 페키지 관리 툴이 아닐까 생각 한다. 다만 Bower와 비교했을 때 디펜던시를 관리하는 계층구조가 조금 달라 -자세히는 모르지만 npm은 디펜던시별로 여러 버전의 디펜던시를 동시에 관리할 수 있지만 Bower의 경우 하나의 디펜던시는 무조건 한 버젼만 관리할 수 있다. 따라서- 프론트엔드 페키지는 Bower로 관리하는 것이 속도면에서 조금 더 낫다는 주장들도 있지만 난 그런것 까지 자세히 모르겠고 여튼 그렇다고 하니 나도 왠만하면 프론트엔드 페키지는 Bower로 관리하는 편이다. (edit: 09/02/2017 - 현재는 모든 프로젝트는 npm 또는 새로운 패키지 매니져인 yarn을 사용하고 있다.)
Bower – 프론트엔드 디펜던시 관리 툴
위에서 언급되었지만 프론트엔드 페키지 관리 툴이며 npm을 이용해 프로젝트의 모든 페키지를 관리할 수도 있고 Bower를 이용해 프론트엔드 페키지만 따로 관리할 수도 있다.
유닛 테스팅
Mocha / Jasmine / Qunit – 테스트 프레임웍
테스팅에 최적화된 신택스(문법?)와 더불어 비동기 함수 테스트를 간편하게 해주는 등 여러가지 테스팅 관련 함수들을 제공해주는 프레임웍 이다. 제목에 언급된 것 외에도 수많은 테스트 프레임웍들이 존재하지만 내가 알기론 현재 Jasmine이 가장 많이 사용되는 프레임웍이고 Mocha도 빠른 속도로 인기를 얻어가고 있는 중이다. Qunit은 원래 jQuery 테스팅을 목적으로 나온데다 상대적으로 오래된 프레임웍이기에 Jasmine이나 Mocha에 비해 여러가지 면에서 부족한 부분이 있다.
Karma – 테스트 러너(runner)
앞서 언급된 테스트 프레임웍을 이용해 작성한 테스트 코드와 실제 소스 코드를 실행해서 에러 여부를 판단해 준다. 브라우저 자동화 툴들과 연동해 UI 테스팅도 가능하긴 하지만 유닛 테스팅에 최적화 되어 있기 때문에 유닛 테스팅 전용으로 사용하는것이 가장 일반적이다. 그리고 Gulp나 Grunt에서도 현재 간단한 테스트 러닝 코멘드가 존재하는 걸로 알고 있고 실제 활용도도 있다고하니 테스트 러너 부분도 앞으로 더 많은 프레임웍들이 생겨날 것이고 그만큼 더 복잡 정교해 질 것이라 예상 된다.
e2e (end to end) 테스팅 (혹은 UI 테스팅)
Selenium / Protractor – 브라우저 자동화 프레임웍
Karma가 유닛 테스트 러너라면 Selenium, Protractor 등은 e2e(또는 UI) 테스트 러너라 할 수 있다. 유닛 테스팅과 달리 hover, click 등의 실제 브라우저 상에서 일어나는 사용자 상호작용에 관한 모든 테스트를 실제 브라우져를 통해 자동으로 할 수 있으며 다양한 브라우져를 이용한 테스팅이 가능하다. Selenium이 가장 보편적인 e2e 테스트 러너이고 Protractor는 AngularJS를 위해 특별히 개발된(Selenium에서 자바스크립트 테스트 부분만 따로 분리해서 wrapping한 프레임웍이라 알고 있다) e2e 테스트 러너이나 AngularJS 이외의 자바스크립트 웹 어플리케이션에 두루 사용될 수 있긴 하다. 다만 Protractor를 사용하기 위해선 여전히 Selenium server가 필요하기 때문에 AngularJS를 사용하지 않는 어플리케이션에서는 대부분 Selenium을 사용하는 것이 좀 더 일반적인 것 같다.
PhantomJS – Headless 브라우저 테스트
Selenium과 Protractor와 마찬가지로 e2e 테스트 러너이지만, 큰 차이점은 headless browser를 이용한다는 점이다. 즉, 브라우져상의 모든 상호 작용 테스트가 가능하지만 실제 브라우져를 이용해서 테스트하진 않고 커멘드 라인 툴에서 브라우져 없이 테스트가 돌아간다. 따라서 앞서 언급된 e2e 테스트 러너에 비해 실행 속도가 현저히 빠르며 로컬 환경에서도 많이 사용 되지만 특히 CI 서버 사용시 서버 상에서도 사용하기 적합하다 할 수 있다.
각종 Helper
Browserify / Webpack / RequireJS – 디펜던시 번들러
이들은 어플리케이션에 필요한 모든 디펜던시를 한곳에서 정의하고 나중에서 필요한 부분에서 필요한 디펜던시만 불러서 사용할 수 있도록 해준다. 자바스크립트 어플리케이션을 모듈 단위로 개발 가능하게 해주는 중요한 역할을 하는 프레임웍들이다.
Sass / Less – CSS 익스텐션
기존의 CSS에서 할 수 없었던 변수 또는 간단한 함수 활용 그리고 @import 디렉디트브를 이용해 스타일링 파일들을 모듈화 할 수 있고 반복되는 코드를 많이 줄일 수 있다. 그러나 개인적인 생각에 nesting 구조로 인해 CSS에 비해 가독성이 다소 떨어져 스타일링은 기존의 CSS와 비슷하게 하고 변수, 함수, @import 등만 적극 활용하는 편이다.
JSHint / JSLint / ESLint – 신텍스 린트 유틸리티
Syntax 경고 및 에러를 알려주는 툴. 예를 들어, 따옴표가 안닫혔다던지 괄호가 빠졌다던지 혹은 세미콜론이 없다던지 등등 코딩 중 쉽게 발생할 수 있는 문법적 오류를 콕 집어주는 툴이다. 원하는 법칙에 맞게 설정을 바꿔서 사용할 수도 있다. 특히 Gulp나 Grunt등의 자동화 툴과 연동해서 파일 수정 후 저장할 때 마다 린트가 실행되도록 하면 실시간으로 문법 오류를 수정할 수 있어 코드의 질을 높이는데 큰 도움이 된다.
Babel – 트렌스파일러
ES2015가 이미 표준화 된 상태이고 ES2016도 현재 표준화 작업 중이다. 따라서 여전히 새로운 표준을 지원하지 않는 브라우저가 있다는 이유로 새로운 신텍스를 사용하지 않을 이유는 없다. 특히 Babel등과 같은 훌륭한 트렌스파일러가 있다면 더더욱 새로운 신텍스를 익힐 필요가 있다고 생각 한다. 나도 아직 많이 사용해 보진 않았지만 특히 화살표 함수와 promise, then 등과 같은 비동기 관련 함수들만 잠시 사용해봐도 많이 편리해진 것을 알 수 있다.
UglifyJS – 파일 최소화 툴
파일 내에 존재하는 모든 빈 공간들을 없애고 긴 함수명을 짧게 바꾸어 파일 사이즈를 최소화 시켜주는 툴이다. 자바스크립트 파일 뿐 아니라 CSS 파일용 최소화 툴들도 있다.
자동화 툴
Gulp / Grunt – 테스크 러너(Task runner)
앞서 언급될 각종 개발 관련 Helper들을 자동으로 실행시켜 주는 테스크 러너이다. 예를들어, 파일 수정후 저장을 할 때마다 브라우져 페이지 새로고침, 신텍스 린트 테스트 등을 실시간 자동으로 실행해 주며, 빌드작업에 포함되는 각종 테스트 및 트렌스파일링, 파일 최소화 작업 등을 모아 한 두개의 간단한 명령으로 자동화 할 수 있다. 게다가 아주 기본적인 서버도 포함하고 있어서 간단한 테스트용 어플리케이션을 빠른 속도로 셋업하는데도 큰 편리를 제공해 준다. 결론적으로 개발 과정에서 불가피하게 끊임없이 반복되는 여러가지 작업들을 자동화 시켜 줌으로써 귀차니즘 극복에 극적인 공헌을 하는 일등 공신이다.
결론은…
프론트엔드 개발 분야는 예전과 달리 엄청 복잡 다양해졌고 앞으로도 더 많은 기술들을 동원해 더욱 견고하고 유지 보수가 용이한 개발 페러다임으로 변화해 갈 것이다. 혹자는 너무 난잡한 툴들이 하루가 멀다하고 쏟아져 나오기 때문에 따라가기 힘들다고 하는데 그건 아마도 프론트엔드 개발이 여전히 과도기적 시기에 놓여 있기 때문일지도 모른다. 하지만 정말 중요한 것은 이런 하나하나의 툴들이 아니라 전체적인 개발 진행의 흐름을 익히는 것인 것 같다.
특히 디펜던시 컨트롤을 시작으로해서 프론트엔드 라우팅, 모듈화된 컨트롤러 혹은 기능들 그리고 엄격한 테스트 커버리지 등 전체적인 개발 패턴을 잘 이해하고 실천한다면 나중에 어떤 툴들이 쏟아져 나온다 해도 상황에 맞는 툴을 잘 선택해서 사용할 수 있게 되는 것 같다.
이렇게 최근의 프론트엔드 개발 패턴을 살펴보면 결론적으로 프론트엔드 개발도 이미 검증되고 어느정도 정립이 된 백엔드 개발 패턴을 따라가고 있다고 볼 수 있다. 왜냐면 백엔드던 프론트엔드던 결론은 개발이니까…
