Composer를 개발하는 방식에서 특히 주목할 만한 점 중 하나는, 이전 버전의 모델을 활용해 이후 버전의 학습 과정을 개선한다는 것입니다.

이런 종류의 부트스트래핑이 가장 분명한 효과를 내는 영역 중 하나가 환경 설정입니다. RL 학습에는 실행 가능한 환경이 필요하며, 시작부터 환경이 망가져 있으면 모델은 과제 해결을 학습하는 대신 환경 설정을 디버깅하느라 토큰을 낭비하게 됩니다. 최악의 경우에는 잘못된 환경 때문에 과제 자체를 아예 풀 수 없게 되어, 아무 보상 신호도 없이 컴퓨팅 자원만 소모하게 됩니다.

이를 해결하기 위해 저희는 설정되지 않은 상태로 체크아웃된 리포지토리에서 작동하는 RL 환경을 자동으로 만드는 시스템인 Composer autoinstall을 만들었습니다. 최신 모델 버전인 Composer 2를 학습시키는 동안에는, 이전 버전인 Composer 1.5를 사용해 이 과정을 관리했습니다. 또한 최신 coding model은 단순히 단계별 안내를 따르는 데 그치지 않고, 프로젝트 의존성을 성공적으로 설정하고, 이를 모의로 대체하고, 설정이 제대로 되었는지 테스트하기 위해서도 상당한 노력을 기울인다는 점을 확인했습니다.

#더 나은 환경은 더 나은 학습 신호를 만듭니다

모델 개발의 여러 측면과 마찬가지로, autoinstall도 프로덕션 Cursor 시스템에서 영감을 받았습니다. Cursor 클라우드 에이전트에는 사용자를 위해 클라우드 환경 설정을 자동화하여 에이전트가 모의 환경에서 프로젝트 작업을 할 수 있게 해 주는 기능이 있습니다. git 체크아웃 상태에서 시작해, 에이전트는 패키지를 설치하고 설정을 설정한 뒤, 코드가 정상적으로 실행되고 안정적인지 확인하는 기본 점검을 수행합니다. 이렇게 하면 이후 요청도 올바르게 설정된 환경에서 시작할 수 있습니다.

RL 학습에서는 이 문제가 훨씬 더 핵심적이지만, 동시에 해결하기 까다로울 수 있습니다. 리포지토리에서 시작해, autoinstall의 목표는 앞으로 마주할 아직 알려지지 않은 코딩 문제를 해결할 수 있도록 코드베이스의 실행 가능한 모의 기본 버전을 만드는 것입니다. 이 기본 환경이 중요한 이유는 Composer가 프로그래밍 언어 린트 명령, 검색, 샌드박스된 셸 사용을 포함한 전체 도구 세트를 활용하는 환경에서 학습되기 때문입니다. 환경을 올바르게 설정하지 못하면 학습이 비효율적이 되고, 보상 신호도 얻지 못한 채 연산 자원만 낭비할 수 있습니다.

#한 에이전트가 성공을 정의하고, 다음 에이전트가 이를 시도합니다

Autoinstall은 두 단계로 이루어집니다. 첫 번째 "목표 설정" 단계에서는 고정된 체크아웃 상태의 코드베이스를 Cursor 에이전트에 제공하고, 환경이 올바르게 설정되어 있다면 실행되어야 할 10개의 명령어와 예상 출력에 대한 상위 수준 설명을 제안하도록 요청합니다.

에이전트는 환경과 관련된 README나 Makefile을 살펴보고, uv 같은 프로젝트 관리 도구나 clippy 같은 린터처럼 일반적인 언어별 명령어도 시도합니다. 에이전트의 작업은 일반적으로 설정 명령어, 가능한 경우 테스트, 그리고 실행 파일을 위한 시작 명령어로 구성됩니다.

두 번째 단계에서는 별도의 Composer 에이전트에 환경의 초기 상태와 제안된 10개 중에서 선택한 3개의 대상 명령어를 제공합니다. 그러면 에이전트는 코드베이스를 살펴보며, 명령어를 실행할 수 있도록 환경을 설정하기 위해 도구 호출을 수행합니다. 이후에는 세 명령어가 모두 실행되는지, 그리고 출력이 첫 번째 에이전트가 제시한 대상 설명과 일치하는지 테스트합니다. 그렇지 않으면 두 번째 단계를 다시 시작합니다. 이 과정을 다섯 번 반복한 뒤에도 에이전트가 환경을 만족스러운 수준으로 설정하지 못하면, 해당 환경은 폐기합니다.

Autoinstall을 통해 Composer는 가능한 한 완전한 방식으로 환경을 올바르게 설정하는 것을 목표로 합니다. 이를 위해 누락된 파일을 모의로 만들거나, 플레이스홀더 이미지를 생성하거나, 심지어 가짜 데이터베이스 테이블까지 만들 수 있습니다. 일부 프로젝트는 테스트를 실행하는 데 필요한 추가 구성 요소를 설치해야 하며, 예를 들어 S3 폴더나 누락된 사이드카 컨테이너가 이에 해당합니다. Composer는 이런 경우도 자주 모의로 구성하며, 이를 작동시키기 위해 MinIO 구성이나 Docker 컨테이너를 만듭니다. 장시간 실행되는 프로세스를 지원하기 위해, RL 사용량 시작 시 이들을 시작할 수 있도록 Autoinstall이 시작 스크립트를 만들 수 있게 했습니다.

#실제 프로젝트를 위한 Autoinstall

Autoinstall 과정을 설명하기 위해, Autoinstall을 사용해 복잡한 실제 프로젝트를 설정한 실제 실험 사례를 살펴보겠습니다. celo-org/celo-monorepo에 구현된 Celo는 여러 주요 의존성을 가진 대규모 블록체인 프로젝트입니다. 이 프로젝트는 설치를 위해 많은 의존성을 관리해야 하고, Testing을 위해 인증 흐름을 모의해야 하므로 Autoinstall을 시험해 보기에 흥미로운 사례입니다.

첫 번째 Autoinstall 단계에서는 에이전트가 핵심 설치 명령을 찾기 위해 프로젝트의 문서와 코드를 살펴보는 모습을 관찰했습니다. 하지만 프로젝트에 포함된 문서는 비교적 부족했기 때문에, 추가 설정 명령을 찾기 위해 프로젝트의 문서 사이트를 웹 명령으로 검색하기도 했습니다. 확인된 명령의 대부분은 설치나 테스트와 관련된 것이었지만, 문서에 나온 소프트웨어를 활용하기 위한 기본적인 최소 애플리케이션도 포함되어 있었습니다.

두 번째 단계에서 에이전트는 실제로 이러한 명령을 실행하는 과제를 맡았습니다. 해야 할 작업은 분명했지만, 모델은 어떤 문제에 부딪힐지 사전에 알지 못했습니다. 이 사례에서는 관련 repo인 Foundry 등 여러 다른 의존성을 설치해야 한다는 점을 찾아냈습니다. 필요한 이 프로젝트의 문서를 읽기 위해 웹 검색도 사용했습니다. 또한 이 환경에서 최소 애플리케이션을 실행하는 과제도 맡았습니다. 이 단계의 첫 번째 반복에서는 이 테스트 애플리케이션을 실행하지 못했지만, 두 번째 반복에서는 모의 사용자를 만들어 애플리케이션을 로컬에서 시작하고 요구 사항을 충족할 수 있다는 점을 찾아냈습니다."

#차세대를 위한 부트스트래핑.

Autoinstall은 이전 모델을 활용해 RL 과정을 부트스트래핑한 흥미로운 예시입니다. 특히 Composer 2는 이제 Terminal-Bench에서 훨씬 더 높은 점수를 기록하고 있습니다(Composer 1.5의 47.9% 대비 61.7%). 이 벤치마크에는 모델이 개발자 환경을 설정하는 능력을 평가하는 테스트가 포함됩니다. 이는 Composer 2가 autoinstall을 위한 더 나은 기반을 제공할 것임을 보여줍니다. 앞으로의 실행에서는 이전 Composer 인스턴스가 실행 관리, 데이터 전처리, 아키텍처 튜닝을 포함해 학습 과정의 여러 다른 측면에서도 큰 역할을 할 것으로 예상합니다.

Composer 2에 대해 자세히 알아보기