DUNA PORTFOLIO

애니또

2022.05 - 현재

팀 구성:

iOS 4명 ⎻ 디자인 2명 ⎻ 서버 2명 ⎻ 기획 (모든 팀원)

본인 역할:

iOS 앱 개발(35%), iOS 파트 리드, 기획, 디자인

마니또 방을 생성하고 방 참여 코드를 통해서 다른 유저와 함께 마니또를 즐길 수 있는 iOS 애플리케이션입니다. 개별 미션, 쪽지함 기능 등을 통해 오프라인뿐만 아니라 온라인에서도 마니또를 진행할 수 있습니다.

사용 기술

UIKit

UI 컴포넌트로 화면 UI 구성 및 Codebase 형식으로 AutoLayout 설정

URLSession

REST API 통신을 위한 기본 코드 작성

Combine

비동기적인 이벤트 처리

Github Action

Release note 작성 자동화 로직

라이브러리(Swift Package Manager)

SnapKit

Codebase 형식으로 간단하게 AutoLayout 코드를 작성할 수 있도록 도와줌

Gifu

Gif 이미지 다운로드 및 캐싱 API 제공

MTNetwork

HTTP 요청, 응답 바디 형식을 체계적으로 정리한 커스텀 네트워킹 라이브러리

Firebase

Messaging API로 푸시 알림 받는 코드 작성

본인 개발 내용

⏺ 기존 MVC 아키텍처를 MVVM으로 리팩토링 진행

관심사 분리를 통한 정확한 이슈 확인 시간 단축 → 전체적인 이슈 해결 속도 개선

테스트 코드 작성 가능한 구조로 개선하며 이전보다 안정적인 구조로 유지보수 가능

⏺ Combine Framework를 사용하여 데이터 흐름을 간결하고 이해하기 쉽게 개선

Delegate를 사용하여 비동기적으로 처리하던 방식을 Combine API로 변경하여 데이터의 흐름이 명확해지고, 디버깅하기 좋은 환경으로 개선됨

⏺ 앱 내 리소스 파일을 모듈화한 MTResource 프레임워크 개발

크기가 큰 리소스 파일 분리로 앱 빌드 속도 향상

⏺ URLSession를 사용하여 자체 네트워크 라이브러리(MTNetwork) 개발

MTNetwork API를 사용하여 서버 코드 작성 소요 시간 단축

기본적인 서버 HTTP 요청 및 응답 바디 데이터 형식을 체계적으로 정리

⏺ Github Action을 사용하여 릴리즈 노트 생성 자동화 Workflow 추가

메인 브랜치에 PR이 머지되는 경우, 릴리즈 노트가 자동으로 작성되도록 하여 작성에 드는 시간 단축

⏺ Google Sheet로 앱 내부에 있는 텍스트를 효율적으로 관리할 수 있도록 개선

팀원 모두가 접근할 수 있는 Google Sheet를 사용해서 텍스트를 쉽게 수정하고 관리할 수 있도록 함

프로젝트 빌드 시에 Google Sheet로부터 실시간으로 텍스트를 가져올 수 있도록 개발

⏺ 앱 내 쪽지 화면 제작

CompositionalLayout를 사용하여 CollectionView 레이아웃 구성

상단 SegmentControl을 탭할 시에 데이터 통신이 진행되도록 구현

이미지 영역 터치 시에 다른 화면으로 이동할 수 있도록 구현

서버로 텍스트, 사진 데이터를 포함한 쪽지 데이터 전송 코드 작성(Multipart/form)

쪽지 푸시 알림을 탭할 시에 바로 쪽지 화면으로 이동할 수 있도록 코드 작성

애니또를 통한 성장

지속적인 유지보수

애니또는 팀원들과 함께 성장했던 프로젝트입니다. 릴리즈를 했다는 것에 안주하지 않고 현재까지도 리팩토링하며 지속적인 업데이트를 진행하고 있는 프로젝트입니다. 이는 릴리즈 이후에 QA 작업을 진행하면서 빠른 트러블 슈팅이 가능한 환경, 테스트가 가능한 환경을 구축하는 것의 중요성을 깨달았기 때문입니다.

가장 먼저 테스트 작업이 어려웠던 환경을 개선해보려고 했습니다. 애니또가 채택하고 있던 MVC 패턴을 MVVM 패턴으로 바꾸는 작업을 진행했습니다. Controller 클래스 내부에 섞여있는 UI 관련 로직과 비즈니스 로직을 분리하여 테스트할 수 있는 환경을 만드는 것이 리팩토링 작업의 핵심이었습니다. 비즈니스와 UI 관련 로직이 분리되고 나니 로직의 위치가 뚜렷해져 빠른 트러블 슈팅이 가능했습니다. 하지만, 저희 팀이 ViewModel 내부에 있는 하나의 함수에서 Input 이벤트를 처리하고 Output으로 내보내는 작업을 하고 있었기에 테스트하기엔 적합하지 않다는 생각이 들었습니다.

문제를 해결하기 위해 저희는 Usecase 클래스를 따로 만들어 해당 클래스 내부에 비즈니스 로직을 위치 시켰습니다. Usecase는 프로토콜을 채택했기에 이후에 테스트를 위한 Mock 클래스를 만드는 것도 쉬웠고 ViewModel에서는 Usecase에서 비즈니스 로직을 가져와서 사용하면 되었기에 로직이 훨씬 간단해졌습니다. 무엇보다도 이슈 발생 시에 대응이 굉장히 빨라졌습니다. 비즈니스 로직에서의 문제라면 Usecase 클래스만, UI에서의 문제라면 Controller, View 클래스만 확인하면 되었기에 빠른 트러블 슈팅이 가능해졌습니다.

01. 02 Latest Update