Claude Code로 코드를 고치고 GitHub PR까지 보내려면, 핵심은 에이전트에게 바로 main에 반영시키지 않는 것입니다. 제가 가장 안정적으로 쓰는 흐름은 새 브랜치 생성 → Claude Code 작업 → git diff 검토 → 작은 단위 커밋 → GitHub CLI로 PR 생성입니다.
즉, Claude Code는 구현과 수정의 속도를 높이고, Git은 변경 이력과 리뷰 안전장치로 둡니다. 이 둘을 섞을 때는 자동화보다 검토 지점을 먼저 설계해야 사고가 적습니다.
오늘은 main 보호, 작업 브랜치, git diff 확인, gh pr create까지만 연결해보세요.
체크리스트를 열어두고 한 기능 단위로 테스트하면 충분합니다.
제가 쓰는 기본 셋업: Claude Code는 작업자, Git은 안전벨트
준비물은 단순합니다. 로컬 프로젝트, Git, Claude Code, GitHub CLI입니다. GitHub Desktop을 써도 되지만, Claude Code와 터미널 흐름을 맞추려면 gh CLI가 훨씬 깔끔합니다.
저는 저장소 루트에 CLAUDE.md를 두고 프로젝트 규칙을 적습니다. 예를 들면 “패키지 매니저는 pnpm”, “테스트는 npm run test”, “API 변경 시 문서도 수정” 같은 내용입니다. 이 파일이 있으면 Claude Code가 매번 같은 설명을 듣지 않아도 됩니다.
1) 브랜치부터 자르고 시작하기
가장 먼저 할 일은 main에서 바로 작업하지 않는 것입니다. 작은 기능이라도 아래처럼 브랜치를 나눕니다.
git checkout main
git pull
git checkout -b feat/admin-user-filter그다음 Claude Code에 요청합니다. 요청은 “관리자 사용자 목록에 검색 필터 추가해줘”보다 “Next.js app/admin/users 페이지에서 name, email 기준 검색 필터를 추가하고 기존 테이블 컴포넌트 구조는 유지해줘. 테스트 명령은 pnpm test야”처럼 구체적으로 쓰는 편이 좋습니다.
2) 작업 후 바로 커밋하지 말고 diff를 먼저 본다
Claude Code가 여러 파일을 고친 뒤에는 곧장 커밋하지 않습니다. 저는 항상 아래 순서로 확인합니다.
git status
git diff --stat
git diff여기서 의도하지 않은 포맷 변경, lock 파일 변경, 설정 파일 수정이 보이면 Claude Code에 다시 말합니다. “package-lock.json 변경은 되돌리고, users 페이지와 관련 컴포넌트만 남겨줘”처럼 좁혀서 지시하면 정리가 빠릅니다.
커밋·PR까지 이어지는 실제 명령 흐름
변경 내용을 확인했다면 커밋 메시지도 Claude Code에 맡길 수 있습니다. 다만 최종 문구는 사람이 고르는 편이 좋습니다.
git add -p
git commit -m 'feat: add user search filter to admin page'
git push -u origin feat/admin-user-filter
gh pr create --fillgit add -p를 쓰면 파일 전체가 아니라 변경 덩어리별로 스테이징할 수 있습니다. Claude Code가 한 번에 리팩터링과 기능 추가를 섞어버렸을 때 특히 유용합니다.
가상의 예: SaaS 관리자 페이지 필터 추가
예를 들어 Next.js와 Supabase로 만든 작은 SaaS 관리자 화면에서 “유저 이메일 검색”을 붙인다고 해보겠습니다. Claude Code에 구현을 맡기면 UI 컴포넌트, 쿼리 파라미터 처리, 서버 액션까지 한 번에 손댈 수 있습니다.
이때 좋은 흐름은 기능 추가 커밋과 리팩터링 커밋을 분리하는 것입니다. 검색 기능은 feat로, 테이블 컴포넌트 정리는 refactor로 나누면 PR 리뷰가 쉬워집니다. 실제 결과는 프로젝트 구조와 테스트 환경에 따라 달라집니다.
Claude Code, Cursor, GitHub Copilot을 Git 작업 기준으로 비교
코딩 에이전트는 모두 비슷해 보이지만 Git과 붙여 쓰는 방식은 꽤 다릅니다. 아래 기준으로 고르면 시행착오가 줄어듭니다.
| 도구 | 잘 맞는 작업 | Git 흐름에서 장점 | 주의할 점 |
|---|---|---|---|
| Claude Code | 터미널 기반 다중 파일 수정, 리팩터링, 테스트 반복 | 로컬 명령과 파일 맥락을 이어가며 작업하기 좋음 | 변경 범위가 커질 수 있어 diff 검토가 필수 |
| Cursor | IDE 안에서 부분 수정, 코드 읽기, 빠른 패치 | 변경 파일을 눈으로 보며 수락하기 쉬움 | 터미널 자동화까지는 별도 습관이 필요 |
| GitHub Copilot | 함수 단위 작성, 자동완성, 간단한 설명 | 기존 VS Code/GitHub 흐름에 자연스럽게 붙음 | PR 생성 자동화보다는 보조 역할에 가까움 |
| Codex CLI | 명령형 작업, 코드 생성 실험, 스크립트 작성 | CLI 중심 워크플로와 잘 맞음 | 팀 표준에 맞춘 검토 규칙을 따로 둬야 함 |
누구에게 이 방식이 맞나
혼자 만드는 빌더라면
혼자 개발하는 SaaS나 사이드 프로젝트라면 이 워크플로가 가장 효율적입니다. Claude Code가 빠르게 구현하고, GitHub PR을 자기 리뷰용 기록으로 남기면 나중에 장애 원인을 찾기 쉽습니다.
팀 프로젝트라면
팀에서는 더 엄격하게 가야 합니다. main 브랜치 보호, 필수 리뷰어, GitHub Actions 테스트 통과 조건을 걸어두세요. 에이전트가 코드를 잘 만들어도 팀 컨벤션과 보안 규칙은 자동으로 보장되지 않습니다.
자주 막히는 지점
Q. Claude Code가 너무 많은 파일을 고치면 어떻게 하나요?
처음 요청을 작게 나누는 것이 제일 좋습니다. 이미 커졌다면 git diff --name-only로 파일 목록을 보고, 관련 없는 파일은 git restore 파일명으로 되돌리세요.
Q. 커밋 메시지도 자동으로 맡겨도 되나요?
초안은 맡겨도 됩니다. 다만 실제 커밋 전에는 변경 목적이 드러나는지 확인하세요. “update code”보다 “fix: handle empty user search query”처럼 원인이 보이는 메시지가 낫습니다.
Q. PR 본문은 어떻게 쓰면 좋나요?
gh pr create --fill로 기본 본문을 만들고, Claude Code에 “변경 요약, 테스트 방법, 리뷰 포인트 3개로 정리해줘”라고 요청하면 빠릅니다. 단, 테스트를 실제로 돌리지 않았다면 돌렸다고 쓰면 안 됩니다.
마지막으로 꼭 피해야 할 실수
가장 흔한 실수는 Claude Code에게 “다 고쳐서 커밋하고 푸시해”라고 한 번에 맡기는 것입니다. 속도는 빨라 보이지만, 변경 이유를 놓치면 PR 리뷰가 어려워집니다.
오늘 적용할 액션은 하나면 충분합니다. 다음 작업부터는 새 브랜치를 만들고, Claude Code 작업 후 git diff를 확인한 뒤, gh pr create로 PR을 남겨보세요. 이 정도만 해도 AI 코딩 작업의 재현성과 안전성이 크게 좋아집니다.
관련 링크
- ai 코딩 구독 요금 비교: Claude Code·Cursor·Copilot, 빌드용으로 돈값 하는 조합
- claude code artifacts, 웹 미리보기 대신 파일로 남기는 실전 작업법
- claude code 모델 추천: 실제 빌드 작업에서 Sonnet과 Opus를 나눠 쓰는 기준
- 관련 태그 더 보기
- 카테고리 더 보기
- 검색 결과 더 보기
- 참고 링크
