Google Jules가 뭔지 모르면 손해인 이유

Google Jules는 GitHub 저장소에 직접 접속해 버그를 고치고, 의존성을 업데이트하고, 새로운 기능을 구현하는 자율 코딩 에이전트입니다. 2025년 5월 19일 출시됐고, 같은 해 8월 6일 정식 베타 종료 선언 이후 유료 플랜 체계가 정비됐습니다. (출처: Jules 공식 changelog)

태스크를 맡기면 Jules는 독립된 클라우드 VM 안에서 저장소를 클론하고, 의존성 설치, 코드 변경, 테스트 실행까지 혼자 처리합니다. 끝나면 Pull Request를 열어줍니다. 내가 자리를 비운 사이에 PR이 열려 있다는 게 핵심입니다. Cursor나 GitHub Copilot처럼 편집기 안에서 같이 작업하는 방식이 아닙니다. 완전한 비동기 실행입니다.

2026년 3월 현재 기준으로 지원 언어는 JavaScript/TypeScript, Python, Go, Java, Rust이며, VM 디스크 공간은 20GB입니다. (출처: Jules 공식 FAQ) 20GB는 대형 의존성 프로젝트도 웬만하면 소화합니다.

무료 플랜으로도 충분히 쓸 수 있는 조건이 있습니다

요금제 구조부터 직접 확인해봤습니다. Jules 공식 문서(usage-limits)에 따르면 플랜은 세 가지입니다.

공식 문서상 무료 플랜의 기본 모델은 Gemini 2.5 Pro로 표기되어 있습니다. 그런데 changelog를 보면 2026년 1월 30일에 “전 사용자 대상으로 Gemini 3 Flash를 기본 모델로 전환”했다고 나옵니다. (출처: Jules changelog, 2026.01.30) 이게 중요한 부분입니다. 문서 표에서 “Gemini 2.5 Pro”라고 쓰인 건 플랜 비교용 기준 표기이고, 실제 작동 모델은 이미 Gemini 3 계열로 올라가 있습니다.

단, 무료 플랜 접근에는 조건이 붙습니다. 현재 Google AI 플랜은 개인 Gmail 계정(@gmail.com)에서만 유료 업그레이드가 가능합니다. Google Workspace나 기업 계정에서는 아직 유료 플랜 전환이 지원되지 않습니다. 이 부분은 Jules 요금 공식 문서에 직접 명시되어 있습니다.

Planning Critic, 숫자로 확인한 실패율 감소

솔직히 “AI가 계획을 세운다”는 말은 많이 들어봤지만, Jules는 2026년 1월 26일에 구체적인 수치를 공개했습니다. Planning Critic이라는 2차 에이전트를 도입한 후 태스크 실패율이 9.5% 감소했다는 내용입니다. (출처: Jules changelog, 2026.01.26) 코딩 에이전트 실패율 9.5% 감소는 실제 작업량으로 따지면 꽤 큰 숫자입니다.

Planning Critic의 작동 방식은 이렇습니다. Jules는 태스크를 시작할 때 먼저 계획을 제안하고 사람의 승인을 기다립니다. 그런데 “자동 승인(Auto-Approved)” 설정이 켜진 경우, 사람 대신 Planning Critic이라는 2차 에이전트가 계획을 먼저 검토하고 다듬습니다. 코드 한 줄 실행 전에 계획 자체를 갈아엎는 구조입니다. 계획 단계에서 시간이 약간 더 걸리지만, 그 대가로 실행 실패율이 9.5% 줄었습니다.

이 숫자가 체감으로 어떤 의미인지 생각해보면, 하루에 100개 태스크를 돌리는 Pro 사용자 기준으로 하루 약 9~10개의 실패 태스크가 사라진다는 뜻입니다. 재시도 비용, 컨텍스트 재구성 시간을 합치면 실질 절감 효과는 훨씬 큽니다.

GitHub 없어도 됩니다 — Repoless 모드의 진짜 의미

Jules를 쓰려면 GitHub 저장소가 필요하다는 인식이 퍼져 있습니다. 그런데 2025년 11월 20일부터는 저장소 없이도 태스크를 시작할 수 있는 Repoless 모드가 생겼습니다. (출처: Jules changelog, 2025.11.20) 기존에는 아이디어가 생겼을 때 GitHub에 빈 저장소를 먼저 만들어야 Jules를 실행할 수 있었습니다.

Repoless 모드는 단순히 저장소 선택 단계를 건너뛰는 게 아닙니다. 2026년 1월 26일 changelog에는 이런 설명이 나옵니다. “Repoless 세션은 사실상 서버리스가 됩니다. Node, Python, Rust, Bun 등 런타임이 사전 로드된 임시 클라우드 개발 환경이 생성되며, API 한 번 호출로 이 환경을 띄울 수 있습니다.” (출처: Jules changelog, 2026.01.26) 프롬프트 안에 있는 컨텍스트만으로 환경이 만들어지고 작업이 끝나면 파일 결과물을 다운로드할 수 있습니다.

Repoless + REST API 조합이 흥미로운 이유

Jules API는 2025년 10월 3일에 정식 출시됐습니다. Repoless 지원이 REST API까지 연결되면, 하나의 API 호출로 서버리스 개발 환경을 띄우고, AI 코딩 에이전트가 코드를 짜고, 결과물을 받아서 파이프라인에 넣는 흐름이 가능해집니다. GitHub 연동 없이도 CI/CD에 Jules를 녹여넣을 수 있다는 뜻입니다. 기존에 코딩 에이전트를 “저장소가 있는 개발자 도구”로만 봤다면 이건 다른 차원의 이야기입니다.

단, 현재 Repoless 모드에서 생성된 파일은 작업이 끝난 후 직접 다운로드해야 합니다. 자동으로 GitHub에 올라가지 않습니다. 이 부분은 기대했던 것과 다를 수 있습니다.

“자율 실행”인데 보안은 괜찮을까요?

보안 연구자 Johann Rehberger가 2025년 5월에 Google Jules의 데이터 유출 취약점을 발견하고 Google에 제보했습니다. 핵심은 두 가지였습니다. 첫째, Jules가 마크다운 이미지를 렌더링할 때 외부 URL 요청이 제한 없이 나가는 구조여서, 프롬프트 인젝션 공격자가 이를 이용해 세션 내 정보를 외부 서버로 빼낼 수 있었습니다. 둘째, view_text_website라는 도구를 통해 Jules가 접근할 수 있는 파일을 읽고 외부 서버로 전송하는 게 가능했습니다. (출처: embracethered.com, 2025.08.13)

특히 이 공격이 계획 승인 단계를 우회해서 사전에 작동했다는 점이 문제였습니다. Jules는 계획을 먼저 사람에게 보여주는 구조라 “계획에서 수상한 URL이 나오면 막을 수 있다”는 기대가 있었는데, 이 우회 공격은 계획 단계 전에 이미 완료됐습니다.

그럼 지금은 안전할까요?

연구자는 제보 후 Google이 작성 내용을 사전 공개하도록 요청했다고 밝혔으나, 게시 시점까지 패치 완료 여부를 확인받지 못했다고 적었습니다. Jules 공식 FAQ는 “VM은 안전한 클라우드 환경에서 실행되지만, API 키 같은 민감 정보는 저장소에 커밋하지 말 것”을 사용자 책임으로 명시하고 있습니다. (출처: jules.google/docs/faq/) 이 부분은 단순 주의 사항이 아니라 실제 공격 경로와 직결되는 내용입니다.

막상 써보면 강력하지만, 저장소에 API 키나 인증 토큰이 있는 상태에서 Julius에게 GitHub Issues를 자동으로 처리하게 맡기는 건 지금 단계에서 조심할 필요가 있습니다. 이게 아쉬웠습니다.

Gemini CLI + Jules, 2026년 3월 실제 스택

Google 개발자 Rowan Merewood가 2026년 3월 15일 dev.to에 공개한 실사용 스택 글에 주목할 만한 관찰이 있습니다. 그는 Gemini CLI와 Jules를 이렇게 나눠 씁니다. Gemini CLI는 터미널에서 직접 함께 작업하는 “활성 페어 프로그래밍”에, Jules는 백그라운드에서 돌아가는 “비동기 서제스천과 스케줄 태스크”에 씁니다. (출처: dev.to, 2026.03.15)

실제로 그가 경험한 Jules의 패턴은 이렇습니다. 성능 개선 에이전트가 코드를 최적화하면, 나중에 보안 에이전트가 와서 해당 코드를 이전 방식으로 되돌리는 일이 생겼습니다. 같은 파일을 건드리는 복수의 제안을 동시에 실행하면 병합 충돌이 납니다. Jules를 쓰려면 한 번에 한 에이전트씩 실행하는 습관이 필요합니다.

한편 2026년 2월 19일에 추가된 CI Fixer는 Jules가 만든 PR에서 GitHub Actions 체크가 실패하면 Jules가 오류 로그를 받아 자동으로 수정하고 재제출하는 기능입니다. (출처: Jules changelog, 2026.02.19) 사람이 로그를 복사해서 다시 Jules에 붙여넣는 수고가 사라진 셈입니다.

또 2026년 2월 2일에는 MCP 서버 연동이 추가됐습니다. Linear, Supabase, Neon, Tinybird, Stitch, Context7 여섯 가지를 지원하며, 보안상의 이유로 현재는 Google이 직접 검증한 서버로만 제한합니다. 이 제한은 앞서 확인한 데이터 유출 취약점 이슈와 맥락이 연결됩니다. 외부 서비스와 연결되는 도구를 선별적으로 허용하는 방식은 사실 보안 문제에 대한 현실적인 대응이기도 합니다.

Q&A

마치며

Google Jules는 2025년 5월 출시 이후 거의 매달 굵직한 업데이트가 있었습니다. Gemini 3 Flash 기본 모델 적용, Planning Critic, Repoless 모드, MCP 서버 연동, CI Fixer까지 반 년 만에 상당히 빨리 달려왔습니다.

개인적인 평가를 말하자면, “비동기 코드 유지보수 담당자”라는 역할에서는 지금도 꽤 쓸 만합니다. TODO 정리, 의존성 업데이트, 보안 점검 같은 일을 맡기고 자리를 비웠다 PR을 확인하는 흐름은 실제로 편합니다. 다만 자율 실행인 만큼 민감한 자격증명 관리에는 기존보다 훨씬 더 주의가 필요합니다. 이 부분이 현재 Jules의 가장 현실적인 한계입니다.

무료로 시작할 수 있고, 실제 모델은 Gemini 3 계열이 올라와 있는 지금, 써보지 않을 이유가 딱히 없습니다. 단, API 키는 저장소에서 꺼내고 시작하는 게 맞습니다.

본 포스팅 참고 자료

1. Jules 공식 Changelog — https://jules.google/docs/changelog
2. Jules 공식 FAQ — https://jules.google/docs/faq/
3. Jules 요금 및 한도 — https://jules.google/docs/usage-limits
4. Google Developers Blog — Jules + Gemini 3 발표 — https://developers.googleblog.com/ko/jules-gemini-3/
5. Google Jules 보안 취약점 연구 (embracethered.com, 2025.08.13) — https://embracethered.com/blog/posts/2025/google-jules-vulnerable-to-data-exfiltration-issues/
6. Gemini CLI and Jules: my March 2026 stack (dev.to, 2026.03.15) — https://dev.to/rowan_m/gemini-cli-and-jules-my-march-2026-stack-4146