JavaScript에 대한 왈가왈부

자바스크립트를 안다는 것은 무엇을 말하는가 ?

 

NodeJS 이전에는 “브라우저의 한계를 아는 것”이다라고 말해주겠는데 이젠 더 머리 아퍼졌다.

‘브라우저’ 혹은 ‘서버사이드’에서 제공하는 Javascript 엔진의 한계를 명확히 아는 것은, 자바스크립트로 원하는 것을 어떻게하면 만들 수 있는지 머리속에서 번개처럼 스쳐가듯 그릴 수 있도록 도와준다. AJAX 방식은 브라우저에서 지원하는 자바스크립트 엔진의 실행 스레드가 하나여야 한다는 제한 때문에 발생하는 쑈가 아니던가. JSONP, callback 이 따위가 왜 언급되는가? Cross Domain 참조 불가 제한 때문이다. Closure를 왜 제대로 알아야 하는가? 망할놈의 브라우저가 callback 함수를 호출할때 참조할 객체를 등록하는 기능을 제공하지 않기 때문이다. Javascript 시간 관련 함수가 예약된 시간에 정확히 실행한다는 보장이 없기 때문에 타이밍 싸움을 하는 것 아닌가! JS로는 local filesystem을 직접 접근하여 쓸 수 없었기에 (HTML5 이전) 서버로 일단 올려보내고 다시 다운받는 희안한 짓을 한 것이다. C++ 이나 Java 같이 근사한 모양으로 상속코드를 짜도록 지원하지 않기 때문에 저마다 상속스타일을 주장한다. typeof(“”) 은 typeof(null)과 같지 않다. http://wtfjs.com/ 에서 계속해서 씹는 이유가 자바스크립트가 너무 사랑스럽기 때문인가? 제대로! 생각처럼 동작 안하기 때문이지 않는가! 알면 알수록 What The F…!을 외치지만 … 그래도 좋은 이유는 ‘내 생각을 표현하기에 이만한 것이 없기 때문’이 아닐까?

 

가장 중요한 것중 하나인 이벤트 처리 조차도 상당한 삽질과 경험을 요한다. 결국 사용자의 마우스와 키보드에 반응하는 것이 웹페이지이기 때문에 사용자의 입력을 처리하는 부분은 무엇보다 중요할 수 밖에 없다. 사용자와의 대화(?)를 원활히 수행하는데 관여하는 JavaScript API와 브라우저별 특징을 아는 것도 큰 일중에 하나다 ㅜ.ㅜ 제길;; 프론트엔드가 괜히 뺑이치는 직업이 아니다. 브라우저별 CSS 표현 차이에 정통하면 전문가인가? 음;;; 어느정도는 그렇다고 생각한다. 다만 그 차이를 알아서 보정(?)해주는 프레임웍이나 라이브러리가 나와주기 전까지는 좀 어깨 힘주고 다녀도 하등의 문제 될 것은 없다. 덧없는 것일뿐…

 

이러한 제한에 익숙해 지기 까지는 각 상황에 따른 경험과 삽질이 뒤따른다. 그래서 ‘안다’라는 의미가 내포하는 바가 크다. 좀처럼 공부해도 자바스크립트가 어떤 놈인지 모르겠다면 자바스크립트를 욕하는 페이지나 사이트를 찾아보라. http://wtfsjs.com 은 좀;; 뭔가 계속 만들어내는 느낌을 주기 때문에 추천하지 않는다. 어떤 것이든 “왜 꼭 이래야 하는가?”를 되물으면서 원리를 파다 보면 결국 다 그 ‘제한’을 체험하게 되고 그 체험이 반복될 때마다 내공이 상승한다.

 

그러나, 이런 지식조차도 상상력을 가진 사람앞에선 아무 것도 아니다. 상상하지 못하면 실현시킬 수 없다는 예기는 JavaScript에게 정말 딱 들어맞는 말이라는 것을 난 강조하고 싶다. 동의하거나 말거나;; ㅋ

 

“상속을 사용하는 코드 스타일을 꼭 따라야 하는가?”

 

“왜 굳이 상속하는가?” .. =__=)’ 안해도 된다. 그냥 순차적으로, 생각의 흐름대로 처리해도 된다. 사장님이 그 사실을 모르더라도 제때 시간내에 프로젝트 마칠수만 있다면 누가 뭐라고 하든 상관없다. 브라우저마다 if..then..으로 분기하더라도 누가 뭐라고 하겠는가. 아하,, 버전차이도 있으니 조건 하나 나타날 때마다 대략 분기는 4개 이상이 되겠구나. 작성한 코드의 크기가 증가한다고해도 열심히 일한줄 알테니 걱정하지 않아도 된다. 로딩이 좀 느려지면 어떤가, 동작하는건 문제없으니. 게다가 작성된 코드를 누군가 무단으로 수정할려고 할때 엄두도 못낼테니 얼마나 좋은가? 도용의 의지도 약간은 꺾일테니 정말 효과적이다. 심지어는 몇일뒤 혹은 몇주뒤에 자신이 짠 코드를 다시 볼 때, 신상을 발견하듯 뭔지 알수 없는 느낌도 받을 수 있으니 일석삼조로구나. 어쨌거나 사장님은 상속을 사용하든 안하든 상관안한다. ㅋ

 

제대로 된 상속 매커니즘을 지원하지 않는 것이 이유라면 그럴듯하다. 그럼 C++ 에서 주장하는 다중상속이 해악하다하여 Interface로 바꾼 Java는 참된? 언어일것이다. 웃;; 맘대로 상속가능한 파이선이 있었네;;; 좀 생각해보니 perl 도 다중상속 한다. 심지어 bash 스크립트도 순서를 프로그래머가 조절한다는 가정하에 여기 저기서 상속(?)할 수 있다. PHP 도 .. =__=)” 음;; 이런 언어들이 “제대로” 상속을 지원하기 때문에 많은 수의 프로그래머가 즐겨 코딩하는 것인가?

 

상속을 하는 스타일을 따르던 싫든 상관없다, 다만 두명이상의 프로그래머와 협업을 할때, 코드사이즈가 머리 한계내에서 다 들어오지 않을 때 ,, 그 때 결정해도… 늦다. ㅋ

 

“DOM 을 다룰줄 아는 것은 무엇보다 기본이다”

 

왜? 어째서 기본인가?

‘기본’이란 항상 쓰이기 때문에 강조할 필요없이 반드시 그래야만 하는 것을 내포하는 것이라 정의할 때, 매 페이지마다 직접 호출하는 DOM API 는 얼마나 되는가. DOM API를 직접 호출한다고 메모리 관리가 자동으로 되진 않는다. node 검색방식에 따라서 호출하는 API function 이름도 틀리다. 결과값을 루프돌든지 hash 처리하든지 어쨌든 후처리 해야한다. 오류및 예외처리도 해야한다. 이런 것을 제대로 처리해주는 프레임웍이 있음에도 불구하고 ‘기본’을 강조하는 것은 대한민국은 ’순수 혈통’이라 뻥쳤던 각종 찌라시 역사처럼 무엇이든지 섞이지 않은 것을 고귀하다 보는 것과 무엇이 다른가? DOM API만으로 충분했다면 왜 jQuery 같은 프레임웍이 등장한 것인가를 설명할 다른 이유를 찾아야 할 것이다.

 

DOM은 직접 호출할 필요가 있을 때 알아도 아무런 상관이 없다. 아이디어가 떠올라 재빨리 코딩하고 디버깅을 거쳐 제대로 동작 되는 것을 확인한후 세부 튜닝(?)을 거치면서 필요한 부분만 직접 DOM API를 호출해도 된다. 예를 들어, Canvas 위에서 실시간으로 의료영상이미지를 조작하는핵심 루틴은 처음부터 DOM을 직접 호출하는 방식이 아니었다. 게다가 단 2% 정도만이 직접 DOM API를 호출할 뿐 대부분 jQuery를 사용한다. 게다가 속도를 내는 부분은 DOM과 관련이 없는 부분이기도 하다!

 

DOM을 다룰 줄 아는 것이 ‘기본’인 시기는 지났다. 프로그래머가 자바스크립트로 어떻게 해야 원하는 것을 얻을 수 있는지에 대해서 눈을 뜬 후에는 그저 관련 정보를 한번 보는 것만으로도 충분히 사용할 수 있기 때문이다.

 

또한, jQuery나 Sencha의 근본작동원리가 어떻게 되는지 반드시 알아야 하는 때는 지났다고 본다. 본인은 굳이 소스를 뜯어가며 작동원리를 익혔으나 이미 전 세계 개발자들에 의해서 검증된 훌륭한 프레임웍이 많이 있는데다가 이런 종류의 프레임웍을 또 하나 더 만들어낸다는 것이 제품/사이트 성격상 꼭 필요한 것이 아니라면 시간과 비용낭비일 가능성이 크다. 설령 자신이 심혈을 기울여 제법 그럴싸한 프레임웍을 만들었다 하더라도 변화무쌍한 브라우저의 발전과 각 버전별 차이를 지속적으로 업데이트할 것인가를 묻는다면…? 업데이트의 의지가 충만하다고 해도 왜 jQuery를 두고 당신이만든 것을 써야하나? 다른 사람에게도 자신이 만든 것을 강제할 권리는 없지 않는가? 각종 프레임웍의 근본 철학과 핵심 원리를 아는 것(누가 이런 점을 예기해줄 것인가?)은 유익할 순 있어도 반드시 강제될 필요는 없다고 생각한다. jQuery instance 생성 순서를 아는 것이 훌륭한 UI 를 만든다는 것과 관계가 있다고 강조할 수 없다. Sencha의 Class hierachy를 꿰뚫는 심미안이 있어야만 CSS 변경을 할 수 있는 것은 아니다.