필자는 웹에 '퍼블리셔'로 입문해서 지금은 '프론트엔드 영역'에서 개발을 하고 있다.


웹표준, 이 단어는 해외에서는 2000년대 중초반부터, 국내에서는 2000년대 후반  되어야 비로소 화두가 되기시작한 단어이다.

(일반적으로 국내 웹개발은 해외의 경향을 짧게는 2-3년, 길게는 4-5년 정도 우리나라가 뒤서고 있다.)


지금이야 정말 개나소나 웹표준 웹표준 하지만,

초기 웹표준에 대한 개발자들의 반응은 이러했다.


"그런거 왜지키냐, 이대로 쓰면 되지않느냐"

"어짜피 인터넷 익스플로러만 쓴다"


이러한 과도기에서도 굳굳히 웹표준화 운동, 웹 접근성 향상 운동을 참여해온 사람들은 매우 존경스럽다.


필자도 퍼블리셔 했었고,(지금도 하지만) 웹표준, 웹접근성 모두 공부했지만, 이들은 어떤 "전문적"지식이 아니다.

한번 책펴서 보고, 마스터 하려면 '마스터'도 어느정도 가능하다.(HTML, CSS가 그렇다.)

대단한 무언가도 없고,

그만큼 사실상 전문성도 없고, 진입장벽도 낮은게 웹퍼블리셔 과정이다. (그래서 학원도 많다.)


하지만 웹퍼블리셔들은 자신들의 직군이 전문성이 없다는 것을 인정하고 싶지 않아 한다.

자신의 입지가 떨어지기를 원하는 사람은 없으니까.


그런데, 요즘은 이 웹표준, 웹 접근성을 소위 '퍼블리셔'라 불리는 웹 개발자들이

자신들의 기득권을 지키는데 이용하고 있는 것 같다. 

퍼블리셔들은 웹표준과 웹접근성이 엄청난 전문성을 지니는 것처럼 이야기 하면서,

 모르는 사람은 '문외한' 취급을 한다던지, '상식이 통하지 않는다'식의 이야기를 하는 경우가 많다.

(여담이지만 여전히 국내에서는 '정말 별볼일없는' 웹표준, 웹 접근성(중요하지 않다는 것은 아니다. 위에 써 놓았듯이

대단한 무언가가 있는 건 아니라는 것이다.)에 집착하는 동안, 해외에서는

HTML5의 플랫폼화, 및 웹의 어플리케이션화가 대세가 되고 있다. 국내에 이식되는데는 몇년이나 걸릴지는 모르지만.


퍼블리셔들이 자신의 기득권을 위해 위선을 행한다.


개발 영역에 종사하는 이유는 다양하지만, 대부분의 사람들이 입을 모아 이야기 하는 대표적인

이유는 무언가 만들어 진다는 것이 뿌듯함을 느낀다는 것이다.(필자도 마찬가지다.)


그런데 위에 언급한 퍼블리셔의 대다수는,"웹접근성"을 지키며 장애인도 웹을 자유로이 이용하는

모두가평등한 웹을만드는것이 뿌듯하고, 그렇게 하는 장애인의 모습을 상상하며 즐거워하고, 

웹에 종사하고, 그게 웹개발의 목표라고 한다. 그리고 그러한 생각을 강요하기도 한다.


물론 그럴수도 있다. 그러한 도덕적으로 훌륭한 사람도 있을 수 있다.

하지만 실제 장애인 자원봉사자의 수나, 어떤 장애인들을 위해 일하는 이타적인 사람들의 비율과

퍼블리셔 중에 그리 말하는 사람의 비율을 비교해 볼 때, 이는 이치에 맞지 않는다.


실제로,  "장애인 차별 금지법 통과" 로 인해 웹 접근성을 강제하도록 의무화 되었는데,

이는 이타적인, 도덕적인 어떠한 것을 떠나서,

사실상 업무적인 스트레스의 증가를 말한다. (주변 게임 개발자중에 이 조항들이 웹이 아닌

게임으로까지 영향을 미친다면 게임 개발을 그만두겠다는 개발자도 있다.)

그런데 이에 대해 퍼블리셔 대부분은 긍정적이고, 이에 대해 환영하는 반응을 보였다.  과연 장애인들의 권리가 증진되어 보였던 긍정일까,

아니면 자신들의 가치가 올라가고 일감이 늘어서 보였던 긍정이었을까? 

본인만이 알 일이다.


필자는 그렇게 이타적이지 못하다. 장애인을 위한 삶을 살 수도 없다.(측은지심 정도는 있지만.)

 그리고 사람들의 대부분이 그러 할 것이다.

장애인들의 기득권을 위해 일하고,

직업에 종사하는 진정한 사람들이 있다면 정말로 존경스럽다.

하지만 '장애인을 위하는 척'하며 자신들의 기득권을 지키는 사람들은 사라져야 한다.

그런 사람들에게는 이렇게 말해주고 싶다.


"언제부터 그렇게 장애인들을 위한 삶을 살아오셨어요?"


출처 : http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=70&MAEULNO=28&No=234


-------------------------------------------------------------------------------

저는 약 10년 전 IT 개발자로 일을 시작했다가 지금은 금융권에 안착하여 홍콩의 금융권에서 

일을 하고 있는 사람입니다. (IT쪽 일 아닙니다) 어쩌다가 T모사가 윈도 호환 OS를 만든다는

얘기를 듣고 어떻게 되었나 궁금해서 얘기를 추적해 보니 온갖 잡음이 있더군요. 개발과정에서

많은 직원이 이혼을 했다는 얘기도 있고 한데, 의외로 많은 젊은이들, 또는 어린이들이 T모사를

두둔하는 경우가 많더군요. 그래서, 글은 잘 못쓰지만 후배 여러분들께 조금이라도 도움이

될까해서 몇자 적어봅니다. 부디 이 글을 읽고 지금이라도 매트릭스의 노예에서 벗어나시길 바랍니다.

(아래 일부 내용은 존칭은 생략하겠습니다.) 표현이 다소 거친 일부 부분 양해 바랍니다.

 

운영진 여러분께서 판단하시기에 내용이 문제가 되거나 논쟁이 생기면 삭제해 주실 것을

부탁 드립니다.

 

간단히 요지는 이렇다. 모 회사의 경영자는 경영을 모르는 자이다. 자사의 초기제품은

M모, O모, S모 사의 제품과 경쟁을 한다. 그런데, 경쟁의 주요포인트는 오로지 가격이다.

벤치마크고 뭐고 일단 가격경쟁으로 market share를 올린다. 나도 약 7년 전에는 이 막장기업과

일정한 사업부문에서 경쟁관계에 있던 또 다른 막장기업의 개발자로 일해 본 적이 있는데,

둘 다 일단 시장경쟁을 후진적인 가격경쟁으로 몰아간다. 기업은 작으니 헐값에 수주를 해도

마치 고속성장을 하는 것처럼 보인다.

 

고객사는 늘어가는데 제품에 신경을 안쓰고 팔다 보니 많은 문제가 생긴다. 그러면 개발자들은 

그 문제를 해결하기 위해 여기저기 고객사를 뛰어다니거나 며칠 밤을 새서 문제를 해결해야 한다. 

개발자들의 원성은 높아지는데, 임금은 올릴 수가 없고, 이를 억제하기 위해서는 코스닥 환상이 

직빵이다. "우리회사는 내년에 코스닥 상장을 할꺼야. 그럼 팔자 핀다구" 개발자들은 십중팔구 

이 개육갑 떠는 소리를 이해하지 못하는 병신 중 상병신이다.

 

왜냐면 여태 포인터가 어쩌구 쓰레드가 어쩌구 하는 것만 배웠고 그게 최고의 기술이며,

이는 여타 종교의 메시아와 같이 어느샌가 남태평양 어디선가 한가한 휴가를 보내는 자신의 환상을

실현시켜 줄 거라는 착각에 빠뜨린다. 자신은 코스닥이 뭔지, 주식이 뭔지, 상장이 뭔지 알 바도 없고,

알 필요도 없다. 경영자란 새끼가 설마 거짓말 하겠어, 좋은 거면 좋은 건가 보다 한다.

 

후진국의 성장률이 높은 이치와 동일한 이유로 회사는 급성장을 하는 것으로 보이고 또라이 경영자는

사업을 확장하기 시작한다. 데이터베이스 사업에서 미들웨어 사업, 이젠 데스크탑 애플리케이션

사업까지 확장을 한다. 그러기 위해서는 많은 개발자들을 고용하기 시작하고, 하지만 애초부터 

시장에서 가격경쟁으로 성장한 회사였기 때문에 재무구조의 상태는 그다지 좋지 않은 상태이므로 

기업의 겉모습은 성장하는 것 같으나 내부의 개발자의 일상생활을 보면 딱하기 그지 없다. 

매일 야근에 주말까지 일을 한다.

 

데스크탑 시장은 가격경쟁으로 호락호락하게 넘어가는 시장이 아니기에 신규사업 대부분이 

시장진출에 실패하고 기존 cash cow 사업의 매출은 여전히 성장하나 이익률은 고꾸라지기 시작한다.

그러다 보면 금고가 비는 것은 순식간이고, 대부분의 기업은 자본만으로 운영되지 않는다. 그렇다. 

은행 대출의 만기 연장으로 기업이 돌아가는데, 은행은 기업이 잘 나갈 때는 그 기업을 VIP로 

모시지만, 그 반대의 경우에는 인정사정 없다. 은행이 만기를 연장해주지 않는다는 것은 기업의 

현금성재산을 써서 은행에 갚아줘야 하기에 회사 사정이 쪼들린다는 얘기다. 회사에 현금성 자산이 

없으니 그 많이 뽑아놓은 개발자들 줄 월급(월급은 현금이다)이 없고, 투자자를 찾아보니 이 상황에

투자할 미친 놈은 없는 거다. 

 

결국 fund raising에 실패를 하면 회사는 부도가 날 수 밖에 없고, 이런 막장기업에 투자할 

호구놈들은 죽어라 야근 밖에 모르고 살았던 세상물정 모르는 개발자들이다. 

(이 소식을 듣고 저는 아무런 관련이 없는 사람이지만 참 마음이 아팠습니다) 그래서, 개발자들의 

피를 빨고 이젠 마지막 최후의 뒤통수까지 친다. 상장 주식도 아니고 비상장 주식을 우리사주라고 

꼬시며 액면의 3배를 요구하는 사기를 치려하자 금감원이 이를 말린다. 결국 액면 2배만 받고 

휴지나 다름없는 우리사주를 주고 또 다시 회사는 굴러가지만, 회사는 결국 구조조정에 들어간다...

 

이런 스토리입니다. 제 생각에는 위 얘기를 이해하지 못하는 개발자들이 십중팔구라고 생각합니다.

그 업계를 나오고 나니 얼마나 내가 바보이며 이용 당해왔나 생각이 들더군요. 회사가 무엇이며

회사가 어떻게 돌아가는 것인지, 경영자, 투자자, 노동자의 위치가 어떻게 다른 것인지를 가르치지 

않는 학교 교육의 문제가 오늘날의 우리나라 이공계의 현실을 불러왔다고 생각합니다.

 

1. 기업의 소유자는 투자자이다.

2. 기업은 오로지 투자자의 돈을 불려주기 위해 존재한다.

3. 투자자가 기업에 얼마나 돈을 넣었는가에 대한 증명이 주식이다.

 

학교에서는 기업은 이윤을 창출하기 위한 집단이라 정의하여 많은 혼란을 불러 일으킵니다. 

대체 누구의 이윤을 창출한단 말입니까? 여러분이 돈 1억을 들여서 회사를 차렸다고 합시다. 

그러면 그 회사는 여러분의 것이 됩니다.

 

직원을 10명을 뽑았습니다. 그렇다면 직원이 그 회사의 소유를 나눠 가지는 것인가요? 아닙니다. 

여러분 입장에서는 그 직원은 컴퓨터나 기계와 마찬가지로 일정한 금액을 먹고 그 이상의 output을

내는 존재에 불과합니다. 그들에게 기업의 소유권은 1%도 없습니다. 그렇다면 기업은 누구의 이윤을

창출하는 것일까요? 그것은 투자자, 즉 여러분의 돈, 1억을 불려주기 위해 존재하는 것입니다. 

여러분이 그 기업을 소유하고 있다는 증서가 주식입니다.

 

만일 여러분이 친구와 함께 5천만원씩 투자해서 기업을 세웠다고 칩시다. 그러면 그 주식을 두 개로 

나눕니다. 만일 여러분이 돈이 필요해서 그 주식을 다른 사람에게 팔아도 그 주식은 누군가의 소유가

되어 여전히 기업의 소유를 증명하게 됩니다.

 

- 야근은 인건비 절감을 위한 치졸한 수단에 불과하다.

 

여러분은 야근을 요구 받으면 무슨 생각이 드나요? 아, 내가 이 회사를 위해 열심히 일하면 회사가 

알아주겠지 하는 생각에 여자친구와의 저녁약속도 취소하고 열심히 야근을 하겠지요. 

야근이 인건비 절감과 무슨 상관이 있는지 생각도 못한 채 말입니다. 원래 여러분은 개발자가 되는 

순간부터 사실 "월요일부터 금요일까지 아침 9시부터 6시까지만" 사용할 수 있는 존재입니다. 

물론 그 시간동안에는 절대 다른 짓을 해서도 안되고 회사를 위해서만 일해야 하지만, 그 이외의 

시간은 회사가 여러분을 부릴 권리는 없는 것입니다.

 

선진 외국에서의 야근이란, 두 가지 경우가 있습니다. 첫째, 자신의 업무에 대해 책임을 져야 하고,

또한 성과에 따른 보너스를 엄청나게 받는 사람이 자신의 일을 당일 끝내기 위해 자발적으로 하는 

야근, 둘째, 업무 효율이 저조하여 당일 해야 할 일을 마치지 못하여 끝내야 하는 경우. 

선진 외국에서는 한국과 같은 아무 이유없는, 그렇다고 해서 따로 보너스를 챙겨주지도 않는 야근을

하는 경우는 없다고 보시면 됩니다.

 

만일 여러분을 한 달간 밤샘을 시킨다면? 경영자로서는 두 사람으로 한 달에 해야 할 일 또는

여러분에게 두달 치 월급을 주어야 함에도 불구하고 현재 월급만으로 이 일을 해결하려는 시도가

됩니다. 또한, 사무실 공간의 리스료 등등도 한 달치가 절약되는 셈이죠. 따라서, 한 달을 밤샘 코딩을

시킨다면 경영자로서는 엄청난 돈을 벌게 되는 것입니다. 개발자는 쌍코피가 터지건 말건 말이죠.

사실상 개발자의 월급은 반토막이 되는 거나 마찬가지입니다.

 

- "코스닥에 상장할 거야. 그럼 팔자 핀다구"

 

코스닥은 뭔지 많이들 들어서 아실 겁니다. 그렇다면 상장은 뭔지 아시나요? 그리고, 상장을 하면

누가 팔자를 피는지 아세요? 코스피 시장이 국내 최대 기업들의 주식이 거래되는 시장이라 보면, 

코스닥은 이보다는 작은 회사들의 주식이 거래되는 마이너 리그라고 보시면 됩니다.

 

- 코스닥에 상장을 하면 왜 돈을 벌고 누가 돈을 버나요?

 

여러분이 회사를 차렸다고 합시다. 회사가 잘 운영되고 있습니다. 그래서, 회사의 가치가 많이 

올라갔습니다. 1억으로 시작한 회사가 1000억의 가치가 되었지만, 그 중 500억을 팔아서 현금으로 

가지고 싶다면 여러분이 소유한 기업의 소유증명인 주식이라는 종이를 누군가에게 팔아야 합니다. 

보통 시장에서 500억원 어치 주식을 한 번에 살 수 있는 거금을 가지거나 그 큰 거금을 한 회사에 

몰아줄 용감한 사람은 많지 않습니다. 따라서, 코스닥과 같은 공개 시장에서 팔고 현금을 얻는 것을

할 수 있으려면, 금융협회 등의 인가를 받아 상장을 해야 하는 것입니다.

 

회사를 세우고 그 주식이 상장되기 전에는 private company입니다. 여러분이 그 회사를 마음대로 

요리할 수 있는 것이지요. 만일 여러분이 일부 투자자에게 private company 상태에서 투자를 받게 

되었습니다. 투자를 받으면 여러분은 그만큼에 해당하는 주식을 내주어야 합니다. 만일 여러분이 

어느 회사에 투자한다, 그러면 무엇이 증명으로 쓰일까요? 그 회사의 일부를 소유하고 있다는 권리를

증명하는 주식을 받는 것입니다. 따라서, 어느 기업을 코스피 시장이 되었건, 코스닥 시장이 되었건,

상장을 한다면 더 이상은 private company가 아니게 됩니다. 불특정 다수의 사람들이 그 회사의 

일부분씩을 나눠 갖게 되는 것이니까요. 그것을 우리는 기업공개 또는 

IPO(Initial Public Offering)라고 합니다.

 

즉, 상장 = 기업공개 = IPO 거의 비슷한 말이라 보시면 됩니다. 또한, 일반적으로 주식을 공개시장에

상장하게 되면 매매경쟁에 의해 가격이 치솟게 됩니다. (누군가 주식은 피라미드 상품이라 했죠)

 

그러면, 코스닥에 상장을 하게 되면 직원들에게 돈이 돌아가나요? 아닙니다. 10원도 없죠. 

오직 그 주식을 소유한 주주들이 행복해집니다. 소유주식의 가치가 올라가니까요. 다만 예외가 

있습니다. 만일 직원이 우리사주를 가지고 있다면? 우리사주도 말만 다를 뿐, 주식이나 

마찬가지이므로 우리사주를 가진 직원 역시 행복해집니다. 결국 상장을 하게 되면, 팔자 펴는 것은 

개발자 여러분이 아니라 투자자가 직접적으로 팔자가 펴고, 한국은 대부분 투자자와 경영자가 

구분이 안되어 있지만, 경영자는 많은 보너스로 팔자가 펴겠죠. 개발자는 약간의 근로 조건이 

개선되는 이상의 효과는 없을 것입니다.

 

회사에서 나중에 우리사주를 줄 거라 합니까? 조만간 스톡옵션을 주겠다고 설레발을 칩니까? 지금 

안줄 거면 그딴 소리는 닥치라고 하는게 좋을 것입니다. 주고 싶은 것이었다면 이미 주었어야 

하는 것입니다. 왜냐면 스톡옵션의 가치는 상장 이전에는 가치가 있기는 하나 거의 없는 것이나 

마찬가지이며, 우리사주는 액면가 이상의 의미는 없는 것입니다.

 

자, 그럼 하고 싶은 이론적 바탕은 대부분 얘기했습니다. 그럼에도 불구하고 여러분은 자신의 

젊은 나날을 소모하며, 육체적 정신적 건강을 해치고, 가족관계를 해치면서까지 허무맹랑한 

코스닥 환상의 뻘소리에 희생당하실 건가요? 어떤 고등학생으로 보이는 사람의 글이 보이더군요. 

"우리나라의 기업이 M모사의 W모와 경쟁할 OS를 만든다면 나는 매일 밤샘작업을 하고 월급이 

적더라도 일해보고 싶다." 이 얘기를 다시 해석해보자면, "나는 세상물정 모르는 돌대가리이며 

내가 가진 코딩할 수 있는 노동력 및 내 사생활 모두를 투자자에게 헐값에 넘겨주고 싶다"의 

뜻입니다.

 

저는 이 모든 것을 금융권에 들어가고 나서도 한참 지나서야 알았습니다. 왜냐면 뼛속까지 이공계 

물이 든 저로서는 학교에서 한 번도 가르쳐 준 적이 없는 것들이기 때문이죠. 사실 우리 교육 

바뀌어야 합니다. 주식에 대한 이해가 없고, 상장이 무엇을 의미하는지, 개발자의 꿈이 왜 허무한 

것이며 경영자들은 이를 어떻게 뒤통수 치고 이용해 먹고 있는지에 대해서 모든 개발자가 

깨달았으면 합니다.

 

오늘도 여기 이 글을 쓰려고 들어왔다가 폐를 절제한 IT개발자의 기사를 보고서는 10년이 지나도 

그 바닥은 여전하구나란 생각만 듭니다. 매트릭스에서 벗어나 이제는 자신을 추스릴 줄 아는 

개발자가 하나라도 더 늘었으면 하는 바람에 쓴 글을 이만 마칩니다.

 

오늘밤도 사무실에서 밤을 새며 코딩을 하고 있을 많은 개발자들을 위하여...

 

프런트 엔드 영역에서 개발을 하다보면,

HTML, CSS의 마크업 언어만으로 코딩을 해주는 '퍼블리셔'의 파일을 넘겨 받아서 js, php등의


개발을 적용하는 경우가 많다. (물론 직접 마크업 하는 경우도 있다.)


그런데, 이 퍼블리셔라는 사람들이 만들어 놓은 파일들을 보면,


개발자로서는 참 난감한 경우가 많다.


여러가지가 있지만, 나열해보면


1.웹 표준, 접근성에 맞지 않게 코딩.


2.테이블을 이용한 막코딩


3.js, php 활용을 고려하지 않은 모양만 갖춘 코딩.


등이 있다. 


여기서 1번,2번은 개인적으로는 퍼블리셔라고 불러주고 싶지도 않은, 

기본적 소양도 갖추지 못한 퍼블리셔라고 본다. 그냥 코더라고 부르겠다.


그런데...3번은 보자. 3번 같은 경우도 정말 자주 있는 일이다. 저런 경우에는 결국

개발자가 다 뜯어서 마크업부터 다시한다. 일을 두번하게 되는 샘이다.

왜 이런 일이 발생할까? 


그렇다! 그는 html, css에도 능숙하고, 웹표준, 접근성 마크도 여러번 달아봤지만, javascript와 php의 j, p 자도 몰랐던 것이다. 내가 만든 이 html에 어떤 조작이 가해져서

어떤 효과를 내고, 어떤 데이터를 가져올지 전혀 모르는 상태에서 마크업을 하니, 오히려

넘겨받은 파일이 정상인 것이 기적인 샘이다.

(물론, js도 능숙하게 다루지만 업무적 포지션이 퍼블리셔인, 진정한 퍼블리셔 분들도 많이 계신다.)


다시 말해서, 퍼블리셔가 js나 php, jsp가 어떻게 돌아가는지 전혀 알지 못하면, 이러한 사태가 빈번히 발생 할 수 있다.

퍼블리셔는 js와 서버 언어에 대한 지식을 키우는 데 게을리 하지 않아야 한다는게 프론트 엔드 개발자로서의 입장이다.


일부 퍼블리셔는 말한다.  (그러면서 그들이 할줄 아는 것에 덧붙여 js도 할줄 아는 ui 개발자와 동등한 대우를 받기를 원한다.)


"웹 접근성, 표준 지키고 크로스 브라우징 레이아웃 마크업 하기도 바쁜데 js도 해야하나요? 내가 왜 js를 해야하나요?

그거 개발자가 하는 거잖아요?"


그러면 이렇게 답변해주고 싶다.


"그러면 퍼블리셔는 프론트 엔드 개발자가 아니네요? 똑같은 대우 해달라고 하지마세요."



바쁘다는 핑계로 자기가 왜 js를 해야 하냐고 주장하지만, 필자의 느낌은,


솔직히 말해서, js를 하고 싶지않고, 변화를 강요받고 싶지 않은 퍼블리셔가 많은것 같다.

주변에서 계속해서 js를 권유하기 때문에 js 자체게 반감을 갖고, 비하하는 퍼블리셔도 종종 보인다.

(실제로 주변 지인 퍼블리셔들의 이야기를 들어보면, js부터는 다양한 개발 방법론이 있는 언어 단계로 접어들어,

그 장벽이 결코 낮지 않다고 한다.)


 분명히 위의 말에서, '이것저것 하느라 바쁜데'라는 말은


누가 들어도 공감 할 수 있는 사실이다. 그러나 필자가 요구하는 것은 js의 업무적인 추가를 요구하는 것은 아니다.


기본적으로 js가 어떻게 구동되며, 퍼블리싱 된 제품을 어떻게 이용 하는지를 알고 퍼블리싱하기를 바라는 것이다.


퍼블리셔라는 포지션은 분명 사라질 수 없는 포지션임은 틀림 없으며, 퍼블리셔도 마크업을 전문적으로 하는


프론트 엔드 개발자의 일환임에도 틀림없다.


그러나 js만을 다루며 html, css를 무시하는 사람이 프론트 엔드 개발자가 아닌 js 코더이듯, 

html, css를 다루며 웹표준, 웹접근성 마크 다는 것을 어떤 대단한 기술을 가진 것인 냥 유세를 부리는

퍼블리셔는 프론트 엔드 개발자가 아니다. 그냥 마크업 코더일 뿐이다. 그런 사람들에겐 이렇게 말 해주고 싶다.


"표준이랑 접근성 그거 난 옛날부터 할줄 알아서 다음단계로 넘어온 거거든요?"


  • Unknown 2012.12.18 02:47

  • 지나가다 2012.12.23 01:15

    퍼블리셔가 개발자로 대접받으려면 최소한 저 위의 3개는 정말 기초적인 건데... 저 기본소양마저 갖추지 않은 경우가 허다합니다.
    현실은 할거없는 사람들 중 학원 교육이나 대충 받고 일하게 된 퍼블리셔들이 대부분이니...
    백엔드쪽에서 개발하는 저도 최근 UI/UX 등이 주목받고 있고, 웹 페이지에서 웹 어플화로의 급속한 발전 단계에 있기에 프론트엔드쪽에 큰 관심을 보이고 있지만... 현실이 이러하니 쉽게 그 분야로 진출을 못하고 있습니다.
    요즘 느끼는 것이 IT 학원들이 한국 IT를 오히려 망치고 있는 것 같아요. 전공자만큼 대접받게 하려면 장기적으로 체계적인 교육 과정을 갖추던가... 자극적인 선동 문구로 호갱 유치에 바쁘니 원...

    • 이나라학생 2012.12.23 10:07 신고

      예. 저도 지나가다님의 말에 적극 동감합니다. 모 카페에서 본 어떤 퍼블리셔는 "'웹 접근성'이 웹 개발의 궁극적 목적이다" 라는 발언도 대단한 자랑인냥 일삼더군요. 웹 프런트 엔드 개발 기술의 범위가 다양해졌음에도 우리나라는 HTML5 브라우저를 사용 할 일이 없다는 것 때문인지(IE) 웹 접근성, 표준 크로스 브라우징 등이 모든 웹 프론트 엔드 개발의 대다수 인냥 엄청난 집착을 하더군요.(오해의 여지가 있지만 이것이 중요하지 않다는 것은 아닙니다.) 실제로 외국의 웹 경향을 보면 UI/UX나 HTML5등의 신 기술이 핫이슈인것에 반하면 말입니다. 제가 모바일에 관심이 많아서 최근에 스마트폰 UX/UI에 관련된 국가기관에서 교육을 받은 적 있는데, 달마다 차비,식비, 생활비까지 모두 주는 무료교육인데, 정작 나오는 사람들의 수준은 한심하기 그지없습니다. 게다가 과정제목과 달리 단순 '퍼블리싱'을 가르치고 모바일적인 요소는 10% 정도더군요. 그렇다고 퍼블리싱을 제대로 가르치는 것도 아니니.. 저런 사람들이 퍼블리셔랍시고 취업을 하게 된다고 생각하니 웹 프론트 업계가 백엔드에 비해 무시받는 것도 이상할 것이 없다는 생각도 들었습니다. 분명 웹 프론트 엔드 영역에서의 기술과 그 다양성은 밝고 무궁무진하지만, 저런 양산형 퍼블리셔들이 계속해서 생산되는 한 우리나라에서의 웹 프론트 엔드 개발 환경의 개선은 없을 것으로 생각됩니다.

  • insook 2012.12.29 19:54

    하코사에서 글 보구 어찌어찌 여기까지 오게 되었네요
    많은 부분 공감하고 갑니다.
    새해복많이 받으세요 :-)

    • 이나라학생 2012.12.30 00:34 신고

      예 누추한곳까지 와주셔서 댓글까지 써주시니 감사하네요.
      새해 복 많이 받으세요~

  • 나그네~ 2013.01.07 13:35

    안녕하세요.... 웹퍼블리셔 와 프론트엔드 개발자로 검색하다보니 여기까지 오게 되었어욤..
    저역시 웹개발만 몇년째하고 있는데욤...
    님이 올려주신 개발이야기 쪽 글들 다 공감합니다. ㅋ
    실제로 겪어보기도 했구염.. 웹디가 코딩까진 하는데 js는 자기 영역 아니고 웹개발 영역 아니냐고 해서.... 난감해
    했던 적도 잇엇구욤.. 웹개발이라고 해서 js를 다 라이브러리로 가지고 있어 뚝닥 하면 나오는 줄 아는....
    여튼 님 글 잼있게 잘 보고 갑니다.!!!! 새해 복 많이 받으세욤.

    • 이나라학생 2013.01.07 18:53 신고

      사실 돌 좀 맞을 각오하고 쓴 글들이 많은데 제전부다 공감해주시니 기쁩니다.

  • 치프 2013.02.27 11:15

    좋은글 잘읽었습니다.

    하지만 웹개발도 일종의 팀플레이라고 저는 생각합니다.
    js 를 잘 못하는 웹ui 개발자와 일한다고 가정할경우,
    같이 psd 를 보며 어떤 마크업을 원한다고 웹개발자가 먼저 제의를 할 수 있고,
    웹ui 개발자도 동의하고 따라올 필요가 있습니다.
    작업물 넘어올때까지 마냥 넋 놓고 기다렸다가 작업물 받고 다시 웹ui 개발자한테
    마크업 맘에 안든다고 고쳐달라고하면 서로 감정싸움에 시간만 소요되겠죠...
    작업 시작전에 서로 기획서와 psd 를 보며 잠깐이나마 커뮤니케이션 한다면
    더 좋은 결과가 나옵니다.

  • EveR™ 2013.03.14 17:13

    좋은글 잘 읽고 갑니다.
    아니라학생님께서 작성하신 글에 공감합니다.
    하지만 제 블로그에서도 언급했다 싶히히 스크립트를 앞새워 HTML,CSS를 별 대수롭지 않게 보는 일반적인 UI(스크립트)개발자는 않좋다는걸 다시한번 말씀드리고 싶어요.
    저도 회사내에서 스크립트 개발자로 점점 성장하고 있지만 그러면서도 웹표준,웹접근성에 대한 공부 또한 소홀히 하지 않고 있습니다.
    아무리 퍼블리셔가 개발을 공부하고 개발자가 아무리 마크업을 공부해도 HTML,CSS,JS,서버사이드언어에 대한 접근방법에 대한 한계는 존재하는거 같습니다. 고로 개발자와 퍼블리셔간에 제일 중요한건 서로의 입장을 고려하여 최대한 협업을 어떻게 잘할지에 대한 고민인거 같습니다.

  • 지나가는사람 2013.03.27 22:26

    글 잘봤습니다. 지금 하는 프로젝트에서 웹에이전시가 들어와서 작업하는데 jquery는 들고 다니네요.
    접근성보장 마크업에서 시작해서 CSS브라우저 호환성, 화면에서 인터랙션이 일어나는 스크립트영역까지는 커버해주네요.
    퍼블리셔는 맨날 에디트플러스로 html만 만드니까...jsp같은 서버페이지로 옮길때 개발자가 html 부분부분 잘라 써야하는 건 어쩔 수 없나봐요.
    또한 상세한 부분에서 개발팀과의 R&R싸움은 끝이 없다는...ㅜㅜ

  • 진실을 말해줄게 2013.07.22 00:36

    그렇게 무시하지 마세요.
    그런 논리라면 SI 업계에서 웹 프로그래머 무시하는거 인정하시든지요.

  • 진실을 말해줄게 2013.07.22 00:37

    당신이 진짜 원하는건 자바스크립트 만지기 싫은거에요

    • 병신인가 2016.04.20 19:39

      이새낀 구글번역기 쓰나? 뭔 말도안되는소리야

  • 진실을 말해줄게 2013.07.22 00:39

    오히려 퍼블리셔들은 프로젝트 나가서 웹개발자들 뒷다마 많이 듣습니다.
    커뮤니케이션 능력이 없는 사람들이 남들 책임으로 몰아가는 전형적인 예를 보네요 ㅎ

    • 이나라학생 2013.07.22 21:47 신고

      퍼블리셔 신거같은데 떳떳하면 이름 밝히고
      논리적으로 승복시키길. 아무논리도없고 감돔도없고
      이뭐병.

  • 마요네즈송 2014.01.26 01:01

    흐음.. 이글을 보니 ㅋㅋ 제가 일하는 곳에서는 개발자가 답답한게..
    디자인의 의도를 제대로 표현하고자 js까지 코딩해서 보내는데..
    개발자들은 그런거 하지말고 디자인이나 하라고 그러네요..
    그리고 자바스크립트가 jQuery가 다인줄 아는것도 답답하고요.. ㅋㅋ

    • 이상하신분 2016.07.31 20:27

      아무리 신입 초짜 개발자라도 jQuery와 Javasript를 모르지 않습니다.
      jQuery가 지 아무리 날뛰어봤자 부처님 손바닥 안에 있는 것처럼 Javascript코드지 뭐냐는 얘기는 할 수 있어도요.

  • 퍼블리셔지만 2014.03.23 04:21

    흠.. 퍼블리셔의 문제보단 개인 마찰로 인한 원한글에 가까워 보이네요.
    퍼블리셔 자바스크립트 하고 싶어하는 사람도 굉장히 많고 잘하는 사람 굉장히 많습니다.
    나이대가 어떻게 되신 분들이랑 다퉜는지는 모르겠습니다만... 요즘은 js 다 하려하고 다 합니다.
    제 경험엔 대게 고집쌔고 그닥 능력도 없는분들이 디자이너와 퍼블리셔를 욕했습니다.
    js를 건내주면 땡큐지만 그거부터 안되니 뿔이 나기 시작한거죠. 개발자 천대받을 에이전시같은곳에 알면서 있으면서 말이죠.

  • 개발자1 2014.07.11 10:55

    저도 개발자인데 3번이 특히 공감가네요. 1,2번 같은 분들은 바로퇴출되는 경우가 많아서 그런지, 전 거의 못본듯... 3번같은 경우는 퍼블리셔분들의 나름 고충이 있다고 생각합니다. 애초에 기획자나 디자이너 개발자 퍼블리셔 4명이 같이 회의를.해야 제대로된 코드가 나오는데 대게는 그런 기획자가 1:1로 일을 진행할때가 많으니 서로 생각하는 바가 다르겠죠. 하지만 퍼플리셔분들이 개발자 입장을 최대한 존중했으면 싶은건 결국엔 거의 모든 마무리 내지는 책임을 개발자가 진다는 겁니다. 가끔 저도 책임이 너무 무거워서 퍼블리셔 내지는 js개발만 하고 싶더라구요.

  • 공부중 2014.12.26 09:44

    프론트 앤드 개발자가 무엇인지 공부하다가 들리게 됐네요.. 마지막이 말이...매우 확 꽂힙니다... 열심ㅎ ㅣ공부해야 겠어요....

  • 퍼블리셔 2015.06.05 13:45

    어느정도 공감이 가는 부분이 많네요.
    글을 읽으면서 느낀건 제대로 된 퍼블리셔와의 협업은 아니었던 듯합니다.
    전 퍼블리셔인데 개인적으로 주석에 이곳에 무엇을 뿌려달라라고만 씁니다. 그외 서로 설명할 필요가 없거든요.
    퍼블리셔라 불리는 사람이라면 대부분 저와 같은 거라고 생각합니다.
    개발자는 데이타만 뿌리면 되거든요.
    실력 있는 퍼블리셔 만나셔서 스트레스 덜 받으며 작업할 수 있길 바랍니다.

  • 2015.06.06 01:20

    비밀댓글입니다

  • 김스카 2015.06.06 01:24

    120% 공감합니다. 퍼블리셔입니다 저는.. 1,2,3을 다 갖춘 퍼블리셔와 일하기가 너무 힘듭니다. 모양만 대충 뽑아놓고 복붙하고 생각없이 코딩해놓은 사이트를 운영하려면 여간 힘든게 아니네요.. 게다가 웹 구성 3요소는 구조 표현 동작인데 ... 그 어느하나도 제대로 하는 사람 보기가 손에꼽을 정도 입니다.. ㅠㅠ. Js를 바라기 이전에 html/css나 제대로 개발했으면 하는 바램이 크네요.. ㅜㅜㅜ

    • 한마디 2016.07.31 20:33

      구조, 표현, 동작을 몰라서 하지 않는 것이 아닌 경우도 있습니다.
      너무 심하게 나누다보면, 유지보수가 더 어려워 집니다. 아무리 좋은 이상적인 기술도 상황에 따라 적용해야지 무조건 이상을 따라갈 수는 없어요.

  • 훈솔 2015.06.18 15:58 신고

    사실 퍼블리셔라는 직군이 상당히 기형적이죠

    디자이너도 아닌것이 그렇다고 개발자도 아니고...
    새로생겼다고 하지만 나누는 기준이 너무 얇았다고봐요

    전 프론트 - 백 으로 나누는걸 지향합니다.

    • 두솔 2016.08.14 03:29

      님 얘기가 옳다면, 개발자는 백단만 해야 하고 프론트단은 건들지도 말아야 하는 겁니다. 그런데 그렇게 되면, 개발 초기 이후 빠져나가는 퍼블리셔의 작업물을 누가 확인하겠습니까? 중간 역할이 없어서 개발자가 문제를 확인하고 이의를 제기해서 다시 수정될 수 있도록 조정할 수밖에 없는 겁니다. 개발 초기에 나타나는 프론트 작업물의 문제점을 발견 못 하면 개발이 안 되기 때문에 그 모든 것을 개발자들이 떠안게 되는 겁니다. 조금 더 이야기를 확장해서 덧붙이자면, 개발 기간이 끝나고 개발자도 빠지는 형태라면, 결국 프론트와 백단을 만질 수 있는 인력으로 최소화될 수밖에 없으므로 프론트와 백단 개발은 나누어지지 않는 겁니다.

  • 나그네 2016.04.25 19:49

    저도 개인적으로 작성자 분풀이로 보입니다. 개발자든 퍼블이든 서로 이해를 해야하는데 본문에서처럼 나 저거 다 할줄 알아서 넘어온건데요.... 라는 문장을 보니깐 쫌 그렇네요 ㅎㅎ... 개발자든 퍼블이든 서로의 까내리는건 안됩니다 ^^;

    • 난시소 2016.08.14 04:17

      '개발자(든)'이 아니라 개발자(던) 퍼블이(던) 서로 이해를 해야 한다는 것을 잘 아시는 분께서 작성작가 의도한 글의 내용을 분풀이로 보시면 곤란하죠.
      실질적으로 이해해야 하는 것이 무엇입니까?
      html, CSS를 다루며 웹 표준, 웹 접근성 마크 다는 것을 어떤 대단한 기술을 가진 것인 양 유세를 부리는 사람이 서로 다른 업무에 대한 이해가 높은 사람으로 비치던가요? 벼는 익을수록 고개를 숙인다는 옛 속담처럼, 작성자가 하려는 얘기도 다르지 않다고 봅니다.

      당신이 퍼블리셔라면, 한 번도 좋고 두 번도 좋으니 되돌아보시기 바랍니다.
      내 업무는 여기까지라고 선을 긋고, 뒷일은 나 몰라라 했던 적은 없었는가 생각해보시기 바랍니다.
      유세 부리는 것을 이해할 필요도 없고, 말로만 이해를 외치는 것도 이해가 아닙니다.

  • 개발자 2016.07.18 23:45

    퍼블리셔 작업물에 JS까지는 하는거 안 좋게 생각하지 않습니다.

    그런데 말이죠, 경력 꽤나 된다는 퍼블리셔도 딱 자기가 하는 선까지에요.

    퍼블리셔가 외주다 보면, 참 난감합니다.

    일단 화면에만 잘 작동하면 퍼블결과물 나오고 끝이라는 마인드가 있어요.

    그걸 끝까지 완성해나아가야 하는 개발자는 빡칠 때가 한 두번이 아닙니다.

    API를 여러개 사용하다보면 호환성 문제가 있습니다. 그런데 그런 호환성 문제를 충분히 확인하지 않았거나 API 사양만으로는 요건에 충족하지 못하거나 실제 개발 과정에서의 데이터 연동에서의 어떠한 문제점이 있는지 확인도 안 하더군요.

    위에 댓글 중에 마요네즈송님의 예화처럼 잘 모르실 수 있는데요, 그러니 JS하지 말라는 모 개발자의 심정이 이해가 가는 겁니다.


이 바닥에 있으면서 출처가 명확하지 않은 단어들이 업계에서 사용되는 걸 보고 처음에 의아해한 적이 있는데 그게 바로 '서버단', '클라이언트단', '네트워크단'이다. '단'은 여러군데에서 사용되고 있어 그 의미가 정확히 무슨 뜻인지 아느냐고 물어보면 다들 "그냥 그렇게들 쓰고 있는데요?" 하며 개의치 않는 분위기이다.


처음 '단'에 관한 이야기를 들었을 때 어떤 개발 영역의 단체를 뜻하는 것으로 생각했었다.


예를 들어 사람들이 '클라이언트단' 이라고 할 때에는 '클라이언트단에서 처리할 것이 별로 없다. 다만 서버단에 부하가 많다는 게 문제이다'와 같이 이야기한다고 하자. 여기서 쓰이는 '단'은 왠지 '집합'적 의미가 있어 보인다. 그럼 '둥글 단(團)'을 쓰는 게 맞는 것처럼 보인다. 예를 들어 사기단, 사절단, 도박단, 사업단 같은 것처럼. 하지만 '측'이라는 의미도 매우 강해보인다. 인용한 부분을 '측'으로 치환하면 '클라이언트측에서 처리할 것이 별로 없다. 다만 서버측에서 부하가 많다는 게 문제이다'처럼 말이 가능해진다. 그렇다면 '측'이 맞는 말이 아닐까?

아쉽겠지만 위의 논의와는 전혀 상관없이 사실 이 '측'과 '단'의 문제는 실제로는 영어 번역에서 온 문제이다. '측'은 'side'를 번역할 때 온 것으로 한자로는 '곁 측(側)'을 쓴다. '단'은 'level'을 번역할 때 온 것으로 한자로는 '층계 단(段)'을 쓴다. 즉 '클라이언트단', '서버단'은 각각 'client level'과 'server level'의 번역인 셈이다.

'측'은 대립되는 사물의 어느 한 쪽을 나타낼 때, '단'은 '계단'에서처럼 여러 개로 나뉘어진 경우에 쓴다.

따라서 엄밀히 말하면 예로 들었던 '클라이언트단에서 처리할 것이 별로 없다. 다만 서버단에 부하가 많다는 게 문제이다'라는 말은 다시 말하면 '데이터가 클라이언트를 거쳐 서버를 거친 후 어디론가 가는데, 클라이언트를 거칠 때에는 처리할 게 별로 없지만 서버를 거칠 때에는 처리가 많아 부하가 많다.'는 말로 풀어서 쓸 수가 있다.

그런데... 사실 '단'을 쓰는 게 그다지 안 어울리는 건 사실이다. 계단, 상단, 중단, 하단이라는 말은 그간 사용되어 온 말이기 때문에 어울리지만 '클라이언트단'은 왠지 어딘가 모르게 어색하다. '계층'이라는 말은 'layer'라는 말에 대한 번역으로 쓰이고 있기 때문에 이도 어쩔 수 없고 대표적인 level의 한국어 번역인 '수준'이라는 말을 쓸 수도 있지만 '수준'이라는 말이 가져다주는 뉘앙스, 이를테면 '수준이 낮다', '수준이 높다'처럼 상당히 위화적인 표현으로 대한민국 사회에서 굳어져 있어 알맞지 않다.

차라리 '단계'라는 말이 좀더 어울리지 않을까?


아직 수년차에도 접어들지 못한 초보 개발자이지만 직관적이고 익숙해지지 않아도 어색하지 않을수 있는, 입문자들도 쉽게 이해할수 있는 개발용어가 사용되길 기대해본다.

  • 지나가는사람 2013.03.27 22:30

    현장에서는 그 '단'을 무지 많이 사용하죠.ㅋ
    프레임워크단, 어플리케이션단, 화면단, DB단, 내딴 니딴 ...

  • 신입사원 2013.09.23 16:53

    회사에서 과제로 서버단에 대해서 발표하라고 해서 무슨말인지 인터넷을 한참을 찾아다녔는데

    정말 좋은 답변입니다.

    감사합니다. ^^

  • Aris 2014.05.03 11:39

    번역상에서 오는 문제들과 업계들간의 용어 남발로 절차가 뒤죽박죽 되는 경우가 많긴 하죠 mvc 방법론에서 모델단 뷰단 컨트롤러단 등으로 시작된게 아닌가 싶은데 확실치는 않군요... 글 재미있게 보고 있습니다. 감사합니다.

  • 유분수 2014.10.01 16:47

    백번 공감하고 갑니다. 괜히 원서로 공부한번 더 하는게 아니죠 기술서나 표준절차성등, ㅋ 잘 보규 가요

  • 하헤히호후 2015.11.30 14:52

    서버 클라이언트도 우리나라 말이 아닌데 레벨붙여서 서버레벨 클라이언트레벨 하면 안되나요 ??

누구나 알다시피 최근 웹 기술의 경향은 단연 클라이언트 쪽에 집중되어 있다.

수 년전을 비교해 보면 엄청난 변화이다. 웹 개발은 크게 프론트엔드와 백엔드로 나누어져 있지만, 국내에서는 프론트엔드 보다 백엔드 개발자 흔히 '웹 프로그래머' 혹은 '웹 개발자'라고 부르는 사람들의 가치가 더 높았다. 다시 말해서 몸값이 더 비쌌다는 이야기다.

하지만, 웹 프론트엔드가 더 복잡해지고 다양한 기술이 쏟아지면서, 프론트엔드 개발자에 대한 수요와 가치가 증가하였고, 이쪽 기술 직군의 정의가 점점 어려워지고있다.

과거 프론트엔드 개발자는 백엔드 개발을 할 기술이 없거나 그 전단계에 하는 견습 정도로 여겨지곤 했었는데, 이와 달리 현재에는 백엔드 개발이 어려워서 이거나 프론트엔드 개발이 쉬워서가 아닌 프론트엔드 개발 자체가 좋아서 프론트에 남아서 개발을 하는 개발자가 많다. 


웹 프론트엔드 직군이란?

2000년대 초반만 하더라도 웹 개발에서는 웹마스터, 웹개발자, 웹디자이너로 나눠져 있었다. 대부분 웹 디자이너가 마크업을 담당했는데, (웹 표준 마크업의 주요성이 덜할 당시) 효율성을 위해 웹 디자이너가 만든 PSD 파일을 짤라서 HTML로 코딩만 하는 'HTML 코더'라는 직종이 있었다.

하지만, 2000년대 중반 부터 웹 표준 마크업의 중요성이 대두되면서 포털 업계를 중심으로 'UI 개발' 직군이 중요한 화두로 떠 오른다. (X)HTML과 CSS를 중심으로 DOM을 핸들링하는 자바스크립트까지 다루는 기술셋을 가진 개발자들이다.


역할에 따른 모델 제안
분명한 사실은 HTML/CSS/JS 기술을 떠난 프론트엔드 개발은 불가능하다. 요즘에는 게임도 웹으로 만들고 2D/3D 그래픽도 웹으로 하는 시대다.

 

 

습득 요구 지식

특징 

   HTML 코더

 HTML, CSS

 테이블 기반 코딩을 주로 하는 2000년대 초반의 프론트 엔드 개발자가 주로 HTML 코더였는데, 현재 업계에서도 어느정도 남아있는것 같다.

   웹 퍼블리셔

 HTML, CSS, 

웹표준, 웹접근성, 크로스 브라우징

 웹 표준이 중시되면서 생기기 시작한 직군. HTML,CSS를 이용한 페이지를 출판하는 일을 한다. 

   UI 개발자

 HTML,CSS, 웹표준, JavaScript

웹 표준에 기반한 사용자 UI를 개발한다 

   RIA 개발자

 플래시, FLEX, AIR, Silverlight

데스크탑 리치기술을 이용하여 보다 다양하고 인터랙티브한 웹사이트를 만드는 직군. 

   프론트 엔드 개발자

상위 능력 전반과 백엔드 영역 능통 

프론트 엔드 개발자라고 적어놓고 위 능력들을 고루 갖추었다고 써놓았는데, 사실 그렇다고 위에 있는 개발자들이 프론트 엔드 개발자가 아니라는 것은아니다. 필자 개인적인 생각으로 이정도는 해야..진정한 프론트엔드 개발자라고 할수있지않을까하는 개인적은 생각을 반영하여 작성해보았다. 



위에서부터 순차적으로 습득 요구 지식이 어느정도 누적 되는 것을 볼수있는데, 


코더 -> 웹퍼블리셔 -> UI개발자 -> (RIA개발자) ->Front-End 개발자


순으로 능력을 덧붙이며 한단계씩 발전한다는 느낌이 강하다.


필자 개인적인 생각으로


HTML 코더나 웹 퍼블리셔 역시도 프론트 엔드 개발자라는 생각은 변함이 없고, HTML,CSS를 등한시 하는것은 아니지만,


HTML,CSS만 할줄 아는 사람과 HTML,CSS,JS를 모두 하는 사람을 동등하게 바라볼 생각은 없기에,


웹 퍼블리셔 까지는(HTML코더는 더더욱,) 미완성의 프론트 엔드 개발자가 아닐까 생각해본다.


[웹 퍼블리셔가 프론트 엔드 개발의 제일 윗단으로, 기획과 디자이너와의 조율을 한다는 견해도 있으나, 필자 경험상 그런 역할은 주로 PL이 맡아서 하는 경우가 대부분이었다.]



웹 FT의 미래는 더 밝다!
프론트엔드 개발자보다 백엔드 개발자들의 몸값이 높고, 백엔드 중에서도 자바나 닷넷 개발자가 PHP나 Python을 쓰는 개발자 보다 몸값이 높은 아이러니한 상황은 국내만의 이상한 현상이다. (웃긴 건 Yahoo, Facebook , Twitter모두 PHP를 주력 개발 언어로 쓴다.)

아직도 "HTML이나 자바스크립트 하는게 뭔 개발이야?"라고 하는 분들께 나는 꼭 이 한마디를 보태 드린다. "구글에서는 아이비리그 나온 박사들도 다 HTML이랑 자바스크립트 해야 하거든요?"







  • 진실을 말해줄게 2013.07.22 00:55

    에효~ 하지만 실상은 당신이 말한 프론트 엔드 개발자 정도 되면 역관광 당합니다.
    그리고 당신이 말한 프론트 엔드 개발자 정도의 스킬이면 백엔드 개발자는 대체 뭘합니까?
    설계하는 것도 아니구요.
    비즈니스 로직이 아니고 일반적인 웹 개발자로서의 로직은 매우 단순합니다.
    게시판 말고 특별히 뭐 있나요? 다양한 환경에서 게시판 만드는게 다 아닌가요??
    저기까지 선 그어놓으면 오히려 백엔드 개발자는 뭐합니까?
    뭐 자바 만지면 대단한 벼슬입니까?
    PHP 든 코볼이든 자바든 C 든 어떤 언어든 무시할 건 못됩니다.
    해당 언어는 도구일 뿐이지 그 도구를 안다고 해서 당신이 크리에이티브한 사람이 되는건 아닙니다.
    이러니 웹 개발자가 무시당합니다.
    퍼블리셔 있는걸 고맙게 생각하세요.
    그 사람들 없으면 그거 다 백엔드가 해야하니까

    • 이나라학생 2013.07.22 21:47 신고

      난독증이있으신거같네요^^

  • script_kiddie 2015.06.20 18:39

    ㅋㅋㅋ 난독증 있으신듯

나는 front-end 개발자 일까? back-end 개발자 일까?


IT관련 일을 해보신 분들은 많이 들어본 이야기 일것 같다.

왜 FE(front-end) 와 BE(back-end) 를 나누어 놓았을까?

개발자로서의 기술적 능력의 높고 낮음을 구분하고 싶어서 였을까?


다른 분류 방법을 제외 하고 단순 FE 와 BE 만을 가지고 이야기 하고자 한다.

FE 와 BE 개발자는 조금씩 다른 언어로 개발을 한다고 생각한다.


일반적으로 다음과 같이 통용된다.

FE : html, css, javascript

BE : server side scripts(asp, php, jsp ..),  java 


이런 분류법이 꼭 맞는건 아니다.

다만 내가 경험해본 IT 쪽 사람들이 자기는 FE 개발자고 BE 개발자라고 말하는 사람들의 개발 언어를 살펴본 내용을 바탕으로 정리를 해본 것이다.


과거에는 FE 라 하면.. 크게 기술을 요하지 않는다고 생각을 많이들 했었다고 생각 한다.

(논란이 있지만 사실이기도 하다. UI적인 대부분은 플래시가 담당하고 있었고, 레이아웃은 소위 말하는 '테이블 코딩'이 

모든걸 해결해주고 있었다.)

BE 는 특정한 기술을 요구하고 또한 개발하는데 어려움이 많다고도 여겼던게 사실인것 같다.


그럼 지금은 어떤가?

지금은 개발자간 기술의 벽이 많이 허물어 지고 그 차이도 크지 않다고 생각 한다.

이제는 프론트엔드의 영역이 웹 표준과 접근성에서부터 dynamic UI/UX에 web Application까지 다양해지며
프론트 영역이 결코 만만한 부분이 아님을 다들 인정하는 분위기다.

다만  FE 와 BE 를 구분짓고 나는 BE 개발자이니 FE 는 내가 알바 아니다 라고 얘기 하는 사람, FE 개발자이니 BE 는 내가 알바 아니다 라고 얘기 하는 사람이 있다면 당장 생각을 고쳐 먹어야 한다고 생각 한다.

적어도 IT 에서 일을 하는 사람이라면 말이다.


서비스를 만드는데 FE 가 어딨고 BE 가 어딨겠는가.

서로 서비스에 대한 needs 와 requirements 를 잘 이해하고 user interaction 에 잘 부함되는 서비스가 될수 있도록 상호 긴밀한 협동을 해야 하는게 아닌가.


분야의 다양성과 각자의 능력에는 차이가 있다는것은 분명히 인정하는 부분이다.

하지만 같은 서비스를 만들면서 FE 니 BE 니 설왕설래 하는건 에너지 낭비며 web2.0 시대에 개발자가 가져서는 안되는 정신 같다.


서로 같은 분야에 종사하며 개발자로서의 삶을 살아 간다면 다 같이 win win 하는 그럼 마음 가짐을 가졌으면 좋겠다.