책에 포함된 노트Google Antigravity 실전 활용법: 코딩을 넘어 오케스트레이션으로

Artifacts로 검증하기: 로그 대신 '증거물'로 신뢰를 만든다

2026-03-23Views 6약 8분

설명이 아니라 '재검증 가능한 결과'가 필요하다

에이전트가 한 일을 사람이 믿지 못하는 이유는 대개 단순합니다. "잘 됐다"는 말은 빠르지만, 다시 확인할 방법이 없기 때문입니다. 반대로 신뢰는 느리게 쌓입니다. 누가 봐도 같은 결론에 도달할 수 있는 증거물(Artifacts)이 남을 때, 검증과 승인은 반복 가능한 루틴이 됩니다.

여기서 말하는 아티팩트는 "로그를 길게 붙여넣은 것"이 아닙니다. 아티팩트는 다음 조건을 만족하는 검증 단위입니다.

제3자가 재현 또는 확인할 수 있어야 한다.
요구사항(또는 티켓)과 연결돼 있어야 한다.
무엇을, 왜, 어떻게 확인했는지가 한 눈에 드러나야 한다.
실패했을 때 '다음 행동'(수정/재시도/롤백)이 명확해야 한다.

GUI 기반 테스트 아티팩트 리뷰 가이드라인 연구도, 리뷰 품질을 올리는 핵심으로 자동화 체크, 체크리스트, 맥락 정보 제공, 변경 시각화 같은 범주를 강조합니다.¹²

로그 중심 검증이 깨지는 지점

로그는 원래 "운영 관측"에는 강합니다. 하지만 리뷰/승인 관점에서는 약점이 분명합니다.

첫째, 로그는 해석이 필요합니다. 사람이 읽어야 하고, 읽는 사람의 경험에 따라 결론이 달라집니다.

둘째, 로그는 종종 맥락이 누락됩니다. 어떤 티켓을 해결하려고 어떤 조건에서 어떤 동작을 했는지, 로그만으로는 연결되지 않습니다.

셋째, 로그는 UI/브라우저 세계를 충분히 담지 못합니다. 화면이 어떻게 바뀌었는지, 사용자가 어떤 경로로 들어가 어떤 상태를 보게 되는지는 스크린샷/녹화/테스트 시나리오가 더 직접적입니다.²

그래서 Antigravity에서 리뷰/승인을 "대화 기록"이 아니라 "증거물 묶음"으로 돌리려면, 처음부터 아티팩트 패키지(Artifact Pack)를 표준으로 만들어야 합니다.

Artifact Pack: '한 번에 통과'시키는 제출물 묶음

Artifact Pack은 작업 종류가 무엇이든, 리뷰어가 "어디를 보면 되는지"를 즉시 알게 하는 제출물 포맷입니다. 코드 리뷰 체크리스트들이 공통으로 요구하는 축(요구사항 충족, 테스트, 문서, 보안 등)을 그대로 담되, Antigravity에서는 이를 사람이 읽기 쉬운 증거물로 바꿔 담습니다.³⁴

Artifact Pack의 최소 구성은 다음 5개로 고정하는 것을 권합니다.

첫째, 변경 요약(1페이지)입니다. 무엇이 바뀌었는지와 영향 범위를 한 문단으로 끝냅니다.

둘째, 요구사항 연결입니다. 티켓/스펙 링크, 혹은 요구사항 ID와의 매핑이 있어야 합니다. 테스트 문서화에서는 요구사항과 테스트를 연결해 추적 가능성을 확보하는 것을 반복해서 강조합니다.⁵

셋째, 구현 계획 또는 작업 체크리스트입니다. 리뷰가 주관적 LGTM이 되지 않도록, 확인 항목을 먼저 고정합니다.¹³

넷째, 검증 증거입니다. 자동 테스트 결과, 수동 테스트 시나리오 결과, 스크린샷/녹화, 성능 측정, 보안 점검 결과 등 "결론이 나오는 자료"를 넣습니다.

다섯째, 재현/롤백 가이드입니다. 문제가 생겼을 때 어떻게 재현하고, 어떻게 원복하는지가 있어야 승인자가 안심합니다.

아티팩트는 '종류'보다 '규칙'이 중요하다

아티팩트는 많이 만들수록 좋은 게 아니라, 같은 규칙으로 남길수록 효과가 커집니다. GUI 기반 테스트 아티팩트 리뷰 가이드라인은 읽기 쉬움(readability), 변경 시각화(visualize changes), 복잡도 감소(reduce complexity) 같은 범주로 "아티팩트를 리뷰 가능한 형태로 만들라"고 말합니다.¹²

Antigravity에서 특히 자주 쓰이는 아티팩트는 다음과 같습니다.

구현 계획(Implementation Plan): 단계, 완료 조건, 검증 방법, 리스크
체크리스트(Checklist): 기능/보안/성능/문서/테스트의 최소 확인 항목
스크린샷/브라우저 녹화: UI 변경, 버그 재현/해결, 플로우 증명
브라우저 기록: 콘솔 에러, 네트워크 요청/응답, 리다이렉트 흐름
테스트 결과물: 통과/실패 요약, 커버리지, 회귀 방지 테스트 추가 여부

중요한 건 "형태"보다 "판정 가능한 질문"으로 바꾸는 것입니다. 예를 들어 스크린샷은 단순 이미지가 아니라, "이 화면에서 이 요소가 이 상태로 보인다"를 증명하는 자료여야 합니다.

스크린샷과 브라우저 기록: UI 검증을 '증거'로 만드는 법

UI 작업에서 리뷰가 자주 깨지는 이유는, 변경이 코드 diff로만은 보이지 않기 때문입니다. 그래서 UI 검증은 처음부터 브라우저 기반 증거를 포함해야 합니다.

스크린샷은 다음 원칙으로 남기면 리뷰 효율이 크게 오릅니다.

"전/후"를 같은 조건(해상도, 계정, 데이터 상태)에서 찍는다.
클릭 경로를 1~2줄로 함께 기록한다.
에러/경고가 없어야 하는 화면이라면 콘솔 상태를 함께 남긴다.

또한 워크플로(승인 플로우, 자동화 플로우 등)는 글로 설명하기보다 "한 장짜리 스크린샷"이 더 강력한 경우가 많습니다. Power Automate 예시처럼, 디자이너 화면 자체를 크게 캡처해 공유하면 별도 다이어그램 없이도 문서화가 됩니다.⁶

체크리스트를 '승인 게이트'로 쓰는 방법

체크리스트는 "해야 할 일 목록"이 아니라, 승인자가 리스크를 통제하는 장치입니다. 코드 리뷰 체크리스트가 LGTM 문화의 위험을 줄이기 위해 표준화를 권하듯, 승인 기준을 체크리스트로 고정하면 에이전트 작업도 객관화됩니다.³

다만 체크리스트를 길게 만들면 아무도 읽지 않습니다. Antigravity용 체크리스트는 '공통 8개 + 작업별 추가' 구조가 실용적입니다.

공통 8개는 다음을 권합니다.

요구사항을 충족하는가
의도하지 않은 동작 변경이 없는가(영향 범위 설명 포함)
자동 테스트가 추가/수정됐는가, 그리고 통과했는가
수동 테스트 시나리오가 있는가(특히 UI/권한/결제)
보안 관점에서 위험이 늘지 않았는가(입력 검증, 인증/인가, 민감정보, 설정)
성능/비용에 급격한 악화가 없는가(핵심 경로만이라도)
운영 관측/에러 처리 기준을 만족하는가
문서/릴리즈 노트/마이그레이션 가이드가 필요한 변경인가

보안 항목은 OWASP의 Secure Code Review 체크리스트처럼, 입력 검증·인증/세션·접근제어·암호화·설정/배포를 축으로 삼으면 누락이 줄어듭니다.⁷

승인(Approval)은 '결정'이 아니라 '증거 확인'으로 설계한다

승인은 사람의 감각으로 내리는 결론이 아니라, 증거를 확인하고 리스크를 수락하는 절차입니다. 따라서 승인 워크플로는 "누가 승인하느냐"만이 아니라 "무엇을 보고 승인하느냐"가 중심이어야 합니다.

실무적으로는 다음 순서가 가장 안정적입니다.

요청(Submit): 에이전트(또는 담당자)가 Artifact Pack 링크와 체크리스트를 제출한다.
검토(Review): 리뷰어는 체크리스트에 따라 증거를 확인하고 코멘트를 남긴다.
승인/반려(Approve/Reject): 승인자는 남겨진 증거와 코멘트 처리 상태를 보고 결정한다.
아카이브(Archive): 승인된 Artifact Pack을 릴리즈/티켓과 함께 저장한다.

승인 워크플로 도구 관점에서도 '누가 언제 승인했고 어떤 코멘트가 남았는지'가 남는 감사 추적(audit trail)이 중요하게 다뤄집니다.⁸ 워크플로 유형을 정할 때도, 반복 가능한 일은 규칙 기반 프로세스 승인, 프로젝트는 유연한 프로젝트 승인, 케이스성 이슈는 조건에 따라 흐름이 달라지는 케이스 승인을 쓰라고 구분합니다.⁹