소프트웨어 버전이란?
Source: Dev.to
저는 소프트웨어 버전이 매 업데이트마다 바뀌는 연속적인 숫자라고 생각했었습니다.
왜 v1.1에서 v1.2로 바뀔까요?
왜 갑자기 v2.0으로 뛰어오를까요?
그날 개발자가 그냥 드라마틱하게 느꼈던 걸까요?
그러다 작은 앱을 만들면서 어느 순간 깨달았습니다.
The First Release
우리 둘이 TaskNest라는 간단한 앱을 만든다고 상상해 보세요.
작업을 만들고 완료 표시를 할 수 있습니다. 특별한 기능은 없습니다.
우리는 자랑스럽게 이렇게 출시합니다:
v1.0.0
첫 번째 “1”은 강력한 의미를 가집니다. 그것은 말합니다:
“이것은 실제입니다. 이것은 안정적입니다. 이것은 준비되었습니다.”
0들은? 아직 추가된 것이 없다는 뜻일 뿐입니다.
이 형식은 실제로 Semantic Versioning이라는 간단한 아이디어를 따릅니다.
A Bug Appears
다음 날, 누군가 보고합니다:
“빈 작업을 만들면 앱이 충돌합니다.”
우리는 즉시 고칩니다. 새로운 기능도 없고, 디자인 변경도 없습니다. 단지 수리일 뿐입니다.
버전은 이렇게 됩니다:
v1.0.1
마지막 숫자만 바뀌어, 다음을 알립니다:
“걱정 마세요. 새로운 것이 없습니다. 작은 수정뿐입니다.”
다른 작은 문제를 또 고친다면:
v1.0.2
작은 수리 = 작은 번호 변화.
A Feature Grows
일주일 후, 사용자들이 묻습니다:
“작업에 마감일을 추가할 수 있을까요?”
그건 수정이 아니라 성장입니다. 마감일을 추가하고, 다른 모든 것이 그대로 작동하도록 합니다.
이제는:
v1.1.0
중간 숫자가 증가하면서 속삭입니다:
“새로운 것이 들어왔습니다.”
나중에 카테고리를 추가한다면:
v1.2.0
더 많은 기능, 여전히 안전하고 호환됩니다.
The Big Decision
몇 달이 흐릅니다. 앱이 성장합니다. 그리고 우리는 작업이 내부적으로 저장되는 방식을 재설계하기로 결정합니다.
- 기존에 저장된 데이터가 작동하지 않음.
- API가 변경됨.
- 우리 통합을 사용하는 개발자들은 코드를 업데이트해야 함.
이번은 심각하므로 우리는 출시합니다:
v2.0.0
1에서 2로의 점프는 자존심 때문이 아니라 영향력 때문입니다. 세계에 이렇게 알리는 방법이죠:
“조심하세요. 이것이 깨질 수도 있습니다.”
And That’s It
이것이 버전 관리입니다: 세 개의 숫자, 세 개의 신호.
- 마지막 숫자 → 작은 수정
- 중간 숫자 → 새로운 기능
- 첫 번째 숫자 → 파괴적 변화
무작위가 아닙니다. 소통입니다.
v2.1.3을 보면 단순히 숫자를 보는 것이 아니라 역사를 보는 것입니다.
이제 무언가를 배포할 때마다 저는 묻지 않습니다:
“어떤 번호를 골라야 할까?”
제가 묻는 것은:
“스토리를 얼마나 바꿨나요?”