웹퍼블리셔를 돌아보다

Category
in occupation, 생각노트
Posted
2014-10-26 23:52
세월호 참사 1주기 결코 잊지 않겠습니다. ※ 본 포스트는 어디까지나 개인적인 견해를 밝히는 글입니다. 딴지나 토론은 환영하지만 논리도 없는 논쟁이나 맹목적인 비난은 거절합니다.

본 포스트는 지난 2014년 5월 17일에 네이버 하드코딩하는사람들(이후 하코사) 카페에서 진행한 세미나에서 발표한 내용을 요약한 글로, 원 슬라이드는 http://seminar1405.publisher.name/ 에서 볼 수 있으며, 슬라이드에서는 내용을 충분히 이해하기 어려운 관계로 글로 풀어서 블로그에 재작성하였다.
아울러 해당 슬라이드를 글로 풀어내며 현 시점에서의 내 견해를 좀 더 덧붙였으며 글로 풀어쓰기 위해 약간 순서와 구성을 살짝 달리했다.

Prologue

무슨 일 하세요?
필자의 직업은 블로그 카테고리, 내용 들을 보면 대략 유추해볼 수 있듯이 "웹 퍼블리셔"다.
그리고 "웹 퍼블리셔"는 뭐냐? 물으면 Front-End 개발자 혹은 Front-End의 전반적인 부분을 다루는 개발자 정도로 표현을 한다.
그러나, 실제 이 분야에 몸을 담고 있는 이들의 많은 이들은 또 달리 생각하는 듯한 분위기인것 같다.
그리하여, 오늘은 이 "웹 퍼블리셔"가 과연 어떤 일을 하는 분야인지, 어떤 포지션인지를 재조명해보고자 이에 대한 이야기를 해 보고자 한다.

Who is Web Publisher

"웹 퍼블리셔"가 누구냐?
최근 이직을 하면서 면접 중에 들었던 이야기이기도 하고, 하코사에서도 많이 볼 수 있는 얘기로 디자이너와 개발자 사이에 끼어 다리 역할을 하는 직군 정도로 표현하는 케이스가 꽤나 많은 듯 하다.
웹 개발 프로세스 간에서는 디자이너와 개발자 사이에 있다는 것이 맞는 이야기이도 하나, 개인적으로 저 말을 굉장히 싫어한다.
물론 다리 역할을 하는 것은 맞다. 시각적으로 만들어낸 시안을 서버사이드 개발자가 개발을 붙이기 이전에 mark-up, css, javascript 등을 build 한다는 데에는 맞는 표현이나, 저 표현의 뉘앙스는 늘상 둘 사이에 낑겨서 손해를 보는 포지션이라는 느낌을 내포하고 있다는 생각을 지울 수가 없다.
어디까지나 publisher는 publisher 자체의 전문 포지션으로 존재한다.

web publisher === front-end developer

아는 사람은 다 알겠지만, "웹 퍼블리셔"라는 이름을 처음 쓴 것은 바로 신현석님이다.
"웹 퍼블리셔"를 어떤 의미로 만들었는지는 신현석님의 블로그에서 찾아볼 수가 있는데 핵심만 뽑아보면,

웹은 기본적으로 문서다. 그래서 문서나 책을 출판하는 퍼블리시(publish)라는 단어를 생각하게 되었고, … 중략 … 이 용어를 만들게 된 이유는 퍼블리싱이라는 업무가 기존의 포지션에서 벗어나서 보다 확실한 전문 영역으로 자리 잡기를 바랬기 때문이다.
웹퍼블리셔라는 말을 만든 이유
업계에 있는 많은 사람들은 웹 퍼블리셔를 예전의 HTML 코더와 동일하게 PSD를 웹 페이지로 옮겨내는 일을 하는 사람으로 인식하고 있다. … 중략 … 나는 클라이언트 사이드 개발자가 되고 싶었다. 그런데 에이전시 업계에서는 그런일 하는 사람이 없으니 이름을 붙여준 것 뿐이다. 요즘은 거꾸로 웹 퍼블리셔라는 말이 HTML 코더들에게 엔지니어로서의 마인드를 강요하게 된 것인가, 업계나 업계 종사자들은 그냥 HTML 코더를 원하는가 싶다.
프론트 엔드 엔지니어와 웹 퍼블리셔

이 정도로 정리해 볼 수 있겠다.
결국 "웹 퍼블리셔"라는 이름을 만든이의 의도는 클라이언트 사이드 개발자 즉, Front-End Developer 라는 거다.

그러나 안타깝게도, 현석님 블로그에도 써 있듯 업계에서 그 이름을 쓰고 있는 이들 스스로가 HTML 코더 정도로만 사용하고 있고 또한 그 이름을 쓰면서 그 이름의 의도와는 상관없이 스스로가 포지션을 축소시키고 퍼블리셔가 뭐냐 물으면 HTML 코더 정도로만 설명하는 이들도 꽤나 많은듯 하다.

JavaScript 퍼블리셔가 해야 하나요?

예전에 굉장히 많이 들었던 질문 중 하나였다. 지금은 그나마 이런 질문을 하는 케이스가 많이 줄어들고 있기는 하지만 여전히 간간히 들려오는 질문이다.

2년전에 하코사에 올렸던 “퍼블리셔의 범주 어디까지 보세요?” 라는 설문조사의 현재까지의 결과를 보면 전체 응답자 중 41.9%가 "웹 표준/ 접근성 준수해서 HTML / CSS 코딩 하는 직무" 항목을 선택했고, 46%가 "라이브러리등을 이용하여 사용자의 기능까지 제공하는 웹 UI 개발 직무"를 선택했다. 설문조사의 결과가 거의 2년 전에 대강 마무리 된 상태였기에 현재에도 유효한 결과라 보기에는 약간 무리가 있지만, 2년 새에 업계의 의식이 갑자기 크게 변했으리라고는 생각하지 않는다.

신현석님도 이런 질문을 많이 받아보셨었나보다. 현석님의 블로그 포스트를 둘러보다 보면,

"웹 퍼블리셔가 자바스크립트도 해야 하나요?",
"웹 퍼블리셔의 업무범위는 어디까지 인가요?"

커뮤니티에서 잊을만 하면 나오는 질문들이다. 추측해 보건데 질문 올린 사람의 의도는 다분히 방어적이다. "내가 이런것 까지도 해야 하는가?", "이 업무를 내가 해야 하는가?". 그리고 그 이면에는 "이런거는 잘 모르는데 어떻게 정당화 할 수 있는 수단이 없을까?"라는 생각이 깔려 있다.
그 안타까운 심정이 이해가 안가는 것은 아니지만 좀 더 발전적으로 자신을 바라봤으면 좋겠다는 생각이 든다.

… 중략 …

분명히 말하고 싶은 것은 우리 업계는 지금 클라이언트 개발자가 무엇보다도 필요하다. 아니 단순히 개발자가 아니라 전문가가 필요하다. 그 이름을 웹 퍼블리셔로 부르던 UI 개발자라고 부르던 웹 접근성 전문가라고 부르던 프론트 엔드 디벨로퍼라고 부르던 그건 중요하지 않다. 웹 브라우저를 잘 알고 HTML, CSS, 자바스크립트를 잘 알고, 웹표준과 웹접근성을 잘 알고, SEO나 기타 클라이언트 사이드 최적화를 잘 아는 그런 사람들이 필요하다. 다 잘하면 가장 좋고 최소한 이런 분야를 자신의 전문 분야로 키워나가려는 자세를 가진 사람이 필요하다.

웹 퍼블리셔의 업무범위

라고 포스팅 되어 있는 것을 볼 수 있다.
필자가 하고 싶은 이야기도 동일하다.
잘 모른다고, 잘 못한다고 하여서 내 업무 영역이 아닌 것은 아니다 라는 것이다.

내 생각에 현재 웹 퍼블리셔의 위기는 바로 여기에 있다.
웹 퍼블리셔라는 이름을 쓰고 있는 이들 스스로가 자신의 업무 영역을 축소시키고 또한 대내외적으로 웹 퍼블리셔를 자신이 축소시킨 그 업무 역할로 소개를 하고 있다라는 것이다.
이름을 만들고 그 이름에 의미를 부여한 이는 따로 있다. 그런데, 그 이름을 가져다 쓰는 이가 정작 그 이름의 의미는 버리고 자기가 취하고 싶은 – ‘뭔가 있어보이는’ – 이름만 취하고서는 그 의미를 자기가 다시 만들어다가 자신이 만든 정체성에 다시 가두고 있다라는 거다.
부탁이다. 그럴거면 웹 퍼블리셔라는 이름 말고 차라리 다른 이름을 만들어써라. 원래 의미를 마음대로 바꾸지 말고.

혹자는 이미 업계에서 받아들여지는 의미가 퍼블리셔는 HTML/CSS로, 프론트엔드 개발자는 거기에 + JS/jQuery 등으로 굳어져있기 때문에 업계에서 인식하는 의미를 사용해야 한다라고 이야기하는 이들도 있다. 하지만 필자는 그 의견에 대해서는 반대 입장이다.
이유의 첫째로는 이름의 의미를 만든 이의 의도때문이고 둘째는 업계가 인식하는 바는 충분히 그 이름을 쓰는 이들이 바꾸어 줄 수 있기 때문이다.
사실 업계가 퍼블리셔라는 직군의 의미를 그렇게 굳히게 된 데에는 퍼블리셔라는 이름을 쓰는 이들로부터의 영향이 가장 크다. 그들이 처음부터 퍼블리셔라는 이름의 의미를 프론트엔드 개발자로 가져갔으면 업계에서의 인식이 HTML/CSS를 하는 이로 굳어지는 일은 없었을 거라 생각한다.
전통적인 웹 제작 방식에서 벗어나지 못하고 그저 자기에게 어려운 일은 방어적으로만 대하다보니 이런 현상이 빚어지게 된게 아닌가 말이다. 결국 그 이름을 쓰는 이가 어떻게 쓰느냐에 따라 이름의 의미에 대한 인식은 충분히 바뀌어 질 수 있다.

Front-End Developer의 role

다시 돌아와서 그렇다면, Web Publisher === Front-End Developer라 한다면 Front-End Developer의 역할은 무엇인가? 라는 질문을 던지지 않을 수가 없다.
사실 Front-End Developer의 역할을 국내에서 딱 정리된 문서라든가 비슷한 무언가를 찾기는 어려웠다.
물론 Front-End의 전반을 다루는 개발자라고 하면 되겠지만 그것으로는 딱히 알기가 힘든 것은 또한 사실이다. 그래서, 해외의 사례들을 찾아봤다.
참고로… 원문은 다 영어이기 때문에… 필자가 직접 번역을… 쿨럭;;; (발번역 죄송 ㅠ_ㅠ)

Apple은 apple.com에 대한 사용자 경험의 혁신을 drive하기 위한 창조적인 프론트엔드 개발자를 찾습니다. HTML5, CSS3, JavaScript를 포함하는 프론트 엔드 기술을 위한 아키텍처 전략을 정의하고, 팀과 애플사 전체에 기술을 전파하는 일을 담당하게 됩니다.

  • 버전관리 시스템(SVN, Git 등) 사용 가능
  • 기본적인 비쥬얼과 인터랙티브 디자인 분야에 대한 이해
  • 의미있는 마크업과 CSS를 사용하여 웹 표준 준수 가능
  • 모든 메이저 브라우저에 대한 이해 및 크로스브라우징 이슈에 대한 이해
  • 혁신적인 인터랙션을 위해 라이브러리에 의존하지 않는 유능한 자바스크립트 프로그래머
  • JavaScript, HTML, CSS 간 상호작용을 알고, 동적으로 요소들을 생성/수정/스타일링 가능을 생성/수정/스타일링 가능
Jobs at Apple

우리는 현대적인 디자인 스타일과 기술의 어플리케이션과 HTML / CSS에 대해 뛰어난 지식을 가진 전문가 찾고 있습니다. 당신이 HTML5 기술 및 최근의 CSS3에 뛰어난 경험과 프론트엔드 웹 어플리케이션 설계에 진심어린 흥미를 가지고 있다면 우리에게 지원해주세요.

  • HTML5/xHTML에 능숙
  • CSS2.1/CSS3 마스터
  • 웹표준에 대한 이해
  • 최신 웹 기술과 반응형 웹 경험
  • 자바스크립트에 대한 기본 지식
HTML5/CSS3 Developer – uberVU
  • 폭 넓은 HTML5, CSS3, JavaScript 경험
  • Bootstrap, Less, Foundation 등을 이용한 반응형 레이아웃 지식
  • IE 8 이상에 대한 특별한 고려사항과 크로스브라우징의 대한 이해
  • SEO의 좋은 사례에 대한 높은 지식
  • SVN 사용에 대한 지식
Junior Front End Developer – nyjobguide

많지는 않지만, 몇몇 해외 업체들의 Front-End Developer직군에 대한 요구사항을 찾아 봤는데 위 내용들을 종합해보면 대략적인 업무 역할이 무엇인지 알 수 있지 않을까 싶다.
그리고 해외 업체의 Front-End 직군에 대한 요구사항을 찾다가 SMASHMAGAZINE, CSS-TRICKS의 집필자 중 한 명인 Chris Coyier가 CSS-TRICKS에 포스팅한 글 중에 웹 산업에 관련된 각 직군에 대한 설명한 글을 찾을 수 있었다.

이 직군은 HTML, CSS, JavaScript, light back-end 작업에 초점을 맞추고 있다. … 중략 … 기술적인 특정 직업명으로 "JavaScript Developer" 혹은 "JavaScript Engineer"같은 것이 적합할 수 있다.

Job Titles in the Web Industry – CSS TRICKS

퍼블리셔는 비전이 없다?

하코사에서 활동을 하다보면 간간히 진로에 관하여 상담을 요청하거나 질문게시판 게시판등에 올라오는 글들을 보면 웹 퍼블리셔에 과연 전망이 있느냐라는 글을 종종 보게 된다.
많은 경우 같이 일하는 개발자나 선임자들이 웹 퍼블리셔는 비전이 없으니 개발을 배워라라는 등의 얘기를 하더라는 글들을 종종 본다.
그럴 때 마다 내가 덧글로 다는 한마디는, 그 사람에게 웹 퍼블리셔가 비전이 없다는 근거를 대보라고 해라 이다.
적어도 내 생각에, 제대로 된 근거를 댈 수 있는 이는 없을거라 생각한다.

웹 퍼블리셔가 비전이 있느냐 라는 질문의 답은 "웹 퍼블리셔는 중요한가?" 라는 질문에 대한 답을 내릴 수 있다면 해결 된다라고 생각한다. 웹 퍼블리셔가 분명 중요하고 다른 직군이 대체 할 수 없는 포지션이라면 과연 이 직군이 미래가 없는 직군이겠냐라는 거다.

과거의 웹 제작 vs. 현재의 웹 제작

과거의 웹 제작은 사실 웹 디자이너 + server-side 개발자가 모든 부분을 다 담당했다 하더라도 과언이 아닐 거다.
두 직군이 모든 걸 다 맡아서 하다 보니 front-end에 관한 부분을 서로 나누어 가져다가 함으로인해 mark-up, css는 웹 디자이너가, javascript등의 프로그래밍이 필요한 부분은 server-side 개발자가 담당했던 것이 과거의 웹 제작 방식이다.

뭐, 당시에는 Front-End에 대한 전문성 필요가 거의 존재하지 않았고 특히나 다양한 브라우저를 사용하기보다는 IE 하나에만 대응하는 경우가 대다수였다. 그러다보니 굳이 웹 퍼블리셔라는 직군 자체가 그다지 필요하지 않았을 거다.

그러나, 현재에 와서 Front-End에 대한 전문성을 가진 직군에 대한 필요가 점차 증가하기 시작했다. 브라우저가 다양해지고 여러가지 Front-End에 대한 기술이 필요해지게 됨에 따라 더 이상 과거의 웹 제작 방식으로는 충분히 대응하기가 쉽지 않게 된것이다.

결국 웹 디자이너, server-side 개발자, Front-End 개발자 3개의 직군으로 좀 더 세분화 되어지고 웹 디자이너는 웹 디자인 작업에 좀 더 집중하고 server-side 개발자는 server-side에, Front-End 개발자는 Front-End에 집중하여 웹을 제작할 수 있게 된 것이다.

크로스브라우징 이슈

퍼블리셔의 필요성이 가장 대두가 된 것중의 하나는 바로 "웹 표준 이슈"와 그로인해 발생 된 "크로스브라우징 이슈" 일 것이다.
필자가 "웹 표준"을 처음 접한게 2008년이었던 것으로 기억한다. 지금 돌아보면 사실 그 때에는 웹 표준이 무언지도 제대로 모르면서 그 말을 가져다 쓰곤 했지만 이후 메가존에서 퍼블리셔로 SK Enclean 쪽에 파견으로 와 계셨던 "임형"을 만나면서 이런 저런 얘기들을 나누고 듣고, 또 "제프리 젤드만의 웹표준 가이드"라는 책을 접하면서 더 웹 표준에 대한 관심이 커졌던 것으로 기억을 한다.
에고… 잠시 엉뚱한데로 샜는데 ;; 무튼, 이 웹 표준이 대두가 되어지면서 동시에 브라우저의 다양성이 국내에서 드디어 이슈화 되기 시작했던 것으로 기억한다. 내 기억이 맞다면… 아마 그 즈음에 크롬 브라우저가 국내에 등장했었던 것으로 안다.

무튼, 이 크로스브라우징에 관한 이슈는 과연 누가 가장 잘 알고 이해하며 잘 해결할 수 있을까?
웹 디자이너? Front-End 개발자? server-side 개발자?
단순히 렌더링에 관한 부분만을 이야기 하는 것이 아니다. 각 브라우저별 렌더링 차이 뿐 아니라 javascript의 동작 의 차이까지를 다 담당할 수 있는 직군은 과연 어디일까?

과연 웹 디자이너나 혹은 server-side 개발자가 본연의 업무 외 이 문제까지도 과연 무리없이 트러블 슈팅을 할 수 있는가 라는 문제이다.

웹 접근성 이슈

지난 4월 11일. "장애인 차별 금지 및 권리구제에 관한 법률(이하 장차법)"이 모든 법인에 확대가 되어짐에 따라 큰 이슈가 되었던 부분 중 하나이다.
"웹 접근성"을 제공하기 위한 기술, 방법의 대다수는 Front-End 개발에 매우 밀접하게 연관되어 있었다. 그 때문인지 사실 웹 접근성에 대해 관심을 가지고 더 나은 접근성을 제공하기 위한 방법들을 모색하는 것은 웹 퍼블리셔 외에는 많지 않은 것 같기도 하다.
실질적으로 사용자와 맞닿게 되는 부분을 만들게 되는게 퍼블리셔다. 그리고 접근성이 필요한 부분 또한 바로 이 사용자와 맞닿게 되는 부분이다. 그렇다면, 과연 이 접근성에 관한 이슈는 퍼블리셔외 누가 잘 담당하고 관리할 수 있을까?

SEO, semantic 등의 이슈들

Front-End에 관련하여 또한 필요시 되는 부분 중 두 가지는 SEO(Search Engine Optimization)와 Semantic 이다.
SEO란 것은 검색엔진최적화 즉, 검색엔진 혹은 크롤러가 웹 페이지에 접근하여 문서의 내용을 쉽게 수집하고 색인을 할 수 있도록 하는 것을 말한다. (여기저기 네이버 IT 용어 사전이라든가 Wiki 에는 검색엔진 상위 노출시키는 방법이라고 나와있지만 Google 검색팀으로부터 들은 이야기는 이는 SEO에 대한 오해다 라는 이야기를 들었다.)
SEO는 결국 mark-up과 매우 밀접하게 연관되어진다.
또한 Semantic의 문제. Sematic은 의미론적으로 용도에 맞도록 mark-up을 작성하자는 것인데, 이를 위해서는 문서 내용의 흐름을 파악·이해해야 하고 이를 바탕으로 용도에 맞는 elements를 선택하여 mark-up 및 문서를 구조화 해야 한다.

웹 퍼블리셔는 중요한가?

앞서 말한 내용 외 또 다른 이슈들로 performance 라던가, 웹사이트 최적화, lazy load, 각종 Front-End에 관련된 기법들도 있을 것이다.
웹 퍼블리셔는 중요한가? 중요하지 않은가?
짤막하게 예로 들은 몇 가지 이슈들만 가지고 봤을 때, 과연 웹 퍼블리셔가 해야 하는 일들을 다른 직군이 대체 할 수 있을까?
적어도 내 생각에는 100% 불가는 아닐지라도 대체는 어렵다라는 결론을 가진다.

요새는 툴이 잘 나오는데요?

그렇다. 종종 이런 얘기를 하는 이들이 있다. 요새는 툴 – Adobe Dreamweaver 라든가 Readbean 같은… – 이 잘 나오기 때문에 웹 퍼블리셔가 딱히 필요하지 않게 될 수 있지 않느냐 라는 반문을 종종 한다.
그렇다면 필자는 한 가지 질문을 다시 던져보고 싶다.
툴이 전문성을 대체할 수 있는가? 라는 것이다.

영상편집툴 캡쳐사진
이 화면은 영상편집 툴을 캡쳐한 그림이다. 윈도우미디어플레이어, 베가스, 프리미어. 아마 영상 편집을 해 본 경험이 있는 이라면 한 번쯤은 다 만져봤을 만한 툴이다.
UCC가 유행하던 시절에 필자도 역시 그 흐름에 합류하여(?) 영상을 찍고 편집하기를 제법 많이 했다.
영상 편집을 한 번도 해본적이 없었음에도 불구하고 영상 편집툴이 워낙에 잘 나와줘있어서 너무 손쉽게 영상편집을 할 수 있었고 비단 필자 뿐 아니라 수 많은 이들이 집에서 간단하게 영상을 만들고 편집할 수 있었다.
그럼 이 툴이 있음으로 인해서 영상 제작(편집)자들이 사라졌는가? 혹은 영상 제작(편집)자들이 밥벌이가 어려워 졌는가 하는 것이다.
적어도 내가 아는 한 그렇지 않다.

그렇다면 왜 그런 것이냐? 그것에 대한 답이 바로 "전문성"이다. 아무리 툴이 잘 나온다고 하여서 그 툴이 "전문성"을 따라 잡을 수는 없다.
영상 편집툴이 잘 나온다고 하여도 그걸 사용하는 이가 아마추어면 그 정도의 퀄리티밖에 나오지를 못한다. 반면 프로가 그 툴을 이용하게 되면 그만큼 생산성이 높아지고 결과물은 아마추어의 것과는 당연 차이가 날 수 밖에 없다.
그것이 프로와 아마추어의 차이다.

웹 퍼블리싱도 마찬가지다. 아무리 툴이 잘 나온다하여도 그 툴을 사용하는 이가 전문적이지 못하다면 결과물의 퀄리티는 그 만큼 밖에 나오지 못한다.
아무리 툴이 잘 나온다고 하여도 툴이 인공지능을 달지 않는 한 Semantic은 제공할 수 없으며, 툴 자체가 접근성을 충분히 제공할 수는 없다.
물론, 단순하게 HTML / CSS 정도만 하는 웹 퍼블리셔라면 그 자리는 툴이 대체할 수 있겠다.

웹 기술의 영역 확장

웹 퍼블리셔의 전망을 이야기 할 때, 빼 놓을 수 없는 부분이 바로 이 "웹 기술의 영역이 확장되고 있다."라는 부분인것 같다.
W3C에서 공식배포하고 있는 HTML5 스티커 중 하나를 보면 I’ve seen the future. It’s in my browser 라는 문구가 있다.

미래가 내 브라우저 안에 있다라는 것.

예를 들자면, EPUB3 를 이용한 전자책. EPUB3는 HTML5, CSS, JavaScript로 구성이 된다.
또는 LG Smart TV의 UI. 이 역시 웹 기술로 구현이 되어져 있으며 이런 Smart TV와 관련하여 W3C에서 현재 WEB and TV 라는 Interest group 활동이 진행되어지고 있다.
국민네비 김기사! 이것 역시 현재 HTML버전으로 만들어지고 있는 중이다. 네비게이션이 HTML로 구현이 된다니!!!!!
또, 오비고라는 업체에서는 HTML5 기술을 이용하여 차량 인포테인먼트 시스템의 공조시스템을 만들어냈다. 웹 기술은 이미 자동차에까지 들어와 있다.

무슨 말이냐. HTML5를 기반으로 융합되어지고 있는 기술들이 꽤 많다라는 것이다.
그리고 그것은 웹에 종사하고 있는 직군들에게 있어서는 계속해서 할 수 있는 분야가 늘어난다라는 것이다.

마치며…

제프리 젤드만은 자기 블로그에서 이런 말을 남겼다.
Wisdom is not a job, but it is always an assetIt’s 2014. is web design dead?, Jeffrey Zeldman
Front-End 개발자가 가진 지식은 웹이라는 플랫폼 위에서 사용자와 직접적으로 맞닿는 Front-Edn를 개발하는 자산이다.
이를 활용하고 하지 않고는 스스로에게 달려있는 것이다.
웹 퍼블리셔가 시야를 조금만 넓혀보면 갈 곳은 무궁무진하다. 이는 퍼블리셔가 앞으로 나아갈 방향이 많다라는 것이고, 곧 퍼블리셔의 전망은 결코 나쁘지 않다라는 반증이기도하다.
물론, 그러기 위해서는 끊임없는 자기 계발과 노력이 필요하겠지만 말이다.

"웹 퍼블리셔"라는 이름을 만든 신현석님의 블로그에 보면 다음과 같은 글이 있다.

활 시위는 당겨졌다.
어느 쪽에 있던 사람이 쏘아지는 화살을 타고 날아갈지는 모른다. 명칭이야 뭐라 불리웠던 그 조직이나 업계의 관행을 따라갈 수 밖에 없다.
다만 다들 본인이 그 중심에 서기 위해서 노력했으면 좋겠다. 나 자신도 그럴 것이다.

프론트 엔드 엔지니어와 웹 퍼블리셔, 신현석

어쩌면 몸 담고 있는 회사의 현실이나 업계의 관행에 따라 Front-End 전문인보다 그냥 주구장창 HTML / CSS만 만지고 있게 될지도 모른다.
때로는 접근성? 퍼포먼스? 그런건 개나 줘버리고 그냥 무조건 빨리 만들기나 해라는 상황에 있을지도 모른다.
그러나 그렇다 하더라도 웹 퍼블리셔 그 이름 값을 하기 위해 노력했으면 좋겠다.

이어령 교수님의 "흔들리는 영혼을 위한 청춘의 인문학"이라는 책에 보면 직장인에 대해 "프로와 포로"가 있다고 얘기 한다.
이 글을 읽고 있는 당신은 프로가 되고 싶은가? 아니면 포로가 되고 싶은가? 기왕 일 하는 거라면 포로보다는 프로가 되었으면 하는 바람이다.

Authored By 멀더끙