Antigravity 2.0을 사용하여 오픈 소스 코드베이스를 탐색하고 더 나은 기술적 결정을 내리는 방법

이 글은 Google I/O Writing Challenge를 위한 제출물입니다.

Hook: 오픈 소스 기여 방식을 바꾼 도구

솔직히 말씀드리겠습니다. 지난 2년 동안 누군가 저에게 어떤 AI 코딩 도구를 사용하느냐고 물을 때마다, 제 대답은 자동적이었습니다. Claude Code를 쓸지 Codex를 쓸지, 둘 중 하나를 고르라는 식이었죠. Google은 대화 주제에 포함조차 되지 않았습니다.

그러다 Google I/O 2026이 열렸습니다.

약 24시간 만에 Google은 20개 이상의 도구를 공개했고, 그중 하나가 스크롤을 멈추게 했습니다. 바로 Antigravity 2.0입니다. 이는 Gemini 3.5 Flash를 기반으로 구축된 독립형 데스크톱 에이전트 오케스트레이션 (Agent Orchestration) 플랫폼으로, 시작은 무료이며 시니어 엔지니어가 팀에게 업무를 위임하는 방식처럼 병렬 AI 서브 에이전트 (Sub-agents)를 생성하도록 설계되었습니다.

저는 단순히 그것에 대해 읽고 싶지만은 않았습니다. 실제 무언가에 적용해 보고 싶었습니다. 그래서 저는 오픈 소스 기여자로서 끊임없이 마주치는 문제, 즉 익숙하지 않은 코드베이스에 들어가서 무엇인가를 건드리기 전에 이미 무엇이 있는지 파악하려고 노력하는 과정에 이 도구를 적용해 보았습니다.

현재 저는 FOSSASIA의 WordPress 플러그인이자 Eventyay 이벤트 플랫폼과 통합되는 WPFAevent를 리뷰하는 데 이 도구를 사용하고 있습니다. 이는 14개의 오픈 이슈(Open issues), 17개의 풀 리퀘스트(Pull requests), PHP + JavaScript + CSS로 구성된 실제 저장소(Repo)이며, Antigravity가 보통 기여 세션의 첫 한 시간을 잡아먹는 컨텍스트 수집 (Context-gathering) 작업을 얼마나 잘 처리하는지 테스트하기에 좋은 환경을 제공했습니다.

이 글은 제가 이 도구를 어떻게 사용하는지, 무엇이 진정으로 인상 깊었는지, 어디에서 마찰을 겪었는지, 그리고 오픈 소스에 기여하려는 모든 개발자가 뛰어들기 전에 알아야 할 사항들에 대한 전체적인 가이드입니다.

Antigravity 2.0이란 무엇인가?

Antigravity 2.0은 Google의 새로운 AI 에이전트 오케스트레이션 (Agent Orchestration)을 위한 독립형 데스크톱 앱입니다. 1년도 채 되지 전, Google은 Agent Manager가 내장된 풀 코드 에디터인 Antigravity IDE를 출시했습니다. 그것은 강력했지만 위압적이었습니다. Antigravity 2.0은 그 모든 것을 완전히 걷어냈습니다. 남은 것은 누구나 열어서 즉시 사용할 수 있는 깔끔한 채팅 인터페이스이며, 복잡한 작업을 자동으로 조정하는 에이전트(Agents)들이 이를 뒷받침합니다.

핵심 키워드는 에이전트(agents) — 복수형이며, 병렬적이고, 자율적이라는 점입니다.

Claude Code(이 글을 쓰는 시점 기준)와 같은 도구는 개발자가 서브 에이전트 워크플로우 (Sub-agent workflows)를 수동으로 구성해야 하는 반면, Antigravity 2.0은 하나의 작업이 여러 개의 특화된 에이전트를 동시에 생성할 수 있고, 또 그래야만 한다는 아이디어를 바탕으로 처음부터 설계되었습니다. 코드 분석 에이전트, 문서를 교차 참조하는 리서치 에이전트, 브라우저 테스트를 실행하는 QA 에이전트가 모두 동시에 작동하며 사용자에게 보고하고, 필요한 경우에만 승인을 요청합니다.

Google I/O에서 팀은 무대 위에서 12시간 동안 Antigravity 2.0을 연속으로 실행했습니다. 93개의 서브 에이전트가 병렬로 작동하며 실제로 작동하는 운영체제를 만들어냈습니다. 이것이 바로 이 도구가 작동하도록 설계된 규모입니다.

Google 생태계에서의 위치: Antigravity는 설치 가능한 스킬(Skills)과 플러그인(Plugins) — Chrome DevTools, 현대적 웹 가이드 등 — 을 통해 Google 제품에 직접 연결됩니다. 또한 전체 스택은 Gemini 3.5 Flash에서 실행되며, 이 모델은 초당 800 토큰에 가까운 속도로 코드를 생성할 수 있는 것으로 알려져 있습니다. 이러한 원시적인 속도는 실제 반복 작업 (Iteration)의 느낌을 완전히 바꿔 놓습니다.

나의 직접적인 실험: WPFAevent 리뷰

환경 및 사전 요구 사항

OS: Linux Mint 22.3 - Cinnamon 64-bit
Antigravity 버전: 2.0.6 (Manual Tarball Release)
Google 계정: 로그인에 필요
리포지토리 (Repo): fossasia/WPFAevent — 로컬에 클론됨
이전 Antigravity IDE 경험: 필요 없음 (단, 기존 IDE 사용자는 원활한 마이그레이션 경로를 제공받음)

1단계: 설치 및 온보딩 (Onboarding)

antigravity.google로 이동하여 사용 중인 플랫폼 — Apple Silicon, Intel Mac, Windows (두 가지 설치 옵션 제공), 또는 Linux용 설치 프로그램을 받으세요.

# macOS: Applications 폴더로 드래그한 후 Spotlight에서 실행
# Windows: 설치 프로그램을 직접 실행
# Linux: 사이트에서 빌드 파일 제공

Linux Mint의 경우, (여전히 이전 1.x 안정 브랜치를 기본값으로 사용하는) 표준 apt 패키지 관리자를 사용하는 대신, 압축 패키지를 수동으로 다운로드하여 시스템의 선택적 애플리케이션 디렉토리(optional application directory)에 직접 압축을 해제합니다.

# 패키지를 시스템 애플리케이션 디렉토리에 압축 해제
sudo tar -xzf Antigravity.tar.gz -C /opt/

Linux 데스크톱 바로가기 문제 해결 (Troubleshooting)

처음에는 내부 패키지 자산(assets)을 가리키는 .desktop 파일 설정을 사용하여 표준 터미널 기반 데스크톱 엔트리(desktop entry)를 생성하려고 시도했습니다:

# 참고: 이 자동화 스크립트 방식은 아이콘/바로가기를 고정(pinning)하는 데 네이티브하게 작동하지 않았습니다
cat << 'EOF' > ~/.local/share/applications/antigravity-ide.desktop
[Desktop Entry]
...

빌드 구조가 자산 라우팅(asset routing)을 다르게 처리하기 때문에 (그 결과 일반적인 톱니바퀴 아이콘이 나타나거나 Mint 메뉴에서 바로가기가 완전히 사라짐), 터미널에서 바이너리 파일을 직접 호출하여 핵심 애플리케이션을 수동으로 확인했습니다:

/opt/Antigravity/antigravity

최종 시각적 아이콘 솔루션

IDE를 실제 브랜딩이 적용된 상태로 Linux Mint 애플리케이션 메뉴에 성공적으로 매핑하기 위해, 텍스트 설정을 완전히 건너뛰고 Cinnamon 데스크톱 환경(Cinnamon Desktop environment) 도구를 사용하여 수동으로 구성했습니다:

Antigravity Press Asset Kit에서 공식 브랜드 로고를 직접 다운로드합니다.
Linux Mint 메뉴 버튼(왼쪽 하단 모서리)을 마우스 오른쪽 버튼으로 클릭 -> **Configure (설정)**를 클릭합니다.
Menu (메뉴) 탭으로 이동하여 Open the menu editor (메뉴 편집기 열기)를 클릭합니다.
지정된 개발 카테고리 아래에서 Antigravity IDE 항목을 찾아 클릭한 후, Properties (속성)를 엽니다.
속성 창 왼쪽의 아이콘 타일을 클릭하고, 다운로드한 프레스 에셋 이미지로 찾아가서 Save (저장)를 누릅니다.

앱을 열고 Google 계정으로 로그인하면 짧은 온보딩 (onboarding) 흐름이 시작됩니다.

온보딩 과정 중에 "Build with Google" 페이지가 나타납니다. 이곳은 **기술 (skills) 및 플러그인 (plugins)**을 설치하는 곳입니다. 이는 본질적으로 에이전트 (agents)에게 특정 도구에 대한 컨텍스트 (context)를 제공하는 통합 기능입니다.

저는 다음을 설치했습니다:

Modern Web Guidance — 에이전트가 웹 개발 패턴 및 모범 사례 (best practices)에 대해 추론할 수 있도록 돕습니다.
Chrome DevTools — 에이전트가 브라우저와 상호작용하고 검사할 수 있는 능력을 부여합니다.

Antigravity IDE에서 마이그레이션 (migrating)하는 경우, "Keep Antigravity IDE" 체크박스를 선택된 상태로 유지하세요. 기존 설정이 깔끔하게 그대로 유지됩니다.

2단계: 프로젝트 생성하기

Antigravity 2.0은 **프로젝트 중심 (project-centric)**입니다. 프로젝트란 단순히 AI가 직접 읽고 쓸 수 있는 로컬 머신의 폴더를 의미합니다.

Projects 옆의 + 아이콘 클릭
→ New Project (새 프로젝트)
→ 클론(cloned)한 리포지토리 (repo) 폴더 선택
...

저는 WPFAevent의 로컬 클론 폴더를 지정했습니다. 이 시점부터 제가 던지는 모든 질문은 WordPress 플러그인에 대한 일반적인 지식이 아니라, 해당 디렉토리에 있는 실제 소스 파일들을 참조하여 답변됩니다.

[IMG:1]

3단계: 코드베이스 파악하기

특정 이슈로 바로 뛰어들기 전에, 프로젝트의 상위 수준 지도를 얻기 위해 오리엔테이션 (orientation) 프롬프트를 보냈습니다:

"이 코드베이스의 개요를 알려주세요. 무엇을 하는 코드이며, 어떻게 구조화되어 있고, 제가 알아야 할 주요 엔트리 포인트 (entry points)는 무엇인가요?""

에이전트 (agent)는 디렉토리를 읽어 플러그인의 목적(Eventyay 이벤트 데이터를 위한 WordPress 통합)을 식별하고, wpfaevent.php를 통해 주요 엔트리 포인트를 추적한 뒤, includes/ 디렉토리 내의 핵심 클래스들을 안내해 주었습니다:

class-event-loader.php — 훅 (hooks) 및 쇼트코드 (shortcodes) 초기화
class-event-api.php — 트랜지언트 캐싱 (transient caching)을 이용한 원격 API 페칭 (fetching) 처리
class-event-admin.php — 관리자 설정 페이지 (API 설정, 캐시 TTL)
class-event-speakers.php, class-event-sessions.php, class-event-schedule.php — 각 쇼트코드에 대한 로직

이전에는 디렉토리를 20분 동안 뒤져야 했던 작업이 약 30초 만에 끝났습니다.

[IMG:1]

4단계: GitHub 이슈 (Issues) 파헤치기

이 워크플로우가 진정으로 유용해지는 지점입니다. 저는 Antigravity를 띄워놓은 상태로 WPFAevent 이슈 목록을 열고, 특정 이슈들을 입력하여 추론을 시작했습니다.

이슈: API 실패 시 캐싱 동작

class-event-api.php가 캐싱을 어떻게 처리하는지 단계별로 설명해 주세요.
어떤 트랜지언트 키 (transient keys)를 사용하며, API 호출이 실패하면 어떤 일이 발생하나요?
실패한 응답이 캐싱되어 사용자에게 제공될 위험이 있나요?

에이전트는 파일을 읽고 트랜지언트 로직을 추적하여, 에러 조건이 발생했을 때 오래된 데이터나 빈 데이터가 캐싱될 수 있는 정확한 지점을 찾아냈습니다. 이는 제가 직접 여러 함수 호출을 거치며 수동으로 추적해야 했을 부분입니다.

이슈: 새로운 쇼트코드 추가

이벤트 스폰서를 표시하기 위한 새로운 쇼트코드를 추가하려면 어떤 파일들을 수정해야 하나요?
기존 쇼트코드들이 사용하는 패턴을 단계별로 설명해 주세요. 그래야 동일한 컨벤션 (conventions)을 따를 수 있습니다.

패턴을 추측하는 대신, 저는 단계별 분석 내용을 얻었습니다: includes/에 새로운 클래스를 생성하고, class-event-loader.php에 이를 등록하며, public/partials/에 디스플레이 템플릿을 추가하고, 새로운 에셋 (assets)을 올바르게 인큐 (enqueue)하는 과정입니다. 에이전트 (agent)는 심지어 제가 사용자에게 노출되는 새로운 문자열을 추가할 경우 languages/에 있는 번역 템플릿을 업데이트해야 한다는 점까지 짚어주었습니다.

문제: 일정 엔드포인트 (Schedule endpoint) 및 다일 이벤트 (multi-day events)

일정 엔드포인트가 다일 이벤트를 올바르게 처리하지 못하는 것에 대한
열린 이슈 (open issue)가 있습니다. class-event-schedule.php의
현재 구현을 바탕으로 할 때, 가장 가능성 있는 원인은 무엇이며,
...

에이전트는 일정 클래스를 읽고, 현재의 그룹화 로직 (grouping logic)이 자정을 넘기는 세션 (sessions)을 고려하지 않은 채 세션당 단일 date 필드만을 가정하고 있다는 점을 식별했으며, 그룹화 함수 (grouping function)를 어디까지 확장해야 하는지 제안했습니다. 저는 단 한 줄의 코드도 작성하기 전에, 테스트할 수 있는 구체적인 가설을 얻을 수 있었습니다.

[Insert screenshot here: Antigravity conversation showing issue analysis with specific file references]

5단계: 아티팩트 (Artifacts)에 대한 인라인 댓글 (Inline Comments)

저를 놀라게 했던 기능 중 하나는 Antigravity가 **반복적 개선 (iterative refinement)**을 얼마나 자연스럽게 처리하는가였습니다. 에이전트가 분석 아티팩트(예: 수정을 위해 필요한 변경 사항에 대한 분석 내용)를 생성하면, Google Docs에 주석을 다는 것과 동일한 방식으로 해당 아티팩트에 직접 댓글을 남길 수 있습니다.

저는 이를 사용하여 에이전트의 제안 중 하나에 대해 반론을 제기했습니다:

[아티팩트에 대한 댓글]: "이 접근 방식은 API 응답 파싱 (parsing)을 수정합니다. 하지만 이 변경 사항을 디스플레이 레이어 (display layer)로만 격리할 수는 없을까요? 이 작업을 위해 class-event-api.php를 건드리고 싶지는 않습니다."

에이전트는 제약 사항을 다시 읽고, 권장 사항을 업데이트했으며, 전적으로 템플릿 파일로 범위를 제한한 수정된 접근 방식을 생성했습니다. 새로운 메시지에서 전체 컨텍스트 (context)를 다시 설명할 필요가 없었습니다.

[Insert screenshot here: Inline comment interface on an analysis artifact]

6단계: 더 넓은 분석을 위한 병렬 에이전트 (Parallel Agents)

한꺼번에 평가하고 싶은 오픈 이슈(open issues)가 여러 개 있을 때, 저는 **워크 트리(work trees)를 활용한 병렬 대화(parallel conversations)**를 사용했습니다. 이는 코드베이스의 별도 복사본들에 대해 여러 에이전트 스레드(agent threads)를 동시에 실행하는 Antigravity의 메커니즘입니다.

워크 트리 (Work Tree) = 프로젝트의 복사본을 포함하는 새로운 폴더로, 에이전트들이 서로 간섭하지 않고 서로 다른 이슈나 접근 방식을 병렬로 탐색할 수 있게 해줍니다.

저는 세 개의 병렬 스레드를 시작했습니다:

스레드 1 — 의존성 감사 (Dependency audit):

composer.json과 includes/ 디렉토리를 확인하세요.
README에 명시된 WordPress 5.8+ 타겟과 비교했을 때
오래된 의존성이나 누락된 요구 사항이 있습니까?
...

스레드 2 — i18n 커버리지 (i18n coverage):

코드베이스를 검토하여 __() 또는 _e()로 감싸여 있지 않은
사용자 대상 문자열을 찾으세요. 파일별로 목록을 작성하세요.
→ 새로운 워크 트리 (New Work Tree)

스레드 3 (메인 스레드) — PR 리뷰 (PR review):

17개의 오픈 풀 리퀘스트(pull requests)가 있습니다. 현재 코드베이스를 바탕으로,
새로운 기여자가 시작하기에 가장 영향력이 크면서도
리스크가 낮은 오픈 이슈는 무엇이라고 생각합니까?

세 스레드가 모두 동시에 실행되었습니다. 제가 메인 스레드에서 돌아오는 PR 분석 내용을 검토하는 동안, 의존성 감사와 i18n 커버리지 체크는 여전히 실행 중이었습니다. i18n 스레드는 특정 파일과 줄 번호가 포함된 목록을 반환했습니다. 이는 수동으로 작성하기에는 매우 지루하지만, 실행에 옮기기에는 매우 간단한 종류의 결과물입니다.

[IMG:1] (여기에 스크린샷 삽입: 병렬 분석 스레드를 보여주는 서브 에이전트 개요 패널)

7단계: 지속적인 기여를 위한 예약된 작업 (Scheduled Tasks)

제가 탐색한 마지막 기능은 Antigravity 2.0에서 새롭게 도입된 **예약된 작업 (Scheduled Tasks)**입니다.