프로젝트 소개
- 프로젝트 인원: 1인 개발(iOS 1명)
- 개발기간: 2024. 3. 8 ~ 2024. 3. 21(총 2주)
- 프로젝트: 신체적 어려움을 겪고 계신 분들을 위한 여행 정보 제공 서비스
- 기술 스택
- UI: CodeBased UI, Snapkit, Floating Panel, TTGTags, Toast-Swift, Accordion UI
- 네트워크: Alamofire, Kingfihser
- DB: RealmSwift
- Configuration: Firebase Crashlytics, Firebase Analytics
기획
이 단계에서 가장 어려움을 많이 겪었던 것 같다. 정해진 기간(약 4일) 내 주제를 선정하고 어떻게 UI 및 DB를 설계해야 했고, 무엇보다도 혼자 스스로 처음부터 끝까지 책임지고 차별점까지 이끌어 내야 한다는 부담감이 밀려왔다.
그래서 하루에 걸쳐 기획안을 만들어 멘토님들께 검토를 받았다. 하지만 안타깝게도 내 생각해 내었던 기획안은 기존 이전 기수들이나 여타 다른 흔히 접할 수 있는 주제였기에 포트폴리오로 활용되기엔 차별성이 떨어진다는 피드백을 받았다. 그래서 그날부터 하루동안 공공데이터포털 사이트를 돌아다니면서 주제 선정에 온 힘을 쏟아붓고, 마감일 하루 전 UI 및 DB 설계를 마친 다음, 멘토님들께 주제에 대한 재심사를 받은 후에야 개발을 시작할 수 있었다.
설계
워낙 똥손이고 디자인 감각이 없다보니 어디서부터 어떻게 디자인을 시작해야 할지 막막했었다. 그래서 일단 래퍼런스라도 많이 찾아보자 하는 마음으로 앱 스토어에서 여행 관련 앱들을 왕창 다운로드하여 디자인을 하나하나 살펴보기 시작하였다.
- 피그마(UI)
살펴보았던 앱들은 대한민국 구석구석, 무장애 남구 BF, 마이리얼트립, 데이트립, VISITSEOUL, 광안리앤, 스마트도슨트 등 이 있었다.
이 앱들의 공통점 살펴보니 여행 앱이다보니 해당 여행지에 대한 이미지 사이즈를 크게 만들고, 그 하단에 그 여행지에 대한 항목들을 나열하는 식으로 구성되어 있다는 사실을 발견하였다.
그래서 피그마에서 여행지에 대한 상세화면 UI를 디자인할 때 그 여행지 이미지를 가장 상단에 배치하고 그 여행지에 대한 설명 및 그곳에서 제공하는 서비스들을 나열하는 식으로 구성하였다.
더구나 여행지 소개가 주제인만큼 지도를 기반으로 제작하면 좋겠다는 생각이 들어 여타 지도로 유명한, 구글 지도, 애프 지도, 카카도 지도 등을 참고하여 메인화면을 구성하기도 하였다.
- DB 설계
DB 부분은 MySQL, MongoDB, MariaDB 와 같은 외부 DB를 사용하지 않고, Realm만 사용하여 구성하였다.(왜냐하면 그게 구현제한 조건이었기 때문이었다.)
그리고 기획단걔에서 UI 디자인 부분에 좀 더 중점을 두다보니 DB 설계에는 비중을 두지 못하였다. 추후 추가적인 기획을 통해 DB 사용 비중을 점차 늘려나갈 예정이다.
개발
- 앱 구조
개발을 시작하기 앞서 내가 가장 중점을 둔 점은 앱의 전제척인 구조였다. 왜냐하면 내가 가장 코드를 작성할 때 가장 중요시하는 부분이 언제든 다시 코드를 보러 돌아왔을 때 앱의 구조가 한눈에 파악되는지이기 때문이다. 그래서 처음에 앱의 구조 설계할 때 프로토콜을 기반으로 구조를 규격화하여 앱을 설계했다.
내가 직접 구성했던 코드 예로 한번 설명해보겠다.
protocol UIViewControllerConfiguration {
func configureNavigationBar()
func configureConstraints()
func configureUI()
func bindings()
}
위 코드 스니핏처럼 UIViewController를 구성할 때 일반적으로 사용되는 요소들이 있다. 이 요소들을 프로토콜로 규격화하여 UIViewController를 선언할 때 이 규격화한 프로토콜을 UIViewController에 채택시키면 이후 다시 코드를 살펴보러 돌아왔을 때 해당 UIViewController가 어떻게 구성되었었는지 한눈에 알 수 있다.
더불어 View으로부터 비지니스 로직을 독립시키기 위해 앱의 전체적인 구조를 MVVM으로 구성하였다.
- 아코디언 UI
이번 출시 프로젝트르 구성하면서 가장 난이도가 높았던 UI는 바로 아코디언식으로 UI를 구성하는 것이었다.
이에 대한 구현방법은 이전에 포스팅해두었다.
- ATS(App Transport Security) 오류
공공데이터를 활용하다 보니 아래와 같은 오류가 발생하였다.
sessionTaskFailed(error: Error Domain=NSURLErrorDomain Code=-1200 "An SSL error has occurred and a secure connection to the server cannot be made."
아무래도 공공데이터포털에 있는 API들 중 일부가 HTTP로 통신되는 것들이 있다 보니 HTTPS를 기본 네트워크 통신 기준으로 삼고 있는 애플 플랫폼에서는 달가운 입장은 아니었던 것 같다.
위 오류 내용을 구글에 검색해 보면 공통적으로 등장하는 단어가 ATS인데 이에 대한 설명은 또 다른 이전 포스트에서 다루었다.
- Firebase Analytics
앱의 사용성에 대해 실시간 분석을 위해 Firebase Analytics를 연결하였는데 잘 작동하지 않는 오류가 발생했었다.
분명 문서를 보고 잘 설정하였다고 생각했는데 원하는 대로 동작하지 않아 순간 당황했었다.
결국 구글 리서치 중 Firebase의 공식 깃허브 리드미에서 그 해결책을 찾을 수 있었다.
문제의 원인은 Xcode의 앱 target에서 Building Settings 탭 부분으로 가서 항목들 중 Other Linker Flags 항목이 있는데 이 부분에 -ObjC 플래그를 추가하지 않아서 발생하던 것이었다.
이를 계기로 공식 문서가 항상 최신화되어 있는 것이 아니라는 사실을 깨달았다.
- 배포 후 리젝 사유
개인적인 앱에 대한 배포를 처음 하다 보니 처음 위와 같은 리젝 사유를 받았을 땐 순간 몹시 당황스러웠다.
하지만 하나씩 차근차근 내용을 살펴보니 '유저가 권한을 거부했을 때에 대한 처리 미흡에 관한 리젝' 과 '권한 요청 문구를 상세하게 작성되지 않은 것에 대한 리젝' 에 관한 내용이었다.
그래서 각각에 대해 신속히 대응한 뒤 다시 재심사를 넣었다.
배운 점 / 느낀 점
처음으로 기획부터 배포까지 혼자서 해내다니 개인적으로 너무 뿌듯했다. 앞으로 누가 기획부터 다시 시작하라고 한다면 흠칫하겠지만 처음 마주했을 때보단 더 담담한 마음으로 작업에 착수할 수 있을 것 같다.
- 서로 도움주는 팀원들
물론 전반적인 과정을 개별과정이었지만 수강 중인 과정에서 과제 초기 단계에서 멘토님들께서 서로 각자 프로젝트 진행 중 발생한 이슈들을 공유하고 이에 대해 함께 해결하고자 팀을 구성해 주셨다. 그래서 매일 수업 종료 후, 서로 개발 진행 상황에 대해 공유하고, 개발 중 이슈 상황이 발생하면 JANDI를 통해 서로 해결방안을 모색하였다. 과정 입학 전 출시를 경험해 본 분들도 계셨어서 보다 수월하게 앱 개발을 배포까지 마무리 지을 수 있었던 것 같다.
- 성장이란
개발하면서 중간에 막히는 부분도 있었지만 문제를 해결하기 위해 고민하고 찾아보는 과정에서 나 스스로도 성장하고 있다는 게 느껴졌다. 아직은 부족하지만 이전보다 더 구조를 고민하며 코드를 작성하려고 했고, MVVM, Observable에 대한 기본 개념도 더 명확하게 익힐 수 있는 계기가 되었던 것 같다.
- 아쉬운 리팩토링
그럼에도 불구하고 코드와 구조가 마음에 들지 않는 부분이 존재한다. 특히 개발 후반으로 갈수록 기간이 쫓기어 오로지 기능이 동작되게만 하는데 매몰되어 깔끔한 코드와 구조에서 멀어져 갔다. 바꾸고 싶은 부분들이 여전히 존재하지만 먼저 개발한 부분과 연결되어 있어서 고치기가 힘들기도 했다. 앱을 처음 설계 단계부터 보다 더 잘 설계하거나 아키텍처나 클린 코드에 대한 것을 더 공부해서 깔끔하게 구조와 코드를 작성할 수 있도록 해야겠다는 생각이 들었다.
아쉬운 점
- 누락된 기능들
마감일에 쫓기다 보니 사실 본래 기획했던 기능들보다 현저히 축소하여 정말 MVP(Minimum Viable Product)만 제작하여 앱을 배포하였다. 앱 개발에 있어 익숙하지 않은 개념들과 이를 적용해야 하는 숙련도가 미숙하다 보니 기능별로 개발할 때, 처음 생각했었던 개발 시간이 약간 차이가 나는 현상이 자주 나타났다. 누락되었던 기능들에 대해선 추후 업데이트를 통해 앱에 추가해 나갈 생각이다.
- 테스트 코드
버그 없는 앱은 없다지만 적어도 어느 정도 안정성이 보장하지 못한 채 앱을 출시했다는 사실이 너무 아쉬움이 남았다. 물론 개인적으로 예상되는 버그들에 대해선 대부분 대응하고 출시하긴 했지만 추후 기능이 추가될 때마다 필수불가결하게 새로운 버그들이 창출될 것이 분명하기 때문에 기존에 잘 동작하였던 기능들에 대해서 애초부터 테스트 코드를 작성하여 안정성을 보장해 줄 수 있다면 유지보수 측면에서 더할 나위 없이 더 개선될 것이라고 생각되었다. 추후 진행할 프로젝트에 대해선 테스트 코드 도입에 대해 한번 고려해 보아야겠다는 생각이 들었다.
'회고' 카테고리의 다른 글
[회고] 2024년 11월 4일(월) (0) | 2024.11.04 |
---|---|
[회고] 2024년 11월 3일(일) (0) | 2024.11.02 |