[iOS] 멋쟁이사자처럼 앱 스쿨 최종 프로젝트 마차챠 회고

  🍡 마차챠란?

• 인터넷 검색을 통해 포장마차의 정보를 쉽게 접하기 어렵다는 사실을 깨달았다.
• 포장마차의 정보(영업 요일, 메뉴, 가격, 리뷰)를 쉽게 알 수 있고 포장마차를 추천해주는 앱을 제작하기로 결심했다.

GitHub - jeoneeee/finalproject-machacha: 마차챠: 포장마차의 위치 및 영업 시간를 제공하는 서비스 🍢

 

 

🐣 프로젝트에서 내가 담당한 기능

• 홈 화면(큐레이션 방식으로 포장마차 보여주기, 알림 확인)
• 디테일 화면(가게 리뷰 사진 5개 보여주기, 가게 정보, 가게 제보(신고)하기, 리뷰 최신순 썸네일 목록 2개 제공(더보기 클릭시 전체 리뷰 확인 가능))
• 리뷰 화면(리뷰 작성 및 시간순으로 리뷰 확인)

 

 

💁🏻‍♀️ 무엇을 배웠는가?

• 애자일 방식으로 진행된 첫 팀 프로젝트인만큼 많은 기술적 성장을 더불어 의사소통 능력, 협업 능력을 향상시킬 수 있는 시간이었다.

 

🧩 기능의 우선순위  구분

• 평소 진행했던 팀 프로젝트는 각 파트마다 매주 조금씩 기능을 개발하는 느낌으로 디벨롭을 해가며 진행해왔었다.
  • ex) 1주차 - 리뷰 뷰 모델 작성, 2주차 - 리뷰 UI 구성 ...
• 하지만 이번 프로젝트는 애자일 방식으로 진행되었기 때문에 각 주차마다 내가 담당한 한가지 분야를 다 끝내고 피드백을 받는 형식으로 진행했었다.
  • ex) 1주차 - 리뷰 구성(뷰 모델, UI 등) -> 2주차 피드백 후 개선
• 위와 같은 애자일 방식으로 팀 프로젝트를 진행하였기 때문에 주어진 시간안에 일을 다 끝내야했었다.
• 나에게 주어진 시간을 최대한 활용하기 위해서는 핵심 기능과 부가기능을 나눠서 구현 우선순위를 정했다.
• 이렇게 매주 기능을 나눠 우선순위를 정하다보니 기능의 우선순위를 파악할 수 있는 안목이 생겼다.

 

🧩 소통의 중요성

• 그동안 멋쟁이사자처럼에서 팀 프로젝트를 진행할때는 정해진 시간안에 좋은 퀄리티의 결과물을 내야해서 기획 할때 조원들과 많은 회의 시간 없이 진행을 해왔었다.
• 이렇게 진행해오다보니 서로 이해한 결과가 달라 만든 결과물이 다르기도하였고, 여러 충돌이 생겨 오히려 더 많은 시간을 투자하게 되었었다.
• 이런 단점을 극복하고자 마차챠를 진행하였을때는 본격 개발 전 팀원들과 충분한 아이디어 회의에 많은 시간을 투자하였다.
• 개발 중 이해가 안되는 프로세스가 있으면 눈치보지않고 바로 DM을 하자!라는 팀 문화도 있었다.
• 이런 시간들 덕분에 오히려 개발 시간이 줄어들었고 팀원들끼리 원활한 의사소통을 하며 개발을 진행할 수 있었다.

 

🧩 async/await를 통한 비동기 처리

• 비동기 처리가 어려웠던 나는 부끄럽지만 평소 강사님의 코드만 복붙해서 컬렉션만 바꿔주는 수준이었다.
• 마차챠 프로젝트 기간동안 이런 점들을 고치고싶었고, 마차챠 기간동안 비동기처리와 관련된 많은 에러와 싸웠다.
• 그 결과 현재 내가 원하는 코드들은 async/await를 사용해 비동기 처리를 할 수 있게 되었다.

 

 

😮‍💨 프로젝트 중 마주친 고민사항

 

🧩 포장마차 정보에 대한 확실성

• 사용자가 작성하고 등록하는 정보에 의존하는 앱인만큼 정보에 대한 확실성에 대해 많은 고민과 회의를 진행하였다.
• 그 결과 관리자 앱을 따로 만들어 포장마차 중복 등록 체크, 사용자 제보(신고) 확인 기능을 추가하였다.
• 프로젝트 시간 관계상 모든 지역의 확실한 포장마차 정보를 알아낼 수 없어 명동으로 지역을 제한하여 팀원들끼리 명동 사전답사를 다녀왔다.

 

🧩 페이지네이션

절망의 코드

• 마차챠는 NoSQL 스키마로 구성되어있어 Review Collection에서 WhereField를 사용해 Review를 가져오고있었다.
• Firebase에서 제시하는 페이지네이션 방법을 사용하기위해서는 order을 사용해 시간순으로 정렬을 해야했었다.
• 하지만 다른 필드끼리의 함수 사용은 금지가 되어있었다..
• 팀원들끼리 페이지네이션 도입과 관련하여 회의를 진행한 결과 시간이 얼마 남지 않은 상태에서 DB 구조를 바꾸는건 무리라 생각해 페이지네이션을 포기하였다.

 

🧩 Kingfisher 도입

• 마차챠는 Firebase Storage를 사용해 이미지를 저장해왔었다.
• 대량의 포장마차 사진 데이터가 들어가니 Firebase Storage의 무료 용량의 초과해 마차챠의 Storage는 터지게 되었다.
• 팀원들끼리 회의를 진행한 결과 이미지 캐싱 기능을 추가하자라는 결론이 나왔고, 결국 Kingfisher를 도입하게 되었다.

 

 

📝 아쉬웠던 점

• 지역을 명동으로 제한했던 점이 아쉽다.
• 홈 화면에 추천 알고리즘을 구현하지 못했던 점이 아쉽다.
• 늦은 발견으로 인해 페이지네이션을 반영하지 못한 점이 아쉽다.

 

 

💡 총 회고

• 평소 내가 코드를 짜면서 이게 좋은 코드인가?라는 생각을 나 자신에게 많이 물어봤는데 항상 나 자신에게 확실한 대답을 하는것이 어려웠었고, 그냥 코드는 작동만 되면 끝난거야!라는 생각이 있었다.
• 마차챠 기간동안 좋은 코드란 무엇인가, 팀원들이 내 코드를 잘 알아볼수있는가?, 사용자에게 이 앱이 사용성이 좋을까?에 대해 많은 고민을 했었던것같다.
• 코드가 단순히 짜서 작동이 된다!에서 끝이 아니라 왜 작동이 되는지, 왜 작동이 안 되는지에 대해서 많이 고민하고 생각하려고 했던 것 같다.
• 사용자의 앱 사용성을 높이기 위해 프로그레스뷰, 스켈레톤뷰, 토스트 메세지 등 여러가지 정보들을 새로 접하며 앱에 반영하려고 노력하였다.
• 단순 개발만 하는 게 아니라 마차챠를 진행하며 '왜?'에 관련된 부분을 많이 배울 수 있었고, 그 덕분에 생각을 하며 개발을 할 수 있게 되었다.