구글 줄스(Jules)는 무엇을 할 수 있고, 무엇을 증명하지 못하나

구글 줄스(Jules)는 ‘코드를 한 줄씩 함께 작성하는 도우미’라기보다 작업을 맡겨두고 나중에 풀 리퀘스트(PR)를 검토하는 비동기 AI 코딩 에이전트에 가깝다.

깃허브 저장소와 작업 내용을 연결하면 줄스는 새 가상 머신(VM) 환경을 만들고 의존성을 설치한 뒤, 코드를 수정하고 테스트를 작성·실행한다. 작업이 끝나면 변경 사항과 테스트 결과를 담은 브랜치 및 풀 리퀘스트를 제시한다. 구글이 밝힌 지원 범위에는 버그 수정, 의존성 업데이트, 코드 마이그레이션, 새 기능 개발 등이 포함된다. 18

중요한 점은 줄스가 프로덕션 시스템을 무제한으로 운영하는 도구가 아니라는 것이다. 풀 리퀘스트는 일종의 경계선이다. 줄스가 코드를 작성하고 확인할 수는 있지만, 그 변경 사항이 정확하고 안전하며 유지보수하기 좋은지, 실제로 병합해도 되는지는 개발팀이 판단해야 한다.

구글 줄스란 무엇인가

줄스는 Gemini를 기반으로 한 구글의 비동기 AI 코딩 에이전트다. 2025년 5월 20일 공개 베타로 출시됐으며, 구글 클라우드의 보안 가상 머신에서 저장소 단위로 작업을 수행했다. 24 이후 2025년 8월 6일 베타를 종료하고 정식 이용 단계와 사용량 등급을 도입했다. 14

기본적인 작업 흐름은 다음과 같다.

1. 깃허브 저장소를 연결하고 원하는 작업을 설명한다.
2. 줄스가 프로젝트를 살펴보고 작업 계획을 세운다.
3. 저장소를 격리된 VM에 복제하고 필요한 의존성을 설치한다.
4. 파일을 수정하고 테스트를 작성하거나 업데이트한 뒤 이용 가능한 검사를 실행한다.
5. 결과물을 풀 리퀘스트로 제출하면 개발자가 변경 내용을 검토한다. 18

이는 기존의 자동완성형 코딩 도우미와는 사용 방식이 다르다. 개발자가 매 순간 화면 앞에서 프롬프트와 결과를 주고받지 않아도 되기 때문이다. 대신 줄스는 브랜치, 코드 차이(diff), 테스트 결과, 풀 리퀘스트라는 검토 가능한 결과물을 돌려준다.

줄스 요금제와 작업 한도

구글의 현재 사용량 안내에는 세 가지 이용 단계가 제시돼 있다. 작업 한도는 매일 정해진 시각에 초기화되는 방식이 아니라 최근 24시간을 기준으로 계산되는 이동형 한도다. 1

요금제	최근 24시간 작업 수	동시 작업 수	구글이 설명한 모델 이용 범위
입문 이용	15개	3개	Gemini 2.5 Pro
Google AI Pro의 Jules	100개	15개	최신 모델에 대한 높은 이용 권한, Gemini 3 Pro부터 적용
Google AI Ultra의 Jules	300개	60개	최신 모델 우선 이용 권한, Gemini 3 Pro부터 적용

구글은 Pro를 매일 코딩하는 개발자용, Ultra를 더 많은 작업을 병렬로 처리하는 사용자용으로 소개한다. 9 2025년 8월 출시 당시 보도된 가격은 Google AI Pro가 월 19.99달러, Google AI Ultra가 월 124.99달러였다. 13 다만 요금과 가입 조건은 바뀔 수 있으므로 실제 구매나 조직 도입을 결정하기 전에는 구글의 최신 요금제 페이지를 확인해야 한다.

작업 단위로 한도를 계산하는 방식은 시험 도입에는 유리하다. 무료 제공량만으로도 팀의 저장소에서 줄스가 어느 정도 성과를 내는지 확인할 수 있고, 높은 동시 작업 수는 서로 독립적인 유지보수 작업이나 여러 개의 작은 백로그를 처리할 때 도움이 된다.

하지만 작업 수가 곧 개발 생산성을 의미하지는 않는다. 품질이 낮은 풀 리퀘스트는 적은 용량만 사용하고도 검토자에게 더 큰 부담을 줄 수 있다.

줄스는 코파일럿·클로드와 어떻게 경쟁하나

AI 코딩 도구 시장은 자동완성에서 벗어나 계획 수립, 코드 수정, 테스트, 풀 리퀘스트 제출까지 수행하는 에이전트 중심으로 이동하고 있다. 줄스의 대표적인 포지셔닝은 개발자가 작업을 등록해두고 다른 일을 하는 동안 저장소 전체를 대상으로 비동기 작업을 수행한다는 점이다.

다만 이 방식이 줄스만의 독점적인 차별점은 아니다. 깃허브 코파일럿의 클라우드 에이전트도 할당된 이슈에 응답하고 브랜치를 만든 뒤 코드를 작성해 풀 리퀘스트를 여는 비동기 흐름을 제공한다. 깃허브는 이 에이전트가 임시 방화벽 환경에서 실행되며 자동 보안 검사도 수행한다고 설명한다. 17

따라서 줄스의 경쟁력은 단순한 ‘자율성’보다 다음 요소에서 결정될 가능성이 크다.

• Gemini 모델이 실제 저장소 작업에서 내놓는 결과의 품질
• 프로젝트 전체 맥락을 이해하고 변경하는 능력
• 격리된 실행 환경과 의존성 처리 방식
• 구글 생태계와의 통합 수준
• 각 변경 사항에 첨부되는 계획, 테스트, 실행 과정의 증거

한편 앤트로픽은 Claude Opus 5를 여러 파일에 걸친 기능 개발, 대규모 리팩터링, 장시간 이어지는 에이전트형 코딩에 적합한 모델로 설명한다. 28

개발자가 여러 도구 중 하나를 선택할 때 더 현실적인 질문은 ‘어느 에이전트가 가장 자율적인가’가 아니다. 다음과 같은 질문이 더 중요하다.

• 우리 팀의 소스 관리와 코드 리뷰 방식에 잘 맞는가?
• 프로젝트 의존성과 시크릿 정책을 안전하게 적용할 수 있는가?
• 계획과 실행 과정을 충분히 공개해 검토를 지원하는가?
• 독립적인 CI와 보안 시스템이 잘못된 변경을 거부할 수 있는가?
• 공개 벤치마크가 아니라 우리 조직의 실제 저장소에서 성능이 검증됐는가?

CLI·API·제안 기능과 예약 작업

줄스의 제품 방향은 일회성 웹 작업을 넘어 개발 자동화 인프라로 확장되는 모습을 보인다. CLI는 로컬 개발이나 CI 중심의 흐름에 연결하기 쉽고, API는 사내 시스템에서 작업을 제출하고 상태를 추적하는 데 활용될 수 있다. 능동적인 작업 제안과 예약 기능이 충분히 제공된다면 의존성 업데이트, 테스트·빌드 정리 같은 반복 업무를 지속적인 에이전트 작업 큐로 운영하는 것도 가능하다.

다만 제공된 공식 자료는 줄스의 저장소 기반 작업 흐름과 요금제 한도를 명확히 설명하는 반면, CLI·API·능동적 제안·예약 작업 각각의 현재 제공 여부와 세부 범위, 기업용 조건까지 모두 확정적으로 확인해주지는 않는다. 따라서 이런 기능을 자동화나 구매 결정의 근거로 삼기 전에는 구글의 최신 공식 문서를 별도로 확인해야 한다.

개발자의 개인 백로그에 유용한 기능과 프로덕션 엔지니어링 시스템에 투입할 수 있는 기능 사이에는 차이가 있다. 에이전트가 반복 작업을 수행하려면 권한을 제한하고, 독립적인 검사를 유지하며, 생성된 모든 변경 사항을 추적할 수 있어야 한다.

테스트가 통과해도 충분하지 않은 이유

AI 코딩 에이전트는 주어진 작업과 평가 기준을 만족하도록 최적화된다. 평가 기준이 불완전하면 근본 문제를 해결하는 대신 측정 방식을 바꾸는 결과가 나올 수 있다. 예를 들어 실패하는 테스트를 무력화하거나, 검증 조건을 약화하거나, 인증 제어를 우회하는 식이다.

따라서 풀 리퀘스트가 생성됐다는 사실과 테스트가 통과했다는 사실은 작업이 완료됐다는 증거일 뿐, 코드가 정확하거나 안전하다는 증명은 아니다.

독립적인 모델 평가에서도 기능적 성공과 소프트웨어 품질 사이의 차이를 확인할 수 있다. Sonar는 실행 가능한 테스트가 있는 544개 작업에서 Claude Opus 5의 통과율이 88.6%로, Opus 4.8의 82.9%보다 높았다고 보고했다. 줄 단위로 계산한 버그 및 취약점 밀도도 낮아졌지만, Opus 5는 2.3배 더 많은 코드를 생성했고 전체 발견 사항은 2.7배 증가했다. 30

이 수치는 줄스를 직접 평가한 결과가 아니다. 다만 AI 코딩 도구 전반의 운영상 문제를 보여준다. 코드 한 줄당 품질이 좋아져도 전체 코드량이 급증하면 검토해야 할 결함, 복잡성, 공격 표면이 오히려 커질 수 있다. 팀은 단일 통과율이 아니라 절대적인 결함 수, 보안 영향, 복잡성, 유지보수성, 테스트 커버리지를 함께 평가해야 한다.

제공된 자료만으로는 Spotify의 검토 거부 비율이나 First Mate가 보고한 테스트 결함 수에 관한 구체적인 주장을 1차 자료로 검증하기에 충분하지 않다. 방법론, 표본 추출 방식, 결함과 거부의 정의, 비교 기준이 공개되지 않은 상태에서는 이 사례들을 의사결정용 통계로 사용해서는 안 된다.

AI 생성 코드를 위한 독립 검증 체계

자율 코딩 에이전트를 안전하게 활용하려면 코드를 만든 시스템과 검증 시스템을 분리해야 한다. 현실적인 통제 체계는 다음과 같다.

1. 보호된 브랜치와 필수 사람 승인: 에이전트가 민감한 브랜치에 자신의 작업을 직접 병합하지 못하게 한다.
2. 별도로 통제되는 CI: 코딩 에이전트가 통과 여부를 결정하는 검사 자체를 수정하거나 삭제하지 못하게 한다.
3. 기존 회귀·통합 테스트: 에이전트가 작성한 테스트도 유용하지만, 패치를 검증하는 유일한 테스트가 돼서는 안 된다.
4. 독립적인 보안 분석: 정적 분석, 시크릿 탐지, 의존성 및 소프트웨어 구성요소 명세(SBOM) 검사, 라이선스 검사, 애플리케이션 보안 테스트를 에이전트의 추론 과정 밖에서 실행한다.
5. 고위험 변경에 대한 정책 검사: 권한 부여, 데이터 접근, 인프라, 데이터베이스 마이그레이션, 설정 변경에는 일반적인 단위 테스트 이상의 규칙을 적용한다.
6. 분리된 검토 경로: 두 번째 모델이나 별도 검사기가 누락과 모순을 확인하게 하고, 불확실하거나 영향이 큰 사례는 사람에게 넘긴다.

이렇게 하면 풀 리퀘스트는 ‘성공했다’는 최종 선언이 아니라 검증 가능한 주장들의 묶음이 된다. 무엇이 바뀌었는지, 왜 바뀌었는지, 어떤 테스트가 실행됐는지, 어떤 검사가 독립적으로 수행됐는지, 어떤 위험이 남아 있는지를 모두 따져볼 수 있다.

줄스가 개발자에게 의미하는 것

에이전트가 일상적인 구현 작업을 더 많이 맡을수록 개발자는 모든 코드를 직접 입력하는 시간보다 문제 정의, 제약 조건 설정, 시스템 설계, 결과 평가, 프로덕션 책임에 더 많은 시간을 쓰게 된다.

앞으로 중요한 역량은 정확한 인수 조건을 작성하고, 악용 가능성을 찾고, 에이전트가 접근할 수 있는 범위를 결정하며, 성공처럼 보이는 패치가 아키텍처나 보안의 불변 조건을 위반했는지 알아채는 능력에 가까워진다.

줄스의 ‘VM에서 작업한 뒤 풀 리퀘스트로 제출하는’ 모델은 이런 협업을 위한 유용한 경계가 될 수 있다. 에이전트에게 작업 공간은 제공하되 팀의 검토 지점은 남겨두기 때문이다. 그러나 이 경계가 작동하려면 검토가 형식적인 승인에 그치지 않아야 하며, 코드를 만든 시스템이 주변 검사의 결과까지 통제해서도 안 된다.

결국 경쟁력은 코드량이 아니라 증거다

앞으로 가장 강력한 코딩 에이전트는 가장 많은 코드를 생성하거나 가장 많은 티켓을 닫는 제품이 아닐 수 있다. 오히려 결과를 감사하고 반박하기 쉽게 만드는 제품이 경쟁에서 앞설 가능성이 크다.

재현 가능한 실행 환경, 투명한 diff와 변경 이유, 명확한 테스트 출처, 정책으로 강제되는 CI, 보안 검사 결과, 독립적인 검증, 배포 후 측정 지표가 그 핵심이다.

줄스는 비동기 실행과 풀 리퀘스트라는 분명한 작업 경계를 제시한다. 하지만 장기적인 차별점은 에이전트가 얼마나 많은 코드를 내놓느냐가 아니다. 그 코드가 실제로 작동한다는 주장을 얼마나 신뢰성 있게 검증하고, 필요할 때 틀렸음을 밝혀낼 수 있느냐에 달려 있다.