우선, 우여곡절이 많았지만 최종 프로젝트로 개발한 앱 MOUP이 앱스토어에 출시되었다.
MOUP - 모이면 업이 된다
모이면 업이 된다 — MOUP 알바생의 근무 시간, 날짜, 월급을 자동으로 계산하고, 루틴(체크리스트) 기능으로 업무를 더 쉽게 관리할 수 있는 앱입니다. 주요 기능 - 급여 계산 - 일정 관리 - 캘린
apps.apple.com
앱 소개 및 나의 역할
위 섹션에서 볼 수 있듯 모업은 모이면 업이 된다 라는 슬로건을 가지는 앱이다.
알바생이 근무 시간, 날짜, 월급을 입력하고 근무를 등록하면 그에 기반해 급여를 계산할 수 있고 좀 더 나아가 야간 수당 등 어떻게 금액이 적용되어있는지 완벽하진 않지만 어느정도 확인이 가능하다. (주휴 수당 등 각종 포인트까지 고려하기엔 너무 스코프가 넓었다..)
그리고 그 근무들에 대해서 내가 등록해두었던 루틴(체크리스트)을 넣어두어 후에 확인하며 근무할 수 있도록 기획 및 구현했다.
이런 어플을 만들게 된 계기는 주제 브레인스토밍 중 리더 분께서 알바생들이 쓸 수 있는 어플을 만들면 좋겠다. 혼자 만들려했던 주제다. 라고 말씀하셨고 좀 더 들어보니 내가 알바했던 시기 초에 메모장 안에 할 일을 적어두고 봐가면서 하는 과정이 번거로웠는데 이 어플의 루틴 기능이라는 게 상당히 매력적으로 다가왔다.
프로젝트 기간은 5월 29일부터 7월 7일까지 잡혔고, 내 역할은 알바생과 사장님의 급여 혹은 인건비를 확인할 수 있는 화면인 홈 화면과 기존 등록해두었던 루틴 관련 작업을 할 수 있으며 오늘 루틴이 무엇이 있는지 확인할 수 있는 루틴 관리였다.
프로젝트를 진행하며 겪었던 시행 착오
많은 우여곡절이 있었지만, 홈 화면에서는 셀을 누르면 해당 셀이 펼쳐지며 그 급여가 어떻게 나오게 되었는지 알 수 있어야 했다.
따라서 셀을 펼쳐 준비되어있는 데이터에 대한 시각화를 구현할 방법을 찾아 많은 시도를 했다.
1. UICollectionView를 쓰며 내부 요소를 isHidden을 통해 관리
2. UITableView의 automaticDimension 기능을 써 위처럼 isHidden을 통해 동적 높이 관리
크게 보았을 땐 이런 방법들을 시도해보았는데, 당시 시간이 없어 트러블슈팅으로 과정을 기록해두었어야 했는데 아쉽다.
결국 2번 방법인 UITableView의 동적 높이 계산을 이용한 방법을 사용했다.
이 시행착오는 화면을 그리는 과정을 좀 더 세밀하게 지켜볼 수 있게 해줬던 것 같아서 좋았다.
애니메이션이 완벽하진 않지만 계속 시도해서 결국 해냈던 게 스스로 잘한 부분 중 하나였다고 생각한다.
두 번째로 앞선 부분과 관련된 점인데, 해당 셀 내에 들어갈 데이터를 유즈케이스로부터 데이터를 받아와 가공해 넣어주어야 했다.
이 과정이 이번 프로젝트에서 가장 어려웠던 부분이었다.. 좀 많이 몰려있었던 시간이었다.
우리 앱은 우선 알바생과 사장의 역할에 기반한 기능을 둘 다 구현해야 했다.
알바생들은 본인의 근무지에 연동했던 근무들에 대한 총 급여를, 사장님들은 본인이 관리하는 매장에서 일하는 근무자들의 인건비를 보여줄 수 있어야 했는데..
전자는 알바생들이 일하는 근무지들을 받아오는 유즈케이스, 그 근무지에 대해 함께 설정했던 년, 월에 본인이 일했던 기록을 가져오는 유즈케이스. 해당 유즈케이스들을 가지고 근무지들마다 내역을 하나씩 파고들어 근무 시작, 종료 시간을 통해 근무 시간을 계산하고 기존에 체크했던 야간 수당 여부 혹은 4대 보험 등 근무 조건에 맞춰 급여를 계산해야 했다.
후자는 관리하는 매장들을 받아오는 유즈케이스, 그 매장들에서 일하는 근무자들을 불러오는 유즈케이스, 그 매장의 근무 요약을 받아올 수 있는 유즈케이스를 사용해야 했다. 해당 유즈케이스들을 통해 근무 내역마다 그 근무자와 id가 일치한지 검사하면서 인건비를 계산해야 했다. 앞선 과정 속에서 일치하는 데이터들을 찾고 별도로 정리하는 과정이 많이 어려웠다.
결국 로직을 어느정도 생각해두고 ai를 통해 검증 및 보완해 나가는 방식을 택했고, 본래 생각하던 로직의 코드를 짜다가 너무 비효율적이라고 생각되는 부분들에 대해 ai가 조언해주면 이를 반영해 전체적인 구조를 잡는 과정을 가졌다.
기존엔 AI를 많이 쓰다보니 무작정 신뢰하기보단 선생님 대안으로 사용을 해왔지만 스스로 해나가는 과정에 도움이 되지않을까 싶어 나의 방식에 불신이 있었는데 어느정도 쓸 수 있어야겠구나라는 결론이 내려졌다.
그러나 구현을 전부 마치고 나니 해당 홈뷰모델의 라인 수가 760줄이었다. 구현하면서도 이게 맞나 싶었고, 후에 유지보수가 힘들 것 같다는 생각이 앞섰다. 가장 크게 들었던 생각은 ViewModel의 책임이 너무 무거워지는 것에 대한 보완을 해주는게 클린아키텍처의 사용 요인 중 하나라는 생각이었는데 지금 코드로선 꽤 높은 비율의 비즈니스 로직이 여전히 ViewModel에서 구현되고 있어 이 방식은 잘못되었다라는 결론이 나왔다(본래 비즈니스 로직은 ViewModel에서 알면 안된다...).
후에 리팩토링 시 UseCase로 비즈니스 로직들을 분리할 예정이다.
아쉬운 점 & 시도해볼 점
앞에서도 물론 UseCase로 비즈니스 로직을 분리한다는 내용이 있었는데, 그 외에도 시간에 쫓겨 챙기지 못한 디테일한 부분이 많았다.
우선 앱 내 의존성을 통틀어 관리해야할 필요가 있어서 메모해두었으나 하지 못했던 DIContainer. 해당 부분을 구현해야 할 것 같고, 여유가 된다면 Coordinator 패턴도 공부해서 적용해보고 싶다. 다만, 우리 어플의 경우 화면 이동이 복잡한지 다시 생각해보고 오버 엔지니어링의 여지가 있을지에 대해서도 고민해보면 좋을 것 같다.
그리고 버전 2를 아예 새로 다시 만들 예정에 있는데, 그 전에 현 버전에서 내 파트에 대한 버그가 한 두개 있다. 해당 버그들을 고칠 필요가 있겠다.
AI에 대한 의존도를 줄여야하나 고민을 많이 했는데 역시 이번에도 결국 공존하는 방식으로 스스로 진행이 되었다. 계속 이렇게 학습해나가며 나만의 근본을 닦아야 한다는 생각이 들었다.
이건 좀 좋았던 점이긴 하나 아쉬움이 남았던 부분인데, MARK 주석 같은 기능을 상당히 좋게 활용할 수 있었다. 다만, 이런 기능을 적용해가면서 구현해본 적이 처음이라 해당 주석에 대한 정리가 깔끔하지 못한 경우가 있다. 이런 부분들을 최적화할 수 있으면 타인이 내 코드를 본다고 해도 읽기 쉬운 좋은 코드가 되지않을까한다.
관련되어 좀 더 나아가면, 팀적으로 시간이 매우 촉박해 코드 리뷰가 굉장히 소홀했는데 앞으론 더 꼼꼼히 코드리뷰를 진행해볼 예정이다.
소감
이번 프로젝트는 내가 개발을 한다는 스코프를 넘어 어느 프로덕트를 만들 때 어떤 가치들을 중요하게 생각하느냐에 대한 성찰을 할 수 있게 해준 좋은 기회였다.
나는 확실히 사용성 좋고 앱 컨셉과 맞으면서 UI/UX적으로 치밀하게 고려된 디자인이 반영된 앱을 만드는게 가장 큰 가치라고 생각하는 것 을 알게 되었다.
앱을 만들면서도 어느 순간 어느 부분이 UX적으로 감점 요소가 될 수 있지 않을까라는 고민을 많이 했으며, 아무리 좋은 코드를 쓴다고 한들 그 어플이 이목을 끌지 않고 사용해도 불편해서 누구도 사용하지 않으면 무슨 소용이 있겠나라는 생각을 했다.
재밌는 점은, 이런 가치들을 잘 따라가 높은 퀄리티로 프로젝트를 구현하기 위해선 위에서 말한 좋은 코드가 뒷받침되어주어야 하는 것도 어느정도 맞는 말이라는 것이다. 결국,, 다 잘해야 한다...!
코딩 실력에 있어서 성장했냐고 하면 조금은 성장했지만, 무엇보다 이 치열한 출시를 위한 과정 속 수 많은 인내를 포함한 다양한 부분들이 가장 이 프로젝트가 값졌다고 말할 수 있게 하는 점들이 아닐까 생각해본다.
앞으로 새 버전을 위해 싹 다시 갈아엎고 만들텐데 그 때 다시 한번 회고를 해보며 현재 프로젝트와 비교를 해보면 좋겠다.
아 늦은 시간에 쓰다보니 정신이 없어서 두서도 없어진 것 같다.. 여튼 나 고생 많았고 완주까지 함께해준 팀원들에게 진심으로 감사의 말씀 올립니다 /(_ _)\