▲

Cloudflare Flagship

 (developers.cloudflare.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Cloudflare Flagship은 코드 재배포 없이 애플리케이션의 기능 노출을 제어하는 Cloudflare의 기능 플래그 서비스임
  • 플래그는 타기팅 규칙과 비율 기반 롤아웃으로 정의되며, Workers 네이티브 바인딩에서 직접 평가 가능함
  • OpenFeature와 호환되고 @cloudflare/flagship SDK로 Workers, Node.js, 브라우저에서 플래그를 평가할 수 있음
  • 타기팅은 사용자 속성, 11개 비교 연산자, AND/OR 그룹화, 순차 평가를 지원하며 일관 해싱으로 값을 유지함
  • 변형은 불리언, 문자열, 숫자, JSON 객체를 지원하고 Cloudflare 대시보드에서 앱 단위로 생성·수정·삭제됨

주요 기능

  • Workers 바인딩

    • Binding reference
    • Workers의 네이티브 바인딩으로 플래그를 평가함
    • 타입 안전 메서드와 기본값 자동 폴백을 제공함

  • OpenFeature SDK

    • View SDK docs
    • @cloudflare/flagship OpenFeature provider로 Workers, Node.js, 브라우저에서 플래그를 평가할 수 있음
    • 다른 플래그 공급자에서 전환할 때 설정 한 줄만 바꾸면 됨

  • 타기팅 규칙

    • Learn about targeting
    • 사용자 속성에 따라 서로 다른 플래그 값을 제공함
    • 규칙은 11개 비교 연산자, 논리 AND/OR 그룹화, 순차 평가를 지원함

  • 비율 기반 롤아웃

    • Learn about rollouts
    • 기능을 사용자 비율에 맞춰 점진적으로 출시할 수 있음
    • 일관 해싱으로 같은 사용자가 항상 같은 플래그 값을 받도록 보장함

  • 다중 타입 변형

    • Use Multi-type variations
    • 플래그 변형은 불리언, 문자열, 숫자, 구조화된 JSON 객체가 될 수 있음
    • 객체 변형을 사용하면 전체 설정 블록을 하나의 플래그로 전달할 수 있음

  • 플래그 관리

    • Use Flag management
    • Cloudflare 대시보드에서 플래그를 생성, 업데이트, 삭제할 수 있음
    • 플래그를 프로젝트나 서비스에 매핑되는 앱으로 구성함
    • 첫 기능 플래그는 Get started guide에서 생성할 수 있음

관련 Cloudflare 서비스

  • Workers: Cloudflare의 글로벌 네트워크에서 서버리스 애플리케이션을 구축하며, Flagship은 바인딩으로 Workers와 네이티브 통합됨
  • KV: Cloudflare의 글로벌 네트워크 전반에 키-값 데이터를 저장하며, Flagship은 이 인프라를 사용해 플래그 설정을 전달함

함께 보면 좋은 글 β

▲
GN⁺   [-]
Hacker News 의견들

  • 네트워크 왕복이 0번인 추상화를 과소평가하면 안 됨. f(feature_name, context) 위에서 컨텍스트는 특정 재고, 특정 공급사, 특정 B2B 고객의 특정 사용자, 특정 비즈니스 모델 하위 유형, 특정 시간대의 표시 여부까지 아주 세밀하게 맞출 수 있음
    직접 로직을 쓰고 상수처럼 빠르게 tight loop에서 실행할 수 있으면 비즈니스 민첩성이 크게 올라감. 일부 고객에게 문구가 바뀔 수 있다고 생각되면 설정 가능하게 코드로 만들면 되고, 테스트와 플래그도 자연스럽게 따라옴
    다만 이런 0-hop 구성에는 정교한 클라이언트 실행 엔진이 필요한데, Cloudflare가 여기서 구현한 것 같지는 않음. 메모리 제약이 있는 Workers에서는 이해되지만, 전통적 인프라에서는 덜 납득됨
    Statsig 방식은 꽤 마음에 듦: “Server SDKs hold the entire ruleset of your project in memory...”라는 접근임
    https://docs.statsig.com/sdks/how-evaluation-works
    직접 만들 수도 있음. 몇 초마다 백그라운드 스레드에서 규칙 집합을 몇 가지 자료구조로 동기화하고 참조를 원자적으로 교체하면 됨. 그다음 적용 규칙 차원에 대한 CRUD 인터페이스만 있으면 됨
    단, 누가 어떤 상수 후보를 만질 수 있는지에 대한 거버넌스는 꼭 필요함. 큰 힘에는 큰 책임이 따름

    • 이 내용을 읽으면 기능 플래그가 애플리케이션 설정/커스터마이징으로 오용되는 패턴이 떠오름. 여러 조직에서 이미 관찰한 안티패턴임
      기능 플래그는 트렁크 기반 개발과 함께 QA 환경에서 기능을 켜고, 운영에는 아직 내보내지 않으며 PO/PM 테스트를 가능하게 하는 용도에 가깝다고 봄. 트렁크 기반 개발은 복잡한 브랜치 전략 없이 빠르고 쉬운 DevOps를 가능하게 함
      반면 애플리케이션 설정은 애플리케이션의 일부이고, 비즈니스 맥락에 맞춰 앱을 커스터마이즈하는 영역임. 관련 프레임워크나 도구가 있는지는 모르겠지만, 둘은 명확히 구분해야 함
    • 구현 자체는 어렵지 않음. Mersenne Twister 같은 것에 모듈로 연산을 얹는 수준인데, 최근 일에서는 Flipper와 선택적인 “현재 플래그 테이블 상태” 엔드포인트만으로 충분했음
      그 모듈로+난수 조합 때문에 LaunchDarkly 같은 도구가 여러 언어용 SDK를 제공해야 했고, 내가 다뤄야 했던 SDK들은 해당 언어에 전혀 잘 맞지 않았음. 평가를 엣지로 밀어낸 탓에 전체 시스템이 필요 이상으로 복잡해졌다고 봄
      실제로는 “이 고객에 대한” 현재 플래그 테이블을 가끔 다시 가져오는 정도가 충분하고, 훨씬 덜 성가심. Flipper가 있어서 이제 이런 걸 직접 다루지 않아도 되어 다행임
    • 그 0-hop 구성이 꼭 정교할 필요도 없고, Cloudflare가 직접 구현할 필요도 없음. OpenFeature에 기대면 클라이언트 라이브러리에 간단한 타기팅 규칙 평가 엔진이 통합되어 있음
    • 좋은 조언임. 덧붙이면 기능 플래그, A/B 테스트, 권한 부여는 서로 다른 세 개념임. 이 글의 프레이밍이 도움이 되었음
      https://www.stigg.io/blog-posts/entitlements-untangled-the-m...
    • 회사에서 Statsig를 잘 쓰고 있음. 완성도 높고 기능도 풍부함. 사용하지 않는 플래그를 제거 후보로 찾아주는 도구가 꽤 괜찮음
      계약상 좌석당 과금은 조금 빡세지만 감당 가능한 수준임

  • 금칠한 Boolean-as-a-service 같음

    • 회사에서 이런 Boolean-as-a-service를 제대로 제공하지 못해 팀 전체가 실패하는 걸 봤음. LaunchDarkly 같은 회사가 따로 존재하는 데는 이유가 있음
      이렇게 단순화하면 세상의 모든 서비스도 bits-as-a-service로 환원할 수 있음. 실제로는 이런 것들에 정당한 비즈니스 가치가 있고, 제공 과정에도 복잡성이 있음
    • 괜찮다고 봄. 데이터베이스에서 수천 개의 기능 플래그를 추적하고, 관리자 대시보드를 만들고 싶지는 않음
      어떤 SaaS 도구든 “excel-as-a-service”라고 부를 수 있고, 그 정도의 효과밖에 없는 표현임
    • 그 Boolean을 정확한 시간에 정확한 위치로 안정적으로 전달하는 건 사소하지 않음

  • JS SDK 문서를 보면 이런 경고가 있음: “클라이언트 provider는 플래그 값을 가져오려면 API 토큰이 필요하다. 이 토큰은 단일 앱에 한정되지 않으므로 토큰을 가진 누구나 계정 내 모든 앱의 플래그를 평가할 수 있다. 공개 애플리케이션에서는 주의해서 사용하라”
    https://developers.cloudflare.com/flagship/sdk/client-provid...
    브라우저에 배포되도록 설계된 클라이언트 SDK가 왜 주의가 필요한지 궁금함. 어떤 클라이언트든 새 targetingKey로 요청을 보내 다른 사용자의 플래그를 관찰할 수 있다는 뜻인가?
    플래그가 중요 정보를 담아서는 안 되겠지만, 흥미로운 설계 선택으로 보임

    • 아마 Cloudflare 내부에서 쓰던 것을 누군가 공개하면 재미있겠다고 생각한 것 같음
      6개월 전에 Cloudflare가 LaunchDarkly 경쟁자를 만들자고 진지하게 판단했을 리는 없어 보임
    • Flagship 팀 엔지니어임. 앱 범위 토큰은 작업 중임

  • 이건 좋지만, 아이러니하게도 아마 Flagship을 써서 제공될 이 기능이 아직 나오길 기다리는 중임
    https://blog.cloudflare.com/enterprise-grade-features-for-al...
    아직 엔터프라이즈 전용 기능이 하위 유료 계정으로 내려온 사례는 하나도 없는 것 같음
    특히 관심 있는 건 이것임:
    https://developers.cloudflare.com/speed/optimization/content...

    • 맞음. Zero Trust 엔터프라이즈 기능이 너무 필요해서 결국 엔터프라이즈 영업 담당자와 직접 이야기해야 할 상황임. 시간이 많이 들고 피하고 싶은 스트레스가 생길 듯함

  • 요즘 Cloudflare가 잘하고 있지만, 세밀한 권한 관리가 부족함. 아직도 운영 환경용으로 완전히 별도 계정을 만들어야 하고, 도메인 하나가 계정 하나에만 묶일 수 있어서 SSO가 꼬임

    • 제품은 멋지고 오랫동안 만족하며 썼지만, 최근 블로그에서는 몇 번 실수가 있었음. 안정성도 한동안 흔들리는 것 같았는데 최근에는 좀 나아진 듯함
    • AWS를 몇 년 쓰다가 Cloudflare를 써봤고 사용자 경험은 마음에 들었지만, 같은 우려 때문에 결국 돌아갔음. 정말 거의 다 왔는데 아쉬움
    • 몇 년 전 모든 프로젝트를 Cloudflare로 옮겼고 후회하지 않음. Workers, D1, R2, Queues, Containers, KV를 쓰고 있음
      이메일 발송은 아직 AWS를 쓰고 있어서, Cloudflare 쪽에 생기면 좋겠음
    • 나도 오늘 더 세밀한 권한을 요청하는 지원 티켓을 열었음
    • 이게 실제 업무에 Cloudflare를 쓰지 못하게 막는 정확한 이유임. 취미용 무료 티어는 좋아함

  • OpenFeature는 처음 알았는데 멋짐. 통합해 본 경험 있는 사람 있나? https://openfeature.dev

    • OpenFeature를 많이 써봤고, 몇몇 클라이언트 라이브러리에 초기 커밋도 했음. 기능 플래그의 미래가 맞고, 생태계도 빠르게 성장 중임
      투명하게 밝히면 Flagsmith의 CTO임. 지난 몇 년간 OpenFeature 도입이 확실히 늘어나는 곡선을 봤음. 예전에는 우리가 고객에게 써보라고 권했지만, 이제는 고객이 OpenFeature를 요구사항으로 들고 옴
      이제 벤더 지원도 꽤 성숙했고 거의 모든 언어를 포괄함. 새 서비스에 기능 플래그를 통합하거나 자체 구현에서 서드파티 솔루션으로 옮기려는 상황이라면 OpenFeature를 추천함
    • 꽤 유용함. 이전 회사에서 썼고, 커스텀 백엔드를 만들되 명세와 SDK는 OpenFeature를 사용했음
      완전한 커스텀 백엔드를 만드는 데 2주 정도 걸렸음. 여러 언어용 SDK도 문제없이 동작했음. 버그 하나를 찾긴 했지만 보고하자 당일에 고쳐졌음

  • 기능 플래그를 잘 이해하지 못하겠음. 데이터베이스의 Boolean과 근본적으로 뭐가 다른가?

    • 플래그 자체가 Boolean이든 문자열이든 숫자든 다른 무엇이든 그건 쉬운 부분임. 어려운 건 타기팅과 롤아웃 규칙, 즉 누가 어떤 플래그를 보게 되는지와 그 규칙을 매우 빠르고 일관되게 평가해야 한다는 요구사항임
      직접 만든 팀들은 보통 제품 관리, 마케팅, 영업에서 더 복잡한 규칙으로 타기팅하고 싶어 하면서 문제가 빠르게 커지는 걸 겪음
      전체적인 난이도로 보면 특별히 어려운 문제는 아니지만, 규모가 큼. 처음에는 보이지 않는 기능이 많이 필요함
      기능 플래그는 본질적으로 권한 시스템에 가깝다고 볼 수 있음. 특정 사용자만 특정 기능에 접근하게 하는 것이고, 권한 시스템을 다뤄본 사람은 그룹 멤버십, 계층적 그룹, 역할, ACL 등이 얼마나 복잡해지는지 앎. 이런 요소들은 기능 플래그 시스템의 다양한 타기팅 규칙과 유사함
    • 퍼센트 롤아웃, RBAC, 감사 이력, A/B 테스트, 다변량 설정까지 들어가면 빠르게 복잡해짐. 그 Boolean 하나가 유지·운영해야 하는 전체 시스템으로 변함
    • 자세한 글은 여기 있음: https://martinfowler.com/articles/feature-toggles.html
    • 항상 Boolean인 것은 아님. 예를 들어 기능 플래그가 A/B 롤아웃에 자주 쓰임
      Cloudflare도 내부적으로 새 기능이나 빌드를 무료 고객에게 먼저 배포하고, 안정화 기간 뒤 더 큰 고객에게 점진적으로 넓히는 방식으로 사용함
      기능 플래그는 일종의 퍼즈 테스트처럼 무작위로 켤 수도 있음. “새로운 것”만 생각하지 말고 “동작 변경”일 수도 있다고 보면 됨
      모든 클라이언트 위의 Boolean이라고 생각할 수도 있겠지만, 일반적으로 그렇게 구현되지는 않음
    • 데이터베이스의 Boolean으로 구현할 수 있으니, 그건 단지 구현 세부사항임
      기능 플래그의 주된 매력은 몇 달과 많은 커밋이 필요한 큰 기능도 메인 브랜치에서 작업할 수 있게 해준다는 점임. 내게는 더 가볍고 반복적인 개발 프로세스를 만들어 줌
      별도 브랜치를 유지하고, 큰 개발 중 기능을 위해 별도 배포 대상까지 두는 방식과 대비됨

  • 기능 플래그는 종종 지나치게 과하게 설계됨
    설정값, 데이터베이스 값, 환경 변수를 확인해서 동적으로 한 경로 또는 다른 경로로 가면 됨
    그게 전부임. 기능을 작게 만들거나, 높은 수준에서 쉽게 전환할 수 있도록 코드를 리팩터링해야 함
    그렇게 쉽게 할 수 없다면, 마이크로서비스 간 기능 활성화를 조정하기 위해 복잡한 기능 플래그 구현이 도움이 될 수는 있음
    기능이 많다면 대시보드도 유용할 수 있음
    하지만 둘 다 기능 플래그를 피해야 한다는 강한 신호라고 봄. 기능 플래그는 로컬하고 임시적인 변경에 더 잘 맞고, 그렇지 않으면 복잡성이 누적되어 관리와 유지보수가 어려워짐

    • 특정 세그먼트, 예를 들어 이탈리아의 저매출 사용자에게 기능을 켜서 비즈니스나 성능 영향을 볼 수 있게 하는 데는 타당성이 있음
      물론 사용자가 매출 기준을 넘거나 국경을 넘었다고 기능을 잃게 하고 싶지는 않을 테니, 어떤 식의 추적 구현이 필요함. 분석과 오류 추적도 기능 플래그 서비스와 통신해야 함
      로켓 과학은 아니지만 환경 변수보다는 확실히 복잡함
    • 기능 플래그의 핵심은 규율임. 목적을 가지고 만들고, 더 이상 가치가 없으면 즉시 제거해야 함. KISS가 적용됨

  • Cloudflare가 기존에 다른 제공업체를 써야 했던 것을 제공하기 시작하면 항상 기대됨. 탄탄할 것이라는 신뢰가 있음
    Function에서는 Statsig를 썼음. 처음에는 한 제품에서 두 명이 쓰기 시작했는데, 12개월 안에 제품 문구와 롤아웃의 상당 부분이 Statsig로 구동되었음
    Statsig는 클라이언트 측 평가가 있어서, Statsig 서버가 사용자 데이터를 처리하지 않아도 내부 개념 기반으로 규칙과 롤아웃을 작성할 수 있음
    Cloudflare가 여기서 정교한 제품을 만들어 줘서 앞으로 다른 제품을 쓰지 않아도 되길 바람

    • 기능 플래그를 서드파티에 맡긴다는 게 의아함. 모든 걸 직접 만들자는 편은 아니지만, 기능 플래그는 직접 만드는 데 큰 문제가 없었음

  • 기술적인 세부 사항은 잘 모르는 평범한 사용자지만, Cloudflare는 비교적 쓰기 쉽다고 느껴짐. 계속 잘해줬으면 함

    • 지금까지 써본 DNS 등록기관 중 최고임
답변달기