URL: https://youtu.be/7ZWX02hwnug 날짜: 2026-07-19 채널: 제미니의 개발실무
📌 핵심 질문 / 이 영상이 다루는 핵심 논점
AI가 코드를 순식간에 대량으로 찍어내는 시대일수록, ==PR(Pull Request)을 커밋·브랜치 단위로 잘게 쪼개 동료가 맥락을 이해할 수 있게 만드는 것이 오히려 더 중요해진다==는 것이 이 영상의 핵심 주장이다.
- AI 시대 이전에도 저자(재민)는 로컬에서 단위별로 커밋하고, 작업이 끝나면 소프트 리셋으로 다시 의미 단위로 커밋을 재구성해 PR을 올리는 방식을 써왔다
- AI 시대에 접어들며 한 커밋에 파일 수백 개가 수정되는 PR이 흔해졌는데, 이는 협업하는 동료에게 "똥을 던지는 것"과 같다
- 코드가 회사의 자산인 이상, AI가 빠르게 짜줬다고 해서 맥락 없이 대충 올리는 것은 무책임한 태도이며, 여전히 일을 잘게 쪼개고 명확하게 구성하는 능력이 중요하다
개발자 유튜버 재민(채널 '제미니의 개발실무')은 실무 지인들과의 대화에서 자주 나온 "PR 올리기 힘들다"는 고민을 계기로, AI 시대 이전부터 써온 커밋 관리 전략과 AI 시대에 이를 어떻게 응용해야 하는지를 설명한다.
1. AI 이전 시대의 PR 작성 전략
1.1. 로컬 커밋과 소프트 리셋을 통한 재구성
- 단위별 로컬 커밋
- 작업 중 수시 커밋: 작업을 진행하면서 중간중간 단위별로 로컬 커밋을 해두어, 문제가 생겼을 때 되돌아갈 수 있는 지점을 만든다
- 전제 조건: 이 방식은 하나의 브랜치에서 처리할 기능(예: ABC 작업)이 너무 크지 않다는 것을 전제로 한다
- 소프트 리셋 후 커밋 재구성
- 작업 완료 후 재구성: 작업이 끝나면 그동안의 커밋들을 그대로 PR로 올리지 않고, 소프트 리셋으로 스테이지에 모두 모은 뒤 의미 단위로 커밋을 다시 나눈다
- 동료가 읽는 기록이라는 관점: PR은 동료가 함께 봐야 하는 것이고, 머지되면 기록으로 남기 때문에 "어떻게 작업했는지, 어떤 생각과 관점이었는지"를 잘 전달하는 커밋 구성이 중요하다
1.2. 파일 단위 추적 가능성과 선행 작업 분리
- 한 파일은 한 커밋에
- 추적 용이성: 예를 들어 파일 A의 수정 내용이 커밋 20개 중 5개에 흩어져 있으면 추적하기 매우 어려우므로, 하나의 PR 안에서는 일반적으로 파일 A의 수정이 한 커밋에만 담기도록 구성한다
- 선행 리팩토링·패키지 변경의 분리
- 별도 브랜치로 먼저 머지: 리팩토링이나 패키지 교체처럼 본작업 전에 필요한 선행 작업은 별도 브랜치로 빼서 먼저 빠르게 머지하거나, PR 자체를 분리한다
- 협업 우선의 철학: 이런 전략을 써온 이유는 협업이 더 중요하고, 팀 전체가 작업 맥락을 이해하는 방식으로 일하는 것이 중요하다고 여겼기 때문이며, 실제로 동료들에게서 좋은 반응과 깨달음이 있었다는 피드백을 받았다
2. AI 시대의 PR 문제와 대응 전략
2.1. AI가 만드는 거대 커밋 문제
- 한 커밋에 파일 수백 개가 몰리는 현상
- AI의 생산성 부작용: AI로 코드를 빠르고 많이 찍어내다 보니, 한 커밋에 파일 500개가 수정되는 등 리뷰어가 감당하기 힘든 PR이 늘고 있다
- 비즈니스 임팩트가 큰 서비스일수록 위험: 금융권이나 대규모 트래픽 서비스처럼 장애 발생 시 시간당·분당 손해가 발생하는 구조에서는 이런 거대 PR의 위험이 훨씬 크다
- 테스트 코드만으로는 부족하다
- AI 테스트 코드의 한계: "AI한테 테스트도 다 맡겼다"고 해도 그것으로 장애가 예방되는 것은 아니다
- 작업자 본인도 맥락을 모르는 위험: 500개 파일짜리 커밋 하나짜리 PR을 올린 본인조차 그 작업의 맥락이나 방향성을 완전히 이해하지 못하고 있을 수 있다는 점이 핵심 문제다
2.2. AI 시대에도 유효한 원칙 — 일을 잘게 쪼개라
- AI에게 커밋·브랜치 분리를 직접 요청하기
- AI한테 시켜서 쪼개기: 작은 요청을 했는데 결과적으로 파일 200개가 수정됐다면, 그 결과물을 그대로 올리지 말고 AI에게 커밋을 나눠 달라고, 필요하면 브랜치도 나눠 달라고 요청해야 한다
- 세션 맥락 활용: 같은 AI 세션이 작업 맥락을 유지하고 있다면, 그 맥락을 활용해 커밋·브랜치 재구성을 맡기는 것이 효율적이다
- 일 쪼개기는 AI 이전에도 핵심 역량이었다
- 스코프 설정의 문제: 200개 파일이 수정될 정도의 작업 요청은 애초에 스코프를 너무 크게 잡았을 가능성이 높으며, 이는 AI 도구 편의성 때문에 "나도 모르게 여러 일을 한 번에 시킨" 결과다
- 불변하는 기본기: 일을 잘게 쪼개고 명확하게 작업 단위를 구성하는 능력은 AI 시대 이전부터 무조건 중요했던 기본기이며, 지금 겪는 어려움은 이 기본기가 부족했던 결과일 수 있다
2.3. 코드는 여전히 회사의 자산이라는 책임감
- 무책임한 PR 업로드에 대한 경계
- 자산으로서의 코드: 코드가 AI가 짰든 사람이 짰든 회사의 지적 자산이자 월급을 벌어오는 서비스·솔루션의 일부이므로, 맥락 없이 대충 올리는 것은 무책임한 태도다
- 1인 개발이 아니라면: 팀원과 함께 운영하는 상황에서 동료가 내 작업의 맥락을 이해해야 하는데, 이를 무시하고 "나는 이렇게 했다"는 식으로 던지듯 올리는 것은 지양해야 한다
- 커밋 메시지와 PR 설명도 AI로 보완 가능
- AI로 쉽게 개선 가능한 영역: 예전에는 커밋 메시지 하나도 고민해서 썼는데, 지금은 GitHub CLI(gh) 플러그인 등을 활용해 AI에게 맡기면 작업 과정까지 잘 정리해준다
- 책임 소재는 여전히 작업자에게: 장애나 문제가 발생했을 때 회사가 개인에게 손해를 직접 지우진 않더라도, 동료와 회사는 작업자의 책임감 있는 태도를 판단하는 근거로 커밋·PR의 품질을 본다
3. 예외와 판단 기준
3.1. 프로젝트 규모와 중요도에 따른 차등 적용
- 토이 프로젝트·개인 프로젝트는 예외
- 적용 제외 대상: 사용자가 거의 없는 토이 프로젝트나 개인 프로젝트에서는 이런 세밀한 커밋 관리 원칙이 크게 중요하지 않다
- 중요 서비스일수록 신중해야 한다
- 고위험 영역의 예시: 금융 관련 서비스, 메인 트래픽을 지탱하는 서비스, 정산 시스템처럼 금전적으로 예민한 부분은 특히 신경 써서 커밋·PR 구조를 설계해야 한다
- 팀 차원의 논의 권장: 동료들과 이런 문제로 고민이 있다면 팀 차원에서 한번 토론해보는 것도 좋은 접근이라고 조언한다
주요 발언 모음
"PR은 내 동료도 같이 봐야 되는 거거든요. 내가 어떻게 작업했는지 내가 어떤 생각을 했는지 어떤 관점을 또... 그게 머지가 됐을 때는 기록으로 남거든요." "커밋 하나에 파일 막 500개 수정돼 있고 막 이러면 정말 이 사람이 미치거든요." "여러분들이 커밋 하나로 뭉쳐 가지고 응 나 했어요. 이렇게 하면은 동료들한테 사실 그건 똥을 던지는 거랑 똑같거든요." "코드는 어쨌든 회사의 자산이잖아요. ... 그걸 약간 무책임하게 올리는 거는 좀 좋지 않은 모습이라고 생각을 하긴 합니다." "그런 이런 PR 내용도 못 맞추겠다면 로컬에 그냥 깃허브 플러그인 깔고 그 AI한테 던지세요. ... 그러면 알아서 잘 써 줍니다."
핵심 데이터 & 수치
- 영상 길이: 약 12분(726초)
- 문제 사례: 커밋 하나에 파일 500개가 수정되는 PR, AI에게 작은 요청을 했음에도 파일 200개가 수정되는 경우
결론 및 시사점
- AI 시대 이전부터 써온 "로컬 단위별 커밋 → 소프트 리셋 → 의미 단위 재구성" 전략은 AI 시대에도 여전히 유효한 PR 관리 원칙이다.
- AI가 코드를 빠르게 대량 생산하는 지금, 한 커밋에 파일 수백 개가 몰리는 PR은 동료에게 리뷰 부담을 전가하는 무책임한 행위다.
- 금융권이나 대규모 트래픽 서비스처럼 장애 영향이 큰 프로젝트일수록 거대 PR의 위험이 크며, 테스트 코드가 있다고 장애가 예방되는 것은 아니다.
- AI가 작업 결과물을 크게 만들었다면, 그대로 올리지 말고 AI에게 커밋·브랜치를 나눠 달라고 다시 요청하는 것이 실질적 해법이다.
- 애초에 요청 스코프를 잘게 쪼개고 명확하게 구성하는 능력은 AI 이전부터 중요했던 기본기이며, 지금의 어려움은 그 기본기 부족의 결과일 수 있다.
- 코드는 AI가 짰든 사람이 짰든 회사의 자산이므로, 커밋 메시지와 PR 설명은 AI 도구(GitHub CLI 플러그인 등)를 적극 활용해서라도 맥락을 명확히 전달해야 한다.
- 토이·개인 프로젝트에는 이런 원칙이 크게 중요하지 않지만, 금융·정산 등 예민한 서비스에는 팀 차원의 논의를 거쳐 신중하게 적용해야 한다.