왜 '코딩'에서 '오케스트레이션'으로 바뀌는가

개발이 어려운 이유는 대개 "코드를 모른다"가 아니라 "코드만으로 끝나지 않는다"에 있습니다. 기능 하나를 배포하려면 코드를 쓰는 시간보다 더 많은 시간이 계획, 실행 환경 준비, 테스트, 재현, 검증, 문서화, 배포 확인으로 흩어집니다. 그래서 최근 도구의 목표도 "코드를 더 빨리 치게 해주는 것"에서 "끝까지 완주하게 해주는 것"으로 옮겨가고 있습니다. Google은 이를 코딩이 아니라 오케스트레이션(orchestration)의 문제로 정의합니다.¹

이 챕터의 목표는 간단합니다. Antigravity를 '어떻게' 쓰기 전에, 무엇을 대신 맡길지를 선명하게 만드는 것입니다. 무엇을 위임할지 정해지면, 이후 챕터의 기능(에이전트, 서피스, 아티팩트, 규칙/워크플로)이 한 장의 그림으로 연결됩니다.

코딩은 '부분 최적화'가 되기 쉬워졌다

전통적인 IDE의 중심은 편집기입니다. 코드를 쓰고, 저장하고, 빌드하고, 실패하면 로그를 보고 다시 고치는 반복이 핵심 루프였죠. 여기에 자동완성과 코드 스니펫, 린트, 리팩터링 도구가 더해지며 "타이핑"은 분명 빨라졌습니다.

하지만 요즘 개발의 병목은 타이핑이 아닙니다. 병목은 대개 다음 지점에서 생깁니다.

• 어떤 변경이 필요한지 계획을 세우는 일(요구사항 해석, 영향 범위 파악)

• 변경을 실제로 실행하는 일(여러 파일 수정, 커맨드 실행, 환경 조정)

• 변경이 맞는지 검증하는 일(테스트, 재현 절차, UI 확인, 배포 후 점검)

즉, "코딩을 더 잘"하는 것만으로는 흐름이 매끄러워지지 않습니다. 개발자는 계속해서 다른 도구와 다른 화면으로 이동하며, 머릿속에서 상태를 들고 다녀야 합니다. 여기서부터 오케스트레이션이 필요해집니다.

개발 흐름을 깨뜨리는 3가지: 컨텍스트 스위칭, 장기 작업, 검증 부담

Antigravity가 겨냥하는 문제를 개발 흐름 관점에서 정리하면 세 가지로 수렴합니다.

1) 컨텍스트 스위칭: '화면 이동'이 아니라 '상태 이동'

개발 중에 IDE, 터미널, 브라우저, 클라우드 콘솔, 문서, 이슈 트래커를 오갑니다. 문제는 탭을 옮기는 행위가 아니라, 탭을 옮길 때마다 "지금 무엇을 하던 중이었지?"라는 상태 복원 비용이 발생한다는 점입니다.

Google은 Antigravity가 에이전트가 에디터·터미널·브라우저를 가로질러 작업을 계획/실행/검증할 수 있도록 설계되었다고 말합니다.¹ 이 말의 핵심은 "화면을 하나로 합친다"가 아니라, 작업의 단위를 '도구'가 아니라 '목표'로 바꾼다는 것입니다.

2) 장기 작업: 개발자의 하루는 '대기'로 찢어진다

버그 재현, 레거시 모듈 리팩터링, 테스트 스위트 확장, 배포 파이프라인 손보기 같은 일은 길어집니다. 길어진다는 것은 단순히 시간이 오래 걸린다는 뜻이 아니라, 중간에 끼어드는 일(회의, 리뷰, 긴급 장애, 메시지)에 의해 작업이 자주 끊긴다는 뜻입니다.

기존 챗봇형 도구는 대체로 동기적입니다. 내가 보고 있는 동안만 의미가 있고, 작업을 "맡겨두고" 다른 일을 하기 어렵습니다. 반면 Antigravity는 에이전트가 복잡한 작업을 수행하는 동안 생성물(계획, 결과, 증거)을 남기고, 사용자는 그 흐름을 비동기로 관찰하며 개입하는 방식으로 설계되어 있습니다. 코딩이 아니라 운영(운용)의 감각이 들어오는 지점입니다.¹

3) 검증 부담: 로그를 읽는 시간이 신뢰의 비용이 된다

에이전트가 코드를 바꿔줄수록, 개발자의 역할은 "작성자"에서 "검증자"로 이동합니다. 그런데 검증을 로그와 대화 기록으로만 하려면, 결국 사람이 다시 모든 것을 훑어야 합니다. 이때 생기는 피로가 'AI 도구를 쓰면 더 바빠지는' 역설을 만들죠.

Antigravity는 이 지점을 Artifacts로 검증하라고 정면으로 제안합니다. 즉, 원시 로그를 스크롤하는 대신 작업 목록, 구현 계획, 스크린샷, 브라우저 녹화 같은 검토 가능한 산출물을 에이전트가 만들어 신뢰를 구축하는 방식입니다.¹²

'오케스트레이션'은 무엇을 의미하는가

오케스트레이션은 멋진 말이 아니라, 개발의 책임 분리를 다시 그리는 단어입니다.

• 개발자는 목표를 정의하고, 제약을 걸고, 결과를 승인합니다.

• 에이전트는 목표를 달성하기 위한 계획을 세우고, 필요한 도구를 호출해 실행하고, 증거를 남깁니다.

이 구조가 성립하려면 에이전트가 단순한 사이드바 챗봇이 아니라, 일할 공간과 감독할 공간을 가져야 합니다. Antigravity는 이를 위해 두 가지 상호작용 방식을 분리합니다. 손으로 코드를 만질 때의 Editor View, 그리고 에이전트를 생성·관찰·오케스트레이션하는 Manager Surface(Agent Manager)입니다.¹²

ctrl+E 로 매니저 서페이스로 진입할 수 있다. (에디터가 안보이고 에이전트 작업들만 볼 수 있는 UI)

여기서 관점이 바뀝니다. 이제 IDE의 중심은 "파일 트리"가 아니라 "진행 중인 작업들"이 됩니다. 이를 '미션 컨트롤'이라고 부르며, 여러 에이전트를 비동기로 띄워 병렬 처리할 수 있습니다.²

Antigravity를 쓰기 전에, '무엇을 대신 맡길지'부터 정하자

Antigravity를 처음 열면 유혹이 있습니다. "일단 에이전트에게 다 시켜보자." 하지만 오케스트레이션 도구는 역설적으로, 위임 범위가 흐릿하면 품질도 흐릿해집니다. 그래서 시작점은 기능 학습이 아니라 위임 설계입니다.

가장 효과적인 질문은 "무엇을 구현해줘"가 아니라, "이 작업에서 사람(나)이 해야 할 판단은 무엇이고, 에이전트가 대신해도 되는 노동은 무엇인가"입니다.

아래 세 가지를 미리 결정해 두면, Antigravity의 장점이 바로 드러납니다.

• 대신 맡길 일(노동): 반복 수정, 파일 생성/정리, 명령 실행, 재현 절차 수행, 스크린샷/녹화로 UI 확인 같은 실행형 작업

• 내가 붙잡을 일(판단): 요구사항 해석, API/아키텍처 선택, 팀 규칙/보안 경계, 최종 승인(merge/release)

• 검증 기준(증거): "테스트 통과"인지, "특정 화면 상태의 스크린샷"인지, "재현 단계와 결과 기록"인지 같은 승인 조건

이렇게 역할을 나누면, 이후의 대화 방식도 달라집니다. 예를 들어 "로그인 버튼 색을 바꿔줘"가 아니라 "버튼 색을 바꾸고, 변경 전/후 스크린샷을 아티팩트로 남겨줘. 그리고 접근성 대비도 함께 확인해줘"처럼 결과 + 증거를 함께 요구하게 됩니다. Antigravity가 아티팩트를 중심으로 신뢰를 만든다는 설명은 바로 이 사용 습관을 전제로 합니다.²

새로운 기본 루프: Plan–Execute–Verify를 '작업 단위'로 돌린다

정리하면, 오케스트레이션 시대의 개발 루프는 파일 단위가 아니라 작업 단위로 굴러갑니다.

Manager Surface에서 작업을 던지고, 에이전트가 계획을 만들고(Plan), 여러 서피스에서 실행하고(Execute), 아티팩트로 검증 가능한 형태로 남깁니다(Verify). 그리고 개발자는 그 산출물에 코멘트로 방향을 수정합니다.¹²

이 루프가 안정적으로 돌기 시작하면, Antigravity를 쓰는 이유가 바뀝니다. "코드를 빨리 얻기 위해"가 아니라, 컨텍스트 스위칭을 줄이고, 장기 작업을 백그라운드로 넘기고, 검증을 산출물 중심으로 바꾸기 위해 쓰게 됩니다.

다음 챕터부터는 이 루프를 실제로 굴리기 위한 준비로 들어갑니다. 설치와 첫 실행을 마치면, 곧바로 '오케스트레이션을 위한 화면 구조'가 왜 그렇게 설계됐는지 체감하게 될 것입니다.

참고

¹Build with Google Antigravity, our new agentic development platform

²Google Antigravity 시작하기 | Google Codelabs