30초 결론: Antigravity와 Cursor 중 어디를 고를 것인가#
에이전트를 먼저 두는 IDE와 에디터를 먼저 두는 IDE의 차이를 브라우저 제어·아티팩트가 실제로 제 역할을 하는 작업에 한정해 비교합니다. 다만 양쪽 모두 에디터와 브라우저 에이전트를 제공하므로 기능 유무보다 검토 흐름과 권한 설정을 살펴봐야 합니다.
비교표: 인터페이스, 모델, 권한, 한국어, 가격 (6–8행)#
아래 공식 자료는 각각 2026-11-01에 확인했습니다. 계정, 버전, 사용 환경에 따라 제공 기능이 다를 수 있습니다.
| 기준 | Antigravity IDE | Cursor |
|---|---|---|
| 작업 환경 | 에디터, 에이전트와 병렬 작업 | 에디터의 에이전트와 CLI |
| 브라우저 | 별도 브라우저 에이전트와 녹화 아티팩트 | 에이전트 브라우저와 스크린샷 |
| 계획과 검토 | 계획 아티팩트 검토 | Plan Mode의 계획 검토. 작업공간에 저장 가능 |
| 실행 권한 | Antigravity 공식 IDE 설정 문서의 IDE 탭은 Strict Mode의 터미널 명령·브라우저 JavaScript·아티팩트 검토를 Request Review로 설명; 실제 설치 동작은 미시험 | 실행 모드와 브라우저 승인 설정에 따라 다름 |
| 모델과 요금 | 개인 무료와 주간 한도, Google AI Pro·Ultra의 확대된 한도와 크레딧 | 신규 개인 구독 Free, Plus 월 $8, Premium 월 $30, 세금 별도; Premium 이상 타사 모델은 첫 요청부터 별도 선불 크레딧 |
| 코드와 개인정보 | Google 약관은 개인 이용의 상호작용 수집·검토와 개선 이용, 설정 변경을 안내; 기업 계정은 별도 약관 확인 | Privacy Mode와 클라우드 에이전트 데이터 처리 확인 |
| 한국어 | 실제 저장소에서 입력·결과 확인; 비교 측정 없음 | 실제 저장소에서 입력·결과 확인; 비교 측정 없음 |
- 브라우저 작업의 녹화와 계획 아티팩트를 중점적으로 검토한다면 Antigravity IDE를 살펴보세요.
- 에디터의 계획·브라우저 도구를 함께 쓰려면 Cursor도 시험하세요. 브라우저 작업이 한 제품에만 있는 것은 아닙니다.
- 두 도구에서 접근 가능한 파일과 명령, 브라우저 권한과 데이터 처리 조건을 정하고 같은 규모의 작업을 직접 평가하세요.
요금 조건은 위 비교표와 아래 가격 항목의 공식 자료를 참고하세요.
Antigravity가 강한 경우 / Cursor가 강한 경우#
Antigravity IDE는 브라우저 동작 녹화와 계획 아티팩트를 검토할 때 후보입니다. 설정과 검토를 거쳐야 하므로 자동 실행만으로 안전이나 결과의 정확성을 보장하지는 않습니다. Cursor는 에디터 안에서 계획과 브라우저 도구를 함께 쓰고 싶은 경우 후보입니다. 실행 모드에 따라 승인과 샌드박스 동작이 달라지며 자동 검토는 보안 경계가 아닙니다.
같은 과제 비교: Antigravity와 Cursor에 같은 이슈를 맡겼을 때#
두 도구에 같은 이슈를 실행한 기록은 아직 없습니다. 직접 비교한다면 민감한 정보가 없는 같은 저장소와 UI 수정 과제를 사용하고, 각 도구의 파일 diff, 브라우저 확인 내용, 테스트 출력과 승인 요청을 따로 기록하세요. 실행하지 않은 테스트는 결과에 포함하지 않습니다.
문서상 검토 자료를 실제 실행 결과와 구분하면 다음과 같습니다. 양쪽 모두 기능이 있다는 것과 같은 결과를 냈다는 것은 다릅니다.
| 검토 자료 | Antigravity 공식 안내 | Cursor 공식 안내 |
|---|---|---|
| 변경 전 계획 | 구현 계획 아티팩트 | Plan Mode의 계획 검토·저장 |
| 브라우저 확인 | 브라우저·녹화 아티팩트 | 브라우저 도구의 확인 내용 |
| 실행 권한 | IDE 설정의 Strict Mode 항목에 명시된 검토 범위 | 실행 모드와 브라우저 승인 |
| 실제 결과 | 같은 과제의 diff·테스트·화면은 아직 미확보 | 같은 과제의 diff·테스트·화면은 아직 미확보 |
브라우저 화면이 예상대로 보이더라도 코드 회귀 테스트를 대신하지는 않습니다. 실제 기록에는 설치 버전, 요청, 권한과 실패한 확인도 함께 남기세요.
문서 추가 확인: Antigravity 공식 변경 기록을 2026-11-02에 확인했습니다. App·CLI·IDE 등 제품별 릴리스가 구분되며 새 버전은 순차 배포될 수 있다고 안내합니다. 비교할 때는 실제 설치 버전과 제품 화면을 따로 기록하세요. 이 확인은 Agent Manager·아티팩트 화면이나 동일 과제 실행의 증거가 아닙니다.
가격: 구독과 사용량#
2026-11-01에 확인한 공식 요금과 사용 조건은 위 비교표를 참고하세요. 기존 구독은 조건이 다를 수 있으므로 각 결제 화면에서 지역 가격, 세금과 추가 사용료를 확인하세요.
2026-11-01 확인 기준 Cursor 요금표는 신규 Plus에 Grok 모델만 사용 가능하다고 설명하지만, 모델 요금 문서는 Grok 외에 Composer 2.5도 명시합니다. 실제 이용 범위는 현재 계정과 결제 화면, 모델 선택기에서 확인하세요.
미르 코드가 맞는 경우 / 맞지 않는 경우#
Mirr Code는 한국어를 우선하는 터미널 작업을 원할 때 살펴볼 수 있습니다. Antigravity IDE나 Cursor의 브라우저·에디터 기능을 같은 방식으로 제공하는지는 이 페이지에서 확인하지 못했습니다. 요금제와 결제 화면에서 현재 조건을 확인하고, 세 도구의 작업 결과를 비교한 기록이 없다는 점을 고려하세요.
브라우저가 필요한 과제부터 고르세요#
이 두 제품을 비교할 때는 브라우저를 실제로 써야 판단할 수 있는 과제를 고르는 편이 좋습니다. 단순한 함수 이름 변경만 시험하면 브라우저 제어와 아티팩트의 가치를 평가하기 어렵습니다. 반대로 보기 좋은 화면만 만들도록 요청하면 데이터 처리나 오류 동작을 놓칠 수 있습니다. 폼의 오류 안내, 키보드 이동과 좁은 화면의 배치를 함께 검토하는 작은 UI 수정처럼 수용 기준을 정할 수 있는 과제가 적절합니다. 이는 시험 과제의 제안이며 이 페이지에서 수행한 결과는 아닙니다.
요청에는 바꿀 화면과 유지할 동작을 함께 적으세요. 오류 메시지를 고치는 과제라면 서버의 검증 계약까지 바꿔도 되는지 정하세요. 디자인을 다듬는 과제라면 제출, 취소와 뒤로 가기의 기존 동작을 유지하는지 확인합니다. 두 도구에 같은 화면 상태와 합성 입력을 주고, 필요한 자료를 한쪽에만 추가하지 않습니다. 화면을 읽은 경로와 실제로 조작한 경로도 기록할 만합니다.
계획과 녹화 아티팩트를 읽는 방법#
계획 아티팩트에는 무엇을 바꾸고 어떻게 검증할지 드러나야 합니다. 계획이 길거나 세련되게 보인다는 이유로 좋은 결과라고 판단하지 마세요. 요구사항의 중요한 예외와 변경 금지 영역을 포함했는지 봅니다. 실제 diff가 계획과 달라지면 변경 이유를 설명할 수 있어야 합니다. 계획을 승인했다는 사실은 이후 생성된 코드를 모두 승인했다는 뜻이 아닙니다.
녹화나 화면 캡처는 어떤 상태를 보았는지 알려 줍니다. 하지만 준비된 로그인 상태, 숨겨진 데이터와 이전 조작을 모르면 같은 장면을 재현하기 어렵습니다. 확인에 사용한 입력과 화면 크기, 시작 경로를 함께 남기세요. 브라우저가 버튼을 눌렀다는 사실과 서버에 올바른 요청이 전달됐다는 사실도 다릅니다. 코드 테스트와 네트워크·상태 검토가 필요한 과제라면 해당 자료를 별도로 확보해야 합니다.
Antigravity 브라우저 하위 에이전트는 브라우저와 상호작용할 때마다 동작 녹화를 만들 수 있고, 녹화는 브라우저 단계 화면 하단에서 재생되며 녹화 아티팩트로도 저장된다고 문서가 설명합니다. 스크린샷과 동작 영상은 상호작용 아티팩트로 저장된다고 문서는 덧붙이고 있습니다. 재생은 행동 순서를 반복해 보여 주므로, 같은 장면을 여러 번 보고 판단하기 전에 어느 단계의 녹화인지 이름을 붙여 두세요 (브라우저 녹화 문서, 브라우저 문서, 2026-11-03 확인).
아티팩트를 공개할 때는 화면 속 개인정보도 점검하세요. 합성 자료를 사용했더라도 주소창, 계정 이름과 알림에 실제 정보가 남을 수 있습니다. 내부 원본과 공개 발췌를 나누고 제거한 범위를 기록합니다. 편집한 영상이 실행 순서나 실패를 숨기지 않는지도 확인하세요. 이 페이지에는 Agent Manager나 실제 과제의 아티팩트 화면이 아직 없습니다. 공식 문서의 기능 설명과 독자가 직접 재현할 수 있는 실제 산출물은 다른 자료라는 구분을 유지합니다.
에이전트 전용 브라우저와 사용자 계정을 분리합니다#
2026-11-03 확인한 Antigravity 브라우저 안내는 별도 브라우저 에이전트, 화면 캡처와 동작 영상 및 분리된 프로필을 설명합니다. 분리된 프로필이 있다는 사실만으로 시험 중 입력한 자료가 모두 비공개로 남는다고 단정할 수는 없습니다. 연결한 계정과 접근한 서비스, 저장한 아티팩트를 별도로 확인하세요. 제품별 브라우저 정책과 해당 계정의 약관도 함께 살피세요.
브라우저 작업을 맡기기 전에는 허용할 사이트와 행동을 정하세요. 읽기, 폼 입력과 최종 제출은 다른 승인입니다. 테스트 사이트에서도 메일 발송이나 외부 웹훅이 연결돼 있다면 예상하지 못한 외부 효과가 있을 수 있습니다. 실제 고객 계정 대신 승인된 합성 계정을 쓰고, 구매·발송·삭제가 필요한 경우에는 별도 허가를 받습니다. 화면이 편리하다는 이유로 사용자의 기존 인증을 조용히 이용하지 않습니다. 실패했다고 더 넓은 로그인 범위나 접근 권한을 추가하는 것도 별도 판단입니다.
Antigravity IDE 브라우저 접근은 거부 목록과 허용 목록의 두 층으로 나뉩니다. 거부 목록은 서버 측 조회로 확인하며 서버에 닿지 않으면 접근을 거부합니다. 허용 목록은 로컬 파일로 저장되고 처음에는 localhost만 들어 있으며, 사용자가 직접 편집하고 언제든 바꿀 수 있습니다. 허용되지 않은 주소로 이동하려 하면 Always allow 버튼이 뜨고, 누르면 그 주소가 허용 목록에 추가됩니다. 거부 목록의 주소는 허용 목록에 넣을 수 없습니다. 사용자 설정의 Browser Tools 항목을 끄면 브라우저 도구 전체가 꺼집니다 (허용·거부 목록 문서, 브라우저 문서, 2026-11-03 확인).
Cursor 브라우저 도구는 기본으로 실행 전 승인을 요구하며, Agent 설정에서 Manual approval, 허용 목록 동작만 자동 실행, Auto-run 중 하나를 고릅니다. Auto-run은 모든 브라우저 동작을 사람의 승인 없이 실행하므로 신뢰하지 않는 사이트에서는 쓰지 말라고 문서가 경고합니다. 관리자가 켤 수 있는 origin 허용 목록은 허용 밖 주소에서 클릭·입력·이동 도구를 막지만, 허용 사이트의 링크, 리디렉션과 클라이언트 측 이동은 막지 못한다고 명시합니다 (브라우저 문서, 2026-11-03 확인).
Cursor 브라우저는 인증 쿠키와 세션 데이터가 브라우저 세션을 넘어 남는다고 문서가 설명합니다. 같은 문서는 브라우저 컨텍스트를 작업 공간마다 분리해 프로젝트별 저장소와 쿠키 상태가 섞이지 않게 한다고 적습니다. 테스트 계정으로 시험할 때는 이전 과제의 로그인 상태가 남아 있는지부터 확인하세요. Antigravity의 분리된 Chrome 프로필과 비교할 때는 세션 유지와 작업 공간 단위 분리를 따로 기록하세요 (브라우저 문서, 2026-11-03 확인).
Cursor 브라우저 도구는 콘솔 메시지, 오류와 로그를 읽고 네트워크 경고까지 확인해 화면에 보이지 않는 실패를 찾는다고 문서가 설명합니다. 비교 기록에는 화면을 본 확인과 콘솔·네트워크 신호를 본 확인을 나눠 적으세요 (브라우저 문서, 2026-11-03 확인).
같은 문서에 따르면 에이전트가 한 브라우저 동작은 채팅 안에 스크린샷과 함께 표시되고, 브라우저 창 자체는 별도 창이나 인라인 패널로 열립니다. 스크린샷은 파일 읽기 도구와 연결돼 에이전트가 텍스트 설명이 아닌 이미지로 화면 상태를 본다는 설명도 있습니다. 화면 확인 기록에는 이미지로 본 항목과 텍스트로 확인한 항목을 나눠 적으세요 (브라우저 문서, 2026-11-03 확인).
자동 검토를 안전 보증으로 읽지 않기#
Cursor의 실행 모드는 Auto-review 분류기가 오류를 낼 수 있으며 보안 경계가 아니라고 설명합니다. Antigravity의 검토 설정 역시 설정 이름만으로 모든 위험이 막혔다고 표현할 수 없습니다. 검토가 필요한 행동, 로컬 파일과 브라우저의 접근 범위가 실제 과제에 맞는지 봐야 합니다. 코드 안의 지침이나 웹 페이지의 문구는 작업 자료일 뿐 새로운 권한을 부여하는 명령으로 취급하지 않는 운영 기준도 필요합니다.
같은 문서에 따르면 Auto-review 분류기는 Cursor 백엔드에서 실행되며, 판단에 필요하면 사용자 컴퓨터에서 읽기 전용 ReadFile, Grep, Glob, ListDir 호출을 할 수 있습니다. 예를 들어 명령이 실행하는 스크립트를 읽는 경우가 여기에 듭니다. 같은 문서는 Auto-review가 셸, MCP, Fetch 도구 호출에 적용된다고 명시합니다. 승인 창이 있다는 사실과 분류기로 전달되는 자료는 서로 다른 기록 항목이므로 데이터 처리 칸에 따로 적으세요 (실행 모드 문서, 2026-11-03 확인).
자동 실행의 평가는 성공한 동작만 보면 안 됩니다. 과제 밖 파일을 고치려 했는지, 필요 없는 외부 페이지를 열었는지와 차단 뒤 어떤 대응을 했는지도 기록합니다. 제한에 막혔다는 사실은 때로 정책이 의도대로 작동한 관찰일 수 있습니다. 승인 횟수를 줄이기 위해 모든 도구를 열어 놓으면 같은 안전 조건의 비교가 되지 않습니다. 실행을 멈추는 기준을 먼저 정하고, 위험한 행동을 실제로 실행해 차단 여부를 확인하려 하지 마세요. 승인된 안전 시험만 수행해야 합니다.
같은 문서는 샌드박스의 네트워크를 기본으로 막고, /tmp와 플랫폼 임시 디렉터리에는 쓸 수 있게 둔다고 설명합니다. 전체 시스템 접근이 필요한 명령은 샌드박스 밖에서 실행될 수 있으며, Cursor가 그 사실을 표시하고 승인을 요청한다고 명시합니다. 승인 기록에는 샌드박스 밖 실행 요청이 몇 번 나왔는지도 함께 적어 두세요 (실행 모드 문서, 2026-11-03 확인).
읽기 접근은 작업 공간 안에서는 자유롭고, 작업 공간 밖 파일은 승인을 받거나 읽기 허용 목록에 있어야 읽을 수 있다고 실행 모드 문서가 설명합니다. 검색 결과도 작업 공간과 허용 목록 밖의 파일을 건너뛴다고 명시하므로, 검색에서 나오지 않은 자료를 없다고 판단하기 전에 허용 목록을 확인하세요 (실행 모드 문서, 2026-11-03 확인).
UI 수정 과제를 수락할 때의 검토 순서#
처음에는 코드 범위를 확인합니다. 요청한 화면의 수정인지, 관련 없는 스타일과 패키지까지 바뀌었는지 살펴보세요. 다음으로 정상 입력과 잘못된 입력을 각각 확인합니다. 오류 안내가 보여도 사용자가 다음 행동을 알 수 없다면 문구와 초점 처리를 검토할 여지가 있습니다. 마지막에는 기존 기능과 테스트를 점검합니다. 화면이 예상처럼 보여도 기존 제출 계약이나 권한 처리가 바뀌었을 수 있습니다. 이 순서는 제안이며 양쪽의 실제 성공·실패 결과는 아닙니다.
Antigravity IDE에서는 대화 중 코드를 쓰기 시작하면 Agent 패널 하단에 Review Changes가 나타나고, 열면 에디터 창에서 이 대화 중 사용자와 에이전트가 만든 모든 변경을 훑을 수 있습니다. 파일 diff에 댓글을 달아 에이전트와 소통할 수도 있습니다. 앱과 CLI의 검토와 커밋은 다른 문서에 있으므로 비교 기록에 제품 화면을 나눠 적으세요 (변경 검토 문서, 2026-11-03 확인).
Antigravity의 Agent 사이드 패널은 편집기 안에서 새 대화를 시작하고 기록을 찾으며, @로 맥락을 붙이고 /로 워크플로를 실행하는 곳입니다. 진행 중에는 단계별 진행 상황과 편집된 파일을 보여 주고, 하단 도구 모음에서 아티팩트, 실행 중인 터미널 프로세스와 열린 파일 변경을 추적한다고 문서가 설명합니다. 이 화면이 어떤 정보를 한곳에 두는지 기록해 두면 Cursor의 에디터 채팅과 비교하는 기준이 됩니다 (사이드 패널 문서, 2026-11-03 확인).
반응형 검토에는 화면 크기와 콘텐츠 상태를 함께 적으세요. 짧은 영어 문구가 맞게 보인 화면과 긴 한국어 오류 문구가 들어간 화면은 다릅니다. 버튼의 줄바꿈, 한글 입력 조합과 잘린 도움말을 확인할 수 있습니다. 다만 자동 브라우저 조작으로 보조기술 사용자의 경험을 모두 검사했다고 주장하지 않습니다. 실제 사람의 접근성 검토가 필요하면 별도 항목으로 남기세요. 화면 캡처는 시각 상태의 일부를 보여 주며 사용성 전체의 인증서가 아닙니다.
여러 에이전트를 동시에 관리한다면 결과와 작업 공간의 연결도 봅니다. 어떤 과제가 어느 브랜치나 파일을 바꿨는지, 다른 과제의 변경을 덮어쓰지 않았는지 확인하세요. Agent Manager의 카드가 완료로 표시돼도 코드의 수용 기준은 별도로 검토하세요. 동시에 실행한 수가 많다는 사실만으로 생산성이 높다고 결론 내리지 않습니다. 충돌 해결과 리뷰에 들어간 사람의 일도 남겨야 전체 흐름을 판단할 수 있습니다. 현재 이 페이지에는 병렬 실행이나 충돌 복구의 실측 자료가 없습니다.
미리보기 조건과 실제 설치 버전을 보관하세요#
공개 가격표와 변경 기록은 현재 제공 범위를 읽는 자료입니다. 순차 배포와 계정 조건이 있으므로 비교 기록에는 실제 제품 화면과 설치 버전을 남기세요. 2026-11-03에 Antigravity 공식 IDE 설정 문서의 Strict Mode 항목을 확인했습니다. Strict Mode에서 터미널 명령은 allowlist와 관계없이 확인을 요청하고, 브라우저 JavaScript와 아티팩트 계획에 따른 행동도 Request Review로 둔다고 설명합니다. 이것은 해당 IDE 문서의 설정 설명이며 App·CLI 전체나 실제 설치에서 검증한 안전 보증이 아닙니다.
가격을 비교할 때는 브라우저 작업에 쓴 모델과 재시도도 실제 사용량에서 확인하세요. 무료 진입이 있다는 설명과 모든 UI 과제를 무료로 끝낼 수 있다는 주장은 다릅니다. Cursor의 신규·기존 구독과 타사 모델 과금, Antigravity의 계정별 한도와 크레딧 조건을 나눠 보세요. 이 페이지는 같은 화면 과제의 실제 지출을 계산하지 않았습니다. 필요한 검토 자료를 어느 흐름에서 더 잘 남길 수 있는지 시험한 뒤 현재 계정의 조건과 함께 결정하는 것이 적절합니다.
연락처 폼을 한 번에 검토하는 가상 walkthrough#
다음은 실행하지 않은 설명용 과제입니다. 연락처 폼에 이름과 이메일 입력이 있고, 서버의 기존 입력 계약은 바꾸지 않는다고 정합니다. 목표는 오류가 난 필드를 알아볼 수 있게 하고 키보드로 수정한 뒤 다시 제출할 수 있게 하는 것입니다. 디자인은 좁은 화면에서도 긴 한국어 안내가 잘리지 않아야 합니다. 이 요청을 Antigravity와 Cursor에 똑같이 전달하되 실제 메일 발송이나 고객 데이터는 사용하지 않는 합성 환경을 전제로 합니다.
구현 전 계획에서 첫 결정은 검증의 위치입니다. 프런트엔드의 안내만 바꿀지와 서버 검증도 바꿀지는 다른 과제입니다. 예시에서는 서버 계약을 유지하므로 클라이언트에서 표시할 오류와 기존 응답의 매핑을 계획에 적습니다. Antigravity의 계획 아티팩트에서는 이 매핑을 구현 전에 검토할 수 있고, Cursor Plan Mode에서는 현재 코드베이스의 검증·제출 경로를 조사한 계획을 편집할 수 있습니다. 두 경로 모두 이 단계에서 서버 계약을 바꾸려는 제안이 들어가면 요청 범위부터 다시 결정하세요.
다음 결정은 첫 오류의 표현입니다. 이름이 비어 있는 경우와 이메일 형식이 맞지 않는 경우를 같은 “오류가 있습니다”로 표시하면 사용자가 무엇을 고쳐야 할지 알기 어렵습니다. 예시 계약은 필드와 수정 행동을 연결하는 안내를 요구합니다. 코드 diff에서는 오류 키가 올바른 입력에 연결되는지, 브라우저에서는 해당 필드와 안내를 실제로 함께 읽을 수 있는지 봅니다. 여기서 계획은 무엇을 의도했는지, diff는 어떤 매핑을 구현했는지, 화면은 그 연결이 어떻게 보이는지를 각각 설명합니다.
| 예시의 상태 전이 | 계획에서 결정할 내용 | diff에서 읽을 연결 | 브라우저에서 볼 장면 |
|---|---|---|---|
| 빈 폼에서 제출 | 필수 조건과 오류 표시 시점 | 검증 결과와 입력 식별자 | 어느 필드를 고쳐야 하는지 |
| 잘못된 이메일 입력 | 오류 수정 안내와 원문 값 유지 | 값 보존과 오류 갱신 | 입력이 사라지지 않고 수정 가능한지 |
| 키보드로 오류 수정 | 초점 이동과 제출 순서 | 이벤트·레이블·오류 연결 | 마우스 없이 다음 동작을 할 수 있는지 |
| 제출 대기 | 중복 입력 처리와 표시 | 제출 상태와 버튼 동작 | 기다리는 이유가 보이는지 |
| 실패 응답 후 재시도 | 입력 유지와 복구 행동 | 실패 상태 해제와 재전송 조건 | 같은 값을 다시 쓰지 않고 재시도 가능한지 |
| 좁은 화면 | 긴 한국어 문구의 배치 | 반응형 스타일과 콘텐츠 관계 | 안내와 버튼이 잘리지 않는지 |
Antigravity 아티팩트와 Cursor 에디터에서 읽는 순서#
Antigravity 브라우저 문서는 Browser Subagent가 페이지를 열고 읽고 조작하며 화면 캡처와 동작 영상을 남길 수 있다고 설명합니다. 이 예시의 재시도 흐름을 영상으로 남긴다면 시작 입력, 실패 상태와 다시 누른 뒤 상태를 연결해 볼 수 있습니다. 실패 응답을 합성 환경에서 준비했다는 조건도 자료 옆에 붙입니다. 계획 아티팩트의 재시도 조건과 영상의 행동 순서를 대조하는 검토 흐름입니다.
Cursor에서는 에디터에서 오류 매핑을 고친 diff를 읽고 브라우저 도구로 해당 화면을 확인하는 흐름을 검토할 수 있습니다. 예를 들어 안내 문구의 키는 바뀌었는데 렌더링이 예전 키를 읽는다면 코드 연결을 에디터에서 추적해야 합니다. 반대로 코드 연결은 맞아도 좁은 화면에서 안내가 겹치면 화면 배치를 조정할 일입니다. 기능을 수정하는 읽기와 실제 화면을 확인하는 읽기를 오갈 때 어떤 정보가 작업 공간에서 바로 보이는지가 선택 기준이 됩니다.
실패 뒤 입력이 지워지는 문제를 발견했다고 가정하면 다음 질문은 값을 언제 초기화하는가입니다. 성공과 실패 양쪽에서 초기화하는 코드를 하나로 묶었는지, 실패 상태만 해제해야 하는데 폼 전체를 다시 만드는지 읽을 수 있습니다. 이 결함을 고치기 위해 서버 응답 형식까지 바꿀 필요가 있는지는 별도로 판단합니다. 상태 전이 표가 있으면 새 요청을 넓히기보다 실패 행과 연결된 코드부터 좁혀 볼 수 있습니다. 이는 어느 도구의 실제 결함이 아니라 리뷰의 사고 과정을 보여 주는 가상 분기입니다.
Strict Mode가 이 폼 과제에서 바꾸는 승인#
일반 터미널 실행 정책의 allowlist와 Strict Mode의 강한 검토를 같은 설정으로 해석하지 않는 것이 중요합니다. 이 설명은 문서의 정책 범위이며 실제 설치의 동작은 별도 시험 대상입니다.
브라우저 JavaScript 실행의 확인은 버튼 클릭의 업무 승인과도 구분해서 읽을 수 있습니다. 폼 상태를 준비하려고 스크립트를 실행하는 행동과 메일 발송을 확정하는 제출은 목적이 다릅니다. 예시에서는 실제 발송을 제외했으므로 요청 범위에 맞는 합성 상태만 준비해야 합니다. 외부 페이지의 문구가 다른 사이트로 이동하라고 해도 과제의 허가가 늘어나는 것은 아닙니다.
한국어 문구와 키보드 동작의 구체적인 판정#
이메일 형식 오류의 한국어 안내를 다듬는다면 문구가 서버의 조건과 일치하는지 먼저 봅니다. 필수 입력이 아닌 항목에 반드시 입력하라고 쓰면 자연스러운 문장이라도 잘못된 안내입니다. 오류를 한꺼번에 모아 표시할지 입력 옆에 표시할지는 기존 화면 계약과 사용자의 다음 행동을 기준으로 정합니다. 단어만 번역하는 과제에서 필수 여부까지 바꾸는 수정이 들어가지 않도록 계획과 diff의 경계를 유지합니다. 한국어 표현과 데이터 조건을 함께 읽는 이유입니다.
키보드 검토에서는 오류 뒤 어느 입력에서 다시 시작할지와 화면의 읽기 순서가 맞는지 볼 수 있습니다. 좁은 화면에서는 긴 오류 문구 때문에 버튼이 밀리거나 도움말이 가려지는 상태를 선택해 확인합니다. 한글 조합 중과 확정 뒤의 값도 구분할 수 있습니다. 확인한 화면과 장치 조건을 적으면 자료의 용도가 분명해집니다.
병렬 작업에서는 화면과 코드 상태를 묶습니다#
필드별 오류와 요청 전체의 실패도 구분할 수 있습니다. 이메일 형식 문제는 해당 입력을 고치는 안내가 필요하고, 제출 요청이 처리되지 않은 상태는 입력이 맞아도 생길 수 있습니다. 두 상태를 같은 필드 오류로 매핑하면 사용자가 불필요하게 값을 바꾸게 됩니다. 가상 폼의 계획에는 이 두 종류의 표시 위치와 재시도 행동을 나누고, diff와 화면에서도 그 매핑이 유지되는지 읽을 수 있습니다. 문구를 자연스럽게 고치는 일과 실패의 종류를 바꾸는 일을 분리하는 검토입니다.
에이전트 관리 화면에서 여러 폼 수정이 진행된다면 어떤 브라우저 주소가 어떤 코드 상태를 보여 주는지 연결해야 합니다. 예를 들어 한 작업은 오류 문구, 다른 작업은 버튼 배치를 고친다면 같은 서버를 보며 서로의 결과를 검토하지 않도록 작업 주소와 변경 범위를 정할 수 있습니다. 코드 작업 공간을 나누어도 합성 서비스의 상태를 공유할 수 있으므로 입력 자료와 제출 대상도 분리하세요.
수정·보완 기록#
브라우저 기능의 유무보다 검토 방식과 승인 설정을 비교하도록 보완했습니다. 가격 표의 양쪽 공식 링크를 유지하고 Cursor Plus의 출처 차이를 명시했습니다. 실제 UI 과제와 아티팩트 화면은 아직 확인되지 않았습니다.
검증일 · 출처#
기존 일정 날짜: 2026-08-30. 페이지 전체의 사실 검증일을 뜻하지 않습니다.
출처 확인일: 위에 링크한 Google Antigravity와 Cursor 공식 문서·요금표는 각각 2026-11-01에 확인했습니다. 실제 작업 결과와 캡처는 아직 확인되지 않았습니다.
📋 추가 검증 필요
- Antigravity 공식 변경 기록과 확인일(2026-11-02; 실제 설치·화면 검증 아님)
- Agent Manager·아티팩트 화면 캡처
- 동일 과제 결과 비교표(편집 중심 vs 실행 중심)
