Google Jules 서비스 종료: 작업 내보내기부터 대체 툴 전환까지

Google Jules 서비스 종료 일정, 언제 무엇을 옮겨야 할까요?

Google의 백그라운드 AI 코딩 에이전트인 Google Jules는 11월 11일 이후 읽기 전용으로 전환된 뒤 최종 종료됩니다. Google이 게시한 Jules 서비스 종료 공지의 날짜는 2026년 10월 29일입니다.

공지에는 정확한 종료 시각이나 시간대, 별도의 API 종료일, 라이선스 기한, 청구 또는 환불 날짜, 종료 후 데이터 보관 일정이 명시되어 있지 않습니다. 표의 일정만으로 추정하지 말고, 아직 답이 나오지 않은 사안으로 남겨 두어야 합니다.

수정을 끝내지 못한 개발자는 우선 Jules에서 마무리할지, 패치와 남은 요구사항을 새 작업으로 넘길지 결정해야 합니다. 엔지니어링 리더라면 일반적인 코드 리뷰에서 드러나지 않는 의존성을 찾아야 합니다. 반복 실행하는 프롬프트, 환경 설정 절차, 저장소 권한, 인증 정보가 여기에 해당합니다.

Jules에 작업을 맡기고 있다면 지금 움직여야 합니다. 완료한 변경 사항을 이미 모두 병합했고 Jules에 보관된 기록도 필요 없는 팀은 옮길 것이 적습니다. 기존 Jules 작업 없이 에이전트를 검토하는 팀이라면 내보내기 단계는 건너뛰고 아래의 실행 환경 선택부터 시작해도 됩니다. 장기적으로 쓸 서비스를 고르는 일은 미룰 수 있지만, 작업을 보존하는 일은 미루면 안 됩니다.

Git 저장소 밖에 남은 작업 맥락을 보존하십시오

GitHub에 이미 있는 코드, 브랜치, 풀 리퀘스트는 그대로 남습니다. Google의 내보내기 대상은 Jules에 저장된 설정, 환경 변수, 예약 작업, 저장소 연결, 메모리, 설정 스크립트와 세션의 프롬프트, 계획, 로그, 패치입니다. 구체적인 절차는 공식 내보내기 안내를 참고하십시오.

풀 리퀘스트, 즉 PR은 코드 변경을 제안하는 단위입니다. 패치는 남길 수 있어도 에이전트가 왜 그 방식을 택했는지까지 담지는 못할 수 있습니다. 설정 스크립트에는 테스트를 통과시키는 데 필요했던 패키지 설치 단계가, 메모리에는 유용해 보이는 리팩터링을 거절한 이유가 들어 있을 수 있습니다. 이 자료를 다른 에이전트의 지침으로 바꾸기 전에 먼저 검토하십시오.

내보낸 자료는 아카이브로 보관하고, 미완료 작업마다 핵심만 추린 인계 자료를 만드십시오. 저장소와 브랜치, 구현하려는 변경 사항, 이미 끝낸 부분, 남은 완료 기준, 성공 여부를 확인할 명령을 포함합니다. 대화 전체를 새 프롬프트에 붙여 넣기보다는 근거가 되는 기록을 링크로 연결하십시오.

예를 들어 의존성 업그레이드 작업이라면 “업그레이드를 마무리하라”는 지시만으로는 부족합니다. 아직 해결하지 못한 호환성 문제, 변경된 파일, 실패를 재현하는 테스트를 남겨야 합니다. 그래야 다음 에이전트의 작업 범위가 명확해지고, 검토자도 미완성 결과를 걸러 낼 수 있습니다.

Google이 공개한 절차로 데이터를 내보내십시오

Google은 Jules Tools와 함께 제공하는 내보내기 프롬프트를 사용하도록 안내합니다. 먼저 설치하고 인증합니다.

npm install -g @google/jules
jules login

홈 디렉터리에서 CLI 코딩 에이전트를 실행한 뒤, 공지에 있는 프롬프트를 펼쳐 복사해 붙여 넣으십시오. 저장소 데이터를 가져오려면 먼저 GitHub를 연결해야 합니다. 결과는 ~/jules-export에 저장됩니다. env-variables.json에 인증 정보 값이 들어 있으므로 비공개로 보관하십시오. 세션별 기록에는 summary.md, 활동 로그, diff가 포함됩니다.

완료 메시지가 떴다고 필요한 자료가 모두 확보된 것은 아닙니다. Google이 공개한 내보내기 도구를 살펴보면, 개별 세션의 상세 정보를 가져오는 데 실패해도 세션 수에는 목록에 조회된 세션이 집계됩니다. 오류는 별도로 보고합니다. 설정 명령도 세션 출력에서 복원하므로, 저장소를 다른 환경으로 옮길 준비가 됐다고 판단하기 전에 실제로 저장된 내용을 확인해야 합니다. 이는 공개 스크립트를 읽고 확인한 사항이며, 이 글을 위해 직접 내보내기를 실행하지는 않았습니다.

전환을 승인하는 리더에게는 이 차이가 중요합니다. “명령 실행이 끝났다”는 사실만으로는 “필요한 패치, 설정, 작업 맥락이 모두 있다”는 것을 입증할 수 없습니다. 중요한 기록이 빠졌다면 아직 접근할 수 있을 때 복구하십시오. 다음 에이전트에게 사라진 내용을 추정해 다시 만들도록 맡겨서는 안 됩니다.

작업 기록과 Jules API는 어떻게 되나요?

작업 기록은 로컬에 보존하고, 자동화가 Jules에 의존하는 부분은 정리해야 합니다. 종료 공지는 다른 에이전트로 기록을 자동으로 가져오거나 종료 후에도 API 서비스를 계속 제공한다고 약속하지 않습니다.

Google의 공개 Jules API 문서는 작업 생성, 계획 승인, 메시지 전송을 비롯한 세션과 활동을 설명합니다. 이런 기능은 실제 작업 실행의 의존성입니다. 팀에서 아무도 Jules 웹사이트를 열지 않더라도, 이슈 봇이 세션을 생성하고 있다면 대체 수단이 필요합니다.

Jules를 호출하는 스크립트, 워크플로 파일, 연동을 목록으로 정리하십시오. 각각 어떤 입력을 받고, 어떤 신호를 기다려 성공을 판단하며, 결과를 어디에 저장하는지 기록합니다. 프롬프트만 바꾸는 방식으로는 전환에 실패할 수 있습니다. 기존 연동이 Jules 세션 식별자를 요구하거나, 완료 여부를 확인하려고 Jules 활동을 반복 조회할 수 있기 때문입니다.

API 빠른 시작 문서가 아직 공개되어 있다는 이유로 서비스 운영 기간이 연장됐다고 판단해서는 안 됩니다. 엔드포인트별 일정이 따로 없다면 서비스 종료 일정을 계획의 기준으로 삼고, 읽기 전용으로 전환되기 전에 작업 생성 경로를 옮기십시오. 이는 운영상의 권고이며, Google이 추가로 발표한 API 종료일은 아닙니다.

기록을 보존하는 것과 실행을 이어 가는 것도 구분해야 합니다. 저장한 계획은 다른 에이전트가 작업을 이해하는 데 도움이 되지만, 이전 에이전트의 실행 환경까지 재현하지는 못합니다. Jules를 열지 않고도 다른 개발자가 다음 단계를 재현할 수 있도록 작업을 마무리하거나 중간 상태를 정리해 두십시오.

Antigravity로 무엇이 이어지며, 지금 쓸 수 있는 기능은 무엇인가요?

Google은 Jules에서 얻은 경험을 자사의 에이전트 개발 플랫폼인 Google Antigravity에 반영하겠다고 밝혔습니다. Google의 공식 Jules 발표에 따르면 원격 자율 백그라운드 실행을 Antigravity의 개발 환경과 결합하는 작업을 진행 중입니다. 다만 이 결합 기능의 제공 시점은 제시하지 않았습니다.

현재 제품도 유용한 백그라운드 작업을 지원합니다. Antigravity App은 병렬 에이전트를 관리하고, 작업을 Projects로 묶으며, 예약 작업을 실행합니다. Google의 Remote Control 문서는 노트북, 데스크톱, 서버에서 실행 중인 세션에 브라우저로 접근하는 방법을 설명합니다.

여기서 구분할 것은 실행할 컴퓨터를 누가 제공하느냐입니다. Remote Control은 기존 컴퓨터에 접속하는 창구입니다. 이 기능만으로 Google이 Jules를 대체할 호스팅 환경을 마련했다고 볼 수는 없습니다. 야간 유지보수 작업을 원하는 팀이라면 어떤 컴퓨터가 계속 켜져 있어야 하는지, 누가 의존성을 관리하는지, 그 컴퓨터를 사용할 수 없게 되면 어떻게 되는지 알아야 합니다.

전환 절차: Antigravity에서 저장소를 열고 필요한 환경 설정과 지침을 다시 구성한 뒤, 명확한 테스트가 있는 작은 작업을 실행하십시오. 원격 접근을 전제로 한다면 대상 컴퓨터와 가용성을 확인합니다. 이 작업 흐름이 검토를 통과한 뒤 반복 실행 일정을 추가하십시오.

Antigravity의 개발 환경을 쓰고 싶고 실행 호스트를 직접 운영할 수 있다면 Antigravity를 선택할 수 있습니다. 요구사항이 “개발자가 노트북을 닫아도 되고, 누구도 다른 컴퓨터를 관리할 필요가 없어야 한다”라면, 제공 일정이 없는 기능에 전환 계획을 걸지 말고 지금 호스팅형 대안을 검토하십시오.

접근 권한과 사용량 한도를 판단할 때는 Antigravity 요금 안내를, 일상적인 개발 환경으로 무엇이 적합한지 비교할 때는 Google Antigravity와 Cursor 비교를 참고하십시오.

AI 코딩 툴을 고를 때는 백그라운드 작업의 실행 환경부터 정하십시오

에이전트가 코드를 작성하는 스타일보다 런타임을 먼저 선택하십시오. 런타임은 작업을 실행하는 컴퓨터와 소프트웨어 환경입니다. 이번 전환에서는 그 환경을 직접 운영할지, 서비스 제공업체의 호스팅을 쓸지, GitHub Actions로 자동 실행할지를 비교하는 것이 유용합니다.

아래 경로는 각 서비스의 현재 문서를 바탕으로 정리한 전환의 출발점입니다. 기능이 모두 같거나 Jules와 공통된 가져오기 형식을 지원한다는 뜻은 아닙니다.

OpenAI Codex Cloud: 프로젝트 설정을 재사용하는 호스팅형 작업

OpenAI Codex Cloud는 컴퓨터가 절전 모드여도 작업을 계속할 수 있는 호스팅형 코딩 에이전트입니다. 작업마다 별도의 워크스페이스를 사용하며, 커밋하거나 PR을 열기 전에 변경 사항과 테스트 결과를 확인할 수 있습니다. 현재 설정 절차는 공식 Codex Cloud 가이드에 나와 있습니다.

전환 절차: ChatGPT에서 Work in > Cloud를 선택하고 환경을 새로 만들거나 기존 환경을 선택하십시오. GitHub 저장소를 연결하고 Codex가 프로젝트를 준비하게 한 뒤, 설정 점검 결과를 검토하고 환경을 게시합니다. 정리한 Jules 인계 자료로 범위가 명확한 작업을 시작하고, 변경 사항과 테스트 결과를 검토하십시오.

관건은 환경의 접근 권한입니다. 로컬 테스트가 성공했더라도 클라우드 작업이 패키지 레지스트리나 필수 서비스에 접근하지 못하면 의미가 없습니다. 환경 설정에 필요한 네트워크 대상과 인증 정보를 지정한 뒤, 그 환경에서 같은 테스트를 확인하십시오.

프로젝트 설정을 재사용할 수 있는 호스팅형 작업 큐가 핵심 요구사항이라면 Codex가 선택지가 됩니다. 첫 시험은 범위가 정해지지 않은 전면 재작성보다, 결과가 맞는지 빠르게 판단할 수 있는 작업으로 시작하십시오. 서비스 종료 대응을 넘어 작업 방식 자체를 비교하려면 Codex와 Claude Code 비교를 참고하십시오.

Claude Code: 클라우드 세션과 저장소 자동화 중 목적에 맞게 선택하십시오

Anthropic의 Claude Code는 노트북을 닫은 뒤에도 계속 실행되는 클라우드 세션과, 저장소 워크플로를 위한 별도의 GitHub Actions 연동을 제공합니다. 사람이 대화로 넘기던 작업을 대체하는지, 자동화 트리거를 대체하는지에 따라 적합한 전환 경로가 달라집니다.

클라우드 세션으로 옮길 때: 저장소를 연결하고 클라우드 환경의 설정 절차, 네트워크 접근, 변수를 구성한 뒤 범위가 정해진 작업을 시작하십시오. 인증을 마친 Claude Code 터미널에서는 claude --cloud로 클라우드 작업을 시작합니다. 일반적인 GitHub 복제 경로를 사용할 때는 세션에 원하는 커밋이 전달되도록 먼저 브랜치를 푸시하십시오. 자세한 내용은 Claude 클라우드 세션 가이드를 참고하십시오.

관건은 공유 사용량과 접근 권한입니다. 클라우드 세션은 계정의 Claude 사용량 한도를 소모하며, 조직 권한에 따라 이용이 제한될 수 있습니다. 개발자의 개인 설정에서 잘 작동한다고 해서 회사 계정으로 같은 작업량을 처리할 수 있다는 뜻은 아닙니다.

GitHub Actions로 옮길 때: 저장소 관리자는 Claude Code에서 /install-github-app을 실행하고 인증 설정을 진행한 뒤, 생성된 워크플로 PR을 검토할 수 있습니다. 명시적인 @claude 요청으로 먼저 시작하고, 이후 대체하려는 반복 작업이나 이벤트 기반 작업을 추가하십시오. 앱, 인증 정보, 워크플로의 요구사항은 Anthropic의 GitHub Actions 가이드에 설명되어 있습니다.

이 경로의 관건은 워크플로를 누가 책임지느냐입니다. 트리거, 인증 정보, 권한을 관리하고, 환경 설정 실패와 코딩 작업 실패를 구분할 담당자가 필요합니다. 저장소 이벤트를 시작점으로 삼는 것이 자연스러운 작업이라면 Actions를 선택하십시오. 이 운영 방식은 Claude Code GitHub Actions 가이드에서 자세히 다룹니다.

GitHub Copilot 코딩 에이전트: GitHub 안에서 작업을 인계하십시오

GitHub Copilot의 코딩 에이전트는 GitHub 워크플로 안에서 백그라운드 구현과 테스트를 수행합니다. 현재 문서는 클라우드 샌드박스와 GitHub Actions 환경을 구분하므로 작업에 선택된 환경을 확인해야 합니다. 자세한 내용은 GitHub의 Copilot 안내를 참고하십시오.

전환 절차: 요금제의 이용 권한과 조직 정책을 확인하고, 저장소와 브랜치를 선택한 뒤, 완료 기준 및 PR 생성 요청을 포함한 작업을 Copilot에 맡기십시오. 병합하기 전에 제안된 변경 사항과 테스트 근거를 살펴봅니다. Jules 작업 목록에 정리한 이슈 설명을 그대로 이어서 사용하면 대체 툴이 요구사항을 충족했는지 판단할 수 있습니다.

제약은 실행 환경에 따라 달라집니다. GitHub Actions 세션은 단일 저장소를 수정하지만, 클라우드 샌드박스 세션은 여러 저장소에 걸쳐 작업할 수 있습니다. 두 환경 모두 작업당 단일 브랜치에서 작업하고 단일 PR을 엽니다. 여러 브랜치의 변경을 함께 조율해야 하는 전환이라면, 각각 검토할 수 있는 작업으로 나누십시오.

검토 대기열과 작업별 담당 체계가 이미 GitHub에 마련되어 있다면 Copilot이 적합합니다. 이슈와 PR 가까이에서 작업을 넘길 수 있습니다. 다만 Jules에 있던 환경과 지침은 여전히 다시 구성해야 합니다.

내보내기를 자동 이전으로 받아들이면 안 됩니다

“Jules가 Antigravity로 옮겨 간다”는 말을 계정 이전 계획으로 받아들이면 오해가 생깁니다. Google의 발표는 제품의 방향성과 데이터 내보내기를 설명합니다. 진행 중인 세션, 예약 작업, 메모리가 대체 서비스에 바로 실행할 수 있는 상태로 나타난다고 약속하지는 않습니다.

브라우저로 접속할 수 있다는 이유만으로 클라우드에서 실행된다고 판단하는 것도 같은 오류입니다. 브라우저로 직접 운영하는 컴퓨터를 제어할 수도 있고, 서비스 제공업체가 호스팅하는 컴퓨터를 제어할 수도 있습니다. 화면은 비슷해 보여도 작업이 계속 실행되도록 책임지는 주체는 다릅니다.

실무적인 합격 기준을 세우십시오. 대체 툴은 필요한 설정을 재현하고, 범위가 명확한 작업을 완료하며, 점검 결과를 보여 주고, 검토 가능한 변경 사항을 내놓아야 합니다. 같은 저장소를 인식하거나 그럴듯한 계획을 만든다는 이유만으로 선택해서는 안 됩니다. 계획은 작업을 이해했다는 근거가 될 수 있지만, 전환이 제대로 됐다는 근거는 실제로 통과한 작업 흐름입니다.

이 기준을 적용하면 엔지니어링 리더가 결정할 범위도 줄어듭니다. 종료 전에 앞으로 쓸 모든 코딩 툴의 선호를 정할 필요는 없습니다. 그대로 두면 중단될 작업에 대해 검증된 실행 경로를 확보하고, 실패 원인을 진단할 담당자를 지정하면 됩니다.

이번 주에 끝낼 전환 체크리스트

우선 대체 경로로 작업 하나를 성공시키고, 그다음 나머지 백로그로 확대하십시오.

• 현황 파악: Jules 저장소, 미완료 세션, 반복 작업, API 호출 주체를 목록으로 작성합니다. 계속할 작업마다 담당자와 이전할 곳을 정합니다.
• 보존: Google의 내보내기 절차를 실행하고 오류와 중요한 파일을 확인한 뒤, 원본 아카이브를 비공개로 보관합니다.
• 완료 또는 중간 상태 정리: 남은 패치를 검토하고, 이어서 진행할 작업마다 이해할 수 있는 브랜치, 요구사항, 테스트를 남깁니다.
• 재구성: 선택한 런타임의 의존성, 지침, 네트워크 접근, 인증 정보를 설정합니다. 비밀 값은 일반적인 작업 메모에 넣지 않습니다.
• 검증: 작은 작업으로 환경 설정, 구현, 테스트, 사람의 검토까지 진행합니다. 성공한 PR뿐 아니라 실패했을 때의 처리 경로도 확인합니다.
• 전환: 대체 경로가 작동한 뒤에만 반복 실행 트리거를 옮깁니다. 중복 요청을 막고, 더 이상 필요 없는 기존 접근 권한을 정리합니다.

월요일에 할 일은 진행 중인 저장소 하나를 골라 Jules의 작업 맥락을 내보내고, 대체 툴에서 작은 작업을 검토 단계까지 끝내는 것입니다. 그러면 서비스가 새 작업을 받지 않게 되기 전에 반복 적용할 수 있는 전환 방식을 확보할 수 있습니다.

개발자 툴의 변화에 대응하는 실무 가이드를 받아보려면 뉴스레터를 구독하십시오.