앱 개발에서의 피처 프리즈와 코드 프리즈: 본질, 차이점 및 역할

피처 프리즈란?

피처 프리즈는 계획된 릴리스 전에 코드베이스에 새 기능을 추가하는 것을 일시적으로 금지하는 것입니다. 팀은 기능 병합을 중단하고 버그 수정, 최적화 및 기존 코드 개선에 집중합니다. 개발자는 범위를 확장하지 않고 버그 수정 범위 내에서만 미완성 기능을 완료합니다.

피처 프리즈는 릴리스에 맞추지 못했지만 메인 브랜치에 이미 부분적으로 병합된 진행 중인 기능의 문제를 해결합니다. 새 기능이 계속 병합되면 회귀 위험이 증가합니다. 각 새 통합에는 이미 완료된 모듈의 재테스트가 필요하기 때문입니다. 피처 프리즈는 릴리스 범위를 고정하여 움직이는 표적에서 안정적인 기능 세트로 전환합니다.

중요한 설명: 피처 프리즈 ≠ 코드 프리즈. 피처 프리즈 중에는 버그 수정, 리팩토링, 종속성 업데이트 및 문서화가 허용됩니다. 금지되는 것은 새로운 사용자 대상 기능, 즉 사용자 관점에서 애플리케이션 동작을 변경하는 코드입니다. 코드 리뷰 확인: PR이 새 화면, 버튼 또는 API 메서드를 추가하는 경우 프리즈가 해제될 때까지 거부됩니다.

코드 프리즈란? 피처 프리즈와의 차이점

코드 프리즈는 모든 코드 변경을 완전히 금지하는 더 엄격한 관행입니다. 치명적이지 않은 경우 버그 수정조차 허용되지 않습니다. 코드 프리즈는 짧은 기간(보통 24~48시간) 동안 도입되며 릴리스 빌드가 고정된 커밋 세트에서 빌드되도록 보장합니다.

피처 프리즈와 코드 프리즈의 차이는 제어 수준에 있습니다. 피처 프리즈는 범위를 관리합니다. 릴리스에 정확히 무엇이 포함될지를 결정합니다. 코드 프리즈는 품질을 관리합니다. 릴리스 하루 전에 새 버그가 도입될 위험을 제거합니다. 실제로 많은 팀이 2단계 모델을 사용합니다. 릴리스 1~2주 전에 피처 프리즈, 24~48시간 전에 코드 프리즈입니다. 코드 프리즈는 계획된 릴리스 날짜 며칠 전에 빌드를 스토어에 업로드해야 하는 모바일 앱에 특히 중요합니다.

코드 프리즈의 예외는 심각한 취약점(CVE 점수 9+)에 대한 보안 수정입니다. 이러한 변경은 필수 패스트트랙 코드 리뷰 및 팀 알림을 포함한 긴급 프로세스를 거칩니다. 다른 모든 변경 사항은 다음 릴리스 주기로 연기됩니다.

피처 프리즈 vs 코드 프리즈: 비교

피처 프리즈와 코드 프리즈의 선택은 팀의 성숙도와 릴리스 빈도에 따라 다릅니다. CI/CD와 피처 플래그를 갖춘 팀은 24시간 코드 프리즈만 필요할 수 있지만, 월간 릴리스 팀은 두 프리즈를 모두 순차적으로 사용하는 경우가 많습니다.

프리즈 유형: 전체, 부분 및 BAU 프리즈

전체 피처 프리즈와 코드 프리즈 외에도 더 유연한 옵션이 있습니다. 부분 피처 프리즈는 특정 모듈(예: 결제 모듈 또는 인증 모듈)에서만 새 기능을 차단하고 다른 구성 요소는 변경할 수 있도록 둡니다.

BAU 프리즈(business as usual freeze)는 타협 옵션으로, 변경량이 특정 임계값(예: 500줄의 코드)을 초과하는 대규모 기능만 금지됩니다. 사소한 개선, UI 조정 및 버그 수정은 계속 병합됩니다. BAU 프리즈는 1주일 동안의 완전한 개발 중단이 경제적으로 불가능한 지속적 전달 프로젝트에 편리합니다.

배포 프리즈(deployment freeze)라는 개념도 있습니다. 이는 프로덕션에 대한 모든 배포를 완전히 중단하는 것으로, 휴일 시즌(크리스마스 휴가, 블랙 프라이데이)의 특징입니다. 이 기간 동안 보안 관련이 아닌 한 핫픽스도 차단됩니다. 배포 프리즈는 일반적으로 1~2주 동안 지속되며 회사 수준에서 조정됩니다.

프리즈 도입 시기와 지속 기간

피처 프리즈를 도입하기 가장 좋은 시기는 코드 완료 후, 모든 계획된 기능이 병합되고 QA를 진행 중일 때입니다. 정확한 시기는 릴리스 주기에 따라 다릅니다. 2주 스프린트의 경우 피처 프리즈는 릴리스 날짜 3~4일 전에 도입되고, 월간 릴리스의 경우 7~10일 전에 도입됩니다. 코드 프리즈는 계획된 릴리스 빌드 시간 24~48시간 전에 도입됩니다.

프리즈 기간은 코드를 안정화하는 데 필요한 최소한이어야 합니다. 너무 긴 프리즈(2주 이상)는 팀의 사기를 저하시키고 병합되지 않은 기능이 축적되어 프리즈 해제 후 각각이 충돌 위험을 높입니다. 너무 짧은 프리즈(피처 프리즈의 경우 24시간 미만)는 충분한 테스트 및 수정 시간을 허용하지 않습니다.

권장되는 방법은 달력 날짜가 아닌 코드베이스 상태에 따라 프리즈를 설정하는 것입니다. 피처 프리즈는 릴리스의 미해결 버그 수가 임계값(예: 10개의 중요 버그)을 초과할 때 도입됩니다. 코드 프리즈는 빌드가 스모크 테스트와 회귀 테스트 스위트를 통과했을 때 도입됩니다. 시간 기반 프리즈(고정 날짜)는 릴리스 날짜가 규제 기관의 승인을 받는 규제 산업(핀테크, 메드테크)에서 여전히 표준입니다.

CI/CD 및 Git을 통한 프리즈 자동화

수동 프리즈 제어는 오류의 원인입니다. 개발자가 실수로 프리즈 해제를 기다려야 하는 PR을 병합할 수 있습니다. 자동화는 Git 브랜치 보호 규칙과 CI/CD 파이프라인을 통해 이를 해결합니다. Git 공급자(GitHub, GitLab, Bitbucket)에서는 특수 태그나 릴리스 관리자의 승인 없이 릴리스 브랜치로의 병합을 차단하는 규칙이 구성됩니다.

CI/CD 파이프라인은 빌드 생성 전에 프리즈 상태를 확인합니다. Jenkins, GitLab CI 또는 GitHub Actions에서는 프리즈 일정이 포함된 구성 파일을 읽고 현재 날짜가 프리즈 기간에 속하면 빌드를 거부하는 단계가 추가됩니다. 다른 방법으로는 관리자 패널의 피처 플래그가 프로덕션 배포를 차단하는 것입니다.

# .github/workflows/check-freeze.yml
name: Check Freeze Status
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  check-freeze:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Check freeze status
        run: node .github/scripts/freeze-check.js
      - name: Block PR if frozen
        if: failure()
        run: echo "Feature freeze is active. PR blocked." && exit 1

예제 freeze-check.js 스크립트는 리포지토리 루트에서 프리즈 일정이 포함된 JSON을 읽습니다. 현재 날짜가 지정된 브랜치의 start_date와 end_date 사이에 있으면 파이프라인이 프리즈 상태 메시지와 함께 실패합니다. Git 브랜치 보호는 두 번째 장벽을 추가합니다. 파이프라인이 트리거되지 않았더라도 규칙은 승인 없이 PR 병합을 허용하지 않습니다.

프리즈 도입 시 흔한 실수

첫 번째 실수는 명확한 해제 기준 없이 프리즈를 하는 것입니다. 팀이 코드를 동결하지만 해제 조건(중요 버그 제로, 회귀 테스트 통과, 제품 관리자 승인)을 정의하지 않습니다. 기준이 없으면 프리즈가 몇 주 동안 지속될 수 있습니다. 프리즈의 완료 정의는 문서화되고 모든 개발자가 알고 있어야 합니다.

두 번째 실수는 프리즈에 너무 많은 예외가 있는 것입니다. 각 예외(“이 PR은 기능이 아니라 기술 부채입니다”)는 프리즈 경계를 모호하게 만듭니다. 예외가 일반 PR 흐름의 20%를 초과하면 프리즈가 작동하지 않습니다. 팀은 차단을 우회하기 위해 기능을 버그 수정으로 이름을 바꿉니다.

세 번째 실수는 릴리스 후보를 무시하는 것입니다. 팀이 릴리스 후보 빌드를 만들지 않고 코드 프리즈 후 프로덕션에 직접 배포하는 경우 프리즈의 목적이 상실됩니다. 사용자가 버그를 발견하게 됩니다. 릴리스 후보는 코드 프리즈 전에 빌드되고 QA 및 스테이징에서 테스트되어야 하며, 품질 확인 후에만 코드 프리즈가 도입되어야 합니다.

네 번째 실수는 수동 제어의 인적 요소입니다. 개발자가 병합 전에 프리즈 상태 확인을 잊을 수 있고, 릴리스 관리자가 알림을 놓칠 수 있습니다. 유일한 신뢰할 수 있는 해결책은 Git 공급자 또는 CI/CD 수준에서의 자동 차단으로, 인적 오류를 제거합니다.