작은 모델들을 한 팀으로 굴리는 법을 묻다

이번에 다룰 논문은 arXiv에 공개된 OrchSLM: Probing the Dynamics of Small Language Model Orchestration으로, 식별자는 arXiv:2609.13470입니다. 원문 링크는 제목 아래에 걸어두었습니다. 이 논문이 던지는 주장은 한 문장으로 정리할 수 있는데, 서로 다른 작은 언어모델들이 각자 독립적으로 답 후보를 만들고 나면 그 뒤의 선택과 조합을 라우터가 맡는 비인터랙티브 오케스트레이션만으로도 에이전트 파이프라인의 많은 부분을 감당할 수 있다는 것입니다.

제가 이 논문을 집어든 이유는 거창하지 않습니다. 평소에 에이전트를 만지다 보면 매번 거대 모델을 부르는 손이 조금 무거워질 때가 있기 때문입니다. 간단한 분류 하나, 짧은 요약 하나를 위해 매번 클라우드를 왕복하는 일이 반복되면 어느 순간 이런 생각이 듭니다. 이 정도는 작은 모델로도 되지 않을까. 그런데 막상 작은 모델을 여러 개 엮으려고 하면 또 다른 고민이 생깁니다. 어떻게 엮어야 전체가 똑똑해질까. OrchSLM은 바로 그 엮는 방식의 움직임을 들여다보겠다고 말합니다.

작은 모델 여러 개가 한 팀이 되면 무슨 일이 생길까

여러 사람이 함께 일하다 보면 누군가의 말 한마디가 팀 전체의 분위기를 바꾸기도 합니다. 그렇다면 여러 개의 작은 AI가 한 팀으로 일할 때도 비슷한 일이 생길까요. 각자 따로 생각한 뒤에 누군가 하나를 고르면, 그 고르는 방식에 따라 팀의 실력이 달라질까요.

저는 이 질문이 마음에 들었습니다. 왜냐하면 에이전트 이야기는 대개 더 큰 모델, 더 긴 추론, 더 많은 도구 호출로 흘러가는데, 이 논문은 반대로 작은 것들을 어떻게 묶을지를 묻기 때문입니다. 작은 모델 하나하나는 분명히 한계가 있습니다. 문맥도 짧게 보고, 긴 추론을 끝까지 끌고 가는 힘도 약합니다. 그런데 이런 약한 존재들을 여러 개 모아두면 전혀 다른 성질이 나타날 수 있습니다. 사람으로 치면 신입 몇 명이 모여 각자 초안을 쓰고, 그중에서 제일 나은 것을 고르는 것과 비슷합니다. 신입 한 명의 글은 불안해도, 다섯 명이 쓴 초안 중에서 고르면 결과가 꽤 괜찮을 때가 있죠.

그렇다면 누가 고를까요. 어떻게 고를까요. 무엇을 기준으로 고를까요. 이 고르는 일을 논문은 라우터라는 이름으로 부릅니다. 라우터는 심사위원 같은 존재인데, 직접 글을 쓰지는 않고 고르기만 합니다. 이 구분이 생각보다 여운이 남습니다. 만드는 일과 고르는 일을 분리하면, 만드는 쪽은 가볍게 많이 시도할 수 있고 고르는 쪽은 차분히 비교할 수 있기 때문입니다.

에이전트가 클라우드에 묶여 있으면 느려지는 이유

에이전트 파이프라인을 실제로 돌려본 분들은 아실 텐데요. 모델 호출이 한 번으로 끝나지 않습니다. 계획을 세우고, 도구를 쓰고, 결과를 보고, 다시 계획을 고치는 과정이 몇 번이고 반복됩니다. 이 반복이 전부 클라우드에 있는 거대 모델에 의존하면 네 가지 부담이 함께 커집니다. 논문이 짚는 지점도 바로 여기인데, 지연과 프라이버시, 연결, 그리고 계산 비용이 그것입니다.

지연은 체감으로 다가옵니다. 사용자가 버튼을 누르고 기다리는 몇 초 사이에 왕복이 서너 번만 끼어도 전체가 느릿해지고, 중간에 한 번이라도 네트워크가 흔들리면 파이프라인 전체가 멈춘 것처럼 보입니다. 그래서 응답을 빨리 주고 싶은 팀은 호출 횟수를 줄이거나, 호출을 가볍게 만들거나, 아예 로컬에서 처리하는 쪽을 고민하게 됩니다.

프라이버시는 더 조심스러운 문제입니다. 에이전트가 다루는 입력에는 로그나 문서, 고객 기록처럼 밖으로 내보내기 어려운 내용이 섞여 있기 마련인데, 매 단계를 클라우드로 보내면 검토해야 할 범위가 끝없이 넓어집니다. 연결도 마찬가지입니다. 항상 온라인이라는 가정은 사무실에서는 당연해 보여도, 공장이나 매장, 이동 중인 환경에서는 그렇지 않습니다. 마지막으로 비용은 조용히 쌓입니다. 한 번 호출은 싸 보여도, 수천 개 작업을 매일 반복하면 합계가 달라지죠. 저희가 새로운 AI 아키텍처를 볼 때도 benchmark 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. 이런 관점에서 보면 클라우드 의존을 낮추자는 제안은 단순한 절약 이야기가 아니라 운영의 모양을 바꾸는 이야기입니다.

매번 거대 모델을 부르는 게 아까워지는 순간

에이전트가 하는 일을 가만히 들여다보면 모두가 어려운 일만 하는 것은 아닙니다. 어떤 단계는 정형화되어 있고, 어떤 단계는 범위가 좁고, 어떤 단계는 비슷한 패턴이 계속 반복됩니다. 예를 들어 들어온 요청을 분류하거나, 정해진 형식으로 바꾸거나, 짧은 구간을 요약하거나, 목록에서 조건에 맞는 항목을 고르는 일 같은 것들입니다. 이런 일들은 거대 모델의 넓은 지식을 매번 동원하지 않아도 될 때가 많습니다.

논문은 이 지점을 또렷하게 짚습니다. 에이전트 작업 안에 반복적이고 범위가 좁은 하위 과제들이 많이 섞여 있으며, 그런 과제들은 오히려 전문화된 작은 언어모델이 더 잘 맡을 수 있다는 것입니다. 생각해보면 사람 조직도 비슷하게 돌아갑니다. 모든 결재를 대표이사가 직접 하지 않듯이, 모든 추론을 거대 모델이 직접 할 필요는 없습니다. 자주 나오는 일은 작은 단위가 빠르고 싸게 처리하고, 정말 어려운 판단만 큰 단위가 맡는 편이 자연스럽습니다.

여기서 재미있는 질문이 생깁니다. 그렇다면 어디까지를 작게 쪼갤 수 있을까요. 너무 잘게 쪼개면 관리 비용이 늘고, 너무 크게 묶으면 작은 모델이 감당하지 못합니다. 그래서 작업의 결을 읽는 일이 먼저 옵니다. 어떤 하위 과제는 입력과 출력이 또렷해서 작은 모델에게 맡기기 좋고, 어떤 과제는 배경지식을 넓게 뒤져야 해서 큰 모델이 여전히 필요합니다. 저는 이 구분을 읽는 감각이야말로 에이전트를 설계하는 사람의 실력이라고 봅니다. 모델을 고르는 문제가 아니라 일을 나누는 문제이기 때문입니다.

말을 많이 시키면 작은 모델이 지치는 이유

작은 모델을 여러 개 쓴다고 해서 무조건 좋아지는 것은 아닙니다. 엮는 방식이 잘못되면 약점이 더 크게 드러나기 때문입니다. 논문이 경계하는 대목도 바로 여기인데, 작은 모델의 제한된 용량과 문맥 창이 긴 호흡의 추론이나 상호작용이 많은 오케스트레이션 전략을 제약할 수 있다는 것입니다.

상호작용이 많은 전략이란 이를테면 반복 검증이나 디베이트 같은 방식입니다. 한 모델이 답을 내면 다른 모델이 비판하고, 다시 고치고, 또 토론하는 식이죠. 큰 모델끼리는 이런 대화가 힘을 발휘할 때가 있습니다. 서로의 빈틈을 메워주면서 답을 다듬을 수 있기 때문입니다. 그런데 작은 모델에게 같은 대화를 시키면 이야기가 달라집니다. 주고받는 말이 길어질수록 문맥이 빨리 찹니다. 앞부분의 조건을 잊거나, 상대의 지적을 제대로 반영하지 못한 채 비슷한 말을 반복하기도 합니다. 토론을 하면 할수록 좋아지는 게 아니라, 말을 많이 시킬수록 지치는 셈입니다.

(참고로 사람도 긴 회의가 이어지면 집중력이 떨어지는데요. 작은 모델의 문맥 제약은 그와 비슷한 피로라고 이해하면 감이 옵니다.)

문제는 그다음입니다. 상호작용을 늘릴수록 조정 비용도 늘어납니다. 누가 언제 말할지 정해야 하고, 대화 기록을 계속 들고 있어야 하며, 중간에 빗나간 흐름을 되돌리는 장치도 필요합니다. 작은 모델 여러 개를 대화로 묶는 일은 그래서 겉보기보다 손이 많이 갑니다. 저는 여기서 조금 멈칫했습니다. 흔히 에이전트라면 서로 대화해야 똑똑해진다고 믿기 쉬운데, 작은 모델에게는 대화 자체가 부담이 될 수 있다는 지적이 신선했기 때문입니다. 그렇다면 대화를 줄이면서도 지혜를 모으는 방법은 없을까요. 이 질문이 다음 대목으로 이어집니다.

각자 따로 풀고 나중에 고르는 방식은 무엇이 다른가

논문이 제안하는 보완적인 길은 비인터랙티브 패러다임입니다. 이름이 조금 딱딱하게 들리지만, 뜻은 단순합니다. 서로 다른 작은 모델들이 각자 독립적으로 답 후보를 만들고, 그 뒤에는 모델끼리 더 이상 대화를 나누지 않는다는 것입니다. 토론도 없고, 반복 검증도 없습니다. 각자 풀고, 모아두고, 고릅니다.

이 방식이 주는 첫인상은 어쩌면 밋밋할 수 있습니다. 대화를 안 하면 뭔가 손해 보는 느낌이 들기 때문입니다. 그런데 운영 관점에서 보면 이 단순함이 꽤 매력적입니다. 각 모델이 독립적이면 일을 병렬로 벌리기 쉽고, 실패한 하나가 전체를 끌고 내려가는 일도 줄어듭니다. 어느 하나가 이상한 답을 내도 다른 후보가 살아 있으면 고르는 쪽에서 걸러낼 수 있죠. 논의 단계를 걷어내고 생성과 선택만 남긴 셈입니다.

저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 아니, 숫자 이야기가 아니라 구조 이야기입니다. 생성과 선택을 분리하면 두 쪽을 따로 개선할 수 있습니다. 생성 쪽은 다양성을 늘리는 방향으로, 선택 쪽은 정확도를 높이는 방향으로 나아갈 수 있습니다. 다양성이 부족하면 비슷한 답만 쌓이고, 선택이 약하면 좋은 답을 두고 다른 답을 집습니다. 그래서 어느 쪽이 병목인지 따로 볼 수 있다는 점이 연구로서도, 제품으로서도 편합니다. 대화를 섞으면 원인을 찾기가 어려워지는데, 단계를 나누면 어디가 문제인지 드러나기 때문입니다.

다시 묻지 않고 고르는 라우터는 어떻게 일할까

비인터랙티브라는 말이 성립하려면 라우터의 역할이 분명해야 합니다. 논문에서 라우터는 캐시된 작은 모델 샘플들을 오케스트레이션하는데, 이 과정에서 모델과의 추가 상호작용은 일어나지 않습니다. 다시 묻지 않고, 모아둔 후보 안에서 고릅니다.

이 장면을 구체적으로 그려보면 이렇습니다. 아침에 고객 요청이 수백 건 들어오는 상황을 떠올려보죠. 작은 모델 A는 분류에 강하고, 작은 모델 B는 짧은 요약에 익숙하고, 작은 모델 C는 정해진 형식으로 바꾸는 데 익숙합니다. 각 모델은 자기 방식대로 후보를 몇 개씩 만들어 캐시에 쌓아둡니다. 라우터는 그 캐시를 보고 과제 성격에 맞는 것을 고릅니다. 중간에 모델에게 다시 전화를 걸어 물어보지 않습니다. 이미 쌓인 것 안에서 고르는 것이죠.

그래서 캐시라는 개념이 생각보다 결정적입니다. 캐시는 단순한 저장소가 아니라 시간과 비용을 나누는 장치이기 때문입니다. 생성을 미리 해두거나 병렬로 해두면, 선택 시점에는 가벼운 연산만으로 답을 고를 수 있습니다. 물론 캐시가 만능은 아닙니다. 후보가 전부 비슷하면 고를 게 없고, 후보가 전부 틀렸으면 고르는 일 자체가 무의미해집니다. 그럼에도 이 구조는 운영자에게 분명한 선택지를 줍니다. 급하면 적은 후보로 빨리 고르고, 여유가 있으면 많은 후보를 모아 천천히 고르면 됩니다. 실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 좋은데, 이 캐시를 어디에 두고 얼마나 들고 있을까요. 메모리와 저장공간, 신선도의 문제까지 함께 따라오기 때문입니다.

제각각이던 방법들을 하나의 틀로 묶으면 보이는 것

이 논문에서 제가 가장 눈여겨본 부분은 새로운 선택 방식을 하나 더 내놓았다는 데 있지 않습니다. 기존에 있던 비인터랙티브 오케스트레이션 방법들을 하나의 라우팅 틀로 묶고, 그 안에 숨어 있던 설계 선택들을 조절 가능한 파라미터로 드러냈다는 데 있습니다.

연구의 흐름을 돌아보면 질문도 바뀌어왔습니다. 처음에는 어떤 선택 방식이 좋은가를 물었고, 다음에는 좋은 선택 방식을 자동으로 찾을 수 있는가를 물었으며, 이제는 서로 다른 선택 방식들이 사실은 같은 틀 안에서 몇 개의 손잡이만 다르게 돌린 것이라는 데까지 온 셈입니다. 이렇게 묶으면 비교가 쉬워집니다. A 방식과 B 방식이 완전히 다른 철학처럼 보여도, 틀 안에서 보면 어느 손잡이를 다르게 돌렸는지가 드러나기 때문입니다.

이런 통일이 주는 실용적인 이득도 있습니다. 팀에서 어떤 방식을 쓸지 고민할 때 처음부터 다시 실험하지 않아도 됩니다. 같은 틀 위에서 손잡이만 바꿔보면서 우리 과제에 맞는 조합을 찾을 수 있습니다. 예를 들어 후보를 몇 개 모을지, 어떤 모델들을 풀에 넣을지, 합의를 어떻게 볼지를 하나씩 바꿔보면서 움직임을 관찰할 수 있습니다. 반면 주의할 점도 있습니다. 틀로 묶었다고 해서 모든 방법이 같아지는 것은 아닙니다. 같은 손잡이를 돌려도 과제 성격에 따라 결과가 다르게 나올 수 있기 때문입니다. 그래서 통일은 끝이 아니라 시작입니다. 이제 손잡이를 돌렸을 때 무엇이 달라지는지를 하나씩 살펴볼 차례입니다.

과제 구조에 따라 팀의 답이 달라지는 이유

논문이 말하는 첫 번째 손잡이는 과제 구조입니다. 같은 모델 풀, 같은 라우터라도 과제의 생김새가 달라지면 오케스트레이션의 움직임이 달라진다는 것입니다.

이 대목은 일상적인 비유로 풀면 잘 와닿습니다. 일종의 시험 문제집이라고 생각해보죠. 어떤 문제는 정답이 하나로 또렷하고, 어떤 문제는 그럴듯한 답이 여러 개입니다. 또 어떤 문제는 풀이 과정이 짧고, 어떤 문제는 중간 단계를 차근차근 밟아야 합니다. 정답이 또렷한 문제에서는 다양한 후보를 모아도 고르는 일이 비교적 쉽습니다. 후보들이 정답 근처에 모이기 때문입니다. 반면 그럴듯한 답이 여러 개인 문제에서는 고르는 일이 훨씬 어려워집니다. 후보마다 각자의 그럴듯함이 있어서 라우터의 판단 기준이 더 정교해야 하기 때문입니다.

여기서 한 걸음 더 들어가면 이런 질문이 생깁니다. 그렇다면 과제를 그대로 둘 것인가, 아니면 고르기 쉽게 바꿀 것인가. 과제를 잘게 나누면 작은 모델이 풀기 쉬워지지만 나누는 기준을 정하는 일이 새로 생깁니다. 반대로 과제를 크게 두면 나누는 수고는 줄지만 작은 모델이 버거워합니다. 저는 이 대목에서 설계자의 손맛이 드러난다고 봅니다. 모델을 바꾸는 것보다 과제를 다듬는 쪽이 전체 성능을 더 크게 바꾸는 경우가 있기 때문입니다. 에이전트 파이프라인을 만질 때도 입력 형식을 조금 다듬거나, 조건을 먼저 걸러주거나, 출력 형식을 고정하는 것만으로 작은 모델들의 정답률이 달라지는 경험을 하신 분들이 있을 텐데요. 과제 구조라는 손잡이는 바로 그런 경험을 정식으로 다루는 자리에 가깝습니다.

모델 풀을 어떻게 짜느냐가 결과를 가른다

두 번째 손잡이는 모델 풀의 구성입니다. 어떤 작은 모델들을 모아둘 것인가의 문제인데, 이 선택이 오케스트레이션의 성격을 크게 바꿉니다.

비슷한 모델만 모아두면 후보들이 비슷해집니다. 안정적으로 보이지만 다양성이 떨어집니다. 어느 하나가 틀리면 나머지도 함께 틀릴 가능성이 높습니다. 반대로 서로 다른 모델들을 섞어두면 후보들의 결이 달라집니다. 어떤 모델은 짧은 지시에 강하고, 어떤 모델은 특정 형식에 강하고, 어떤 모델은 다른 도메인의 표현에 익숙합니다. 이렇게 결이 다르면 하나가 놓친 것을 다른 하나가 잡아낼 여지가 생깁니다. 다양성이 일종의 보험이 되는 셈입니다.

그런데 다양성이 항상 좋은 것만은 아닙니다. 결이 너무 다르면 라우터가 비교하기 어려워집니다. 사과와 자전거를 놓고 어느 쪽이 더 좋은 답인지 고르는 것처럼 기준이 흔들릴 수 있기 때문입니다. 그래서 풀을 짤 때는 비슷한 듯 다른 조합을 찾는 감각이 필요합니다. 겹치는 부분은 있어야 비교가 되고, 다른 부분은 있어야 고를 맛이 납니다.

실제 운영에서는 비용의 결도 함께 봐야 합니다. 풀에 모델을 많이 넣으면 후보가 풍부해지지만 생성 비용과 캐시 부담이 늘어납니다. 적게 넣으면 가볍지만 선택의 폭이 좁아집니다. 저는 그래서 풀 구성 문제를 단순한 모델 쇼핑이 아니라 예산 배분 문제로 봅니다. 같은 예산을 어디에 쓸지 고르는 일인데, 하나의 큰 모델에 쓸지, 여러 개의 작은 모델에 나눠 쓸지, 그 작은 모델들을 어떻게 다르게 기를지가 함께 걸려 있기 때문입니다.

합의를 어떻게 읽느냐에 따라 최종 답이 달라진다

세 번째 손잡이는 다중에이전트 합의입니다. 여러 모델이 내놓은 후보들을 어떻게 모아 최종 답으로 삼을지의 문제입니다.

합의라고 하면 흔히 투표를 떠올립니다. 다수가 말한 것을 고르는 방식이죠. 그런데 합의의 결은 투표보다 넓습니다. 여러 후보가 서로 가리키는 방향을 읽는 것, 겹치는 부분을 추리는 것, 흩어진 답들 사이에서 중심을 찾는 것까지 모두 합의의 방식에 들어갑니다. 후보들이 한곳에 모이면 합의는 쉽습니다. 어디를 골라도 크게 다르지 않기 때문입니다. 후보들이 흩어져 있으면 합의는 어려워집니다. 어느 쪽 손을 들어줄지 기준이 필요하기 때문입니다.

여기서는 조금 조심해서 읽을 필요가 있습니다. 합의가 잘 됐다고 해서 정답이라는 보장은 없기 때문입니다. 여러 모델이 같은 오해를 공유하면 합의는 또렷해지지만 답은 틀립니다. 반대로 소수 의견이 정답인 경우도 있습니다. 어려운 문제일수록 다수가 틀리고 소수가 맞는 일이 생기죠. 그래서 합의를 읽는 일은 단순한 다수결이 아니라 분포를 읽는 일에 가깝습니다. 후보들이 어떻게 흩어져 있는지, 그 흩어짐이 우연인지 치우침인지, 라우터가 그 모양을 얼마나 잘 읽는지가 결과를 가릅니다.

개인적으로 와닿았던 대목은 합의가 상호작용 없이도 가능하다는 점입니다. 서로 대화를 나누지 않아도, 모아둔 후보들의 모양만으로 어느 정도 합의를 읽을 수 있다는 것입니다. 대화를 줄이면 비용과 지연이 줄고, 그 빈자리를 후보의 다양성과 라우터의 판단으로 메우는 구조입니다. 물론 대화가 주는 다듬기의 맛은 줄어듭니다. 그럼에도 많은 반복 과제에서는 이 정도 합의로 충분한 경우가 있습니다. 모든 문제에 토론이 필요한 것은 아니기 때문입니다.

캐시가 쌓이면 운영의 풍경이 달라진다

지금까지의 이야기를 운영의 눈으로 다시 보면 캐시의 존재감이 커집니다. 생성과 선택을 나누고, 선택 시점에 다시 묻지 않는 구조에서는 모아둔 후보의 질과 양이 곧 성능이기 때문입니다.

캐시가 있으면 좋은 점이 여럿 있습니다. 먼저 지연을 다스리기 쉽습니다. 생성을 미리 해두거나 병렬로 돌려두면, 사용자가 기다리는 순간에는 고르는 일만 남습니다. 다음으로 프라이버시와 연결의 부담을 나누기 쉽습니다. 민감한 판단은 로컬의 작은 모델과 캐시 안에서 처리하고, 꼭 필요한 경우에만 바깥의 큰 모델을 부르는 식으로 경계를 그을 수 있습니다. 마지막으로 비용의 모양이 바뀝니다. 매번 큰 모델을 부르는 변동 비용 대신, 작은 모델들의 생성과 저장이라는 다른 비용으로 바뀝니다. 어느 쪽이 싼지는 workload마다 다르지만, 적어도 선택지가 생긴다는 점이 다릅니다.

반면 캐시는 공짜가 아닙니다. 쌓아두면 신선도가 문제됩니다. 어제 만든 후보가 오늘도 유효한지, 입력 분포가 바뀌면 캐시를 얼마나 빨리 갈아야 하는지 따져야 합니다. 저장공간과 메모리도 봐야 합니다. 후보를 많이 쌓을수록 고를 폭은 넓어지지만 들고 있는 짐도 무거워집니다. 그래서 캐시 정책은 연구의 바깥이 아니라 안쪽에 있습니다. 무엇을 얼마나 쌓아둘지, 언제 버릴지, 어떤 과제의 후보를 우선 보관할지가 오케스트레이션의 일부가 되기 때문입니다. 좋은 건 알겠는데, 이걸 실제로 어떻게 서빙할까요. 이 질문에 답하려면 모델 실력만큼이나 캐시 운영을 함께 이야기해야 합니다.

그래서 다음에는 무엇을 보면 좋을까

앞에서 살펴본 손잡이들을 한데 모아보면 논문의 태도가 보입니다. 새로운 필살기를 내놓기보다, 오케스트레이션의 움직임이 어디에서 나오는지를 드러내겠다는 태도입니다. 과제 구조와 모델 풀 구성, 그리고 합의라는 손잡이를 돌려보면서 움직임의 결을 읽겠다는 것이죠. 저는 이 접근이 마음에 듭니다. 에이전트를 만들다 보면 어느 날은 잘 되던 조합이 다음 날은 흔들리는데, 그 이유를 손잡이의 언어로 설명할 수 있으면 다음 시도가 쉬워지기 때문입니다.

다만 과장하지 않고 읽을 대목도 있습니다. 비인터랙티브가 모든 상호작용을 대체한다는 이야기로 읽으면 어긋납니다. 논문이 말하는 것은 보완적인 길에 가깝습니다. 대화와 검증이 꼭 필요한 어려운 추론도 있고, 모아둔 후보 안에서 고르는 것만으로 충분한 반복 과제도 있다는 것입니다. 어디에 무엇을 쓸지를 가르는 눈이 여전히 필요합니다. 또한 손잡이를 돌렸을 때의 움직임이 모든 과제와 모든 풀에서 똑같이 나타난다고 일반화하기도 어렵습니다. 과제와 풀과 합의가 맞물려 돌아가는 구조에서는 조건이 바뀌면 결이 달라질 수 있기 때문입니다.

제가 앞으로 보고 싶은 것은 이 손잡이들이 실제 serving 조건과 만났을 때의 모습입니다. 지연 예산이 빡빡한 자리에서는 후보를 몇 개까지 모을 수 있을까요. 연결이 끊긴 자리에서는 로컬의 풀과 캐시만으로 어디까지 갈 수 있을까요. 프라이버시 경계가 엄격한 자리에서는 어떤 과제를 로컬에 남기고 어떤 것만 바깥으로 보낼까요. 그리고 라우터 자체의 비용은 얼마나 될까요. 고르는 일이 너무 무거워지면 가벼운 생성의 이득이 줄어들 수 있기 때문입니다. 이런 질문들은 논문 한 편으로 닫히지 않습니다. 오히려 논문이 손잡이를 보여줬기 때문에 비로소 물을 수 있게 된 질문들에 가깝습니다.

여러 모델이 함께 일하는 풍경은 앞으로 더 흔해질 것 같습니다. 모두가 거대해지는 쪽으로만 가지 않고, 작아지고 흩어지고 각자의 몫을 맡는 쪽으로도 갈 것이기 때문입니다. 그렇다면 남는 질문은 하나입니다. 우리는 만드는 힘과 고르는 힘 중 어디에 더 투자해야 할까요. OrchSLM은 고르는 힘의 쪽에 조명을 비추면서, 그 조명 아래에 놓인 손잡이들을 하나씩 보여준 논문으로 기억될 것 같습니다. 다음에 에이전트 파이프라인에서 반복되는 호출을 마주하면, 저는 먼저 이 질문부터 떠올리게 될 것 같습니다. 이건 대화로 풀어야 할 문제일까, 아니면 모아두고 고르면 될 문제일까.