C.T.O BLOG

[이제와서 jQuery를 쓰면 안되는 이유]가 이제와서 흥하고 있어서 2부를 써봅니다. 1부에서는 jQuery의 DOM 관리 문제에 대해 썼는데, 2부에서는 현재 jQuery에 어떤 이슈가 있는지 정리해보겠습니다.

jQuery의 이슈들

1. 사이즈가 크다.
jQuery 1.12.4 minified버전은 95K이고 압축하면 34K정도 됩니다. 크다면 크고 작다면 작은 사이즈입니다. 몇년전까지만해도 핸드폰의 사양이 낮아서 문제가 컸는데, 요즘은 그 정도는 아닙니다. 게다가 React나 Angular같은 라이브러리는 훨씬 더 크니 사이즈로 문제삼기는 좀 애매하죠. 필요없는 라이브러리를 제거한 slim버전은 27K인데, 예전 IE는 지원하지 않습니다.

2. Modular하지 않다.
한 프로젝트에서 jQuery의 모든 기능을 이용하는 경우는 없습니다. Javascript의 표준 모듈 방식인 것도 아니고, Tree Shaking도 지원하지 않기에 필연적으로 안쓰는 코드를 포함하게 되는데, 이게 옳은 일인지 고민이 필요합니다. 특히 Animation이나 AJAX는 너무 구식이라 더 좋은 대안을 쓰는게 낫습니다. slim 버전에서는 이와 같은 기능이 분리되었습니다.

3. 너무 쉽다.
document.getElementById(“some-id”)보다 $(“#some-id”)쪽이 훨씬 보기 편합니다. 그런데 너무 쉽다보니 $를 남발하게 됩니다. 생각보다 $를 쓰는게 메모리와 CPU를 잡아먹습니다. 그리고 jQuery.data같은 함수는 DOM에 직접 읽고 쓰는 기능을 제공하는데, 덕분에 속도면에서도 느리고 변수를 Global에 노출시키게 됩니다. 너무 편해서 잘못된 코딩을 하게 되는 것도 문제입니다만, 근본적으로 보자면 jQuery를 이해하지 못하고 쓰는게 문제겠죠.

4. jQuery는 javascript가 아니다.
기본적으로 jQuery는 Select한 element의 배열을 기준으로 작업합니다. $(“.some-class”) 이면 [el1, el2, el3]와 같은 Selector에 의해 선택된 배열을 내부에 가지고 있으면서 그 기준으로 작업을 합니다. 그런데 예를 들어 $(“div”).text()를 하면 div의 내용을 가져오는데, div가 두개가 있을 때는 두 div의 내용을 합쳐서 하나의 스트링을 반환합니다. < div >123< /div >< div >456</ div >이면 $(“div”).text()의 결과는 “123456”이 됩니다. 근데 과연 이런 동작이 맞을까요? 대부분 text()로 값을 가져오는 경우는 하나의 값이 필요해서 입니다. 두개의 text값이 필요하다면 각각의 값을 배열로 반환하는게 맞지 않을까 하네요. jQuery의 수많은 함수가 배열로 동작하는데, $(“.some-class”)가 배열처럼 보이지 않기에 문제를 일으킬 소지가 있습니다. 이와는 반대로 val()일때는 맨 처음 element의 값만 가져오도록 되어있는데 다른 함수들과 동작이 다릅니다.

jQuery의 hide, show는 element에 style을 적용합니다. < div style=”display:none” >처럼요. 그런데 element의 style은 우선도가 높기에 css에서 설정한게 안먹을 수도 있습니다. 그러므로 가급적 쓰면 안됩니다만 어디에고 그런 설명을 찾기는 어렵습니다.

jQuery만의 독특한 동작이 상당히 많습니다. 그게 틀린 방식은 아닙니다만 웹표준은 아닙니다. 그러므로 jQuery를 잘 쓰기 위해서는 jQuery 내부 동작을 잘 알아야 합니다. 근데 그럴꺼면 그냥 javascript로 작성하는게 더 편하지 않나 합니다.

5. 웹표준을 지키지 않는다.
지키지않는다는게 정확한 표현은 아니고, jQuery가 워낙 오래되서 웹표준이 정해지기 전에 나왔기 때문에 문제가 좀 있습니다. 예를 들어 jQuery Deferred는 하위호환때문에 Promise/A+ 표준을 지키지 않습니다. Ajax도 fetch라는 표준이 나와서 굳이 jQuery방식을 쓸 필요가 없구요. jQuery를 도입하게 되면 브라우저에서 지원하니 성능적으로 월등하고, 표준이라서 앞으로도 변함이 없는 기술을 놔두고 굳이 예전 방식을 써야 하는 상황이 됩니다. ES6로 들어서면서 Javascript의 기능도 많이 늘었기에 polyfill이나 transpiler로 처리하는게 장래를 생각하면 더 나은 방식입니다.

6. 업데이트의 문제
1.x버전과 2.x버전은 공식적으로 소프트웨어로서의 수명을 다했습니다. IE6~8을 지원하려면 1.x를 써야 하는데 그렇게 되면 차후의 서포트를 받지 못하게 됩니다. IE9부터는 jQuery 3.x에서 지원하므로 당분간은 문제가 없을 예정입니다만 IE9, 10지원을 포기하면 수많은 대안이 존재합니다.

7. Virtual DOM과 상성이 안좋다.
Virtual DOM뿐만이 아니라 요즘 나오는 라이브러리들은 DOM을 직접 다루지 않고 template에서 자동으로 생성하기 때문에 jQuery와 함께 쓰기가 매우 애매합니다. 둘 중의 하나를 골라야한다면 Vue, React, Angular같은 새로운 라이브러리를 선택하는게 맞겠죠.

이 외에도 문제는 많이 찾을수 있을테지만, jQuery같이 규모가 크고 수많은 사람들이 쓰고 있는 라이브러리에 치명적인 문제는 그리 많지 않습니다. 작은 사이트를 만들고 돌리는데는 아직도 jQuery만으로 충분합니다. 그러나 점점 트렌드가 바뀌고 있으니 준비하고 다음 단계로 넘어가야 하지 않을까 하네요. 특히나 Javascript 업계는 전례가 없을 정도로 빨리 변하고 있으니까요.

회사 로고를 만들기위해 폰트에 관해 공부 했는데 그때 알게된 정보를 기록으로 남겨본다. 디자인은 포토샵으로 크롭하고 용량줄이는 정도만 할 줄 알고, 폰트 쪽은 완전 초보라 디자인 전문가가 보면 별거 아닌 내용이다.

1. 폰트 종류는 크게 나눠서 Serif와 Sans Serif가 있다. 장식적이고 가독성이 높은 폰트가 Serif, 모던하고 심플한 폰트가 Sans Serif이다. Serif는 글자의 장식적인 부분을 의미하고 Sans는 without을 의미한다. 전통적으로 출판업에는 사람이 읽기 쉬운 Serif 폰트가 주로 쓰여지고 있었기 때문에 Sans Serif는 역사가 오래 되지 않았다.

2. 예전엔 로고나 헤드라인에는 Sans Serif를, 본문엔 가독성이 좋은 Serif를 썼는데, 요즘엔 본문에 Sans Serif를 써도 뭐라고 하는 사람이 없다. 디자이너들이 Helvetica 이후로 모던한 폰트를 적극적으로 쓰기도 했고, 해상도가 낮은 PC 모니터에서는 장식이 많은 Serif를 읽기가 힘들기에 Sans Serif만 써서 그렇기도 하다. 이유야 어찌되었든 Sans Serif가 인기를 얻은지 몇십년이 지나서 사람들 눈에 폰트 형태가 익숙해지니 굳이 본문에 Serif를 쓸 필요가 없는 것이다. 그런데 모니터가 다 레티나로 바뀌면서 본문용으로 Serif체가 쓰이는 경우가 늘어나고 있다. 트렌드는 돌고 돈다. (모니터에서는 산세리프가 더 가독성이 높다는 주장도 있다.)

3. 한글의 구조가 사각형이라서인지 한글 Serif는 영문 Serif와 느낌이 많이 다르다. 영문 디자인을 그대로 따라할 수 없는 이유이다.

4. 웨이트가 많고, 글자 간격이 일정하고, 디자인에 일관성이 있는 폰트가 사용성이 좋다. 그런 폰트는 어떤 알파벳 조합이나 미디어(책, 문서, 웹사이트 등등)상에서도 아름답게 보인다. 당연한 이야기지만 유명한 유료 폰트는 이런 조건을 대부분 만족한다. 최근에는 무료 폰트 중에서도 이런 폰트들이 많이 나와서 웹폰트나 로고로 자주 쓰이고 있다. Lato, Roboto, Linux Libertine 등등.. 잘 알아두면 웹개발에 많은 도움이 된다. 그런데 이렇게 잘 알려진 무료 폰트는 너무 많은 사이트에서 웹폰트로 쓰고 있기 때문에 이제는 좀 식상한 감이 있다. 특히 Lato..

5. 로고에 쓰이는 폰트는 굳이 유료일 필요는 없지만 디자인 작업을 하는 입장에서 보면 범용성있는 유료 폰트로 단기간에 퀄리티있는 로고를 만드는게 남는 장사다. 무료 폰트를 검색해서 일일이 자간과 형태를 조절하는건 귀찮은 일이니까.. 어차피 조절해야한다고? 그러면 디자이너 쓰는 비용이 폰트 비용보다 더 든다.

6. 유료 폰트는 웨이트와 라이센스 종류에 따라 과금이 천차만별이다. 원하는 웨이트 하나만 사서 데스크탑 용도로만 쓰면 몇 만원 선에서 지출이 끝나는데, 풀셋으로 갖추려면 돈이 몇백단위로 나간다. 특히 PDF, E-Book, 앱, 서버 등에 폰트를 포함해서 배포하는 라이센스가 무진장 비싸다(최소 10배). 임베디드 용도로 써야 한다면 그에 따른 라이센스 비용도 체크해야 한다. BI를 위해서 전부 사는 것도 괜찮은 방법이지만 그만큼 돈을 벌어야겠지..

7. Helvetica, Univers, Futura, DIN, Baskerville, Avenir, Bodoni, Gill Sans 등등등.. 유명한 유료 폰트는 알아두는게 좋다. 길거리나 웹에서 볼 수 있는 대부분의 타이포그래피가 이런 유명한 폰트를 기반으로 만들어지고 있다. 무료 폰트 중에는 이런 유명한 폰트를 흉내낸 폰트가 꽤 있는데, 완성도는 살짝 떨어져도 잘만 이용하면 쓸 만하다.

8. 영문 웹폰트를 잘 쓰면 개성있는 사이트를 만들 수 있지만, 한글이나 일본어는 쓸 만한 웹폰트가 많지 않다보니 그에 맞춰서 쓸 수 있는 영문 웹 폰트를 찾는 일이 쉽지 않다. 디자이너가 열심히 찾아다녀야한다. 그리고 한글 웹폰트는 무거워서 잘 안쓰게 된다.

8. 광고/브랜딩에 신경쓰는 화장품, 의류 브랜드는 로고의 폰트와 브랜드 이미지가 완벽하고 일치하고 어색한 부분이 없다. 고급 디자인 에이전시에 맡겼겠지.. 그 외의 일반적인 간판은 대충 만든게 눈에 보인다.

9. 헬베티카는 폰트 자체에 개성이 없고, 이탤릭체가 어설프다는 이유로 디자이너 사이에서 호불호가 갈린다. 길거리를 다니면 헬베티카 쓰는 간판이 많은데, 무성의해 보인다.

10. 무료 폰트를 찾는다면 다음의 두 사이트를 추천한다. 특히 구글은 완전 짱임.. http://www.dafont.com/ https://www.google.com/fonts 유료 폰트사이트는 검색해보면 많이 나온다.

풀스택 개발엔 디자인도 포함된다. 사이트 하나를 만드는데 필요한 전문 지식이 이렇게 많다.

IT 프로젝트에서 마감날이 다가오면 개발자들이 제일 바빠집니다. 기획과 디자인이 늦게 끝난 프로젝트라면 더더욱 그렇죠. 아무리 개발 경력을 쌓아도 마감에 대한 압박은 어쩔 수 없지만, 초반에 열심히 체력을 비축해 두었으면 어떻게든 버틸 수 있습니다. (프로젝트 중간에 긴급 투입되었다면…)

아무튼 마감에 치이면 밥 먹을 시간도 부족해서, 저녁을 컵라면으로 때우는 일이 생깁니다. 일본의 컵라면이야 맛있으니 큰 불만은 없지만, 자주 먹다보니 항상 맛있는 컵라면을 먹는게 쉬운일이 아니라는 사실을 알게 되었습니다.

컵라면을 끓이는 방법은 아주 간단합니다. 1. 뚜껑을 열어 스프를 꺼내고, 2. 따뜻한 물을 선에 맞춰 붓고, 3. 정해진 시간을 기다린 후 먹으면 됩니다.

그런데 직접해보니 2, 3단계가 쉽지가 않습니다. 밝은 곳이 아니면 물을 붓는 선이 잘 안보이는데다, 컵을 기울여서 쥐게되면 적당히 부었다고 생각했는데 오버하는 경우가 생깁니다.  정해진 시간을 맞추는 것도 어려운게 물을 부은 다음에 바로 시작 시간을 체크해야 하는데 빼먹는다거나, 기다리는 중간에 메신저등등의 인터럽트가 걸릴 때도 있습니다.

그렇다면 항상 완벽한 컵라면을 먹고 싶다면 어떻게 해야할까요? 1. 물따르는 곳의 조명이 밝아야 합니다. 2. 정확히 수평을 유지하려면 테이블 위에 올려놓고 주전자나 포트를 이용해 따르는 방식이어야 합니다. 3. 다 따르자마자 스톱워치를 돌리고 중간의 인터럽트는 무시합니다.

그런데 이게 쉬운 일은 아니죠. 포트 대신에 정수기만 있다거나 탕비실 조명이 원래 어두운 상황에서, 단지 컵라면을 완벽하게 끓이기 위해 조명을 바꾸거나 포트를 사기는 애매하니까요. 중간에 중요한 연락이 왔는데 무시하기도 그렇죠.

그리고 더욱 근본적인 문제가 있는데, 맛있게 보여서 사온 컵라면이 맛이 없으면 모든 과정을 제대로 해내도 원하는 결과를 얻지 못합니다.

결국은 가끔 실패한  컵라면을 먹는 것으로 타협을 보게 됩니다. 하지만 어떻게해야 최선의 컵라면을 먹을수 있는지 고민해보았다면, 그리고 더 나은 방법을 제시할 수 있다면, 누군가 컵라면에 대해 고민하고 있을때 조언해줄 수 있습니다. 그런게 개발자의 일이 아닐까 하네요.

P.S. 참고로 제가 먹고 성공한 컵라면을 소개해 드리겠습니다.

일본 컵라면 추천 2016년

요즘들어 젊은 개발자들과 대화할 기회가 많이 생기면서 제가 생각하는 웹개발에 대해 한 번 정리할 필요를 느꼈습니다. 제가 웹개발을 잘 아는 것은 아니지만 정리해가면서 배우는 것도 있으니까요. 일단은 특징에 대해 정리하고 차차 웹개발 프로세스에 대해서도 정리할 생각입니다.

제가 생각하는 웹 개발의 특징은 다음과 같습니다. 스테이트가 없는 것도 특징이지만, 너무 당연한 듯해서 제외했습니다.

1. 데이터 처리가 중심이다.
2. 비동기로 움직인다.
3. 다양한 사용자층이 있다.
4. 다양한 개발자/회사들이 참여하고 있다.
5. 계속 발전한다.

데이터 처리가 중심이다

웹에는 이미 fancy한 것들이 넘치기때문에 컨텐츠가 없는 사이트는 매력이 없습니다. 많은 초보 개발자 분들이 언어나 프레임웍을 공부를 하느라 데이터 관리에는 소홀하신 모습을 보이시는데, ORM으로 가든, NoSQL로 가든, Machine Learning으로 가든 데이터의 본질적인 특성을 이해해야 좋은 서비스를 만들 수 있다는 사실엔 변함이 없습니다. 자주 변경되는 필드를 정규화한다던가, 자주 검색되는 필드에 인덱싱을 건다던가 캐싱을 한다던가 하는 DB 관리도 중요하지만, 정말 필요한 데이터를 수집하고 있는지,  어떤 식으로 보여주어야 하는지에 대한 고민도 해야합니다. MySQL의 스펙을 빠삭하게 아는 것만으로는 현장에서 필요한 개발자가 될 수 없습니다. 물론 MySQL의 스펙을 열심히 공부하는 개발자는 데이터의 특성에 대해서도 이해하려고 노력하는 경우가 대부분이죠.

비동기로 움직인다

모던 웹브라우저는 이미 비동기 방식으로 동작하고 있습니다. 개발하기엔 동기방식이 편하지만 사용자 경험(UX)을 높히기 위해서는 비동기를 도입할 필요가 있습니다. 즉시 즉시 처리해야 사용자들의 만족도가 올라가니까요. 요즘은 서버쪽도 비동기 방식이 각광을 받고 있습니다. NGINX + PHP-FPM이 인기인데는 다 이유가 있습니다. 비동기 동작을 모르고 웹개발 하기는 점점 더 어려워 질테니 지금 당장 뭔가 배우는 것을 추천합니다. 예를 들자면 RxJS.

다양한 사용자층이 있다.

웹의 오픈성은 세상 모든 계층의 유저를 불러모읍니다. 유저마다 요구하는 것이 다르고, 다양한 요구를 반영하기 위해 설계가 복잡해질 가능성이 높은데다, 실제로 써보지 않으면 필요한지 아닌지 알 수 없는 부분도 많습니다. 그러므로 일단 빨리 올리고 유저의 피드백을 모아 기민하게 반응할 필요가 있습니다. 심지어 클라이언트가 원하는 소프트웨어를 구현하는 SI라 하더라도 초기 기획서 대로 개발되는 일은 많지 않습니다. 그러므로 웹개발자라면 사양 변경에 따른 수정은 당연한 것으로 생각하고 미리 대비가 되어있어야 합니다. 또 하나 주의해야할 점은 웹서비스는 어떠한 접근도 가능하기 때문에 해킹이나 잘못된 입력에 대한 체크는 기본 중의 기본이라는 것입니다. e-commerce나 유저의 개인정보를 취급하는 사이트라면 더더욱 주의가 필요합니다.

다양한 개발자/회사들이 참여하고 있다.

페이스북, 구글, 아마존같은 실리콘밸리 대기업이 웹업계를 대표하고 있긴 하지만, 전 세계적으로 다양한 회사와 개발자들이 존재하고 그 시장 규모도 어마어마합니다. 예를 들어 도쿄브랜치는 현재 일본 시장에서 소규모 개발 프로젝트를 다수 진행하고 있는 중인데, 아직 안망하고 있습니다. 한국에서 IT개발하면 자바로 하는 SI가 전부인 것같지만 다양한 개발 커뮤니티가 존재합니다. 이런 상황에서 어떤 식으로 개발하는 것이 좋을지, 혹은 어떻게 개발 경력을 쌓아야 할지 결정하는 일은 쉽지 않습니다. 회사가 정해준다면 그걸 따르기만 하면 되지만, 개발 경력을 쌓다보면 자기가 스택을 선택해야할 상황이 옵니다. 지금 새로운 웹서비스를 개발할때 Angular vs React vs Vue.js vs jQuery, Ruby on Rails vs PHP vs Go vs Java Spring이라면 어떤 선택이 최선일까요?  단가가 중요한 경우라면 빠르고 안정적으로 개발할수 있는 기술을 선택하는 것이 베스트겠지만, 거대 IT회사가 개발했거나, 시장에서 주로 쓰이는 기술을 선택하는 것이 더 유리할 수도 있습니다.

계속 발전한다.

웹업계란 마치 끊임없이 레이즈를 해야하는 포커판과 같습니다. 지금도 계속 새로운 서비스가 나오고 있고, 온라인 상에서는 어떻게 하면 유저에게 더 좋은 서비스를 제공할수 있을지 활발한 토론이 계속 되고 있습니다. 프론트엔드로 치면 처음엔 jQuery면 되었는데 Backbone이 나오고 Angular가 나오고 React가 나오는 식입니다. 기능이 추가되면서 한번에 구현해야할 요구사항도 늘어나고 있기 때문에 개발은 점점 더 복잡해지고 있고 앞으로도 이 추세는 계속 될 것입니다. 이런 상황에서 웹개발자가 할 일은 프로젝트의 복잡성을 낮추는 기법을 연구하고 기술 자체보다는 UX를 우선으로 생각하는 일일 것입니다.

간단하게 제가 매일 겪고있는 웹개발의 이슈들을 정리해봤습니다. 업계에 종사하는 분들이 보면 별것 아닌 뻔한 이야기지만 웹개발을 시작하시는 분들에게 조금이라도 도움이 되었으면 합니다.

프론트엔드 개발을 오래하다보니 예전 프로젝트를 관리할 일이 종종 생기고 있습니다. 그런데 워낙 프론트엔드의 기술 발전이 빠르다보니 이미 아무도 쓰지 않는 예전의 기술로 프로젝트를 관리하는 것이 무척 난이도 높은 작업이 되버렸습니다. 시대의 흐름에 맞게 es6와 npm기반으로 바꾸고 싶어서 다양한 방법을 리뷰하다가 rollup.js과 buble를 알게 되었습니다.

rollup.js는 es6의 표준 모듈 시스템을 지원하는 bundler이고, buble는 es6코드를 es5로 바꿔주는 transpiler입니다. 더 복잡하고 유명한 프로그램도 있지만 제 목적엔 rollup.js이 최적이더군요. 특히나 최종 결과가 너무 깔끔하게 나와서 감동했습니다.

rollup.js의 환경 설정에 시간이 걸리는데, 한번에 처리하기 위해서 boilerplate를 github에 올려놨습니다. node.js와 git가 설치되어있다면 5분도 안걸립니다.

git clone https://github.com/fri13th/rollup-jquery-boilerplate your-project
cd your-project
npm install

build명령을 실행시키면 es6로 작성된 src/main.js 파일을 바탕으로 dist폴더에 es5형식의 파일이 생성됩니다.

npm run build

그런데 파일을 수정할 때마다 빌드명령을 입력하기는 귀찮은 일이죠. 그럴 때를 위해  watch모드가 존재합니다.

npm run watch

built-in서버 기능은 안넣었는데 html 파일에 dist/app.js를 넣어서 제대로 동작하는지 확인해보시기 바랍니다. 혹은 직접 만들어진 코드를 보셔도 됩니다.

browser-sync를 이용하여 built-in서버기능을 넣었습니다.

npm run serve

index.html 파일과 src폴더내의 js파일을 수정하면 바뀐 결과가 바로 브라우저에 반영되는 것을 보실수 있습니다.

아래처럼 es6 형식으로 작성한 코드가

import $ from 'jquery';
import {view} from 'template';
import {cube} from 'utils';

let array = [1, 2, 3];

console.log(cube(3));
$(() => console.log(view('World', array)));

es5로 깔끔하게 변환됩니다.

(function ($) {
  'use strict';

  $ = 'default' in $ ? $['default'] : $;

  function view(who, array) {
    return ("\nHello, " + who + "!\n" + (array.map(function (no) { return ("" + no); }).join('')) + "\n");
  }

  // This function gets included
  function cube ( x ) {
    return x * x * x;
  }

  var array = [1, 2, 3];

  console.log(cube(3));
  $(function () { return console.log(view('World', array)); });

}(jQuery));
//# sourceMappingURL=app.js.map

이렇게 개발환경을 설정하니 es5로 작업하는 것과 속도 면에서 별 차이가 없고, es6의 깔끔한 문법덕분에 개발 효율은 몇배로 증가했습니다. 예전 코드를 main.js에 통채로 카피해서 하나씩 es6화 하는 것도 가능하고, 최종결과가 IE8같은 레거시 브라우저에서도 문제 없이 돌아가니, 지금 당장 프로젝트에 적용할 수 있는 것도 무척 매력적입니다.

이번에 rollup.js를 써서 개발하면서 느낀 것은 Javascript의 미래가 생각보다 멀리 있지 않다는 것입니다. es5는 이제 잊으시고 지금 당장 es6개발에 도전해보시기 바랍니다.

이번에 Angular 1 기반 프로젝트를 Angular 2로 이전하는 작업을 하게 되었습니다. node기반 프로젝트들이 설정 난이도가 높기로 유명해서 걱정했는데 angular-cli덕분에 금방 끝낼수 있었습니다. 그 과정이 감동적으로 심플해서 간단하게 정리해봤습니다.

개발 환경은 제 맥북기준으로 설명하겠습니다. 일단 npm이 있어야 하는데 저는 nvm을 이용해서 v6.2.1을 깔았습니다. nvm은 brew를 통해서 깔면 됩니다. 참고로 nvm과 npm 설정은 10분에 포함이 안됩니다.

brew install nvm
nvm install v6

npm 설정이 끝났다면 글로벌 라이브러리를 설치합니다.

npm i -g eslint angular-cli typings

그리고 angular-cli를 이용해서 프로젝트 폴더에 신규 프로젝트를 만듭니다.

cd ~/path_to_projects
ng new project

프로젝트 폴더와 필요한 모든 파일이 생성됩니다. 원래라면 더 이상의 작업은 필요없는데, RC2를 적용하려면 수정이 필요합니다.  라이브러리를 버전업하고 angular-forms를 추가해야 하는데 forms에 관해서는 이 문서를 확인해보시기바랍니다.

수정을 위해서, 그리고 작업을 위해서 IDE로 VS Code를 쓰고 있는데 아래는 제가 쓰는 플러그인의 리스트입니다. vi나 에디터플러스로 편집하셔도 아무 문제 없습니다만 intellisense가 지원되는 IDE가 편하긴 편하더군요. VS Code를 설정하는 시간도 10분에 안들어갑니다.

EditorConfig.EditorConfig-0.2.7/
christian-kohler.npm-intellisense-0.1.1/
dbaeumer.vscode-eslint-0.10.16/
johnpapa.Angular2-0.4.4/

프로젝트 폴더로 들어가셔서 package.json을 수정합니다.

  "dependencies": {
    "@angular/common": "2.0.0-rc.2",
    "@angular/compiler": "2.0.0-rc.2",
    "@angular/core": "2.0.0-rc.2",
    "@angular/http": "2.0.0-rc.2",
    "@angular/forms": "0.1.0",
    "@angular/platform-browser": "2.0.0-rc.2",
    "@angular/platform-browser-dynamic": "2.0.0-rc.2",
    "@angular/router": "3.0.0-alpha.7",
...

rc.1을 rc2로 바꾸고 router의 버전을 alpha.3에서 alpha.7로 올려줍니다. @angular/forms의 추가도 잊지 마시길.

src/main.ts에서 http와 forms를 쓰도록 변경해줍니다.

import { bootstrap } from '@angular/platform-browser-dynamic';
import { enableProdMode } from '@angular/core';
import { AwardResultComponent, environment } from './award-result/';
import { HTTP_PROVIDERS } from '@angular/http';
import { disableDeprecatedForms, provideForms } from '@angular/forms';

if (environment.production) {
  enableProdMode();
}

bootstrap(AwardResultComponent, [HTTP_PROVIDERS, disableDeprecatedForms(), provideForms()]);

disableDeprecatedForms는 RC2전용으로 RC1 이전의 forms를 쓰지 못하게 막는 코드인데 RC3이후로는 쓰이지 않을 예정입니다.

src/system-config.ts에 forms를 한 줄 추가해줍니다.

const barrels: string[] = [
...
  '@angular/forms',
...

이제 라이브러리를 설치하고 서버를 실행시킵니다.

npm install
ng serve

http://localhost:4200/ 으로 접속해서 app works! 메세지가 보이면 성공입니다. src/app/app.component.ts에서 title을 변경하면 자동으로 브라우저에 반영되는지 확인해보시기 바랍니다. 만약 built-in 서버가 필요가 없다면 build –watch를 하시면 됩니다.

ng build --watch

어때요? 10분이면 충분하죠?

저의 경우 built-in서버 대신 nginx위에서 작업했는데 dist/index.html 을 참조해서 페이지를 하나 만들고, System.js의 base URL을 설정하니 문제없이 동작했습니다. 아래와 같은 코드를 System.import 위에 넣어주시면 됩니다.

System.config({baseURL:'/path-to-projects/project/dist/'});

angular-cli를 만져보니 요즘 구글이 정말 일을 잘하고 있구나 라는 생각이 들었습니다. ng 명령어를 이용하면 테스트를 비롯한 다양한 기능이 지원되는데 직접 확인해보시기 바랍니다.

환경설정이 간단하게 끝났으니 그 다음엔 웹어플리케이션을 제작하는 일이 남았습니다. typescript를 익히시고 angular2 quickstart 나 angular2 seed 같은 예제를 참조하신 후에 자신만의 멋진 프론트엔드 작업을 하시기 바랍니다. 아차차, 테스트를 위해서 jasmin, karma를, ajax를 위해선 rxjs도 알아둬야 하는 걸 빼먹을 뻔 했네요.

Angular2를 조금 써봤는데 내부적으로는 많이 바뀌었지만 실제 작업을 해보면 Angular 1과 거의 비슷한 감각으로 사용할 수 있도록 설계되어 있었습니다. 능력자 구글의 서포트가 있으니 정식버전이 나오면 프론트엔드 분야에 큰 영향을 미치지 않을까 예상해봅니다. 마치 초창기 스프링처럼요. 성공적으로 환경 설정하시고 잘 활용해보시기 바랍니다.

TL;DR: 모던 MVC프레임웍은 기능이 풍부한 대신에 하위호환에 신경을 쓰지 않는다. PHP는 기능은 떨어지는 대신에 장기적으로 안정된 플랫폼을 제공한다. 지금은 어떤 스타일의 개발이 올바른 방식인지 고민해볼 때이다.

전편의 반응이 나쁘지 않아서 시간을 두고 작성하려 했던 2부를 연휴에 바로 작성했습니다. 전편에서는 PHP가 전세계적으로 잘나가는 현상에 대해 이야기 했는데, 실질적인 웹개발 이야기는 빼고 보이는 현상만 다루다보니 2000년대 초반의 악명높은 PHP로 오해하시는 분들도 계시더군요. 이번엔 현재의 웹서버 개발 상황과 모던 PHP에 대해 자세히 설명을 해보겠습니다.

개인적으로 웹서버 개발은 딱히 익사이팅한 작업은 아니라고 생각합니다. 프로그램의 동작 여부와는 상관없는 노가다 작업이 많기 때문입니다.

예를 들자면 일반적인 서버 프로그램은 보통 이런 식으로 동작합니다. 유저 입력이 들어오면 -> 받은 입력을 처리해서 -> 내부로직을 통해 DB의 데이터를 처리하고 -> 결과를 html로 뿌려줍니다. 참 쉽죠?

그런데 이 과정에는 최소한 두가지의 노가다 작업이 필요합니다. 유저에게서 입력받은 데이터가 정상인지 체크하는 Server side validation과, DB의 데이터를 프로그램에서 사용할 수 있는 형식으로 변환해 주는(퉁쳐서 ORM이라고 부르기도 하는) 작업입니다. 이 이외에도 수많은 노가다가 존재합니다만(파일 업로드 처리라던가 pagination이라던가 나열하면 끝이 없습니다.) 이 두가지는 작업량도 많은데다 이미 존재하는 사양을 코드로 변환하는 단순한 과정이기에 재미도 없습니다. 이 중에서 Server side validation은 모든 입력을 대상으로 하지 않으면 보안에 구멍이 생기지만, 안해도 어차피 티가 잘 안나는 작업이라서 누구에게도 인기가 없습니다.

이쯤에서 웹 개발의 초기에 PHP로 작성한 코드를 한번 확인해보겠습니다. 라고 해도, 요즘도 네이버에서 검색하면 지식인에 이런 코드가 나옵니다.

$name = $_GET["name"];
mysql_query("INSERT INTO users (name) VALUES ('$name')", $conn);

정말 끔찍한 코드입니다. Server side validation에 대한 개념 자체가 없네요. $name에 sql injection 코드가 들어가면 DB는 한방에 끝장입니다. 만약에 $name에 script태그라도 들어가 있으면 CSRF에 직빵입니다. 스팸으로 $name에 이상한 값이 들어가게 되면 쓸모없는 유저가 계속 추가되어 디스크와 CPU 자원을 낭비하게 되겠죠. 이런 코드는 바닥부터 새로 만드는 게 훨씬 낫습니다.

세상에는 유저로부터의 입력이 거의 없는 스태틱한 사이트도 있고, DB가 필요없는 사이트도 있기 때문에 대충 만든다고 큰 문제가 되는 경우는 생각보다 많지 않습니다. 하지만 대충 만들어도 되는 사이트에서 프로의 개발자가 짭짤하게 돈벌기는 무척 어려운 일입니다. 돈되는 사이트를 만들려면 바닥부터 제대로 만들어야 하기에, 현장에서는 지겨운 반복 작업을 단순화해 주는 고마운 MVC프레임웍이 활발하게 쓰이고 있습니다.

써보신 분들은 아시겠지만 모던 MVC프레임웍은 기능이 너무 좋아서 지금에 와서 안쓰고 개발한다는 것은 생각할 수도 없습니다. 얼마나 좋은지 Server side validation의 샘플 코드를 통해 확인하고, 마지막으로 모던 PHP 코드와 비교해보겠습니다.

스프링

public class User {
    @Size(min=2, max=30) 
    private String name;
}

@Controller
public class FormController {
    @RequestMapping(value="form", method=RequestMethod.POST)
    public String submitForm(@Valid Subscriber subscriber, BindingResult result, Model m) {
        if(result.hasErrors()) {
            return "formPage";
        }
    }
}

strictly typed 언어임에도 annotation으로 예술적으로 깔끔하게 구현했습니다.

장고

class NameForm(forms.Form):
    name = forms.CharField(max_length=100)

form = NameForm(request.POST)
    if form.is_valid():
        # do something

python 특유의 문법 덕분에 매우 깔끔하게 구현되었습니다.

다음은 루비온레일즈입니다.

class Person < ActiveRecord::Base
  validates :name, presence: true, length: { minimum: 3 }
end
 
person = Person.new
person.valid? # => false
person.errors.messages

가장 짧고 간결할 뿐만아니라 기능도 풍부합니다. 레일즈답네요.

모던 PHP에서는 이렇게 처리가 가능합니다.

class UserForm extends BaseForm {
    public $userid;
    public $sanitizeRules = array(
        "userid" => array(
            'required' => true,
            'filter' => FILTER_SANITIZE_FULL_SPECIAL_CHARS
        ),
    );
}

$form = new UserForm();
if ($form->error) {
   // do something
}

filter_var_array라는 내장 함수를 그대로 이용하는 클래스를 간단하게 만들어서 Server side validation구현해봤습니다. 한눈에 봐도 지저분한 데다 그나마 기본제공 기능만으론 부족해서 필요한 기능을 자체 제작해서 넣어야 쓸만해집니다. (sanitization과 validation을 구별하는 것은 별도로 하고요) 확실히 말해서 PHP의 코드는 어찌어찌 굴러는 가지만 아름답지도 않고 제공하는 기능은 필요 최소한입니다.

여기까지만 보면 왜 열등한 PHP를 써야하는지 이해가 안갈껍니다. 세상엔 훨씬 더 나은 개발환경이 널렸으니까요. 해답은 모던 MVC프레임웍의 업그레이드 가이드에 있습니다.

루비온레일즈의 가이드에 보면 업그레이드에 대해 이렇게 설명해놨습니다..

Before attempting to upgrade an existing application, you should be sure you have a good reason to upgrade. 업그레이드를 하고 싶다면 꼭 해야하는 이유가 있어야 할 것이다.

장고의 가이드엔 이렇게 나와있네요.

While it can be a complex process at times, upgrading to the latest Django version has several benefits. 업그레이드가 복잡한 일이긴 하지만 최신버전으로 업그레이드 해두면 몇가지 좋은 점이 있다.

스프링의 가이드는 업그레이드 시 필요한 과정에 대한 긴 리스트로 이루어져있습니다. 게다가 이미 3.0, 3.1는 서포트가 끝났고, 3.2는 올해말에 끝날 예정이고 4.0은 시큐리티 패치만 지원되고 있다고 하네요. 거기에다 올해말에 나올 Spring 5는 Java8이상만 지원한다는 군요. 한국의 전자정부 프레임웍이 3.x기반으로 알고 있는데 괜찮은지 걱정이 됩니다.

성공한 웹프레임웍 진영에서는 매년 새로운 기능으로 무장한 업데이트 버전이 나오고 있습니다. 그리고 2~3년이 지난 버전은 서서히 지원을 중단하고 있습니다. 이것은 웹 프레임웍의 코어 뿐만이 아니라 생태계에 포함된 라이브러리나 패키지에도 똑같이 적용됩니다. 하이버네이트의 업그레이드 가이드를 보면 스프링을 어떻게 업데이트 한다해도 하이버네이트를 업데이트 하는건 전혀 다른 작업이라는 것을 알 수 있습니다. 장고의 패키지 사이트에서 최근까지 관리가 잘 되고 있는 프로젝트 중 임의로 한 개를 선택해서 확인해보니 2년전에 나온 1.7 이상만 지원하고 있습니다. 지원하는 버전이 많아지면 전부 대응하기 어려우니 오픈소스를 운영하는 입장에서는 당연한 일입니다.

제가 느끼는 최근의 웹 개발은 이런 패턴입니다. 최신의 웹 프레임웍 선정(경우에 따라서 안정성을 위해 한버전 아래를 선택하기도 합니다.) -> 최신 기술을 써서 멋진 사이트 개발 -> 1년후: 새 프레임웍이 나왔지만 아직도 현재 프레임웍이 쓸만하다. -> 2년후: 슬슬 기능 업데이트와 써드 파티의 지원이 끊기고 있다. xxx기능을 쓰고 싶은데 추가가 어려우니 포기한다. 슬슬 업그레이드를 하면 좋겠다고 생각한다. -> 3년후: 보안패치가 끊긴다는데 공격당할 일이 있을까? 이미 오래된 프로젝트라 손대면 할일이 많으니까 조용히 있는다. -> 4년이후: 호환되는 코드가 없고 처음에 개발한 사람도 어디론가 가버렸다. 작은 문제는 땜빵하지만 큰 문제가 생기면 방법이 없다.

개발자들이 최상의 성능을 가진 모던 MVC 프레임웍으로 개발하기 위해서는 최소 3~4년에 한번씩 업그레이드를 해야합니다. (그럼에도 2년째 부터는 개발이 답답해지는 문제가 있습니다.) 그런데 현실적으로 개발자를 위해서, 혹은 유지보수의 편의를 위해서 서버 스택을 적절한 시기에 교체하는 회사는 기술력 중심이거나 급속도로 성장하는 스타트업 정도가 아닐까 합니다. 아무래도 업그레이드 비용에 대한 의견은 개발자와 경영자가 다를 수 밖에 없습니다. 물론 과거의 스택에 그대로 매여있어도 됩니다. 최신 기술을 못쓸 뿐이지 기본적인 기능은 전부 가능한데다 기능이 적어서 심플하고 리퍼런스도 많으니까요. 웹사이트의 성능이 좀 떨어져도 된다면, 그리고 그 스택을 유지 보수할 줄 아는 개발자가 계속 존재한다면 별 상관 없습니다.

하지만 그런 개발은 별로 재미없고 도전적이지도 않습니다. 개발자의 경력에 안좋기도 하구요. 그래서 모던 PHP를 이용한 개발이 의미가 있습니다. PHP로 개발하면 레거시 문제를 효과적으로 다룰수 있는데다 비용을 거의 들이지 않고도 쿨한 새로운 기능(PHP 7.0의 경우 null coalescing operator나 극적으로 개선된 엔진 등)을 쓸 수 있습니다. 모던 PHP개발은 개발자와 경영자가 동시에 만족할 수 있는 방법론입니다.

누구나 다 인정하듯 PHP의 코드는 지저분하기때문에 높은 생산성을 유지하는 것은 쉬운 일이 아닙니다. 노하우를 쌓을 때까지는 많은 시간과 노력이 걸릴것이고, 모던 PHP에 익숙한 개발자를 구하기도 어렵습니다. 하지만 투자의 가치는 있다고 자신합니다. 지금 당장이라도 멋진 사이트를 제작하고 싶으신 분들은 저희 회사로 연락주시면 성심성의껏 상담해 드리겠습니다. 언제든 환영합니다!

TL;DR

PHP는 언어 정책이 매우 보수적이기때문에 현재 개발하는 소스가 앞으로 버전업 되면서도 그대로 동작할 가능성이 높다. 요즘 웹은 성능이 상향 평준화되었기 때문에 굳이 신기능을 쓰기 위해서 다른 언어/프레임웍을 선택하는 건 의미없는 일이다. 그 시간에 본업에 집중하자. 보안이나 성능 관련 이슈는 PHP가 알아서 해 줄 것이다.

풀스택을 지향하는 잡식성 개발자인 저에게도 편애하는 언어가 둘 있는데 PHP와 Javascript입니다. Javascript는 요즘 대세라고 해도 과언이 아닌데다 node.js가 나오면서 서버 플랫폼으로도 각광을 받고 있습니다. 그에 비하면 PHP는 안티가 무척이나 많은데, 이렇게 인식이 안좋은 언어는 classic asp이외에 본적이 없습니다. 얼마나 인기가 없냐고 하면 예전에 이런 에피소드도 있었습니다. 협력회사 담당자가 저희 회사의 인력 구성이 어떤지 물어보면서, 그 회사에 웹개발자는 있나요? PHP 개발자 말구요. 라고 했었습니다. (PHP 전문가가 한명 있긴 있었죠. 바로 저..) 이 정도로 안티가 많으면 마켓쉐어도 미미해야 할텐데 2015년 12월 기준 서버사이드 언어로서의 사용률이 81.7%이고, 전 세계 사이트의 25.8%가 워드프레스를 쓰고 있습니다. 이런 걸 이율배반이라고 하던가요.

PHP만이 가지고 있는 언어적 특성이 이런 상황의 근본적인 원인이 아닐까 합니다. 개발용어로 설명하자면 컨트롤 로직과 프리젠테이션 레이어가 분리되어있지 않다는 것인데, 쉽게 말하면 PHP 코드와 html이 뒤섞여있다는 것이죠. PHP의 템플릿적인 특성덕분에 개발을 잘 모르고도 코딩이 가능하지만, 개발을 잘 안다면 안티패턴을 돌아가느라 코딩하기가 좀 귀찮아 집니다. 덕분에 다른 언어들 보다 잘못 설계된 코드와 만날 가능성이 높죠. 왜 PHP가 이런 – 매력적인 – 특징을 갖게 되었는지에 대해 이해하기 위해서는 html 초창기 시절의 분위기부터 설명해야 할 듯 합니다.

다들 아시다시피 html은 평범한 텍스트 파일이기에 초기에는 텍스트 에디터로 제작했습니다. vi나 emacs나 아마도 notepad같은 걸 썼겠죠. 시간이 지날수록 다이나믹한 컨텐츠에 대한 니즈가 커졌고 이때 등장한게 CGI(Common Gateway Interface)입니다.

CGI는 거의 모든 언어로 작성이 가능합니다. 심지어는 COBOL로도요.. 웹초기에는 개발자들이 DB나 텍스트를 다룰때 쓰던 C나 Perl로 개발하는게 일반적이였습니다. 90년대 후반에는 JAVA기반의 Servlet도 나왔습니다만 pro*c와의 연결이 여의치 않아서 결국 C로 데이터베이스를 다루던 기억이 있습니다. 아무튼 CGI를 설정하고 프로그래밍하고 컴파일하는 작업은 딱히 어려운 일은 아니지만, 어쨌든 무조건 개발자가 필요했습니다.  초창기에 웹을 다루던 사람들은 대부분 전문가라서 별 문제가 안되었지만 점점 한계에 부딪히게 됩니다. PHP는 이런 시대적 상황을 배경으로 탄생했습니다. html파일에 간단히 코드를 넣는 것만으로누구나 쉽게 동적인 웹사이트를 만들수 있게 되었습니다. 게다가 당시에는 CGI방식보다 월등하게 속도가 빨랐습니다. fastcgi를 설정해야 PHP와 비슷한 속도가 났는데, fastcgi는 문법이 달라서 개발이 상대적으로 까다로웠습니다.  지금에서야 fastcgi가 일반화되고, PHP는 성능문제로 까이고 있지만 그 당시에는 가히 혁명적이였죠. 폭발적인 PHP의 인기덕분에 CGI 방식에서 template을 이용한 방식으로 웹트렌드가 크게 바뀌게 되고 asp나 jsp같은 아류작이 나오는 계기가 됩니다. 사용하기 쉬운 템플릿이 웹개발의 필수라는 것을 모두가 알게 된 것이죠.

서버 프레임웍의 트렌드는 2000년대 초반 Java진영에서 Struts가 에 나오면서 MVC로 바뀌게 됩니다. MVC는 재사용성이 매우 뛰어났기 때문에 순식간에 엔터프라이즈 시장을 장악하게 됩니다. 2005년에 나온 Ruby on Rails는 Struts및 그전까지의 구세대 MVC프레임웍의 문제점이였던 복잡한 xml설정과 사용 방식을 Convention over Configuration으로 깔끔하게 해결한데 이어, 줄어든 복잡도만큼 다양한 최신 기술을 마구 구겨 넣어서 인기를 끌게 됩니다. 지금 생각해보면 어째서 그렇게 프레임웍의 설정이 복잡해야했는지 이해가 안가지만, 2000년대 초반은 정말 아무 것도 정해진게 없었던 웹개발의 매드맥스 시절이였습니다. RoR 이후로 시장에 수많은 유사 MVC프레임웍이 등장하고 서로 영향을 주는 상황으로 발전하게 되었습니다. RoR이 승승 장구하던 와중에 PHP는 4에서 5로 넘어가면서 스텝이 살짝 엉키더니 6.0을 만든다고 삽질하다가 시장의 흐름에서 완전히 소외되었습니다. 그런 이유로 2000년대 후반부터 PHP개발자에 대한 인식은 최악이 되었습니다.

한때는 어디가서 PHP 개발한다고 하기도 부끄러운 시절도 있었는데, 요즘 들어 인식이 조금씩 바뀌고 있습니다. 그렇게 된데는 페이스북과 워드프레스가 가장 큰 역할을 했습니다.

페이스북이 창립했을 당시인 2004년의 PHP는 완전 핫한 언어였지만, 회사가 세계규모로 커지고 그 사이 PHP의 인기가 식었음에도 페이스북은 꾸준히 PHP를 사용했습니다. IT 업계 큰형님이 PHP를 밀고 있으니 구글이 크롬을 통해 밀고 있는 Javascript만큼 백이 든든합니다. 이에 비하면 Ruby는 서포트가 많이 소박하죠. 게다가  페이스북은 PHP자체의 개선에도 많은 노력을 들여서 hack이나 hhvm같은 오픈소스도 만들었습니다. 그 결과로 나온  PHP7 덕분에 이제 PHP가 성능이 부족하다는 느낌은 없어졌습니다. 재밌게도 TechEmpower의 작년 framework benchmark를 보면 PHP+PHP-FPM+NGINX의 성능이 이미 스크립트 언어 중에 적수가 없을 정도로 좋았습니다. 이때의 PHP는 5.6인데도 말이죠. hhvm은 테스트 도중에 문제가 생겨서 결과에 반영이 안되었지만, PHP7으로 같은 벤치마크를 한다면 거의 탑텐 안에 들어가리라 생각됩니다. 이 정도 성능이 나오는 스크립트 언어가 지금까지 있었던가요. python이나 ruby는 GIL때문에 근본적으로 불가능한 일이죠.

워드프레스의 인기는 날이 갈수록 점점 더 높아만 가고 있습니다. 무료 플러그인과 마켓에서 60달러 정도에 살 수있는 테마를 사용하면 간단하게 프로페셔널한 사이트를 만들수 있고, 자동 업데이트 덕분에 – 커스텀 코드를 넣지 않는 이상 – 언제까지라도 무료로 서포트를 받을 수 있습니다. 최소 3~4명이 만들어야 할 사이트를 혼자서 고퀄로 뚝딱 만들 수 있으니 들어가는 비용이 1/3이하입니다. 이런 플랫폼이 인기가 없으면 그게 더 이상한 일입니다. 게다가 웹디자인도 플랫+반응형으로 통일되고 있고, 낮은 버전의 IE에 대응할 필요도 없어졌기에, 워드프레스로 제작한 사이트의 퀄리티는 나날이 눈부시게 높아지고 있습니다. 왠만한 기성품 웹사이트가 따라갈 수 있는 수준을 한참 뛰어 넘었습니다.

이런 워드프레스의 코어가 PHP 5.2를 기반으로 하고 있다는 것은 시사하는 점이 매우 큽니다.  5.2는 2006년에 발표되었고 5.3의 출시가 늦어지면서 웹사이트및 호스팅 업체에 광범위하게 채택된 버전이고, 현재도 12%의 점유율을 보여줄 정도로 바퀴벌레같은 생명력을 자랑합니다. PHP 5.2의 출시가 이미 10년전인데다 공식적인 서포트도 끊긴걸 생각하면 워드프레스의 개발 방법론은 매우 보수적입니다. 그런데 이런 보수성은 PHP라는 언어 자체의 특징이기도 합니다. PHP 5.2의 코드는 별다른 수정없이 7.0에서도 잘 돌아가니까요. 어떠한 언어의 웹프레임웍도 이렇게까지 다양한 버전을 서포트하는 경우는 없습니다. 예를들어 Java는 버전별로 클래스의 포맷이 달라서 Java8로 만든 라이브러리가 Java10에서 실행된다는 보장이 전혀 없습니다. PHP 보수성은 웹개발사에서 매우 예외적이고 PHP의 확고한 철학이 있기에 가능한 일입니다.

PHP의 아버지인 Rasmus Lerdorf씨는 무척 재미있는 분인데 한 컨퍼런스에서 이렇게 말했습니다.

I actually hate programming, but I love solving problems. 나는 프로그래밍은 싫어하지만 문제해결은 좋아한다.

이런 실용적인 철학은 PHP의 곳곳에서 발견됩니다. 예를 들자면 PHPDoc을 이용한 Type Hinting은 유용한 기능이지만 코드가 엄청 지저분해 보이는 단점이 있습니다. Python같은 언어는 이 기능이 없거나 일부분만 구현했는데, PHP에서는 그냥 지저분한 채로 구현합니다. 직접 써보면 역시 PHP는 짱이라는 걸 인정하지 않을 수 없습니다.

이제와서 PHP를 사용해야 하는 이유는 웹의 생태계에 있어서 더 이상 언어의 버전이라던가 프레임웍의 구조적인 아름다움이라던가 하는 요인이 개발자가 생각하는 것 만큼 중요하지 않기 때문입니다. 유저들은 보안적으로 완벽하고 속도가 빠른 사이트에서 양질의 컨텐츠를 다양한 디바이스를 통해 보고 싶을 뿐입니다. 10년전 기술인 PHP 5.2로도 충분히 그런 사이트를 만들수 있다는 것이 워드프레스를 통해 증명되었습니다. 비록 글로벌 변수를 쓰는 등 내부적으로 지저분한 부분이 있기는 하지만요. 게다가 같은 코드를 PHP 7.0에서 돌리기만해도 속도가 두배로 빨라집니다. 현 시점에서 일부러 5.2호환으로 만들 필요는 없지만, 지금 만드는 코드가 10년후의 최신 환경에도 동작한다는 건 PHP 생태계가 아니면 상상도 못할 일입니다. 영속적으로 발전하는 코드라니 완전 멋지지 않나요?

앞으로의 웹은 오랜기간 쓰여지면서 최대한 많은 사용자를 모으는 플랫폼이 주도하게 될 것입니다. 그런데 아직도 타 언어/프레임웍에서는 쿨한 신기능 추가에만 신경을 쓰고 있습니다. 대부분의 메이저 프레임웍이 1년에 하나씩 메이저 업데이트를 발표하지만(그보다 더 짧은 경우도 있습니다) 워드프레스처럼 버튼 하나만 눌러서 업그레이드 되는 경우는 없습니다. PHP가 아니니까, 철학이 다르니까 불가능한 것입니다. (그런 의미에서 기능을 최소한으로 줄이고 하위호환을 중시하는 GO는 PHP와 비슷한 철학을 공유하고 있습니다.)

이제라도 늦지 않았습니다. PHP로 개발자 중심이 아닌 사용자와 웹 생태계 중심의 개발을 시작해 보세요. 컨트롤 로직과 프리젠테이션 레이어가 혼합되어 생기는 문제는 MVC패턴을 적용하면 쉽게 해결됩니다. 아직 매뉴얼이 제작 중이지만 PHP 기반의 no-framework framework인  usa-framework으로 시작하는 것도 괜찮은 선택이 될 것입니다. 잘 모르는게 있으시면 저에게 연락주세요. 언제든 환영입니다!

TL;DR

jQuery는 DOM을 직접 다루는 기능이 너무 많기 때문에 안티패턴의 위험이 높다. jQuery를 쓰는 것자체가 나쁜 건 아니지만 좋은 개발을 위해선 위험한 기능은 쓰지 않도록 강제해야 한다.

올해로 jQuery가 나온지 10년이 되었습니다. 나올때부터 인기있던 jQuery지만 현재도 탑 밀리언 사이트 내의 이용율이 78%나 될 정도로 시장을 평정하고 있는 것은 놀라운 일입니다. 이런 인기의 비결은 무엇일까요? 작년 5월 jQuery 창시자인 존 레식은 트위터에서 이렇게 이야기했습니다.

이런 말 하는게 슬프지만 jQuery가 javascript를 대체하지는 않는다.  jQuery가 성공한 것은 DOM이 문제가 많다는 증거일 뿐이다. 원문 링크

프론트엔드 개발의 현재 상황에 대한 상당히 의미심장한 이야기이죠. 이 말의 의미를 제대로 이해하기 위해서 10년도 더 된 고릿적 이야기를 한 번 꺼내보겠습니다.

1990년대 웹개발에는 javascript가 나설 자리가 없었습니다. javascript의 기능자체도 별게 없었지만, 깔끔하게 정리된 문서도 없었고, 시장을 양분하고 있던 Netscape과 IE의 DOM구조가 완전히 달랐기 때문에 하나의 기능을 위해서 두번의 스크립트 개발이 필요했습니다. 이런 사정이 나아진 것은 Netscape가 완전히 망가진 2003년도 전후로 Windows XP와 IE6가 세상을 통일하기 시작하면서부터였습니다. 성능 좋은 브라우저가 시장을 독점하니 암흑의 시기가 끝나고 드디어 스크립트의 전성기가 열렸습니다. 2004년 말에 AJAX기능을 위시한 Web 2.0의 논의가 시작된 것도 그런 흐름 때문이였습니다.

Web 2.0의 유행을 타고 2005년 전후로 다양한 javascript 프레임웍이 출현했습니다. prototype, script.aculo.us, dojo등등.. 당시의 프레임웍은 DOM을 확장하고,  prototype을 이용해 타 언어의 class를 흉내내려하는 경우가 많았습니다. 그러한 방식은 자바스크립트를 좀 더 자바처럼 보이게 해주었습니다. 지금은 잘 이해가 안가겠지만 그땐 그게 쿨했습니다.

한편 Netscape의 후신인 파이어폭스가 2004년 말에 출시되었습니다. 휴식기간이 길었음에도 MS가 열심히 삽질을 해준 덕분에 파이어폭스의 기능과 성능은 IE를 월등히 뛰어넘었고 사용자들은 열광했습니다. MS입장에서 보자면 삽질할 만한 어쩔수 없는 이유가 있었지만, 그 덕분에 브라우저 시장의 유일한 지배자가 될 기회를 영원히 놓치고 말았습니다. 덕분에 다시 혼돈의 카오스가 열리게 됩니다.

2006년에 파이어폭스의 애드온으로 등장한 firebug덕분에 프론트엔드 개발은 정말이지 거대한 패러다임의 변화를 맞이했습니다. 과거에는 코드 내에 document.write나 alert를 넣는 매우 원시적인 방식으로 디버깅을 했었는데, firebug의 등장으로 한번에 상황이 바뀌게 되었습니다.(무려 console.log라니!) 덕분에 마이너했던 파이어폭스가 사이트 개발 할 때는 메인 브라우저가 되었고, IE는 출시전 테스트 단계에서만 쓰이는 찬밥 신세가 되었습니다. 그러면서 자연스럽게 웹표준을 준수하는 브라우저와 IE의 괴리가 문제가 되기 시작했습니다.

IE와 파폭은 DOM 구조가 달랐고, 기존의 프레임웍으로는 모듈화 하기가 쉽지 않았습니다. 하나의 브라우저가 시장을 지배하는 구조가 끝났기 때문에 다양한 문제가 파생했습니다. IE6가 만들었던 2003~2005년의 짧은 평화는 깨졌습니다. 이런 시대적 배경 속에 드디어 jQuery가 등장합니다. DOM을 추상화해서 관리해 주는데다, 깔끔한 플러그인 방식을 지원했기 때문에 jQuery는 나오자마자 선풍적인 인기를 끌었습니다.

2006년에 프론트엔드의 혁명이 시작되었다면, 2007년은  jQuery, 파이어폭스, Firebug가 적극적으로 시장을 넓혀가는 와중에 IE7이 삽질하고 있는 상황으로 요약할 수 있겠습니다. 2008년부터는 애플의 사파리와 구글의 크롬이 등장하면서 본격적인 브라우저 춘추전국시대로 돌입합니다. 그리고 그 즈음 iPhone으로 인해 모바일의 시대가 열리고 브라우저 파편화는 더욱 가속화 되어 현재까지 이어집니다. 2000년대 후반 jQuery가 지원하는 브라우저는 Nightly Build버전을 포함해서 11개 였는데, 요즘은 최소 30여개 이상입니다.

이렇게 생각할수도 있겠습니다. 브라우저가 파편화되더라도 표준만 제대로 지키면 문제없지 않겠느냐고요. 네, 이론적으로는 그렇습니다만 새로운 브라우저는 예외없이 새로운 문제를 만들었습니다. 이런 상황에서 jQuery가 업계 표준이 된 것은 당연합니다. 물론 jQuery만으로 모든 cross-browser문제가 해결 되는 것은 아니지만 jQuery없이 개발하는 건 상상하기 힘든 일입니다.

처음으로 돌아가서 존 레식의 이야기는 이런 의미입니다. 요즘 사람들은 브라우저의 파편화가 보편화된 시대에 살고 있고, DOM이 제대로 동작한다는 것을 믿을 수 없기 때문에 일상적으로 jQuery를 씁니다. jQuery의 개발 방법론이 좋아서가 아니구요. 이미 시대는 jQuery의 패러다임을 뛰어 넘었습니다. Babel을 통해 ES6가 현실화 되었고, MVC패턴과 two-way binding이 일상화 되었고, node.js로 서버도 만들고, 심지어 atom에디터같은 데스크탑 어플도 만들수 있는 시대가 되었습니다.

그런데 시대가 바뀌었음에도 jQuery만 하면 자바스크립트를 왠만큼 하는 것 처럼 생각하시는 분들이 많이 있습니다. 이미 jQuery가 제공하는 개발 방법론은 낡았는데 그대로 쓰시는 분들이 너무 많습니다. 예를 들면 .closest()같은게 대표적입니다. 박스를 만들고 그 중에 하나를 클릭하면 상위 엘리먼트에 클래스를 지정하는 경우를 가정해 봅시다.

<div class="box">
<ul>
  <li><a href="#dog" class="item">Dog</a></li>
  ...
</ul>
</div>

li를 클릭하면 상위 div에 class를 추가하는 스크립트를 .closest()를 이용해서 만들어 봅니다. 박스가 한 페이지에 여러 개 들어갈수도 있으니 each를 써서 이벤트를 지정해야합니다.

$("div.box").each(function(){
  var $items = $(this).find("li a.item");
  $items.on("click", function(e){
    var $this = $(this);
    $this.closest("div").removeClass().addClass($this.text().toLowerCase());
  });
})

여기서부터 문제가 생깁니다. javascript 코드에.closest(“div”)가 갑툭튀하는데, 이것만 봐서는 무슨 의미인지 알수가 없습니다. 실제로 html태그를 확인해야 하는데, 그러기위해선 크롬 디버그 창을 열고 해당 엘리먼트를 선택한 후 Source화면에서 하나씩 위로 올라가봐야 합니다.

스크립트 개발이 다 끝나고 나니, 애니메이션을 위해 여분의 div를 넣자는 의견이 나옵니다.

<div class="box">
<ul>
  <li><div class="anim"><a href="#dog" class="item">Dog</a></div></li>
  ...
</ul>
</div>

이렇게 되면 javascript는 전혀 건드리지 않고 html만 수정했는데, 프로그램이 동작하지 않습니다. jQuery가 DOM을 다루는데 스페셜리스트인 것은 좋은데, 이런 기능은 View와 Controller를 연동시키기때문에 안티 MVC패턴을 만듭니다. 역사가 10년이나 된 jQuery에는 안타깝게도 이런 식의 DOM을 다루는 스페셜한 기능이 너무나 많습니다. 그리고 이런 기능을 사용한 후에 자기는 jQuery 좀 할 줄 안다고 어깨를 으쓱대는 사람들도 많습니다.

※참고로 위의 코드는 이런 식으로 재작성이 가능합니다.

$("div.box").each(function(){
  var $box = $(this);
  $box.find("li a.item").on("click", function(e){
    $box.removeClass().addClass(this.href.replace(/.*#/, ""));
  });
})

2016년이 되면서 IE 10이하의 브라우저의 대응이 끝났습니다. 현장에서는 IE8이 대응리스트에서 사라지고 있는 중이고, 당장 저부터 다음 프로젝트에는 대응할 생각이 없습니다. 게다가 IE11을 제외한 모든 브라우저가 에버그린 업데이트를 지원하기 시작했기때문에 브라우저 파편화 문제는 많이 해결되는 추세입니다. 올해 말이면 더욱 더 좋아져 있겠죠.  jQuery가 단기간에 대체되지는 않겠지만, 앞으로는 점점 jQuery에 의존할 필요가 없어질 것입니다.

앞으로는 부작용없이 최소한의 기능만을 빌린 jqLite, bliss.js, u.js 등을 이용한 개발이나, ES6 스타일로 개발하는 것도 유망해 질 듯합니다. 복잡다단했던 웹 업계에 jQuery중독에서 벗어날 시기가 찾아온 것입니다.

P.S. 방문하시는 분들이 많아서 2부를 작성해봤습니다.

이제와서 jQuery를 쓰면 안되는 이유 part 2