17장. 브랜치와 PR: 망치지 않고 고치는 법

커밋만으로는 부족한 순간이 온다

지난 장에서 우리는 커밋이 왜 중요한지 배웠습니다. 커밋은 "여기까지는 안전하다"라고 표시하는 체크포인트였습니다. 이 습관만 생겨도 개발이 훨씬 덜 무서워집니다.

그런데 서비스를 조금 더 만들기 시작하면 새로운 문제가 생깁니다. 커밋을 잘 남기고 있어도, 지금 잘 돌아가는 작업 위에서 바로 새 기능을 고치는 것 자체가 불안한 순간이 옵니다.

예를 들어 지금 메인 화면은 잘 보이고, 게시글 목록도 정상적으로 뜬다고 해 봅시다. 그런데 여기에 로그인 기능을 붙이고 싶습니다. 이 작업은 생각보다 손이 많이 갑니다. 버튼도 바뀌고, 헤더도 바뀌고, 상태 관리도 바뀌고, 서버 연결도 건드릴 수 있습니다. 만약 이 작업을 현재 잘 돌아가는 코드 위에서 바로 시작하면 어떨까요?

기능 하나를 고치다가 다른 기능이 함께 흔들릴 수 있습니다. 커밋이 있으니 되돌릴 수는 있지만, 작업 도중에는 계속 불안합니다. "지금 상태가 반쯤 망가진 건지, 아직 진행 중인 건지"도 헷갈립니다.

바로 이때 필요한 것이 브랜치입니다.

브랜치는 쉽게 말해, 본 작업을 지켜 둔 채 다른 길에서 안전하게 수정해 보는 방법입니다. 초보자에게 이 개념은 아주 중요합니다. 잘하는 사람보다 먼저 필요한 것은 빠르게 고치는 능력이 아니라, 망치지 않고 고치는 구조이기 때문입니다.

브랜치는 '평행한 작업 길'이다

브랜치라는 말을 처음 들으면 어렵게 느껴집니다. 하지만 감각은 의외로 단순합니다.

하나의 프로젝트 안에서 작업 흐름을 갈라서 관리하는 것입니다.

비유해 보면 이렇습니다. 지금 여러분의 프로젝트에는 "현재 공개 가능한 안정 버전"이라는 길이 하나 있습니다. 이 길을 우리는 보통 main 브랜치라고 부릅니다. 여기서는 가급적 잘 돌아가는 상태를 유지합니다.

그런데 새 기능을 붙이고 싶습니다. 그렇다고 안정된 길 위에서 바로 공사를 시작하면 길 전체가 엉망이 될 수 있습니다. 그래서 옆에 임시 작업 도로를 하나 냅니다. 그 도로에서 마음껏 수정하고 실험합니다. 이 임시 작업 도로가 브랜치입니다.

즉, 브랜치는 프로젝트를 하나 더 복사해서 완전히 따로 만드는 것이 아닙니다. 같은 프로젝트 안에서 특정 작업을 위한 별도의 작업 흐름을 만드는 것입니다.

이렇게 이해하면 됩니다.

main은 지금까지의 안정된 본선입니다. 브랜치는 새 기능이나 수정 작업을 시험하는 우회로입니다.

왜 초보자일수록 브랜치를 먼저 배워야 할까

많은 초보자는 브랜치를 "팀 개발할 때 쓰는 고급 기능"으로 생각합니다. 하지만 실제로는 그 반대입니다. 초보자일수록 브랜치가 더 필요합니다.

왜냐하면 초보자는 한 기능을 고치다가 예상보다 훨씬 많은 곳을 건드리기 쉽기 때문입니다. 특히 AI와 함께 작업하면 더 그렇습니다. 버튼 문구만 바꾸고 싶었는데 관련 컴포넌트 구조가 바뀌고, 파일이 나뉘고, 스타일 방식까지 바뀌는 일이 생길 수 있습니다.

이때 main에서 바로 작업하고 있었다면 마음이 급해집니다. 반쯤 바뀐 상태에서 다른 기능 테스트도 어렵고, 지금 멈춰야 할지 계속 가야 할지도 헷갈립니다.

하지만 브랜치에서 작업 중이라면 훨씬 차분해집니다.

"좋아, 이건 실험 브랜치에서 해 보는 중이야." "이상하면 버리면 되고, 괜찮으면 합치면 돼."

이 한 문장이 주는 심리적 안정감이 큽니다. 브랜치는 단순한 기술이 아니라, 안심하고 시도하게 만드는 작업 방식입니다.

main 브랜치는 '항상 비교적 안정적인 상태'로 두자

브랜치를 이해할 때 가장 먼저 잡아야 할 감각은 이것입니다.

main은 가급적 안정 상태로 유지한다.

여기서 안정 상태란 완벽한 상태를 뜻하지는 않습니다. 버그가 하나도 없고 디자인도 완성된 상태여야 한다는 말은 아닙니다. 지금까지 작업한 범위 안에서는 최소한 "돌아간다"라고 말할 수 있는 상태를 뜻합니다.

예를 들어 메인 화면과 게시글 목록까지 만든 단계라면, main에서는 적어도 그 두 기능은 정상적으로 보여야 합니다. 그 위에서 검색 기능을 붙이고 싶다면, 검색은 별도 브랜치에서 시작하는 것입니다.

이 원칙을 지키면 장점이 많습니다.

• 언제든 돌아올 기준점이 생깁니다.

• AI에게 큰 수정을 맡길 때도 덜 불안합니다.

• 문제가 생겼을 때 "안정 버전"과 "실험 버전"을 구분할 수 있습니다.

• 나중에 배포할 때도 기준이 명확해집니다.

초보자에게는 특히 두 번째와 세 번째가 중요합니다. 잘 안 되는 코드를 붙잡고 있는 것보다, 잘 되는 기준점을 따로 지키는 것이 훨씬 강력합니다.

브랜치는 언제 만들면 좋을까

정답은 간단합니다.

기능 하나를 새로 만들거나, 기존 기능을 꽤 많이 손볼 때 만들면 좋습니다.

예를 들어 이런 작업은 브랜치를 따로 만드는 편이 좋습니다.

• 로그인 기능 추가

• 회원가입 페이지 만들기

• 게시글 작성 기능 연결

• 검색 기능 도입

• 모바일 레이아웃 정리

• 공통 컴포넌트 구조 변경

반대로 아주 작은 오타 수정이나 문구 한 줄 변경처럼 영향 범위가 매우 작고 분명한 작업은 상황에 따라 바로 처리할 수도 있습니다. 하지만 초보자라면 처음에는 조금 과하다 싶을 만큼 브랜치를 자주 써 보는 편이 낫습니다. 그러다 보면 "아, 이 정도는 굳이 안 나눠도 되겠구나"라는 감각이 나중에 생깁니다.

처음에는 이렇게 생각하면 됩니다.

조금이라도 불안하면 브랜치를 만든다.

이 기준은 꽤 훌륭합니다.

브랜치 이름은 작업 내용을 바로 알아보게 짓자

브랜치를 만들 때 초보자가 자주 놓치는 것이 이름입니다. 이름을 대충 지으면 나중에 스스로도 헷갈립니다.

예를 들어 test, work, new, fix2 같은 이름은 당장은 편해 보여도 시간이 지나면 의미가 사라집니다. 반면 이름에 작업 목적이 드러나면 훨씬 좋습니다.

예를 들면 이런 식입니다.

• feature/login

• feature/post-create

• feature/search

• fix/mobile-header

• fix/post-edit-error

• refactor/button-component

꼭 이 형식을 외울 필요는 없습니다. 중요한 것은 이 브랜치가 무엇을 하려는 브랜치인지 이름만 보고 알 수 있어야 한다는 점입니다.

이름이 분명하면 GitHub에서 볼 때도 편하고, AI에게 현재 작업 맥락을 설명할 때도 도움이 됩니다.

가장 기본적인 브랜치 작업 흐름

초보자는 복잡한 명령을 많이 알기보다, 흐름 하나를 반복해서 익히는 것이 중요합니다.

보통은 이런 순서로 움직입니다.

먼저 main이 안정 상태인지 확인합니다. 그리고 새 작업을 시작할 브랜치를 만듭니다. 그 브랜치에서 파일을 수정하고, 저장하고, 커밋합니다. 어느 정도 작업이 끝나면 GitHub에 올리고 PR을 만듭니다. 검토와 테스트를 거쳐 괜찮다면 main에 합칩니다.

터미널에서는 보통 이런 식으로 시작합니다.

git checkout main
git pull
git checkout -b feature/login

이 명령은 순서대로 이런 뜻입니다.

먼저 main 브랜치로 이동합니다. 그다음 최신 상태를 가져옵니다. 그리고 feature/login이라는 새 브랜치를 만들고 그 브랜치로 이동합니다.

이제부터는 이 새 브랜치 안에서 작업하면 됩니다. 로그인 기능을 만들다가 코드가 흔들려도, 본선인 main은 아직 안전하게 남아 있습니다.

이 단순한 흐름만 몸에 익혀도 작업 안정성이 확 달라집니다.

PR은 '합쳐도 되는지 검토받는 문'이다

브랜치를 만들었다면 이제 PR을 알아야 합니다. PR은 Pull Request의 줄임말입니다.

처음 이름만 들으면 꽤 헷갈립니다. 그런데 의미는 의외로 쉽습니다.

"내가 브랜치에서 작업한 내용을 main에 합치고 싶은데, 먼저 한번 검토해 주세요."

이 요청이 바로 PR입니다.

즉, PR은 단순히 합치는 버튼이 아닙니다. 합치기 전에 변경 내용을 보여 주고, 확인하고, 이야기하는 공간입니다.

초보자는 종종 이렇게 묻습니다.

"혼자 작업하는데도 PR이 필요한가요?"

대답은 "네, 오히려 더 유용할 수 있습니다"입니다.

혼자 만드는 프로젝트라도 PR을 쓰면 장점이 많습니다. 브랜치에서 바뀐 내용을 한눈에 비교할 수 있고, 내가 무엇을 바꾸려는지 스스로 정리하게 되고, 합치기 전에 마지막으로 테스트하는 습관이 생깁니다.

팀에서는 PR이 다른 사람과의 협업 도구라면, 혼자 작업할 때의 PR은 현재의 나와 미래의 나를 위한 검토 창구입니다.

브랜치와 PR은 어떤 관계일까

둘은 따로가 아니라 한 흐름입니다.

브랜치는 작업하는 공간이고, PR은 그 작업을 본선에 합칠지 검토하는 문입니다.

조금 더 풀어서 말하면 이렇습니다.

브랜치가 없으면 안전하게 실험할 공간이 없습니다. PR이 없으면 그 실험 결과를 정리해서 살펴볼 기회가 사라집니다. 그래서 브랜치와 PR은 함께 쓸 때 가장 강합니다.

작업 흐름으로 보면 이런 식입니다.

브랜치 생성 → 작업 → 커밋 → GitHub에 푸시 → PR 생성 → 검토 → 머지

이 순서를 처음부터 완벽하게 외울 필요는 없습니다. 하지만 큰 흐름은 기억해 두는 것이 좋습니다. 우리는 이제 단순히 파일만 고치는 것이 아니라, 안전하게 수정하고, 확인한 뒤, 본선에 반영하는 방식을 배우고 있기 때문입니다.

머지는 '두 작업 흐름을 하나로 합치는 일'이다

머지라는 말도 자주 나옵니다. 어렵게 들리지만 뜻은 단순합니다.

브랜치에서 작업한 내용을 main에 합치는 것입니다.

예를 들어 feature/search 브랜치에서 검색 기능을 만들었다고 해 보겠습니다. 테스트도 해 봤고, PR에서 바뀐 파일도 확인했습니다. 이제 괜찮다고 판단되면 main에 그 변경을 반영합니다. 이 과정을 머지라고 합니다.

머지는 "브랜치 작업을 공식 반영하는 순간"이라고 생각하면 좋습니다.

여기서 중요한 것은, 브랜치에서 작업했다고 해서 자동으로 main이 바뀌는 것이 아니라는 점입니다. 머지하기 전까지는 본선이 지켜집니다. 그래서 브랜치가 안전한 것입니다.

초보자에게는 이 차이가 아주 중요합니다. 작업 중간 상태와 공식 반영 상태를 구분할 수 있기 때문입니다.

혼자 작업해도 PR을 거치면 좋은 이유

혼자 만들 때는 종종 이런 유혹이 생깁니다.

"어차피 내가 만든 건데 그냥 바로 main에 합치면 되지 않을까?"

물론 급한 작은 작업에서는 그렇게 할 수도 있습니다. 하지만 초보자일수록 PR을 거치는 습관이 도움이 됩니다.

왜냐하면 PR은 단순한 절차가 아니라, 실수를 줄이는 강제 멈춤 버튼 역할을 하기 때문입니다.

브랜치에서 열심히 작업하다 보면 사람은 자기 코드에 익숙해집니다. 그래서 분명히 바뀐 내용을 놓치기도 하고, 테스트를 건너뛰기도 하고, 불필요한 파일이 섞여도 그냥 지나치기 쉽습니다. 그런데 PR을 열면 바뀐 파일과 코드 차이가 비교 화면으로 보입니다. 그 순간 한 걸음 떨어져서 보게 됩니다.

이때 이런 질문을 스스로 던질 수 있습니다.

• 내가 의도한 파일만 바뀌었나?

• 임시 코드나 console 로그가 남아 있지 않나?

• UI만 바꾸려던 작업인데 서버 파일까지 건드려졌나?

• 실제로 실행해 봤나?

• 지금 main에 합쳐도 되는 수준인가?

이 질문을 한 번 거치느냐 아니냐의 차이는 생각보다 큽니다.

GitHub에서 PR을 만드는 흐름

GitHub에서의 흐름도 크게 어렵지 않습니다.

브랜치 작업을 커밋한 뒤 원격 저장소에 올립니다.

git push -u origin feature/login

그러면 GitHub에서 보통 "Compare & pull request" 같은 버튼이 보입니다. 그 버튼을 눌러 PR을 만들 수 있습니다.

PR 화면에서는 보통 제목과 설명을 적습니다. 여기서 너무 길게 쓸 필요는 없습니다. 다만 이 PR이 무엇을 위한 것인지가 드러나면 좋습니다.

예를 들면 이런 식입니다.

제목: 로그인 페이지 UI 및 기본 입력 검증 추가

설명: 로그인 화면을 만들고, 이메일과 비밀번호 입력값 검증을 추가함. 실제 인증 연결은 다음 작업에서 진행 예정.

이렇게 써 두면 나중에 다시 봐도 흐름이 분명합니다. 무엇을 했고, 무엇은 아직 안 했는지도 보입니다.

PR에서 꼭 확인할 것들

PR을 열었다고 끝난 것은 아닙니다. 오히려 중요한 검토는 여기서 시작됩니다.

초보자는 아래 체크만 해도 큰 실수를 많이 줄일 수 있습니다.

• 변경 파일 수가 생각보다 많지 않은지 확인합니다.

• 내가 하려던 작업과 무관한 수정이 끼어 있지 않은지 봅니다.

• 화면에서 직접 눌러 보고, 입력해 보고, 저장해 봅니다.

• 에러가 없는지 터미널과 브라우저 콘솔을 확인합니다.

• 기존 기능이 깨지지 않았는지 최소한 한 번 확인합니다.

여기서 핵심은 완벽함이 아닙니다. 합치기 전에 한 번 더 눈으로 확인하는 습관입니다.

특히 AI가 일부 코드를 작성한 경우에는 꼭 PR 화면을 통해 변경 범위를 보세요. AI는 꽤 그럴듯하게 많은 파일을 만질 수 있기 때문입니다. 내가 요청한 범위를 넘어선 수정이 없는지 꼭 확인해야 합니다.

AI와 함께할수록 브랜치 전략이 더 중요해진다

이 책의 핵심은 AI와 협업해 서비스를 완성하는 것입니다. 그렇다면 브랜치와 PR은 더 중요해집니다.

AI는 작업 속도를 엄청나게 끌어올립니다. 하지만 속도가 빨라질수록 잘못된 변경도 순식간에 퍼질 수 있습니다. 그래서 AI와 함께할 때는 "잘 시키는 법"만큼이나 "안전하게 받는 구조"가 중요합니다.

가장 추천하는 흐름은 이렇습니다.

먼저 main이 안정 상태인지 확인합니다. 그리고 새 브랜치를 만듭니다. 그다음 AI에게 한 번에 하나의 작업만 맡깁니다. 결과를 받은 뒤 직접 실행해 보고, PR에서 바뀐 파일을 확인합니다. 문제가 없으면 머지합니다.

이 방식의 좋은 점은 분명합니다. AI가 잘했을 때는 빠르게 흡수할 수 있고, AI가 너무 많이 바꿨거나 엉뚱하게 바꿨을 때는 브랜치 단위로 멈출 수 있습니다.

즉, 브랜치는 AI를 덜 위험하게 만들어 주는 안전 레일입니다.

초보자가 가장 많이 겪는 실수

브랜치와 PR을 처음 쓰면 자주 나오는 실수가 있습니다.

첫 번째는 모든 작업을 계속 main에서 하는 것입니다.

이렇게 하면 브랜치를 배우는 이유가 거의 사라집니다. 작은 수정도 본선 위에서 바로 진행되므로, 작업 중간 상태가 프로젝트 전체를 흔들 수 있습니다.

두 번째는 브랜치를 만들었지만 너무 오래 끌고 가는 것입니다.

브랜치 하나에서 로그인, 검색, 디자인 수정, 폴더 정리까지 다 해 버리면 결국 또 하나의 거대한 변경 덩어리가 됩니다. 브랜치는 작고 분명한 목적을 가질수록 좋습니다.

세 번째는 PR을 열어 놓고 검토를 안 하는 것입니다.

PR은 단지 통과 의례가 아닙니다. 바뀐 내용을 점검하는 시간입니다. 이 시간을 건너뛰면 PR의 장점이 사라집니다.

네 번째는 합친 뒤 브랜치를 정리하지 않는 것입니다.

작업이 끝난 브랜치를 계속 쌓아 두면 목록이 지저분해지고, 무엇이 살아 있는 브랜치인지 헷갈립니다. 머지가 끝나면 보통 그 브랜치는 정리해도 됩니다.

브랜치는 크게 잡지 말고 작게 여러 번 쓰자

초보자는 종종 브랜치를 아주 거창한 작업에만 써야 한다고 생각합니다. 하지만 실제로는 반대입니다. 브랜치는 작게, 자주 쓰는 것이 좋습니다.

예를 들어 "인증 시스템 전체 만들기"라는 거대한 브랜치 하나를 만드는 것보다, 아래처럼 나누는 편이 훨씬 좋습니다.

• 로그인 페이지 UI 만들기

• 회원가입 폼 만들기

• 인증 연동 붙이기

• 로그아웃 버튼 연결하기

이렇게 나누면 장점이 많습니다. 한 번에 검토할 양이 줄고, 문제가 생겨도 범위가 작고, 머지 이후의 상태도 더 자주 안정화됩니다.

이 감각은 커밋을 나누는 감각과 비슷합니다. 좋은 브랜치도 결국 설명 가능한 한 덩어리 작업이어야 합니다.

충돌은 무서운 벌칙이 아니라, 같은 부분을 함께 고쳤다는 신호다

브랜치와 머지를 배우다 보면 언젠가 충돌이라는 말을 만나게 됩니다. 영어로는 conflict라고 부릅니다.

이 단어 때문에 초보자는 겁부터 먹습니다. 뭔가 큰일 난 것처럼 느껴지기 때문입니다. 하지만 충돌은 대부분 "같은 부분을 서로 다르게 고쳤으니 어느 쪽을 반영할지 정해 달라"는 신호에 가깝습니다.

예를 들어 main에서도 헤더 문구가 바뀌었고, 내가 작업 중인 브랜치에서도 같은 헤더 부분을 수정했다면 Git은 둘을 자동으로 합치기 어려워할 수 있습니다. 이때 충돌이 납니다.

중요한 것은, 충돌이 났다고 해서 프로젝트가 망한 것은 아니라는 점입니다. 다만 자동으로 결정하지 못하니 사람이 판단해 달라는 상태일 뿐입니다.

처음에는 충돌을 피하는 것이 더 중요합니다. 이를 위해서는 다음 습관이 좋습니다.

• 브랜치를 너무 오래 끌지 않습니다.

• 작업을 자주 머지합니다.

• main의 최신 상태를 너무 오래 무시하지 않습니다.

• 같은 파일을 동시에 크게 바꾸는 일을 줄입니다.

충돌을 완전히 피할 수는 없지만, 작은 브랜치와 짧은 작업 주기를 유지하면 훨씬 덜 아프게 지나갑니다.

초보자를 위한 가장 안전한 협업 루틴

이 장의 핵심은 결국 하나입니다. 실수해도 본 작업을 지키는 구조를 만드는 것입니다.

초보자에게는 아래 루틴을 추천합니다.

작업을 시작하기 전에 먼저 main이 안정 상태인지 확인합니다. 그리고 오늘 할 일 하나만 정합니다. 예를 들어 "게시글 검색 UI 만들기"처럼요. 그다음 그 작업용 브랜치를 만듭니다.

브랜치 안에서만 수정합니다. 작업이 어느 정도 끝나면 실행해서 직접 확인합니다. 그다음 커밋합니다. 필요하면 여러 커밋으로 나눌 수 있습니다. 그리고 GitHub에 푸시해서 PR을 만듭니다.

PR에서 변경 파일과 차이를 확인합니다. 화면도 다시 한 번 테스트합니다. 괜찮다면 머지합니다. 머지 후에는 main으로 돌아와 최신 상태를 받고, 끝난 브랜치는 정리합니다.

이 루틴은 처음에는 조금 번거롭게 느껴질 수 있습니다. 하지만 몇 번만 해 보면 알게 됩니다. 이것이 결국 가장 덜 불안하고, 가장 덜 망가지는 방식이라는 것을요.

기억해 두면 좋은 최소 명령어

명령어를 많이 외울 필요는 없습니다. 지금 단계에서는 몇 가지만 익혀도 충분합니다.

git checkout main
git pull
git checkout -b feature/search
git status
git add .
git commit -m "검색 UI 추가"
git push -u origin feature/search

이 흐름은 이런 뜻입니다. 안정된 main으로 가서 최신 상태를 가져온 뒤, 새 브랜치를 만들고, 작업하고, 상태를 확인하고, 커밋하고, 원격 저장소에 올리는 것입니다.

여기에 GitHub에서 PR을 만들고 머지하는 흐름까지 연결되면, 초보자도 꽤 안전한 개발 루틴을 갖추게 됩니다.

명령어 하나하나를 완벽히 외우는 것보다 더 중요한 것은 왜 이 순서로 하는지를 이해하는 것입니다. 우리는 멋져 보이려고 이 절차를 배우는 것이 아닙니다. 실수해도 괜찮은 구조를 만들기 위해 배우는 것입니다.

브랜치와 PR은 실수를 줄이는 기술이 아니라, 실수를 작게 만드는 기술이다

이 문장은 꼭 기억할 가치가 있습니다.

브랜치와 PR을 쓴다고 해서 실수가 사라지지는 않습니다. 여전히 잘못 고칠 수 있고, 엉뚱한 파일을 건드릴 수도 있고, AI가 이상한 결과를 줄 수도 있습니다.

하지만 차이가 있습니다. 실수가 프로젝트 전체를 무너뜨리는 대신, 브랜치 안의 작은 범위로 갇히게 됩니다. 그리고 PR이라는 검토 단계 덕분에 합치기 전에 한 번 더 걸러 볼 수 있습니다.

즉, 브랜치와 PR의 진짜 힘은 완벽함이 아니라 피해 범위 축소에 있습니다.

초보자에게는 이것이 엄청난 장점입니다. 실패가 작아지면 시도를 더 많이 할 수 있고, 시도가 많아지면 실력도 빨리 늡니다.

이제부터는 '고치는 사람'이 아니라 '안전하게 고치는 사람'이 된다

개발을 오래 하려면 단지 기능을 붙이는 법만 알아서는 부족합니다. 고치고, 비교하고, 확인하고, 합치는 흐름을 알아야 합니다. 그래야 서비스가 커져도 버틸 수 있습니다.

브랜치와 PR은 바로 그 흐름의 시작입니다. 이 감각이 생기면 앞으로 로그인 기능을 붙일 때도, CRUD를 만들 때도, 디자인을 다듬을 때도 훨씬 덜 불안해집니다. 심지어 AI에게 작업을 맡길 때도 "일단 브랜치에서 해 보자"라는 든든한 선택지가 생깁니다.

결국 개발은 정답을 한 번에 맞히는 일이 아니라, 안전한 구조 안에서 계속 수정해 가는 일입니다.

다음 장으로 가기 전에

이번 장에서는 브랜치, 머지, PR이 무엇인지, 그리고 왜 초보자에게 특히 중요한지 배웠습니다. 핵심은 간단합니다.

커밋은 체크포인트를 남기는 일이고, 브랜치는 본선을 지키며 다른 길에서 작업하는 일이며, PR은 그 작업을 합치기 전에 한 번 더 검토하는 문입니다.

이제 우리는 단순히 저장하고 커밋하는 단계에서 한 걸음 더 나아갔습니다. 망치지 않고 고치는 구조를 배우기 시작한 것입니다.

다음 장에서는 이 흐름을 바탕으로, AI와 함께 작업할 때 꼭 지켜야 하는 습관을 살펴보겠습니다. AI는 빠른 조수이지만, 안전한 작업 습관이 있을 때 비로소 믿을 만한 동료가 됩니다.