[회고] 디프만 14기 Bibbi 서비스 앱 개발 회고

Jenny·2024년 2월 19일

📝 개요

취업 준비 과정을 거치면서 마땅한 앱 런칭 경험이 없던 저는 프로젝트를 런칭해보고자 디프만 - 디자이너와 프로그래머가 만났을 때 연합동아리에 지원하게 되었습니다.

💁‍♂️ 서비스 소개

저희 Bibbi서비스는 가족에게 자발적으로 하루에 한번 사진과 함께 생존신고를 하고, 그 추억을 영원히 공유하는 어플리케이션입니다. 저희는 사용자 설문 조사를 통해 부모와 자녀의 연락 빈도수가 저조하다는 것을 확인하였고 이를 해결하기 위해 하루에 딱 한번, 자발적으로 가족에게 "생존신고" 를 하는 앱을 구상하게 되었습니다.

🧑‍💻 iOS 개발

iOS GitHub Repository: https://github.com/depromeet/14th-team5-iOS

저희 iOS 팀원분들은 기획 회의를 마친 후 개발을 시작하기에 앞서 개발 환경과 실현 가능성 및 컨벤션에 대해 논의하였습니다.

그뿐만 아니라 앱 운영에 대해 고려하였기에 Tuist를 도입하여 빌드 속도를 향상할 수 있도록 노력하였으며 모듈 단위를 어떤 기준을 삼아서 나눌 것인지에 심도 있게 고민하였습니다.

⚒️ iOS Architecture

저희 iOS 팀원분들과 많이 고민한 부분이 바로 아키텍처 부분이라고 생각합니다.

이전 사이드 프로젝트 활동을 할 때도 같은 고민을 하였는데 어떻게 하면 외부 간의 의존성을 줄일 수 있는지, 혹은 코드 분석 시간을 단축할 수 있는지에 대해 고민하였습니다. 이러한 공통적인 목적을 팀원이 가지고 있었기에 저희는 Clean Architecture + ReactorKit 사용하였습니다.

특히 Reactor를 채택하여 모두 형식적인 틀 안에 비즈니스 로직을 구현할 수 있게 되어 코드 분석 시간을 단축할 수 있도록 하였으며 무엇보다 Clean Architecture를 통해 외부 의존성을 줄일 수 있을 뿐만 아니라 각 계층 간의 비즈니스 로직을 분리할 수 있었습니다.

📸 이미지 업로드

Bibbi Service에 핵심 기능 중 하나인 카메라를 이용한 사진 업로드 기능이 있습니다. 저희는 사진 업로드 과정에 있어서 다들 흔히 사용하고 있는 multipart 방식을 사용하지 않고 Presigned-url을 발급받아 직접 클라이언트(iOS)가 이미지를 S3에 업로드하는 방식으로 구현하였습니다. 저 역시 Presigned-url에 많은 어려움을 겪었습니다. 하지만 이러한 방식을 통해 서버가 직접 multipart 파일을 가지고 있지 않아도 되며 리소스 낭비를 줄일 수 있기 때문에 트래픽을 줄일 수 있다고 합니다.

Presigned-url은 다음 글에 정리 하겠습니다 :)

😍 다양한 경험

저희는 이러한 노력 끝에 서비스를 런칭하게 되었고 디스콰이엇에 트렌딩 프러덕트 1위를 할 수 있었습니다. 이뿐만 아닌 렛플측에서 저희 서비스를 배너 광고에 올려 주셨으며 저희 서비스가 다른 사용자분들께 많이 알려주시게 되며 다양한 트래픽과, 이슈 경험을 맞보게 될 수 있는 하나의 계기가 되었습니다.

🎉 디프만 최종 발표

애정이 가는 5조 팀과 어느덧 최종 발표까지 오게 되었습니다. 짧은 기간이었지만 그만큼 많은 성장을 할 수 있었던 좋은 계기가 되었습니다. 모두 감사합니다.!! :)
사실 이러한 짧은 기간에도 불구하고 값진 경험을 쌓게 해주신 저희 5팀에 감사의 인사를 드리고 싶으며 앞으로 Bibbi앱 운영을 진행하면서 지속해서 함께 성장해 나아갈 수 있도록 기원하겠습니다!! :) 마치며 저희 디프만 최종 발표회에서 저희 Bibbi 서비스는 많은 팀 분에게 극찬을 받았으며 결국