제7장 첫 번째 작업 위임하기

Antigravity를 처음 쓰는 사람은 대개 두 종류로 나뉜다. 한쪽은 너무 조심해서 아무 일도 시키지 못하고, 다른 한쪽은 첫날부터 "내 앱 하나 다 만들어줘"를 던진다. 둘 다 조금 아깝다.

첫 번째 작업 위임은 단순한 체험이 아니다. 사실상 앞으로의 협업 방식을 정하는 선언에 가깝다. 이때 프롬프트를 흐리게 쓰면 에이전트는 넓게 해석하고, 당신은 결과를 의심하고, 다시 길게 설명하고, 결국 "AI가 빠르다더니 왜 더 피곤하지?"라는 결론에 도착한다. 반대로 첫 위임을 잘 설계하면 이후의 모든 작업이 쉬워진다. 에이전트는 무엇을 중요하게 봐야 하는지 배우고, 당신은 어디서 검토해야 하는지 감을 잡는다.

Antigravity가 Planning 모드와 Fast 모드를 나누고, 계획과 아티팩트를 먼저 보여 주는 이유도 여기에 있다. 이 도구는 당신이 AI와 수다를 떨기보다, 일을 맡기고 검토하는 방식으로 협업하길 기대한다.¹²

첫 위임은 "똑똑한 질문"이 아니라 "좋은 업무 지시"다

많은 사람이 프롬프트를 "질문"처럼 쓴다. 예를 들어 "로그인 버그 고쳐줘" 같은 식이다. 사람끼리 일할 때도 이런 지시는 곤란하다. 어느 환경에서? 무엇이 버그인지? 어디까지 고치면 끝인지? 기존 방식은 유지해야 하는지? 아무것도 없기 때문이다.

Antigravity에서 좋은 첫 프롬프트는 챗봇 질문보다 업무 지시서에 가깝다. 핵심은 다섯 가지다.

• 목표: 무엇을 만들거나, 고치거나, 분석할 것인가

• 맥락: 어느 프로젝트, 어느 화면, 어느 기능이 관련되는가

• 범위: 무엇은 포함하고 무엇은 건드리지 말아야 하는가

• 완료 기준: 어떤 상태가 되면 끝났다고 볼 것인가

• 검증 방식: 테스트, 스크린샷, diff, 설명 중 무엇으로 증명할 것인가

이 다섯 가지가 들어가면 에이전트는 덜 추측한다. 추측이 줄면 엇나감도 줄고, 검토도 짧아진다.

예를 들어 이렇게 말하는 편이 훨씬 낫다.

현재 Next.js 대시보드 프로젝트에서 모바일 뷰에서 로그인 버튼이 눌리지 않는 문제를 수정해 주세요. 원인을 먼저 파악하고, 인증 방식은 바꾸지 말고 관련 파일만 최소 범위로 수정해 주세요. 완료 기준은 iPhone SE 크기에서 버튼이 정상 클릭되고, 기존 이메일 로그인은 그대로 유지되며, lint와 테스트가 통과하는 것입니다. 변경 파일 diff와 수정 전후 설명을 함께 남겨 주세요.

이 프롬프트가 좋은 이유는 문장이 길어서가 아니다. 목표, 제약, 완료 기준이 모두 들어 있기 때문이다. 에이전트는 이제 "로그인 전체를 갈아엎을까?" 같은 위험한 상상을 덜 하게 된다.

좋은 첫 작업은 작지만 끝이 분명해야 한다

처음부터 큰 기능 하나를 통째로 맡기고 싶은 마음은 이해된다. 하지만 첫 위임은 실력 테스트가 아니라 협업 프로토콜 테스트에 가깝다. 따라서 규모보다 경계가 중요하다.

가장 좋은 첫 작업은 작지만 끝이 또렷한 일이다. 예를 들면 이런 종류다.

• 기존 프로젝트를 읽고 구조와 위험 지점을 요약하기

• 특정 UI 깨짐 한 곳 수정하기

• 버튼, 폼 검증, 빈 상태 화면처럼 범위가 제한된 기능 하나 추가하기

• 테스트 하나 보강하고 왜 그 테스트가 필요한지 설명하게 하기

반대로 처음부터 피하면 좋은 일도 있다. 인증 체계 전면 개편, 데이터베이스 마이그레이션, 배포 파이프라인 손보기, 결제 연동 같은 작업이다. 이런 일은 언젠가 맡기게 되겠지만, 첫 미션으로는 너무 넓고 위험하다.

첫 작업의 목적은 "와, 이것도 되네"가 아니라 "아, 이렇게 맡기면 되는구나"를 배우는 것이다.

Plan 모드와 Fast 모드는 속도 버튼이 아니라 사고 방식이다

Antigravity의 두 모드는 단순히 느림과 빠름의 차이가 아니다. Planning은 먼저 생각하고, Fast는 먼저 움직인다. 공식 문서에 따르면 Planning 모드에서 에이전트는 작업을 정리하고 Artifact를 만들며 더 충분히 조사하고 계획한 뒤 실행한다. 반면 Fast 모드는 작업을 바로 실행한다.² Codelab도 복잡한 작업에는 계획 중심 접근을, 단순한 작업에는 즉시 실행 방식을 권한다.¹

이 차이를 몸으로 이해하면 모드 선택이 쉬워진다.

처음 쓰는 사람에게는 아주 단순한 원칙이 좋다. 조금이라도 범위가 넓어 보이면 Plan부터 시작하라. 첫 협업에서는 속도보다 예측 가능성이 더 중요하기 때문이다.

경험담을 곁들이면 더 기억에 남는다. Fast 모드는 숙련된 목수가 삐걱거리는 의자 다리를 바로 고치는 방식이고, Plan 모드는 건축가가 설계도를 먼저 펼치는 방식이다.⁴ 지금 당신의 작업이 의자 다리인지, 건물 골조인지만 구분하면 된다.

첫 프롬프트는 "어떻게"보다 "무엇을" 더 잘 말해야 한다

초보자가 자주 하는 두 번째 실수는 구현 방법까지 너무 촘촘하게 지정하는 것이다. 예를 들어 "bcrypt로 암호화하고, users 테이블을 바꾸고, JWT도 넣고, 라우터도 이렇게 나누고..."처럼 말하면 에이전트는 이미 답이 정해진 시험지를 푸는 학생이 된다.

첫 위임에서는 보통 문제 정의와 제약을 먼저 주는 편이 낫다.⁴ 구현 세부는 Plan에서 에이전트가 제안하게 두고, 당신은 그중 맞는 길을 고르면 된다. 이 방식이 좋은 이유는 두 가지다.

첫째, 에이전트가 더 나은 접근을 제안할 여지가 생긴다. 둘째, 당신도 정말 중요한 제약이 무엇인지 분명히 하게 된다. 예를 들어 "DB 스키마는 바꾸지 말 것", "기존 인증 플로우 유지", "모바일 우선", "외부 라이브러리 추가 금지" 같은 조건은 구현 방법보다 훨씬 중요한 정보다.

좋은 프롬프트는 에이전트를 통제하는 문장이 아니라, 에이전트가 헤매지 않도록 울타리를 세우는 문장이다.

Plan 모드에서 제일 중요한 순간은 승인 직전이다

튜토리얼 흐름에서도 Antigravity는 첫 프로젝트를 만들 때 프롬프트를 받은 뒤 곧바로 코드를 쓰기보다 Implementation Plan을 만들고, 사용자가 이를 검토한 뒤 진행하도록 안내한다.³ 바로 이 순간이 첫 협업의 핵심이다.

많은 사람이 계획을 대충 훑고 바로 승인한다. 하지만 그럼 Planning 모드를 쓴 의미가 크게 줄어든다. 계획을 읽는 이유는 에이전트의 글쓰기 실력을 감상하려는 게 아니다. 코드가 생기기 전에 오해를 잡기 위해서다.

계획을 볼 때는 다음 네 가지 질문만 던져도 충분하다.

• 내가 요청한 문제가 정확히 이해되었는가

• 건드릴 파일과 범위가 과하지 않은가

• 검증 방법이 구체적인가

• 위험한 가정이나 빠진 예외가 없는가

예를 들어 로그인 버튼 버그 하나를 고치는데 계획에 "인증 라이브러리 교체"가 들어 있다면, 그건 벌써 범위가 미끄러진 것이다. 반대로 UI 수정인데도 검증 계획에 스크린샷이나 브라우저 확인이 빠져 있다면, 나중에 다시 확인하느라 한 바퀴 더 돌게 된다.

좋은 리뷰는 길 필요가 없다. 짧아도 선명하면 된다.

인증 방식 교체는 범위 밖입니다. 현재 라이브러리는 유지해 주세요.

모바일 390px 기준 검증도 추가해 주세요.

수정 범위를 로그인 화면과 관련 스타일 파일로 제한해 주세요.

이런 코멘트는 방향을 바로잡는다. 반면 "좀 더 깔끔하게"나 "이건 별로예요"는 사람도 못 알아듣고 에이전트도 못 알아듣는다.

코멘트는 감상이 아니라 조향이다

에이전트와 처음 일할 때는 피드백 문장도 중요하다. 많은 사용자가 결과를 보고 감상부터 남긴다. "괜찮네요", "생각보다 별론데요", "다시 해볼래요?" 같은 말이다. 이런 반응은 인간 동료에게도 어렵고, 에이전트에게는 더 어렵다.

좋은 피드백은 보통 세 조각으로 되어 있다.

• 무엇이 맞았는지: 유지할 부분

• 무엇이 부족한지: 바꿔야 할 부분

• 무엇은 건드리지 말아야 하는지: 보호할 부분

예를 들어 이렇게 말하면 훨씬 잘 작동한다.

방향은 좋습니다. 버튼 터치 영역을 넓힌 접근은 유지해 주세요. 다만 텍스트 크기가 모바일에서 너무 작으니 390px 기준으로 재조정해 주세요. 기존 이메일 로그인 흐름과 색상 토큰은 바꾸지 마세요.

이 문장은 에이전트에게 세 가지를 동시에 알려 준다. 무엇을 칭찬해야 하는지가 아니라, 무엇을 유지하고 무엇을 수정해야 하는지를 알려 준다. 협업은 감탄사가 아니라 기준으로 굴러간다.

첫 결과물은 "말"이 아니라 "증거"로 검토해야 한다

Antigravity는 원래 결과를 증명 가능한 형태로 보여 주도록 설계된 도구다. 그래서 첫 작업이 끝났을 때도 가장 먼저 볼 것은 "다 됐습니다"라는 문장이 아니라, 그 말을 뒷받침하는 흔적이다.¹³

처음에는 아래 순서로 확인하면 충분하다.

• Code diff: 바뀐 범위가 요청한 일에 비해 너무 넓지 않은가

• 테스트 또는 실행 로그: 통과했다고 했을 때 실제로 무엇을 돌렸는가

• 스크린샷이나 브라우저 결과: UI 작업이라면 눈으로 확인 가능한가

• 변경 요약: 왜 이렇게 바꿨는지 설명이 요청과 맞는가

이 순서가 좋은 이유는 단순하다. 결과를 신뢰하는 방식이 문장 읽기에서 증거 읽기로 바뀌기 때문이다. 특히 첫 작업일수록 이 습관이 중요하다. 처음부터 "설명보다 근거"를 요구해야, 이후 에이전트도 자연스럽게 그렇게 일한다.

여기서 한 가지 재미있는 사실이 있다. 초보자는 종종 코드를 전부 다 읽어야 안심된다고 생각한다. 물론 중요한 변경이라면 코드를 읽어야 한다. 하지만 첫 단계에서 더 중요한 건 코드를 전부 읽는 것이 아니라 무엇을 읽어야 할지 좁히는 것이다. 계획이 괜찮고, diff 범위가 적절하고, 검증이 맞다면 읽어야 할 곳도 훨씬 줄어든다.

첫 작업의 피드백 루프는 짧고 자주 돌아야 한다

에이전트 협업은 한 번에 완벽한 결과를 뽑는 게임이 아니다. 오히려 짧은 루프를 빨리 돌리는 편이 훨씬 좋다. Planning으로 방향을 맞추고, 작은 범위로 실행하고, 결과를 검증하고, 다시 한 번 좁게 수정하는 식이다.

이 루프에서 중요한 것은 한 번에 너무 많은 수정 요청을 쌓지 않는 것이다. 첫 위임에서는 특히 그렇다. 열 가지를 한꺼번에 고치라고 하면, 어느 수정이 효과가 있었는지 파악하기 어렵다. 차라리 두세 개의 분명한 조정만 주는 편이 낫다.

예를 들면 이런 식이다.

1차 결과는 기능적으로 맞습니다. 다음 반복에서는 두 가지만 수정해 주세요. 첫째, 모바일 버튼 간격을 8px 늘려 주세요. 둘째, 빈 상태 문구를 더 짧게 바꿔 주세요. 그 외 로직과 파일 구조는 유지해 주세요.

이 정도면 에이전트도 집중하기 쉽고, 당신도 무엇이 바뀌었는지 판단하기 쉽다.

처음 세 번의 위임은 이렇게 가져가면 안전하다

처음부터 모든 걸 잘할 필요는 없다. 대신 순서를 잘 잡으면 된다. 가장 무난한 학습 곡선은 아래와 같다.

첫 번째 위임: 읽기 전용 탐색

프로젝트를 분석하게 하되 수정은 금지한다. 예를 들어 "이 저장소가 무엇을 하는지 설명하고, 주요 폴더 구조와 위험 지점 세 개를 정리해 달라"고 맡긴다. 이 단계에서는 에이전트가 코드를 읽고 맥락을 잡는 방식을 보는 것이 목적이다.

두 번째 위임: 작은 수정 하나

문구 수정, 스타일 깨짐 수정, 간단한 버그 하나처럼 끝이 분명한 일을 맡긴다. 여기서 Plan과 Fast의 차이, diff 검토, 테스트 확인 루프를 익히면 된다.

세 번째 위임: 작은 기능 하나

예를 들어 빈 상태 화면 개선, 필터 추가, 간단한 폼 검증처럼 UI와 로직이 함께 있는 작은 기능을 맡긴다. 이때부터 스크린샷이나 브라우저 검증까지 요구하면 좋다.

이 세 단계를 밟고 나면, 당신은 이미 단순 사용자에서 감독 가능한 협업자로 넘어와 있다.

바로 써먹는 첫 프롬프트 템플릿

아래 템플릿은 대부분의 첫 작업에 무난하게 맞는다.

현재 [프로젝트/화면/기능]에서 [문제 또는 목표]를 해결해 주세요.
범위는 [포함할 것]까지이고, [제외할 것]은 건드리지 말아 주세요.
완료 기준은 [기능 조건], [테스트 조건], [UI 또는 성능 조건]입니다.
먼저 계획을 제시하고, 관련 파일과 검증 방법을 포함해 주세요.
결과에는 변경 요약과 검증 근거를 함께 남겨 주세요.

타겟 독자별로 조금 바꾸면 더 잘 맞는다.

개발자용

현재 React 프로젝트의 설정 화면에서 저장 버튼이 비활성화된 채로 남아 있습니다. 원인을 파악하고 수정해 주세요. 상태 관리 방식은 바꾸지 말고 관련 파일만 최소 범위로 수정해 주세요. 완료 기준은 값 변경 시 버튼이 활성화되고, 저장 후 다시 비활성화되며, 기존 테스트가 통과하는 것입니다. 먼저 계획을 보여 주고 진행해 주세요.

테크 리드·CTO용

이 저장소의 인증 모듈 구조를 읽고, 유지보수 리스크와 개선 우선순위를 정리해 주세요. 아직 코드는 수정하지 말고, 현재 구조 요약, 문제점, 가장 안전한 개선 순서, 예상 영향 범위를 계획 형태로 제시해 주세요.

1인 창업자·PM용

현재 랜딩 페이지에 이메일 수집 폼을 추가해 주세요. 디자인 톤은 기존과 맞추고, 모바일에서도 자연스럽게 보여야 합니다. 외부 백엔드는 붙이지 말고 일단 프론트 UI와 성공 메시지 흐름만 구현해 주세요. 완료 기준과 확인 방법을 포함한 계획부터 보여 주세요.

이 예시들의 공통점은 같다. 거창하지 않다. 대신 목표, 범위, 금지선, 완료 기준이 있다.

결국 첫 위임은 에이전트를 길들이는 일이 아니라, 나를 훈련하는 일이다

Antigravity를 잘 쓰는 사람은 특별한 프롬프트 마법을 아는 사람이 아니다. 일을 작게 나누고, 목표와 제약을 분명히 적고, 계획을 읽고, 결과를 증거로 검토하는 사람이다.

첫 번째 작업 위임의 품질이 중요한 이유도 바로 여기에 있다. 그 한 번의 위임이 이후의 습관을 만든다. 애매하게 맡기면 계속 애매한 결과를 받게 되고, 명확하게 맡기면 점점 더 관리 가능한 협업이 된다.

한 줄로 정리하자. 처음부터 빨리 시키지 말고, 처음부터 정확하게 시켜라. Antigravity에서는 그 차이가 곧 생산성의 차이로 돌아온다.

참고

¹Google Antigravity 시작하기 | Google Codelabs

²Google Antigravity Documentation - Agent modes settings

³Complete Guide to Google Antigravity

⁴Planning vs Fast Mode in Google Antigravity: When and How to Use Each