게임 Feature Flag 부채 대시보드 설계: 소유자와 제거 예정일을 관리하는 방법
게임 기능별 Feature Flag를 방치하지 않도록 소유자, 만료·제거 예정일, 위험도와 사용 현황을 한눈에 관리하는 대시보드의 데이터 모델과 점검 규칙, 알림, 제거 완료까지의 운영 절차를 정리합니다.
핵심 요약
Feature Flag 부채 대시보드는 기능 토글 목록이 아니라 각 Flag의 소유자, 제거 예정일, 현재 상태, 위험도, 사용 현황을 추적하는 운영 도구다. 핵심은 Flag를 등록할 때 TTL(Time to Live)과 담당자를 필수로 지정하고 제거 예정일이 가까워지면 알림과 티켓을 자동으로 생성하는 것이다.
게임 Feature Flag 부채는 왜 발생하는가?
Feature Flag는 미완성 기능을 숨기거나 점진적 출시를 제어하는 데 유용하다. 하지만 출시가 끝난 뒤에도 코드와 설정에 남아 있으면 조건문, 테스트 분기, 운영 문서가 계속 늘어난다.
특히 다음 상황에서 부채가 빠르게 쌓인다.
- 이벤트 기간에만 사용하는 임시 Flag가 영구적으로 남는다.
- 담당 팀이 바뀌었지만 소유자 정보가 갱신되지 않는다.
- 제거 예정일 없이 Flag를 생성한다.
- 서버와 클라이언트가 서로 다른 Flag 값을 참조한다.
- 비활성 상태라고 생각했지만 특정 플랫폼이나 지역에서 계속 사용된다.
따라서 대시보드는 단순히 활성화 여부를 보여주는 화면이 아니라 제거 작업의 우선순위를 결정하는 데이터베이스 역할을 해야 한다.
대시보드에는 어떤 데이터를 넣어야 하는가?
최소한 다음 필드를 관리해야 한다.
| 필드 | 설명 | 필수 여부 |
|---|---|---|
feature_flag_key | 코드와 설정에서 사용하는 고유 키 | 필수 |
feature_name | 사람이 이해할 수 있는 기능명 | 필수 |
flag_type | Release, Experiment, Permission, Kill Switch 등 | 필수 |
owner_team | 기능을 책임지는 팀 | 필수 |
owner_user | 최종 의사결정 담당자 | 필수 |
created_at | Flag 생성일 | 필수 |
rollout_start_at | 점진적 출시를 시작한 시각 | 권장 |
removal_due_at | Flag 제거 예정일 | 필수 |
status | Planned, Active, Cleanup, Removed, Archived | 필수 |
environment | Development, Staging, Production | 필수 |
platform_scope | PC, Console, Mobile 등 적용 플랫폼 | 권장 |
usage_last_seen_at | 실제 참조가 마지막으로 관측된 시각 | 권장 |
risk_level | Low, Medium, High, Critical | 필수 |
cleanup_ticket | 제거 작업을 추적하는 이슈 ID | 권장 |
notes | 출시 조건, 예외, 의존성 | 권장 |
owner_team만 기록하면 책임이 분산될 수 있다. 팀 단위 소유자와 함께 owner_user를 지정해야 알림을 받을 사람과 최종 승인자를 명확히 할 수 있다.
Feature Flag 메타데이터 테이블 예시
관계형 데이터베이스를 사용한다면 다음과 같은 구조로 시작할 수 있다.
CREATE TABLE feature_flags (
feature_flag_key VARCHAR(120) PRIMARY KEY,
feature_name VARCHAR(200) NOT NULL,
flag_type VARCHAR(30) NOT NULL,
owner_team VARCHAR(80) NOT NULL,
owner_user VARCHAR(120) NOT NULL,
created_at TIMESTAMP NOT NULL,
rollout_start_at TIMESTAMP NULL,
removal_due_at TIMESTAMP NOT NULL,
status VARCHAR(20) NOT NULL DEFAULT 'planned',
environment VARCHAR(20) NOT NULL,
platform_scope VARCHAR(200) NULL,
usage_last_seen_at TIMESTAMP NULL,
risk_level VARCHAR(20) NOT NULL DEFAULT 'medium',
cleanup_ticket VARCHAR(80) NULL,
notes TEXT NULL
);실제 Flag Provider가 LaunchDarkly, Unleash, Firebase Remote Config 또는 자체 서버인지와 관계없이 내부 대시보드에서는 공통 메타데이터 형식으로 통합하는 편이 좋다. OpenFeature를 사용한다면 Provider별 SDK 구현과 별개로 이 메타데이터를 중앙 관리할 수 있다.
소유자와 제거 예정일은 어떻게 정할까?
제거 예정일은 기억에 의존해 입력하지 말고 Flag의 목적과 수명에 따라 기본 TTL을 제공해야 한다.
| Flag 유형 | 기본 TTL 예시 | 제거 판단 기준 |
|---|---|---|
| Release Flag | 14~30일 | 정식 출시 후 기본값이 확정되었는가 |
| Experiment Flag | 실험 종료 후 7일 | 분석 결과가 승인되었는가 |
| Permission Flag | 30~90일 | 권한 정책이 코드나 계정 시스템으로 이전되었는가 |
| Kill Switch | 90일 후 재검토 | 실제 장애 대응용으로 계속 필요한가 |
| Live Event Flag | 이벤트 종료 후 7일 | 이벤트 데이터 보존과 재실행 계획이 끝났는가 |
예정일은 다음처럼 계산할 수 있다.
예외적으로 장기 유지가 필요한 Flag도 있다. 이 경우 제거 예정일을 비워 두는 대신 재검토일과 예외 사유를 반드시 기록한다. 무기한 유지가 승인된 Flag는 별도의 permanent_reason 또는 문서 링크를 갖게 하면 감사와 인수인계가 쉬워진다.
소유권을 RACI로 나누기
한 사람이 모든 책임을 지게 하기보다 업무를 다음처럼 나누면 협업이 안정적이다.
| 역할 | 책임 |
|---|---|
| Feature Owner | Flag의 목적, 기본값, 제거 판단을 책임진다. |
| Tech Owner | 코드와 SDK 참조를 제거하고 테스트를 수정한다. |
| QA Owner | Flag 제거 후 기능 회귀와 플랫폼별 동작을 검증한다. |
| Release Manager | 릴리스 일정에 정리 작업을 반영하고 미완료 항목을 에스컬레이션한다. |
| Product Manager | 기능 출시 완료와 Flag 제거 우선순위를 결정한다. |
부채 대시보드는 어떤 화면으로 구성해야 하는가?
첫 화면에는 전체 Flag 수보다 즉시 행동이 필요한 항목이 먼저 보여야 한다. 권장 요약 지표는 다음과 같다.
| 지표 | 의미 |
|---|---|
| 제거 기한 초과 | removal_due_at이 현재 시각보다 이전인 미정리 Flag 수 |
| 7일 내 제거 예정 | 가까운 시일에 작업이 필요한 Flag 수 |
| 소유자 미지정 | 담당자가 없어 조치할 수 없는 Flag 수 |
| 사용 흔적 없음 | 최근 관측 기간에 참조되지 않은 Flag 수 |
| 고위험 활성 Flag | Production에서 활성이고 위험도가 높은 Flag 수 |
| 평균 정리 지연일 | 제거 예정일 이후 완료까지 걸린 평균 일수 |
필터는 owner_team, flag_type, environment, platform_scope, risk_level, status, removal_due_at 기준으로 제공한다. 특히 Production + Active + 기한 초과 조합은 기본 저장 필터로 만들어 릴리스 회의 전에 바로 확인할 수 있어야 한다.
대시보드의 상세 행에는 현재 값만 표시하지 말고 다음 행동도 함께 제공한다.
- 소유자에게 알림 보내기
- 정리 티켓 생성 또는 연결하기
- 제거 예정일 연장 요청하기
- 코드 참조 목록 열기
- 제거 완료 승인 요청하기
- 예외 사유와 재검토일 기록하기
이렇게 구성하면 대시보드가 보고서에서 작업 큐로 전환된다.
상태 전이 정의하기
상태를 임의로 변경하면 데이터 신뢰도가 떨어지므로 전이 조건을 문서화한다.
flowchart LR
A[Flag 등록] --> B[소유자와 TTL 지정]
B --> C[출시 및 사용량 수집]
C --> D{제거 예정일 임박}
D -- 아니오 --> C
D -- 예 --> E[알림 및 정리 티켓 생성]
E --> F[코드 설정 문서 정리]
F --> G[QA 검증]
G --> H[Removed 처리]Removed는 코드에서 조건문을 삭제한 상태를 뜻한다. Provider에서 값을 비활성화한 것만으로는 제거 완료로 처리하지 않는다. 클라이언트 캐시, 서버 기본값, 원격 설정, 분석 이벤트와 테스트 픽스처까지 확인해야 한다.
대시보드를 운영 프로세스에 어떻게 연결할까?
1단계: 등록 시점에 소유권과 TTL을 강제한다
Pull Request 템플릿이나 Flag 생성 API에서 다음 항목을 필수화한다.
- Flag 목적
- Flag 유형
- 기본값
- Production 적용 여부
- 소유 팀과 담당자
- 제거 예정일
- 관련 기획서와 티켓
CI에서 메타데이터가 없는 Flag 키를 발견하면 빌드를 실패시키거나 최소한 경고를 남긴다. 코드 검색만으로 모든 참조를 찾기 어렵다면 Flag Provider의 API 목록과 정적 분석 결과를 함께 수집한다.
2단계: 사용 현황과 저장소 참조를 수집한다
대시보드 데이터는 세 가지 출처를 결합하는 것이 좋다.
| 출처 | 수집 정보 |
|---|---|
| Flag Provider API | 현재 값, 환경, 대상 사용자, 변경 이력 |
| 런타임 로그 또는 메트릭 | 실제 평가 횟수, 플랫폼, 지역, 마지막 사용 시각 |
| Git 저장소 분석 | 코드 내 참조 파일, 서비스, 브랜치, 테스트 사용 여부 |
런타임 평가 횟수가 0이라고 해서 즉시 삭제하면 안 된다. 특정 시즌 콘텐츠나 장애 대응 경로처럼 평소에는 호출되지 않는 기능이 있을 수 있으므로 기능 유형과 위험도를 함께 판단해야 한다.
3단계: 기한과 위험도에 따라 알림을 자동화한다
권장 알림 기준은 다음과 같다.
- 제거 예정일 14일 전: 담당자와 팀 채널에 사전 알림
- 제거 예정일 3일 전: 정리 티켓의 우선순위 상향
- 제거 예정일 당일: 담당자, PM, Release Manager에게 알림
- 예정일 초과 7일: 팀 리드에게 에스컬레이션
- 소유자 삭제 또는 비활성화: 소유권 재지정 요청
위험도는 영향도와 노출도 그리고 지연 기간을 조합해 계산할 수 있다.
예를 들어 Production 전체 사용자에게 적용되는 결제 관련 Kill Switch는 사용 횟수가 적더라도 높은 위험도로 분류할 수 있다. 반대로 개발 환경의 내부 UI 실험 Flag는 지연일수가 같아도 낮은 우선순위를 가질 수 있다.
4단계: 제거 작업을 릴리스 체크리스트에 포함한다
Flag 제거는 별도 업무로 미뤄지기 쉽다. 따라서 기능 출시 티켓에 다음 완료 조건을 포함한다.
- 기본값이 최종 기능 동작과 일치한다.
- 모든 플랫폼에서 Flag 없이 기능이 정상 동작한다.
- 서버와 클라이언트의 조건문 및 SDK 호출을 제거했다.
- 원격 설정과 환경 변수에서 키를 삭제했다.
- 테스트, 분석 이벤트, 운영 문서를 갱신했다.
- QA 검증과 Feature Owner 승인을 완료했다.
- 대시보드 상태를
Removed로 변경했다.
우선순위는 어떻게 정할까?
모든 오래된 Flag를 같은 날 제거하려고 하면 운영 리스크가 커진다. 다음 기준으로 정리 순서를 정한다.
| 우선순위 | 조건 | 권장 조치 |
|---|---|---|
| P0 | 결제, 로그인, 저장 데이터에 영향을 주며 Production에서 활성 | 즉시 소유자 지정과 제거 계획 수립 |
| P1 | 제거 예정일이 지났고 여러 플랫폼에서 사용 | 다음 릴리스의 필수 작업으로 등록 |
| P2 | 사용 흔적이 없지만 복구나 이벤트 재실행 가능성이 있음 | 재현 테스트 후 제거 |
| P3 | 개발·스테이징 환경에만 존재 | 정기 정리 배치에서 처리 |
대시보드에는 정렬 기준: 부채 점수 내림차순을 기본값으로 제공하되 릴리스 직전에는 제거 예정일 오름차순으로 확인할 수 있게 한다.
문서화와 팀 운영 규칙
대시보드만 만들고 운영 규칙을 정하지 않으면 몇 주 뒤 다시 낡은 목록이 된다. 다음 규칙을 팀의 개발 문서와 PR 템플릿에 함께 기록한다.
- 모든 임시 Flag는 생성 시 제거 예정일을 가진다.
- 예정일을 연장할 때는 연장 사유와 새 재검토일을 남긴다.
- 담당자가 변경되면 1영업일 안에 소유권을 갱신한다.
- Production Flag는 릴리스 회고 또는 주간 운영 회의에서 상태를 확인한다.
Removed처리에는 코드 변경 PR과 QA 확인 링크가 필요하다.- 90일 이상 유지된 Flag는 장기 유지 사유를 재승인한다.
팀 규모가 작다면 주간 15분의 Flag 정리 시간을 운영해도 충분하다. 중요한 것은 회의 횟수가 아니라 생성, 알림, 정리, 검증의 책임이 끊기지 않는 것이다.
자주 묻는 질문 (FAQ)
Feature Flag와 환경 변수는 같은 방식으로 관리해야 하나?
목적은 다르지만 소유자, 변경 이력, 적용 환경, 제거 또는 재검토일은 같은 원칙으로 관리할 수 있다. 특히 환경 변수에 숨겨진 기능 토글은 대시보드 수집 대상에 포함해야 한다.
제거 예정일을 지키지 못하면 Flag를 자동으로 삭제해도 되는가?
일반적으로 Production 기능을 자동 삭제하는 것은 위험하다. 기한 초과 알림과 티켓 자동 생성은 권장하지만 실제 삭제는 소유자와 QA의 검증을 거친다.
사용량이 없는 Flag는 바로 제거해도 되는가?
바로 제거하면 안 된다. 플랫폼, 지역, 시즌 이벤트, 장애 대응 경로별 호출 여부를 확인하고 관련 문서와 복구 절차를 검토한 뒤 제거한다.
정리
게임 Feature Flag 부채를 줄이는 핵심은 Flag를 만들 때부터 수명을 관리하는 것이다. feature_flag_key, 소유자, 유형, 환경, 제거 예정일, 위험도, 사용 현황을 표준화하고 대시보드와 알림을 릴리스 프로세스에 연결하면 오래된 토글을 실행 가능한 정리 목록으로 바꿀 수 있다.
대시보드의 성공 기준은 화면이 예쁜지에 있지 않다. 기한 초과 Flag가 누구의 책임인지 즉시 알 수 있고 제거 작업이 티켓과 QA 검증을 거쳐 실제 코드 삭제로 이어지는지가 핵심이다.
