개발자가 알아야 할 지식: 기능 플래그, 배포와 출시를 분리하는 스위치

코드를 배포했다는 사실과 사용자에게 기능을 열었다는 사실은 같지 않아도 됩니다. 기능 플래그는 이 둘 사이에 스위치를 둡니다.

왜 개발자가 알아야 하나

큰 기능을 한 번에 배포하면 위험도 한 번에 열립니다. 기능 플래그를 쓰면 코드는 미리 배포하되 내부 사용자, 일부 고객, 특정 지역처럼 작은 범위부터 기능을 켤 수 있습니다.

개발자에게 중요한 이유는 배포 전략이 코드 구조에 영향을 주기 때문입니다. 플래그 경계가 너무 넓거나 오래 남으면 코드가 복잡해지고, 반대로 잘 설계하면 롤백과 실험이 훨씬 쉬워집니다.

운영 중 장애가 났을 때도 플래그는 유용합니다. 전체 배포를 되돌리지 않고 문제가 된 기능만 끌 수 있다면 복구 시간이 짧아지고 다른 변경까지 함께 되돌리는 위험을 줄일 수 있습니다.

핵심 개념

플래그에는 종류가 있습니다. 짧게 쓰는 release flag, 실험용 experiment flag, 운영 차단용 ops flag, 권한 제어용 permission flag는 수명과 관리 방식이 달라야 합니다.

플래그 평가는 안정적이어야 합니다. 같은 사용자가 매 요청마다 다른 결과를 받으면 실험과 경험이 흔들립니다. 사용자 ID나 조직 ID 기준으로 일관되게 나누는 방식이 흔합니다.

플래그도 부채가 됩니다. 기능이 완전히 출시된 뒤에도 분기 코드가 남아 있으면 테스트 조합이 늘고 버그가 숨어듭니다. 플래그마다 소유자와 제거 시점을 정해야 합니다.

작은 예시 또는 체크리스트

새 결제 화면을 만들 때 new_checkout_enabled 플래그를 두고 내부 계정에서 먼저 켭니다. 문제가 없으면 5%, 25%, 100%처럼 점진적으로 넓힙니다. 결제 실패율이 오르면 배포 롤백 대신 플래그를 끄고 원인을 분석할 수 있습니다.

• 플래그의 목적과 예상 제거 날짜가 기록되어 있는가?
• 기본값이 안전하며 설정 서비스 장애 때 어떤 값으로 동작하는가?
• 플래그 상태별 핵심 경로 테스트가 있는가?
• 플래그 변경 이력이 감사 로그로 남는가?
• 완료된 플래그를 제거하는 정리 루틴이 있는가?

실무에서 자주 생기는 오해

• “기능 플래그가 있으면 배포가 항상 안전하다”는 오해가 있습니다. 잘못된 플래그 경계나 의존성 변경은 여전히 장애를 만들 수 있습니다.

• “모든 것을 플래그로 감싸자”도 위험합니다. 플래그가 많아질수록 가능한 상태 조합이 폭발하고 테스트가 어려워집니다.

• “출시 후 나중에 지우면 된다”는 말은 대개 잊힙니다. 오래된 플래그는 코드 이해를 방해하는 숨은 조건문이 됩니다.

오늘 바로 적용해보기

현재 코드에 남아 있는 오래된 플래그 목록을 뽑고 실제로 꺼질 수 있는지 확인해보세요.

새 플래그를 만들 때 생성 이유, 소유자, 제거 조건을 같은 PR에 적어두세요.

플래그 설정 시스템이 느리거나 실패할 때 서비스가 어떤 기본값을 쓰는지 테스트하세요.

더 알아보기

• Martin Fowler: Feature Toggles
• LaunchDarkly: Feature flag best practices
• Google SRE Book: Release Engineering

오늘의 takeaway

기능 플래그는 배포를 느슨하게 만드는 도구가 아니라, 출시의 위험을 더 작게 나누는 운영 장치입니다.