[iOS] 출시 후 첫 신규기능 <온보딩> 업데이트 후기

 

1. 출시 2달 어땠는지?

메뉴얼이 출시된지 약 2달이 지났습니다.

부끄럽지만 매일 4명에서 많게는 13명(!) 정도가 우리 앱을 사용해주고 계십니다.

 

유료로 출시하게 되면서 내부적으로 조금 더 책임감을 가지고 개발하게 되는 선순환이 되기는 했지만,

아무래도 무료로 출시할 때보다는 유저 유입 자체가 적을 수밖에 없습니다.

 

신규 유입은 홍보로 해결할 수 있다고 생각 했는데요.

메뉴얼을 설치하고 사용하게 되면서 얼마나 우리 앱에 남아줄까? 하는게 근본적인 해결책이었습니다.

 

매우 부족하지만 꾸준히 써주고 계신다..

메뉴얼은 "작성한 일기를 다시 읽는 경험"을 가장 중요하게 생각하는 서비스입니다.

 

다시 읽기 위해서는 어느정도 작성한 일기가 있어야 하는데, 이 부분이 다소 미흡했던 것 같아요.

우리 서비스에서 진입하고 "이정도면 추천 해줄 일기가 많이 쌓였지 않았을까?" 하고,

일정 기간 또는 일정 메뉴얼을 작성하게 될 경우 추천 서비스가 활성화 되도록 해놓았는데요. 

 

 

그러다 보니까, 상단 영역이 항상 붕 뜨는 문제가 생겼습니다 ㅎㅎ..

주변 지인에게도 "이 영역은 대체 뭐하는 영역이야?" 라는 물음을 수도 없이 들었어요.

 

"메뉴얼을 작성하시면 다양한 컨텐츠를 확인할 수 있어요." 라고 했는데,

유저에게 얼마나, 어떤 컨텐츠를 적어야 하는지 안내 해주지 못했고,

그러다 보니 사용자가 중간에 이탈하는 경우가 많다고 생각했어요.

 

"작성한 일기를 다시 읽는 경험"이 가장 중요하다고 했는데, 사실 그 경험을 단 한 번도 주지 못했던 거예요.

그래서 우리 팀은 유저가 메뉴얼을 설치하고, 일기 추천을 자연스럽게 받을 수 있도록 기획을 수정하고 신규 기능을 추가하기로 했습니다.

 

작은 기능이지만, 신규 기능을 출시 후에 업데이트 할 때는 생각보다 많은 것들을 고민하게 되었는데,

그 고민들을 적어 내려가고자 합니다.

 

---

2. 온보딩 기능을 기획 해보자

우리 앱이 가장 미흡했던 것은, 메뉴얼을 처음 진입하고 일기를 추천 받는 경험까지 이끌어주는 것이었어요.

사실 그 경험이 없다면, 아이폰 기본 메모 앱 또는 다른 메모장과 다를 바 없는 앱이 되니까요 ㅎㅎ..

그래서 일기를 다시 읽을 수 있는 최소한의 기한과 일기를 작성할 수 있도록 돕고자, 온보딩 기능을 기획했습니다.

 

2-1. 얼마나 일기를 작성해야 하는가?

첫 번째 고민은 일기를 얼마나 작성해야 추천 기능을 활성화할까? 라는 물음이었어요.

사실 많으면 많을 수록 좋지만, 현실적으로는 쉽지 않았구요. 많은 후보군이 있었지만 최종 14일로 결정되었습니다.

 

7일도 아니고 10일도 아니고 14일인 이유는 단순합니다.

 

A : "7일은 좀 짧지 않나?"

B : "아무래도 1주일 전 일기를 추천해주는 건 임팩트가 적긴 하지.."

C : "흠.. 7일은 짧고 10개는 애매하니 14일 2주 ㄱ"

A, B : "ㄱ"

 

2-2. 14일 vs 14개

두 번째 고민은 기간과 개수였어요.

근데 이 고민은 금방 정리되었습니다.

 

A : "하루에 글을 14개 작성하면, 내일부터 바로 과거의 일기를 추천해주는게 맞나?"

B, C : (끄덕)

 

---

3. 개발을 시작하자

디자이너 친구들이 열심히 스크린을 만들어 주었습니다.

기획도 꼼꼼하게 만들어준 덕에, 개발은 매우 쉽고(?) 빠르게 진행되었는데요. 매우 심플하죠?

 

아무것도 작성하지 않았을 경우의 UI

14개를 모두 작성했을 경우 UI

3-1. 온보딩을 완료했는지 체크를 위한 DB추가

public class MomentsRealm: Object {
    @Persisted(primaryKey: true) public var _id: ObjectId
    @Persisted public var lastUpdatedDate: Date
    @Persisted public var onboardingClearDate: Date?  // 신규 추가
    @Persisted public var onboardingIsClear: Bool     // 신규 추가
    @Persisted public var items: List<MomentsItemRealm>
}

온보딩은 1회성으로 신규 설치 유저 기준, 14개 미만으로 작성한 유저에게 모두 보여야 했습니다.

15개 이상 작성할 경우에는 보이면 안되므로 해당 영역을 담당하는 Realm DB에 저장할 새로운 값을 추가했는데요.

 

@Persisted public var onboardingIsClear: Bool

onBoardingIsClear는 변수명 그대로 "온보딩 기능을 모두 완료했는가?"를 true/false로 체크하는 값입니다.

 

@Persisted public var onboardingClearDate: Date?

위에 클리어 여부를 체크하는 값이 있는데 왜 굳이 "onboardingClearDate"라는 값이 또 있는지 의아할 수도 있는데요.

14개를 작성하더라도 바로 일기 추천을 시작하는 것이 아닌

"다음날부터 추천"하기 때문에, 클리어한 날짜가 필요했습니다.

 

클리어한 날짜 다음부터 추천해줘! 하기 위해서는요!

 

3-2. 디자인시스템 추가

내부적으로 디자인 시스템을 한 뷰에서 볼 수 있도록 관리하고 있습니다.

Moments/onboardingView 를 확인할 수 있도록 UI를 업데이트 했습니다.

 

마음대로 지은 변수명의 폐해.. (현재는 변경함 ㅎㅎ)

모두 Codebase UI로 진행했고, SnapKit과 Then Library를 사용해서 편하게 만들었습니다.

UI는 최대한 관리하기 쉽도록 하는 방법을 꾸준히 연구하고 있어요.

 

- 웹으로 치면 div 기준으로 파일을 분리하는 것이 좋을지?

- 하나의 파일 안에서 모든 뷰를 하나로 그리는 것이 좋을지?

 

정답은 없지만, 다음에는 FlexLayout을 활용해서 기존 StackView를 사용한 레이아웃도 리팩토링을 진행할 예정입니다.

효율적으로 UI를 그리는 것은 항상 어려운 것 같아요.

 

 

3-3. DB Migration

이번에 온보딩 신규 기능이 들어가면서, 새로운 DB 값이 추가되었습니다.

메뉴얼이 출시 되기 전에는 DB에 새로운 값을 넣고 빼는 것 자체가 매우 편안했습니다.

그냥 테스터들은 앱을 지웠다 깔면 되니까요!

 

그런데, 메뉴얼이 출시되고 나서부터는 조금 이야기가 달라졌어요.

일기를 열심히 작성하고 있었는데, 신규 기능이 출시되었다고 앱스토어에서 업데이트했더니

작성한 일기들이 모두 날라가게 되면 아마 사용자는 리뷰에 별 1개를 남기고

우리 앱을 다시는 쳐다보지 않으실 거예요 ㅎㅎ.. 🔥

 

그래서 최대한 Migration에 실수가 없도록 노력하고, 최대한 무결성을 검증하기 위해서 노력하고 있답니다.

그 결과 성공적인 Crash 0%!

// config 설정(이전 버전에서 다음 버전으로 마이그레이션될때 어떻게 변경될것인지)
let config = Realm.Configuration(
    schemaVersion: 5, // 새로운 스키마 버전 설정
    migrationBlock: { migration, oldSchemaVersion in
        if oldSchemaVersion <= 2 {
            // 마이그레이션 수행(버전 2보다 작은 경우 버전 2에 맞게 데이터베이스 수정)
            migration.enumerateObjects(ofType: MomentsItemRealm.className()) { oldObject, newObject in
                newObject!["icon"] = "120px/book/open"
            }
        }

        if oldSchemaVersion <= 3 {
            migration.enumerateObjects(ofType: MomentsRealm.className()) { oldObject, newObject in
                newObject!["onboardingClearDate"] = nil
            }
        }

        if oldSchemaVersion <= 5 {
            migration.enumerateObjects(ofType: MomentsRealm.className()) { oldObject, newObject in
                newObject!["onboardingIsClear"] = false
            }
        }
    }
)

 

3-4. 총 개발 기간

커밋 상으로 보면 순수 투자 시간 기준 약 4일이 걸린 것 같습니다.

온보딩 브랜치를 따로 생성해서 작업을 진행했는데, 확실히 다른 기능과 컨플릭트날 일이 없어서 너무 좋더라구요.

 

이때 당시에 한참 패키지 모듈화를 함께 진행하고 있었는데, 아무 컨플릭트 없이 잘 들어가서 기분이 매우 좋았다는 후기..

 

---

 

4. 마무리

런칭된 앱에 신규 기능을 추가하는 것은 굉장히 신경쓸 것이 많다는 것을 알았습니다.

아무래도 사용자들의 시간과 이야기가 담겨 있는 일기 DB를 제 부주의로 날려먹을 수 있다는 것에 굉장한 압박이 느껴지더라구요.

그래서 최대한 팀원들과 테스트할 수 있도록 다양한 시도를 하고 있습니다.

 

팀원 중에는 대부분이 메뉴얼을 실사용하고 있기 때문에, 테스트하기 위한 시료가 없는만큼 메뉴얼 테스트플라이트 버전에서 테스트하기 쉽지 않았어요. 팀원들의 일기들도 소중하니까요.

 

그래서 테스트를 하기위한 Menual Alpha를 fastlane으로 따로 빌드해서 배포하고 있습니다.

debug mode를 앱에서 활성화하고 테스트를 해야할까? 싶었는데, 따로 앱을 빌드하는 것이 가장 안전하더라구요.

 

실제로 '백업하기/복원하기' 기능을 다음 신규 기능으로 제공하려고 개발하고 있는데 해당 기능은 Alpha에서만 제공하고 있습니다.

최대한 Alpha에서 검증이 되면, Beta(마켓버전)에서 테스트하고 출시하는 프로세스로 진행하고 있습니다.

 

매우 간단한 온보딩 기능임에도 런칭한 앱에서 신규 기능을 추가하는 것은 신경쓸 부분이 매우 많다는 것을 경험했습니다.

다음 백업/복원 기능 역시, 유저들의 DB를 직접 건드는 작업으로 매우 리스키한 작업인데요.

해당 작업도 이번 경험을 토대로 잘 출시되었으면 좋겠습니다.