React로 시작하는 프론트 개발은 필자(seolim)의 경험을 기반으로 작성되며 절대 정답이 아닙니다! 이점을 유념하며 읽기 바랍니다.
프론트엔드 개발이란?
3세대 웹서비스 이후 SPA가 유행하기 시작하면서 Frontend, Backend의 개념이 정립되었다.
쉽게말하면 HTML/Javascript와 데이터를 조작/제공하는 부분이 구조적으로 분리된것이다.
따라서 현대에 와서는 Web service의 개발에 있어서 프론트 사이드와 백엔드 사이트의 구별이 더욱 세분화 되어있다.
그런데 프론트엔드 개발이란 뭘까? 화면을 그리는 것? 그건 디자이너 아닌가?
위 글의 중간 프론트엔드 엔지니어가 실제로 하는 일을 적은 부분이 있다. 해당 부분을 번역해보면
**What Front End Engineers actually do:**
1. 디자이너와 엔지니어간 시각 언어 확립
2. 디자인으로 부터 표현 컴포넌트 세트 정의
3. 다양한 웹 어플리케이션의 기준 확립
4. 웹 어플리케이션의 범위를 기기, 브라우저, 화면, 애니메이션 측면에서 정의
5. 브랜드 충성도, 코드 품질, 관계자의 상품 리뷰를 위한 품질 보증 가이드라인 개발
6. 적절한 스타일시트를 사용해 어플리케이션 꾸미기
7. 디바이스별 목업을 통해 어플리케이션 꾸미기
8. SEO, 문법성, 접근성, 스키마들을 고려한 마크업 하기
9. API를 통한 정보 접근방식 정하기
10. 다양한 interaction 워크플로우를 수행하는 개발 및 하위 표준 포괄성
11. 각종 보안 이슈 안전성 확보
12. **항상 사용자가 최우선임을 잊지 않기**
C
복사
와우, 저렇게만 보면 정말 많은 일을 한다. 하지만 결국 저 모든 일은 사용자와 서비스의 데이터의 유연한 인터렉션 및 다양한 대응을 하나의 프레임워크에서 하기 위한 일들이다.
결국 프론트엔드 개발자가 해야할 일이라는 것은 유연하고 reusable한 프론트 프로세스를 구축하는 일이다.
42seoul의 "이호준"멘토님께 이런 이야기를 들었다.
Front개발에서 팝업의 종류가 3개 만들어졌는데, 그 순서를 모두 바꿔야하는 상황이 개발에서 생겼어. 그런데, 누구는 하루 종일 자기가 만든 코드 찾아가면서 수정하는데, 누구는 설정 약간만 바꿔서 30분만에 다 고쳐서 가져올수 있어.
프론트엔드 개발자가 가져야하는 자세는 바로 이런 자세일 것이다.
프론트엔드 개발자의 역량
Javascript, HTML, CSS, React, Vue...
프론트엔드 개발자라고 하면 가장 먼저 떠올릴 스펙, 당연히
어떻게 보면 당연히 갖추어야 할 기술적 소양이다. 당연히 저 기술적 스펙을 가지고 있는 것은 중요하다.
그래서 많은 사람들이 js강의를 듣고 클론코딩을 하며 개인프로젝트를 git에 올린다. 그래서 그걸로 좋은 개발자가 될 수 있을까?
위 글을 빌리자면 개발자는 결국 "문제를 잘 해결할 수 있는 사람"이다. 개인의 기술은 아무리 잘 단련해봤자 어자피 그것을 해온 기간이 결정해주며, 새로운 문제는 언제든지 생겨난다. 결국 좋은 개발자라는 것은 문제를 얼마나 잘 파악해오고 서로 원활한 소통을 할 수 있으며 앞으로 발생할 문제를 쉽게 해결하는 방향으로 기술을 사용할 수 있는 사람이다.
단순히 기술 공부만 할 것이 아니라 이런 부분을 항상 함께 공부해야 한다.
아래 내용들은 필자가 개인적으로 역량을 높이는 방법으로 추천하는 방식이다.
1. 일단 만들고 만들면서 써라.
뭐던간에 일단 만들어봐야 감이 온다. 기술 스펙은 아무거나 상관없다. 이유도 없다. 그냥 생각한게 있으면 만들어본다. 생각나는게 없다? 네이버 홈페이지라도 만들어 보자. 홈페이지가 어려우면 하물며 계산기라도 만들어 보자.
모든 개발의 시작은 흥미이다. 취업이 쉬워서, 많이 찾으니까, 평균연봉이 높아서, 다 필요없고 개발은 재미있으니까 하는거다.
그리고 만들면서 생각날때마다 기록하자. 세상엔 기록을 위한 쉬운 서비스들이 많다. Notion이던 hackmd건 작업중에 생각날때마다 다 적어두자. 잘 쓸 필요도 없고 모든것을 기록할 필요도 없다. 예를 들어 "react"를 썼으면 react를 왜 썼는지 쓸때 "그냥 검색하니 제일 처음에 나와서"도 좋다. 일단 기록해라. 중간에 코드를 쓰다가 헷갈렸으면 써두고, 그냥 작업중에 아 이거 써야지 라고 생각날때마다 기록하자. 모든 것을 기록하는 버릇은 나중에 아카이빙(자료 저장 및 보관)에 큰 도움이 된다.
2. 프로세스 흐름에 따라 작업해보자.
세상에 협업이 얼마나 어려웠고 커뮤니케이션이 안됬으면 jira나 trello와 같은 협업 툴이 개발되고 그 과정을 상세하게 만든 가이드까지 나왔을까? 나중에 이 가이드를 어떤 회사에 가던간에 따라야 한다. 그 과정을 미리 연습한다는 셈 치고 해보자.
애자일 프로세스의 스크럼 방식이건, git flow건 하나 정해놓고 규격적으로 따라해보는 것이다. 특히 git flow는 한번 따라서 개발을 해보길 추천한다. 이런 방식은 결국 협업에서 서로의 대화를 줄이는 역할을 수행한다. 굳이 서로 "말하지 않아도 알아요"를 만드는 과정이다. 이런 연습은 취업을 하려는 사람들에게도 큰 장점이 될 수 있다. 기록지로써의 역할또한 수행된다.
3. 모델링 및 리펙토링을 해보자.
대부분의 주니어들은 위 2사항을 굉장히 소홀히 한다. 만들 때 일단 앉아서 에디터부터 키고 코딩을 시작하고, 코딩이 끝나면 다시 보지 않는다. 한번 개발하기 전 본인이 만들 작품을 그려보자. 직접적으로 말하면 적어도 UserFlowChart나 시퀀스 다이어그램정도는 그리고 개발을 해보자.
또한 완성된 코드를 리뷰하고 재구성하는 과정을 거쳐보자. 이런 일련의 과정들은 본인을 회고하는 과정이 되고 본인의 코드 품질을 늘리는데 큰 도움이 된다. 특히 여러 기능을 만들면서 공통으로 분리할 수 있는 기능을 파악하고 마이크로 단위로 세분화하는 과정을 거쳐보자.
