배포해도 바로 공개되지 않는 기능, 기능 플래그의 역할

오늘의 인사이트 요약

• 배포는 코드를 반영하고 공개는 사용 대상을 엽니다.

• 기능 플래그는 조건에 맞춰 실행 경로를 고릅니다.

• 기능을 꺼도 이미 저장한 데이터는 되돌아가지 않습니다.

새 기능의 배포는 끝났지만 고객에게 보여줄 시점은 따로 정하고 싶을 때가 있습니다. 모든 이용자에게 한 번에 공개하기 전에 일부 계정에서만 확인하고 싶을 수도 있습니다. 오늘은 기능 플래그로 배포와 공개를 나누는 원리와 운영 중 주의할 점을 알아보겠습니다.

1. 기능 플래그는 어떻게 동작할까?

기능 플래그는 코드에 넣은 조건으로 기능의 사용 여부를 제어하는 장치입니다. 새 코드를 서버에 배포한 뒤에도 특정 사용자에게만 기능을 보여주거나 공개를 미룰 수 있습니다. 실행 중에 설정을 바꿀 수 있는지는 구현 방식에 따라 다릅니다.

기능 플래그는 피처 플래그나 기능 토글이라고도 부릅니다. 프로그램이 설정을 읽고 새 기능을 실행할지 기존 기능을 유지할지 선택하는 방식입니다. 가령 가상의 쇼핑몰에서 새 검색 화면을 만들어 배포해도, 플래그가 꺼져 있으면 이용자는 기존 화면을 계속 볼 수 있습니다.

이때 배포와 공개 시점이 분리됩니다. 배포는 실행할 코드를 운영 환경에 반영하는 일이고, 공개는 그 기능을 사용할 대상을 여는 일입니다. 모든 플래그가 화면에만 작용하는 것은 아닙니다. 서버의 처리 방식을 바꾸거나 운영 중 특정 기능을 중단하는 용도로도 쓰입니다.

플래그를 바꾸면 언제 반영될까?

설정 파일이나 환경변수를 읽는 단순한 방식은 변경 후 재시작이나 재배포가 필요할 수 있습니다. 실행 중에 설정을 갱신하는 구조라면 별도 배포 없이 바꾸지만, 설정 전달과 캐시 갱신에 걸리는 시간도 있습니다. 관리자 화면에서 저장했다고 모든 서버와 앱에 동시에 적용됐다고 보지는 않습니다.

플래그가 꺼져 있을 때 어느 동작으로 돌아가는지 이름과 설명에 남깁니다. 켜짐이 새 기능인지 사용 중단인지를 팀마다 다르게 해석하면 조작이 어려워집니다. 공개·실험·운영처럼 목적별 차이를 더 살펴보고 싶다면 Pete Hodgson의 Feature Toggles를 참고해 보세요.

2. 일부 사용자에게만 공개하는 이유는 무엇일까?

일부 사용자에게 먼저 공개하면 새 기능이 실제 환경에서 동작하는지 살핀 뒤 대상을 넓힐 수 있습니다. 사내 검수 계정, 신청한 베타 이용자, 일정 비율의 사용자처럼 공개 대상 조건을 정합니다. 대상이 작다고 오류의 영향까지 항상 작은 것은 아니므로 결제나 중요한 데이터 변경은 따로 검토합니다.

비율 공개는 요청이 올 때마다 무작위로 화면을 바꾸는 것과 다릅니다. 같은 사용자가 새 화면과 기존 화면을 계속 오가면 하던 작업도 이해하기 어렵습니다. 일관된 사용자 식별자를 기준으로 묶고, 조직이 함께 쓰는 서비스라면 개인과 회사 중 어느 단위로 공개할지도 정합니다.

비율을 늘릴 때 어떤 결과를 볼까?

새 기능을 실제로 받은 사용자와 받지 않은 사용자를 구분해 관찰합니다. 전체 이용자의 평균만 보면 일부에게 생긴 오류가 묻힐 수 있습니다. 오류나 응답 시간뿐 아니라 업무 완료 여부를 확인하고, 문제가 생겼을 때 중단할 조건도 함께 정합니다. 작은 비율에서 시작하는 것은 검수를 생략하는 이유가 아닙니다.

비율을 올릴 때 기존 대상이 유지되는지, 다른 플래그와 같은 그룹을 쓰는지도 도구별로 확인합니다. 비율 배분의 동작 원리를 구체적으로 이해하려면 LaunchDarkly의 비율 공개 안내를 참고해 보세요. 일부 공개만으로 A/B 테스트의 성과가 입증되는 것은 아니며 실험 목적과 비교 설계는 별도로 필요합니다.

3. 기능을 끄면 배포도 되돌아갈까?

플래그를 끄는 것은 보통 실행 경로를 바꾸는 일입니다. 이전 프로그램으로 되돌리는 배포 롤백과는 다릅니다. 새 기능이 이미 만든 주문, 변경한 데이터, 외부로 보낸 알림은 플래그를 끄는 것만으로 취소되지 않습니다. 화면이 돌아와도 뒤에서 진행 중인 작업이 남아 있는지 확인합니다.

예를 들어 가상의 서비스에서 새 주소 입력 화면을 끄더라도, 그 화면이 저장한 주소를 기존 화면이 읽을 수 있어야 합니다. 데이터 호환성이 맞지 않으면 기능을 꺼도 업무가 복구되지 않습니다. 켜진 상태뿐 아니라 꺼진 상태와 전환 이후에도 조회·수정이 이어지는지 검수합니다. 버튼을 숨기는 플래그는 서버의 권한 검사도 대신하지 못합니다.

공개를 마친 플래그는 언제 없앨까?

잠시 쓰려고 만든 공개용 플래그는 전체 공개가 안정된 뒤 제거할 시점과 담당자를 정합니다. 사용하지 않는 조건이 쌓이면 기존·신규 경로를 함께 이해하고 검수해야 하는 부담이 남습니다. 비상 중단용으로 계속 유지할 플래그는 목적과 점검 책임을 분명히 해 구분합니다.

플래그마다 이름, 목적, 기본 동작, 담당자, 변경 기록, 정리 조건을 남기면 인수인계할 때 도움이 됩니다. 설정을 읽지 못할 때의 기본 동작도 미리 정해 검수합니다. 짧게 쓰는 플래그의 정리와 안정적인 운영 방식을 더 살펴보고 싶다면 Unleash의 기능 플래그 운영 지침을 참고해 보세요. 기능을 추가하면서 운영자가 어떻게 제어할지도 함께 설계하는 셈입니다.

기능 개발과 공개 이후의 운영을 함께 설계합니다

똑똑한개발자는 프로덕트 기획·디자인·개발·운영 경험을 바탕으로 서비스 구축을 돕습니다. 새 기능을 구현하는 범위와 함께 공개 대상, 검수 조건, 운영 중 변경이 필요한 흐름을 연결해 살펴봅니다.

서비스에 맞는 기능 공개와 운영 방식을 설계하고 싶다면 아래 똑똑한개발자 링크로 이야기 나눠주세요. 감사합니다.