ROAR: 서로 다른 AI 연구 시스템을 하나로 묶는 실행 기록 인프라

오늘 다룰 논문은 ROAR: Unifying Runs across Heterogeneous AI-Driven Research Systems입니다. arXiv 2610.03966으로 공개된 이 연구가 내세우는 주장은 하나로 정리됩니다. 서로 다른 AI 연구 시스템이 남긴 실행 기록을 관계형 스키마와 파싱 계층으로 정규화하면, 계보와 시간 구조를 해치지 않고도 여러 문제와 여러 시스템에 걸친 통합 분석이 가능해진다는 것입니다. 원문 링크는 제목 아래에 걸어두었습니다.

이 문제를 제가 처음 마주했을 때 느낌은 생각보다 개인적이었습니다. 연구실에서 실험 로그를 정리하다 보면 폴더마다 형식이 다르고, 어떤 폴더에는 점수만 있고 어떤 폴더에는 중간 과정이 자세히 남습니다. 나중에 두 실험을 비교하려고 하면 점수 하나를 놓고도 이게 같은 조건에서 나온 숫자인지를 확신하기 어렵죠. 논문을 읽기 전부터 저는 이 지점에서 멈칫했습니다. 모델이 똑똑해지는 속도보다 실험을 모아 읽는 속도가 느리다면, 결국 우리는 무엇을 배우고 있는 걸까요.

달라도 너무 다른 실험 기록을 모아놓으면 무슨 일이 생길까

여러 사람이 함께 일하다 보면 각자 메모 방식이 다르다는 것을 곧 알게 됩니다. 누군가는 날짜별로 꼼꼼히 적고, 누군가는 결과만 메신저에 던져둡니다. 그렇다면 여러 AI 연구 시스템이 각자 남긴 실행 기록을 한곳에 모아 비교해야 한다면 어떤 일이 생길까요.

지금 AI로 연구를 수행하는 시스템, 즉 ADRS라고 불리는 부류가 바로 이런 상태에 놓여 있습니다. 시스템마다 풀려는 문제도 다르고 남기는 로그의 모양도 다릅니다. 어떤 시스템은 코드 변경 이력을 자세히 남기고, 다른 시스템은 최종 점수와 몇 줄의 요약만 남깁니다. 그래서 두 시스템을 나란히 놓고 어느 쪽이 더 나은 탐색을 했는지를 묻기가 어렵습니다. 비교의 기준선 자체가 없기 때문입니다.

저는 이 대목에서 도서관 카드를 떠올렸습니다. 책마다 두께도 주제도 다르지만 도서관에서는 저자, 출판연도, 청구기호라는 같은 형식으로 정리하니까 책을 찾을 수 있습니다. ROAR가 하려는 일도 이와 비슷합니다. 서로 다른 실행 기록을 버리지 않으면서도 같은 방식으로 꺼내 읽을 수 있게 만드는 것이죠. 이 시도가 왜 필요했는지를 이해하면 뒤에 나오는 설계가 훨씬 자연스럽게 읽힙니다.

한 번의 실행이 왜 비싼 탐색이 되는 걸까

ADRS의 한 번 실행을 단순한 프로그램 실행으로 보면 이야기가 어긋납니다. 논문이 그리는 그림에서 한 번의 실행은 넓은 답안 공간을 헤매며 답을 찾아가는 값비싼 탐색에 가깝습니다. 모델이 가설을 세우고, 코드를 바꾸고, 실험을 돌리고, 실패를 보고 다시 방향을 트는 과정이 한 번의 run 안에 들어 있기 때문입니다.

여기서 비용은 계산서상의 GPU 시간만을 뜻하지 않습니다. 시행착오 자체가 비용입니다. 답을 찾기까지 거쳐야 하는 중간 단계가 많고, 그 단계마다 평가를 돌려야 하니까요. 그래서 연구자들은 한 번 잘됐다는 결과만으로 안심하지 않습니다. 같은 과정을 여러 번 돌려봐야 그 결과가 운인지 실력인지를 가릴 수 있습니다. 저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 한 번의 실행이 탐색이라면 여러 번의 실행은 그 탐색에 대한 통계가 되기 때문입니다.

문제는 바로 여기서 커집니다. 실행이 비싸고 여러 번 돌려야 하는데, 그 기록을 모아두는 공용 기반은 없었다는 것입니다. 각 팀이 자기 방식으로 로그를 쌓으니 실행 횟수가 늘어날수록 배우는 속도는 오히려 느려집니다. 비싼 돈을 내고 얻은 경험이 다음 팀에게 전달되지 않는 셈이죠. 그렇다면 이 악순환은 어디에서 끊을 수 있을까요. 논문은 그 답을 기록을 모으는 방식에서 찾습니다.

같은 설정인데 결과가 달라지면 무엇을 믿어야 할까

같은 코드를 같은 설정으로 돌렸는데 점수가 다르게 나오면 보통은 당황합니다. 버그를 의심하거나 어딘가에서 시드가 바뀌었을 거라고 생각하죠. 그런데 ADRS에서는 이런 흔들림이 예외가 아니라 관찰되는 현상 중 하나로 보고됩니다. 동일한 설정의 실행들이 서로 다른 점수로 수렴할 수 있다는 것입니다.

왜 그럴까요. ADRS 안에는 언어로 된 판단이 여러 단계에 걸쳐 들어 있습니다. 다음에 무엇을 시도할지를 고르는 과정 자체가 매번 조금씩 달라질 여지를 품고 있기 때문입니다. 작은 선택의 차이가 다음 탐색 경로를 바꾸고, 그 경로의 차이가 최종 점수의 차이로 남습니다. 일종의 나비효과처럼요. 생각해보면 사람도 비슷하게 일합니다. 같은 과제를 같은 시간에 시작해도 팀마다 중간에 시도하는 순서가 달라서 결과가 달라지죠.

여기서는 조금 조심해서 읽을 필요가 있습니다. 흔들림이 있다고 해서 모든 결과가 무의미해지는 것은 아니기 때문입니다. 오히려 흔들림의 크기를 알아야 평균의 의미를 해석할 수 있습니다. 한 번의 성공보다 여러 번의 분포가 더 정직한 이야기가 되는 셈입니다. 저는 이 대목을 읽으면서 예전에 본 실험 노트가 떠올랐습니다. 가장 높은 점수 하나만 굵게 적힌 노트였는데, 그 아래 작은 글씨로 적힌 나머지 시도들을 보고 나서야 그 점수의 무게를 알 수 있었습니다.

서로 다른 시스템의 기록을 어떻게 같은 표에 담을까

그렇다면 서로 다른 시스템의 기록을 어떻게 같은 표에 담을 수 있을까요. ROAR의 답은 관계형 스키마와 파싱 계층의 조합입니다. 서로 다른 모양의 출력을 무작정 한 형식으로 찍어내는 대신, 중간에 해석해주는 층을 두는 방식이죠.

파싱 계층은 각 시스템의 로그를 읽어서 관계형 표가 이해할 수 있는 행과 관계로 바꿔줍니다. 이때 버려지지 말아야 할 것이 두 가지 있습니다. 하나는 데이터 계보, 즉 어떤 결과가 어떤 과정에서 나왔는지를 보여주는 연결이고, 다른 하나는 시간 구조, 즉 탐색이 어떤 순서로 진행됐는지를 보여주는 흐름입니다. 점수만 옮기면 비교는 쉬워지지만 탐색의 이야기가 사라집니다. ROAR는 점수와 함께 그 점수까지의 경로를 살리려고 합니다.

저는 이 선택이 꽤 영리하다고 봤습니다. 흔히 통합이라고 하면 모든 차이를 지워버리는 쪽으로 흐르기 쉽기 때문입니다. 그런데 이 논문은 차이를 지우는 대신 차이를 읽는 법을 따로 두었습니다. 파싱 계층이 시스템별 방언을 번역해주고, 관계형 스키마는 번역된 내용을 같은 문법으로 보관하는 것이죠. 덕분에 시스템이 달라도 어떤 시도가 언제 어떤 선행 시도로부터 나왔는지를 따라갈 수 있습니다.

물론 여기서 걱정되는 지점도 생깁니다. 번역 과정에서 원래 기록의 뉘앙스가 손상되지는 않을까요. 논문의 입장은 계보와 시간 구조를 보존함으로써 그 손실을 줄이겠다는 것입니다. 실행을 평평한 점수 하나로 누르는 대신, 실행을 시간에 따라 펼쳐진 과정으로 보관하겠다는 것이죠. 실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 그렇다면 이 구조 위에 어떤 분석을 올릴 수 있을까요. 뒤에 나오는 900번 이상의 실행 묶음이 그 답을 보여줍니다.

새로운 시스템이 와도 표를 고치지 않아도 되는 이유

통합 기반을 만들 때 가장 빨리 깨지는 약속이 하나 있습니다. 새로운 형식이 오면 표를 뜯어고치겠다는 약속이죠. 처음에는 몇 개 안 되는 시스템만 지원하면 되니까 표를 자주 바꿔도 괜찮아 보입니다. 그런데 시스템이 하나둘 늘어날 때마다 표를 고쳐야 한다면 그 기반은 오래가기 어렵습니다.

ROAR는 새로운 ADRS가 와도 스키마를 고치지 않고 받아들일 수 있도록 설계됐다고 설명합니다. 파싱 계층에서 새 시스템의 방식을 흡수하기 때문에, 보관하는 쪽의 그릇은 그대로 둘 수 있다는 것입니다. 저는 이 대목에서 콘센트 어댑터를 떠올렸습니다. 집의 전기 배선을 바꿀 수는 없으니 나라마다 다른 플러그를 어댑터에서 받아주는 것과 비슷합니다. 그릇을 바꾸는 대신 번역기를 늘리는 선택이죠.

이 차이는 생각보다 중요합니다. 스키마를 자주 바꾸면 과거 데이터와의 호환성이 깨지고 분석 코드도 함께 흔들립니다. 반면 그릇이 안정적이면 분석을 쌓아갈 수 있습니다. 오늘 만든 분석이 내일 온 새 시스템의 기록에도 그대로 적용되니까요. 저희가 새로운 AI 아키텍처를 볼 때도 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 이후 분석의 비용 구조를 어떻게 바꾸는지를 함께 봅니다. 스키마를 바꾸지 않아도 된다는 말은 결국 분석의 수명을 늘리겠다는 말이기 때문입니다.

그렇다면 이런 확장이 실제로 가능할까요. 논문은 여러 ADRS에서 모은 900번 이상의 실행 묶음을 그 증거로 내밉니다. 서로 다른 출신의 기록이 같은 그릇에 담겼다는 것을 직접 보여주는 것이죠. 다음으로 볼 것은 그 묶음이 무엇을 말해주는지입니다.

900번의 실행을 한곳에 모으니 처음 보인 것

900번이라는 숫자는 그 자체로 시선을 끕니다. 단일 팀이 한두 시스템으로 모으기에는 벅찬 규모이고, 여러 시스템에 걸쳐 모았다는 점에서 더 눈에 띕니다. 그런데 저는 이 숫자보다 그 뒤의 배치가 더 중요하다고 봅니다. 따로따로 있으면 각자 흩어진 점에 불과했던 실행들이 한 스키마에 모이면서 비로소 분포와 경향으로 읽히기 시작하기 때문입니다.

개별 실행만 보면 연구자는 자기 시스템의 몇 번 성공에 주목하기 쉽습니다. 우리 시스템이 이 문제에서 좋은 점수를 냈다는 식이죠. 하지만 여러 시스템의 실행을 같은 문제 축 위에 올려놓으면 질문이 바뀝니다. 어느 시스템이 이겼는지가 아니라, 어떤 탐색이 어떤 문제에서 먹히는지로 말이죠. 시야가 시스템 자랑에서 탐색 이해로 옮겨갑니다.

여기서 재미있는 질문이 생깁니다. 이렇게 모인 기록은 과연 공정한 비교를 가능하게 할까요. 완전히 공정한 비교는 어렵습니다. 시스템마다 시도 횟수도 다르고 문제의 난이도도 다르기 때문입니다. 그럼에도 모으는 쪽이 낫습니다. 조건의 차이를 표 안에서 드러낼 수 있기 때문입니다. 비교할 수 없다는 것을 막연히 말하는 대신, 무엇이 달라서 직접 비교가 어려운지를 구체적으로 가리킬 수 있게 됩니다. 이 투명성만으로도 다음 실험을 설계하는 방식이 달라집니다.

대부분의 성과는 왜 초반에 몰려 있을까

모인 기록에서 드러난 관찰 중 하나는 많은 실행이 대부분의 성과를 탐색 초반에 실현한다는 점입니다. 달리 말하면 뒤로 갈수록 새로 얻는 것이 줄어드는 경우가 많다는 것입니다. 처음 몇 번의 시도에서 점수가 껑충 뛰고, 그 뒤에는 미세한 조정만 이어지는 그림이죠.

왜 이런 모양이 나올까요. 이유를 따져보면 크게 두 갈래로 볼 수 있습니다. 하나는 쉬운 개선이 먼저 발견되기 때문입니다. 명백한 버그 수정이나 당연한 방향 전환은 초반에 소진됩니다. 다른 하나는 탐색이 스스로 만든 경로에 갇히기 때문입니다. 초반에 잡은 방향이 이후 시도를 끌어당기면서 새로운 갈래로 뻗어나가기가 어려워지는 것이죠. 등산로에 비유하면 처음에는 가파르게 오르다가 능선에 올라선 뒤에는 평평하게 걷는 것과 비슷합니다.

이 관찰은 운영에 직접적인 함의를 줍니다. 실행을 무작정 길게 끌 필요가 없을 수 있다는 것입니다. 초반에 성과가 몰린다면 예산을 뒤쪽에 얇게 펴기보다 앞쪽 탐색의 폭을 넓히는 편이 나을 수 있습니다. 물론 모든 문제가 그렇다는 뜻은 아닙니다. 어떤 문제는 뒤늦게 열리는 문이 있으니까요. 그래서 여기서 멈추지 않고 다음 관찰로 이어져야 합니다. 초반 이후를 어떻게 만드느냐는 이전 답안을 어떻게 쓰느냐와 연결되기 때문입니다.

이전 답안을 보여주는 방법이 문제마다 달랐던 이유

ADRS를 돌릴 때 이전에 찾은 답안을 어떻게 활용할지는 오래된 고민입니다. 좋은 답안을 보여주면 탐색이 빨라질 것 같지만, 보여주는 방식에 따라 오히려 탐색이 좁아질 수도 있습니다. ROAR로 모은 기록은 이 선택의 효과가 문제마다 다르다는 것을 보여줍니다.

어떤 문제에서는 이전 답안을 강하게 참조하는 편이 잘 먹힙니다. 이미 찾은 구조를 다듬는 것만으로 점수가 오르는 문제에서는 당연한 일입니다. 반면 다른 문제에서는 이전 답안에서 한 발 떨어지는 편이 낫습니다. 이전 답안에 묶이면 새로운 구조를 시도하지 못하기 때문입니다. 같은 처방이 문제에 따라 약이 되기도 하고 족쇄가 되기도 하는 셈입니다.

저는 이 대목에서 오답 노트를 다시 떠올렸습니다. 오답 노트가 어떤 과목에서는 놀라운 효과를 내지만 어떤 과목에서는 오히려 사고를 굳게 만듭니다. 해법이 정형화된 영역에서는 과거 풀이가 지름길이 되지만, 열린 탐색이 필요한 영역에서는 과거 풀이가 시야를 가리기 때문입니다. ADRS의 이전 답안 활용도 같은 궤적을 그립니다.

여기서 제가 앞으로 보고 싶은 것은 문제의 성격과 처방 사이의 연결입니다. 어떤 신호를 보면 강한 참조를 고르고 어떤 신호를 보면 약한 참조를 골라야 할까요. 논문은 모인 묶음이 바로 이런 선택을 위한 재료가 될 수 있다고 말합니다. 과거 기록을 보면 문제별 반응이 드러나니까, 다음 실행의 설정을 감으로 고르지 않아도 된다는 것이죠.

모인 기록으로 다음 실행을 고르는 법

앞선 이야기가 관찰이었다면 이번 이야기는 활용입니다. 모인 실행 묶음을 다음 ADRS 실행의 설정에 쓸 수 있다는 것입니다. 이전 답안을 어떻게 활용할지 같은 선택을 문제에 맞춰 고르는 데 과거 기록을 쓰는 것이죠.

방식은 직관적입니다. 비슷한 문제에서 어떤 설정이 어떤 결과를 냈는지를 표에서 꺼내봅니다. 강한 참조가 잘 먹혔던 문제와 약한 참조가 필요했던 문제를 구분하고, 새로 풀 문제의 성격을 그 지도 위에 올려놓는 것입니다. 지도 없이 출발하는 것과 발자국이 찍힌 지도를 들고 출발하는 것의 차이는 큽니다. 특히 실행 한 번이 비싸다면 첫발의 방향이 전체 예산을 좌우하기 때문입니다.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 이 지도가 얼마나 믿을 만할까요. 과거 기록은 어디까지나 과거의 시스템과 과거의 문제에서 나온 것입니다. 새 시스템과 새 문제에 그대로 통한다는 보장은 없습니다. 그럼에도 저는 이 시도를 낮게 보지 않습니다. 아무 근거 없이 설정을 고르는 것보다는 과거 분포를 보고 고르는 편이 낫기 때문입니다. 완벽한 예측이 아니라 실패의 확률을 조금이라도 낮추는 용도라면 충분히 값어치가 있습니다.

다만 여기서 한 가지 경계가 필요합니다. 과거에 잘된 설정을 따라가는 관성이 새로움을 막을 수도 있기 때문입니다. 겉보기에 확산처럼 보이는 사례 대부분이 소수의 반복 때문이듯, 과거 기록도 자주 등장한 설정이 좋아 보이는 착시를 만들 수 있습니다. 그래서 기록을 쓸 때는 빈도뿐 아니라 조건을 함께 봐야 합니다. 어떤 설정이 어떤 문제에서 어떤 경로를 거쳐 성공했는지를 함께 읽는 것이죠. ROAR가 계보와 시간 구조를 남기려는 이유가 바로 여기에 닿아 있습니다.

그래서 연구 시스템 인프라는 어디로 가야 할까

처음으로 돌아가 보겠습니다. 이 논문은 새로운 탐색 알고리즘을 내놓은 것이 아닙니다. 탐색을 모아 읽는 그릇을 내놓은 것입니다. 저는 이 선택을 꽤 오래 곱씹었습니다. 보통 연구는 더 잘 찾는 법을 말하는데, 이 연구는 찾은 것을 더 잘 모으는 법을 말하기 때문입니다.

이 차이가 왜 중요할까요. ADRS의 실행이 비싸고 여러 번 돌려야 하며 설정이 같아도 흔들린다면, 개별 실행 하나하나를 완벽하게 만드는 것만으로는 부족합니다. 실행들을 엮어서 읽는 층이 있어야 전체 그림이 보입니다. ROAR는 그 층을 관계형 스키마와 파싱 계층으로 만들자고 제안합니다. 새 시스템이 와도 그릇을 바꾸지 않고, 계보와 시간을 살리고, 900번 이상의 기록으로 그 쓰임을 증명한 것이죠.

그렇다면 사람의 역할은 무엇일까요. 그릇이 생겼다고 해서 해석이 자동으로 따라오지는 않습니다. 초반 성과에 취해 탐색을 일찍 접을지, 이전 답안을 강하게 쓸지 약하게 쓸지, 과거 기록을 어디까지 믿을지는 여전히 사람의 판단에 남습니다. 오히려 그릇이 생기면서 질문은 더 선명해졌습니다. 무엇을 모을지가 아니라 모은 것을 어떻게 읽을지가 남았기 때문입니다.

앞으로 에이전트가 더 오래 일하고 더 많은 시스템이 연결될수록, 개별 실행 하나가 아니라 실행들의 묶음을 보는 눈이 더 중요해질 것 같습니다. ROAR는 그 눈을 위한 첫 번째 안경에 가깝습니다. 안경이 세상을 대신 보지는 않지만, 없으면 보이지 않던 것이 보이게 만듭니다. 다음에는 이 안경을 쓰고 어떤 문제 지도가 그려질지, 그 지도 위에서 어떤 탐색이 다시 설계될지를 지켜보고 싶습니다.