Computer Science

[CS] 개발자의 기본기, 팀으로 일하기

도리닥닥 2023. 2. 21. 20:05
728x90

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

 흔히 업무를 수행하는데 필요한 지식과 기술을 의미하는 "하드 스킬"과 업무 효율성을 극대화 하기 필요한 "소프트 스킬"로 구분지어서 말하곤 합니다. 개발자에게 있어서 기술적인 역량은 "하드 스킬"이라고 할 수 있지만, 그 외에 필요한 개발자의 역량은 무엇이 있을까?

 

 실제 개발자들에게 업무를 할 때 중요한 역량을 물어보면, 오히려 개발 능력 외에 커뮤니케이션 능력, 소통 능력, 협업 능력, 팀워크를 강조하는 경우가 많습니다. 이러한 것들이 개발자로서 갖춰야할 "소프트 스킬"이라고 할 수 있습니다.

 

 개발자에게 협업과 커뮤니케이션이 강조되는 이유는 개발자 혼자서 하나의 프로덕트를 만들 수 없기 때문입니다. 어느정도 규모가 있는 프로젝트들은 수많은 직군들과 협업을 통해서만 만들어 낼 수 있습니다. 특히 프론트엔드 개발자는 업무 특성상 모든 직군들과 가장 많이 소통을 해야하는 포지션 입니다. 그 중에서는 개발자들도 있지만 마케팅, 디자인, 기획자 처럼 타 직군 사람들과도 있습니다. 따라서, 이런 생소한 영역을 청자를 고려해서 알아들을 수 있게 쉽게 풀어서 설명할 수 있는 능력을 갖추는 것이 중요합니다.

 

 타 직군과의 소통 외에도 개발자간에도 소통은 중요하면서도 어려운 요소입니다. 남에게 내가 구현한 로직을 다른 사람에게 설명하거나, 남의 설명을 듣고 구현을 하는 것은 쉽지 않습니다. 이렇게 프론트엔드 개발자간의 의사소통하기도 힘든데, 다른 개발자와 함께 소통하기 위해서는 더더욱 많은 노력이 필요합니다. 그렇다면 소통을 잘하려면 어떻게 해야할까?

 

소통은 크게 말로하는 소통, 문서로하는 소통으로 나눌 수 있습니다. 말로하는 소통은 내가 말하는 목적이 '상대방을 이해시키기 위함'임을 명심해야 합니다. 그렇기에 내가 알고 있는 것, 말하고자 하는 것을 쏟아내듯이 말하는 것이 아닌, 생각을 잘 정리해서 말하는 것이 중요합니다.

 

 일반적으로 개발자는 말로하는 소통 보다, 문서로 하는 비동기적 소통을 더 많이 하고 선호합니다. 개발자에게 있어서 문서는, commit, PR 그리고 코드입니다. 이러한 문서롤 통해서 개발자들은 서로 의도를 표현하고, 피드백을 주고 받고, 팀의 능률을 올리기 위해 노력합니다. 따라서 문서들의 중요성을 인식하고 이를 잘 작성하고 자 하는 것은 굉장히 중요한 일 입니다.

 

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

 

Git & GitHub

  • Git은 분산 버전 관리 시스템입니다.
  • 깃을 사용해서 코드의 버전을 관리하고, 손쉽게 코드를 롤백하거나, 브랜치에서 개발 후 다른 환경과 병합하는 등의 과정을 손쉽게 활용할 수 있습니다.
  • GitHub은 Git의 원격 저장소입니다. GitHub을 통해 개인적으로만 사용할 수 있었던 Git의 기능들을 여러 사람들에게 공유하고, 팀원들과 공동으로 작업할 수 있습니다.
  • Git과 GitHub은 현재 개발 생태계에서 분산 버전 관리 시스템의 표준입니다. 대부분의 개발팀이 Git과 GitHub또는 GitHub과 유사한 원격 저장소 시스템 등을 활용하면서 작업을 합니다.

 

Commit Message

 Git & GitHub은 이제 버전 관리 시스템을 넘어서서 문서와 협업툴의 역할 또한 수행하고 있습니다. 개발자가 다른 개발자의 코드를 분석할 때 이 코드가 어떤 목적을 가지고 언제 작성되었는가를 확인하기 위해서 가장 먼저 확인하는 것은 Git의 Commit Message입니다. 만약 이때 commit message가 제대로 작성되어 있지 않다면, 코드의 히스토리를 파악하기 힘들어 집니다. 따라서 commit message를 올바르게 작성하는 것은 기본적으로 지켜져야 할 사항입니다.

 

여기에 덧붙여 개발자는 팀으로 이루어서 함께 작업하기 때문에 팀 내에서 일관된 커밋 메시지 규칙을 정하는 것은 필수적입니다. 커밋 메시지에는 정석, 무조건 이런 방식을 따라야 한다라는 정해진 규칙은 없습니다.

 

History 관리 및 Branch 관리 전략

 Git을 사용하면서 개별 커밋 메시지도 중요하지만 프로젝트의 전체 흐름이 어떻게 이루어져 있는지를 보기 위해서는 전체 커밋의 히스토리를 확인하게 될 것입니다. 히스토리가 관리가 제대로 되어 있지 않다면 커밋들이 늘어나면 늘어날 수록 점점 맥락을 파악하기 힘들어질 것입니다.

 

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

 

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

 

 

 

 

출처: 원티드 프리온보딩 인턴십 프론트엔드

https://pollen-port-115.notion.site/1-3-7cf6ac2fbdec4ffca3b45a98029db60e