얼마전에 front-end developer 의 기본스킬에 대해서 외국의 어떤 블로그에 실린것을 본적이 있었다. 그리고 예전에 내가 웹 퍼블리셔의 업무 범위라는 글을 작성한적이 있는데 내가 작성한 글은 너무 오래되었고 외국의 블로그의 경우 front-end가 javascript 개발에 가까운것 같아서 우리나라에서 웹 퍼블리셔 라고 불리는 사람들의 조건에 대해서 생각해보게 되었다. 사람마다 생각이 다르고, 받아들이는 입장도 다르니 보고 태클걸지말자. 날 아는 사람은 알겠지만 태클걸면 바로 고쳐준다. =_= 우리 또 귀 얇자너?

하나하나 쳐다보자.

영어

일단 이것이 첫 번째 라는것이 매우 슬프다. 나 솔직히 영어 정말 증오한다. 게다가 증오하는 만큼 정말 못한다. ㅠ_ㅠ
근데 W3C 에서 나오는 HTML, CSS, WCAG등의 스펙 문서를 비롯해서 최신 트랜드에 대한 글은 우리나라에서 만들어내는 콘텐츠의 양보다 외국에서 만들어지는 양이 압도적으로 많다. 압도적으로 많다기 보다 한국의 웹 퍼블리셔는 콘텐츠를 거의 생산해내지 않는다고 보는것이 맞을듯하다.  블로그는 대부분 하지않고 외국의 글들을 열심히 퍼다 트위터에 소개하기 바쁘다. 트위터에서 외국 글 소개하고 코멘트 하는 사람들 보면  난 그냥 좀 그렇더라, 그 글 번역이라도 해서 소개하던가, 그럴 시간이 없다면,  글에 대한 특징이나 장단점에 대한 소개가 좀 더 있으면 좋겠다는…
음 잠시 다른얘기가 나왔지만 너도나도 한글 콘텐츠 만들라면 아직 시간이 걸리니, 어쩔 수 없지 않은가? 공부하려면 영어글이라도 봐야지
아까도 언급했듯이 난 영어를 거의 할 줄 모른다. 그래도 영어로 된 웹 문서는 본다. 우리에겐 훌륭한 인터넷 사전과 구글 번역기가 있다.이것만 잘 활용해도 번역까지는 아니더라도 대충 이글이 어떤 얘기를 하는지 정도는 알 수 있다. 본만큼 실력이 늘게 되어있다.
구글 번역기가 맘에 안들면 구글번역이를 일본으로 우회해서 번역하는 방법도 있다. 영어>일본어>한국어, 영어>한국어, 영어 이세가지 놓고 비교하면 말만들기 쉬워 진다 ㅋㅋㅋ

Spec 읽는 법

스펙을 모두 읽을 필요는 없다. 하지만 스펙은 사전과 같다. 필요할때 적절하게 바로 찾아볼 수 있어야 한다. 스펙은 실력의 밑천이 된다. 스펙은 보기 어려워서 안본다는 개 같은 말 절대 하지말자. 안보니까 어렵다-_-

HTML과 CSS

HTML, CSS로 밥벌어 먹는 사람이 HTML, CSS 가 뭔지 몰라서는 안된다. 오해는 할 수 있고, 전부를 모를 수 도 있다. 하지만 자기가 자주 사용하는 요소와 속성의 뜻이나 사용처 효과등은 알아두는게 기본이라고 생각한다.
난 이게 언급될것이 아니라고 생각했었는데, 많은 경우에서 내가 잘못 생각 했었다라고 깨달았다. 기본도 모르는 사람들이 너무 많다.
Spec 한번 보면 모두 해결될 문제다.

HTML, CSS가 어떤뜻인지도 모르는 사람들도 있을까봐 겁난다.

Javascript

언급하기 좀 애매한 문제였는데, 우리나라의 웹 퍼블리셔라면 난 기본적인 제어문이나, DOM 접근 정도는 할 수 있어야 한다고 생각한다. Javascript를 자신의 업무 범위에 포함 시키지 않더라도, 할 줄 아는 상태에서 HTML, CSS 하는것과 할 줄 모르는 상태에서의 결과물은 상당한 차이를 보인다고 생각한다. 퀄리티, 시간, 구조 등등 어느 한곳에서는 두각을 내게 되어있다.

많은 웹 퍼블리셔들이 자바스크립트를 배우는 것을 두려워 한다고 봤는데, 그런점을 Jquery라는 javascript library 가 해결해 주었다. 문제는 jquery 가 없으면 javascript 를 못하는 사람들도 많은 듯한데, Jquery를 할 수 있는 사람은 javascript도 할 수 있어야 한다.

서버측 언어의 개발

기본적으로 웹이 돌라가는 생리를 알아야 한다. 분명히 웹에서 중요한 위치를 차지하고 있는것들이 서버측에 매달려 있다. 데이터 베이스, 웹 서버, 서버측 언어등등의 콘텐츠를 생산하기 위한 기본적인 데이터 제공을 이부분에서 해주고 있다. 서버측 메모리 관리가 어쩌고, db최적화가 어쩌고, 깊게 들어갈 필요없이 서버측에서 언어가 어떤방식으로 실행되고 구동되는지 알 필요가 있다. 이것도 javascript처럼 아는만큼 보인다고 할 수 있다.

Source code management system[(revision or version) control system]

소스코드의 버전 관리는 상당히 중요하다. 세상은 혼자 사는게 아니다. 또한 내 기억력이 졸라 좋다(사실 기억력은 내가 좀 좋지 -_-)해도 모든 코드의 변경사항을 알수는 없다. 우리나라처럼 맨날 코드를 수정 개선하지않고 새로 만들어 버리는 나라는 상대적으로 그 중요성이 떨어진다고는 하나, 코드의 유지보수는 언제는 존재하고 그 로그의 저장은 언제나 필요하다.

서버동기화를 위해 SVN 같은거 쓸꺼면 그냥 FTP 써라 -_- 로그에 ” . ” 이딴거 쓰지 말고…

Source code compress or beautify

얼마전에 CSS속성을 정렬하는 방법에 대해 이야기한적이 있다. 뭐 이것에 대한 자세한 이야기는 다른사람이 조만간 할거라 보고..

암튼 소스코드의 정렬은 누구나 보기 쉽게 유지보수하기 쉽게 만드는 것을 그 목표로 삼는데, 우리는 CSS를 셀렉터 하나 정의당 한 줄로 모두 쓰고 있지 않나?(그 속성끼리의 순서도 정해놓고 말이지? -_-;;; )
이 방법(한줄로 주욱)이 옳다고 생각하는사람이 많으니, 뭐 나야 부정하진 않을꺼다.
하지만 코드의 용량적인 최적화와 작업의 효율성을 고려해서 코드 압축이나 코드정렬등의 기능을 사용하길 권장한다.
역시 난 이딴거 쓰기 싫다고 해도 이게 뭐인지 정도는 알아두자 -_-;

결론

생각나는건 이 정도인데 사실 위의 언급한 부분은 그냥 웹 퍼블리셔들이라면 기본적으로 알고 시작해야하는 부분이라 생각한다. 거의 디폴트 기본속성? (디아3에서 캐릭터를 선택할때 악마사냥꾼을 선택하고 레벨1로 게임을 딱 진입했을때의 그때?) 이것이 기본이 되어야 더 좋은 웹 서비스를 만들고 접근성이 높은 사이트를 만들 수 있다. 요즘 보면 트랜드에 민감한 척하는 사람들 많은데 기본도 안되어있는 트랜드 라는 것은 그 깊이가 뻔이 눈에 보일때가 많다.(나처럼 부족하면 그냥 트랜드에 둔감하면 된다.)

사실 트랜드 중요하다. 하루하루가 바뀌는 이 업계는 더욱이 그렇다. 저 위의 것들을 공부하고 알려고 노력했던 사람은 트랜드에도 강할것이다. 기본은 변하지않으니까….

기본은 사람의 마음가짐과 행동이다.

(이제 디아 해야지…)