SOPT makers 1기 Playground 팀 FE 개발자들의 KPT 회고

남주영·2023년 1월 25일

현재 대학생 연합 IT 창업 동아리 SOPT 회원들 간의 연결을 위한 서비스인 SOPT Playground를 운영하고 있습니다.
이는 SOPT makers라는 기수제로 운영되는 조직에서 만들고 있는데요.

SOPT makers란?
https://playground.sopt.org/makers
(!곧 2기 리크루팅 예정!)

저는 현재 SOPT Playground를 만드는 팀의 FE 리드로 활동하고 있습니다.
그리고 지난 2023년 1월 20일, SOPT makers 1기 활동을 마무리 하면서 제가 FE 개발자로 속해 있는 Playground 팀의 FE 회고를 진행했습니다.
이후 회고를 되새기고 액션 아이템을 정리하기 위해 작성한 회고 요약본을 기반으로 이 경험을 공유해보려 합니다.

🔍 회고를 하게 된 배경

1기는 SOPT에 서비스를 공식적으로 도입하기 위한 발판을 만들기 위해 굉장히 바빴습니다.
SOPT Playground의 기반이 되는 회원가입, 프로필, 프로젝트 기능을 만들며 중간 중간 작은 실행 및 검증을 하고 유저 유입을 이끌어 내기 위해 다음과 같은 이벤트들에 대응했습니다.

SOPT 기획 파트 세미나에 참여한 멘토가 프로필 쪽지 기능을 통해 질문을 받도록 하여 프로필 기능을 기반으로 한 커뮤니케이션 니즈 검증
SOPT 공식 행사인 솝커톤, 앱잼으로 만들어진 프로젝트를 우리 서비스에 등록할 수 있도록, 행사 일정에 맞추어 프로젝트 기능 개선

이렇게 달려온 결과 SOPT의 다음 기수(32기)부터는 SOPT Playground가 공식 서비스로 이용될 예정입니다.
이러한 과정에서 속도를 위해 FE 간의 커뮤니케이션 비용은 최소화 하기 위해 노력했으며(코드 리뷰는 열심히 하였음.) 기술 부채가 많이 쌓였습니다.

하지만 이제 서비스를 더욱 안정화하고 확장해야 하는 단계가 왔기에 재정비가 필요하다 생각했고 이에 FE 팀 회고가 크게 도움이 될 것이라 생각했습니다.

🫂 팀 소개

처음으로 팀에 대한 퍼블릭한 글을 쓰게 되어, 간단하게나마 우리 팀원들을 소개하려고 합니다.
~~제 맘대로 멋진 소개 멘트를 붙여봤으나 혹시 부담스러울까봐 지웠습니다.~~
간단히 깃허브 프로필 링크를 첨부하겠습니다.

또한 SOPT Playground의 레포지토리 링크를 공유합니다.

https://github.com/sopt-makers/sopt-playground-frontend

📜 회고 방식

회고 방법론
좋았던 점, 나빴던 점에 대해 두루 살펴보고 Action item을 도출해내기 좋은 KPT 회고를 선택했습니다.
회고를 위한 툴
피그잼에 간단히 KEEP / PROBLEM / TRY 섹션을 나누어 자유롭게 포스트잇을 붙일 수 있도록 했습니다.
평소에 생각하던 것은 미리 작성해올 수 있도록 사전에 이를 공유했습니다.
진행 방식
회고 시작 후 자유롭게 작성하는 시간을 가진 후,
Keep 중에 중요하다고 생각하는 것 5가지를 스티커를 통해 투표하고 투표 수가 많은 것을 중심으로 다같이 얘기를 나눠보았습니다.
Problem도 같은 과정을 반복했는데, 투표 수가 많이 나온 것에 대해 이야기 할 때에 Try와 엮어 이야기해 보았습니다.
Try는 하나하나 보며 지금 바로 실천할 수 있는 Action item이 있을지 같이 고민했습니다.

🚀 회고 요약본

여기부터 아래 내용은 사전에 작성했던 회고 요약본을 그대로 옮겨온 것입니다!
참고로 친밀함을 베이스로 활동하는 동아리이기 때문에 회고가 진지하고 엄숙한 분위기에서 이루어지지 않았고 따라서 회고 요약본도 다소 날것의(?) 느낌으로 작성이 되었습니다.
친밀한 팀 분위기가 자랑하고 싶은 것 중 하나이기도 해서, 정제하지 않은 채 그대로 올려봅니다. :)

지난 1월 20일에 진행한 플레이그라운드 FE의 1기 KPT 회고를 통해 나온 Action item을 정리해보겠다.

다음 회고 때까지 꼭 잘 실천하는 귀염방댕이 플그 FE가 되길!

1. 2기 Sprint0 때 페어 프로그래밍을 해보자

리뷰 짝이 아닌 팀원과 페어 프로그래밍을 하면 4명의 코드를 거의 완벽히 파악할 수 있지 않을까? 라는 의견이 나옴.
하지만 비슷한 경험을 해본 팀원이 매우 강도가 높은 방식이라고 함.

결론: 2기 Sprint0 때 어떻게든 일단 한 번 페어 프로그래밍을 해보기로 함.

K/P/T

Problem: 미묘하게 통일성 없는 코드 스타일 / 내가 맡지 않은 코드를 100% 파악하고 있진 못함
Try: 페어 프로그래밍

2. 2기 모집 TF 끝나고 대대적인 리팩토링 작업을 시작하자

K/P/T

Problem: 기술 부채로 인해 파산해버린 몇몇 코드들
Try: Sprint0 때 기술 부채 청산하자

3. QA 개선 관련

머지하기 전 FE에서

개발한 본인이 충분히 테스트를 거치고 PR 올리기 (리뷰어의 시간은 소중하다)
리뷰어도 브랜치 받아서 열심히 확인하기 (리뷰어에게도 어느 정도 책임이 있다)
2를 효율적으로 하기 위해 프리뷰 배포 개선하기

배포 후 팀에서

팀 단위로 QA를 하는 시간을 가지자 ex) 회의 때

K/P/T

Problem: 작은 수정 사항이어도 사이드 이펙트가 있을 만한 코드는 테스트가 충분히 필요한데 그러지 못한 채로 배포된 적이 꽤 있음 / 선머지 → 후테스트 → 대참사 → 롤백
Try: 리뷰할 때 브랜치 받아서 열심히 돌려 보기 & 올린 사람이 열심히 이것저것 테스트 해보기

4. 2주에 한 번 or 매주 / 30분~1시간, 코드에 대한 정기 회의 시간을 갖자

챕터 단위로 해도 좋을 듯 함

K/P/T

Keep: 기술 고민을 함께 하는 것
전반적인 Problem 해당
Try: 코드에 대한 정기 회의

😇 우리 잘하는 것도 많다 (Keep)

위 Action Item은 주로 Problem이 근간이 되었기 때문에 Keep은 따로 기재를 해보겠다.

피그잼에서 스티커(공감) 2개 이상 받은 것들만 모아봤다.

리뷰를 꼼꼼히 해주는 팀원들 (고퀄리티 리뷰 감사합니다)
다들 코인 노래방을 좋아한다 (앞으로도 기본 1인3곡 체제 잘 유지하자) (+1인3곡 채우기 전엔 못 나간다고 함)
기술 고민을 함께 하는 것
친밀한 관계
새로운 제안에 긍정적인 것
슬랙 메시지에 대한 응답 속도가 빠르고 일할 맛 나는 리액션을 잘 해준다.

✅ 그 외 인지하고 있으면 좋을 K/P/T

위에서 언급한 것들에 비해 당장은 비교적 중요도가 낮을 수 있지만 다들 인지하고 있으면 좋을 것들이다.

가지고 온 기준은 스티커(공감) 1개 이상 받은 것, 여러 번 언급이 됐던 것

Keep

It’s not my job을 외치지 않는 팀원들
자주 만나는 팀원들
리뷰 짝 제도 (너무 잘 적용된 것 중에 하나라 당연해져서 아무도 안 적어준 것 같아서 작성자가 임의로 추가함.)

Problem

프로덕션 배포가 수동인데 제때에 배포를 하지 않아 문제가 생겼을 경우 트래킹이 어려웠음. 게다가 머지 커밋을 남기는 탓에 어떤 쪽이 문제였는지 찾기도 조금 어려웠음.
바쁠 땐 리뷰를 제때 하지 못했음.
icon 관련 여러 문제
- 용량이 너무 커서 확인해보니 파일 안에 base64로 박혀있었다.
- 네이밍 규칙이 딱히 없다.
- 에셋이 피그마에 정리된게 아니라서 같은 모양의 아이콘이 여러 개 존재할 수 있다.
- 폴더 구조가 이상하다.