Swifter {Swift Developer}

메뉴

프리랜서의 iOS 앱 개발 준비하기

최근 몇년간 몇몇 금융권 및 스타트업에서 iOS앱을 개발해오면서 나름대로 프리랜서로써 일해오면서 백엔드도 개발하고 팀구성을 할경우 4~5명으로 스크럼 개발을 진행해보았을 때 최근 나름대로 정리한 개발기준을 정리한 것을 공개한다. (정확하게는 위탁받은 개발 업무를 팀에 맞게 확장했다)

개발 기준 iOS버전

iOS운영체제 버전은 10버전 이상을 대상한다. 매년 출시되는 iOS버전을 그해 맞는 최신버전을 기준으로 개발을 해야 하는데 하위 버전을 고려할 경우 어떤 제약이 발생하기 앞으로 업그레이드를 고려해서 앞으로 출시되는 신규버전으로 올라가기 위해서 정보수집과 노하우를 축적하는 것이 과제이다.

개발언어

Swift 3.0이상을 기준으로 한다. 아직 Swift 3.x가 대중화되지 않았지만 Swift 3.x부터 크게 API가 바뀌었고 Swift 4.x가 출시될 경우 호환성을 유지한다고 발표되었기 때문에 Swift 3.0이상을 기준으로 개발언어로 사용하며, Xcode 8.3부터는 Swift 3.x만 지원한다. 프리랜서로써 되도록 네이티브 앱 개발을 기업들에게 추천하지만 가끔 보다 빠른 개발을 위해 React Native같은 것이나 하이브리드앱으로 개발하려는 경우가 있는데 개인적으로 아직 해당 프레임웍들의 안정화가 되지 않았기 때문에 개발일정에 차질이 발생할 수 있어 하지 않았다.

다만, 2016년말에 발표한 ThoughtWorks의 Technology Radar에서 React.js와 Redux가 ADOPT되었고 React Native는 TRIAL되었기 때문에 2017년도에는 많이 채용될 가능성이 높다.

React X Redux는 이전부터 사용은 해왔고, iOS 및 Android용 앱을 같이 만드는 경우가 아니면 사용하지 않었더, 또한 플랫폼도 더 다양해지고 있어 웹, iOS, Android, 윈도우용으로 개발한다고 하면 논리적인 공통화등으로 비용 및 운영적인 부분의 장점을 통해 비용절감을 도모한다.

개발환경

실제 Mac에서 Jenkins와 채팅류, GitBucket과 Redmine은 다른 서버와 비슷한 형태로 구성한다. Rocket.chat(또는 Slack), Hubot은 Docker로 구축하고 제품개발 이외의 화녁ㅇ에서 새로운 기술을 채택하는 것은 개발자로써도 성장의 기회이기 때문에 중요하다.

ITS(Issue Tracking System)

ITS는 보통 Redmine을 이용한다. redmine_backlogs플러그인을 추가하여 백로그와 개발하는 사용자스토리와 작업을 관리한다. 또한, 노하우와 팀 결정에 대해 스프린트별로 사진, 계획등의 회의록등을 Redmine Wiki에 남기게 되어 있다. (한국에서는 보통 JIRA를 이용하는데 이건 좀 크고 docker랑 이슈가 있어서 Redmine을 이용해요) 작성은 Markdown에서 작성할 수 있다.

SCM(Source Control Management)

SCM은 GitBucket을 이용하는데 도입이 편하다. 최근 2년간 모든 프로젝트에서 이용했으며, 기본 설정은 Xcode에서 Push를 못해서 확인해보니 SSH를 사용할 수 있게 설정을 변경했다. 다만 대기업이나 금융권의 경우, 회사 특성상 외부 서비스에 소스코드를 올릴 수 없기 때문에 자신의 서버를 이용하고 있다. 비용 이슈가 있는 경우, BitBucket을 사용하는 경우도 있다.

Git 브랜치모델은 GitHub Flow에 유사한 모델을 채용해야 한다. 최근 프로젝트에서 git-flow를 채용해보았지만 너무 무거웠다. 그래서 GitHub FLow를 사용해 보려고 한다.

CI(Continuous Integration)

CI는 필자가 Mac을 사용하기 때문에 Jenkins를 사용한다. Bundler에서 gem을 통해 Cocoapods에서 종속성해결하고 fastlane에서 빌드후 SwiftLint 실행 테스트를 통해 진행해 왔다. 다만, 아직은 Test Flight에서 업로드할 수 없기 때문에 이슈는 있다. 금융권같은 큰 기업의 경우 외부 CI서비스를 이용할 수 없기 때문에 이슈가 있다. 그래서 보통은 CircleCI의 CircleCI Enterprise를 이용하여 처리할 수 있지만 비용 부분이 이슈가 있다.

내부소통(채팅)

채팅은 Rocket.Chat을 이용한다. Slack도 좋지만, Mac에서 Docker을 구축했다.

채팅에서는 각 개발팀원간의 소통공간을 준비하고 현재 개발중인 내용들이 나오도록 구성한다.

소프트웨어 아키텍쳐

보통은 Clean Architecture를 변형해서 사용한다. 현재는 작은 앱개발이라도 미래에 규모가 커질 수 있다면 보수성이 높고, 제대로 계층분류된 아키텍쳐를 적용한다. 이 아키텍쳐는 Java기반의 안드로이드 앱개발에서도 사용할 수 있어 자유도가 높기 떄문에 추천하고 있다.

하지만, 작성하는 클래스가 MVC보다 많고 각각의 구성요소간의 관계를 이해하는데 다소 시간이 필요하다는 것이 개발 규모나 앞으로 미래를 감안해서 채용하길 권장한다. 그래서 팀원간의 능력차를 고려해서 Swift언어 경험이 있는 팀원이 샘플을 만들어 모든 사람이 이해하도록 하고 있다. 또한 정말로 작은 앱 개발일 경우에는 일반적인 MVC로 충분하다고 판단하고 MVC기반으로 개발하고 되도록 오픈소스 프레임웍도 최소로 사용한다.

설계

백로그의 사용자 스토리에 로버스트니스(Robustness)를 작성하도록 권장하고 있다. 이 단계에서 어떤 인터페이스가 있는지, 이벤트가 있는지, 실체가 있는지를 드러내고 있다.

로버스트니스 위 그림은 3가지 요소(+ Actor)에서 설명한다. 간단하고 작성하기 쉬운것과 경계는 화면과 외부 시스템의 인터페이스 제어는 비즈니스 로직 엔티티는 도메인 모델에 연결한다.

설계서

설계서는 엑셀등으로 만들어도 되기 때문에 사소한 문제라도 꼼꼼히 설계하는 것이 중요하다. 필자가 같이 했던 팀은 Markdown에서 설계서를 작성하도록 했다. 대부분 개발자나 디자이너도 Mac을 사용했기 때문에 Excel대신 Markdown을 채택했다. 고객들에게 관련 자료를 제공할 경우에는 Pandoc이라는 도구를 통해 마이크로소프트 워드나 PDF로 변환해서 공유하거나 인쇄하였다.

또한, Markdowneh Git으로 관리하고 Pull Request에 대한 리뷰를 한다. 그리고 처음부터 완벽한 설계를 목표로 하기보다는 여러가지 의견들을 받아 설계하고 소스코드를 작성하면서 설계를 개선해 나간다는 흐름으로 개발한다. (클라이언트들은 이것을 대부분이 이해하지 못하는 경우가 많다)

라이브러리

라이브러리는 Swift 3.x를 지원하는 것들을 채용한다.

  • Alamofire (네트워크 통신용)
  • Realm (로컬 데이터베이스)
  • Bolts-Swift (Promise 라이브러리)
  • Kingfisher (캐싱 이미지)
  • RxSwift (FRP)
  • R.swift (리소스 관리 라이브러리 – 파일이 많은 프로젝트는 비추천함)

정리

최근까지 iOS앱 개발을 이것저것 해보면서 정리해 보았다. 다소 국내 상황과는 틀리게 되도록 자체적인 오픈소스를 이용해서 환경구축을 해본 경험위주로 정리했다.

 

Facebook Comments

카테고리:   Swift 3.0

댓글

죄송하지만 댓글은 닫혀 있습니다.