4부-15장. 코딩 에이전트 시대 — Gemini CLI, Code Assist, Antigravity, Jules

코딩 도구의 주인공은 조금씩 바뀌고 있다. 예전에는 에디터가 중심이었고, 그다음에는 자동완성 기능이 박수받았다. 이제는 한 단계 더 나아갔다. 내가 한 줄씩 입력하는 대신, AI가 계획을 세우고, 파일을 고치고, 테스트를 돌리고, 때로는 브라우저까지 열어 검증하는 시대가 왔다. Gemini CLI, Gemini Code Assist, Antigravity, Jules는 이 변화를 서로 다른 방식으로 보여주는 대표 선수들이다.¹²³⁴

이 장의 핵심은 단순하다. 이제 중요한 것은 코드를 얼마나 많이 외우느냐보다, AI에게 무엇을 만들게 할 수 있느냐다. 문법 암기보다 더 중요한 능력은 문제를 잘게 쪼개고, 요구사항을 분명히 말하고, 결과를 검수하는 힘이다. 한마디로 말하면, 타이핑 실력의 시대에서 지시력의 시대로 넘어가는 중이다.

코딩 보조에서 코딩 에이전트로

기존의 AI 코딩 도구는 주로 옆자리 조수였다. 함수 하나를 완성해 주고, 에러 메시지를 해석해 주고, 비슷한 코드 한 덩어리를 추천해 주는 식이었다. 하지만 코딩 에이전트는 다르다. 이들은 일을 맡길 수 있는 작은 작업자에 가깝다. 프로젝트를 읽고, 변경 계획을 세우고, 여러 파일을 동시에 수정하고, 실패하면 다시 시도한다. 어떤 도구는 터미널에서 움직이고, 어떤 도구는 IDE 안에서 일하고, 어떤 도구는 아예 클라우드에서 백그라운드로 돌아간다.¹⁴⁵

이 차이는 생각보다 크다. 보조 도구를 쓸 때 사용자는 계속 손을 움직여야 한다. 반면 에이전트를 쓸 때 사용자는 감독자가 된다. 목표를 정하고, 중간 결과를 확인하고, 위험한 행동에 승인 버튼을 누른다. 개발자가 감독자로 이동하고 있다는 뜻이다.

물론 여기서 오해하면 안 된다. 감독자는 일이 더 쉬워진 사람이 아니라, 책임이 더 커진 사람이다. AI가 코드를 많이 대신 써줄수록, 사람은 더 정확하게 지시하고 더 냉정하게 검토해야 한다. 실제로 2025년 Stack Overflow 개발자 설문을 보면 많은 개발자가 AI 도구를 쓰거나 쓸 계획이 있었지만, 정확도를 신뢰한다고 답한 비율은 높지 않았고, 가장 큰 불만도 거의 맞지만 완전히 맞지는 않는 결과였다.⁶ AI가 코드를 대신 써준다고 해서 검토까지 면제되는 것은 아니다.

네 도구를 먼저 한 문장으로 이해하자

이 장에서 다룰 네 가지를 아주 짧게 요약하면 이렇다.

• Gemini CLI는 터미널에서 직접 움직이는 오픈소스 작업반장이다.

• Gemini Code Assist는 익숙한 VS Code 안으로 들어온 현장 통역사다.

• Antigravity는 여러 에이전트를 동시에 굴리는 관제탑형 IDE다.

• Jules는 GitHub 저장소를 받아서 백그라운드에서 PR까지 만들어오는 비동기 개발자다.

같은 구글 생태계 안에 있지만 결이 다르다. Gemini CLI와 Code Assist는 지금 당장 내 옆에서 같이 일하는 도구에 가깝고, Antigravity는 복수의 에이전트를 조직하는 작업실에 가깝다. Jules는 맡겨 두고 기다렸다가 결과물을 받는 외주형 에이전트에 가깝다. 이 차이를 이해하면 어떤 상황에 어떤 도구를 써야 하는지가 훨씬 선명해진다.

Gemini CLI — 터미널에서 가장 빠르게 시작하는 에이전트

Gemini CLI는 구글이 공개한 오픈소스 터미널 에이전트다. 개인 구글 계정으로 로그인하면 무료 사용량 안에서 Gemini 모델을 바로 쓸 수 있고, Google Search 그라운딩, 파일 읽기와 쓰기, 셸 명령 실행, 웹 가져오기, MCP 연동 같은 기능을 자연스럽게 연결한다.¹³

이 도구의 매력은 세 가지다. 첫째, 진입 비용이 낮다. 무료 티어가 꽤 넉넉해서 코딩 에이전트를 처음 써보는 사람도 부담 없이 맛볼 수 있다. 둘째, 터미널 중심 워크플로와 잘 맞는다. 이미 git, npm, python, docker를 자주 쓰는 사람이라면 손이 거의 안 끊긴다. 셋째, 단순한 채팅이 아니라 실제 행동으로 이어진다. 계획을 세운 뒤 바꾸고, 파일을 수정하고, 테스트를 실행하고, 스크립트 모드로 자동화까지 붙일 수 있다.¹³

특히 Gemini CLI는 단순히 코드를 쓰는 도구가 아니다. 공식 문서가 강조하듯, 콘텐츠 생성, 문제 해결, 심층 조사, 작업 관리 같은 범용 로컬 유틸리티로도 쓸 수 있다.² 즉, 이 도구는 개발자만의 망치가 아니라, 1인 크리에이터에게는 작은 만능 공구 상자에 가깝다.

재미있는 지점은 Plan Mode다. 예전 AI 코딩 도구는 성급한 인턴처럼 바로 파일부터 만지는 경우가 많았다. 반면 계획 모드는 먼저 무엇을 바꿀지, 어떤 파일을 건드릴지, 어떤 테스트가 필요한지를 제안한다. 사용자는 여기서 방향을 수정할 수 있다. 이 한 단계가 사고를 꽤 많이 줄인다.⁷

다만 약점도 있다. 터미널이 낯선 사람에게는 첫인상이 차갑다. 또 무료라고 해서 무한정 쓸 수 있는 것도 아니다. 개인 계정 기반 무료 사용량은 충분히 실용적이지만, 여러 세션을 동시에 돌리거나 장시간 대형 작업을 맡기면 금방 한계가 온다.¹³ 그래서 Gemini CLI는 입문과 일상 작업에는 매우 강하지만, 팀 단위 고강도 운영에서는 API 키나 Vertex AI 같은 다음 단계 선택이 필요해진다.

Gemini Code Assist — 같은 엔진, 더 익숙한 운전석

Gemini Code Assist를 이해하는 가장 쉬운 방법은 이렇다. Gemini CLI의 강한 엔진을 VS Code 안에 넣은 버전이라고 생각하면 된다. 공식 문서에 따르면 VS Code의 Gemini Code Assist 에이전트 모드는 Gemini CLI를 기반으로 하며, MCP 서버, 메모리 관련 명령, 내장 도구, 웹 검색, 웹 가져오기 등 CLI의 핵심 기능을 IDE 안에서도 활용할 수 있다.²

이 말은 무엇을 뜻할까. 터미널이 무서운 사람도 에이전트 시대의 이점을 놓칠 필요가 없다는 뜻이다. 사이드바 채팅에 자연어로 지시하면 AI가 파일을 읽고, 수정하고, 필요한 도구를 호출하면서 일한다. 동시에 사용자는 익숙한 에디터 화면에서 diff를 보고, 파일 구조를 보고, 직접 손으로 마무리할 수 있다.

Code Assist의 장점은 속도보다 심리적 안전감이다. 터미널은 잘못 치면 모든 것이 무서워 보이지만, IDE는 눈으로 보인다. 보이는 것은 안심을 만든다. 그래서 비개발자, 혹은 개발 경험이 적은 실무자에게는 Code Assist가 Gemini CLI보다 더 좋은 첫 번째 선택일 수 있다.

또 하나 중요한 포인트는 할당량이 CLI와 에이전트 모드 사이에서 공유된다는 점이다.² 즉, 같은 엔진을 여러 창에서 동시에 돌릴수록 체감 소모도 커진다. 실전에서는 도구를 많이 여는 것보다, 지금 어떤 창이 메인 작업장인지 정하는 편이 낫다. 에이전트를 다섯 명 불러놓고 감독이 한 명도 못 따라가면 생산성이 아니라 소음만 늘어난다.

Antigravity — 코딩 도구가 아니라 에이전트 관제탑

Antigravity는 이름부터 심상치 않지만, 구조도 꽤 독특하다. 구글 Codelab 설명을 보면 Antigravity는 단순한 자동완성 도구가 아니라, 계획하고, 코딩하고, 웹을 탐색하며, 여러 자율 에이전트를 관리하는 에이전트 중심 개발 플랫폼이다.⁴ 쉽게 말해, 에디터가 주인공이 아니라 에이전트가 주인공인 IDE다.

여기서 핵심 개념은 Agent Manager다. 보통 IDE는 파일 트리와 코드 창이 중심이다. 그런데 Antigravity는 여러 에이전트의 상태, 작업 계획, 산출물, 승인 요청을 한눈에 보는 미션 컨트롤 성격이 강하다.⁴ 한 명의 개발자가 코드를 직접 치는 대신, 여러 AI 작업자에게 각기 다른 임무를 보내고 동시에 진행 상황을 본다. 마치 혼자 일하는 것이 아니라 작은 개발 팀을 운영하는 느낌에 가깝다.

이 도구가 특히 인상적인 부분은 브라우저 서브에이전트와 아티팩트 체계다. 브라우저 서브에이전트는 클릭, 스크롤, 입력, 로그 읽기 같은 행동으로 실제 웹페이지를 검증하고, 아티팩트는 작업 계획, 구현 계획, 코드 diff, 스크린샷, 브라우저 녹화까지 남긴다.⁴ 쉽게 말해 AI가 그냥 잘했다고 말로 보고하는 것이 아니라, 증거 봉투까지 같이 들고 오는 셈이다.

비개발자에게 Antigravity가 매력적인 이유도 여기에 있다. 코드를 다 읽지 못해도, 계획 문서와 스크린샷, 녹화본을 통해 결과를 검수할 수 있다. 완벽하지는 않지만, 적어도 검토의 문턱을 크게 낮춘다. 코드를 모르면 아무것도 못 보던 시대에서, 이제는 산출물과 행동 기록을 보고도 상당 부분 판단할 수 있는 시대로 가는 것이다.

반면 단점도 분명하다. 자율성이 높을수록 설정과 승인 정책이 중요해진다. 터미널 실행을 어디까지 허용할지, 브라우저에서 자바스크립트 실행을 자동 승인할지, 어떤 단계마다 검토를 끼워 넣을지 결정해야 한다.⁴ 다시 말해, Antigravity는 강력하지만 설정을 아무 생각 없이 넘기면 곤란한 도구다. 잘 훈련된 팀장에게는 훌륭한 관제탑이지만, 아무 준비 없는 초보자에게는 너무 많은 버튼이 달린 조종석이 될 수도 있다.

Jules — 백그라운드에서 PR을 만들어오는 비동기 에이전트

Jules는 이 장의 네 도구 중 가장 성격이 다르다. Gemini CLI나 Code Assist, Antigravity가 지금 내 눈앞에서 같이 일하는 동료라면, Jules는 일을 맡겨놓고 나중에 결과를 받는 비동기 에이전트다. 구글 설명에 따르면 Jules는 저장소를 안전한 Google Cloud VM에 복제한 뒤, 프로젝트 전체 문맥을 이해하고 테스트 작성, 기능 추가, 버그 수정, 의존성 업데이트 같은 작업을 수행하며, 완료 후에는 계획과 추론 과정, diff를 보여준다.⁵

이 구조는 아주 현실적이다. 사람이 늘 화면 앞에 붙어 있을 필요가 없다. 오전에 이슈 세 개를 던져놓고, 오후에 돌아와 PR 세 개를 검토하는 식의 흐름이 가능해진다. GitHub 워크플로에 바로 붙고, 병렬 작업도 가능하며, 오디오 체인지로그 같은 기능으로 최근 변경점을 요약해 주기도 한다.⁵

Jules를 잘 쓰는 사람은 주로 이런 유형이다. 첫째, 저장소 관리가 중심인 개발자. 둘째, 반복적 유지보수 이슈가 많은 팀. 셋째, 직접 코드를 치는 시간보다 검토와 승인 시간이 더 중요한 사람이다. 반대로, 방금 떠오른 아이디어를 10분 안에 바로 실험해 보고 싶다면 Jules보다는 CLI나 IDE형 도구가 더 낫다. Jules는 빠른 핑퐁보다 맡기고 기다리는 리듬에 잘 맞는다.

이 점에서 Jules는 코딩 도구라기보다 개발 프로세스 도구에 가깝다. 직접 만드는 손보다, 파이프라인에 투입되는 자동 작업자에 가깝기 때문이다.

Claude Code, Codex, Aider와 비교하면 제미나이 진영은 어디에 서 있나

코딩 에이전트 시장은 이미 혼전이다. Claude Code는 대규모 코드베이스 이해와 복잡한 멀티파일 리팩터링에서 강한 평가를 받고, Codex 계열은 샌드박스 실행과 자동화 흐름에서 장점이 있으며, Aider는 여러 모델을 갈아 끼우는 유연성과 git 워크플로로 사랑받는다.⁷ 그 사이에서 Gemini 진영의 포지션은 꽤 선명하다.

제미나이 쪽의 가장 큰 무기는 진입장벽이 낮다는 점이다. Gemini CLI는 무료 시작점이 좋고, Code Assist는 익숙한 IDE 안으로 그 힘을 들여오며, Antigravity는 에이전트 중심 IDE라는 새로운 형태를 밀고, Jules는 비동기 GitHub 작업자로 분화한다. 한마디로 같은 생태계 안에서 도구의 배치가 촘촘하다.

반대로 절대적인 장점만 있는 것은 아니다. 복잡하고 지저분한 대규모 리팩터링에서 여전히 Claude Code를 선호하는 목소리는 많다.⁷ 그리고 안전한 격리 실행이 최우선인 자동화 파이프라인에서는 Codex류의 샌드박스 철학이 더 편한 경우도 있다.⁷ 따라서 현실적인 답은 하나의 도구로 통일하는 것이 아니라, 작업 종류에 따라 라우팅하는 것이다.

가볍게 정리하면 이렇다. 탐색과 초안은 Gemini CLI나 Code Assist, 에이전트 운영과 검증은 Antigravity, 저장소 기반 백그라운드 작업은 Jules, 아주 복잡한 리팩터링은 Claude Code, 격리된 자동 실행은 Codex 쪽이 어울리는 경우가 많다. 시대의 정답은 올인보다 조합이다.

비개발자도 바이브 코딩으로 도구를 만들 수 있을까

대답은 그렇다. 다만 여기서 중요한 단어는 앱이 아니라 작은 도구다.

비개발자가 가장 많이 실패하는 이유는 첫 프로젝트가 너무 크기 때문이다. 처음부터 SaaS를 만들고, 결제를 붙이고, 회원가입을 붙이고, 관리자 페이지를 만들고, 모바일 대응까지 하려 한다. 그러면 AI도 흔들리고 사람도 흔들린다. 바이브 코딩은 마술이 아니라 압축된 협업이다. 잘 되려면 범위를 작게 잡아야 한다.

비개발자에게 가장 좋은 첫 번째 프로젝트는 이런 종류다. 파일 이름 일괄 변경기, CSV 정리 웹앱, 유튜브 스크립트 정리기, 블로그 초안 생성기, 견적서 자동 작성기, 구글 시트 데이터를 읽어 요약 리포트를 만드는 도구 같은 것들이다. 문제 정의가 분명하고, 입력과 출력이 선명하고, 실패했을 때 피해가 작다. 이런 도구는 AI가 만들기도 쉽고 사람이 검수하기도 쉽다.

여기서 꼭 기억할 원칙이 있다. 바이브 코딩의 핵심은 코드를 안 보는 것이 아니라, 코드를 전부 이해하지 못해도 제품을 전진시키는 것이다. 즉, 비개발자도 최소한 다음 네 가지는 알아야 한다.

• 이 도구가 무엇을 해야 하는지 한 문장으로 설명할 수 있어야 한다.

• 어떤 입력이 들어오고 어떤 출력이 나와야 하는지 말할 수 있어야 한다.

• 망가졌을 때 무엇이 잘못된 것인지 예시로 보여줄 수 있어야 한다.

• 최소한의 테스트 시나리오를 만들 수 있어야 한다.

문법보다 이것이 더 중요하다. AI에게 함수 하나를 잘 쓰게 하는 능력보다, 어떤 도구를 왜 만드는지 분명히 말하게 하는 능력이 훨씬 큰 차이를 만든다.

30분 실전: 비개발자가 만드는 첫 번째 도구

가장 추천하는 입문 과제는 로컬에서 돌아가는 간단한 콘텐츠 정리기다. 예를 들어 폴더에 넣은 텍스트 파일 여러 개를 읽어서, 제목 후보를 뽑고, 핵심 문장을 요약하고, 중복 아이디어를 묶어 주는 작은 도구를 만든다고 해보자. 이 정도면 1인 크리에이터에게 바로 쓸모가 있다.

작업 흐름은 생각보다 단순하다. 먼저 Code Assist나 Antigravity에서 이렇게 지시한다. 한국어 UI를 가진 데스크톱 또는 웹앱을 만들고, txt와 md 파일을 업로드할 수 있게 하고, 각 파일의 제목 후보 세 개와 5문장 요약을 만들고, 비슷한 주제를 묶어 하나의 표로 보여 달라고 요청한다. 그리고 결과는 CSV로 내보낼 수 있게 해 달라고 덧붙인다.

그다음 바로 코드를 더 만들게 하지 말고, 구현 계획을 먼저 보라고 한다. 어떤 파일 구조로 만들지, 어떤 라이브러리를 쓸지, 업로드 제한은 어떻게 할지, 오류 메시지는 어떻게 표시할지 확인한다. 여기서 계획이 이상하면 코드는 그보다 더 이상해진다.

세 번째는 테스트다. 샘플 텍스트 세 개를 준비해 넣어 본다. 서로 비슷한 글 두 개와 전혀 다른 글 하나를 넣고, 묶음이 제대로 되는지 본다. 파일이 비어 있을 때 어떻게 되는지, 지나치게 긴 파일은 어떻게 처리하는지, 한글 인코딩이 깨지지 않는지도 확인한다. 이 단계에서 문제를 잡으면 이후 고생이 크게 줄어든다.

마지막은 배포보다 저장이다. 첫 프로젝트는 세상에 공개하는 것보다, 내 컴퓨터에서 안정적으로 다시 실행되는지가 더 중요하다. 바이브 코딩 초보가 가장 많이 놓치는 장면은 첫 시연에 성공하고 다음 날 다시 켜 보니 안 되는 순간이다. 그래서 첫 도구는 반드시 실행 방법을 README로 남기게 해야 한다. 설치, 실행, 입력 예시, 오류 대응을 한글로 써 달라고 AI에게 시키면 된다.

이 과정을 해보면 깨닫게 된다. 내가 코드를 줄줄 쓰지 않았어도, 문제 정의와 검수만으로 충분히 제품을 움직일 수 있다는 사실을 말이다. 바로 여기서 자신감이 생긴다.

현실적인 선택지: 누가 무엇부터 써야 하나

비개발자이지만 작은 자동화 도구를 빨리 만들고 싶다면, 가장 현실적인 시작점은 Gemini Code Assist나 Antigravity다. 화면이 보이고, 수정 사항을 확인하기 쉽고, 계획과 결과를 눈으로 검토할 수 있기 때문이다.²⁴ 터미널이 익숙한 사람이라면 Gemini CLI가 더 빠르고 가볍다.¹³

이미 GitHub 저장소를 운영하고 있고, 반복적인 버그 수정이나 테스트 보강을 자동화하고 싶다면 Jules가 좋다. 직접 붙어서 대화하기보다 일을 맡기고 PR로 받는 흐름이 잘 맞는다.⁵

비용을 최소화하고 싶다면 Gemini CLI의 무료 시작점은 여전히 매력적이다. 다만 무료는 입장권이지 무한 패스가 아니다. 개인 실험과 소규모 도구 제작에는 훌륭하지만, 여러 에이전트를 동시에 오래 돌리는 순간부터는 유료 키, 조직용 라이선스, 혹은 다른 도구와의 혼합 운용이 현실적이 된다.¹²³

그리고 정말 중요한 한 가지. 비개발자라고 해서 반드시 GUI 도구만 써야 하는 것은 아니다. 처음에는 Code Assist나 Antigravity로 시작하고, 익숙해지면 Gemini CLI로 내려오는 것이 좋다. 높은 곳에서 아래로 내려오는 것이 아니라, 쉬운 인터페이스에서 본질을 익힌 뒤 더 빠른 도구로 이동하는 것이다.

결국 남는 사람은 코더가 아니라 지휘자다

코딩 에이전트 시대의 진짜 변화는 생산 속도만이 아니다. 역할의 재편이다. 사람은 점점 더 설계자, 검수자, 우선순위 결정자, 품질 책임자가 된다. 반대로 AI는 구현자, 초안 작성자, 반복 작업자, 실험 담당자가 된다.

이 변화는 개발자에게만 해당하지 않는다. 기획자, 마케터, 작가, 강사, 운영자에게도 같다. 업무를 작은 도구로 바꾸는 감각이 있는 사람, AI에게 모호하지 않게 시키는 사람, 결과를 냉정하게 검토하는 사람이 점점 더 강해진다.

그래서 이제 중요한 것은 코드를 얼마나 많이 아느냐보다, AI에게 무엇을 만들게 하느냐다. 좋은 질문을 하는 사람, 좋은 기준을 세우는 사람, 좋은 검수 습관을 가진 사람이 결국 더 많은 것을 만든다. 에이전트 시대의 경쟁력은 손가락 속도가 아니라 문제를 제품으로 번역하는 능력이다.

그리고 그 능력은 개발자만의 전유물이 아니다. 오늘 작은 도구 하나를 만들어 본 사람에게서부터, 이미 새로운 시대는 시작되고 있다.

참고

¹Gemini CLI 소개

²Gemini Code Assist의 Gemini CLI 문서

³Gemini CLI GitHub 저장소

⁴Google Antigravity 시작하기

⁵Jules 공개 베타 소개

⁶Stack Overflow Developer Survey 2025 AI 섹션

⁷Top 5 Terminal AI Coding Agents in 2026