Jules 종료 전 보존할 것: GitHub 코드와 세션 기록은 다르다

코드와 작업 맥락을 나눠 보관하는 모습을 표현한 생성형 개념 이미지다. 실제 Jules 화면이 아니다.

Jules 종료를 앞두고 GitHub 저장소만 복제하면 충분할까. 코드와 에이전트의 작업 기록은 서로 다른 보존 대상이다. 먼저 미완료 세션을 정리하고, 서비스 안에 남은 맥락을 별도로 내보낸 뒤 실제로 다시 읽고 사용할 수 있는지 확인해야 한다.

이 글은 공개 공지와 문서를 바탕으로 정리한 준비 가이드다. 실제 계정의 내보내기나 마이그레이션을 실행한 후기는 아니다.

먼저 확인할 일정과 보존 범위

Google은 2026년 10월 29일 Jules 종료를 발표했다. 세션 작업을 마무리할 수 있는 기한은 11월 11일이며, 그 이후 연말까지 읽기 전용으로 전환하고 12월 31일 서비스를 종료한다고 안내한다. 정확한 전환 시각과 시간대는 명시하지 않았다. 따라서 마지막 날에 작업을 몰아넣는 계획은 피하는 편이 좋다.

GitHub에 이미 저장된 코드·브랜치·PR은 그대로 남는다. 별도 내보내기는 Jules 내부의 설정과 이력을 다룬다. 공식 범위에는 계정 설정, 환경변수, 예약 작업, 연결 저장소, 메모리, 설정 스크립트와 세션별 프롬프트·계획·활동 로그·패치가 포함된다. Jules 공식 종료 공지

1. 백업보다 먼저 미완료 작업을 분류한다

아래는 이 글에서 제안하는 점검 순서다.

아직 검토하지 않은 변경: 어떤 세션에서 나왔는지, 어떤 커밋을 기준으로 작성됐는지 기록한다.

PR까지 올라간 변경: GitHub에서 실제 브랜치와 PR을 열어 확인한다. 생성 완료 표시만으로 판단하지 않는다.

Jules에만 남은 판단 근거: 실패한 접근, 재현 조건, 테스트 명령 등 다음 작업자가 알아야 할 내용을 선별한다.

반복 작업: 예약의 목적과 실행 주기를 정리한다. 내보낸 설정 파일이 다른 도구에서 자동 실행된다고 가정하지 않는다.

예를 들어 세션이 만든 패치를 GitHub에 올렸더라도, 특정 테스트를 제외한 이유가 대화에만 남아 있을 수 있다. 반대로 이미 병합된 코드를 다시 적용하면 중복 변경이 된다. 보존 목록에는 “저장됨”뿐 아니라 “어디에 저장됐고 검토가 끝났는가”를 함께 남기는 것이 유용하다.

2. 공식 내보내기 절차를 그대로 확인한다

공식 공지는 Jules Tools 설치와 로그인을 안내한 뒤, 페이지에 제공된 내보내기 프롬프트를 CLI 코딩 에이전트에서 실행하는 절차를 제시한다. 결과는 로컬 폴더에 저장된다. 아래는 공지의 준비 명령이며, 이 글을 작성하면서 실행하지 않았다.

실제 실행 전에는 공식 공지의 최신 내보내기 프롬프트를 직접 읽는다. 여기서는 긴 스크립트를 복제해 시간이 지나면 낡는 별도 배포본을 만들지 않는다.

공식 예제는 일부 문서화되지 않은 엔드포인트를 사용한다고 밝힌다. 오류가 나면 임의로 인증 방식을 바꾸거나 성공으로 간주하지 말고 실패한 단계와 응답을 확인해야 한다.

3. 내보낸 폴더는 비밀정보가 포함된 백업으로 취급한다

특히 공식 안내의 env-variables.json에는 환경변수 값이 들어간다. 내보낸 폴더를 저장소에 넣지 말고 비공개로 유지하라는 경고가 있다. 공식 내보내기 주의사항

실무적으로는 다음 원칙을 권한다.

코드 저장소나 공개 동기화 폴더 밖에 보관한다.

백업 경로와 접근 권한을 먼저 정하고, 팀에 공유할 때도 필요한 범위만 전달한다.

문제를 문의할 때 토큰이나 환경변수 원문 대신 오류 코드와 비밀정보를 제거한 로그를 사용한다.

새로운 코딩 도구에 전체 폴더를 곧바로 넣지 않는다. 먼저 비밀값과 업무상 비공개 맥락을 분리한다.

내보내기를 완료했다는 사실은 새 도구로 이전이 완료됐다는 뜻이 아니다. 프롬프트와 메모리, 예약 설정은 도구마다 의미가 다르므로 사람이 검토한 뒤 필요한 내용만 재구성해야 한다.

4. 파일이 생겼는지와 복구 가능한지는 따로 확인한다

백업 검증은 다음 세 층으로 나눌 수 있다. 이 구분은 공식 제품 기능이 아니라 이 글의 운영 제안이다.

목록 검사: 필요한 저장소와 세션이 포함됐는지 대조한다. 세션 수가 0이어도 실제 사용 이력과 맞는지 확인한다.

내용 검사: 중요한 작업의 요약·활동 로그·패치를 열어 읽는다. 파일 크기가 0이 아닌 것만으로 충분하지 않다.

사용 가능성 검사: 별도 작업 복사본에서 패치 적용 가능성과 프로젝트 테스트를 확인한다.

Git 패치는 적용 전에 변경 범위와 적용 가능성을 읽기 전용으로 검사할 수 있다. 다음은 경로를 자신의 파일에 맞춰 바꿔 사용하는 문서 기반 예시다.

--stat은 변경 통계를 보여주고, --check는 패치를 실제 적용하지 않고 현재 작업 트리에 적용 가능한지 검사한다. 성공하더라도 테스트 통과나 요구사항 충족을 뜻하지 않는다. 이미 반영된 변경인지 검토한 뒤 실제 적용·테스트 여부를 결정한다. Git apply 공식 문서