틀어진 한 단계만 실행 중에 고치는 AI 워크플로우 — 정답표 없이

여러 AI가 분업하는 작업에서, 정답표 없이 틀어진 단계만 실행 도중에 골라 고치는 InFlowOp. 그런데 정작 성패를 가른 건 교정 솜씨가 아니었다.
English  ·  日本語  ·  한국어
← 목록으로
온
온틀 리서치
2026년 10월 06일 수정 2026.10.16 읽기 15분 조회 1

온틀에 "경쟁사 가격을 조사해 요약 보고서로 만들어 달라"는 프로젝트가 들어왔다고 하자. 일은 셋으로 갈린다. 자료 수집, 데이터 분석, 보고서 작성. 이렇게 여러 AI가 역할을 나눠 한 가지 일을 함께 처리하는 작업 흐름을 멀티에이전트 워크플로우(여러 AI 에이전트가 분업하는 작업 파이프라인)라 부른다.

이 방식의 약점은 한 단계가 틀어지는 순간 드러난다. 데이터 분석이 엉뚱한 결과를 내면 보통은 처음부터 다시 돌린다. 이미 잘 끝난 자료 수집까지 두 번 값을 치른다. 수도꼭지 하나가 샌다고 집을 통째로 다시 짓는 꼴이다.

InFlowOp이라는 논문은 집을 다시 짓지 않는다. 새는 데만 고친다. 그것도 실행이 끝나기를 기다리지 않고 도중에, 그리고 '정답표'(무엇이 맞는 답인지 미리 적어 둔 기준) 없이. 이 글은 위 보고서 한 건을 처음부터 끝까지 따라가며 세 가지를 본다. 분석 단계를 누구에게 맡길지 어떻게 고르는가, 무엇을 보고 "틀어졌다"고 판정하는가, 그리고 어디까지 되돌리는가.

미리 한 가지만 귀띔해 둔다. 이 논문에서 가장 흥미로운 대목은 '어떻게 고치느냐'가 아니다. 그 교정 기술 뒤에는 더 중요한 질문 하나가 숨어 있는데, 그 답은 글 마지막의 숫자가 직접 말해 줄 것이다.

설계를 이끄는 저울 하나

InFlowOp의 심장에는 저울 하나가 있다. 일을 어떻게 쪼개고 누구에게 맡길지를, 성공 가능성(신뢰도)과 걸리는 시간(지연)을 하나로 합친 점수로 환산해 재는 저울이다. 그리고 점수가 가장 낮은 길이 이긴다.

당장 와닿게 장면을 하나 올려 보자. 분석 단계를 맡길 후보가 둘이다. 하나는 정확하지만 느린 큰 모델, 하나는 빠르고 값싸지만 자주 틀리는 작은 모델. 큰 모델은 신뢰도가 높은 대신 지연이 크고, 작은 모델은 그 반대다. 저울은 둘을 같은 눈금 위에 올려 전체 점수를 더 낮추는 쪽을 고른다. "이 일이 요구하는 걸 얼마나 채우느냐"를 "돌리는 데 얼마가 드느냐"와 맞세우는 셈이다.

여기서 '비용'은 청구서에 찍히는 돈이 아니라 설계를 고르기 위한 점수라는 것만 기억해 두자. 이 구분은 뒤에서 숫자를 읽을 때 다시 쓰인다.

누구에게 맡길까

그렇다면 저울에 올릴 후보는 어떻게 정할까? 그러자면 먼저 일을 조각내야 한다. InFlowOp은 조각의 개수를 미리 정해 두지 않는다. 잘게 나눌수록 조각 하나하나는 좁고 믿음직해지지만, 돌려야 할 AI가 늘어 느려지고 틀어질 길목도 많아진다. 그래서 일단 더는 못 쪼갤 최소 단위까지 잘게 분해한 다음, 도로 합치는 편이 점수를 낮출 때만 다시 뭉친다. 얼마나 잘게 나눌지조차 취향이 아니라 점수가 정하는 것이다.

조각이 정해지면 조각마다 후보 AI를 저울에 올린다. 이때 판단 기준이 핵심인데, 정답과 맞는지가 아니다. 결과물에 반드시 들어가야 할 항목을 미리 적어 두고, 각 후보가 그 항목을 얼마나 채울 수 있을지를 점수로 매긴다. 후보가 스스로 밝힌 역량과 그동안 쌓은 수행 기록을, 그 조각이 요구하는 바와 대조하는 식이다.

여기가 이 논문의 영리한 지점이다. '정답과 맞느냐'가 아니라 '요구한 항목을 갖췄느냐'만 보기 때문에, 정답을 모르는 상태에서도 평가가 돌아간다.

어느 후보도 기준선을 넘지 못하면, 그 조각은 '맡을 사람이 없는 자리'로 드러난다. 이때만 벌점을 물려 새 AI를 만들어 후보에 보탠다. 중요한 건 억지로 떠넘기는 선택과 새로 만드는 선택이 같은 저울 위에서 겨뤄진다는 점이다. 그래서 새로 만드는 일은 정말 아무도 못 맡을 때만 일어난다.

무엇을 보고 틀어졌다 하는가

아무리 잘 짰어도 설계는 결국 예측이다. 진짜 약점은 돌려 봐야 처음 모습을 드러낸다.

보고서로 돌아가자. 돌려 보니 데이터 분석 단계가 쓸 수 없는 표를 내놨다. 그런데 보고서 작성 단계는 이미 그 표를 전제로 문장을 쓰고 있다. 무엇을 보고 틀어졌다고 판정할까?

InFlowOp은 여기서도 정답과 대조하지 않는다. 대신 각 단계에 시작 전부터 '약속'을 걸어 둔다. 이 단계가 받아야 할 입력의 조건, 그리고 내놔야 할 출력의 조건이다.

가격 보고서의 분석 단계로 구체화해 보자. 입력 조건은 이를테면 '자료 수집이 넘겨준 표에 경쟁사별 가격이 빈칸 없이 채워져 있을 것, 통화 단위가 하나로 통일돼 있을 것'이다. 출력 조건은 '분석 결과에 경쟁사 수만큼의 비교 행이 있고, 각 행에 가격과 순위가 숫자로 들어 있을 것' 정도다. 정답(진짜 시장 1위가 누구인지)은 프로젝트가 다 끝나야 알 수 있지만, 이런 조건은 단계가 시작되기도 전에 적어 둘 수 있다. 그래서 전체를 끝내지 않고도 실행 도중에 틀어진 지점을 바로 집어낸다.

판정은 거기서 한 걸음 더 나간다. 약속의 어느 쪽이 깨졌는지가 책임 소재를 가른다. 출력 조건을 못 맞췄다면 — 예컨대 비교 행은 다 있는데 순위 칸이 비었다면 — 일은 제대로 놓였는데 맡은 AI가 덜 해낸 것이다. 반대로 입력 조건부터 어긋났다면 — 넘겨받은 표의 가격 칸이 애초에 비어 있었다면 — 필요한 재료를 받지도 못한 셈이다. 뒤엣것은 담당을 바꿔도 고쳐지지 않는다. 일을 쪼갠 방식 자체를 다시 손봐야 한다.

어디까지 되돌리나

판정이 끝나면 실행은 틀어진 그 단계에서만 멈춘다. 이미 쌓인 진척은 건드리지 않는다. 고치는 수는 싼 것부터 꺼낸다.

가장 싼 수는 담당만 바꾸는 것이다. 단계도 의존 구조도 그대로 두고 맡은 AI만 교체한다. 방금 실패한 후보는 빼고 차선을 올린다. 출력이 미달일 때 쓰는 수다.

이걸로 안 되면 한 단계 더 올라간다. 그 단계를 더 잘게 쪼갠 작은 작업 흐름으로 바꾸는 것이다. 앞서 본 분해·배정을 그 자리에서만 한 번 더 돌리는 값이 든다. 입력부터 부실했을 때 쓰는 수다.

모든 수에는 예산이 걸려 있다. 다 쓰면 원래 값으로 되돌린다. 바뀐 결과는 검증을 통과했을 때만 반영되고, 아니면 버린다. 덕분에 교정은 워크플로우를 나아지게 할 수는 있어도, 지어 둔 것보다 나빠지게 두지는 않는다.

고친 뒤에는 어디까지 다시 돌릴까? 되돌릴 필요가 있는 건 그 단계의 결과에 기대고 있던 뒷 작업들뿐이다. 보고서 예라면 분석에 의존하던 보고서 작성만 다시 돈다. 그 바깥에서 이미 끝난 자료 수집은 그대로 재사용한다. 한 번 고치는 값이 전체가 아니라 영향받은 범위만큼으로 묶이는 것 — 이것이 집을 다시 짓지 않고 새는 데만 고친다는 말의 실제 모습이다.

숫자가 말하는 것

이제 숫자다. 저자들은 측정 도구부터 손봤다. 여러 AI가 분업하는 워크플로우를 제대로 재려면 그에 맞춰 짜인 과제가 필요하다. 그래서 공개 데이터셋을 손봐 새 벤치마크(성능 측정용 표준 문제집) Braid를 따로 만들었다. 과제마다 자료가 여럿 딸려 오는데, 자료끼리 내용이 겹치지 않고, 정답이 미리 새어 나오지 않으며, 질문에 실제로 맞는 자료가 들어가도록 품질 기준을 걸어 걸러 냈다.

핵심 비교는 하나다. 바탕 모델과 시도 횟수를 똑같이 맞춘 채 구성·교정 방식만 바꿨을 때, 정확도가 어떻게 달라지는가. 논문이 앞세운 대표 수치는 단일 에이전트(AI 하나로 푸는 방식) 대비 최대 11.97%포인트, 워크플로우 기준선 대비 최대 9.64%포인트다. 여기서 '최대'는 여러 백본(바탕이 되는 AI 모델)과 갈래를 통틀어 가장 높았던 값이지, 어느 한 모델의 대표 성과가 아니다. 그리고 이 9.64%포인트는 '워크플로우를 어떻게 꾸리느냐' 전체가 만든 최대 향상 폭이지, '실행 중 교정'이라는 한 장치만 떼어 낸 독립 효과가 아니라는 점에 주의하자 — 그 몫은 바로 아래 표에서 따로 드러난다.

더 많은 걸 말해 주는 건 모듈을 하나씩 얹어 가며 잰 표다. 바탕 모델은 Qwen3.5-9B, 5개 도메인(분야) 평균이다.

구성 방식 정확도(%) 단일 에이전트 대비(%포인트)
Single agent 17.38 —
greedy-search 15.49 -1.89
Coalesce(비용 기반 분할) 22.21 +4.83
Coalesce + 흐름 속 교정 23.80 +6.42
InFlowOp(전체) 25.13 +7.75

읽는 순서가 중요하다. 혼자 할 때(17.38)가 출발점이다. 점수를 기반으로 나눈 Coalesce는 거기서 +4.83%포인트 뛴다 — 표에서 가장 큰 한 칸이다. 왜인지는 그 바로 윗줄이 말해 준다. 똑같이 나누더라도 눈앞에서 좋아 보이는 쪽으로만 집어 쪼갠 greedy-search(탐욕적 분할)는 혼자 할 때보다 오히려 1.89%포인트 낮았으니까. 그러니 나눈다는 것 자체는 이득을 보장하지 않는다. 이득은 '어떻게' 나누느냐에서 온다.

그다음이 이 논문의 진짜 반전이다. 잘 지어 둔 설계 위에 교정을 더했을 때 보탠 몫은 그보다 작았다. 실행 흐름 속 교정이 약 +1.6%포인트(표의 23.80 − 22.21), 각 AI가 수행 경험을 쌓아 스스로 역량 기록을 갱신하는 장치가 다시 약 +1.3%포인트. 둘을 합쳐도 처음에 잘 나눈 한 수(+4.83%포인트)에 못 미친다. 틀어진 걸 잘 고치는 솜씨보다, 애초에 잘 나누는 설계가 훨씬 남는 장사라는 뜻이다. 앞에서 귀띔한 '더 중요한 질문'의 답이 바로 이것이다.

규모를 건너뛰는 장면도 있다. 작은 Qwen3.5-4B에 InFlowOp을 입히면 5개 도메인 평균 20.81에 닿는다. 더 큰 Qwen3.5-9B(17.38)나 GPT-5-mini(16.33), GPT-5.4-mini(17.49)를 그냥 혼자 돌렸을 때를 모두 웃도는 값이다. 작은 모델도 좋은 설계를 입으면 큰 모델의 어설픈 사용을 넘어선다는 얘기다. 가장 강한 바탕 모델에서도 흐름은 같다. 혼자 돌린 41.99에서 49.37로 오른다.

여기서 한 가지 오해를 미리 막아 두자. 이 표의 숫자는 전부 '정확도'다. 돈이나 시간이 줄었다는 증명이 아니다. 이 점수를 곧장 '비용 절감'으로 읽으면 세 겹의 함정에 빠진다. 우선 이 점수는 상대 비교용으로 만든 Braid 위에서만 잰 값이라, 특정 서비스의 실제 지출을 절대값으로 말해 주지 않는다. 또 교정이 정확도를 +1.6%포인트 올렸다고 해서 그 교정에 든 실제 비용이 그만큼 쌌다는 뜻도 아니다. 표가 재는 건 어디까지나 정확도 상승분이다. 마지막으로, 지연을 점수에 넣었다고 해서 그 값이 벽시계로 잰 초(秒)라는 보장도 없다(측정 방식의 세부는 원문 부록에 있다). 요컨대 이 표는 "얼마를 아꼈나"가 아니라 "어느 설계가 더 영리한가"에 답하는 표다.

한계도 분명하다. 이득은 차트·수학·금융에서 크고 물리에서 가장 작다. 물리는 어떤 모델, 어떤 방법을 써도 낮게 머문다. 협응 설계로도 넘지 못하는, 바탕 모델의 추론력 자체가 벽인 영역이 있다는 신호다. 전체가 정답표 없는 점수 위에 서 있다는 사실도 양날이다. 약속을 엉성하게 적어 두면 틀린 단계를 통과시키거나 멀쩡한 단계를 멈춰 세운다. 점수 계산도 AI가 스스로 밝힌 역량에 기대는 만큼, 그 선언이 과장되면 저울 전체가 낙관 쪽으로 기운다.

온틀에는 어떻게 들어오나

온틀은 고객 프로젝트마다 AI PM(프로젝트 매니저)을 붙여 접수부터 완료까지 끌고 간다. 그래서 'greedy가 혼자 할 때보다 낮았다'는 그 한 줄이 남의 얘기가 아니다. PM이 요청을 잘게 쪼개는 것 자체를 미덕으로 삼으면 조정 비용만 늘 뿐이다. 쪼개는 기준은 언제나 '적합도 대비 수행 비용'이어야 한다.

InFlowOp의 틀을 온틀에 포갠다면, 달라지는 건 교정 절차 몇 개가 아니라 PM의 일 자체다. 지금까지 가격 보고서의 분석 표가 틀어졌을 때 온틀 PM이 택할 수 있는 길은 둘뿐이었다. 처음부터 다시 돌리거나(진척 폐기), 사람이 끼어들어 전체를 손보거나. 두 길 다 결국 사람이 워크플로우를 다시 짠다는 뜻이다.

이 틀이 들어오면 '워크플로우를 어떻게 다시 짤까'라는 판단을 시스템이 떠안는다. 그러면 PM의 무게중심이 옮겨 간다. 개별 태스크 하나하나의 품질을 지키는 감시자에서, 프로젝트 전체의 목표가 제대로 달성되는지를 보는 기획자로. 고객에게 약속할 수 있는 것도 달라진다 — '틀리면 사람이 붙어 고쳐 드립니다'가 아니라, '틀어진 조각만 시스템이 자동으로 되감아 다시 돌립니다'가 된다. 되감는 동안에도 고객 화면에는 여전히 '진행중'과 '완료'만 보이고, 먼저 끝난 자료 수집 같은 단계는 그대로 산다. 입력이 부실해 단계를 다시 쪼개야 할 때는, 작업 지도 위에서 노드(지도 위의 점 하나, 곧 한 단계) 하나가 여러 하위 노드로 갈라져 나오는 식이다.

다만 이건 지금 온틀에 박혀 있는 기능이 아니라, 이 논문이 가리키는 방향이다. 온틀이 다음에 어디로 갈지를 비추는 한 줄인 셈이다.

자주 묻는 질문

적합도를 그냥 AI에게 판단시키면 안 되나?

저자들도 그 방식을 함께 실험했는데, 요구 항목을 기준표로 두고 '계산'하는 쪽이 AI에게 적합도를 '판단'시키는 쪽보다 나았다. 사람이든 모델이든 "얼마나 잘 맞겠는가"를 눈대중으로 매기면 흔들린다. 채워야 할 항목을 못으로 박아 두고 채움 여부를 세는 편이 더 안정적이었다는 뜻이다.

쓰려면 모델을 새로 학습시켜야 하나?

아니다. 별도 학습도, 추가 정답 데이터도 필요 없는 2단계 틀이다. 전제는 하나뿐 — 각 단계에 입력·출력 조건을 약속으로 선언해 두는 것이다.

Braid 벤치마크는 어떻게 만들어졌나?

공개 데이터셋 10개를 손봐 14개로 재구성했고, 8개 도메인에 걸쳐 19개 평가 갈래로 짜였다. 각 과제는 두 가지 복잡도와 두 가지 구성 방식으로 조립되며, 네 가지 품질 기준을 걸어 하나라도 통과 못 하면 과제로 쓰지 않았다. 네 가지 품질 기준은 자료끼리 내용이 겹치지 않게, 정답이 미리 새어 나오지 않게, 질문에 맞는 자료가 제대로 들어가게 하는 장치다.

참고자료