Cloudflare Flagship, 기업 고객 중 베타 사용자에게만 기능 켜기

요금제와 베타 태그를 한 규칙으로 묶는다

기업 요금제를 쓰는 고객 중 베타 프로그램 참여자에게만 새 결제 화면을 열려면 두 조건이 모두 맞아야 한다. Flagship에 profile.plan equals "enterprise"와 tags has "beta"를 AND 조건으로 두고, 일치하면 켜짐 값을 반환하도록 설정한다. 기본값은 꺼짐으로 두며 다른 사용자에게 켜짐을 주는 규칙도 없어야 한다.

10월 23일 추가된 구조화 평가 문맥은 이런 조건에 쓰는 사용자 정보를 원래 모양으로 전달하게 해 준다. 프로필 안의 요금제를 따로 최상위 필드로 옮기거나 태그 목록을 문자열 하나로 합칠 필요가 줄었다.

연산자의 방향은 구별해야 한다. tags has "beta"는 사용자의 배열에 beta가 있는지 검사한다. plan in ["enterprise", "business"]는 사용자의 단일 요금제가 지정한 목록에 속하는지 검사한다. 문자열 일부를 찾는 contains를 태그 배열 검사에 대신 쓰지 않는다.

Workers에서는 중첩 객체를 그대로 전달한다

이미 FLAGS 바인딩과 new-checkout 불리언 플래그를 연결했다면 다음 형태로 평가할 수 있다. 예시의 사용자 식별자·요금제·태그는 애플리케이션에서 확인한 값으로 채운다.

const enabled = await env.FLAGS.getBooleanValue("new-checkout", false, {
  targetingKey: "customer-107",
  profile: { plan: "enterprise" },
  tags: ["beta"]
});

Workers 밖에서 직접 평가 API를 호출한다면 객체·배열을 JSON 본문에 담은 POST를 사용한다. GET 쿼리에 JSON처럼 생긴 문자열을 넣어도 중첩 객체로 바뀌지 않는다. API 토큰에는 Flagship Read·Write·Evaluate 중 적어도 하나의 권한이 필요하다.

TypeScript·Python·Go SDK는 0.6.0부터 구조화 문맥을 지원한다. SDK는 HTTP 평가에 구조화 값이 들어오면 POST로 보낸다. 기존 SDK를 쓰는 프로젝트라면 데이터 구조뿐 아니라 설치한 버전도 함께 맞춰야 한다.

조건이 맞아도 앞선 규칙이 결과를 결정할 수 있다

Flagship은 위에서부터 규칙을 평가하고 첫 일치 결과를 사용한다. 모든 기업 고객에게 꺼짐을 주는 규칙이 먼저 있다면, 뒤에 둔 기업 베타 고객 규칙까지 도달하지 않는다. 구체적인 대상을 고르는 규칙을 넓은 규칙보다 앞에 둬야 한다.

플래그 자체가 비활성 상태면 기본 변형을 반환한다. 아무 규칙에도 맞지 않을 때도 기본 변형을 사용하므로, 플래그의 활성 상태와 기본값을 따로 확인해야 한다.

데이터 이름도 결과를 바꾼다. 조건에 필요한 속성이 없으면 부정 연산에서도 일치하지 않는다. 최상위에 점을 포함한 profile.plan 키와 중첩 profile 객체가 동시에 있으면 최상위의 정확한 키가 우선한다. 옛 평탄화 필드와 새 객체를 함께 보내는 전환 과정에서 특히 살필 부분이다.

베타 그룹 일부부터 켜려면 사용자 ID를 고정한다

대상 조건을 만든 뒤 비율 배포를 붙일 수 있다. 같은 배포 설정에서 동일한 사용자가 같은 결과를 받으려면 targetingKey 같은 고정 식별자를 제공한다. 중첩 profile.id를 배정 기준으로 지정하는 방법도 있다.

해당 비율에 들지 않은 사용자는 다음 규칙으로 넘어간다. 뒤쪽 규칙이 그 사용자에게 다시 기능을 켜 주는지도 확인해야 한다. 배정 기준 값이 없거나 null이면 평가할 때마다 무작위로 배정되므로, 사용자에게 보이는 기능에는 안정적인 ID가 필요하다.

처음 적용할 때는 기업 베타 고객, 기업 일반 고객, 비기업 베타 고객을 각각 설명용 테스트 조건으로 잡을 수 있다. 세 경우의 결과를 나란히 보면 ‘기업 고객 중 베타 참여자만’이라는 의도가 실제 규칙에 반영됐는지 확인하기 쉽다.