팀 문화를 만들기!(코드리뷰, 일정관리, 이슈관리)

들어가는 글:

짧은 기간 동안 결과물을 내는 해커톤을 마치고 난 뒤 그전보다는 꽤나 긴 기간을 가지고 진행하는 E2E 프로젝트가 시작되었습니다. 더 많아진 팀원들과 5주로 길어난 프로젝트 기간은 개발적인 부분에서 약간의 여유를 가져다줬지만 그와 함께 팀원들 간의 다양한 소통의 방법이 필요한 순간으로 다가왔습니다.

코드 리뷰, 팀 컨벤션, 일정 및 이슈 관리 등 생각보다 신경 써야 하는 것이 많게 느껴졌습니다.

위 주제를 관련하여 팀 내부에서 고민한 점과 그 고민의 결과물에 대해서 이야기해 보려고 합니다.

팀 문화가 중요한가요?

위 질문에 저도 처음에는 중요성을 딱히 느끼지 못했습니다.

그러나 프로젝트의 진행도에 따라 한 팀 내부에서도 라이브러리, 애플리케이션 등으로 소규모 팀이 나눠지니 일정 공유, 프로젝트 진행 상황 공유 등 팀 소통 역할의 존재감이 드러나기 시작했습니다.

또한 개발 팀 내부에서 아주 중요하게 작용하는 코드 리뷰에서도 팀 문화는 매우 중요하게 되었습니다.

저의 팀의 한 일화를 바탕으로 두겠습니다.

🙍‍♂️: 여러분 PR올렸어요~ 리뷰 부탁드려요

팀원: 네~~

~~N분 후

🙋‍♂️: 여러분 혹시 많이 바쁘신가요..ㅠㅠ 해당 PR이 Merge되어야 다음 작업이 가능해요ㅠㅠ
팀원: 헉 바로 해드릴게요!!ㅠㅠ

팀으로 개발이 진행되다 보면 위와 같은 경험을 종종 하게 될 것이라고 생각됩니다.

kernel 360 과정을 진행하며, 디렉터님들께서 코드 리뷰를 모두가 열심히 참여해라!라고 말씀해 주시곤 합니다.

그러나 코드 리뷰는 어쩔 수 없는 개발의 병목 현상을 가져오기도 합니다.

더불어, 조금은 모두가 예민하게 받아들일 수도 있는 부분이기에 서로의 생각을 맞추는 과정이 꼭 필요했습니다.

그 외에도 일정 관리나, 각 팀별 진행도 등은 오전, 오후 스크럼에서 이야기를 한다고 하여도, 따로 문서화와 같이 가시적인 요소가 없으니 담당자에게 계속해서 질문을 하기도 하였습니다.

저의 팀은 멘토님과의 이야기를 통해 이런 코드 리뷰의 병목 현상 방법과 일정 및 소통과 관련된 팀 문화에 대해 여쭤보았고 그에 대한 답으로 “서로가 이해하고 공유할 수 있는 SUMTIME만의 문화를 만들어보세요!”라는 답을 받았습니다.

그렇게 되면 팀원 모두 공유할 수 있는 우선순위가 생기게 되고 병목을 효과적으로 줄이는 것과 함께, 프로젝트에 이슈가 생겨도 빠른 대처가 가능할 것이라고 생각되었습니다.

따라서 저의 팀 내부에서는 적절한 개발 문화와 팀 내부 문화를 만들어보고자 하였습니다.

코드 관리

다수의 인원이 하나의 프로젝트를 개발하게 된다면 어떤 일이 생길 수 있을까요?

개발 인력이 늘어났으니 더 빠른 개발이 가능해질 것입니다. 그러나 한편으로는 다양한 사람이 한 프로젝트를 구현하게 된다면 각자의 스타일이 담긴 여러 코드가 모여 난잡한 코드가 될 수도 있습니다. 이런 상황을 방지하기 위해 코드를 관리하는 것이 협업에서는 꼭 필요한 부분이라고 생각되었습니다. 해당 부분에서는 리뷰 문화 정하기, 리뷰 자동화 하기 두 가지 섹션을 팀원과 고민해 보았습니다.

리뷰 문화 정하기

코드 리뷰란 리뷰어와 리뷰이가 모두 성장할 수 있는 좋은 기회입니다. 그러나 이는 잘못하면 병목 혹은 불필요한 감성 소모 등으로 이어질 가능성이 있습니다. 그렇기에 사전에 필요한 부분에는 코드 리뷰 문화를 정립하는 것이 매우 중요한 포인트라고 생각했습니다.

SUMTIME 팀 내부에서는 뱅크 샐러드의 코드 리뷰 문화를 참고해 보았습니다.

이 방법은 리뷰이가 지켜야 하는 것과 리뷰어가 지켜야 하는 것이 있습니다.

• 리뷰이가 지켜야 하는 것

  • pr을 올릴 때, 적절한 tag 활용하기

    이 말은 즉, pr에 적절한 tag를 사용하여, 해당 pr의 급함 정도, 우선순위 등을 나타내는 용도로 사용합니다.

    

    위처럼 해당 pr 상태를 서로 공유할 수 있는 rule을 만들어 공유했습니다.

  • Now: 보자마자 바로 리뷰 필요함. 다른 사람의 작업에 영향을 줌

  • BeforeLunch: 점심시간 전까지 리뷰 필요함

  • 5PM: 오후 5시 이전까지 리뷰 필요함

    태그를 달아 PR 담당자에게 그 중요성을 미리 알림으로, 리뷰어가 어느 부분에 더 집중해야 하는지 쉽게 파악할 수 있습니다. 이는 병목 현상을 줄이고, 팀원들 간의 소통을 더 원활하게 만드는 데 효과적이었습니다.

• 리뷰어가 지켜야 하는 것

  • 리뷰의 우선순위 상태를 나타내기

    

    P1 꼭 반영해 주세요 (Request changes) : 버그, 잠재적 버그 또는 코드 컨벤션 위반 시
    P2 웬만하면 반영해 주세요 (Request changes) : 더 나은 접근법이나 코드 품질 향상이 필요할 때
    P3 방식 제안 또는 의견 (Comment) : 다른 방식의 제안이나 기술적인 의견을 제공할 때
    P4 사소한 의견입니다 (Approve) : 코드 승인

    리뷰를 남길 때 해당 리뷰가 어떤 정도를 나타내는지 팀원들과 논의한 뒤, 해당 코드를 사용하여 리뷰를 남길 때 추가하였습니다. 위의 방법을 사용하고부터는 리뷰어의 리뷰 내용이 어떤 정도로 이야기를 한 것인지 코드를 통해 바로 알아 볼 수 있었고, 리뷰이가 적절한 판단을 통해 수락할 수 있었습니다.

    사전에 문화과 규칙을 만들어 놓으니 추가적인 소통 및 감성 소모 없이 협업을 진행할 수 있었습니다.

리뷰 자동에게 맞기기

리뷰를 하다 보면 어떤 것을 리뷰를 해야 하지.. 이것도 리뷰를 해야 하나..?라는 순간이 생기기 마련입니다.

예를 들어 “나는 If 문을 쓰고 내용이 적어도 꼭 중괄호를 쓰는 것이 가독성이 좋지 않나..?”, “return 문 위에 개행을 꼭 하는 편인데 다른 분이 그렇게 하지 않을 경우에 리뷰로 남겨도 될까…?”라는 경우가 있을 것입니다.

그런데 이런 것은 개개인의 스타일이기에 리뷰로 남기기 매우 조심스러운 부분일 것입니다.

이럴 때 사용할 수 있는 것이 컨벤션을 정한 뒤 자동에게 맞기는 방법이 있을 것입니다.

• linter 사용 linter란 코딩 컨벤션과 에러를 체크해 주는 작은 프로그램입니다. 독립적으로 실행할 수도 있고 IDE의 플러그인으로도 존재합니다. 사전에 팀원들과 논의한 컨벤션을 linter에 등록해놓는다면, 사소한 코드 스타일의 부분은 리뷰로 언급해야 할 일이 없어질 것입니다.
  

SUMTIME 내부에서는 esLint와 prettier 등을 사용하여 팀원들 간의 코드에 일정한 컨벤션을 유지하고, 일정하게 정렬할 수 있는 룰을 지정하였습니다.

이러한 자동화 도구와 명확한 리뷰 규칙을 잘 활용하면 팀원 간의 불필요한 논쟁을 줄이고, 리뷰 병목을 방지할 수 있었습니다. 규칙을 정해가면서 느꼈던 가장 중요한 것은 효율성과 투명한 소통이며, 이를 통해 프로젝트 일정에 맞춰 모두가 같은 목표를 향해 나아갈 수 있게 서로를 이해하는 과정이었습니다.

일정 관리

일정 관리와 관련해서는 정말 많은 방법론이 존재합니다.

한편으로는 왜 이렇게 많은 방법이 있을까라는 궁금증으로 돌아오기도 합니다. 간단하게 유추 가능하겠지만 그만큼 정답이 없고 어렵기 때문일 것입니다.

SUMTIME 팀의 상황은 한 팀 내부에 전반적인 애플리케이션 개발 팀과, 애플리케이션에 들어가는 timetable을 오픈소스로 만드는 오픈소스 팀이 내부적으로 나뉘어 진행되었습니다.

한 프로젝트 내에서도 도메인에 따라 분리가 되니 이 두 팀 사이의 소통의 창구가 필요했습니다.

일정 공유하기

소통 창구란 각 팀 내부에서 현재 누가 어떤 작업을 진행하고 있는지, 전체적인 목표는 어떻게 되는지, 목표까지의 진행도는 어떤지 등이 있을 것입니다. 두 팀은 다른 작업을 하더라도 전체적인 얼라인을 맞추고 프로젝트 마감에는 무리가 없게 진행이 되기 위해서 꼭 필요한 상황 공유일 것입니다.

이런 목적을 가지고 SUMTIME 팀에서는 팀별 마일스톤을 세워 주차 별 최종 목표와 최종 목표에 도달하기 위한 일별 목표를 체크 리스트로 남겼습니다.

그러나 생각만큼 계획한 것을 계획한 시간 내에 해내는 것은 어려운 일이었습니다.

개발을 진행하며 모르는 기술을 사용할 때는, 해당 기술을 학습하기 위한 러닝 커브가 존재합니다.

그리고 러닝 커브를 적절하게 개발 일정에 녹여 기간을 산정하는 것은 매우 어려운 일이었습니다. 무한정으로 러닝 커브를 우선시에 두는 것도 불가능 한 일이고, 해당 개념을 잘 알지 못하고 사용한다면 해당 코드는 얼마 가지 못해 레거시 코드가 될 가능성이 매우 큰 부분이기도 합니다.

또한, 이것은 팀원들 간의 투명한 소통이 없다면 누군가는 왜 일을 안하지? 왜 pr이 안올라오지? 등과 같은 의문으로 이어질 가능성도 있을 것입니다. 그러나 경험이 많지 않은 상황에서 어느 정도가 적절한 것일까?라는 고민이 가장 크게 들었습니다.

내가 오랫동안 한 작업을 가지고 있는 것인지, 과하게 러닝에 집착을 하는 것인지, 너무 얕게 알아보고 개발을 하는 것인지 의문 투성이었습니다.

개발 일정 정하기

이런 고민들을 멘토링을 진행할 때, 멘토님께 여쭤보았습니다.

가장 중요한 것은 투명한 소통이라고 하셨습니다. 모순스럽지만 프로젝트의 기간이 짧으면 짧을수록 팀원 간의 많은 이야기를 나눠야한다고 하셨습니다. 처음에는 의아했지만 해당 문장을 곱씹을수록 이는 정말 중요한 문장이었습니다.

프로젝트의 기간이 짧을수록 우선순위에 따른 개발이 중요해지고, 작은 시간도 최대한 헛되지 않게 사용하는 것이 중요할 것입니다. 또한 문서화를 남길 시간이 부족하니 무엇보다 팀원끼리 같은 생각을 가지고 있는 것이 중요할 것입니다. 소위 말하는 “얼라인을 맞춘다”라는 의미겠지요.

서로가 투명하게 서로의 퍼포먼스를 인지하고, 학습이 필요한 기간을 이야기해야 할 것입니다.

적절함의 기준은 정말 다양하게 정해질 수 있겠지만, 키포인트는 “팀원 모두가 이해할 수 있는 정도”일 것입니다.

사회적으로 정해진 선이 있지만 그 바운더리 내에서는 팀원이 이해하고 공유할 수 있는 정도가 적당한 정도의 기준이 될 수 있겠구나 싶었습니다.

예시로는 아래와 같은 상황이 있을 것입니다.

🙋‍♂️: 나는 React-query를 처음 사용해 보는데 기초 지식도 매우 부족한 편이야. 따라서 나는 해당 스택을 이해하는데 4,5일 정도가 걸릴 것 같아.

팀원: 4,5일은 우리의 전체적인 프로젝트 일정에서 조금 부담스러운 시간인 것 같아. 러닝 시간을 2,3일 정도로 줄이고 진행하는건 어때? 이후, 개인 공부를 통해서 부족한 부분은 학습하고 리펙토링을진행하고, 현재는 구현이라는 것에 초점을 맞춰보는 것이 우리 일정에 적합할 것 같아.

…2일 후…

🙋‍♂️: 진행해 보았는데 해당 개념이 어렵게 느껴져서 러닝에 대한 기간이 더 필요한 것 같아. 아니면, 혹시 해당 개념을 아는 사람이 있다면, 도와줄 수 있을까?

위와 같은 식으로 일정을 정하고 수행해나갈 수 있을 것입니다.

팀원 간의 소통을 통해 정한 일정에서 과하게 벗어나는 일은 피할 수 있을 것입니다. 앞서 이야기한 것처럼 중요한 포인트는 팀원 간의 투명한 소통일 것입니다. 일정이 수정되더라도 이것을 팀원들이 빠르게 공유하고 전체 일정에 무리가 없도록 후속 작업들을 조절할 수 있을 것입니다.

위에서 이야기한 것처럼 에자일의 핵심은 유연성과 소통입니다. 계획된 일정과 실제 상황 사이에서 발생하는 차이를 빠르게 인지하고, 필요에 따라 일정을 조정하는 것을 중요하게 생각합니다. 에자일하게 프로젝트를 진행하며, 점점 더 효율적으로 문제를 해결할 수 있게 되고, 최종적으로는 프로젝트 목표에 도달할 수 있을 것입니다.

이슈 관리

일정을 잡고 개발을 진행을 하면서도 다양한 상황에 마주할 수 있었습니다.

기획에서 빠뜨린 부분, 코드 리뷰에서 발견하지 못했던 버그, 결과물에서 아쉬운 부분 등등 다양한 이슈들을 마주치게 됩니다. 이런 것을 코드리뷰로 남기긴 하지만 이것들이 한 곳에 아카이빙 되지는 않아 까먹기 일쑤였습니다.

이것을 어떻게 해결하고 한 곳에서 확인 할 수 있을지 고민하던 중, 깃허브의 프로젝트를 활용해 보기로 하였습니다.

1. 현재 github을 사용하고 있어 접근성이 좋음
2. Issue, PR 와 함께 관리가 가능함

위와 같은 장점을 가지고 있어 SUMTIME은 github Project를 활용하여 이슈를 관리하기로 하였습니다.

프로젝트를 생성하며 중요하게 생각했던 것은 “backlog”였습니다.

코드리뷰를 하거나, 프로젝트를 살펴보다 발견한 이슈들을 backlog에 하나의 카드로 남기기로 하였습니다.

남길 때도 속성을 활용하여, 해당 이슈가 application 파트인지 library 즉 오픈소스의 이슈인지 옵션을 걸어 해당 요소를 작업할 사람에게 정보를 넘겨주도록 하였습니다.

타이틀, 이슈와 관련된 사진이 있다면 사진, 발생하게 된 경로를 작성하여 해당 이슈를 다른 사람이 다시 묻지 않아도 되게 작성하며, 본인이 파악하기에 해당 이슈의 원인이 있다면 그것도 같이 작성하였습니다.

백로그를 활용하면서, 작은 요소들이 뭉쳐 전체적인 프로젝트의 품질을 올릴 수 있음을 느낄 수 있었습니다.

추가적으로 내가 놓쳤던 부분을 확인 가능하고 다음 개발에서는 동일한 실수를 하지 않게 주의를 하게 되었습니다.

느낀 점

여러 아티클을 읽어보고 우리 팀에 적합한 협업 문화를 만들어 나가기 위한 고민을 기록해보았습니다. 이번 Kernel 과정에서 협업은 매우 중요한 요소였고, 이를 효율적이고 효과적으로 진행하는 방법에 대해 깊이 생각해보는 기회가 되었습니다.

다양한 아티클을 통해 우리 팀에 녹여낼 방안을 고민한 경험은 의미 있는 활동이었습니다. 앞으로 회사나 큰 조직에 들어갔을 때, 직접 문화를 만들어볼 기회가 있을지 모르지만, 필요성을 느껴 문화를 구축해 본 경험은 매우 소중하다고 생각합니다. 이를 통해 다른 조직에서 다양한 규칙이 존재하는 이유를 더 잘 이해할 수 있을 것입니다.

알고 따르는 것과 그저 따르는 것에는 큰 차이가 있다고 생각합니다. 만약 의견을 제시할 수 있는 기회가 생긴다면, 그때 이 경험을 잘 활용할 수 있을 것입니다.

개발 실력을 키우는 것도 중요하지만, 다른 사람과 협업하며 더 큰 시너지를 내는 것에 가치를 두고 있었기에, 이번 기회를 통해 더 넓은 시야로 다양한 관점을 고민할 수 있었습니다. 그 결과, 한층 성장한 느낌을 받아 매우 뿌듯합니다.

앞으로도 꾸준히 더 나은 방식을 찾기 위해 고민하며, 팀에 적합한 협업 방식을 찾기 위해 노력하는 팀원이 되고자 합니다.