프론트엔드 개발자의 기본 소양
2012년 4월 12일
한번은 어떤 프로젝트의 README 파일에서도 적은 적이 있지만, 그 글에서 Node, npm, Homebrew, git, tests 개발 빌드 등등 이런 얘기를 썼어요.
한때는 파일을 수정하고, (가능하면) 로컬에서 태스트하고 ftp로 올리는게 프로트앤드 개발자가 하던일의 대부분인 때가 있었습니다. (나도 포함해서) 우리는 ie6이랑 다퉈가며 모든 브라우져에서 픽셀단위로 완벽하게 맞추는 일로 능력을 평가 당했었죠. 프론트 개발자의 경우에는 프로그래밍에 대한 지식이 별로 없었죠. HTML, CSS, 자바스크립트(보통은 jQuery)를 다루기는 하는데 독학한 실력 정도였고요.
근데 지난 몇 년간 상황이 좀 바뀌었어요. 상황이 바뀐 이유는.. 프론트엔드 개발이 중요해졌기 때문인지도 모르겠어요. 아니면 브라우저 벤더들이 브라우저를 표준화하기 시작했기 때문인지도 모르고요. 그것도 아니면, 프론트엔드 개발자들이 보기에 소프트웨어 개발에 대해 뭔가 깨달은 바가 있었기 때문인지도 모릅니다.
여튼 중요한 건 짜잘한 것을 중요하게 여기다가, 도구를 중요하게 하는 쪽으로 전환이 이루어지고 있다는 점입니다. 이제는 프론트엔드 개발자로서 성공하려면 몇가지 기본적으로 갖춰야 하는 능력들이 있습니다.
이런 소양을 갖추지 못한 프론트엔드 개발자는 점점 더 뒤떨어졌다는 느낌을 받게 될 거에요. 지식을 전달하는 사람들의 입장에서는, 이런 정도는 당연히 알겠지? 하고 가정하는 것들이 많아질 것이기 때문입니다.
다음은 제가 개인적으로, 사람들이 익숙했으면 하는 것들을 몇 개 나열 하였습니다. 좀 찾아봐야겠다는 분들을 위해서 참고할 수 있는 곳도 언급해두었습니다.
자바스크립트 라이브러리를 다룰수 있다는 것으로는 충분치 않습니다.
라이브러리의 모든 기능을 순수 자바스크립트로 구현할 줄 알아야 하는 정도는 아니더라도, 언제 라이브러리가 필요한지는 알아야 합니다. 그리고 라이브러리가 필요하지 않은 경우에는 순수 자바스크립트로 구현을 할 수는 있어야 합니다.
JavaScript : The Good Parts - 이 정도는 적어도 한 번은 읽어보셨겠죠? 객체, 배열, 함수 등은 이해를 해야 합니다. 그리고 이들을 왜 call하고 apply해야 하는지, 어떻게 call하고 apply하는지도 알아야 합니다. 또한 프로토타입의 상속을 다룰 수 있어야 하고요, 이 모든 것의 비동기적 특성을 다룰 수 있어야 합니다.
순수 자바스크립트 부분이 좀 취약하시면, 다음을 참고하세요.
깃헙 계정이 있어야, 오픈 소스 커뮤니티에 참여할 수 있겠죠. 오픈 소스 커뮤니티는 프론트엔드 개발 기술을 둘러싸고 커져왔으니, 참여해야겠죠? 저장소(레포)의 복사본을 만드는 것(클론) 쯤은 눈감고도 할 수 있어야 합니다. 그리고 협업으로 프로젝트를 진행할 때, 브랜치를 사용하는 방법을 이해해야 합니다.
깃을 익히시려면 다음을 참고하세요.
한 두개의 `<script>`나`<style>` 태그로 페이지의 의존 파일들을 관리하던 때는 지났습니다. RequireJS 같은 incorporate된 훌륭한 툴을 프로젝트에서 사용할 수 없다 하더라도, Backbone Boilerplate처럼 프로젝트에 이식할 방법을 찾아야 합니다. 왜냐면 도입했을 때의 이점이 많기 때문이죠! RequireJS는 내장된 압축툴로 작고 모듈화된 작은 파일들로 쪼개주고 실서버에 적용할때는 하나로 합쳐지고 압축된 파일로 바꿔줍니다.
AMD(비동기적 모듈 정의)에 회의가 든다고요? 귀찮은거겠죠, 변명은 개뿔입니다. 최소한, UglifyJS나 Closure Compiler 같은 도구에 대해서는 알고 있어야 합니다. 이런 도구는 알아서 파일을 압축해주고, 최소화 파일을 붙여서 하나로 만든 후에 실서버에 넣어줍니다.
그냥 css를 쓰고 있다면(sass나 stylus같은 전처리기(preprocessor)를 사용하고 있지 않으면) RequireJS 는 css파일도 모듈화시키는데 도움을 줍니다. `@import`파일 을 페이스 파일에 적고 개발에 필요한 의존 파일을 로딩하세요. 나중에 실서버에 적용할때는 RequireJS optimizer 가 베이스 파일에 모아줍니다.
지난 십년 간 브라우저에 기반한 개발도구가 무지 발달하였습니다.
이런 도구를 사용하면 개발과정을 매우 향상시킬 수 있습니다. 사용할 줄 안다면 말이죠. (코드를 디버그할 때 아직도 `alert`를 사용하고 있다면, 엄청난 시간을 낭비하는 셈입니다.)
자기가 주로 사용하는 툴을 제공하는 브라우저를 찾아보세요. 제 경우에는 요즘 구글 크롬 개발툴(Google Chrome’s Developer Tools)을 이용합니다. 하지만 다른 개발도구에 대해서도 안테나를 세워 두세요. 개발자의 피드백을 받아들여서 유용한 기능을 많이 추가하고 있기 때문입니다. 예를 들어 오페라의 드래곤플라이(Dragonfly)에는 아주 유용한 기능이 있습니다. 예를 들어 CSS 프로파일러, 사용자가 정의할 수 있는 키보드 단축기, USB 연결이 필요없는 원격 디버깅, 사용자 정의 색상표를 저장하고 사용하는 기능 등등이 있습니다다.
브라우저 개발툴에 대한 지식이 부족하다면 Fixing these jQuery(Fixing these jQuery)를 참고하세요. 이것을 보면 디버깅에 대한 전반적인 것들과 단계식 디버깅을 하는 방법(step debugging)을 알 수 있습니다. 이것을 알면 삶이 달라질 거에요.
이제 커맨드 라인을 능숙하게 다루는 것은 필수입니다. 선택의 여지가 없어요. 커맨드라인을 못 다루면 너무 많은 것을 잃습니다. 터미널에서 모든 것을 해야한다는 얘기를 하려는게 아니에요. git GUI를 쓰지 말라는 얘기가 아닙니다. 다만 git GUI를 안 쓰면 여러분의 삶은 훨씬 나아질 겁니다. 중요한 것은, 어떤 프로젝트를 진행하고 있던지 간에, 터미널 윈도우를 띄워놓아야 한다는 것입니다. 다음은 커맨드 라인에서 눈감고도 헤치울 수 있어야 하는 작업의 목록입니다.
자주 사용하는 커맨드라인 명령어가 있다면, .bashrc나 .profile, .zshrc 등등을 수정하세요. 그리고 alias를 만들어서, 다 타이핑 할 필요가 없게 만드세요. alias를 ~/.gitconfig 파일에 추가할 수도 있습니다. 기안니 치아페타의 dotfiles라는 저장소(레포지토리)를 보면, 어떤 것을 할 수 있는지 알 수 있을 겁니다.
주의 : 윈도우만 사용하고 있다면, 도와주기가 참으로 난감합니다. Cygwin(Cygwin)을 권하는 것 외에는.. 오픈소스 프론트 엔드 개발 커뮤니티에서 참여하려면, 윈도우만 사용해서는 어렵습니다. 맥북 에어는 저렴하고, 강력하고, 엄청 가벼우니 생각해 보세요. 우분투나 다른 *nix(유닉스) 계열의 OS도 생각해보세요.
얼마 전까지만해도 서버에서는 XHR에 대해서 HTML로 응답을 보내주었습니다. 그런데 불과 12에서 18개월 전부터 프론트엔드 개발 커뮤니티에서, 서버로부터 순수한 상태의 데이터를 요청하기 시작했습니다. 그런데 이 데이터를 DOM에 삽입할 수 있는 HTML로 바꾸는 작업은 코드 안에서 바로 하기에는 너무나 지저분하고 유지보수하기 어려운 작업입니다. 바로 이 때 필요한 것이 클라이언트-사이트 템플릿팅 라이브러리입니다. 이 라이브러리를 사용하면, 템플릿을 관리하기가 편하고, 데이터랑 합쳐서 HTML 문자열을 만들 수 있습니다. 템플릿팅 툴을 선택하려면 가란 민즈의 '템플릿 선택하기(template chooser)'를 참고하세요. 방향을 잘 잡아줄 겁니다.
폴 아이리쉬는 이런 말을 한 적이 있죠. 프론트엔드 개발자들이 실제 타이핑하는 코드와, 결국 만들어지는 코드가 매우 달라지고 있다고요.. CSS 전처리기는 그 좋은 예입니다. 물론 아직도 CSS를 사용하는 게 유일한 방법이라고 생각하는 사람들도 있지만, 이들도 합류하기 시작했습니다(. 이런 CSS preprocessor같은 도구들을 사용하면 유용한 기능들을 쓸 수 있습니다. 변수, 수학, 로직, 믹스인 등의 기능 등..
(역자주: CSS preprocessor의 예에는 LESS CSS 등이 있다. LESS CSS 한국어 사용법(http://opentutorials.org/course/269/1849))
모듈화된 방식, 느슨하게 coupled된 방식으로 코딩을 했을 때의 좋은 점은 테스트하기가 더 쉽다는 겁니다. Grunt(Grunt)같은 도구를 사용하면, 테스트하기가 어렵습니다. 테스트하는 프레임워크의 호스트가 몇 개 있습니다. 그 중에 취향과 여분의 스택에 따라 고르시면 되요. 지금 제가 제일 좋아하는 것은 자스민과 모카(Jasmine and Mocha )입니다.
코딩 자체를 모듈화된 방식으로, 서로 느슨하게 연관된 방식으로 했다면 테스트를 하는 게 즐거운 작업이 될 수도 있어요. 하지만 그렇지 않은 경우에는 테스트하는 것 자체가 어려운 정도가 아니라 불가능할 수도 있죠. 반면에, 미리미리 테스트를 작성해두면, 심지어 코딩을 하기 전에 말이죠, 생각을 정리할 수 있을 겁니다. 그리고 코드도 정리가 될 거에요. 또한 이렇게 하면 코딩을 진행해나갈 수록 점점 자신감을 갖고 리팩토링을 할 수 있게 됩니다.
유닛 테스트를 위해 Grunt가 가지고 있는 프로젝트를 셋업할 수 있는 능력은 프로세스 자동화에 대한 하나의 예입니다. 프론트엔드 개발의 현실은 반드시 해야만 하는 수많은 반복적인 일들이 있다는 것이지요. 하지만, 한 친구가 예전에 말해줬는데, 좋은 개발자는 대충 눈대중으로 어림잡는 게으른 개발자라고 합니다. 만약에 당신이 똑같은 일을 세 번 이상 반복한다면 그건 자동화를 고려해야 하는 시점입니다.
make 같은 툴은 옛날부터 이런 작업을 도와 주었습니다. rake, grunt,같은 다른 훌륭한 툴도 많지만요. 파일 시스템에 관련된 작업자동화에는 자바스크립트 말고 다른 언어를 배우는건 매우 도움이 됩니다.
Node의 비동기적인 특성은 단순히 파일들을 처리하기에는 정말로 엄청난 부담이 될 겁니다. 빌드생성, 코드 품질 보증 등등의 테스크에 특화된 자동화 툴은 이미 많습니다.
한번이라도 세미콜론이나 불필요한 콤마 따위로 고생해본 적이 있다면 그걸 찾아 내기 위해서 얼마나 많은 시간을 허비해야 하는 지 알 겁니다. 그렇기 때문에 JSHint 같은 툴을 돌려봐야 하는 거죠. 이 툴은 설정을 변경할 수도 있고, 여러분이 사용하는 코드 편집기나 빌드 프로세스에 통합시키는 방법도 많이 있습니다.
프론트엔드 개발자에게는 정해진 메뉴얼이란 건 없습니다. 하지만 MDN이 그나마 근접하죠. 좋은 프론트엔드 개발자들은 검색을 할 때 앞에 mdn을 붙입니다. 예를 들면 mdn javascript arrays라고 검색하는 거죠. 이렇게 해서 영리를 목적으로 하는 w3schools의 검색결과를 피하는 거죠.
이런 글을 읽기만 한다고 실력이 나아지지는 않죠.
실력이 좋아지려면, 그 일을 ‘직접 해야’만 합니다.
그럼 화이팅!