Review Changes & Source Control — 에이전트가 만든 변경 검토하기

1. 왜 별도 검토 단계가 필요한가? #

에이전트가 코드를 자동으로 직접 저장해 버리면 다음 두 가지 문제가 생깁니다.

• ❌ 의도하지 않은 파일까지 수정 — 한 요청이 다섯 파일을 건드릴 때 한두 파일이 잘못된 방향으로 가도 인지하기 어려움
• ❌ 되돌리기 비용 — git에 커밋되기 전 단계라 IDE 단위로 일괄 되돌리는 도구가 마땅하지 않음

Antigravity는 이 문제를 두 단계로 분리합니다.

1. 에이전트 → "제안된 변경" — 파일은 아직 수정되지 않은 상태. 사용자에게 diff로 보여줌
2. 사용자 검토 → 일부/전체 수락 — 수락한 변경만 실제 파일에 반영됨

이 흐름은 Implementation Plan → Walkthrough(완료 요약) → Review Changes로 이어지는 큰 작업 사이클의 마지막 사람 검수 지점입니다.

2. Review Changes 흐름 #

2.1 진입 — Manager View의 "Review Changes" 버튼

에이전트가 한 작업 단위(Task Group)를 완료하면 Agent Manager 우측에 "Review Changes" 버튼이 활성화됩니다. 클릭하면 변경된 파일 목록과 각 파일의 diff가 나란히 표시됩니다.

2.2 검토 단위 — 파일별·hunk별 수락/거절

2.3 검토 중에 할 수 있는 작업

• 코멘트 남기기 — 특정 hunk에 의견을 달아 다음 턴에 에이전트가 참고하게 함
• 부분 수락 후 추가 요청 — "이 변경은 받았는데 X 부분만 추가로 손봐 줘" 식 후속 대화
• 되돌리기 — Accept한 직후라도 동일 패널에서 한 번 더 되돌릴 수 있음 (단, 시간 지나거나 다른 변경이 위에 쌓이면 git에서 처리해야 함)

3. Source Control 패널 #

Review Changes에서 수락한 변경은 워크스페이스 파일에 적용됩니다. 거기서부터는 일반 git 흐름이고, Antigravity는 VS Code와 같은 Source Control 사이드바를 제공합니다.

3.1 진입 — 좌측 사이드바의 분기 아이콘

에디터 왼쪽 활동 표시줄(Activity Bar)의 Source Control(분기 아이콘) 또는 단축키 Ctrl+Shift+G (macOS: Cmd+Shift+G)로 패널을 엽니다.

3.2 패널 구성

3.3 diff 보기

파일 이름을 클릭하면 좌·우 두 패널의 diff 뷰가 열립니다. 좌측은 HEAD, 우측은 워킹 디렉터리. 줄 단위로 이전 ↔ 이후를 비교하고 우클릭으로 해당 줄을 stage/unstage 합니다.

3.4 Inline Suggestions

에이전트가 한 변경 위에 마우스를 올리면 인라인 코멘트와 빠른 액션(되돌리기·추가 수정 요청)이 표시됩니다. 코드 리뷰 도구와 비슷한 UX입니다.

4. 실전 워크플로 #

4.1 권장 흐름 — 5단계

1. 요청·계획 — 자연어로 작업 요청, Planning 모드면 Implementation Plan 검토 후 승인.
2. 에이전트 실행 — Task Group 단위로 작업 진행. 중간 산출물은 Walkthrough에 누적.
3. Review Changes — 파일별로 diff 확인. 의도와 다른 부분은 Reject 또는 코멘트.
4. Accept — 검토된 변경만 워크스페이스에 반영.
5. Source Control — Staged 영역에서 다시 한 번 확인 후 git 커밋. 필요 시 push.

4.2 작은 작업과 큰 작업의 분기

4.3 코멘트로 후속 요청 잇기

Review Changes에서 특정 hunk에 코멘트를 남기고 그대로 다음 턴을 시작하면, 에이전트가 그 코멘트를 컨텍스트로 받아 후속 변경을 만듭니다. 별도 채팅 입력 없이도 "여기 이렇게 고쳐 줘"가 이어집니다.

5. 트러블슈팅 #

6. git worktree로 병렬 작업 #

에이전트에게 한 프로젝트에서 여러 작업을 동시에 시키면(예: main에서 리팩터링을 진행 중인데 급한 hotfix가 필요), 브랜치를 하나 만들어 git switch로 오가는 방식은 컨텍스트가 계속 뒤섞입니다. git worktree는 같은 .git 저장소를 공유한 채 브랜치별로 독립 폴더를 만들어 두는 기능입니다. 폴더가 물리적으로 분리되니 에이전트 세션·에디터 창·터미널을 각각 띄워 진짜 병렬로 굴릴 수 있습니다.

6.1 branch만 쓸 때 vs worktree를 쓸 때

6.2 언제 worktree가 필요한가

• 에이전트에게 여러 작업을 동시에 맡길 때 — main에서 대형 리팩터링이 돌아가는 중에 hotfix가 들어와도 서로 파일을 덮어쓰지 않습니다.
• 스테이징한 변경을 잃지 않고 다른 브랜치를 봐야 할 때 — git stash로 임시 저장·복원하는 절차 없이 그냥 다른 폴더에서 작업합니다.
• 여러 브랜치의 빌드·테스트를 병렬로 돌릴 때 — 각 폴더에 별도 node_modules·.venv가 있으니 의존성 재설치·캐시 충돌이 없습니다.
• PR 리뷰용 브랜치를 임시로 열어 볼 때 — 내 작업 폴더는 그대로 두고 리뷰 폴더만 따로 열어 실행·비교합니다.

6.3 기본 사용법

# 새 브랜치와 함께 worktree 생성 (부모 폴더에 만들기)
git worktree add ../myproject-feat -b feature/new-ui

# 기존 브랜치를 worktree로 열기
git worktree add ../myproject-hotfix hotfix/urgent

# 현재 worktree 목록 확인
git worktree list

# 작업이 끝난 worktree 정리 (폴더 삭제 후)
git worktree remove ../myproject-feat

# 이미 삭제된 폴더의 참조 정리
git worktree prune

6.4 Antigravity와 함께 쓰기

1. 워크스페이스로 메인 폴더(myproject/)를 열고 main 브랜치의 대화를 시작합니다.
2. 새 터미널에서 git worktree add ../myproject-feat -b feature/xxx를 실행합니다.
3. Antigravity에서 agy-ide ../myproject-feat로 두 번째 창을 엽니다. 창마다 독립된 Agent Manager가 뜨므로 서로 방해 없이 병렬 실행됩니다.
4. 각 창의 에이전트가 낸 변경은 각자의 폴더에만 반영되고, 커밋 히스토리는 공유된 .git에 모입니다. main에 병합할 때만 다시 만나면 됩니다.