기능을 정식 출시하기 전에 베타 버전을 먼저 출시하여 사용자의 피드백을 수집하고, 성능 및 기능을 테스트 하는 것이 일반적입니다. 하지만 기능 배포 및 제품 출시 사이클이 단축 되어 출시가 훨씬 더 잦아지면서 베타 테스트를 거칠만한 충분한 기간과 리소스가 주어지지 않게 되었습니다.
이에 따라 베타 테스트를 아예 진행하지 않거나 충분한 유저 옵트인(opt-in)을 확보하지 못한채 테스트를 진행할 수 밖에 없어 제한적인 피드백만 수집하는 등 준비가 되지 않은채 출시를 강행하게 되기도 하는데요.
이런 환경 속에서 제대로 베타 테스트를 진행할 방법은 없을까요?
기능 플래그를 활용하면 해결할 수 있습니다.
점진적 출시: 기능 플래그를 이용하면 0%부터 출시 비중을 점진적으로 늘려갈 수 있습니다. 0%에서 1%, 이상이 없으면 5% > 10% > n0% > 100%까지 지속적으로 시스템 이슈와 사용자 피드백을 확인하면서 점진적으로 출시 트래픽을 높여갈 수 있습니다.
사용자 피드백: 점진적 출시 과정에서 사용자 피드백 루프 (feedback loop)을 형성하여 출시 → 사용자 피드백 → 피드백 반영 → 트래픽 확대하여 개선된 서비스 출시의 과정을 반복하면 빠르게, 완성도 높은 제품을 출시할 수 있습니다.
실시간 옵트인(opt-in)/옵트아웃(opt-out): 베타 버전을 출시하게 되면 처음에는 옵트인을 했다가 서비스의 경험이 만족스럽지 않거나, 기대했던 것과 다른 경험 등의 이유로 테스트 중간에 옵트아웃을 하는 사용자들이 생깁니다. 이 때 기능 플래그를 사용하면 간단하게 베타 버전의 온/오프가 가능합니다.
타겟팅 출시: 글로벌 서비스이거나 넓은 범위의 사용자를 아우르는 서비스를 출시할 때에는 베타 테스트도 사용자 특성에 맞춰 진행 하는데요. 이 때 기능 플래그의 파라미터(parameter)를 활용하면 버전별로 배포를 하거나 다국적 서비스라면 국가별 서버를 구축하는 등 번거롭고 추가 비용이 발생하는 과정을 거치지 않고도 맞춤형 베타 서비스 제공이 가능합니다.
권한 부여: 기능 플래그를 사용하는 또 한가지의 이유는 개발팀의 리소스 낭비를 줄이는 데에 있습니다. 기능 플래그를 생성하여 출시한 베타 버전에 걸고, 운영 부서나 출시 결정을 내리는 유관 부서 담당자에게 기능 플래그 키에 대한 접근 권한을 제공함으로써 비즈니스 의사결정이 변경될 때마다 시스템에 반영하기 위해 투입되었던 개발팀의 리소스를 줄일 수 있습니다.
.png)
.png)
