지난 5월 31일 몇가지 논의를 위해서 AJ의 주도로 마크업을 위주로 하시는 분들이 많이 모여있는 Clearboth와 제가 속해있는 FRENDS가 번개식으로 MeetUp을 가지고 이런저런 논의를 하던 중에 프론트앤드영역에 롤(role)과 호칭에 대한 얘기가 나왔습니다. 프론트앤드쪽에선 오랜 논쟁거리중 하나인데 모임 뒤에 트위터로 그부분에 대한 업급을 하기 시작하면서 이 호칭문제가 오늘 트위터에서 뜨거운 감자로 떠오르고 하루종일 많은 사람들이 참여하며 얘기가 오갔습니다. 많은 프론트앤드 종사자들이 이 부분에 대해서 의견을 나누면서 Channy님이 RFC- 웹 프론트엔드 개발자에 대한 소회라는 글로 더 많은 의견을 요청하는 글을 올려주셨고 프론트앤드쪽에 이름있는 분들도 많은 의견을 내주셨습니다.(감사하게도 Channy님이 해당 글들을 모으는 작업을 해주셨습니다.)
이왕 뜨거운 감자가 된 마당에 저도 이 논의에 참여해 보고자 포스팅을 작성합니다. 사실 저는 이 블로그에서 좀 객관적으로 팩트 위주로만 글을 올리는 편이었는데 때로는 논의가 좀 더 적극적으로 진행되기 위해서는 약간 적나라한 의견을 내는것도 좋다는 생각이 들어서 약간의 비난(?)을 감수하고 포스팅을 하게 되었습니다.언젠가 SNS에서 본 국내 오픈소스에는 트롤이 좀 필요하다는 말이 생각납니다. 전 뭐 그럴 성격도 못되지만 해외 메일링같은 경우도 누군가 격렬히 비난하면서 많은 논쟁이 시작되곤 하죠.(제가 그럴꺼라는건 아니고요 ㅎ)
저는 웹개발자입니다. 굳이 분류하자면 서버사이드 개발(즉 백앤드)에 근본(?)을 두고 있고 시작도 서버사이드로 시작했고 서버사이드 개발을 해서 생계를 유지하면서 살고 있습니다. 그럼에도 프론트앤드 개발에 많은 관심을 가지고 있고 다양하게 만져보는 것은 프론트앤드부터 백앤드까지 전부가 웹개발의 범주에 포함되기 때문이지만 아무리 관심을 가지고 있다고 하더라도 기본적으로 서버사이드에 종사를 하고 있기 때문에 프론트앤드 종사자분들이 겪고 있는 현업에서의 고충을 제대로 다 이해하고 있다고 보기는 어려울 수도 있습니다.(그래도 프론트앤드에 애정만큼은 지지 않는다 생각합니다. ㅎ 사실 돈벌어주는 서버보다 프론트앤드를 너무 좋아해서 문제죠. ㅋ)
어떻게 불러야 할 것인가...
앞에서도 얘기했지만 이 호칭문제는 하루이틀 논의된 주제가 아닙니다. 과거에는 HTML 코더라고 불리었었고 지금은 웹퍼블리셔, UI개발자, Javascript개발자, 프론트앤드 개발자등으로 다양한 호칭이 프론트앤드 영역에서 사용되고 있으며 혼용되서 사용되거나 영역에 따라 분리되거나 해서 사용하고 있습니다. 많은 용어가 있음에도 각자 자신의 회사에서 사용하는 용어를 그대로 사용하거나 각자 좀 다른 의미로 사용하고 받아들이는 사람도 자신의 기준으로 받아들이기 때문에 이 호칭에 대한 통일이나 정확한 인식의 확산은 필요한 부분이라고 생각합니다.
저같은 경우는 Toby님의 나는 코더다라는 글에 동의하고 있기 때문에 코더라는 말이 격하하는 의미로 사용되고 있다는 것에 약간의 안타까움을 느끼고 있지만 프론트앤드 영역의 과거상 좀 예민한 용어이기 때문에 상대방이 어떻게 받아들일지 몰라서 잘 사용하고 있지는 않았습니다.
저는 보통은 프론트앤드 영역을 개발하는 사람들을 퍼블리셔라고 불렀던 것 같습니다. 과거에 제가 그 용어를 블로그에서 사용하면 퍼블리셔라는 용어를 별로 좋아하지 않는다는 피드백을 종종 받고는 했지만 다른 말은 딱히 생각나지 않았었고 신현석님이 만드신 이 "웹퍼블리셔"라는 말은 제 입장에서는 상당히 괜찮아 보이는 말이라고 생각하고 있었고 HTML이나 JavaScript영역에 대해서 낮게 취급하거나 하지 않는 저로써는 이 단어가 격하해서 부른다는 느낌도 전혀 없었기 때문입니다. 그리고 지금의 회사외에는 JavaScript를 주업무로 하는 개발자들을 따로 둔 곳을 보지 못했기 때문에(포털을 제외한 국내 대부분의 업체가 그러할테고요.. 물론 최근에는 많이 달라지고 있습니다.) 프론트앤드 영역에서 퍼블리셔외에 다른 호칭을 추가로 사용해야 한다고 느껴지지 않았던 것 같습니다.(아직 호칭이 논의중이고 글의 내용상 이글에서도 퍼블리셔라는 용어를 그대로 사용하겠습니다. 양해를...)
현재는 프론트앤드 개발자라는 용어를 많이 사용하는데 FRENDS가 구성되면서 그동안 제가 만나봤던 퍼블리셔와는 약간 다른(?) 개발자들을 만나면서 그분들이 프론트앤드 개발자라는 용어를 주로 사용하였기 때문에 익숙해졌습니다. FRENDS에 있는 사람들은 프론트앤드영역에서도 대부분 JavaScript에 좀 특화된 특징을 가지고 있었고 그전까지 제가 보던 웹퍼블리셔의 범주를 훨씬 뛰어넘어서 필요한 건 어떤 기술이든 다 끌어다가 사용하는 것을 보면서 기존에 사용하던 것과 다른 호칭이 필요한 것을 무의식중에 느낀 것 같고 FRENDS 사람들이 주로 사용하던 프론트앤드 개발자라는 용어를 받아들였던 것 같습니다.
그러면서 언제부터인지 모르게 JavaScript까지 능수능란하게 다루는 사람을 프론트앤드 개발자로.. 그렇지 않은 제가 기존에 알고 있던 퍼블리셔들은 그대로 퍼블리셔로 나누게 되는 선을 그어버리게 되었던 것 같습니다. Clearboth 사람들과 만나서 이런 얘기를 하던 중에 문득 이부분을 깨달았습니다. "어? 내가 언제부터 이 두가지를 따로 생각하게 되었지?"하는 생각이 들면서 약간 당황했지만 하루종일 이부분에 대해서 많은 고민을 했습니다.
아무래도 서버사이드부터 시작을 하고 근본을 두고 있어서 그런지 AJ가 그러했던 것처럼 저도 프로그래밍과 마크업의 선을 그었던것 같습니다. 일반적으로 비즈니스로직을 가지고 있는 코딩과 프리젠테이션 영역을 담당하는 마크업과 스타일링을 경계로 생각하고 있었는데 이부분은 지금도 상당히 고민인 부분입니다. 웹사이트가 만들어지는데 디자인부터 디비까지 다 필요한데 디자이너를 디자이너를 부르고 DBA를 DBA라고 부르는건 괜찮은데 퍼블리셔를 퍼블리셔라고 부르는건 왜 격하하는 발언이 되어야 하는 것인가 하는 의문이 솔직히 있습니다. 크게보면 모두가 다 개발의 범주에 들어가지만 DBA를 개발자라고 부르지 않는다는 것과 비슷하지 않나 생각하고 있습니다.
그러면 이것은 호칭의 문제인가...
이번에 새로 대두된 문제가 아니기 때문에 트위터에서 많은 얘기가 오갔다고 하더라도 명쾌한 결론이 난 것은 아닙니다. 하루종일 머리아프게 많은 고민을 하기는 했지만 아직도 제대로 정리가 다 안되었는데 이 글 자체도 토론의 과정이라고 생각하기에 고민하는 생각들을 그대로 쓰려고 합니다.
오랜 고민을 해보았는데 이게 호칭의 문제가 아닌것 같다는 생각이 들었고 근본적으로는 파워게임의 문제가 아닌가 하는 생각이 들었습니다. 다른 말로 하자면 프론트앤드영역이 웹에서 그 중요도에 비해서 제대로된 대우를 받지 못하고 있다는 것이 호칭뒤에 숨겨진 핵심 이슈가 아닌가 생각하고 있습니다. 만약 그렇다면 이 문제를 해결하는 것은 단순히 서로 합의된 호칭을 정하는 것이 아닌 상황을 개선하는 쪽으로 방향이 잡혀야 하는 것 같습니다. 어찌보면 HTML코더에서 웹퍼블리셔라는 이름으로 바뀌었음에도 비슷한 이슈가 계속되는 것자체가 이부분이 해결되지 않았기 때문이 아닌가 생각합니다.
제 경험상의 개발과정을 보면 디자이너가 디자인을 하고 퍼블리셔가 마크업에 CSS로 스타일링을 하면서 크로스 브라우징 작업을 하게 되고 이부분을 서버사이드 개발자가 받아서 서버쪽 로직을 모두 작업하면서 그 결과내용을 HTML파일 내에 조합하고 동적인 부분에 대해서 JavaScript작업을 해서 딜리버리 하는 순서로 이루어졌습니다.(대부분 비슷하리라 생각을 합니다.)
이 과정을 보면 전체 Flow중에 서버사이드 개발자가 관여하는 영역이 훨씬 넓게 분포해 있다고 생각됩니다. 퍼블리셔가 작업을 하는 영역과 비교해서 넓게 관여하고 있으며 실제로 결과 마크업도 동적으로 만들기 위해서 서버사이드 개발자가 마지막으로 다루게 되고 서비스로 딜리버리 하는 것도 서버사이드에서 책임을 가지고 있습니다. 이건 서버사이드가 프론트앤드보다 더 중요하기 때문이 아니라 오래전부터 자리잡은 개발관례상 서버사이드가 더 많은 비중을 가지고 있기 때문이 아닌가 하는 의문이 들었습니다.
사실 제가 느끼기에는 서버사이드 개발자들은 일반적으로 프론트앤드 영역에 그다지 관심을 가지고 있지 않습니다. 그럼에도 예전에 CS개발자들이 웹개발자들을 무시했듯이 지금은 서버사이드 개발자들이 이상하게 프론트앤드 영역을 무시하는 문화가 있습니다. 물론 이런 마인드를 가진 서버개발자중에 기본적인 프론트앤드에 대한 지식(DTD가 무슨 역할을 하는지 웹표준은 왜 준수해야 하는지, JavaScript는 왜 unobtrusive하게 작성해야 하는지 등)이 그다지 없으면서 단순히 문법정도만 알면서 하는 것이기 때문에 중요하게 생각할 부분은 아니긴 하지만 그와 상관없이 보통은 프론트앤드에 대해서 깊게 알고 싶어하지도 않습니다.(전반적인 풍토를 얘기하는 것입니다.) 저같은 경우는 프론트앤드영역을 무시하는 개발자들의 말을 들으면 순간 울컥하면서 그사람에 대해서 평소 생각하던 레벨을 2단계정도 하향조정하고는 하지만 어찌보면 자신들의 주 업무영역인 서버사이드의 영역이 아니기 때문에 당연할 수도 있다고 생각합니다.
영역이 넓어져야 합니다.
프론트앤드 영역에 대한 퀄리티 책임은 프론트앤드가 모두 가져가야 한다는 것이 제가 가진 기본적인 생각입니다. 작년에 FRENDS모임을 할때 Boxersb님이 기술발표모임에서 자바의 템플릿엔진인 Apache Velocity에 대해서 발표하는 것을 보고 프론트앤드 영역에 대해서 더 많은 책임을 가지기 위해서 Velocity까지 공부한다는 것에 대해서 상당히 놀랬었던 기억이 납니다. 프론트앤드영역을 제대로 책임지기 위해서는 그것에 관련된 기술까지도 통째로 끌어안아야 하고 그럼으로써 프론트앤드 개발자들의, 다른 말로 하면 퍼블리셔들의 영역을 스스로 높일 수 있다고 생각합니다. 지금처럼 디자인이슈가 없는 관리자페이지는 서버사이드개발자들이 알아서 다 해결하고 유저서비스단의 프론트영역만 가져가는 것도 좀 문제가 있지 않나 생각합니다.
서버사이드 개발자들이 프론트앤드에는 그다지 관심이 없다고는 했지만 여태 "내가 JavaScript를 짜야되냐"고 말하는 서버사이드 개발자는 여태 단한번도 보지 못했습니다.(힘들다는 소린 많이하죠.) 그런데 프론트앤드에 종사하고 있는 퍼블리셔들 사이에서는 어째서 "JavaScript를 해야하는가?"라는 질문이 나와야 하는 것일까요? 더 좋은 대우를 받으려면 더 많은 영역에 관여를 하고 퀄리티를 높여야 하는 것은 당연한 수순입니다.
그렇다면 프론트앤드가 왜 서버사이드보다 덜 중요한 취급을 받아야 하냐는 질문은 좀 의미없지 않나 생각합니다. 과거에는 웹표준이나 크로스브라우징에 대한 이슈들에 대해서 중요하다는 인식을 주기위한 움직임이 많이 필요했습니다. 물론 앞으로도 개선이 더 많이 필요하지만 웹브라우저전쟁이 다시 시작되고(국내에는 물론 ActiveX라는 큰벽이 있지만요.) HTML5의 등장으로 인해서 업계에서도 프론트앤드에 대한 비중도 상당히 많이 올라갔다고 생각하고 그부분을 모르는 사람도 시각적으로 느낄수 있게 해줄수 있는 기술들이 다양하게 갖추어져 있습니다.(얼마전에 어떤 아주머니가 다른 사람한테 크롬브라우저라는 걸 깔면 엄청 빠르데라는걸 듣고는 상당히 놀랬던 기억이 납니다.)
전에는 어떻게?를 고민해야 했다면 이제는 영역을 확대할 수 있는 방법들은 수없이 많이 생겼다고 생각합니다. 심지어 몇년내에는 프론트앤드에서 SQL쿼리까지 작성해서 만들어야 합니다.(비록 여러 이슈로 표준스펙에서는 아웃되었지만요.) 모임때 rootbox님이 말씀하셨던 것처럼 퍼블리셔가 더 많은 롤을 가져가게 되면 자연히 회사내에서 위치는 올라가게 마련입니다. JavaScript를 포함해서 뷰단을 모두 퍼블리셔쪽에서 가져가겠다는데 (비록 새로운 방식에 대한 불안감이 있을 지언정) 반대할 서버사이드 개발자들은 없을꺼라고 생각합니다. 업무 덜어준다고 더 좋아하겠지요. 프론트앤드 기술에 관심이 많은 저로써도 최근에는 프론트앤드 기술들이 너무 다양해지고 깊이가 깊어져서 슬슬 서버사이드랑 병행하기가 버겨워 지고 있습니다.
Epilogue
직접 프론트앤드에 종사하지 않는 입장에서 어쩌면 알아서 확보하라는 식의 무책임한 발언을 했는지도 모르겠습니다. 저도 개발자인데 업계상황을 모르는건 아닙니다. 지금도 야근하느라고 힘든데 여기서 일을 더 가져온다는건 생각도 할 수 없을수도 있고 위에서 꽉 막힌 마인드가 자리잡혔거나 개발팀과 대화가 제대로 되지 않아서 영역을 넓히는게 너무 힘들수도 있습니다만 제가 말하고자 하는 것은 목표점에 대한 생각입니다. 일이 더 잘 이루어지고 더 좋은 결과물이 나오는데 싫어할 오너나 관련자들은 없습니다.
물론 단기간에 한꺼번에 도달할 수 있는 목표는 아닌 것은 알고 있습니다. 그렇기 때문에 결론은 나오지 않았어도 현업개발자들이 주축이 된 이 논의 자체가 너무 좋습니다. 지금의 웹표준이나 크로스 브라우징에 대한 인식이 많이 좋아진것도 일부 의식있는 사람들이 열심히 홍보하고 활동한 것들이 쌓인 결과라고 생각하고 있습니다. 가만히 있는데 위에서 알아서 중요한 위치에 배정해 주고 좋은 대우를 해주는 일은 없을꺼라고 생각하고 그런 일은 발생하지 않습니다. 지금의 좋지않은 인식과 환경을 가장 잘 알고 있는 것은 현업에 있는 사람들이고 그들만이 그렇게 할 수 있으며 현업에서 직접 움직여서 바꾸었을때 더 좋은 환경에 도달할 수 있다고 생각합니다. 한두사람만으로는 아무것도 할 수 없을지 모르지만 목소리가 모이고 움직임이 누적되기 시작하면 상황은 바꿔나갈 수 있다고 생각합니다.
덧) 현업에 종사하는 퍼블리셔분들을 격하하거나 비난할 의도는 전혀 없음을 말씀드리고 싶고 다른 생각이나 잘못된 부분이 있으시면 언제든지 의견 환영합니다. 이래야 한다고 얘기한다기 보다는 전 이렇게 생각합니다!라는 의견으로 바주시고 더 많은 논의가 되었으면 좋겠습니다.
Outsider's Dev Story
Stay Hungry. Stay Foolish. Don't Be Satisfied.
이 글에 나온 Toby는 제가 아니고 원조 토비님이군요 ㅎㅎ
퍼블리셔들이 js 꼭 해야 하는가? 라는 반응을 보이는건 그들의 커리어가 개발에서 출발하지 않았다는 점에 있는 것 같습니다.
저도 그렇구요.
개발자 입장에선 HTML, CSS도 개발의 일부지만,
퍼블리셔 입장에선 어떠한 로직이 없는 순수한 마크업과 스타일링의 영역인거죠.
js로 넘어가면서 굉장히 다양한 개발 방법론이 있는 '언어'단계로 들어가는데 그 시작이 쉽지 않아 큰 장벽으로 느껴지게 되구요.
실제로 저도 js가 너무 너무 어렵습니다.
다양한 경우를 고려하여 최적화된 코드로 작성하는 '개발자' 수준의 코드를 짜려면 언제쯤이 될까 까마득 합니다.
또한 주변에서 계속해서 js를 권유하기 때문에, 이제는 반사적으로 그런 이야기에 반감이 생기는 단계까지 온 사람들이 많습니다.
좀 더 솔직한 표현으론, js를 학습하고 싶지 않고 변화를 강요받는 것이 불편한 퍼블리셔가 많은 것이죠. 사실입니다.
반면에 퍼블리셔 그룹안에서도 이런 개발자들의 생각에 동의하는 사람들이 있습니다.
js 배우기 싫어하는 다른 퍼블리셔들의 태도를 안타까워 하며, 나는 빨리 js익혀서 업그레이드 되어야 하는데. 라는 생각을 하지요.
이 들은 '퍼블리셔'라는 명칭으로 불리면 마치 내가 개발 배우기를 싫어한다는 오해를 받고 있는 것 같은 느낌이 들어서. 그 명칭으로 불리지 않기를 바랍니다.
그러니까 '퍼블리셔'라고 불리기를 싫어하는 것은 퍼블리셔들의 자격지심. 맞습니다.
하지만 js 배우기 싫어하는 퍼블리셔들의 입장은...
"이미지 자르고, HTML/CSS 코딩하고, 크로스 브라우징 하는 것 만으로도 이미 충분히 많은 일을 하고 있는데. 웹표준 따라 시맨틱하게 작업하는 것도 쉽지 않은데 js까지?
지금도 바쁜데 뭘 더해야 된다고... 게다가 박봉인데!"
이 업무는 개발능력이 향상되어도 소요시간이 짧아지지 않는 일이죠.
지금의 방식대로 앞으로도 누군가는 계속 해야하는 일인겁니다.
그러니 이들이 개발을 배워서 프론트엔드개발자로 거듭난다고 해도.
퍼블리셔라는 업무 영역은 없어질 수 없는 것이지요.
지금의 퍼블리셔들이 모두 프론트엔드개발자가 되면 좋겠지만,
현실적으로 시스템화 하기에는 제시된 목표를 따라올 수 있는 작업자의 비율이 너무 적을겁니다.
아니면 디자이너가 이미지 슬라이싱을 한다?
제대로 하려면 디자이너가 퍼블리셔가 되어야 합니다.
제가 디자인을 했을 때의 경험을 생각해보면... 디자이너가 퍼블리싱 하면 디자인에 집중하기 어렵습니다. 퍼블리싱을 배우면 디자인 능력이 떨어지는게 아닌가 싶을 정도로 디자인과 퍼블리싱은 사고하는바가 다른 것 같습니다.
그래서 제 생각으론, 결국 퍼블리셔는 없어질 수 없는 포지션입니다.
하지만 부정적인 인식이 많은 단어로 굳어진 만큼 '프론트 엔드 개발자'로 묶어서 불러주고.
그 안에서 '마크업개발자'라는 서브 호칭으로 분류하는 것이 이상적이지 않을까 싶네요.
트롤이라고 하셨는데, 저는 좀 더 부정적인 용어들을 사용해서 폭로하듯이 댓글을 달았네요.
어쩌면 이런 표현은 문제 해결에 도움이 되지 않을 것 같기도 합니다.
정말 해결이 되려면 개발자들이 퍼블리셔들을 인정해주고 포용해주는 방식이 이상적일테지요.
js 배워야 뒤져치지 않는다고 스트레스 주지 않고, '마크업 잘 하시는 분들 부러워요' 식의 립서비스를 해주는게 정말 공생할 수 있는 길일 것 같아요.
그렇게 화합한 상태에서 함께 '프론트엔드 개발자' 직군의 가치를 올리기 위해 자신의 자리에서 최선을 다하는게 제일 좋겠지요.
그부분도 얘기하려고 했었는데 정리해놓고 글을 장석하지 않았더니 고민중에만 생각하고는 빠뜨렸네요. 말씀하신것 처럼 퍼블리셔에는 프로그래밍쪽에 베이스를 가진 사람과 디자인 혹은 그외 프로그래밍에 베이스가 없던 사람들이 같이 있는것 같습니다. 그렇다보니 프로그래밍으로의 개념의 전환을 하기가 어려운 것같은데 제가 직접 경험하고 있는 부분이라 고민은 되는데 딱히 어떤 해결책(?)들이 있을지는 잘 모르겠습니다. 더 논의되어야 겠지요
저도 퍼블리셔가 없어질 포지션이라고 생각지 않고 js에 비해서 더 낮은 포지션이거나 쉬운 업무라고는 생각지 않습니다. 시맨틱한 마크업과 크로스 브라우징이 상당히 고난이도 테크닉이라 생각하고 있지만 국내 환경상 단순반복작업이 될수도 있다고 생각되지만 이 논의하고는 약간 다른 부분이고 사실 어느 프로그래밍도 업무는 단순업무로 변해버리곤 하죠.
변화를 가지려면 포션을 더 크게 먹어야 한다는 거고요. 반드시 모든 퍼블리셔가 JS의 영역까지 넘어와야한다고는 생각지 않고 갈수록 한명이 다 커버하기에는 쉽지 않은 규모가 되어가고 있습니다.(이해는 있어야겠지요.) 프론트앤드 개발자중에 마크업을 잘하는 사람이 있고 JS를 잘하는 사람들이 있고 CSS에 집중되신 분들이 있을수 있겠지만 전체적으로 봤을때 프론트앤드로 분류될수 있는 부분은 모두 서버에서 떼어가서 프론트앤드 개발자들사이에서 해결될수 있어야 조직도 더 커지고 목소리도 낼수 있어지지 않을까 하면서 정리했던 의견이었습니다.
딱히 부정적인 용어들로 느껴지지 않지만 좀 거친논의가 이루어지는 것도 이목도 끌수 있고 더 많은 얘기가 오갈수도 있지 않을까 합니다. 그냥 좋은글, 좋은 논의 보고 넘어가는걸 바라는건 아니니까요 ㅎㅎ
많은 부분 공감하지만.. 저는 퍼블리셔라는 포지션이 없어져야 한다고 생각합니다. 즉, HTML/CSS 만 다루는 직군이 따로 있기 보다는 한 조직내에서 Front-End 전반을 모두 다루어야 한다고 주장하는 쪽이에요~ 현재 퍼블리셔라는 포지션이 있는 이유중 하나 (JS 를 따로 생각하는 퍼블리셔분들이요..) 가 업계에서 Front-End 분야의 비중을 크게 두지 않고 있어서 라고 생각해요.. 대부분의 회사가 이런 부분만을 다루는 직군을 정규직으로 채용하지 않고 있습니다. (정규직으로 채용하는 회사도 물론 있지만..) 그래서 더욱 더 퍼블리셔분들에게 "같이 개발하자" 라고 말하고 싶은 겁니다.. 하나의 직군에서 Front-End 단을 그야말로 완벽히 커버해준다고 하면 그보다 이상적인 조합이 어디 있겠습니까.. 다만 Front-End 개발자 조직에서 마크업 과 JS 의 업무분장은 있을 수 있겠죠. 같은 조직에서 "개발자" 로서 시작하고 스킬업을 해나가며 차츰 Front-End 전반을 다룰 수 있는 역량을 키워야 합니다. 그러면 자연스럽게 업계의 인식과 처우등이 많이 개선될 꺼라고 생각합니다.
그리고 스킬업이 되어도 소요시간이 짧아지지 않는다는 것도, 이런 조직적인 문제로 자연히 해결될 수 있다 생각합니다.
마크업/CSS 의 가이드화, 버그 나 여러가지 케이스 기반 지식축적 등이 있으면 입문자도 좀 더 쉽게 개발이 가능하고, 숙련자는 보다 빠르고 쉽게 개발할 수도 있습니다. 이건 Front-End 개발자 모두가 자신이 가진 노하우를 축적하고 공유함으로써도 해결 가능할것 같네요~~ :)
예.. 전체 프론트앤드 영역으로 뭉쳐서 영역을 같이 넓여 나가야 할것 같습니다. 그 내부에선 어떻게 조직이 구성되든 어떤 롤을 하는지에 관계없이요 ㅎ
그리고 퍼블리싱이 디자인부서쪽으로 구성되어있는 조직은 빠져나와서 독립하거나 개발쪽부서로 조직구성이 되는것이 더 맞는것 같아요.
그렇군요.
퍼블리셔 커뮤니티 하코사의 전체회원이 2만3천명이 넘거든요.
그 중에 충분한 개발 능력을 흡수해서 완성형(?)프론트 엔드 개발자로 살아갈 사람은 몇명이 될까요?
퍼블리셔가 없어지지 않을 것이란 것은,
마크업+개발 양쪽을 커버하지 못하고 머무르는 비율이 높을 것이란 예상이었습니다.
하지만 저는 boxersb님이 제안하시는 그림이 좋은 것 같아요.
이상적이잖아요 ㅎㅎ
맞습니다.. 문제는 사실 우리에게 있었던거죠.. Front-End 종사자 시니어들이 앞장서서 텃밭을 일구어 나가야죠.. 그리고 그 텃밭을 다치지 않게 걷고 뛸 수 있도록 해줘야합니다.
이번에 이런 바람이 불었고 앞으로는 거슬를 수 없는 태풍과도 같은 흐름이 되면 자연히 따라오게 될꺼라고 믿어요~ㅎ
열심히 합시다!!
글이 짱길군요!! -.-;;
전 html이 자바보다 더 어려운 것 같아요.;; 글과 상관 없는 이야기 이긴 하지만@.@
요기 실콘벨리에선 백엔드 / 프론트엔드 라고만 부르고 딱히 publisher라고 는 안부르더라구요. publisher == front-end 이렇게 보구요. front-end 는 기본 적으로 php 같은 스크립트 웹언어 정도는 하는 영역?; 물론 하드코어 서버사이드 쪽은 아니지만요;;
아 댓글 정리 안되는데요 ㅎ
front-end쪽으로 전향하려고 노력하는 일인으로써!! publisher 들이 하는 간지나는 markup이나 css는 기본으로 갖추어야 하는 항목이 아닐까 싶어요..
publisher 이랑 front-end랑 굳이 나누어야 할 이유가;;; publisher 든 front-end 쪽이던 목표는 어차피 똑같고 .. 다만 한국 업종 자체가 좀 나뉘어서 예매해지는 것 같은데요..
ㅋㅋ 댓글 정신없네요 ㅋㅋㅋ 죄송합니다 ㅋ
그러게... 쓰다보니.. ㅎㅎ
마크업과 스타일링은 프로그래밍이랑 사고가 좀 다른것 같다는 생각을 좀 하고 있음.. 어려워.. ㅎㅎ
퍼블리셔는 국내에서 만들어진 용어도 프론트앤드가 낮게 보는 인식을 바꾸어보려고 만들어졌지만 결과적으로는 또다른 인식으로 자리잡혀진듯.. 이 논의 자체가 왜 퍼블리셔랑 프론트앤드가 따로 구분되어야 하는가부터 얘기가 시작된것 같아. 거긴 어때? ㅎㅎ 한국보다는 전반적으로는 낫기는 하겠지만 거기선 프론트앤드가 어떻게 인식되는지 좀 궁금하기도.. ㅎㅎㅎ
덧) 근데 publisher랑 front-end는 타입은 다른가보군...ㅋㅋㅋ (===로.. ㅋㅋ)
좋은글 잘 읽었습니다.. 아직은 미흡하지만 프론트앤드개발자란말애 동의하는 퍼블르셔 1인입니다
감사합니다.. 다같이 해결해나가고 돌파구를 마련해야할 문제인듯 합니다 .^^
웹쪽이 아니라 일반회사에서도 흔한일입니다.
자기일이 더 고귀해 보이고 어려워 보이기 마련이죠.
자기일을 더 중하게 생각하는건 개개인적인 부분같구요 완전히 다르지는 않겠지만 여기서 얘기하느건 업계의 인식에 대한 얘기입니다.
저는 거의 비슷하지만 약간은 다른 견해를 가지고 있는데요. 핵심부터 말하자면 지금의 시대는 개발 업계의 산업혁명의 시대와 같다고 생각하는 부분에 있습니다. 나쁘게 말하자면 컨베어벨트가 가능해진/필요한 시대랄까요... ㅎㅎ
다만, 산업혁명의 컨베어벨트와 다른 점이 있다면, 노력에 따라 더 높은 수준의 능력치를 얻을 수 있고, 그러기 위해서 Velocity를 예로 들으신 것 처럼 더 넓은 영역을 공부해서 자신의 능력치를 최대한 끌어낼 수도 있다는 것이겠죠. 그리고 퍼블리싱도 역시 전문영역이기 때문에, 끝없이 학습해야 하는 직업인지라.. 즉, JS를 쓰기 위한 공부가 아니라 더 퍼블리싱을 잘 하기 위해 JS등을 반드시 배워야 한다고 보고요.
추가로 약간 다른 얘기지만, 이미 백엔드쪽이 많은 세분화가 이루어져 있듯이, 앞으로 프론트엔드 개발 영역도 많은 세분화가 이루어 질 것이라고 생각합니다. 이를테면 현재의 퍼블리싱, UI 액션/애니메이션 개발, 서버연동 라이브러리 개발 등으로요. 따라서 퍼블리싱도 프론트엔드 개발 영역의 하나인데, 단지 분업화의 과정이 조금 더 분명해서 조금 일찍 분업화가 된 것이랄까요? 그리고 원래는 프론트엔드 영역에서 해야 맞는 것인데 어쩔 수 없이 또는 관성적으로 서버 영역에서 하던 것이, 기술의 발전에 의해 프론트엔드로 지속적으로 넘어오고 있기도 하고, 그래서 좀 더 세분화될 필요가 있기도 하고요.
물론 혼자서 다 할 수 있는 분도 계시겠고, 다 하면 좋기도 하겠지만, 규모가 커지면 혼자서 감당하는 것은 일반적으로는 불가능하기 때문에 아마도 개발에 대한 수요와 범위가 커지면서 점점 더 그렇게 될, 또 그렇게 하는 것이 바람직 할 것으로 보입니다.
좀 횡설수설했는데요. ㅎㅎ 요즘 이 부분에 대한 생각이 좀 있어서 다양한 방법으로 세분화를 시도해보고 있는데요. 개발해야 할 영역들을 좀 더 명확히 정의해서 설계한 다음 선을 긋고 개발을 하니까, 확실히 개발 목록이나 스케쥴들이 좀 더 명확해지는 감이 있더군요. 요즘 관심있는 주제다보니 주제넘게 댓글 한 번 달아보았습니다. ㅎㅎ
아참, 전 퍼블리셔가 일종의 기획자의 포지션에 있다고 생각하는데요. 퍼블리셔는 기획자와 디자이너, 그리고 JS개발자 모두의 사이에서, 디자인과 기획의 정확한 의도를 알고 코딩을 하는 것이 무엇보다 중요한 부분이라고 생각합니다. 따라서 퍼블리셔는 코딩 능력도 중요하지만 커뮤니케이션 능력이 다른 직군에 비해 더욱 중요한 부분이 아닌가라는 생각도 합니다. (아참, 구글이나 페이스북 오픈그래프 태그를 다는 등의 SEO 등의 능력은 기본 탑재해야 할 것 같은데 이건 많이들 생각 안하시는 것 같아요..)
저도 생각은 비슷합니다. 다만 이글에서는(아주 오래된 글이지만) 프로젝트내의 역할보다는 개인에게 좀더 초점이 있습니다. 요즘처럼 프론트엔드가 커진 상황에서 한명이 프론트엔드를 다 맞는 것은 당연히 적절하지 않습니다만 개인이 그중에 한부분만 알아야 하냐 하면 그렇지는 않다고 생각합니다. 이어서 커뮤니케이션의 중요성을 이야기하셨듯이 이부분이 되려면 다른 부분에 대해 어느정도 알고 있어야 커뮤니케이션도 원활하다고 보고 있습니다.
글에서는 그런 얘기는 안했지만 기획자 포지션도 얘기하셨듯이 프론트엔드 개발자는 UI/UX에 대해서도 어느정도 정통해야 한다고 생각하고 있습니다.(적다보니 할게 정말 많;;;)
도움도 안되는 글같은건 쓰지도 맙시다.
사람은 돈을 벌기 위해 일을 하는겁니다.
당신같은 글은 읽는 시간이 아깝네요
다른 의견을 하시려면 "돈을 벌기 위해 일한다는 당연한 얘기"보다는 좀더 자세한 논리를 얘기하시면 저나 다른 보는 사람에게 도움이 되겠네요.