멋쟁이 사자처럼 앱 스쿨 / OUR, 우리들의 취업&스터디 플랫폼을 구현하면서 느꼈던 모든 것

제목을 너무 거창하게 써 놓았는데..

멋사 앱스쿨 2기를 하면서 진행했던 첫번째 프로젝트를 정리하고 회고하는 글입니다.

그냥 저의 다사다난한 공부 기록임을 감안하면서.. 심심하신 분만 보세요... 

 

이번 대형 프로젝트 B 는 LinkedIn을 오마주한 취업 플랫폼을 직접 만들어 보는것이었다.

관리자 앱과 소비자 앱, 총 2개의 앱을 만들어야 했다.

관리자 앱은 아이패드로 구현해야 했으며, 인원 분배가 굉장히.. 이상했는데

관리자는 총 4명이서 하고 나머지 소비자 앱을 할 20명이서 한것 같다.

그중에서 나는.. 소비자 앱을 했기 때문에 관리자 앱을 배제하고 회고를 작성해보려고 한당!!

먼저 소비자 앱에는 피드, 스터디, 등록, 알림, 프로필 총 5개의 탭을 가진 앱이었다.

 

 

우리의 앱을 정리(소개)해보면 …

• 우리 앱은 취직에 필요한 활동들과 정보를 공유할 수 있는 취업 특화 SNS이다.
• 우리 앱은 스터디 모집 글을 작성하고 참여 신청을 할 수 있다.
• 우리 앱은 사용자끼리 친구를 맺고 이력서, CV를 공유할 수 있다.
• 우리 앱은 서로 취업에 대한 정보 공유글을 게시하고 이를 피드에서 확인할 수 있다.

라는 것을 주제로 우리들의 취업/스터디 플랫폼인 OUR를 만들게 되었다.

 

그래서 어떻게 했는데?를 정리해보자면..

(로그인은 구글 로그인으로 구현함)

 

1. 피드

등록하는 곳에서 등록하는 일반적인 피드글이 올라오는 곳으로

아래 보이는 사진처럼 사진/위치(옵셔널), 내용이 들어간 글을 보여주는 탭이다.

 

댓글을 달거나 하트를 누르는 커뮤니티 기능도 제공한다. 리포스트 기능과 공유 기능도 가능하고 한다!

 

 

2. 스터디

등록한 스터디를 보여주는 곳으로 전체/온라인/오프라인을 구별해서 볼 수 있으며,

각 게시물 마다 댓글을 통해서 소통할 수 있다. 스터디를 북마크하여 저장할수 있다.

또한 현재까지 지원한 멤버들의 정보도 확인할 수 있다.

 

 

3. 등록

여기가 내가 맡은 파트!!!

글은 일반 피드 등록과 스터디 모집으로 나뉘어졌는데,

피드 등록을 통해서 등록된 글은 위의 피드에서 볼 수 있었고,

스터디 모집을 통해서 등록된 글들은 스터디탭에서 볼 수 있다.

 

사실 이 두개의 등록중에서도 내가 집중적으로 맡은 곳은 스터디 등록 페이지였다.

멋사에서 걸어준 조건은 사진과 위치를 꼭!!! 사용해야 한다고 해서 저렇게 뷰를 디자인해서 구현했다.

 

• 제목과 내용은 꼭 들어가야 등록 버튼이 활성화 되었으며, 사진과 위치는 옵셔널이었다.
• 위치는 검색이 가능했지만… 나갔다가 다시 돌아와도 이전 위치를 나타내는 핑이 삭제되지 않는다는 문제점이 있었다.
  끝내.. 해결하지 못했음. 왜냐하면 내가 직접 공부하면서.. 모두 수작업으로 짠 코드가 아니었기 때문임..

 

 

4. 알림

알림도 내가 안 해서 모르겠지만..

일단 우리 앱은 팔로우 기능이 있는 앱이었기 때문에 누군가 자신을

팔로잉하면 알림이 오도록 구현을 했으며, 본인이 등록/지원한 스터디에 관련한 알람도 오도록 구현했다.

 

 

 

5. 프로필

사용자의 정보를 담고 있는 탭으로, 팔로워, 팔로잉, 게시물 등을 확인할 수 있었고,

본인이 저장한 스터디 및 지원한 스터디도 확인할 수 있다.

 

 

FireBase 활용한 백엔드 구현

우리 앱의 모든 데이터는 파베에 저장되고 파베에서 가져와서 활용하는 형식이었다.

파베에 데이터를 저장하는 방법에 대해서 알 수 있어서 좋았다.

 

 

이제 장점과 단점을 정리해보려고 한다...

장점

• 사진, 지도와 같은 기능을 구현해 볼수 있어서 좋았다.
• 20명이 넘는 사람들과 함께 깃을 사용하면서 깃 충돌 해결법과… 깃 사용법을 정말 많이 배우고 고생했다. (?)
• 협업이라는 것을 경험해보았다.
• 피그마를 처음 사용해보았다.
• 나름대로 포인트 색상, 메인 색상들을 규정하고.. 그에 알맞은 디자인을 하려고 했으며,
  우리끼리의 브랜치 규칙, PR 규칙을 생성하여 사용하려고 노력했다!!!
• 파베의 Storage를 사용해보았다!!! 매우 값진 경험.
  실제로 서버가 없는 우리기 때문에 사진을 어떻게 보관하느냐가 정말 관건이었는데
  파베의 스토리지를 활용하여 거기에 데이터를 올리고 메타 데이터를 통해 서버의
  url값을 활용하여 다시 뿌려주는 방법으로 우리 앱에서 데이터를 활용할 수 있었다.
• 깃 Ignore를 처음 사용해보았다. 크라켄 살짝 고수됨.

나름.. 열심히 피그마도 하고.. 깃 컨벤션도 정하고.. 포인트 색상/틴트 색상, 로고 디자인 등..

개발 뿐만 아니라 기획부터 UI/UX까지 경험해볼 수 있었다.

 

 

단점

1. 기획을 얼레벌레 하다보니 중간에 허점이 너무 많아서 소통하기가 힘들었다.

 

회의 없이 냅다 뷰부터 그리게 되었음….

물론 관리자팀에서 우리가 데이터 모델을 짜줄테니까 이거 사용해서 만들면 돼요~

하긴 했지만… 어떻게 된건지 말로 풀어보자면…

 

링크드인에는 이렇게 있으니까 우리는 피드/스터디/등록/알림/마이

이렇게 탭을 나누어서 탭별로 사람을 분배해서 만들어볼까요~?

… 이러다 보니 아무리 백엔드에서 데이터 모델을 짜줘도 우리가 필요한

데이터 모델과는 달라서 나는 백엔드에서 짜준 파베 공간말고 내가 직접 새로 만들어서 사용함. . .

 

다른 뷰들도 회의 없이 뷰부터 시작을 했기 때문에 서로 다른 탭?들의 상황을 모른채 각각 따로따로 데이터모델을 만들어서 진행했다.

(뿌리는 건 우리였기 때문에 나머지는 일단 만들고 더미데이터를 채워서 사용하는 형식으로 진행되었음)

 

⇒ 지금보니까 말도 안 되는 흐름인데.. 진짜 이런 흐름으로 일 분배해서 시작했음…

20명다 협업도 처음이고 기획을 경험해본 사람도 없었기 때문에.. 즉 아무도 진행을 어떻게 해야할까?를 몰랐다.

그래서 나중에 우리가 뿌려주는 데이터를 가져다 쓰는 스터디팀과의 마찰도 많았고, 데이터 모델을 하나씩 맞추는 것도 힘들었다. (CodingKeys를 활용하여 어찌저찌 맞춰서 사용하긴 했음)

 

피드 팀도 우리가 뿌려주는 데이터를 가져다가 써야했는데..

우리와의 소통이 부족해서 결국 피드팀은 우리가 뿌려주는 데이터를 가져다

사용하지 못했다는 슬픈 후문이 있다… (마지막까지 에러 대박…이었습니다 흑흑 ㅠ)

 

 

2. 다른 팀의 진행 상황을 전혀 알 수 없었다.

중간 중간에 한번씩 전체 회의를 해서 “우리 탭은 ___까지 진행했습니다”라는 것을

서로 공유하고 인지하면서 프로젝트를 하면 좋았을텐데..

 

그런 시간이 전혀 없어서 나는 프로젝트 내내 다른 탭들의 진행상황을 알지 못했다..

관리자도 마찬가지.. 사람이 너무 많다보니 의견도 많고 소통하기 쉽지 않은데,

온라인이기까지해서 소통하기 너무 힘들었다.

 

→ 그래서 앞으로는 주기적으로 2-3일에 한번씩 프로젝트 시작 아침에는

모여서 우리는 어디까지 진행했고, 필요한 부분이 어디에요 라는 소통을 해야겠다고 결심했다…

 

 

3. 깃허브의 충돌이 어마어마했다.

20명이 넘는 사람들이 하나의 깃 레포를 공유하고 머지하다보니.. 너무 충돌이 심했다.

머지가 잘못되어 프로젝트 파일이 날라가는 경우도 있었으며..

충돌 해결 후 재확인하지 않고 머지하다보니 파일이 누락된다거나

코드가 제대로 커밋되지 않는다거나 하는 문제점이 있었다.

깃 때문에 새벽 4-5시까지 다들 고생을 너무 많이 하고 이런 부분 때문에 프로젝트 진행이 더 더디었다…

 

약 2주 동안 데브 커밋만.. 800개가 넘었다… 개인 브랜치 커밋 포함하면 2000은 훌쩍 넘는 수치일것 같다…

•  이런 깃허브를 경험하면서 깨달은 것은… 사람이 많은 프로젝트면 일수록!!!! 꼭!!!! 자주 커밋하고 머지하는게 필수라는것.
  갭이 커지고 커지다 보니까 머지할 때 충돌이 너무 많이 난다는 건 정말… 스트레스 받는 일
• 그리고 맘대로 파일 삭제 및 파일명 수정은 금지라는 것!!!!!!!
  새롭게 그룹을 만들고 파일을 만들어서 작업하기 때문에 pb 파일도 무조건 커밋하고 푸시해야 하는데..
  남이 사용중인 파일을 맘대로 삭제하거나 파일명을 수정하는 경우가 종종 있어서 충돌이 정말 많이 일어났다.
  (근데 애초에 글케 맘대로 하는게 트롤임.)

그렇게 때문에.. 작업 공간이 겹친다면 겹치지 않도록 하는것이 최최최우선의 방법일것 같고.. 각자!! 어떤 일을 하는지 공유가 잘 되어야 한다는 것도 정말 중요하다는 것이다. 그리고 앞으로 본인 맘대로 파일명을 수정하거나 삭제하는 이상한 짓을 해버린다면.. 프로젝트에 있어서 제한을 둬야겠다는 생각도 들었다.

 

 

3. 공부의 부재

일단 구현을 먼저!!! 해야했기 때문에.. 그 와중에 사진과 지도를 꼭 사용해야 했는데

지도는 정말 낯설고.. 처음보는 API였다.

 

막 구글링을하고 찾아보아도.. 내가 하고 싶은건 안 나와서 유튜브를 보면서 ..

동영상을 멈춰가면서 코드를 이해하지 못한 상태로 그대로 따라 쳐서 구현을 했다. 

물론 내가 더 열심히 했다면.. 알수도 있었겠지만.. 이미 매일 새벽4시에 잠을 잤어서.. 흑흑

 

https://www.youtube.com/watch?v=fjZd1CwjlxQ&t=981s 

이 강의를 보면서.. 이해하지 못한 상태로 정말 그대로 따라 쳐서 구현했기 때문에

마크가 중복적으로 찍히는 에러를 해결하지 못했다.

 

시간에 촉박하게 구현을 해서 불가피했다는 게 너무 너무 아쉬웠다.

그래서 지도는 지금 따로 공부하고 있는중이다 ㅠㅠ

 

4. 의외로 너무나도 각박한 파베

우리가 사진을 저장하고 가져오기 위해서 Firebase의 Storage를 사용했는데..

세상 천사처럼 느껴졌던 파베가 이렇게 악마일 수가 없었다 (ㅋㅋ)

파베 스토리지 트래픽 제한이 하루에 1기가라는게 정말 너무했다는 것.

 

일반 엑코의 프리뷰에서 사진 로딩될 때도 트래픽에 저장되고..

앱 테스트 하면서 사진이 로딩되면 또 그것도 트래픽으로 찍히기 때문에

우리가 사진을 얼마 등록하지 않아도 사람이 많다보니 (사진 하나에 3-5메가)

금방 1기가가 넘어버린다는것이 정말 큰 문제점이었다.

이게 이렇게 넘어버리면.. 아예 접속도 안 되고 사진도 불러올 수가 없음.

물론 애뮬이라는게 있긴 하지만..

실제 서비스할 때 스토리지 사용은 힘들겠다는 생각이 정말 많이 들었다.

그치만 파베 사용법을 알아서 좋았다. (물론 현업에서는 안 쓰지만.. 취준할 때는 한창 쓸테니 알아서 좋았다는 말~..)

 

 

느낀점

프로젝트를 하면서.. 지식의 부재도 부재지만.. 기획이 정말 탄탄해야 한다는 것을 배웠다.

기획이 없다보니 우리가 어떤 데이터 모델이 필요한지 모르는 상태로 백엔드가 구성되고

백엔드는 입장에서 만든 데이터 모델을 활용하다보니 아무도 사용하지 않고 각자 다 따로따로

데이터 모델을 만들어버리는 이상한 상황이 벌어졌다.

 

이런 데이터 모델을 나중에 합치려고 하니까 어? 우리는 이런 기능이 필요해서 모델에 이런 정보까지 넣었는데..

등록에서 이거 안 넣어서 만들었어요?라는 이상한 마찰이 발생하고..

기획과 소통의 중요성을 정말 처절하게 배웠다.

 

프로젝트를 하면서 아.. 이게 맞나? 라는 생각을 정말 많이 했지만

하면서 배우는 것은 무조건 있다는 게 프로젝트의 매력인것 같다.

어쨌든 나는 프로젝트라는 연습을 통해서 기획의 중요성과 협업에서 가져야할 태도,

다인원의 깃 사용법, Firebase의 장단점등 다양한 부분을 배울 수 있었다.

 

이걸 토대로 다음, 다다음 프로젝트는 더 성장할 수 있지 않을까?!

 

 

회고 아닌 회고.. 끝!!!