upco #1. 역할 분담 & 프로젝트 기획 (1주차)

코드캠프 내 프로젝트 시작 후 일주일이 지났다.

오늘은 그간 있었던 내용들을 포스팅하고 최대한 시간순서대로 정리하는 시간을 가져본다.

 

1일차.

프로젝트 첫날은 팀원 배정 후 역할을 나누었고, 나는 팀장을 맡게 되었다.

장(長)의 역할은 익숙한 편이라 자신이 있었다.

역할을 선정한 이후에는 어떤 서비스를 만들지 함께 고민했다.

내가 제시한 아이디어는 기각되었지만, 아이디어가 변형되어

결국 '실시간 유저들 위치정보를 제공하는 동네친구 찾기 서비스'로 결정되었다.

단순히 한 사람의 위치정보가 아닌, 다른 유저들의 위치정보까지 제공하는 기능,

채팅을 포함한 화상채팅 기능을 넣어 다른 팀들과 다른 차별점을 둘 수 있다는 것이 그 이유였다.

이후 팀장으로서 주말동안 할 것에 대해, 각자의 역할에 따라 할 일을 부여하고 규칙을 정했다.

 

2일차.

프로젝트 후 첫 주말이었다.

어떤 서비스를 할 것인지 기획은 결정하였으니 이를 구체화할 수 있는 것이 필요했다.

이때쯤 한 팀원이 이전에 자신이 만든 '비지니스 모델 캔버스'를 보여주셨는데,

여기서 경영학을 전공하던 대학시절 작성해 본 적 있던 '비지니스 린 캔버스'가 떠올라 우리 서비스의 캔버스를 완성했다.

머릿속에 있는 것을 직접 문서로 작성하다 보니, 우리가 서비스를 어떻게 구현할 것인지 구체화할 수 있던 시간이 되었다.

 

3일차.

3일차에는 팀원들이 무엇을 하고 있는지 물어보지 않고도 파악할 수 있도록 엑셀파일을 하나만들어 공유했다.

해당 파일에는 우리 팀이 프로젝트를 진행하는 동안 완성해야 할 각종 문서들을 포함하였고,

각 날짜를 나눈 뒤 각 팀원들의 이름을 넣고 '할 일'과 '완료 여부'를 구분했다.

이후에는 2일차 때 작성한 캔버스를 기준으로 기획의도를 작성하였다.

 

4일차. 

4일차부터는 서비스 목적에 맞는 기능을 명시한 '사용자 요구사항 정의서',

사용자가 경험하는 모든 단계를 표현하는 'User-flow'를 비롯한 문서들을 팀원들과 함께 작성했다.

데이터베이스의 관계도를 다루는 ERD 또한 작성했는데,

특이 사항이 있다면 우리 서비스의 ERD의 경우, 이전 내가 수업 때 작성한 ERD의 규모보다 매우 작다는 것 정도.

하지만, DB는 서비스 목적에 따라 규모가 달라지는 것이기에 개의치 않기로 했다.

이후에는 프론트엔드 분들에게 wireFrame, 화면정의서를 맡기고, 백엔드 팀원들끼리는 API 정의서를 작성했다.

사실 처음에는 이 문서들을 모두 작성해야 할 필요가 있느냐 싶다가도,

팀원들과 얘기를 거치며 서로 잘못 이해하고 있는 부분들에 대해 교정할 수 있는 시간이 되었던 것 같다.

 

5일차. 

5일차에는 프론트엔드, 백엔드가 각각 작성한 문서들을 함께보며 수정하고 회의하는 시간을 가졌다.

이때 회의 도중 내가 이해하지 못하는 내용이나 개념들이 종종 등장했는데,

내가 인식하고 있는 것보다 개발에 대해 잘 모르고 있었다는 것을 알게 된 시간이었다.

다소 부끄러웠지만, 앞으로 개발 공부를 하는 것에 있어 동기부여가 될 것이라 믿어 의심치 않는다.

추가로 프로젝트 내 사용될 기능에 대해 역할을 분담했다.

나는 지도와 관련된 API는 혼자, 화상 통화 기능에 관한 webRTC를 팀원 한 분과 함께 구현하기로 했다.

이후에는 사용자의 위치정보를 어떻게 구현할지 고민하고 정보를 찾아보았다.

그리고 집에 돌아와서는 MongoDB에 유저 위치정보를 저장하는 로직을 혼자 연습해보았다.

 

6일차.

프로젝트 시작 후 멘토님들과 첫 중간 점검 시간을 가졌다.

멘토님들은 우리 팀의 ERD를 보고 왜 이리 규모가 작느냐 떨떠름해하시다가,

우리 서비스의 기획을 듣고 수긍하신 뒤 코드캠프 내에서 처음 시도하는 프로젝트라고 말씀해주셨다.

그 덕분인지 '우리 서비스는 특별하다'라는 메시지가 팀원들에게 전달되어 팀 사기가 전체적으로 올라간 것 같다.

중간 점검 내용으로는, 

사용자 위치정보를 SQL 에 저장하게 되면 과부하가 일어날 수 있으니 다른 방식으로 구현하라는 것.

채팅방의 채팅 내용들은 수정될 내용들이 없으니, SQL 보다는 noSQL 을 활용하라는 것.

프론트의 경우 사용자 편의성을 중심으로 생각하고 디자인을 구상하라는 것 내용들이었다.

이후 중간 점검이 끝난 뒤, 실시간 유저 위치 정보를 저장하는 방식에 대해 찾아보다가

일반적으로 위치 정보를 저장할 때 Redis를 사용한다는 것에 알게 되었고 이를 활용하기로 했다.

이전에 Redis를 활용하여 로그아웃을 구현한 적이 있었기 때문에 그리 어렵지 않을 것이라는 생각이 들었다.

 

7일차.

7일차에는 팀원들과 서비스 이름을 정하는 시간을 가졌다.

여러 의견이 나왔지만, 내가 제시한 '엎코'('엎'어지면 '코'닿는 곳에서 만나는 친구)가 만장일치로 결정되었다. 

팀장이라 내가 제시한 것을 팀원들이 그냥 밀어준 것인지도 모르겠지만, 기분은 좋았다.

이후에는 서버를 담당하는 팀원이 서버를 올리기 전까지 시간이 남아 혼자 redis에 위치 정보를 저장하는 방식에 대해 구현했다.

처음에는 로그아웃할 때 구현했던 방식을 활용하여,

유저 아이디는 key, 위치 정보를 value로 저장하고 필요할 때마다 읽어온 뒤,

조건문을 포함한 반복문을 작성하여 해당 범위 내에 있는 유저들을 반환하는 방식으로 로직을 작성했는데 비효율적이라고 느꼈다.

그리고 이에 대해 chatGPT에 질문을 던지자, Geo API 라는 답변을 받게 되었는데 다음 8일차 포스팅에는 이에 대해 다뤄보기로 한다.