기능 플래그로 새 기능을 일부 사용자에게 먼저 공개하는 법

새 기능을 완성했다고 모든 방문자에게 바로 보여 줄 필요는 없습니다. 코드는 서버에 올리되 실제 공개는 내부 사용자나 작은 대상부터 시작하면 예상하지 못한 오류가 생겨도 영향을 좁힐 수 있습니다.

공연장에 새 조명을 미리 설치한 뒤 구역별 스위치로 일부 관객에게만 켜는 장면을 떠올려 보세요. 조명 장비를 설치하는 일은 코드 배포이고, 어느 구역에서 불을 켤지 정하는 스위치가 기능 플래그입니다. 문제가 보이면 기존 조명이 켜진 익숙한 무대로 안내할 수 있어야 합니다.

코드 배포와 기능 공개는 서로 다른 일이다

배포는 새 코드가 실행 환경에 들어가는 일입니다. 공개는 사용자가 그 기능을 실제로 보거나 쓸 수 있게 하는 일입니다. 기능 플래그는 둘을 분리해 배포된 코드의 특정 경로를 켜거나 끄는 설정입니다. Microsoft는 이를 다시 배포하지 않고 기능을 끄고 켜거나, 특정 사용자에게만 보여 주거나, 공개 비율을 늘리는 기능 관리 방식으로 설명합니다.

이 구분이 필요한 이유는 배포 성공 표시가 사용자 경험까지 보장하지 않기 때문입니다. 새 검색 화면이 서버에는 들어갔어도 플래그가 꺼져 있으면 방문자는 기존 화면을 봅니다. 반대로 플래그를 켜면 같은 배포 안에서 새 화면을 보게 됩니다. 먼저 “코드가 올라갔는가”와 “누가 새 기능을 받는가”를 다른 질문으로 적어야 합니다.

기본값은 익숙한 경로로 돌아가게 만든다

안전한 플래그에는 꺼졌을 때 사용할 기존 경로가 필요합니다. 새 기능 설정을 읽지 못하거나 기능 관리 서비스에 잠시 연결되지 않아도 애플리케이션 안의 기본값으로 동작해야 합니다. Firebase Remote Config도 앱 안에 기본값을 두고, 원격 값은 가져온 뒤 활성화 시점을 제어하는 흐름을 안내합니다.

다음은 구조를 이해하기 위한 짧은 예시입니다.

const useNewSearch = flags.newSearch === true;
return useNewSearch ? showNewSearch() : showCurrentSearch();

newSearch가 분명히 참일 때만 새 검색을 보여 주고, 값이 없거나 거짓이면 현재 검색으로 돌아갑니다. 실제 서비스에서는 플래그를 읽는 데 실패했을 때의 동작, 새 기능에 필요한 데이터가 없을 때의 화면, 기존 경로가 계속 작동하는지를 함께 시험해야 합니다.

첫 대상은 내부 사용자와 작은 범위로 정한다

점진적 공개는 한 번에 모든 사용자에게 켜지 않고 작은 대상부터 넓히는 방식입니다. 내부 점검 계정, 동의한 시험 사용자, 특정 앱 버전처럼 이유를 설명할 수 있는 대상을 먼저 정합니다. 이후 새 기능을 받은 그룹과 기존 기능을 쓰는 그룹에서 오류와 핵심 행동을 비교합니다.

Firebase의 rollout은 새 값을 받는 그룹과 기존 값을 받는 대조 그룹을 나누고, 안정성을 확인하며 노출 범위를 늘리는 예를 제공합니다. 모든 기능이 같은 도구를 써야 한다는 뜻은 아닙니다. 중요한 것은 한 사용자가 요청할 때마다 새 기능과 기존 기능 사이를 무작위로 오가지 않도록 대상 규칙을 안정적으로 유지하고, 누가 어떤 경로를 받았는지 기록할 수 있게 만드는 일입니다.

켜기 전에 성공과 중단 기준을 먼저 쓴다

기능을 켠 뒤 기분에 따라 판단하면 오류가 보여도 공개를 계속하기 쉽습니다. 시작 전에 정상으로 볼 조건과 즉시 멈출 조건을 짧게 적습니다. 성공 기준은 새 화면이 보였다는 사실이 아니라 사용자가 검색, 저장, 가입 같은 목적을 끝냈는지까지 포함해야 합니다.

플래그: new_search
기본값: 꺼짐, 기존 검색 사용
첫 대상: 내부 시험 계정
확인: 검색 완료, 빈 결과, 오류, 응답 지연
중단: 결제나 삭제 영향, 오류 급증, 기존 경로 실패

오류율, 응답 시간, 완료율처럼 기존에 보던 지표를 플래그 상태와 연결합니다. 새 기능을 받은 사용자 수만 세면 “노출됐다”는 사실만 알 수 있습니다. 오류가 늘거나 핵심 완료가 줄었는데도 공개 비율만 높여서는 안 됩니다.

플래그를 끄는 일과 코드 롤백은 같지 않다

플래그를 끄면 사용자가 새 화면이나 동작에 들어가는 길을 막을 수 있습니다. 하지만 이미 저장된 데이터, 발송된 메일, 처리된 결제, 바뀐 데이터베이스 구조까지 자동으로 되돌아가지는 않습니다. 새 기능이 데이터를 쓰기 시작했다면 기존 코드가 그 데이터를 읽을 수 있는지도 미리 확인해야 합니다.

예를 들어 새 주문 흐름을 끄더라도 이미 생성된 주문 상태는 남습니다. 기능 플래그를 비상 정지 버튼처럼 사용할 수는 있지만, 되돌릴 수 없는 외부 작업에는 중복 방지, 취소 절차, 데이터 복구 계획이 따로 필요합니다. 플래그를 끈 뒤에도 오류가 계속되면 코드 배포 자체의 롤백이나 별도 복구가 필요한지 판단합니다.

기능 플래그는 권한과 비밀 저장소가 아니다

화면에서 관리자 메뉴를 숨기는 플래그만으로 권한을 보호할 수는 없습니다. 사용자가 화면을 우회해 서버 요청을 보낼 수 있으므로 서버는 매 요청에서 인증과 권한을 다시 확인해야 합니다. 플래그는 공개 대상을 정하는 도구이지 보안 경계를 대신하는 문이 아닙니다.

Firebase 문서는 클라이언트가 받는 Remote Config 값은 최종 사용자가 접근할 수 있으므로 비밀 자료를 넣지 말라고 안내합니다. API 키, 비밀번호, 결제 비밀값, 개인정보를 플래그 이름이나 값에 저장하지 마세요. 사용자의 승인이나 약관 동의가 필요한 기능을 설정 하나로 몰래 켜는 방식도 피해야 합니다.

공개가 끝난 플래그는 정리 계획을 세운다

모든 사용자에게 안정적으로 공개한 뒤에도 오래된 분기 코드를 계속 남기면 가능한 경로가 늘어나 테스트가 어려워집니다. 반대로 새 기능을 중단했다면 사용하지 않는 코드와 설정이 남아 다음 작업에서 잘못 켜질 수 있습니다. 플래그마다 담당자, 만든 이유, 기본값, 제거 조건을 기록합니다.

정리는 공개와 같은 날 서두르지 않습니다. 필요한 관찰 기간과 복구 가능성을 확인한 뒤 별도 변경으로 기존 분기를 제거하고 테스트합니다. 기능 플래그 목록에서 이름만 지우기 전에 코드가 그 값이 없을 때 안전한 기본 경로를 선택하는지 먼저 확인하세요.

오늘 바로 해볼 작은 실습

실제 서비스 설정을 바꾸지 않고 10분 동안 종이 공개 계획을 만듭니다.

1. 만들고 있는 기능 하나를 고르고 기존 경로와 새 경로를 한 줄씩 적습니다.
2. 플래그 이름과 꺼졌을 때 사용할 안전한 기본값을 적습니다.
3. 첫 공개 대상을 내부 시험 계정처럼 좁고 설명 가능한 그룹으로 정합니다.
4. 새 기능에서 확인할 완료 행동, 오류, 응답 시간을 하나씩 고릅니다.
5. 결제, 삭제, 개인정보 변경이 생기면 즉시 멈춘다는 기준을 적습니다.
6. 플래그를 꺼도 남는 데이터와 외부 작업이 무엇인지 적습니다.
7. 기존 경로가 새 데이터도 읽을 수 있는지 확인 질문을 만듭니다.
8. 공개가 끝난 뒤 플래그와 분기 코드를 정리할 담당자를 적습니다.
9. API 키, 토큰, 비밀번호, 실제 고객 정보를 적지 않았는지 다시 봅니다.
10. 운영 콘솔의 플래그를 켜거나 끄는 동작은 이번 실습에서 하지 않습니다.

마지막으로 “누구에게 먼저 켜고, 무엇을 보면 넓히며, 어떤 상황에서 끄는가”를 한 문장으로 말해 보세요. 이 문장이 모호하거나 기본 경로를 설명할 수 없다면 실제 공개를 시작하지 않고 개발자와 운영 담당자에게 확인하는 것이 안전합니다.