Bucket

대부분의 플래그 도구는 개별 사용자를 기준으로 생각한다. Bucket은 오히려 모든 것을 회사 중심으로 구성한다. 실제로 비용을 내고 갱신하는 주체는 그 계정이다. 고객 계정 전체를 한 번의 동작으로 켤 수 있고, B2B 팀이 보통 원하는 것이 바로 이것이다. 개인이 아니라 팀에 파는 경우 수작업이 크게 줄어든다.

기능을 대상의 아주 작은 일부에 배포하고 동작을 지켜본 뒤 노출을 한 단계씩 늘릴 수 있다. 첫날에 전면 출시를 약속하도록 강요하는 것은 없다. 점진적 배포는 팀이 피처 플래그 플랫폼을 도입하는 핵심 이유다. 작게 시작한다. 나중에 넓힌다.

기능을 출시한다고 해서 누군가 쓰는지는 알 수 없다. Bucket은 사용 데이터를 한 화면에 모아, 어떤 회사가 새 기능을 받아들였고 어떤 회사가 무시했는지 보여준다. 이것이 추측과 확신의 차이다. 대부분의 팀은 추측한다. Bucket은 다르다.

오래된 플래그는 쌓여서 코드를 엉망으로 만든다. Bucket은 오래된 플래그를 보관하고 이를 참조하던 불필요한 코드를 자동으로 제거한다. 죽은 플래그를 하나씩 지우며 오후를 다 보내고, 그사이 프로덕트 매니저는 지난주에 나갔어야 할 데모 빌드를 기다린 경험이 있는 사람이라면 이게 얼마나 홀가분한지 정확히 알 것이다.

SDK는 React, Vue, Next.js, Node.js 등을 지원하고 타입 안전성도 내장돼 있다. 패키지를 설치하고 게시 가능 키를 넘긴 뒤 훅이나 클라이언트 메서드를 호출해 플래그를 확인한다. 설정은 개발자가 원래 코드를 쓰는 방식에 가깝게 유지된다. 새로운 사고 모델은 필요 없다.

엔지니어링 작업이 이미 있는 Linear에서 플래그를 만들고 관리할 수 있고, 플래그 변경을 Slack으로 보내 팀이 상황을 파악하게 할 수 있다. 플래그를 그것을 일으킨 구체적인 이슈에 묶으면 맥락이 한곳에 모인다. 티켓, 커밋 메시지, 다시는 검색되지 않을 Slack 스레드에 흩어지지 않는다.

Bucket은 Model Context Protocol을 지원해서 Cursor, VS Code 같은 편집기의 AI 코딩 에이전트가 플래그를 직접 읽고 관리할 수 있다. 팀이 코드를 쓰는 데 AI 도구를 쓰더라도 그렇게 만들어진 플래그는 여전히 추적하고 검토할 수 있다. 이런 팀은 대부분 이미 플래그를 쓴다. Bucket은 모델의 조준점을 사람이 아니라 계정으로 돌릴 뿐이고, 고객이 기업일 때 바로 그 차이가 중요하다.

켜고 끄는 플래그를 넘어, 구성 값을 원격으로 밀어 넣고 새 코드를 출시하지 않고 동작을 바꿀 수 있다. 킬 스위치는 뭔가 고장 난 순간 모든 사용자에게 그것을 끌 수 있는 레버 하나를 준다. 새벽 2시에 문제가 생겼을 때 그 레버가 바로 핵심이다.