[Naver Deview 2023] LiveOps : 네이버앱의 실시간 운영과 크래시 핸들링 솔루션

지난 2월 네이버가 주최하는 컨퍼런스 Deview 2023이 열렸습니다. 오랜만에 오프라인으로 진행된 컨퍼런스인 만큼 경쟁이 치열했다고 합니다. 3시에 티켓이 열리자마자 매진이 됐다고 하네요 ㅎㅎ

 

아쉽게 가지는 못했지만 지난 달 말에 세션 영상이 올라왔습니다. 

대부분 백엔드 관련 내용이 많았고 AR관련 주제가 하나가 있긴했는데 안드로이드까지 다뤄서 사실상 iOS 관련 단독 주제는 없었습니다... 🥲 하지만 모바일이 아니더라도 "인공지능을 사용한 장소 추천" 등 재밌는게 많아 시간 날 때마다 틈틈이 보려고 합니다. ㅎㅎ

 

이번 포스팅에서는 "모바일 앱 운영을 위한 LiveOps"를 정리하겠습니다.

안드로이드 개발자님께서 발표를 해주셨지만 iOS에도 적용될 수 있는 매우 흥미있는 이야기입니다.

 

LiveOps : 네이버앱의 실시간 운영과 크래시 핸들링 솔루션

 

1. 도입 배경

모바일 앱은 사용자에게 편리한 기능과 안정적인 환경을 제공합니다. 하지만 그와 동시에 플랫폼적인 한계가 있습니다.

1. 스토어 심사 기간

2. 배포 후 수정 불가

이 두 개는 모바일 개발자를 힘들게 만듭니다. 특히 2번 배포 후 수정 불가로 인해 배포 이후에 앱 크래쉬를 발견하게 된다면 사용자는 큰 불편을 느낄 수 밖에 없습니다.

네이버의 경우에도 심사와 배포에 5~6일 정도의 시간이 소요된다고 합니다.

배포가 된다고 해도, 해당 배포 버전을 90%의 사용자가 업데이트하기 까지 2~3달의 시간이 걸린다고 합니다.

 

이를 막기 위한 운영 정책 방식과 장애 대응 방식이 네이버에 있습니다.

 

운영 정책 방식으로는 데브 옵스를 통해 리드 타임을 개선합니다. (리드 타임 : 조달 기간 -> 개발에서 배포까지의 시간이라고 보면 될 것 같습니다.)

또 강제 업데이트를 통해 사용자 요구를 반영합니다. 가끔 특정 버전에서 앱 업데이트를 안하면 사용불가 Alert이 뜨던데 이 경우가 같습니다.

 

장애 대응 방식으로는 예외 사항 처리, 테스트 코드 작성이 있습니다.

 

이러한 대책 방식들은 유의미하지만 각각의 한계점이 있습니다.

 

리드 타입을 아무리 줄여도 다음 배포까지 기다려야 합니다. 배포되더라도 사용자의 업데이트를 기다려야 합니다.

강제 업데이트는 사용자 친화적이지 않습니다.

 

코드 상으로 예외 사항을 잘 처리했더라도 SDK, 기기, 서버 문제로 발생하는 모든 문제를 해결할 수는 없습니다.

테스트 코드 작성은 많은 리소스를 필요로 하며 100% 만족할수는 없습니다.

 

네이버는 한 달 이용자(MAU)가 4000만명 입니다.

이 중 1%의 사용자에게만 재현되는 크래시가 있더라도 최소 20만명에게 크래시가 발생합니다.

네이버는 크래시가 나더라도 배포 없이 대응할 수 있기위해 LiveOps를 도입했습니다.

 

2. LiveOps 소개

LiveOps의 정의입니다. = 배포 없는 실시간 대응이라고 생각하면 될 것 같습니다.

 

게임 앱에서 업데이트 없이 이벤트를 진행하는 것과 동일한 맥락입니다.

 

네이버에서는 LiveOps를 사용해 위와 같은 기능을 제공합니다.

장애 상황 접근의 예시로는 네이버 앱에서 홈 접근 실패 시 웹 뷰로 네이버 홈화면을 띄어 주는 것입니다.

자세한 예시는 뒤에서 시연합니다.

 

LiveOps는 크게 3가지 Core, NRC, NRE로 나눌 수 있습니다.

• Core : 네트워크를 콘솔에 설정된 데이터 설정, 데이터 캐시. 특정 사용자, 날짜 타겟팅하는 전략이 있음
• NRC : Core에서 받아온 데이터를 기반으로 키-값 을 리턴함. 특정 타겟에만 원하는 value 값 리턴
• NCE : Core에서 받아온 데이터를 기반으로 사용자 이벤트를 훅킹(hooking)하여 해당 시점에 원하는 전략을 실행. 특정 타겟에만 원하는 이벤트 발생

이벤트 훅킹은 해당 이벤트를 가로챈다는 것입니다. 내가 원하는 시점, 타겟에게만 보여주기 위해 이벤트를 가로채서 가지고 있는 거라고 생각하면 될 것 같습니다.

 

NRC 부터 살펴보겠습니다. NRC는 키-값을 리턴해줍니다.

배포 후 사용자의 on/off에 따라 기능을 on/off 합니다. 특정 기능에 대해 특정 타겟층에게만 on으로 해 배포가 가능합니다. → A/B 테스트 가능

현재 사진에서 Android & OS 11 인 기기에 대해서만 기능을 On 했습니다. 오른쪽 사진을 보면 OS 11 핸드폰만 기능이 켜지는 것을 확인할 수 있습니다.

 

on/off 기능을 통해 목표 타겟층에게만 니즈에 맞는 콘텐츠 노출이 가능합니다.

30대에게만 골프관련 콘텐츠를 노출시킬 수 있습니다.

 

현재 네이버 앱의 뉴스 기능을 보면 20대 추천 기능이 있는데, LiveOps를 사용하지 않았을까 생각이 됩니다.

20's Beta

 

NRC는 Firebase Remote Config와 비슷한 기능을 제공해줍니다.

하지만 이런 NRC는 미리 코드를 작성해줘야 합니다. 즉 에러에 대한 어느정도 예측이 필요합니다.

 

여기서 NCE(Naver Codeless Event)는 이름 그대로 코드 없이 동적으로 전략 주입이 가능합니다. 예측 불가능한 에러 상황에서도 적용이 가능하게 됩니다.

 

NCE는 기존 이벤트를 훅킹해서 원하는 이벤트를 실행합니다.

위 그림 처럼 비즈니스 로직에 따라 크래시가 발생할 수 있습니다.

 

아래 그림과 같이 NCE를 사용함으로써 크래시를 우회할 수 있습니다. 

이벤트를 트리거 할 경우 기존 이벤트를 훅킹합니다 -> 비즈니스 로직을 수행하지 않고 해당 시점에 특정 전략(=NCE)를 실행합니다.

그림처럼 이벤트를 훅킹에서 NCE 전략을 사용하거나, 기존 비즈니스 로직을 수행하는 것 둘 다 사용할 수 있습니다. 

(발표에서는 비즈니스 로직을 블록킹한다는 표현을 사용했습니다)

 

트리거 할 수 있는 이벤트 목록입니다.

1. View 클릭
2. 스크립 진입
3. 네트워크 호출
4. 딥 링크

View 클릭의 경우 안드로이드의 onClick 이벤트를 통해 View클릭을 감지합니다. -> iOS의 경우 View 터치 이벤트를 생각하면 됩니다.

 

위 이벤트 발생시 처리 할 수 있는 전략은

1. 토스트 메시지
2. 팝업 창
3. 업데이트 팝업 창
4. 웹 랜딩 (=웹 View로 해당 View 대체)
5. 딥 링크 교체

활요할 수 있는 사례를 보겠습니다.

A버튼 클릭시 B화면으로 진입하는 로직입니다. 이 때 B화면 진입 시 크래시가 발생하는 상황입니다.

NCE를 사용해 A버튼 클릭시 팝업을 띄어줍니다. -> B화면으로 이동 차단

업데이트 팝업을 사용해 Hotfix 업데이트 유도도 가능합니다.

 

에러가 발생하지 않더라도 목표 타겟층에게만 이벤트 제공도 가능합니다.

특정 버전 사용자에게만 업데이트 팝업을 띄어줄 수 있습니다.

위 사진의 경우 버전 2.0.0 이하의 사용자가 메인 스크린 진입시 업데이트 팝업을 띄어줍니다. 그림을 보면 type뿐만 아니라 content도 주입해 줄 수 있어 보입니다.

 

3. 플로우 및 구조

개념을 이해했으니 플로우를 살펴보겠습니다.

그림에 클라이언트 앱, 모바일 SDK, 서버를 확인할 수 있습니다.

 

클라이언트 앱은 사용자가 설치하는 앱입니다. 

 

모바일 SDK는 클라이언트 앱을 통해 플랫폼, OS, 네이버 로그인 등의 정보를 주입 받습니다. 이러한 정보를 factor라고 합니다.

콘솔에서 받아온 데이터를 앱에 전달합니다.

 

서버는 값을 세팅할 수 있는 콘솔을 제공합니다. 발표에서 웹을 통해 설정하는 콘솔을 볼 수 있습니다.

콘솔에 설정된 데이터를, API를 통해 바일 SDK에 전해줍니다.

factor에 따라 값 설정이 가능합니다 -> 특정 사용자 그룹 타겟팅 가능

배포 히스토리를 서버에서 관리합니다. -> 롤백 기능 제공

 

factor

factor의 목록으로는 플랫폼, 디바이스 모델, OS버전, 앱 버전, Naver 아이디, 날짜가 있습니다.

(factor는 변수 타입이라고 생각하면 될 것 같습니다. + 아마 나이, 성별 정보는 Naver ID를 기반으로 서버에 있는 사용자 데이터를 사용하는 것 같습니다.)

 

연산자

이런 factor와 연산자를 조합해서 조건을 만듭니다.

연산자의 경우 5개 =, >, ≥, <, ≤ 가 있습니다.

 

조건

조건은 평소에 코딩할 때 그 조건입니다.

플랫폼이 안드로이드일 경우 -> platform == android 이런 식입니다.

 

룰

룰은 컨디션을 and, or 연산자로 묶어 줍니다. 아래와 같은 특징을 가집니다.

• 룰을 모두 만족할 경우 값을 내줍니다
• 우선 순위 조정이 가능합니다
• 사용자 타겟팅을 조정할 수 있습니다

ex) platform == ios && iOS >= 16.0.0 일 경우만 true를 리턴하는 룰입니다.

 

전체적인 구조 그래프입니다.

하나씩 분리해서 확인해보겠습니다.

NRC에서는 active/storage 데이터를 기반으로 동작합니다. fetch와 active(사용) 시점이 다를 수 있어 인터페이스를 나눠서 제공 중입니다.

(서버에서 룰을 가져오는 것 = fetch, 특정 화면 진입 시까지 사용 안 할 수 있으므로 fetch와 사용 시점이 다를 수 있습니다. 예를 들어 마이페이지 진입시에 사용하는 룰은 홈 화면에서 필요가 없겠지요)

 

NRC는 value를 제공할 뿐만 아니라 타입 컨버팅의 역할을 수행합니다.

 

Auto Hooking을 통해 다양한 이벤트 시점을 훅킹하고 원하는 시점에 이벤트 실행이 가능합니다.

 

NCE 이벤트 후킹 방식은 다음과 같습니다.

 

Screen Enter의 경우 라이프 사이클 함수를 상속받은 함수를 통해 이벤트를 훅킹합니다. (iOS에서는 viewDidLoad 생각하면 될 것 같습니다.)

이 경우 기존 로직을 블락킹하는 것이 불가능합니다. (아마 이미 화면에 진입해 로직이 실행되기 때문으로 생각됩니다. viewDidLoad를 생각해보면 NCE를 실행하기 전에 View와 데이터 값을 설정되기 때문으로 추측해봅니다.)

하지만 Screen Enter의 경우 View Click이나 Deep Link를 통해 화면 진입 전에 처리 할 수 있어 큰 문제는 되지 않습니다.

 

BCI (Bytecode Instrumantation)는 컴파일 되는 과정에서 바이트 코드에 접근하여 코드를 수정하는 방법입니다.

안드로이드에서 Transform이라는 Gradel API를 제공해 특정 함수를 원하는 대로 수정 대체해줍니다.

 

(기존 코드를 수정하지 않고 BCI를 사용해 이벤트 훅킹 함수를 추가해 주는 것 같습니다.)

 

플러그인 내부적으로 Call.eqeueue 함수를 찾아 교체해줍니다.

Network I/O을 이런식으로 호출해 코드를 직접 수정할 필요가 없습니다!

 

 

4. 사용 사례

API관련 이슈로 네이티브 홈에서 장애가 발생할 경우 웹 View로 전환해줍니다.

웹에서 버튼을 이케이케 눌러주면 앱에서 홈 화면 진입시 자동으로 웹 View로 들어갑니다.

 

이 부분은 영상으로 보는게 더 편하고 이해하기 쉽습니다.

해당 영상 25:42 ~ 부터 확인할 수 있습니다.

 

LiveOps : 네이버앱의 실시간 운영과 크래시 핸들링 솔루션

 

이 외에도 사용하지 못하는 static URL 변경, QR 체크인 장애시 대처 방안, 신규 공지 및 업데이트 유도 등을 영상에서 확인할 수 있습니다.

 

 

5. 도입 효과

배포 프로세스 없이 대응이 가능하므로 리소스를 아낄 수 있고, 실시간 운영이 가능해집니다.

장애 대응도 훨씬 빠르고 간편해졌습니다.

 

앞으로의 계획으로는 점진적 배포, 전략 추가 등이 있습니다.

 

앱이라서 불가능합니다 -> 앱이라서 가능합니다

 

 

 

 

여기까지 LiveOps 였습니다.

기존에 배포 주기를 앞당기기 위한 내용은 많이 봤어도 이번 발표처럼 실시간으로 대응하는 것은 처음 봤는데, 앱의 구조적인 한계를 뛰어넘기 위한 노력이 너무 멋있습니다.

WWDC만 보다가 한국어로 된 발표를 보니 훨씬 이해가 잘되는 것 같습니다 😂

 

끗!