Cloudflare Flagship

네트워크 왕복이 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에 기대면 클라이언트 라이브러리에 간단한 타기팅 규칙 평가 엔진이 통합되어 있음

회사에서 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 경쟁자를 만들자고 진지하게 판단했을 리는 없어 보임

OpenFeature를 많이 써봤고, 몇몇 클라이언트 라이브러리에 초기 커밋도 했음. 기능 플래그의 미래가 맞고, 생태계도 빠르게 성장 중임
투명하게 밝히면 Flagsmith의 CTO임. 지난 몇 년간 OpenFeature 도입이 확실히 늘어나는 곡선을 봤음. 예전에는 우리가 고객에게 써보라고 권했지만, 이제는 고객이 OpenFeature를 요구사항으로 들고 옴
이제 벤더 지원도 꽤 성숙했고 거의 모든 언어를 포괄함. 새 서비스에 기능 플래그를 통합하거나 자체 구현에서 서드파티 솔루션으로 옮기려는 상황이라면 OpenFeature를 추천함

꽤 유용함. 이전 회사에서 썼고, 커스텀 백엔드를 만들되 명세와 SDK는 OpenFeature를 사용했음
완전한 커스텀 백엔드를 만드는 데 2주 정도 걸렸음. 여러 언어용 SDK도 문제없이 동작했음. 버그 하나를 찾긴 했지만 보고하자 당일에 고쳐졌음

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

플래그 자체가 Boolean이든 문자열이든 숫자든 다른 무엇이든 그건 쉬운 부분임. 어려운 건 타기팅과 롤아웃 규칙, 즉 누가 어떤 플래그를 보게 되는지와 그 규칙을 매우 빠르고 일관되게 평가해야 한다는 요구사항임
직접 만든 팀들은 보통 제품 관리, 마케팅, 영업에서 더 복잡한 규칙으로 타기팅하고 싶어 하면서 문제가 빠르게 커지는 걸 겪음
전체적인 난이도로 보면 특별히 어려운 문제는 아니지만, 규모가 큼. 처음에는 보이지 않는 기능이 많이 필요함
기능 플래그는 본질적으로 권한 시스템에 가깝다고 볼 수 있음. 특정 사용자만 특정 기능에 접근하게 하는 것이고, 권한 시스템을 다뤄본 사람은 그룹 멤버십, 계층적 그룹, 역할, ACL 등이 얼마나 복잡해지는지 앎. 이런 요소들은 기능 플래그 시스템의 다양한 타기팅 규칙과 유사함

퍼센트 롤아웃, RBAC, 감사 이력, A/B 테스트, 다변량 설정까지 들어가면 빠르게 복잡해짐. 그 Boolean 하나가 유지·운영해야 하는 전체 시스템으로 변함

항상 Boolean인 것은 아님. 예를 들어 기능 플래그가 A/B 롤아웃에 자주 쓰임
Cloudflare도 내부적으로 새 기능이나 빌드를 무료 고객에게 먼저 배포하고, 안정화 기간 뒤 더 큰 고객에게 점진적으로 넓히는 방식으로 사용함
기능 플래그는 일종의 퍼즈 테스트처럼 무작위로 켤 수도 있음. “새로운 것”만 생각하지 말고 “동작 변경”일 수도 있다고 보면 됨
모든 클라이언트 위의 Boolean이라고 생각할 수도 있겠지만, 일반적으로 그렇게 구현되지는 않음

데이터베이스의 Boolean으로 구현할 수 있으니, 그건 단지 구현 세부사항임
기능 플래그의 주된 매력은 몇 달과 많은 커밋이 필요한 큰 기능도 메인 브랜치에서 작업할 수 있게 해준다는 점임. 내게는 더 가볍고 반복적인 개발 프로세스를 만들어 줌
별도 브랜치를 유지하고, 큰 개발 중 기능을 위해 별도 배포 대상까지 두는 방식과 대비됨

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

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

기능 플래그의 핵심은 규율임. 목적을 가지고 만들고, 더 이상 가치가 없으면 즉시 제거해야 함. KISS가 적용됨

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

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

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