달리던 에이전트를 멈추지 않고 고치는 법, ARIA가 던진 질문

ARIA: Runtime Inspection and Amendment for Multi-Agent Systems는 arXiv 번호 2610.20780으로 공개된 멀티 에이전트 연구입니다. 원문 링크는 제목 아래에 걸어두었습니다. 이 연구가 내세우는 주장은 하나의 문장으로 정리됩니다. 고장 난 뒤에 다시 돌리는 대신 실행 검증된 복구 경험을 미리 학습해 두면, 작은 모델도 달리는 멀티 에이전트 흐름에 알맞은 순간에 개입할 수 있다는 것입니다. 이 글에서는 그 문제의식에서 출발해 실패가 번지는 방식과 사후 진단의 한계, 복구쌍 데이터의 구축, 개입 시점과 수정 방식을 함께 배우는 구조, 그리고 낯선 조합으로의 일반화 주장까지 차례로 따라갑니다.

혼자 틀리면 메모인데 함께 틀리면 사고가 된다

여러 사람이 함께 일하다 보면, 누군가의 말 한마디가 팀 전체의 분위기나 방향을 바꾸기도 합니다. 그렇다면 여러 AI가 한 팀으로 일할 때도 비슷한 일이 생길까요? ARIA가 출발한 지점이 바로 여기입니다. 제가 이 논문에서 가장 흥미롭게 본 부분은 실패를 모델 하나의 실수로 보지 않았다는 점인데, 하나의 에이전트가 저지른 작은 착각이 다른 에이전트의 입력이 되면서 고칠 수 있던 오류가 과제 전체의 실패로 굳어지는 장면을 정면으로 다루기 때문입니다.

생각해보면 사람 조직도 비슷하게 망가집니다. 회의 초반에 누군가 숫자를 하나 잘못 읽으면, 다음 사람은 그 숫자를 전제로 표를 만들고, 그다음 사람은 그 표를 전제로 보고서를 씁니다. 처음에는 지우개 하나로 지울 수 있던 오류가 세 단계를 거치면 문서 전체를 다시 써야 하는 일로 커집니다. 멀티 에이전트 시스템에서는 이 과정이 더 빠르고 조용하게 일어납니다. 에이전트들은 서로의 중간 출력을 의심 없이 이어받는데, 중간에 멈춰 서서 이 전제가 맞는지 묻는 역할이 따로 없기 때문입니다.

그래서 ARIA가 그리는 실패는 한 방에 무너지는 드라마가 아닙니다. 처음에는 사소해 보이는 엇갈림이 대화와 파일과 도구 호출을 타고 조금씩 번지고, 어느 순간인가 되돌릴 수 없는 방향으로 굳어지는 흐름이죠. 저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 개별 모델의 똑똑함을 올리는 일과 흐름 전체가 틀어지는 것을 막는 일은 서로 다른 문제인데, 오랫동안 우리는 전자에만 점수를 매겨 왔기 때문입니다. 그렇다면 흐름을 살리는 일은 누가 맡아야 할까요? 그 질문이 다음 이야기로 이어집니다.

끝난 경기를 복기하면 다음 경기를 살릴 수 있을까

실패를 다루는 익숙한 방법은 끝난 뒤에 돌아보는 것입니다. 실행 기록을 펼쳐서 어디서 틀렸는지 찾고, 처음부터 다시 돌리거나 사람이 직접 고치는 방식이죠. 그런데 ARIA가 지적하는 지점은 이 방법이 다음 실행을 돕기는 해도, 지금 달리는 실행을 돕지는 못한다는 데 있습니다. 경기가 끝난 뒤에 복기를 아무리 정밀하게 해도, 이미 진 경기의 점수가 바뀌지 않는 것과 같습니다.

여기서는 조금 조심해서 읽을 필요가 있습니다. 사후 진단이 쓸모없다는 이야기가 아니기 때문입니다. 어디서 자주 넘어지는지 아는 일은 분명히 도움이 됩니다. 그런데 막상 에이전트들이 일하는 현장에서는 그 지식이 손에 잡히지 않습니다. 진단은 멈춘 기록을 상대로 나오는데, 정작 도움이 필요한 순간은 기록이 아직 쓰이는 중이기 때문입니다. 다시 말해, 아는 것과 끼어드는 것은 서로 다른 능력인데, 기존 접근은 아는 쪽에만 머물렀던 셈입니다.

또 하나는 반복 실행의 비용 문제입니다. 고장 난 작업을 처음부터 여러 번 돌리면서 고칠 때까지 기다리는 방법은 가끔 통하는데, 매번 처음부터 헤매는 에이전트를 옆에서 보고 있자면 속이 탑니다. 같은 실수를 세 번째 반복할 때쯤이면, 차라리 중간에 누군가 어깨를 두드리며 방향만 잡아줬으면 싶어지니까요. 그런데 기존의 재실행 탐색은 그 어깨를 두드리는 타이밍을 배우지 않습니다. 고장마다 새로 헤매면서 답을 찾기 때문입니다. 그렇다면 헤맴 자체를 학습 데이터로 바꾸면 어떻게 될까요? 연구진이 고른 길은 바로 그쪽이었습니다.

달리면서 고친다는 말은 실제로 무엇을 뜻할까

ARIA라는 이름에는 검사(inspection)와 수정(amendment)이라는 두 동작이 나란히 들어 있습니다. 저는 이 짝을 처음 보고 고개를 끄덕였는데, 고친다는 말 속에 언제 고칠지와 어떻게 고칠지가 함께 들어 있기 때문입니다. 언제 끼어들지 모르면 고칠 거리도 못 찾고, 어떻게 이어갈지 모르면 끼어든 게 오히려 방해가 됩니다. 그래서 연구진은 개입 시점과 수정 생성을 하나의 능력으로 묶습니다.

이 구분은 생각보다 중요합니다. 표면적으로 보면 개입은 그냥 빨리 하면 좋은 것처럼 보이는데, 실제로는 그렇지 않습니다. 너무 일찍 손대면 에이전트 스스로 바로잡을 수 있던 흔들림까지 끊어버리고, 너무 늦게 손대면 이미 굳어진 전제를 되돌리느라 더 큰 공사가 필요해지기 때문입니다. 일종의 응급실 분류처럼요. 모든 환자에게 같은 처방을 내리는 게 아니라, 지금 손대야 하는 경우와 지켜봐도 되는 경우를 가르는 일이 먼저라는 뜻입니다.

저는 여기서 멈칫했습니다. 우리가 에이전트에게 흔히 바라는 모습이 스스로 끝까지 해내는 자율성인데, 중간에 끼어드는 장치가 그 자율성을 해치지 않을까 하는 걱정이 들었기 때문입니다. 그런데 논문의 관점에서 보면 개입은 자율성의 반대가 아니라 자율성을 유지하기 위한 장치에 가깝습니다. 사람이 동료의 어깨너머로 화면을 보다가 엉뚱한 파일을 지우려 할 때만 조용히 말리는 것처럼요. 자주 끼어들수록 좋은 게 아니라, 끼어들지 않아도 되는 흐름을 만드는 게 목표라는 점에서 이 설계는 꽤 절제되어 있습니다. 그렇다면 이 절제된 타이밍 감각은 어디서 배울 수 있을까요? 답은 데이터에 있습니다.

2만 4천 번의 헤맴에서 골라낸 3,953개의 복구

ARIA의 데이터 구축 이야기는 숫자부터가 묵직합니다. 네 가지 멀티 에이전트 틀과 여섯 가지 벤치마크, 여덟 가지 호스트 모델에 걸쳐 24,000개가 넘는 성공과 실패 궤적을 모았고, 그중에서 검증된 복구쌍 3,953개를 건졌다고 합니다. 성공만 모은 것도 아니고 실패만 모은 것도 아니라, 성공과 실패를 나란히 놓고 그 사이를 잇는 복구 경험을 캐낸 것입니다. (참고로 여기서 복구쌍이란 실패 흐름을 살려낸 전후 기록 묶음을 뜻하는데, 단순히 잘된 답안지가 아니라 어디서 방향을 틀어 어떻게 살렸는지가 함께 적혀 있습니다.)

이 과정이 흥미로운 이유는 탐색의 위치를 옮겼기 때문입니다. 보통은 실행 중에 여러 대안을 시험하면서 고치려고 하는데, 그러면 매번 시간과 비용이 듭니다. 반면 ARIA는 그 비싼 탐색을 데이터 만드는 단계로 밀어 넣습니다. 실패한 흐름을 다시 돌려보고 고쳐보고, 정말로 살아나는 복구만 남겨서 학습 신호로 쓰는 것이죠. 미리 땀을 흘려 연습 문제를 풀어두면, 본番에서는 오래 고민하지 않고 바로 손이 나가는 것과 같습니다. 저희가 새로운 AI 아키텍처를 볼 때도 benchmark 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 보는데, 이 연구는 실행 중 탐색 비용을 학습 단계로 옮겼다는 점에서 비용 구조 자체를 바꾼 셈입니다.

숫자를 그대로 믿기 전에 조건을 봐야 한다는 점도 짚고 싶습니다. 24,000개라는 모음 자체가 성능을 보장하지는 않기 때문입니다. 많은 기록을 모았는지보다 어떤 복구만 남겼는지가 더 중요한데, 연구진은 실행으로 검증된 경우만 남겼다고 말합니다. 말로만 그럴듯한 수정이 아니라 실제로 돌려보니 살아나는 수정을 골랐다는 뜻이니까요. 일반 파일에만 남겼을 때는 17%에 그쳤지만 특정 파일에 옮겨 적었을 때는 55%까지 올라갔다는 식의 조건부 숫자가 전염 연구에서 중요했듯이, 여기에서도 무엇이 검증 조건이었는지가 결과를 읽는 열쇠가 됩니다. 실행 검증이라는 필터를 통과한 3,953개라는 숫자는 그래서 단순한 분량 자랑이 아니라 품질 선언에 가깝습니다. 그렇다면 그 복구쌍 안에는 정확히 무엇이 들어 있을까요?

무엇이 잘못됐고 어디서 손대야 하는지 적어두는 일

복구쌍 하나에는 세 가지가 함께 적혀 있습니다. 무엇이 잘못됐는지, 어디서 개입해야 하는지, 그리고 실행을 어떻게 이어가야 하는지입니다. 저는 이 세 칸짜리 양식이 마음에 들었는데, 실패 설명만 있거나 수정 답만 있는 기록보다 현장에서 훨씬 쓸모가 있기 때문입니다. 병원에서 인수인계할 때도 진단명만 넘기지 않고, 언제 무엇을 했고 다음 근무자가 무엇을 이어야 하는지를 함께 넘기죠. 그 메모가 있어야 다음 사람이 같은 검사를 반복하지 않습니다.

여기서 재미있는 질문이 생깁니다. 왜 하필 어디서 개입할지가 따로 필요할까요? 실패 지점과 개입 지점이 항상 같지는 않기 때문입니다. 불이 난 곳과 불을 끄기 위해 물을 뿌려야 하는 곳이 다를 때가 있듯이, 에이전트 흐름에서도 잘못이 드러난 장면보다 한두 단계 앞이나 뒤가 손대기 좋은 자리일 수 있습니다. 예를 들어 두 번째 에이전트가 숫자를 잘못 옮겼는데, 정작 흐름을 살리려면 세 번째 에이전트가 그 숫자를 쓰기 직전이 더 좋은 개입 자리일 수 있습니다. 연구진이 개입 위치를 따로 적어둔 것은 이런 시간차 감각을 학습시키겠다는 뜻으로 읽힙니다.

어떻게 이어갈지에 대한 기록도 그냥 정답지가 아닙니다. 실패한 궤적을 통째로 버리고 처음부터 다시 쓰는 게 아니라, 살릴 수 있는 부분은 살리면서 방향만 트는 이어쓰기입니다. 긴 글을 쓰다가 앞 문단 하나가 어긋났을 때 전체를 지우지 않고 그 문단부터 다시 쓰는 것과 같습니다. 이 차이가 나중에 시스템 전체의 비용을 가릅니다. 처음부터 다시 돌리면 멀쩡하던 앞부분까지 다시 계산해야 하는데, 중간부터 이어가면 그 낭비가 줄어들기 때문입니다. 그렇다면 이렇게 만든 기록은 특정 틀에서만 통할까요, 아니면 어디서든 쓸 수 있을까요?

궤적만 보이면 올라탈 수 있다는 말의 뜻

ARIA는 특정 멀티 에이전트 틀에 묶이지 않는 설계를 내세웁니다. 실행 궤적을 볼 수 있고, 중간부터 다른 이어쓰기로 교체할 수 있는 시스템이라면 어떤 틀에도 붙을 수 있다는 설명이죠. 저는 이 조건을 보고 꽤 현실적이라고 느꼈는데, 모든 틀을 뜯어고치라는 요구가 아니라 두 가지 통로만 열어달라는 부탁이기 때문입니다. 궤적을 보여주는 창 하나, 그리고 이어쓰기로 갈아타는 문 하나. 이 두 개만 있으면 ARIA가 조수석에 탈 수 있다는 뜻입니다.

생각해보면 사람 조직의 외부 코치도 비슷하게 일합니다. 팀 내부 규칙을 다 외우지 않아도, 회의록을 볼 수 있고 중간에 발언권을 얻어 방향을 제안할 수 있으면 도움을 줄 수 있습니다. 내부 직함이 없어도 회의록 공개와 발언 기회라는 두 가지 장치만 있으면 코치가 설 자리가 생기는 것과 같습니다. ARIA가 말하는 MAS 비의존이란 특정 틀 전용 장치가 아니라, 이런 코치 자리 하나를 표준으로 만들겠다는 선언에 가깝습니다.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 궤적을 본다는 게 정확히 무엇일까요? 에이전트들이 주고받은 메시지와 도구 호출과 파일 변경 같은 중간 기록을 순서대로 읽을 수 있다는 뜻인데, 이 기록이 있어야 어디서 흐름이 틀어졌는지 찾을 수 있습니다. 그리고 이어쓰기 교체란, 틀어진 지점 이후의 계획을 통째로 버리는 대신 수정된 이어쓰기로 바꿔 끼우는 동작입니다. 기차가 잘못된 선로로 들어서기 직전에 분기기를 바꿔주는 것과 같습니다. 기차 자체를 바꾸지 않아도 분기기 하나로 행선지가 달라지니까요. 문제는 그 분기기를 언제 바꿀지 아는 일인데, 그 타이밍을 배우는 주체가 바로 작은 모델입니다.

작은 모델이 타이밍과 처방을 함께 배우는 일

ARIA가 학습시키는 모델은 크기로 승부하는 모델이 아닙니다. 검증된 복구 경험에서 언제 개입해야 하는지와 어떻게 고쳐야 하는지를 함께 배우는, 말하자면 작지만 눈썰미 있는 조수에 가깝습니다. 저는 이 선택을 보고 연구진의 문제의식이 분명하다고 느꼈는데, 실행 중에 매번 거대 모델을 여러 번 돌릴 수 없으니 개입 감각을 따로 떼어내 가볍게 만들겠다는 판단이기 때문입니다.

이 둘을 함께 배운다는 점이 묘수입니다. 타이밍만 배우면 손은 빠르지만 무엇을 해야 할지 모르고, 처방만 배우면 처방전은 좋은데 꺼내는 순간이 늦기 때문입니다. 마치 운전 옆자리의 동승자처럼요. 위험한 순간에 브레이크를 외치는 일과, 그다음에 어느 길로 돌아가야 하는지 알려주는 일은 따로 떨어지면 쓸모가 반감됩니다. 언제 외칠지와 어디로 가라고 할지를 같은 사람이 알아야 흐름이 끊기지 않죠. ARIA의 작은 모델이 맡는 역할이 바로 이 동승자 자리입니다.

여기서는 조금 조심해서 읽을 필요가 있습니다. 작다는 말이 성능이 낮아도 된다는 뜻은 아니기 때문입니다. 오히려 개입 판단은 매 실행마다 켜져 있어야 해서, 무겁고 느린 모델은 현장에서 쓰기 어렵습니다. 가벼워야 매 순간 곁에 있을 수 있고, 곁에 있어야 타이밍을 잡을 수 있습니다. 그래서 작은 모델이라는 선택은 타협의 결과가 아니라 현장 조건에서 나온 요구에 가깝습니다. 계속 켜둘 수 있어야 한다는 조건이 크기를 정한 셈입니다. 그렇다면 이렇게 배운 감각은 처음 보는 현장에서도 통할까요?

처음 보는 팀과 처음 보는 선수 앞에서도 통할까

논문이 내세우는 주장 가운데 읽는 사람의 손을 멈추게 하는 대목이 바로 일반화입니다. 학습 때 보지 못한 틀과 호스트 모델에서도 개입이 통했다는 보고인데, 이게 사실이라면 ARIA가 배운 것이 특정 틀의 버릇이 아니라 실패가 번지는 공통 문법이라는 뜻이 되기 때문입니다. 저는 이 대목을 읽고 기대와 의심을 함께 품었는데, 일반화라는 말은 언제나 조건을 따져봐야 하기 때문입니다.

왜 이 주장이 중요할까요? 멀티 에이전트 현장은 틀마다 대화 방식과 도구 목록과 기록 형식이 조금씩 다르기 때문입니다. 축구팀과 농구팀은 둘 다 팀 운동이지만, 같은 작전이 통하지 않는 것처럼요. 그런데도 ARIA는 틀을 가리지 않고 통했다고 말합니다. 그렇다면 연구진이 포착한 것은 특정 틀의 규칙이 아니라, 에이전트가 서로의 출력을 이어받을 때 생기는 공통의 취약 구간일 가능성이 큽니다. 잘못된 전제를 의심 없이 이어받는 버릇, 중간 검증 없이 다음 단계로 넘어가는 버릇 같은 것들이죠.

다만 여기서 물을 질문도 남습니다. 보지 못한 조합에서 통했다는 말이 모든 낯선 조합에서 통한다는 뜻은 아닐 텐데, 어디까지가 통하고 어디부터가 안 통할까요? 여덟 가지 호스트 모델과 네 가지 틀이라는 다양성은 분명히 설득력이 있는데, 그 다양성이 현장의 모든 다양성을 대신하지는 않기 때문입니다. 저는 이 숫자를 성공 선언보다 초대장으로 읽고 싶습니다. 더 많은 틀과 더 지저분한 현장에서 어디까지 버티는지 보여달라는 초대라는 뜻입니다. 그 초대장을 받아들기 전에, 먼저 이 연구가 무엇이 아닌지를 분명히 해둘 필요가 있습니다.

다시 돌리는 일과 달리면서 고치는 일은 다르다

ARIA를 처음 들으면 기존의 재시도나 자가 수정과 뭐가 다르냐는 질문이 바로 나옵니다. 겉으로 보면 다 고치는 이야기니까요. 그런데 들여다보면 방향이 다릅니다. 재시도는 고장 난 뒤에 처음부터 다시 뛰는 것이고, ARIA는 뛰는 중에 방향을 트는 것이기 때문입니다. 마라톤에서 길을 잘못 들었을 때 결승점에 가서 다시 뛰는 것과, 길목에서 자원봉사자가 미리 방향을 잡아주는 것의 차이와 같습니다.

또 하나 자주 겹쳐 보이는 것이 사후 진단 도구입니다. 어디서 틀렸는지 찾아주는 도구는 이미 있는데, 굳이 실행 중에 끼어들 필요가 있냐는 반문입니다. 그런데 진단은 원인을 알려줄 뿐 손을 잡아주지 않습니다. 병명만 알려주고 처방은 다음에 오라는 것과 같습니다. 반면 ARIA가 겨냥하는 것은 진단과 처방과 투여 시점이 하나로 묶인 실행 중 개입인데, 이 묶음 자체가 학습의 대상이라는 점에서 기존 진단과 결이 다릅니다.

개인적으로 덧붙이고 싶은 구분이 하나 더 있습니다. ARIA는 에이전트를 더 똑똑하게 만드는 연구가 아니라, 똑똑한 에이전트들이 함께 일할 때 생기는 틈을 메우는 연구에 가깝습니다. 개별 선수의 기량을 올리는 훈련이 아니라, 패스가 끊기는 지점을 읽고 미리 움직이는 팀 훈련 같은 것이죠. 그래서 단일 모델 점수표만 보고 이 연구를 평가하면 놓치는 게 생깁니다. 진짜로 봐야 할 것은 개별 점수가 아니라 흐름이 살아나는지 여부이기 때문입니다. 그렇다면 흐름이 산다는 것을 우리는 어떻게 알아볼 수 있을까요? 그 질문은 다음 장면의 몫입니다.

성공과 실패 사이를 잇는 연습 문제의 값어치

24,000개가 넘는 궤적과 3,953개의 검증된 복구쌍이라는 숫자는 어떻게 읽어야 할까요? 저는 이 숫자보다 그 뒤의 선별 과정을 더 중요하게 봅니다. 많이 모았다는 사실보다, 실제로 돌려보니 살아나는 복구만 남겼다는 필터가 이 데이터의 성격을 정하기 때문입니다. 말로만 그럴듯한 수정은 버리고, 이어붙였더니 과제가 실제로 풀리는 수정만 남겼다는 뜻입니다. 연습 문제를 만들 때 해설지만 그럴듯한 게 아니라, 그 해설대로 풀었더니 실제로 답이 나오는 문제만 남긴 셈입니다.

이 선별이 중요한 이유는 학습 신호의 오염을 막기 때문입니다. 잘못된 개입까지 정답처럼 가르치면 모델은 손대야 할 때와 가만히 있어야 할 때를 헷갈리게 되는데, 실행 검증이라는 관문을 두면 그 혼선이 줄어듭니다. 운전 연습에서 옆자리 강사가 매번 다른 말을 하면 초보 운전자가 더 헷갈리는 것과 같습니다. 일관되게 살아나는 경우만 보여줘야 감이 잡힙니다. 3,953이라는 숫자는 그래서 분량의 자랑이 아니라 정제도의 표현에 가깝습니다.

그런데 여기서도 물을 점이 남습니다. 검증된 복구란 결국 주어진 벤치마크 안에서 풀린 경우를 뜻하는데, 벤치마크 바깥의 지저분한 현장에서도 같은 기준으로 검증됐다고 말할 수 있을까요? 연구진이 여섯 가지 벤치마크를 썼다는 대목은 이런 의심을 덜어주지만, 완전히 없애주지는 않습니다. 현장에는 벤치마크에 없는 도구와 권한과 시간 압박이 있기 때문입니다. 저는 그래서 이 데이터를 완성품보다 출발점으로 봅니다. 실행 검증된 복구쌍이라는 양식을 만들었다는 점 자체가 성과이고, 그 양식을 현장 데이터로 채우는 일은 다음 몫으로 남는 것이죠. 그 다음 몫을 생각하면 자연스럽게 비용 이야기로 이어집니다.

매번 헤매지 않으면 무엇이 달라질까

ARIA의 설계에서 제가 실무적으로 가장 눈여겨본 대목은 탐색 비용의 위치입니다. 실행 중에 여러 대안을 시험하는 대신, 그 탐색을 데이터 구축과 학습 단계로 옮겼다는 점인데, 이러면 현장에서는 오래 고민하지 않고 바로 개입할 수 있기 때문입니다. 매번 처음부터 헤매는 에이전트 옆에서 같은 고민을 반복하는 대신, 미리 풀어본 문제의 감으로 바로 손을 대는 구조입니다. 시험 당일에 문제를 처음 보는 학생과, 비슷한 유형을 수백 번 풀어본 학생의 차이와 같습니다.

운영 측면에서 보면 이 차이는 상당히 큽니다. 실행 중 탐색은 매 고장마다 시간과 토큰과 도구 호출을 다시 쓰는데, 학습된 개입은 그때그때의 추가 탐색 없이 판단만 내리면 되기 때문입니다. 밤사이 공시가 늦게 도착하거나 아침에 특정 종목이 거래 정지에 걸려도 예측 라인은 멈추면 안 되는 것처럼, 에이전트 라인도 고장마다 멈춰 서서 처음부터 다시 생각할 수는 없습니다. 옆에서 지켜보던 조수가 짧게 방향만 잡아주고 흐름을 이어가게 하는 편이 훨씬 싸게 먹히죠.

저희 팀 관점에서도 같은 기준이 통합니다. 새로운 구조를 볼 때 점수만 묻지 않고, 그 점수를 내기 위해 어떤 계산을 매번 반복하는지를 함께 묻기 때문입니다. 같은 성공률이라도 매번 다섯 번씩 다시 돌려서 얻은 성공과 한 번의 개입으로 이어간 성공은 비용이 다릅니다. ARIA가 겨냥한 것은 바로 이 두 번째 종류의 성공인데, 성공률이라는 분자보다 비용이라는 분모를 함께 본 셈입니다. 그렇다면 이 성공을 더 넓은 현장에서 믿으려면 무엇이 더 필요할까요? 마지막 질문으로 넘어갈 차례입니다.

제가 앞으로 보고 싶은 것은 고장 난 현장의 기록이다

지금까지의 이야기를 정리하면 이렇습니다. 멀티 에이전트에서는 작은 오류가 이웃 에이전트를 타고 번지면서 고칠 수 있던 문제가 과제 실패로 굳어집니다. 끝난 뒤의 진단이나 처음부터의 반복 실행은 그 굳어짐을 늦추지 못하는데, ARIA는 실행 검증된 복구 3,953개를 미리 학습해 실행 중에 언제 어떻게 끼어들지를 아는 작은 모델로 맞섰습니다. 궤적을 보여주고 이어쓰기를 갈아끼울 수 있으면 어떤 틀에도 붙을 수 있다는 설계와, 보지 못한 틀과 모델에서도 통했다는 보고까지 덧붙였습니다.

그렇다면 사람의 역할은 무엇일까요. 저는 앞으로 보고 싶은 것이 논문 바깥의 고장 기록입니다. 벤치마크 안의 24,000개 궤적을 넘어, 권한이 막히고 도구가 바뀌고 시간에 쫓기는 실제 현장에서 이 개입 감각이 어디까지 버티는지 궁금하기 때문입니다. 연구실 점수 이상으로 평가할 만한 지점이 있다면, 운영의 아침을 지켜주는 장치인지 여부일 텐데, 그 증명은 결국 현장 기록에서 나올 수밖에 없습니다.

다행히 확인할 방법은 단순합니다. 궤적을 남기는 일, 개입이 통했는지 실행으로 확인하는 일, 그리고 통하지 않은 경우를 다시 복구쌍으로 돌려보내는 일. 이 순환이 돌기 시작하면 ARIA는 논문 한 편을 넘어 현장의 습관으로 남을 수 있습니다. 앞으로 에이전트가 더 오래 일하고 더 많은 에이전트와 연결될수록, 개별 모델 하나가 똑똑한지만 보는 것을 넘어 흐름 사이에서 무엇이 번지고 어떻게 바로잡히는지를 함께 살펴봐야 할 것 같습니다. 저는 그 흐름을 읽는 눈이야말로 다음 멀티 에이전트 경쟁의 갈림길이라고 봅니다.