복잡한 일 하나를 AI 하나에게 통째로 맡기면 버거울 때가 많다. 그래서 역할을 쪼갠다. 요청을 뜯어보는 AI, 순서를 설계하는 AI, 코드를 짜는 AI, 검수하는 AI를 사슬처럼 엮는다. 이렇게 엮은 작업 흐름을 멀티에이전트 워크플로라고 부른다.
문제는 이 팀을 "학습으로 더 잘하게" 만들려 할 때 생긴다. 똑똑한 직원을 여럿 뽑아 놓고도 성과가 안 나는 회사를 떠올려 보라. 대개 사람이 모자라서가 아니다. 누가 무엇을 책임지는지, 잘한 사람에게 어떻게 보상이 돌아가는지가 없어서다. AI 워크플로도 똑같다.
그런데 업계의 학습법은 한쪽으로 쏠려 있었다. 일의 순서와 역할을 짜는 '설계자'(논문 용어로 생성기, Generator) 하나만 가르치고, 그 설계대로 실제로 손을 움직이는 나머지 역할은 처음 실력 그대로 뒀다. 요리의 성패가 총괄 셰프 혼자 책임이 아닌데도 그래 왔다.
FloWright는 이 비대칭을 깬다. 한 번의 실행으로 남은 그 기록을 채점하는 것만으로 설계자든 실무자든 가리지 않고 역할별 책임을 같은 신호로 나눈다. 책임을 가리는 데 추가 모델도, 사람이 손으로 단 정답표도, 워크플로를 따로 다시 돌려 보는 일도 없이. 이렇게 거저 얻은 신호로 모든 역할을 함께 학습시킨다 — 학습 자체는 과제마다 여러 번 실행(롤아웃)해 정책을 반복 갱신하는 강화학습이다. 그 결과 작은 4B 모델에서 학습 전 대비 평균 +5.03%p가 올랐다(여러 역할을 동시에 키웠을 때).
가장 흥미로운 건 숫자가 아니라 방법이다. 실행 기록에 드러난 실패를 공짜로 역할별로 가르는 방식.
멀티에이전트 워크플로를 주방에 빗대 보자. 재료 손질, 불 조절, 플레이팅을 각자 맡고, 손님은 완성된 접시 하나로 평가한다. 요리가 맛없게 나왔다. 여기서 진짜 어려운 질문이 나온다. 누가 간을 잘못 봤나? 완성품만 핥아서는 영영 알 수 없다.
워크플로는 노드와 엣지로 이어진 그래프다. 노드는 일하는 지점(에이전트·도구·스킬), 엣지는 그 사이를 흐르는 데이터와 제어다. FloWright는 이 그래프를 주방의 채점 장치로 쓴다. 논문은 이를 측정 장치(harness)라고 부르는데, 워크플로를 끝까지 돌려 답을 내게 하고 그 답을 채점하는 심사 시스템이라고 보면 된다. 여기서 나온 점수 하나가 평가 지표도 되고, 학습 신호도 되고, 뒤에 설명할 테스트 시점 최적화의 목표도 된다. 셋을 한 장치에서 길어 올린다.
핵심은 실패를 되짚는 법이다. 측정 장치는 요리가 어떤 공정을 어떤 순서로 거쳤는지 조리 과정 영상처럼 기록으로 남긴다. 이 기록이 실행 트레이스(execution trace), 말 그대로 "누가 무엇을 했는지"의 발자국이다. 그리고 각 역할에는 자기가 "저작한" 노드가 있다. 설계자는 자기가 그리고 배선한 모든 노드, 실행 역할은 자기가 직접 돌린 에이전트 노드다.
구체적인 한 장면으로 따라가 보자. 어떤 과제에서 노드 하나가 실행 중 오류를 내 멈췄고, 그 뒤에 매달린 노드들도 입력을 못 받아 줄줄이 무너졌다. 최종 답이 틀렸다. 이때 측정 장치는 트레이스에 남은 실패 노드와 그 의존관계를 훑어, 뒤에서 덩달아 무너진 연쇄 실패는 책임에서 빼고 처음 미끄러진 노드에만 책임을 건다. 그 노드를 설계자가 배선했다면 설계자에게, 실행 역할이 돌린 노드라면 실행 역할에게 간다. 한쪽에 다 뒤집어씌우지 않고, 각자 저작한 노드 범위 안에서만 나눠 묻는다. 이것이 "구조를 아는 보상(structure-aware credit)"이다.
다만 이 규칙이 짚어내는 건 어디까지나 실행 기록에 '실패 노드'로 드러난 잘못뿐이다. 노드가 오류 없이 돌아갔는데 결과가 틀렸거나, 요구사항 한 줄을 빠뜨린 것처럼 실패로 드러나지 않은 잘못은 이 장치가 가려내지 못하고, 뒤에 설명할 계층 보상의 전역 신호(답이 얼마나 맞는가)에 맡긴다. 한 역할이 저작한 노드가 다른 역할과 겹치는 구간에서도 책임은 깔끔히 갈리지 않는다. 그러니 "틀린 곳을 모두 자동으로 밝혀낸다"가 아니라 "드러난 실패를 역할별로 나눈다"가 정확하다.
여기서 결정적인 절약이 생긴다. 그 조리 과정 영상은 측정 장치가 채점하면서 이미 남긴 것이다. 책임을 가리려고 별도 심판 모델이나 보상 모델을 붙이거나, 사람이 주석을 달거나, 워크플로를 몇 번씩 다시 돌릴 필요가 없다. 기존 연구들이 책임 소재를 가리려고 바로 그런 추가 비용을 쏟았고, 그러고도 엉뚱한 곳에 책임을 돌리곤 했다. FloWright는 이미 있는 발자국을 읽을 뿐이다.
두 번째 장치는 "어디까지 올라갔나"를 재는 계층 보상(hierarchical reward)이다. 결과를 합격/불합격으로 뭉개지 않고 사다리처럼 단을 쌓는다. 출력이 형식에 맞게 읽히는가, 그 기여가 유효한가, 워크플로가 끝까지 돌아 답을 내는가, 그 답이 얼마나 맞는가. 여기에 앞의 구조 기반 책임이 다섯 번째 단으로 붙는다. 덕분에 요리가 중간에 엎어져도 "3단까지는 올라갔다"는 신호가 남는다. 0점짜리 침묵 대신 방향을 가리키는 피드백이다. 각 단의 가중치는 역할마다 다르게 둔다.
이 두 장치가 깔리면, 같은 측정 장치 하나에서 어떤 역할이든 자기 몫의 보상을 뽑아 쓸 수 있다. 그래서 학습의 범위를 넓힐 수 있다. 역할 하나만 스스로 발전시킬 수도, 에이전트와 스킬을 함께, 설계하는 상류와 실행하는 하류를 함께, 혹은 여러 에이전트를 동시에 키울 수도 있다.
여럿을 함께 키우면 재미있는 일이 벌어진다. 한 역할이 나아지면 다른 역할이 마주하는 상황 자체가 바뀐다. 손질 담당이 솜씨가 늘면, 불 담당은 전보다 고른 재료를 받아 들고 새로운 수준에서 연습하게 된다. 서로가 서로의 연습 문제지가 되는 것이다. 논문은 이를 서로의 커리큘럼(mutual curriculum)이라고 부른다.
학습은 두 시점으로 나뉜다. 훈련 시점에는 강화학습으로 모델의 가중치 자체를 바꾼다. 테스트 시점에는 가중치를 건드리지 않고, 재사용할 수 있는 사전 지식을 증류(distillation)한다. 증류란 잘 풀었던 경험을 짧은 참고 자료로 요약해 두는 것이다. 성공한 요리의 레시피를 카드로 남겨 다음 팀이 참고하게 하는 셈이다. 자기 경험에서 뽑기도 하고, 더 강한 교사 모델에서 뽑기도 하고, 둘 다 쓰기도 한다.
제대로 평가하려면 제대로 된 문제지가 필요했다. 멀티에이전트 워크플로는 그동안 단일 질문 수학이나 함수 하나짜리 코딩처럼 에이전트 하나로도 풀리는 데이터로 평가돼 왔다. 그런 쉬운 문제에서는 다시 재 보면 여러 명이 달라붙은 이점이 거의 안 드러난다. 워크플로가 혼자보다 무엇을 더 해내는지 보이질 않는 것이다.
그래서 DataWright가 등장한다. 기존 데이터셋을 더 어렵게 손봐, 여러 하위 질문을 묶는 식으로 "워크플로가 꼭 필요한" 과제로 바꾼다. 채점 방식은 그대로 두고 난이도만 끌어올린다.
훈련은 Qwen3.5 계열 4B·9B 모델로 네 개 데이터셋에서 돌렸다. 평가는 훨씬 넓게 폈다. 두 오픈소스 모델에 더해 폐쇄형 모델까지, 전부 학습에 쓰지 않은 테스트셋(held-out)에서 쟀다. 한 역할이 다른 역할과 다른 크기의 모델을 써도 되므로, 작은 상류에 큰 하류, 그 반대 조합까지 봤다.
평가지는 세 구역이다. 훈련에 쓴 조건(in-distribution), 같은 데이터셋이되 훈련이 못 본 전략·난이도(out-of-distribution), 아예 훈련에 안 쓴 데이터셋(out-of-domain). 이 설계가 재려는 건 분명하다. "배운 조건에서 잘하나"가 아니라 "본 적 없는 전략·난이도·도메인으로 얼마나 번지나"다. 반대로 이 표가 못 재는 것도 분명하다. 실제 서비스 트래픽, 실시간 비용과 지연, 사람 사용자와의 상호작용은 여기에 없다.
먼저 눈에 띄는 건, 학습을 시작하기도 전이다. 작은 4B 모델이라도 FloWright 구조로 워크플로를 짜서 돌리는 것만으로 도구를 쥔 단일 에이전트를 한참 앞질렀다(32.09 대 20.70). 혼자 머리를 쥐어짜는 것보다 일을 잘 조직하는 쪽이 낫다는 뜻이다. 작은 모델일수록 더 그렇다.
| 설정 (Qwen3.5-4B) | 전체 정확도(%) |
|---|---|
| 단일 에이전트(도구·스킬 없음) | 7.42 |
| 단일 에이전트(도구·스킬 있음) | 20.70 |
| FloWright(학습 전) | 32.09 |
| + 단일 역할 자기진화 | 34.92 |
| + 상류-하류 공진화 | 35.15 |
| + 에이전트-스킬 공진화 | 36.15 |
| + 다중 에이전트 공진화 | 37.12 |
더 중요한 건 방향이다. 함께 키우는 역할이 많을수록 향상이 커졌다. 역할 하나만 학습시키면 +2.83%p, 상류와 하류를 함께 키우면 +3.06%p, 에이전트와 스킬을 함께 키우면 +4.06%p. 그 끝, 여러 에이전트를 동시에 키운 경우가 가장 컸다(표 맨 아랫줄). 그리고 이 다중 공진화는 세 구역 전부에서, 모든 데이터셋·전략·난이도에서 플러스를 지켰다. 어쩌다 한 조건에서만 오른 게 아니라는 뜻이다.
여기서 초록의 "최대 +7.41%p"를 제자리에 놓자. 이 숫자는 전체 평균이 아니다. 특정 조건 한 칸(39.32 대 31.91)에서 가장 크게 오른 값이라, 평균 향상과는 구분해서 봐야 한다.
작은 모델에서 다듬은 역할이 큰 모델과 섞여도 그 이득이 살아남는 효과도 나타났다. 4B로 최적화한 역할은 4B 그대로 두고 나머지만 9B로 돌리는 혼합 조합에 끼워 넣자 그 이득이 따라붙어, 전부 9B로 돌린 기준선보다 정확도가 더 올라가기도 했다. 작은 모델의 학습 내용을 큰 모델로 옮겨 심는 게 아니라, 싸게 다듬은 작은 역할을 그대로 두고 다른 역할에 큰 모델을 붙이는 길이 열린 셈이다. 9B 단독으로도 방향은 같아서, 학습 전 47.50%가 단일 역할 자기진화로 51.39%(+3.89%p)가 됐다.
가중치를 건드리지 않는 테스트 시점 최적화도 효과를 냈다. 다만 눈여겨볼 지점이 있다. 성공 사례를 예시로 요약하는 방식은 사례 다섯 개를 줬을 때 가장 큰 이득을 낸 반면, 하나만 줬을 때는 오히려 학습 전보다 낮았다. 사례 하나로는 일반화할 근거가 모자라고, 증거가 어느 정도 쌓여야 참고 자료가 도움이 된다는 이야기다.
마지막으로 눈금 하나. 절대 정확도가 7~50%대로 낮다. 쉬운 벤치마크가 아니라 DataWright로 일부러 어렵게 만든 과제라서다. 이 숫자들은 "잘 푸는 AI"가 아니라 "워크플로가 혼자보다 무엇을 더하는가"를 재는 자다.
한 장면으로 좁혀 보자. 고객이 "재고 관리 대시보드를 만들어 달라"고 요청한다. 온틀의 AI PM은 이를 접수→분석→설계→개발→QA로 쪼개고 각 단계에 전문 역할을 배정한다. 요청을 쪼개는 PM이 FloWright의 상류라면, 분석·설계·개발·QA를 실제로 해내는 역할들이 하류다.
이 파이프라인을 개선할 때 손대기 쉬운 쪽은 PM의 분해 로직, 즉 상류다. FloWright가 하는 말은 거기서 멈추지 말라는 것이다. 요청을 잘 쪼개는 PM만 다듬고 실행 역할을 고정해 두면, 전체가 좋아질 여지가 구조적으로 막힌다. 위 사례에서 분석 담당이 "재고 임계치 알림" 요구사항 한 줄을 놓쳐 프로젝트가 개발 단계에서 주저앉았다고 하자. 이건 PM이 일을 잘못 쪼개서가 아니라 분석 역할이 미끄러진 것이다. PM만 손봐서는 같은 실패가 반복된다.
여기서 구조 기반 책임이 들어온다. 온틀은 이미 작업 흐름을 git 그래프 형태(레일·노드·parent_id)로 남기고 실행 트레이스를 보관한다. 하지만 기록이 있다는 사실만으로 역할별 책임이 저절로 갈리지는 않는다. 두 가지가 더 필요하다. "각 노드를 어느 역할이 저작했는가"를 아는 것, 그리고 실행 기록의 실패 노드와 그 의존관계를 따라 연쇄 실패는 걷어내고 처음 미끄러진 노드를 짚는 규칙이다. 이 둘이 있어야 완료 점수 하나를 분석·설계·개발·QA 역할별 피드백으로 쪼갤 수 있다.
다만 원논문이 긋는 선을 온틀에도 그대로 옮겨야 한다. 이렇게 역할별로 갈리는 건 실행 기록에 '실패'로 드러난 노드뿐이다. 위 사례의 "재고 임계치 알림" 누락처럼 노드가 멀쩡히 돌아갔는데 요구사항 한 줄이 빠진 잘못은 실패 노드로 잡히지 않아, 이 규칙만으로는 분석 역할에 자동으로 꽂히지 않는다. 그런 몫은 프로젝트 전체 결과로 매기는 전역 보상이 떠안고, 노드 저작이 역할 간에 겹치는 구간에서도 책임은 깔끔히 갈리지 않는다.
사다리형 보상도 그대로 옮겨 쓸 수 있다. 프로젝트가 완료에 이르지 못해도 "요건 파싱은 됐고 설계까지 유효했는데 개발 실행에서 멈췄다"처럼 어디까지 갔는지를 단으로 남기면, 다음 분해와 배정이 그 지점을 피해 가도록 손볼 수 있다. 다만 분명히 하자. 이건 온틀에 이식할 수 있는 설계 시사점이지, 지금 구현돼 있다는 뜻은 아니다.
저자들이 스스로 밝히는 전제가 있다. in-distribution 구역은 훈련에 쓴 난이도를 평가에도 쓰되 특정 수준만 빼낸 구조라, 그 성적은 "훈련 분포 안의 성적"이다.
내가 보기에 남는 질문은 이렇다. 훈련 백본이 Qwen3.5 계열에 쏠려 있고, 평가는 넓지만 훈련은 네 개 데이터셋이라는 비교적 좁은 지점에서 출발한다. 공진화가 좋다는 결론은 분명하되, 역할 수를 늘릴 때의 학습 비용과 수렴 난도 같은 운영 관점의 트레이드오프는 이 표만으로 판단하기 이르다. 벤치마크 정확도 한 축만 봤다는 점도 기억해야 한다. 실제 서비스에서 못지않게 중요한 비용·지연·안정성은 다른 자로 재야 한다.
더 나은 워크플로를 만들려면 워크플로 전체가 필요하다는 뜻입니다. 설계자 한 명을 갈아 끼우는 게 아니라, 짜고 실행하는 역할들이 서로를 연습 문제처럼 밀어 올리며 함께 진화해야 한다는 이 연구의 주장을 제목에 담은 것입니다.
다릅니다. FloWright는 모든 역할을 함께 학습시키는 방법 쪽이고, DataWright는 그 방법을 제대로 평가할 수 있도록 쉬운 데이터셋을 "워크플로가 필요한" 어려운 과제로 바꿔 주는 문제지 생성 쪽입니다. 방법과 평가 환경, 두 축으로 나눠 보면 됩니다.
학습은 모델이 작을수록 돌리기 싸고 빠릅니다. 한 역할을 작은 4B 모델로 다듬은 뒤, 그 역할은 4B 그대로 실행하고 나머지 역할만 큰 9B 모델로 돌리는 혼합 구성이 가능합니다. 작은 모델의 학습 내용을 큰 모델로 옮겨 심는 게 아니라, 싸게 학습시킨 작은 역할을 그대로 쓰면서 다른 역할에 큰 모델을 붙이는 것입니다. 이 연구에서 그렇게 꾸린 혼합 조합이 전부 큰 모델로만 간 기준선을 앞지른 사례가 나왔다는 게 그 가능성을 보여 줍니다.
논문은 arXiv에, 요약과 토론은 HuggingFace에 올라와 있고, 저자들이 운영하는 프로젝트 페이지가 초록에 명시돼 있습니다. 아래 참고자료의 링크에서 시작하면 됩니다.