티스토리 뷰

일기

[iOS 앱 개발 외주 회고] 방구석 iOS 개발

Brilliant Bennett 2020. 5. 8. 04:34

프로젝트 요약

기간

2020년 2월 21일 ~ 2020년 4월 30일

내용

  • 식단 관련 SNS iOS 앱 개발
  • 안드로이드 기준 제플린 및 apk를 참고하여 iOS 버전 개발

기능

  • 소셜 로그인 (카카오톡, Apple 로그인)
  • 인스타그램 형식 피드 (게시글 작성, 좋아요, 댓글)
  • Youtube 플레이어 및 외부 링크 웹 브라우징
  • 질문 게시판 (질문 작성, 댓글, 익명)
  • 게시글 컬렉션 뷰
  • 캘린더 뷰

 

클라이언트와 개발자를 연결해주고 PM 역할까지 수행해주는 업체의 소개로 iOS 외주를 진행하였다. iOS 개발 외주는 처음이었기에 우여곡절도 많았고 삽질도 굉장히 많았다.

 

무엇보다 가장 힘들었던 점은 디자인 가이드가 모두 안드로이드 기준이라는 것... 더불어 UI 커스텀이 이렇게 어려운지 새삼 다시 느꼈다.

 

이번 외주를 진행하면서 iOS 개발에 대해 느낀 점, 배운 점, 그리고 다음에 참고할만한 점 등을 정리하며 회고해본다.

 


프로젝트 시작 전

일단 외주를 진행할 때에 개발자와 클라이언트 이외에 PM이 따로 존재한다는 점이 굉장히 큰 메리트였다. 외주를 많이 해본 적도 없고 아직 학생 신분이니 (대학원 휴학생이라는 애매한 신분이긴 하지만) 분쟁이 발생하거나 일정 조율 등에서 문제가 발생할 여지가 비교적 클 것이다. 그러나 PM이 옆에서 일정 및 개발 진행 사항을 조정해주면 이러한 걱정을 덜 수 있었고, 실제로 PM 덕분에 편하게 진행했다.

 

필자의 iOS 개발 경험은 초보자 수준에 가깝다. 지금까지 진행했던 프로젝트나 관심사는 백엔드 개발이며, iOS 개발 경험은 앱스토어 출시도 못한 동영상 가이드 앱과 계량기 앱이 전부다. 심지어 스마트 관광 앱 공모전에 따릉이를 주제로 참가하여 iOS 개발 파트장을 맡았으나 제대로 이끌지 못한 채 흐지부지 되었다. (졸업생 신분과 개발 경험만으로 파트장을 맡았었다...) 그러나 외주는 계약을 하고 업체의 서비스를 만드는 일인 만큼 그 책임감이 막중했기에 이번 프로젝트를 기회로 삼아 iOS 개발을 제대로 시작해보고 싶었다.

 

외주 킥오프 미팅 전, 클라이언트에게 안드로이드 버전 APK 파일을 받았다. 클라이언트 측은 이를 기준으로 삼아 iOS 버전을 개발해달라고 했다. APK 파일을 참고하여 어찌어찌 개발할 수는 있겠지만 이는 명확하지 않은 기능 정의와 서로 다른 OS를 고려하지 않은 기획으로 여러 혼란이 야기될 것 같았다. 그래서 디자인 가이드서버 API 문서를 요구했고 다행히 미팅 때 전달해주시기로 했다. 앞으로 다른 앱 외주를 진행할 때에도 이 두 개는 필수적으로 존재해야 개발자가 힘들지 않을 수 있을 것 같다.

 

(여담으로 원래 네이티브 개발을 좋아했는데 이번 프로젝트를 통해 Flutter나 React Native 등에도 관심이 생겼다.)


프로젝트 초반 (스프린트 1)

받은 디자인 가이드는 안드로이드 기반 제플린이고, API 문서는 노션으로 정리된 파이어베이스 관련 문서였는데 지금 구조와 많이 다른 이전 버전이었다. 이 시기에 저 두 가지를 클라이언트 측에 어필하여 더 편하게 작업할 수도 있었는데 시간적 여유가 많았음에도 이를 어필하지 못한 점이 조금 아쉽다. 앞으로 다른 프로젝트를 맡게 된다면 디자인 가이드API 문서를 중요하게 확인하자.

 

이미 시작했으니 불평만 늘어놓을 수는 없기에 개발을 시작했다. 혼자 프로젝트를 진행하기 때문에 스토리보드를 사용하여 빠르게 UI 작업을 끝내려고 했다. 그러나 이는 큰 오산이었다. UI에 커스텀이 많을수록 스토리보드보다 코드로 작성하는 것이 훨씬 빠르고 편했다. 이를 계기로 스토리보드는 앞으로 건들지 않을 것 같다^^ 혹시나 iOS에 입문한 앱 개발자들이라면 꼭 코드로 UI를 작성하는 법을 배워두길 추천한다. 그래도 Auto Layout 만큼은 이전 iOS 프로젝트에서 사용했던 SnapKit 라이브러리를 사용하여 코드로 작성했기에 조금 수월할 수 있었다.

 

UI 보다 기능 구현에 더 자신이 있었기 때문에 시간이 오래 걸릴 것 같은 전체 UI 작업을 먼저 진행하고 전체 기능을 구현했다. 이 방법에서 딱히 불편함을 느끼진 못했지만 화면 별로 나누어 UI와 기능을 애자일 하게 개발했다면 더 빠르게 작업할 수 있었을지도 모르겠다는 생각이 들긴 한다.


프로젝트 중반 (스프린트 2)

기존 계획으로는 스프린트 1에 UI 작업, 스프린트 2에 기능 구현, 스프린트 3에 검수 및 앱스토어 심사 순으로 작업하려고 했다. 그러나 생각보다 UI 작업 속도도 늦었고 클라이언트 측과 커뮤니케이션도 서로 늦어져서 스프린트 2 역시 UI 작업이 주가 되었다. 여기서 속도를 냈어야 했는데 아쉽게 느껴지는 부분이다.

 

슬랙, 트렐로, 노션 등과 같은 협업 도구를 도입할 경우 구성원들이 쉽게 접근할 수 있도록 장려하는 것이 매니저의 큰 역할 중 하나라는 것을 새삼 느꼈다. 나중에 팀 혹은 회사를 리드할 때에 무작정 좋은 도구를 도입하기보다 구성원들이 잘 활용할 수 있도록 고민해야 한다는 것을 잊지 말아야겠다. (PM님 고생하셨습니다.)

 

해당 스프린트에서 UI 작업 방식을 스토리보드에서 코드로 변경했다. 바꾸고 나니 편리함과 재사용성이 훨씬 좋아졌다. 이때 전수열 님(devxoul)의 Then 라이브러리를 사용하며 컨벤션도 많이 참고했다. iOS 개발에서 정말 많이 배우고 있는 분이며 프로젝트에도 많은 도움을 얻을 수 있었다.

 

카카오톡 소셜 로그인 기능을 구현하다 보니 iOS 쪽의 정보 부족이 절실히 느껴졌다. 예제나 카카오 개발 가이드조차 objective-c로 작성되거나 패키지 매니저 없이 import 하는 방식으로 설명되었다. (내가 못 찾은 걸 지도...) 패키지 매니저 없이 import 하려니 잘 알지 못하는 프로젝트 빌드 옵션을 건드리게 되었고 다른 라이브러리가 오류를 뿜는 경우가 많아 여기서 굉장히 많은 시간을 날렸다. Kakao SDK v2 Beta 버전은 Cocoa Pod으로 설치가 가능했는데 내가 사용했던 다른 라이브러리와 버전이 충돌하여 사용할 수 없었다. 다행히 어떤 글에서 Cocoa Pod으로 Kakao SDK v1을 설치하는 글을 찾아서 간단하게 해결할 수 있었다. 

pod 'KakaoOpenSDK'

위와 같이 Podfile에 적어 Kakao SDK를 사용할 수 있었다.

 

캘린더 역시 내가 직접 커스텀해서 구현하는 것은 외주 단위에서는 조금 무리지 않나 싶었다. 그래서 라이브러리를 찾아보던 중 FSCalendar 가 유명해서 눈에 들어왔다. 다행히 요구사항에 맞는 수준으로는 커스텀이 가능해서 쉽게 구현할 수 있었다.

 

파이어베이스 API 문서를 클라이언트 측에서 최신 버전으로 유지해주시지 않아 직접 파이어베이스 콘솔에서 데이터 구조를 확인하고 작업했다. 또 설계된 파이어베이스 구조에 알 수 없는 필드들이 몇 가지 있어서 곤란했지만 개발에는 지장이 없었기에... 파이어베이스 사용 자체가 처음이었으나 구글의 문서화가 잘되어있어 수월하게 구현할 수 있었다. 다만, 비동기 처리 때문에 골치가 조금 아팠는데 PromiseKit 라이브러리로 비교적 깔끔하게 짤 수 있었다. 그리고 여기서 RxSwift를 공부하고 싶다는 욕구가 폭발했다. 딱 봐도 Rx로 짜면 너무 깔끔할 것 같았기에... 하지만 마감이 있는 작업이라 Rx로 갈아엎기는 무리여서 다음에 사용해보기로 했다.


프로젝트 후반 (스프린트 3)

생각보다 UI 작업이 오래 걸려서 기능 구현이 늦어졌다. 그래서 스프린트 기간이 조금 늘어났지만 결국 완성할 수 있었다. 아직 기획되지 않은 요구사항 때문에 미완성된 기능(애플 로그인, 푸시 알림 등)으로 앱스토어 심사는 거절되겠지만 심사 제출을 끝으로 해당 프로젝트를 마무리했다. 앱스토어 심사는 처음이었지만 심사 제출 자체는 어렵지 않았다. 다만, 그들의 깐깐한 심사를 통과하는 것이 제일 어렵지 않을까...

 

이번 프로젝트를 통해 배운 점을 정리해보자면

  1. 디자인 가이드와 API 문서는 확실하게!!
  2. (개인적인 취향으로) UI는 코드가 더 편한 것 같다.
  3. 뭔가 구현할 때에 힘들다는 느낌이 들면 라이브러리를 열심히 찾아보자!
  4. Rx 짱짱인 듯...

다음부터는...

해당 프로젝트를 끝내고 난 후 RxSwift 공부할 겸 전수열 님께서 만드신 ReactorKit을 공부해보고 있다. 다음 프로젝트는 ReactorKit 까지는 아니더라도 RxSwift를 이용해서 정해진 시간 내에 최대한 깔끔하게 만들어보고 싶다.

 

아, 그리고 기능 구현이 바빠서 차마 DI (Dependency Injection)을 잘 못하고 Singleton 객체만 주구장창 사용했는데 다음엔 Swinject로 DI까지 깔끔하게 해 봐야겠다.

 

앞으로 내가 진행하는 iOS 프로젝트에서 SnapKit, Then, PromiseKit, Swinject는 필수 라이브러리가 되지 않을까 생각된다.

 

아래는 이번 프로젝트의 Podfile이다.

# Uncomment the next line to define a global platform for your project
platform :ios, '11.0'

target 'MyProject' do
  # Comment the next line if you don't want to use dynamic frameworks
  use_frameworks!

  pod 'SnapKit', '~> 5.0.1'

  pod 'Firebase'
  pod 'Firebase/Auth'
  pod 'Firebase/Core'
  pod 'Firebase/Database'
  pod 'Firebase/Storage'
  pod 'FirebaseUI/Storage'
  pod 'CodableFirebase'

  pod 'FSCalendar'
  pod 'Alamofire', '~> 5.0.5'
  pod 'Then'
  pod 'SwiftyJSON'
  pod 'PromiseKit', '~> 6.13.1'

  pod 'KakaoOpenSDK'
# pod 'Alamofire'

# pod 'YouTubePlayer'
  pod 'YouTubePlayer', :git => 'https://github.com/weakfl/Swift-YouTube-Player.git', :branch => 'use-wkwebview'

end
댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday