[회고] 북트립 AppStore 출시 회고

내 인생 첫 출시앱 .. (아직도 볼 때마다 신기하다 ㅎ)

개발 소요 기간 : 22.09.13 - 22.09.29 (약 16일)

사용한 라이브러리 ( 총 9개 )
- Alamofire
- FSCalendar
- IQKeyboardManager
- KingFisher
- Mantis
- Realm
- Snapkit
- SwiftyJSON
- Toast

맡은 역할
- 기획 / 디자인 / 개발 모두

기획 단계

이번 출시 프로젝트에서 하고 싶었던 아이디어가 생각보다 많았는데, 그중에서도 내가 정말로 평소에 불편함을 느끼고 이를 해결하고 싶었던 문제를 앱의 주제로 삼는 것이 좋겠다는 생각이 들어서 이전부터 꼭 앱으로 만들고 싶었던 독립서점 큐레이팅 앱을 만들어야겠다는 생각이 들어 북트립을 기획하게 되었다. 그래서 일단 기획 단계에서는, 지도 기반으로 가장 다양한 독립서점을 큐레이팅 하는 방식으로 만들어야겠다고 생각해서 지도 기반의 기능 위주로 기획을 했다. 그리고 일단 출시 프로젝트 기간동안 내가 어느 정도까지 기능을 구현할 수 있을지 감이 잡히지 않아서 가장 최소한의 기능 위주로 기획서를 만들었는데, 역시나 기능이 출시 프로젝트 기간 대비 부족하다는 피드백을 들었다. 그래서 멘토님과 상의를 해서, 사용자가 독립서점을 방문해서 관련된 방문 기록을 남길 수 있는 기능을 추가하기로 결정했다. 이런 일련의 과정을 겪으면서, 기획이라는 과정에서는 시간 안에 낼 수 있는 나의 능력을 잘 판단하는 것이 중요하다는 생각이 들었다. 출시 프로젝트를 진행하기 전에는 이런 규모있는 프로젝트를 진행한 경험이 적다보니, 나의 능력에 대한 인지 능력이 많이 부족했다는 생각이 든다.

개발 단계

처음 개발을 시작하면서 맞닥뜨린 문제는 독립서점의 이름을 Naver Place API 를 사용해서 검색한 후, JSON 데이터를 사용자에게 표현하고자 했었는데, 생각보다 Place API 에서 나오는 정보가 한정적이라 이 API를 사용하기 어렵게 되었던 문제였다. 처음에는 단순히 '오, Place API를 사용하면 네이버에서 검색했을 때 나오는 장소에 대한 모든 정보가 그대로 나오겠지?' 라고 생각하고, 기획단계에서 API에 대한 정보를 자세히 찾지 않아 개발 단계에서 많은 시간을 허비했던 경험이 있다. 이를 통해, 기획 단계에서 사용하고자 하는 API 에 대해 자세히 알아본 후에 사용하고자 하는 목적과 API의 적합성을 비교하는 과정이 선행되어야 한다는 사실을 깨달았다. 그리고 기획이 탄탄하지 않으면, 개발 단계에서 크고 작은 시간을 허비하게 되어 전체적인 효율성이 저해된다는 것을 몸소 깨달았기에 다음 프로젝트에서는 기획을 좀 더 구체적이게 짜야겠다는 생각이 들었다. 다음은 북트립 개발을 진행하면서 다른 것에 비해 조금 더 오래 고민하게 되었던 문제를 소개해보고자 한다.

1) API를 사용하지 않고, 어떻게 JSON 데이터를 만들 것인가?

일단 내가 선택한 방법은 내가 지도에 표시하고자 하는 독립서점에 대한 정보(독립서점명, 주소, 링크, 경도, 위도, 운영시간)를 JSON 형식으로 적어주고, JSON 데이터의 Key 값과 동일한 구조체를 만들어준 후에 그 변수의 값에 따라 Value 값을 파싱해주는 방법을 선택했다. 여기서 중요한 점은 JSON Data의 Key 값은 구조체의 멤버 이름과 일대일 매칭을 해주어야만 문제없이 사용할 수 있기 때문에, 오타를 조심해야 한다. 반점을 적지 않는다거나, 오타가 난다거나 그러면 오류파티가 열린다.. 그렇다 항상 손꾸락이 문제였다 ..


2) 사용자가 이미지를 올리고자 할 때, 어떤 방식으로 용량을 처리할 것인가? 만약 사용자가 100개의 이미지를 저장하고자 한다면?

사용자가 독립서점에서 찍은 사진을 저장하고자 할 때, 이미지 용량을 처리해주지 않는다면 앱의 용량이 어마어마해진다. 특히 요즘같이 카메라 화질이 좋은 세상에서는 사진 하나당 용량이 크기 때문에 꼭 이미지 용량 처리를 해주어야만 했다. 그래서 어떤 방식으로 이미지 용량을 처리해줄지 고민하다가, image resize 방법으로 용량을 처리해주기로 했다. 이는 파라미터로 새롭게 적용할 가로길이를 받아서 원본이미지와 비율을 비교해서 세로 길이도 적용해시켜주는 방법이고 UIGraphicsImageRenderer객체를 생성해준 후에 image()함수를 통해서 이미지에 접근해서 원하는 작업을 한 후 반환해주면 되는 생각보다 간단한 방법이었다. 하지만 render.image 부분과 draw 부분이 많은 CPU를 사용하게 되어, 이러한 고용량 이미지가 쌓이다보면 앱이 터질 수 있는 불상사가 발생할 수도 있다고 하니 이 부분은 추후 개선해나가야 할 것 같다.

3) 한 화면 내 같은 버튼으로 서로 다른 동작을 처리하고자 한다면 어떻게 기능을 구현해야 할까?

이 문제는 진짜 생각보다 간단한 문제였는데, '같은 Button에 다른 Action을 지정할 수 있을까?'라는 문제에 꽂혀서 도저히 어떻게 해결해야할지 감이 잡히지 않았었다. 내가 이 문제를 경험했던 부분은 수정화면에서 였는데, 캘린더탭에서 날짜를 클릭한 후에 나오는 수정화면 내의 삭제버튼과 포토탭을 클릭한 후에 포토카드를 클릭했을 때 나오는 수정화면 내의 삭제버튼이 서로 다르게 동작해야만 했다. 왜냐하면 캘린더에서는 Realm 이 선택한 날짜 기준으로 필터링이 되어있기 때문에 이를 기준으로 indexPath를 사용해 삭제해야 했고, 포토탭에서는 전체 Realm 을 날짜가 빠르고 같은 날짜 안에서도 최근에 등록된 순으로 Sort를 한 후에 indexPath를 사용해 삭제해야했기 때문에 이를 분리해서 Button Action을 지정해주어야 했다. 처음에는 이를 고려하지 않아서 계속 Realm Exception 오류가 발생했는데, 차근차근 각 탭마다 어떤 task를 사용해야 하는지 생각해보는 과정을 통해서 이 부분에 대한 처리가 필요하다는 판단이 들었다. 그래서 최종적으로는 UserDefaults를 활용해, 캘린더탭을 클릭했을 때를 false 로 지정하고 포토탭을 클릭했을 때는 true로 지정해 이에 따른 분기처리를 해주어 해결했다. 정말 생각보다 쉬운 문제였는데, 같은 Realm을 탭마다 다르게 filtering 하고 sort하는 과정에서 머리가 복잡해져 생각보다 이 문제를 해결하는 데 많은 시간이 소요되었던 것 같다.


4) 왜 실시간 나의 위치를 클릭하면 (파란점) 앱이 꺼질까?

지도 기능을 다 구현한 후에 버그가 있는지 살펴보다가, 다른 Annotation을 클릭하면 괜찮은데, 실시간 나의 위치를 클릭하면 앱이 꺼지는 오류를 발견했다. (왜 안돼..!) 그래서 이부분에 대해서 멘토님께 여쭤보니, 강제해제연산자를 사용하지 말고 옵셔널 바인딩 처리가 따로 필요할 거 같다고 말씀해주셨다. as? 는 "런타임 시점"에 다운 캐스팅을 하고 실패할 경우 nil을 return 하지만, as!는 "런타임 시점"에 다운 캐스팅을 하고 실패할 경우 에러가 발생하기 때문에 앱이 꺼지는 것이었다. 그래서 이 부분은 안전하게 guard let 으로 옵셔널 바인딩 처리를 해주고 as! 가 아닌 as?를 사용함으로써, 오류가 해결되었었다.


5) tmp 파일은 어떤 파일인가?

디바이스에 이미지가 잘 저장되고 있는지 확인해보기 위해 Download Container 를 통해 이미지 용량을 확인하는 과정에서 tmp 라는 파일을 마주하게 되었다. 왜냐하면 내가 저장하고 있는 이미지의 용량에 비해 데이터의 용량이 엄청 컸기 때문이다. 이 파일에는 내가 저장하고 있는 원본 이미지 파일이 그대로 올라가고 있어서 전체 데이터 용량이 어마무시하게 커졌던 것이다. 그래서 이 파일의 용도가 굉장히 궁금해졌다. 이 부분에 대해서 멘토님께 여쭤보니, tmp 파일은 시스템에서 관리하는 임시 파일들이라 시간이 지나면 제거되거나, 혹은 KingFisher 에서 캐싱관리를 하고 있을 거라고 말씀해주셨다. 또 혹시 신경쓰이면 이 파일을 정기적으로 제거해도 괜찮다고 하셨다. 나는 이 부분이 굉장히 신경쓰였기 때문에, tmp 파일을 제거할 수 있는 방법을 찾아보았다.

사실 아직까지도 코드에 대한 이해가 완벽하진 않지만, FileManager Extension을 통해 Appdelegate 에서 앱이 실행될 때마다 위 함수를 실행시켜 정기적으로 tmp 파일을 제거할 수 있다는 걸 알게 되었다.

리젝

첫 출시를 하고 기대되는 마음으로 기다리고 있었는데, 리젝이 되었다는 알림이 왔다. 그렇게 수도 없이 봤던 권한 문구에 관련된 리젝.. 사실 피리스트 파일에 문구 쓸 때도 너무 간단한가 라는 생각이 들긴 했는데 다른 앱의 사진 권한 허용 문구도 이렇게 쓰길래 ('사진을 첨부하기 위해서 권한 허용이 필요합니다') 이렇게 써도 되겠구나 라는 안일한 생각이 화를 부른 거 같다는 생각이 들었다. 그래서 리젝 알림을 보고 바로 권한 문구를 최대한 구체적으로 바꿔서 재심사를 넣었고 바로 다음날에 통과되었다고 통지가 왔다. 이번 리젝을 통해서 다시 한 번 권한 문구는 최대한 구체적이고 자세하게 쓰는 것이 중요하구나를 인지하게 되었다.

앞으로 업데이트 해야 할 부분

원래 지금 구현된 것보다 조금 더 디테일한 부분까지 완성도있게 해서 출시를 하고 싶었는데, 생각보다 시간이 빡빡하고 마지막에 버그를 잡는데에 대부분의 시간을 투자해서 일단 전체적인 기능이 오류없이 동작하는 것까지 확인하고 출시를 하게 되었던 것 같다. (나머지는 미래의 내가 수고하겠지..) 그래서 앞으로 남은 업데이트는 지금까지 받은 피드백과 시간이 부족해서 구현하지 못한 디테일한 기능들을 구현하는 데에 집중하고자 한다.

- 포토탭에 하나의 Cell만 정중앙에 보이도록 만들기

원래 CollectionViewCell을 넘길 때 화면 정중앙에 Cell을 하나씩만 보이게 만들고 싶었는데, 시간도 부족하고 어떻게 해야할지 감이 잘 잡히지 않아서 우선은 최대한 중앙에 보이도록 만들긴 했지만 주변 지인들로부터 화면 중앙에 포토카드가 보였으면 좋겠다는 피드백을 들어서 이 부분에 대한 레이아웃을 어떻게 잡아야 할지 좀 더 고민해보는 시간이 필요할 것 같다는 생각이 든다.

- 포토카드를 한 번에 모아서 볼 수 있는 기능

위와 같은 피드백을 주신 분도 있는가 하면, 사진을 넘기는 방식이 아닌 한 화면에 다 모아서 볼 수도 있으면 좋겠다는 피드백을 주신 분도 계셨다. 그래서 포토카드를 다양한 방식으로 보일 수 있도록 기능을 다양화할 수 있도록 업데이트를 해볼 것이다.

- 포토탭에 대한 Tutorial 필요

시간이 부족해서 캘린더탭과는 달리 포토탭에는 따로 Tutorial을 작성하지 않았는데, 이 부분에 대한 피드백이 들어와서 이 부분도 추후 업데이트 때 추가할 예정이다. 포토탭을 처음 들어갔을 때, 빈 화면이 나오는데 사용자 관점에서 이 탭은 어떤 탭인지 인지하기 어렵다고 한다. 따라서 이 부분에 대한 추가적인 Tutorial 이 필요할 것 같다는 판단이 들어 이 부분도 추후에 업데이트를 해볼 예정이다.

- 백업 / 복구 기능

느낀 점

이번 출시 프로젝트를 진행하면서, AppStore에 출시까지의 일련의 과정을 경험해 볼 수 있었고 오류를 해결하는 능력을 많이 키울 수 있었던 것 같다. 처음 앱 출시를 진행하다 보니, 돌아보면 미숙했던 부분도 많고 다시 돌아가면 더 잘할 수 있을 것 같은 부분도 많이 있지만 그래도 그런 시간들이 있었기 때문에 더 많이 성장할 수 있었던 것 같다는 생각이 든다. 16일이라는 기간이 짧은 시간은 아니었던 만큼, 체력적으로 힘든 시간도 있었고 매일이 오류와의 전쟁이었지만 출시하고 AppStore에 내 이름으로 앱이 올라가고 나니 그동안의 힘들었던 것들이 다 날라갈 만큼 뿌듯했던 경험이었던 것 같다. 앞으로는 북트립을 잘 관리해서, 사용자들이 사용하기에 편리한 앱으로 만들어나가고 싶다.

‎북트립