팀에서 개발자로서 잘 협업하는 방법

 

안녕하세요! NewCodes입니다!

 

최근에 그룹 프로젝트에서

협업을 하며 생긴 습관과 TIP에 대해

총정리해보고자 합니다. 

 

이를 바탕으로 더 나은 협업을 위한 

발판으로 삼아보겠습니다!

 

🎯 이 글을 통해 얻어갈 수 있는 것

1. 개발 작업할 때 사소하지만 꼭 필요한 태도와 TIP
2. 코드리뷰를 유익하게 잘 주고받는 방법
3. 팀에 조금이라도 더 기여하는 방법

 

---

📝 작업을 본격적으로 시작하기 전 

1) 요구사항을 꼼꼼히 읽으며 파악하자. 

 : 요구사항을 파악하는 건 기본 중에 기본이다. 요구사항이 이해가 되더라도 한 두 번은 더 읽어봐야 한다. 굳이 이렇게 해야 하는 이유는 요구사항을 오인했을 때 나중에 수정하는 비용이 다소 크기 때문이다. 작업 초반에 일어난 실수일수록 후반에 잡기가 힘들어진다. 또, 요구사항은 대부분 명확하지 않을 수 있기에 요구사항에 의문이 든다면 팀원과 의논하는 게 좋다. 

⭐️ NewCodes' TIP ⭐️
요구사항은 무조건 2번 이상 진득하게 읽자!

 

2) 간단해 보이는 작업이라도 차분히 설계하고 들어가자. 

하루 작업에 대해 작은 Todo로 쪼갠 예시

 : 작업을 할 때는 급하게 코드부터 작성해서는 안 된다. 언뜻 보기에 간단해 보이더라도 충분히 설계하고 들어가는 게 좋다. 코드를 작성하기 이전에 요구사항을 읽고 설계하는 데 시간을 투자하는 걸 아까워해서는 안 된다. 설계라고 해서 거창할 필요가 없다. 우선 해당 작업을 완수하기 위해서 어떤 일들을 해야 하는지 작은 단위로 작업을 쪼개보자. 그리고 중요하다고 생각하는 단위에 대해서는 어떻게 구현할지 계획을 세워보면 된다. 이는 오늘 작업하는 나에게 기준점이자 좋은 나침반이 될 수 있다. 

⭐️ NewCodes' TIP ⭐️
하나의 작업이라도 여러 작은 단위의 Todo로 쪼개보고 시작하자!

 

 

---

💻 작업을 하는 중

1) 근거 있는 코드를 작성하자. 

 : 스스로 작성한 코드에 대해서 설명할 수 있는 건 정말 중요하다. 내가 작성한 코드에 대해서 잘 설명하지 못하거나, 별 이유 없이 복사 붙여넣기한 코드라면 팀에서 곤란해지는 경우가 생긴다. 곤란한 경우는 다음과 같다. 해당 코드로 인해 버그가 생겼을 때, 곧바로 대응하기가 어렵다. 내가 작성한 코드에 대해 동료가 리팩토링, 최적화 등의 이유로 의견을 물을 때 제대로 답변할 수 없다. 

 근거 있는 코드란 다음과 같다. 라이브러리를 썼다면 무슨 이유로 썼고, 그로 인한 장단점은 무엇인지 설명할 수 있다. 해당 자료구조 혹은 알고리즘을 채택한 이유를 논리적으로 설득할 수 있다. AI를 사용했다면 코드를 그대로 붙여넣기하지 않고, 비판적으로 검토하며 내 것으로 소화할 수 있다. 

⭐️ NewCodes' TIP ⭐️
코드 한 줄 한 줄 생각을 담아서 작성하자!

 

2) 일관성 있는 코드를 작성하자. 

 : 일관성 있는 코드는 읽기 쉽다. 읽기 쉬우면 유지보수에도 편하다. 이때 일관적이라는 기준은 상황마다 다를 수 있다. 가장 우선시 고려해야 하는 건 팀의 코드 컨벤션일 것이다. 그다음으로는 내가 프로젝트에서 이전에 작업했던 결과물에 비추어 판단해 볼 수 있다. 네이밍을 짓는 방식이 일관적인지, 폴더 및 파일 구조가 일관적인지, 코드 포맷팅이 일관적인지, 에러 처리 방식이 일관적인지, 환경 변수 사용 방식이 일관적인지 등등 다양한 측면이 있다. 

⭐️ NewCodes' TIP ⭐️
코드를 작성하기 전에 관련된 코드를 열고 이전에는 어떻게 했는지 살펴보자!

 

3) 처음부터 완벽하게 코드를 작성한다는 마음을 내려두자. 

 : 우선 동작하는 코드를 작성하는 데 초점을 두자. 그러고나서 조금씩 뜯어고치면 된다. 이때 뜯어고치는 타이밍을 잘 잡아야 한다. 너무 먼 길을 오면 고치기가 어려울 수 있기 때문이다. 초반에 했던 게 휘발이 될 것 같다거나 깊게 딥다이브를 한 번 했다면 다시 돌아와서 작업한 결과물을 되돌아보며 개선하는 게 좋다. 

⭐️ NewCodes' TIP ⭐️
알고리즘 문제를 정해진 시간 안에 풀고 점진적으로 개선하는 연습을 해보자! 

 

4) 개발일지를 작성하며 나의 사고 과정을 남기자. 

최근 작성한 개발일지

 : 개발일지는 필수는 아니지만, 왠만하면 작성하는 게 좋다. 개발일지 작성하는 게 습관화가 되어있지 않다면, 적는 게 어려울 수 있다. 하지만 습관만 들어두면 여러모로 이점을 얻을 수 있다. 든든한 보조기억장치로서 역할을 한다. 개발 중에 불가피하게 잠깐 다른 일을 하고 오거나 쉬었다 와도 어디까지 했고 무엇을 고민하고 있었는지 금방 캐치할 수 있다. 작업을 다 한 이후에는 PR을 작성할 때 내가 어떤 작업을 했는지 돌아볼 수 있게 된다. 또, 팀에 관련 작업 상황을 공유해야 하거나 내가 해당 작업을 복기해야 하는 경우가 있을 때 탁월한 참고 자료가 된다. 

⭐️ NewCodes' TIP ⭐️
개발일지 창은 한 곳에 항상 띄워두고, 나의 사고과정을 수시로 남기자!

 

5) 공식 레퍼런스를 참고하며 신뢰성을 높이자. 

 : 개발을 하다보면 생각보다 공식 레퍼런스에 답이 나와있는 경우가 많다. 물론 공식적인 자료는 접근성이 그렇게 좋지는 않다. 내가 원하는 자료가 어디에 있는지 직접 찾아야 하고, 원하는 정보가 없을 확률도 있기 때문이다. 그럼에도 공식 자료를 보려는 노력을 하는 게 좋다. 그래야 내 코드에도 확신이 생기기 마련이고, 막혔던 부분에 대해서 힌트를 얻을 수도 있다. 

⭐️ NewCodes' TIP ⭐️
레퍼런스를 탐색할 때는 '신뢰성'을 중요시 여기자. 그러면 자연스레 공식문서로 향할 것이다!

 

 

---

🚀 작업을 다 하고 나서 

1) 코드가 잘 돌아가는지 테스트하자. 

 : PR을 올리기 전에는 항상 내가 작성한 코드가 잘 작동하는지 테스트하는 건 기본 중에 기본이다. 꼭 테스트 코드를 작성하는 게 아니더라도 포스트맨으로 간단한 API 테스트 정도는 해볼 수 있을 것이다. 이와 더불어 관련한 엣지케이스도 고려할 수 있으면 좋다. 또, 기존의 테스트 코드가 잘 돌아가는지도 확인해야 한다. 기존의 코드에 영향을 주어서는 안 되기 때문이다. 

⭐️ NewCodes' TIP ⭐️
작업을 하고 나서 '처음 테스트'할 때 브라우저를 통해 수동적으로 테스트하는 게 아니라,
테스트 코드를 직접 작성해 자동화된 테스트를 시도하자!

 

2) 코드를 수동으로 점검하자. 

 : 자동화된 테스트 도구에게만 내 코드를 점검하게 하기 보다는 수동으로 점검하는 노력도 필요하다. 처음 보는 사람 입장에서 가독성은 괜찮을지, 일관성 있게 코드가 짜여졌는지, 근거를 설명할 수 없는 코드가 있는지, 주석으로 단 설명이 적절한지 등등 분명 스스로 체크해보자.

⭐️ NewCodes' TIP ⭐️
커밋하기 전에 코드를 다시 읽어보는 습관을 기르자!

 

3) PR에 문제해결과정을 담자. 

문제해결과정을 담은 PR 예시

 : PR에 무엇을 작성할지는 팀마다 다르겠지만, 문제해결과정을 적어두는 게 좋다고 생각한다. 거창할 필요는 없다. 어째서 문제가 발생했고 어떻게 해결했는지 간단하게나마 드러내주면 된다. 그러면 PR을 보는 사람으로 하여금 이 사람이 어떤 작업을 했으며 어떤 문제를 해결했는지 더욱 잘 파악할 수 있다. 또한, 나중에 내가 한 작업을 정리해야 하는 상황이 생길 때나 관련 디버깅을 해야 할 때 좋은 참고 자료가 될 수 있다. 

⭐️ NewCodes' TIP ⭐️
작성했던 개발일지 중 가장 주요했던 부분을 가져와보자!

 

 

---

🕵🏻‍♂️ 코드 리뷰를 작성할 때

1) 코드 리뷰를 남길 때는 기준을 정하자. 

 : 상황마다 코드 리뷰를 어떻게 남기는지 달라지겠지만, 나는 보편적으로 아래와 같은 범주에서 코멘트를 남긴다. 

• 예외 케이스에 대해 처리가 안 된 부분이 있다면 언급
• 성능적인 면에서 더 나은 방법이 있다면 제시
• 장애 가능성이 있어보이는 부분 체크 
• 특정 함수, 모듈의 역할과 책임이 적절한지
• 일관적이지 않게 작성된 코드에 대해 언급 
• 중복된 코드가 다소 반복되면 모듈화 제시 
• 함수, 변수의 더 나은 네이밍이 있다면 제시 
• 상수로 따로 관리했으면 하는 것 

(코드 리뷰 관련해서는 아래 글도 추천드립니다!)

좋은 코드리뷰란 OOO이다. 

좋은 코드리뷰란 OOO이다.

⭐️ NewCodes' TIP ⭐️
PR에서 코드를 본격적으로 읽기 전에 중점적으로 보고자 하는 걸 생각하고 들어가자!

 

2) 피드백을 줄 때는 상대방을 고려하자. 

 : 피드백을 주고 받을 때는 항상 상대방에 대한 존중이 기저에 깔려있어야 한다. 개발자는 주로 기계와 대화하는 사람이지만, 사람과 이야기할 때에도 기계처럼 대해서는 안 된다. 상대방의 결과물에 대해서 피드백을 할 때는 상대방이 공들여 노력한 결과물임을 우선 인식해야 한다.

⭐️ NewCodes' TIP ⭐️
"이 부분은 이러이러해서 이렇게 하는 게 어떨까요?",
"이렇게 하면 이러한 부분이 좋아질 것 같아요."와 같은 말투로 피드백을 전달하자!

 

3) 피드백을 받을 때는 나의 결과물에 대한 피드백임을 인지하자.

 : 피드백을 받을 때 주의해야 하는 건 오로지 나 자신을 향한 피드백이라고 오해해서는 안 된다. 오로지 나의 결과물에 대해 피드백을 받은 것이며, 자존감을 깎아내리거나 주저앉을 필요가 전혀 없다. 물론 내가 정말 노력한 결과물에 대해서 날카로운 피드백을 받거나 예상치 못한 혹평을 받으면 기분이 안 좋기 마련이다. 그래도 결국엔 이를 이겨내야 한다. 돌이켜보면 듣기 좋은 피드백보다는 조금은 아팠던 피드백들이 나의 성장에 도움이 훨씬 더 많이 되었다. 마지막으로 최대한 열려있는 자세로 피드백을 받아들이되, 비판적으로 사고하여 소화하자. 

⭐️ NewCodes' TIP ⭐️
어쩔 수 없이 피드백이 아플 때는 잠시 환기하는 시간을 가지자!

 

 

---

🤗 팀으로 함께 한다는 것

1) 팀에서 매일 하는 루틴을 형성하자.

매일 회고하는 문화

 : 팀에서 함께 하는 루틴을 만들면 시너지가 나고 긍정적인 효과가 많이 생긴다. 최근 진행한 그룹 프로젝트에서 매일 개발일지 작성하는 문화, 매일 회고하는 문화를 형성한 적이 있다. 덕분에 팀 내 공유가 활성화되었고, 서로가 어떤 작업을 하고 있는지 어떤 게 어려운지 등을 빠르게 파악할 수 있었다. 또한, 아침 데일리 스크럼에는 TMI를 공유하고 스트레칭을 하며 서로 워밍업하는 시간을 가지기도 하며 친밀해지는 계기가 되기도 했다. 

⭐️ NewCodes' TIP ⭐️
팀 문화를 만들고 싶다면 나부터 먼저 하고 이를 매일 공유하자!

 

2) 동료가 잘한 일이 있다면 칭찬을 아끼지 말자. 

 : 동료가 팀에 기여를 한 일이 있다면 사소한 거라도 칭찬을 아끼지 말아야 한다. 이는 그 동료에게 노력을 인정해주는 것뿐만 아니라 팀 전체에 긍정적인 효과를 가져다준다. 팀 내에서 동료들의 선행이 공유되면 공유될수록 그 집단은 건강하게 성장할 확률이 높다. 그러한 선행은 보통 하나로 끝나지 않고, 어떠한 방식으로든 이어지는 경우가 있기 때문이다. 또, 칭찬을 하며 업된 분위기는 서로에게 친밀해질 수 있는 기회가 되기도 한다. 

⭐️ NewCodes' TIP ⭐️
하루에 한 번은 칭찬한다고 생각하자!

 

 

---

🔥 마무리

그룹프로젝트 이후 돌이켜보니 제 스스로가 이전보다 훨씬 성장했네요. 혼자 공부하고 혼자 개발할 때는 이런 것들을 몰랐는데 말이죠.

 

이상 마치겠습니다! 혹시 질문이 있으시면 편하게 댓글 남겨주세요!