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

에이전트가 코드를 다 만든 뒤 곧바로 적용되는 것이 아니라, diff 형태로 보여주고 사람이 수락한 부분만 워크스페이스에 반영됩니다. 이 흐름이 Review Changes이고, 이후 git 영역과 연결되는 곳이 Source Control 패널입니다. 공식 문서 — Review Changes + Source Control

이 페이지의 목적: Review Changes(에이전트 결과물 diff 검토)와 Source Control(VS Code 스타일 git 패널) 두 인접 기능의 흐름·UI·자주 마주치는 문제를 정리합니다. 두 기능은 같은 화면 영역을 공유하지만 책임이 다릅니다.

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

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

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

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

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

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

한 줄 비유

코드 리뷰의 PR 단계와 같습니다. 변경이 곧바로 main으로 들어가지 않고, diff로 확인한 뒤 한 줄·한 파일 단위로 받아들이는 흐름이 IDE 내부로 들어온 것입니다.

2. Review Changes 흐름 #

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

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

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

Review Changes 수락 단위
단위	동작	사용 시점
Accept All	모든 변경을 한 번에 적용	전체 흐름이 의도와 맞을 때 — 가장 자주 쓰는 동작
파일별 Accept / Reject	해당 파일의 모든 변경만 일괄 적용 또는 폐기	코드 변경은 OK, 부수적으로 수정된 README는 마음에 안 들 때
Hunk별 Accept / Reject	한 파일 안의 변경 블록 일부만 적용	한 파일에 의도한 수정과 의도치 않은 수정이 섞여 있을 때
Reject All	이번 작업 단위의 모든 변경 폐기	접근이 잘못됐다고 판단해 처음부터 다시 요청할 때

2.3 검토 중에 할 수 있는 작업

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

실전 팁: 처음에는 "파일별 검토 + Accept" 흐름을 권장합니다. Accept All은 익숙해진 뒤로. Hunk별 검토는 큰 리팩터링에서 진가가 드러납니다.

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 패널 구성

Source Control 패널 구성
영역	내용
변경 사항 (Changes)	아직 staged 되지 않은 파일 목록
스테이지 (Staged Changes)	커밋 대상으로 추가된 파일 목록
커밋 메시지 입력란	상단 텍스트 영역. `Cmd+Enter`로 커밋
액션 메뉴	… 아이콘으로 Pull/Push/Fetch/Branch 등 일반 git 작업 호출

3.3 diff 보기

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

3.4 Inline Suggestions

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

4. 실전 워크플로 #

4.1 권장 흐름 — 5단계

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

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

작업 규모별 검토 전략
작업 규모	권장 검토 단위	예시
한두 줄 수정	Accept All — 빠르게 진행	오타 수정, 변수명 변경
한 파일 1~50줄	파일별 검토	한 함수 리팩터, 작은 기능 추가
여러 파일·100+ 줄	파일별 + 중요한 곳은 hunk별	아키텍처 변경, 의존성 이동
대형 마이그레이션	Walkthrough + 단계별 Review Changes	프레임워크 업그레이드, 폴더 구조 재편

4.3 코멘트로 후속 요청 잇기

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

5. 트러블슈팅 #

Q. Source Control 패널이 변경을 자동으로 감지하지 못해요.
공식 포럼에 보고된 알려진 이슈입니다. 패널 상단 새로고침 버튼(↻)을 누르거나, 워크스페이스를 다시 열면 즉시 반영됩니다.

Q. Accept All을 눌렀는데 한 파일이 빠졌어요.
해당 파일이 .gitignore에 포함됐거나, 권한 시스템(Unified Permissions)의 Filesystem 범주에서 Deny로 막혀 있을 수 있습니다. Permission 설정과 ignore 규칙을 점검하세요.

Q. 일부만 Accept했는데 변경이 모두 사라졌어요.
Accept하지 않은 hunk는 폐기됩니다. 의도하지 않게 Reject한 경우 같은 작업을 다시 요청하거나, 패널 상단의 실행 취소(짧은 시간 내에만 노출됨)를 사용합니다.

Q. 큰 diff에서 hunk 단위 검토가 너무 느려요.
한 번에 모든 hunk를 보지 말고, 파일별로 Accept한 뒤 다음 파일로 이동하는 흐름을 권장합니다. 패널 폭을 늘리거나 단축키로 다음 파일(Alt+→)·이전 파일(Alt+←)로 빠르게 이동할 수 있습니다.

Q. 에이전트 작업과 별개로 내가 직접 만든 변경이 섞여 있어요.
작업 요청 전에 git stash로 본인 변경을 분리하거나, 별도 브랜치를 만들어 에이전트 작업을 격리하세요. 병렬 대화처럼 깨끗한 시작점을 만드는 것이 가장 안전합니다.