에이전트 이해하기: 계획(Plan)–실행(Execute)–검증(Verify) 사이클
에이전트는 '대화 상대'가 아니라 '작업자'다
Antigravity에서 에이전트는 질문에 답하는 챗봇보다, 목표를 받아서 실제로 일을 끝내는 작업자에 가깝습니다. Google은 Antigravity를 "에디터·터미널·브라우저를 넘나들며 자율적으로 계획하고 실행하고 검증하는" 에이전트 중심 개발 플랫폼으로 소개합니다.1 즉, 여러분의 역할은 코드를 대신 타이핑하는 사람이 아니라, 작업을 정의하고, 결과를 검수하고, 위험한 지점에서 승인/중단/방향수정을 하는 오케스트레이터가 됩니다.
이 관점이 잡히면, 에이전트에게 "설명해줘"를 반복하는 대신 "이 기준으로 끝내줘"라고 지시하게 되고, 결과 확인도 "말"이 아니라 "증거물(Artifacts)"로 보게 됩니다.2
전체 사이클 한 장으로 이해하기
Antigravity에서의 에이전트 업무 흐름은 다음의 루프로 이해하면 가장 안정적입니다.
Plan(계획) → Execute(실행) → Verify(검증) → (필요 시 Replan/재계획) → 완료
이 구조는 최근 멀티 에이전트 오케스트레이션 연구에서도 반복적으로 강조됩니다. 작업을 DAG(의존성 그래프)로 분해해 실행하고, 오케스트레이션 레벨에서 검증해 누락을 찾아 재계획하는 방식이 품질을 끌어올리는 핵심이라는 주장입니다.3
Antigravity의 실전 사용에서는 이 루프를 "대화 로그"가 아니라 "계획 문서, 구현 계획, 테스트 결과, 스크린샷/브라우저 녹화, diff" 같은 산출물로 돌립니다.2
Plan: '무엇을' '어떤 기준으로' 끝낼지 합의하기
계획 단계는 "잘할 것"을 기대하는 시간이 아니라, 일이 끝났다고 말할 수 있는 조건을 명확히 하는 시간입니다. Plan이 부실하면 Execute는 빨라져도 Verify에서 계속 걸리고, 결국 사람의 재작업이 늘어납니다.
Antigravity에 Plan을 요청할 때는 다음 3가지를 반드시 포함시키는 것이 좋습니다.
첫째, 목표를 결과물 중심으로 표현합니다. "로그인 버그를 고쳐줘" 대신 "재현→원인 분리→회귀 테스트 추가→fix→브라우저에서 정상 로그인 증거(스크린샷/녹화)까지"처럼, 작업자의 체크아웃(완료 상태)을 정의합니다.1
둘째, 제약을 명시합니다. 예를 들어 "기존 API 스펙 유지", "DB 마이그레이션 금지", "의존성 추가 금지", "터미널 커맨드는 실행 전 승인" 같은 제약은 계획 품질을 크게 올립니다. 에이전트는 도구를 쓸 수 있기 때문에, '가능한 수단'이 넓을수록 제약이 없으면 의도와 다른 해법으로 빠지기 쉽습니다.4
셋째, 검증 기준(acceptance criteria)을 문장으로 박아 둡니다. "테스트 통과", "에러 재현 불가", "UI가 스펙과 일치" 같은 표현은 추상적일 수 있으니, 가능하면 "어떤 테스트를 추가/실행하고", "어떤 화면 상태를 스크린샷으로 남기고", "어떤 로그/메트릭을 확인할지"까지 적습니다.2
Plan 산출물은 대개 "Task List / Implementation Plan" 형태가 되는데, Antigravity는 이런 산출물을 검토 가능한 아티팩트로 만들고, 사용자는 그 위에 코멘트를 남기는 방식으로 방향을 고정합니다.1
Execute: 계획을 '행동'으로 바꾸는 단계, 사람은 운전대를 잡지 않는다
실행 단계에서 중요한 원칙은 하나입니다. 사람이 운전대를 잡고 있으면, 에이전트의 장점이 사라집니다.
Plan을 승인한 뒤에는 에이전트가 에디터 수정, 터미널 실행, 브라우저 검증을 이어서 진행하도록 맡기고, 사람은 "진행 상황을 묻는 질문"보다 "중간 산출물의 품질을 올리는 피드백"에 집중하는 편이 훨씬 효율적입니다.1
다만 Execute는 '방임'이 아니라 '위험 관리가 포함된 위임'입니다. 특히 터미널/외부 시스템 변경 같은 행위는 파급이 크기 때문에, 많은 에이전트 시스템은 명시적 승인 지점을 두거나, 실패 횟수/위험도에 따라 사람에게 제어권을 넘기는 방식이 안전하다고 봅니다.5
실전에서 Execute를 안정화하는 가장 좋은 방법은 에이전트에게 "작업 기록을 남기는 방식"을 강제하는 것입니다. Antigravity의 철학도 '로그를 읽게 하지 말고, 검증 가능한 산출물을 남겨라'에 가깝습니다.2
Verify: "됐어요"가 아니라 "증거는 여기 있어요"로 끝낸다
검증은 에이전트가 잘했는지 의심하는 과정이 아니라, 다음 사람(미래의 나, 리뷰어, 팀)이 다시 확인할 수 있게 만드는 과정입니다.
Antigravity는 신뢰를 "말"이 아니라 Artifacts(계획, diff, 스크린샷, 브라우저 녹화, 워크스루 등)로 만든다는 점을 전면에 내세웁니다.2 즉 Verify는 "에이전트가 테스트를 돌렸는가?"가 아니라 "테스트 결과가 어떤 아티팩트로 남았는가?"를 묻는 단계입니다.
Verify를 설계할 때는, 산출물의 형태를 미리 지정하면 좋습니다.
예를 들어 UI 변경 작업이라면 '수정 diff'와 함께 '브라우저에서 특정 화면을 열어 특정 요소가 보이는 스크린샷'이 남아야 합니다. 버그 수정이라면 '재현 절차'와 '재현이 더 이상 되지 않는 증거', 그리고 '회귀를 막는 테스트'가 남아야 합니다. 이런 형태의 검증은 단일 에이전트든 멀티 에이전트든 품질을 끌어올리는 핵심 신호로 작동합니다.3
Replan: 검증에서 걸리면, 다시 "대화"가 아니라 "재설계"로 간다
검증에서 문제가 나오면, 많은 사람이 다시 채팅 모드로 돌아가 "왜 안 돼?"를 묻습니다. 하지만 더 좋은 접근은 "계획의 어떤 항목이 실패했는지"를 기준으로 재계획(replan)을 거는 것입니다.
Plan-and-Execute 계열 아키텍처에서는 재계획을 명시적인 단계로 두어, 현재 상태를 평가하고 계획을 갱신하거나 새로운 단계를 추가합니다.46 이는 감각적으로도 납득이 됩니다. 실행이 실패했을 때 필요한 것은 '새로운 말'이 아니라 '새로운 작업 단위'이기 때문입니다.
재계획을 잘 걸기 위한 문장은 단순합니다.
"방금 Verify에서 A가 실패했어. 원인을 3개 가설로 분류하고, 각 가설을 검증하는 최소 실험을 계획에 추가해줘. 그 계획을 승인받은 뒤에만 실행해."
이 한 문장만으로도, 에이전트는 즉흥적인 수정 반복 대신, 원인 분리와 실험 설계를 하게 됩니다.
사람이 개입해야 할 지점: '도와주기'가 아니라 '통제하기'
에이전트에게 계속 친절하게 설명해주는 방식의 개입은 비용이 큽니다. 대신 사람은 다음 같은 지점에서 결정권자로 개입하는 편이 좋습니다.
첫째, 요구사항이 애매할 때입니다. 제품/UX 의사결정, 정책/보안 요구사항 같은 것은 에이전트가 대신 정하면 실패 비용이 커집니다. 이때 사람의 개입은 '설명'이 아니라 '선택'이어야 합니다.
둘째, 되돌리기 어려운 작업일 때입니다. 배포, 데이터 변경, 비용이 발생하는 외부 호출, 계정/권한 관련 조작은 승인 단계를 두는 것이 안전합니다. 많은 자율 에이전트 설계가 위험 작업에서 인간 승인(또는 강제 개입)을 안전장치로 봅니다.57
셋째, 실패가 반복될 때입니다. 같은 작업을 여러 번 재시도하는 동안 비용만 늘고 결과가 나아지지 않으면, 사람은 실행을 멈추고 "문제 정의" 또는 "관측 방법(검증)"을 바꿔야 합니다. 실패 임계치를 넘으면 인간이 제어권을 가져오는 설계가 실제 운영에서 중요하다는 점도 강조됩니다.5
실전 프롬프트: '작업자에게 내리는 지시문' 템플릿
아래 템플릿은 Antigravity에서 에이전트를 작업자로 다루기 위한 최소 문장들입니다.
첫 번째는 계획 강제 템플릿입니다.
"지금부터 Planning Mode로 진행해. 먼저 Task List와 Implementation Plan을 아티팩트로 만들어. 각 단계마다 완료 조건과 검증 방법을 써. 내가 승인하기 전에는 실행하지 마."12
두 번째는 검증 산출물 강제 템플릿입니다.
"완료 보고는 말로 하지 말고 아티팩트로 해. 최소한 diff, 실행한 테스트 명령과 결과, 그리고 UI라면 스크린샷(또는 브라우저 녹화)을 포함해."2
세 번째는 위험 작업 승인 템플릿입니다.
"터미널에서 (삭제/마이그레이션/배포/권한 변경/외부 결제) 성격의 명령은 실행 전에 반드시 확인 질문을 해. 대안이 있으면 비용과 리스크를 비교해 제안해."5
이 세 가지를 기본값으로 두면, 에이전트는 '채팅에서 그럴듯한 말'을 늘리는 방향이 아니라 '검증 가능한 산출물'을 남기는 방향으로 움직입니다.
요약: Plan–Execute–Verify가 잡히면, 에이전트가 팀원이 된다
Plan–Execute–Verify 사이클의 핵심은 단순합니다. Plan에서 완료 기준을 합의하고, Execute에서 사람의 손을 빼고, Verify에서 산출물로 신뢰를 쌓습니다.12 그리고 Verify에서 걸리면 다시 대화로 감정 노동을 하는 대신, 재계획으로 작업 단위를 재정의합니다.36
다음 챕터에서는 이 사이클이 에디터 안에서만 끝나지 않고, 터미널과 브라우저까지 묶이면서 어떻게 "크로스-서피스 워크플로"가 되는지 구체적인 흐름으로 확장해 보겠습니다.
참고
1Build with Google Antigravity, our new agentic development platform
2Google Antigravity Documentation (Rules / Workflows 포함)
4Plan-and-Execute Agents (LangChain Blog)
5Human Intervention: A Critical Safeguard in AI Agent Systems
6ReAct vs Plan-and-Execute: A Practical Comparison of LLM Agent Patterns
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.