블로그 목록으로
소프트웨어

배포와 공개를 분리하라: 피처 플래그로 업무 시스템 기능을 안전하게 여는 법

코드 배포와 기능 공개를 피처 플래그로 분리하면 월말 마감이나 행사 기간에도 배포를 멈추지 않고, 부서·사업장 단위로 기능을 안전하게 열 수 있습니다. 플래그 유형 구분부터 킬 스위치, 수명 관리, 감사 로그, 데이터 마이그레이션 원칙까지 업무 시스템에 맞는 운영 방법을 정리했습니다.

POLYGLOTSOFT 기술팀2026-10-267분 소요0
피처 플래그점진적 배포릴리즈 관리업무 시스템운영 안정성

배포 날마다 긴장하는 이유

업무 시스템을 운영하는 팀에게 배포일은 여전히 긴장되는 날입니다. 코드를 서버에 올리는 순간 새 기능이 모든 사용자에게 열리기 때문입니다. 배포(deployment)와 공개(release)가 한 번에 일어나는 구조에서는 작은 화면 오류 하나만 나와도 전체를 되돌려야 하고, 그 사이 함께 반영된 다른 수정까지 같이 빠집니다.

현업 일정과 부딪히는 문제도 있습니다. 회계팀의 월말 마감 주간, 물류센터의 대형 프로모션 기간에는 "이번 주는 아무것도 바꾸지 말아 달라"는 요청이 나옵니다. 개발은 끝났는데 공개할 수 없으니 브랜치가 몇 주씩 쌓이고, 나중에 한꺼번에 합치면서 충돌과 장애 위험이 오히려 커집니다.

피처 플래그(Feature Flag)는 이 두 사건을 떼어 놓는 장치입니다. 코드는 미리 배포해 두고, 기능을 여는 시점은 설정으로 따로 정합니다.

피처 플래그의 기본 구조

네 가지 플래그를 구분해야 합니다

  • 릴리즈 플래그: 미완성이거나 공개 전인 기능을 숨깁니다. 수명이 짧아 몇 주 안에 제거해야 합니다.
  • 실험 플래그: 사용자 그룹별로 다른 화면이나 로직을 보여 주고 효과를 비교합니다.
  • 운영 스위치: 외부 연동이나 무거운 배치처럼 장애 시 즉시 꺼야 하는 기능을 제어합니다. 상시로 유지되는 경우가 많습니다.
  • 권한 플래그: 특정 고객사나 등급에만 기능을 엽니다. 사실상 제품 설정에 가깝습니다.
  • 종류마다 수명과 관리 주체가 다르므로, 하나의 목록에 섞어 두면 무엇을 지워도 되는지 아무도 판단하지 못하게 됩니다.

    서버 측 판단과 클라이언트 측 판단

    서버에서 플래그를 판단하면 규칙이 외부에 드러나지 않고, 데이터 처리 로직까지 함께 통제할 수 있습니다. 클라이언트에서 판단하면 화면 전환은 빠르지만 비공개 기능의 존재가 번들에 노출될 수 있습니다. 업무 시스템에서는 권한과 데이터에 영향을 주는 판단은 반드시 서버에서 하고, 클라이언트는 결과만 받아 화면을 그리는 방식을 권장합니다.

    업무 시스템에서의 점진 공개 전략

    부서·사업장·사용자 그룹 단위로 엽니다

    일반 서비스는 사용자 비율(1% → 10% → 50%)로 공개하지만, 업무 시스템은 조직 단위가 더 자연스럽습니다. 예를 들어 새 입고 검수 화면을 전국 5개 물류센터에 도입한다면 다음과 같이 진행할 수 있습니다.

  • 1주차: 본사 IT팀과 핵심 사용자 10명
  • 2주차: 물동량이 가장 적은 1개 센터
  • 3~4주차: 나머지 4개 센터 순차 공개
  • 이렇게 하면 문제가 생겨도 영향 범위가 한 사업장으로 제한되고, 현장 교육도 센터별로 나눠 진행할 수 있습니다.

    재배포 없이 끄는 킬 스위치

    킬 스위치는 장애 대응 시간을 크게 줄입니다. 재배포로 롤백하려면 빌드와 승인, 배포에 수십 분이 걸리지만 플래그 전환은 수 초면 끝납니다. 다만 끄는 순간 기존 경로로 안전하게 돌아갈 수 있도록 이전 로직을 공개 완료 전까지 지우지 않는 것이 전제입니다.

    플래그가 기술부채가 되지 않게

    수명 관리: 기한과 담당자

    플래그를 만들 때 담당자와 제거 예정일을 함께 등록하는 규칙을 둡니다. 릴리즈 플래그라면 전체 공개 후 2~4주 안에 코드에서 지우는 식입니다. 2012년 미국 증권사 나이트 캐피털은 쓰지 않던 플래그를 재사용했다가 구 코드가 되살아나면서 약 45분 만에 4억 달러 이상의 손실을 냈습니다. 남겨 둔 플래그는 언젠가 사고가 됩니다.

    조합 폭증을 막는 설계 규칙

    켜고 끌 수 있는 플래그가 10개라면 이론상 조합은 2의 10제곱, 즉 1,024가지입니다. 전부 테스트할 수는 없으므로 다음 규칙을 권장합니다.

  • 플래그끼리 서로 의존하지 않게 설계합니다.
  • 한 기능에는 하나의 플래그만 둡니다.
  • 테스트는 "현재 운영 상태"와 "다음 공개 예정 상태" 두 가지 조합을 필수로 검증합니다.
  • 감사·권한·데이터 정합성

    누가 언제 바꿨는지 기록합니다

    플래그 전환은 사실상 운영 환경 변경입니다. 변경자, 시각, 이전 값과 이후 값, 변경 사유를 감사 로그로 남기고, 운영 스위치처럼 영향이 큰 플래그는 승인자를 따로 지정하는 것이 좋습니다.

    껐다 켜도 깨지지 않는 데이터 구조

    기능을 끄더라도 이미 쌓인 데이터는 남습니다. 따라서 스키마 변경은 확장 → 이관 → 축소 순서로 진행합니다. 새 컬럼을 먼저 추가하되 기존 컬럼은 유지하고, 플래그가 켜진 동안 양쪽에 함께 기록한 다음, 전체 공개가 확정된 뒤에야 기존 컬럼을 제거합니다. 이 원칙을 지키면 플래그를 다시 꺼도 기존 화면이 정상 동작합니다.

    도입 방법과 POLYGLOTSOFT의 접근

    자체 구현과 외부 서비스

    플래그가 수십 개 이하이고 조직 단위 공개만 필요하다면 DB 테이블과 관리 화면만으로도 충분합니다. 실험 분석, 실시간 반영, 다수 서비스 연동이 필요해지면 LaunchDarkly, Unleash, Flagsmith 같은 도구를 검토할 만합니다. 처음부터 CNCF의 표준 인터페이스인 OpenFeature에 맞춰 두면 나중에 구현체를 바꾸기도 쉽습니다.

    잦은 요구 변경을 안전하게 반영하는 운영

    구독형 개발에서는 요구사항이 매주 바뀌는 것이 자연스럽습니다. POLYGLOTSOFT는 변경 사항을 작은 단위로 자주 배포하고, 고객이 원하는 시점에 원하는 부서부터 기능을 여는 방식으로 운영합니다. 마감 주간에는 배포를 멈추지 않고 공개만 미루면 됩니다.

    배포일마다 긴장하고 계시다면 POLYGLOTSOFT의 구독형 개발 서비스를 검토해 보시기 바랍니다. 피처 플래그와 감사 로그, 단계 공개 전략까지 포함한 안정적인 업무 시스템 운영 체계를 함께 설계해 드립니다. 지금 바로 문의해 주십시오.

    기술 상담이 필요하신가요?

    스마트공장, AI, 물류자동화 분야의 전문 컨설턴트가 귀사의 요구사항을 분석해 드립니다.

    무료 상담 신청