Google Jules 11월 11일 읽기 전용 전환 전 어떻게 이전할까? 2026

Google Jules 이전의 우선순위는 지금 설정과 세션 기록을 내보내고, 2026년 11월 11일 전에 상호작용이 필요한 작업을 마무리하는 것입니다. 코드는 GitHub에 이미 저장되어 있을 수 있지만, Jules의 설정과 작업 흐름이 Google Antigravity나 다른 에이전트로 자동 이전된다고 가정해서는 안 됩니다. 공식 이전 공지는 세션 완료 기한과 읽기 전용 전환을 안내합니다.

이 안내는 Jules 개인 설정과 미완료 작업을 보존하려는 독립 개발자, 예약 작업과 공유 저장소를 운영하는 소규모 팀, CI 및 플랫폼 엔지니어를 위한 것입니다. macOS 전용 빌드가 없다면 에이전트 이전 자체에 Mac이 필수는 아닙니다.

마지막 업데이트: 2026년 11월 5일. 일정과 자료 범위는 Jules 이전 공지와 Jules Tools CLI 문서를 기준으로 확인했습니다. 실제 작업 시각과 시간대, 후속 변경 사항은 공식 문서에서 다시 확인해야 합니다.

Google Jules 이전은 코드 보관과 서비스 자료 보존을 따로 봐야 합니다

Google Jules는 언제 읽기 전용이 되며, 그 전에 무엇을 해야 하나요? 공식 공지에 따르면 Jules 세션은 2026년 11월 11일까지 완료할 수 있고, 이후 읽기 전용 상태로 바뀌어 2026년 12월 31일 서비스를 종료합니다. 날짜가 가까운 작업은 대화형 세션을 먼저 끝내거나 담당자에게 인계한 뒤, Jules Tools로 설정과 기록을 내보내야 합니다. Jules의 일정과 이전 범위 공지를 작업 직전에 다시 확인하세요.

여기서 중요한 구분은 저장 위치입니다. 저장소의 코드, 브랜치, 풀 리퀘스트는 GitHub에 남아 있을 수 있지만, 그것만으로 Jules 안의 환경 설정이나 예약 작업, 세션 기록까지 보존되는 것은 아닙니다. 공식 공지는 GitHub에 저장된 코드와 브랜치, 풀 리퀘스트가 Jules 내보내기 범위에 포함되지 않는다고 설명합니다. 따라서 GitHub 저장 상태와 Jules 서비스 자료의 내보내기 상태를 별도로 확인해야 합니다.

세션 목록을 볼 때는 오래된 대화보다 현재 실행 중인 일의 위험부터 판단합니다. 릴리스나 내부 마감이 걸린 작업, Jules의 반복 실행에 의존하는 작업, 결과 검토자가 정해지지 않은 작업은 우선 처리 대상입니다. 세션을 넘길 때는 저장소와 브랜치, 기대 산출물, 실행할 테스트, 사람의 검토 책임을 함께 기록해야 합니다. 열린 세션을 다른 에이전트에서 이어갈 수 있다고 추정하는 것은 인계가 아닙니다.

읽기 전 세션 정리와 자료 내보내기를 분리합니다

Jules 안에서 계속 대화하거나 결과를 수정해야 하는 작업은 읽기 전용 전환 전에 마무리해야 합니다. 단순히 세션 제목이나 완료 표시만 확인하지 말고, 실제 코드 변경이 저장소에 반영됐는지와 테스트 결과가 남아 있는지 확인하세요. 미완료 작업은 저장소 이슈나 팀의 작업 기록에 현재 상태, 다음 단계, 담당자를 적어 넘기는 편이 안전합니다.

Jules Tools로 설정, 환경 변수와 세션 기록을 어떻게 내보내나요? 먼저 공식 Jules Tools CLI 참고 문서를 열어 설치, 로그인, 현재 제공되는 내보내기 명령과 요구 조건을 확인합니다. 문서에 나온 절차대로 도구를 준비하고 인증한 다음, 안내된 내보내기 작업을 실행하세요. 명령 이름이나 옵션을 기억에 의존해 입력하지 말고, 문서의 현행 표기와 계정 권한을 대조해야 합니다.

작업 전에는 로그인 계정과 대상 자료의 접근 권한을 확인하고, 로컬에 쓸 수 있는 저장 위치를 마련합니다. 실행이 끝나면 도구가 표시한 결과 경로를 기록하고, 파일이 실제로 생성됐는지 확인합니다. 문서에서 안내하는 출력 형태와 항목을 기준으로 설정, 환경 변수, 예약 작업, 저장소 연결, 기억, 설정 스크립트, 세션 활동 기록을 차례로 대조합니다. 결과 경로나 일부 항목이 예상과 다르면 성공으로 간주하지 말고 공식 CLI 안내와 실행 결과를 다시 살펴보세요.

환경 변수 자료에는 토큰이나 다른 민감한 값이 들어 있을 수 있습니다. 내보낸 파일을 공개 저장소나 일반 작업 문서에 올리지 말고, 접근 제한과 보관 정책을 적용하세요. GitHub의 비밀 정보 관리 문서도 비밀 값의 저장과 취급 기준을 검토할 때 참고할 수 있습니다.

내보낸 자료에는 무엇이 들어가며, GitHub 코드는 따로 보관해야 하나요? 공식 공지에 명시된 Jules 설정과 작업 기록은 내보내기 결과에서 확인하되, 코드와 브랜치, 풀 리퀘스트는 GitHub에서 직접 확인해야 합니다. 저장소가 존재하는 것과 Jules의 예약 작업, 권한, 환경 변수가 재구성된 것은 서로 다른 상태입니다. 팀은 내보낸 자료와 GitHub 저장소를 각각 대조하는 것이 좋습니다.

Jules 자료를 다른 코딩 에이전트에 그대로 가져올 수 있다고 전제해서도 안 됩니다. 내보내기는 보존을 위한 절차이지, 다른 제품이 같은 형식으로 읽고 기존 작업을 이어받는다는 보장은 아닙니다. 팀에서 사용 중인 저장소 지침, 실행 스크립트, 테스트 방법은 새 환경에서 사람이 확인하고 다시 설정해야 할 수 있습니다.

Google Antigravity와 새 에이전트는 실제 저장소 작업으로 검증합니다

Google Antigravity가 Jules 작업과 설정을 자동으로 이어받나요? 공식 이전 공지에서 Google Antigravity를 언급했다는 사실만으로 자동 가져오기나 기능의 동등성이 확인된 것은 아닙니다. Google Antigravity 공식 소개를 확인하되, 자동 이전을 전제로 계획하지 마세요. 가져오기 기능이나 지원 범위가 공식 문서에 명시되기 전까지는 설정과 작업 흐름을 별도로 재구성하는 편이 안전합니다.

검증에는 재현 가능한 대표 작업 하나를 사용합니다. 저장소 지침을 읽고 작은 변경을 만들게 한 뒤, 프로젝트 테스트를 실행하고 사람이 변경 사항을 검토하는 흐름을 확인하세요. 성공 기준은 에이전트가 코드를 작성했는지만이 아닙니다. 새 작업 환경이 의존성을 준비하고, 필요한 권한만 사용하며, 테스트와 풀 리퀘스트 검토를 거쳐 결과를 전달해야 합니다.

Jules 이전 뒤 대체 에이전트의 저장소 작업과 테스트는 어떻게 검증하나요? 저장소를 연결한 뒤 작업 지침과 테스트 명령을 새 환경에서 확인하고, 제한된 권한으로 대표 작업을 실행합니다. 이어 테스트 로그와 변경 내역을 검토하고, 풀 리퀘스트 검토 책임자가 결과를 승인하는지 확인합니다. 에이전트 응답이 그럴듯해 보여도 테스트가 실행되지 않았거나 검토 단계가 빠졌다면 이전 완료로 판단하지 마세요.

Jules의 예약 작업을 다른 서비스로 옮길 때도 같은 원칙을 적용합니다. 실행 주기와 입력 조건, 실패 시 알림을 문서화하고, 담당자가 결과를 확인할 수 있는지 시험해야 합니다. 작업 기록이 내보내졌다는 사실만으로 예약 실행이 새 환경에서 복구됐다고 볼 수 없습니다.

macOS 전용 작업은 별도의 검증 대상으로 둡니다. 예를 들어 Xcode 프로젝트라면 새 환경에서 실제 빌드와 테스트가 가능한지 확인해야 합니다. Apple의 Xcode 시스템 요구 사항을 기준으로 필요한 macOS 환경을 확인하고, 해당 환경을 확보할 방법을 정하세요. 이 검증은 Jules 데이터 이전과는 별개입니다.

보관 책임자와 macOS 후속 작업을 지정합니다

마지막으로 내보낸 자료의 보관 위치와 접근 권한, 유지 책임자를 기록합니다. GitHub 저장소 담당자와 Jules 내보내기 자료 담당자가 다르다면 각자의 확인 범위를 명시하세요. 내보내기 결과에서 재구성할 수 없는 설정, 수동으로 다시 만들어야 하는 예약 작업, 사람의 판단이 필요한 세션은 별도 목록으로 남겨야 서비스 종료 이후에도 빈틈이 줄어듭니다.

다음 항목을 모두 확인할 때까지 이전 완료로 표시하지 마세요.

• [ ] 진행 중인 세션마다 완료 상태 또는 인계 담당자가 지정되어 있습니다.
• [ ] 공식 CLI 문서에 따라 Jules 자료를 내보냈고 결과 위치를 기록했습니다.
• [ ] 내보낸 설정, 환경 변수, 예약 작업, 저장소 연결, 기억, 스크립트와 세션 기록을 확인했습니다.
• [ ] 민감한 자료의 접근 권한을 제한하고 보관 위치를 정했습니다.
• [ ] GitHub의 코드, 브랜치, 풀 리퀘스트를 별도로 확인했습니다.
• [ ] 대표 저장소 작업에서 권한, 의존성, 테스트와 사람의 검토를 검증했습니다.
• [ ] macOS 전용 빌드가 있는 경우 해당 환경에서 별도로 확인했습니다.
• [ ] 남은 재구성 작업과 자료 보관 책임자를 기록했습니다.

이전 작업이 macOS 밖에서 끝나는 저장소 자동화라면, Mac을 추가하는 것보다 새 에이전트의 권한과 테스트 절차를 먼저 안정화하는 편이 적절합니다. 반대로 Xcode 빌드처럼 macOS 도구 체인이 필요한 작업은 Linux나 Windows 환경만으로 검증을 마칠 수 없습니다. 로컬 Mac은 직접 접근과 물리 장치 연결에 유리하지만, 팀의 공유 실행 환경으로 쓰려면 장비 운영과 가용성도 함께 고려해야 합니다.

Mac 환경이 필요한 작업을 짧게 이어서 시험해야 한다면, 새 장비를 바로 구매하기 전에 맥 이용 방식과 비용 비교를 살펴보고 요구 조건을 확인할 수 있습니다. 비밀 정보와 접근 정책은 자료 보호 안내와 함께 검토하세요. 원격 Mac이 모든 Jules 이전에 필요한 것은 아니지만, macOS 전용 빌드나 테스트가 남아 있고 로컬 장비를 마련하기 어렵다면 xcoderent의 실제 원격 Mac 환경으로 해당 단계를 검증하는 선택지가 있습니다. 다만 장기간 고정된 부하나 물리 장치 연결이 필수라면 자체 Mac 운영이 더 적합할 수 있습니다.

마무리 기준은 내보내기 파일을 만든 데 있지 않습니다. 세션 인계, 자료 대조, 대표 작업 실행, 테스트와 사람의 검토까지 확인하고 남은 일을 책임자에게 넘겼다면, 그 결과를 기준으로 다음 작업을 진행하면 됩니다.