SeSAC iOS 과정을 수강하며 약 3주간의 스프린트를 통해 기획부터 출시까지 앱 개발 전체의 프로세스를 1인 개발자가 해쳐나간 과정과 느낀점을 적은 글입니다.
앱스토어 바로가기
기획
"책을 좋아하는 사람으로써 도서를 관리하고 독서를 기록하는 앱을 만들고 싶다" 라는 생각으로 시작했다. 막상 빈 페이지를 눈 앞에두고 앱을 구상하는건 어려웠다. 그래서 먼저 앱스토어에 무작정 들어가 도서관리에 연관된 앱을 여러개 다운받았다. 한 6~7개를 받아서 분석을 해보니 도서 앱이 가지는 공통점들이 몇가지 보였다.
그러한 공통점들을 기반으로 내 앱에도 가져갈 기능과 가져가지 않을 기능으로 나누었다. 그 후 덧붙히고 싶은 기능을 구상해보았고 나 같은 경우는 타이머 기능이었다. 그리하여 기존에 타이머 기능이 있는 앱을 자세히 분석해보며 좋은 점과 아쉬운 점을 정립하였고 그 외에도 다른 유사 앱들은 가지고 있지 않은 기능들을 추가하여 기획상의 차별점을 두었다.
그러나 첫 술에 배부르랴. v1.0(MVP)에 들어갈 기능들만 따로 빼 두었고 추후에 업데이트할 기능들을 나누고 나서야 기획 단계를 넘어갈 수 있었다.
천리 길도 한 걸음부터. 작업의 우선순위를 명시하고 그것을 지켜야한다.
(그림: 초기 기획서의 한 부분)
계획
"일단 화면 부터 만들고 보자"라는 생각이 든다면 잠시 참는게 좋다. 개발 시작 전 탄탄한 프로젝트 관리체계를 잡는것이 개발 그 자체 못지않게 중요했고 프로젝트가 진행 될 수록 빛을 냈다.
나는 노션에 테이블로 Backlog를 작성하며 프로젝트를 관리했다. 각 테스크마다 번호, 현재 Iteration,제일 큰 단위인 Epic, 중간 단위인 Story 를 정립하고 테스크, 상태, 예상/실제 공수 시간을 작성했다.
테스크 하나는 개별적인 페이지로 각 테스크에서 발생하는 특이사항들을 따로 기록했고 제목에 이모티콘을 사용해 페이지에 들어가보지 않아도 시각적으로 어떤 내용인지 한눈에 들어오도록 하였다. 그러나 공수를 정한다는건 쉽지 않았다. 처음 다뤄보는 기술들은 얼마나 걸릴지 전혀 감이 오지 않았고 이미 아는거라도 내 예상을 벗어나 훨씬 더 오래, 혹은 더 일찍 끝나는 경우도 다반사였다. 그럼에도 이렇게 잡아야 하는 이유는 회사에서 동료들과 개발을 할 때에, 그리고 매니저와 일을 할 때 꼭 필요한 과정이기 때문에 무리하게 어림을 잡아서라도 작성했다.
또한 점점 쌓이는 합계 공수 시간을 보면서 한편으로 뿌듯함도 느낄 수 있었다.
내 노오력도
(그림: 노션 백로그 페이지)
(테스크 상세)
개발자는 문제를 해결하는 사람이다. 정리가 잘 되어야 문제도 잘 풀린다.
개발
앱,웹, 클라이언트 개발은 화면 먼저 그리고 싶은 생각이 들게 만든다. 눈 앞에 보이는 결과가 일을 많이 했다고 믿게 만들기 때문일까? 하지만 이건 좋지 않다고 생각한다. 각 화면을 먼저 구상했으면 각 화면마다 필요한 데이터가 뭔지 정립할 필요가 있다. 또한 화면들이 어떻게 이동할지, 그리고 데이터의 흐름이 어떻게 될지 먼저 정의가 되어야한다. 물론 이 과정을 거쳤어도도 개발을 하면서 계속 수정을 거쳤다.
또한 더더욱 API를 사용한다면 서버에서 오는 Raw 응답을 어떻게 가공하고 View까지 보여줄건지 생각을 해야했다. 이게 가능하려면 먼저 사용자의 Use Case를 먼저 명확하게 정립해야했다. 나 또한 특정 화면에서(사용자가 독서를 하는 뷰) Use Case가 명확하지 않아 다시 기획서로 돌아가는 작업을 거쳤다.
이 프로젝트에선 MVVM패턴을 사용했다. 그 외에도 Local DB엔 Singleton + Repository패턴을, 네트워킹은 Router패턴을 사용했다. 이런 저런 패턴을 합쳐서 사용하다 보니 굳이? 라는 생각이 들 때도 있었는데 예를들어 ViewModel에서 직접 Realm에 접근 할 수 있음에도 Repository 를 쓰는 경우가 그랬다. 제한된 시간 속에서 개발을 하며 기능을 쳐내다보니 패턴의 일관성을 놓치는 부분도 발생했고 이러한 부분은 충분히 리팩토링을 통해 개선 할 수 있을것 같다.
개발하면서 겪은 자세한 트러블슈팅은 따로 글을 작성할 계획이다.
출시
처음 버전 1.0을 테스트 플라이트(이하 테플)에 올리고 3번이나 빌드를 다시 올린 후에야 심사를 제출했다. 그리고 나선 언제 심사 상태가 바뀔지 계속 핸드폰을 붙들고 있었다. 개발이 완성되어도 앱스토어 커넥트에서 신경써줘야 할 점이 꽤나 많았다 (스크린샷, 개인정보 처리 등).
출시를 하며 겪은 시행착오 중 하나는 애플의 Appstore Connect 서비스가 다운되었던것이다. 아마 한 새벽 2시쯤에 XCode에서 아카이브를 하려고 했을때 처음 오류가 났었다. 그 후 번들 아이디도 몇 번이나 바꿔봤지만 해결되지 않았고 결국 새벽4시가 넘어 잠에 들었다. 다음 날 아침이 되어서야 오픈채팅방을 통해 애플 서비스가 다운된 소식을 접했고 전 날 밤에 시간을 버렸다는 생각이 조금 억울하기도 했지만 이런건 별거 아니고 충분히 있을 수 있는 일이라고 생각했다. 오히려 서버가 복구 되는 동안 계속해서 기능개발을 했고 그 날 오후에 앱스토어 커넥트 서비스가 정상으로 돌아오면서 앱을 등록하고 테플에 배포할 수 있었다.
내 앱은 Crashlytics를 위한 진단 데이터 외에 별도로 데이터를 수집하지 않아 신경써야 할 점이 많진 않았지만 다른 수강생들을 보니 많이들 Info.plist파일에 관련된 리젝이 많았고 그 중 상당한 부분이 Privacy에 관하여 권한 설명을 충분히 하지 않았다는 이유에서였다.
버전 1.0을 제출하고 심사에 통과되기까지 약 24시간이 좀 넘게 걸렸다. 예전에 비하면 상당히 빨라진 편이다. 심사를 기다리는 사이에 테플에 새로 올라온 버그들을 대응하기위해 Git에 바로 버전1.0.1 브렌치를 만들어 개발을 이어나갔다.
(그림: 출시 완료)
차근 차근 알려주는 대로 하기만 하면 생각보다 어렵지는 않았다.
운영
서비스 런칭이란 곧 할 일이 잔뜩 생기는걸 의미하는것 같다. 물론 출시 직후엔 조금 숨을 돌릴 수 있었으나 출시가 되자마자 나는 1.0.1버전으로 다시 심사를 넣었다. 버전 업데이트는 12시간도 채 안걸렸다.
현재는 1.0.2버전을 개발중이고 디자이너와 협업을 준비중에 있다. 이제 출발점에 다시 올랐다. 사용자들과 소통하고 서비스를 운영해 나가며 애정을 가지고 지속적으로 개선 및 업데이트를 꾸준히 해나가는것이 내 목표이다.
(그림: 앱스토어 커넥트)
처음 앱을 출시하면서까지 많은 시행착오가 있었습니다. 그 과정에서 많은 도움을 주신 멘토 Hue, Jack, Kokojong & Bran 님, 동료 수강생 분들, 테스트에 도움 주신 지인분들께 감사드립니다 🙏
