Artifacts의 5가지 종류

에이전트와 일할 때 검토가 느린 이유는 AI가 코드를 많이 만들어서만이 아닙니다. 어디를 봐야 안심할 수 있는지 모를 때 검토는 끝없이 늘어집니다. 계획을 봐야 할 일을 스크린샷에서 찾고, 스크린샷으로 확인할 일을 diff에서 찾고, diff만으로는 알 수 없는 사용자 흐름을 코드만 읽으며 상상하려 들면 검토는 금방 피로해집니다.

Antigravity의 Artifacts는 바로 그 혼란을 줄이기 위해 존재합니다. Google은 Artifact를 에이전트가 자신의 작업을 진행하거나, 사람에게 작업 내용과 생각을 전달하기 위해 만들어내는 모든 산출물로 넓게 정의합니다.¹ 중요한 점은 "뭔가 많이 보여준다"가 아닙니다. 각 Artifact가 서로 다른 질문에 답한다는 데 있습니다.

무엇을 봐야 안심할 수 있는가

작업을 맡긴 뒤 개발자가 확인하고 싶은 질문은 대체로 다섯 가지입니다.

• 지금 에이전트가 어디까지 왔는가

• 애초에 올바른 방향으로 가고 있는가

• 화면이 내가 기대한 모양으로 바뀌었는가

• 실제 사용자 흐름이 끊기지 않고 동작하는가

• 결국 코드에서 무엇이 바뀌었는가

이 다섯 질문에 각각 답하는 것이 Task Lists, Implementation Plans, Screenshots, Browser Recordings, 그리고 Code Diffs입니다. 엄밀히 말하면 diff는 공식 문맥에서 별도 리뷰 표면으로 다뤄질 때도 있지만, 실무에서는 사실상 여섯 번째 Artifact처럼 작동합니다.³

Task Lists — 진행 상황을 검증하는 아티팩트

Task List는 가장 소박해 보이지만, 긴 작업에서는 가장 먼저 안심을 줍니다. 이 문서는 에이전트가 큰 작업을 작은 단계로 나눠 현재 무엇을 했고, 무엇이 남았는지 추적하는 체크리스트에 가깝습니다. Antigravity 관련 가이드들에서도 Task List는 복잡한 작업의 진행 상황을 구조적으로 보여주는 핵심 Artifact로 설명됩니다.²

Task List가 답하는 질문은 단순합니다. "지금 뭐 하는 중이지?" 이 질문은 생각보다 중요합니다. 에이전트가 20분째 조용하면 사람은 본능적으로 불안해집니다. 그런데 Task List를 열어 보니 "테스트 작성 완료, 브라우저 검증 진행 중"이라고 적혀 있으면, 그 침묵은 갑자기 정상적인 노동으로 보입니다.

Task List에서 봐야 할 것은 화려한 설명이 아닙니다. 세 가지면 충분합니다.

• 작업 순서가 자연스러운가

• 빠진 단계가 없는가

• 원래 요청보다 일이 불필요하게 커지고 있지 않은가

예를 들어 "버튼 색 바꿔줘" 같은 작은 요청인데 Task List에 상태 관리 리팩터링, 디자인 시스템 정리, 공통 컴포넌트 재구성 같은 항목이 잔뜩 올라와 있다면, 그 순간 이미 범위가 흔들리고 있다는 뜻입니다. 반대로 "로그인 버그 수정"인데 브라우저 확인이나 테스트 항목이 빠져 있다면, 완료 선언이 나와도 마음이 불편할 수밖에 없습니다.

Task List의 검증 역할은 정답 검증보다는 과정 검증에 가깝습니다. 즉, 이 문서를 보고 "코드가 맞다"까지 판단하기는 어렵지만, "적어도 제대로 된 순서로 일하고 있구나"는 빠르게 판단할 수 있습니다. 실무에서 이 차이는 큽니다. 과정이 말이 되면 결과 검토 범위도 줄어들기 때문입니다.

Implementation Plans — 방향을 검증하는 아티팩트

Implementation Plan은 코드를 쓰기 전에 읽는 설계도입니다. Planning 모드에서는 특히 이 문서가 중요해지고, 설정에 따라 에이전트가 작업 전 사용자 리뷰를 요청하기도 합니다.² 많은 사람이 이 단계를 형식적인 예고편처럼 넘기지만, 사실 가장 값싼 검토는 여기서 일어납니다.

Implementation Plan이 답하는 질문은 "이 에이전트가 지금 맞는 문제를 풀고 있는가?" 입니다.

코드 리뷰는 비싸지만, 방향 리뷰는 상대적으로 쌉니다. 예를 들어 "사내 관리자 페이지에 CSV 내보내기 기능 추가"를 요청했다고 합시다. 그런데 계획서를 보니 새 라이브러리를 두 개 깔고, 백엔드 엔드포인트를 새로 만들고, 권한 체계까지 손보려 합니다. 이때 이상함을 느끼고 멈추는 것이 좋습니다. 어쩌면 진짜 필요한 것은 기존 API 재사용과 버튼 하나 추가일 수도 있기 때문입니다.

Implementation Plan에서 꼭 봐야 하는 지점은 다음과 같습니다.

• 어떤 파일과 계층을 건드리려 하는가

• 새 의존성이나 외부 서비스가 필요한가

• 제외해야 할 범위를 제대로 제외했는가

• 검증 방법을 어떻게 잡았는가

좋은 계획서는 "무엇을 바꿀지"만 말하지 않고 "왜 그렇게 바꾸는지"까지 암시합니다. 반대로 나쁜 계획서는 그럴듯한 기술 용어를 많이 쓰지만, 정작 성공 기준이 없습니다. "리팩터링한다", "최적화한다", "개선한다" 같은 말이 잔뜩 보이는데, 어떤 조건이 충족되면 끝나는지 모른다면 위험 신호입니다.

Implementation Plan의 진짜 가치는 실수를 막는 데 있습니다. 코드가 잘못 나온 뒤 되돌리는 것보다, 잘못된 방향을 시작 전에 꺾는 것이 훨씬 싸기 때문입니다. 인간 팀원과 일할 때도 설계 검토가 중요한 이유가 바로 이것입니다. 에이전트라고 예외는 아닙니다. 오히려 더 그렇습니다.

Screenshots — 정적인 결과를 검증하는 아티팩트

스크린샷은 UI 작업에서 가장 직관적인 증거입니다. 코드를 몰라도 볼 수 있고, 몇 초 안에 어색함을 감지할 수 있습니다. Antigravity 생태계의 가이드들은 스크린샷을 변경 전후 화면, 반응형 상태, 특정 UI 요소의 변화까지 보여주는 대표적인 시각적 검증 수단으로 다룹니다.³

스크린샷이 답하는 질문은 "보이는 결과가 맞는가?" 입니다.

여기서 중요한 것은 "예쁘다"만 보는 것이 아닙니다. 개발자의 눈으로 보면 스크린샷은 꽤 많은 사실을 알려줍니다. 버튼 정렬이 맞는지, 간격이 깨졌는지, 텍스트가 잘렸는지, 로딩 상태가 어색한지, 모바일에서 요소가 밀리는지, 에러 메시지가 지나치게 공격적인지 같은 것들이 한 장 안에서 드러납니다.

스크린샷을 검토할 때는 확대해서 특정 부분만 보는 습관보다, 먼저 전체 화면을 훑는 편이 좋습니다. 에이전트는 종종 목표한 부분은 잘 고치고 주변 레이아웃을 은근슬쩍 망가뜨립니다. 검색창을 예쁘게 다듬었는데 헤더 높이가 틀어지거나, 카드 간격을 줄였더니 모바일에서 버튼이 접히는 식입니다. 사람은 원래 요청한 한 군데만 보다가 이런 부작용을 놓치기 쉽습니다.

다만 스크린샷에는 분명한 한계도 있습니다. 스크린샷은 정지 화면입니다. 그래서 클릭 이후의 상태 변화, 애니메이션, 비동기 로딩, 폼 제출 플로우 같은 것은 제대로 설명하지 못합니다. 한마디로 스크린샷은 정적 진실에는 강하지만, 동적 진실에는 약합니다.

그래서 스크린샷을 볼 때는 이렇게 생각하면 편합니다. "보이는 모양은 맞는가?"를 확인하는 데는 최고지만, "이게 실제로 잘 굴러가나?"를 확신하기에는 아직 한 걸음 부족합니다.

Browser Recordings — 동작의 흐름을 검증하는 아티팩트

브라우저 녹화는 Antigravity의 차별점이 가장 잘 드러나는 지점입니다. 공식 문서에 따르면 브라우저 서브에이전트가 브라우저에서 실제로 동작할 때, 검토를 위해 녹화가 생성될 수 있고, 이 기록은 Recording Artifact로 저장됩니다.⁴ 브라우저 확장 가이드에서도 이 서브에이전트는 클릭, 타이핑, 스크롤, DOM 분석, 콘솔 로그 확인, 네트워크 요청 점검 같은 브라우저 수준의 검증 작업을 수행할 수 있다고 설명합니다.⁵

Browser Recording이 답하는 질문은 "실제 사용자처럼 써 봤을 때도 괜찮은가?" 입니다.

이 차이는 매우 큽니다. 로그인 페이지를 예로 들어 봅시다. 스크린샷만 보면 입력창도 예쁘고 버튼도 멀쩡합니다. 그런데 녹화를 보니 비밀번호를 입력한 뒤 버튼을 눌렀을 때 로딩 스피너가 잠깐 번쩍이고, 잘못된 자격 증명에서는 토스트가 화면 아래에 잠깐 떴다가 사라지고, 성공 후 리다이렉트가 두 번 일어나는 장면이 보일 수 있습니다. 이런 문제는 스크린샷 한 장으로는 잘 안 잡힙니다.

브라우저 녹화를 볼 때는 마지막 성공 장면보다 과정의 어색함을 봐야 합니다. 예를 들면 이런 것들입니다.

• 클릭이 잘못된 요소에 먼저 갔는가

• 로딩이 지나치게 길거나 깜빡이는가

• 스크롤 위치가 예상과 다르게 튀는가

• 에러가 뜬 뒤 회복 흐름이 자연스러운가

• 모바일 뷰포트에서 터치 대상이 너무 작은가

브라우저 녹화의 장점은 QA 담당자의 눈을 빌려온 듯한 느낌을 준다는 데 있습니다. 코드는 멀쩡해 보여도 실제 사용 흐름이 어색하면 제품은 금방 싸구려처럼 느껴집니다. 녹화는 바로 그 미묘한 어색함을 잡아냅니다.

동시에 녹화는 "에이전트가 진짜 브라우저를 열어 확인했는가"를 보여주는 증거이기도 합니다. 채팅창의 "브라우저 검증 완료"라는 문장보다, 직접 클릭하고 이동한 기록 한 편이 훨씬 설득력 있습니다. 검토자는 설명보다 흔적을 더 빨리 믿습니다.

Code Diffs — 사실상의 여섯 번째 아티팩트

이제 결국 개발자가 가장 자주 돌아오는 곳이 남았습니다. 바로 diff입니다. 코드 diff는 눈에 띄게 화려하지 않지만, 실무 신뢰의 중심은 여기에 있습니다. Antigravity 관련 가이드들도 Code Diffs를 검토 가능한 핵심 증거로 다루며, 변경된 줄을 직접 코멘트할 수 있는 중요한 리뷰 표면으로 설명합니다.³

Diff가 답하는 질문은 "도대체 실제로 무엇이 바뀌었는가?" 입니다.

이 질문은 단순해 보이지만, 거의 모든 불안을 압축합니다. 에이전트가 설명한 의도와 실제 변경 범위가 일치하는지, 테스트만 추가한 건지, 설정 파일도 건드렸는지, 전혀 상관없는 파일이 함께 수정됐는지, 삭제가 필요한 수준 이상으로 크게 일어났는지 모두 diff에서 드러납니다.

Diff 리뷰가 강력한 이유는 전체 결과물을 다시 읽지 않아도 변경된 델타만 볼 수 있기 때문입니다. 일반적인 리뷰 원칙에서도 전체 산출물보다 diff 경계에서 검토하는 편이 더 효율적이라고 봅니다. 실수는 기존 코드보다 새로 바뀐 부분에 집중되어 있기 때문입니다.⁶

Diff를 볼 때 특히 주의할 부분은 이런 곳입니다.

• 인터페이스나 API 계약이 바뀌었는가

• 환경 변수, 설정 파일, 권한 관련 코드가 수정됐는가

• 에러 처리나 예외 흐름이 빠졌는가

• 테스트가 코드 변경을 제대로 따라왔는가

• 요청하지 않은 리팩터링이 끼어들었는가

여기서 자주 생기는 함정도 있습니다. diff가 작다고 항상 안전한 것은 아닙니다. 한 줄의 타입 변경이 시스템 전체 계약을 흔들 수 있고, 설정 파일 한 줄이 배포 환경을 망칠 수 있습니다. 반대로 diff가 크다고 무조건 나쁜 것도 아닙니다. 다만 리뷰 피로도가 급격히 올라가므로, 큰 diff일수록 계획서와 Task List, 그리고 시각적 증거를 함께 묶어 봐야 합니다.

결국 diff는 "에이전트가 무슨 말을 했는가"가 아니라, 저장소에 어떤 현실을 남겼는가를 보여주는 표면입니다. 개발자는 말보다 변경 이력을 더 오래 기억합니다.

가장 빠른 검토 순서

Artifacts를 잘 쓰는 사람은 모든 것을 같은 깊이로 보지 않습니다. 작업 종류에 따라 먼저 봐야 할 표면이 달라집니다.

버그 수정이나 리팩터링처럼 영향 범위가 걱정되는 작업이라면, 먼저 Implementation Plan으로 방향을 보고, 다음에 Code Diff로 변경 범위를 확인한 뒤, 마지막에 테스트나 브라우저 증거를 확인하는 편이 좋습니다. 반대로 UI 손질이나 디자인 수정이라면 스크린샷과 브라우저 녹화가 먼저입니다. 코드가 예뻐도 화면이 어색하면 제품은 실패한 것이니까요.

실전에서는 다음 순서가 가장 안정적입니다.

• Plan으로 방향을 확인한다

• Task List로 빠진 단계와 진행 상태를 본다

• Screenshot과 Recording으로 실제 동작을 확인한다

• Diff로 최종 변경 범위를 좁게 검토한다

이 순서가 좋은 이유는, 사람의 불안이 추상에서 구체로 줄어들기 때문입니다. 처음에는 "이 에이전트가 이상한 데로 가는 것 아닌가?"가 걱정이고, 그다음은 "정말 작동하나?"가 걱정이고, 마지막에는 "그 과정에서 뭘 망쳤나?"가 걱정입니다. Artifacts는 그 불안의 순서에 맞춰 검토 표면을 나눠 줍니다.

안심은 속도가 아니라 시야에서 나온다

에이전트 시대의 검토는 더 많이 읽는 사람이 이기는 게임이 아닙니다. 올바른 증거를 올바른 순간에 읽는 사람이 이깁니다.

Task List는 진행을 안심시켜 주고, Implementation Plan은 방향을 안심시켜 주고, Screenshots는 모양을 안심시켜 주고, Browser Recordings는 흐름을 안심시켜 주고, Code Diffs는 변경 범위를 안심시켜 줍니다. 이 다섯 겹이 쌓이면, 개발자는 더 이상 AI의 말을 무작정 믿지도 않고, 모든 파일을 처음부터 끝까지 읽으며 자신을 벌주지도 않게 됩니다.

결국 좋은 검토란 "AI를 믿는 법"을 배우는 일이 아닙니다. 어떤 Artifact가 어떤 종류의 불안을 줄여주는지 아는 것입니다. 그 감각이 생기면 검토 속도는 자연스럽게 빨라집니다. 그리고 그때부터 AI 결과 검토는 피곤한 뒷수습이 아니라, 꽤 잘 설계된 운영 절차처럼 느껴지기 시작합니다.

참고

¹Google Antigravity Documentation — Artifacts

²Google Antigravity 공식문서 이해하기 3 — Artifacts

³Complete Guide to Google Antigravity

⁴Google Antigravity Documentation — Browser Recordings

⁵Antigravity Browser Extension: Complete Guide

⁶Diff-Based Review Over Output Review