프론트엔드 버전 관리(Major.Minor.Patch)

프론트엔드 프로젝트 진행하다 보면 버전을 올려야 하는 상황 자주 발생함
하지만 patch인지 minor인지 major인지 헷갈리는 경우 많음

버전은 보통 아래 구조 사용함

 

MAJOR.MINOR.PATCH 예 1.4.2

버전 판단 기준은 사용자 기준이 아니라 개발자 API 기준임

---

PATCH 버전

예 1.4.2 → 1.4.3

 

의미

• 기능 변화 없음
• 버그 수정 또는 내부 개선

프론트엔드 예시

• CSS 깨짐 수정
• console error 제거
• API 호출 오류 fix
• edge case 처리
• 성능 최적화
• 내부 refactoring 외부 영향 없음

예시

<div className="card" />

 

스타일 버그 수정만 진행

기존 기능 동일하면 patch

---

MINOR 버전

예 1.4.2 → 1.5.0

 

의미

• 새 기능 추가
• 기존 코드 깨지지 않음

프론트엔드 예시

• 새로운 UI 추가
• 새로운 페이지 추가
• 새로운 API 사용
• optional prop 추가

예시

API에 새로운 field 추가

{ "name": "철수", "nickname": "chulsoo" }

 

FE에서 nickname 입력 UI 추가 및 저장 기능 추가

기존 기능 그대로 동작

 

minor 또 다른 예

<Button loading />

optional prop 추가

기존 코드 영향 없음

---

MAJOR 버전

의미

Breaking change
기존 코드 깨짐
사용 방식 변경됨
업데이트하면 기존 프로젝트가 그대로 동작하지 않을 가능성 있음

언제 올림

• 컴포넌트 props 구조 변경
• 함수 signature 변경
• API 응답 구조 변경으로 기존 로직 수정 필요
• 기존 기능 제거(deprecated 제거)
• 디자인 시스템 전체 변경
• React major 업데이트로 사용 방식 변경

버전 예시
1.4.2 → 2.0.0

 

코드 예시

기존 (v1.x)

type ButtonProps = {
  size: "small" | "large"
}

<Button size="small" />

변경 (v2.0.0)

type ButtonProps = {
  variantSize: "sm" | "lg"
}

<Button variantSize="sm" />

왜 MAJOR인가
기존 코드 <Button size="small" /> 전부 에러 발생
사용자가 코드 수정해야 정상 동작
즉 하위 호환 깨짐 → MAJOR 버전 증가

---

왜 major 잘 안 올리는지

breaking change 발생하면 다른 팀 코드 깨질 가능성 있음
migration 비용 증가
배포 리스크 증가

그래서 deprecated 처리 후 다음 major에서 제거 전략 많이 사용함