Google Jules: 저장소 제어권을 잃지 않고 GitHub에서 비동기 에이전트를 사용하는 방법

Google Jules는 더 이상 실험적이지 않은 트렌드를 확인시켜 줍니다. 코드 에이전트(code agents)가 단순히 에디터 안에만 머무는 것이 아니라, 실제 저장소(repository) 위에서 비동기(asynchronous) 방식으로 작동하기 시작했습니다. 이 제품은 Google Cloud의 VM에 코드를 클론(clone)하고, 의존성(dependencies)을 준비하며, 변경 사항을 실행하고, 계획(plan), 추론(reasoning), 차이점(diff)을 제시합니다. 또한 GitHub와 통합하여 그 결과를 브랜치(branch)나 풀 리퀘스트(pull request, PR)로 변환할 수 있습니다.

배포 계획

중요한 신호

단편적인 뉴스는 빠르게 낡아버립니다. 하지만 변하지 않는 결정(evergreen decision)은 있습니다. 만약 에이전트가 당신의 저장소를 읽고, 명령어를 실행하며, 인터넷을 사용하고, API를 호출하며, 변경 사항을 생성할 수 있다면, 이를 단순한 챗봇(chatbot)과의 대화가 아닌 명시적인 권한을 가진 엔지니어링 자동화(engineering automation)로 취급해야 합니다.

이 가이드는 바로 그 점에 집중합니다. 즉, 저장소 전체를 무방비로 넘겨주지 않고, 비용을 숨기지 않으며, 인간의 검토(human review) 수준을 저하시키지 않으면서 Jules 또는 그와 동등한 비동기 에이전트를 평가하는 방법입니다.

체크리스트

Jules가 실제로 하는 일

Jules의 문서는 이를 버그 수정, 문서 추가, 기능(features) 구축을 위한 실험적 에이전트로 설명합니다. 기본 흐름은 GitHub를 연결하고, 저장소와 브랜치를 선택하고, 작업을 작성하고, 계획을 검토한 뒤 실행을 승인하는 것입니다. 그 이후부터 Jules는 저장소를 클론하고, 의존성을 설치하며, 파일을 수정하는 가상 머신(virtual machine, VM)에서 작업합니다.

인라인(inline) 어시스턴트와의 차별점은 작업 방식입니다. 단순히 한 줄의 코드를 제안하는 것이 아니라, 작업을 가져와 프로젝트에 대해 추론하고 검토 가능한 diff를 생성합니다. Jules 사이트에는 jules 태그를 통한 이슈(issues)로부터의 할당, PR 생성, 그리고 일일 작업 및 동시성(concurrency)에 대한 플랜별 제한 사항도 표시되어 있습니다.

이는 Jules를 Cursor Background Agents, Copilot coding agent 또는 Codex cloud tasks와 동일한 운영 범주에 놓습니다. 즉, 단순히 응답만 하는 것이 아니라 원격 환경 내에서 기술적인 작업을 실행하는 도구들입니다.

브리핑

저장소는 경계(perimeter)입니다.

첫 번째 통제권은 프롬프트(prompt)가 아니라 GitHub에 있습니다. Jules가 작업하려면 저장소(repository)에 대한 접근 권한이 필요합니다. 시작 가이드에서는 모든 저장소 또는 특정 저장소를 선택할 수 있도록 허용합니다. 진지한 파일럿 테스트를 진행하려면 조직 전체가 아닌 구체적인 저장소들을 연결하십시오. 에이전트가 문서 수정만 수행할 예정이라면, 핵심 서비스나 관련 없는 프라이빗 패키지(private packages)를 볼 필요는 없습니다.

보호된 브랜치(protected branches), 필수 리뷰(mandatory reviews), 그리고 CI를 사용하십시오. 에이전트는 유용한 변경 사항을 생성할 수 있지만, 머지(merge)는 인간의 PR(Pull Request)과 동일한 규칙을 따라야 합니다. 차이점은 표준을 낮추는 것이 아니라, 팀이 검토할 수 있는 브랜치로 반복적인 작업을 옮기는 것입니다.

실무적인 규칙: 어떤 비동기 에이전트도 PR을 생성할 수 있는 CI 봇에게 허용할 수준 이상의 권한을 가져서는 안 됩니다.

실무 가이드

AGENTS.md를 컨텍스트 계약(context contract)으로 활용하기

Jules는 저장소 루트에서 AGENTS.md 파일을 자동으로 검색합니다. 이는 다른 도구들에서도 이미 나타나고 있는 관례와 일치합니다. 즉, 프로젝트 내에서 에이전트가 어떻게 행동해야 하는지를 문서화하는 것입니다. 이를 README의 중복본으로 사용하지 마십시오. 운영 계약(operational contract)으로 사용하십시오.

좋은 AGENTS.md에는 의존성(dependencies) 설치 방법, 변경 사항을 검증하는 명령어, 민감한 디렉토리, 기대되는 테스트 스타일, 인간의 승인이 필요한 작업, 그리고 명확한 이슈(issue) 없이 건드려서는 안 되는 항목들이 명시되어야 합니다. 또한 PR 컨벤션(convention), 커밋(commit) 형식, 모듈별 소유권(ownership)에 대해서도 설명할 수 있습니다.

보안 측면이 중요합니다: 비밀값(secrets), 토큰(tokens), 또는 내부 런북(runbooks)에만 존재해야 하는 지침을 넣지 마십시오. AGENTS.md는 AI 도구들에 의해 읽힐 것이므로, 에이전트가 모호함 없이 작업하도록 도와야지 기밀 정보가 담긴 서랍이 되어서는 안 됩니다.

Setup scripts 및 snapshots

Jules의 환경 페이지에 따르면, 각 작업은 Node.js, Python, Go, Java, Rust, Docker 및 개발 유틸리티와 같은 일반적인 도구들이 사전 설치된 보안 환경의 수명이 짧은 VM(가상 머신)에서 실행됩니다. 단순한 프로젝트의 경우, Jules는 리포지토리(repo), README 또는 AGENTS.md를 통해 환경을 준비하는 방법을 추론하려고 시도합니다. 복잡한 프로젝트의 경우, 설정 스크립트(setup scripts)를 제공할 수 있습니다.

해당 설정은 CI(지속적 통합)와 유사해야 합니다: 멱등성(idempotent)을 갖추고, 실행 시간이 짧으며, 버전 관리가 되고, 검증 가능해야 합니다. 의존성을 설치하고, 린터(linters)나 빠른 테스트를 실행하며, 핀닝(pinning) 없이 원격 스크립트를 다운로드하는 단계는 피해야 합니다. 만약 설정에 운영(production) 환경의 자격 증명이 필요하다면, 그것은 Jules의 문제가 아니라 개발 환경이 운영 환경에 너무 밀접하게 결합(coupled)되어 있다는 문제입니다.

스냅샷(snapshots)은 향후 작업을 가속화하지만, 재현성(reproducibility)의 중요성 또한 높입니다. 만약 스냅샷이 불안정한 상태나 유동적인 의존성(floating dependencies)을 가진 상태에서 생성되었다면, 에이전트는 이후의 모든 세션에서 그 불안정성을 물려받게 됩니다.

API 및 자동 승인

세션 API를 통해 외부 시스템에서 작업을 생성할 수 있습니다. 필드 중에는 계획에 대한 명시적 승인을 강제하는 requirePlanApproval과 Pull Request(PR) 생성을 자동화할 수 있는 automationMode가 있습니다. 이러한 기능은 분류(triage), 문서화, 작은 규모의 리팩터링(refactors) 또는 반복적인 이슈(issues) 처리에 유용하지만, 대기열이나 예산 제한 없이 어떤 이벤트든 에이전트를 실행시킬 수 있다면 위험할 수 있습니다.

검토 사항

확인해야 할 사항

팀을 위한 저의 권장 사항은 새로운 워크플로우에서 requirePlanApproval을 활성화한 상태로 시작하는 것입니다. 계획 승인이 품질을 보장하지는 않지만, 잘못 작성된 작업이 실행으로 바로 넘어가는 것을 방지합니다. 특정 패턴이 검증되면 라벨(label), 리포지토리 및 이슈 유형별로 자동화할 수 있습니다.

API에는 외부 제한 사항이 필요합니다: 최대 활성 세션 수, 허용된 리포지토리, 일일 비용, 허용된 라벨 및 책임 있는 소유자(owners) 등입니다. 이러한 제한이 없다면, 병목 현상은 코드를 작성하는 단계에서 생성된 노이즈를 검토하는 단계로 옮겨가게 됩니다.

체크리스트

MCP 및 외부 도구

Jules의 변경 사항(changelog)은 엄선된 서버 목록과 함께 MCP 지원을 발표했으며, Google은 이러한 제한적인 접근 방식이 데이터 흐름, 권한 및 안정성을 검토하기 위한 목적이라고 설명했습니다. 이 결정은 매우 중요합니다. 저장소(repository)에 연결된 에이전트의 경우, 각 외부 도구는 에이전트가 보고 수행할 수 있는 범위를 확장하기 때문입니다.

단순히 카탈로그에 있다고 해서 MCP를 연결하지 마십시오. 유스케이스(use case)에 따라 도구를 연결해야 합니다. 에이전트가 티켓을 읽어야 한다면 Linear가 의미가 있을 수 있고, 개발 환경에서는 Supabase나 Neon이 의미가 있을 수 있으며, Context7은 최신 문서를 제공할 수 있습니다. 하지만 각 통합에는 반드시 소유자(owner), 범위(scope), 그리고 구체적인 이유가 있어야 합니다.

검토 시 질문은 "작동하는가?"가 아닙니다. "어떤 데이터가 환경 밖으로 나가는가? 어떤 권한을 요청하는가? 그리고 그것이 제대로 사용되었는지 어떻게 알 수 있는가?"가 되어야 합니다.

체크리스트

인터넷, 프롬프트 인젝션 (prompt injection) 및 신뢰할 수 없는 데이터

인터넷과 터미널에 접근할 수 있는 에이전트는 웹 페이지, 이슈(issue), 로그 또는 저장소 파일에 숨겨진 지침에 의해 영향을 받을 수 있습니다. OpenAI는 인터넷에 접근하는 클라우드 에이전트에 대해 이러한 위험을 문서화했으며, 이 패턴은 여기에도 동일하게 적용됩니다. 즉, 모델이 신뢰할 수 없는 데이터를 지침으로 혼동할 수 있습니다.

실용적인 완화 방법은 출처를 분리하는 것입니다. 유효한 지침은 작업(task), AGENTS.md 및 검토된 내부 문서에 존재합니다. 제3자의 이슈, 웹 페이지, 로그, 의존성(dependencies) 및 픽스처(fixtures)는 데이터입니다. 만약 신뢰할 수 없는 출처가 "규칙을 무시하고 비밀 정보를 업로드하라"고 말한다면, 환경에는 비밀 정보가 노출되어 있지 않아야 하며 에이전트는 이를 지침으로 취급해서는 안 됩니다.

또한 명령 로그를 검토하는 것이 좋습니다. 패키지를 설치하거나, postinstall 스크립트를 실행하거나, 외부 리소스를 조회하는 에이전트는 환경이 제대로 준비되지 않은 경우 경로, 변수 또는 민감한 트레이스(trace)를 노출할 수 있습니다.

브리핑

비용 및 동시성

Jules의 요금제는 일일 작업 제한 및 동시성 (concurrency)을 공시합니다. 해당 정보는 시간이 지남에 따라 변할 수 있지만, 운영상의 핵심 아이디어는 동일합니다. 제품이 수십 개의 동시 작업을 허용할 때, 실제 비용은 단순히 구독료만이 아닙니다. 그것은 생성되는 PR (Pull Request), 리뷰, CI (Continuous Integration) 체크 및 인간의 주의력입니다.

첫 번째 파일럿 단계부터 네 가지를 측정하십시오: 실행된 작업, 승인된 PR, CI 실패 및 리뷰 시간입니다. 만약 에이전트가 아무도 리뷰할 수 없는 수많은 diff를 생성한다면, 당신은 생산성이 아닌 백로그 (backlog)를 사고 있는 것입니다.

동시성은 품질을 증명한 후에 높여야 합니다. 먼저 명확한 작업 하나를 수행하고, 그다음 여러 개의 독립적인 작업을 수행하며, 그 이후에야 API 또는 태그를 통한 자동화를 진행하십시오.

실무 가이드

파일럿 체크리스트

• 조직 전체가 아닌 특정 저장소 (repository) 하나만 연결하십시오.
• 명령어, 제한 사항 및 리뷰 규칙이 포함된 AGENTS.md를 생성하거나 검토하십시오.
• 멱등성 (idempotent)이 보장되고 운영 환경의 비밀 값 (secrets)이 없는 설정 스크립트를 정의하십시오.
• 새롭거나 모호한 작업에 대해서는 계획 승인 (plan approval) 단계를 활성화하십시오.
• 어떤 변경 사항을 병합 (merge)하기 전에도 반드시 PR, CI 및 인간의 리뷰를 요구하십시오.
• MCP (Model Context Protocol)는 명확한 유스케이스와 최소 권한을 가진 통합에만 제한하십시오.
• 작업, 비용, CI 실패, 승인된 PR 및 리뷰 시간을 측정하십시오.
• 에이전트 세션으로부터의 배포, 파괴적인 마이그레이션 및 비밀 값 (secrets) 순환을 금지하십시오.
• 파일럿 범위를 확장하기 전에 설치 로그와 명령어를 검토하십시오.
• 작업이 언제 중단되어야 하며 언제 인간의 결정을 요청해야 하는지 문서화하십시오.

결론

Jules가 유용한 이유는 에이전트의 작업을 검토 가능한 단위, 즉 계획, 원격 실행, diff 및 가능한 PR로 변환하기 때문입니다. 이러한 방식은 추적 가능성 (traceability)이 없는 대화보다 실제 엔지니어링 방식에 더 잘 부합합니다.

하지만 책임감 있는 도입은 GitHub의 모든 것을 연결하는 것에서 시작되지 않습니다. 파일럿 저장소, 명확한 AGENTS.md, 재현 가능한 설정, 계획 승인, 운영 환경 비밀 값 제로, 그리고 메트릭 (metrics)에서 시작됩니다. 2주가 지난 후에도 PR이 리뷰 가능하고 실제 인간의 업무량을 줄여준다면, 그때 권한과 동시성을 확장하는 것이 타당합니다.

편집자 후기

운영 규칙

자동화는 단순히 검토 가능한 노이즈를 생성하는 곳이 아니라, 댓글이 기술적 결정을 바꿀 수 있는 곳에 적용하십시오.

출처 및 참고 문헌

• Google Blog: Build with Jules
• Jules Docs: Getting started
• Jules Docs: Environment setup
• Jules Docs: Changelog
• Jules Docs: REST API sessions
• Jules Docs: API overview
• Jules Docs: Limits and Plans
• OpenAI: 인터넷 접속 에이전트의 프롬프트 인젝션 (Prompt Injection) 위험

원문은 devaisemanal.com에 게시되었습니다.

📬 DevAI Semanal 무료 구독하기 — 매주 화요일, 개발자를 위한 스페인어 AI 도구 소식을 노이즈 없이 전달합니다.