버전 꼬임 이제 그만: Cursor AI로 ‘update:minor’ 한 줄에 끝낸 릴리즈 혁명

버전 올리기가 이렇게 귀찮다니..

 안녕하세요. 저는 화물운송 플랫폼 Sendy에서 Next.js와 TypeScript를 주력으로 사용하는 프론트엔드 개발자입니다. 제가 회사에 입사한 지 1년 남짓 되었는데요. 제가 오기 전, 처음 두 명이던 팀에서는 코드리뷰가 강제가 아니어서 package.json 숫자를 직접 바꾸고 PR을 바로 머지해도 큰 문제가 없었습니다.

 그러나 세 번째 인원이 합류하면서 코드 리뷰 문화가 정착됐고 소규모 조직으로서의 모습을 갖추었습니다. 개발 인원의 증가에 따라 업무량이 많아지면서 PR이 쌓이기 시작했습니다. 그에 따라 코드 리뷰가 지연되기 시작했고, 릴리즈가 제때 이루어지지 않았습니다. 그 결과 “이번엔 누가 버전을 올려야 할까요?”라는 질문이 자연스럽게 돌아왔습니다.

 한 번은 제가 버전 업데이트를 깜빡한 채 릴리즈를 진행했습니다. 배포 후 몇 분 만에 “버전은 올리셨나요?”라는 슬랙 알림을 받고, 부랴부랴 ‘버전만 올리는 긴급 PR’을 작성해 다시 릴리즈해야 했습니다. 이후로 파트원들도 같은 실수를 반복했습니다. 작은 실수였지만 팀 전체의 흐름이 꼬였고, “다음부터는 꼭 자동화해야겠다”는 절실함이 생겼습니다.

---

제가 겪었던 세 가지 Pain Point

1. 릴리즈 직전의 수동 버전 수정
   • package.json과 package-lock.json을 모두 열어 숫자를 맞춰 적어야 했습니다.
   • 정말 쉬운 일이지만 이슈가 끝날 때마다 같은 일을 반복해야 해서 번거롭고 피곤하게 느껴졌습니다.
2. 제대로 동작하지 않는 npm version
   • 사내 규칙상 버전을 major.minor 두 단계로만 유지해 npm version patch 명령이 맞지 않았습니다.
3. 사소하지만 빈번한 실수
   • 누군가는 버전을 올렸는데, 다른 사람이 또 올려 충돌이 발생했습니다.
   • 때로는 버전 올리기를 잊고 PR을 머지해 릴리즈 버전이 꼬였습니다.

---

초기 대안 - Semantic Release

학습 곡선	커밋 메시지 규칙만 익히면 CI가 자동으로 릴리즈했습니다	자유로운 커밋 문화를 지키고 싶었습니다
커뮤니티	⭐️ 21 만, 플러그인 생태계 풍부	플러그인을 이해하고 구성해야 하는 부담
CI 통합	GitHub Actions 예제가 잘 준비돼 있었습니다	우리 팀 규모에는 “과하다”는 의견이 많았습니다

결론: “커밋 규칙 강제”가 주는 러닝 커브가 이득보다 크다고 판단했습니다. 그래서 직접 스크립트 코드를 작성하기로 결정했습니다.

---

해결책 - “라벨 하나면 끝!” 전략

1. 버전 업데이트 스크립트 코드 작성

1. Cursor AI에게 “major.minor 체계를 유지하면서 CLI로 버전을 올리는 스크립트를 작성해 달라”고 요청했습니다.
2. 받은 코드를 scripts/update-version.js로 저장하고 node scripts/update-version.js [major | minor] 형태로 호출하도록 했습니다.
3. package.json에 다음과 같이 등록해 사용했습니다.

"scripts": {
  "version:major": "node scripts/update-version.js major",
  "version:minor": "node scripts/update-version.js minor"
}

---

2. GitHub Actions와 라벨링 자동화

1. 라벨 정의: update:major, update:minor 두 가지만 만들었습니다.
2. 머지 트리거: PR이 main에 병합될 때 라벨을 확인해 대응 스크립트를 실행했습니다.
3. CI 스텝 예시

on:
  pull_request:
    types: [closed]

jobs:
  bump-version:
    runs-on: ubuntu-latest
    if: github.event.pull_request.merged == true && github.event.pull_request.base.ref == 'main' && (contains(github.event.pull_request.labels.*.name, 'update:major') || contains(github.event.pull_request.labels.*.name, 'update:minor')) }}
    steps:
      - uses: actions/checkout@v4
      - name: Set up Node
        uses: actions/setup-node@v4
        with: { node-version: 20 }
      - name: Run version script
        run: |
          LABELS="${{ join(github.event.pull_request.labels.*.name, ',') }}"
          if [[ "$LABELS" == *"update:major"* ]]; then
            npm run version:major
          elif [[ "$LABELS" == *"update:minor"* ]]; then
            npm run version:minor
          else
            echo "No version label, skipping."
          fi
      - name: Push tag & version bump
        run: |
          git push --follow-tags

1. CI 실행 시간은 약 10–15 초였으며, 태그 푸시까지 자동으로 처리했습니다.

---

3. 프로젝트 Github 권한 설정

 버전을 올린 뒤에는 태그와 함께 git push가 이뤄져야 했습니다. 그러나 GitHub Actions가 리포지토리에 쓰기(write) 권한을 가지려면, 프로젝트 Admin이 권한을 부여해 주어야 했습니다.

 저는 해결해야 할 문제 상황과 요구 사항을 정리해 회사 CTO님께 요청드렸습니다.

“릴리즈 자동화를 위해 GitHub Actions 봇에게 write 권한이 필요합니다. 태그-푸시까지 자동으로 이루어지면 버전 꼬임 사고를 많이 없앨 수 있습니다.”

 CTO님께서는 내용을 검토하시고 “정말 좋은 아이디어”라며 바로 권한을 열어 주셨습니다. 덕분에 버전 스크립트 → 태그 푸시까지 전 과정이 완전히 자동화됐고, 팀원들은 릴리즈 과정에서 한 단계 더 손을 뗄 수 있었습니다.

---

결과 - 팀원들의 DX가 눈에 띄게 향상됐습니다

자동화를 도입한 이후 다음과 같은 효과를 얻었습니다.

• “버전을 올릴 사람”을 정할 필요가 없어 컨텍스트 스위치가 줄었습니다.
• 릴리즈 전에 CI가 버전을 올려 주어 버전이 꼬이는 일이 사라졌습니다.
• 단점으로는 CI가 종료될 때까지 기다려야 한다는 점이 있지만, 대개 1분 내외여서 큰 불편은 없었습니다.

 무엇보다 스스로 느끼는 가장 큰 장점은 "같은 일을 반복하지 않아도 된다!"는 사실이었습니다. "지금 이대로도 문제 없는데 왜 굳이 개선해?" 라며 현 상황을 유지했다면 지금까지도 자주 버전 업데이트를 잊고 긴급 PR을 작성했을 겁니다.

---

다음 과제 - 더 똑똑한 자동화?

• 라벨 자동 추천: PR 제목에 feat:가 있으면 update:minor, BREAKING CHANGE가 있으면 update:major를 자동으로 제안할 계획입니다.
• 챗봇 UI 도입: Slack 봇이 “다음 버전을 vX.Y로 올릴까요?”라고 묻고, 팀원이 클릭 한 번으로 확정하는 방식을 구상하고 있습니다.

---

마무리

 자동화를 도입하기 전에는 릴리즈 때마다 “혹시 또 버전을 놓치지 않을까” 하는 불안이 머릿속을 떠나지 않았습니다. 푸시한 뒤에도 한 번 더 파일을 열어 숫자가 맞는지 다시 확인했고, 배포하기 직전에는 작은 오타 하나에도 손이 떨렸습니다. 하지만 라벨 + Cursor AI 조합을 적용한 뒤로는 “버전 걱정”이 업무 목록에서 완전히 사라졌습니다. 덕분에 리뷰 코멘트를 좀 더 세심하게 남길 수 있었고, 회의 시간에도 기능 기획에 집중할 여유가 생겼습니다.

 팀 분위기도 눈에 띄게 달라졌습니다. 파트리드께서는 “릴리즈 체크리스트에서 버전 항목을 지웠다”며 만족해하셨고, 파트원 역시 "배포 절차가 단순해져서 좋다"는 소감을 남겼습니다. 작은 자동화지만, “우리가 실수할 수도 있는 영역”을 시스템이 대신 맡아 준다는 사실만으로도 팀원이 느끼는 심리적 안전감이 크게 높아졌습니다.

 버전 관리는 겉보기에 사소해 보여도, 매주 반복된다면 팀의 생산성을 좌우하는 핵심 루틴입니다. 하루 투자로 완성한 이 간단한 자동화가 저희 팀의 개발 경험을 한층 쾌적하게 만들었습니다. 여러분도 팀 상황에 맞는 가벼운 자동화를 도입해 보시길 권해드립니다. 작은 귀찮음을 없애는 순간, 더 재미있는 문제에 집중할 힘이 생깁니다.

---

참조

• https://github.com/semantic-release/semantic-release