프론트엔드 개발자가 1년차에 할 수 있는 일
입사일기
최근 브런치 연재를 많이 하지 못했다.
그동안 글을 쓰지 않은 것은 아니고, 이직준비를 하면서 비어있는 시간 동안 돈을 벌어야 해서 의뢰를 받아서 원고를 쓰는 일을 했다. 주로 블로그나 유튜브 원고였다. 서평을 30장씩 쓰는 학과를 나와서 글 쓰는 게 수월하다는 장점은 있다. 큰 장점이라고 생각한다. 글 쓰는 건 재미있고, 소소하게 돈도 벌 수 있으니까.
신입 프론트엔드 개발자로 취직을 했다.
데이터가 재미있게 느껴졌지만, 분석보다는 눈에 보이도록 나타내는 데 훨씬 더 흥미가 생겼다. 생활코딩을 보며 웹 개념을 익히고 노마드 코더를 따라 nodeJS 로 동영상 플랫폼을 만드는 공부를 했다. 워드프레스를 이용해 웹사이트를 만드는 일을 몇달 간 하다가, 최근 리액트를 다루는 회사로 이직했다.
사실 동영상 플랫폼을 따라 만드는 작업은 현재 진행중이다. 챌린지라는 프로젝트에 참여하고 있는데, 두번 과제를 제출하지 못하면 아웃이다. 벌써 한번 과제를 빼먹어서 위기이다. 아마 재수강을 해야할 것 같다. 눈과 머리로는 따라가겠는데 직접 하려고 들면 너무 어렵다. 백엔드에 저장된 데이터를 api로 받아와서 프론트 화면에 나타내는 플로우가 너무 어렵게 느껴지기 때문인데, 이 내용은 아래에서 마저 이야기하겠다.
프론트엔드 개발자, 1년차에는 무엇을 할 수 있을까?
프론트엔드 개발자가 1년차(이제 막 시작했을 때)에 할 수 있는 일을 주관적인 관점에서 써보려고 한다. 나는 웹을 독학으로 시작한 후 반년간 데이터 사이언스 국비지원과정을 들으며 파이썬과 SQL 을 공부했다. (하둡..? 대용량 데이터를 저장하고 처리할 수 있는 다양한 인프라를 배웠는데 잘 기억나지 않는다. 선명히 기억나는 건 파이썬과 SQL이다. R이라는 언어도 배웠지만 파이썬이 좀더 내 취향이었다) 이후 워드프레스로 웹사이트를 만들면서 어쩔 수 없이 PHP를 공부했는데, 웹을 모르는 채 각종 플러그인만으로는 필요한 기능을 구현할 수가 없어서 다시 열심히 웹을 공부했다. 간신히 자바스크립트 기초까지 알고 나서, nodeJS 를 공부하던 중 이직을 했고, 리액트로 웹서비스(+ 앱)를 만드는 일을 할 수 있는 기회를 얻게 되었다.
그래서, 할 수 있는 것은
1. github 협업
이직 직전에 사이드프로젝트 두개를 시작했다. 둘다 github 로 협업을 하는데, 회사에 입사하기 전에 삽질을 해보길 정말 다행이라고 생각한다. 아직도 적절한 커밋메시지를 정하지 못하거나, 커밋 실수로 브랜치에 작업내역을 지저분하게 남기거나, 풀 리퀘스트를 실수로 올려 닫고 다시 리퀘스트 하는 등의 어리버리한 짓을 하지만 빈도가 많이 줄었다. 명령어도 드디어 다 외웠다.
github 페이지에서...
> fork // 원격저장소를 내 깃허브 원격저장소로 복사해온다. 만일 관리자로부터 직접 해당 저장소에 invitation 받았을 때는 fork 하지 않고 바로 작업 가능
Terminal에서...
git clone <저장소 이름> // 내 컴퓨터의 로컬저장소에 원격저장소의 프로젝트를 복사
git checkout -b <내가 작업할 브랜치 이름> // 마스터 브랜치는 건드리지 않고 내가 작업할 브랜치 생성. 작업할 세부내용에 따라 각각 브랜치를 정하게 된다. 브랜치 이름을 정하는 규칙도 사전에 합의한다. 가령 새로 만들 때는 'feature/작업내용' , 내용을 수정할 때는 'fix/작업내용'
git branch // 생성된 브랜치들을 확인할 수 있다. 이때, 아직 이해가 가지 않는 부분이 있는데 내가 회사컴퓨터로 생성한 브랜치를 github 원격저장소에 push 한 후 집에서 pull 해와도 내 컴퓨터에서 브랜치목록을 확인해보면 그 브랜치가 보이지 않는다. 왜 그런 것일까? 일단은 브랜치생성은 로컬영역에서의 작업이라고 이해해두었다.
git add . // 현재 작업내용을 스테이징한다. 끝에 점 빼먹으면 안됨
git commit -m "커밋메시지" // 깃허브 원격저장소에는 커밋을 한 내용이 히스토리처럼 남는다. 커밋메시지를 통해 내가 작업한 과정을 한눈에 볼 수 있다. 브랜치이름처럼 규칙성 있게 정하면 깔끔하다. 날짜를 적는 습관이 있었는데, 날짜는 기본적으로 표시되므로 안 적어도 된다.
git rebase -i HEAD // 만일 아직 원격저장소로 push 하지 않은 커밋내용이 있다면 수정하기 쉽다. 수정하고 싶은 커밋개수를 고려해 HEAD~1 부터 HEAD~4 정도로 적당히 들어가서 수정한다. 알기쉽게 정리해두신 분이 계셔서 링크를 걸어둔다. https://beomseok95.tistory.com/231
git push origin <내가 작업한 브랜치 이름> // origin 이 아니라 꼭 내 브랜치에 push 해야 한다. 코드를 합칠지 말지는 pull request 를 통해 관리자에게 보내면 관리자가 코드를 리뷰한 뒤 결정하게 된다.
git push -f origin <내가 커밋 수정한 브랜치 이름> // 위에서 rebase -i 를 통해 커밋을 수정한 내용이 이미 원격저장소에 push 했던 내용이라면 이 명령어를 통해 덮어써줘야 한다
github 페이지에서...
pull request // push 를 하고 github 저장소로 들어가보면 제일 상단에 pull request 를 할 수 있도록 버튼이 생성된다. 리퀘스트를 하면 팀 관리자에게 이메일이 간다. 이제 뿌듯해하고 약간은 불안해하며 얌전히 코드리뷰를 기다린다.
2. 웹 라우팅 및 뷰 렌더링 작업
nodeJS 와 react 는 기본적으로 몇가지 명령어만으로 간단히 로컬호스트에 연결해서 웹화면을 띄울 수 있다. 내가 할 수 있는 것은 싱글페이지 웹사이트에서 필요한 기능과 링크로 연결되는 화면의 경로를 설정하고(라우팅), 그에 맞게 화면을 렌더시키는 작업이다.
리액트에서는 화면에 필요한 요소들을 작은 컴포넌트 단위로 효율적으로 분리시키는 것과 context api 혹은 redux 를 통해 전역변수를 활용하는 부분이 너무 어렵다. 화면에 그려지는 내용들은 각각 데이터베이스와 api 로 연결되어야 하고, 이를 위해 가장 적절한 컴포넌트 설계가 필요하다. 그런데 나는 예를 들어 화면에 사진과 그 사진의 설명을 배치한다고 하면 사진줄, 설명줄로 나누어 각각 display: flex 를 활용해 두줄로 정렬 시키고 싶은데, 실제 데이터베이스와의 연결을 고려하면 컴포넌트는 사진하나와 설명하나로 구성되는 것이 더 자연스럽다는 피드백을 받았다. 그러고 보니 맞는 말이었다... 사진과 설명이 하나의 묶음으로 같이 있는 게 당연하지...? 바보..
또한, nextJS 를 활용하면 라우팅과 화면 연결이 더 간편하다는 내용을 공부했지만 실제로 실습해보지는 못했다.
스타일링은 tailwind 나 styled component 를 활용한다. 사이드프로젝트에서 tailwind 를 많이 써봤는데, 미리 구성된 스타일요소들을 간단하고 규칙적인 클래스명을 갖다 붙임으로써 자유롭게 쓸 수 있어서 참 편리하다고 생각했다. 나의 지저분한 css와 이제 이별할 수 있는 걸까?
하지만, 할 수 없는 것은
1. 데이터베이스 (mongo db) api 송수신
mongo db 에 데이터를 저장하고 api 로 받아와서 프론트에 뿌려주는 것이 너무 어렵다. 앞서 동영상플랫폼을 따라 만드는 작업은 노마드코더의 수업 '유튜브 클론코딩 챌린지' 이다. 풀스택 개발을 해볼 수 있는 기회라고 생각해 수강신청을 하고 예습을 하던 중 몽고디비에서 진도를 못 나가다가 새 회사로 출근하게 되었다. 안 그래도 어려운데 회사를 나가야 되(는 핑계가 생겼으)니, 어려운 코딩과제를 할 시간이 없다.
그런데 사실, 회사에서도 리액트를 쓰니까 몽고디비를 알아야 하긴 한다. 그래서 지금도 몽고디비를 공부하다가 잠시 머리를 식힐 겸 글을 작성하고 있다. json 파일로 데이터베이스에 입력된 데이터가, 특정 명령을 통해 받아져서 뷰의 특정 부분에 알맞은 모양으로 뿌려지는 것이 신기하고 어렵다.
2. 디자이너와의 원활한 소통
디자이너와의 소통이 자유롭지 못하다. 보내주신 디자인 대로 뷰에 그릴 수는 있는데, 더 나은 ux 를 위한, 혹은 자연스러운 기능구현을 위한 디자인을 제안하지는 못하겠다. 지금 회사일 때문에 주말에만 짬내서 같이 하고 있는 일정관리 웹앱 사이드프로젝트 팀이 있는데, 디자이너분과 기획자분과 기능 및 ux 회의를 하던 도중 "화면 상에 어떻게 나타내면 좋을까요?" 라든지, "이 기능 구현할 수 있나요?" 라는 질문을 받았을 때 뭔가 백엔드적인 지식을 약간 섞어 가능여부와 가장 좋은 방법을 말씀드리고 싶었는데, 알 수 없었다. 나는 그냥 받아서 그릴 수만 있으니깐... 흑.
정말 감사하게도, 나와 소통해주시는 디자이너, 기획자, 백엔드개발자분들이 모두 인내심을 가지고 적극적으로 피드백을 해주셔서 더 나은 ux, 더 예쁜 ui, 가능한 기능 설계에 대해 듣고 배우는 시간이 많다. 정말로 감사한 일이다.
3. 백엔드 개발자와의 원활한 소통
가장 감사한 것은 역시 백엔드 개발자분들이다. 모든 프론트엔드 개발자가 백엔드 개발자에 비해 웹 지식이 적은 것은 결코 아니다. 그것은 연차에 따라, 또 개인의 실력에 따라 다 다르다. 다만 내 경우에는 api 를 어려워하다보니, 프론트작업을 수정해야 하는 경우가 정말 많다. 내가 뭔가를 질문하면 코멘트를 길게 달아주시지만, 내가 뭘 어떻게 모르는지 정확하게 표현하기 어려운 경우가 훨씬 많아서, 질문을 하기 위해서 오랜시간 검색을 하곤 한다.
4. 다양한 업무 프레임워크와 플랫폼 활용
회사에서는 aws와 firebase 등 다양한 서비스와 플랫폼, 프레임워크를 활용한다. 매 의뢰마다 필요한 인프라를 다르게 구축하기도 한다. 결국 다 알아야 하는데, 비슷비슷해보이면서도 달라서 전부 튜토리얼부터 봐야할 판이다.
적어놓고보니 할 줄 모르는 게 너무 많다. 회사일도 잘하고, 개인적으로 웹서비스도 운영하고 싶은데 요원해 보인다.
그럼 다시 공부하러!
