[프로젝트] 첫 어플리케이션 출시 및 회고

NoeG·2022년 6월 29일
1

프로젝트

목록 보기
1/2
post-thumbnail

Photly - 함께 남기는 하루 한 장 (IOS/Android)

매일 새로운 미션을 받고,
미션에 맞는 각자의 사진을 공유하는 커플 전용 어플리케이션이다.

IOS - Apple 앱스토어

https://apps.apple.com/kr/app/photly/id1628693332

Android - Google 플레이스토어

https://play.google.com/store/apps/details?id=com.zagmar.couple_seflie_app

기획부터 출시까지 약 4개월이 걸렸다.

처음 출시해본 완성도 있는 어플리케이션이다. (추후 업데이트 예정)

나를 포함하여 디자이너1, 프론트앤드1, 백앤드1 총 3명이 팀을 이뤄서 사이드 프로젝트 형식으로 진행하였고,
나는 프론트앤드 개발을 담당하여 Flutter를 통해 개발을 진행하였다.

프로젝트 개요

시작: 2022년 2월
목표 기한: 3개월

2개월 내로 초기 모델을 구현한 뒤
1개월 간 테스트 겸 초기 운영에 집중을 하는 계획이었다.

팀 단위 프로젝트 목표

  1. 회원 가입 기능이 들어가는 서비스일 것
  2. 자발적 회원가입이 약 30명 정도 (1개월 테스트 기간 동안)
  3. 이후 피드백을 거쳐 버전업을 하는 것
  4. 비즈니스 모델을 넣어 수익 5만원 이상 도출해보기

개인적인 프로젝트 목표

  1. MVVM 아키텍처를 적용하여 코드 구현해보기
  2. 디자인을 모든 기기에 완벽하게 대응하는 것
  3. 클린 코드 지향하기
  4. 어플리케이션의 지속적인 업데이트를 통해 서비스 지속적으로 운영하기
  5. Git을 통한 작업 관리
  6. 프로젝트의 문서화

회고

프로젝트를 진행하며 많은 어려움이 있었다.
그 문제점을 분석하고 해결책을 찾아보고자 한다.

1. 지연된 프로젝트

목표였던 2개월 간의 개발 기간을 넘어 4개월이 걸려서야 마무리가 되었다.

문제의 원인

  1. 계획의 수립 및 이행이 잘 이루어지지 않음
  2. 작업 단위의 분리가 제대로 이루어지지 않음
  3. 기획의 미흡함
  4. 기술적인 미흡함

해결책

1. 개발을 진행하기에 앞서 개발의 흐름을 정하고 작업 단위를 분리하여 순차적으로 진행하자

본 프로젝트에서 구현한 서비스는 복잡한 구조가 아니었기에 이에 대해 큰 고민을 할 필요가 없다고 생각을 해서

로그인 / 회원가입 / 메인화면 / 글쓰기 / 디테일페이지

정도로 나누고 진행을 하였다.
그러나 개발을 진행하며 계획의 미흡함은 그대로 소요시간의 지연으로 나타났다.
실제로 '회원가입' 기능은 개발 도중에 여러 작업으로 쪼개졌는데 계정 관리는 Amplify로, 회원 정보는 DB에 저장을 하는 방식으로 나뉘었기 때문이다. 동시에 정보가 등록이 되는 것이 아니기에 작업을 쪼개지 않고서는 너무나도 많은 에러 발생 상황이 나타났기 때문이다.
애초에 계획을 세우며 흐름을 정리했다면 처음부터 작업의 단위를 나누어 시작했을 것이고 수많은 코드 수정을 하는 일은 없었을 것이다.

2. 작업 단위는 Feature가 되어야하며 최대한 작은 단위로 구성하여 테스트 및 커밋 기록을 남기기 쉽도록 하자

본 프로젝트에서는 각 Feature 단위가 아닌 시스템 계층별로 작업을 하였다.
https://www.popit.kr/개발을-여러-층의-케익으로-나누기/
위의 글에서 설명하듯이 해당 방법이 잘못된 것은 아니지만 테스트와 작업 내역을 기록(Git Commit)을 하는 것에 있어 완벽히 분리가 되지 않아 어려움이 있었다.
계층별로 작업을 하기 위해서는 개발 계획이 완벽하게 문서화되어 있어야하는데 그렇지도 않았기 때문에 많은 시간을 소요했던 것 같다.

3. 작업 현황 일지를 작성하자

작업 단위로 기록되는 Commit 내역과 별개로 하루에 진행한 작업의 양을 적는 것이다.
학기 중에 사이드 프로젝트를 진행하다보니 과제나 시험 등 다양한 이유로 작업에 공백이 생겼다. 그러나 작업 일지를 기록하지 않아 작업의 공백이 파악이 어려웠고 자꾸만 공백이 이어졌다.
프로젝트 후반부에 많은 시간을 한 번에 쏟고서야 겨우 마무리를 할 수 있었는데 이를 반복하지 않기 위해서는 개발 계획과 작업 현황을 비교하며 작업량을 맞춰가는 것이 중요한 것 같다.

2. 팀원의 이탈

팀원 중 디자이너 분이 프로젝트 중후반에 이탈을 하는 일이 발생했다. 따라서 디자인 수정, 아이콘 작업, 배포용 미리보기 화면 등을 직접 처리하게 되었다.

문제의 원인

  1. 초반부에 집중된 디자인 작업
  2. 개인 개발 작업으로 인해 전반적인 프로젝트 진행 관리 소홀
  3. 팀 단위 규칙적인 소통 부재

해결책

1. 정기적인 피드백을 통해 각자의 결과물을 점검할 것

정기적인 피드백을 하지 않았던 것은 아니다. 다만 개발을 착수하면서는 이미 완성된 디자인을 기반으로 작업을 하는 것에 급급하여 개발 결과물의 피드백에만 집중을 하는 경향이 있었다.
컨셉 디자인이나 아이콘 등은 당장 필요한 중요한 작업물이 아니라는 생각에, 디자인 작업이 지연되더라도 크게 신경을 쓰지 않았고 이는 곧 매너리즘으로 이어졌다.

2. 작업 현황을 공유할 것

작업 현황 일지의 작성과 같은 이유이다. 서로의 작업 현황에 대해 신경을 쓰기 어려우므로 각자 진행 상황을 공유하며 작업량을 맞춰가는 것이 중요한 것 같다.

3. 에자일 방식을 통해 작업량을 맞출 것

이번 프로젝트에서는 개발에 필요한 디자인이 모두 완성이 되고 개발에 착수를 하였다. 그렇게 개발에 착수한 후에는 디자인 작업에 대한 필요도와 관심이 줄어서 더 이상 디자인의 발전은 없었다. 작업 단위를 같이 나누어 에자일 방식으로 작업을 해나갔다면 필요에 의해서라도 작업량을 맞춰가며 진행했을 것 같다.

profile
아이디어를 세상에 꽃 피워보기

0개의 댓글