3주 동안의 깃헙 이슈트래커 클론 코딩을 마치며

프로젝트

지난 3주에 걸쳐 깃헙의 이슈 탭을 클론 코딩하는 프로젝트를 진행하였습니다. 4명이 함께 작업을 했는데, 이 과정에서 제 자신의 협업 스타일, 학습 태도 등에 대해 다시금 돌아보는 기회가 되어 좋았던 거 같습니다. 리액트도 처음 사용해보았지만 단순히 기술적인 습득만이 아니라, '함께' 프로젝트를 하며 느낀 점을 정리해보고 가면 좋을 거 같아 이렇게 기록으로 남겨보려고 합니다.

컨벤션과 기록

한 가지 큰 아쉬움이 남는 건 후반에 바빠질수록 기록에 소홀해진 부분입니다. 크게는 API 명세서부터 작게는 하루하루의 개발일지까지, 실질적인 구현 일정에 맞춰 진행하다 보니 작성하지 못하고 넘어간 것이 많습니다. 사실 오프라인으로 모여서 바로바로 즉석에서 논의를 하면서 진행하면 기록에 할애하는 시간이 조금 아깝다고 당장은 많이 느끼는 것 같습니다. 그 자리에서 서로 합의가 되고, 사실상 대화하고 논의하는 시간보다 작성하는 시간이 더 걸리게 될 때도 있기 때문이지 않나 싶습니다. 이번이 단기간 프로젝트고 규모가 크지 않기 때문에 기록이 없더라고 문제가 크지 않았지만, 협업의 크기가 커지고 기간이 길어지면 기억과 즉석 회의에 의존하는 것에는 분명히 한계가 생깁니다. 설계에 변화가 생기면 바로바로 수정하고, 회의는 반드시 기록을 남기고, 작업 분배와 작업 현황은 시간이 걸리더라도 다음 프로젝트에선 조금 더 정성을 들여보고 싶습니다. 이번 프로젝트 특성상 서버와 클라이언트 개발을 딱 나눠서 하지 않고, 하나의 기능에 대해서 담당자가 직접 구현하다 보니 API 명세서 같은 부분은 우선도가 많이 떨어진 감이 있는데, 이 또한 사실 분배하여 작업을 하는 경우라면 반드시 작성하고 넘어가야 하는 내용이라고 생각합니다.

컨벤션 & 룰

모든 명명을 카멜 케이스로 하고 DB의 테이블명을 소문자 복수형으로 작성하는 것과 같은 명명 규칙도 중요했지만, 이보다 이번에 크게 의식하며 진행한 건 커밋, PR, 깃 컨벤션이었습니다. 작성해야 하는 내용과 언어 등을 강제하다보니 커밋에 인식해져서 커밋의 단위가 조금 커진 문제가 있다고 생각은 합니다만, 나중에 되돌아가서 커밋 내용을 살펴볼 때 맥락을 쉽게 파악할 수 있을 거 같습니다. 적용해본 커밋 컨벤션과 예시는 아래와 같습니다.

🔧 커밋 컨벤션

커밋 구분

• 커밋은 최소 기능 단위로 분리한다.
• 백, 프론트가 동시에 작업된 경우, 백과 프론트 파일을 분리하여 커밋한다.

커밋 태그

• CHORE : 설정, config파일
• FEAT : 기능관련된 모든, css
• FIX : 기능관련 버그 수정
• STYLE : 코드 스타일, 형식 관련
• DELETE : 삭제
• DOCS : 문서 작업
• REFACTOR : 리팩토링
• CONFLICT : 컨플릭트 해결

언어

• 영어로 작성
• 동사 원형으로 시작 (added → add)

커밋 바디

• why: 해당 커밋 내용이 작성된 이유 및 배경
• what: 작성한 내용
• etc: 기타 추가할 내용. (예. 향후 작업 내용, 추가 설명)

커밋 메시지 예시

[FEAT] create a button for submitting login information 

[why] Cuz... 

[what] A button for a login form. 

[etc] The style hasn't been attached yet.

커밋의 경우 템플릿을 프로젝트 단위로 미리 적용시켜두면 직접 하나하나 작성할 필요가 없기 때문에, 그 부분을 활용하면 훨씬 더 효율적으로 컨벤션을 지키며 커밋을 할 수 있는 것 같습니다. 이는 PR 또한 마찬가지로, 깃헙에서 템플릿 파일을 올리면 알아서 PR을 작성할 때 해당 템플릿을 띄워줍니다.

↕ PR 컨벤션

PR의 경우 깃헙에서 PR을 작성할 때의 컨벤션과 간략한 gitflow를 활용한 내용이 혼합되어 있습니다. 브랜치의 경우, master를 배포할 브랜치로 지정하고 배포 준비가 되기 전까지는 일종의 버퍼처럼 작동하는 develop브랜치를 두었습니다. 모든 기능은 feature/<기능명> 같은 식으로 명명된 브랜치에서 작업을 진행하고 develop으로 PR을 보내는 방식으로 작업이 진행되었습니다. 원래라면 Hotfix 같은 브랜치도 있었겠지만, 이번에 배포에 크게 치중을 하지 않았다 보니 (반성할 부분이기도 합니다^^;;) 배포 관련 브랜치보다는 기능 작업을 위한 브랜치 구성에 좀 더 집중을 한 거 같습니다. 적용해본 룰과 템플릿을 이렇습니다.

 

• 모든 PR은 최소 2명 이상에게 리뷰를 받아야만 merge가 가능합니다.
• 브랜치 전략은 간략화된 gitflow를 채택
  • master: 배포가 가능한 상태의 최종본
  • develop: 기능이 완료되면 머지되는 버퍼존
  • feature: 각각의 기능을 명시한다. 브랜치명은 'feature/<기능명>'
  • fix: 기능 수정 시 사용한다. 브랜치명은 'fix/<기능명>'
• 언어
  • 한국어
• PR시 기존 브랜치 삭제

merge, rebase 관련

feature 브랜치에서 작업하던 중 develop이 업데이트되는 경우:

1. 로컬 develop에서 원격 develop을 pull 해온다.
2. 작업 중인 feature가 있는 경우, 해당 브랜치로 checkout 해서 로컬 develop을 rebase 한다.

merge, rebase는 하면서도 혼선이 굉장히 많았는데, 아직도 깃은 공부할 게 많은 거 같습니다. 위처럼 결정하게 된 계기는 컨플릭 해결과도 많은 연관이 있습니다. 여러 명이 각자 작업을 하다 보면 develop으로 PR을 하는 시점에서 굉장히 뒤죽박죽인 경우가 많습니다. 이때 컨플릭을 해결하면서 브랜치가 많아지고 머지가 복잡하게 돌아가는데, 브랜치와 커밋 기록을 조금은 간편화하고 컨플릭 해결도 편하게 하고 싶어서 rebase를 하는 방식으로 진행했습니다. rebase를 하면 컨플릭 나는 시점까지 거슬러 올라가서 거기서 커밋을 다시 고치고 올라오다 보니 모든 기록이 남는다기보다는 기능이 새로이 붙는 영역만 기록을 남게 됩니다. 물론 엄격하게 따지면 실제 작업한 것과 약간 다른 내용이 될 수도 있어서 세세하고 정확한 작업 기록이 필요하다면 rebase보단 merge를 하는 방식이 맞을 수도 있겠습니다만, 개인적으로는 기능 구현의 큰 흐름이 읽기 쉬워서 rebase를 하는 전략도 좋았다고 생각합니다. 아직도 둘의 차이가 완전히 이해된 건 아니어서 공부가 더 필요하지만 대략 아래의 그림과 같은 차이가 생긴다는 걸 알게 되었습니다.

 

배포

이번에 또 다른 큰 아쉬움은 CICD의 미활용입니다. Nginx를 이용해 프론트도 직접 배포를 해보아 좋았으나, 그와 함께 원래는 자동 배포도 도전해볼 계획이었는데 이 역시 구현에 급급하다 보니 정말 새로운 것을 시도할 엄두가 안 났던 거 같습니다. 그래도 다행히 피어 세션을 하면서 젠킨스를 이용하신 팀을 만나 구경을 할 기회가 있었는데, 겁내지 말고 다음엔 프로젝트 초반부터 바로 도입을 해야겠다고 결심이 굳었습니다. 누군가 하는 걸 한 번만 보면 의외로 금방 할 수 있겠다 싶은 경우가 많은데, 개인적으로 자동 배포를 단 한 번도 해본 적이 없어서 괜히 겁내고 망설였던 거 같습니다. 아직도 리눅스, 서버 인스턴스 관리 같은 영역이 좀 무서운데(?) 자동 배포만큼은 꼭 도전해보려고 합니다.

나중은 없다

마지막 주에 팀원들과도 고개를 끄덕거리며 얘기한 것이 '나중에'의 함정이었습니다. 물론 구현을 위해 당장 시급하지 않은 부분을 미뤘기 때문에 더 많은 기능을 붙인 것도 사실입니다. 하지만 여기서 얻은 교훈은 '나중에'라고 미뤄둔 것치고 정말 되돌아와서 고치거나 구현한 것이 없다는 것입니다. 문제가 보인다면 그 자리에서 바로 고치는 것이 사실 베스트인 건 맞습니다. 정말로 우선순위가 아니어서 미루는 것과, 우선순위일 텐데 당장 공부할 엄두가 안 나서 미루는 것은 차이가 있습니다. 후자의 경우 늘 경계하며 프로젝트를 작업할 필요가 있는 것 같습니다. 언젠가 해야 할 거 같다면 그냥 그 자리에서 시간이 좀 들더라도 알아내서 짚고 넘어가야겠습니다.

마치며

전반적으로 힘도 많이 들었지만 정말 재미있게 작업한 3주였습니다. 개발 공부를 시작하고서 딱 나눠서 분담하지 않고 백, 프론트 구분 없이 여러 명이 협업한 것은 처음이라, 낯선 부분도 많고 팀원들에게 민폐가 된 부분도 많았지만 그만큼 성장의 기회도 되었습니다. 겨우 3주 정도 해본 거라 아직도 적당히 합의를 하고 완만하게 넘어가야 하는 부분과 반드시 하고 넘어가야 하는 부분의 경계가 명확히 와 닿지는 않습니다. 제 경우는 어쨌든 데드라인은 존재하고, 룰을 엄격하게 지키다 미완성이 되느니 무조건 만들고 봐야 한다는 주의가 강한데, 매번 이런 식으로 주먹구구로 하면 부메랑으로 돌아오는 경우도 부지기수입니다. 절충안을 잘 찾으면서 부스트캠프의 마지막 프로젝트도 감정 상하지 않고 함께 잘 마무리했으면 하는 바람입니다.