1인 개발자를 위한 가장 현실적인 Git 브랜치 전략: Main + Develop

1인 개발자를 위한 가장 현실적인 Git 브랜치 전략: Main + Develop

2026년 2월 10일

처음엔 혼자 만드는데 브랜치 전략이 왜 필요하냐고 생각했습니다. 첫 배포 이후, 생각이 바뀌었습니다.

1. 문제 상황

크롬 익스텐션 한스푼을 개발하면서 초기에는 별다른 브랜치 전략 없이 main에 직접 커밋했다.

프로젝트 생성, 초기 기능 구현, 배포 준비까지 모두 main 하나에서 이루어졌다. 혼자 만드는 프로젝트인데 복잡한 브랜치가 필요하다고 생각하지 않았다.

그런데 v0.0.1을 크롬 웹 스토어에 배포하고 나서는 상황이 달라졌다.

  • “지금 main이 스토어에 올라간 버전이랑 같은 코드인가?”
  • “새 기능 개발하다가 main이 깨지면 어떻게 되지?”
  • “이전에 배포한 v0.0.1은 어디서 확인하지?”

사용자가 설치한 버전이 존재하는 순간부터, main은 더 이상 내 전용 작업 공간이 아니었다. 그 시점에서 “배포된 코드”와 “개발 중인 코드”를 구분해야 한다는 필요성이 생겼다.

2. 내가 처음 한 생각

처음 든 생각은 이것이었다.

“1인 개발인데 Git Flow처럼 복잡하게 할 필요가 있나?”

팀 프로젝트에서 쓰는 Git Flow는 main, develop, feature/*, release/*, hotfix/*까지 5종류의 브랜치를 운용한다. 혼자 하는 프로젝트에 이걸 그대로 적용하면 오버엔지니어링이 될 것 같았다.

그래서 처음에 떠올린 건 단순한 feature 브랜치 방식이었다.

main ──────────────────── (항상 안정)
└── feature/xxx ── (개발 후 main에 머지)

하지만 이 방식도 문제가 있었다. 배포 전에 여러 기능을 동시에 개발하면, 무엇이 배포되었고 무엇이 개발 중인지 여전히 main만 봐서는 파악하기 어려웠다.

그래서 관점을 바꿨다.

“브랜치 전략은 협업을 위한 게 아니라, 배포 상태를 명확히 하기 위한 도구다.”

3. 실제로 해 본 선택

main + develop 두 브랜치 전략

Git Flow보다 단순하게, GitHub Flow보다는 구조적으로, main과 develop 두 브랜치만 운용하는 전략을 택했다.

main ──●────────────●──────────●── (배포 가능한 상태)
↑ ↑ ↑
PR PR PR
develop ───●──●──●──●───●──●──●────●── (개발 진행 중)
브랜치역할
main크롬 웹 스토어에 배포된 안정 버전
develop개발 진행 중인 코드

규칙은 단순하다.

  • 개발은 develop에서 한다.
  • main은 PR을 통해서만 머지한다.
  • main에 직접 push는 브랜치 보호 규칙으로 막는다.

GitHub Releases로 버전 관리

크롬 익스텐션은 스토어 제출 시 manifest.json의 버전이 이전보다 높아야 한다. 즉, 버전 관리가 단순한 숫자가 아니라 배포의 전제 조건이다.

이 점에서 Semantic Versioning을 기준으로 삼고, GitHub Releases를 버전의 공식 기록으로 활용하기로 했다.

v0.0.1 → v0.0.2 → v0.0.3

각 릴리즈에는 배포된 기능 목록을 정리해두었다. 어떤 버전에 어떤 기능이 들어갔는지 나중에 되돌아볼 수 있는 기록이 된다.

CI로 버전 변경을 강제

develop → main PR을 올릴 때, apps/extension/package.json의 버전이 올라갔는지 확인하는 GitHub Actions를 추가했다.

# .github/workflows/version-check.yml
on:
  pull_request:
    branches: [main]
    paths:
      - "apps/extension/**"

버전을 올리지 않으면 CI가 실패하고 머지가 막힌다. 규칙을 기억에 의존하지 않고 코드로 강제한 것이다.

이는 실제로 한 번 효과가 있었다. v0.0.2 때 버전 올리는 것을 깜빡하고 PR을 올렸는데, CI가 막아줘서 스토어 제출 전에 잡아낼 수 있었다.

4. 결과

v0.0.1, v0.0.2, v0.0.3을 각각 독립적으로 추적할 수 있게 되었고, main을 보면 항상 “이게 지금 스토어에 올라간 코드”라고 확신할 수 있게 되었다.

무엇보다 배포 상태에 대한 불안감이 사라졌다. 예전엔 “main이 지금 배포된 버전이랑 같은가?” 를 코드를 열어봐야 알 수 있었지만, 지금은 브랜치 구조 자체가 답을 준다.

단, 한 가지 솔직한 단점이 있다. 1인 개발에서 PR 리뷰어가 없다 보니, PR이 형식적인 절차가 되기 쉽다. 코드 리뷰가 없는 PR은 “머지 버튼 누르는 의식” 에 가까워진다. 이 부분은 여전히 개선이 필요하다.

5. 지금 다시 해본다면?

배포 전에 브랜치 전략을 먼저 잡을 것이다.

처음 main에 직접 커밋하던 시점으로 돌아간다면, 프로젝트 생성 직후에 develop 브랜치를 만들고 시작했을 것이다.

브랜치 전략은 팀이 생겼을 때 도입하는 게 아니라, 사용자가 생겼을 때 필요해진다. 사용자가 설치한 버전이 존재하는 순간, 코드에는 책임이 생기기 때문이다.

GitHub Releases도 마찬가지다. v0.0.1부터 체계적으로 기록해두면, 나중에 “어느 버전에 뭐가 들어갔더라?”를 찾아 헤매지 않아도 된다.

참고