첫 협업 프로젝트를 준비하면서 가장 큰 고민이 무엇인가요?
리아와 스펜서가 여러분들의 고민을 모아 멘토님에게 조언을 구해보았습니다!
코발트에서 함께 근무하고, 데브코스에서 멘토로 활동해 주시는 김지은&조규현 멘토님과 첫 협업을 멋지게 시작해봅시다. 🏃🏃🏻♂️
- 마지막 업데이트 일시: 2021-11-26
- 질문자: 리아
- 답변자: 프론트 멘토 김지은님, 백엔드 멘토 조규현님
Github 관련
실무에서 프론트, 백 레포를 각각 만드나요(monorepo, multirepo)?
Q. 데브코스에서는 통합 Org에 각 팀이 Repository(이하 레포)를 생성하는데요. 프론트, 백엔드 따로 레포를 생성할지 혹은 하나로 관리할지 고민이 됩니다.
지은 멘토
저희 회사는 따로 사용하고 있고, 프론트 내에서만 monorepo 구조로 되어 있습니다. 서로 각 장단점이 있습니다. 백엔드, 프론트 둘다 javascript를 사용한다면 monorepo가 장점이 될 수 있습니다. (같은 모델을 사용 할 수도 있으니깐요) 하지만 저희 회사처럼 프론트는 javascript 백엔드는 ktolin을 사용한다면 따로 나누는게 맞습니다.규현 멘토
실무에서는 정해져 있다고 말씀드리기 어려운것 같습니다. 다만 프로젝트 유형 따라 어느 정도 정해져 있을 것이라 생각합니다. 다중 레포로 관리하게 된다면 관심사와 설정값을 따로 관리 할 수 있는 장점이 있지만, 분리된 만큼 각 저장소를 따로 관리가 되어야 할 것 입니다. (예를 들어 CI/CD, 이슈트레커, wiki, realse 등등 분리된 만큼 관리되는 대상이 늘어 날것 입니다.)
단일 레포로 관리하게 된다면 버전 기록이 한곳에 파악 및 관리를 할 수 있습니다. 하나의 저장소만 신경쓰면 되기때문에 관리포인트가 줄어 듭니다. 단점도 마찬가지로 한가지로 통일 되어 있으니 분리 해서 보기가 힘들 수도 있습니다.
(TMI) 여러분이 자주 이용하시는 또한 모노레포로 관리 되고 있습니다.
무엇보다도 먼저 다중, 단일 저장소의 장단점을 살펴 본뒤 팀원 분들과 협의 하는것이 가장 중요하다고 생각합니다. (결국 프로젝트를 만들어 나가는 사람의 의견이 제일 중요하다고 생각합니다.)
함께 읽으면 좋은 링크
회사마다 다르겠지만 지은, 규현님이 근무하시는 코발트에서의 깃헙 이슈 관리 규칙이 궁금합니다!
지은 멘토- 저희의 이슈는 크게4가지 입니다. 버그, 개선, 기능, 리팩토링
- 이슈 라벨을 다음과 같이 정했습니다. (개선, 기능, 버그, 디자인, 에픽, 리팩토링, 릴리즈, 문서)
- 이슈에 따라 문서를 다르게 적습니다.
- 개선이면 기존과 무엇이 개선이 되었는지, 연관된 이슈가 무엇인지,
- 버그라면 버그설명, 재현경로, 필요하다면 스크린샷 등 어떤 환경에서 버그가 발생되었는지.
- 그리고 연관된 이슈가 있으면 같이 링크를 걸어주고, 이 이슈의 pr이 생긴다면 linked pull request에 pr을 연결합니다.
규현 멘토- 저희는 시나리오 기반(문서, 다이어그램) 으로 이슈를 생성하고 있습니다.
- 시퀀스 다이어그램을 활용한다면 로직 흐름을 정리 할 수 있어서 좋습니다.
- 다이어그램을 활용하다면 의사소통의 비용을 낮출수 있습니다.
- 해당 이슈 내용중 중요한 내용은 체크리스트로 관리합니다.
- 연관 이슈 이외에도 디자인, 혹은 관련 링크가 있다면 최대한 많이 링크를 걸어 줍니다.
추천 도구
실무에서 통상적으로 쓰이는 PR 템플릿이 있나요?
Q. 템플릿은 아니더라도 반드시 PR에는 이런 내용이 포함되어야 할 것 같다~라는 멘토님의 의견도 궁금합니다.
지은 멘토- 일반적으로 많이 쓰이는 템플릿은 있지만, 보통 회사에서 만들어서 사용합니다. 저희는 아래와 같은 내용을 작성합니다.
- 연관이슈, PR설명, 리뷰할 부분, 비고
- 어떤 이슈랑 연관되었는지. PR설명 (어떤 기능이 추가되었거나, 어떤 버그를 수정했는지 등)
- 커밋 리스트 중에서 한 커밋만 리뷰를 받고 싶다면 이 커밋만 리뷰해 달라는 내용도 적습니다.
- 그리고 작업하다가 고민되는 부분도 비고란에 적기도 합니다.
- 가끔 이슈에서 브랜치를 따 작업하다가 PR올릴때 이슈와 관련 없는 코드를 작성 할 때도 있습니다. 이럴경우는 따로 이슈를 만들어서 다른 브랜치에서 작업 후 따로 PR을 올려야 합니다.
- 최대한 PR은 관련된 이슈와 관련된 내용으로 올리고, 최대한 작은 단위로 올립니다.
- 너무 덩치가 커지면 리뷰해주는 사람도 보기가 힘들어집니다.
그 외 Github 관련하여 유의해야 할 것들이 있을까요?
Q. 실제 함께 협업 중인 두 분에게 각각 프론트, 백엔드 입장에서의 조언도 궁금합니다.
지은 멘토- 처음에 git 사용 규칙을 잘 정해서 사용하시면 될 것 같아요.
- 충돌나는 걸 무서워해 다른 사람의 코드 merge하는걸 기다렸다가 거기에서 브랜치 따서 작업하고 이러진 않았으면 좋겠습니다.
- 유의해야 할 것들보다는 git 기능들을 이것저것 많이 사용해보시는 걸 추천드립니다.
- 나중에 git 커밋정리, git 꼬였을때 당황하지 않고 잘 해결 할 수 있도록요!
규현 멘토- 항상 실행 가능해야 하는 브랜치와, 개발을 진행하는 브랜치를 잘 나누어서 관리하는 것이 좋을 것 같습니다.
- Force push 를 지양 하는 것이 좋을 것 같습니다.
- 합칠수 있는 커밋은 최대한 합치는 것이 좋을 것 같습니다.
- rebase 를 잘 활용 하면 좋을 것 같아요
Workflow 관련 (작성 예정)
참고 링크
협업 관련
어떻게 일을 분배해야 할까요?
Q. 개인 또는 소수의 인원과 협업을 진행했지만 이번처럼 많은 인원과의 협업은 처음입니다. 일을 분배할 때 보통 어떤 식으로 결정하게 되나요? 팀장이 적재적소에 배치해 주는지, 만약 팀장이 없다면 현명한 방법이 있을지도 궁금합니다.
지은 멘토- 저희는 먼저 디자인 보고 페이지 단위로 일을 우선순위 정합니다.
- 이때는 필요에 의하면 기획자까지 참여해서 어느 페이지를 선작업 해줬으면 좋겠다고 의견을 주면 거기에 맞춰서 작업을 합니다.
- 그 페이지 안에서도 목록을 가져오는 api를 먼저 요청하고, 그 다음에 조작하는(PUT, PATCH, DELETE) api를 요청합니다.
- 보통은 프론트가 백엔드한테 api 작업 순서를 요청드리는 것 같아요!
- 목록을 가져오는 api요청하기 전에 디자인을 보고 response모델을 같이 정의한 후에 각자(프론트,백엔드) 작업을 시작합니다. (최소 와이어프레임)
- 만약 업무 정리가 안되어서 우왕좌와 하고 있을때는 팀장이 일정에 차질 없도록 업무를 정해서 우선순위 매겨줍니다 (이런것들의 팀장님 역할 아닐까요?ㅎㅎ)
규현 멘토- 해당 스프린트에 관련 일정들을 체크하고 우선순위를 먼저 정합니다.
- 모든 사람이 함께 참여하여 우선순위를 함께 정합니다.
- 선행이 필요한 작업이 있을 수도 있지만 없을 수도 있습니다.
- 스프린트에 포함 되지 않는 일은 해당 스프린트에서 일을 결정합니다.
- 기능 개발 이외에도 개발자가 해야 하는 일은 여러 가지 있다고 생각합니다.
- 인프라, 문서, 기획, 회의도 업무에 포함됩니다.
- 모든 인원이 같은 일을 할 필요는 없다고 생각합니다.
- 도메인 기준으로 나눠서 일을 해도 좋습니다.
- 이슈 유형으로 나눠도 좋습니다.
- 리팩토링이 필요할 경우 모두 다같이 리팩토링 할 필요는 없다고 생각합니다.
협업을 위해 뭐부터 시작해야 할까요? 😢
Q. 지금 우리는 아래와 같은 고민을 갖고 있어요. - FE : 백엔드가 어떻게 구성되어있는지 모르니 어떻게 요청드려야할 지 모르겠다. - BE : 프론트 파트에서 기능명세서를 주셔야 우리가 도와드릴 수 있을 것 같다. 그래서 시작조차 하지 못하고 있는데요... 뭐부터 시작해야 할지, 어떻게 풀어나가야 할지 고민입니다.
지은 멘토- 서로 어디서 대화를 주고받을건지, api문서는 어디서 확인할 건지, 각자 작업상황을 어떻게 확인할 건지 작업 순서를 어떻게 가져갈건지 이런걸 정해야 겠죠?
- 그 다음에 할일을 정해서 작업 할 티켓(이슈)를 먼저 만듭니다.
- 그리고 이슈가 생길때 저희는 인력이 별로 없기 때문에 슬랙 DM으로 바로 요청하거나, 바쁠떄는 github issue, pr comment를 적극적으로 사용하고 있습니다.
- 기능 명세서를 작성한다면 저는 프론트, 백엔드가 같이 작성하는 것이 맞다고 생각합니다.
- 백엔드에서 Rest api를 사용한다면 response 모델을 같이 어느정도 맞추고 작업을 시작하는 것도 좋을 것 같습니다.
규현 멘토- 첫 번째로 서비스, 기획에 대한 공통적인 이해를 먼저 하는 것이 좋을 것 같습니다.
- 협업 툴을 정합니다.
- 어떤 툴을 사용할 것인지, 해당 툴에서는 어떠한 것들을 담당할지 정합니다.
- 서비스에서 필요한 기능들을 나열합니다. 큰 항목부터 세부적으로 정리합니다.
- 스프린트를 정합니다.
- 해당 스프린트에서 작업 할 기능들을 정하고, 함께 회의를 진행합니다.
- 어떤 화면들이 필요한지, 어떤 기능들이 있는지 함께 진행합니다.
- API 스펙을 함께 정하여 프론트엔드 & 백엔드가 병렬로 개발 할 수 있도록합니다.
- 엔드포인트, Request, Response 가 정의 되어 있다면 어느 한쪽이 완료 되지 않더라도 개발을 할 수있습니다.
- 스프린트를 기반으로 할일 목록(이슈) 들을 작성합니다.
- 스프린트를 시작하면서 각각의 티켓 (할일) 을 상태(완료 여부)를 알려줍니다.
- 완료된 티켓(할일) 에 대해 연동하고, 함께 QA 를 진행합니다.
- QA 에서 버그, 개선점이 생긴다면 해당 티켓(할일) 에 관련된 사람을 멘션을 이용하여 comment 를 남깁니다. (비동기적으로 일 할 수 있어요)
- 핫픽스일 경우 최대한 핫픽스에 먼저 집중하여 해결 합니다.
스크럼은 모두가 함께하나요?
Q. 스크럼은 각 포지션끼리 하는지 혹은 모두가 함께하는지 궁금합니다! 그리고 어떤 이야기를 주로 나누는지도 궁금해요.
지은 멘토- 네 저희는 모두가 함께합니다. 일단 저희가 전원 인력이 적기 때문에 한팀으로 이루어집니다.
- 그리고 모두가 함께 해야 작업 진행상황이 공유가 되며, 막히는 부분이 어딘지 알 수 있고 같이 해결 하는데 더 좋다고 생각합니다.
- 단 모두가 솔직해야 합니다! 적극적이어야 하고요!
규현 멘토- 관련된 모든 인원이 참여하게 됩니다.
- 현재 진행 상태와 진행중 발생하는 문제점, 이슈들에 대해 공유합니다.
- 이슈해결에 있어 시간이 많이 소요될 경우 일정을 재산정하기도 하며, 같이 해당 자리에서 같이 해결하기도 합니다.
- 이슈에 관련해서는 숨기거나 부끄러워 할 필요가 없습니다.
- 혼자 해결하지 못했다는 생각보다 더 빨리 해결하기 위해 공유한다고 생각하면 좋습니다.
- 개발자들은 백로그에 있는 작업이 얼마나 남았는지 공유합니다.
- 번다운 차트를 통해 스프린트 동안 얼마나 작업이 남았는지 추적 할 수 있습니다.
하나의 이슈를 처리하는 흐름이 궁금합니다.
지은 멘토- 스프린트에 먼저 개발할 기능을 정합니다.
- 기획자, 디자이너가 화면을 구성합니다. (없다면 개발자 끼리 와이어프레임을 그립니다.)
- 개발자 끼리 작업 우선순위를 정합니다.
- 에픽단위의 이슈를 만듭니다. (상황에 따라 기능이슈일 수 있습니다)
- 백엔드, 프론트 각자 이슈를 만듭니다. 이슈에 설명을 자세하게 적습니다.
- 이슈에도 체크리스트를 따로 만들어서 작업이 어디까지 되고 있는지 상황 파악도 합니다.
- 해당 이슈의 작업을 할 브랜치를 땁니다.
- 이슈가 크다면 브랜치를 여러번 만들어서 PR을 여러번 날립니다.
- PR 리뷰가 마무리 된다면 머지를 합니다.
- QA후 버그 수정까지 마무리가 되어 운영에 배포가 된다면 이슈를 close 합니다.
찐 동료로서 규현님, 지은님이 협업 시 유의할 점을 조언해 주신다면 어떤 것이 있을까요?
지은 멘토- 다른 사람이 작성한 코드를 존중 해줍니다. (서로 성장하는데 도움을 주어야 합니다)
- 예를 들어, 프론트개발자가 컴포넌트를 공통으로 만들어서 작업을 해야하는데 다른 api가 수정이 필요하다. 수정요청 했을때 백엔드 개발자한테 충분한 이해를 시킨다. 그런데 충분한 이해가 안 되었다. 백엔드 개발자는 프론트 개발자가 작성한 코드를 내려받고 왜 response를 바꿔야 하는지 분석하려고 하지 않는다. 다른 충분한 방법으로도 제안 할 수 있다. (서로 존중해줘야 합니다)
- 이럴때 프론트 개발자는 백엔드 구조 및 상황 설명을 듣고 왜 바꿔줄 수 없는지 파악한다. 서로 이 건에 대해 어떻게 해결할지 논의한다. (이런게 건강한 논의라고 생각합니다.)
- 다른 예시로는 프론트가 백엔드 조금 안다고 또는 백엔드가 프론트 조금 안다고 훈수를 두면 안된다. 예를들어 프론트가 백엔드 쿼리 조금 안다고 백엔드개발자는 열심히 개발하고 있는데, 여기는 이 쿼리 쓰면 될텐데 그 쿼리 쓰신거에요?, 또는 백엔드가 프론트 조금 안다고 여기는 response를 이렇게 줄 테니 화면을 이런 방식으로 만드시면 될거에요. 이런 훈수를 두게 되면 상대방이 기분 나쁠 수 있다. (물론 안 그런 사람도 있을테지만) 모를때 물어보고 서로 같이 해결하는 방식이 좋을 것 같습니다.
- 이것은 백엔드-프론트 사이가 아니더라도 프론트-프론트, 백엔드-백엔드 에서도 조심해야 할 것 같아요
- 그리고, 남이 작성한 코드 또는 남이 해결하지 못하고 있는 코드를 재작성 하려고 할때 조심스레 물어본다. 이 코드 이부분보다는 이렇게 수정하는 것이 더 가독성에 좋을 것 같은데 같이 바꿔봐도 될까요? 제가 바꿔도 괜찮을까요? 등.
- 서로 의견을 낼때 혼동되는 용어가 오간다면 용어를 정해서 한 용어로만 대화합니다. 서로 협업하며 단어 사용으로 헷갈리는 부분을 최소화 해야 합니다.
규현 멘토- 이기려고 논쟁을 하기보다는 현 상황에 선택 가능한것들에 대해 논의 하는 것이 좋습니다.
- 기억에 의존된 논의 보다 자료 기반의 논의를 하는 것이 좋습니다.
- 자료가 없다면 다같이 회의 하여 불필요한 논쟁을 줄입니다.
- 간혹 내가 기억하기론.. 이라는 말을 할 때가 많습니다.
- 당연하다고 생각하는 부분은 없습니다.
- 이건 당연한것 아닌가? 라는 생각보다는 다를 수 있다라는 점을 생각해야 합니다.
- 변경점에 있어서 나에겐 단순하다고 생각 할 수 있지만 단순 하지 않을 수도 있습니다.
- 같이 일하고 싶은 개발자 이야기
- 프론트엔드 개발자가가 같이 일하고 싶은 백엔드 개발자 되기
- 서로 사용되는 용어가 달라 오해하기 쉬우니 공통된 용어로 통일하는 것이 좋습니다.
- 도메인 기반으로 소통하는 것이 좋습니다.
- 서로 다른 용어를 중간언어로 만들어서 관리하는 것도 좋습니다.
- 프로젝트가 끝나는 시점에 프로젝트도 남겠지만 사람도 남으니 잘 지내시면 좋겠습니다.
- 표현을 하더라도 상처가 되지 않게 신경써주세요.
- 단! 솔직하게 주장해야 하는 말을 하지 말라는 것이 아닙니다.
- 변화가 잦을 수 있다는 것을 기억 해주었으면 좋겠다.
- 규칙에 벗어난 일이라면 무조건 적으로 규칙을 따르기 보다 예외를 만들고 해당 예외를 규칙으로 관리 하면 더 유연하게 협업 할 수 있을 것이라 기대 합니다.
함께 읽으면 좋은 링크
