버전 숫자, 그냥 올리셨나요? 1.0.0의 비밀, 아무도 알려주지 않는 룰 🤫

 

개발자라면 누구나 매일 마주치는 v1.2.3, v2.0.0 같은 버전 숫자들! 혹시 "이번엔 기능을 좀 많이 넣었으니 앞 숫자를 올려볼까?" 혹은 "간단한 수정이니 마지막 숫자만 살짝 올려야지" 와 같이 감으로 버전을 올리고 계신가요? 🤔

 

만약 그렇다면, 당신은 자신도 모르게 다른 개발자와의 약속을 어기고 있을지도 모릅니다. 이 버전 숫자들에는 사실 매우 중요하고 엄격한 규칙이 숨어있습니다. 바로 시맨틱 버저닝(Semantic Versioning), 줄여서 SemVer라고 불리는 약속이죠.

 

오늘은 이 버전 숫자의 비밀을 파헤쳐보고, 왜 이 규칙을 지키는 것이 '협업'과 '안정적인 소프트웨어 관리'의 핵심인지 알아보겠습니다.

---

🧐 버전, 그게 뭔데? 왜 중요한데?

소프트웨어 버전은 단순히 업데이트 순서를 나타내는 숫자가 아닙니다. 버전을 통해 우리는 "이번 업데이트에 어떤 성격의 변화가 있었는지"를 예측할 수 있어야 합니다.

 

예를 들어, 내가 사용하던 라이브러리가 v1.5.2에서 v1.5.3으로 업데이트되었다면? "아, 간단한 버그 수정이겠구나. 바로 업데이트해도 내 코드가 망가질 일은 없겠다!"라고 안심할 수 있습니다.

 

하지만 v1.5.2에서 v2.0.0으로 업데이트되었다면? "어? 앞 숫자가 바뀌었네? 이건 기존 코드를 고쳐야 할 수도 있는 큰 변화다. 업데이트 전에 변경 사항을 꼼꼼히 읽어봐야겠다!"라고 경계해야 하죠.

 

이처럼 버전 숫자는 개발자 간의 중요한 의사소통 수단입니다. SemVer는 바로 이 소통을 위한 표준 규칙입니다.

---

📖 시맨틱 버전(SemVer)의 세 가지 약속

SemVer는 메이저(Major).마이너(Minor).패치(Patch)라는 세 부분으로 구성됩니다.

1.0.0을 기준으로 하나씩 살펴볼까요?

🚨 1.x.x: 대격변의 숫자, 메이저(Major)

메이저 버전은 가장 신중하게 올려야 하는 숫자입니다.

• 올리는 순간: 기존 버전과 호환되지 않는(Breaking Change) API 변경이 있을 때.
• 핵심 의미: "주목! 이 업데이트를 적용하면 당신의 기존 코드는 더 이상 작동하지 않을 수 있습니다! 반드시 코드를 수정해야 합니다."

'호환되지 않는 변경'이란 무엇일까요? 말 그대로 이전 버전의 사용법으로는 더 이상 쓸 수 없게 되는 변경을 의미합니다.

🚫 이런 게 바로 메이저 업데이트!

• 함수나 클래스의 이름이 바뀔 때이제 getUserInfo를 호출하던 모든 코드는 에러가 발생합니다.

// 변경 전 (v1.5.2)
function getUserInfo(id) { /* ... */ }

// 변경 후 (v2.0.0)
function fetchUserData(id) { /* ... */ } // 이름 변경!

• 함수의 필수 파라미터가 추가되거나 삭제될 때기존처럼 sendMessage("hello")라고만 호출하면 recipient가 없어서 에러가 발생하겠죠.

// 변경 전 (v2.1.0)
function sendMessage(text) { /* ... */ }

// 변경 후 (v3.0.0)
function sendMessage(text, recipient) { /* ... */ } // 필수 파라미터 recipient 추가!

• 기능의 동작 방식이나 반환 값이 완전히 달라질 때

이처럼 메이저 버전 업데이트는 사용자에게 "큰일 났다, 공부 다시 해야겠다"라는 신호를 주는 것과 같습니다.

---

✨ x.1.x: 새로운 기능의 등장, 마이너(Minor)

마이너 버전은 소프트웨어에 새로운 가치가 더해졌음을 알리는 긍정적인 신호입니다.

• 올리는 순간: 기존 버전과 호환되면서 새로운 기능이 추가될 때.
• 핵심 의미: "걱정 마세요! 당신의 코드는 그대로 작동합니다. 그리고 우리가 만든 멋진 새 기능도 한번 써보세요!"

'호환된다(Backward-Compatible)'는 것이 핵심입니다. 기존 코드는 단 한 줄도 고치지 않아도 완벽하게 동일하게 동작해야 합니다.

 

✅ 이런 게 바로 마이너 업데이트!

• 새로운 함수나 클래스가 추가될 때 calculateSum을 사용하던 코드는 아무런 영향을 받지 않습니다.

// 기존 코드 (v1.2.5)
function calculateSum(a, b) { return a + b; }

// 새로운 기능 추가 (v1.3.0)
function calculateSum(a, b) { return a + b; }
function calculateProduct(a, b) { return a * b; } // 새로운 함수 추가!

 

• 기존 함수에 선택적(Optional) 파라미터가 추가될 때 기존처럼 createUser("John", "john@email.com")으로 호출해도 options는 기본값({})을 가지므로 문제없이 작동합니다.

// 변경 전 (v1.3.4)
function createUser(name, email) { /* ... */ }

// 변경 후 (v1.4.0)
function createUser(name, email, options = {}) { /* ... */ } // 선택적 파라미터 추가!
기존처럼 createUser("John", "john@email.com")으로 호출해도 options는 기본값({})을 가지므로 문제없이 작동합니다.

• 곧 사라질 기능이라고 예고(deprecated)할 때 (실제 삭제는 메이저 업데이트!)

마이너 업데이트는 사용자들이 부담 없이 적용하고 새로운 기능을 탐색하게 만드는 기분 좋은 업데이트입니다.

---

🐛 x.x.1: 버그는 조용히 사라질 뿐, 패치(Patch)

패치 버전은 가장 빈번하게 일어나며, 가장 안전한 업데이트입니다.

• 올리는 순간: 기존 버전과 호환되면서 버그를 수정할 때.
• 핵심 의미: "기존에 있던 문제가 해결되었습니다. 새로운 기능은 없으니 안심하고 업데이트하세요."

패치 버전은 기능적인 변화가 전혀 없어야 합니다. 오로지 내부적인 오류 수정이나 성능 개선에만 집중합니다.

🛠️ 이런 게 바로 패치 업데이트!

• 계산 로직의 오류를 바로잡을 때

  // 버그가 있던 코드 (v1.4.1)
  function getDiscountPrice(price, discount) {
    return price + (price * discount); // 버그! 할인이 아니라 할증이 됨
  }
  
  // 버그 수정 (v1.4.2)
  function getDiscountPrice(price, discount) {
    return price - (price * discount); // 올바르게 수정
  }
  

• 보안 취약점을 해결할 때
• 성능 저하 문제나 메모리 누수를 해결할 때
• 문서나 주석의 오타를 수정하는 사소한 변경

---

숲을 봅시다: 그래서 SemVer가 왜 그렇게 중요할까? 🌲

이 규칙을 지키는 것은 단순히 깔끔해 보이기 위함이 아닙니다. 현대 소프트웨어 개발의 핵심인 '의존성 관리(Dependency Management)'와 직결되기 때문입니다.

우리가 만드는 프로그램은 수많은 다른 라이브러리(의존성)들을 가져와 조립하는 방식으로 만들어집니다. 이때 package.json 같은 파일에 버전을 명시하죠.

{
  "dependencies": {
    "react": "^18.2.0",
    "some-library": "~1.3.1"
  }
}

여기서 보이는 ^ (캐럿)과 ~ (틸드)가 바로 SemVer 규칙을 활용하는 똑똑한 장치입니다.

• ~1.3.1: "1.3.x 버전 내에서 가장 최신 패치 버전으로 설치해줘." (예: 1.3.2, 1.3.5는 되지만 1.4.0은 안됨)
• ^18.2.0: "18.x.x 버전 내에서 호환성이 보장되는 가장 최신 마이너, 패치 버전으로 설치해줘." (예: 18.2.1, 18.3.0은 되지만 19.0.0은 안됨)

만약 some-library 개발자가 SemVer를 무시하고, 버그 수정이라며 1.3.2 버전에 호환성이 깨지는 변경을 포함시켰다면 어떻게 될까요? 우리는 안전할 것이라 믿고 업데이트했지만, 우리 프로젝트는 갑자기 이유도 모른 채 망가질 것입니다. 끔찍하죠? 😱

SemVer는 개발자들 사이의 신뢰이며, 안정적인 생태계를 유지하는 최소한의 약속입니다.

요약: 한눈에 보는 버전 업 규칙 📜

버전변경 내용호환성예시

버전	변경 내용	호환성	예시
메이저 (1.x.x)	API 변경	깨짐 (Breaking)	함수 이름 변경, 파라미터 삭제
마이너 (x.1.x)	새로운 기능 추가	유지 (Backward-compatible)	새로운 함수 추가, 선택적 파라미터 추가
패치 (x.x.1)	버그 수정	유지 (Backward-compatible)	계산 오류 수정, 보안 패치

 

이제 버전 숫자를 볼 때마다 그 안에 담긴 의미가 보이시나요? 여러분이 만드는 소프트웨어의 버전을 정할 때도, 이 약속을 꼭 지켜주세요. 그것이 동료와 미래의 나를 돕는 가장 확실한 방법입니다.

---