작년 10월부터 현재까지 코딩테스트 대비를 위한 스터디에 참여하고 있다. 중간에 한달 반 ? 정도 공백이 있었으니 실제 진행기간은 6개월이 조금 넘었을 것 같다.
제일 처음 시작할 때 인원이 10명 정도? 그랬는데 현재는 나를 포함해 총인원 3명이 진행 중이다. 공백 이후에 스터디 진행 방식을 새롭게 바꿨는데 매우 효과적이고 효율적이라고 느껴져서 그 과정을 간단히 소개하고자 한다.
초기 스터디 진행 방식
초기에 슬랙으로 진행이 되었다. 이 때는 스터디원들 모두 Git 은 물론 코드 공유를 어떻게 하는 것이 편할지에 대한 고민보다는 문제 하나하나 풀기에 급급했다.
스터디 대장님이 정해오는 프로그래머스 lv.1 문제 를 모두 같이 1시간 정도 풀고, 나머지 1시간은 각자 풀이 코드를 채팅방에 올려두고 코드를 보면서 리뷰를 진행했다.
상대적으로 많은 인원이 참석하다 보니 3팀으로 쪼개서 각 팀에서 먼저 리뷰를 하고, 그 후에 팀마다 한명씩 대표로 전체 인원에게 본인의 코드를 설명하는 형식으로 진행했다.
한 문제만 진행했음에도 인원이 많다보니 각자 코드 리뷰에도 시간이 생각보다 많았고, 리뷰 시간이 정해져 있어서 어떤 날은 너무 빨리 끝나기도 하고, 또 어떤 날은 시간이 부족하기도 한 경우가 발생했다.
초기 한달 정도 진행 후에 개인 사정으로 빠지시는 분들이 몇 분 계셨고, 3개월 이후에 제XXXX 부트캠프 중도하차로 스터디가 잠정 중단되었다. (나도 이 때 공백이 생겼다.)
2차 스터디 진행 방식
이후에 혼자서 공부를 하다가 스터디 대장님과 다른 한 분이 스터디를 계속 진행하고 계셨다는 소식을 듣고 다시 재참여하기 시작했다. 플랫폼도 프로그래머스에서 백준으로 변경되었고, 바킹독 님의 깃헙 리포에 추천 문제들을 차례대로 풀어나가기 시작했다. 이 때부터는 디스코드로 화면 공유 및 소스 코드 공유를 하면서 매일 3시간동안 5문제를 풀고 한시간 정도 각자 코드를 설명하는 형식으로 진행했다.
초기 스터디 때보다 소수의 인원이 진행을 해서 발표 시간을 많이 쓰진 않았지만, 가끔씩 문제 난이도가 너무 높은 경우가 있어서 3명 모두 한 문제만 풀이 성공하는 경우도 있었고, 마찬가지로 리뷰 시간이 정해져 있어서 각자 코드를 파악하는데 대부분의 시간이 소요되는 경우도 있었다.
이 때부터 어떻게 하면 리뷰를 효과적으로 할 수 있을까? 라는 공통 고민이 생기기 시작했고, 2개월 정도 지난 후에 약 2주 정도의 공백을 가지고 현재와 같은 형태로 변경되었다.
3차 스터디 진행 방식 (현재)
올해 (2023년) 2월쯤에 강의를 들으면서 GitHub의 Project, Pull Request 를 개인 리포지토리 관리에 활용하고 있었다. 이후에 코테스터디 진행 방식에 관한 고민이 생겼을 때, 이것을 적용해보면 좋겠다는 생각이 들어서 GitHub 에서 다른 스터디들이 적용하고 있는 방식이 있을까 검색해봤다. 아쉽게도 이거다! 싶은 레퍼런스가 없어서 조금 더 고민을 하다가 현재 방식으로 진행해보자고 건의를 했고, 한달이 지난 지금 모두가 만족하며 진행 중이다.
자세한 내용은 README 에 설명이 되어 있는데, 요약하자면 각자 풀이가 끝난 코드를 커밋해서 PR을 날리면 나머지 인원들이 해당 PR을 리뷰하고 승인하는 형식이다. 다른 스터디들을 찾아보니 이와 유사하게 진행하는 곳이 몇군데 있었는데, Commit 메세지 혹은 PR 템플릿이 별도로 없어 단순히 소스를 저장하기 위한 용도로만 사용하고 있었다. 이 부분이 아쉽다는 생각이 들어 몇가지를 추가했다.
Pull Request Template 의 활용
현재는 하루 2문제씩 진행하고 시간 제한은 별도로 없다. 하지만 고민을 오래하더라도 최대 2시간은 넘기지 않으려고 노력하고 있는데, 아무래도 문제 풀이를 각자 진행하다보니 이 부분을 확인하면 좋겠다는 생각을 했다. 그래서 풀이여부와 소요시간을 함께 기입하도록 하였다.
너무 어려워서 풀지 못했던 문제를 리뷰 이후에도 풀지 않고 넘어가는 경우가 많았다. 그 부분을 해결하고자 답안이라도 참고해서 꼭 당일에 풀고 넘어갈 수 있도록 했다. 해당 부분 역시 별도로 기입하도록 했으며, 추후에 PR을 통해 어떤 부분, 어떤 문제를 고민했었는지 파악할 수 있도록 하였다.
Pull Request Labeling
PR을 날릴 때 별도로 Labeling 을 진행하고 혹여 실수로 PR을 날린 경우도 표시한다. 로그가 깔끔하게 남겨져 있으니 뿌듯함은 2배가 되고, 혹여 PR을 다시 날리더라도 기존에 남겨져 있던 리뷰가 있을수도 있기 때문에 해당 PR 번호를 링크로 남겨둬서 참조하기 쉽도록 하였다.
Branch Protection Rule 활용
Settings탭의 Branches를 살펴보면 Protection Rule을 적용하는 부분이 있다. Require approvals 에 체크하면 PR을 머지하기 이전에 반드시 승인을 받도록 설정하는 부분이 있다. 이 부분을 활용해서 반드시 Peer Review 가 끝나고 승인을 받도록 했다.
현재 리뷰는 PR을 통해 다른 스터디원의 코드를 직접 확인하고 Review Comment를 직접 남기는 방식으로 진행하고 있다. 리뷰 시간을 별도로 정해두고 진행하는 것보다 시간 절약도 되고, 리뷰가 본연의 목적에 맞게 효과적으로 진행되고 있어 모두 만족하고 있다. 코드를 보다 이해가 가지 않는 부분은 별도로 코멘트를 남기거나 디스코드를 통해 직접 설명을 해주는 형식으로 진행한다.
Pull Request Merge 시 Commit Message
PR을 승인할 때 Merge 옵션을 살펴보면 Squash and Merge 가 있다. 그냥 Merge를 진행할 경우 해당 PR에 포함되는 모든 커밋 로그가 Merge 할 Branch에도 그대로 포함되게 되는데 현재 문제 풀이를 각자 개별 브랜치에서 진행하고 커밋 메세지에는 별도로 규칙을 정하고 있지 않다. 성격상 로그가 지저분해지는 것을 참을 수 없어 다른 스터디원들에게 양해를 구하고 해당 옵션을 강력 추천했다. (감사합니다 여러분 🙇♂️)
그리고 #번호 를 붙이면 어떤 PR을 통해 머지가 이루어졌는지 한눈에 파악할 수 있어서 이전에 리뷰 내용을 찾아보기도 쉽다. (이 부분은 진행한 문제번호와 문제 제목을 기입해도 됐을 것 같지만 이렇게 작성하는게 더 깔끔해보여서 ...)
마무리
좋은 인연들을 만난 덕분에 현재도 스터디를 꾸준히 진행하고 있다. 짧다면 짧고 길다면 긴 6개월이라는 기간이다. 다른 스터디원 분들은 기존에 참여하고 계시던 부트캠프를 졸업하고 열심히 취업 준비를 하고 계시고, 나는 새로운 부캠에 참여 중이다.
스터디를 꾸준히 진행했음에도 여전히 알고리즘은 어렵지만, 그간 배웠던 내용들을 하나씩 하나씩 적용하다보니 나름 성취감이란게 느껴지기도 한다.
모쪼록 지금도 어딘가에서 공부하고 계실 수많은 개발자 지망생 여러분들도 화이팅 하시길 바라며, 알고리즘 스터디를 진행하고 계시거나, 진행하실 계획이라면 이 방법을 꼭 적용해보시길 추천한다. 처음에는 조금 번거롭고 귀찮을 수 있지만, 알고리즘 스터디를 하면서 Git, GitHub에 익숙해지고 좀 더 알차게 이용할 수 있다는 큰 장점도 있고, 익숙해지면 효과적이고 효율적으로 스터디를 진행할 수 있다.
PS. 궁금한 점들, 혹은 더 좋은 개선 아이디어들이 있으시다면 댓글로 남겨주시길 바랍니다 ~
