Clearboth document:job

Sat, 10 Jul 2010 18:23:19 +0900

by Wise 어느덧 웹표준 코딩 실무를 한지 1년의 시간이 흘렀습니다. 많은 분들이 종종 저에게 “경력이 1년 같지는 않다”는 말씀을 해주십니다. 더 열심히 하라는 말씀도 많이 해주십니다. 이런 분들에게 모두 진심으로 감사드립니다.

요 즘 가면 갈수록 드는 저의 생각은 1년을 그 누구보다 열심히 했다고 생각을 했지만 대체 무엇을 한 걸까?? 기본도 안 된거 같다는 느낌을 많이 받습니다. “저와 같은 고민을 하는 사람이 있겠구나.”라는 생각에 이곳에 글로 옮기고 있습니다.

모 직업학교를 나오면서 그 당시에는 술 먹고 놀면서도 집에 도착하면 새벽 2시까지는 공부를 혼자 했었습니다. 주말 하루를 제외 하고는 4시간 이상을 자본 기억이 없습니다. 작년 7월초 두 회사에 면접을 보고 나서 두 회사에 다 합격은 하였습니다. 그 중 한 회사에 입사하면서 주 업무(코딩)을 시작했습니다. 그 당시에는 SI업체가 무슨 일을 하는지도 솔직히 모르고 들어왔습니다. 나이도 있었고 많은 회사를 고를 입장은 아니었다고 스스로 생각했습니다.

입사하자마자 교육도 없이 웹 접근성 프로젝트에 바로 투입이 되었습니다. 학교에서 아무리 잘해도 실무에서 배우는 부분과는 정말 천지차이라고 많이 느꼈습니다. 이 때 스터디 그룹이 있을 거라는 생각을 못 했습니다.

크로스브라우징도 잘 못하던 시절, 거기에 접근성에 맞는 부분들까지, 운이 좋게도 시작부터 많은 것을 배울수 있었고, 결과도 잘 나왔습니다. 하지만 그 결과가 그 당시의 저에겐 전부라고 생각했었습니다. (지금 생각해보면 이때의 시간이 제일 아깝다고 느낍니다.)

그로부터 저의 코딩 생활에 전환점이 발생했습니다. 한 친구를 통해 작년 12월 12일 “ 웹 개발자를 위한 스크린 리더 이해 그리고 웹 접근성“ 이란 세미나를 듣게 되었습니다. 스크린리더기의 사용법까지 잘 들으면서 많은 부분이 제 가슴에 요동을 쳤습니다. 스크린리더기도 처음 봤지만, “정말 이렇게 사용되는구나.”라고 느꼈습니다. 그 전까지만 해도 웹 접근성 심사에 점수가 중요했고 웹접근성 품질마크획득이 회사의 사업 목표라 그렇게만 받아 들였었던 것 같습니다. 하지만 그게 다가 아니라는 느낌을 처음 접하게 되었던 날이었습니다.

그날로 인하여 저에게는 많은 변화들이 발생했습니다. 스터디를 일주일에 금요일, 토요일 포함하여 3개를 유지하며 시간이 될 경우 갈 수 있는 세미나에 동참하게 되었습니다. 그러다 네 번째 표준의 날 경진대회가 있었습니다. 그 때를 계기로 새롭게 느끼는 것들이 많습니다.

결국 1년동안 코더로 불리건, 퍼블리셔로 불리건, UI개발자로 불리건 호칭이 중요한 것이 아니었습니다. 저는 HTML과 CSS와 자바스크립트를 다루는 사람입니다.

그런데도 HTML 4.0, XHTML 1.0, XML 1.0에 관한 많은 표준문서들이 존재 합니다. 처음부터 끝까지 읽은 것이 겨우 HTML 4.01¹⁾정도와 XHTML 1.0 조금 이었습니다. 이 부분도 깊게 마스터 한 것이 아닙니다.

이글을 쓰면서 신입 코더의 1년생활을 돌아보았습니다. 시간은 참 빠르게 지나간 것 같습니다. 그에 비하여 실력은 많이 부족하다고 느낍니다. 저는 HTML과 CSS와 자바스크립트를 잘 다루는 사람이 되고 싶습니다.

이 글을 읽으신 분에게 꼭 권하고 싶은 부분이 있습니다. 모두 지금까지 어떻게 자신이 왔나를 한번씩 돌아보시는 기회가 되셨으면 좋겠습니다.

저는 그 기회를 잘 잡기 위해서 이제서야 HTML 4.0 부터 제대로 시작하려 합니다.

코딩, 마크업, 웹퍼블리셔, 신입, webpublisher

¹⁾ 한글로 번역된 명세서를 클리어보스에서 제공하고 있습니다.

웹퍼블리셔도 문서를 만든다

Tue, 29 Jun 2010 14:45:41 +0900

by 추지호 웹퍼블리셔 또는 마크업 개발자/UI 개발을 담당하고 있는 사람(이하 웹퍼블리셔)들에게 꼭 필요한 기술이 한가지 있다면 바로 문서화가 아닐까 싶다. Trac과 같은 훌륭한 프로젝트 관리툴이 있고, 이를 이용하면 별도의 문서화가 필요없을 정도로 내부의 위키와 이슈트래킹 등이 훌륭하게 지원되지만 Trac은 협업(Co-work)을 위한 시스템으로, 개인 단위에서 문서화를 할 목적이라면 부담되는 것일 수 있다. 그래서 내가 하고 있는 문서화 방법을 공유해 보고자 한다. Trac과 같은 별도의 시스템을 사용하지 않고, 위키( 스프링노트)와 메모장을 이용하는 비교적 간단한 방법이다.

내가 생각하는 웹퍼블리셔의 문서화는 다음 3가지 문서를 통해서 이루어진다.

Markup Guide

기획 단계에서 작성 가능한 문서로 프로젝트의 간단한 개요와 HTML 문서의 DTD, Encoding, Meta 정보, 주석 처리 방식, 웹접근성과 웹표준화 적용 범위 등을 설정할 수 있다. 또한, 디렉토리 구조와 파일 네이밍 규칙, CSS 운용 방법, 기획 단계에서 요구되는 자바스크립트의 종류와 적용 범위 등도 함께 예측하거나 정리해 볼 수 있다. 이 문서는 프로젝트 발주자에게 제안되어 웹접근성과 웹표준의 범위를 결정하는데 도움이 되고, 개발자와 사전에 내용적 합의를 이끌 수 있는 문서다. 최초에 한번 작성해 두면 이 후 프로젝트에서는 몇가지 사항만 수정하면서 유지할 수 있다

Issue Tracking

프로젝트 진행 중에 작성 가능한 문서로 각종 버그나 협업간 발생하는 이슈들을 기록한다. 프로젝트 진행중에는 시간을 갖고 문서를 작성하기가 여의치 않을 때가 많다. 때문에 짧고, 간단하게 기록하는 방식이 좋다. 메모장을 이용하여 날짜별로 파일을 저장해 두거나, 오픈마루의 레몬펜, 구글 노트를 이용하는 방법도 있다. 'issue_날짜_번호'로 제목을 만들고, txt 파일일 경우에 issue_080802_01.txt와 같이 만들면 되겠다. 내용은 '날짜_번호'로 이루어진 고유 번호와 1. 이슈내용, 2. 수정내용, 3. 요청 및 기타사항 을 적는다. 메모장으로 기록한 경우에는 프로젝트 종료 후 별도의 위키사이트나 스프링노트 등에 종합하여 정리하는 것이 보관하기 용이하다.

Publishing Report

프로젝트 종료 또는 웹사이트 오픈 직후에 작성 가능한 문서다. 어떤 프로젝트이건 기획 문서대로 완성되는 경우는 거의 없다. 때문에 Markup Guide를 작성하고, 개발자와 합의를 이끌었다고 하더라도 결과물에서는 제대로 반영되지 않았거나, 무시되는 경우가 많다. 이러한 사실을 기록하는 문서가 최종 Publishing Report다. 또한, 이 문서에서는 html, css, js등 파일수와 용량, 플래시나 동영상, 이미지 등의 정보를 수치로 기록하여, 정량화하여 사이트의 퍼포먼스 측정의 객관적인 자료가 될 수 있도록 한다. 아울러 HTML, CSS Validation을 실시한 결과 등을 포함하여, 스스로 웹표준화 정도를 측정하고 다음 프로젝트를 준비하는데 필요한 자료로 삼는다.

이 밖에도 웹접근성 향상을 위해서 주로 적용되는 'Cross Browsing'이나 각종 웹표준화 작업 이슈들을 문서화 해두면 프로젝트 진행에 도움이 되며, 협업간의 의사소통의 어려움을 극복하는데 힘이 된다. 이를테면 웹표준에 대한 인식이 부족한 기획자나 디자이너를 설득하기 위해서 침이 마르도록 설명을 해본들 잘 먹혀들지를 않는다. 하지만 구체적으로 보여줄 수 있는 문서가 있고, 결과물이 있다면 사정을 달라질 수 있다. 문서화는 웹퍼블리셔로 하여금 자신의 노하우를 축적하는 방법이기도 하면서 동시에 훌륭한 커뮤니케이션 수단으로써 이용될 수도 있는 것이다.

위에서 내가 적용해 보고 있는 3가지 문서와 방법을 간단히 소개했지만 특별히 검증된 것도 아니고, 반드시 좋은 것은 더더욱 아니다. NHN의 웹표준화팀이 운영하는 NULI에 보면 마크업과 CSS, 접근성 이슈들이 상세히 정리되고 유지되고 있는 것을 볼 수 있는데 문서화의 좋은 예라 할 수 있을것 같다. 회사와 개인마다 조금씩 가이드가 다를 수 있고, 프로세스와 스타일이 다를 수 있기 때문에 꼭 남의 것을 따르기 보다 참조하여 자신의 것을 만들어 가는 것이 더 좋을 것이라는 생각도 해본다.

css, html, markup, webpublisher, 마크업, 문서화, 웹퍼블리셔, 웹표준, 웹표준화

Read or add comments to this article

어떤 직함이 좋은가?

Tue, 02 Mar 2010 00:18:11 +0900

HTML과 CSS를 주로 다루면서 웹 사이트의 사용자 화면을 설계하는 사람들을 주로 웹 퍼블리셔라고 합니다. 과거에는 HTML 코더나 하드 코더, 핸드 코더라고도 불렸구요. 포털이나 게임사같은 경우에는 UI개발자라고도 합니다. 혹은 마크업 개발자나 HTML 개발자라고 부르는 사람들도 있습니다. ASP, JSP와 같은 서버측 언어를 다루는 전통적인 웹 개발자를 서버 사이드 개발자라고 하여 반대로 클라이언트 사이드 개발자 또는 프론트 앤드 개발자(백 앤드 개발자의 반대어)라고도 합니다.

디자이너냐 개발자냐라는 고리타분한 논쟁에서부터 코더냐 웹퍼블리셔냐라는 최근의 고민까지 우리는 우리들 스스로의 정체성을 확립하기까지 너무 많은 에너지를 쏟고 있습니다. 하지만 불려지는 이름이 다양할 뿐 사실은 모두 공통된 업무를 하고 있는 것이지요. 회사와 정책에 따라 직무 범위가 조금씩 다를 뿐인 것입니다. 그럼에도 사람 마음이란 것이 참 가벼워서 어느 것 하나로 결정되기를 바라나 봅니다.

2010년 첫번째 설문 주제로 'HTML, CSS, JS등을 주로 다루면서 사용자 화면을 설계하는 당신은 어떤 직함이 가장 좋습니까?' 라는 질문을 던져 보겠습니다.

jobtitle

HTML, CSS, JS등을 주로 다루면서 사용자 화면을 설계하는 당신은 어떤 직함이 가장 좋습니까?

아울러 직함과 관련하여 여러분의 다양한 의견도 부탁드립니다. 어떤 이름은 좋다. 나쁘다라는 의견도 좋고, 그 의미나 해석도 좋습니다. 설문의 목적이 1위 직함으로 몰아가자!는 결코 아니지만 불려지는 이름이 곧 우리가 하고 있는 일을 대변하고 있다고 생각합니다. 직함만 보고도 아 그런 일을 하는 사람이구나. 훌륭한 일을 하고 계십니다라는 이야기를 듣고 싶은게 욕심은 아닐테니까요. 많은 의견 남겨 주시면 감사하겠습니다.

다른 설문조사

설문조사, 웹퍼블리셔, 웹디자이너, 웹개발자, HTML코더, UI개발자, 마크업개발자, HTML개발자, 클라이언트 사이드 개발자, 프론트 앤드 개발자

Read or add comments to this article

마크업 개발 7단계, 웹퍼블리셔는 할 일도 많군

Tue, 29 Jun 2010 14:45:32 +0900

by 추지호 웹퍼블리셔(Web Publisher)는 웹사이트를 제작함에 있어서 어느 정도의 역량을 가져야 하며, 어디까지가 우리의 역할일까? HTML 중심의 이러한 개발 및 디자인 작업을 하면서 항상 갖게 되는 질문이고 속 시원하게 대답이 나오지 않는 질문이기도 하다.

다음은 나름의 경험과 고민을 통해서 정리한 것으로 개인마다 의견이 다를 수 있다. 조금 더 경력이 쌓이면 달라질 수도 있겠지만 우선은 다음과 같은 일곱 단계의 과정을 웹퍼블리셔가 할 수 있는 업무의 범위라고 생각하고 간략히 정리해 보겠다. (편의상 단계라는 표현을 썼지만 반드시 지켜져야 하는 순서는 아닙니다.)

1단계 - 환경분석과 시스템배치

기획 단계에서 프로젝트에 대한 환경적인 분석을 실시한다. 여기서 환경이라 함은 사이트가 운영 및 유지되는 서버와 서버 사이드 개발 인력의 수, 역량 등을 의미한다. 사용된 웹서버와 데이터베이스 서버는 무엇인가? 인코딩을 무엇을 할 것이며, HTML 문서의 가장 중요한 DTD 정의는 무엇으로 할 것인가? 스크립트를 구현함에 있어서 서버 사이드 개발자와 어디까지를 공유할 것인가? 디렉토리는 어떻게 구성하며 이미지 서버는 별도로 둘 것인가? 크로스 브라우징은 어디까지 지원할 것인가? 주요 접근성 이슈를 어떻게 확보할 것인가?와 같은 프로젝트 도입 이전에 고려될 수 있는 여러가지 시스템적 인적 환경을 조사하고 마크업 개발에 필요한 조건들을 기획자에게 제안하여 스토리보드에 반영될 수 있도록 한다. 특히 웹접근성 확보를 위한 고민은 디자이너와 서버 사이드 개발자의 역량에 따라서 적용 가능한 범위가 제한될 수 있으므로 충분히 논의가 될 필요가 있다. (논의 없이 웹퍼블리셔가 이러 이러한 웹접근성 이슈를 처리하자라고 문서화 해봤자 서버 사이드 개발자들은 웹퍼블리셔가 혼자서 다 할 수 있는 것들로 오해해 버리는 경우가 종종 있다.)

2단계 - 구조적 설계(HTML Design)

기획자로부터 기획문서(스토리보드)가 만들어지면 이를 바탕으로 HTML 문서를 작성한다. 이 때의 HTML 문서는 디자인이 적용되지 않은 상태이며 사이트의 가장 기초적인 골격의 형태(내용의 선형성을 유지하면서 접근성이 확보되어야 한다.)를 가진다. 완성된 HTML을 통해서 사이트 네비게이션과 프로세스를 체크하여 문제점을 보완한다. 이는 사이트의 가장 기본적인 프로토타입이 될 수 있으며, 이 단계에서 발견된 문제점은 보다 빠르고 쉽게 수정될 수 있다.

3단계 - 스타일시트 설계(CSS Design)

디자이너에 의해 디자인이 완료(또는 단계적 완료)되면 HTML 문서 위에 스타일을 작성하여 적용하기 시작한다. 둘 이상의 웹퍼블리셔가 함께 작업한다면 시니어가 마스터 CSS를 설계하고, 주니어가 이를 통해 작업을 진행할 수 있도록 한다.

4단계 - 스크립트 개발(Script Development)

스토리보드를 통해서 전체적인 프로세스를 확인하고 서버사이드 연동 없이 구현 가능한 '동작(behavior)'요소를 확인하여 목록화 한다. 3단계 이전에 가능한 스크립트를 구분하여 미리 작성하거나 필요한 스크립트를 준비해 두면 후반 작업의 수고를 덜어줄 수 있다. 사이트의 규모가 제법 크거나 스크립트의 사용이 많은 경우 jQuery와 같은 라이브러리를 이용하는 것도 좋다. 단, 이같은 라이브러리 사용시 서버 사이드 개발자와 합의를 해 두는 것이 좋다. 때때로 prototype.js와 jQuery가 함께 뒤섞인 사이트가 오픈되기도 하기 때문이다. 이는 매우 비효율적인 짓이다.

5단계 - 테스트, 유효성 검사(Test And Validation Check)

테스트는 사이트 네비게이션과 링크 요소의 값이 정상인지를 확인하는 과정으로, 서버 사이드 개발이 이루어지지 않은 환경에서도 적절한 링크를 따르고 있어야 한다. 특히 게시판의 리스트, 뷰, 쓰기 화면의 링크를 생략하거나 데드 링크를 수정하지 않고 그대로 서버 사이드 개발로 넘기는 경우가 많은데 협업간의 편의를 위해서라도 깔끔하게 처리하자. 유효성 검사는 HTML과 CSS에 대한 문법적 검사로 페이지 단위로 이루어진다. Firefox의 확장기능인 HTML Validator를 이용하거나 Dreamweaver의 유효성 체크를 이용하면 검사 시간을 절약할 수 있다. 단, HTML Validator나 Dreamweaver의 기능이 W3C의 유효성 검사와 같지 않을 수 있으므로 메인 페이지나 주요 페이지의 경우 별도의 W3C 유효성 검사를 실시한다.

6단계 - 웹접근성 검사

완성된 사이트(서버 사이드 개발 완료)가 웹접근성을 충분히 확보하고 있는지 확인한다. 서버 사이드 개발자에 의해 HTML과 CSS, Script의 문법이 표준을 따르지 않게 되거나, 접근성을 제한하는 경우가 확인된다면 피드백을 통해서 수정할 수 있도록 한다. 웹접근성 검사는 KADO의 WAH를 이용할 수 있다.

7단계 - 문서화

일련의 과정을 통해서 문서를 남기는 작업은 그 무엇보다 중요하다. 1단계 기획단계에서 시스템을 분석하고 웹접근성 확보와 표준화 레벨을 결정함에 있어서 조사하고 결정된 사항들을 문서로 만들어 기초 가이드로 설정할 수 있다. 2~6단계에 이르는 동안 협업간의 여러가지 이슈가 발생할 수 있고 이를 이슈리스트(가칭)로 정리를 해 둔다면 차후 프로젝트를 진행함에 있어서 실수와 오류를 줄일 수 있다. 최종적으로 사이트가 오픈이 되면 주요 페이지의 W3C 유효성 검사와 웹접근성 검사등을 실시한 결과를 문서화 하여 유지보수 또는 차후 리뉴얼의 참고문서가 되도록 한다.

css, html, html개발, script, web publisher, 마크업개발, 문서화, 웹접근성, 웹퍼블리셔, 웹표준

Read or add comments to this article

웹퍼블리셔 평균 연봉

Fri, 01 Jan 2010 23:56:44 +0900

Read or add comments to this article

2008년 웹 퍼블리셔 연봉 조사

Sat, 02 Jan 2010 22:57:42 +0900

지난 9월 26일부터 약 한달간 하드코딩하는사람들를 통해서 웹퍼블리셔들의 연봉 조사를 해봤었습니다. 하코사 공식 설문은 아니었고 제가 게시판을 통해서 실시했던 것으로 대략적인 정보만 공유해 보고자 실시된 설문입니다. 때문에 이번 결과를 인용하거나 자신의 연봉협상에 절대적인 기준 자료로 삼는 것은 자제하시고 간단히 참고만 하셨으면 합니다.

프리랜서의 경우 정규직과 다소 차이가 나는 페이를 지급 받는 경우가 많아서 설문 불참을 권유했습니다.(그럼에도 참여했을 수도 있습니다.) 연봉 산정 기간은 08년 올해 받고 있는 연봉을 기준으로 했습니다.

총 스물 일곱분이 투표를 해 주셨고, 연봉 2000만원 미만이 16명으로 가장 많은 것으로 나타났습니다. 한 분이 4000만원 이상을 선택해 주셨는데 실수로 선택하시지 않았나 싶습니다. (아니라면?)

2,3년 차 경력을 가지신 분들은 총 열 여섯분이 참여해 주셨구요. 2500~3000만원 사이의 연봉이 여덟분으로 가장 많았네요. 2000~2500만원 사이도 다섯분으로 나타났습니다.

경력 4년 차 이상이신 분들은 총 열 일곱분이 참여를 해주셨습니다. 3000~4000만원 사이의 연봉을 받으시는 분들이 아홉분을 가장 많이 나타났습니다.

총 육십분께서 이번 연봉 조사 설문에 참여를 해 주셨는데요. 특별히 코멘트 할만한 사항이 있지는 않지만 설문 참여율에 있어서 1년차 경력을 가지신 분들이 유독 많았고, 연봉에 대한 관심도 가장 높았습니다. 최근에 웹퍼블리셔로 진로를 결정하거나 웹개발 또는 웹디자인에서 전향하는 케이스가 늘고 있는데 그런 부분을 무시할 수는 없을 것 같습니다.

개인적으로는 4년차 이상에서 연봉 5000만원 이상을 받는 분이 계셔서 용감하게 클릭을 해 주셨으면 하고 바랬는데 한분도 용기를 내지 않으셔서 조금 아쉽네요.

몇 년 전만 해도 HTML코더라는 이름으로 계약직과 아르바이트로 몇 몇 회사를 돌아다닐때 받던 월급이 월 80~90만원이었던 것을 생각해보면 근래에 이 직군에 대한 인식이 조금은 나아지고 있구나 싶습니다. 하지만 웹에이젼시를 비롯한 이쪽 산업군이 전반적으로 연봉 테이블이 높지 않기 때문에 개인의 역량 계발이 크게 이루어지지 않는다면 (그리고 경제가 계속 좋지 않게 된다면…) 전체적인 연봉 상승이 쉽게 이루어지지는 않을것 같다는 생각이 드네요.

개인적인 생각이지만 웹퍼블리셔라는 직업을 선택한 많은 분들이 대부분 돈 보다는 이 일에 대한 비전과 재미, 그리고 열정 때문에 시작한 경우가 많다고 봅니다. 저 역시 한 때는 HTML 코더로 어떻게 먹고 살까 고민하면서 포기하려고도 했지만 역시나 이 일이 제게는 가장 재미있는 일이라고 생각했고 앞으로도 계속 할 생각입니다. 그렇지만 노력에 상응하는 댓가가 없다면 그 역시 현실 앞에서 스스로를 좌초시키는 계기가 되곤 하죠. 좋은 회사에서 자신의 능력을 충분히 발휘하고 그만한 댓가를 받는 것. 모든 분들이 그렇게 되기를 바라겠습니다.

노파심에 다시 한번 말씀드리지만 제대로된 조사가 아니기 때문에 개인적으로 참고만 하시길 바라겠습니다.

설문조사, 웹퍼블리셔, web publisher, 연봉

Read or add comments to this article

2009년 웹 퍼블리셔 연봉 조사

Thu, 07 Jan 2010 21:47:07 +0900

2009년 12월 20일부터 12월 31일까지 진행된 2009년 웹퍼블리셔 연봉 조사 설문 결과입니다. 설문에 참여해 주신 모든 분들께 감사드립니다.

이 설문은 많은 웹 퍼블리셔들이 자신의 연봉 수준이 적절한지에 대한 궁금함이 많았고, 이를 조금이나마 풀어줄 수 있을까 하여 클리어보스에서 실시한 것입니다. 공신력은 갖지 않으므로 공식적인 문서는 물론이거니와 가급적 인용을 삼가해 주셨으면 합니다.

이번 설문조사에 참여해 주신 분은 총 115명이며, 최소 연봉자는 1,200만원, 최대 연봉자는 5,800만원, 평균 연봉은 2,600만원인 것으로 조사되었습니다.

다음은 경력과 근무지 분포도입니다.

경력

경력	인원	백분율
1년차 미만	24	21%
1~3년차	51	44%
4년차 이상	24	21%
7년차 이상	16	14%

3년을 기준으로 6:4정도로 분포가 나뉘어졌습니다. 1~7년차 이내의 중급자가 65%로 나타났습니다.

근무지

근무지	인원	백분율
웹 에이젼시	60	52%
소프트웨어 회사(게임사 포함)	15	13%
포털/서비스	18	16%
일반 대기업 IT부서	2	2%
일반 중소기업 IT부서	15	13%
기타	5	4%

웹 에이젼시가 과반 이상을 차지했습니다. 프리랜서 등 기타 항목은 5명으로 4%정도를 차지했습니다.

연봉

년차별 평균

단위 : 만원

구분	1년차 미만	1~3년차	3년차 이상	7년차 이상
인원	24	51	24	16
평균	1,873	2,366	2,983	3,878
최소	1,200	1,500	2,100	3,200
최대	5,100	5,000	4,400	5,800

꾸준히 상승되는 모습을 볼 수 있지만, 대체로 높지 않은 평균 연봉입니다.

업종별 평균

구분	웹 에이젼시	소프트웨어	포털/서비스	일반 대기업	일반 중소기업	기타
인원	60	14	17	2	15	5
평균	2,302	3,340	2,950	3,400	2,352	3,168
최소	1,200	1,500	1,800	1,800	1,500	1,800
최대	5,800	5,100	5,000	5,000	3,400	5,000

업종별로 볼 때 게임사를 포함한 소프트웨어 개발 회사와 대기업의 평균 연봉이 높게 나타났습니다. 웹 에이젼시와 일반 중소기업의 IT부서의 평균 연봉은 2,300만 정도입니다. 그리고 웹 에이젼시의 최소 연봉은 1,200으로 포털/서비스나 대기업 최소 연봉에 비해 600만원 가량 차이가 났습니다.

업종별/년차별 평균

구분	1년차 미만	1~3년차	4년차 이상	7년차 이상
웹 에이젼시	1,676	2,202	2,811	3,880
소프트웨어 회사(게임사 포함)	3,600	3,100	3,150	4,250
포털/서비스	1,800	2,357	3,240	3,720
일반 대기업 IT부서	-	1,800	-	5,000
일반 중소기업 IT부서	2,850	2,100	2,795	3,350
기타	3,000	3,000	-	3,840

업종별 연봉을 년차별로 세분화 하여 살펴봤습니다. 웹 에지젼시의 경우 1년차 미만 신입 사원일 때 1,676만 정도를 받는 것으로 나타났고, 일반 중소기업 IT부서와는 1,000만원 가량 차이가 나기도 했습니다. (하지만 이 설문은 표본이 매우 적기 때문에 정확한 결과라고 판단하기 어렵습니다.)

만족도

구분	매우 만족한다	만족한다	보통이다	낮다	매우 낮다
인원	1	10	25	61	18
평균	3,000	3,270	3,195	2,424	1,988
최소	3,000	1,800	1,800	1,200	1,400
최대	3,000	5,100	5,800	4,200	4,300

만족도 조사에서는 자신의 현재 연봉이 낮다고 생각하는 경우가 79%로 상당히 높게 나타났습니다.

업종별 불만족도

만족도 '낮음'와 '매우낮음' 통계입니다.
수치가 높을수록 만족도 낮음.

구분	인원	백분율
웹 에이젼시	45	39%
소프트웨어 회사	7	6%
포털/서비스	12	10%
일반 대기업	2	1%
일반 중소기업	11	9%
기타	2	1%

업종별 불만족도에서는 웹 에이젼시가 39%로 대체로 자신의 연봉 수준에 불만이 있음을 알 수 있었습니다.

만족도(보통이상)/년차별

구분	1년차 미만	1~3년차	4년차
인원	9	11	9
평균	2,378	3,191	3,287
최소	1,800	2,200	2,980
최대	5,100	5,000	4,400

만족도 보통 이상을 선택한 경우는 년차별로 고루 나타났습니다.

만족도(낮음이하)/년차별

구분	1년차 미만	1~3년차	4년차	7년차 이상
인원	15	40	15	8
평균	1,569	2,139	2,800	3,530
최소	1,200	1,500	2,100	3,200
최대	2,100	3,200	4,000	4,200

만족도 낮음 이하를 선택한 경우는 1년차 미만 신입에서부터 1~3년차까지의 경우가 55명으로 70% 이상을 차지했습니다. 또, 1년차 미만인 경우에는 아무래도 사회로의 첫 발 내지는 배움의 자세를 갖게 됨으로써 연봉을 스스로 낮추거나 회사의 결정을 쉽게 수긍하는 듯한 인상인 반면, 1~3년차의 경우 자신의 대우에 대한 불만이 가장 높은 것으로 보여집니다.

희망 인상율

범위	인원	백분율
5% 이내	3	3%
5% ~ 10%	24	21%
10% ~ 20%	40	35%
20% ~ 30%	21	18%
30% 이상	15	13%
회사가 정한대로	8	7%
기타	4	3%

2010년에 희망하는 연봉 인상율에서는 5~30% 사이에 주로 몰려있습니다. 특히 10~20%대의 인상폭을 가장 많은 분들이 희망하고 계셨습니다.

직문범위

이 설문은 중복 선택된 결과입니다.

직무내용	인원	백분율
HTML	109	95%
CSS	108	94%
JavaScript	59	51%
AJAX	16	14%
서버측 언어(ASP, JSP, PHP)	26	23%
웹디자인	22	19%
웹기획	10	9%
기타	41	36%

현재 자신의 직무 범위를 묻는 질문에 대해서는 거의 모든 분들이 HTML, CSS를 선택해 주셨고, JavaScript와 서버측 개발 언어를 차순위로 선택해 주셨습니다. 웹디자인이나 웹기획을 겸하는 경우도 각각 22명, 10명으로 적지 않았습니다.

필요한 직무

이 설문은 중복 선택된 결과입니다.

직무내용	인원	백분율
웹 표준	46	40%
웹 접근성	61	53%
웹 디자인	13	11%
웹 기획	25	22%
웹 개발	25	22%
자바스크립트	81	70%
플래쉬와 액션스크립트	27	23%
실버라이트	10	9%
기타	11	10%

2010년에 자신의 연봉을 높이기 위해서 앞으로 필요한 직무 능력에는 어떤 것들이 있는가하는 질문이었습니다. 웹 표준이나 웹 접근성에 대한 선택이 많긴 했지만 자바스크립트를 배워야 한다라는 답변이 81회 선택됨으로써 가장 높게 나타났습니다.

이상으로 2009년 웹 퍼블리셔 연봉 조사 결과였습니다. 서두에서도 밝혔지만 위의 설문 조사 결과는 표본이 115명으로 일반화 하기에는 매우 부족한 숫자입니다. 그저 한 번 살펴보시고 현재 자신의 위치를 가늠해 보시면서 다른 사람들의 생각과 방향 등을 읽을 수 있는 기회가 되시기를 바라겠습니다. 또한, 2010년에는 더욱 더 열심히 공부하시고, 현업에 수고하시면서 원하시는 연봉도 받으시길 바라겠습니다.

다른 설문조사

설문조사, 연봉, 웹퍼블리셔

Read or add comments to this article

어떤 사람들이 웹퍼블리셔가 될까?

Tue, 29 Jun 2010 14:45:17 +0900

웹 생태계에서 최근에 각광(?)을 받고 있는 직업이 있다면 단연 웹 퍼블리셔다. UI개발자나 마크업 개발자라고도 불리우는- 또는 과거의 이름 그대로 HTML 코더라고 불리우는 이 직업에 대해서 많은 기대와 고민들이 있다. 이 문서에서는 어떤 사람들이 웹 퍼블리셔라는 직업을 선택했는지를 조사해 보려고 한다. 당신이 지금 웹퍼블리셔(또는 비슷한 업무의 직업)라면 이전에 어떤 일을 하던 사람이었는가?

willBecomWhoWebpublisher

당신은 어떤 일을 하던 사람인가요?

아래 글은 2008년 10월 30일 작성된 글로, 하드코딩하는 사람들(카페)을 통해서 진행된 설문조사 결과입니다.

웹퍼블리셔라는 직업을 갖고 있는 사람들을 만나다 보면 전직 웹디자이너나 개발자가 적지 않았음을 쉽게 알 수 있다. 그래서 하드코딩하는 사람들 카페를 통해서 한 주 동안 설문을 실시했다. 총 쉰 일곱(57)분이 참여를 해 주셨다.

예상은 했지만 웹디자이너 출신의 웹퍼블리셔가 서른 두 명으로 절반이 넘었다. 웹표준 준수와 웹접근성 향상이라는 목적 아래 큰 이슈가 되면서 웹퍼블리셔나 UI개발자와 같은 직군이 파생되어 주목을 받고 있지만 HTML 마크업이나 CSS 디자인 작업 자체가 웹디자이너의 역활 안에서 이루어져 왔다는 것을 상기해보면 이런 결과를 이해할 수 있을 것 같다.

현재도 웹디자인과 HTML, CSS를 함께 다루는 웹디자이너들이 많고, 웹디자인과 웹퍼블리싱 사이의 경계를 짓지 못하고 일을 떠 안고 있는 분들이 많은 것 같다. 웹퍼블리싱 일을 하는 사람들에게도 정확한 업무 역활과 범위가 정해져 있지 않아 혼란스럽지만 이렇게 HTML, CSS 작업이 구체적으로 분업화 되는 과도기적 상황에서 웹디자이너의 업무 범위 역시 혼란스러울 수 있을것 같다.

처음부터 웹퍼블리셔로 시작한 경우는 아홉명으로 16%를 차지했고, IT가 아닌 전혀 다른 일을 하다가 넘어온 경우도 여섯명으로 11%나 되었다.

이외로 웹개발자 출신이 다섯명으로 웹디자이너에 비해 적었고, 웹기획자 출신은 한명으로 나타났다.

다른 설문조사

설문조사, 웹개발자, 웹기획자, 웹디자이너, 웹접근성, 웹퍼블리셔, 웹표준, 전직

Read or add comments to this article

웹 퍼블리셔의 작업중 가장 오래 걸리는 것은?

Sun, 03 Jan 2010 12:30:29 +0900

웹 퍼블리셔가 웹 사이트 하나를 작업하는데 걸리는 평균적인 시간을 얼마나 될까요? 또, HTML, CSS, JavaScript 중 가장 많은 시간이 투입되는 경우는 뭘까요? 이미지를 슬라이스 하는데 걸리는 시간은 얼마나 될까요? 제 경우에는 자바스크립트와 이미지를 자르는 시간이 상당히 많이 소요되는 것 같습니다. 특히 PC의 사양이 높지 않다면 포토샵을 실행하고, 수십 메가바이트의 PSD 파일을 다루는 작업은 적잖은 시간을 빼앗아 가곤 합니다. 여러분은 어떤가요?

worktime

다음 작업 중 가장 긴 시간이 소요되는 일은 어떤 것입니까?

다른 설문조사

설문조사, 웹퍼블리셔, 작업시간, HTML, CSS, JavaScript, 마크업, 스타일시트, 자바스크립트, 이미지 슬라이스, 포토샵

Read or add comments to this article