[비개발] 동시 작업 시 메인 반영 꼬임 해결 (Git이 갑자기 복잡해졌다)

 

AI 개발 협업 기록

“혼자 개발할 때는 쉬웠는데, AI 여러 세션으로 개발하니 Git이 갑자기 어려워졌어”

main, branch, worktree, PR, merge가 왜 필요한지 비개발자 관점에서 정리해봤어. 나처럼 AI 코딩 도구로 사이드 프로젝트를 운영하는 사람이라면 한 번쯤 겪게 되는 문제 같아.

예전에는 수정 → 로컬 테스트 → 커밋 → 푸시만 알면 됐어. 그런데 여러 AI 세션이 동시에 작업하기 시작하니, 단순한 방식으로는 변경사항이 서로 섞이더라. 그래서 이번에 Git 작업 흐름을 다시 정리해봤어.

1. 왜 갑자기 복잡해졌을까?

단건으로 개발할 때는 보통 이렇게 진행했어.

단건 작업 흐름

main에서 바로 수정
→ 로컬 테스트
→ commit
→ push
→ 배포

이 방식은 작업이 하나뿐일 때는 아주 편해. 바꾼 파일도 명확하고, 문제가 생겨도 어디서 생겼는지 찾기 쉬워.

그런데 AI 코딩 도구를 여러 개 켜고 동시에 작업하기 시작하면 상황이 달라져. 예를 들면 이런 식이야.

여러 세션이 동시에 작업하는 상황

세션 A: 홈 화면 입력 영역 수정
세션 B: 아이콘 로딩 최적화
세션 C: 문서 가이드라인 수정
세션 D: 모바일 UI 수정

사람 입장에서는 작업이 나뉘어 보이지만, Git 입장에서는 그냥 같은 프로젝트 안에서 여러 파일이 바뀐 것뿐이야.

Git이 보는 상태

M app.html
M css/style.css
M js/app.js
M docs/workflow.md

문제는 여기서 시작됐어.
이 파일이 어느 세션의 작업인지, 지금 커밋해도 되는 파일인지, 다른 작업이 섞인 건 아닌지 계속 헷갈리게 돼.

2. 먼저 Git의 4개 공간을 구분해야 해

Git을 처음 보면 용어가 어렵지만, 나는 이렇게 4개 공간으로 나눠서 보니까 이해가 쉬웠어.

구분	쉽게 말하면	예시
작업 폴더	실제로 파일을 수정하는 내 PC 폴더	my-project/
로컬 Git	내 PC에 저장되는 변경 이력	commit
원격 저장소	GitHub 같은 온라인 저장소	origin/main
배포 환경	실제 사용자가 보는 서비스	운영 웹사이트

여기서 중요한 건 커밋, 푸시, 머지, 배포가 모두 같은 말이 아니라는 점이야.

전체 흐름

파일 수정
→ commit: 내 PC Git에 저장
→ push: GitHub에 올림
→ PR / merge: main에 합침
→ deploy: 실제 서비스에 반영

3. 꼭 알아야 할 용어 정리

Working tree, 워킹트리

워킹트리는 실제로 파일을 수정하는 작업 폴더야. 예전에는 프로젝트 폴더 하나만 열고 모든 작업을 했어.

기본 워킹트리 예시

my-project/

그런데 여러 AI 세션이 같은 워킹트리를 동시에 쓰면 변경사항이 섞이기 쉬워.

Branch, 브랜치

브랜치는 쉽게 말하면 작업용 평행 세계야. 실제 운영 기준이 되는 main을 바로 건드리지 않고, 별도 작업 줄기를 만들어서 수정하는 방식이야.

브랜치 예시

main
feature/input-ui
fix/icon-loading
docs/workflow-guide

비유하면 main은 원본 문서이고, 브랜치는 원본을 복사해서 만든 수정안이야.

Commit, 커밋

커밋은 변경사항을 저장한 스냅샷이야. “이 시점의 변경사항을 하나의 단위로 저장한다”라고 보면 돼.

커밋 메시지 예시

fix: adjust input padding
fix: lazy-load icons
docs: add workflow guide

Push, 푸시

푸시는 내 PC에 있는 커밋을 GitHub 같은 원격 저장소에 올리는 거야. 그런데 여기서 헷갈리기 쉬운 점이 있어.

push 완료 = main 반영 완료가 아닐 수 있어.

작업 브랜치에 push한 상태라면, GitHub에는 올라갔지만 아직 main에는 안 들어간 상태야.

Pull Request, PR

PR은 Pull Request의 줄임말이야. 쉽게 말하면 “이 브랜치 작업을 main에 합쳐도 될까요?”라고 요청하는 절차야.

PR의 의미

feature/input-ui → main
이 작업을 main에 합쳐도 되는지 확인해 주세요.

PR에서는 변경 파일 목록, 실제 변경 내용, 충돌 여부, 리뷰 결과 등을 확인할 수 있어.

Merge, 머지

머지는 브랜치 작업을 main에 실제로 합치는 거야. PR이 “합쳐도 될까요?”라면, merge는 “합쳤습니다”에 가까워.

origin/main

origin은 GitHub에 있는 원격 저장소를 가리키는 이름이고, origin/main은 GitHub에 있는 main 브랜치 상태를 뜻해.

내 PC의 main과 GitHub의 origin/main은 다를 수 있어. 그래서 작업 전에는 원격 main이 최신인지 확인하는 습관이 중요해.

4. worktree는 왜 쓰는 걸까?

이번에 가장 헷갈렸던 개념이 worktree였어. 그런데 비유하자면 꽤 단순해.

worktree는 같은 프로젝트를 작업별로 다른 책상에 펼쳐놓는 방식이야.

예를 들어 하나의 프로젝트를 이렇게 나눠서 작업할 수 있어.

worktree 예시

my-project/
my-project-input-ui/
my-project-icon-loading/
my-project-docs-guide/

각각은 같은 프로젝트를 기반으로 하지만, 서로 다른 폴더에서 서로 다른 브랜치를 작업할 수 있어.

기본 폴더

기존 작업이나 확인용으로 유지

UI 작업 폴더

입력 영역, CSS 등 특정 작업 전용

최적화 작업 폴더

아이콘 로딩, JS 수정 등 별도 작업 전용

이렇게 나누면 한 세션이 다른 세션의 파일을 실수로 건드릴 가능성이 줄어들어.

worktree를 쓰는 이유
여러 AI 세션이 동시에 작업할 때, 작업 파일이 서로 섞이지 않게 분리하기 위해서야.

5. 예전 방식과 병렬 작업 방식 비교

구분	단건 작업 방식	병렬 작업 방식
작업 위치	main 워킹트리	작업별 worktree
브랜치	main에서 바로 작업 가능	작업별 브랜치 생성
검토	로컬 diff 중심	PR diff로 확인
장점	빠르고 단순함	변경사항이 섞일 위험이 낮음
단점	병렬 작업에 취약함	용어와 절차가 조금 복잡함

정리하면, 작업이 하나뿐이면 단순 방식이 빠르고 좋아. 하지만 동시에 여러 작업을 진행한다면 worktree, branch, PR을 쓰는 게 훨씬 안전해.

6. 실제 병렬 작업 흐름은 이렇게 보면 돼

병렬 작업은 대략 이런 순서로 진행하면 돼.

1. origin/main 기준을 최신화한다.
   가장 최신 main을 기준으로 작업을 시작해야 나중에 충돌이 줄어든다.
2. 작업 전용 worktree를 만든다.
   기존 작업 폴더에 남아 있는 다른 변경사항과 분리하기 위해서다.
3. 작업 전용 branch를 만든다.
   예: fix/input-padding, feature/home-search
4. 작업 대상 파일만 수정한다.
   unrelated 변경이 섞이지 않게 파일 범위를 계속 확인한다.
5. 로컬 테스트와 diff 확인을 한다.
   문법 검사, 화면 검증, 변경 파일 목록 확인을 진행한다.
6. 커밋하고 작업 브랜치에 push한다.
   이 단계에서는 GitHub에 올라가지만 main 반영은 아직 아니다.
7. PR을 만든다.
   main에 합치기 전에 변경 파일, 충돌 여부, 리뷰 결과를 확인한다.
8. 조건이 맞으면 merge한다.
   이때 비로소 main에 반영된다.
9. 작업이 끝난 worktree와 branch를 정리한다.
   남겨두면 나중에 헷갈리기 쉽다.

7. push와 merge를 헷갈리면 안 돼

내가 가장 헷갈렸던 부분은 이거였어.

“이미 push 됐는데 왜 또 PR이 필요하지?”

답은 간단해.

상태	의미	main 반영 여부
작업 브랜치에 push	GitHub에 수정안이 올라간 상태	아직 아님
PR 생성	main에 합치기 전 검토 요청	아직 아님
PR merge	작업 브랜치를 main에 합침	반영됨
배포 완료	운영 환경에 적용됨	사용자에게 보임

그래서 작업 브랜치에 push만 된 상태는 “백업과 공유는 됐지만, main에는 아직 안 들어간 상태”라고 보면 돼.

8. 언제 단순 방식으로 해도 될까?

모든 작업을 복잡하게 할 필요는 없어. 나는 앞으로 이렇게 구분하려고 해.

상황	추천 방식	이유
작업 1개만 진행	main 직접 작업 가능	변경사항이 섞일 가능성이 낮음
문구, 오타, 작은 CSS 수정	main 직접 또는 단순 브랜치	영향 범위가 작음
여러 AI 세션 동시 작업	worktree + branch + PR	변경 파일 섞임 방지
공통 CSS, 핵심 JS, HTML 수정	브랜치 + PR 권장	영향 범위가 넓음
인증, DB, 배포 설정 수정	별도 worktree + PR 필수에 가깝게	장애 리스크가 큼
기존 워킹트리에 unrelated 변경이 있음	clean worktree 권장	커밋 오염 방지

내 기준 결론
작업 하나만 있고 git status가 깨끗하면 단순 방식도 괜찮다. 하지만 동시 작업이 있거나 이미 수정 파일이 섞여 있으면 worktree와 PR을 쓰는 게 안전하다.

9. 실수하기 쉬운 명령

병렬 작업 중에는 특히 이 명령을 조심해야 해.

위험한 방식

git add .
git add -A

이 명령은 현재 폴더의 모든 변경사항을 stage할 수 있어. 다른 세션의 변경이 섞여 있는 상태에서는 매우 위험해.

대신 작업 대상 파일만 정확히 지정하는 게 좋아.

안전한 방식

git add app.html js/app.js
git add css/style.css
git add docs/workflow.md

그리고 커밋 전에는 stage된 파일을 꼭 확인해야 해.

커밋 전 확인

git diff --cached --name-only

이 결과가 내가 의도한 파일만 보여야 커밋해도 돼.

10. AI에게 줄 때 좋은 작업 지시문

AI 코딩 도구에게는 “잘 해줘”보다 작업 경계와 금지사항을 분명히 주는 게 좋더라.

병렬 작업 시작 지시문

AI 작업 지시문 예시

이 작업은 다른 세션과 병렬로 진행 중이므로 main 직접 수정 금지.

origin/main 기준 clean worktree를 만들고 새 브랜치에서 진행해줘.
작업 대상 파일만 수정하고, unrelated 변경은 건드리지 마.
git add . / git add -A 금지.
커밋 전 git diff --name-only와 git diff --cached --name-only로 범위를 보고해줘.

PR 조건부 merge 지시문

PR merge 지시문 예시

PR 생성해줘.

아래 조건이 모두 충족되면 main에 merge까지 진행해줘.
- PR diff가 지정 파일만 포함
- 충돌 없음
- 추가 수정 없음
- unrelated 변경 없음
- 리뷰 결과 No findings

조건이 하나라도 깨지면 merge하지 말고 중단 보고해줘.

작업 정리 지시문

정리 지시문 예시

PR merge가 완료됐으니 작업 worktree와 브랜치만 정리해줘.

기존 작업 폴더는 건드리지 마.
git reset --hard 금지.
git clean 금지.
대상 worktree, 로컬 브랜치, 원격 브랜치만 삭제하고 결과 보고해줘.

11. 내가 기억하려고 만든 운영 원칙

• 작업이 하나뿐이고 상태가 깨끗하면 단순 방식도 괜찮다.
• 동시에 2개 이상 작업하면 main 직접 작업은 피한다.
• 세션마다 작업 대상 파일을 명확히 정한다.
• 기존 워킹트리에 unrelated 변경이 있으면 clean worktree를 쓴다.
• 커밋할 때 git add .를 쓰지 않는다.
• 커밋 전에는 반드시 stage된 파일 목록을 확인한다.
• 작업 브랜치에 push됐다고 main에 반영된 것은 아니다.
• PR은 main에 합치기 전 마지막 검문소라고 생각한다.
• merge가 끝난 브랜치와 worktree는 정리한다.
• 작업 중 발견한 별도 문제는 원래 작업 PR에 섞지 않고 후속 과제로 분리한다.

12. 한 문장으로 정리하면

예전에는 한 사람이 한 책상에서 한 작업만 했기 때문에 단순한 Git 흐름으로 충분했어.

단건 작업

수정 → 테스트 → commit → push

하지만 AI 여러 세션이 동시에 작업하기 시작하면, 책상을 나누고 작업 줄기를 나누고 main에 합치기 전에 검문하는 과정이 필요해져.

병렬 작업

worktree 분리
→ branch 작업
→ 테스트
→ push
→ PR
→ merge
→ 정리

결론
Git이 갑자기 어려워진 게 아니라, 작업 방식이 바뀐 거였어. 단건 개발에서는 단순함이 장점이고, 병렬 개발에서는 분리가 안전장치가 된다.

이 글은 개인 웹서비스를 AI 코딩 도구와 함께 개발하면서 겪은 Git 작업 흐름 정리야.

나처럼 비개발자에 가깝지만 AI 도구로 서비스를 만들고 운영하는 사람이라면, main, branch, worktree, PR, merge의 차이만 알아도 작업 안정성이 꽤 좋아질 것 같아.