슬슬 개발자 취업 준비 시장에 뛰어들면서 원티드에서 진행하는 프리온보딩 코스를 신청했다.
더 나은 코드를 짜는 법을 물론 중점적으로 배우지만 첫 세션 내용은 바로 개발자의 기본기에 대한 부분이었다. 오늘 배운 세션 내용을 되짚어보며 정리하고자 한다.

개발자로서 갖춰야 할 역량은 무엇이 있을까?

흔히 업무에 필요한 역량을 말할 때 업무를 수행하는데 필요한 지식과 기술을 의미하는 “하드 스킬”과 업무 효율성을 극대화 하기 필요한 능력인 “소프트 스킬"로 구분지어서 말하곤 한다. 개발자는 개발을 하는 사람이기에 당연히 기술적인 역량이 필요할 것이다. 기술적인 역량은 개발자의 핵심이 되는 역량이므로 “하드 스킬” 이라고 할 수 있다. 그렇다면 그 외에 개발자에게 필요한 역량은 무엇이 있을까? 실제 개발자들에게 업무를 할 때 중요한 역량을 물어보면 오히려 개발 능력 외에 커뮤니케이션 능력, 소통 능력, 협업 능력, 팀워크를 강조하는 경우가 많다. 이러한 것들이 개발자로서 갖춰야 할 “소프트 스킬”이라고 할 수 있다.

개발자에게 협업과 커뮤니케이션이 강조되는 이유는 개발자 혼자서는 하나의 프로덕트를 만들 수 없기 때문 이다. 흔히 개발을 통해서 무언가를 만들 수 있기에 “개발자는 혼자서 프로덕트를 만들 수 있을 것이다”라고 생각하지만 어느정도 규모가 있는 프로덕트의 경우에는 개발자뿐만 아니라 수많은 직군들과의 협업을 통해서만 만들어 낼 수 있다. 그리고 특히 프론트엔드 개발자는 업무 특성 상 흔히 기획자, 디자이너, FE 개발자, BE 개발자로 구성되어 있는 제품팀에서 모든 직군들과 가장 많이 소통을 해야 하는 포지션이다. 심지어 마케팅 부서와도 협력이 많이 이루어지는 포지션이 FE 개발자이다. 그리고 개발자가 다루는 영역은 타 직군 사람들에게는 생소한 부분이 많다. 따라서 이런 생소한 영역을 청자를 고려해서 알아들을 수 있게 쉽게 풀어서 설명할 수 있는 능력을 갖추는 것이 굉장히 중요하다.

소통은 크게 말로 하는 소통과, 문서로 하는 소통으로 나눌 수 있다. 구두로 소통을 할 때는 내가 말하는 목적은 ‘상대방을 이해시키기 위함'임을 명심해야 한다. 그렇기에 내가 알고있는 것, 말하고자 하는 것을 쏟아내듯이 말하는 것이 아니라 나의 생각을 잘 정리해서 말하는 것이 중요하다. 일반적으로 개발자는 구두로 하는 소통보다는 문서로 하는 비동기적 소통을 더 많이 하고 선호한다. 문서라는 단어를 들었을때는 일반적으로 구글 시트, PDF, PPT, 노션 등의 툴을 떠올릴 것이다. 하지만 개발자가 주로 작성하는 문서는 commit, PR,그리고 코드이다. 이러한 문서를 통해서 개발자들은 서로 의도를 표현하고, 피드백을 주고받고, 팀의 능률을 올리기 위해 노력 한다. 따라서 이러한 문서들의 중요성을 인식하고 이를 잘 작성하고자 노력하는 것은 굉장히 중요한 일이다.

이와 연관해서 Git과 GitHub을 문서의 관점에서 알아보고, 협업 능력, 효율적인 소통을 위해서 어떤 부분들을 시도할 수 있는지 그리고 개발자는 어떻게 팀으로 일하는지에 대해 좀 더 자세히 알아보자.

Git & GitHub을 사용하면서 지켜야 할 것

Git & GitHub의 정의

Git : Git은 분산 버전 관리 시스템이다. Git을 사용해서 코드의 버전을 관리하면서 손쉽게 코드를 이전으로 롤백하거나, 분리된 환경(브랜치)에서 개발 후 다른 환경과 병합하는 등의 과정을 손쉽게 활용할 수 있다.

GitHub : GitHub은 Git의 원격 저장소이다. GitHub을 이용해 개인적으로만 사용할 수 있었던 Git의 기능들을 인터넷을 이용해서 여러 사람들이게 공유하고, 팀원들과 공동으로 작업할 수 있게 되었다.

• Git과 GitHub은 현재 개발 생태계에서 분산 버전 관리 시스템의 표준이다.
• 대부분의 개발팀이 Git과 GitHub 또는 GitHub과 유사한 원격 저장소 시스템(GitLab, BitBucket) 등을 활용하면서 작업한다.

Commit Message

Git & GitHub은 이제는 버전 관리 시스템을 넘어서서 문서와 협업 툴의 역할 또한 수행하고 있다. 개발자가 다른 개발자의 코드를 분석할 때 이 코드가 어떤 목적을 가지고 언제 작성되었는가를 확인하기 위해서 가장 먼저 확인하는 것은 Git의 Commit Message다. 실제로 이를 위해서 git blame 이란 명령어도 git에 존재하고 있다. 저 명렁어를 통해서 특정 코드를 누가 언제, 어느 커밋에서 수정했는지 알 수 있다. 그런데 만약 이때 commit message가 제대로 작성되어 있지 않다면, “작업중”, “커밋", “시작", “수정" 이런 커밋 메세지들로만 이루어져 있다면 이 코드의 히스토리를 파악하기가 힘들어진다. 따라서 커밋 메세지를 올바르게 작성하는 기본적으로 지켜져야 할 사항이다.

개발자는 팀을 이루어서 함께 작업한다. 그렇기에 팀 내에서 일관된 커밋 메시지 규칙을 정하는 것은 필수적이다. 규칙을 정하지 않고 개인이 원하는 형식으로 각자 작성하는건 한 팀에서 한국어, 영어, 불어, 일어, 중국어 등 각자 다른 언어를 사용하는 것과 다름 없는 상황이다. 커밋 메시지에는 정석, 무조건 이런 방식을 따라야 한다라는 정해진 규칙은 없다. 커밋 메세지에 어떤 내용들이 포함되어야 할 지 생각해보고, 팀 내에서 어떤 규칙을 사용할지 레퍼런스를 찾아보고 논의하는 과정을 거치면서 다듬어나가야 한다.

• Git과 GitHub은 단순한 버전관리도구를 넘어선 문서 & 협업 툴이다.
• Git의 가장 기본적인 문서인 커밋 메시지를 잘 작성하는 것이 중요하다.
• 팀으로 작업을 진행한다면 팀의 커밋 메세지 규칙을 정하는 것은 필수적이다.

History 관리 및 브랜치 관리 전략

프로젝트의 전체 흐름이 어떻게 이루어져 있는지를 보기위해서는 전체 커밋의 히스토리를 확인해야 한다. 이 때 만약 master의 commit history가 뒤죽박죽으로 섞여있고 불필요한 Working In Progress와 같은 커밋들이 섞여있다면 전체 히스토리를 파악하기가 힘들어진다. 그리고 히스토리 관리가 제대로 되어 있지 않다면 커밋들이 늘어나면 늘어날수록 점점 맥락을 파악하기가 힘들어질 것이다.

그러면 history를 깔끔하게 유지하기 위해서 커밋을 유의미한 단위로만 해야할까? 명백히 한 단위로 떨어지는 결과물일때만 커밋을 남겨야 하는걸까? 일반적으로 그렇게 하면 커밋을 못한 상태로 작업물을 잃어버릴 우려가 크고 작업중에 최대한 많은 시점에 커밋을 남겨야지 중간중간 돌아가면서 확인하기가 쉬운데 그러한 이점을 누리기가 힘들어진다. 따라서 작업중일때는 원하는만큼 커밋을 남기되, 최종적으로 브랜치의 작업이 완료되고 PR을 통해서 master에 머지 요청을 하기 전 시점에 적절하게 원하는 형태로 커밋을 정리해주면 된다.

Git에서는 squash 를 통해서 여러 커밋들을 하나로 합칠 수 있다. squash 명령을 단독으로 수행할 수는 없으며 일반적으로 rebase 동작을 하면서 interative 모드를 이용해서 squash를 진행해준다.

Git commit squash
스쿼싱이란 여러 개의 연속 커밋을 가져와 하나로 묶는 것이다.
주요 의도는 많은 커밋을 몇 가지 관련 커밋으로 압축하는 것인데, 이렇게 하면 git 기록이 간결하고 명확해진다.
또 다른 용도는 브랜치를 병합하는 과정에서 스쿼싱을 수행하는 것이다. 일반적으로 일부 기능 개발을 위해 메인 브랜치에서 기능 브랜치를 만든다. 기능 완료 후 메인 브랜치에 병합할 때 기능 브랜치에서 수행된 다양한 커밋 메시지를 하나로 스쿼시할 수 있다.

squash의 자세한 사용법은 직접 사용해 보고 다시 정리하자