Blog for QTI developers

2016/08/22

프런트엔드 엔지니어란? HTML 코더와 차이와 역할

http://html-coding.co.jp/knowhow/about_coder/front-end-engineer/ 에서 게재된 칼럼을 번역하여 올려봅니다. 프런트엔드 엔지니어라는 말을 근래에 부쩍 자주 듣는데, 무언가 애매모호한 이미지가 있습니다. 이 글에서는 프런트엔드 엔지니어(개발자)가 무엇인지에 대해서 나름 잘 정리하고 있어서 참고가 될 것 같아서 번역을 하였습니다. 일본쪽 글이라 다소 한국하고 안맞는 용어들도 있어서 한국 현실에 맞게 몇몇 용어들은 바꿔봤습니다(예를 들어 디렉터. 한국에서 전산 프로젝트에서 디렉터라는 말보다는 PM이라고 하는 것이 일반적이라 PM으로 변경하였습니다).

한마디로 요약하자면, 프런트엔드 엔지니어는 웹개발에서 전반적인 기술 지식와 컨텐츠 표현력을 가진 기술자라고 하면 되겠습니다.


요즘 수년간 프런트엔드 엔지니어라고 하는 말을 듣는 일이 많아 진 것 같은 느낌이 듭니다만, 프런트 엔드 엔지이어의 정의는 회사마다 다른것이 보통입니다.
다만 많은 경우, "JavaScript와 HTML/CSS3, PHP라고하는 프로그램 언어 등, 고도의 웹스킬을 가진 사람"을 가리키고 있고, 그 스킬들을 살려서 웹사이트를 구축하는 일의 내용이 대부분입니다. (어플리케이션 제작회사의 경우, 어플리케이션 개발의 프런트 엔드를 가리키는 경우도 있습니다.)

이 컬럼에서는 프런트엔드 엔지니어라고 하는 것은 "Web제작에 있어서 HTML/CSS는 물론, JavaScript와 각종 API, WebGL과 캔버스 등 웹사이트를 표현에서 필요로 하는 여러가지 기술 및 지식을 가지고, 그것들을 취사선택할 수 있는 사람"이라고 정의하겠습니다.

이 정의를 바탕으로, 프런트엔드 엔지니어로써 Web제작의 현장에서 일할때에 필요로 하는, 또는 알아두고 싶은 지식을 소개하도록 하겠습니다.
수많은 Web제작을 경험한 필자가, 실제 Web제작에서 필요하였던 기술, 이것은 알아두어야한다고 느낀 지식 등, 어디까지나 현장감각을 중요시하는 사항들을 소개하도록 하겠습니다.





기술의 발전과 프런트엔드 엔지니어가 탄생한 배경

프런트엔드 엔지니어라고 하는 직종이 탄생한 것에는, Web제작에 관한 새로운 기술들이 등장한 것과, HTML코더의 업무범위와 깊은 관련이 있습니다.
아래에서 소개하고 있는 그림은, HTML코더가 담당하는 업무의 변모입니다. 이것을 보면, HTML코더라고 하는 직종이 대응하여야 하는 업무가 현격히 많아지고 있다는 것을 알수 있습니다.


HTML 코더가 담당하는 업무확대의 이미지



종래의 HTML코더는 (1)~(2)이 작업범위였습니다.
(3)부터는 프로그래머의 지식도 필요한 CMS도 등장. 이후(4)~(8)도 지금까지의 연장에서 HTML코더가 담당하는 케이스도 있었습니다. 그러나 이것은 이른바 "오퍼레이터"로써 HTML코더의 작업으로부터 벗어나 버리게 됩니다.
이대로 "HTML코더"라고 하는 명칭이라면, 모든 HTML코더가 앞어 이야기했던 것과 같은 업무를 할수 있는것 아니냐라는 오해가 생겨나므로, 명확한 구분이 필요로 하게 되는 것입니다.
그러면, 모든 웹프로그래머의 작업범위에서 할수없는가 라는 이야기가 나오게 됩니다만, (4)~(8)은 HTML/CSS와 밀접한 관계성이 있고, 깊은 브라우저 지식도 가지고 있어야 합니다. 이런 점에있어서, 웹프로그래머는 HTML코더 만큼의 지식도 없고 최적이지도 않습니다.

이런 배경에서, 태어난 것이 프런트엔드 엔지니어입니다.
지금까지의 HTML코더의 업무도 범위안에 넣고, CMS구축과 JavaScript를 사용하여 제작도 가능한 고도의 기술을 가진 사람을 "프런트엔드 엔지니어"라고 자리매김하므로써, HTML코더와 명확한 선을 긋고, 현장에서의 혼란을 회피할수 있게 됩니다.
여기에서 "명확한 선긋기"라고 썼습니다만, 뒤에서 부터는 구체적인 예를 근거로, HTML코더와의 차이점을 소개하도록 하겠습니다.

[역주]
※ SEO - Search Engine Optimization 검색엔진 최적화
※ CMS - content management system의 약어로 wordpress와 같이 웹컨텐츠를 쉽게 만들어주는 툴을 의미한다



「HTML코더」와「프런트엔드 엔지니어」의 차이점


일반적으로 말하는 HTML코더는, 디자이너가 마무리한 "그림"을 인터넷(웹브라우저)위에서 표현하기 위해서, HTML과 CSS로 "재현하는" 사람을 가리키고, 이른바 오퍼레이터와 같은 위치를 갖게 됩니다.
그에 반해서 프런트엔드 엔지니어는, 사이트를 개발하는 것에서, 최적의 기술 및 구조는 무엇인가를 생각하고, 때로는 디지이너와 PM의 상담역할도 되고, "하고싶은 것을 실현하기" 위한 기술적인 추적과 제작을 담당합니다.

특히 근래의 웹제작환경은 크게 변하여 왔고, HTML/CSS만으로 만들어진 움직임이 없는 사이트에서, CMS를 사용한 관리의 간편함, JavaScript를 사용하여 한층 더 사용자의 시선을 끌수 있는 인터페이스 등이 트렌드가 되었습니다.

이런 변화는, 사용자에게 즐거음과 편리성을 안겨주고, 고객에게는 "이런 표현과 움직임이 가능하지 않나?"라고 하는 선택할 수 있는 가지수를 많이 주고 있습니다.
그러나, 반대의 의미로 이야기하자면, 할수 있는 것이 늘어나는 것 만큼, 무엇이 최적이고, 어떤 수법을 채용하면 좋을지에 대한 판단을 하기 어렵게 된다고 할 수도 있습니다.

이것은 개발자에게 마찬가지라 할 수 있어서, 고객의 요구에 대하여, 어떤 기술과 표현방법이 최적인가를 선택하여야 합니다. 또한, 요구에 응할뿐만 아니라, 스스로 최적의 밥법을 제안하여야만 하는 경우도 있습니다.
즉 지금까지와 같이, 디자인을 웹상에서 재현하는 코딩스킬만으로는 대응할수 없는 안건이 늘어난다고 할수 있습니다.
그리고 그것을 팔로우 하기 위해서 탄생한것이, 프런트엔드 엔지니어라고 하는 직종이 것입니다.




코딩 스킬 이외에 필요한 것

프런트엔드 엔지니어에게는, 종래의 HTML코더가 가지고 있는 코딩 스킬 이외에도, 여러가지 지식이 요구되어지는 것이 이해될 수 있다고 생각합니다.
특히, HTML5, CSS, CMS, JavaScript에 관련한 지식은, 지금의 Web제작에 있어서는 필수라고도 할수 있는 것입니다. 그것들 중에서, 프런트엔드 엔지니어로써 특히 이해되어야 하는 포인트를 간단히 정리해보았습니다.



HTML5의 경우


HTML5에서 주목할 포인트는, 태그뿐만 아니라, API입니다. 물론 태그도 중요합니다만, 이것은 지금까지의 HTML연장선에 있는 탓에, HTML코더라도 금방 배울 수 있다고 생각합니다.
프런트엔드 엔지니어로써는, HTML5 API를 익히고, 지금까지 불가능 하였던 것의 실현과 HTML5를 사용하여 현재보다 더 나아지도록 하는 것과 같은 대응이 기대되고 있습니다.
대표적인 예를 들어보면, HTML5 API를 사용하여서 로컬 파일의 접근이 가능하다거나, 드래그 앤드 드롭이 네이티브하게 구현할수 있다거나 하는 것을 들 수 있습니다.
이렇듯, 종래의 HTML에서는 어려운(할수없는) 것도, HTML5 API를 이용해서 용이하게 실현가능하게 되었습니다. 프런트엔드 엔지니어로써는 그런 것을 이해하고, 받아들이고, 제안할 수 있게 되는 것이 요구되고 있습니다.



CSS의 경우


CSS에 있어서는, HTML코더와 프런트엔드 엔지니어의 기술적인 장벽은 없습니다. 그러나 JavaScript에서 HTML요소를 움직인다거나, 표시 비표시로 한다거나 하는 동작의 경우, CSS에서 커버하는 범위와 JavaScript에서 커버하는 범위를 판단하여 설계하지 않으면 안됩니다.
또한, CSS3를 지원하는 브라우저의 점유율도 늘어나고 있어서, 어떤 CSS3프로퍼티가 어떤 브라우저에서 지원되고 있는지, 벤더 프리픽스(역주:부트스트랩처럼 회사나 단체에서 배포하는 CSS는 클래스네임등에 배포자를 알수 있는 접두사를 붙인다)는 필요한지 등을 판단 하기 위한 지식이 필요합니다.


CMS의 경우


블로그정도라면, CSS와 같은 기술적인 장벽은 없습니다만, CMS표준의 기능으로는 할수 없는 확장과 JavaScript에서HTML요소를 조작할수 있는것을 전제로 한 템플릿 제작 등, HTML관련 기술과의 연계에 신경을 쓴 구축이 요구됩니다.



JavaScript의 경우


JavaScript로는 움직임이 있는 인터페이에서 부터 본격적인 웹어플리케이션까지, 여러가지 것들을 만들수 있습니다만, 웹 제작 현장에서는 어느 것인가라고 한다면 전자가 확률적으로도 많다고 할 수 있을 것입니다. 현재로는 JQuery가 있어서, 슬라이더와 라이트박스와 같은 자주 필요로 하는 것은 플러그인을 도입하여 간단하게 구현가능합니다. 그러나 플러그인 만으로는실현 불가능한 요망도 있는 것도 분명합니다.
그 때문에 플러그인의 도입뿐만 아니라, 커스터마이징과 일일이 스스로 만들수 있는 능력이 요구됩니다.
이렇듯, 단순하게 "재현하는 기술"이 높은것 만으로는 프런트 엔드 엔지니어라고 부를 수 없고, 한걸음 두걸음도 앞을 생각하고, 최적의 것을 제안 개발 가능한 것이 필요로 하게 됩니다.


HTML코더와 프런트엔드 엔지이어가 배우는 것의 차이


HTML코더
프런트엔드 엔지니어
HTML5
태그
(HTML의 연장이 아니어서 문제없이 익힐 수 있다)
태그+API
(할수 없던 것의 실현. 더 편리하도록 하기 위한 대응)
CSS
CSS프로퍼티
CSS레이아웃
CSS에서 커버하는 범위, JavaScript에서 커버하는 범위의 판단과 설계

CSS3프로퍼티의브라우저 지원
CMS
블로그 정도의 구축
CMS표준기능으로는 할 수 없는 확장

HTML관련기술과의 연계
JavaScript
플러그인을 사용한 간단한 구현
플러그인의 커스터마이징
오리지날인터페이스의 작성방법






프런트엔드 엔지니어의 현장에서의 가치

Web제작 현장에서의 프런트엔드 엔지니어의 가치라고 한다면, "다양하고 높은 스킬을 가지고, 여러가지 요구에 대응할 수 있고, 또한 제안할수 있는" 것에 있습니다.
예를 들면, 제작 안건을 진행한 후에, 프런트엔드 엔지니어에 대하여 웹 디렉터가 자주 하는 상담은 다음 두가지 입니다.
이런 움직임, 이런 표현을 하고 싶은데 재현가능한가? 작업시간은?
이 기능을 사용하여 구축하고 싶다
어떤 요망이든, 그것을 실현하는것 자체에 별 다른 문제는 없습니다. 그러나 프런트엔드 엔지니어의 경우는, 여기에 "왜지? "란 말이 붙게됩니다.
"움직임"과 "표현" 에 대하여서는, 웹사이트 목적에 대하여, "왜 그것 아니면 안되는건가?" 도 생각할 수 있습니다.시간과 예산을 고려하고, 요구대로 할수 있는 경우는 문제가 없습니다만, 상황이 여의치 않은 경우는 "무리야"라고 하는 결론을 내지 않고, 시간과 예산에 맞는 대체 방안으로 대응하는 것도 역할이라 할수 있습니다.

"이 기능을 사용하여서 구축하고 싶다"라고 하는 요망에 대하여서는,


  • 진짜로 그 기능이 필요한가?
  • 요망하고 있는 것이라면 별도의 기능쪽이 구현이 빠르다
  • 장래적으로는 별도의 기능을 구현하여두는 편이 효율적

이라고 하는 제안을 합니다.

고객의 기대에 부응하기 위해서, PM과의 상담과는 별개로, 디자이너에게서 "이 디자인 사양으로 코딩할때에 문제가 없는가?"라는 상담도 현장에서는 빈번하게 일어납니다.문제가 있으면, "어디를 어떻게 하면, 디자인을 재현할수 있다"라는 식의 어드바이스를 합니다.
특히, 반응형 웹디자인으로 사이트를 구축하는 경우는 PC와 스마트폰에서 어떤식으로 보여주는 방식으로 할까 등, 기술적인 면의 어드바이스와 제안을 요청받습니다.
이렇듯이, 프런트엔드 엔지니어는, 최적의 제안 및 성과물을 납품하기 위한 필수불가결한 키맨이라고 할 수 있습니다. 앞으로의 제작현쟁에서 프런트엔드 엔지니어가 있는 것과 없는것으로, 개발의 스피드도 퀄리티도 크게 변할 것입니다.




타직종과의 관계와 역할

지금까지 프런트엔드 엔지니어에 대한 정의와 갖춰야 할 지식 및 기술에 관하여 썼습니다. 이제 부터는 그것들에 근거하여 프런트엔드 엔지니어로써 타직종과 관계할 때 주의할 점을 소개하도록 하겠습니다.

PM과 관계

PM으로부터는 실현의 가능성 여부와,  더 좋은 방법이 없는지에 대한 제안을 빈번하게 요청받습니다.
프런트엔드 엔지니어의 책무라고도 할 수 있는, 요망에 대응하기 위한 촤적의 판단과 제안을 하는 것도 중요합니다만, PM은 전체의 스케쥴 관리를 하고 있다는 점을 잊어서는 안됩니다.
스케줄에서 크게 벗어나는 제안이라면 무의미한 일이 되어버리므로 스케쥴과 리소스를 생각해서, 그중에서 실현가능한 베스트 케이스를 제인하는 것이 필요할 것입니다.


디자이너와 관계

움직임이 있는 인터페이스에 관하여, 그것을 지원하는 기존의 플러그인이 있는지, 없으면 만들수 있는지 등등, 디자인을 문제없이 재현가능한가를 상담하는 케이스가 있습니다.
작금의 웹 제작은 "겉보기"만으로는 끝나지 않는다라고 하는 것을 앞서 소개하였습니다만, 기술이 늘어난 만큼 앞으로도 이러한 상담은 요청받을 것입니다.
프런트엔드 엔지니어로써는, Web의 기술로 할수 있는 여러가지 표현에 대하여 정보를 제공하여서 디자인을 이끌어 내준다거나, 코딩하는 시점에서 디자인을 보고 "이러한 디자인은 시간이 든다" "이렇게하면 빨리 코딩을 할 수 있다" 라고 하는 퀄리티 측면과 효율적인 진행방법의 제안도 필요하다고 할 수 있습니다.



HTML와 관계

프런트엔드 엔지니어는 HTML코더의 상위직이라는 위치를 갖는다고 할 수 있습니다. 그런 탓에, HTML코더로써는 프런트엔드 엔지니어를 "무엇이라도 의지할수 있는 사람" 이라는 인식으루가지는 경우가 많은 것 같습니다. 또한 코더에서 레벨상승하여 프런트엔드 엔지니어를 목표로하고 있는 사람도 있을 수 있습니다.
그러한 입장에서, 문제가 일어난 때에 상담을 요청받는 일도 당연히 많아지게 됩니다. 대신에 자신이 작업을 하는 편이 빠른 케이스도 있는가라고 생각할 수 있지만, 문제를 검증하고, 그사람이 결실을 맺을 수 있도록 "해결방법"과 "원인"을 피드백하는 것도 중요합니다.
HTML코더와 밀접한 관계에 있는 프런트엔드 엔지니어로써는, 현장의 수준을 끌어올리는 것에도 힘을 써서, 전체 스킬업을 꾀하는 역할도 있다고 할 수 있습니다.
그밖에도 프로그래머로 부터 프로그램을 짜기 쉬운 코딩을 하고 싶다라고 하는 요청에 대하여, 촤적의 코딩 가이드라인을 작성한다거나, 풍부하고 고도의 지식을 보유하고 있다는 것에서 자사 사이트에서 칼럼을 집필하는 등의 스킬 아웃풋을 한다거나 하는경우도 있습니다.
이처럼 프런트엔드 엔지니어는 제작의 역할에 그치지 않고, 제작 레벨의 향상괴 업무효율화를 향한 움직임도 기대하고 있는 직종이라고 할 수 있습니다.




프런트엔드 엔지니어가 있는 경우 제작 과정의 흐름

지금까지, 프런트엔드 엔지니어가 어떤일을 하고, 어떤 역할을 가지고 있는지를 소개하였습니다. 이제부터는 더 구체적인 이미지를 떠오를 수 있도록 제작 공정에 따라 프런트엔드 엔지니어가 어떤식으로 관여하는가를 소개하겠습니다.

개발 흐름에서 프런트엔드 엔지니어의 역할





제작공정에서  HTML코더와 적재적소 작업을 분담하고, 프런트엔드 엔지니어밖에 할 수없는 부분을 담당하는 것은 당연한 일이지만, 각 공정의 상담역할로써도 힘을 발휘합니다.
예를들면, HTML코딩을 했던 경험이 있는사람이라면 누구라도, "의미를 모르겠어" "쓸데없는거 아냐?" "더 좋은 방법이 았다" 라고하는 요구사항을 마주 대한 적이 있다고 생각합니다.
 보통이라면 이런 요구 사항에 대해서 의견을 얘기할 터인데, 코딩은 Web제작의 현장에서 말하자면 후공정에 있는 탓에, "지금에와서 바꿀수 없다" 라고 하는 사태에 빠지는 일도 있습니다.
그러나 코딩의 지식을 겸비한 프런트엔드 엔지니어가 각 공정사이에 들어가서, 그때마다 요구조건의 확인과 상담을 받아서, 전술하였던 문제를 줄이는 것이 가능합니다. 말하자면 원활하게 작업을 진행시키기 위한 윤활유의 역할을 담당한다고도 할수 있습니다.




요구사항의 포인트

HTML코딩은 하류공정(역주:lower process)이므로, 스케줄이빠듯하게 되어 불명확한 요구사항의 확인이 발생하고,  허둥지둥해버리고 마는 경우가 있습니다. 그렇게 되지 않기 위해서도, 사전에 요구사항을 파악하고, 불분명한 점을 없애서 작업이 스무스하게 진행될수 있도록 하여야 합니다.
기본적으로 요구사항이라고 하는 것은, "무언가를 실현하기 위해서"에 있는 것이므로, 다음 항목을 확인하여,  사전 요구사항 확인시에 빠뜨리지 않게 됩니다.

  1. 목적과 얻고 싶은 효과
  2. 어떠한 조건에서 실행되는 것인가?
  3. 실행되고 나서 완료까지의 사이에서 움직임은 어떻게 되는가?
  4. 완료하고 나면, 어떻게 되는건가?
  5. 다른 요구사항과 충돌나지는 않는가?
  6. 전체를 봐서 정합성이 잘 맞는가?

1~4은 케이스를 나눌 수 있는 경우가 많아서 경험을 쌓는것으로 자연스럽게 대응이 가능하게 되고, 불명확한 점을 놓치면, 가능성도 낮아진다고 말할수 있습니다. 그러나 5~6은 사이트 전체의 이야기이고, 모든 요청사항을 파악하고 사용자의 움직임을 시뮬레이션하지 않으면 놓쳐버리는 경우가 있습니다.
만의 하나, 작업중에 5~6에서 문제가 발생한 경우는, 근본적으로 변경되는 경우가 많고, 대응에 시간이 걸리므로, 어느정도 시간을 갖고 차근히 요청사항을 확인하는 쪽이 낫다고 할 수 있습니다.



정리

프런트엔드 엔지니어는 기본적으로 개발자라고 하는 입장입니다만, 위에서 언급한 개발흐름도를 보고 알수 있듯이, 실제는 개발 범위외에도 많은 부분 관여하고 있습니다.
"상담역할"도 가진 경우, 일부분의 공정에서 관여한다라기 보다, 현재 진행 상태의 확인과 상담에 대하여, 각 개발 담당에 제안 및 어드바이스를 행하고, 결과적으로 원활한 개발 체제를 만들어가고 있는 것입니다.

Share:

댓글 1개:

  1. 내가 왜 이렇게 배우고싶은건 많고 머리 쥐나고 어려운데도
    자꾸 관심이 이런데 쏠릴까 싶었는데..
    프론트 엔드 개발자가 되고싶었던 건가 보네요 ㅠ,.ㅠ (현재 웹디겸퍼블리셔)
    우연히 자료 찾다가 이글을 보고 깨달았습니다.
    좋은 정보도 배워야 할 글들도 많은 곳이네요. 감사합니다 ^^

    답글삭제