웹 퍼블리셔세요?

클리어보스에서는 지난해 2월과 9월 경력이 1년이 못되는 서른명 정도의 분들을 모시고 '웹 퍼블리셔 오리엔테이션'이라는 자리를 가졌었습니다. 그리고 여름과 겨울에 가볍게 오프라인 모임을 갖기도 했었구요. 그 외에도 몇 차례 술자를 통해서 인사를 나눴던 분들도 계셨습니다.

첫 인사를 나누고 나면 으레 디자인을 하시는지 개발을 하시는지 업무를 묻곤 하게 되는데요. 아무래도 자리가 자리이니 만큼 짐짓 '웹 퍼블리셔'이겠지 하면서 "웹 퍼블리셔세요?"라고 질문을 해 봅니다. 그런데 의외로 적지 않은 분들이 머뭇거리시면서 "그게요... 아직은..."이라는 식으로 말 끝을 흐리곤 하시더라구요.

왜 그러셨을까요? 조금 더 이야기를 나누다 보면 저와 하는 일이 거의 같았습니다. HTML과 CSS를 주로 다루고, 자바스크립트를 너무 어려워 하지만 조금씩 공부하면서 적용해 가고 있다구요. 그럼 저는 "아 그럼 웹 퍼블리셔네요~"라면서 "왜 어려워하세요?"라고 되 묻곤 합니다.

그 분들은 웹 퍼블리셔라는 이름에 대한 부담을 갖고 계셨어요. 그리 먼 과거도 아닌 불과 몇 해 전까지만 해도 우리들 같은 사람들을 주로 HTML 코더라고 불려졌고, 그렇게 알아 왔습니다. 하지만 신현석님께서 보다 넓고, 깊은 의미로 직업적인 사명감과 자부심을 갖고자 '웹 퍼블리셔'라는 이름을 제안하셨습니다. 그리고 여러 사람들이 호응을 했고, 지금은 적잖은 곳에서 '웹 퍼블리셔'라는 직함을 사용하고 있지요. 그런데 비슷한 일을 하는데 어떤 회사는 'UI개발자' 누구는 '마크업 개발자' 어디는 계속 '코더'라고 불리고 있다 보니 혼란스러워들 하시더라구요.

웹 퍼블리셔라는 이름은 버겁고, UI개발자나 마크업 개발자, 프론트 앤드 개발자... 같은 여러 이름은 자신의 정체성을 더욱 모호하게 만드는 것 같고... 그렇지 않나 생각해 봅니다.

일단, 왜 '웹 퍼블리셔'라는 이름이 버겁다고 느껴질까요? 제 짧은 생각으로는 직함이 요구하는 전문성의 범위가 생각보다 넓기 때문입니다. HTML을 단지 기계적으로 작성하는 것이 아니라 논리적으로 판단하고, 의미 있게 작성할 수 있어야 하고, 표준에 맞도록 마크업 해야 한다는 것. 물론 CSS도 경제적이고 효율적으로 작성하고, 브라우저간 상호 운용성을 확보할 수 있어야겠죠. 핵은 지양하면서 말이죠. 거기에 웹 접근성 향상을 위한 심리적 부담감과 쉽지 않은 법률과 가이드라인. 거기에 단기간에 상승된 회사내의 입지. 웹 표준과 웹 접근성 이슈는 모두 '우리'에게 전담되어버린 듯 한 상황은 어지간한 경력자라 하더라도 쉽게 감내하기 어려울 수 있다고 봅니다. 사람마다 차이는 있겠지만 상당한 부담감이 될 수 있을것 같습니다. 그렇다 보니 '나는 아직 웹 퍼블리셔는 아니고, 코더다.'라는 생각을 갖게 되고, 족보 없는 가계도가 그려지곤 합니다. 코더를 하다가 웹 표준 좀 하면 웹 퍼블리셔, 그리고 자바스크립트를 조금 다룰 수 있게 되면 UI개발자. 로 말이지요.

지금 클리어보스에서 'HTML, CSS, JS 등을 주로 다루면서 사용자 화면을 설계하는 당신은 어떤 직함이 가장 좋습니까'라는 간단한(?) 설문조사를 진행하고 있습니다. 한 사흘 정도 진행되었는데 UI개발자가 37명으로 가장 많은 분이 택해 주셨고, 웹 퍼블리셔는 20명이 23%, 프론트 앤드 개발자가 13명으로 15%를 차지했습니다. 전체 결과를 보고 싶으시거나 설문에 참여하고 싶으신 분들은 클리어보스를 찾아주세요.

사실 설문의 결과는 그다지 중요하지 않을 수도 있습니다. 특별히 공신력이 있는 사이트도 설문 조사 방식도 아니니까요. 1위 결과를 모두 함께 사용하자라는 캠페인을 벌일 생각은 아예 없구요. 중요한 건 두가지 정도일 것 같습니다. 하나는 지금 이런 고민을 하는 순간이 과도기적 상황이라는 것이구요. 또 하나는 어떤 이름이 중요한 것이 아니라 스스로 자신의 일을 정의하고, 자부심을 갖느냐하는 점이라고 생각합니다. 최근 몇 년 동안 여러가지 상황들이 빠르게 변하면서 '코더'라는 직군이 급 부상한 상황에서 자리를 잡아가고 있다고 생각하구요. 이것은 앞으로도 몇 년은 더 지나야 조금 더 명확한 직무 범위나 가이드라인이 만들어질 것이라고 생각합니다. 그리고 두번째에 대해서 얼마전에 신현석님도 '웹 퍼블리셔의 업무범위'라는 글을 통해서 적으셨지만 우리들이 어떤 이름으로 불리는건 그렇게 중요한 것이 아닙니다. 첫번째 이유를 들어 시간이 정리를 해 줄 것입니다.(물론 그 시간 동안에 여러 사람들의 자발적인 노력과 행동들도 있을 겁니다.) 스스로 한계를 긋고 울타리를 좁게 만드는 것이 문제지요. 어떤 직군이나 자기계발은 언제나 요구되는 덕목입니다. 개발자나 디자이너, 기획자들 모두 다 그렇게 계속 공부하고, 연습하면서 자신의 직무 범위를 넓히고, 깊게 해 나갑니다. 우리도 그래야 한다는 것이지요. 자바스크립트를 어느 정도까지 해야 하는가를 고민하기 보다 일단 시작하시고 할 수 있을 만큼 계속해서 하시는 것이 좋습니다. HTML, CSS, JS, XML, SEO, 표준, 접근성, 시멘틱, 디자인, 도구, UI, UX... 이렇게 나열된 직무 갯수에 지레 겁먹지 마시길 바랍니다. 저도 위에 나열된 것중 어느것 하나 확실하게 잘 하는 것은 없습니다. 걱정하고 계시는 여러분과 크게 다르지 않은 것이지요. 어제도 HTML 공부를 했고, 오늘도 해야 합니다.

어떻게 보면 이런 논의나 설문 자체가 소모적인 논쟁이고, 답이 나지 않는 것일 수 있습니다. 하지만 고민하지 않고 넘기다 보면 나중에는 자신의 의지와 상관없이 큰 흐름에 그저 쓸려 다니기만 하기 쉽습니다.

나 스스로 고민해 보지 않으면 내 것이 되지 않는다. 그게 제 생각입니다.

개발자들이여 당신의 상사가 바보같다고 느껴진다면 이 책을 선물하라

소프트웨어 누가 이렇게 개떡같이 만든 거야 상세보기

데이비드 S. 플랫 지음 | 인사이트 펴냄

소프트웨어 사용이 어려운 이유는? 『소프트웨어 누가 이렇게 개떡같이 만든 거야』는 왜 사용자가 소프트웨어를 사용하기가 어려운지에 대해 이야기한다. 소프트웨어를 어렵게 느끼는 이유는 무엇인지, 누구 때문에 이러한 일들이 발생하는지, 과연 잘 만들어진 소프트웨어는 어떠한 것인지에 대해 재미있고 직관적으로 풀이한다. 잘못된 소프트웨어를 만드는 개발자들의 방식과 사용자들이 생각하는 방법을 대조적으로 알기

저는 웹퍼블리셔입니다. XHTML으로 마크업을 하고 CSS를 가지고 웹디자이너가 건네준 디자인을 브라우저 화면에 재디자인합니다. 그리고 JavaScript로 약간의 재주를 부리기도 합니다.

최근에 웹2.0이라는 경제적 용어가 이슈가 되고, 뒤를 이어서 웹접근성과 웹표준화에 대한 이슈가 커지고 있습니다. 하지만 아직도 많은 수의 클라이언트(기업의 우두머리들)와 웹사이트를 대신해서 만들어주는(웹에이젼시) 기업 내의 거의 모든 사람들은 이를 외면하거나 애써 피하려고만 합니다. 오직 웹퍼블리셔들만이 쫑알쫑알 떠들어 대는 듯한 느낌이 강합니다. 그나마 그것도 소수의 웹퍼블리셔들만이 말입니다.

최근에 저는 사내에서 적극적(?)으로 웹표준 홍보를 하고 있습니다. 웹디자이너들에게 사용자들이 폰트를 크게 키워서 볼 수 있다는 것을 인식시키고, 유연한 레이아웃을 부탁합니다. 바로가기 셀렉트 박스 옆에 버튼을 달아두면 시각장애인도 이용할 수 있을것이다라는 이야기도 합니다. 플래셔에게는 플래시의 대체 텍스트 기능이 들어 있음을 알려줍니다.(저는 플래시를 전혀 모릅니다. 하지만 웹에서 검색을 통해서 알아냈고, 그 사실을 항상 플래시를 다루는 사람들에게 알려주고 있는 겁니다! 이게 뭡니까!) 기획자와는 아주 긴 시간 논쟁을 벌여야 합니다. 그들의 스토리보드를 뜯어고쳐야 하고, 개발 프로세스를 개선할 것을 요구합니다. 그들에게 장차법을 소개하고, 다양한 브라우저를 보여줍니다. 그리고 우리 회사가 만들었던 그 많은 사이트들을 하나씩 보여줍니다. 그들은 당황해 합니다. 그러나 어떻게 해야 할지 모릅니다. 그저 클라이언트가 좋아만 하면 그만이다 말합니다. 20대를 위한 사이트는 20대만 들어오면 되고, 비주얼이 강한 사이트는 시각 장애인이 와도 볼게 없으니 무시해도 된다라는 논리. 청각 장애인을 위해서 간단한 사이트를 하나 더 만들면 되지 않겠냐는 논리. 회원가입 양식에 온갖 항목을 집어놓고 단 하나의 에러도 표시해주지 않아서 다시 처음부터 가입하게 만드는 개발자의 센스. 우리에게 사용자란 무엇인지? 사용자를 위한 사용성이란 무엇인지? 한번 진지하게 고민해봐야 하지 않을까요.

웹표준과 웹접근성에 대한 이슈는 이 책이 지적하는 사용자에 대한 사용성과 아주 밀접한 관계를 가지고 있습니다. 바보같은 개발자들은 자신들의 관점으로 사용성을 판단한다. 맞는 말인것 같습니다. 저도 제가 코딩한 마크업 문서의 오류를 확실하게 찾아내지 못합니다. 제가 작업한 스크립트가 사용자에게 편리함을 준다고 착각할 때가 아주 많습니다. 저 역시 한 명의 사용자라고 생각하기 때문입니다. 하지만 개발자는 어디까지나 개발자입니다. 완벽하게 사용자일 수 없습니다. 온전하게 컴퓨터를 제대로 알지 못하는 사용자 말입니다. 시시때때로 경고창과 말도 안되는 에러 메세지를 띄워서 사용자에게 선택을 강요하는 것은 개발자가 생각하는 사용자에 대한 사용성일 뿐입니다. 사용자들은 그것들을 원하지도 않고, 오히려 불편해 한다는 사실을 이 책은 적나라하게 보여주고 있습니다.

제가 생각하는 한국의 웹은 아주 심각할 정도의 개발자들의 웹입니다. 온통 신기하고 제멋대로인 웹이 지천에 널려 있습니다. 사용자들은 이 불편한 웹을 매번 새롭게 교육받으며 몇번의 시행착오를 거치며 적응해 가고 있습니다.

UI/UX를 떠들면서 우리는 항상 사용자 입장에서 생각한다라는 말을 합니다. 하지만 진정 사용자가 누구였는지를 고민하지 않았습니다.

처음 이 책의 제목을 접했을때 나는 단지 윈도우(또는 맥)의 소프트웨어를 만드는 사람들에게 딴지를 거는 것이겠지 싶었습니다. 하지만 저자는 윈도우와 웹을 폭넓게 껴 안으며 사용자를 무시하는 모든 개발자들을 싸잡아 '바보'로 만들었습니다.

너무나 속이 후련하고 시원합니다. 만약에 당신의 상사가- 대리나 팀장, 과장이나 부장이나 심지어 실장이나 이사라고 할지라도- 정말 바보같다고 느껴진다면 이 책을 읽어보라고 말 하시기 바랍니다. 저는 이 삼품평으로 인해 출판사가 돈을 더 벌고 저자가 비싼 음식을 먹게 할 마음은 추호에도 없습니다. 가까운 도서관에 이 책이 있다면 공짜로라도 보시기를 바랄 뿐입니다. 지인중에 누군가 이미 이 책을 사서 보았다면 빌리거나 복사라도 해서 읽어보시길 바라는 겁니다.

개발자들은 너무나 소심해서 자신을 향해 '바보'라고 욕을 해대면 화를 낼지 모릅니다. 하지만 최소한 그렇게 부끄러워할 줄 아는 개발자라면 이 책을 읽고 사용자에 대한 생각을 고칠수 있을것이라고 생각합니다.

UI개발자와 웹퍼블리셔

올블로그에서 UI개발자를 뽑는다는 채용공고를 내었군요. 개인적으로는 좋은자리라고 생각합니다.
그런데 공고글과 아래 댓글들을 읽다가 살짝 아쉬운 생각을 갖게 되었습니다.

올블로그측에서 올린 공고 내용중 자격조건이 아래와 같습니다.

* 우리나라 최고의 웹표준 전문가가 되어야겠다는 개인적인 비전을 가진 사람
* HTML과 CSS에 대한 기본적인 개념 탑재
* 위지웍 에디터를 사용하지 않고 하드코딩 가능
* 프로그래밍을 조금 할 줄 알면서 디자인에 관심이 많으신 분~

그리고 댓글에서 "재시켜 알바"님은 문장만 번드릇 하지 결국은 '단순 코더'를 뽑는게 아니냐하고 아쉬움을 나타내셨습니다. 저 역시 복지쪽만 보고 "오 나쁘지 않은데~"라고 생각하고 말뻔 했는데, "재시켜 알바"님 덕분에 기업과 개인(웹퍼블리셔)의 시각 차이를 다시한번 고민하게 되었습니다.

한동안 코더, 웹퍼블리셔, UI개발자 등 공통의 업무(HTML코딩)를 가진(조금씩 차이를 두고 있기는 하지만) 직군과 이름에 대한 토론이 일었던 적이 있었습니다. 그 가운데 윤좌진님의 "나는 웹퍼블리셔입니다"라는 선언문(?) 이후로 "웹퍼블리셔"라는 이름이 많이 사용되고 있는 분위기가 되었고, 그렇게 굳어져 나간다고 생각했습니다.

하지만 최근에 네이버를 비롯해서 다음, NCSOFT 등 업계의 리딩기업들이 "웹퍼블리셔"보다는 "UI개발자"라는 이름으로 코딩업무를 할 인력들을 채용하고 있는듯 합니다. 상대적으로 웹에이젼시쪽에서는 "웹퍼블리셔"가 많이 정착되어 가는 분위기인데 말입니다.

어디까지나 제 생각이지만 포털/게임사에서 요구하는 UI개발자는 UI를 기획하고 제안할 수 있는 이론적 지식을 갖추어야 합니다. 그리고 시멘틱한 마크업을 통해서 구현할 수 있어야 할 것입니다. 그리고 웹퍼블리셔 역시 그래야 한다고 생각하고 있습니다. 그럼 둘의 차이는 근본적으로 없는 것인데 부르는 이름이 두개이다 보니 혼란이 생기곤 합니다. 얼핏 UI개발자가 웹퍼블리셔보다 나은 직종같아 보이기까지 합니다. 여전히 많은 웹퍼블리셔들이 웹퍼블리셔의 업무의 범위를 HTML코딩과 CSS작성정도로 국한시키고 있는것 같습니다. 스스로 한계를 만드는 것이 아닌지 싶습니다.

이런것 같습니다. 웹에이젼시는 기본적으로 웹사이트를 대행해서 제작해주는 회사입니다. 따라서 그 안에서 일을 해야하는 HTML코더들은 (현재까지는 그리고 당분간은) 순수하게 코딩이 주 업무가 될 수 있습니다. 하지만 네이버를 비롯한 포털업체와 게임회사들은 방대한 컨텐츠를 효과적으로 제공하기 위한 UI/UX를 개발하는데 집중해야할 필요성이 있을것입니다. 하지만 웹에이젼시든 포털/게임이든 이러한 업무를 담당하는 사람에게 요구되는 첫번째 기능은 HTML코딩입니다. 다만 여기서 포털/게임사에서 "UI개발자"를 요구할때 정말로 UI를 제안하고 기획할만한 코더가 많지 않다는데 있는것 같습니다.

결국은 UI개발자던 웹퍼블리셔건 해야할 일은 크게 다르지 않다는 겁니다. 현시점에서는 말이죠. 하지만 두 이름이 간극을 좁히지 않고 점점 멀어져 가야 한다면, 확실한 영역과 의미를 가져야 할 것 같습니다. UI개발자가 웹퍼블리셔(코더)보다 한 수 위라는 잘못된 인식을 가져서도 안될듯 하며, 지금처럼 두 이름의 직군의 경계가 모호해져서도 안될것입니다. 아울러 하나의 이름으로 갈 것이라면 그 시기가 조금이라도 당겨져야 할 것 같다는 생각도 해봅니다.

베스킨라빈스에 코더가?!

여자친구와 함께 간 베스킨라빈스에서 아이스크림을 먹고 있는데 눈에 확 띠는 "BR Cooler"
나는 순간 "BR Coder"라고 읽어버렸다. 직업병인가!

태그와 태그 사이에 나 있다

지난 2년 군대에 있는 동안 가장 힘들게 날 괴롭혔던 것은 나의 미래였다. 과거에 묻어둔 사랑과 열정에도 나는 쓸쓸해 했지만 다가오는 미래는 처량한 감상에만 빠질 수 없게 만들었던게 사실이다. 특히 직업이라는 것. 나이를 먹고 나도 한 사람의 몫으로 삶을 지탱해야 할 때가 되어서 그래 내게도 뚜렷한 직업이 필요해지는 시기가 오니까 막막했다.

입대전 나는 학생이었지만 한편으로는 프리랜서라는 타이틀을 달고 있는 직업인이기도 했다. 그 때는 코더라는 이름으로 불리던 그 일. 인터넷에 뿌려져 있는 수 많은 웹페이지들을 출판(Publishing)하는 일을 하는 작업이다. HTML이라는 아주 쉽고 간단한 언어를 가지고 약간의 수고만 해주면 얼마든지 할 수 있는 일이었다. 웹디자이너들이 주로 겸해서 하기는 했지만 제법 규모가 있는 웹에이젼시에서는 업무의 효율을 높이기 위해 코더들을 아르바이트나 계약직, 또는 낮은 연봉의 정규직으로 채용하고 있었다. 작업은 단순했지만 업무의 양은 상상을 초월한다. 흔히 노가다와 비교하는데, 정말 단순히 삽질만 온 종일 하는 것과 같은 일과의 연속이었다. 창의적이고 생산적인 일은 디자이너와 개발자의 몫이지 코더의 몫이 아니었다. 고분고분히 좀비처럼 페이지만 만들어내면 그만이었다.

과연 이 일을 계속 해야만 하는가? 그게 지난 2년동안 날 가장 힘들게 흔들었던 고민이었다. 하루가 다르게 변하는 세상, 웹세상에서 희망을 볼 수 있을까. 한국이라는 척박한 공간에서 웹이라고 꿈을 심어볼만하겠는가. 나의 생각은 대체로 부정적이고 회의적인 것이었다.

내가 상병을 달고 다섯달쯤 지났을 때 부대에 인터넷방이 생겼다. 그리고 그 즈음하여 나는 김중태님의 블로그에서 시멘틱웹에 대한 이야기를 처음 접했다. 김중태님은 웹2.0과 시멘틱웹을 설명하기 위한 책을 내셨는데 다음 휴가때 수원역에 도착하자 마자 서점을 찾아 책을 샀다. 지금 생각해보면 그 책이 내가 웹퍼블리셔(코더)의 명함을 조금 더 유예할 수 있도록 꿈을 잡아준 길라잡이였던것 같다. 김중태님의 책과 블로그에서 나는 현실의 변화와 더불어 내 인식의 변화를 가져올 수 있었고, 인식의 변화는 내 다짐을 굳히고, 행동을 결행하는데 도움이 되었다.

올 여름. 나는 마지막 휴가를 나와 몇 군데 회사의 면접을 봤다. 며칠의 고민이 있었지만 비교적 어렵지 않게 지금의 회사를 선택하고 전역 후 바로 출근을 할 수 있었다. 난 웹퍼블리셔가 되었다.

소속은 개발팀이고, 처음 명함은 개발자였지만 업무적으로 퍼블리셔였고, 현재 새로 받은 명함에는 '웹'이라는 글자가 생략되긴 했지만 퍼블리셔라고 적혀 있다. 디자인팀이 아닌 개발팀에 소속되어 있는 까닭은 회사와 나 개인의 합의와 결정에 의한 것이었다.

지금의 웹퍼블리싱 작업은 과거와 많이 달라져, 기본적으로 UI를 인식하고 설계하는 기획자적 안목과 이미지로 구현된 디자인을 의미론적으로 분석하여 재디자인하는 디자이너적인 창의력, 프론트(웹브라우져)단에서의 사용자 인터페이스를 위한 개발자적 실용성을 고루 갖추어야만 하게 되었다.

물론 나는 아직도 많이 부족하고, 이제부터라는 생각으로 공부하고, 실무를 더해가고 있다. 여건도 크게 나아지진 않았다. 아직도 디자이너나 개발자보다는 낮은 대우를 받아야만 하고, 업무의 양은 웹표준화로 인해 더욱 가중되었다. 인력은 부족하고 요구는 늘었다. 웹퍼블리셔의 작업은 결과만을 두고 보았을때 최종 사용자에게 가장 눈에 띄지 않는 작업이다. 때문에 퍼블리셔의 능력에 따른 대접을 요구하기란 더욱 힘들다. 하지만 웹퍼블리셔의 세심한 노력과 과정에 따라 완성된 사이트의 질은 크게 높아지거나 낮아지게 된다.

무심하게 눈발이 내리는 겨울밤. 사회에 첫 발을 내딛고, 반년의 시간을 지난 즈음. 그리고 새로운 공부와 인연을 맺기 직전의 순간에 이런 글을 남기는 까닭은 내 자신의 측은함도 있겠지만, 내 직업에 대한 약간의 자부심이 불을 피우기 시작했음이기도 할 것이다.

웹표준화를 통해서 가장 강조되는 것은 의미있는 태그를 사용하라는 것이다. 이것은 장애를 가진 사람들을 비롯한 모든 웹에 접근 가능한 사람과 기계들에게 정보로의 접근을 허락하고, 공평하게 제공되어질 수 있어야 하는 철학에서 비롯된다고 본다. 의미있는 태그란 무엇인가. 내가 웹을 통해 나타내고자 하는 내용이 무엇인지를 그림이나 영상이 아닌 태그로써 보여줄 수 있어야 한다는게 아닐까.

고로,
태그와 태그 사이에 나 자신을 가장 먼저 정의하고 보여줄 수 있어야 하지 않나 생각해본다.

웹표준화 작업에 따른 용어의 혼란

말과 글이라는게 참 어렵고, 중요한 것이라서 어떻게 불리고, 어떻게 씌여지느냐에 따라 성격이 달라지는것 같습니다. 그리고 본래 용어가 없는 것이 행동이나 결과로 나타나면서 새롭게 만들어지기도 하고, 용어가 발생하고 의미를 부여받으면서 성격이 굳어지기도 합니다. 최근에 웹표준화 작업이 빈번해지면서 과거와 현재의 용어가 충돌하는 모습을 종종 보게 되는것 같습니다.

1. 코딩과 퍼블리싱

우리같은 사람들이 하는 일을 가르켜 대부분이 '코딩'이라고 하죠. 하지만 자바든 C든 코드를 작성하는 작업 역시 '코딩'이거든요. 그래서 개발자분들과 대화할땐 '코딩'이라는 용어때문에 혼란을 빚기도 합니다. 다행히 요즘은 '퍼블리싱'이라는 용어를 쓰면서 그 의미를 새롭게 정의하고 있죠.

2. (HTML)코더와 웹퍼블리셔

업무 자체를 부르던 용어는 그 직종의 이름이 됩니다. 코딩을 한다라고 말 했을때 우린 '(HTML)코더'였고, 퍼블리싱 작업을 한다고 하는 지금은 '웹퍼블리셔'입니다. ('나는 웹퍼블리셔입니다' 참고) 사실 둘의 차이는 없습니다. 하지만 용어의 차이가 가져다 주는 느낌은 아주 다릅니다. '코더'일 때 우린 디자이너와 개발자 사이에서 자리도 제대로 잡지 못하고, 때론 멸시를 받아가면서 한낱 '알바'에 불과한 일을 하고 있다고 생각해야 했습니다. 하지만 지금은 당당하게 '웹퍼블리셔'임을 밝히며, 우리가 하는 일에 자부심을 가지기 시작했습니다. 디자이너와 개발자도 함부로 하지 못합니다.

3. TABLE코딩과 DIV코딩

표준화 작업과 관련해서 'DIV코딩'이라는 정체 불명의 용어도 생겨났습니다. 그리고 과거의 비표준화 코딩을 'TABLE코딩'이라고 부르게 되더군요. 어찌보면 맞습니다. 표준화 코딩시에 가장 많이 등장하는 태그가 아무래도 'DIV'이고, 과거의 방식에서는 'TABLE'이 가장 많이 나왔죠. 다시 말해 디자인을 구조화시키는 작업에서 그 레이아웃을 잡는데 있어 핵심이 되는 태그가 'TABLE'에서 'DIV'로 바뀐점을 시사합니다. 그래서 꼭 틀린 의미로 보이지는 않더군요. 다만, 'DIV코딩'이 마치 'TABLE'태그를 완벽하게 대체한다는 의미로 오해될 수도 있는것 같습니다. 이건 아니겠죠. 표준화 코딩에서 'TABLE'태그 역시 사용 가능한 태그이고, 표를 만들어야할 자리에 궂이 'DIV'로 어려움을 사서 할 이유는 없으니까요.

현장에서 일을 하고 있는 퍼블리셔들은 누구보다 이러한 용어의 혼란을 잘 알고 있을겁니다. 지금 이 순간에도 "아무개씨 코딩좀 부탁해요", '요즘은 코더 구하기가 어려워", "코딩 잘 되가?" 라는 말들을 듣고 있는 분들이 계실겁니다. 비교가 되지는 않지만 일본이 독도를 다케시마라고 부르는 것을 우리는 참지 못하죠. 누군가 우리를 그저 코더라고만 부른다면 괜히 화가 날지도 모릅니다. 표준화 코딩이라고 하지 않고, DIV코딩이라고 하면 그 사람의 무지함에 치를 떨수도 있습니다. 하지만 어디까지나 과도기적인 현상이라고 생각합니다. 우리들 조차도 스스로를 '웹퍼블리셔'라고 말하지 않는 사람이 아직도 많고, '퍼블리싱'보다는 '코딩'이라는 용어가 더 편하게 느껴지기도 합니다. TABLE코딩이든 DIV코딩이든 나 스스로 이해하고, 작업을 진행시킬 수 있기도 합니다. 차차 나아지리라 봅니다. 직종을 가르키는 용어가 이미 널리 알려지기 시작했다는건 그래서 참 다행인겁니다. 웹표준화라는 용어도 많이 알려져 있구요. 개인적으로 '퍼블리싱'과 '코딩'중에는 '코딩'이 좀 더 편하더군요. 프로그래밍도 흔히 '개발'이라고 짧은 용어로 많이 쓰죠. 다만, 세번째 TABLE코딩과 DIV코딩의 문제는 신중하게 반응해 봐야겠습니다. 누군가 "DIV코딩해 주세요"라고 한다면, "아 표준화코딩이요?"라고 되물어 줍시다. 그렇게 자연스럽게 용어를 바꿔 나가면, 인식과 의미가 변해가지 않을까요.