Offcanvas
Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
Offcanvas
1111Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
개발자

기능 플래그로 개발하는 데브옵스 사례 5가지

Isaac Sacolick  | InfoWorld 2021.11.03
오래 전 개발자로 일할 당시, 필자는 코드를 쓰고 애플리케이션을 빌드해 환경에 배포할 수 있게 해주는 플랫폼과 툴, 라이브러리를 최적화하는 일을 항상 즐겼다. 버전 제어에 컨커런트 버전 시스템(Concurrent Versions System)과 서브버전(SubVersion)을 사용하고 C++ 앱을 위한 makefile을 쓰고 아파치 앤트(Apache Ant) 스크립트를 개발해서 자바 앱을 패키징하고 온갖 유닉스 스크립트를 만들어 배포를 자동화했다. 지금은 깃과 젠킨스 등의 툴 덕분에 여러 필수적인 데브옵스 작업이 간편해졌고 많은 조직이 이와 같은 툴을 필수적인 소프트웨어 개발 툴로 간주한다.
 
당시 개발했던 몇 가지 뼈대가 지금은 상용 플랫폼이 되어 있다. 기능 플래그도 그중 하나인데, 아마 많은 조직이 이 기능을 거의 모르거나, 기초적인 방식으로만 사용 중일 것이다. 특히 마이크로서비스를 개발하고 고객 경험을 혁신하거나 레거시 애플리케이션을 현대화하는 기업에서 이는 큰 기회의 손실일 수 있다.
 
ⓒ Getty Images Bank

필자는 2020년 기능 플래그를 사용한 애자일 실험 방법에 대한 글에서 데브옵스 부서가 기능 플래그를 사용해 사용자 경험 실험을 관리하거나 배포된 기능을 런타임에 제어하는 방법에 초점을 두고 설명했다. 버전 제어 툴에 분기 전략을 구현하는 대신 기능 플래그를 사용해서 프로덕션 기능을 켜거나 끄는 편이 확장성과 관리 편의성 면에서 더 유리할 수 있다.
 
빌드와 A/B 테스트 기능에 무엇을 넣을지를 제어하는 것은 기능 플래그의 극히 일부에 불과하다. 런치다클리(LaunchDarky)의 공동 창업자이자 CTO인 존 코두멀과 이야기를 나눈 후, 기능 플래그가 애자일 개발 부서와 데브옵스 작업 방식, 소프트웨어 개발 역량을 어디로 이끄는지를 정리해야겠다고 생각했다.
 
코두멀은 기능 플래그가 데브옵스에 중요한 이유에 대해 “기능 플래그를 사용할 이유는 수없이 많지만, 가장 중요한 혜택은 큰 규모에서 속도 희생 없이 위험을 낮추는 데 있다. 코드가 아무리 잘 정의되어 있더라도 오류와 예기치 못한 버그는 발생할 수밖에 없다. 기능 플래그는 개발자가 몇시간, 며칠이 아닌 몇 밀리초 내에 변경을 롤백할 수 있게 해준다”라고 말했다.
 
기능 플래그를 소프트웨어 개발 기능 로드맵의 최상위에 배치할 만한 5가지 이유를 살펴보자.
 

제품 관리자에게 기능 제어 역량 제공

기능 플래그는 어느 코드가 어느 사용자에게 활성화될지를 제어하지만, 그렇다고 개발 부서가 그 스위치를 관리해야 한다는 것을 의미하지는 않는다. 개발 부서가 어떤 기능을, 언제 활성화할지를 결정하는 열쇠를 제품 소유자에게 맡겨야 하는 이유는 많다.
 
예를 들어 제품 부서가 새로운 기능을 발표할 때 진행할 마케팅 이벤트에서 활성화할 기능을 개발 중이라고 치자. 이 이벤트에 동원되어 프레젠테이션 동안 대기하다가 정확한 타이밍에 기능을 켜는 일을 기꺼이 맡을 애자일 개발자가 있을까?
 
개발 부서는 어떤 플래그를 제품 관리자에게 넘겨줄지를 논의해야 한다. 실용적인 측면에서도 그게 더 낫고, 비즈니스 스폰서와의 신뢰도 강화할 수 있다. 코두멀은 “이제 릴리스 프로세스가 민주화되는 중이다. 더 이상 엔지니어가 전적으로 롤아웃을 제어하지 않고, 릴리즈 프로세스를 비즈니스 의사 결정자의 손에 넘기고 있다”라고 말했다.
 

워크플로우를 사용해 기능 켜고 끄기

버스 운전대를 적절한 자격을 갖춘 사람에게 맡기는 것도 중요하지만 자동화와 워크플로우를 활용해 그 과정을 제어한다면 더 좋다. 워크플로우는 기능에 대한 액세스가 긍정적인 결과로 이어질 때 액세스를 확장하거나, 반대로 성능 또는 안정성 문제를 유발하는 경우 자동으로 축소 또는 비활성화하는 데 유용하다.
 
워크플로우는 사고를 추적하고 기능 플래그와의 연관성을 찾는 모니터링 툴 또는 AI옵스 플랫폼과 통합될 때 매우 강력해질 수 있다. 연관된 사고와 알림은 기능을 제어하고 켜고 끄는 자동화를 트리거할 수 있다.
 

고객 분석과 통합되어 세그먼트 제어

A/B 테스트를 수행하거나 다중 무장 도적(multi-armed bandit) 알고리즘을 실행하면서 서서히 더 폭넓은 대상에 기능을 개방하는 것은 새로운 기능을 롤아웃하는 한 가지 방법이다. 이 방법이 자연스럽게 확장된 것이 제어 세그먼트를 베타 테스터 또는 얼리 어댑터 그룹으로 사용하는 것이다. 고객 대면 애플리케이션의 경우 제품 개발자와 마케터가 고객 관계 관리 또는 고객 분석 툴에 정의된 고객 세그먼트에 따라 제안을 개인 맞춤화하고자 할 수 있다.
 
어도비, 어퀴아(Acquia), 옵티마이즐리(Optimizely) 같은 주요 공급업체의 디지털 경험 플랫폼에서는 고급 콘텐츠 관리 및 개인화 기능을 제공한다. 대규모 전자상거래 솔루션, 구독 웹사이트 또는 기타 옴니채널 고객 경험을 개발할 때 적합한 선택이 된다. 그러나 기본적인 개인화 또는 고객 세그먼트 분류 규칙이 필요한 대규모 또는 엔터프라이즈 애플리케이션에서는 기능 플래그와 함께 정적 또는 동적 고객 세그먼트를 사용해 기능을 제어하는 정도로 충분하다.
 

모든 이해관계자에게 기능 롤아웃에 대한 정보 제공하기

기능 플래그 기능을 직접 개발하면 된다고 생각하기 쉽다. 구성을 켜고 끄는 스위치와 기본적인 비즈니스 규칙은 그다지 복잡하지 않게 애플리케이션에 코딩해 넣을 수 있기 때문이다. 그러나 개발자로서 필자의 경험으로 보면 서비스, 애플리케이션, 개발 부서 전반에 걸쳐 많은 플래그가 생성되면 기능 플래그를 관리하고 제어하기가 어렵게 될 수 있다. 개인적으로 생각하는 기준은 플래그 30개다. 그 선을 넘으면 문서화하고 지원하기 위한 기술 부채가 쌓이기 시작한다.
 
기술 부채보다 더 큰 문제는 커뮤니케이션이다. 사용자가 지원 티켓을 생성할 때 서비스 부서는 개발 부서가 애플리케이션에서 활성화한 기능이 무엇이고 도움을 요청한 사용자가 누구인지 아는가? 애플리케이션 오류가 급증한다면 네트워크 운영 센터에서 이를 추적해서 사고 직전에 켜진 기능을 찾아낼 수 있는가?
 
기능 플래그를 깃허브, 지라 소프트웨어, 스플렁크, 슬랙 등 IT 툴에 연결하는 것은 구성 변경을 브로드캐스팅하고 추적하기 위한 한 가지 방법이다. 예를 들면 다음과 같다.
 
  • 다른 개발 부서가 기능 플래그, 애자일 사용자 스토리에서 포착된 요구사항 및 기반 코드를 추적해야 할 경우도 있다.
  • 사이트 안정성 엔지니어가 변경에 대한 정보를 얻고 관찰 가능한 데이터, 로그 및 기능 상태에 대한 모니터링 알림으로부터 문제를 파악하기 위해 슬랙 채널을 추적할 수 있다.
  • 훈련된 서비스 데스크 및 고객 지원 부서 역시 이러한 툴을 사용해서 사용자 문제를 연구하고 진단할 수 있다.
 
이런 모든 통합을 DIY식 기능 플래그로 구현하기는 어렵다. 자체 개발은 처음에는 통할 수 있지만 상용 제품이 제공하는 관리 및 통합 기능에는 미치지 못할 것이다.
 

앱 현대화 및 클라우드 마이그레이션 롤아웃 제어

레거시 애플리케이션을 현대화하면서 모놀리식 애플리케이션을 마이크로서비스로 분해하고 퍼블릭 클라우드 애플리케이션을 마이그레이션하는 IT 부서가 많다. 특히 배포 제어를 위한 견고한 자동화 테스트 또는 지속적 통합/지속적 배포(CI/CD) 파이프라인이 없는 레거시 애플리케이션 환경에서 직면하는 과제는 재설계된 앱이 프로덕션에 사용할 준비가 되었는지 여부를 알아내는 것이다.
 
개발 부서는 이러한 기회를 사용하여 더 견고한 자동화 및 지속적 테스트를 개발하는 등 기술 부채를 해결해야 한다. 그러나 시간적 제약, 전문가의 부재, 애플리케이션 복잡성 때문에 현실적으로 불가능한 경우도 있다.
 
기능 플래그를 추가해서 전환을 제어하는 방법도 있다. 런치다클리의 코두멀은 “몇 년 동안 테스트를 쓰고 시스템에 대한 확신을 얻을 수 있고, 실제로 테스트에 투자도 해야 한다. 그러나 새로운 환경으로 마이그레이션할 때, 기능 플래그는 기존 것과 새로운 것을 나란히 실행할 수 있는 역량을 제공한다. 두 시스템이 동일하게 동작한다면 이전 시스템으로 가는 트래픽을 차단하고 확신을 갖고 전환을 실행할 수 있다”라고 말했다.
 
즐, 결론은 기능 플래그는 버전 제어, CI/CD, 코드형 인프라, AI옵스와 함께 필수적인 데브옵스 기능이라는 것이다. 애플리케이션 현대화, 사용자 경험 개선, 배포 빈도 증대를 추구하는 조직에서 기능 플래그를 개발에 활용하고 기능 플래그 관리 툴을 사용하면 가독성과 유연성, 개인화 옵션을 한층 더 개선할 수 있다. editor@itworld.co.kr
 Tags 데브옵스 기능플래그
Sponsored

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.