안티그래비티(Antigravity) 대안: 에이전트 IDE를 쓰지 않을 때의 선택

30초 결론: Antigravity를 떠나야 하는 사람과 남아야 하는 사람#

Agent Manager와 아티팩트를 자주 쓴다면 Antigravity IDE를 계속 쓸 이유가 있습니다. 터미널이 편하다면 Antigravity에도 CLI가 있으므로 Mirr Code와 함께 작업 방식, 가격과 한도를 비교하세요.

비교를 시작하기 전에 합성 데이터만 담긴 저장소를 쓰고 비밀번호·API 키·실제 고객 데이터는 제외하세요. Antigravity는 개인과 조직 계정의 조건이 다르므로, 사용할 계정 유형의 Antigravity 약관과 Google 개인정보처리방침을 먼저 확인하세요. 조직 계정이면 적용 계약도 함께 확인하세요.

한눈에 보기: Antigravity와 미르 코드#

공식 출처 확인: 2026-11-01. 표는 제공 방식과 조건을 비교하며 성능 순위가 아닙니다.

어디가 더 나은가: Antigravity가 강한 경우 / 미르 코드가 맞는 경우 / 미르 코드가 아직 부족한 점#

Antigravity는 IDE의 시각적 결과물과 CLI를 함께 선택할 수 있습니다. Mirr Code의 터미널 중심 흐름이 맞는지는 직접 확인해야 하며, IDE의 Agent Manager와 아티팩트를 같은 방식으로 제공한다고 가정하면 안 됩니다. 양쪽의 완성도를 비교한 동일 과제 자료도 아직 없습니다.

같은 과제를 비교할 때 확인할 점#

작은 버그 수정과 테스트 추가를 같은 출발점에서 요청하고, 계획·수정 범위·diff·테스트 결과를 비교해 보세요. 이 페이지에는 아직 양쪽의 실제 실행 기록, diff 또는 테스트 출력이 없습니다.

가격: 구독료와 모델 사용료#

2026-11-01 기준 금액과 무료 이용 조건은 위 표를 참고하세요. Antigravity의 월 0달러 표시와 Mirr 공개 요금 조회 금액 모두 적용 지역과 세금 포함 여부는 확인되지 않았습니다. Antigravity 유료 플랜의 구독료와 초과 사용은 공식 가격과 플랜 안내에서 확인하세요. Mirr 금액을 플랜명이나 혜택에 연결해 단정하지 않았습니다. 요금 페이지에서 최신 금액과 결제 조건, 한도를 확인하세요.

옮기는 방법: 설치, 규칙, MCP, 첫 작업#

1. 비교 기록은 두 도구에서 각각 따로 저장하고, 아티팩트 화면과 터미널 기록을 같은 과제 번호로 묶어 두세요.
2. 자동 이전은 확인되지 않았으므로 옮긴 뒤 승인 기록을 직접 검토하세요.

터미널 전환이 아니라 다른 IDE 검토 방식이 필요한 경우에는 다음 후보도 있습니다. 문서에서 기능이 보인다는 이유로 검토 결과나 안전성이 같다고 볼 수는 없습니다.

어느 후보를 고르든 작은 합성 UI 과제에서 파일 diff, 브라우저 확인 내용과 테스트를 따로 남기세요. 이 표는 그 실행 기록이나 비교 점수를 제공하지 않습니다.

출처 확인(2026-11-03): Antigravity MCP 문서는 Antigravity가 Model Context Protocol을 지원한다고 설명하며, 스키마나 로그·API 스펙을 프롬프트에 복사하는 대신 구조화된 컨텍스트를 직접 가져오거나 필요한 행동을 실행하는 방식으로 사용된다고 안내합니다. 이 문서는 App·CLI·IDE 전 제품에 걸쳐 MCP 서버를 연결하고 설정하는 방법을 다루므로, IDE의 아티팩트나 Agent Manager와 같은 기능을 전제로 읽어서는 안 됩니다. Mirr를 병행할 때는 이 MCP 연결의 서버·권한·실행 조건을 새 환경에서 다시 기록하는 항목으로 남기면, 이전 목록에서 문서 비교와 실행 확인을 구분할 수 있습니다. 이 표준은 에이전트가 즉각적인 작업 공간을 넘어 지역 개발 도구에 안전하게 연결하는 다리 역할을 한다고 설명합니다.

안티그래비티를 떠나는 것과 IDE를 떠나는 것#

안티그래비티 대안을 찾는 이유가 화면 때문이라면 제품을 바꾸기 전에 작업면을 나눠 보세요. 에디터에서 파일을 찾는 일, 에이전트의 진행을 보는 일과 결과 아티팩트를 검토하는 일은 서로 다릅니다. 터미널만 필요한 사람과 시각적 검토가 필요한 사람이 같은 선택을 할 이유는 없습니다. 아래는 대안을 고르는 제안이며 동일 과제의 결과나 작업 시간을 측정한 내용은 아닙니다.

최근 과제에서 실제로 열어 본 화면을 적어 보세요. 계획을 확인했는지, 여러 작업의 상태를 봤는지, 결과 이미지를 검토했는지와 코드 diff만 읽었는지를 나눕니다. 사용하지 않는 UI를 필수 기능으로 계산할 필요는 없습니다. 반대로 화면에서 승인하던 중요한 판단이 있다면 터미널 전환 뒤 누가 어디에서 그 판단을 할지 정하세요.

Antigravity에도 CLI가 있으므로 터미널을 쓰고 싶다는 요구만으로 다른 제품으로 옮길 필요가 있다고 단정하지 않습니다. 기존 계정과 현재 기능을 유지한 채 작업면을 바꾸는 안과 Mirr Code 같은 별도 후보를 시험하는 안을 비교할 수 있습니다. 어느 쪽이 현재 계정에서 가능한지와 조건은 공식 문서에서 확인하세요. 제품에 CLI가 있다는 사실은 IDE와 모든 기능이 같다는 뜻이 아닙니다.

Agent Manager가 필요한 작업을 적기#

여러 작업의 진행을 시각적으로 보는 흐름을 실제로 쓴다면 그 목적을 구체적으로 적습니다. 어떤 과제가 대기 중인지 찾는 일인지, 사람이 승인할 항목을 확인하는 일인지, 결과를 다른 사람에게 전달하는 일인지에 따라 대체할 방법이 달라집니다. 화면의 이름을 새 도구에서 찾는 것보다 원래 하던 판단을 계속할 수 있는지 보는 편이 좋습니다.

진행 상태의 표시와 작업의 실제 완료도 구분하세요. 도구가 완료라고 표시해도 원래 수용 기준과 파일 diff, 테스트가 맞는지 사람의 검토가 필요합니다. 여러 작업이 동시에 움직였다면 어느 변경이 어느 과제에서 나왔는지 추적할 수 있어야 합니다. 상태 목록이 보기 좋다는 이유로 결과의 정확성을 높게 평가하지 않고 필요한 기록이 남는지 따로 봅니다.

터미널로 옮긴다면 사람이 확인할 요약 형식을 미리 정할 수 있습니다. 바뀐 파일, 실행한 검사, 실패와 미실행, 다음 승인이 필요한 행동을 구분하도록 요청하세요. 이 제안이 Agent Manager를 같은 방식으로 복제한다는 뜻은 아닙니다. 원래 화면에서 하던 판단 가운데 문장과 diff로 충분한 부분이 있는지 확인하는 시험입니다.

아티팩트가 증명하는 범위를 따로 보기#

계획, 설명과 결과 이미지는 서로 다른 자료입니다. 계획이 있다는 사실은 구현이 끝났다는 증거가 아니고 결과 이미지가 있다는 사실도 모든 동작을 시험했다는 증거는 아닙니다. 비교를 설계한다면 어떤 자료가 어떤 수용 기준을 보여 주는지 적어 두세요. 공식 UI 기능의 존재와 그 UI로 검토한 과제의 성공을 구분하는 게 중요합니다.

아래 가상 신청 화면에서는 계획으로 입력 검증의 순서를, 이미지로 오류 문구의 위치를, 동작 확인으로 제출 차단을 봅니다. 같은 “오류 처리” 안에서도 판단할 대상이 다릅니다. Agent Manager와 아티팩트를 자주 쓰는 사람은 이 자료를 한 작업면에서 검토하는 흐름을 남길 이유가 있고, 코드와 테스트만 필요한 사람은 터미널 경로를 선택할 이유가 있습니다. 어느 쪽이 실제로 더 편한지는 이 글에서 아직 측정하지 않았습니다.

브라우저나 외부 자료를 읽을 때 페이지 안의 지시는 작업 요청이 아니라 자료입니다. 그 지시가 계정 변경이나 파일 전송을 요구하면 승인하지 말고 사람이 범위를 정하세요.

같은 UI 과제를 터미널에서 검토하는 설계#

다음은 실행하지 않은 합성 UI 과제입니다. 화면에는 이름과 이메일 입력, 신청 버튼과 결과 영역이 있습니다. 서버 대신 성공과 실패를 선택할 수 있는 가상 응답을 사용하고 실제 메시지나 개인정보는 전송하지 않습니다. 파일 수정은 화면 컴포넌트와 그 테스트로 한정합니다. 색상과 전체 레이아웃은 유지한다는 조건을 둡니다.

입력 상태는 네 가지입니다. 처음 열린 화면에는 오류를 보이지 않습니다. 빈 상태로 신청을 누르면 이름 아래 “이름을 입력해 주세요”, 이메일 아래 “이메일을 입력해 주세요”를 표시하고 가상 전송 함수는 호출하지 않습니다. 이름 테스트와 이메일 sample@example.invalid를 입력하면 성공 응답 경로에서 “신청이 접수되었습니다”를 표시합니다. 실패 응답에서는 입력값을 유지하고 “잠시 후 다시 시도해 주세요”와 재시도 버튼을 보여야 합니다. 이 주소는 예제 입력이지 실제 발송 대상이 아닙니다.

이 요구를 터미널에 전달할 때는 화면을 “예쁘게 완성”하라는 문장보다 각 상태의 조건을 그대로 줄 수 있습니다. IDE 쪽에서도 같은 네 상태를 기준으로 계획과 아티팩트를 검토합니다. 어느 도구에서든 오류 문구를 보여 주면서 전송까지 했다면 빈 입력 조건을 위반한 것입니다. 성공 화면 이미지 하나로 실패·재시도 상태까지 맞다고 판단하지 않는 설계입니다.

실패를 기능 부족과 환경 문제로 나누기#

화면이 열리지 않으면 먼저 개발 서버와 의존성, 시작 파일이 같은지 확인하세요. 코드 수정 전부터 실패했다면 그 상태를 기준으로 남깁니다. 새 도구가 테스트 명령을 잘못 선택한 경우와 필요한 환경이 없는 경우도 분리합니다. 환경 문제를 일반적인 제품 품질로 평가하지 않으면서도 작업을 끝내기 위해 사람이 한 일은 숨기지 않는 편이 좋습니다.

계획과 실제 변경이 다르면 바뀐 이유를 요청합니다. 요구사항이 중간에 달라졌는지, 구현 중 제약을 발견했는지와 에이전트가 임의로 범위를 줄였는지 살펴보세요. 사람이 범위를 줄이기로 결정했다면 그 결정 이후의 과제 결과로 기록합니다. 처음 요구한 모든 기능을 끝낸 것처럼 표현하면 대안 선택에 필요한 근거가 왜곡됩니다.

무료·미리보기 조건을 업무 약속으로 바꾸지 않기#

공개 가격에 무료가 표시돼도 특정 과제를 끝낼 사용량과 일정이 보장된 것은 아닙니다. 현재 계정 자격과 모델, 한도의 주기와 추가 사용 조건을 확인하세요. 무료 범위를 넘어서는 업무를 계획한다면 실제 사용할 계정과 결제 조건을 담당자가 확인하세요.

기존 Google AI 구독이 있는 경우에도 코딩 작업에 어떤 조건이 적용되는지 따로 봅니다. 이미 내는 비용과 새로 생기는 비용을 구분하고 다른 용도로 유지할 구독을 전부 코딩 비용으로 배분하지 마세요. 이 글은 구독 사용 비율이나 환율, 세금을 가정하지 않습니다. 실제 내역이 없는 절감액을 표에 넣는 대신 필요한 관찰을 정리할 수 있습니다.

한도에 도달하면 지금까지 만든 파일과 남은 검사를 보존합니다. 다른 경로로 계속했다면 계정과 모델이 바뀌었다는 사실을 남기세요. 여러 조건을 섞어 완료한 작업을 무료 경로 하나에서 끝낸 결과로 읽으면 안 됩니다. 제한이 없는 시험을 승인받은 경우에도 외부 쓰기와 데이터 범위는 별도이며 업무 목적을 벗어난 행동까지 허용되는 것은 아닙니다.

아티팩트 없이도 남겨야 할 검토 자료#

앞의 화면을 코드 중심으로 검토한다면 테스트의 기대 조건을 먼저 채울 수 있습니다. 빈 제출에서는 가상 전송 호출 수 0, 유효 입력의 성공에서는 성공 문구, 실패에서는 입력값 보존과 재시도 버튼이 조건입니다. “오류 안내 추가”라는 하나의 테스트 이름만 두면 이 차이를 놓칠 수 있습니다. 여기의 호출 수는 가상 과제의 기대값이며 실제 관찰한 결과가 아닙니다.

이미지로 볼 조건도 채워 둡니다. 이름 오류는 이름 입력 바로 아래, 이메일 오류는 이메일 아래에 있어야 하며 두 오류가 한 줄의 일반 경고로 합쳐지면 요구와 다릅니다. 실패 상태에서 버튼과 문구가 가려지지 않아야 합니다. 키보드·보조 기술 검토는 실제로 수행한 범위만 말할 수 있으며 이 예제는 그 검토 결과를 제공하지 않습니다. 동작 조건과 시각 조건을 서로 대신하지 않는 것이 선택의 기준입니다.

계획과 결과가 어긋나는 경우#

재시도에는 한 가지 상태를 더 정할 수 있습니다. 가상 전송이 처리 중일 때 신청 버튼을 연속으로 눌러도 중복 요청을 만들지 않는다는 조건입니다. 실패 뒤의 재시도는 허용하지만 처리 중 재클릭은 같은 행동이 아닙니다. 기대 화면은 처리 중 표시와 중복 제출 방지이며, 성공한 뒤에는 실패 문구가 남지 않아야 합니다. 이 조건도 실행 결과가 아니라 앞의 합성 화면에 추가한 수용 기준입니다.

이렇게 조건을 채우면 “버튼을 눌러 보았다”는 확인보다 선택할 것이 분명합니다. 계획 아티팩트에는 초기·오류·처리 중·실패·성공 상태의 관계가 필요하고, 코드 검토에는 전송 함수가 언제 호출되는지가 필요합니다. 디자인 담당자가 처리 중 표시를 바꾸려는 것과 개발자가 중복 호출을 막으려는 것은 서로 다른 수정입니다. 시각적 작업면을 유지할 이유가 있는지 바로 이 접점에서 판단할 수 있습니다.

가상 계획이 “문구만 추가한다”인데 빈 제출에서도 전송되는 원인이 기존 코드에 있다면 문구만으로 수용 조건을 만족할 수 없습니다. 선택 A는 검증 분기를 함께 고치는 안이고 선택 B는 과제를 단순 문구 수정으로 줄이는 안입니다. 원래 요구가 빈 전송 차단이라면 A가 맞고, B를 택하려면 요구 자체가 바뀝니다. 멋진 결과 이미지는 이 선택을 대신하지 못합니다.

다른 불일치도 있습니다. 실패 응답에서 성공 문구를 그대로 보여 주면 상태 모델이 잘못된 것이고, 실패 문구는 맞지만 입력을 모두 지우면 값 보존 요구를 놓친 것입니다. 계획 아티팩트에는 상태별 출력이 있어야 이런 차이를 구현 전에 볼 수 있습니다. 이 예에서 아티팩트가 필요한 이유는 자료를 많이 남기기 위해서가 아니라 서로 다른 실패를 다른 수정으로 연결하기 위해서입니다.

작업 관리 화면이 유용한 세 가지 상황#

다음은 가상의 작업 상황입니다. 여러 과제를 동시에 맡기는 사람은 어느 과제가 사람의 결정을 기다리는지 빨리 찾고 싶을 수 있습니다. 이때 작업 목록의 목적은 개수를 많이 보여 주는 것이 아니라 필요한 판단을 놓치지 않게 하는 것입니다. 터미널 후보를 고른다면 같은 정보를 어떤 방식으로 볼지 정하고 실제 과제로 확인할 수 있습니다.

첫 상황은 디자인 담당자와 개발자가 앞의 네 상태를 함께 고르는 작업입니다. 디자인 담당자는 오류 위치를, 개발자는 전송 차단과 상태 전환을 봅니다. 시각적 자료를 한곳에서 검토하는 흐름을 자주 쓴다면 IDE의 아티팩트 작업면을 유지할 이유가 있습니다. 코드만으로 두 사람의 판단이 충분한 팀이라면 터미널에서 구현하고 별도 화면을 보는 안도 가능합니다.

둘째 상황은 신청 화면과 결과 페이지를 따로 작업하는 경우입니다. 두 과제가 같은 성공 문구와 응답 상태를 공유하므로 동시에 바꾸면 접점이 생깁니다. 가상 팀은 성공 응답 계약을 먼저 고정하고 화면별 구현을 나눌 수 있습니다. 여러 작업의 상태를 보는 UI가 필요한지는 이 의존 관계를 관리하는 방식에 달려 있습니다. 작업 개수가 많아 보인다는 이유만으로 생산성을 높게 평가하지는 않습니다.

셋째 상황은 장애 후 재시도 UX를 지원 담당자에게 넘기는 일입니다. 지원 담당자는 전체 코드보다 실패 문구와 입력 보존, 재시도 후 어느 상태로 돌아가는지를 알아야 합니다. 이때 실패 화면과 동작 조건을 묶어 전달하면 업무에 맞는 자료가 됩니다. 반대로 코드 조사만 하는 개발자에게 같은 화면 묶음은 필수 산출물이 아닐 수 있습니다. 사용 목적이 다른 사람이 같은 대안을 고를 필요는 없습니다.

대안 비교의 범위를 고정하는 질문#

이 가상 화면은 빈 입력을 검증하지만 이메일의 실제 소유자를 확인하거나 메일을 보내지는 않습니다. 주소가 비어 있지 않은지와 도메인이 실제로 응답하는지는 다른 업무이므로 이번 과제에 외부 조회를 추가하지 않는 안입니다.

이 표는 두 작업면의 동등성을 입증하는 표가 아닙니다. 독자가 어떤 업무를 시험할지 고르는 질문입니다. 현재 버전에서 필요한 기능과 계정 조건을 확인하고 같은 합성 과제에 적용해야 합니다. 한쪽에 기능이 없다고 주장하려면 실제 공식 범위와 버전을 확인해야 하며 이 글의 미확인을 부재로 바꿔 쓰지 않습니다.

터미널 전환이 맞지 않을 수 있는 경우#

결과 이미지를 함께 보며 승인하는 팀은 그 협업 방식을 잃는 비용을 확인하세요. 터미널만으로 같은 검토가 가능하다고 가정하지 말고 필요한 자료를 어디에서 공유할지 정하세요. 다른 프로그램을 계속 열어야 한다면 그 작업도 새 흐름의 일부입니다. 응답이 짧고 빨랐다는 이유로 전체 검토가 쉬워졌다고 판단하지 않는 편이 좋습니다.

현재 Agent Manager와 아티팩트를 업무 기록으로 활용한다면 보존과 검색 경로도 확인하세요. 실제 계약과 제품 문서에서 확인하지 않은 보관 기간이나 내보내기 기능을 임의로 약속하지 않습니다. 필요한 자료가 무엇인지 목록을 만들고 담당자가 현재 지원 범위를 확인하게 하세요. 새 도구에 로그가 남는다는 사실만으로 같은 기록 관리가 된다고 볼 수 없습니다.

반대로 시각적 기능을 거의 쓰지 않는 사람은 제품 자체를 바꾸기 전에 CLI 경로를 살펴볼 수 있습니다. 기존 계정과 조건을 유지한 안과 새 구독을 쓰는 안을 분리해 비교하세요. 불필요한 전면 교체를 피하면서 실제 필요한 작업면을 고르는 것이 목적입니다.

이 비교의 한계#

이 페이지의 한계는 실제 Agent Manager·아티팩트 화면과 같은 과제의 터미널 결과가 아직 없다는 것입니다. 위 화면과 호출 수는 모두 제안한 수용 조건입니다. 실제 계정의 접근·잔여량·초과 사용이나 접근성 검사를 수행한 결과도 아닙니다. 이 조건을 한곳에 두고, 대안 판단은 이후의 구체적인 상태별 선택으로 읽으면 됩니다.

떠나기 전 남길 검토 기록#

앞의 디자인·개발 협업 팀의 가상 결론은 “시각적 검토가 필요하므로 IDE를 남기고, 터미널에는 파서 같은 비시각적 조사만 맡긴다”입니다. 반대로 혼자 로컬 함수를 고치는 사람의 결론은 “Agent Manager의 시각적 작업 관리는 필수가 아니므로 Antigravity CLI와 Mirr를 먼저 살펴본다”가 될 수 있습니다. 둘 다 제품 전체를 떠나는 결정과는 다릅니다.

구독 변경은 또 다른 축입니다. 기존 Google AI 구독을 다른 용도로 계속 쓴다면 새 터미널 비용을 구독 절감으로 계산할 수 없습니다. 무료 개인 조건과 주간 한도는 앞의 공식 가격 기록으로 남기고, 특정 과제를 무료로 끝낸 횟수나 시간은 만들지 않습니다. 필요한 작업면을 고른 뒤 그 작업면의 현재 계정 조건을 검토하는 순서입니다.

전달 자료를 읽는 순서#

가상 지원 담당자에게는 먼저 실패 입력 상태를 보여 주고, 재시도 버튼을 누른 뒤 입력이 유지되는지, 성공 응답에서는 어느 문구로 바뀌는지 설명합니다. 개발자에게는 같은 자료에 상태 분기와 단위 검사를 연결할 수 있습니다. 같은 자료를 읽더라도 필요한 순서가 다른 이유입니다. 공개 데모를 만든다면 이 예처럼 합성 이름과 주소만 쓰고 실제 계정·토큰·개인정보는 제외해야 합니다.

별도 출처 확인 — 2026-11-03: 공개 가격은 개인용 $0/month와 기본 주간 제한을 표시하고 플랜 문서는 요금제별 한도와 변경 가능성을 안내합니다. 실제 계정의 접근과 잔여량, 초과 사용을 시험한 결과는 아니며 이 조건을 영구 제공 약속으로 읽지 않습니다.

화면 증거와 터미널 증거를 연결하는 방법#

이 합성 과제의 예상 연결표는 각 자료가 다른 판단을 맡도록 구성합니다. 실제 화면이나 출력을 채운 결과표는 아닙니다.

IDE의 시각적 검토를 남길지, 터미널에서 코드와 테스트를 다룬 뒤 별도 화면을 볼지 이 표로 선택할 수 있습니다. 아티팩트 UI를 쓰지 않아도 상태 모델이 없어지는 것은 아니며, UI를 쓴다고 동작 검토가 자동으로 끝나는 것도 아닙니다. 원래의 질문은 그 판단을 어떤 작업면에서 할지입니다. 이 글은 그 선택을 구체화했고 실제 Agent Manager 캡처와 같은 과제의 결과는 미확인으로 유지합니다.

개인 무료 조건과 팀 조건을 나눠 읽기#

플랜 문서는 개인 계정과 Gemini Enterprise 팀 조건을 나누고, Google AI 플랜별로 모델과 한도가 다르다고 설명합니다. Pro와 Ultra에서는 기본 한도 이후 구매 AI 크레딧을 쓰는 설정을 Never와 Always로 구분합니다. 세 가지 조건을 하나의 "무료 여부"로 합치지 말고 아래처럼 나눠 적으세요.

이 표는 공식 플랜 설명을 옮긴 것이며, 실제 계정에서 설정을 확인하거나 한도를 소진해 본 결과가 아닙니다. 무료 범위에서 끝난 작업은 과제별 완료 기록으로 따로 남기세요.

IDE 엄격 모드에서 확인 요청이 나오는 행동#

IDE 설정 문서의 엄격 모드(Strict Mode) 항목은 터미널 명령을 allowlist와 관계없이 확인 대상으로 두고, 브라우저 JavaScript와 아티팩트 계획에 따른 행동을 Request Review로 둔다고 설명합니다. 이는 IDE 설정 문서의 설명이며, App이나 CLI 전체에서 같은 보호가 적용된다는 뜻이 아닙니다. 아티팩트 검토와 승인 흐름을 비교할 때는 어느 작업면의 설정인지 항목마다 적으세요.

수정·보완 기록#

출처 범위: 개인 무료 표시는 주간 한도와 함께 읽어 보세요. Agent Manager·아티팩트의 실제 화면과 터미널 결과 비교는 이 페이지에서 아직 확인하지 않았습니다.

검증일 · 출처 · 관련 페이지#

2026-11-01 확인: Antigravity 제품 안내, 공식 가격, 플랜과 한도, Mirr 작업 모드. 릴리스별 변경 사항과 실제 화면 동작은 별도 검토가 필요합니다. 동일 과제의 터미널 실행 기록과 결과 비교는 아직 없습니다.

출처 확인(2026-11-02): Antigravity 공식 변경 기록은 App·CLI·IDE 등 제품별 기록을 구분하고, 새 버전이 순차 배포돼 도달까지 며칠이 걸릴 수 있다고 안내합니다. 이 기록만으로 현재 계정의 버전이나 Agent Manager·아티팩트 화면을 확인했다고 볼 수는 없습니다.

그래서 Mirr Code는?#

Mirr Code는 한국어 중심의 터미널 코딩 에이전트입니다. 작업 모드, 모델, 요금과 결제를 확인하세요. 시각적 IDE 관리와 터미널을 함께 쓰고 싶다면 Antigravity도 살펴보세요.

관련#

• 작업 모드