SSAFY 공통 프로젝트 회고
총 7주 간의 개발 기간 동안 다사다난했던 공통 프로젝트가 끝났다.
프로젝트 기간 동안 팀원 절반의 생일을 축하했고, 팀원 절반은 지각 스택을 모으고 모아 결석을 찍었다.
잘 했던 일과 못 했던 일, 그리고 협업 기간 동안 있었던 일과 이슈에 대해 정리해 보려고 한다.
공통 프로젝트에서 팀장과 백엔드 리더를 겸임했다.
프로젝트를 시작하기 전 내가 그나마 할 줄 아는 일들은 다음과 같았다.
토들러 백엔드 엔지니어
Spring framework와 JPA를 이용한 기본적인 작업 가능
자잘한 툴이나 라이브러리들... CICD 돌려 본 적 있음
React와 Vuejs로 간단한 뷰 제작 가능
실무 경험 아주 쪼끔 있음
팀 빌딩
자기소개를 하고, 반 내에서 자율적으로 팀구성을 진행했다.
운 좋게도 1학기 관통 파트너분과 같은 반에 배정돼서 희희낙락하다가 팀구성을 못해서 발등에 불 떨어진 상태였는데 다행히도 팀 제의를 받을 수 있었다.
한 장의 장표로 그 사람의 모든 것을 알 수는 없음에도 불구하고 거의 헤드헌터급 스카우팅이었음
싸피 1학기를 잘 마치고 온 교육생이라면 다들 이렇다 할 자랑거리 하나쯤 들고 오기 마련이지만 내 눈에는 우리 팀이 유독 드림팀으로 보였다.
실제로도 발표 진행하는 동안 팀원들 자랑만 삼 분동안 한 적도 있음( ͡° ͜ʖ ͡°)
분담
우리 팀은 프론트 셋과 백엔드 셋으로 이루어져 있었다.
직무 밸런스는 좋지만 6명이서 기획, 개발, 배포, qa까지 진행해야 하는 특성 상 감투 하나씩 더 씌워드림.
그런데 진행하다보니 몇가지 업무를 제외하고는 담당자가 모호해졌다.
각자 손이 빠른 분야가 있는 법인데 그걸 팀 빌딩 시점부터 미리 알 수는 없으니 어쩔 수 없다.
감투 쓰고 가신 만큼 프로젝트의 몰입감이 올라갔다고... 올라가셨지요...?
PM/PL(BE) 팀장과 백엔드 리더. 네이버 사다리타기가 점지한 팀장.
JIRA 이슈관리도구 Jira Sprint를 start/close하고 번다운차트를 예쁘게 관리한다. (일을 했으면 번다운 떨구라고 계속 리마인드 시켜주심) 동시에 nginx와 coturn, signalling 서버 전반을 제어해주셨다.
PD Project Designer로 디자인 총괄...이었으나 리액트 훅을 비롯해 컴포넌트를 기깔나게 다루시더니... 후반부 UCC 작업을 진행해 주시면서는 정말 편집 PD를 겸직하심
Docs 노션 관리를 도맡아 해주셨으나... 후반부에는 자타공인 프론트의 디자인총괄로 본업을 전환하심.
B&R Build&Release로 개인 S3를 생성해서 관리해주셨다. 후반부에는 음성과 영상 컨트롤, 녹화 관련 업무를 맡아주셨고 단순 배포나 부분 재배포 작업은 손 남는 사람이 빌드스크립트나 휴먼배포로 해결했다.
PL(FE) 초반에 프론트 리더 정하고 가는 게 좋겠다고 제의했었는데, 올해 들어 다섯번째로 잘한 일이었던 것 같다. 첫번째가 뭔지는 팀원들도 아실 거임.
업무 분담 말고도 성격적으로 케미가 굉장히 좋았다.
프로젝트의 성공은 팀 분위기에 있다고 하는데 정말 이렇게 마음에 드는 프로젝트 팀은 처음이었을 정도로 분위기가 독특했다. 너무 좋았음.
밑작업
프로젝트 시작 당시 백엔드 팀원들은 관련 기술스택 전반에 아직 익숙하지 않은 상태였다.
내가 가져가고 싶은 걸 밀어붙이려면 그만한 근거와 준비가 되어 있어야 했으니 미리 준비해가야겠다 생각을... 했는데...
사다리가... 사다리가 날 팀장으로 뽑아버린 거예요.
내가 가진 지론은 단순했다.
리더는 초반에 굴러야 한다.
만일 리더도 모든 게 처음이라면 당연히 다같이 구르면 된다.
그런데 내가 리더를 맡게 된 상황에서 게으르게 있다가 다같이 갈피 못 잡고 시간 낭비하기에는 대학교 내내 팀장직 맡으면서 쌓은 짬바랑 자존심이 있었다.
= 나는 두 배로 굴러야 한다.
첫주차에는 제공 받은 스켈레톤 코드를 바탕으로 분석하고 기능을 추가구현하는 개인과제를 내줬는데, 솔직히 나는 유경험자라 꿀을 좀 빨았다.
그렇다면 남는 시간에는 일을 해야죠...
팀원들이 각자 스켈레톤 코드를 분석하고 공부하는 동안 나는 리팩토링 작업에 몰두했다.
기존 플젝을 그대로 들고 올 수도 있었겠지만 팀원들이 이미 분석한 프로젝트를 바탕으로 리팩토링하는 게 이해에 도움이 되리라는 판단이었다.
DI는 모두 생성자 주입 방식으로 변경했고, 엔티티에서는 @Setter를 모두 제거했다. exception은 어떻게 커스텀할 것인지, Advice는 어떻게 잡고 로그는 어떻게 찍을 건지, jwt와 sns login은 spring security에게 맡길 것인지, properties에는 뭘 설정해 놓을 건지, build는 어떻게 돌릴 건지 등등
회원 관련 API는 변동이 있어봤자 거기서 거기이므로 controller와 service, kakao 로그인을 포함한 api 일체를 미리 구현해뒀다. 해당 과정에서 User entity 내부에 비즈니스 로직을 작성해서 팀원들이 DDD에 익숙해질 수 있었으면 했다.
그러니까 Controller와 Service만 작성하면 되는 상태로, 새로운 스켈레톤+가이드 코드를 짠 거다.
하지만 저건 백엔드 리더+익숙한 코딩스타일을 팀원들에게 설득하고 싶은 내 욕심이었지 팀장의 일은 아니었다.
우리는 협업도구로 노션을 선택했는데, 나는 노션이 익숙하질 않았다. 노션으로 발표대본이나 좀 짜봤죠... 뭐예요 저거 표 어케 만드는데
그래서 깃허브를 돌면서 노션으로 작성된 문서를 싹 긁어온 다음 차용할 건 차용하고 버릴 건 버리면서 템플릿을 짰다.
기존에 썼던 브랜치 전략과 컨벤션 등도 넣어뒀다.
백엔드든 전략이든 바꾸게 되더라도 노베이스에서 시작하는 것보다는 수정하는 편이 낫다고 생각했다.
그렇게 본격적인 첫 팀 미팅 전까지 백엔드 틀과 노션 템플릿을 잡아 놓자 이쯤이면 어디가서 내가 팀장이랑 백엔드리더였다고 말할 수는 있겠다는 희망이 생겼다.
협업
Notion과 Gitlab, Jira를 사용했다.
Notion
초반에 잡아간 노션 템플릿에서 크게 변화된 건 없다.
노션 메인페이지 아래쪽에는 일정이나 카드 등이 있었다.
Jira로 일정 관리를 했기 때문에 달력은 거의 쓰지 않았고, 카드는 아이디어 회의할 때 유용하게 사용했다.
또 후반부로 가면서 노션 페이지 여러번 클릭하기가 너무 귀찮아져서 보면 하위페이지로 들어가야 할 친구들이 메인으로 나와 있는 걸 볼 수 있다.
Gitlab
깃허브랑 별 차이점은 없다고 생각했는데 파고 들어가면 좀 차이가 크다.
예전 버전 깃허브 같다는 생각이 많이 들었다.
가장 대표적인 걸로는 메인 브랜치가 master임.
그리고 jenkins랑 연동할 때 쓰이는 gitlab hook이 java8이라거나 conflict를 웹에서 바로 처리하기는 어렵다거나 하는 점들이 좀 달랐다.
브랜치 전략은 노션 템플릿을 작성할 당시 임의로 정한 후에 팀원들의 의견을 받아 수정해서 가져갔다.
중간에 깃랩 리포가 변경되면 브랜치 전략을 수정해서 가져가자는 의견이 있었는데 이런저런 일로 인해 그냥 초반 전략을 마지막까지 가져가게 되었다.
깃랩 이슈는 이미 처리한 이슈에 추후 리팩토링해야 할 사항이 있다거나 보완점이 있을 때 등등 가끔 사용했다.
Jira
첫째는 기획과 프로젝트 구조, 둘째와 셋째는 실질적인 개발과 추가기능 구현이다.
월요일마다 스프린트를 발행해서 금요일에 닫았고, 설이 있던 주에는 2주짜리 스크럼을 짰는데 시간이 갈수록 번다운 차트 예쁘게 그리는 데에 집중하게 되는 우리들을 볼 수 있었다.
우리팀 특: 낮에는 수평이다가 새벽에만 떨굼, 주말에 일하기 때문에 차트에 안 찍힘
시간이 갈수록 이슈 발행하는 게 수월해졌는데, 그게 짬바가 생겨서 그런가 아니면 프로젝트 막바지로 갈수록 해야 할 일이 명확해졌기 때문인지는 잘 모르겠다.
둘 다라고 하자.
WebEx/Discord/KakaoTalk
기본 교육시간~저녁 먹기 전까지는 항상 웹엑스를 이용했다.
세부세션을 미리 엄청 파 놓은 다음에 각자 업무상의 이슈가 생기면 담당자들 끌고 세부세션으로 가는 방식이었다.
(님들 진실의 방 집합 -> 하면 프론트가 다같이 어딘가로 사라졌다 옴)
다들 저녁 먹으러 가느라고 한 번 웹엑스를 닫은 이후에는 디코로 모였다.
그러다 업무상의 이슈가 생기면 바로 카톡으로 담당자를 호출함.
다들 디코 미접속 상태더라도 어차피 다들 작업 중이셨으므로... 카톡으로 호출하면 이십분 내에 와 주시는 기적을 보여주셨다.
화면 공유할 때 웹엑스가 압도적으로 편했으므로 밤에도 웹엑스를 자주 열긴 했다.
디코 음악봇 두 개 넣어놓고 새벽의 취향자랑했던 거 절대 못 잊음
거의 2교대로 일하는 수준이었고, 다들 프로젝트에 진심이셨다.
이유는 기획에서 나옴
기획
기획을 세 번 갈아엎었다.
초반부에 갈아엎은 것도 아니고, 충분한 회의를 거쳐 기능 명세까지 나왔을 시점에서 갈아엎었다.
보통 1주일 반 정도 걸리는 기획을 우리 팀은 거의 3주 꽉 채워서 마무리했는데, 그럴 가치가 있었다고 생각한다.
배경
우리 팀은 웹RTC를 사용하는 웹기술 도메인을 선택했다.
그에 따라 화상 서비스를 이용하는 서비스를 기획해야 했고, 그 과정에서 많은 것들을 얻을 수 있었다.
탈락한 기획들
초기 아이디어해커톤 당시 기획으로, 화상 에타 같은 느낌이었다.
학교 도메인 기반으로 인증을 거친 후 각 분류별로 방을 개설할 수 있는 기획이었지만 드랍했다.
하지만 여기서 나왔던 수많은 세부 아이디어와 즐거움이라는 모토는 최종발표까지 살아서 가게 된다.
레시피에 눌린 좋아요 수와 클래스 오픈 요청 수를 기반으로 수요를 판단한 뒤 원데이클래스를 오픈할 수 있는 서비스를 기획했지만 이 서비스가 강의자 입장에서 정확히 무슨 메리트가 있는지 판단하기 까다로웠고, 거의 일주일 간 매달리다가 결국 드랍했다.
그래서 각자 노션 페이지를 판 후에, 다음 아이디어 회의 때까지 아이디어를 기획해 오기로 했는데...
팀원들이 새벽 세 시에 노션으로 카톡을 하기 시작함
최종_진짜최종_찐최종
🙋♀️네 저희 노래방합니다
🧏♂️ 👥 👥 👥 뭐라고요
🙋♀️저희 노래방해요
시중 노래방 앱은 있었지만 참가 인원이 한정되어 있고, 음성채팅만 제공하거나 별도의 리액션이 없어 떠들고 즐길 수 있는 분위기는 아니었다.
결정적으로 재미를 부르짖던 팀원들의 니즈를 완벽하게 만족시켜 줄 수 있었음
기획이 길어진다고 해서 팀원들이 조급해하지 않았으면 했다.
솔직히 나도 안 조급함
그래서 기획 기간 동안에는 전체 회의 때 우리 진짜 괜찮으니까 이거 이틀 정도 더 생각해 본 다음에 결론 짓자는 말을 좀 많이 했다. (하지만 개발 시작한 이후로는 은근히 쪼아댐..ㅎㅎ)
개발에만 들어가면 DB를 포함한 백엔드 일체는 금방 가져갈 수 있다는 자신이 있었고, WebRTC의 경우에도 짬짬이 하나씩 맡아 돌려본 덕에 담당 팀원들이 이미 지식을 숙지하고 있는 상태였다.
내가 시간을 계산할 수 없었던 건 프론트였지만... 다들 제대로 하드캐리를 해주신 덕에 아무 문제 없었다.
개발
개발 자체는 일사천리였다.
프론트에서는 이삼주 정도 리액트 학습에 몰두하셨는데 그렇게 개발을 시작하시더니... 자고 일어나면 뭐가 커밋되어있고 서비스 때깔이 달라지고 그랬다.
이게 진짜 되나 싶었는데 그걸 해 오시고 상상도 못했던 걸 추가해 오셔서 백엔드 입장에서는 눈 돌아가느라 바빴다.
하씁 미러볼
백엔드 틀을 미리 짜서 가져간 덕에 실질적인 개발기간 동안 백엔드를 만질 일은 거의 없었다.
API 명세를 짜는 데에 이틀이 걸렸고, 테스트 코드를 포함한 비즈니스 로직을 작성하기까지 다시 이틀이 걸렸다.
이후로 프론트 요구 사항이나 버그에 따라 간간히 수정하기는 했지만 실질적으로 API를 짜는 데 걸린 시간은 많지 않았다.
그 시간을 WebRTC와 서버 구축에 온전히 할애했다.
WebRTC 관련해서는 음성 지연에 대한 감을 잡기 위해 WebRTC를 차용한 모든 서비스들에서 노래를 질러봤고, 쿠렌토와 오픈비두에서도 각각 질러봤다.
WebRTC 관련해서는 정보가 많은 것 같으면서도 너무 없었다. 기본적인 개념을 잡고 기술을 선택하는 것만 해도 한세월이었다.
우리는 kurento를 선택했다. 오픈비두와 쿠렌토 모두 제공하는 데모가 많았는데, 각자 하나씩 맡아서 테스팅 해봤을 때 초반 구축만 잘 해준다면 쿠렌토가 커스텀은 더 쉽겠다 싶었다. 우리가 원하는 라이브러리들도 전부 제공하고 있었다.
하지만 튜닝까지 해가며 공을 들였던 쿠렌토를... ucc 최종 촬영 4일 남기고 openvidu로 싹 엎게 된다. 관련 이슈는 따로 기술할 예정.
쿠렌토를 사용하면서는 coturn이랑 nginx랑 시그널링이랑 kms docker... 그냥 인프라를 다 따로 올려서 세팅한 경험 덕에 모든 서버를 docker compose로 한 번에 설치할 수 있는 openvidu는... 우리 팀원들에게 있어 정말 신세계였고 껌이었다.
🤦 도커 올리니까 되긴 하는데 간헐적으로 이딴 워닝이 나면서 빈값이ㅠ 오는데ㅠ 이것 뭐예요?
💁♀️ 아 그거 turn 짓임 도커 초기 세팅값이 다른가봐요 수정끗
🙋♂️ 3478 왜 아직 살아있어요? 킬할게요
그렇게 우리는 점점 진심이 되어 갔고... 컨설턴트님과 코치님을 너무 괴롭혔고... 아이유와 오마이걸 노래를 부르실 수 있는 서비스를 만들어야 한다는 생각에 휩싸여서... 정말 너무 진심이 되어버렸다.
내 생일파티도 여기서 함.
결과
나는 프로젝트 기간 내내 엄복동 망한 비처럼 구구절절했고 팀원들은 서로에게 가차없는 딜을 박으며 밤을 샜다.
우리는 진지하게 이건 된다를 외치고 있었는데...
정말 엄복동이 되어버릴 위기에 처함
전국 발표 때, 회심의 UCC는 끊겨서 송출되고 십분 전까지만 해도 말짱하던 서비스는 시연에서 갑자기 나만 접속이 안 됐다. 서비스가 불안정하다는 걸 감안하더라도 터질 리 없는 종류의 에러였다.
노련한 팀원 분이 잘 대처해 주셨지만 발표 시간을 계산하던 내 멘탈은 이미 터진 뒤라 심정이 참 그랬다.
내게만 일어난 서비스 장애는 웹엑스를 나오자마자 복구되었다. 아니 진짜 왜...?
몇백명이 모인 웹엑스에서 두 시간 접속해 있으면 컴퓨터가 맛이 간다는 달갑지 않은 사실만 얻었다.
단체로 모여서 하루에 리허설만 두 시간씩 했던 전국 발표가 끝나자마자 우리는 각자 조용히 술 한 병씩 깠다.
오류 났을 때 채팅에 괜찮아괜찮아 많이 남겨주시고 응원메세지랑 카톡도 쏟아졌는데 정말 너무 감사드렸지만 답할 멘탈이 없었다.
기깔나는 발표를 자신했다 보니까 이게 정말 최악이었는지 평타였는지도 분간이 안 갔다.
와 이게 멘탈 깨지는 기분이구나 하고 살면서 첨 겪어봤다.
아래는 발표 ppt에 포함된 팀원 자기소개 내 파트다.
그리고
1등 먹음
ㅋㅋㅋㅋ발단~~~ 전개~~~~~~~~ 위기절정결말 이케 와버림...
리허설을 다같이 자주 모여서 하지 않았더라면 내게 문제가 터졌을 때 팀원분이 바로 대신 화면 공유하고 시연 시나리오를 돌려주실 수 없었을 거다.
대본을 외우지 않았더라면 내 멘탈은 정말 털렸을 거고, 아이컨택 연습을 하지 않았더라면 카메라를 볼 용기도 안 났을 거다.
준비해서 득 본 거고 끝이 좋으니까 됐다.
아쉬운 거
1. 내가 너무 많은 범위를 건드렸다.
프로젝트 초반에는 분명 도움이 됐다. 나는 주워 들은 게 많아서 비교적 초반 러닝커브가 낮은 편이고, 초반부 배포와 백엔드, 프론트의 아주 일부에 그냥 손을 댔다. 손이 빠른 편이라 별 문제는 없어 보였다.
그런데 프로젝트 진척이 물살을 타면서 업무가 내게 몰려버렸다. 업무량보다 업무 범위의 문제였다. A팀원과 같이 일을 하다가 B팀원의 세션으로 넘어가 요구사항을 수정하는 일이 빈번해졌고, 내가 빠지는 순간 작업 속도가 현저하게 나아가지 못한다는 것을 깨달았다. 초반부에는 별로 손 갈 것 없어서 대강 내가 처리했던 작업들도 개발이 고도화됨에 따라 여기저기서 쓰이게 되었다.
결국 팀원들의 개인 일정이 내 처리속도에 매여버린 거다. 초반에 문서 작업을 더 해놓거나 분업을 한 채로 시작해야 했었다는 생각이 든다.
2. 너무 덩어리로 움직였다.
기획이나 회의는 팀 전체의 일이 맞다. 하지만 WebRTC의 경우는 담당인 백엔드끼리만 논의해야 할 일이 있었고, 프론트 엔드의 해당 페이지 담당자와 함께 논의해야 할 일이 있었다. 일정상 어쩔 수 없는 일이긴 했으나 내가 리드했던 백엔드도 다양한 업무를 따각따각 수행한다기보다는 덩어리로 자주 움직였던 감이 있다. 전체 미팅을 할 때도 내용 자체가 백엔드의 기술적 측면으로 흘러가는 감이 많아 프론트의 작업시간을 뺏는 기분이 들었다. 업무 분장에 대해 조금 더 고민해 보고 업무에 따른 유닛을 보다 유연하게 구성할 필요가 있었다.
3. 교통정리를 잘 하자.
회의가 루즈해질 때가 있었다. 적당히 정리하고 주도할 필요가 있는데 좀 얼을 탔다. 물론 팀원분들이 잘 이끌어주셨지만 진행을 잘 했더라면 더 빠르게 물살을 탈 수 있었지 않았을까 싶다. 사회자 역할은 꺼리는 편인데 생각해보면 내가 팀장이었다.
마치면서
팀원들 각자가 너무 고생했는데, 그만한 결과가 나온 것 같아서 다행스러우면서도 즐겁고 고마웠다.
빈말 아니라 내가 특출나서 얻은 결과가 아니었다. 팀원들이 8기통 외치면서 폭주하면 나는 그냥 같이 와아악하면서 남은 기름이나 체크하고 네비나 봤다.
그리고 정말 많이 챙겨주셨던 컨설턴트님과 코치님들, 프로님들께도 너무 감사드린다. 믿고 달린다는 게 뭔지 알 것 같았다.
몰두했던 기술을 막바지에 갈아엎겠다는 결단을 내리거나, 프론트 하드캐리를 받거나, 팀원들 개개인이 프로젝트에 온전히 몰입했던 경험 모두가 새롭고 소중했다.
기획 당시부터 재미라는 핵심 가치 하나만을 보고 달려왔는데 우리는 7주 동안 정말 즐거웠고, 모든 분들이 개발하면서 즐거움을 느끼셨으면 좋겠다.
+)
사실 많이 부족했다고 생각한다.
발표 때 뭐 잘못될까봐 개발이 끝났는데도 불구하고 추가하지 못했던 기능들이 있었고, nginx 관련해서도 우리 컨테이너에서만 오류가 나는 바람에 멘토님께서 초기화를 제안하시기도 했다.
그래서 싸피 공식 배포 끝난 다음에 백엔드 담당자들끼리 모여서 그 부분을 싹 돌려서 재배포했다.
후-련
