Jules 같은 AI 코딩 에이전트는 개발자가 다른 일에 집중하는 동안 코드를 빌드, 리팩터링, 스캐폴드할 수 있습니다. 이런 편리함과 사용 편의성은 매우 반갑지만 때로는 미묘한 버그, 놓친 엣지 케이스, 미검증된 가정이 생길 수도 있다는 뜻이기도 합니다. 그래서 개발자가 코드를 보기 전에 먼저 자동으로 검토하고 비판하는 새로운 기능을 Jules에 도입하려 합니다.
그 역할은 간단하지만 강력합니다. Jules가 코드를 빌드하는 동안 비평가 기능은 코드를 비판적으로 검토합니다. 제안된 모든 변경 사항은 적대적일 정도로 비판적인 검토를 거친 후에 완료됩니다. 즉, 비평가 기능이란 Jules의 동료 검토자로서 코드 품질 원칙을 심도 있게 숙지한 상태에서, 개발자가 버그가 발생할 위험이 있는 새로운 방식으로 코딩할 때 주저 없이 지적하는 역할을 한다고 생각하시면 됩니다.
비평가 기능은 비평 기능 증강 생성이라는 코드 생성 프로세스에 직접 통합됩니다. 이번 첫 번째 버전의 경우, 최종 출력을 한 번에 평가하는 원샷 프로세스 방식입니다. 향후 목표는 도구 호출을 사용할 수 있거나 하위 작업 후 또는 계획 이전에 트리거할 수 있는 진정한 다단계 에이전트로 만드는 것이지만, 현재로서는 전체 생성 결과를 한 번에 검토합니다. 이러한 비평가 기능은 외부 도구(예: 코드 해석기 또는 검색엔진)를 사용하여 출력 결과를 검증하고 그 결과로부터 학습하는 다단계 연구에 기반을 두게 될 것입니다.
비평가 기능은 코드를 수정하는 것이 아니라, 코드의 필요한 부분에 플래그를 지정한 다음 Jules가 개선하도록 다시 전달하는 역할을 합니다. 예를 들면 다음과 같습니다.
이는 패치가 생성된 후 제출되기 전에 발생하므로(여전히 플래그가 지정된 경우에는 여러 번 발생할 수도 있음), Jules는 실시간으로 계획을 다시 세울 수 있습니다. 조잡한 PR을 줄이고, 테스트 범위를 개선하며, 보안을 강화하는 것이 저희의 목표입니다.
Linter는 깊이 없이 고정된 규칙을 따르고 테스트는 특정 어설션을 검증할 뿐입니다. 반면, 비평가 기능은 코드 이면에 숨은 인텐트와 컨텍스트까지 이해합니다. 이는 참조 없이 정확성과 견고성을 판단하는 평가 방법에 더 가깝고, 표준적인 구현 없이도 판단할 수 있습니다.
또한 비평가 기능은 LLM-as-a-judge에 대한 연구에서 영감을 받았는데, 한 모델이 품질과 정확성에 대해 다른 모델의 작업을 평가하는 방식입니다. 이러한 종류의 자동 심사는 생성과 긴밀하게 통합될 때 유용하고, 검토를 실시간 피드백 루프로 전환할 수 있습니다.
1: Jules에 작업을 시작하라고 지시합니다.
2: 비평가 기능은 후보 패치와 그에 대한 설명을 한 번에 검토하여 전반적인 판단을 내립니다.
3: Jules가 피드백에 응답한 후 작업을 마치며, 그 후 비평가 기능이 업데이트된 패치를 다시 검토하고 더 이상 문제가 남지 않을 때까지 필요하다고 판단하는 모든 사항에 계속 플래그를 지정할 수 있습니다.
4: 이미 내부적으로 검토된 코드를 받습니다.
이 방식은 '행위자'가 생성하고 '비평가'가 평가하는 행위자-비평가 강화 학습(RL)에서 차용한 것입니다. RL에서 이 루프는 학습 신호를 기반으로 행위자와 비평가를 업데이트합니다. LLM-as-critic 설정에서도 패턴은 비슷합니다. 즉, 제안한 후 평가하는 것입니다. 하지만 학습 매개변수를 업데이트하는 대신 피드백은 현재 상태와 다음 단계에 영향을 미칩니다. 이와 동일한 원리가 재학습 없이도 비평가의 평가를 통해 품질을 관리하는 LLM-as-a-judge에 대한 연구도 뒷받침합니다.
반복이 빠르게 진행되는 세계에서 비평가 기능은 검토를 프로세스 초기에, 그리고 생성 행위 자체로 옮깁니다. 이는 사람이 검토한 코드가 이미 점검, 미세 조정, 스트레스 테스트를 거쳤음을 의미합니다. 물론, 사용하기 전에 항상 개발자는 생성된 코드를 신중하게 검토해야 합니다.
훌륭한 개발자는 단순히 코드를 작성하는 데 그치지 않고 의문을 제기합니다. 이제 Jules도 마찬가지 역할을 합니다.
