A/B 테스트와 기능 플래그는 사용자마다 다른 화면을 보여주는 도구입니다. 그 결정을 어디에서 하느냐에 따라 로컬 평가와 원격 평가로 나뉩니다. 우리 서비스에는 어느 쪽이 맞는지, 질문 하나로 정리했습니다.
같은 서비스를 쓰고 있어도 모든 사용자가 같은 화면을 보지는 않습니다. 어떤 사용자에게는 실험 중인 새 홈 화면이 보이고, 어떤 사용자에게는 아직 공개 전인 기능이 먼저 열려 있고, 어떤 사용자에게만 할인 안내 인앱 메시지가 뜹니다.
A/B 테스트, 기능 플래그, 원격 구성, 인앱 메시지는 모두 이런 차이를 만드는 도구입니다. 도구는 달라도 하는 일의 본질은 같습니다. 사용자 정보를 보고, 정해둔 규칙에 따라, 이 사용자에게 무엇을 적용할지 정하는 것. 핵클에서는 이 결정을 평가(evaluation) 라고 부릅니다.
그렇다면 평가는 어디에서 이루어질까요? 두 곳 중 하나입니다. 사용자가 쓰는 앱이나 브라우저(이하 클라이언트) 안에서 이루어지면 로컬 평가, 핵클 서버에서 이루어지면 원격 평가입니다.
그렇다면 어느 쪽을 선택해야 할까요? 기준은 생각보다 단순합니다. 이 질문 하나면 대부분 정리됩니다.
“평가의 기준이 되는 사용자 정보는 어디서 바뀌는가?”
평가의 기준이 되는 정보가 클라이언트에서 바뀐다면 로컬 평가가, 클라이언트가 모르는 채 핵클 서버에서 갱신되는 정보라면 원격 평가가 더 효율적인 방식입니다.
같은 기능을 어느 방식으로도 만들 수 있는데 추천이 갈리는 이유는, 사용자 정보를 다루는 동작이 다르기 때문입니다. 요약하면, 로컬 평가는 클라이언트에서 바뀐 값을 서버에 묻지 않고 다음 판단에 바로 반영하고 원격 평가는 핵클 서버에 저장된 최신 값을 그대로 반영합니다.
로컬 평가는 평가에 쓸 규칙 전체를 핵클 서버에서 미리 내려받아 두는 방식입니다. 앱이나 웹이 열리면서 핵클 SDK가 준비될 때 규칙을 받아 둡니다. 그래서 어떤 사용자에게 무엇을 보여줄지 정해야 하는 순간에는, 서버에 묻지 않고 클라이언트 안에서 바로 판단합니다.
원격 평가는 그 판단을 핵클 서버가 맡는 방식입니다. 사용자 정보가 바뀌면 SDK가 바뀐 내용을 핵클 서버로 보내고, 핵클 서버가 다시 계산한 결과를 받아 저장해 둡니다. 평가 규칙은 핵클 서버에만 있습니다.
오해하기 쉬운 부분이 하나 있습니다. 원격 평가라고 해서 화면을 그릴 때마다 서버를 호출하는 것은 아닙니다. 서버와 통신하는 시점은 사용자 정보가 바뀔 때뿐이고, 평소에는 저장해 둔 결과를 바로 사용합니다. 그래서 화면은 빠르게 그려집니다.
실제 시나리오로 살펴보겠습니다.
커머스 앱의 온보딩을 예로 들어보겠습니다. 신규 사용자가 관심 카테고리를 고르면, 바로 다음 화면부터 그 관심사에 맞춰 홈 구성을 다르게 보여주는 A/B 테스트를 하려고 합니다. 패션을 고른 사용자에게는 패션 중심 홈을, 리빙을 고른 사용자에게는 리빙 중심 홈을 보여주고, 절반에게만 적용해서 효과를 확인하는 실험입니다.
여기서 평가의 기준이 되는 정보, 즉 관심사는 사용자가 앱 안에서 방금 만든 정보입니다.
로컬 평가에서는 이 작업이 한 번에 이어집니다. 관심사를 고르는 순간 그 값이 SDK에 즉시 반영되고, 다음 화면의 판단은 이미 내려받아 둔 규칙으로 서버에 묻지 않고 이루어집니다. 다음 화면은 기다림 없이 실험이 적용된 상태로 열립니다. 관심사를 고른 사용자에게만 열리는 기능이 있다면, 그 기능 플래그도 같은 순간에 켜집니다.
같은 실험을 원격 평가로 하면 어떨까요? 사용자 정보가 바뀔 때마다 핵클 서버가 다시 계산해야 합니다. 온보딩처럼 사용자의 선택에 따라 정보가 연달아 바뀌는 화면에서는, 화면이 넘어갈 때마다 서버에 한 번 다녀오는 시간이 끼어듭니다. 동작은 하지만, 가장 매끄러워야 할 첫인상 구간의 응답 속도가 통신 품질에 좌우됩니다.
이러한 상황에서는 로컬 평가가 효율적입니다. 위 시나리오와 같이 로그인, 관심사 선택, 장바구니 담기, 구매처럼 클라이언트에서 만들어지는 정보로 바로 다음 순간의 화면과 기능을 결정해야 할 때 주로 로컬 평가를 사용합니다. 앱 버전이나 디바이스 OS, 화면 경로처럼 기기가 이미 가지고 있는 정보로 대상을 나눌 때도 마찬가지입니다.
이번에는 반대 상황입니다. 회원 등급이 있는 서비스를 생각해 보겠습니다. 등급은 매일 새벽에 백엔드가 누적 구매액을 집계해서 산정하고, 산정된 등급은 [사용자 속성 API]나 [CSV 업로드]로 핵클 서버에 사용자 정보로 올려 둡니다. 마케팅팀이 "VIP 등급에게만 새 혜택 공간을 먼저 열어주자" 고 제안했습니다. 기능 플래그로 대상을 지정해서 켜면 되는 일입니다.
여기서 평가의 기준이 되는 정보, 즉 등급은 클라이언트가 모르는 정보입니다. 백엔드가 만들어 핵클 서버에 저장해 둔 값일 뿐, 사용자의 앱은 자기 등급을 모릅니다.
로컬 평가는 클라이언트가 알고 있는 정보로 판단합니다. 그래서 이 기능을 열려면 등급을 앱까지 옮겨오는 일이 먼저 필요합니다. 등급을 내려주는 API를 만들고, 앱이 그 값을 받아 사용자 정보로 설정하는 식입니다. 대상 조건으로 쓰고 싶은 서버 정보가 늘어나면 그만큼 옮겨오는 일도 늘어나고, 경우에 따라 앱 업데이트가 함께 필요해집니다.
원격 평가는 값을 옮겨오지 않아도 되는 쪽을 택합니다. 판단이 핵클 서버에서 이루어지니까, 핵클 서버에 저장된 최신 등급이 그대로 반영됩니다. 새벽에 등급이 갱신되면 그날 기능이 열리는 대상도 함께 바뀝니다. 앱은 고칠 것이 없고, 배포할 것도 없습니다. 등급별로 다른 할인율을 내려주는 원격 구성이든, VIP만 대상으로 한 A/B 테스트나 인앱 메시지든 마찬가지입니다.
이러한 상황에서는 원격 평가가 효율적입니다. 이번 시나리오의 등급처럼 클라이언트는 모르지만 핵클 서버에는 저장되어 있는 정보로 기능을 열거나, 실험 대상을 나누거나, 구성 값을 정해야 할 때 주로 원격 평가를 사용합니다.
평가의 기준이 되는 사용자 정보가 어디서 바뀌는지를 먼저 확인하면 쉽게 어떤 방식을 사용하는 것이 효율적일지 판단할 수 있습니다.
핵클 SDK에서 두 방식을 바꾸는 일은 SDK를 준비할 때 설정 항목 하나(evaluationMode)를 지정하는 것으로 이루어지고, A/B 테스트와 기능 플래그, 원격 구성, 인앱 메시지를 만들고 운영하는 방법은 두 방식 모두 동일합니다. 플랫폼별 설정 방법과 지원하는 SDK, 자세한 동작은 아래 문서에서 확인할 수 있습니다.
.png)
