Google Jules 사용법은 코드 자동완성보다 GitHub 이슈를 작게 쪼개고, 계획과 diff를 검토하는 방식에 가깝습니다. 비동기 코딩 에이전트를 실제 저장소 유지보수에 쓰는 흐름을 정리합니다.
Google Jules는 코드 자동완성 도구라기보다, GitHub 저장소를 읽고 별도 클라우드 환경에서 작업을 수행하는 비동기 코딩 에이전트입니다. 공식 공지에 따르면 Jules는 베타를 벗어나 공개 출시됐고, Gemini 2.5 기반으로 코드 계획을 세우며 GitHub 이슈 연동과 멀티모달 지원이 강화됐습니다.
언제 쓰면 좋은가
바로 옆에서 코드를 한 줄씩 제안받는 상황보다, ‘이 버그를 재현하고 테스트까지 추가해줘’, ‘의존성 버전을 올리고 깨지는 부분을 정리해줘’처럼 시간이 걸리는 유지보수 작업에 맞습니다. 사람이 계속 지켜보지 않아도 백그라운드에서 진행되는 점이 핵심입니다.
실사용 흐름
- 1단계: GitHub 저장소 연결 – Jules는 실제 코드베이스를 복제해 맥락을 파악하므로, 먼저 작업할 저장소와 브랜치 권한을 정리합니다.
- 2단계: 이슈를 작업 단위로 쪼개기 – ‘로그인 오류 수정’보다 ‘소셜 로그인 실패 시 500이 아니라 사용자 메시지를 보여주고 테스트를 추가’처럼 완료 조건을 써야 결과 검토가 쉽습니다.
- 3단계: Jules가 제시한 계획 확인 – 공식 설명처럼 Jules는 계획과 reasoning, diff를 보여주는 흐름을 갖습니다. 계획 단계에서 파일 범위가 과도하면 줄여서 다시 지시합니다.
- 4단계: 결과 diff와 테스트 확인 – 통과한 테스트, 바뀐 파일, 위험한 설정 변경 여부를 확인한 뒤 PR로 넘기는 방식이 안전합니다.
업무 예시
작은 쇼핑몰 프로젝트라면 ‘장바구니 수량 변경 시 합계가 즉시 반영되지 않는 문제를 찾아 수정하고, 관련 단위 테스트를 추가해줘’처럼 요청할 수 있습니다. 사내 관리자 페이지라면 ‘오래된 API 호출을 새 엔드포인트로 바꾸되 화면 문구와 권한 체크는 유지해줘’처럼 보존 조건을 같이 적는 것이 좋습니다.
주의할 점
비동기 에이전트는 편하지만, 저장소 접근 권한을 넓게 열수록 검토 책임도 커집니다. 프로덕션 비밀키, 배포 토큰, 결제 관련 코드는 별도 권한 관리가 필요합니다. Jules 결과는 바로 병합하기보다 사람이 diff를 보고 테스트 로그를 확인하는 단계가 반드시 있어야 합니다.
Jules에 맡기기 좋은 요청과 피해야 할 요청
Jules에는 반복적이지만 검토 가능한 작업을 맡기는 것이 좋습니다. 예를 들어 ‘테스트가 없는 결제 금액 계산 함수에 단위 테스트 추가’, ‘오래된 패키지 업데이트 후 깨지는 타입 오류 수정’, ‘GitHub 이슈 42번의 재현 조건을 코드에서 찾아 수정’ 같은 요청은 범위와 완료 기준이 분명합니다.
반대로 ‘서비스 구조를 전부 개선해줘’처럼 넓은 요청은 사람이 의도하지 않은 대규모 변경으로 이어질 수 있습니다. 처음에는 파일 범위를 제한하고, 설정 파일·배포 파일·보안 관련 파일은 수정 전에 확인을 요구하는 방식이 안전합니다.
PR로 넘기기 전 확인할 것
- Jules가 설명한 계획과 실제 diff가 일치하는지 확인합니다.
- 새로 추가된 테스트가 실제 버그를 재현하는지 봅니다.
- 패키지 업데이트가 lock 파일만 바꾼 것인지, 런타임 코드까지 바꿨는지 구분합니다.
- 자동 생성된 코드 주석이나 임시 로그가 남아 있지 않은지 확인합니다.
처음 사용하는 팀이라면 실제 운영 저장소보다 샘플 저장소나 내부 도구 저장소에서 먼저 시도하는 편이 좋습니다. 한 번의 작업에서 코드 스타일, 테스트 실행 방식, 리뷰 문화를 얼마나 잘 따라오는지 확인한 뒤 주요 저장소로 넓히는 단계적 도입이 안전합니다.