28th SOPT APPJAM 앱잼 - 두리번(DOORIBON) 회고 (2)

2021.07.20 - [프로그래밍/잡다한 개발 일지] - 28th SOPT APPJAM 앱잼 - 두리번(DOORIBON) 회고 (1)

28th SOPT APPJAM 앱잼 - 두리번(DOORIBON) 회고 (1)

---

이번 글은 주로 1주차 내용이 나올 것 같다.

금손 지인언니가 만든 가상배경

📌  협업 툴

1주차가 시작되었다. 두리번은 총 4개의 협업 툴을 사용하였는데 노션, 게더타운, 슬랙, 디스코드 였다. 노션은 전체 페이지와 각 파트별로 페이지를 파서 사용하였는데 서버에서는 레퍼런스 관리, 이슈 관리, 명세서, 일정 관리등 다방면으로 사용하였다. 슬랙에서는 주로 파트별로 개발 이야기를 하거나 다른 파트와 교류할 용도로 사용했다. 슬랙은 코드 스니펫 기능을 굉장히 깔끔하게 제공해서 서버 채널에서 유용하게 사용하였다. 특히 좋았던건 PM 유진언니가 모든 채널에 다 들어와있어서 서버 채널에서도 도움을 준 일이 많았던 점이다.

여담으로 서버 채널이 제일 시끄러웠다고 한다. 

유난히 시끄러웠던 서버번

노션을 깔끔하게 잘 정리한 것 같다.

 원래는 게더타운에서 일종의 사무실 처럼 모여서 작업하려고 했지만 게더 자체가 느리기도 하고, 개발 특성상 열어놓는 창이 많아 불편하다는 평이 있었다. 대안으로 나온 것이 디스코드였다. 나는 디스코드를 워낙 잘 쓰고 있었고, 신촌 연합 운영진에서나 알고리즘 대회 준비를 할 때 사용하여서 익숙한 툴이었다. 

게더타운에서 열린 미몽 청문회와 우리의 (구) 사무실

게더가 귀엽긴 했다. 게더에서 디스코드로 넘어가고 디스코드에서는 사실상 rythm 봇만 사용한 것 같다. 다들 작업 할 때 심심하니까 음악 재생 봇인 rythm을 불러다가 작업하고는 했다. rythm이 각 채널 별로 올 수가 없고 한 채널에서만 사용가능해서 결국 뒤로 갈수록 모든 파트가 한 채널에서 작업 하는 수준이 됐는데 오히려 정겹고 좋았던 것 같다. 바로바로 소통도 가능하니까.

1-2 주차는 같은 파트를 제외하고는 대부분이 온라인 작업이었는데 그럼에도 모든 파트가 함께 모여있는 느낌이 들만큼 온라인 협업 툴을 제대로 사용한 것 같다.

👩🏻‍💻 Coding, Commit Convention, Branch 전략 

서버 1차 과제이기도 했고, 개발 프로젝트의 시작점인 코딩 컨벤션, 커밋 브랜치 전략을 정했다. 파트장님이 주신 자료가 잘 정리되어 있어서 거의 차용하여 만들었다. 사실 이전 프로젝트들이 거의 나 혼자 하거나 친구랑 둘이 한 프로젝트라 이렇게 세세하게 규칙을 정하진 않았었다. 그래서 이렇게까지? 라는 생각을 잠깐 했는데 앱잼이 끝나고 보니 각기 다른 3명이서 통일성 있는 코드를 작성하고, Git 이 꼬이지 않게 개발하기 위해서 필수였구나 하는 생각이 들었다.

이 내용은 두리번 서버 Github README 에 정리되어 있다.

https://github.com/TeamDooRiBon/DooRi-Server/blob/develop/README.md

GitHub - TeamDooRiBon/DooRi-Server: 🛠 두리번 서버 보수 완료 🛠

Coding Convention

Coding Convention에서는 변수명, 주석, bracket, 비동기 함수, Database 규칙을 정했다. 대표적으로 변수명 camelCase 사용, async-await 지향 등 이런 종류의 규칙이었다.

나는 Bracket 규칙을 맨날 까먹어서 PR 날릴 때 피드백 받고 수정하곤 했다. 알고리즘 대회 준비 할 때 빠르게 코드를 짜려던 습관이 남아서 그런지 자꾸 중괄호나 괄호를 띄어쓰기 없이 붙여쓰는 버릇이 생겼던 것 같다. 그래도 앱잼 하면서 Bracket 규칙은 점점 잘 지키게 되었다.

while (Dooribon) {
	world.best = Dooribon;
}

Commit Convention

사실 쓴건 .. 한정적이긴 하다.

커밋 컨벤션에서는 주로 feat, fix, style, comment, docs, chore 정도 사용한 것 같다. 어쩌면 잘못 쓴것일수도 .. ?

Branch Strategy

여기서 꽤 많은 시간을 쏟았는데 앱잼 전 나의 목표가 Github Conflict 안나기 이기도 했고, 내 자신 자체도 깃헙 협업이 막 익숙한 편은 아니어서 셋이서 Github flow를 완벽히 이해 후 시작하자고 했다. 파트장님께 많이 물어보기도 하고, 구글링도 열심히 한 결과 

3명이서 local-develop (jobchae, judy, xxeol)을 만들고 remote-develop 으로의 PR을 날리는 flow를 정했고, 각자 맡은 기능은 local-develop_feature/#이슈번호 로 올리기로 정했다.

앱잼하면서 issue 나 PR, Code Review 등 Git 협업에 꽤 많이 익숙해진 것 같다. 아, 그리고 앱잼동안 conflict 안나기는 실패했다! 나긴 했는데 모두 알아서 잘 해결하고 돌아왔다는..

힘든 깃헙과의 싸움 결과

 

🛠 서버 시동 걸기

시동은 방탈출로

두리번은 금손 디자이너들 덕분에 뷰가 빠르게 나오고 있었는데 서버는 첫주차에 해당 뷰와 와이어프레임, IA를 참조하여 DB 설계와 API 명세서 초안 작성을 끝내야 한다. 사실상 DB만 제대로 설계하면 그 뒤는 API 코드를 작성하면 끝나는 일이다. 우리는 첫주차 목요일까지를 기한으로 잡고 DB와 명세서 초안을 작성하기로 했다. 두리번의 경우 처음부터 약간의 어려움이 있었는데 어플리케이션 자체가 그룹 서비스기에 유저 각각이 작성한 DB 내용들을 여타 커뮤니티 서비스와는 다르게 모든 유저에게 다 보여주면 안된다. 해당 그룹에 존재하는 멤버들에게만 나타나야하는 내용들이 많아서 그룹 DB를 어떤식으로 설계할지가 큰 고민이었다.

이런 식으로 멤버를 묶어줘야 하기에 User DB 보다 Group DB 중앙으로 생각하고 설계를 시작했다.

필요한 DB를 우선적으로 정했는데 기능에 맞게끔 User, Group, Schedule, Tendency, Board, Wish DB 틀을 잡았다. Group 별로 나머지 DB들은 모두 ref 관계로 ObjectId를 저장하게 설계하였다.

여담이지만 데모데이 날 서버 멘토님께 이런 그룹 서비스를 구현할 때 DB를 어떤식으로 설계하는게 좋을지 여쭤보았다. 멘토님은 우리와 반대로 나머지 DB들에 Group ObjectId를 참조할 것 같다고 하셨다. 지금 생각해보면 Group DB에 너무 복잡하게 나머지 DB들을 모두 참조한 것 같기도 하다. 효율적으로 DB를 설계하기엔 아직 배울게 많다는 걸 느꼈다.

최종 DB 다이어그램

Group DB 에서 모든 DB를 참조하고 있어 굉장히 복잡해 보인다. 아예 멘토님 말씀처럼 DB 자체를 반대로 구현해보고 싶지만.. 그러면 서버 API를 갈아 엎어야하니 이 정도로 만족한다.

 

DB 설계를 마치고 바로 API 명세서 작성에 들어갔다. 뷰 하나 하나를 살펴보며 어떤 데이터가 필요하고 어떤 데이터를 받아와야하는지 고민했다. 3명이서 같이 뷰를 보면서 필요한 API method를 정해놓고, 노션에 정리했다. 이후에는 정리한 API를 기반으로 3명이서 각자 원하는 API 명세서를 작성하도록 했다. 

명세서 초안 작업

초반에는 Wish List 기능이 있어서 해당 명세서까지 작성하느라 약 30개 정도 존재했는데 후에 기능 구현을 취소하기로 해서 최종적으로 24개의 API 명세서를 작성했다. 여행 성향 테스트가 가장 늦게 작성된 명세서인데 이 이야기는 후에 따로 쓰도록하겠다.

정해둔 기한보다 이틀정도 넘을 때까지 성향 테스트가 명세서를 짤 수가 없어서 일단 성향 테스트를 뒤로 미루고 나온 명세서부터 구현하기 시작했다. 일주일이상 남았을 때 서버 배포가 나의 목표였어서 사실 조금 조급해졌다.

❤️‍🔥 PM 따라 Wework 탐방

우리팀 최대 복지라 하면 Wework.

PM 유진 언니가 위워크 게스트로 우리를 불러줘서 종로, 홍대, 여의도 위워크를 탐방할 수 있는 귀중한 기회를 얻었다. 이런 공유 오피스는 처음 방문했는데 화장실 갔다가 헉! 소리낸건 처음이었다. 

미친 뷰와 한국적인 위워크

서버끼리 작업하러 만나면 카페에서 10시까지 하다가 집으로 가야 했지만 24시간 오피스인 위워크는 조금 더 늦게까지 작업이 가능했다. 개인적으로 나는 낮보다 밤에 코딩이 더 잘 되는 사람이라 10시에 흐름이 끊기지 않고 조금 더 작업할 수 있어서 좋았다. 커피도 무한 제공이라 나같은 커피 처돌이에게 위워크는 꿈의 작업 공간이었다. 

🔪 잔 치 + 마니또

1주차 토요일은 잔치날이었다. 아무래도 온라인이다보니 다른 파트 팀원들과 친해지기 어려운 면이 있었다. 이 점을 위해 기획단에서 낮에 함께 작업하다가 저녁에 4명씩 조를 짜줘서 친해지는 자리를 만들어주었다. 이 날 나랑 같은 조가 된 사람들은 상진, 인우, 지인!

사실 저기서 지인 언니 빼고 다 아는 사람들이어서 어색하지 않았다. 토크의 주제는 거의 두리번 마니또였다. 두리번 자체적으로 산타마니또 어플을 통해 마니또 게임을 진행했다. 각자 서로의 마니또가 되고 하루에 한번 미션을 수행했다. 나는 이때 PM의 마니또였는데 어처구니 없이 들켜서 속일 수 없었다는 슬픈 이야기. 

 -> 마니또 오픈 카톡방이 폭파되어 새로운 방으로 들어가야했는데 내가 거의 마지막으로 들어갈 차례였다. 입이 방정이지 유진 언니한테 "오카방이 새로 생겼어?" 라고 해버린 바람에 내가 아직 방에 안들어간 걸 들켜버렸다.

들켜버린 이수만

아무튼 술자리에서 마니또 이야기도 하고, 민트 초코 소주도 마시며 절거운 시간을 보냈다. 2차는 유진언니 집으로 향했는데 여기가 찐 술잔치였다. 올리고 싶은 사진과 이야기는 많지만 두리번의 사생활을 존중하도록 하겠다.

일주일 동안 DB 고민하고, API 명세서까지 짜느라 머리가 지끈거렸었는데 이런 리프레쉬 데이를 기획해준 기획단 언니들이 고마웠다. 기획 의도에 맞게 나도 이 날 원래 알던 팀원과도 처음 본 팀원들과도 많이 친해질 수 있었다. 나름대로 할땐 하고 놀땐 노는 일주일을 보낸 것 같다. 사실 서버랑 방탈출 한번 더 하고 싶어서 초조했다.

 

나는 과연 서버와 방탈출을 또 할 수 있었을까?

다음편에 계속.

쓰기 귀찮아서 급 마무리하는 거 아니다.