1인 개발자도 Git 브랜치·PR 써야 할까

이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.

혼자 개발하다 보면 이런 생각이 든다. "메인 브랜치? 기능 브랜치? 풀 리퀘스트? 이거 다 팀에서 여러 명이 부딪히지 않으려고 하는 거 아니었어? 나 혼자인데 그냥 main에 바로 커밋하면 안 되나?"

맞다. 절반은 맞는 말이다. 브랜치와 PR 문화의 상당 부분은 "여러 사람이 같은 코드를 동시에 건드릴 때 충돌을 막는" 목적이다. 혼자라면 그 목적은 통째로 사라진다.

그런데도 1인 개발자에게 끝까지 남는 이유가 있다. 이 글은 팀용 명분을 걷어내고, 혼자일 때 진짜로 도움이 되는 것만 골라낸다. 결론부터 말하면 — 다 할 필요는 없지만, 딱 두세 가지는 혼자여도 확실히 남는다.

먼저, 세 단어가 각각 뭔지부터

용어가 어렵게 느껴지는 이유는 대부분 "그래서 이게 실제로 뭐냐"를 건너뛰고 규칙부터 배우기 때문이다. 비유로 정리하자.

`main` 브랜치 = 손님에게 내놓는 진열대

main(예전엔 master)은 그냥 "이건 완성돼서 언제든 내놔도 되는 버전"이라고 약속한 한 줄기다. 특별한 기술이 있는 게 아니라, 사람들이 "main = 믿을 수 있는 버전"으로 취급하기로 정한 관습이다.

당신의 프로젝트가 Vercel이나 다른 곳에 자동 배포된다면, 보통 main에 올라간 코드가 곧 실서비스가 된다. 즉 main은 "실험실"이 아니라 "매장"이다.

브랜치(branch) = 눈치 안 보고 어지를 수 있는 작업대

브랜치는 main을 그 순간 그대로 복사한 평행우주다. 여기서 뭘 하든 main에는 영향이 없다.

새 기능을 반쯤 만들다 말아도 → main은 멀쩡하다.
뭔가 잘못 건드려서 다 깨졌어도 → 그 브랜치만 버리면 된다.
파일을 20개 갈아엎는 대공사를 해도 → 옆 우주(main)는 그대로다.

핵심 감각은 이거다. 브랜치는 "실패해도 되는 공간"이다.

PR(Pull Request) = "이 작업대의 결과를 진열대에 합치겠습니다"라는 제안 + 기록

브랜치에서 작업이 끝나면, 그 변경을 main에 합쳐야 한다. 이때 "이 브랜치를 main에 병합해 주세요"라고 올리는 게 PR이다.

PR은 그냥 병합 버튼이 아니다. 그 안에는:

이번에 무엇을 바꿨는지 (파일 단위 diff)
왜 바꿨는지 (내가 적은 설명)
합치기 전 자동 검사(테스트·빌드) 통과 여부

가 한 장에 모인다. 팀에선 이걸로 동료가 리뷰하지만, 혼자라면 리뷰어가 미래의 나가 된다.

팀에서 쓰는 이유 중, 혼자면 버려도 되는 것

솔직하게 걸러내자. 아래는 1인 개발자에게 거의 의미 없는 명분이다.

팀에서의 이유	혼자일 때
여러 명이 같은 파일 동시 수정 → 충돌 방지	나 혼자라 충돌 자체가 안 남
동료 코드 리뷰로 품질 관리	리뷰해 줄 동료가 없음
누가 무슨 작업 중인지 공유	내가 다 알고 있음
승인 없이 배포 못 하게 통제	내가 승인자 겸 개발자

이걸 그대로 따라 하면 그냥 혼자 하는 요식행위가 된다. "1인 개발자인데 왜?"라는 의문은 여기서 나온다. 정당한 의문이다.

그러니 위 항목들은 잊어라. 이제 혼자여도 남는 것만 본다.

혼자여도 진짜 남는 이유 4가지

1. main을 "항상 작동하는 버전"으로 지킬 수 있다

이게 가장 크다. 자동 배포를 쓴다면 특히 그렇다.

바로 main에 커밋하는 습관이면, 반쯤 만든 기능·실험 코드가 그대로 실서비스에 올라간다. 저녁에 "잠깐 이것만 고쳐볼까" 하고 main을 건드렸다가 사이트가 깨진 채로 밤새 방치되는 게 이 방식의 전형적인 사고다.

브랜치를 쓰면 규칙이 단순해진다.

main은 언제나 배포 가능한 상태. 불안정한 건 전부 브랜치에서.

실험은 브랜치에서 실컷 어지르고, 완성돼서 검증된 것만 main으로 넘긴다. 그러면 main은 항상 "지금 당장 배포해도 안 터지는 버전"으로 유지된다.

2. 실패를 두려워하지 않고 대담하게 실험할 수 있다

초보일수록 "이거 건드렸다가 망하면 어떡하지"라는 공포 때문에 소극적으로 코딩한다. 브랜치는 그 공포를 없애준다.

git switch -c try-new-idea   # 새 실험용 브랜치 생성 + 이동
# ...마음껏 갈아엎는다...

이 실험이 성공하면 main에 합치고, 망하면:

git switch main              # 원래 안전한 곳으로 복귀
git branch -D try-new-idea   # 실험 브랜치 통째로 폐기

방금 저지른 대참사가 흔적 없이 사라진다. main은 손도 안 댔으니까. 이 "언제든 깨끗하게 되돌아갈 곳이 있다"는 안정감이 실력 성장의 속도를 바꾼다.

3. PR은 "미래의 나"를 위한 변경 일지가 된다

혼자여도 3개월 뒤의 나는 사실상 남이다. "이 코드 왜 이렇게 짰지? 내가 짠 거 맞나?"는 1인 개발자의 국룰이다.

PR을 남기면 각 변경마다:

무엇을 바꿨고 (diff가 자동 기록)
왜 그랬는지 (설명란에 내가 한 줄 남김)

가 GitHub에 영구 보관된다. 나중에 "이 기능 언제, 왜 이렇게 바뀌었지?"를 검색하면 PR 목록이 그대로 답을 준다. 커밋 메시지만으로도 어느 정도 되지만, PR은 "관련된 커밋 여러 개 + 의도 설명 + 검사 결과"를 한 묶음으로 보여준다는 게 다르다.

4. 병합 전에 자동 검사(CI)가 한 번 막아준다

GitHub에 PR을 올리면, 미리 설정해 둔 자동 검사(테스트 실행, 빌드 성공 여부 등)가 돌아간다. 이게 초록불이어야 병합하는 규칙을 세우면:

빌드가 깨지는 코드가 main에 못 들어간다 = 배포가 터질 코드를 사전 차단
테스트가 실패하는 코드도 마찬가지

혼자라 리뷰어는 없지만, 자동 검사가 "말 없는 리뷰어" 역할을 해준다. 특히 Vercel 같은 플랫폼은 PR마다 미리보기(Preview) URL을 자동으로 만들어준다. main에 합치기 전에 "실제 배포된 모습"을 그 임시 주소에서 눈으로 확인하고 넘길 수 있다. 이건 혼자일수록 오히려 더 유용하다 — 봐 줄 사람이 나밖에 없으니까.

그래서, 최소한의 실전 워크플로우

거창하게 갈 필요 없다. 1인 개발자에게 충분한 최소 루틴은 이렇다.

1) 새 작업 시작 — main에서 브랜치를 딴다

git switch main
git pull                       # 원격의 최신 main을 먼저 받아온다
git switch -c feature/login    # 이번 작업용 브랜치 생성

브랜치 이름은 feature/무엇, fix/무엇처럼 뭘 하는 브랜치인지 드러나게 짓는다.

2) 작업하면서 커밋 — 의미 단위로 쪼갠다

git add .
git commit -m "로그인 폼 UI 추가"
# ...계속 작업...
git commit -m "로그인 API 연동"

3) 원격에 올리고 PR 생성

git push -u origin feature/login

그다음 GitHub에서 "Compare & pull request" 버튼을 누르거나, GitHub CLI가 있다면:

gh pr create --fill

4) 자동 검사 초록불 + 미리보기 확인 → 병합

검사가 통과하고 미리보기가 멀쩡하면 "Merge" 버튼. 병합되면 그게 곧 배포다.

5) 끝난 브랜치 정리

git switch main
git pull
git branch -d feature/login    # 로컬 브랜치 삭제

이 다섯 단계가 전부다. 몸에 붙으면 한 사이클에 몇 초 안 걸린다.

반대로, 오버엔지니어링 하지 마라

브랜치·PR을 배우면 "규칙을 완벽하게 지켜야 한다"는 강박이 생기기 쉽다. 혼자라면 아래는 하지 마라. 시간만 잡아먹는다.

오타 하나 고치는데 브랜치 파기 — 사소하고 안전한 변경은 main에 바로 커밋해도 된다. 격식은 "위험한 변경"에만 쓴다.
거창한 브랜치 전략(git-flow 등) 도입 — develop/release/hotfix 여러 층으로 나누는 전략은 여러 팀이 릴리스 주기를 관리하려고 만든 것이다. 혼자면 main + 짧은 작업 브랜치, 이 2단이면 충분하다.
PR에 장문의 리포트 쓰기 — 혼자 볼 건데 한두 줄이면 된다. "왜 이렇게 했는지"만 남겨라.
셀프 리뷰 승인 절차 강제 — 내가 올리고 내가 승인하는 형식적 절차는 무의미하다. 자동 검사만 걸어라.

핵심 원칙: 격식은 "실패했을 때 아플 변경"에 비례해서 쓴다. 안전한 건 가볍게, 위험한 건 브랜치로.

정리

"1인 개발자인데 왜?"에 대한 답:

여러 명 충돌 방지·동료 리뷰·작업 공유 → 혼자면 버려도 된다. 이게 의문의 원인이었다.
main을 항상 배포 가능한 상태로 유지 → 혼자여도 남는다. (특히 자동 배포면 필수급)
실패해도 되는 실험 공간 → 혼자여도 남는다. 대담하게 코딩하게 해준다.
미래의 나를 위한 변경 기록(PR) → 혼자여도 남는다.
병합 전 자동 검사·미리보기 → 혼자여도 남는다. 말 없는 리뷰어.

브랜치와 PR은 "팀을 위한 규칙"이기 전에 "과거·미래의 나와 협업하는 도구"다. 혼자라고 협업이 없는 게 아니다. 3개월 전의 나, 3개월 후의 나가 늘 옆에 있다. 그 둘을 위해서라면, 이 정도 습관은 혼자여도 충분히 남는 값을 한다.