해외 Frontend 엔지니어 업무 소개

국내에서 어느정도 일을 하다가, 해외에 취직을 하게 되었고 Frontend의 경험이 없었던 상황에서 지금 다니는 회사가 나름의 표준이라고 생각을 하다가, 국내에서 일하는 지인에게 웹 퍼블리셔라는 직군이 있다는 것을 듣게 되었습니다.

솔직히 말해서 웹 퍼블리셔라는 직군이 한국에 있다는 것이 굉장히 이상하다고 생각했습니다. 이 직군을 구분한다는 것이 회사 성장에 있어서 방해가 된다는 것이 제 의견입니다. 기본적으로 Frontend 개발자는 Backend 못지 않게 대우를 잘 받는 편이며 업무 방식에 있어서도 제가 지인에게 들었던 내용과 좀 다르긴 합니다. Frontend와 Backend의 경계가 없고, 한 개발자가 양쪽 영역 (Fullstack)에 대해 개발을 하는 것이 최종 목표가 되어야 된다고 생각합니다. 그 의미에서 웹 퍼블리셔와 Front 개발자의 구분은 업무 영역 가르기를 통한 생산성 악화로 이어질 수 밖에 없습니다.

그래서 제 경험에 대해서 어느 정도 공유를 해 볼까 합니다.  혹시나 제가 경험한 사례들을 회사에서 도입하고 싶으시다면 도움이 되었으면 합니다. 

업무 영역 구분

UX 디자이너

한국에서는 웹 디자이너라고 불리는 UX 디자이너는 업무 영역이 조금 광범히 하고, 기술적인 부분에서는 좀 다릅니다. 보통 업무에 대한 영역이라고 하면 UX에 관한 모든 사용자 경험과 디자인까지 PO (Product Owner)와 밀접하게 상의하고 결과물을 만들어 냅니다. 

결과물이라고 하면 보통은 Invision이나 Zeplin으로 만들어 냅니다. Invision은 실제로 어떤 결과물이 나올지 시뮬레이션을 해 볼 수 있어서 좋습니다. 개발을 시작하기 전에 UX 디자이너, PO와 개발자와 함께 Invision을 통해서 리뷰를 하고 피드백을 코멘트로 남기고, 수정이 필요하다 싶으면 UX 디자이너가 수정을 해 줍니다. 

요구사항과 함께 UX와 디자인이 논리적으로 오류가 없다고 판단될 때 Invision과 Zeplin으로 개발자가 개발을 시작할 수 있습니다. 이미지와 폰트 (Assets)가 다 같이 포함되어 있기 때문에 별도로 요청할 일은 없습니다.

Frontend 개발자

웹 퍼블리셔라는 Role이 없는 관계로 HTML, CSS을 포함해서 모든 것을 다 개발해야 됩니다. 

Component driven development

방법론이 되었던, 프로세스가 되었던, 프레임워크가 되었던 그 이후에 프론트 개발자의 생산성을 올리는 책임은 개발자들에게 있습니다. 그 중에 일반적으로 많이 사용 되는 두가지 툴이 있습니다. 둘 중에 하나를 선택해도 되고, 다른 좋은 툴이 있다면 비슷하게 적용하면 됩니다.

스토리북 : https://storybook.js.org/

비트 : https://bit.dev/

공통으로 쓰는 UI 컴포넌트

웹사이트를 개발하다 보면 button, radio button, dropdown list, toggle, date field, calendar등 여러페이지에서 공통적으로 사용되는 UI 컴포넌트를 만드는 것입니다. 스토리북이나 비트의 경우 github에서  pull request를 만들고 각 Branch마다 storybook을 UX 디자이너에게 공유하고 협업을 할 수 있습니다. 

이 사이트가 스토리북의 사례 중 하나 입니다. https://building.coursera.org/coursera-ui/

UI 뿐만이 아니라 Theme과 Layout의 Example까지 활용 용도는 많지만 주로 핵심적인 UI Components를 만들어서 공유하는 용도로 많이 쓰입니다. Vue, React, Angular 모두 활용할 수 있으며, 보통은 별도의 private npm package를 만들어서 UI components 버젼을 별도로 관리합니다. Colors, typography, fonts, layout도 이 package 안에 포함시킵니다. 보통은 색깔에서도 hex 코드를 사용하지 않고 UX 디자이너가 정해준 color name이 있는 팔레트를 constants 파일로 저장해서 사용합니다. 

Frontend 개발자 업무 절차

보통의 기업에서는 스크럼을 많이 사용하기 때문에 스토리 별로 일이 진행이 됩니다. UX 디자이너가 디자인을 완료한 뒤 해당 기능의 개발을 완료하면, 기본적으로 공통 컴포넌트나 디자인 가이드라인에 따라서 개발을 완료합니다.

유닛 테스트는 기본적으로 필수적인데 github repository의 master branch에 있는 Code coverage가 본인의 branch보다 낫을 경우 merge를 할 수 없게 막아놓습니다. 예를 들어 Redux pattern을 사용했을 경우는, action, reducer, container 그리고 view나  component는 UI test까지 작성합니다.

Integration test도 같이 포함되어야 하는데 일반적으로 Mock server를 통해서 Backend test data를 테스트 케이스로 처리해서 작성합니다. BDD를 한다면 스토리에 gherkin이 QA에 의해 작성되어 있다면 같이 활용하면 됩니다. BDD framework는 기회가 되면 따로 설명을 해 드리도록 하겠습니다. 메뉴얼 테스트가 필요해서 QA가 하면 되긴 하지만, 기본적으로 모든 테스트를 자동화할 수 있도록 합니다. 

그리고 가능하다면 github의 Branch마다 별도의 docker를 만들고, 독립적으로 확인할 수 있도록 하는 것이 좋습니다. 

유닛 테스트와 Integration test가 완료가 되면 UX 디자이너에게 Branch의 링크를 공유해서 해당 결과물이 어떤지 피드백을 받을 수 있고, 수정을 통해서 개발을 완료하게 됩니다.