Colin's Blog
협업을 위해 입사이전에 알고가면 좋을 것들

흔히들 기본이 중요하다는 말들을 많이 합니다. 그 기본에는 cs라는 범주 안에 존재하는 여러 용어들과 개념, 또 각 도메인(프론트엔드, 백엔드, 머신러닝 등)에서 기본적으로 사용되는 개념들과 활용 능력 등을 포함하고 있는데요. 그런데 진짜 일을 바로 시킬 수 있는 사람에게 필요한 기본은 어떤 것들이 있을까요? 이번 글에서는 위에서 얘기한 추상적인 개념에 기반을 둔 기본에 대해 얘기하기보다는, JS생태계에서 업무를 하고 있는 개발자의 관점에 조금 치우쳐서 전반적으로 일을 하기위해 어떤 것들을 기본으로 알고가야하는지에 대해 나누어 보려고 합니다.

개발자도구

많이들 사용하시겠지만 개발자도구를 단순히 console.log() 용도로만 사용하시는 분들을 많이 봤습니다. 디테일하게 얘기해보면 무궁무진한 활용이 가능하지만 실무에서 필요할 때와 간단한 팁으로 나누어서 정리해보려고 합니다.

Elements 탭

원하는 요소를 클릭하고 Styles에 값을 주어 퍼블리싱등을 할 때 주로 사용하실텐데요.

사진과 같이 원하는 요소를 클릭한 후에 이를 $0으로 참조하여 원하는 이벤트를 추가할 수 도 있고, DOM에서 값을 읽어오거나 조작이 필요할 때 $0 참조를 통하여 미리 로직을 수행해볼 수 도 있습니다.

$0은 가장 최근에 클릭한 요소, $1은 최근의 한번 전에 클릭했던 요소, $2는 최근의 두번 전에 클릭했던 요소를 참조하여 총 $4까지 사용할 수 있습니다.

Network

백엔드와 프론트가 서로 협업을 할 때 필수적으로 사용해야 하는 탭입니다. 보통의 협업은 api 명세를 정하고 프론트는 그에 따라 맞는 로직을 구성하게 되는데요. 명세를 따라서 요청을 보냈을 때 제대로 된 값이 오는지 안오는지를 확인하는 과정에서 주로 사용됩니다.

백엔드와의 협업에서 가장 중요한건 지금 어떤 문제가 발생했을 때 어떤 파트에서 잘못된 부분을 일으키는지를 빠르게 파악하고 요청하는 것입니다. 이에 대한 과정을 간단하게 정리해보겠습니다.

  1. Status Code를 확인합니다.

    1. 2~300은 요청이 제대로 들어간것이겠죠?
    2. 400은 클라이언트에서 어떤 잘못된 요청을 보냈다는 의미이지만 이때는 api 명세가 틀려서 발생되는 에러일 가능성도 있기 때문에 빠르게 확인하고 소통하는 것이 필요합니다.
    3. 500은 서버에서 발생되는 에러라는 의미이므로 보내진 쿼리 파라미터의 확인과 함께 백엔드와 빠르게 소통하는 것이 필요합니다.

  2. 네트워크 탭에 기록되어 있는 요청을 클릭하여 요청과 응답에 대한 내용을 파악합니다.

    1. 데이터 페칭에 대한 요청과 응답은 보통 XMLHttpRequest와 Fetch API를 활용하기 때문에 XHR 타입만 볼 수 있도록 필터링하여 보는 것이 가독성에 좋습니다.
    2. Header 탭에서 Request URL과 Request Method, 그리고 Query Parameter를 확인하여 명세와 일치하는지 확인합니다.
    3. Preview 탭을 활용하여 수신된 데이터가 제대로 들어왔는지를 확인합니다.
      1. 이때 들어온 데이터에 대고 오른쪽 클릭을 한 뒤 Store as global variable를 클릭하면 콘솔에서 해당 데이터를 핸들링 할 수 도 있습니다.

  3. 해당 글의 취지에서는 벗어나지만, 어떤 에러가 발생하고 해당 이슈에 대한 원인이 다른 파트에게 있을 때는 굉장히 조심스럽게 요청하는 것이 좋습니다. 이슈는 누구에게든 발생할 수 있기 때문에 본인 파트에서 발생하지 않은 이슈라고 생각하는 이유를 논리정연하게 정리하여 조심스럽게 전달하는 것을 추천합니다.

Tip.

package.json

JS 기반 개발자라면 처음 일을 받고 프로젝트를 세팅하는 과정에서는 필수적으로 마주치게 되는게 package.json인데요. 물론 간단하게 npm install 후 npm start로 프로젝트를 실행하게 해놓은 개발 환경도 있겠지만, 높은 확률로 package.json의 명세에 여러 실행 커맨드를 작성하게 해놓았을 겁니다. 입사를 하게 되면 가장 먼저 파악해야할 부분과 package.json의 명세 중 알고 있어야 할 부분들을 정리해보려고 합니다.

package.lock.json이란?

package.json의 dependencies 중괄호 내부에 적혀있는 값들은 단순 버전이 아니라 version range, 즉 버전의 범위를 지칭하는 값이 적혀있습니다. 만약 새로운 개발자가 와서 환경을 세팅하는데, 프로젝트에 버전의 범위를 지칭하는 파일만 있고, npm install을 실행하면 어떻게 될까요? ^3.12.1 라는 dependency는 마이너한 패치가 이루어진 3.14.2가 설치될 수 도 있고 이는 오류를 발생시킬 수 있습니다. 이러한 라이브러리 관련 이슈는 디버깅도 굉장히 힘이듭니다. package.lock.json은 이러한 에러를 방지하는 용도를 가지고 있습니다. 버전의 범위가 지칭되어 있지만 lock.json에 지칭된 파일이 생성될 당시의 연관된 dependency들에 대한 정보를 가지고 있기 때문에 이를 통해 위에서 언급한 에러를 미연에 방지할 수 있도록 합니다.

같은 맥락에서 dependency를 설치하고 lock.json이 변경되면 해당사항도 같이 commit하여야 합니다.

Git

이미 한 회사에 입사를 할 정도의 분이시라면 개인 프로젝트를 통해서든, 소규모 프로젝트를 통해서든 Git을 어느정도 활용하실 줄 알고 Command도 잘 아실거라고 생각합니다. 그래서 너무 기초적인 얘기보다는 협업에서의 관점에서 알아야 할 커맨드를 정리해보려고 합니다.

Branch 전략

운이 좋게도 소규모, 중규모, 대규모 스타트업을 전부 경험해볼 수 있었습니다. 이와 같은 경험을 토대로 바라봤을 때, 배포 전략은 규모에 따라서 달라질 수 있지만 Branch 전략은 Git flow, Github flow 에서 크게 벗어나지 않았습니다.이러한 용어도 있구나 라는 관점에서 작성한 맥락이며, 이 부분에 대해서는 참조로 대신하겠습니다.

https://woowabros.github.io/experience/2017/10/30/baemin-mobile-git-branch-strategy.html
https://medium.com/daangn/deploy-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EC%A0%84%EB%9E%B5-%ED%99%9C%EC%9A%A9-%EB%B0%A9%EB%B2%95-545f278ca878

Rebase

현재 저는 프론트엔드 개발자가 16명 정도 있는 팀에서 근무하고 있고, 모노레포 환경에서 개발하고 있습니다. 즉 16명이 심하면 각각 하나씩 feature를 가지고 개발한 뒤에 master 브랜치에 머지를 하게될 수 도 있는 환경입니다. 이와 같은 환경에서 각각 브랜치에 커밋한 내용들이 마스터에 머지된 후 시간별로 정렬되었을 때는 어떤 feature에서 작성된 커밋인지도 알 수 없고, history 파악에도 문제가 생길 수 있습니다. 이러한 부분을 방지하기 위해 저희 팀에서는 rebase의 interaction 옵션을 통한 squash를 사용합니다.

pick 9c02134 대표 커밋
squash 129sd01 서브 커밋1
squash 1qd2304 서브 커밋2

위와 같은 형태를 통해 대표적인 커밋을 남겨놓고 머지하는 방식을 주로 사용합니다. 물론 많은 회사에서 위와같은 방식을 위해 rebase를 사용한다고 일반화 할 수 는 없으나, 협업의 관점에서 rebase가 가지고 있는 여러 옵션들은 미리 알아두면 조금 더 같이 일하는데 숙련된 사람으로 만들어줄 수 있을 것이라고 생각합니다. git 그래프의 관리적인 부분에서도 장점이 있지만 rebase에 관한 내용은 좀 더 좋은 포스팅들이 많기 때문에 참조로 대신하겠습니다.

https://git-scm.com/book/ko/v2/Git-%EB%B8%8C%EB%9E%9C%EC%B9%98-Rebase-%ED%95%98%EA%B8%B0
http://meetup.toast.com/posts/39

reset과 reflog

입사한지 얼마 안 되었을 때는 긴장을 한 탓에 실수를 할 때가 많습니다. 잘못된 커밋을 올리기도하고.. 또 잘못된 커밋을 수정하려다가 아예 커밋을 삭제해버리기도하고.. 이런 상황에서 필요한 reset과 reflog 커맨드를 소개할까 합니다.

reset

대표적으로 방금 올린 커밋을 수정하기 위해서는 두가지로 나뉘어집니다.

방금 올린 커밋을 수정하기 위해서 -> git reset --soft HEAD^

방금 올린 커밋을 삭제하기 위해서 -> git reset --hard HEAD^

여기서 HEAD의 의미는 현재 브랜치의 마지막 커밋의 스냅샷과 같은 의미로 가장 최근의 커밋을 reset 시킨다는 의미와 같습니다. 위에서 사용한 ^와 다르게 HEAD~(숫자 2부터) 틸드를 활용하면 숫자2부터 최근 커밋중 2개를 삭제한다와 같은 의미로 사용됩니다.

--hard: reset하기 전까지 했던 staging area, working directory의 작업까지 모두 reset
--mixed(default): staging area은 reset, reset하기 전까지 했던 working directory의 작업은 남겨둠.
--soft: reset하기 전까지 했던 staging area, working directory의 작업은 남겨둠.

참조: https://opentutorials.org/module/4032/24533

reflog

위의 reset –hard는 어쩔 때는 두통을 일으키는 존재가 될 수 도 있습니다. 이러한 상황을 타개하기 위해서 git reflog를 통한 복구가 존재합니다.

  1. git reflog 명령어를 통해 커밋이력을 확인합니다.
  2. 커밋이라면 git reset –hard ${해당 커밋 id}
  3. 브랜치라면 git checkout -b ${삭제된 브랜치 이름} HEAD@${해당커밋 id}

결론

실무에 대한 경험이 많지 않거나 개발자로 첫 커리어를 시작하시려는 분들을 타겟으로 처음 일을 했을 때 알았으면 좋았을 것들을 나열해보면서 쉽고 기초적인 내용을 다루어 봤습니다. 이 밖에도 신입 개발자들이 알고있다면 좋을 부수적이지만 도움이 되는 내용들이 있다면 댓글로 함께 공유해주셔도 좋을 것 같습니다.

글쓴이

© 2018 Colin. All rights reserved.