Feature Flags? 누구냐 넌

1. 서론

이전 API Version 관리를 포스팅했던 내용에 이어 이번에는 Feature Flags 내용을 작성해보려고 한다.

 

현재까지 나는 신규 프로젝트를 개발하는 일이 잦았다.

신규프로젝트를 진행하며 빠르게 변동되는 API들을 관리할 필요성이 있었고 서비스 도중 사용하지 않는 API를 제외시키기 위해 업데이트 후 재 배포를 했던 경우도 여럿 있었다.

 

그러다 문득, 들었던 생각은 굳이 API 필터링을 위해 배포 비용을 감안해야 할까?라는 의문이 들었었고 이를 해결할 수 있는 방법은 없을지 최근 생각하게 되었었다.

 

이런 고민에 대한 이야기를 민수님, 건수님께 꺼냈을 때 민수님께서 Feature Flags란 키워드를 알려주셨었고 해당 키워드에 대해서 한번 학습을 진행해 보았고 이를 잊지 않기 위해 정리를 함께 진행했다.

 

이번 글에서는 Feature Flags에 대한 이야기, 간단한 구현과 내 생각을 함께 적어보려고 한다.

 

2. Feature Flags?

Feature Flags는 다른 말로는 Feature Toggles, Feature Bits, Feature Flippers이라고도 이야기할 수 있다.

 

Feature Flags는 팀에서 코드를 변경하지 않고도 시스템 동작을 수정할 수 있는 기술이다. 해당 기술은 새로운 기능을 빠르고 안전하게 고객에게 제공할 수 있는 하나의 패턴으로도 생각할 수 있다.

( 나는 해당 기술을 접하며 Toggle의 기능을 한번 상기시켜 보았었다. )

 

또한, 예를 들어, 나는 해당 기능을 보며 다음과 같은 생각을 했었다.

• 신규 API를 배포한 이후 만약 장애상황이 발생되면 ON / OFF를 통해 이전 API를 제공할 수 있겠다.
  
  
• 비즈니스 상황으로 인해 v1, v2 버전의 API가 사용되고 있을 때 점진적으로 v1의 요청 수가 줄어들어 해당 API를 사용하지 못하게 하는 요구사항이 주어질 때 즉각적으로 대응할 수 있겠다.
  
  
• 백오피스를 통해 활성화 & 비활성화 API를 시각적으로 관리할 수 있겠다.

 

이와 더해 Feature Flag를 사용하는 정책을 어떻게 정하고 활용하는지에 따라 발전할 수 있는 가짓수는 다양할 수 있겠단 생각도 함께 들었다.

하지만, 해당 기술을 접목하게 될 때 토글의 기능의 설계, 관리하는 부분에서 복잡성을 야기할 수도 있겠다는 생각도 함께 들었다. 이 생각은 Martin Fowler의 Feature Toggles 아티클에서도 이야기하고 있음을 알 수 있다.

 

3. Feature Flag의 종류

Release Toggles

• 릴리즈 토글을 사용하면 불완전하고 테스트되지 않은 코드 경로를 잠복 코드로 프로덕션에 출시할 수 있다.
• 이는 Continuous Delivery를 실행하는 팀을 위해 Trunk 기반 개발을 활성화하는 데 사용되는 피쳐 플래그다.
• 이를 통해 진행 중인 피쳐를 통합 브랜치(예. main, trunk, master)에 체크인할 수 있으며 해당 브랜치를 언제든지 프로덕션에 배포할 수 있다.
• 릴리즈 토글을 사용하면 불완전하고 테스트되지 않은 코드를 절대 켜지지 않는, 숨어있는 코드 상태로 프로덕션에 배포할 수 있다.
• 같은 방법으로 이제 Product Manager는 절반만 완성된 피쳐를 최종 사용자에게 노출되는 걸 방지할 수 있다.

예를 들어, 전자 상거래 사이트에서 배송 파트너 중 하나에 대해서만 동작하는 새로운 예상 배송 날짜 기능을 사용자에게 표시하지 않고, 모든 배송 파트너에 대해 해당 기능이 구현될 때까지 기다리는 걸 선호할 수 있다.

 

Experiment Toggles

• 실험 토글은 독립된 몇 개의 변수나 A/B 테스트를 수행하는 데 사용된다.
• 시스템의 각 사용자는 그룹(cohort)에 배치되고, 런타임에 토글 라우터는 사용자를 그들이 속한 그룹에 따라 특정 코드 또는 다른 코드로 일관되게 분기시킨다.
• 다른 그룹의 집계 동작을 추적함으로써 다른 CodePath의 효과를 비교할 수 있다.
• 일반적으로 전자상거래 시스템의 구매 흐름이나 버튼의 클릭 유도문과 같은 항목에 대한 데이터 기반 최적화를 수행하는데 사용된다.

 

Ops Toggles

• 시스템 동작의 운영 측면을 제어하는 데 사용된다.
• 시스템 운영자가 성능을 저하시키거나 문제가 있을만한 피쳐를 Degrade 시키거나 비활성화할 수 있는 기능이다.
• 대부분의 Ops 토글은 상대적으로 수명이 짧다. 새로운 피쳐의 운영에 대한 확신이 생기면 플래그를 삭제한다.

 

Permissioning Toggles

• 특정 사용자가 받는 피쳐나 Product 경험을 바꾸는 데 사용된다.
• 해당 토글은 이전 아티클, 영상 등에서 보았던 일부 유저에게 기능을 선 제공하여 반응을 체크하는 비즈니스가 생각났다.

 

4. 그럼 유의해야 하는 건 없을까?

Feature Flags를 적용하고 사용할수록 더 이상 OFF로 관리가 필요 없는 API나 데이터가 쌓일 것이다.

 

이와 같은 상황이 발생하면 결국 사용하지 않는 레거시 데이터에 의해 데이터베이스의 비용이 증가할 것이다.

 

나는 위 상황을 생각했을 때 이전 FCM 푸시를 개발했을 때 Topic의 신선도 보장이라는 키워드가 함께 생각났다.

 

FCM 또한 Topic을 서버에서 관리를 진행해줘야 했기에 적재를 진행했었고 사용하지 않는 Topic들을 제거해줘야 했었다.

 

즉, 각 Flags들 간 어느 정도의 기간이 경과되었을 때 데이터 신선도를 관리할지 의사결정을 하여 관리하는 게 중요하단 생각이 들었다.

 

5. 실습 진행

실습을 진행할 때 현재 내가 업무에서 직면하고 있는 문제를 토대로 한번 요구사항을 부여해 개발하면 좋겠다고 생각을 했다.

요구사항은 다음과 같다.

• 현재 Member 서버를 개발하고 있고 API가 제공되고 있다.
• Feature Flag API는 다음과 같은 기능을 제공한다.
  • Feature Flag의 항목을 등록할 수 있다.
  • Feature Flag의 항목들을 조회할 수 있다.
  • Feature Flag의 항목을 수정할 수 있다. ( Active On & Off )
  • Feature Flag의 항목을 제거할 수 있다.

또한, 백오피스 등에서 활성화되어있는 API들의 관리를 위한 Page가 존재해야 한다.

이번 실습에서는 다양한 Toggles 기법이 존재하지만 현재 문제를 해결하기 위해 운영환경에서 On / Off를 할 수 있는 단순 상황을 토대로 생각을 하고 개발을 진행하였다.

실습 코드의 경우 일반적인 다른 CRUD와 차이점은 없기에, 불필요한 내용은 생략하고 주요 포인트만 다뤄보려고 한다.

 

• Feature Flag Annotation

먼저, 각 서비스 API의 관리를 위해 Feature Flag 어노테이션을 구현했다.

 

해당 어노테이션은 앞으로 각 API 메서드에 포함될 경우 각 선언한 API 명칭에 따라 On / OFF 여부를 검증하게 된다.

해당 어노테이션의 Aspect는 다음과 같다.

 

• FeatureFlag Aspect

해당 구현에 의해 만약 요청이 들어왔을 경우 활성화되어있지 않은 API의 경우 다음과 같은 에러를 반환한다.

“현재 해당 API는 사용할 수 없습니다.”

 

해당 어노테이션은 Member Controller에 적용하였다.

 

실행을 하고 각 관리되고자 하는 Name을 추가하게 될 경우 아래와 같이 페이지에서 관리가 가능하다.

최초 추가 시, API는 활성화가 되어있는 상황이다.

해당 API에 요청을 보낼 경우 정상적으로 동작이 수행된다.

 

• 회원 생성 시 ( On인 상황 )

 

• 회원 조회 시 ( On인 상황 )

 

만약 이때 회원가입 API를 비활성화한다고 가정해 보겠다.

위와 같이 설정을 진행한 이후, 재 요청을 보내게 될 경우 사용할 수 없다는 에러를 반환하게 된다.

 

이처럼 각 On / Off에 따라 유연하게 API 관리를 진행할 수 있다.

현재 예제에서는 정말 간단한 요소가 추가되었지만 위에서 설명했던 것과 같이 각 Flag 정책에 따라 관리될 포인트를 나눠 적용할 수도 있다.

 

해당 부분은 한번 더 발전을 시켜보려고 한다.

( 해당 예시와 키워드를 알려주신 민수님께 다시 한번 감사드린다. )

 

위 설명한 것에 더해 Readme에도 작성을 진행하였다.

 

구현한 내용은 아래 링크에서 확인할 수 있다.

https://github.com/JoeCP17/Feature-flag-web

 

6. 마치며

처음 해당 키워드를 접하고 학습을 진행하며 알게 모르게 많은 기업들에서 해당 기술을 고려하고 사용하고 있는 곳이 있음을 알 수 있었다.

 

내가 생각했던 고민을 이미 이전부터 정말 훌륭하신 개발자분들께서 하시고 계셨고 이에 대한 산출물이 나왔다고 생각한다.

 

이전 카프카 포스팅을 작성했을 때 카프카 탄생배경에 대해 간략하게 이야기했던 적이 있는데 이번 학습을 진행하며 당연한 이야기겠지만 현재상황에서의 어려움을 직면하고 불편함을 마주했을 때 이를 개선하기 위해 새로운 기술 또는 프레임워크가 탄생하고 이는 성장으로 가는 한 발자국의 발자국이 되고 있구나를 다시 한번 느낄 수 있었다.

 

아직, 부족함이 많지만 나 또한 어려움에 직면했을 때 이를 해결할 수 있는 여러 요소들을 고민하고 기여하고 싶단 생각을 다시 한번 하게 된 계기가 되었다.

REF

Feature Toggles (aka Feature Flags)

Feature Toggles (aka Feature Flags)

https://github.com/minsoozz/feature-flag-example

Feature Toggle 150% 활용하기