Category Archives: Web Standards

마크업 가이드

회사 이야기는 잘 안 하는 편인데, 이번에 조직을 변경하여 카카오에서 만드는 서비스의 사용자단에서 보여지는 산출물(HTML, CSS)을 만드는 조직의 리더를 그만두게 되었다. 이제 다른 업무를 하게 될 예정인데, 4년 넘게 몸담은 조직이라, 그동안 내가 해온 일들을 인수인계를 하기 위한 용도로 문서 작성을 하고 있다. 4년간 해온 일들을 정리할 수 있어서 나에게도 의미 있는 시간들이었는데…

내가 입사했을 당시에는 마크업 가이드가 존재했다.(지금도 존재한다) 접두어, 접미어, 예약 어등의 네이밍부터 중첩 허용범위 등 상당히 엄격하게 정의되어 있었고, 코드리뷰 시스템을 통해서 상당히 안정적으로 결과물을 배포하고 있었다. 그 당시 나의 상위 리더는 우리 구성원들이 경험이 많지 않았기 때문에, 우선 답을 알려 주는 것이 필요했다고, 몇 년이 지나면 가이드에서 벗어나서 좀 더 창의적으로 업무를 할 수 있게 되면 좋겠다고… 이야기 했다.

난 쉽게 납득이 가지 않았다. ‘가이드만 지키면 되는데 창의적인 생각을 뭐하러?’

그리고 다시 가이드를 봤다. 이건 안내서(guide)가 아니라 규칙(regulation)이었다. 난 리더의 말을 실현하기 위해 규칙이라고 되어있는 부분을 최소화하기로 했다. 필수로 지켜야 하는 항목과, 적용을 선택할 수 있는 부분 그리고 예전에 필수였지만 지금은 참고만 하는 항목으로 분리했다. 그리고 필수로 지켜야 하는 항목에는 반드시 그 근거를 넣도록 했다. 이제 규제는 최소화하고 창의적으로 생각할 수 있는 길을 만들어줬다고 생각했다.

예전의 가이드 시절부터 업무를 배운 친구들은 가이드가 빈약하다고 투덜 댄다. 최근에 입사한 친구들은 뭐 이렇게 지킬게 많냐고 투덜댄다.

난 무엇을 한 걸까… 그래도 나아지고 있겠지…

가장 중요한 것

참 많은 말이 생겼다. 웹 표준, 웹 접근성, RWD, Mobile First 등등등

우리는 근 10년여간 무엇을 위해 웹 표준의 날을 하고 세미나를 하고,
내가 하는 업무의 직함을 가지고 싸우고 얘기하고,
왜 다른 사람의 생각과 나의 생각이 다른지 고민하고 함게 하려하고 힘을 내고 그랬던 것 일까?

2001년에 웹 사이트를 만들어 돈을 버는 업체에 입사하여 일을 시작했다. 무려 14년…

그런데 위의 고민은 많이 했는데… 내가 왜 이일을 하는지 고민해 본적은 없는것 같다. 웹 표준을 왜 하는지, 웹 접근성을 왜 하는지 이런것만 고민 했던것 같다.

언제부턴가(제주에 올때 즈음인것 같은데) 내가 자주 말하는 주장이 하나 있는데… 그 말에 답이 있을지도 모르겠다.

내가 얘기해 왔던 것은 “콘텐츠가 제일 중요하다.” 였다.

그랬다 접근성도 표준도 RWD 도 모두 목적은 콘텐츠를 좀 더 잘 전달하기 위해서 일것이다..

콘텐츠가 제일 중요하다.

내가 일하는 직군의 이름이 그렇게도 중요한가?

내가 무슨일을 하는지는 여기 들어오는 사람이면 대충 알거고
이쪽 직군에서 수 년째 결론이 나지 않은채로 어떤 것이 맞는지 논의만 되고 있는 문제가 하나 있다면, 내가 일하고 있는 직군에 이름이 무엇인지에 대한 이야기 일것이다.

오늘 Kipfa라는 단체에서 Frontend Developer Ability Test를 만들어서 진행하려고 공개를 한 모양이다.
의도도 좋고 뭐 내가 남 돈버는데 왈가왈부 할건 아니지만,

자기네 마음대로, 지금 사용하고 있는 다양한 직군명을 정리를 해버렸네, 그것도 말도 안되게?
그들의 정의대로 하면 프론트엔드 디벨로퍼의 습득요구지식은 HTML, CSS, 웹표준, 웹접근성, Javascript, UX/UI, 웹 사이트 최적화 정도이고, 웹 퍼블리셔는 “HTML, CSS, 웹표준, 웹접근성, Javascript” 정도 라고 한다. 또한 HTML coder는 습득지식이 “HTML, CSS” 라고 한다는데…
그들이 말하는데로 이해해 보자면 front-end 업무 직군은 무슨 전직 시스템인가보다. 기술 탑재하고 레벨업하면 1차전직, 2차전직 뭐 이런식으로 말이지…

물론 현재 직군에 가장 잘 어울리는 말을 정하기가 쉽지 않은것 이라는 것도 알고 있고, 사람들이 대체적으로 어떤 직군명을 선호하는것도 알기는 아는데…
그리고 뭐 사업하는 사람들이야 자기가 쓰고 싶은말을 강조하고 싶겠지만, 저 내용을 감수하고 출제한 위원님들은 자기네들이 무슨 짓을 하고 있는것 인지는 알고있나?
외국에서 front-end developer라고 하니 그냥 그게 맞다고 생각하는건가? 외국에서는 사용하는 웹 개발자의 정의와 우리가 사용하는 웹 개발자의 범위가 어떻게 다른지는 알고는 있는건가?

웹 퍼블리셔, 웹 UI개발자 모두 많은 고민에서 나온 용어임을 잊지 말자. 그냥 단계의 하나로 치부할 용어는 아니라고 생각한다.

물론 나도 직군명이 그냥 하나로 통합되면 좋겠다. 그래야 말하기 편하니까..
그러나 내가 일하고 있는 직군의 명칭이 front-end developer라 불리우든, html coder든 웹 퍼블리셔든 중요한게 아니다. 단계로 나눌 필요는 더더욱 없고…
html, CSS만 할줄 아는 사람도 html,css 외에도 다른 스킬을 가졌어도, 그냥 우리는 같은 일을 하는 사람이고 같은 직군의 동료이다.
넌 웹퍼블리셔지만 난 프론트엔드개발자라고 너랑 나랑은 다른 직군의 사람! 이럴것이 아니다.

중요한건 내가 일하는 것에 대한 직군명, 내 직함, 그리고 보유스킬이 아니라 웹을 바라보는 관점 그리고 웹을 얼마나 사랑하는가, 그리고 웹에 대한 관심과 노력이다.(뭐 물론 돈 벌려는 의지도 중요하지…)
웹을 사랑하고 접근하는 만큼 실력과 보유 스킬은 늘게 되어있다.

SVN의 commit은 FTP upload가 아니다.

넥슨이라는곳에 입사를 했을때 결과물에 대한 파일 전달을 FTP의 특정 서버나 사내 공유폴더에 업로드하는것이 아닌 CVS라는 툴을 통해서 업로드 해야한다는 이야기를 듣게 되었다. 그때는 정말 결과물 업로드의 용도로만 알고 있었기 때문에 왜 내가 내손으로 작업할걸 업로드하는데 log comment등을 같이 작성해야하는지 몰랐다. CVS가 스타크래프트의 SCV처럼 뭔가를 운반하는 의미로 상통하지 않을까 이런 또라이 같은 생각을 하기도 했다. 좀 지나고 CVS가 버전 관리툴이라는것을 알게 되었고 난 좀 감동했다. ‘그럼 작업하다가 잘못 업로드 한게 있어도 이전 버전으로 돌릴 수 있는것이 아닌가!!!’ 라면서 감동했고 좀 더 자유롭게 좀 더 내맘대로 작업을 해볼 수 있는 기회도 생겼었다. 물론 남들의 작업 로그를 보면서 공부를 하기도 했다. 그때는 그냥 일하다 시간이 남아서 다른 팀원들의 각종 코드나 로그를 보는것이었는데 지금 생각해 보면 내가 지금까지 일해 오면서 버틸 수 있는 원동력이 거기서 비롯된것같다.

시간이 지나면서 난 CVS, SVN, Mercurial를 겪게 되었고 수많은 conflict와 merge를 겪으면서 내 자신도 성장했을거다 아마;;;;
넥슨에서는 commit log를 남길때 내가 이 commit을 하는 목적과 이유에 대해서 분명히 작성하는걸 규칙으로 세웠다. 그 덕분에 다른 사람의 코드를 보기가 더욱 쉬웠고, 담당자가 바뀌어도 인수 인계 절차가 간소화 될 수 있었다.
오페라에서는 더욱 그랬다. 오페라는 Bug tracking System으로 JIRA를 쓰고 있었고 그곳에서는 JIRA의 bug number나, Task number를 commit log 작성시에 포함하여 연동시키는 방법을 쓰고 있었다. 실제 내가 회사를 떠나도 내가 짠 코드와 내가 기록한 로그들은 남아있을것이다. 내가 만든 코드를 고칠 경우나 분석 할 일이 있을 때, 퇴사한 나에게 전화를 하지 않아도 되는점이라고 해야할까? 그렇게 나는 버전관리도구에 익숙해져갔다.

오페라를 관두고 잠깐 일을 하던 회사가 있었는데 그곳도 분명히 SVN을 사용하는 회사였다. 아 그럼 로그들을 보면서 내가 히스토리를 파악하면 되겠구나 생각했는데, 이게 웬걸? commit log의 절반 이상이 “.”이었다. 어느 정도 정보를 기록하는 사람도 있었지만 그 마저도 적절한 log는 아니었다. 이곳은 SVN에 커밋을 하면 특정 테스트 웹 서버에 동기화되어 웹에서 확인 가능한 상태가 되는 방식이었다. 그리고 그 URL을 협업하는 담당자에게 공유하는 방식이었다.  왜 log를 제대로 작성하지 않는가? 라고 물었더니… 대부분의 대답은

“어짜피 이 작업은 나만 하지 이걸 누가 본다고?”는 것이었다… 충격적이었다.
난 다시 물었다. 만약에 담당자가 바뀌면 어쩔것인가? 라는 질문을 했고 안 바꾸면 되지 와 그러기 위해 인수인계가 있는거다. 라는 답이 돌아왔다.
어안이 벙벙해서 SVN담당자와 팀장에게 따지듯이 물었다. 근데 이 두 사람은 이 이상한 상황을 개선하려고 엄청 노력을 했다는것이었다.
대부분 SVN은 테스트 서버에 파일을 올리기 위한 용도로 쓰는상황에서, 난 commit log를 의미있게 입력하게끔 만들고 싶었다.

불편하지만 commit log를 작성하는 규칙을 만들었고, 따르기를 바랬다.

그러다 한서비스만 4~5년 맡아서 진행하는 동료의 프로젝트에 내가 추가로 애드온을 작성할일이 생겼다. 난 그냥 아무 생각없이 작업을 했는데 페이지 레이아웃이 뒤틀리는 현상이 발생했고, 원인을 찾아서 쓸데없는 CSS코드가 삽입되어 있음을 찾아냈다. 내 입장에서야 쓸데없지만 담당자에게는 중요한 코드니까 넣었겠지라고 생각하며 물어봤는데, 그 코드가 뭔지는 모르겠지만 절대 지울수 없다고 한다. 그래서 반대로 해당 이슈에 대해 물어봤고, 그런 이슈는 듣도 보도 못했다는것; 결국 SVN에서 그 쓸데없는 CSS파일을 업로드한 시점을 찾았고 거기에는 당연히 commit log가 “.” 되어 있었다. 물어봐도 당연히 답이 안나왔다.
commit log가 조금이라도 작성이 되었으면 나중에 귀찮지 않았을것이다.
현재 자신이 작업하는 것이 혼자 버전관리를 한다고 해도 작업에 대한 로그는 남겨져야 한다. 당연한 얘기지만 버전관리툴은 결과물을 서버에 업로드하는 툴이 아니다 =_=

버전관리는 사용하면서 파일을 날짜별로 분기하는곳도 있다. 파일안에 보면 주석으로 변경사항을 기록한다. 버전관리는 왜 쓰는지 모르겠다.  예전의 파일에서 문제점이 생겨서 왜 이런 문제가 생겼는지 찾아보려고 해도 절대 답이 나오지않는다. 사람의 기억에 의존한다. 배포되는 파일과 작업하는 파일의 위치가 다르게 존재하고 작업하는 사람의 리비전과 배포하는사람의 리비전은 별도로 존재한다. 그 사이에 어떤 수정을 가하는지 알 수가 없다. 알 수 없기 때문에 추가 작업은 결과물에서 파일을 다운받아 작업한다. 버전관리가 될리없다. 버전관리의 최대장점이 여러사람이 작업하고 그 로그를 관리할 수 있다는것인데, 그게 안된다.

버전관리 주기도 엄청 중요하고 내 개인적인 기준으로는  최소한의 태스크로 구분을 하는편인데… 위의 상황에서 이런게 강조되는게 맞는가 싶다.

웹 접근성 향상 전략세미나 발표

오늘 서울상공회의소에서 열린 웹 접근성 향상 전략세미나에서 HTML5 과 AJax 접근성이라는 주제로 발표를 진행했다.

애초에 HTML5와 Ajax접근성에 대해 얘기하는것을 꺼리고 있었는데 내가 잘모르기도 하거니와(최근 너무 접근성하면 평가 방법에만 심취했었나보다) 민감한 얘기들이 나올수밖에 없는 부분이었기 때문이었다.

암튼 겁네 좋은 기회이기에 준비를 했는데 30분이라는 시간이 너무 짧았다…
빨리진행해야한다는 부담감에 말은꼬였고 목은 계속 메였다. ㅠ_ㅠ

발표자료도 책자와 많이 바뀌어서 청중 분들께 너무 죄송했다.
암튼 발표자료를 다시 올려둔다. HTML5&Ajax Accessibility 발표자료 다운로드

그나저나 1시간전에 명동에서 공항버스를 탔는데 난 왜 이제 서울역을 지난걸까…. 난 무사히 제주에 갈 수 있을까?