피처 플래그와 롤백 설계: 배포를 되돌릴 수 있어야 실험도 빠르다

핵심 요약

피처 플래그는 배포와 기능 노출을 분리하지만 데이터 변경까지 자동으로 되돌리지는 않는다. 플래그 기본값, 소유자, 대상 규칙, 실패 시 안전 상태, 데이터 호환성, 제거 기한을 함께 설계해야 한다.

피처 플래그는 코드를 배포한 뒤 기능을 켜고 끌 수 있게 해 준다. 작은 사용자 집단에 먼저 노출하고, 오류가 보이면 즉시 끄며, 실험군과 대조군을 나눌 수 있다. 그러나 플래그가 있다는 이유만으로 릴리스가 안전해지는 것은 아니다. 잘못된 기본값, 오래된 타기팅 규칙, 데이터 스키마 변경, 플래그 서비스 장애가 새로운 실패 지점을 만든다.

특히 “플래그를 끄면 롤백된다”는 표현은 주의해야 한다. 화면이나 코드 경로는 이전 상태로 돌아갈 수 있지만 이미 저장된 데이터, 발송된 메시지, 외부 API 호출, 결제 상태는 그대로 남을 수 있다. 피처 플래그는 실행 경로 전환 장치이고, 데이터 복구는 별도 설계가 필요하다.

플래그를 만들 때 적을 여덟 가지

필드	질문
목적	릴리스, 실험, 운영 차단, 권한 중 무엇인가
소유자	누가 켜고 끄며 사고 때 응답하는가
기본값	플래그 시스템을 읽지 못하면 어떤 값인가
안전 상태	장애 시 기능을 켜는 것이 안전한가, 끄는 것이 안전한가
대상 규칙	사용자·조직·리전·버전 중 무엇으로 나누는가
관측 지표	어떤 오류·지연·비즈니스 지표를 비교하는가
중단 조건	어떤 값에서 자동 또는 수동으로 끄는가
제거일	코드와 설정에서 언제 삭제하는가

플래그 이름만 보고 의미를 추측하지 않게 한다. new_checkout보다 checkout_v2_write_path_enabled처럼 범위와 동작이 드러나는 이름이 낫다. 다만 이름에 고객명이나 민감한 사업 정보를 넣지 않는다.

기본값을 네트워크 장애 상황에서 결정한다

플래그 제공자가 느리거나 네트워크가 끊기면 SDK는 캐시나 기본값을 사용한다. 이때 기본값이 잘못되면 전체 사용자가 실험 기능을 보거나, 보안 통제가 꺼질 수 있다.

새 기능은 대개 off가 안전하지만, 필수 보안 패치라면 예외일 수 있다.
운영 차단 플래그는 제공자 장애 시에도 마지막 알려진 안전 값을 유지해야 할 수 있다.
권한 플래그는 클라이언트가 아니라 서버에서 평가하고, 불확실하면 거부하는 편이 안전하다.
결제·데이터 삭제 같은 고위험 기능은 플래그 결과만으로 실행하지 말고 권한과 비즈니스 검증을 별도로 수행한다.

SDK 초기화 실패, 캐시 만료, 잘못된 타입, 존재하지 않는 플래그에 대한 동작을 테스트한다. 기본값은 코드 리뷰 대상이어야 하며 운영 콘솔 설정만으로 결정하지 않는다.

단계적 노출 순서

개발·스테이징: 기능 경로와 관측 필드를 확인한다.
내부 사용자: 직원 계정 또는 테스트 테넌트에서 업무 흐름을 검증한다.
카나리: 대표적인 소수 사용자·리전·인스턴스에 노출한다.
점진 확대: 1%, 5%, 25%, 50%처럼 조직에 맞는 단계로 늘린다.
전체 노출: 안정성 확인 후 기본 경로로 전환한다.
플래그 제거: 구 코드와 타기팅 규칙을 삭제한다.

비율은 예시다. 고객 수가 적거나 한 고객의 영향이 크다면 비율보다 특정 테스트 조직과 리전을 사용하는 편이 낫다. 단계마다 최소 관찰 시간과 다음 단계 승인 조건을 둔다.

카나리에서 비교할 지표

기능군과 대조군을 같은 시간대에 비교해야 트래픽 변화와 릴리스 영향을 구분하기 쉽다.

요청 성공률과 오류 코드
p50·p95·p99 지연 시간
CPU, 메모리, DB 연결, 큐 적체
재시도와 타임아웃
데이터 검증 실패와 중복 처리
고객 이탈, 결제 실패, 검색 성공 같은 업무 지표
고객지원 문의와 수동 복구 건수

플래그 평가 결과를 로그·트레이스에 넣을 때는 플래그 키, 변형 값, 평가 이유, 규칙 버전을 기록한다. 사용자 개인정보나 전체 타기팅 조건을 로그에 복사하지 않는다.

중단 조건은 배포 전에 정한다

사고가 난 뒤 “조금 더 보자”는 논쟁을 줄이려면 중단 조건을 미리 합의한다.

- 카나리 오류율이 대조군보다 지속적으로 높다.
- 핵심 업무 성공률이 허용 범위를 벗어난다.
- 데이터 불일치 또는 중복 기록이 1건이라도 발생한다.
- 플래그 평가 지연이 서비스 SLO를 위협한다.
- 운영자가 원인을 설명할 수 없는 고객군 노출이 확인된다.

수치는 서비스별 기준선과 오류 예산에 맞게 채운다. 데이터 손상처럼 되돌리기 어려운 신호는 낮은 임계치를 사용하고 즉시 중단한다.

데이터 마이그레이션과 플래그를 함께 설계하기

가장 위험한 릴리스는 코드 경로와 데이터 구조가 동시에 바뀌는 경우다. 안전한 패턴은 구·신 버전이 일정 기간 함께 동작하도록 만드는 것이다.

읽기 경로 전환

새 컬럼이나 새 저장소를 먼저 만들고 백필한다. 검증이 끝나면 읽기 플래그로 일부 트래픽만 새 경로를 사용한다. 문제가 있으면 구 경로로 되돌릴 수 있다.

이중 쓰기

구·신 저장소에 동시에 쓰면 전환이 쉬워 보이지만 부분 실패와 순서 문제가 생긴다. 쓰기 ID, 멱등성, 재처리 큐, 불일치 탐지를 준비한다. 단순히 두 번 호출하는 구현은 데이터 일관성을 보장하지 않는다.

파괴적 변경 지연

구 컬럼 삭제, 타입 축소, 제약 강화는 모든 구 코드가 사라지고 데이터 검증이 끝난 뒤 수행한다. 구조 추가, 백필, 읽기 전환, 파괴적 삭제를 분리하는 expand-contract 순서와 연결한다.

플래그를 끌 수 있어도 이미 새 형식으로 저장된 데이터를 구 코드가 읽지 못한다면 롤백이 아니다. 코드 호환성과 데이터 호환성을 별도로 테스트한다.

실패 모드와 방어

타기팅 규칙이 예상보다 넓다

이메일 도메인, 국가, 앱 버전 조건이 잘못되어 전체 고객에게 노출될 수 있다. 실행 전 예상 대상 수를 계산하고 상한을 넘으면 승인을 요구한다.

플래그 콘솔 권한이 과도하다

코드 리뷰 없이 운영 기능을 바꿀 수 있으므로 관리자 권한을 최소화하고, 고위험 플래그는 이중 승인과 변경 창을 둔다. 모든 변경 전후 값을 감사 로그로 남긴다.

플래그가 영구 설정이 된다

오래된 플래그는 가능한 경로 수를 늘리고 테스트를 어렵게 한다. 생성 시 제거일을 필수로 하고, 만료된 플래그를 빌드나 대시보드에서 경고한다.

클라이언트 플래그가 보안 통제로 사용된다

브라우저에서 버튼을 숨기는 것은 권한 통제가 아니다. 서버가 모든 요청에 대해 인증과 권한을 다시 검사해야 한다. 클라이언트 플래그 값은 사용자가 바꿀 수 있다고 가정한다.

플래그 서비스가 단일 장애점이 된다

로컬 캐시, 마지막 정상 값, 타임아웃, 회로 차단기, 기본값을 설계한다. 평가 실패가 요청 지연을 연쇄적으로 키우지 않게 한다.

플래그 운영 런북

사고 증상과 영향을 확인한다.
현재 플래그 값, 규칙 버전, 최근 변경자를 조회한다.
대상 범위를 좁히거나 안전 상태로 전환한다.
캐시 전파와 실제 평가 결과를 확인한다.
데이터 변경이 있었다면 별도 복구 절차를 실행한다.
고객 영향과 지원팀 공지를 갱신한다.
원인 수정 후 작은 집단에서 다시 검증한다.
임시 플래그와 예외에 제거 기한을 붙인다.

플래그를 끈 뒤에도 오류가 계속되면 코드 배포, 데이터, 캐시, 외부 의존성을 조사한다. 플래그 변경만 반복하면 원인과 상태가 더 혼란스러워질 수 있다.

제거 체크리스트

전체 사용자가 목표 경로를 안정적으로 사용한다.
구 경로로 돌아갈 운영 필요가 없다.
데이터 백필과 불일치 검증이 완료되었다.
구 코드와 테스트가 제거되었다.
플래그 설정과 타기팅 규칙이 삭제되었다.
대시보드와 문서가 새 경로를 기준으로 갱신되었다.
제거 후 빌드와 카나리 검증이 완료되었다.

참고 기준

피처 플래그는 빠른 실험을 가능하게 하지만 안전성은 자동으로 따라오지 않는다. 기본값, 대상 상한, 관측 지표, 데이터 호환성, 제거 기한을 설계하면 플래그는 임시 분기문이 아니라 통제된 릴리스 장치가 된다.