🤔 피쳐 플래그

https://flags-sdk.dev/

Flags SDK

 

우리 팀은 여러 환경에서 동일한 코드베이스를 사용하면서 환경 변수를 통해 기능을 제어하고 있다. 예를 들어, A 프로젝트, B 프로젝트, C 프로젝트에 따라 동일한 기능을 비활성화하거나 활성화시켜 유저들에게 보여주고 있다. 이 방식도 기본적으로 유용하지만, 배포 주기나 일정에 유연하게 대응하기 어렵기 때문에 배포와 기능 관리의 유연성이 더 필요한 상황이다. 또, 문제가 발생했을 때 빠른 롤백이나 점진적인 배포가 어려워 리스크 관리가 힘든 상황이다. 이런 문제를 해결하기 위해 팀에서 피쳐 플래그 도입을 고려하고 있다고 해서 간단하게 살펴보았다. 

(라이브러리 설명은 이미 문서화되어 있어 따로 적지 않았다.)

피쳐 플래그를 사용하면 좋은 점

1. 기능 제어

피쳐 플래그를 사용하면 기능 제어에 관한 장점이 많이 언급된다. 하지만 사실 현재 우리가 사용하고 있는 환경 변수 방식과 큰 차이가 없다고 느껴지기도 한다. 환경 변수도 결국 기능을 활성화/비활성화하는 방식이기 때문이다. 다만, 피쳐 플래그는 더 디테일한 관리를 가능하게 해 줄 것 같다.

예를 들어, QA 검증 중인 기능이라면, 피쳐 플래그를 사용하면 해당 기능을 특정 환경에서만 활성화하고, QA 검증이 완료되지 않은 기능은 숨길 수 있다. 이렇게 기능의 노출 여부를 제어할 수 있기 때문에, 더 세밀한 관리가 가능하다. (++ 환경 변수 관리 방식은 단순히 활성화/비활성화만 하게 되어, 기능을 활성화하거나 비활성화하는 데 있어 피쳐 플래그보다는 좀 더 포괄적인 방식이 될 수 있다.)

개인적인 생각으로는, QA 검증 중인 기능은 프로덕션에 나가지 않는 것이 맞다고 본다. 그렇기 때문에 매주 정기 배포일을 체크하고, 내 에픽이 올려져도 되는지 QA 팀과 논의하는 시간이 필요하다. 또한, 배포 전에 내 에픽이 어디에 배포되는지 더블 체크하는 과정이 필요하다.

하지만 현재 우리 팀의 상황은 정기적인 배포 외에도 외부 요청으로 갑자기 Stage 환경에 있는 A 에픽을 더 빨리 배포해야 하는 경우도 발생하는데 이때, Stage에 다른 B 에픽이 검증 중이라면, A 에픽을 체리픽하거나 B 에픽을 급하게 가리는 작업을 다시 해야 한다. 하지만 피쳐 플래그를 사용하면 ON/OFF만으로 간단하게 조정할 수 있어, 피쳐 플래그를 도입한다면 추가 작업 없이 빠르게 배포할 수 있다는 점이 큰 장점이 될 것 같다.

2. 배포와 기능 관리의 독립성

위의 내용과 거의 비슷하지만 피쳐 플래그는 배포와 기능 활성화를 독립적으로 관리할 수 있게 해 준다. 정기 배포 일정을 고려하지 않고 기능을 나중에 활성화하거나 비활성화할 수 있기 때문이다. 즉, 배포에 대한 리스크를 줄이면서도 유연하게 기능을 조정할 수 있다는 장점이 있다.

3. 책임감의 증가

피쳐 플래그를 사용하면 기능을 관리하는 책임감이 조금 더 명확해진다. 피쳐 플래그는 기능을 동적으로 활성화하거나 비활성화할 수 있기 때문에, 이를 설계하고 관리하는 개발자는 해당 기능이 언제, 어디서, 어떻게 활성화될지 결정할 권한을 가진다. 또한, 기능이 어디에서 보이고, 어디에서 보이지 않아야 하는지, 현재 어디까지 배포되었는지 등을 한 번 더 확인하게 된다.

 

++ 내가 생각한 장점들을 지피티에게 공유하고.. 지피티의 의견을 물어보았다.

피쳐 플래그는 환경 변수 방식에 비해 기능 제어의 유연성을 크게 향상시킨다. 또한 배포 리스크 관리, 빠른 롤백, 점진적인 배포가 가능하게 해 주기 때문에, 우리 팀에게 큰 도움이 될 수 있다. 배포와 기능 관리를 동적으로 하고 싶다면, 피쳐 플래그 도입을 진지하게 고려해 볼 만하다. 그렇지만, 피쳐 플래그는 개발자만의 주도권이 아닌, 팀 전체의 협업과 책임이 중요한 도구라는 점을 명심해야 한다. 피쳐 플래그를 통해 팀은 기능을 더욱 효율적으로 관리하고, 리스크를 줄이면서도 빠르게 개선할 수 있는 주도권을 가질 수 있다.