Web publisher Hye Jin Lee

웹퍼블리셔의 자바스크립트 범위는 어디까지 인가

굉장히 민감하고 조심스러우며, 논쟁이 많은 부분중 하나 입니다. 사실 이부분에 대한 정답은 없습니다. 지난 세미나에서 멀더끙님께서 재미있는 이야기를 해주셨습니다.

웹개발자 역시 javascript 는 생소하다. 다만 서버언어등을 공부하고 사용했기때문에 논리적으로 풀어나가는 능력이나 문법에 대한 이해가 조금 수월할 뿐이다.

개발자 분들 역시 자신의 분야와 밀접할 뿐 따로 공부를 하셔야 하는 부담은 같다는 거죠. 과거에는 간단한 롤링베너나 아코디언메뉴, 탭메뉴처럼 화면상에서 이미 만들어진 html 을 시각적으로 표현하는 부분에 대해 제한적으로 웹퍼블리셔가 기능을 만들곤 했으며, 딱 거기까지가 우리가 해야할 일이라고 말하곤 했습니다. 하지만 정작 해당 스크립트를 제대로 사용하기 위해서는 html 이 만들어지기까지의 일련의 과정에서 다른 방식이 사용된다면(예를들어 컨텐츠를  ajax 처리 한다거나, 숨겨진 메뉴를 비동기 로드 한다거나) 우리가 만들어 놓은 함수는 새로 만들거나 쓰지 못하게 되는 경우가 굉장히 많아지게 됩니다. 그리고 실제로 그런 일들이 많이 있었죠.

저역시 수없이 많은 시행착오과 오류를 범해오면서 '개발자 탓' 만 해오던 때가 있었습니다. 하지만 지나고 보면 다 그럴만한 이유와 사정이 있었던 건데요...

이부분의 정답은 없으나 현재의 제가 생각하는 웹퍼블리셔의 프론트 개발 관여 범위는 이렇습니다.

' 화면에 뿌려지는 컨텐츠 중 퍼블리셔가 관여해야 하는(롤링 베너나 동적으로 움직이는 컨텐츠, 혹은 탭과 같은) 이벤트 처리는 data를 받아와 뿌리고 동작하는 부분까지 모두 관여해야 한다. 이때 웹개발자에게 요청하거나 역으로 보내줄수 있는 부분은 json 등으로 가공된 javascript 파일이며, 개발자는 해당 데이터만 정상적으로 넘겨주면 된다.'

예를 들어 우리는 컨텐츠 제일 하단에 롤링베너를 만들어야 합니다. 좌,우측으로 클릭하면 다음 페이지에 존재하는 컨텐츠가 화면에 뿌려집니다. 과거에 우리는 ul태그 등으로 리스트를 만들고 좌,우측 버튼을 클릭하면 필요한 컨텐츠는 보여주고 필요없는 컨텐츠는 숨기는 방법을 주로 사용했습니다. 이제 아래와 같은 방법이 더 좋은 방법이 아닐까 합니다.

banner 데이터를 받거나 혹은 만든다(샘플)

베너의 갯수를 확인하여 좌,우 버튼이 필요한지 필요없는지 파악한다.

좌,우 버튼이 필요하다면(갯수가 화면에 뿌려지는 것보다 많다면) 좌우 버튼의html 을 만들고 이벤트를 추가한다.

최초 화면에 뿌려질(필요한 베너만)정보만 html 을 만들어 화면에 뿌린다.

좌,우 버튼이 클릭되면 필요한 html 영역이 있는지 확인하여 없다면 동적으로 해당 html 을 생성한다. 이때 불필요한 베너는 숨긴다.

만약 버튼이 클릭되었을때 필요한 html 이 이미 만들어져 있다면 해당 베너를 보여주고 기존 베너들은 숨긴다.

업체마다 개발자 마다 다르지만 통상은 아래와 같은 데이터를 받아와 html 을 생성할 수 있습니다.

var banner = [{    img : 'banner1.jpg'   ,src : 'http://www.bannerLink.kr/'   ,target : '_blank'   ,alt : '베너입니다'},{    img : 'banner2.jpg'   ,src : 'http://www.bannerLink.kr/'   ,target : '_blank'   ,alt : '베너입니다2'},{    img : 'banner3.jpg'   ,src : 'http://www.bannerLink.kr/'   ,target : '_blank'   ,alt : '베너입니다3'}]

이런 데이터는 보통 banner.js 등과 같이 js 파일로 전달 받을 수 있으며, 혹은 html 문서내에 추가되어 받을수도 있습니다.그리고 js 파일로 넘겨 받는다면 우리는 document.createElement('script') 와 같이 스크립트엘리먼트를 동적으로 생성하여 해당 엘리먼트에 속성을 추가해 동적으로 js 파일을 로드할 수도 있습니다. 당연히 로드가 완료되면 필요한 스크립트가 실행되도록 콜백함수도 만들어 낼 수 있습니다. 이 방법은 초기에 과도한 데이터 파일(많은수의 js 파일)이 로드됨으로써 발생되는 블럭킹 현상을 어느정도 감소시킬 수 있습니다.

동적으로 스크립트를 로드하고 콜백함수를 실행하는 샘플파일을 첨부합니다. 제가 작성한 부분이며 발견되지 않은 오류가 있을수 있습니다. 문서에도 표기하였으나 MIT 라이센스 규약을 따릅니다.

또한 우리는 위와같은 방법으로 불필요하게 로드되는 컨텐츠(display:none 이적용되었을 이미지들)의 수를 상당수 줄여 불필요한 트래픽 방지 및 페이지 로드속도가 줄어드는 이득을 얻을 수 있습니다.

위의 데이터는 jquery 를 이용해 쉽게 재가공 할 수 있습니다.

var htm = [];$.each(banner,function(index){    htm[index] = '<a href="'+this.link+'" target="'+this.target+'" ><img src="'+this.src+'" alt="'+this.alt+'" /></a>'})

이후 부터는 매우 간단한 일들입니다. 지금까지 어느정도의 UI를 개발해본 분들이라면 아시겠지만, htm 배열에 저장되어 있는 html 태그들을 그냥 꺼내서 필요할때마다 꺼내쓰면 되기 때문입니다.

최근 이미지를 많이 사용하는 사이트의 경우 이러한 패턴으로 페이지 제작을 하는 경우가 많이 있습니다. 과거처럼 자바스크립트를 껐을경우도 정상적으로 접근해야 한다는 조항이 현재는 절대적이지 않으므로(그리고 이러한 방법으로 얻을 수 있는 이점이 매우 크기때문에), 현재도 그렇지만 향후에도 javascript (혹은 ECMAscript)의 의존도는 더 커질것이라고 생각됩니다.

결론

안타깝게도 아직까지 많은 분들이 자바스크립트와 담을 쌓고 계시거나 혹은 html , css 가 가장 중요하며 웹접근성과 웹표준, 그리고 크로스브라우징같은 이슈가 가장 큰 이슈라고 생각하십니다. 그러나 웹은 이미 웹을 뛰어 넘어 매우 빠르게 발전하고 있으며, html5 에 추가된 매우 많은 api 관련 태그들 역시 대부분 javascript 를 통해 컨트롤 됩니다.

우리가 해야하는 일, 할수 있는 일이 많아지는 만큼 우리는 보다 전문적인 직업이 될 수 있으며, 우리에게 의존하게 만들 수 있습니다. 그것은 우리가 그렇게 할때 가능한 것입니다.

제가 적은 이글이 결코 html, css, 접근성, 표준화를 소홀히 하라는 말은 아닙니다. 단지 너무 얽메이지 말고, 열린 마음으로 도전하시길 바라는 마음에 적은 글입니다. 저역시 html, css, 접근성 등과 관련된 이슈에 대해 짬짬히 공부를 하고 새로운 이슈에 대해 검토하고 있습니다. 웹에서는 모든것이 중요합니다.

현재의 내가 하고 있는일도 벅찬데...라는 생각은 자신을 가둘뿐 아무런 도움이 되지 않습니다.

좀더 자신있게 자신의 가치를 높이는 일에 도전해 보시면 좋겠습니다.

-- git :

http://www.git-scm.com/

-- node.js :

http://nodejs.org/

-- gulp :

http://gulpjs.com/

-- gulp less :

https://github.com/plus3network/gulp-less

-- bower :

http://bower.io/

-- ruby :

https://www.ruby-lang.org/ko/

-- hologram :

http://trulia.github.io/hologram/

단, 한가지 일이 아니라 다양한 일을 해야 하고 그만큼 디자이너에게 요구되는 스킬셋이 많습니다. 그 중 가장 중요한 스킬은 '본인의 아이디어를 어떤식의 비쥬얼 언어를 사용하여 표현해 낼 줄 아는 가'인것 같아요. 비쥬얼 커뮤니케이션 디자인 스킬이라고나 할까요. 표현하는 방식은 정말 디자이너 개개인에 달려있어요. 본인이 생각하기에 비주얼로 표현하는것이 좋다면 비주얼로 표현하는 것이고, 와이어프레임으로 표현하는 것이 편하다면 와이어프레임으로 표현하는 거죠. 대신 그것을 잘 팔아야하죠. 프로덕트 매니저와 엔지니어들과 옆에 앉아 함께 일도 많이 해야 해요. 그렇기에 UX디자이너는 과거 비주얼 디자이너들이 하던 일보다 더 많은 일을 할 수 있고, 자기가 욕심 부리는 만큼 더 크게 성장할 수도 있다고 봅니다.

디자이너를 보는 관점도 많이 달라졌죠. 한국에서 UX디자이너로 일하고 계신 분들을 보면 보통은 과거에 디자인 기획, 와이어프레임 짜시던 분들과 많이 다르지 않은 것 같아요. 즉, 누군가가 ‘이런 디자인을 했으면 좋겠다’라고 디자인 Tasks를 주면 그것을 완성하시는 것 같아요. 반면 미국에서 UX디자인을 잘 하시는 분들을 보면 아무도 그 사람들에게 무엇을 하라고 하지 않아요. 저의 경우에도 처음에 Flash팀에 들어갔을 때 저에게 주어진 Tasks가 없어서 당황했던 적이 있었어요. 그런 경우에는, 본인이 ‘내가 이런 일을 해야 한다, 이건 이렇게 바꿔야 한다.’라고 직접 PM에게 들고 가서 설득하고 아이디어를 제시해야 하는거죠.

예를 들어 이미 한 5~6년 된 오래된 어플리케이션에서 뭘 바꾸겠어요? 이미 잘 돌아가고 있고 사용자들도 익숙해진 상황에서 디자인 할 것이 딱히 없어요. 그렇지만, 그럴 때 UX디자이너가 나서서 ‘내가 생각할 땐 이러이러한 것이 문제인 것 같다, 이렇게 바꾸면 달라질 것 같다’하고 문제 의식을 가지고 어떻게 하면 사용자의 경험이 더 나아질 수 있을까를 계속 연구하는거죠.