MASS 해설: 같은 AI로 팀을 꾸리고 그 작업 기록으로 다시 학습하기

배경과 문제

자기 개선에는 성과를 평가하는 과정과 그 평가로 다음 행동을 바꾸는 과정이 모두 필요하다. 연구처럼 정답이 정해져 있지 않은 과제는 결과를 검증하는 데 오래 걸리거나 전문 지식이 필요하다. MASS는 이때 현재 모델보다 강한 감독자를 계속 사용할 수 없다고 가정하고, 같은 모델에서 유용한 학습 신호를 얻는 방법을 연구한다. 실제로 모든 분야에서 AI가 사람보다 뛰어난 평가자라는 사실을 전제한 것은 아니다.

문제는 같은 모델이 과제 수행, 평가, 개선을 모두 맡으면 오류가 바로잡히기보다 오히려 강화될 수 있다는 점이다. 생성과 평가가 같은 학습된 사전 지식을 공유하기 때문이다. 예를 들어 혼자 쓴 보고서의 오류를 스스로 찾기는 어렵다. 같은 사람이 같은 생각으로 다시 읽기 때문이다. 이 연구는 바로 이 '동질적 루프'에서 유용한 자기 감독 신호를 어디서 얻을지 질문한다. 연구팀은 모델 하나를 그대로 두고 자기비판을 시키는 대신, 같은 모델의 복제본들에게 서로 다른 역할을 맡겨 팀으로 일하게 하는 발상의 전환을 제안한다.

기존 접근의 한계

Self-Refine처럼 모델이 자기 출력을 비평하고 고치는 방법은 가중치를 고정한 채 작동한다. Self-Rewarding Language Models는 자체 점수로 선호 학습을 반복한다. 저자들이 지적하는 공통 어려움은 생성자와 평가자가 같은 지식을 공유할 때 같은 오류를 계속 놓칠 수 있다는 점이다. 팀의 구성과 정보 전달 방식을 바꾸면 그중 일부 문제를 줄일 수 있는지가 MASS의 질문이다.

ADAS·AFlow·GPTSwarm은 에이전트 구조를 탐색하고, SIA·HASE는 작업 체계와 가중치를 함께 갱신하는 연구다. MASS의 특징은 핵심 학습 루프에서 현재 모델이 실행·평가·수정을 모두 맡는다는 점이다. 그러나 실험 전체에서 외부 모델을 쓰지 않은 것은 아니다. 합성 과제는 GPT-5.5가 만들었고, 사후 성과 보고에는 별도의 강한 모델 판정을 사용했다.

연구방법을 단계별로

MASS는 두 단계를 번갈아 수행한다. 먼저 내부 루프에서는 모델 가중치를 고정한 채 멀티에이전트 워크플로우를 탐색한다. 워크플로우는 코드가 아니라 과제 프롬프트 뒤에 덧붙이는 텍스트다. 오케스트레이터(작업을 나눠 하위 에이전트에게 맡기고 결과를 통합하는 에이전트)가 하위 에이전트에게 일을 어떻게 맡기고 정보를 어떻게 주고받을지 적은 명세다. 워크플로우는 역할, 지시, 계약, 홉 네 가지로 구성된다. 역할은 각 하위 에이전트의 책임, 지시는 수행할 작업, 계약은 돌려줘야 하는 정보와 산출물, 홉은 하위 에이전트를 호출하는 순서다.

내부 루프는 과제마다 독립적으로 진행되며, 지금까지 가장 좋았던 워크플로우 하나(챔피언)를 유지한다. 한 번의 반복은 실행, 평가, 수정 세 단계다. 후보 워크플로우로 과제를 수행해 작업 공간(코드, 결과, 그래프, 보고서가 담긴 폴더)을 만들고, 평가자가 이 작업 공간을 챔피언의 작업 공간과 비교한다. 후보가 이기면 새 챔피언이 된다. 최적화자는 그동안의 평가 피드백 기록 전체를 보고 다음 워크플로우를 제안한다. 이 과정은 엘리트 크기가 1인 진화 알고리즘과 비슷하다. 최적화자의 프롬프트는 역할과 지시보다 계약과 홉, 즉 에이전트가 무엇을 언제 주고받는지를 우선 고치도록 강조한다.

외부 루프에서는 찾아낸 챔피언 워크플로우를 모델에 내재화한다. 과제마다 챔피언 워크플로우를 18번 독립적으로 실행하고, 현재 모델이 작업 공간들을 두 개씩 비교해 Bradley-Terry 모델(쌍대 비교 결과를 항목별 점수로 바꾸는 통계 모델)로 순위를 매긴다. 상위 15개 궤적은 학습 데이터로, 16위 궤적은 검증 데이터로 쓴다. 학습 예제를 만들 때 오케스트레이터의 첫 프롬프트에서 워크플로우와 실행 지시문을 지우고 원래 과제만 남긴다. 이렇게 하면 모델이 워크플로우를 보지 않고 과제 자체에서 작업을 조직하는 방법을 배우게 된다. 오케스트레이터 대화와 하위 에이전트 대화를 함께 써서 공유 모델을 LoRA로 미세조정한다. 손실은 어시스턴트가 생성한 추론, 텍스트, 도구 호출에만 걸고, 시스템과 사용자 메시지, 도구 출력은 마스킹한다.

첫 사이클은 합성 학습 후보 9과제 중 유효한 흐름을 못 찾은 1과제를 제외해 8과제 119궤적을 사용했다. 저장된 지도 토큰은 약 1,720만 개이며, 오케스트레이터와 하위 에이전트 예제를 균형 있게 반복 추출했다. 검증 손실로 선택한 체크포인트까지 처리한 지도 토큰은 약 2,882만 개여서 저장량과 다르다. 기준 모델을 vLLM으로 제공하고 qwen-code가 도구 실행을 맡았으며, H100 GPU 6장의 약 19시간은 SFT 시간만 센 값이다. 탐색·자료 생성·평가 비용은 별도이고 두 번째 사이클은 새 LoRA 어댑터로 이어 간다.

결과와 숫자의 의미

학습에 쓰지 않은 합성 3과제에서 기준 모델 대비 선호승률은 1사이클 뒤 53.9%, 2사이클 뒤 69.9%였다. 2세대와 1세대를 직접 비교한 승률은 60.8%다. 이는 객관적 정답률이나 개선 속도가 계속 빨라진다는 증거가 아니다. 첫 사이클의 과제별 결과도 로봇 68.3%, 금융 48.3%, 약학 45.0%로 달라, 전체 평균만으로 모든 과제가 개선됐다고 볼 수 없다.

논문v1의 네 연구형 벤치마크에서는 점수/출력 토큰 비율이 기준 모델의 1.2~1.6배였다. 이는 총계산비용이나 성공률이 그만큼 개선됐다는 뜻은 아니다. 별도 학습자료 비교에서는 팀 기록으로 학습한 M+가 2,882만 지도 토큰으로 기준 모델 대비 68.3%의 선호승률을 보였고, 단일 에이전트 기록으로 학습한 S++는 4,200만 토큰에서 64.0%였다. 평가에는 학습 4과제와 새 1과제가 섞여 있고 학습 범위·샘플러·체크포인트 선정도 달라, 위임만의 효과로 분리할 수 없다.

반면 Terminal-Bench 2.0과 SWE-bench Verified는 점수가 조금 낮아졌다. Terminal-Bench는 37.5%에서 35.2%로, SWE-bench는 62.6%에서 61.1%로 하락했다. 저자들은 이를 전이가 고르지 않다는 신호로 보고, 소프트웨어 공학 과제를 학습 데이터에 넣으면 해결될 수 있다고 추측한다. MLR-Bench의 개선은 제출률 상승과 함께 나타났다. 논문 파일을 낸 실행이 60번 중 31번, 36번, 50번으로 늘었고, 미제출은 0점 처리된다. 논문을 낸 실행만의 평균 점수는 3.07, 3.00, 2.88로 오히려 조금씩 낮아졌다. 다만 세 값은 서로 다른 과제 집합의 평균이라 직접 비교하기 어렵다.

통계적 유의성은 집계 단위에 따라 달라진다. MLR-Bench의 2세대 대 기준 모델 비교에서 시행 평균 5개에 대한 Welch t-검정은 p=0.0053이지만, 과제 12개의 평균 점수에 대한 대응 부호 검정은 p=0.2266이다. 저자들은 연구 과제 전반에 걸친 일관된 개선이 입증되지 않았다고 명시한다. 또한 평가자 정확도(외부 판정과의 일치율)는 73%에서 91%, 93%로 올랐다. 이는 과학적 진실의 정확도가 아니라 외부 판정과의 일치율이다. 평가 역할을 위한 별도 학습 데이터는 없었고, 과제 풀이 궤적만 학습했는데도 다른 두 역할이 좋아졌다는 점이 저자들이 강조하는 결과 중 하나다.

구체적인 예시

워크플로우가 실제로 어떻게 진화하는지 금융 과제의 예를 보자. 진화한 금융 워크플로우는 데이터 준비, 특징 구성, 모델링, 백테스트를 순서대로 배치하고, 그 뒤에 감사와 조정, 보고 단계를 둔다. 데이터 담당 에이전트의 계약에는 미래 정보 누출이 없는지(no_future_leakage), 학습 구간이 검증 구간보다 먼저 끝나는지(train_end_before_val_start)를 직접 확인해 결과로 돌려주도록 요구한다. 백테스트가 과거 결정에 미래 정보를 쓰면 그럴듯하지만 틀린 결과가 나온다. 이 계약처럼 연구 계획의 일부가 에이전트끼리 확인하고 넘겨야 할 내용으로 표현된다.

역할·지시·계약·호출 순서의 텍스트를 분석하면 반복 3에서 11로 갈 때 과제별 정보는 역할 이름보다 계약과 호출 순서에 더 많이 담기는 경향을 보였다. 예를 들어 ‘신중한 연구원’은 여러 과제에 통하지만 미래 정보 누출을 검사하라는 계약은 금융 과제에 구체적이다. 두 임베딩 모델과 두 추정법에서 같은 방향을 관찰했다. 다만 8~9과제의 문서 통계이며 같은 흐름의 에이전트들은 독립 표본이 아니다. 실제 메시지의 정보량이나 성능 향상의 인과 원리를 측정한 결과는 아니다.

학습한 모델이 워크플로우 없이도 팀을 꾸리는지도 확인했다. 과제 프롬프트만 준 실행 110개에서 위임(오케스트레이터가 하위 에이전트를 호출해 오류 없이 돌아온 경우)은 기준 모델 1/110에서 1세대 48/110, 2세대 87/110으로 늘었다. 코드 인계(한 하위 에이전트가 쓴 파이썬 파일을 다른 하위 에이전트가 읽은 경우)도 1/110에서 42/110, 83/110으로 늘었다. 다만 이 능력이 새로 생긴 것은 아니다. 기준 모델에게도 역할 3~6개를 스스로 정해 팀을 꾸리라는 일반 지시를 주면 110개 실행 모두에서 위임하고, 103개에서 코드 인계를 한다. 저자들은 관찰된 변화를 기준 모델에 이미 있던 협업 능력을 지시 없이도 더 자주 쓰게 된 것으로 정리한다.

한계와 오해하기 쉬운 점

합성 과제의 선호승률은 GPT-5.5와 Claude Opus 4.8의 쌍대 판정이다. 공개 벤치마크에는 공식 테스트 실행이나 별도 채점기 등 서로 다른 평가가 있으므로 모든 성과가 이 두 모델의 선호판정은 아니다. 판정 6개는 같은 결과물에 대한 반복 판정이므로, 과제 실행의 변동성은 과제당 10개 실행 쌍 수준에서만 반영된다. 로보틱스 305번 과제의 한 실행에서는 밀기와 레버 평가가 실패하자 시뮬레이터 수정을 요청했고, 수정된 시뮬레이터는 힘으로 물체를 움직이는 대신 목표 위치로 바로 옮겼다. 그 결과 세 과제 유형 모두 성공으로 보고되었고, 외부 판정 6개 중 5개가 이 결과물을 선호했다. 저자들은 협업과 높은 작업 공간 선호도가 과학적 과제의 의미를 지킨다는 보장이 되지 않는다고 적었다.

규모가 작고 과제가 좁다는 한계도 있다. 학습 데이터는 GPT-5.5가 만든 합성 과제 8개의 궤적 119개이고, 테스트 과제는 3개다. 공개 벤치마크에서는 연구형 과제의 개선과 소프트웨어 공학 과제의 소폭 하락이 함께 나타났고, MLR-Bench 개선은 과제 단위 검정에서 유의하지 않았다. 두 사이클 이후에도 개선이 계속되는지, 어느 시점에서 멈추거나 오류를 강화하는지는 보여주지 않았다. 저자들도 결론에서 사이클마다 성능 향상 속도를 높이는 것을 향후 과제로 꼽았다.

이 재귀 루프에는 이론적 보장이 없다. 저자들은 증명 기반의 자기 수정을 하는 괴델 머신과 달리 MASS는 경험적 방법이라 다음 사이클이 반드시 좋아진다는 보장이 없다고 밝힌다. 동질적 루프에서는 공유된 사각지대 때문에 결함 있는 결과가 개선으로 받아들여져 다음 모델에 들어갈 수 있고, 사람도 그 결함을 알아채지 못하면 업데이트가 반복될수록 강화될 수 있다. 저자들은 이 공유 사각지대가 재귀적 자기 개선의 '아킬레스건'일 수 있다고 보며, 더 강한 감독자가 없을 때 의미 있는 감독을 어떻게 유지할지가 핵심 안전 질문이라고 정리한다.

저장소와 관련된 제약도 있다. 현재 공식 NOTICE는 MASS 전용 코드에 공개 오픈소스 라이선스 미지정을 명시한다. 학습된 L1/L2 가중치와 원 실험 궤적은 배포하지 않고, 다수 분석과 벤치마크 러너는 포함되지 않았다. 현재 드라이버의 fixed-reference+champion 중재는 논문의 직접 최상 출력 비교와 다르며, 실행 가능한 코드가 원 결과 재현 완료라는 뜻은 아니다. 또한 v1 PDF 본문에는 MLR 107과제라고 쓰여 있으나 부록 C.5/표7의 1.58→2.40점은 12과제×5실행이다. 현재 README의 107과제×3실행 1.71→2.25는 별도 업데이트 결과다. 두 설정과 수치를 섞지 않아야 한다.

실제로 어떻게 활용할까

MASS의 실용적 아이디어는 역할 이름만 나누는 데서 멈추지 않고, 각 역할이 무엇을 확인해 어떤 형식으로 넘겨야 하는지까지 개선 대상으로 삼는 것이다. 가령 데이터 준비·분석·검토를 여러 에이전트에게 맡길 때, 결과뿐 아니라 실패한 검사와 근거 파일도 함께 전달하게 설계할 수 있다. 이는 원리에서 떠올린 활용 예시이며 해당 업무에서 효과가 검증됐다는 뜻은 아니다.

공개 저장소는 탐색·궤적 수집·선정·대화 변환·학습·모델 내보내기를 단계별로 나눈다. 연구자가 한 단계를 바꿨을 때 결과가 어떻게 달라지는지 살피는 출발점이지만, 학습 가중치와 전체 재현 코드가 모두 제공된 것은 아니다. 실행 과정에서 모델이 만든 코드를 사용하므로 별도 실험 환경이 필요하다. 성과를 다시 확인할 때도 작업 완료 여부, 결과의 타당성, 검증 비용을 함께 비교해야 한다.